1 \input texinfo @c -*-texinfo-*-
5 @set last-update 1999-04-23
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.
264 * Front End:: Design and implementation of the @code{g77} front end.
267 * M: Diagnostics. Diagnostics produced by @code{g77}.
269 * Index:: Index of concepts and symbol names.
271 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
274 @unnumbered GNU GENERAL PUBLIC LICENSE
275 @center Version 2, June 1991
278 Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
279 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
281 Everyone is permitted to copy and distribute verbatim copies
282 of this license document, but changing it is not allowed.
285 @unnumberedsec Preamble
287 The licenses for most software are designed to take away your
288 freedom to share and change it. By contrast, the GNU General Public
289 License is intended to guarantee your freedom to share and change free
290 software---to make sure the software is free for all its users. This
291 General Public License applies to most of the Free Software
292 Foundation's software and to any other program whose authors commit to
293 using it. (Some other Free Software Foundation software is covered by
294 the GNU Library General Public License instead.) You can apply it to
297 When we speak of free software, we are referring to freedom, not
298 price. Our General Public Licenses are designed to make sure that you
299 have the freedom to distribute copies of free software (and charge for
300 this service if you wish), that you receive source code or can get it
301 if you want it, that you can change the software or use pieces of it
302 in new free programs; and that you know you can do these things.
304 To protect your rights, we need to make restrictions that forbid
305 anyone to deny you these rights or to ask you to surrender the rights.
306 These restrictions translate to certain responsibilities for you if you
307 distribute copies of the software, or if you modify it.
309 For example, if you distribute copies of such a program, whether
310 gratis or for a fee, you must give the recipients all the rights that
311 you have. You must make sure that they, too, receive or can get the
312 source code. And you must show them these terms so they know their
315 We protect your rights with two steps: (1) copyright the software, and
316 (2) offer you this license which gives you legal permission to copy,
317 distribute and/or modify the software.
319 Also, for each author's protection and ours, we want to make certain
320 that everyone understands that there is no warranty for this free
321 software. If the software is modified by someone else and passed on, we
322 want its recipients to know that what they have is not the original, so
323 that any problems introduced by others will not reflect on the original
324 authors' reputations.
326 Finally, any free program is threatened constantly by software
327 patents. We wish to avoid the danger that redistributors of a free
328 program will individually obtain patent licenses, in effect making the
329 program proprietary. To prevent this, we have made it clear that any
330 patent must be licensed for everyone's free use or not licensed at all.
332 The precise terms and conditions for copying, distribution and
336 @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
339 @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
344 This License applies to any program or other work which contains
345 a notice placed by the copyright holder saying it may be distributed
346 under the terms of this General Public License. The ``Program'', below,
347 refers to any such program or work, and a ``work based on the Program''
348 means either the Program or any derivative work under copyright law:
349 that is to say, a work containing the Program or a portion of it,
350 either verbatim or with modifications and/or translated into another
351 language. (Hereinafter, translation is included without limitation in
352 the term ``modification''.) Each licensee is addressed as ``you''.
354 Activities other than copying, distribution and modification are not
355 covered by this License; they are outside its scope. The act of
356 running the Program is not restricted, and the output from the Program
357 is covered only if its contents constitute a work based on the
358 Program (independent of having been made by running the Program).
359 Whether that is true depends on what the Program does.
362 You may copy and distribute verbatim copies of the Program's
363 source code as you receive it, in any medium, provided that you
364 conspicuously and appropriately publish on each copy an appropriate
365 copyright notice and disclaimer of warranty; keep intact all the
366 notices that refer to this License and to the absence of any warranty;
367 and give any other recipients of the Program a copy of this License
368 along with the Program.
370 You may charge a fee for the physical act of transferring a copy, and
371 you may at your option offer warranty protection in exchange for a fee.
374 You may modify your copy or copies of the Program or any portion
375 of it, thus forming a work based on the Program, and copy and
376 distribute such modifications or work under the terms of Section 1
377 above, provided that you also meet all of these conditions:
381 You must cause the modified files to carry prominent notices
382 stating that you changed the files and the date of any change.
385 You must cause any work that you distribute or publish, that in
386 whole or in part contains or is derived from the Program or any
387 part thereof, to be licensed as a whole at no charge to all third
388 parties under the terms of this License.
391 If the modified program normally reads commands interactively
392 when run, you must cause it, when started running for such
393 interactive use in the most ordinary way, to print or display an
394 announcement including an appropriate copyright notice and a
395 notice that there is no warranty (or else, saying that you provide
396 a warranty) and that users may redistribute the program under
397 these conditions, and telling the user how to view a copy of this
398 License. (Exception: if the Program itself is interactive but
399 does not normally print such an announcement, your work based on
400 the Program is not required to print an announcement.)
403 These requirements apply to the modified work as a whole. If
404 identifiable sections of that work are not derived from the Program,
405 and can be reasonably considered independent and separate works in
406 themselves, then this License, and its terms, do not apply to those
407 sections when you distribute them as separate works. But when you
408 distribute the same sections as part of a whole which is a work based
409 on the Program, the distribution of the whole must be on the terms of
410 this License, whose permissions for other licensees extend to the
411 entire whole, and thus to each and every part regardless of who wrote it.
413 Thus, it is not the intent of this section to claim rights or contest
414 your rights to work written entirely by you; rather, the intent is to
415 exercise the right to control the distribution of derivative or
416 collective works based on the Program.
418 In addition, mere aggregation of another work not based on the Program
419 with the Program (or with a work based on the Program) on a volume of
420 a storage or distribution medium does not bring the other work under
421 the scope of this License.
424 You may copy and distribute the Program (or a work based on it,
425 under Section 2) in object code or executable form under the terms of
426 Sections 1 and 2 above provided that you also do one of the following:
430 Accompany it with the complete corresponding machine-readable
431 source code, which must be distributed under the terms of Sections
432 1 and 2 above on a medium customarily used for software interchange; or,
435 Accompany it with a written offer, valid for at least three
436 years, to give any third party, for a charge no more than your
437 cost of physically performing source distribution, a complete
438 machine-readable copy of the corresponding source code, to be
439 distributed under the terms of Sections 1 and 2 above on a medium
440 customarily used for software interchange; or,
443 Accompany it with the information you received as to the offer
444 to distribute corresponding source code. (This alternative is
445 allowed only for noncommercial distribution and only if you
446 received the program in object code or executable form with such
447 an offer, in accord with Subsection b above.)
450 The source code for a work means the preferred form of the work for
451 making modifications to it. For an executable work, complete source
452 code means all the source code for all modules it contains, plus any
453 associated interface definition files, plus the scripts used to
454 control compilation and installation of the executable. However, as a
455 special exception, the source code distributed need not include
456 anything that is normally distributed (in either source or binary
457 form) with the major components (compiler, kernel, and so on) of the
458 operating system on which the executable runs, unless that component
459 itself accompanies the executable.
461 If distribution of executable or object code is made by offering
462 access to copy from a designated place, then offering equivalent
463 access to copy the source code from the same place counts as
464 distribution of the source code, even though third parties are not
465 compelled to copy the source along with the object code.
468 You may not copy, modify, sublicense, or distribute the Program
469 except as expressly provided under this License. Any attempt
470 otherwise to copy, modify, sublicense or distribute the Program is
471 void, and will automatically terminate your rights under this License.
472 However, parties who have received copies, or rights, from you under
473 this License will not have their licenses terminated so long as such
474 parties remain in full compliance.
477 You are not required to accept this License, since you have not
478 signed it. However, nothing else grants you permission to modify or
479 distribute the Program or its derivative works. These actions are
480 prohibited by law if you do not accept this License. Therefore, by
481 modifying or distributing the Program (or any work based on the
482 Program), you indicate your acceptance of this License to do so, and
483 all its terms and conditions for copying, distributing or modifying
484 the Program or works based on it.
487 Each time you redistribute the Program (or any work based on the
488 Program), the recipient automatically receives a license from the
489 original licensor to copy, distribute or modify the Program subject to
490 these terms and conditions. You may not impose any further
491 restrictions on the recipients' exercise of the rights granted herein.
492 You are not responsible for enforcing compliance by third parties to
496 If, as a consequence of a court judgment or allegation of patent
497 infringement or for any other reason (not limited to patent issues),
498 conditions are imposed on you (whether by court order, agreement or
499 otherwise) that contradict the conditions of this License, they do not
500 excuse you from the conditions of this License. If you cannot
501 distribute so as to satisfy simultaneously your obligations under this
502 License and any other pertinent obligations, then as a consequence you
503 may not distribute the Program at all. For example, if a patent
504 license would not permit royalty-free redistribution of the Program by
505 all those who receive copies directly or indirectly through you, then
506 the only way you could satisfy both it and this License would be to
507 refrain entirely from distribution of the Program.
509 If any portion of this section is held invalid or unenforceable under
510 any particular circumstance, the balance of the section is intended to
511 apply and the section as a whole is intended to apply in other
514 It is not the purpose of this section to induce you to infringe any
515 patents or other property right claims or to contest validity of any
516 such claims; this section has the sole purpose of protecting the
517 integrity of the free software distribution system, which is
518 implemented by public license practices. Many people have made
519 generous contributions to the wide range of software distributed
520 through that system in reliance on consistent application of that
521 system; it is up to the author/donor to decide if he or she is willing
522 to distribute software through any other system and a licensee cannot
525 This section is intended to make thoroughly clear what is believed to
526 be a consequence of the rest of this License.
529 If the distribution and/or use of the Program is restricted in
530 certain countries either by patents or by copyrighted interfaces, the
531 original copyright holder who places the Program under this License
532 may add an explicit geographical distribution limitation excluding
533 those countries, so that distribution is permitted only in or among
534 countries not thus excluded. In such case, this License incorporates
535 the limitation as if written in the body of this License.
538 The Free Software Foundation may publish revised and/or new versions
539 of the General Public License from time to time. Such new versions will
540 be similar in spirit to the present version, but may differ in detail to
541 address new problems or concerns.
543 Each version is given a distinguishing version number. If the Program
544 specifies a version number of this License which applies to it and ``any
545 later version'', you have the option of following the terms and conditions
546 either of that version or of any later version published by the Free
547 Software Foundation. If the Program does not specify a version number of
548 this License, you may choose any version ever published by the Free Software
552 If you wish to incorporate parts of the Program into other free
553 programs whose distribution conditions are different, write to the author
554 to ask for permission. For software which is copyrighted by the Free
555 Software Foundation, write to the Free Software Foundation; we sometimes
556 make exceptions for this. Our decision will be guided by the two goals
557 of preserving the free status of all derivatives of our free software and
558 of promoting the sharing and reuse of software generally.
568 BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
569 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
570 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
571 PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
572 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
573 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
574 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
575 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
576 REPAIR OR CORRECTION.
579 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
580 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
581 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
582 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
583 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
584 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
585 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
586 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
587 POSSIBILITY OF SUCH DAMAGES.
591 @heading END OF TERMS AND CONDITIONS
594 @center END OF TERMS AND CONDITIONS
598 @unnumberedsec How to Apply These Terms to Your New Programs
600 If you develop a new program, and you want it to be of the greatest
601 possible use to the public, the best way to achieve this is to make it
602 free software which everyone can redistribute and change under these terms.
604 To do so, attach the following notices to the program. It is safest
605 to attach them to the start of each source file to most effectively
606 convey the exclusion of warranty; and each file should have at least
607 the ``copyright'' line and a pointer to where the full notice is found.
610 @var{one line to give the program's name and a brief idea of what it does.}
611 Copyright (C) 19@var{yy} @var{name of author}
613 This program is free software; you can redistribute it and/or modify
614 it under the terms of the GNU General Public License as published by
615 the Free Software Foundation; either version 2 of the License, or
616 (at your option) any later version.
618 This program is distributed in the hope that it will be useful,
619 but WITHOUT ANY WARRANTY; without even the implied warranty of
620 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
621 GNU General Public License for more details.
623 You should have received a copy of the GNU General Public License
624 along with this program; if not, write to the Free Software
625 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
628 Also add information on how to contact you by electronic and paper mail.
630 If the program is interactive, make it output a short notice like this
631 when it starts in an interactive mode:
634 Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
635 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
637 This is free software, and you are welcome to redistribute it
638 under certain conditions; type `show c' for details.
641 The hypothetical commands @samp{show w} and @samp{show c} should show
642 the appropriate parts of the General Public License. Of course, the
643 commands you use may be called something other than @samp{show w} and
644 @samp{show c}; they could even be mouse-clicks or menu items---whatever
647 You should also get your employer (if you work as a programmer) or your
648 school, if any, to sign a ``copyright disclaimer'' for the program, if
649 necessary. Here is a sample; alter the names:
652 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
653 `Gnomovision' (which makes passes at compilers) written by James Hacker.
655 @var{signature of Ty Coon}, 1 April 1989
656 Ty Coon, President of Vice
659 This General Public License does not permit incorporating your program into
660 proprietary programs. If your program is a subroutine library, you may
661 consider it more useful to permit linking proprietary applications with the
662 library. If this is what you want to do, use the GNU Library General
663 Public License instead of this License.
666 @unnumbered Contributors to GNU Fortran
670 In addition to James Craig Burley, who wrote the front end,
671 many people have helped create and improve GNU Fortran.
675 The packaging and compiler portions of GNU Fortran are based largely
676 on the GNU CC compiler.
677 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
678 for more information.
681 The run-time library used by GNU Fortran is a repackaged version
682 of the @code{libf2c} library (combined from the @code{libF77} and
683 @code{libI77} libraries) provided as part of @code{f2c}, available for
684 free from @code{netlib} sites on the Internet.
687 Cygnus Support and The Free Software Foundation contributed
688 significant money and/or equipment to Craig's efforts.
691 The following individuals served as alpha testers prior to @code{g77}'s
692 public release. This work consisted of testing, researching, sometimes
693 debugging, and occasionally providing small amounts of code and fixes
694 for @code{g77}, plus offering plenty of helpful advice to Craig:
700 Dr.@: Mark Fernyhough
702 Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
706 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
708 Dr.@: A. O. V. Le Blanc
730 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
731 provided the patch to add rudimentary support
732 for @code{INTEGER*1}, @code{INTEGER*2}, and
734 This inspired Craig to add further support,
735 even though the resulting support
736 would still be incomplete, because version 0.6 is still
740 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
741 and encouraged Craig to rewrite the documentation in texinfo
742 format by contributing a first pass at a translation of the
743 old @file{g77-0.5.16/f/DOC} file.
746 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
747 some analysis of generated code as part of an overall project
748 to improve @code{g77} code generation to at least be as good
749 as @code{f2c} used in conjunction with @code{gcc}.
750 So far, this has resulted in the three, somewhat
751 experimental, options added by @code{g77} to the @code{gcc}
752 compiler and its back end.
754 (These, in turn, have made their way into the @code{egcs}
755 version of the compiler, and do not exist in @code{gcc}
756 version 2.8 or versions of @code{g77} based on that version
760 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
763 Thanks to Mary Cortani and the staff at Craftwork Solutions
764 (@email{support@@craftwork.com}) for all of their support.
767 Many other individuals have helped debug, test, and improve @code{g77}
768 over the past several years, and undoubtedly more people
769 will be doing so in the future.
770 If you have done so, and would like
771 to see your name listed in the above list, please ask!
772 The default is that people wish to remain anonymous.
776 @chapter Funding Free Software
778 If you want to have more free software a few years from now, it makes
779 sense for you to help encourage people to contribute funds for its
780 development. The most effective approach known is to encourage
781 commercial redistributors to donate.
783 Users of free software systems can boost the pace of development by
784 encouraging for-a-fee distributors to donate part of their selling price
785 to free software developers---the Free Software Foundation, and others.
787 The way to convince distributors to do this is to demand it and expect
788 it from them. So when you compare distributors, judge them partly by
789 how much they give to free software development. Show distributors
790 they must compete to be the one who gives the most.
792 To make this approach work, you must insist on numbers that you can
793 compare, such as, ``We will donate ten dollars to the Frobnitz project
794 for each disk sold.'' Don't be satisfied with a vague promise, such as
795 ``A portion of the profits are donated,'' since it doesn't give a basis
798 Even a precise fraction ``of the profits from this disk'' is not very
799 meaningful, since creative accounting and unrelated business decisions
800 can greatly alter what fraction of the sales price counts as profit.
801 If the price you pay is $50, ten percent of the profit is probably
802 less than a dollar; it might be a few cents, or nothing at all.
804 Some redistributors do development work themselves. This is useful too;
805 but to keep everyone honest, you need to inquire how much they do, and
806 what kind. Some kinds of development make much more long-term
807 difference than others. For example, maintaining a separate version of
808 a program contributes very little; maintaining the standard version of a
809 program for the whole community contributes much. Easy new ports
810 contribute little, since someone else would surely do them; difficult
811 ports such as adding a new CPU to the GNU C compiler contribute more;
812 major new features or packages contribute the most.
814 By establishing the idea that supporting further development is ``the
815 proper thing to do'' when distributing free software for a fee, we can
816 assure a steady flow of resources into making more free software.
819 Copyright (C) 1994 Free Software Foundation, Inc.
820 Verbatim copying and redistribution of this section is permitted
821 without royalty; alteration is not permitted.
824 @node Funding GNU Fortran
825 @chapter Funding GNU Fortran
826 @cindex funding improvements
827 @cindex improvements, funding
829 Work on GNU Fortran is still being done mostly by its author,
830 James Craig Burley (@email{@value{email-burley}}), who is a volunteer
831 for, not an employee of, the Free Software Foundation (FSF).
832 (He has a web page at @uref{@value{www-burley}}.)
834 As with other GNU software, funding is important because it can pay for
835 needed equipment, personnel, and so on.
837 @cindex FSF, funding the
838 @cindex funding the FSF
839 The FSF provides information on the best way to fund ongoing
840 development of GNU software (such as GNU Fortran) in documents
841 such as the ``GNUS Bulletin''.
842 Email @email{gnu@@gnu.org} for information on funding the FSF.
844 To fund specific GNU Fortran work in particular, the FSF might
845 provide a means for that, but the FSF does not provide direct funding
846 to the author of GNU Fortran to continue his work. The FSF has
847 employee salary restrictions that can be incompatible with the
848 financial needs of some volunteers, who therefore choose to
849 remain volunteers and thus be able to be free to do contract work
850 and otherwise make their own schedules for doing GNU work.
852 Still, funding the FSF at least indirectly benefits work
853 on specific projects like GNU Fortran because it ensures the
854 continuing operation of the FSF offices, their workstations, their
855 network connections, and so on, which are invaluable to volunteers.
856 (Similarly, hiring Cygnus Support can help a project like GNU
857 Fortran---Cygnus has been a long-time donor of equipment usage to the author
858 of GNU Fortran, and this too has been invaluable---@xref{Contributors}.)
860 Currently, the only way to directly fund the author of GNU Fortran
861 in his work on that project is to hire him for the work you want
862 him to do, or donate money to him.
863 Several people have done this
864 already, with the result that he has not needed to immediately find
865 contract work on a few occasions.
866 If more people did this, he
867 would be able to plan on not doing contract work for many months and
868 could thus devote that time to work on projects (such as the planned
869 changes for 0.6) that require longer timeframes to complete.
870 For the latest information on the status of the author, do
871 @kbd{finger -l burley@@gnu.org} on a UNIX system
872 (or any system with a command like UNIX @code{finger}).
874 Another important way to support work on GNU Fortran is to volunteer
876 Work is needed on documentation, testing, porting
877 to various machines, and in some cases, coding (although major
878 changes planned for version 0.6 make it difficult to add manpower to this
880 Email @email{@value{email-general}} to volunteer for this work.
882 @xref{Funding,,Funding Free Software}, for more information.
885 @chapter Protect Your Freedom---Fight ``Look And Feel''
886 @c the above chapter heading overflows onto the next line. --mew 1/26/93
888 To preserve the ability to write free software, including replacements
889 for proprietary software, authors must be free to replicate the
890 user interface to which users of existing software have become
893 @xref{Look and Feel,,Protect Your Freedom---Fight ``Look And Feel'',
894 gcc,Using and Porting GNU CC}, for more information.
896 @node Getting Started
897 @chapter Getting Started
898 @cindex getting started
903 If you don't need help getting started reading the portions
904 of this manual that are most important to you, you should skip
905 this portion of the manual.
907 If you are new to compilers, especially Fortran compilers, or
908 new to how compilers are structured under UNIX and UNIX-like
909 systems, you'll want to see @ref{What is GNU Fortran?}.
911 If you are new to GNU compilers, or have used only one GNU
912 compiler in the past and not had to delve into how it lets
913 you manage various versions and configurations of @code{gcc},
914 you should see @ref{G77 and GCC}.
916 Everyone except experienced @code{g77} users should
917 see @ref{Invoking G77}.
919 If you're acquainted with previous versions of @code{g77},
920 you should see @ref{News,,News About GNU Fortran}.
921 Further, if you've actually used previous versions of @code{g77},
922 especially if you've written or modified Fortran code to
923 be compiled by previous versions of @code{g77}, you
924 should see @ref{Changes}.
926 If you intend to write or otherwise compile code that is
927 not already strictly conforming ANSI FORTRAN 77---and this
928 is probably everyone---you should see @ref{Language}.
930 If you don't already have @code{g77} installed on your
931 system, you must see @ref{Installation}.
933 If you run into trouble getting Fortran code to compile,
934 link, run, or work properly, you might find answers
935 if you see @ref{Debugging and Interfacing},
936 see @ref{Collected Fortran Wisdom},
937 and see @ref{Trouble}.
938 You might also find that the problems you are encountering
939 are bugs in @code{g77}---see @ref{Bugs}, for information on
940 reporting them, after reading the other material.
942 If you need further help with @code{g77}, or with
943 freely redistributable software in general,
946 If you would like to help the @code{g77} project,
947 see @ref{Funding GNU Fortran}, for information on
948 helping financially, and see @ref{Projects}, for information
949 on helping in other ways.
951 If you're generally curious about the future of
952 @code{g77}, see @ref{Projects}.
953 If you're curious about its past,
954 see @ref{Contributors},
955 and see @ref{Funding GNU Fortran}.
957 To see a few of the questions maintainers of @code{g77} have,
958 and that you might be able to answer,
959 see @ref{Open Questions}.
962 @node What is GNU Fortran?
963 @chapter What is GNU Fortran?
964 @cindex concepts, basic
965 @cindex basic concepts
967 GNU Fortran, or @code{g77}, is designed initially as a free replacement
968 for, or alternative to, the UNIX @code{f77} command.
969 (Similarly, @code{gcc} is designed as a replacement
970 for the UNIX @code{cc} command.)
972 @code{g77} also is designed to fit in well with the other
973 fine GNU compilers and tools.
975 Sometimes these design goals conflict---in such cases, resolution
976 often is made in favor of fitting in well with Project GNU.
977 These cases are usually identified in the appropriate
978 sections of this manual.
981 As compilers, @code{g77}, @code{gcc}, and @code{f77}
982 share the following characteristics:
990 They read a user's program, stored in a file and
991 containing instructions written in the appropriate
992 language (Fortran, C, and so on).
993 This file contains @dfn{source code}.
995 @cindex translation of user programs
997 @cindex code, machine
1000 They translate the user's program into instructions
1001 a computer can carry out more quickly than it takes
1002 to translate the instructions in the first place.
1003 These instructions are called @dfn{machine code}---code
1004 designed to be efficiently translated and processed
1005 by a machine such as a computer.
1006 Humans usually aren't as good writing machine code
1007 as they are at writing Fortran or C, because
1008 it is easy to make tiny mistakes writing machine code.
1009 When writing Fortran or C, it is easy
1010 to make big mistakes.
1013 @cindex bugs, finding
1014 @cindex @code{gdb}, command
1015 @cindex commands, @code{gdb}
1017 They provide information in the generated machine code
1018 that can make it easier to find bugs in the program
1019 (using a debugging tool, called a @dfn{debugger},
1020 such as @code{gdb}).
1024 @cindex @code{ld} command
1025 @cindex commands, @code{ld}
1027 They locate and gather machine code already generated
1028 to perform actions requested by statements in
1030 This machine code is organized
1031 into @dfn{libraries} and is located and gathered
1032 during the @dfn{link} phase of the compilation
1034 (Linking often is thought of as a separate
1035 step, because it can be directly invoked via the
1037 However, the @code{g77} and @code{gcc}
1038 commands, as with most compiler commands, automatically
1039 perform the linking step by calling on @code{ld}
1040 directly, unless asked to not do so by the user.)
1042 @cindex language, incorrect use of
1043 @cindex incorrect use of language
1045 They attempt to diagnose cases where the user's
1046 program contains incorrect usages of the language.
1047 The @dfn{diagnostics} produced by the compiler
1048 indicate the problem and the location in the user's
1049 source file where the problem was first noticed.
1050 The user can use this information to locate and
1052 @cindex diagnostics, incorrect
1053 @cindex incorrect diagnostics
1054 @cindex error messages, incorrect
1055 @cindex incorrect error messages
1056 (Sometimes an incorrect usage
1057 of the language leads to a situation where the
1058 compiler can no longer make any sense of what
1059 follows---while a human might be able to---and
1060 thus ends up complaining about many ``problems''
1061 it encounters that, in fact, stem from just one
1062 problem, usually the first one reported.)
1065 @cindex questionable instructions
1067 They attempt to diagnose cases where the user's
1068 program contains a correct usage of the language,
1069 but instructs the computer to do something questionable.
1070 These diagnostics often are in the form of @dfn{warnings},
1071 instead of the @dfn{errors} that indicate incorrect
1072 usage of the language.
1075 How these actions are performed is generally under the
1076 control of the user.
1077 Using command-line options, the user can specify
1078 how persnickety the compiler is to be regarding
1079 the program (whether to diagnose questionable usage
1080 of the language), how much time to spend making
1081 the generated machine code run faster, and so on.
1083 @cindex components of g77
1084 @cindex @code{g77}, components of
1085 @code{g77} consists of several components:
1087 @cindex @code{gcc}, command
1088 @cindex commands, @code{gcc}
1091 A modified version of the @code{gcc} command, which also might be
1092 installed as the system's @code{cc} command.
1093 (In many cases, @code{cc} refers to the
1094 system's ``native'' C compiler, which
1095 might be a non-GNU compiler, or an older version
1096 of @code{gcc} considered more stable or that is
1097 used to build the operating system kernel.)
1099 @cindex @code{g77}, command
1100 @cindex commands, @code{g77}
1102 The @code{g77} command itself, which also might be installed as the
1103 system's @code{f77} command.
1105 @cindex libg2c library
1106 @cindex libf2c library
1107 @cindex libraries, libf2c
1108 @cindex libraries, libg2c
1109 @cindex run-time, library
1111 The @code{libg2c} run-time library.
1112 This library contains the machine code needed to support
1113 capabilities of the Fortran language that are not directly
1114 provided by the machine code generated by the @code{g77}
1117 @code{libg2c} is just the unique name @code{g77} gives
1118 to its version of @code{libf2c} to distinguish it from
1119 any copy of @code{libf2c} installed from @code{f2c}
1120 (or versions of @code{g77} that built @code{libf2c} under
1124 The maintainer of @code{libf2c} currently is
1125 @email{dmg@@bell-labs.com}.
1127 @cindex @code{f771}, program
1128 @cindex programs, @code{f771}
1130 @cindex @code{as} command
1131 @cindex commands, @code{as}
1132 @cindex assembly code
1133 @cindex code, assembly
1135 The compiler itself, internally named @code{f771}.
1137 Note that @code{f771} does not generate machine code directly---it
1138 generates @dfn{assembly code} that is a more readable form
1139 of machine code, leaving the conversion to actual machine code
1140 to an @dfn{assembler}, usually named @code{as}.
1143 @code{gcc} is often thought of as ``the C compiler'' only,
1144 but it does more than that.
1145 Based on command-line options and the names given for files
1146 on the command line, @code{gcc} determines which actions to perform, including
1147 preprocessing, compiling (in a variety of possible languages), assembling,
1150 @cindex driver, gcc command as
1151 @cindex @code{gcc}, command as driver
1152 @cindex executable file
1153 @cindex files, executable
1155 @cindex programs, cc1
1156 @cindex preprocessor
1158 @cindex programs, cpp
1159 For example, the command @samp{gcc foo.c} @dfn{drives} the file
1160 @file{foo.c} through the preprocessor @code{cpp}, then
1161 the C compiler (internally named
1162 @code{cc1}), then the assembler (usually @code{as}), then the linker
1163 (@code{ld}), producing an executable program named @file{a.out} (on
1166 @cindex cc1plus program
1167 @cindex programs, cc1plus
1168 As another example, the command @samp{gcc foo.cc} would do much the same as
1169 @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
1170 @code{gcc} would use the C++ compiler (named @code{cc1plus}).
1172 @cindex @code{f771}, program
1173 @cindex programs, @code{f771}
1174 In a GNU Fortran installation, @code{gcc} recognizes Fortran source
1175 files by name just like it does C and C++ source files.
1176 It knows to use the Fortran compiler named @code{f771}, instead of
1177 @code{cc1} or @code{cc1plus}, to compile Fortran files.
1179 @cindex @code{gcc}, not recognizing Fortran source
1180 @cindex unrecognized file format
1181 @cindex file format not recognized
1182 Non-Fortran-related operation of @code{gcc} is generally
1183 unaffected by installing the GNU Fortran version of @code{gcc}.
1184 However, without the installed version of @code{gcc} being the
1185 GNU Fortran version, @code{gcc} will not be able to compile
1186 and link Fortran programs---and since @code{g77} uses @code{gcc}
1187 to do most of the actual work, neither will @code{g77}!
1189 @cindex @code{g77}, command
1190 @cindex commands, @code{g77}
1191 The @code{g77} command is essentially just a front-end for
1192 the @code{gcc} command.
1193 Fortran users will normally use @code{g77} instead of @code{gcc},
1195 knows how to specify the libraries needed to link with Fortran programs
1196 (@code{libg2c} and @code{lm}).
1197 @code{g77} can still compile and link programs and
1198 source files written in other languages, just like @code{gcc}.
1200 @cindex printing version information
1201 @cindex version information, printing
1202 The command @samp{g77 -v} is a quick
1203 way to display lots of version information for the various programs
1204 used to compile a typical preprocessed Fortran source file---this
1205 produces much more output than @samp{gcc -v} currently does.
1206 (If it produces an error message near the end of the output---diagnostics
1207 from the linker, usually @code{ld}---you might
1208 have an out-of-date @code{libf2c} that improperly handles
1209 complex arithmetic.)
1210 In the output of this command, the line beginning @samp{GNU Fortran Front
1211 End} identifies the version number of GNU Fortran; immediately
1212 preceding that line is a line identifying the version of @code{gcc}
1213 with which that version of @code{g77} was built.
1215 @cindex libf2c library
1216 @cindex libraries, libf2c
1217 The @code{libf2c} library is distributed with GNU Fortran for
1218 the convenience of its users, but is not part of GNU Fortran.
1219 It contains the procedures
1220 needed by Fortran programs while they are running.
1222 @cindex in-line code
1223 @cindex code, in-line
1224 For example, while code generated by @code{g77} is likely
1225 to do additions, subtractions, and multiplications @dfn{in line}---in
1226 the actual compiled code---it is not likely to do trigonometric
1229 Instead, operations like trigonometric
1230 functions are compiled by the @code{f771} compiler
1231 (invoked by @code{g77} when compiling Fortran code) into machine
1232 code that, when run, calls on functions in @code{libg2c}, so
1233 @code{libg2c} must be linked with almost every useful program
1234 having any component compiled by GNU Fortran.
1235 (As mentioned above, the @code{g77} command takes
1236 care of all this for you.)
1238 The @code{f771} program represents most of what is unique to GNU Fortran.
1239 While much of the @code{libg2c} component comes from
1240 the @code{libf2c} component of @code{f2c},
1241 a free Fortran-to-C converter distributed by Bellcore (AT&T),
1242 plus @code{libU77}, provided by Dave Love,
1243 and the @code{g77} command is just a small front-end to @code{gcc},
1244 @code{f771} is a combination of two rather
1245 large chunks of code.
1247 @cindex GNU Back End (GBE)
1249 @cindex @code{gcc}, back end
1250 @cindex back end, gcc
1251 @cindex code generator
1252 One chunk is the so-called @dfn{GNU Back End}, or GBE,
1253 which knows how to generate fast code for a wide variety of processors.
1254 The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
1255 @code{cc1plus}, and @code{f771}, plus others.
1256 Often the GBE is referred to as the ``gcc back end'' or
1257 even just ``gcc''---in this manual, the term GBE is used
1258 whenever the distinction is important.
1260 @cindex GNU Fortran Front End (FFE)
1262 @cindex @code{g77}, front end
1263 @cindex front end, @code{g77}
1264 The other chunk of @code{f771} is the
1265 majority of what is unique about GNU Fortran---the code that knows how
1266 to interpret Fortran programs to determine what they are intending to
1267 do, and then communicate that knowledge to the GBE for actual compilation
1269 This chunk is called the @dfn{Fortran Front End} (FFE).
1270 The @code{cc1} and @code{cc1plus} programs have their own front ends,
1271 for the C and C++ languages, respectively.
1272 These fronts ends are responsible for diagnosing
1273 incorrect usage of their respective languages by the
1274 programs the process, and are responsible for most of
1275 the warnings about questionable constructs as well.
1276 (The GBE handles producing some warnings, like those
1277 concerning possible references to undefined variables.)
1279 Because so much is shared among the compilers for various languages,
1280 much of the behavior and many of the user-selectable options for these
1281 compilers are similar.
1282 For example, diagnostics (error messages and
1283 warnings) are similar in appearance; command-line
1284 options like @samp{-Wall} have generally similar effects; and the quality
1285 of generated code (in terms of speed and size) is roughly similar
1286 (since that work is done by the shared GBE).
1289 @chapter Compile Fortran, C, or Other Programs
1290 @cindex compiling programs
1291 @cindex programs, compiling
1293 @cindex @code{gcc}, command
1294 @cindex commands, @code{gcc}
1295 A GNU Fortran installation includes a modified version of the @code{gcc}
1298 In a non-Fortran installation, @code{gcc} recognizes C, C++,
1299 and Objective-C source files.
1301 In a GNU Fortran installation, @code{gcc} also recognizes Fortran source
1302 files and accepts Fortran-specific command-line options, plus some
1303 command-line options that are designed to cater to Fortran users
1304 but apply to other languages as well.
1306 @xref{G++ and GCC,,Compile C; C++; or Objective-C,gcc,Using and Porting GNU CC},
1307 for information on the way different languages are handled
1308 by the GNU CC compiler (@code{gcc}).
1310 @cindex @code{g77}, command
1311 @cindex commands, @code{g77}
1312 Also provided as part of GNU Fortran is the @code{g77} command.
1313 The @code{g77} command is designed to make compiling and linking Fortran
1314 programs somewhat easier than when using the @code{gcc} command for
1316 It does this by analyzing the command line somewhat and changing it
1317 appropriately before submitting it to the @code{gcc} command.
1320 @cindex @code{g77} options, -v
1322 Use the @samp{-v} option with @code{g77}
1323 to see what is going on---the first line of output is the invocation
1324 of the @code{gcc} command.
1327 @chapter GNU Fortran Command Options
1328 @cindex GNU Fortran command options
1329 @cindex command options
1330 @cindex options, GNU Fortran command
1332 The @code{g77} command supports all the options supported by the
1334 @xref{Invoking GCC,,GNU CC Command Options,gcc,Using and Porting GNU CC},
1336 on the non-Fortran-specific aspects of the @code{gcc} command (and,
1337 therefore, the @code{g77} command).
1339 @cindex options, negative forms
1340 @cindex negative forms of options
1341 All @code{gcc} and @code{g77} options
1342 are accepted both by @code{g77} and by @code{gcc}
1343 (as well as any other drivers built at the same time,
1344 such as @code{g++}),
1345 since adding @code{g77} to the @code{gcc} distribution
1346 enables acceptance of @code{g77}-specific options
1347 by all of the relevant drivers.
1349 In some cases, options have positive and negative forms;
1350 the negative form of @samp{-ffoo} would be @samp{-fno-foo}.
1351 This manual documents only one of these two forms, whichever
1352 one is not the default.
1355 * Option Summary:: Brief list of all @code{g77} options,
1356 without explanations.
1357 * Overall Options:: Controlling the kind of output:
1358 an executable, object files, assembler files,
1359 or preprocessed source.
1360 * Shorthand Options:: Options that are shorthand for other options.
1361 * Fortran Dialect Options:: Controlling the variant of Fortran language
1363 * Warning Options:: How picky should the compiler be?
1364 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1365 * Optimize Options:: How much optimization?
1366 * Preprocessor Options:: Controlling header files and macro definitions.
1367 Also, getting dependency information for Make.
1368 * Directory Options:: Where to find header files and libraries.
1369 Where to find the compiler executable files.
1370 * Code Gen Options:: Specifying conventions for function calls, data layout
1372 * Environment Variables:: Env vars that affect GNU Fortran.
1375 @node Option Summary
1376 @section Option Summary
1378 Here is a summary of all the options specific to GNU Fortran, grouped
1379 by type. Explanations are in the following sections.
1382 @item Overall Options
1383 @xref{Overall Options,,Options Controlling the Kind of Output}.
1385 -fversion -fset-g77-defaults -fno-silent
1388 @item Shorthand Options
1389 @xref{Shorthand Options}.
1391 -ff66 -fno-f66 -ff77 -fno-f77 -fno-ugly
1394 @item Fortran Language Options
1395 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect}.
1397 -ffree-form -fno-fixed-form -ff90
1398 -fvxt -fdollar-ok -fno-backslash
1399 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1400 -fugly-comma -fugly-complex -fugly-init -fugly-logint
1401 -fonetrip -ftypeless-boz
1402 -fintrin-case-initcap -fintrin-case-upper
1403 -fintrin-case-lower -fintrin-case-any
1404 -fmatch-case-initcap -fmatch-case-upper
1405 -fmatch-case-lower -fmatch-case-any
1406 -fsource-case-upper -fsource-case-lower -fsource-case-preserve
1407 -fsymbol-case-initcap -fsymbol-case-upper
1408 -fsymbol-case-lower -fsymbol-case-any
1409 -fcase-strict-upper -fcase-strict-lower
1410 -fcase-initcap -fcase-upper -fcase-lower -fcase-preserve
1411 -ff2c-intrinsics-delete -ff2c-intrinsics-hide
1412 -ff2c-intrinsics-disable -ff2c-intrinsics-enable
1413 -fbadu77-intrinsics-delete -fbadu77-intrinsics-hide
1414 -fbadu77-intrinsics-disable -fbadu77-intrinsics-enable
1415 -ff90-intrinsics-delete -ff90-intrinsics-hide
1416 -ff90-intrinsics-disable -ff90-intrinsics-enable
1417 -fgnu-intrinsics-delete -fgnu-intrinsics-hide
1418 -fgnu-intrinsics-disable -fgnu-intrinsics-enable
1419 -fmil-intrinsics-delete -fmil-intrinsics-hide
1420 -fmil-intrinsics-disable -fmil-intrinsics-enable
1421 -funix-intrinsics-delete -funix-intrinsics-hide
1422 -funix-intrinsics-disable -funix-intrinsics-enable
1423 -fvxt-intrinsics-delete -fvxt-intrinsics-hide
1424 -fvxt-intrinsics-disable -fvxt-intrinsics-enable
1425 -ffixed-line-length-@var{n} -ffixed-line-length-none
1428 @item Warning Options
1429 @xref{Warning Options,,Options to Request or Suppress Warnings}.
1431 -fsyntax-only -pedantic -pedantic-errors -fpedantic
1432 -w -Wno-globals -Wimplicit -Wunused -Wuninitialized
1437 @item Debugging Options
1438 @xref{Debugging Options,,Options for Debugging Your Program or GCC}.
1443 @item Optimization Options
1444 @xref{Optimize Options,,Options that Control Optimization}.
1447 -ffloat-store -fforce-mem -fforce-addr -fno-inline
1448 -ffast-math -fstrength-reduce -frerun-cse-after-loop
1449 -fexpensive-optimizations -fdelayed-branch
1450 -fschedule-insns -fschedule-insn2 -fcaller-saves
1451 -funroll-loops -funroll-all-loops
1452 -fno-move-all-movables -fno-reduce-all-givs
1456 @item Directory Options
1457 @xref{Directory Options,,Options for Directory Search}.
1462 @item Code Generation Options
1463 @xref{Code Gen Options,,Options for Code Generation Conventions}.
1465 -fno-automatic -finit-local-zero -fno-f2c
1466 -ff2c-library -fno-underscoring -fno-ident
1467 -fpcc-struct-return -freg-struct-return
1468 -fshort-double -fno-common -fpack-struct
1469 -fzeros -fno-second-underscore
1470 -fdebug-kludge -femulate-complex
1471 -falias-check -fargument-alias
1472 -fargument-noalias -fno-argument-noalias-global
1474 -fsubscript-check -ff2c-subscript-check
1479 * Overall Options:: Controlling the kind of output:
1480 an executable, object files, assembler files,
1481 or preprocessed source.
1482 * Shorthand Options:: Options that are shorthand for other options.
1483 * Fortran Dialect Options:: Controlling the variant of Fortran language
1485 * Warning Options:: How picky should the compiler be?
1486 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1487 * Optimize Options:: How much optimization?
1488 * Preprocessor Options:: Controlling header files and macro definitions.
1489 Also, getting dependency information for Make.
1490 * Directory Options:: Where to find header files and libraries.
1491 Where to find the compiler executable files.
1492 * Code Gen Options:: Specifying conventions for function calls, data layout
1496 @node Overall Options
1497 @section Options Controlling the Kind of Output
1498 @cindex overall options
1499 @cindex options, overall
1501 Compilation can involve as many as four stages: preprocessing, code
1502 generation (often what is really meant by the term ``compilation''),
1503 assembly, and linking, always in that order. The first three
1504 stages apply to an individual source file, and end by producing an
1505 object file; linking combines all the object files (those newly
1506 compiled, and those specified as input) into an executable file.
1508 @cindex file name suffix
1509 @cindex suffixes, file name
1510 @cindex file name extension
1511 @cindex extensions, file name
1514 For any given input file, the file name suffix determines what kind of
1515 program is contained in the file---that is, the language in which the
1516 program is written is generally indicated by the suffix.
1517 Suffixes specific to GNU Fortran are listed below.
1518 @xref{Overall Options,,gcc,Using and Porting GNU CC}, for
1519 information on suffixes recognized by GNU CC.
1522 @cindex .f filename suffix
1523 @cindex .for filename suffix
1524 @cindex .FOR filename suffix
1526 @item @var{file}.for
1527 @item @var{file}.FOR
1528 Fortran source code that should not be preprocessed.
1530 Such source code cannot contain any preprocessor directives, such
1531 as @code{#include}, @code{#define}, @code{#if}, and so on.
1533 You can force @samp{.f} files to be preprocessed by @code{cpp} by using
1534 @samp{-x f77-cpp-input}.
1537 @cindex preprocessor
1538 @cindex C preprocessor
1539 @cindex cpp preprocessor
1540 @cindex Fortran preprocessor
1542 @cindex programs, cpp
1543 @cindex .F filename suffix
1544 @cindex .fpp filename suffix
1545 @cindex .FPP filename suffix
1547 @item @var{file}.fpp
1548 @item @var{file}.FPP
1549 Fortran source code that must be preprocessed (by the C preprocessor
1550 @code{cpp}, which is part of GNU CC).
1552 Note that preprocessing is not extended to the contents of
1553 files included by the @code{INCLUDE} directive---the @code{#include}
1554 preprocessor directive must be used instead.
1556 @cindex Ratfor preprocessor
1557 @cindex programs, @code{ratfor}
1558 @cindex @samp{.r} filename suffix
1559 @cindex @code{ratfor}
1561 Ratfor source code, which must be preprocessed by the @code{ratfor}
1562 command, which is available separately (as it is not yet part of the GNU
1563 Fortran distribution).
1564 One version in Fortran, adapted for use with @code{g77}, is at
1565 @uref{ftp://members.aol.com/n8tm/rat7.uue} (of uncertain copyright
1566 status). Another, public domain version in C is at
1567 @uref{http://sepwww.stanford.edu/sep/prof/ratfor.shar.2}.
1570 UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
1572 Users of other operating systems, especially those that cannot
1573 distinguish upper-case
1574 letters from lower-case letters in their file names, typically use
1575 the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.
1580 Use of the preprocessor @code{cpp} allows use of C-like
1581 constructs such as @code{#define} and @code{#include}, but can
1582 lead to unexpected, even mistaken, results due to Fortran's source file
1584 It is recommended that use of the C preprocessor
1585 be limited to @code{#include} and, in
1586 conjunction with @code{#define}, only @code{#if} and related directives,
1587 thus avoiding in-line macro expansion entirely.
1588 This recommendation applies especially
1589 when using the traditional fixed source form.
1590 With free source form,
1591 fewer unexpected transformations are likely to happen, but use of
1592 constructs such as Hollerith and character constants can nevertheless
1593 present problems, especially when these are continued across multiple
1595 These problems result, primarily, from differences between the way
1596 such constants are interpreted by the C preprocessor and by a Fortran
1599 Another example of a problem that results from using the C preprocessor
1600 is that a Fortran comment line that happens to contain any
1601 characters ``interesting'' to the C preprocessor,
1602 such as a backslash at the end of the line,
1603 is not recognized by the preprocessor as a comment line,
1604 so instead of being passed through ``raw'',
1605 the line is edited according to the rules for the preprocessor.
1606 For example, the backslash at the end of the line is removed,
1607 along with the subsequent newline, resulting in the next
1608 line being effectively commented out---unfortunate if that
1609 line is a non-comment line of important code!
1611 @emph{Note:} The @samp{-traditional} and @samp{-undef} flags are supplied
1612 to @code{cpp} by default, to help avoid unpleasant surprises.
1613 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
1614 gcc,Using and Porting GNU CC}.
1615 This means that ANSI C preprocessor features (such as the @samp{#}
1616 operator) aren't available, and only variables in the C reserved
1617 namespace (generally, names with a leading underscore) are liable to
1618 substitution by C predefines.
1619 Thus, if you want to do system-specific
1620 tests, use, for example, @samp{#ifdef __linux__} rather than @samp{#ifdef linux}.
1621 Use the @samp{-v} option to see exactly how the preprocessor is invoked.
1624 Unfortunately, the @samp{-traditional} flag will not avoid an error from
1625 anything that @code{cpp} sees as an unterminated C comment, such as:
1627 C Some Fortran compilers accept /* as starting
1628 C an inline comment.
1630 @xref{Trailing Comment}.
1632 The following options that affect overall processing are recognized
1633 by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:
1636 @cindex -fversion option
1637 @cindex options, -fversion
1638 @cindex printing version information
1639 @cindex version information, printing
1640 @cindex consistency checks
1641 @cindex internal consistency checks
1642 @cindex checks, of internal consistency
1644 Ensure that the @code{g77}-specific version of the compiler phase is reported,
1646 and, starting in @code{egcs} version 1.1,
1647 that internal consistency checks in the @file{f771} program are run.
1649 This option is supplied automatically when @samp{-v} or @samp{--verbose}
1650 is specified as a command-line option for @code{g77} or @code{gcc}
1651 and when the resulting commands compile Fortran source files.
1653 @cindex -fset-g77-defaults option
1654 @cindex options, -fset-g77-defaults
1655 @item -fset-g77-defaults
1656 @emph{Version info:}
1657 This option is obsolete in @code{egcs}
1659 The effect is instead achieved
1660 by the @code{lang_init_options} routine
1661 in @file{egcs/gcc/f/com.c}.
1663 @cindex consistency checks
1664 @cindex internal consistency checks
1665 @cindex checks, of internal consistency
1666 Set up whatever @code{gcc} options are to apply to Fortran
1667 compilations, and avoid running internal consistency checks
1668 that might take some time.
1670 This option is supplied automatically when compiling Fortran code
1671 via the @code{g77} or @code{gcc} command.
1672 The description of this option is provided so that users seeing
1673 it in the output of, say, @samp{g77 -v} understand why it is
1676 @cindex modifying g77
1677 @cindex code, modifying
1678 Also, developers who run @code{f771} directly might want to specify it
1679 by hand to get the same defaults as they would running @code{f771}
1680 via @code{g77} or @code{gcc}.
1681 However, such developers should, after linking a new @code{f771}
1682 executable, invoke it without this option once,
1683 e.g. via @kbd{./f771 -quiet < /dev/null},
1684 to ensure that they have not introduced any
1685 internal inconsistencies (such as in the table of
1686 intrinsics) before proceeding---@code{g77} will crash
1687 with a diagnostic if it detects an inconsistency.
1689 @cindex -fno-silent option
1690 @cindex options, -fno-silent
1691 @cindex f2c compatibility
1692 @cindex compatibility, f2c
1693 @cindex status, compilation
1694 @cindex compilation, status
1695 @cindex reporting compilation status
1696 @cindex printing compilation status
1698 Print (to @code{stderr}) the names of the program units as
1699 they are compiled, in a form similar to that used by popular
1700 UNIX @code{f77} implementations and @code{f2c}.
1703 @xref{Overall Options,,Options Controlling the Kind of Output,
1704 gcc,Using and Porting GNU CC}, for information
1705 on more options that control the overall operation of the @code{gcc} command
1706 (and, by extension, the @code{g77} command).
1708 @node Shorthand Options
1709 @section Shorthand Options
1710 @cindex shorthand options
1711 @cindex options, shorthand
1712 @cindex macro options
1713 @cindex options, macro
1715 The following options serve as ``shorthand''
1716 for other options accepted by the compiler:
1719 @cindex -fugly option
1720 @cindex options, -fugly
1722 @cindex ugly features
1723 @cindex features, ugly
1724 @emph{Note:} This option is no longer supported.
1725 The information, below, is provided to aid
1726 in the conversion of old scripts.
1728 Specify that certain ``ugly'' constructs are to be quietly accepted.
1732 -fugly-args -fugly-assign -fugly-assumed
1733 -fugly-comma -fugly-complex -fugly-init
1737 These constructs are considered inappropriate to use in new
1738 or well-maintained portable Fortran code, but widely used
1740 @xref{Distensions}, for more information.
1742 @cindex -fno-ugly option
1743 @cindex options, -fno-ugly
1745 @cindex ugly features
1746 @cindex features, ugly
1747 Specify that all ``ugly'' constructs are to be noisily rejected.
1751 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1752 -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
1756 @xref{Distensions}, for more information.
1758 @cindex -ff66 option
1759 @cindex options, -ff66
1762 @cindex compatibility, FORTRAN 66
1763 Specify that the program is written in idiomatic FORTRAN 66.
1764 Same as @samp{-fonetrip -fugly-assumed}.
1766 The @samp{-fno-f66} option is the inverse of @samp{-ff66}.
1767 As such, it is the same as @samp{-fno-onetrip -fno-ugly-assumed}.
1769 The meaning of this option is likely to be refined as future
1770 versions of @code{g77} provide more compatibility with other
1771 existing and obsolete Fortran implementations.
1773 @cindex -ff77 option
1774 @cindex options, -ff77
1777 @cindex f2c compatibility
1778 @cindex compatibility, f2c
1779 @cindex f77 compatibility
1780 @cindex compatibility, f77
1781 Specify that the program is written in idiomatic UNIX FORTRAN 77
1782 and/or the dialect accepted by the @code{f2c} product.
1783 Same as @samp{-fbackslash -fno-typeless-boz}.
1785 The meaning of this option is likely to be refined as future
1786 versions of @code{g77} provide more compatibility with other
1787 existing and obsolete Fortran implementations.
1789 @cindex -fno-f77 option
1790 @cindex options, -fno-f77
1793 The @samp{-fno-f77} option is @emph{not} the inverse
1795 It specifies that the program is not written in idiomatic UNIX
1796 FORTRAN 77 or @code{f2c}, but in a more widely portable dialect.
1797 @samp{-fno-f77} is the same as @samp{-fno-backslash}.
1799 The meaning of this option is likely to be refined as future
1800 versions of @code{g77} provide more compatibility with other
1801 existing and obsolete Fortran implementations.
1804 @node Fortran Dialect Options
1805 @section Options Controlling Fortran Dialect
1806 @cindex dialect options
1807 @cindex language, dialect options
1808 @cindex options, dialect
1810 The following options control the dialect of Fortran
1811 that the compiler accepts:
1814 @cindex -ffree-form option
1815 @cindex options, -ffree-form
1816 @cindex -fno-fixed-form option
1817 @cindex options, -fno-fixed-form
1818 @cindex source file format
1821 @cindex Fortran 90, features
1823 @item -fno-fixed-form
1824 Specify that the source file is written in free form
1825 (introduced in Fortran 90) instead of the more-traditional fixed form.
1827 @cindex -ff90 option
1828 @cindex options, -ff90
1829 @cindex Fortran 90, features
1831 Allow certain Fortran-90 constructs.
1833 This option controls whether certain
1834 Fortran 90 constructs are recognized.
1835 (Other Fortran 90 constructs
1836 might or might not be recognized depending on other options such as
1837 @samp{-fvxt}, @samp{-ff90-intrinsics-enable}, and the
1838 current level of support for Fortran 90.)
1840 @xref{Fortran 90}, for more information.
1842 @cindex -fvxt option
1843 @cindex options, -fvxt
1845 @cindex Fortran 90, features
1846 @cindex VXT extensions
1847 Specify the treatment of certain constructs that have different
1848 meanings depending on whether the code is written in
1849 GNU Fortran (based on FORTRAN 77 and akin to Fortran 90)
1850 or VXT Fortran (more like VAX FORTRAN).
1852 The default is @samp{-fno-vxt}.
1853 @samp{-fvxt} specifies that the VXT Fortran interpretations
1854 for those constructs are to be chosen.
1856 @xref{VXT Fortran}, for more information.
1858 @cindex -fdollar-ok option
1859 @cindex options, -fdollar-ok
1862 @cindex symbol names
1863 @cindex character set
1864 Allow @samp{$} as a valid character in a symbol name.
1866 @cindex -fno-backslash option
1867 @cindex options, -fno-backslash
1868 @item -fno-backslash
1870 @cindex character constants
1871 @cindex Hollerith constants
1872 Specify that @samp{\} is not to be specially interpreted in character
1873 and Hollerith constants a la C and many UNIX Fortran compilers.
1875 For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
1876 three characters, with the second one being newline.
1877 With @samp{-fno-backslash}, it specifies four characters,
1878 @samp{A}, @samp{\}, @samp{n}, and @samp{B}.
1880 Note that @code{g77} implements a fairly general form of backslash
1881 processing that is incompatible with the narrower forms supported
1882 by some other compilers.
1883 For example, @samp{'A\003B'} is a three-character string in @code{g77},
1884 whereas other compilers that support backslash might not support
1885 the three-octal-digit form, and thus treat that string as longer
1886 than three characters.
1888 @xref{Backslash in Constants}, for
1889 information on why @samp{-fbackslash} is the default
1890 instead of @samp{-fno-backslash}.
1892 @cindex -fno-ugly-args option
1893 @cindex options, -fno-ugly-args
1894 @item -fno-ugly-args
1895 Disallow passing Hollerith and typeless constants as actual
1896 arguments (for example, @samp{CALL FOO(4HABCD)}).
1898 @xref{Ugly Implicit Argument Conversion}, for more information.
1900 @cindex -fugly-assign option
1901 @cindex options, -fugly-assign
1903 Use the same storage for a given variable regardless of
1904 whether it is used to hold an assigned-statement label
1905 (as in @samp{ASSIGN 10 TO I}) or used to hold numeric data
1906 (as in @samp{I = 3}).
1908 @xref{Ugly Assigned Labels}, for more information.
1910 @cindex -fugly-assumed option
1911 @cindex options, -fugly-assumed
1912 @item -fugly-assumed
1913 Assume any dummy array with a final dimension specified as @samp{1}
1914 is really an assumed-size array, as if @samp{*} had been specified
1915 for the final dimension instead of @samp{1}.
1917 For example, @samp{DIMENSION X(1)} is treated as if it
1918 had read @samp{DIMENSION X(*)}.
1920 @xref{Ugly Assumed-Size Arrays}, for more information.
1922 @cindex -fugly-comma option
1923 @cindex options, -fugly-comma
1925 In an external-procedure invocation,
1926 treat a trailing comma in the argument list
1927 as specification of a trailing null argument,
1928 and treat an empty argument list
1929 as specification of a single null argument.
1931 For example, @samp{CALL FOO(,)} is treated as
1932 @samp{CALL FOO(%VAL(0), %VAL(0))}.
1933 That is, @emph{two} null arguments are specified
1934 by the procedure call when @samp{-fugly-comma} is in force.
1935 And @samp{F = FUNC()} is treated as @samp{F = FUNC(%VAL(0))}.
1937 The default behavior, @samp{-fno-ugly-comma}, is to ignore
1938 a single trailing comma in an argument list.
1939 So, by default, @samp{CALL FOO(X,)} is treated
1940 exactly the same as @samp{CALL FOO(X)}.
1942 @xref{Ugly Null Arguments}, for more information.
1944 @cindex -fugly-complex option
1945 @cindex options, -fugly-complex
1946 @item -fugly-complex
1947 Do not complain about @samp{REAL(@var{expr})} or
1948 @samp{AIMAG(@var{expr})} when @var{expr} is a @code{COMPLEX}
1949 type other than @code{COMPLEX(KIND=1)}---usually
1950 this is used to permit @code{COMPLEX(KIND=2)}
1951 (@code{DOUBLE COMPLEX}) operands.
1953 The @samp{-ff90} option controls the interpretation
1956 @xref{Ugly Complex Part Extraction}, for more information.
1958 @cindex -fno-ugly-init option
1959 @cindex options, -fno-ugly-init
1960 @item -fno-ugly-init
1961 Disallow use of Hollerith and typeless constants as initial
1962 values (in @code{PARAMETER} and @code{DATA} statements), and
1963 use of character constants to
1964 initialize numeric types and vice versa.
1966 For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
1967 @samp{-fno-ugly-init}.
1969 @xref{Ugly Conversion of Initializers}, for more information.
1971 @cindex -fugly-logint option
1972 @cindex options, -fugly-logint
1974 Treat @code{INTEGER} and @code{LOGICAL} variables and
1975 expressions as potential stand-ins for each other.
1977 For example, automatic conversion between @code{INTEGER} and
1978 @code{LOGICAL} is enabled, for many contexts, via this option.
1980 @xref{Ugly Integer Conversions}, for more information.
1982 @cindex -fonetrip option
1983 @cindex options, -fonetrip
1986 @cindex @code{DO} loops, one-trip
1987 @cindex one-trip @code{DO} loops
1988 @cindex @code{DO} loops, zero-trip
1989 @cindex zero-trip @code{DO} loops
1990 @cindex compatibility, FORTRAN 66
1991 Executable iterative @code{DO} loops are to be executed at
1992 least once each time they are reached.
1994 ANSI FORTRAN 77 and more recent versions of the Fortran standard
1995 specify that the body of an iterative @code{DO} loop is not executed
1996 if the number of iterations calculated from the parameters of the
1997 loop is less than 1.
1998 (For example, @samp{DO 10 I = 1, 0}.)
1999 Such a loop is called a @dfn{zero-trip loop}.
2001 Prior to ANSI FORTRAN 77, many compilers implemented @code{DO} loops
2002 such that the body of a loop would be executed at least once, even
2003 if the iteration count was zero.
2004 Fortran code written assuming this behavior is said to require
2005 @dfn{one-trip loops}.
2006 For example, some code written to the FORTRAN 66 standard
2007 expects this behavior from its @code{DO} loops, although that
2008 standard did not specify this behavior.
2010 The @samp{-fonetrip} option specifies that the source file(s) being
2011 compiled require one-trip loops.
2013 This option affects only those loops specified by the (iterative) @code{DO}
2014 statement and by implied-@code{DO} lists in I/O statements.
2015 Loops specified by implied-@code{DO} lists in @code{DATA} and
2016 specification (non-executable) statements are not affected.
2018 @cindex -ftypeless-boz option
2019 @cindex options, -ftypeless-boz
2020 @cindex prefix-radix constants
2021 @cindex constants, prefix-radix
2022 @cindex constants, types
2023 @cindex types, constants
2024 @item -ftypeless-boz
2025 Specifies that prefix-radix non-decimal constants, such as
2026 @samp{Z'ABCD'}, are typeless instead of @code{INTEGER(KIND=1)}.
2028 You can test for yourself whether a particular compiler treats
2029 the prefix form as @code{INTEGER(KIND=1)} or typeless by running the
2036 IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
2037 IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
2041 Reports indicate that many compilers process this form as
2042 @code{INTEGER(KIND=1)}, though a few as typeless, and at least one
2043 based on a command-line option specifying some kind of
2046 @cindex -fintrin-case-initcap option
2047 @cindex options, -fintrin-case-initcap
2048 @item -fintrin-case-initcap
2049 @cindex -fintrin-case-upper option
2050 @cindex options, -fintrin-case-upper
2051 @item -fintrin-case-upper
2052 @cindex -fintrin-case-lower option
2053 @cindex options, -fintrin-case-lower
2054 @item -fintrin-case-lower
2055 @cindex -fintrin-case-any option
2056 @cindex options, -fintrin-case-any
2057 @item -fintrin-case-any
2058 Specify expected case for intrinsic names.
2059 @samp{-fintrin-case-lower} is the default.
2061 @cindex -fmatch-case-initcap option
2062 @cindex options, -fmatch-case-initcap
2063 @item -fmatch-case-initcap
2064 @cindex -fmatch-case-upper option
2065 @cindex options, -fmatch-case-upper
2066 @item -fmatch-case-upper
2067 @cindex -fmatch-case-lower option
2068 @cindex options, -fmatch-case-lower
2069 @item -fmatch-case-lower
2070 @cindex -fmatch-case-any option
2071 @cindex options, -fmatch-case-any
2072 @item -fmatch-case-any
2073 Specify expected case for keywords.
2074 @samp{-fmatch-case-lower} is the default.
2076 @cindex -fsource-case-upper option
2077 @cindex options, -fsource-case-upper
2078 @item -fsource-case-upper
2079 @cindex -fsource-case-lower option
2080 @cindex options, -fsource-case-lower
2081 @item -fsource-case-lower
2082 @cindex -fsource-case-preserve option
2083 @cindex options, -fsource-case-preserve
2084 @item -fsource-case-preserve
2085 Specify whether source text other than character and Hollerith constants
2086 is to be translated to uppercase, to lowercase, or preserved as is.
2087 @samp{-fsource-case-lower} is the default.
2089 @cindex -fsymbol-case-initcap option
2090 @cindex options, -fsymbol-case-initcap
2091 @item -fsymbol-case-initcap
2092 @cindex -fsymbol-case-upper option
2093 @cindex options, -fsymbol-case-upper
2094 @item -fsymbol-case-upper
2095 @cindex -fsymbol-case-lower option
2096 @cindex options, -fsymbol-case-lower
2097 @item -fsymbol-case-lower
2098 @cindex -fsymbol-case-any option
2099 @cindex options, -fsymbol-case-any
2100 @item -fsymbol-case-any
2101 Specify valid cases for user-defined symbol names.
2102 @samp{-fsymbol-case-any} is the default.
2104 @cindex -fcase-strict-upper option
2105 @cindex options, -fcase-strict-upper
2106 @item -fcase-strict-upper
2107 Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
2108 -fsymbol-case-upper}.
2109 (Requires all pertinent source to be in uppercase.)
2111 @cindex -fcase-strict-lower option
2112 @cindex options, -fcase-strict-lower
2113 @item -fcase-strict-lower
2114 Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
2115 -fsymbol-case-lower}.
2116 (Requires all pertinent source to be in lowercase.)
2118 @cindex -fcase-initcap option
2119 @cindex options, -fcase-initcap
2120 @item -fcase-initcap
2121 Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
2122 -fsymbol-case-initcap}.
2123 (Requires all pertinent source to be in initial capitals,
2124 as in @samp{Print *,SqRt(Value)}.)
2126 @cindex -fcase-upper option
2127 @cindex options, -fcase-upper
2129 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
2131 (Maps all pertinent source to uppercase.)
2133 @cindex -fcase-lower option
2134 @cindex options, -fcase-lower
2136 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
2138 (Maps all pertinent source to lowercase.)
2140 @cindex -fcase-preserve option
2141 @cindex options, -fcase-preserve
2142 @item -fcase-preserve
2143 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
2145 (Preserves all case in user-defined symbols,
2146 while allowing any-case matching of intrinsics and keywords.
2147 For example, @samp{call Foo(i,I)} would pass two @emph{different}
2148 variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)
2150 @cindex -fbadu77-intrinsics-delete option
2151 @cindex options, -fbadu77-intrinsics-delete
2152 @item -fbadu77-intrinsics-delete
2153 @cindex -fbadu77-intrinsics-hide option
2154 @cindex options, -fbadu77-intrinsics-hide
2155 @item -fbadu77-intrinsics-hide
2156 @cindex -fbadu77-intrinsics-disable option
2157 @cindex options, -fbadu77-intrinsics-disable
2158 @item -fbadu77-intrinsics-disable
2159 @cindex -fbadu77-intrinsics-enable option
2160 @cindex options, -fbadu77-intrinsics-enable
2161 @item -fbadu77-intrinsics-enable
2162 @cindex @code{badu77} intrinsics
2163 @cindex intrinsics, @code{badu77}
2164 Specify status of UNIX intrinsics having inappropriate forms.
2165 @samp{-fbadu77-intrinsics-enable} is the default.
2166 @xref{Intrinsic Groups}.
2168 @cindex -ff2c-intrinsics-delete option
2169 @cindex options, -ff2c-intrinsics-delete
2170 @item -ff2c-intrinsics-delete
2171 @cindex -ff2c-intrinsics-hide option
2172 @cindex options, -ff2c-intrinsics-hide
2173 @item -ff2c-intrinsics-hide
2174 @cindex -ff2c-intrinsics-disable option
2175 @cindex options, -ff2c-intrinsics-disable
2176 @item -ff2c-intrinsics-disable
2177 @cindex -ff2c-intrinsics-enable option
2178 @cindex options, -ff2c-intrinsics-enable
2179 @item -ff2c-intrinsics-enable
2180 @cindex @code{f2c} intrinsics
2181 @cindex intrinsics, @code{f2c}
2182 Specify status of f2c-specific intrinsics.
2183 @samp{-ff2c-intrinsics-enable} is the default.
2184 @xref{Intrinsic Groups}.
2186 @cindex -ff90-intrinsics-delete option
2187 @cindex options, -ff90-intrinsics-delete
2188 @item -ff90-intrinsics-delete
2189 @cindex -ff90-intrinsics-hide option
2190 @cindex options, -ff90-intrinsics-hide
2191 @item -ff90-intrinsics-hide
2192 @cindex -ff90-intrinsics-disable option
2193 @cindex options, -ff90-intrinsics-disable
2194 @item -ff90-intrinsics-disable
2195 @cindex -ff90-intrinsics-enable option
2196 @cindex options, -ff90-intrinsics-enable
2197 @item -ff90-intrinsics-enable
2198 @cindex Fortran 90, intrinsics
2199 @cindex intrinsics, Fortran 90
2200 Specify status of F90-specific intrinsics.
2201 @samp{-ff90-intrinsics-enable} is the default.
2202 @xref{Intrinsic Groups}.
2204 @cindex -fgnu-intrinsics-delete option
2205 @cindex options, -fgnu-intrinsics-delete
2206 @item -fgnu-intrinsics-delete
2207 @cindex -fgnu-intrinsics-hide option
2208 @cindex options, -fgnu-intrinsics-hide
2209 @item -fgnu-intrinsics-hide
2210 @cindex -fgnu-intrinsics-disable option
2211 @cindex options, -fgnu-intrinsics-disable
2212 @item -fgnu-intrinsics-disable
2213 @cindex -fgnu-intrinsics-enable option
2214 @cindex options, -fgnu-intrinsics-enable
2215 @item -fgnu-intrinsics-enable
2216 @cindex Digital Fortran features
2217 @cindex @code{COMPLEX} intrinsics
2218 @cindex intrinsics, @code{COMPLEX}
2219 Specify status of Digital's COMPLEX-related intrinsics.
2220 @samp{-fgnu-intrinsics-enable} is the default.
2221 @xref{Intrinsic Groups}.
2223 @cindex -fmil-intrinsics-delete option
2224 @cindex options, -fmil-intrinsics-delete
2225 @item -fmil-intrinsics-delete
2226 @cindex -fmil-intrinsics-hide option
2227 @cindex options, -fmil-intrinsics-hide
2228 @item -fmil-intrinsics-hide
2229 @cindex -fmil-intrinsics-disable option
2230 @cindex options, -fmil-intrinsics-disable
2231 @item -fmil-intrinsics-disable
2232 @cindex -fmil-intrinsics-enable option
2233 @cindex options, -fmil-intrinsics-enable
2234 @item -fmil-intrinsics-enable
2235 @cindex MIL-STD 1753
2236 @cindex intrinsics, MIL-STD 1753
2237 Specify status of MIL-STD-1753-specific intrinsics.
2238 @samp{-fmil-intrinsics-enable} is the default.
2239 @xref{Intrinsic Groups}.
2241 @cindex -funix-intrinsics-delete option
2242 @cindex options, -funix-intrinsics-delete
2243 @item -funix-intrinsics-delete
2244 @cindex -funix-intrinsics-hide option
2245 @cindex options, -funix-intrinsics-hide
2246 @item -funix-intrinsics-hide
2247 @cindex -funix-intrinsics-disable option
2248 @cindex options, -funix-intrinsics-disable
2249 @item -funix-intrinsics-disable
2250 @cindex -funix-intrinsics-enable option
2251 @cindex options, -funix-intrinsics-enable
2252 @item -funix-intrinsics-enable
2253 @cindex UNIX intrinsics
2254 @cindex intrinsics, UNIX
2255 Specify status of UNIX intrinsics.
2256 @samp{-funix-intrinsics-enable} is the default.
2257 @xref{Intrinsic Groups}.
2259 @cindex -fvxt-intrinsics-delete option
2260 @cindex options, -fvxt-intrinsics-delete
2261 @item -fvxt-intrinsics-delete
2262 @cindex -fvxt-intrinsics-hide option
2263 @cindex options, -fvxt-intrinsics-hide
2264 @item -fvxt-intrinsics-hide
2265 @cindex -fvxt-intrinsics-disable option
2266 @cindex options, -fvxt-intrinsics-disable
2267 @item -fvxt-intrinsics-disable
2268 @cindex -fvxt-intrinsics-enable option
2269 @cindex options, -fvxt-intrinsics-enable
2270 @item -fvxt-intrinsics-enable
2271 @cindex VXT intrinsics
2272 @cindex intrinsics, VXT
2273 Specify status of VXT intrinsics.
2274 @samp{-fvxt-intrinsics-enable} is the default.
2275 @xref{Intrinsic Groups}.
2277 @cindex -ffixed-line-length-@var{n} option
2278 @cindex options, -ffixed-line-length-@var{n}
2279 @item -ffixed-line-length-@var{n}
2280 @cindex source file format
2281 @cindex lines, length
2282 @cindex length of source lines
2284 @cindex limits, lengths of source lines
2285 Set column after which characters are ignored in typical fixed-form
2286 lines in the source file, and through which spaces are assumed (as
2287 if padded to that length) after the ends of short fixed-form lines.
2290 @cindex extended-source option
2291 Popular values for @var{n} include 72 (the
2292 standard and the default), 80 (card image), and 132 (corresponds
2293 to ``extended-source'' options in some popular compilers).
2294 @var{n} may be @samp{none}, meaning that the entire line is meaningful
2295 and that continued character constants never have implicit spaces appended
2296 to them to fill out the line.
2297 @samp{-ffixed-line-length-0} means the same thing as
2298 @samp{-ffixed-line-length-none}.
2300 @xref{Source Form}, for more information.
2303 @node Warning Options
2304 @section Options to Request or Suppress Warnings
2305 @cindex options, warnings
2306 @cindex warnings, suppressing
2307 @cindex messages, warning
2308 @cindex suppressing warnings
2310 Warnings are diagnostic messages that report constructions which
2311 are not inherently erroneous but which are risky or suggest there
2312 might have been an error.
2314 You can request many specific warnings with options beginning @samp{-W},
2315 for example @samp{-Wimplicit} to request warnings on implicit
2316 declarations. Each of these specific warning options also has a
2317 negative form beginning @samp{-Wno-} to turn off warnings;
2318 for example, @samp{-Wno-implicit}. This manual lists only one of the
2319 two forms, whichever is not the default.
2321 These options control the amount and kinds of warnings produced by GNU
2325 @cindex syntax checking
2326 @cindex -fsyntax-only option
2327 @cindex options, -fsyntax-only
2329 Check the code for syntax errors, but don't do anything beyond that.
2331 @cindex -pedantic option
2332 @cindex options, -pedantic
2334 Issue warnings for uses of extensions to ANSI FORTRAN 77.
2335 @samp{-pedantic} also applies to C-language constructs where they
2336 occur in GNU Fortran source files, such as use of @samp{\e} in a
2337 character constant within a directive like @samp{#include}.
2339 Valid ANSI FORTRAN 77 programs should compile properly with or without
2341 However, without this option, certain GNU extensions and traditional
2342 Fortran features are supported as well.
2343 With this option, many of them are rejected.
2345 Some users try to use @samp{-pedantic} to check programs for strict ANSI
2347 They soon find that it does not do quite what they want---it finds some
2348 non-ANSI practices, but not all.
2349 However, improvements to @code{g77} in this area are welcome.
2351 @cindex -pedantic-errors option
2352 @cindex options, -pedantic-errors
2353 @item -pedantic-errors
2354 Like @samp{-pedantic}, except that errors are produced rather than
2357 @cindex -fpedantic option
2358 @cindex options, -fpedantic
2360 Like @samp{-pedantic}, but applies only to Fortran constructs.
2365 Inhibit all warning messages.
2367 @cindex -Wno-globals option
2368 @cindex options, -Wno-globals
2370 @cindex global names, warning
2371 @cindex warnings, global names
2372 Inhibit warnings about use of a name as both a global name
2373 (a subroutine, function, or block data program unit, or a
2374 common block) and implicitly as the name of an intrinsic
2377 Also inhibit warnings about inconsistent invocations and/or
2378 definitions of global procedures (function and subroutines).
2379 Such inconsistencies include different numbers of arguments
2380 and different types of arguments.
2382 @cindex -Wimplicit option
2383 @cindex options, -Wimplicit
2385 @cindex implicit declaration, warning
2386 @cindex warnings, implicit declaration
2388 @cindex /WARNINGS=DECLARATIONS switch
2389 @cindex IMPLICIT NONE, similar effect
2390 @cindex effecting IMPLICIT NONE
2391 Warn whenever a variable, array, or function is implicitly
2393 Has an effect similar to using the @code{IMPLICIT NONE} statement
2394 in every program unit.
2395 (Some Fortran compilers provide this feature by an option
2396 named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)
2398 @cindex -Wunused option
2399 @cindex options, -Wunused
2401 @cindex unused variables
2402 @cindex variables, unused
2403 Warn whenever a variable is unused aside from its declaration.
2405 @cindex -Wuninitialized option
2406 @cindex options, -Wuninitialized
2407 @item -Wuninitialized
2408 @cindex uninitialized variables
2409 @cindex variables, uninitialized
2410 Warn whenever an automatic variable is used without first being initialized.
2412 These warnings are possible only in optimizing compilation,
2413 because they require data-flow information that is computed only
2414 when optimizing. If you don't specify @samp{-O}, you simply won't
2417 These warnings occur only for variables that are candidates for
2418 register allocation. Therefore, they do not occur for a variable
2419 @c that is declared @code{VOLATILE}, or
2420 whose address is taken, or whose size
2421 is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
2422 arrays, even when they are in registers.
2424 Note that there might be no warning about a variable that is used only
2425 to compute a value that itself is never used, because such
2426 computations may be deleted by data-flow analysis before the warnings
2429 These warnings are made optional because GNU Fortran is not smart
2430 enough to see all the reasons why the code might be correct
2431 despite appearing to have an error. Here is one example of how
2435 SUBROUTINE DISPAT(J)
2444 If the value of @code{J} is always 1, 2 or 3, then @code{I} is
2445 always initialized, but GNU Fortran doesn't know this. Here is
2446 another common case:
2449 SUBROUTINE MAYBE(FLAG)
2451 IF (FLAG) VALUE = 9.4
2453 IF (FLAG) PRINT *, VALUE
2458 This has no bug because @code{VALUE} is used only if it is set.
2460 @cindex -Wall option
2461 @cindex options, -Wall
2463 @cindex all warnings
2464 @cindex warnings, all
2465 The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
2467 options which pertain to usage that we recommend avoiding and that we
2468 believe is easy to avoid.
2469 (As more warnings are added to @code{g77}, some might
2470 be added to the list enabled by @samp{-Wall}.)
2473 The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
2474 because they warn about constructions that we consider reasonable to
2475 use, on occasion, in clean programs.
2479 @c Print extra warning messages for these events:
2483 @c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
2488 @cindex -Wsurprising option
2489 @cindex options, -Wsurprising
2491 Warn about ``suspicious'' constructs that are interpreted
2492 by the compiler in a way that might well be surprising to
2493 someone reading the code.
2494 These differences can result in subtle, compiler-dependent
2495 (even machine-dependent) behavioral differences.
2496 The constructs warned about include:
2500 Expressions having two arithmetic operators in a row, such
2502 Such a construct is nonstandard, and can produce
2503 unexpected results in more complicated situations such
2505 @code{g77}, along with many other compilers, interprets
2506 this example differently than many programmers, and a few
2508 Specifically, @code{g77} interprets @samp{X**-Y*Z} as
2509 @samp{(X**(-Y))*Z}, while others might think it should
2510 be interpreted as @samp{X**(-(Y*Z))}.
2512 A revealing example is the constant expression @samp{2**-2*1.},
2513 which @code{g77} evaluates to .25, while others might evaluate
2514 it to 0., the difference resulting from the way precedence affects
2517 (The @samp{-fpedantic} option also warns about expressions
2518 having two arithmetic operators in a row.)
2521 Expressions with a unary minus followed by an operand and then
2522 a binary operator other than plus or minus.
2523 For example, @samp{-2**2} produces a warning, because
2524 the precedence is @samp{-(2**2)}, yielding -4, not
2525 @samp{(-2)**2}, which yields 4, and which might represent
2526 what a programmer expects.
2528 An example of an expression producing different results
2529 in a surprising way is @samp{-I*S}, where @var{I} holds
2530 the value @samp{-2147483648} and @var{S} holds @samp{0.5}.
2531 On many systems, negating @var{I} results in the same
2532 value, not a positive number, because it is already the
2533 lower bound of what an @code{INTEGER(KIND=1)} variable can hold.
2534 So, the expression evaluates to a positive number, while
2535 the ``expected'' interpretation, @samp{(-I)*S}, would
2536 evaluate to a negative number.
2538 Even cases such as @samp{-I*J} produce warnings,
2539 even though, in most configurations and situations,
2540 there is no computational difference between the
2541 results of the two interpretations---the purpose
2542 of this warning is to warn about differing interpretations
2543 and encourage a better style of coding, not to identify
2544 only those places where bugs might exist in the user's
2547 @cindex DO statement
2548 @cindex statements, DO
2550 @code{DO} loops with @code{DO} variables that are not
2551 of integral type---that is, using @code{REAL}
2552 variables as loop control variables.
2553 Although such loops can be written to work in the
2554 ``obvious'' way, the way @code{g77} is required by the
2555 Fortran standard to interpret such code is likely to
2556 be quite different from the way many programmers expect.
2557 (This is true of all @code{DO} loops, but the differences
2558 are pronounced for non-integral loop control variables.)
2560 @xref{Loops}, for more information.
2563 @cindex -Werror option
2564 @cindex options, -Werror
2566 Make all warnings into errors.
2571 @cindex extra warnings
2572 @cindex warnings, extra
2573 Turns on ``extra warnings'' and, if optimization is specified
2574 via @samp{-O}, the @samp{-Wuninitialized} option.
2575 (This might change in future versions of @code{g77}.)
2577 ``Extra warnings'' are issued for:
2581 @cindex unused parameters
2582 @cindex parameters, unused
2583 @cindex unused arguments
2584 @cindex arguments, unused
2585 @cindex unused dummies
2586 @cindex dummies, unused
2587 Unused parameters to a procedure (when @samp{-Wunused} also is
2592 Overflows involving floating-point constants (not available
2593 for certain configurations).
2597 @xref{Warning Options,,Options to Request or Suppress Warnings,
2598 gcc,Using and Porting GNU CC}, for information on more options offered
2599 by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.
2601 Some of these have no effect when compiling programs written in Fortran:
2604 @cindex -Wcomment option
2605 @cindex options, -Wcomment
2607 @cindex -Wformat option
2608 @cindex options, -Wformat
2610 @cindex -Wparentheses option
2611 @cindex options, -Wparentheses
2613 @cindex -Wswitch option
2614 @cindex options, -Wswitch
2616 @cindex -Wtraditional option
2617 @cindex options, -Wtraditional
2619 @cindex -Wshadow option
2620 @cindex options, -Wshadow
2622 @cindex -Wid-clash-@var{len} option
2623 @cindex options, -Wid-clash-@var{len}
2624 @item -Wid-clash-@var{len}
2625 @cindex -Wlarger-than-@var{len} option
2626 @cindex options, -Wlarger-than-@var{len}
2627 @item -Wlarger-than-@var{len}
2628 @cindex -Wconversion option
2629 @cindex options, -Wconversion
2631 @cindex -Waggregate-return option
2632 @cindex options, -Waggregate-return
2633 @item -Waggregate-return
2634 @cindex -Wredundant-decls option
2635 @cindex options, -Wredundant-decls
2636 @item -Wredundant-decls
2637 @cindex unsupported warnings
2638 @cindex warnings, unsupported
2639 These options all could have some relevant meaning for
2640 GNU Fortran programs, but are not yet supported.
2643 @node Debugging Options
2644 @section Options for Debugging Your Program or GNU Fortran
2645 @cindex options, debugging
2646 @cindex debugging information options
2648 GNU Fortran has various special options that are used for debugging
2649 either your program or @code{g77}.
2655 Produce debugging information in the operating system's native format
2656 (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
2659 @cindex common blocks
2660 @cindex equivalence areas
2661 @cindex missing debug features
2662 Support for this option in Fortran programs is incomplete.
2663 In particular, names of variables and arrays in common blocks
2664 or that are storage-associated via @code{EQUIVALENCE} are
2665 unavailable to the debugger.
2667 However, version 0.5.19 of @code{g77} does provide this information
2668 in a rudimentary way, as controlled by the
2669 @samp{-fdebug-kludge} option.
2671 @xref{Code Gen Options,,Options for Code Generation Conventions},
2672 for more information.
2675 @xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
2676 gcc,Using and Porting GNU CC}, for more information on debugging options.
2678 @node Optimize Options
2679 @section Options That Control Optimization
2680 @cindex optimize options
2681 @cindex options, optimization
2683 Most Fortran users will want to use no optimization when
2684 developing and testing programs, and use @samp{-O} or @samp{-O2} when
2685 compiling programs for late-cycle testing and for production use.
2686 However, note that certain diagnostics---such as for uninitialized
2687 variables---depend on the flow analysis done by @samp{-O}, i.e.@: you
2688 must use @samp{-O} or @samp{-O2} to get such diagnostics.
2690 The following flags have particular applicability when
2691 compiling Fortran programs:
2694 @cindex -malign-double option
2695 @cindex options, -malign-double
2696 @item -malign-double
2697 (Intel x86 architecture only.)
2699 Noticeably improves performance of @code{g77} programs making
2700 heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data
2702 In particular, systems using Pentium, Pentium Pro, 586, and
2704 of the i386 architecture execute programs faster when
2705 @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data are
2706 aligned on 64-bit boundaries
2709 This option can, at least, make benchmark results more consistent
2710 across various system configurations, versions of the program,
2713 @emph{Note:} The warning in the @code{gcc} documentation about
2714 this option does not apply, generally speaking, to Fortran
2715 code compiled by @code{g77}.
2717 @xref{Aligned Data}, for more information on alignment issues.
2719 @emph{Also also note:} The negative form of @samp{-malign-double}
2720 is @samp{-mno-align-double}, not @samp{-benign-double}.
2722 @cindex -ffloat-store option
2723 @cindex options, -ffloat-store
2725 @cindex IEEE 754 conformance
2726 @cindex conformance, IEEE 754
2727 @cindex floating-point, precision
2728 Might help a Fortran program that depends on exact IEEE conformance on
2729 some machines, but might slow down a program that doesn't.
2731 This option is effective when the floating-point unit is set to work in
2732 IEEE 854 `extended precision'---as it typically is on x86 and m68k GNU
2733 systems---rather than IEEE 754 double precision. @samp{-ffloat-store}
2734 tries to remove the extra precision by spilling data from floating-point
2735 registers into memory and this typically involves a big performance
2736 hit. However, it doesn't affect intermediate results, so that it is
2737 only partially effective. `Excess precision' is avoided in code like:
2742 but not in code like:
2747 For another, potentially better, way of controlling the precision,
2748 see @ref{Floating-point precision}.
2750 @cindex -fforce-mem option
2751 @cindex options, -fforce-mem
2753 @cindex -fforce-addr option
2754 @cindex options, -fforce-addr
2756 @cindex loops, speeding up
2757 @cindex speed, of loops
2758 Might improve optimization of loops.
2760 @cindex -fno-inline option
2761 @cindex options, -fno-inline
2763 @cindex in-line code
2764 @cindex compilation, in-line
2765 @c DL: Only relevant for -O3?
2766 Don't compile statement functions inline.
2767 Might reduce the size of a program unit---which might be at
2768 expense of some speed (though it should compile faster).
2769 Note that if you are not optimizing, no functions can be expanded inline.
2771 @cindex -ffast-math option
2772 @cindex options, -ffast-math
2774 @cindex IEEE 754 conformance
2775 @cindex conformance, IEEE 754
2776 Might allow some programs designed to not be too dependent
2777 on IEEE behavior for floating-point to run faster, or die trying.
2779 @cindex -fstrength-reduce option
2780 @cindex options, -fstrength-reduce
2781 @item -fstrength-reduce
2782 @cindex loops, speeding up
2783 @cindex speed, of loops
2784 @c DL: normally defaulted?
2785 Might make some loops run faster.
2787 @cindex -frerun-cse-after-loop option
2788 @cindex options, -frerun-cse-after-loop
2789 @item -frerun-cse-after-loop
2790 @cindex -fexpensive-optimizations option
2791 @cindex options, -fexpensive-optimizations
2793 @item -fexpensive-optimizations
2794 @cindex -fdelayed-branch option
2795 @cindex options, -fdelayed-branch
2796 @item -fdelayed-branch
2797 @cindex -fschedule-insns option
2798 @cindex options, -fschedule-insns
2799 @item -fschedule-insns
2800 @cindex -fschedule-insns2 option
2801 @cindex options, -fschedule-insns2
2802 @item -fschedule-insns2
2803 @cindex -fcaller-saves option
2804 @cindex options, -fcaller-saves
2805 @item -fcaller-saves
2806 Might improve performance on some code.
2808 @cindex -funroll-loops option
2809 @cindex options, -funroll-loops
2810 @item -funroll-loops
2811 @cindex loops, unrolling
2812 @cindex unrolling loops
2813 @cindex loops, optimizing
2814 @cindex indexed (iterative) @code{DO}
2815 @cindex iterative @code{DO}
2816 @c DL: fixme: Craig doesn't like `indexed' but f95 doesn't seem to
2817 @c provide a suitable term
2818 @c CB: I've decided on `iterative', for the time being, and changed
2819 @c my previous, rather bizarre, use of `imperative' to that
2820 @c (though `precomputed-trip' would be a more precise adjective)
2821 Typically improves performance on code using iterative @code{DO} loops by
2822 unrolling them and is probably generally appropriate for Fortran, though
2823 it is not turned on at any optimization level.
2824 Note that outer loop unrolling isn't done specifically; decisions about
2825 whether to unroll a loop are made on the basis of its instruction count.
2827 @c DL: Fixme: This should obviously go somewhere else...
2828 Also, no `loop discovery'@footnote{@dfn{loop discovery} refers to the
2829 process by which a compiler, or indeed any reader of a program,
2830 determines which portions of the program are more likely to be executed
2831 repeatedly as it is being run. Such discovery typically is done early
2832 when compiling using optimization techniques, so the ``discovered''
2833 loops get more attention---and more run-time resources, such as
2834 registers---from the compiler. It is easy to ``discover'' loops that are
2835 constructed out of looping constructs in the language
2836 (such as Fortran's @code{DO}). For some programs, ``discovering'' loops
2837 constructed out of lower-level constructs (such as @code{IF} and
2838 @code{GOTO}) can lead to generation of more optimal code
2839 than otherwise.} is done, so only loops written with @code{DO}
2840 benefit from loop optimizations, including---but not limited
2841 to---unrolling. Loops written with @code{IF} and @code{GOTO} are not
2842 currently recognized as such. This option unrolls only iterative
2843 @code{DO} loops, not @code{DO WHILE} loops.
2845 @cindex -funroll-all-loops option
2846 @cindex options, -funroll-all-loops
2848 @item -funroll-all-loops
2849 @c DL: Check my understanding of -funroll-all-loops v. -funroll-loops is correct.
2850 Probably improves performance on code using @code{DO WHILE} loops by
2851 unrolling them in addition to iterative @code{DO} loops. In the absence
2852 of @code{DO WHILE}, this option is equivalent to @samp{-funroll-loops}
2853 but possibly slower.
2855 @item -fno-move-all-movables
2856 @cindex -fno-move-all-movables option
2857 @cindex options, -fno-move-all-movables
2858 @item -fno-reduce-all-givs
2859 @cindex -fno-reduce-all-givs option
2860 @cindex options, -fno-reduce-all-givs
2861 @item -fno-rerun-loop-opt
2862 @cindex -fno-rerun-loop-opt option
2863 @cindex options, -fno-rerun-loop-opt
2864 @emph{Version info:}
2865 These options are not supported by
2866 versions of @code{g77} based on @code{gcc} version 2.8.
2868 Each of these might improve performance on some code.
2870 Analysis of Fortran code optimization and the resulting
2871 optimizations triggered by the above options were
2872 contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).
2874 These three options are intended to be removed someday, once
2875 they have helped determine the efficacy of various
2876 approaches to improving the performance of Fortran code.
2878 Please let us know how use of these options affects
2879 the performance of your production code.
2880 We're particularly interested in code that runs faster
2881 when these options are @emph{disabled}, and in
2882 non-Fortran code that benefits when they are
2883 @emph{enabled} via the above @code{gcc} command-line options.
2886 @xref{Optimize Options,,Options That Control Optimization,
2887 gcc,Using and Porting GNU CC}, for more information on options
2888 to optimize the generated machine code.
2890 @node Preprocessor Options
2891 @section Options Controlling the Preprocessor
2892 @cindex preprocessor options
2893 @cindex options, preprocessor
2895 @cindex programs, cpp
2897 These options control the C preprocessor, which is run on each C source
2898 file before actual compilation.
2900 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
2901 gcc,Using and Porting GNU CC}, for information on C preprocessor options.
2903 @cindex INCLUDE directive
2904 @cindex directive, INCLUDE
2905 Some of these options also affect how @code{g77} processes the
2906 @code{INCLUDE} directive.
2907 Since this directive is processed even when preprocessing
2908 is not requested, it is not described in this section.
2909 @xref{Directory Options,,Options for Directory Search}, for
2910 information on how @code{g77} processes the @code{INCLUDE} directive.
2912 However, the @code{INCLUDE} directive does not apply
2913 preprocessing to the contents of the included file itself.
2915 Therefore, any file that contains preprocessor directives
2916 (such as @code{#include}, @code{#define}, and @code{#if})
2917 must be included via the @code{#include} directive, not
2918 via the @code{INCLUDE} directive.
2919 Therefore, any file containing preprocessor directives,
2920 if included, is necessarily included by a file that itself
2921 contains preprocessor directives.
2923 @node Directory Options
2924 @section Options for Directory Search
2925 @cindex directory, options
2926 @cindex options, directory search
2929 These options affect how the @code{cpp} preprocessor searches
2930 for files specified via the @code{#include} directive.
2931 Therefore, when compiling Fortran programs, they are meaningful
2932 when the preprocessor is used.
2934 @cindex INCLUDE directive
2935 @cindex directive, INCLUDE
2936 Some of these options also affect how @code{g77} searches
2937 for files specified via the @code{INCLUDE} directive,
2938 although files included by that directive are not,
2939 themselves, preprocessed.
2944 @cindex options, -I-
2946 @cindex -Idir option
2947 @cindex options, -Idir
2949 @cindex directory, search paths for inclusion
2950 @cindex inclusion, directory search paths for
2951 @cindex search paths, for included files
2952 @cindex paths, search
2953 These affect interpretation of the @code{INCLUDE} directive
2954 (as well as of the @code{#include} directive of the @code{cpp}
2957 Note that @samp{-I@var{dir}} must be specified @emph{without} any
2958 spaces between @samp{-I} and the directory name---that is,
2959 @samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
2960 is rejected by the @code{g77} compiler (though the preprocessor supports
2962 @c this is due to toplev.c's inflexible option processing
2963 Also note that the general behavior of @samp{-I} and
2964 @code{INCLUDE} is pretty much the same as of @samp{-I} with
2965 @code{#include} in the @code{cpp} preprocessor, with regard to
2966 looking for @file{header.gcc} files and other such things.
2968 @xref{Directory Options,,Options for Directory Search,
2969 gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
2972 @node Code Gen Options
2973 @section Options for Code Generation Conventions
2974 @cindex code generation, conventions
2975 @cindex options, code generation
2976 @cindex run-time, options
2978 These machine-independent options control the interface conventions
2979 used in code generation.
2981 Most of them have both positive and negative forms; the negative form
2982 of @samp{-ffoo} would be @samp{-fno-foo}. In the table below, only
2983 one of the forms is listed---the one which is not the default. You
2984 can figure out the other form by either removing @samp{no-} or adding
2988 @cindex -fno-automatic option
2989 @cindex options, -fno-automatic
2990 @item -fno-automatic
2991 @cindex SAVE statement
2992 @cindex statements, SAVE
2993 Treat each program unit as if the @code{SAVE} statement was specified
2994 for every local variable and array referenced in it.
2995 Does not affect common blocks.
2996 (Some Fortran compilers provide this option under
2997 the name @samp{-static}.)
2999 @cindex -finit-local-zero option
3000 @cindex options, -finit-local-zero
3001 @item -finit-local-zero
3002 @cindex DATA statement
3003 @cindex statements, DATA
3004 @cindex initialization, of local variables
3005 @cindex variables, initialization of
3006 @cindex uninitialized variables
3007 @cindex variables, uninitialized
3008 Specify that variables and arrays that are local to a program unit
3009 (not in a common block and not passed as an argument) are to be initialized
3012 Since there is a run-time penalty for initialization of variables
3013 that are not given the @code{SAVE} attribute, it might be a
3014 good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.
3016 @cindex -fno-f2c option
3017 @cindex options, -fno-f2c
3019 @cindex @code{f2c} compatibility
3020 @cindex compatibility, @code{f2c}
3021 Do not generate code designed to be compatible with code generated
3022 by @code{f2c}; use the GNU calling conventions instead.
3024 The @code{f2c} calling conventions require functions that return
3025 type @code{REAL(KIND=1)} to actually return the C type @code{double},
3026 and functions that return type @code{COMPLEX} to return the
3027 values via an extra argument in the calling sequence that points
3028 to where to store the return value.
3029 Under the GNU calling conventions, such functions simply return
3030 their results as they would in GNU C---@code{REAL(KIND=1)} functions
3031 return the C type @code{float}, and @code{COMPLEX} functions
3032 return the GNU C type @code{complex} (or its @code{struct}
3035 This does not affect the generation of code that interfaces with the
3036 @code{libg2c} library.
3038 However, because the @code{libg2c} library uses @code{f2c}
3039 calling conventions, @code{g77} rejects attempts to pass
3040 intrinsics implemented by routines in this library as actual
3041 arguments when @samp{-fno-f2c} is used, to avoid bugs when
3042 they are actually called by code expecting the GNU calling
3043 conventions to work.
3045 For example, @samp{INTRINSIC ABS;CALL FOO(ABS)} is
3046 rejected when @samp{-fno-f2c} is in force.
3047 (Future versions of the @code{g77} run-time library might
3048 offer routines that provide GNU-callable versions of the
3049 routines that implement the @code{f2c}-callable intrinsics
3050 that may be passed as actual arguments, so that
3051 valid programs need not be rejected when @samp{-fno-f2c}
3054 @strong{Caution:} If @samp{-fno-f2c} is used when compiling any
3055 source file used in a program, it must be used when compiling
3056 @emph{all} Fortran source files used in that program.
3058 @c seems kinda dumb to tell people about an option they can't use -- jcb
3059 @c then again, we want users building future-compatible libraries with it.
3060 @cindex -ff2c-library option
3061 @cindex options, -ff2c-library
3063 Specify that use of @code{libg2c} (or the original @code{libf2c})
3065 This is the default for the current version of @code{g77}.
3068 valid to specify @samp{-fno-f2c-library}.
3069 This option is provided so users can specify it in shell
3070 scripts that build programs and libraries that require the
3071 @code{libf2c} library, even when being compiled by future
3072 versions of @code{g77} that might otherwise default to
3073 generating code for an incompatible library.
3075 @cindex -fno-underscoring option
3076 @cindex options, -fno-underscoring
3077 @item -fno-underscoring
3079 @cindex symbol names, underscores
3080 @cindex transforming symbol names
3081 @cindex symbol names, transforming
3082 Do not transform names of entities specified in the Fortran
3083 source file by appending underscores to them.
3085 With @samp{-funderscoring} in effect, @code{g77} appends two underscores
3086 to names with underscores and one underscore to external names with
3087 no underscores. (@code{g77} also appends two underscores to internal
3088 names with underscores to avoid naming collisions with external names.
3089 The @samp{-fno-second-underscore} option disables appending of the
3090 second underscore in all cases.)
3092 This is done to ensure compatibility with code produced by many
3093 UNIX Fortran compilers, including @code{f2c}, which perform the
3094 same transformations.
3096 Use of @samp{-fno-underscoring} is not recommended unless you are
3097 experimenting with issues such as integration of (GNU) Fortran into
3098 existing system environments (vis-a-vis existing libraries, tools, and
3101 For example, with @samp{-funderscoring}, and assuming other defaults like
3102 @samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
3103 external functions while @samp{my_var} and @samp{lvar} are local variables,
3107 I = J() + MAX_COUNT (MY_VAR, LVAR)
3111 is implemented as something akin to:
3114 i = j_() + max_count__(&my_var__, &lvar);
3117 With @samp{-fno-underscoring}, the same statement is implemented as:
3120 i = j() + max_count(&my_var, &lvar);
3123 Use of @samp{-fno-underscoring} allows direct specification of
3124 user-defined names while debugging and when interfacing @code{g77}-compiled
3125 code with other languages.
3127 Note that just because the names match does @emph{not} mean that the
3128 interface implemented by @code{g77} for an external name matches the
3129 interface implemented by some other language for that same name.
3130 That is, getting code produced by @code{g77} to link to code produced
3131 by some other compiler using this or any other method can be only a
3132 small part of the overall solution---getting the code generated by
3133 both compilers to agree on issues other than naming can require
3134 significant effort, and, unlike naming disagreements, linkers normally
3135 cannot detect disagreements in these other areas.
3137 Also, note that with @samp{-fno-underscoring}, the lack of appended
3138 underscores introduces the very real possibility that a user-defined
3139 external name will conflict with a name in a system library, which
3140 could make finding unresolved-reference bugs quite difficult in some
3141 cases---they might occur at program run time, and show up only as
3142 buggy behavior at run time.
3144 In future versions of @code{g77}, we hope to improve naming and linking
3145 issues so that debugging always involves using the names as they appear
3146 in the source, even if the names as seen by the linker are mangled to
3147 prevent accidental linking between procedures with incompatible
3150 @cindex -fno-second-underscore option
3151 @cindex options, -fno-second-underscore
3152 @item -fno-second-underscore
3154 @cindex symbol names, underscores
3155 @cindex transforming symbol names
3156 @cindex symbol names, transforming
3157 Do not append a second underscore to names of entities specified
3158 in the Fortran source file.
3160 This option has no effect if @samp{-fno-underscoring} is
3163 Otherwise, with this option, an external name such as @samp{MAX_COUNT}
3164 is implemented as a reference to the link-time external symbol
3165 @samp{max_count_}, instead of @samp{max_count__}.
3167 @cindex -fno-ident option
3168 @cindex options, -fno-ident
3170 Ignore the @samp{#ident} directive.
3172 @cindex -fzeros option
3173 @cindex options, -fzeros
3175 Treat initial values of zero as if they were any other value.
3177 As of version 0.5.18, @code{g77} normally treats @code{DATA} and
3178 other statements that are used to specify initial values of zero
3179 for variables and arrays as if no values were actually specified,
3180 in the sense that no diagnostics regarding multiple initializations
3183 This is done to speed up compiling of programs that initialize
3184 large arrays to zeros.
3186 Use @samp{-fzeros} to revert to the simpler, slower behavior
3187 that can catch multiple initializations by keeping track of
3188 all initializations, zero or otherwise.
3190 @emph{Caution:} Future versions of @code{g77} might disregard this option
3191 (and its negative form, the default) or interpret it somewhat
3193 The interpretation changes will affect only non-standard
3194 programs; standard-conforming programs should not be affected.
3196 @cindex -fdebug-kludge option
3197 @cindex options, -fdebug-kludge
3198 @item -fdebug-kludge
3199 Emit information on @code{COMMON} and @code{EQUIVALENCE} members
3200 that might help users of debuggers work around lack of proper debugging
3201 information on such members.
3203 As of version 0.5.19, @code{g77} offers this option to emit
3204 information on members of aggregate areas to help users while debugging.
3205 This information consists of establishing the type and contents of each
3206 such member so that, when a debugger is asked to print the contents,
3207 the printed information provides rudimentary debugging information.
3208 This information identifies the name of the aggregate area (either the
3209 @code{COMMON} block name, or the @code{g77}-assigned name for the
3210 @code{EQUIVALENCE} name) and the offset, in bytes, of the member from
3211 the beginning of the area.
3213 Using @code{gdb}, this information is not coherently displayed in the Fortran
3214 language mode, so temporarily switching to the C language mode to display the
3215 information is suggested.
3216 Use @samp{set language c} and @samp{set language fortran} to accomplish this.
3224 EQUIVALENCE (I,XX(20:20))
3227 GDB is free software and you are welcome to distribute copies of it
3228 under certain conditions; type "show copying" to see the conditions.
3229 There is absolutely no warranty for GDB; type "show warranty" for details.
3230 GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
3232 Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
3234 Starting program: /home/user/a.out
3236 Breakpoint 1, MAIN__ () at cd.f:5
3237 Current language: auto; currently fortran
3238 (gdb) set language c
3239 Warning: the current language does not match this frame.
3241 $2 = "At (COMMON) `x_' plus 0 bytes"
3243 $3 = "At (COMMON) `x_' plus 4 bytes"
3245 $4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3247 $5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3249 $6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
3251 $7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
3252 (gdb) set language fortran
3257 Use @samp{-fdebug-kludge} to generate this information,
3258 which might make some programs noticeably larger.
3260 @emph{Caution:} Future versions of @code{g77} might disregard this option
3261 (and its negative form).
3262 Current plans call for this to happen when published versions of @code{g77}
3263 and @code{gdb} exist that provide proper access to debugging information on
3264 @code{COMMON} and @code{EQUIVALENCE} members.
3266 @cindex -femulate-complex option
3267 @cindex options, -femulate-complex
3268 @item -femulate-complex
3269 Implement @code{COMPLEX} arithmetic via emulation,
3270 instead of using the facilities of
3271 the @code{gcc} back end that provide direct support of
3272 @code{complex} arithmetic.
3274 (@code{gcc} had some bugs in its back-end support
3275 for @code{complex} arithmetic, due primarily to the support not being
3276 completed as of version 2.8.1 and @code{egcs} 1.1.2.)
3278 Use @samp{-femulate-complex} if you suspect code-generation bugs,
3279 or experience compiler crashes,
3280 that might result from @code{g77} using the @code{COMPLEX} support
3281 in the @code{gcc} back end.
3282 If using that option fixes the bugs or crashes you are seeing,
3283 that indicates a likely @code{g77} bugs
3284 (though, all compiler crashes are considered bugs),
3285 so, please report it.
3286 (Note that the known bugs, now believed fixed, produced compiler crashes
3287 rather than causing the generation of incorrect code.)
3289 Use of this option should not affect how Fortran code compiled
3290 by @code{g77} works in terms of its interfaces to other code,
3291 e.g. that compiled by @code{f2c}.
3293 @emph{Caution:} Future versions of @code{g77} might ignore both forms
3296 @cindex -falias-check option
3297 @cindex options, -falias-check
3298 @cindex -fargument-alias option
3299 @cindex options, -fargument-alias
3300 @cindex -fargument-noalias option
3301 @cindex options, -fargument-noalias
3302 @cindex -fno-argument-noalias-global option
3303 @cindex options, -fno-argument-noalias-global
3305 @item -fargument-alias
3306 @item -fargument-noalias
3307 @item -fno-argument-noalias-global
3308 @emph{Version info:}
3309 These options are not supported by
3310 versions of @code{g77} based on @code{gcc} version 2.8.
3312 These options specify to what degree aliasing
3314 is permitted between
3315 arguments (passed as pointers) and @code{COMMON} (external, or
3318 The default for Fortran code, as mandated by the FORTRAN 77 and
3319 Fortran 90 standards, is @samp{-fargument-noalias-global}.
3320 The default for code written in the C language family is
3321 @samp{-fargument-alias}.
3323 Note that, on some systems, compiling with @samp{-fforce-addr} in
3324 effect can produce more optimal code when the default aliasing
3325 options are in effect (and when optimization is enabled).
3327 @xref{Aliasing Assumed To Work}, for detailed information on the implications
3328 of compiling Fortran code that depends on the ability to alias dummy
3331 @cindex -fno-globals option
3332 @cindex options, -fno-globals
3334 @cindex global names, warning
3335 @cindex warnings, global names
3336 @cindex in-line code
3337 @cindex compilation, in-line
3338 Disable diagnostics about inter-procedural
3339 analysis problems, such as disagreements about the
3340 type of a function or a procedure's argument,
3341 that might cause a compiler crash when attempting
3342 to inline a reference to a procedure within a
3344 (The diagnostics themselves are still produced, but
3345 as warnings, unless @samp{-Wno-globals} is specified,
3346 in which case no relevant diagnostics are produced.)
3348 Further, this option disables such inlining, to
3349 avoid compiler crashes resulting from incorrect
3350 code that would otherwise be diagnosed.
3352 As such, this option might be quite useful when
3353 compiling existing, ``working'' code that happens
3354 to have a few bugs that do not generally show themselves,
3355 but which @code{g77} diagnoses.
3357 Use of this option therefore has the effect of
3358 instructing @code{g77} to behave more like it did
3359 up through version 0.5.19.1, when it paid little or
3360 no attention to disagreements between program units
3361 about a procedure's type and argument information,
3362 and when it performed no inlining of procedures
3363 (except statement functions).
3365 Without this option, @code{g77} defaults to performing
3366 the potentially inlining procedures as it started doing
3367 in version 0.5.20, but as of version 0.5.21, it also
3368 diagnoses disagreements that might cause such inlining
3369 to crash the compiler as (fatal) errors,
3370 and warns about similar disagreements
3371 that are currently believed to not
3372 likely to result in the compiler later crashing
3373 or producing incorrect code.
3375 @cindex -fsubscript-check option
3376 @cindex -ff2c-subscript-check option
3377 @item -fsubscript-check
3378 @itemx -ff2c-subscript-check
3379 @cindex bounds checking
3380 @cindex range checking
3381 @cindex array bounds checking
3382 @cindex subscript checking
3383 @cindex substring checking
3384 @cindex checking subscripts
3385 @cindex checking substrings
3386 Enable generation of run-time checks for array subscripts
3387 and substring start and end points
3388 against the (locally) declared minimum and maximum values.
3390 The current implementation uses the @code{libf2c}
3391 library routine @code{s_rnge} to print the diagnostic.
3393 However, whereas @code{f2c} generates a single check per
3394 reference for a multi-dimensional array, of the computed
3395 offset against the valid offset range (0 through the size of the array),
3396 @code{g77} generates a single check per @emph{subscript} expression.
3397 This catches some cases of potential bugs that @code{f2c} does not,
3398 such as references to below the beginning of an assumed-size array.
3400 @code{g77} also generates checks for @code{CHARACTER} substring references,
3401 something @code{f2c} currently does not do.
3403 Since a future version of @code{g77} might use a different implementation,
3404 use the new @samp{-ff2c-subscript-check} option
3405 if your application requires use of @code{s_rnge} or a compile-time diagnostic.
3407 @emph{Note:} To provide more detailed information on the offending subscript,
3408 @code{g77} provides @code{s_rnge}
3409 with somewhat differently-formatted information.
3410 Here's a sample diagnostic:
3413 Subscript out of range on file line 4, procedure rnge.f/bf.
3414 Attempt to access the -6-th element of variable b[subscript-2-of-2].
3418 The above message indicates that the offending source line is
3419 line 4 of the file @file{rnge.f},
3420 within the program unit (or statement function) named @samp{bf}.
3421 The offended array is named @samp{b}.
3422 The offended array dimension is the second for a two-dimensional array,
3423 and the offending, computed subscript expression was @samp{-6}.
3425 For a @code{CHARACTER} substring reference, the second line has
3429 Attempt to access the 11-th element of variable a[start-substring].
3432 This indicates that the offended @code{CHARACTER} variable or array
3434 the offended substring position is the starting (leftmost) position,
3435 and the offending substring expression is @samp{11}.
3437 (Though the verbage of @code{s_rnge} is not ideal
3438 for the purpose of the @code{g77} compiler,
3439 the above information should provide adequate diagnostic abilities
3443 @xref{Code Gen Options,,Options for Code Generation Conventions,
3444 gcc,Using and Porting GNU CC}, for information on more options
3446 shared by @code{g77}, @code{gcc}, and other GNU compilers.
3448 Some of these do @emph{not} work when compiling programs written in Fortran:
3451 @cindex -fpcc-struct-return option
3452 @cindex options, -fpcc-struct-return
3453 @item -fpcc-struct-return
3454 @cindex -freg-struct-return option
3455 @cindex options, -freg-struct-return
3456 @item -freg-struct-return
3457 You should not use these except strictly the same way as you
3458 used them to build the version of @code{libg2c} with which
3459 you will be linking all code compiled by @code{g77} with the
3462 @cindex -fshort-double option
3463 @cindex options, -fshort-double
3464 @item -fshort-double
3465 This probably either has no effect on Fortran programs, or
3466 makes them act loopy.
3468 @cindex -fno-common option
3469 @cindex options, -fno-common
3471 Do not use this when compiling Fortran programs,
3472 or there will be Trouble.
3474 @cindex -fpack-struct option
3475 @cindex options, -fpack-struct
3477 This probably will break any calls to the @code{libg2c} library,
3478 at the very least, even if it is built with the same option.
3481 @node Environment Variables
3482 @section Environment Variables Affecting GNU Fortran
3483 @cindex environment variables
3485 GNU Fortran currently does not make use of any environment
3486 variables to control its operation above and beyond those
3487 that affect the operation of @code{gcc}.
3489 @xref{Environment Variables,,Environment Variables Affecting GNU CC,
3490 gcc,Using and Porting GNU CC}, for information on environment
3500 @chapter The GNU Fortran Language
3502 @cindex standard, ANSI FORTRAN 77
3503 @cindex ANSI FORTRAN 77 standard
3504 @cindex reference works
3505 GNU Fortran supports a variety of extensions to, and dialects
3506 of, the Fortran language.
3507 Its primary base is the ANSI FORTRAN 77 standard, currently available on
3509 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
3510 or as monolithic text at
3511 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
3512 It offers some extensions that are popular among users
3513 of UNIX @code{f77} and @code{f2c} compilers, some that
3514 are popular among users of other compilers (such as Digital
3515 products), some that are popular among users of the
3516 newer Fortran 90 standard, and some that are introduced
3520 (If you need a text on Fortran,
3521 a few freely available electronic references have pointers from
3522 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
3523 net project', @cite{User Notes on Fortran Programming} at
3524 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
3525 material might not apply specifically to @code{g77}.)
3527 Part of what defines a particular implementation of a Fortran
3528 system, such as @code{g77}, is the particular characteristics
3529 of how it supports types, constants, and so on.
3530 Much of this is left up to the implementation by the various
3531 Fortran standards and accepted practice in the industry.
3533 The GNU Fortran @emph{language} is described below.
3534 Much of the material is organized along the same lines
3535 as the ANSI FORTRAN 77 standard itself.
3537 @xref{Other Dialects}, for information on features @code{g77} supports
3538 that are not part of the GNU Fortran language.
3540 @emph{Note}: This portion of the documentation definitely needs a lot
3544 Relationship to the ANSI FORTRAN 77 standard:
3545 * Direction of Language Development:: Where GNU Fortran is headed.
3546 * Standard Support:: Degree of support for the standard.
3548 Extensions to the ANSI FORTRAN 77 standard:
3551 * Terms and Concepts::
3552 * Characters Lines Sequence::
3553 * Data Types and Constants::
3555 * Specification Statements::
3556 * Control Statements::
3557 * Functions and Subroutines::
3558 * Scope and Classes of Names::
3560 * Fortran 90 Features::
3563 @node Direction of Language Development
3564 @section Direction of Language Development
3565 @cindex direction of language development
3566 @cindex features, language
3567 @cindex language, features
3569 The purpose of the following description of the GNU Fortran
3570 language is to promote wide portability of GNU Fortran programs.
3572 GNU Fortran is an evolving language, due to the
3573 fact that @code{g77} itself is in beta test.
3574 Some current features of the language might later
3575 be redefined as dialects of Fortran supported by @code{g77}
3576 when better ways to express these features are added to @code{g77},
3578 Such features would still be supported by
3579 @code{g77}, but would be available only when
3580 one or more command-line options were used.
3582 The GNU Fortran @emph{language} is distinct from the
3583 GNU Fortran @emph{compilation system} (@code{g77}).
3585 For example, @code{g77} supports various dialects of
3586 Fortran---in a sense, these are languages other than
3587 GNU Fortran---though its primary
3588 purpose is to support the GNU Fortran language, which also is
3589 described in its documentation and by its implementation.
3591 On the other hand, non-GNU compilers might offer
3592 support for the GNU Fortran language, and are encouraged
3595 Currently, the GNU Fortran language is a fairly fuzzy object.
3596 It represents something of a cross between what @code{g77} accepts
3597 when compiling using the prevailing defaults and what this
3598 document describes as being part of the language.
3600 Future versions of @code{g77} are expected to clarify the
3601 definition of the language in the documentation.
3602 Often, this will mean adding new features to the language, in the form
3603 of both new documentation and new support in @code{g77}.
3604 However, it might occasionally mean removing a feature
3605 from the language itself to ``dialect'' status.
3606 In such a case, the documentation would be adjusted
3607 to reflect the change, and @code{g77} itself would likely be changed
3608 to require one or more command-line options to continue supporting
3611 The development of the GNU Fortran language is intended to strike
3616 Serving as a mostly-upwards-compatible language from the
3617 de facto UNIX Fortran dialect as supported by @code{f77}.
3620 Offering new, well-designed language features.
3621 Attributes of such features include
3622 not making existing code any harder to read
3623 (for those who might be unaware that the new
3624 features are not in use) and
3625 not making state-of-the-art
3626 compilers take longer to issue diagnostics,
3630 Supporting existing, well-written code without gratuitously
3631 rejecting non-standard constructs, regardless of the origin
3632 of the code (its dialect).
3635 Offering default behavior and command-line options to reduce
3636 and, where reasonable, eliminate the need for programmers to make
3637 any modifications to code that already works in existing
3638 production environments.
3641 Diagnosing constructs that have different meanings in different
3642 systems, languages, and dialects, while offering clear,
3643 less ambiguous ways to express each of the different meanings
3644 so programmers can change their code appropriately.
3647 One of the biggest practical challenges for the developers of the
3648 GNU Fortran language is meeting the sometimes contradictory demands
3651 For example, a feature might be widely used in one popular environment,
3652 but the exact same code that utilizes that feature might not work
3653 as expected---perhaps it might mean something entirely different---in
3654 another popular environment.
3656 Traditionally, Fortran compilers---even portable ones---have solved this
3657 problem by simply offering the appropriate feature to users of
3658 the respective systems.
3659 This approach treats users of various Fortran systems and dialects
3660 as remote ``islands'', or camps, of programmers, and assume that these
3661 camps rarely come into contact with each other (or,
3662 especially, with each other's code).
3664 Project GNU takes a radically different approach to software and language
3665 design, in that it assumes that users of GNU software do not necessarily
3666 care what kind of underlying system they are using, regardless
3667 of whether they are using software (at the user-interface
3668 level) or writing it (for example, writing Fortran or C code).
3670 As such, GNU users rarely need consider just what kind of underlying
3671 hardware (or, in many cases, operating system) they are using at any
3673 They can use and write software designed for a general-purpose,
3674 widely portable, heterogenous environment---the GNU environment.
3676 In line with this philosophy, GNU Fortran must evolve into a product
3677 that is widely ported and portable not only in the sense that it can
3678 be successfully built, installed, and run by users, but in the larger
3679 sense that its users can use it in the same way, and expect largely the
3680 same behaviors from it, regardless of the kind of system they are using
3681 at any particular time.
3683 This approach constrains the solutions @code{g77} can use to resolve
3684 conflicts between various camps of Fortran users.
3685 If these two camps disagree about what a particular construct should
3686 mean, @code{g77} cannot simply be changed to treat that particular construct as
3687 having one meaning without comment (such as a warning), lest the users
3688 expecting it to have the other meaning are unpleasantly surprised that
3689 their code misbehaves when executed.
3691 The use of the ASCII backslash character in character constants is
3692 an excellent (and still somewhat unresolved) example of this kind of
3694 @xref{Backslash in Constants}.
3695 Other examples are likely to arise in the future, as @code{g77} developers
3696 strive to improve its ability to accept an ever-wider variety of existing
3697 Fortran code without requiring significant modifications to said code.
3699 Development of GNU Fortran is further constrained by the desire
3700 to avoid requiring programmers to change their code.
3701 This is important because it allows programmers, administrators,
3702 and others to more faithfully evaluate and validate @code{g77}
3703 (as an overall product and as new versions are distributed)
3704 without having to support multiple versions of their programs
3705 so that they continue to work the same way on their existing
3706 systems (non-GNU perhaps, but possibly also earlier versions
3709 @node Standard Support
3710 @section ANSI FORTRAN 77 Standard Support
3711 @cindex ANSI FORTRAN 77 support
3712 @cindex standard, support for
3713 @cindex support, FORTRAN 77
3714 @cindex compatibility, FORTRAN 77
3715 @cindex FORTRAN 77 compatibility
3717 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
3718 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
3719 support are those that are probably rarely used in actual code,
3720 some of which are explicitly disallowed by the Fortran 90 standard.
3723 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
3724 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
3725 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
3726 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
3729 @node No Passing External Assumed-length
3730 @subsection No Passing External Assumed-length
3732 @code{g77} disallows passing of an external procedure
3733 as an actual argument if the procedure's
3734 type is declared @code{CHARACTER*(*)}. For example:
3744 It isn't clear whether the standard considers this conforming.
3746 @node No Passing Dummy Assumed-length
3747 @subsection No Passing Dummy Assumed-length
3749 @code{g77} disallows passing of a dummy procedure
3750 as an actual argument if the procedure's
3751 type is declared @code{CHARACTER*(*)}.
3754 SUBROUTINE BAR(CFUNC)
3762 It isn't clear whether the standard considers this conforming.
3764 @node No Pathological Implied-DO
3765 @subsection No Pathological Implied-DO
3767 The @code{DO} variable for an implied-@code{DO} construct in a
3768 @code{DATA} statement may not be used as the @code{DO} variable
3769 for an outer implied-@code{DO} construct. For example, this
3770 fragment is disallowed by @code{g77}:
3773 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
3777 This also is disallowed by Fortran 90, as it offers no additional
3778 capabilities and would have a variety of possible meanings.
3780 Note that it is @emph{very} unlikely that any production Fortran code
3781 tries to use this unsupported construct.
3783 @node No Useless Implied-DO
3784 @subsection No Useless Implied-DO
3786 An array element initializer in an implied-@code{DO} construct in a
3787 @code{DATA} statement must contain at least one reference to the @code{DO}
3788 variables of each outer implied-@code{DO} construct. For example,
3789 this fragment is disallowed by @code{g77}:
3792 DATA (A, I= 1, 1) /1./
3796 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
3797 requirements offer no additional capabilities.
3798 However, @code{g77} doesn't necessarily diagnose all cases
3799 where this requirement is not met.
3801 Note that it is @emph{very} unlikely that any production Fortran code
3802 tries to use this unsupported construct.
3805 @section Conformance
3807 (The following information augments or overrides the information in
3808 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3810 Chapter 1 of that document otherwise serves as the basis
3811 for the relevant aspects of GNU Fortran.)
3813 The definition of the GNU Fortran language is akin to that of
3814 the ANSI FORTRAN 77 language in that it does not generally require
3815 conforming implementations to diagnose cases where programs do
3816 not conform to the language.
3818 However, @code{g77} as a compiler is being developed in a way that
3819 is intended to enable it to diagnose such cases in an easy-to-understand
3822 A program that conforms to the GNU Fortran language should, when
3823 compiled, linked, and executed using a properly installed @code{g77}
3824 system, perform as described by the GNU Fortran language definition.
3825 Reasons for different behavior include, among others:
3829 Use of resources (memory---heap, stack, and so on; disk space; CPU
3830 time; etc.) exceeds those of the system.
3833 Range and/or precision of calculations required by the program
3834 exceeds that of the system.
3837 Excessive reliance on behaviors that are system-dependent
3838 (non-portable Fortran code).
3841 Bugs in the program.
3850 Despite these ``loopholes'', the availability of a clear specification
3851 of the language of programs submitted to @code{g77}, as this document
3852 is intended to provide, is considered an important aspect of providing
3853 a robust, clean, predictable Fortran implementation.
3855 The definition of the GNU Fortran language, while having no special
3856 legal status, can therefore be viewed as a sort of contract, or agreement.
3857 This agreement says, in essence, ``if you write a program in this language,
3858 and run it in an environment (such as a @code{g77} system) that supports
3859 this language, the program should behave in a largely predictable way''.
3862 @section Notation Used in This Chapter
3864 (The following information augments or overrides the information in
3865 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3867 Chapter 1 of that document otherwise serves as the basis
3868 for the relevant aspects of GNU Fortran.)
3870 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
3871 and ``must not'' and ``may not'' denote prohibition.
3872 Terms such as ``might'', ``should'', and ``can'' generally add little or
3873 nothing in the way of weight to the GNU Fortran language itself,
3874 but are used to explain or illustrate the language.
3879 ``The @code{FROBNITZ} statement must precede all executable
3880 statements in a program unit, and may not specify any dummy
3881 arguments. It may specify local or common variables and arrays.
3882 Its use should be limited to portions of the program designed to
3883 be non-portable and system-specific, because it might cause the
3884 containing program unit to behave quite differently on different
3888 Insofar as the GNU Fortran language is specified,
3889 the requirements and permissions denoted by the above sample statement
3890 are limited to the placement of the statement and the kinds of
3891 things it may specify.
3892 The rest of the statement---the content regarding non-portable portions
3893 of the program and the differing behavior of program units containing
3894 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
3896 That content offers advice and warnings about the @code{FROBNITZ}
3899 @emph{Remember:} The GNU Fortran language definition specifies
3900 both what constitutes a valid GNU Fortran program and how,
3901 given such a program, a valid GNU Fortran implementation is
3902 to interpret that program.
3904 It is @emph{not} incumbent upon a valid GNU Fortran implementation
3905 to behave in any particular way, any consistent way, or any
3906 predictable way when it is asked to interpret input that is
3907 @emph{not} a valid GNU Fortran program.
3909 Such input is said to have @dfn{undefined} behavior when
3910 interpreted by a valid GNU Fortran implementation, though
3911 an implementation may choose to specify behaviors for some
3912 cases of inputs that are not valid GNU Fortran programs.
3914 Other notation used herein is that of the GNU texinfo format,
3915 which is used to generate printed hardcopy, on-line hypertext
3916 (Info), and on-line HTML versions, all from a single source
3918 This notation is used as follows:
3922 Keywords defined by the GNU Fortran language are shown
3923 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
3926 Note that, in practice, many Fortran programs are written
3927 in lowercase---uppercase is used in this manual as a
3928 means to readily distinguish keywords and sample Fortran-related
3929 text from the prose in this document.
3932 Portions of actual sample program, input, or output text
3933 look like this: @samp{Actual program text}.
3935 Generally, uppercase is used for all Fortran-specific and
3936 Fortran-related text, though this does not always include
3937 literal text within Fortran code.
3939 For example: @samp{PRINT *, 'My name is Bob'}.
3942 A metasyntactic variable---that is, a name used in this document
3943 to serve as a placeholder for whatever text is used by the
3944 user or programmer---appears as shown in the following example:
3946 ``The @code{INTEGER @var{ivar}} statement specifies that
3947 @var{ivar} is a variable or array of type @code{INTEGER}.''
3949 In the above example, any valid text may be substituted for
3950 the metasyntactic variable @var{ivar} to make the statement
3951 apply to a specific instance, as long as the same text is
3952 substituted for @emph{both} occurrences of @var{ivar}.
3955 Ellipses (``@dots{}'') are used to indicate further text that
3956 is either unimportant or expanded upon further, elsewhere.
3959 Names of data types are in the style of Fortran 90, in most
3962 @xref{Kind Notation}, for information on the relationship
3963 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
3964 and the more traditional, less portably concise nomenclature
3965 (such as @code{INTEGER*4}).
3968 @node Terms and Concepts
3969 @section Fortran Terms and Concepts
3971 (The following information augments or overrides the information in
3972 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3974 Chapter 2 of that document otherwise serves as the basis
3975 for the relevant aspects of GNU Fortran.)
3979 * Statements Comments Lines::
3980 * Scope of Names and Labels::
3983 @node Syntactic Items
3984 @subsection Syntactic Items
3986 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
3988 @cindex limits, lengths of names
3989 In GNU Fortran, a symbolic name is at least one character long,
3990 and has no arbitrary upper limit on length.
3991 However, names of entities requiring external linkage (such as
3992 external functions, external subroutines, and @code{COMMON} areas)
3993 might be restricted to some arbitrary length by the system.
3994 Such a restriction is no more constrained than that of one
3995 through six characters.
3997 Underscores (@samp{_}) are accepted in symbol names after the first
3998 character (which must be a letter).
4000 @node Statements Comments Lines
4001 @subsection Statements, Comments, and Lines
4003 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
4005 @cindex trailing comment
4007 @cindex characters, comment
4009 @cindex exclamation point
4010 @cindex continuation character
4011 @cindex characters, continuation
4012 Use of an exclamation point (@samp{!}) to begin a
4013 trailing comment (a comment that extends to the end of the same
4014 source line) is permitted under the following conditions:
4018 The exclamation point does not appear in column 6.
4019 Otherwise, it is treated as an indicator of a continuation
4023 The exclamation point appears outside a character or Hollerith
4025 Otherwise, the exclamation point is considered part of the
4029 The exclamation point appears to the left of any other possible
4031 That is, a trailing comment may contain exclamation points
4032 in their commentary text.
4037 @cindex statements, separated by semicolon
4038 Use of a semicolon (@samp{;}) as a statement separator
4039 is permitted under the following conditions:
4043 The semicolon appears outside a character or Hollerith
4045 Otherwise, the semicolon is considered part of the
4049 The semicolon appears to the left of a trailing comment.
4050 Otherwise, the semicolon is considered part of that
4054 Neither a logical @code{IF} statement nor a non-construct
4055 @code{WHERE} statement (a Fortran 90 feature) may be
4056 followed (in the same, possibly continued, line) by
4057 a semicolon used as a statement separator.
4059 This restriction avoids the confusion
4060 that can result when reading a line such as:
4063 IF (VALIDP) CALL FOO; CALL BAR
4067 Some readers might think the @samp{CALL BAR} is executed
4068 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4069 assume its execution is unconditional.
4071 (At present, @code{g77} does not diagnose code that
4072 violates this restriction.)
4075 @node Scope of Names and Labels
4076 @subsection Scope of Symbolic Names and Statement Labels
4079 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4081 Included in the list of entities that have a scope of a
4082 program unit are construct names (a Fortran 90 feature).
4083 @xref{Construct Names}, for more information.
4085 @node Characters Lines Sequence
4086 @section Characters, Lines, and Execution Sequence
4088 (The following information augments or overrides the information in
4089 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4091 Chapter 3 of that document otherwise serves as the basis
4092 for the relevant aspects of GNU Fortran.)
4097 * Continuation Line::
4099 * Statement Labels::
4102 * Cpp-style directives::
4106 @subsection GNU Fortran Character Set
4109 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4111 Letters include uppercase letters (the twenty-six characters
4112 of the English alphabet) and lowercase letters (their lowercase
4114 Generally, lowercase letters may be used in place of uppercase
4115 letters, though in character and Hollerith constants, they
4118 Special characters include:
4124 Semicolon (@samp{;})
4128 @cindex exclamation point
4129 Exclamation point (@samp{!})
4133 @cindex double quote
4134 Double quote (@samp{"})
4139 Backslash (@samp{\})
4143 @cindex question mark
4144 Question mark (@samp{?})
4150 Hash mark (@samp{#})
4155 Ampersand (@samp{&})
4159 @cindex percent sign
4160 Percent sign (@samp{%})
4165 Underscore (@samp{_})
4171 @cindex open bracket
4172 @cindex left bracket
4173 Open angle (@samp{<})
4179 @cindex close bracket
4180 @cindex right bracket
4181 Close angle (@samp{>})
4184 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4185 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4186 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4193 Note that this document refers to @key{SPC} as @dfn{space},
4194 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4199 @cindex source file format
4200 @cindex source format
4201 @cindex file, source
4203 @cindex code, source
4207 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4209 The way a Fortran compiler views source files depends entirely on the
4210 implementation choices made for the compiler, since those choices
4211 are explicitly left to the implementation by the published Fortran
4214 The GNU Fortran language mandates a view applicable to UNIX-like
4215 text files---files that are made up of an arbitrary number of lines,
4216 each with an arbitrary number of characters (sometimes called stream-based
4219 This view does not apply to types of files that are specified as
4220 having a particular number of characters on every single line (sometimes
4221 referred to as record-based files).
4223 Because a ``line in a program unit is a sequence of 72 characters'',
4224 to quote X3.9-1978, the GNU Fortran language specifies that a
4225 stream-based text file is translated to GNU Fortran lines as follows:
4229 A newline in the file is the character that represents the end of
4230 a line of text to the underlying system.
4231 For example, on ASCII-based systems, a newline is the @key{NL}
4232 character, which has ASCII value 12 (decimal).
4235 Each newline in the file serves to end the line of text that precedes
4236 it (and that does not contain a newline).
4239 The end-of-file marker (@code{EOF}) also serves to end the line
4240 of text that precedes it (and that does not contain a newline).
4246 Any line of text that is shorter than 72 characters is padded to that length
4247 with spaces (called ``blanks'' in the standard).
4250 Any line of text that is longer than 72 characters is truncated to that
4251 length, but the truncated remainder must consist entirely of spaces.
4254 Characters other than newline and the GNU Fortran character set
4258 For the purposes of the remainder of this description of the GNU
4259 Fortran language, the translation described above has already
4260 taken place, unless otherwise specified.
4262 The result of the above translation is that the source file appears,
4263 in terms of the remainder of this description of the GNU Fortran language,
4264 as if it had an arbitrary
4265 number of 72-character lines, each character being among the GNU Fortran
4268 For example, if the source file itself has two newlines in a row,
4269 the second newline becomes, after the above translation, a single
4270 line containing 72 spaces.
4272 @node Continuation Line
4273 @subsection Continuation Line
4274 @cindex continuation line, number of
4275 @cindex lines, continuation
4276 @cindex number of continuation lines
4277 @cindex limits, continuation lines
4279 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4281 A continuation line is any line that both
4285 Contains a continuation character, and
4288 Contains only spaces in columns 1 through 5
4291 A continuation character is any character of the GNU Fortran character set
4292 other than space (@key{SPC}) or zero (@samp{0})
4293 in column 6, or a digit (@samp{0} through @samp{9}) in column
4294 7 through 72 of a line that has only spaces to the left of that
4297 The continuation character is ignored as far as the content of
4298 the statement is concerned.
4300 The GNU Fortran language places no limit on the number of
4301 continuation lines in a statement.
4302 In practice, the limit depends on a variety of factors, such as
4303 available memory, statement content, and so on, but no
4304 GNU Fortran system may impose an arbitrary limit.
4307 @subsection Statements
4309 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4311 Statements may be written using an arbitrary number of continuation
4314 Statements may be separated using the semicolon (@samp{;}), except
4315 that the logical @code{IF} and non-construct @code{WHERE} statements
4316 may not be separated from subsequent statements using only a semicolon
4317 as statement separator.
4319 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4320 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4322 These alternatives may be written as normal statements---they are not
4323 subject to the restrictions of the @code{END} statement.
4325 However, no statement other than @code{END} may have an initial line
4326 that appears to be an @code{END} statement---even @code{END PROGRAM},
4327 for example, must not be written as:
4334 @node Statement Labels
4335 @subsection Statement Labels
4337 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4339 A statement separated from its predecessor via a semicolon may be
4344 The semicolon is followed by the label for the statement,
4345 which in turn follows the label.
4348 The label must be no more than five digits in length.
4351 The first digit of the label for the statement is not
4352 the first non-space character on a line.
4353 Otherwise, that character is treated as a continuation
4357 A statement may have only one label defined for it.
4360 @subsection Order of Statements and Lines
4362 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4364 Generally, @code{DATA} statements may precede executable statements.
4365 However, specification statements pertaining to any entities
4366 initialized by a @code{DATA} statement must precede that @code{DATA}
4369 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4370 @samp{INTEGER J} is permitted.
4372 The last line of a program unit may be an @code{END} statement,
4377 An @code{END PROGRAM} statement, if the program unit is a main program.
4380 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4383 An @code{END FUNCTION} statement, if the program unit is a function.
4386 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4390 @subsection Including Source Text
4391 @cindex INCLUDE directive
4393 Additional source text may be included in the processing of
4394 the source file via the @code{INCLUDE} directive:
4397 INCLUDE @var{filename}
4401 The source text to be included is identified by @var{filename},
4402 which is a literal GNU Fortran character constant.
4403 The meaning and interpretation of @var{filename} depends on the
4404 implementation, but typically is a filename.
4406 (@code{g77} treats it as a filename that it searches for
4407 in the current directory and/or directories specified
4408 via the @samp{-I} command-line option.)
4410 The effect of the @code{INCLUDE} directive is as if the
4411 included text directly replaced the directive in the source
4412 file prior to interpretation of the program.
4413 Included text may itself use @code{INCLUDE}.
4414 The depth of nested @code{INCLUDE} references depends on
4415 the implementation, but typically is a positive integer.
4417 This virtual replacement treats the statements and @code{INCLUDE}
4418 directives in the included text as syntactically distinct from
4419 those in the including text.
4421 Therefore, the first non-comment line of the included text
4422 must not be a continuation line.
4423 The included text must therefore have, after the non-comment
4424 lines, either an initial line (statement), an @code{INCLUDE}
4425 directive, or nothing (the end of the included text).
4427 Similarly, the including text may end the @code{INCLUDE}
4428 directive with a semicolon or the end of the line, but it
4429 cannot follow an @code{INCLUDE} directive at the end of its
4430 line with a continuation line.
4431 Thus, the last statement in an included text may not be
4434 Any statements between two @code{INCLUDE} directives on the
4435 same line are treated as if they appeared in between the
4436 respective included texts.
4440 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4444 If the text included by @samp{INCLUDE 'A'} constitutes
4445 a @samp{PRINT *, 'A'} statement and the text included by
4446 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4447 then the output of the above sample program would be
4456 (with suitable allowances for how an implementation defines
4457 its handling of output).
4459 Included text must not include itself directly or indirectly,
4460 regardless of whether the @var{filename} used to reference
4461 the text is the same.
4463 Note that @code{INCLUDE} is @emph{not} a statement.
4464 As such, it is neither a non-executable or executable
4466 However, if the text it includes constitutes one or more
4467 executable statements, then the placement of @code{INCLUDE}
4468 is subject to effectively the same restrictions as those
4469 on executable statements.
4471 An @code{INCLUDE} directive may be continued across multiple
4472 lines as if it were a statement.
4473 This permits long names to be used for @var{filename}.
4475 @node Cpp-style directives
4476 @subsection Cpp-style directives
4478 @cindex preprocessor
4480 @code{cpp} output-style @code{#} directives @xref{C Preprocessor
4481 Output,,, cpp, The C Preprocessor}, are recognized by the compiler even
4482 when the preprocessor isn't run on the input (as it is when compiling
4483 @samp{.F} files). (Note the distinction between these @code{cpp}
4484 @code{#} @emph{output} directives and @code{#line} @emph{input}
4487 @node Data Types and Constants
4488 @section Data Types and Constants
4490 (The following information augments or overrides the information in
4491 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4493 Chapter 4 of that document otherwise serves as the basis
4494 for the relevant aspects of GNU Fortran.)
4496 To more concisely express the appropriate types for
4497 entities, this document uses the more concise
4498 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
4499 instead of the more traditional, but less portably concise,
4500 byte-size-based nomenclature such as @code{INTEGER*4},
4501 wherever reasonable.
4503 When referring to generic types---in contexts where the
4504 specific precision and range of a type are not important---this
4505 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
4506 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
4508 In some cases, the context requires specification of a
4510 This document uses the @samp{KIND=} notation to accomplish
4511 this throughout, sometimes supplying the more traditional
4512 notation for clarification, though the traditional notation
4513 might not work the same way on all GNU Fortran implementations.
4515 Use of @samp{KIND=} makes this document more concise because
4516 @code{g77} is able to define values for @samp{KIND=} that
4517 have the same meanings on all systems, due to the way the
4518 Fortran 90 standard specifies these values are to be used.
4520 (In particular, that standard permits an implementation to
4521 arbitrarily assign nonnegative values.
4522 There are four distinct sets of assignments: one to the @code{CHARACTER}
4523 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
4524 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
4525 Implementations are free to assign these values in any order,
4526 leave gaps in the ordering of assignments, and assign more than
4527 one value to a representation.)
4529 This makes @samp{KIND=} values superior to the values used
4530 in non-standard statements such as @samp{INTEGER*4}, because
4531 the meanings of the values in those statements vary from machine
4532 to machine, compiler to compiler, even operating system to
4535 However, use of @samp{KIND=} is @emph{not} generally recommended
4536 when writing portable code (unless, for example, the code is
4537 going to be compiled only via @code{g77}, which is a widely
4539 GNU Fortran does not yet have adequate language constructs to
4540 permit use of @samp{KIND=} in a fashion that would make the
4541 code portable to Fortran 90 implementations; and, this construct
4542 is known to @emph{not} be accepted by many popular FORTRAN 77
4543 implementations, so it cannot be used in code that is to be ported
4546 The distinction here is that this document is able to use
4547 specific values for @samp{KIND=} to concisely document the
4548 types of various operations and operands.
4550 A Fortran program should use the FORTRAN 77 designations for the
4551 appropriate GNU Fortran types---such as @code{INTEGER} for
4552 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
4553 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
4554 where no such designations exist, make use of appropriate
4555 techniques (preprocessor macros, parameters, and so on)
4556 to specify the types in a fashion that may be easily adjusted
4557 to suit each particular implementation to which the program
4559 (These types generally won't need to be adjusted for ports of
4562 Further details regarding GNU Fortran data types and constants
4573 @subsection Data Types
4575 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
4577 GNU Fortran supports these types:
4581 Integer (generic type @code{INTEGER})
4584 Real (generic type @code{REAL})
4590 Complex (generic type @code{COMPLEX})
4593 Logical (generic type @code{LOGICAL})
4596 Character (generic type @code{CHARACTER})
4602 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
4604 The generic types shown above are referred to in this document
4605 using only their generic type names.
4606 Such references usually indicate that any specific type (kind)
4607 of that generic type is valid.
4609 For example, a context described in this document as accepting
4610 the @code{COMPLEX} type also is likely to accept the
4611 @code{DOUBLE COMPLEX} type.
4613 The GNU Fortran language supports three ways to specify
4614 a specific kind of a generic type.
4617 * Double Notation:: As in @code{DOUBLE COMPLEX}.
4618 * Star Notation:: As in @code{INTEGER*4}.
4619 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
4622 @node Double Notation
4623 @subsubsection Double Notation
4625 The GNU Fortran language supports two uses of the keyword
4626 @code{DOUBLE} to specify a specific kind of type:
4630 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
4633 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
4636 Use one of the above forms where a type name is valid.
4638 While use of this notation is popular, it doesn't scale
4639 well in a language or dialect rich in intrinsic types,
4640 as is the case for the GNU Fortran language (especially
4641 planned future versions of it).
4643 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
4644 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
4645 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
4646 often are substituted for these, respectively, even though they
4647 do not always have the same meanings on all systems.
4648 (And, the fact that @samp{DOUBLE REAL} does not exist as such
4649 is an inconsistency.)
4651 Therefore, this document uses ``double notation'' only on occasion
4652 for the benefit of those readers who are accustomed to it.
4655 @subsubsection Star Notation
4656 @cindex *@var{n} notation
4658 The following notation specifies the storage size for a type:
4661 @var{generic-type}*@var{n}
4665 @var{generic-type} must be a generic type---one of
4666 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4667 or @code{CHARACTER}.
4668 @var{n} must be one or more digits comprising a decimal
4669 integer number greater than zero.
4671 Use the above form where a type name is valid.
4673 The @samp{*@var{n}} notation specifies that the amount of storage
4674 occupied by variables and array elements of that type is @var{n}
4675 times the storage occupied by a @code{CHARACTER*1} variable.
4677 This notation might indicate a different degree of precision and/or
4678 range for such variables and array elements, and the functions that
4679 return values of types using this notation.
4680 It does not limit the precision or range of values of that type
4681 in any particular way---use explicit code to do that.
4683 Further, the GNU Fortran language requires no particular values
4684 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
4686 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
4687 on all systems, for example,
4688 but not all implementations are required to do so, and @code{g77}
4689 is known to not support @code{REAL*1} on most (or all) systems.
4691 As a result, except for @var{generic-type} of @code{CHARACTER},
4692 uses of this notation should be limited to isolated
4693 portions of a program that are intended to handle system-specific
4694 tasks and are expected to be non-portable.
4696 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
4697 only @code{CHARACTER}, where it signifies not only the amount
4698 of storage occupied, but the number of characters in entities
4700 However, almost all Fortran compilers have supported this
4701 notation for generic types, though with a variety of meanings
4704 Specifications of types using the @samp{*@var{n}} notation
4705 always are interpreted as specifications of the appropriate
4706 types described in this document using the @samp{KIND=@var{n}}
4707 notation, described below.
4709 While use of this notation is popular, it doesn't serve well
4710 in the context of a widely portable dialect of Fortran, such as
4711 the GNU Fortran language.
4713 For example, even on one particular machine, two or more popular
4714 Fortran compilers might well disagree on the size of a type
4715 declared @code{INTEGER*2} or @code{REAL*16}.
4717 is known to be disagreement over such things among Fortran
4718 compilers on @emph{different} systems.
4720 Further, this notation offers no elegant way to specify sizes
4721 that are not even multiples of the ``byte size'' typically
4722 designated by @code{INTEGER*1}.
4723 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
4724 certainly be possible, but would perhaps be stretching the original
4725 intent of this notation beyond the breaking point in terms
4726 of widespread readability of documentation and code making use
4729 Therefore, this document uses ``star notation'' only on occasion
4730 for the benefit of those readers who are accustomed to it.
4733 @subsubsection Kind Notation
4734 @cindex KIND= notation
4736 The following notation specifies the kind-type selector of a type:
4739 @var{generic-type}(KIND=@var{n})
4743 Use the above form where a type name is valid.
4745 @var{generic-type} must be a generic type---one of
4746 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4747 or @code{CHARACTER}.
4748 @var{n} must be an integer initialization expression that
4749 is a positive, nonzero value.
4751 Programmers are discouraged from writing these values directly
4753 Future versions of the GNU Fortran language will offer
4754 facilities that will make the writing of code portable
4755 to @code{g77} @emph{and} Fortran 90 implementations simpler.
4757 However, writing code that ports to existing FORTRAN 77
4758 implementations depends on avoiding the @samp{KIND=} construct.
4760 The @samp{KIND=} construct is thus useful in the context
4761 of GNU Fortran for two reasons:
4765 It provides a means to specify a type in a fashion that
4766 is portable across all GNU Fortran implementations (though
4767 not other FORTRAN 77 and Fortran 90 implementations).
4770 It provides a sort of Rosetta stone for this document to use
4771 to concisely describe the types of various operations and
4775 The values of @var{n} in the GNU Fortran language are
4776 assigned using a scheme that:
4780 Attempts to maximize the ability of readers
4781 of this document to quickly familiarize themselves
4782 with assignments for popular types
4785 Provides a unique value for each specific desired
4789 Provides a means to automatically assign new values so
4790 they have a ``natural'' relationship to existing values,
4791 if appropriate, or, if no such relationship exists, will
4792 not interfere with future values assigned on the basis
4793 of such relationships
4796 Avoids using values that are similar to values used
4797 in the existing, popular @samp{*@var{n}} notation,
4798 to prevent readers from expecting that these implied
4799 correspondences work on all GNU Fortran implementations
4802 The assignment system accomplishes this by assigning
4803 to each ``fundamental meaning'' of a specific type a
4804 unique prime number.
4805 Combinations of fundamental meanings---for example, a type
4806 that is two times the size of some other type---are assigned
4807 values of @var{n} that are the products of the values for
4808 those fundamental meanings.
4810 A prime value of @var{n} is never given more than one fundamental
4811 meaning, to avoid situations where some code or system
4812 cannot reasonably provide those meanings in the form of a
4815 The values of @var{n} assigned so far are:
4819 This value is reserved for future use.
4821 The planned future use is for this value to designate,
4822 explicitly, context-sensitive kind-type selection.
4823 For example, the expression @samp{1D0 * 0.1_0} would
4824 be equivalent to @samp{1D0 * 0.1D0}.
4827 This corresponds to the default types for
4828 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
4829 and @code{CHARACTER}, as appropriate.
4831 These are the ``default'' types described in the Fortran 90 standard,
4832 though that standard does not assign any particular @samp{KIND=}
4833 value to these types.
4835 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
4836 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
4839 This corresponds to types that occupy twice as much
4840 storage as the default types.
4841 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
4842 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
4844 These are the ``double precision'' types described in the Fortran 90
4846 though that standard does not assign any particular @samp{KIND=}
4847 value to these types.
4849 @var{n} of 4 thus corresponds to types that occupy four times
4850 as much storage as the default types, @var{n} of 8 to types that
4851 occupy eight times as much storage, and so on.
4853 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
4854 are not necessarily supported by every GNU Fortran implementation.
4857 This corresponds to types that occupy as much
4858 storage as the default @code{CHARACTER} type,
4859 which is the same effective type as @code{CHARACTER(KIND=1)}
4860 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
4862 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
4864 @var{n} of 6 thus corresponds to types that occupy twice as
4865 much storage as the @var{n}=3 types, @var{n} of 12 to types
4866 that occupy four times as much storage, and so on.
4868 These are not necessarily supported by every GNU Fortran
4872 This corresponds to types that occupy half the
4873 storage as the default (@var{n}=1) types.
4875 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
4877 @var{n} of 25 thus corresponds to types that occupy one-quarter
4878 as much storage as the default types.
4880 These are not necessarily supported by every GNU Fortran
4885 This is valid only as @code{INTEGER(KIND=7)} and
4886 denotes the @code{INTEGER} type that has the smallest
4887 storage size that holds a pointer on the system.
4889 A pointer representable by this type is capable of uniquely
4890 addressing a @code{CHARACTER*1} variable, array, array element,
4893 (Typically this is equivalent to @code{INTEGER*4} or,
4894 on 64-bit systems, @code{INTEGER*8}.
4895 In a compatible C implementation, it typically would
4896 be the same size and semantics of the C type @code{void *}.)
4899 Note that these are @emph{proposed} correspondences and might change
4900 in future versions of @code{g77}---avoid writing code depending
4901 on them while @code{g77}, and therefore the GNU Fortran language
4902 it defines, is in beta testing.
4904 Values not specified in the above list are reserved to
4905 future versions of the GNU Fortran language.
4907 Implementation-dependent meanings will be assigned new,
4908 unique prime numbers so as to not interfere with other
4909 implementation-dependent meanings, and offer the possibility
4910 of increasing the portability of code depending on such
4911 types by offering support for them in other GNU Fortran
4914 Other meanings that might be given unique values are:
4918 Types that make use of only half their storage size for
4919 representing precision and range.
4921 For example, some compilers offer options that cause
4922 @code{INTEGER} types to occupy the amount of storage
4923 that would be needed for @code{INTEGER(KIND=2)} types, but the
4924 range remains that of @code{INTEGER(KIND=1)}.
4927 The IEEE single floating-point type.
4930 Types with a specific bit pattern (endianness), such as the
4931 little-endian form of @code{INTEGER(KIND=1)}.
4932 These could permit, conceptually, use of portable code and
4933 implementations on data files written by existing systems.
4936 Future @emph{prime} numbers should be given meanings in as incremental
4937 a fashion as possible, to allow for flexibility and
4938 expressiveness in combining types.
4940 For example, instead of defining a prime number for little-endian
4941 IEEE doubles, one prime number might be assigned the meaning
4942 ``little-endian'', another the meaning ``IEEE double'', and the
4943 value of @var{n} for a little-endian IEEE double would thus
4944 naturally be the product of those two respective assigned values.
4945 (It could even be reasonable to have IEEE values result from the
4946 products of prime values denoting exponent and fraction sizes
4947 and meanings, hidden bit usage, availability and representations
4948 of special values such as subnormals, infinities, and Not-A-Numbers
4951 This assignment mechanism, while not inherently required for
4952 future versions of the GNU Fortran language, is worth using
4953 because it could ease management of the ``space'' of supported
4954 types much easier in the long run.
4956 The above approach suggests a mechanism for specifying inheritance
4957 of intrinsic (built-in) types for an entire, widely portable
4959 It is certainly reasonable that, unlike programmers of other languages
4960 offering inheritance mechanisms that employ verbose names for classes
4961 and subclasses, along with graphical browsers to elucidate the
4962 relationships, Fortran programmers would employ
4963 a mechanism that works by multiplying prime numbers together
4964 and finding the prime factors of such products.
4966 Most of the advantages for the above scheme have been explained
4968 One disadvantage is that it could lead to the defining,
4969 by the GNU Fortran language, of some fairly large prime numbers.
4970 This could lead to the GNU Fortran language being declared
4971 ``munitions'' by the United States Department of Defense.
4974 @subsection Constants
4976 @cindex types, constants
4978 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
4980 A @dfn{typeless constant} has one of the following forms:
4983 '@var{binary-digits}'B
4984 '@var{octal-digits}'O
4985 '@var{hexadecimal-digits}'Z
4986 '@var{hexadecimal-digits}'X
4990 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
4991 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
4992 and @samp{0123456789ABCDEFabcdef}, respectively.
4993 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
4996 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
4997 treated as typeless. @xref{Fortran Dialect Options,, Options
4998 Controlling Fortran Dialect}, for information on the
4999 @samp{-ftypeless-boz} option.
5001 Typeless constants have values that depend on the context in which
5004 All other constants, called @dfn{typed constants}, are interpreted---converted
5005 to internal form---according to their inherent type.
5006 Thus, context is @emph{never} a determining factor for the type, and hence
5007 the interpretation, of a typed constant.
5008 (All constants in the ANSI FORTRAN 77 language are typed constants.)
5010 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
5011 Fortran (called default INTEGER in Fortran 90),
5012 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
5013 additional precision specified is lost, and even when used in a
5014 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
5015 and @samp{1D0} is always type @code{REAL(KIND=2)}.
5018 @subsection Integer Type
5020 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
5022 An integer constant also may have one of the following forms:
5025 B'@var{binary-digits}'
5026 O'@var{octal-digits}'
5027 Z'@var{hexadecimal-digits}'
5028 X'@var{hexadecimal-digits}'
5032 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5033 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5034 and @samp{0123456789ABCDEFabcdef}, respectively.
5035 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5038 @node Character Type
5039 @subsection Character Type
5041 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
5043 @cindex double quoted character constants
5044 A character constant may be delimited by a pair of double quotes
5045 (@samp{"}) instead of apostrophes.
5046 In this case, an apostrophe within the constant represents
5047 a single apostrophe, while a double quote is represented in
5048 the source text of the constant by two consecutive double
5049 quotes with no intervening spaces.
5051 @cindex zero-length CHARACTER
5052 @cindex null CHARACTER strings
5053 @cindex empty CHARACTER strings
5054 @cindex strings, empty
5055 @cindex CHARACTER, null
5056 A character constant may be empty (have a length of zero).
5058 A character constant may include a substring specification,
5059 The value of such a constant is the value of the substring---for
5060 example, the value of @samp{'hello'(3:5)} is the same
5061 as the value of @samp{'llo'}.
5064 @section Expressions
5066 (The following information augments or overrides the information in
5067 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5069 Chapter 6 of that document otherwise serves as the basis
5070 for the relevant aspects of GNU Fortran.)
5077 @subsection The @code{%LOC()} Construct
5078 @cindex %LOC() construct
5084 The @code{%LOC()} construct is an expression
5085 that yields the value of the location of its argument,
5086 @var{arg}, in memory.
5087 The size of the type of the expression depends on the system---typically,
5088 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5089 though it is actually type @code{INTEGER(KIND=7)}.
5091 The argument to @code{%LOC()} must be suitable as the
5092 left-hand side of an assignment statement.
5093 That is, it may not be a general expression involving
5094 operators such as addition, subtraction, and so on,
5095 nor may it be a constant.
5097 Use of @code{%LOC()} is recommended only for code that
5098 is accessing facilities outside of GNU Fortran, such as
5099 operating system or windowing facilities.
5100 It is best to constrain such uses to isolated portions of
5101 a program---portions that deal specifically and exclusively
5102 with low-level, system-dependent facilities.
5103 Such portions might well provide a portable interface for
5104 use by the program as a whole, but are themselves not
5105 portable, and should be thoroughly tested each time they
5106 are rebuilt using a new compiler or version of a compiler.
5108 Do not depend on @code{%LOC()} returning a pointer that
5109 can be safely used to @emph{define} (change) the argument.
5110 While this might work in some circumstances, it is hard
5111 to predict whether it will continue to work when a program
5112 (that works using this unsafe behavior)
5113 is recompiled using different command-line options or
5114 a different version of @code{g77}.
5116 Generally, @code{%LOC()} is safe when used as an argument
5117 to a procedure that makes use of the value of the corresponding
5118 dummy argument only during its activation, and only when
5119 such use is restricted to referencing (reading) the value
5120 of the argument to @code{%LOC()}.
5122 @emph{Implementation Note:} Currently, @code{g77} passes
5123 arguments (those not passed using a construct such as @code{%VAL()})
5124 by reference or descriptor, depending on the type of
5125 the actual argument.
5126 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5127 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5128 in fact might compile to identical code.
5130 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5131 ``pass, by value, the address of @samp{I} in memory''.
5132 While @samp{CALL FOO(I)} might use that same approach in a
5133 particular version of @code{g77}, another version or compiler
5134 might choose a different implementation, such as copy-in/copy-out,
5135 to effect the desired behavior---and which will therefore not
5136 necessarily compile to the same code as would
5137 @samp{CALL FOO(%VAL(%LOC(I)))}
5138 using the same version or compiler.
5140 @xref{Debugging and Interfacing}, for detailed information on
5141 how this particular version of @code{g77} implements various
5144 @node Specification Statements
5145 @section Specification Statements
5147 (The following information augments or overrides the information in
5148 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5150 Chapter 8 of that document otherwise serves as the basis
5151 for the relevant aspects of GNU Fortran.)
5159 @subsection @code{NAMELIST} Statement
5160 @cindex NAMELIST statement
5161 @cindex statements, NAMELIST
5163 The @code{NAMELIST} statement, and related I/O constructs, are
5164 supported by the GNU Fortran language in essentially the same
5165 way as they are by @code{f2c}.
5167 This follows Fortran 90 with the restriction that on @code{NAMELIST}
5168 input, subscripts must have the form
5170 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
5174 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
5176 is allowed, but not, say,
5178 &xx x(:3,8::2)=1,2,3,4,5,6/
5181 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
5182 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
5184 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
5186 could be used instead of the example above.
5188 @node DOUBLE COMPLEX
5189 @subsection @code{DOUBLE COMPLEX} Statement
5190 @cindex DOUBLE COMPLEX
5192 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5193 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5195 @node Control Statements
5196 @section Control Statements
5198 (The following information augments or overrides the information in
5199 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5201 Chapter 11 of that document otherwise serves as the basis
5202 for the relevant aspects of GNU Fortran.)
5212 @subsection DO WHILE
5215 @cindex MIL-STD 1753
5217 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5218 Fortran 90 standards, is provided by the GNU Fortran language.
5219 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
5225 @cindex MIL-STD 1753
5227 The @code{END DO} statement is provided by the GNU Fortran language.
5229 This statement is used in one of two ways:
5233 The Fortran 90 meaning, in which it specifies the termination
5234 point of a single @code{DO} loop started with a @code{DO} statement
5235 that specifies no termination label.
5238 The MIL-STD 1753 meaning, in which it specifies the termination
5239 point of one or more @code{DO} loops, all of which start with a
5240 @code{DO} statement that specify the label defined for the
5241 @code{END DO} statement.
5243 This kind of @code{END DO} statement is merely a synonym for
5244 @code{CONTINUE}, except it is permitted only when the statement
5245 is labeled and a target of one or more labeled @code{DO} loops.
5247 It is expected that this use of @code{END DO} will be removed from
5248 the GNU Fortran language in the future, though it is likely that
5249 it will long be supported by @code{g77} as a dialect form.
5252 @node Construct Names
5253 @subsection Construct Names
5254 @cindex construct names
5256 The GNU Fortran language supports construct names as defined
5257 by the Fortran 90 standard.
5258 These names are local to the program unit and are defined
5262 @var{construct-name}: @var{block-statement}
5266 Here, @var{construct-name} is the construct name itself;
5267 its definition is connoted by the single colon (@samp{:}); and
5268 @var{block-statement} is an @code{IF}, @code{DO},
5269 or @code{SELECT CASE} statement that begins a block.
5271 A block that is given a construct name must also specify the
5272 same construct name in its termination statement:
5275 END @var{block} @var{construct-name}
5279 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5282 @node CYCLE and EXIT
5283 @subsection The @code{CYCLE} and @code{EXIT} Statements
5285 @cindex CYCLE statement
5286 @cindex EXIT statement
5287 @cindex statements, CYCLE
5288 @cindex statements, EXIT
5289 The @code{CYCLE} and @code{EXIT} statements specify that
5290 the remaining statements in the current iteration of a
5291 particular active (enclosing) @code{DO} loop are to be skipped.
5293 @code{CYCLE} specifies that these statements are skipped,
5294 but the @code{END DO} statement that marks the end of the
5295 @code{DO} loop be executed---that is, the next iteration,
5296 if any, is to be started.
5297 If the statement marking the end of the @code{DO} loop is
5298 not @code{END DO}---in other words, if the loop is not
5299 a block @code{DO}---the @code{CYCLE} statement does not
5300 execute that statement, but does start the next iteration (if any).
5302 @code{EXIT} specifies that the loop specified by the
5303 @code{DO} construct is terminated.
5305 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5306 is the innermost enclosing @code{DO} loop when the following
5314 Otherwise, the following forms specify the construct name
5315 of the pertinent @code{DO} loop:
5318 CYCLE @var{construct-name}
5319 EXIT @var{construct-name}
5322 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5324 However, they cannot be easily thought of as @code{GO TO} statements
5325 in obscure cases involving FORTRAN 77 loops.
5334 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5339 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5340 above are equivalent to a @code{GO TO} statement to either label
5341 @samp{10} or @samp{20}.
5343 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5344 above fragment, it is helpful to first translate it to its equivalent
5345 using only block @code{DO} loops:
5353 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5360 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5361 to @code{GO TO} so they may be more easily understood by programmers
5362 accustomed to FORTRAN coding:
5367 IF (J .EQ. 5) GOTO 18
5369 IF (K .EQ. 3) GO TO 12
5370 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5378 Thus, the @code{CYCLE} statement in the innermost loop skips over
5379 the @code{PRINT} statement as it begins the next iteration of the
5380 loop, while the @code{EXIT} statement in the middle loop ends that
5381 loop but @emph{not} the outermost loop.
5383 @node Functions and Subroutines
5384 @section Functions and Subroutines
5386 (The following information augments or overrides the information in
5387 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5389 Chapter 15 of that document otherwise serves as the basis
5390 for the relevant aspects of GNU Fortran.)
5396 * Generics and Specifics::
5397 * REAL() and AIMAG() of Complex::
5398 * CMPLX() of DOUBLE PRECISION::
5400 * f77/f2c Intrinsics::
5401 * Table of Intrinsic Functions::
5405 @subsection The @code{%VAL()} Construct
5406 @cindex %VAL() construct
5412 The @code{%VAL()} construct specifies that an argument,
5413 @var{arg}, is to be passed by value, instead of by reference
5416 @code{%VAL()} is restricted to actual arguments in
5417 invocations of external procedures.
5419 Use of @code{%VAL()} is recommended only for code that
5420 is accessing facilities outside of GNU Fortran, such as
5421 operating system or windowing facilities.
5422 It is best to constrain such uses to isolated portions of
5423 a program---portions the deal specifically and exclusively
5424 with low-level, system-dependent facilities.
5425 Such portions might well provide a portable interface for
5426 use by the program as a whole, but are themselves not
5427 portable, and should be thoroughly tested each time they
5428 are rebuilt using a new compiler or version of a compiler.
5430 @emph{Implementation Note:} Currently, @code{g77} passes
5431 all arguments either by reference or by descriptor.
5433 Thus, use of @code{%VAL()} tends to be restricted to cases
5434 where the called procedure is written in a language other
5435 than Fortran that supports call-by-value semantics.
5436 (C is an example of such a language.)
5438 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5439 for detailed information on
5440 how this particular version of @code{g77} passes arguments
5444 @subsection The @code{%REF()} Construct
5445 @cindex %REF() construct
5451 The @code{%REF()} construct specifies that an argument,
5452 @var{arg}, is to be passed by reference, instead of by
5453 value or descriptor.
5455 @code{%REF()} is restricted to actual arguments in
5456 invocations of external procedures.
5458 Use of @code{%REF()} is recommended only for code that
5459 is accessing facilities outside of GNU Fortran, such as
5460 operating system or windowing facilities.
5461 It is best to constrain such uses to isolated portions of
5462 a program---portions the deal specifically and exclusively
5463 with low-level, system-dependent facilities.
5464 Such portions might well provide a portable interface for
5465 use by the program as a whole, but are themselves not
5466 portable, and should be thoroughly tested each time they
5467 are rebuilt using a new compiler or version of a compiler.
5469 Do not depend on @code{%REF()} supplying a pointer to the
5470 procedure being invoked.
5471 While that is a likely implementation choice, other
5472 implementation choices are available that preserve Fortran
5473 pass-by-reference semantics without passing a pointer to
5474 the argument, @var{arg}.
5475 (For example, a copy-in/copy-out implementation.)
5477 @emph{Implementation Note:} Currently, @code{g77} passes
5479 (other than variables and arrays of type @code{CHARACTER})
5481 Future versions of, or dialects supported by, @code{g77} might
5482 not pass @code{CHARACTER} functions by reference.
5484 Thus, use of @code{%REF()} tends to be restricted to cases
5485 where @var{arg} is type @code{CHARACTER} but the called
5486 procedure accesses it via a means other than the method
5487 used for Fortran @code{CHARACTER} arguments.
5489 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5490 how this particular version of @code{g77} passes arguments
5494 @subsection The @code{%DESCR()} Construct
5495 @cindex %DESCR() construct
5501 The @code{%DESCR()} construct specifies that an argument,
5502 @var{arg}, is to be passed by descriptor, instead of by
5505 @code{%DESCR()} is restricted to actual arguments in
5506 invocations of external procedures.
5508 Use of @code{%DESCR()} is recommended only for code that
5509 is accessing facilities outside of GNU Fortran, such as
5510 operating system or windowing facilities.
5511 It is best to constrain such uses to isolated portions of
5512 a program---portions the deal specifically and exclusively
5513 with low-level, system-dependent facilities.
5514 Such portions might well provide a portable interface for
5515 use by the program as a whole, but are themselves not
5516 portable, and should be thoroughly tested each time they
5517 are rebuilt using a new compiler or version of a compiler.
5519 Do not depend on @code{%DESCR()} supplying a pointer
5520 and/or a length passed by value
5521 to the procedure being invoked.
5522 While that is a likely implementation choice, other
5523 implementation choices are available that preserve the
5524 pass-by-reference semantics without passing a pointer to
5525 the argument, @var{arg}.
5526 (For example, a copy-in/copy-out implementation.)
5527 And, future versions of @code{g77} might change the
5528 way descriptors are implemented, such as passing a
5529 single argument pointing to a record containing the
5530 pointer/length information instead of passing that same
5531 information via two arguments as it currently does.
5533 @emph{Implementation Note:} Currently, @code{g77} passes
5534 all variables and arrays of type @code{CHARACTER}
5536 Future versions of, or dialects supported by, @code{g77} might
5537 pass @code{CHARACTER} functions by descriptor as well.
5539 Thus, use of @code{%DESCR()} tends to be restricted to cases
5540 where @var{arg} is not type @code{CHARACTER} but the called
5541 procedure accesses it via a means similar to the method
5542 used for Fortran @code{CHARACTER} arguments.
5544 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5545 how this particular version of @code{g77} passes arguments
5548 @node Generics and Specifics
5549 @subsection Generics and Specifics
5550 @cindex generic intrinsics
5551 @cindex intrinsics, generic
5553 The ANSI FORTRAN 77 language defines generic and specific
5555 In short, the distinctions are:
5559 @emph{Specific} intrinsics have
5560 specific types for their arguments and a specific return
5564 @emph{Generic} intrinsics are treated,
5565 on a case-by-case basis in the program's source code,
5566 as one of several possible specific intrinsics.
5568 Typically, a generic intrinsic has a return type that
5569 is determined by the type of one or more of its arguments.
5572 The GNU Fortran language generalizes these concepts somewhat,
5573 especially by providing intrinsic subroutines and generic
5574 intrinsics that are treated as either a specific intrinsic subroutine
5575 or a specific intrinsic function (e.g. @code{SECOND}).
5577 However, GNU Fortran avoids generalizing this concept to
5578 the point where existing code would be accepted as meaning
5579 something possibly different than what was intended.
5581 For example, @code{ABS} is a generic intrinsic, so all working
5582 code written using @code{ABS} of an @code{INTEGER} argument
5583 expects an @code{INTEGER} return value.
5584 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
5585 argument returns an @code{INTEGER*2} return value.
5587 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
5588 an @code{INTEGER(KIND=1)} argument.
5589 Code that passes something other than an @code{INTEGER(KIND=1)}
5590 argument to @code{IABS} is not valid GNU Fortran code, because
5591 it is not clear what the author intended.
5593 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
5594 is not defined by the GNU Fortran language, because the programmer
5595 might have used that construct to mean any of the following, subtly
5600 Convert @samp{J} to @code{INTEGER(KIND=1)} first
5601 (as if @samp{IABS(INT(J))} had been written).
5604 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
5605 (as if @samp{INT(ABS(J))} had been written).
5608 No conversion (as if @samp{ABS(J)} had been written).
5611 The distinctions matter especially when types and values wider than
5612 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
5613 operations performing more ``arithmetic'' than absolute-value, are involved.
5615 The following sample program is not a valid GNU Fortran program, but
5616 might be accepted by other compilers.
5617 If so, the output is likely to be revealing in terms of how a given
5618 compiler treats intrinsics (that normally are specific) when they
5619 are given arguments that do not conform to their stated requirements:
5621 @cindex JCB002 program
5625 C Modified 1999-02-15 (Burley) to delete my email address.
5626 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
5627 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
5630 C Written by James Craig Burley 1997-02-20.
5633 C Determine how compilers handle non-standard IDIM
5634 C on INTEGER*2 operands, which presumably can be
5635 C extrapolated into understanding how the compiler
5636 C generally treats specific intrinsics that are passed
5637 C arguments not of the correct types.
5639 C If your compiler implements INTEGER*2 and INTEGER
5640 C as the same type, change all INTEGER*2 below to
5645 INTEGER*2 ISMALL, ILARGE
5646 INTEGER*2 ITOOLG, ITWO
5650 C Find smallest INTEGER*2 number.
5654 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
5659 C Find largest INTEGER*2 number.
5663 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
5668 C Multiplying by two adds stress to the situation.
5672 C Need a number that, added to -2, is too wide to fit in I*2.
5676 C Use IDIM the straightforward way.
5678 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
5680 C Calculate result for first interpretation.
5682 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
5684 C Calculate result for second interpretation.
5686 ITMP = ILARGE - ISMALL
5687 I3 = (INT (ITMP)) * ITWO + ITOOLG
5689 C Calculate result for third interpretation.
5691 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
5695 PRINT *, 'ILARGE=', ILARGE
5696 PRINT *, 'ITWO=', ITWO
5697 PRINT *, 'ITOOLG=', ITOOLG
5698 PRINT *, 'ISMALL=', ISMALL
5707 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
5708 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
5711 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
5712 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
5715 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
5716 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
5719 PRINT *, 'Results need careful analysis.'
5723 No future version of the GNU Fortran language
5724 will likely permit specific intrinsic invocations with wrong-typed
5725 arguments (such as @code{IDIM} in the above example), since
5726 it has been determined that disagreements exist among
5727 many production compilers on the interpretation of
5729 These disagreements strongly suggest that Fortran programmers,
5730 and certainly existing Fortran programs, disagree about the
5731 meaning of such invocations.
5733 The first version of @code{JCB002} didn't accommodate some compilers'
5734 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
5736 In such a case, these compilers apparently convert both
5737 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
5738 instead of doing an @code{INTEGER*2} subtraction on the
5739 original values in @samp{I1} and @samp{I2}.
5741 However, the results of the careful analyses done on the outputs
5742 of programs compiled by these various compilers show that they
5743 all implement either @samp{Interp 1} or @samp{Interp 2} above.
5745 Specifically, it is believed that the new version of @code{JCB002}
5746 above will confirm that:
5750 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
5751 @code{f77} compilers all implement @samp{Interp 1}.
5754 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
5757 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
5758 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
5761 If you get different results than the above for the stated
5762 compilers, or have results for other compilers that might be
5763 worth adding to the above list, please let us know the details
5764 (compiler product, version, machine, results, and so on).
5766 @node REAL() and AIMAG() of Complex
5767 @subsection @code{REAL()} and @code{AIMAG()} of Complex
5768 @cindex @code{Real} intrinsic
5769 @cindex intrinsics, @code{Real}
5770 @cindex @code{AImag} intrinsic
5771 @cindex intrinsics, @code{AImag}
5773 The GNU Fortran language disallows @code{REAL(@var{expr})}
5774 and @code{AIMAG(@var{expr})},
5775 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
5776 except when they are used in the following way:
5779 REAL(REAL(@var{expr}))
5780 REAL(AIMAG(@var{expr}))
5784 The above forms explicitly specify that the desired effect
5785 is to convert the real or imaginary part of @var{expr}, which might
5786 be some @code{REAL} type other than @code{REAL(KIND=1)},
5787 to type @code{REAL(KIND=1)},
5788 and have that serve as the value of the expression.
5790 The GNU Fortran language offers clearly named intrinsics to extract the
5791 real and imaginary parts of a complex entity without any
5795 REALPART(@var{expr})
5796 IMAGPART(@var{expr})
5799 To express the above using typical extended FORTRAN 77,
5800 use the following constructs
5801 (when @var{expr} is @code{COMPLEX(KIND=2)}):
5808 The FORTRAN 77 language offers no way
5809 to explicitly specify the real and imaginary parts of a complex expression of
5810 arbitrary type, apparently as a result of requiring support for
5811 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
5812 The concepts of converting an expression to type @code{REAL(KIND=1)} and
5813 of extracting the real part of a complex expression were
5814 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
5815 they happened to have the exact same effect in that language
5816 (due to having only one @code{COMPLEX} type).
5818 @emph{Note:} When @samp{-ff90} is in effect,
5819 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
5820 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
5821 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
5822 treated as @samp{REAL(REALPART(@var{expr}))}.
5824 @xref{Ugly Complex Part Extraction}, for more information.
5826 @node CMPLX() of DOUBLE PRECISION
5827 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
5828 @cindex @code{Cmplx} intrinsic
5829 @cindex intrinsics, @code{Cmplx}
5831 In accordance with Fortran 90 and at least some (perhaps all)
5832 other compilers, the GNU Fortran language defines @code{CMPLX()}
5833 as always returning a result that is type @code{COMPLEX(KIND=1)}.
5835 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
5836 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
5839 CMPLX(SNGL(D1), SNGL(D2))
5842 (It was necessary for Fortran 90 to specify this behavior
5843 for @code{DOUBLE PRECISION} arguments, since that is
5844 the behavior mandated by FORTRAN 77.)
5846 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
5847 which is provided by some FORTRAN 77 compilers to construct
5848 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
5850 However, this solution does not scale well when more @code{COMPLEX} types
5851 (having various precisions and ranges) are offered by Fortran implementations.
5853 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
5854 an extra argument used to specify the desired kind of complex
5856 However, this solution is somewhat awkward to use, and
5857 @code{g77} currently does not support it.
5859 The GNU Fortran language provides a simple way to build a complex
5860 value out of two numbers, with the precise type of the value
5861 determined by the types of the two numbers (via the usual
5862 type-promotion mechanism):
5865 COMPLEX(@var{real}, @var{imag})
5868 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
5869 performs no conversion other than to put them together to form a
5870 complex result of the same (complex version of real) type.
5872 @xref{Complex Intrinsic}, for more information.
5875 @subsection MIL-STD 1753 Support
5876 @cindex MIL-STD 1753
5878 The GNU Fortran language includes the MIL-STD 1753 intrinsics
5879 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
5880 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
5881 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
5883 @node f77/f2c Intrinsics
5884 @subsection @code{f77}/@code{f2c} Intrinsics
5886 The bit-manipulation intrinsics supported by traditional
5887 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
5888 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
5891 Also supported are the intrinsics @code{CDABS},
5892 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
5893 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
5894 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
5895 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
5898 @node Table of Intrinsic Functions
5899 @subsection Table of Intrinsic Functions
5900 @cindex intrinsics, table of
5901 @cindex table of intrinsics
5903 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
5905 The GNU Fortran language adds various functions, subroutines, types,
5906 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
5907 The complete set of intrinsics supported by the GNU Fortran language
5910 Note that a name is not treated as that of an intrinsic if it is
5911 specified in an @code{EXTERNAL} statement in the same program unit;
5912 if a command-line option is used to disable the groups to which
5913 the intrinsic belongs; or if the intrinsic is not named in an
5914 @code{INTRINSIC} statement and a command-line option is used to
5915 hide the groups to which the intrinsic belongs.
5917 So, it is recommended that any reference in a program unit to
5918 an intrinsic procedure that is not a standard FORTRAN 77
5919 intrinsic be accompanied by an appropriate @code{INTRINSIC}
5920 statement in that program unit.
5921 This sort of defensive programming makes it more
5922 likely that an implementation will issue a diagnostic rather
5923 than generate incorrect code for such a reference.
5925 The terminology used below is based on that of the Fortran 90
5926 standard, so that the text may be more concise and accurate:
5930 @code{OPTIONAL} means the argument may be omitted.
5933 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
5934 (generally named @samp{A}) may be specified.
5937 @samp{scalar} means the argument must not be an array (must
5938 be a variable or array element, or perhaps a constant if expressions
5942 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
5945 @code{INTENT(IN)} means the argument must be an expression
5946 (such as a constant or a variable that is defined upon invocation
5950 @code{INTENT(OUT)} means the argument must be definable by the
5951 invocation of the intrinsic (that is, must not be a constant nor
5952 an expression involving operators other than array reference and
5953 substring reference).
5956 @code{INTENT(INOUT)} means the argument must be defined prior to,
5957 and definable by, invocation of the intrinsic (a combination of
5958 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
5961 @xref{Kind Notation}, for an explanation of @code{KIND}.
5965 (Note that the empty lines appearing in the menu below
5966 are not intentional---they result from a bug in the
5967 GNU @code{makeinfo} program@dots{}a program that, if it
5968 did not exist, would leave this document in far worse shape!)
5971 @c The actual documentation for intrinsics comes from
5972 @c intdoc.texi, which in turn is automatically generated
5973 @c from the internal g77 tables in intrin.def _and_ the
5974 @c largely hand-written text in intdoc.h. So, if you want
5975 @c to change or add to existing documentation on intrinsics,
5976 @c you probably want to edit intdoc.h.
5988 @include intdoc.texi
5990 @node Scope and Classes of Names
5991 @section Scope and Classes of Symbolic Names
5992 @cindex symbol names, scope and classes
5995 (The following information augments or overrides the information in
5996 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5998 Chapter 18 of that document otherwise serves as the basis
5999 for the relevant aspects of GNU Fortran.)
6002 * Underscores in Symbol Names::
6005 @node Underscores in Symbol Names
6006 @subsection Underscores in Symbol Names
6009 Underscores (@samp{_}) are accepted in symbol names after the first
6010 character (which must be a letter).
6016 A dollar sign at the end of an output format specification suppresses
6017 the newline at the end of the output.
6019 @cindex <> edit descriptor
6020 @cindex edit descriptor, <>
6021 Edit descriptors in @code{FORMAT} statements may contain compile-time
6022 @code{INTEGER} constant expressions in angle brackets, such as
6024 10 FORMAT (I<WIDTH>)
6027 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
6029 These Fortran 90 features are supported:
6032 @cindex FORMAT descriptors
6033 @cindex Z edit descriptor
6034 @cindex edit descriptor, Z
6035 @cindex O edit descriptor
6036 @cindex edit descriptor, O
6037 The @code{O} and @code{Z} edit descriptors are supported for I/O of
6038 integers in octal and hexadecimal formats, respectively.
6040 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6041 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
6042 specifier is supported.
6045 @node Fortran 90 Features
6046 @section Fortran 90 Features
6048 @cindex extensions, from Fortran 90
6050 For convenience this section collects a list (probably incomplete) of
6051 the Fortran 90 features supported by the GNU Fortran language, even if
6052 they are documented elsewhere.
6053 @c makeinfo 1.68 objects to the nested parens
6055 @xref{Characters Lines Sequence,,{Characters, Lines, and Execution Sequence}},
6058 @xref{Characters Lines Sequence},
6060 for information on additional fixed source form lexical issues.
6061 @cindex @samp{-ffree-form}
6062 Further, the free source form is supported through the
6063 @samp{-ffree-form} option.
6064 @cindex @samp{-ff90}
6065 Other Fortran 90 features can be turned on by the @samp{-ff90} option;
6066 see @ref{Fortran 90}.
6067 For information on the Fortran 90 intrinsics available,
6068 see @ref{Table of Intrinsic Functions}.
6071 @item Automatic arrays in procedures
6072 @item Character assignments
6073 @cindex character assignments
6074 In character assignments, the variable being assigned may occur on the
6075 right hand side of the assignment.
6076 @item Character strings
6077 @cindex double quoted character constants
6078 Strings may have zero length and substrings of character constants are
6079 permitted. Character constants may be enclosed in double quotes
6080 (@code{"}) as well as single quotes. @xref{Character Type}.
6081 @item Construct names
6082 (Symbolic tags on blocks.) @xref{Construct Names }.
6083 @item @code{CYCLE} and @code{EXIT}
6084 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
6085 @item @code{DOUBLE COMPLEX}
6086 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement
6088 @item @code{DO WHILE}
6090 @item @code{END} decoration
6095 @item @code{IMPLICIT NONE}
6096 @item @code{INCLUDE} statements
6098 @item List-directed and namelist I/O on internal files
6099 @item Binary, octal and hexadecimal constants
6100 These are supported more generally than required by Fortran 90.
6101 @xref{Integer Type}.
6102 @item @samp{O} and @samp{Z} edit descriptors
6103 @item @code{NAMELIST}
6105 @item @code{OPEN} specifiers
6106 @code{STATUS='REPLACE'} is supported.
6107 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6108 @code{STATUS='SCRATCH'} is supplied.
6109 @item @code{FORMAT} edit descriptors
6110 @cindex FORMAT descriptors
6111 @cindex Z edit descriptor
6112 @cindex edit descriptor, Z
6113 The @code{Z} edit descriptor is supported.
6114 @item Relational operators
6115 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
6116 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
6117 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
6118 @item @code{SELECT CASE}
6119 Not fully implemented. @xref{SELECT CASE on CHARACTER Type,,
6120 @code{SELECT CASE} on @code{CHARACTER} Type}.
6121 @item Specification statements
6122 A limited subset of the Fortran 90 syntax and semantics for variable
6123 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
6124 (@code{KIND} is of limited usefulness in the absence of the
6125 @code{KIND}-related intrinsics, since these intrinsics permit writing
6126 more widely portable code.) An example of supported @code{KIND} usage
6129 INTEGER (KIND=1) :: FOO=1, BAR=2
6130 CHARACTER (LEN=3) FOO
6132 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
6135 @node Other Dialects
6136 @chapter Other Dialects
6138 GNU Fortran supports a variety of features that are not
6139 considered part of the GNU Fortran language itself, but
6140 are representative of various dialects of Fortran that
6141 @code{g77} supports in whole or in part.
6143 Any of the features listed below might be disallowed by
6144 @code{g77} unless some command-line option is specified.
6145 Currently, some of the features are accepted using the
6146 default invocation of @code{g77}, but that might change
6149 @emph{Note: This portion of the documentation definitely needs a lot
6153 * Source Form:: Details of fixed-form and free-form source.
6154 * Trailing Comment:: Use of @samp{/*} to start a comment.
6155 * Debug Line:: Use of @samp{D} in column 1.
6156 * Dollar Signs:: Use of @samp{$} in symbolic names.
6157 * Case Sensitivity:: Uppercase and lowercase in source files.
6158 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6159 * Fortran 90:: @dots{}versus the GNU Fortran language.
6160 * Pedantic Compilation:: Enforcing the standard.
6161 * Distensions:: Misfeatures supported by GNU Fortran.
6165 @section Source Form
6166 @cindex source file format
6167 @cindex source format
6168 @cindex file, source
6170 @cindex code, source
6174 GNU Fortran accepts programs written in either fixed form or
6178 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6179 allowing tabs) and Fortran 90's fixed form.
6181 Free form corresponds to
6182 Fortran 90's free form (though possibly not entirely up-to-date, and
6183 without complaining about some things that for which Fortran 90 requires
6184 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6186 The way a Fortran compiler views source files depends entirely on the
6187 implementation choices made for the compiler, since those choices
6188 are explicitly left to the implementation by the published Fortran
6190 GNU Fortran currently tries to be somewhat like a few popular compilers
6191 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6192 definition along with more
6193 flexibility offered by command-line options is likely to be offered
6196 This section describes how @code{g77} interprets source lines.
6199 * Carriage Returns:: Carriage returns ignored.
6200 * Tabs:: Tabs converted to spaces.
6201 * Short Lines:: Short lines padded with spaces (fixed-form only).
6202 * Long Lines:: Long lines truncated.
6203 * Ampersands:: Special Continuation Lines.
6206 @node Carriage Returns
6207 @subsection Carriage Returns
6208 @cindex carriage returns
6210 Carriage returns (@samp{\r}) in source lines are ignored.
6211 This is somewhat different from @code{f2c}, which seems to treat them as
6212 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6213 inside such constants.
6217 @cindex tab character
6218 @cindex horizontal tab
6220 A source line with a @key{TAB} character anywhere in it is treated as
6221 entirely significant---however long it is---instead of ending in
6222 column 72 (for fixed-form source) or 132 (for free-form source).
6223 This also is different from @code{f2c}, which encodes tabs as
6224 @samp{\t} (the ASCII @key{TAB} character) inside character
6225 and Hollerith constants, but nevertheless seems to treat the column
6226 position as if it had been affected by the canonical tab positioning.
6228 @code{g77} effectively
6229 translates tabs to the appropriate number of spaces (a la the default
6230 for the UNIX @code{expand} command) before doing any other processing, other
6231 than (currently) noting whether a tab was found on a line and using this
6232 information to decide how to interpret the length of the line and continued
6235 Note that this default behavior probably will change for version 0.6,
6236 when it will presumably be available via a command-line option.
6237 The default as of version 0.6 is planned to be a ``pure visual''
6238 model, where tabs are immediately
6239 converted to spaces and otherwise have no effect, so the way a typical
6240 user sees source lines produces a consistent result no matter how the
6241 spacing in those source lines is actually implemented via tabs, spaces,
6242 and trailing tabs/spaces before newline.
6243 Command-line options are likely to be added to specify whether all or
6244 just-tabbed lines are to be extended to 132 or full input-line length,
6245 and perhaps even an option will be added to specify the truncated-line
6246 behavior to which some Digital compilers default (and which affects
6247 the way continued character/Hollerith constants are interpreted).
6250 @subsection Short Lines
6251 @cindex short source lines
6252 @cindex space, padding with
6253 @cindex source lines, short
6254 @cindex lines, short
6256 Source lines shorter than the applicable fixed-form length are treated as
6257 if they were padded with spaces to that length.
6258 (None of this is relevant to source files written in free form.)
6261 continued character and Hollerith constants, and is a different
6262 interpretation than provided by some other popular compilers
6263 (although a bit more consistent with the traditional punched-card
6264 basis of Fortran and the way the Fortran standard expressed fixed
6267 @code{g77} might someday offer an option to warn about cases where differences
6268 might be seen as a result of this treatment, and perhaps an option to
6269 specify the alternate behavior as well.
6271 Note that this padding cannot apply to lines that are effectively of
6272 infinite length---such lines are specified using command-line options
6273 like @samp{-ffixed-line-length-none}, for example.
6276 @subsection Long Lines
6277 @cindex long source lines
6278 @cindex truncation, of long lines
6280 @cindex source lines, long
6282 Source lines longer than the applicable length are truncated to that
6284 Currently, @code{g77} does not warn if the truncated characters are
6285 not spaces, to accommodate existing code written for systems that
6286 treated truncated text as commentary (especially in columns 73 through 80).
6288 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6289 for information on the @samp{-ffixed-line-length-@var{n}} option,
6290 which can be used to set the line length applicable to fixed-form
6294 @subsection Ampersand Continuation Line
6295 @cindex ampersand continuation line
6296 @cindex continuation line, ampersand
6298 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6299 continuation line, imitating the behavior of @code{f2c}.
6301 @node Trailing Comment
6302 @section Trailing Comment
6304 @cindex trailing comment
6306 @cindex characters, comment
6309 @cindex exclamation point
6310 @code{g77} supports use of @samp{/*} to start a trailing
6312 In the GNU Fortran language, @samp{!} is used for this purpose.
6314 @samp{/*} is not in the GNU Fortran language
6315 because the use of @samp{/*} in a program might
6316 suggest to some readers that a block, not trailing, comment is
6317 started (and thus ended by @samp{*/}, not end of line),
6318 since that is the meaning of @samp{/*} in C.
6320 Also, such readers might think they can use @samp{//} to start
6321 a trailing comment as an alternative to @samp{/*}, but
6322 @samp{//} already denotes concatenation, and such a ``comment''
6323 might actually result in a program that compiles without
6324 error (though it would likely behave incorrectly).
6329 @cindex comment line, debug
6331 Use of @samp{D} or @samp{d} as the first character (column 1) of
6332 a source line denotes a debug line.
6334 In turn, a debug line is treated as either a comment line
6335 or a normal line, depending on whether debug lines are enabled.
6337 When treated as a comment line, a line beginning with @samp{D} or
6338 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6339 When treated as a normal line, such a line is treated as if
6340 the first character was @key{SPC} (space).
6342 (Currently, @code{g77} provides no means for treating debug
6343 lines as normal lines.)
6346 @section Dollar Signs in Symbol Names
6350 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6351 when the @samp{-fdollar-ok} option is specified.
6353 @node Case Sensitivity
6354 @section Case Sensitivity
6355 @cindex case sensitivity
6356 @cindex source file format
6357 @cindex code, source
6359 @cindex uppercase letters
6360 @cindex lowercase letters
6361 @cindex letters, uppercase
6362 @cindex letters, lowercase
6364 GNU Fortran offers the programmer way too much flexibility in deciding
6365 how source files are to be treated vis-a-vis uppercase and lowercase
6367 There are 66 useful settings that affect case sensitivity, plus 10
6368 settings that are nearly useless, with the remaining 116 settings
6369 being either redundant or useless.
6371 None of these settings have any effect on the contents of comments
6372 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6373 or of character or Hollerith constants.
6374 Note that things like the @samp{E} in the statement
6375 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6376 are considered built-in keywords, and so are affected by
6379 Low-level switches are identified in this section as follows:
6383 Source Case Conversion:
6387 Preserve (see Note 1)
6389 Convert to Upper Case
6391 Convert to Lower Case
6395 Built-in Keyword Matching:
6399 Match Any Case (per-character basis)
6401 Match Upper Case Only
6403 Match Lower Case Only
6405 Match InitialCaps Only (see tables for spellings)
6409 Built-in Intrinsic Matching:
6413 Match Any Case (per-character basis)
6415 Match Upper Case Only
6417 Match Lower Case Only
6419 Match InitialCaps Only (see tables for spellings)
6423 User-defined Symbol Possibilities (warnings only):
6427 Allow Any Case (per-character basis)
6429 Allow Upper Case Only
6431 Allow Lower Case Only
6433 Allow InitialCaps Only (see Note 2)
6437 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6438 consistent with these source switches---in the sense that input will be
6439 expected to meet the same requirements as source code in terms
6440 of matching symbol names and keywords (for the exponent letters).
6442 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6443 which uppercases @code{NAMELIST} input and symbol names for matching.
6444 This means not only that @code{NAMELIST} output currently shows symbol
6445 (and keyword) names in uppercase even if lower-case source
6446 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6447 adequately supported when source case preservation (option A0)
6450 If A0 is selected, a warning message will be
6451 output for each @code{NAMELIST} statement to this effect.
6453 of the program is undefined at run time if two or more symbol names
6454 appear in a given @code{NAMELIST} such that the names are identical
6455 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6456 For complete and total elegance, perhaps there should be a warning
6457 when option A2 is selected, since the output of NAMELIST is currently
6458 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6459 but that seems to be overkill for a product in beta test.
6461 Note 2: Rules for InitialCaps names are:
6465 Must be a single uppercase letter, @strong{or}
6467 Must start with an uppercase letter and contain at least one
6471 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6472 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6474 Note that most, but not all, built-in names meet these
6475 requirements---the exceptions are some of the two-letter format
6476 specifiers, such as @code{BN} and @code{BZ}.
6478 Here are the names of the corresponding command-line options:
6481 A0: -fsource-case-preserve
6482 A1: -fsource-case-upper
6483 A2: -fsource-case-lower
6485 B0: -fmatch-case-any
6486 B1: -fmatch-case-upper
6487 B2: -fmatch-case-lower
6488 B3: -fmatch-case-initcap
6490 C0: -fintrin-case-any
6491 C1: -fintrin-case-upper
6492 C2: -fintrin-case-lower
6493 C3: -fintrin-case-initcap
6495 D0: -fsymbol-case-any
6496 D1: -fsymbol-case-upper
6497 D2: -fsymbol-case-lower
6498 D3: -fsymbol-case-initcap
6501 Useful combinations of the above settings, along with abbreviated
6502 option names that set some of these combinations all at once:
6505 1: A0-- B0--- C0--- D0--- -fcase-preserve
6506 2: A0-- B0--- C0--- D-1--
6507 3: A0-- B0--- C0--- D--2-
6508 4: A0-- B0--- C0--- D---3
6509 5: A0-- B0--- C-1-- D0---
6510 6: A0-- B0--- C-1-- D-1--
6511 7: A0-- B0--- C-1-- D--2-
6512 8: A0-- B0--- C-1-- D---3
6513 9: A0-- B0--- C--2- D0---
6514 10: A0-- B0--- C--2- D-1--
6515 11: A0-- B0--- C--2- D--2-
6516 12: A0-- B0--- C--2- D---3
6517 13: A0-- B0--- C---3 D0---
6518 14: A0-- B0--- C---3 D-1--
6519 15: A0-- B0--- C---3 D--2-
6520 16: A0-- B0--- C---3 D---3
6521 17: A0-- B-1-- C0--- D0---
6522 18: A0-- B-1-- C0--- D-1--
6523 19: A0-- B-1-- C0--- D--2-
6524 20: A0-- B-1-- C0--- D---3
6525 21: A0-- B-1-- C-1-- D0---
6526 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6527 23: A0-- B-1-- C-1-- D--2-
6528 24: A0-- B-1-- C-1-- D---3
6529 25: A0-- B-1-- C--2- D0---
6530 26: A0-- B-1-- C--2- D-1--
6531 27: A0-- B-1-- C--2- D--2-
6532 28: A0-- B-1-- C--2- D---3
6533 29: A0-- B-1-- C---3 D0---
6534 30: A0-- B-1-- C---3 D-1--
6535 31: A0-- B-1-- C---3 D--2-
6536 32: A0-- B-1-- C---3 D---3
6537 33: A0-- B--2- C0--- D0---
6538 34: A0-- B--2- C0--- D-1--
6539 35: A0-- B--2- C0--- D--2-
6540 36: A0-- B--2- C0--- D---3
6541 37: A0-- B--2- C-1-- D0---
6542 38: A0-- B--2- C-1-- D-1--
6543 39: A0-- B--2- C-1-- D--2-
6544 40: A0-- B--2- C-1-- D---3
6545 41: A0-- B--2- C--2- D0---
6546 42: A0-- B--2- C--2- D-1--
6547 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6548 44: A0-- B--2- C--2- D---3
6549 45: A0-- B--2- C---3 D0---
6550 46: A0-- B--2- C---3 D-1--
6551 47: A0-- B--2- C---3 D--2-
6552 48: A0-- B--2- C---3 D---3
6553 49: A0-- B---3 C0--- D0---
6554 50: A0-- B---3 C0--- D-1--
6555 51: A0-- B---3 C0--- D--2-
6556 52: A0-- B---3 C0--- D---3
6557 53: A0-- B---3 C-1-- D0---
6558 54: A0-- B---3 C-1-- D-1--
6559 55: A0-- B---3 C-1-- D--2-
6560 56: A0-- B---3 C-1-- D---3
6561 57: A0-- B---3 C--2- D0---
6562 58: A0-- B---3 C--2- D-1--
6563 59: A0-- B---3 C--2- D--2-
6564 60: A0-- B---3 C--2- D---3
6565 61: A0-- B---3 C---3 D0---
6566 62: A0-- B---3 C---3 D-1--
6567 63: A0-- B---3 C---3 D--2-
6568 64: A0-- B---3 C---3 D---3 -fcase-initcap
6569 65: A-1- B01-- C01-- D01-- -fcase-upper
6570 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6573 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6574 (except comments, character constants, and Hollerith strings) must
6575 be entered in uppercase.
6576 Use @samp{-fcase-strict-upper} to specify this
6579 Number 43 is like Number 22 except all input must be lowercase. Use
6580 @samp{-fcase-strict-lower} to specify this combination.
6582 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6583 non-UNIX machines whereby all the source is translated to uppercase.
6584 Use @samp{-fcase-upper} to specify this combination.
6586 Number 66 is the ``canonical'' UNIX model whereby all the source is
6587 translated to lowercase.
6588 Use @samp{-fcase-lower} to specify this combination.
6590 There are a few nearly useless combinations:
6593 67: A-1- B01-- C01-- D--2-
6594 68: A-1- B01-- C01-- D---3
6595 69: A-1- B01-- C--23 D01--
6596 70: A-1- B01-- C--23 D--2-
6597 71: A-1- B01-- C--23 D---3
6598 72: A--2 B01-- C0-2- D-1--
6599 73: A--2 B01-- C0-2- D---3
6600 74: A--2 B01-- C-1-3 D0-2-
6601 75: A--2 B01-- C-1-3 D-1--
6602 76: A--2 B01-- C-1-3 D---3
6605 The above allow some programs to be compiled but with restrictions that
6606 make most useful programs impossible: Numbers 67 and 72 warn about
6607 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6609 68 and 73 warn about any user-defined symbol names longer than one
6610 character that don't have at least one non-alphabetic character after
6612 Numbers 69 and 74 disallow any references to intrinsics;
6613 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6614 67+69, 68+69, 72+74, and 73+74, respectively.
6616 All redundant combinations are shown in the above tables anyplace
6617 where more than one setting is shown for a low-level switch.
6618 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6619 The ``proper'' setting in such a case is the one that copies the setting
6620 of switch A---any other setting might slightly reduce the speed of
6621 the compiler, though possibly to an unmeasurable extent.
6623 All remaining combinations are useless in that they prevent successful
6624 compilation of non-null source files (source files with something other
6628 @section VXT Fortran
6630 @cindex VXT extensions
6631 @cindex extensions, VXT
6632 @code{g77} supports certain constructs that
6633 have different meanings in VXT Fortran than they
6634 do in the GNU Fortran language.
6636 Generally, this manual uses the invented term VXT Fortran to refer
6637 VAX FORTRAN (circa v4).
6638 That compiler offered many popular features, though not necessarily
6639 those that are specific to the VAX processor architecture,
6640 the VMS operating system,
6641 or Digital Equipment Corporation's Fortran product line.
6642 (VAX and VMS probably are trademarks of Digital Equipment
6645 An extension offered by a Digital Fortran product that also is
6646 offered by several other Fortran products for different kinds of
6647 systems is probably going to be considered for inclusion in @code{g77}
6648 someday, and is considered a VXT Fortran feature.
6650 The @samp{-fvxt} option generally specifies that, where
6651 the meaning of a construct is ambiguous (means one thing
6652 in GNU Fortran and another in VXT Fortran), the VXT Fortran
6653 meaning is to be assumed.
6656 * Double Quote Meaning:: @samp{"2000} as octal constant.
6657 * Exclamation Point:: @samp{!} in column 6.
6660 @node Double Quote Meaning
6661 @subsection Meaning of Double Quote
6662 @cindex double quotes
6663 @cindex character constants
6664 @cindex constants, character
6665 @cindex octal constants
6666 @cindex constants, octal
6668 @code{g77} treats double-quote (@samp{"})
6669 as beginning an octal constant of @code{INTEGER(KIND=1)} type
6670 when the @samp{-fvxt} option is specified.
6671 The form of this octal constant is
6678 where @var{octal-digits} is a nonempty string of characters in
6679 the set @samp{01234567}.
6681 For example, the @samp{-fvxt} option permits this:
6689 The above program would print the value @samp{16}.
6691 @xref{Integer Type}, for information on the preferred construct
6692 for integer constants specified using GNU Fortran's octal notation.
6694 (In the GNU Fortran language, the double-quote character (@samp{"})
6695 delimits a character constant just as does apostrophe (@samp{'}).
6696 There is no way to allow
6697 both constructs in the general case, since statements like
6698 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
6700 @node Exclamation Point
6701 @subsection Meaning of Exclamation Point in Column 6
6703 @cindex exclamation point
6704 @cindex continuation character
6705 @cindex characters, continuation
6706 @cindex comment character
6707 @cindex characters, comment
6709 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
6710 a fixed-form source file
6711 as a continuation character rather than
6712 as the beginning of a comment
6713 (as it does in any other column)
6714 when the @samp{-fvxt} option is specified.
6716 The following program, when run, prints a message indicating
6717 whether it is interpreted according to GNU Fortran (and Fortran 90)
6718 rules or VXT Fortran rules:
6721 C234567 (This line begins in column 1.)
6724 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
6725 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
6726 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
6730 (In the GNU Fortran and Fortran 90 languages, exclamation point is
6731 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
6732 marks a line as a continuation line when it appears in column 6.)
6736 @cindex compatibility, Fortran 90
6737 @cindex Fortran 90, compatibility
6739 The GNU Fortran language includes a number of features that are
6740 part of Fortran 90, even when the @samp{-ff90} option is not specified.
6741 The features enabled by @samp{-ff90} are intended to be those that,
6742 when @samp{-ff90} is not specified, would have another
6743 meaning to @code{g77}---usually meaning something invalid in the
6744 GNU Fortran language.
6746 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
6747 to gratuitously reject Fortran 90 constructs.
6748 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
6749 to do that, although its implementation is certainly incomplete at
6752 When @samp{-ff90} is specified:
6756 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
6757 where @var{expr} is @code{COMPLEX} type,
6758 is the same type as the real part of @var{expr}.
6760 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
6761 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
6762 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
6765 @node Pedantic Compilation
6766 @section Pedantic Compilation
6767 @cindex pedantic compilation
6768 @cindex compilation, pedantic
6770 The @samp{-fpedantic} command-line option specifies that @code{g77}
6771 is to warn about code that is not standard-conforming.
6772 This is useful for finding
6773 some extensions @code{g77} accepts that other compilers might not accept.
6774 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
6775 always imply @samp{-fpedantic}.)
6777 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
6778 for conforming code.
6779 With @samp{-ff90} in force, Fortran 90 is used.
6781 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
6782 and @samp{-fno-f90} are in force are:
6786 Automatic arrays, as in
6795 where @samp{A} is not listed in any @code{ENTRY} statement,
6796 and thus is not a dummy argument.
6799 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
6801 These commas are disallowed by FORTRAN 77, but, while strictly
6802 superfluous, are syntactically elegant,
6803 especially given that commas are required in statements such
6804 as @samp{READ 99, I} and @samp{PRINT *, J}.
6805 Many compilers permit the superfluous commas for this reason.
6808 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
6810 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
6811 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
6813 An example of an implicit use is the expression @samp{C*D},
6814 where @samp{C} is @code{COMPLEX(KIND=1)}
6815 and @samp{D} is @code{DOUBLE PRECISION}.
6816 This expression is prohibited by ANSI FORTRAN 77
6817 because the rules of promotion would suggest that it
6818 produce a @code{DOUBLE COMPLEX} result---a type not
6819 provided for by that standard.
6822 Automatic conversion of numeric
6823 expressions to @code{INTEGER(KIND=1)} in contexts such as:
6827 Array-reference indexes.
6829 Alternate-return values.
6831 Computed @code{GOTO}.
6833 @code{FORMAT} run-time expressions (not yet supported).
6835 Dimension lists in specification statements.
6837 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
6839 Sizes of @code{CHARACTER} entities in specification statements.
6841 Kind types in specification entities (a Fortran 90 feature).
6843 Initial, terminal, and incrementation parameters for implied-@code{DO}
6844 constructs in @code{DATA} statements.
6848 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
6849 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
6850 expressions are disallowed anyway).
6853 Zero-size array dimensions, as in:
6856 INTEGER I(10,20,4:2)
6860 Zero-length @code{CHARACTER} entities, as in:
6867 Substring operators applied to character constants and named
6871 PRINT *, 'hello'(3:5)
6875 Null arguments passed to statement function, as in:
6882 Disagreement among program units regarding whether a given @code{COMMON}
6883 area is @code{SAVE}d (for targets where program units in a single source
6884 file are ``glued'' together as they typically are for UNIX development
6888 Disagreement among program units regarding the size of a
6889 named @code{COMMON} block.
6892 Specification statements following first @code{DATA} statement.
6894 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
6895 but not @samp{INTEGER I}.
6896 The @samp{-fpedantic} option disallows both of these.)
6899 Semicolon as statement separator, as in:
6906 @c Comma before list of I/O items in @code{WRITE}
6907 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
6908 @c statements, as with @code{READ} (as explained above).
6911 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
6914 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
6918 Expressions having two arithmetic operators in a row, such
6922 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
6923 following constructs result in diagnostics:
6927 Use of semicolon as a statement separator on a line
6928 that has an @code{INCLUDE} directive.
6932 @section Distensions
6934 @cindex ugly features
6935 @cindex features, ugly
6937 The @samp{-fugly-*} command-line options determine whether certain
6938 features supported by VAX FORTRAN and other such compilers, but considered
6939 too ugly to be in code that can be changed to use safer and/or more
6940 portable constructs, are accepted.
6941 These are humorously referred to as ``distensions'',
6942 extensions that just plain look ugly in the harsh light of day.
6945 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
6946 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
6947 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
6948 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
6949 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
6950 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
6951 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
6954 @node Ugly Implicit Argument Conversion
6955 @subsection Implicit Argument Conversion
6956 @cindex Hollerith constants
6957 @cindex constants, Hollerith
6959 The @samp{-fno-ugly-args} option disables
6960 passing typeless and Hollerith constants as actual arguments
6961 in procedure invocations.
6970 These constructs can be too easily used to create non-portable
6971 code, but are not considered as ``ugly'' as others.
6972 Further, they are widely used in existing Fortran source code
6973 in ways that often are quite portable.
6974 Therefore, they are enabled by default.
6976 @node Ugly Assumed-Size Arrays
6977 @subsection Ugly Assumed-Size Arrays
6978 @cindex arrays, assumed-size
6979 @cindex assumed-size arrays
6980 @cindex DIMENSION X(1)
6982 The @samp{-fugly-assumed} option enables
6983 the treatment of any array with a final dimension specified as @samp{1}
6984 as an assumed-size array, as if @samp{*} had been specified
6987 For example, @samp{DIMENSION X(1)} is treated as if it
6988 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
6989 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
6990 or @code{ENTRY} statement in the same program unit.
6992 Use an explicit lower bound to avoid this interpretation.
6993 For example, @samp{DIMENSION X(1:1)} is never treated as if
6994 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
6995 Nor is @samp{DIMENSION X(2-1)} affected by this option,
6996 since that kind of expression is unlikely to have been
6997 intended to designate an assumed-size array.
6999 This option is used to prevent warnings being issued about apparent
7000 out-of-bounds reference such as @samp{X(2) = 99}.
7002 It also prevents the array from being used in contexts that
7003 disallow assumed-size arrays, such as @samp{PRINT *,X}.
7004 In such cases, a diagnostic is generated and the source file is
7007 The construct affected by this option is used only in old code
7008 that pre-exists the widespread acceptance of adjustable and assumed-size
7009 arrays in the Fortran community.
7011 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
7012 treated if @samp{X} is listed as a dummy argument only
7013 @emph{after} the @code{DIMENSION} statement (presumably in
7014 an @code{ENTRY} statement).
7015 For example, @samp{-fugly-assumed} has no effect on the
7016 following program unit:
7027 @node Ugly Complex Part Extraction
7028 @subsection Ugly Complex Part Extraction
7029 @cindex complex values
7031 @cindex imaginary part
7033 The @samp{-fugly-complex} option enables
7034 use of the @code{REAL()} and @code{AIMAG()}
7035 intrinsics with arguments that are
7036 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
7038 With @samp{-ff90} in effect, these intrinsics return
7039 the unconverted real and imaginary parts (respectively)
7042 With @samp{-fno-f90} in effect, these intrinsics convert
7043 the real and imaginary parts to @code{REAL(KIND=1)}, and return
7044 the result of that conversion.
7046 Due to this ambiguity, the GNU Fortran language defines
7047 these constructs as invalid, except in the specific
7048 case where they are entirely and solely passed as an
7049 argument to an invocation of the @code{REAL()} intrinsic.
7057 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7058 and @samp{-fno-ugly-complex} is in effect, because the
7061 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7062 is specified, in which case the appropriate interpretation is
7063 chosen and no diagnostic is issued.
7065 @xref{CMPAMBIG}, for information on how to cope with existing
7066 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7067 with @code{COMPLEX(KIND=2)} arguments.
7069 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7070 intrinsic, used to extract the real part of a complex expression
7072 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7073 intrinsic, used to extract the imaginary part of a complex expression
7076 @node Ugly Null Arguments
7077 @subsection Ugly Null Arguments
7078 @cindex trailing comma
7079 @cindex comma, trailing
7080 @cindex characters, comma
7081 @cindex null arguments
7082 @cindex arguments, null
7084 The @samp{-fugly-comma} option enables use of a single trailing comma
7085 to mean ``pass an extra trailing null argument''
7086 in a list of actual arguments to an external procedure,
7087 and use of an empty list of arguments to such a procedure
7088 to mean ``pass a single null argument''.
7090 @cindex omitting arguments
7091 @cindex arguments, omitting
7092 (Null arguments often are used in some procedure-calling
7093 schemes to indicate omitted arguments.)
7095 For example, @samp{CALL FOO(,)} means ``pass
7096 two null arguments'', rather than ``pass one null argument''.
7097 Also, @samp{CALL BAR()} means ``pass one null argument''.
7099 This construct is considered ``ugly'' because it does not
7100 provide an elegant way to pass a single null argument
7101 that is syntactically distinct from passing no arguments.
7102 That is, this construct changes the meaning of code that
7103 makes no use of the construct.
7105 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7106 and @samp{I = JFUNC()} pass a single null argument, instead
7107 of passing no arguments as required by the Fortran 77 and
7110 @emph{Note:} Many systems gracefully allow the case
7111 where a procedure call passes one extra argument that the
7112 called procedure does not expect.
7114 So, in practice, there might be no difference in
7115 the behavior of a program that does @samp{CALL FOO()}
7116 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7117 in force as compared to its behavior when compiled
7118 with the default, @samp{-fno-ugly-comma}, in force,
7119 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7120 arguments to be passed.
7122 @node Ugly Conversion of Initializers
7123 @subsection Ugly Conversion of Initializers
7125 The constructs disabled by @samp{-fno-ugly-init} are:
7128 @cindex Hollerith constants
7129 @cindex constants, Hollerith
7131 Use of Hollerith and typeless constants in contexts where they set
7132 initial (compile-time) values for variables, arrays, and named
7133 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7134 type-declaration statements specifying initial values.
7136 Here are some sample initializations that are disabled by the
7137 @samp{-fno-ugly-init} option:
7140 PARAMETER (VAL='9A304FFE'X)
7141 REAL*8 STRING/8HOUTPUT00/
7145 @cindex character constants
7146 @cindex constants, character
7148 In the same contexts as above, use of character constants to initialize
7149 numeric items and vice versa (one constant per item).
7151 Here are more sample initializations that are disabled by the
7152 @samp{-fno-ugly-init} option:
7157 PARAMETER (IA = 'A')
7158 PARAMETER (BELL = 7)
7162 Use of Hollerith and typeless constants on the right-hand side
7163 of assignment statements to numeric types, and in other
7164 contexts (such as passing arguments in invocations of
7165 intrinsic procedures and statement functions) that
7166 are treated as assignments to known types (the dummy
7167 arguments, in these cases).
7169 Here are sample statements that are disabled by the
7170 @samp{-fno-ugly-init} option:
7174 PRINT *, IMAX0(2HAB, 2HBA)
7178 The above constructs, when used,
7179 can tend to result in non-portable code.
7180 But, they are widely used in existing Fortran code in ways
7181 that often are quite portable.
7182 Therefore, they are enabled by default.
7184 @node Ugly Integer Conversions
7185 @subsection Ugly Integer Conversions
7187 The constructs enabled via @samp{-fugly-logint} are:
7191 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7193 context (typically implies nonportable dependencies on how a
7194 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7197 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7201 The above constructs are disabled by default because use
7202 of them tends to lead to non-portable code.
7203 Even existing Fortran code that uses that often turns out
7204 to be non-portable, if not outright buggy.
7206 Some of this is due to differences among implementations as
7207 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7208 @code{INTEGER} values---Fortran code that assumes a particular
7209 coding is likely to use one of the above constructs, and is
7210 also likely to not work correctly on implementations using
7211 different encodings.
7213 @xref{Equivalence Versus Equality}, for more information.
7215 @node Ugly Assigned Labels
7216 @subsection Ugly Assigned Labels
7217 @cindex ASSIGN statement
7218 @cindex statements, ASSIGN
7219 @cindex assigned labels
7222 The @samp{-fugly-assign} option forces @code{g77} to use the
7223 same storage for assigned labels as it would for a normal
7224 assignment to the same variable.
7226 For example, consider the following code fragment:
7234 Normally, for portability and improved diagnostics, @code{g77}
7235 reserves distinct storage for a ``sibling'' of @samp{I}, used
7236 only for @code{ASSIGN} statements to that variable (along with
7237 the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
7238 statements that reference the variable).
7240 However, some code (that violates the ANSI FORTRAN 77 standard)
7241 attempts to copy assigned labels among variables involved with
7242 @code{ASSIGN} statements, as in:
7253 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7254 is specified on the command-line, ensuring that the value of @code{I}
7255 referenced in the second line is whatever value @code{g77} uses
7256 to designate statement label @samp{10}, so the value may be
7257 copied into the @samp{ISTATE} array, later retrieved into a
7258 variable of the appropriate type (@samp{J}), and used as the target of
7259 an assigned-@code{GOTO} statement.
7261 @emph{Note:} To avoid subtle program bugs,
7262 when @samp{-fugly-assign} is specified,
7263 @code{g77} requires the type of variables
7264 specified in assigned-label contexts
7265 @emph{must} be the same type returned by @code{%LOC()}.
7266 On many systems, this type is effectively the same
7267 as @code{INTEGER(KIND=1)}, while, on others, it is
7268 effectively the same as @code{INTEGER(KIND=2)}.
7270 Do @emph{not} depend on @code{g77} actually writing valid pointers
7271 to these variables, however.
7272 While @code{g77} currently chooses that implementation, it might
7273 be changed in the future.
7275 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7276 for implementation details on assigned-statement labels.
7279 @chapter The GNU Fortran Compiler
7281 The GNU Fortran compiler, @code{g77}, supports programs written
7282 in the GNU Fortran language and in some other dialects of Fortran.
7284 Some aspects of how @code{g77} works are universal regardless
7285 of dialect, and yet are not properly part of the GNU Fortran
7287 These are described below.
7289 @emph{Note: This portion of the documentation definitely needs a lot
7294 * Run-time Environment Limits::
7296 * Compiler Constants::
7297 * Compiler Intrinsics::
7300 @node Compiler Limits
7301 @section Compiler Limits
7302 @cindex limits, compiler
7303 @cindex compiler limits
7305 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7306 on lengths of identifiers, number of continuation lines, number of external
7307 symbols in a program, and so on.
7309 @cindex options, -Nl
7311 @cindex options, -Nx
7313 @cindex limits, continuation lines
7314 @cindex limits, lengths of names
7315 For example, some other Fortran compiler have an option
7316 (such as @samp{-Nl@var{x}}) to increase the limit on the
7317 number of continuation lines.
7318 Also, some Fortran compilation systems have an option
7319 (such as @samp{-Nx@var{x}}) to increase the limit on the
7320 number of external symbols.
7322 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7323 no equivalent options, since they do not impose arbitrary
7324 limits in these areas.
7326 @cindex rank, maximum
7327 @cindex maximum rank
7328 @cindex number of dimensions, maximum
7329 @cindex maximum number of dimensions
7330 @cindex limits, rank
7331 @cindex limits, array dimensions
7332 @code{g77} does currently limit the number of dimensions in an array
7333 to the same degree as do the Fortran standards---seven (7).
7334 This restriction might be lifted in a future version.
7336 @node Run-time Environment Limits
7337 @section Run-time Environment Limits
7338 @cindex limits, run-time library
7341 As a portable Fortran implementation,
7342 @code{g77} offers its users direct access to,
7343 and otherwise depends upon,
7344 the underlying facilities of the system
7345 used to build @code{g77},
7346 the system on which @code{g77} itself is used to compile programs,
7347 and the system on which the @code{g77}-compiled program is actually run.
7348 (For most users, the three systems are of the same
7349 type---combination of operating environment and hardware---often
7350 the same physical system.)
7352 The run-time environment for a particular system
7353 inevitably imposes some limits on a program's use
7354 of various system facilities.
7355 These limits vary from system to system.
7357 Even when such limits might be well beyond the
7358 possibility of being encountered on a particular system,
7359 the @code{g77} run-time environment
7360 has certain built-in limits,
7361 usually, but not always, stemming from intrinsics
7362 with inherently limited interfaces.
7364 Currently, the @code{g77} run-time environment
7365 does not generally offer a less-limiting environment
7366 by augmenting the underlying system's own environment.
7368 Therefore, code written in the GNU Fortran language,
7369 while syntactically and semantically portable,
7370 might nevertheless make non-portable assumptions
7371 about the run-time environment---assumptions that
7372 prove to be false for some particular environments.
7374 The GNU Fortran language,
7375 the @code{g77} compiler and run-time environment,
7376 and the @code{g77} documentation
7377 do not yet offer comprehensive portable work-arounds for such limits,
7378 though programmers should be able to
7379 find their own in specific instances.
7381 Not all of the limitations are described in this document.
7382 Some of the known limitations include:
7385 * Timer Wraparounds::
7386 * Year 2000 (Y2K) Problems::
7388 * Character-variable Length::
7389 * Year 10000 (Y10K) Problems::
7392 @node Timer Wraparounds
7393 @subsection Timer Wraparounds
7395 Intrinsics that return values computed from system timers,
7396 whether elapsed (wall-clock) timers,
7398 or other kinds of timers,
7399 are prone to experiencing wrap-around errors
7400 (or returning wrapped-around values from successive calls)
7401 due to insufficient ranges
7402 offered by the underlying system's timers.
7404 @cindex negative time
7407 Some of the symptoms of such behaviors include
7408 apparently negative time being computed for a duration,
7409 an extremely short amount of time being computed for a long duration,
7410 and an extremely long amount of time being computed for a short duration.
7412 See the following for intrinsics
7413 known to have potential problems in these areas
7414 on at least some systems:
7415 @ref{CPU_Time Intrinsic},
7416 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
7417 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
7418 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
7419 @ref{Secnds Intrinsic},
7420 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
7421 @ref{System_Clock Intrinsic},
7422 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
7423 @ref{Time8 Intrinsic}.
7425 @node Year 2000 (Y2K) Problems
7426 @subsection Year 2000 (Y2K) Problems
7427 @cindex Y2K compliance
7428 @cindex Year 2000 compliance
7430 While the @code{g77} compiler itself is believed to
7431 be Year-2000 (Y2K) compliant,
7432 some intrinsics are not,
7433 and, potentially, some underlying systems are not,
7434 perhaps rendering some Y2K-compliant intrinsics
7435 non-compliant when used on those particular systems.
7437 Fortran code that uses non-Y2K-compliant intrinsics
7439 is, itself, almost certainly not compliant,
7440 and should be modified to use Y2K-compliant intrinsics instead.
7442 Fortran code that uses no non-Y2K-compliant intrinsics,
7443 but which currently is running on a non-Y2K-compliant system,
7444 can be made more Y2K compliant by compiling and
7445 linking it for use on a new Y2K-compliant system,
7446 such as a new version of an old, non-Y2K-compliant, system.
7448 Currently, information on Y2K and related issues
7449 is being maintained at
7450 @uref{http://www.gnu.org/software/year2000-list.html}.
7452 See the following for intrinsics
7453 known to have potential problems in these areas
7454 on at least some systems:
7455 @ref{Date Intrinsic},
7456 @ref{IDate Intrinsic (VXT)}.
7459 @cindex date_y2kbuggy_0
7460 @cindex vxtidate_y2kbuggy_0
7461 @cindex G77_date_y2kbuggy_0
7462 @cindex G77_vxtidate_y2kbuggy_0
7463 The @code{libg2c} library
7464 shipped with any @code{g77} that warns
7465 about invocation of a non-Y2K-compliant intrinsic
7466 has renamed the @code{EXTERNAL} procedure names
7467 of those intrinsics.
7468 This is done so that
7469 the @code{libg2c} implementations of these intrinsics
7470 cannot be directly linked to
7471 as @code{EXTERNAL} names
7472 (which normally would avoid the non-Y2K-intrinsic warning).
7474 The renamed forms of the @code{EXTERNAL} names
7475 of these renamed procedures
7477 by appending the string @samp{_y2kbug}
7478 to the name of the procedure
7485 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
7486 CALL DATE_Y2KBUG (STR)
7487 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
7490 (Note that the @code{EXTERNAL} statement
7491 is not actually required,
7492 since the modified names are not recognized as intrinsics
7493 by the current version of @code{g77}.
7494 But it is shown in this specific case,
7495 for purposes of illustration.)
7497 The renaming of @code{EXTERNAL} procedure names of these intrinsics
7498 causes unresolved references at link time.
7499 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
7500 is normally compiled by @code{g77}
7501 as, in C, @samp{date_(&str, 20);}.
7502 This, in turn, links to the @code{date_} procedure
7503 in the @code{libE77} portion of @code{libg2c},
7504 which purposely calls a nonexistent procedure
7505 named @code{G77_date_y2kbuggy_0}.
7506 The resulting link-time error is designed, via this name,
7507 to encourage the programmer to look up the
7508 index entries to this portion of the @code{g77} documentation.
7510 Generally, we recommend that the @code{EXTERNAL} method
7511 of invoking procedures in @code{libg2c}
7513 When used, some of the correctness checking
7514 normally performed by @code{g77}
7517 In particular, it is probably better to use the
7518 @code{INTRINSIC} method of invoking
7519 non-Y2K-compliant procedures,
7520 so anyone compiling the code
7521 can quickly notice the potential Y2K problems
7522 (via the warnings printing by @code{g77})
7523 without having to even look at the code itself.
7525 If there are problems linking @code{libg2c}
7526 to code compiled by @code{g77}
7527 that involve the string @samp{y2kbug},
7528 and these are not explained above,
7529 that probably indicates
7530 that a version of @code{libg2c}
7531 older than @code{g77}
7533 or that the new library is being linked
7534 to code compiled by an older version of @code{g77}.
7536 That's because, as of the version that warns about
7537 non-Y2K-compliant intrinsic invocation,
7538 @code{g77} references the @code{libg2c} implementations
7540 using new names, containing the string @samp{y2kbug}.
7542 So, linking newly-compiled code
7543 (invoking one of the intrinsics in question)
7545 might yield an unresolved reference
7546 to @code{G77_date_y2kbug_0}.
7547 (The old library calls it @code{G77_date_0}.)
7549 Similarly, linking previously-compiled code
7551 might yield an unresolved reference
7552 to @code{G77_vxtidate_0}.
7553 (The new library calls it @code{G77_vxtidate_y2kbug_0}.)
7555 The proper fix for the above problems
7556 is to obtain the latest release of @code{g77}
7557 and related products
7558 (including @code{libg2c})
7559 and install them on all systems,
7560 then recompile, relink, and install
7562 all existing Fortran programs.
7564 (Normally, this sort of renaming is steadfastly avoided.
7565 In this case, however, it seems more important to highlight
7566 potential Y2K problems
7567 than to ease the transition
7568 of potentially non-Y2K-compliant code
7569 to new versions of @code{g77} and @code{libg2c}.)
7572 @subsection Array Size
7573 @cindex limits, array size
7576 Currently, @code{g77} uses the default @code{INTEGER} type
7578 which limits the sizes of single-dimension arrays
7579 on systems offering a larger address space
7580 than can be addressed by that type.
7581 (That @code{g77} puts all arrays in memory
7582 could be considered another limitation---it
7583 could use large temporary files---but that decision
7584 is left to the programmer as an implementation choice
7585 by most Fortran implementations.)
7587 @c ??? Investigate this, to offer a more clear statement
7588 @c than the following paragraphs do. -- burley 1999-02-17
7589 It is not yet clear whether this limitation
7590 never, sometimes, or always applies to the
7591 sizes of multiple-dimension arrays as a whole.
7593 For example, on a system with 64-bit addresses
7594 and 32-bit default @code{INTEGER},
7595 an array with a size greater than can be addressed
7597 can be declared using multiple dimensions.
7598 Such an array is therefore larger
7599 than a single-dimension array can be,
7602 @cindex limits, multi-dimension arrays
7603 @cindex multi-dimension arrays
7604 @cindex arrays, dimensioning
7605 Whether large multiple-dimension arrays are reliably supported
7606 depends mostly on the @code{gcc} back end (code generator)
7607 used by @code{g77}, and has not yet been fully investigated.
7609 @node Character-variable Length
7610 @subsection Character-variable Length
7611 @cindex limits, on character-variable length
7612 @cindex character-variable length
7614 Currently, @code{g77} uses the default @code{INTEGER} type
7615 for the lengths of @code{CHARACTER} variables
7618 This means that, for example,
7619 a system with a 64-bit address space
7620 and a 32-bit default @code{INTEGER} type
7621 does not, under @code{g77},
7622 support a @code{CHARACTER*@var{n}} declaration
7623 where @var{n} is greater than 2147483647.
7625 @node Year 10000 (Y10K) Problems
7626 @subsection Year 10000 (Y10K) Problems
7627 @cindex Y10K compliance
7628 @cindex Year 10000 compliance
7630 Most intrinsics returning, or computing values based on,
7631 date information are prone to Year-10000 (Y10K) problems,
7632 due to supporting only 4 digits for the year.
7634 See the following for examples:
7635 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
7636 @ref{IDate Intrinsic (UNIX)},
7637 @ref{Time Intrinsic (VXT)},
7638 @ref{Date_and_Time Intrinsic}.
7640 @node Compiler Types
7641 @section Compiler Types
7642 @cindex types, of data
7645 Fortran implementations have a fair amount of freedom given them by the
7646 standard as far as how much storage space is used and how much precision
7647 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7648 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7649 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7650 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7651 the interpretation of @var{n} varies across compilers and target architectures.
7653 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7654 and @code{REAL(KIND=1)}
7655 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7656 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7657 Further, it requires that @code{COMPLEX(KIND=1)}
7658 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7659 storage-associated (such as via @code{EQUIVALENCE})
7660 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7661 corresponds to the real element and @samp{R(2)} to the imaginary
7662 element of the @code{COMPLEX(KIND=1)} variable.
7664 (Few requirements as to precision or ranges of any of these are
7665 placed on the implementation, nor is the relationship of storage sizes of
7666 these types to the @code{CHARACTER} type specified, by the standard.)
7668 @code{g77} follows the above requirements, warning when compiling
7669 a program requires placement of items in memory that contradict the
7670 requirements of the target architecture.
7671 (For example, a program can require placement of a @code{REAL(KIND=2)}
7672 on a boundary that is not an even multiple of its size, but still an
7673 even multiple of the size of a @code{REAL(KIND=1)} variable.
7674 On some target architectures, using the canonical
7675 mapping of Fortran types to underlying architectural types, such
7676 placement is prohibited by the machine definition or
7677 the Application Binary Interface (ABI) in force for
7678 the configuration defined for building @code{gcc} and @code{g77}.
7679 @code{g77} warns about such
7680 situations when it encounters them.)
7682 @code{g77} follows consistent rules for configuring the mapping between Fortran
7683 types, including the @samp{*@var{n}} notation, and the underlying architectural
7684 types as accessed by a similarly-configured applicable version of the
7685 @code{gcc} compiler.
7686 These rules offer a widely portable, consistent Fortran/C
7687 environment, although they might well conflict with the expectations of
7688 users of Fortran compilers designed and written for particular
7691 These rules are based on the configuration that is in force for the
7692 version of @code{gcc} built in the same release as @code{g77} (and
7693 which was therefore used to build both the @code{g77} compiler
7694 components and the @code{libg2c} run-time library):
7697 @cindex REAL(KIND=1) type
7698 @cindex types, REAL(KIND=1)
7700 Same as @code{float} type.
7702 @cindex REAL(KIND=2) type
7703 @cindex types, REAL(KIND=2)
7705 Same as whatever floating-point type that is twice the size
7706 of a @code{float}---usually, this is a @code{double}.
7708 @cindex INTEGER(KIND=1) type
7709 @cindex types, INTEGER(KIND=1)
7710 @item INTEGER(KIND=1)
7711 Same as an integral type that is occupies the same amount
7712 of memory storage as @code{float}---usually, this is either
7713 an @code{int} or a @code{long int}.
7715 @cindex LOGICAL(KIND=1) type
7716 @cindex types, LOGICAL(KIND=1)
7717 @item LOGICAL(KIND=1)
7718 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7720 @cindex INTEGER(KIND=2) type
7721 @cindex types, INTEGER(KIND=2)
7722 @item INTEGER(KIND=2)
7723 Twice the size, and usually nearly twice the range,
7724 as @code{INTEGER(KIND=1)}---usually, this is either
7725 a @code{long int} or a @code{long long int}.
7727 @cindex LOGICAL(KIND=2) type
7728 @cindex types, LOGICAL(KIND=2)
7729 @item LOGICAL(KIND=2)
7730 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7732 @cindex INTEGER(KIND=3) type
7733 @cindex types, INTEGER(KIND=3)
7734 @item INTEGER(KIND=3)
7735 Same @code{gcc} type as signed @code{char}.
7737 @cindex LOGICAL(KIND=3) type
7738 @cindex types, LOGICAL(KIND=3)
7739 @item LOGICAL(KIND=3)
7740 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7742 @cindex INTEGER(KIND=6) type
7743 @cindex types, INTEGER(KIND=6)
7744 @item INTEGER(KIND=6)
7745 Twice the size, and usually nearly twice the range,
7746 as @code{INTEGER(KIND=3)}---usually, this is
7749 @cindex LOGICAL(KIND=6) type
7750 @cindex types, LOGICAL(KIND=6)
7751 @item LOGICAL(KIND=6)
7752 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7754 @cindex COMPLEX(KIND=1) type
7755 @cindex types, COMPLEX(KIND=1)
7756 @item COMPLEX(KIND=1)
7757 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7758 one for the imaginary part).
7760 @cindex COMPLEX(KIND=2) type
7761 @cindex types, COMPLEX(KIND=2)
7762 @item COMPLEX(KIND=2)
7763 Two @code{REAL(KIND=2)} scalars.
7765 @cindex *@var{n} notation
7766 @item @var{numeric-type}*@var{n}
7767 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7768 Same as whatever @code{gcc} type occupies @var{n} times the storage
7769 space of a @code{gcc} @code{char} item.
7771 @cindex DOUBLE PRECISION type
7772 @cindex types, DOUBLE PRECISION
7773 @item DOUBLE PRECISION
7774 Same as @code{REAL(KIND=2)}.
7776 @cindex DOUBLE COMPLEX type
7777 @cindex types, DOUBLE COMPLEX
7778 @item DOUBLE COMPLEX
7779 Same as @code{COMPLEX(KIND=2)}.
7782 Note that the above are proposed correspondences and might change
7783 in future versions of @code{g77}---avoid writing code depending
7786 Other types supported by @code{g77}
7787 are derived from gcc types such as @code{char}, @code{short},
7788 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7790 That is, whatever types @code{gcc} already supports, @code{g77} supports
7791 now or probably will support in a future version.
7792 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7793 apply to these types,
7794 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7795 assigned in a way that encourages clarity, consistency, and portability.
7797 @node Compiler Constants
7798 @section Compiler Constants
7800 @cindex types, constants
7802 @code{g77} strictly assigns types to @emph{all} constants not
7803 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7805 Many other Fortran compilers attempt to assign types to typed constants
7806 based on their context.
7807 This results in hard-to-find bugs, nonportable
7808 code, and is not in the spirit (though it strictly follows the letter)
7809 of the 77 and 90 standards.
7811 @code{g77} might offer, in a future release, explicit constructs by
7812 which a wider variety of typeless constants may be specified, and/or
7813 user-requested warnings indicating places where @code{g77} might differ
7814 from how other compilers assign types to constants.
7816 @xref{Context-Sensitive Constants}, for more information on this issue.
7818 @node Compiler Intrinsics
7819 @section Compiler Intrinsics
7821 @code{g77} offers an ever-widening set of intrinsics.
7822 Currently these all are procedures (functions and subroutines).
7824 Some of these intrinsics are unimplemented, but their names reserved
7825 to reduce future problems with existing code as they are implemented.
7826 Others are implemented as part of the GNU Fortran language, while
7827 yet others are provided for compatibility with other dialects of
7828 Fortran but are not part of the GNU Fortran language.
7830 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7831 a facility that is simply an extension of the intrinsic groups provided
7832 by the GNU Fortran language.
7835 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7836 * Other Intrinsics:: Intrinsics other than those in the GNU
7840 @node Intrinsic Groups
7841 @subsection Intrinsic Groups
7842 @cindex groups of intrinsics
7843 @cindex intrinsics, groups
7845 A given specific intrinsic belongs in one or more groups.
7846 Each group is deleted, disabled, hidden, or enabled
7847 by default or a command-line option.
7848 The meaning of each term follows.
7851 @cindex deleted intrinsics
7852 @cindex intrinsics, deleted
7854 No intrinsics are recognized as belonging to that group.
7856 @cindex disabled intrinsics
7857 @cindex intrinsics, disabled
7859 Intrinsics are recognized as belonging to the group, but
7860 references to them (other than via the @code{INTRINSIC} statement)
7861 are disallowed through that group.
7863 @cindex hidden intrinsics
7864 @cindex intrinsics, hidden
7866 Intrinsics in that group are recognized and enabled (if implemented)
7867 @emph{only} if the first mention of the actual name of an intrinsic
7868 in a program unit is in an @code{INTRINSIC} statement.
7870 @cindex enabled intrinsics
7871 @cindex intrinsics, enabled
7873 Intrinsics in that group are recognized and enabled (if implemented).
7876 The distinction between deleting and disabling a group is illustrated
7877 by the following example.
7878 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7879 If group @samp{FGR} is deleted, the following program unit will
7880 successfully compile, because @samp{FOO()} will be seen as a
7881 reference to an external function named @samp{FOO}:
7889 If group @samp{FGR} is disabled, compiling the above program will produce
7890 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7891 or, if properly invoked, it is not enabled.
7892 To change the above program so it references an external function @samp{FOO}
7893 instead of the disabled @samp{FOO} intrinsic,
7894 add the following line to the top:
7901 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7902 that group do not exist at all, whereas disabling it tells @code{g77} to
7903 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7905 Hiding a group is like enabling it, but the intrinsic must be first
7906 named in an @code{INTRINSIC} statement to be considered a reference to the
7907 intrinsic rather than to an external procedure.
7908 This might be the ``safest'' way to treat a new group of intrinsics
7910 code, because it allows the old code to be generally written as if
7911 those new intrinsics never existed, but to be changed to use them
7912 by inserting @code{INTRINSIC} statements in the appropriate places.
7913 However, it should be the goal of development to use @code{EXTERNAL}
7914 for all names of external procedures that might be intrinsic names.
7916 If an intrinsic is in more than one group, it is enabled if any of its
7917 containing groups are enabled; if not so enabled, it is hidden if
7918 any of its containing groups are hidden; if not so hidden, it is disabled
7919 if any of its containing groups are disabled; if not so disabled, it is
7921 This extra complication is necessary because some intrinsics,
7922 such as @code{IBITS}, belong to more than one group, and hence should be
7923 enabled if any of the groups to which they belong are enabled, and so
7928 @cindex intrinsics, groups of
7929 @cindex groups of intrinsics
7931 @cindex @code{badu77} intrinsics group
7933 UNIX intrinsics having inappropriate forms (usually functions that
7934 have intended side effects).
7936 @cindex @code{gnu} intrinsics group
7938 Intrinsics the GNU Fortran language supports that are extensions to
7939 the Fortran standards (77 and 90).
7941 @cindex @code{f2c} intrinsics group
7943 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
7945 @cindex @code{f90} intrinsics group
7947 Fortran 90 intrinsics.
7949 @cindex @code{mil} intrinsics group
7951 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
7953 @cindex @code{mil} intrinsics group
7955 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
7957 @cindex @code{mil} intrinsics group
7959 VAX/VMS FORTRAN (current as of v4) intrinsics.
7962 @node Other Intrinsics
7963 @subsection Other Intrinsics
7964 @cindex intrinsics, others
7965 @cindex other intrinsics
7967 @code{g77} supports intrinsics other than those in the GNU Fortran
7969 This set of intrinsics is described below.
7972 (Note that the empty lines appearing in the menu below
7973 are not intentional---they result from a bug in the
7974 @code{makeinfo} program.)
7977 @c The actual documentation for intrinsics comes from
7978 @c intdoc.texi, which in turn is automatically generated
7979 @c from the internal g77 tables in intrin.def _and_ the
7980 @c largely hand-written text in intdoc.h. So, if you want
7981 @c to change or add to existing documentation on intrinsics,
7982 @c you probably want to edit intdoc.h.
7994 @include intdoc.texi
7996 @node Other Compilers
7997 @chapter Other Compilers
7999 An individual Fortran source file can be compiled to
8000 an object (@file{*.o}) file instead of to the final
8002 This allows several portions of a program to be compiled
8003 at different times and linked together whenever a new
8004 version of the program is needed.
8005 However, it introduces the issue of @dfn{object compatibility}
8006 across the various object files (and libraries, or @file{*.a}
8007 files) that are linked together to produce any particular
8010 Object compatibility is an issue when combining, in one
8011 program, Fortran code compiled by more than one compiler
8012 (or more than one configuration of a compiler).
8014 disagree on how to transform the names of procedures, there
8015 will normally be errors when linking such programs.
8016 Worse, if the compilers agree on naming, but disagree on issues
8017 like how to pass parameters, return arguments, and lay out
8018 @code{COMMON} areas, the earliest detected errors might be the
8019 incorrect results produced by the program (and that assumes
8020 these errors are detected, which is not always the case).
8022 Normally, @code{g77} generates code that is
8023 object-compatible with code generated by a version of
8024 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
8025 to be generally compatible with @code{g77} as built by @code{gcc}.
8026 (Normally, @code{f2c} will, by default, conform to the appropriate
8027 configuration, but it is possible that older or perhaps even newer
8028 versions of @code{f2c}, or versions having certain configuration changes
8029 to @code{f2c} internals, will produce object files that are
8030 incompatible with @code{g77}.)
8032 For example, a Fortran string subroutine
8033 argument will become two arguments on the C side: a @code{char *}
8034 and an @code{int} length.
8036 Much of this compatibility results from the fact that
8037 @code{g77} uses the same run-time library,
8038 @code{libf2c}, used by @code{f2c},
8039 though @code{g77} gives its version the name @code{libg2c}
8040 so as to avoid conflicts when linking,
8041 installing them in the same directories,
8044 Other compilers might or might not generate code that
8045 is object-compatible with @code{libg2c} and current @code{g77},
8046 and some might offer such compatibility only when explicitly
8047 selected via a command-line option to the compiler.
8049 @emph{Note: This portion of the documentation definitely needs a lot
8053 * Dropping f2c Compatibility:: When speed is more important.
8054 * Compilers Other Than f2c:: Interoperation with code from other compilers.
8057 @node Dropping f2c Compatibility
8058 @section Dropping @code{f2c} Compatibility
8060 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
8061 some cases, faster code, by not needing to allow to the possibility
8062 of linking with code compiled by @code{f2c}.
8064 For example, this affects how @code{REAL(KIND=1)},
8065 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
8066 With @samp{-fno-f2c}, they are
8067 compiled as returning the appropriate @code{gcc} type
8068 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
8069 in many configurations).
8071 With @samp{-ff2c} in force, they
8072 are compiled differently (with perhaps slower run-time performance)
8073 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
8074 C as an intermediate language---@code{REAL(KIND=1)} functions
8075 return C's @code{double} type, while @code{COMPLEX} functions return
8076 @code{void} and use an extra argument pointing to a place for the functions to
8077 return their values.
8079 It is possible that, in some cases, leaving @samp{-ff2c} in force
8080 might produce faster code than using @samp{-fno-f2c}.
8081 Feel free to experiment, but remember to experiment with changing the way
8082 @emph{entire programs and their Fortran libraries are compiled} at
8083 a time, since this sort of experimentation affects the interface
8084 of code generated for a Fortran source file---that is, it affects
8085 object compatibility.
8087 Note that @code{f2c} compatibility is a fairly static target to achieve,
8088 though not necessarily perfectly so, since, like @code{g77}, it is
8089 still being improved.
8090 However, specifying @samp{-fno-f2c} causes @code{g77}
8091 to generate code that will probably be incompatible with code
8092 generated by future versions of @code{g77} when the same option
8094 You should make sure you are always able to recompile complete
8095 programs from source code when upgrading to new versions of @code{g77}
8096 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8098 Therefore, if you are using @code{g77} to compile libraries and other
8099 object files for possible future use and you don't want to require
8100 recompilation for future use with subsequent versions of @code{g77},
8101 you might want to stick with @code{f2c} compatibility for now, and
8102 carefully watch for any announcements about changes to the
8103 @code{f2c}/@code{libf2c} interface that might affect existing programs
8104 (thus requiring recompilation).
8106 It is probable that a future version of @code{g77} will not,
8107 by default, generate object files compatible with @code{f2c},
8108 and that version probably would no longer use @code{libf2c}.
8109 If you expect to depend on this compatibility in the
8110 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8111 all of the applicable code.
8112 This should cause future versions of @code{g77} either to produce
8113 compatible code (at the expense of the availability of some features and
8114 performance), or at the very least, to produce diagnostics.
8116 (The library @code{g77} produces will no longer be named @file{libg2c}
8117 when it is no longer generally compatible with @file{libf2c}.
8118 It will likely be referred to, and, if installed as a distinct
8119 library, named @code{libg77}, or some other as-yet-unused name.)
8121 @node Compilers Other Than f2c
8122 @section Compilers Other Than @code{f2c}
8124 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8125 code compiled by @code{g77} is not expected to work
8126 well with code compiled by the native compiler.
8127 (This is true for @code{f2c}-compiled objects as well.)
8128 Libraries compiled with the native compiler probably will have
8129 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8131 Reasons for such incompatibilities include:
8135 There might be differences in the way names of Fortran procedures
8136 are translated for use in the system's object-file format.
8137 For example, the statement @samp{CALL FOO} might be compiled
8138 by @code{g77} to call a procedure the linker @code{ld} sees
8139 given the name @samp{_foo_}, while the apparently corresponding
8140 statement @samp{SUBROUTINE FOO} might be compiled by the
8141 native compiler to define the linker-visible name @samp{_foo},
8142 or @samp{_FOO_}, and so on.
8145 There might be subtle type mismatches which cause subroutine arguments
8146 and function return values to get corrupted.
8148 This is why simply getting @code{g77} to
8149 transform procedure names the same way a native
8150 compiler does is not usually a good idea---unless
8151 some effort has been made to ensure that, aside
8152 from the way the two compilers transform procedure
8153 names, everything else about the way they generate
8154 code for procedure interfaces is identical.
8158 use libraries of private I/O routines which will not be available
8159 at link time unless you have the native compiler---and you would
8160 have to explicitly ask for them.
8162 For example, on the Sun you
8163 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8167 @node Other Languages
8168 @chapter Other Languages
8170 @emph{Note: This portion of the documentation definitely needs a lot
8174 * Interoperating with C and C++::
8177 @node Interoperating with C and C++
8178 @section Tools and advice for interoperating with C and C++
8180 @cindex C, linking with
8181 @cindex C++, linking with
8182 @cindex linking with C
8183 The following discussion assumes that you are running @code{g77} in @code{f2c}
8184 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8186 advice about quick and simple techniques for linking Fortran and C (or
8187 C++), the most common requirement.
8188 For the full story consult the
8189 description of code generation.
8190 @xref{Debugging and Interfacing}.
8192 When linking Fortran and C, it's usually best to use @code{g77} to do
8193 the linking so that the correct libraries are included (including the
8195 If you're linking with C++ you will want to add
8196 @samp{-lstdc++}, @samp{-lg++} or whatever.
8197 If you need to use another
8198 driver program (or @code{ld} directly),
8199 you can find out what linkage
8200 options @code{g77} passes by running @samp{g77 -v}.
8203 * C Interfacing Tools::
8204 * C Access to Type Information::
8205 * f2c Skeletons and Prototypes::
8206 * C++ Considerations::
8210 @node C Interfacing Tools
8211 @subsection C Interfacing Tools
8215 Even if you don't actually use it as a compiler, @code{f2c} from
8216 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8217 interfacing (linking) Fortran and C@.
8218 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8220 To use @code{f2c} for this purpose you only need retrieve and
8221 build the @file{src} directory from the distribution, consult the
8222 @file{README} instructions there for machine-specifics, and install the
8223 @code{f2c} program on your path.
8225 Something else that might be useful is @samp{cfortran.h} from
8226 @uref{ftp://zebra/desy.de/cfortran}.
8227 This is a fairly general tool which
8228 can be used to generate interfaces for calling in both directions
8229 between Fortran and C@.
8230 It can be used in @code{f2c} mode with
8231 @code{g77}---consult its documentation for details.
8233 @node C Access to Type Information
8234 @subsection Accessing Type Information in C
8236 @cindex types, Fortran/C
8237 Generally, C code written to link with
8238 @code{g77} code---calling and/or being
8239 called from Fortran---should @samp{#include <g2c.h>} to define the C
8240 versions of the Fortran types.
8241 Don't assume Fortran @code{INTEGER} types
8242 correspond to C @code{int}s, for instance; instead, declare them as
8243 @code{integer}, a type defined by @file{g2c.h}.
8244 @file{g2c.h} is installed where @code{gcc} will find it by
8245 default, assuming you use a copy of @code{gcc} compatible with
8246 @code{g77}, probably built at the same time as @code{g77}.
8248 @node f2c Skeletons and Prototypes
8249 @subsection Generating Skeletons and Prototypes with @code{f2c}
8252 @cindex -fno-second-underscore
8253 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8254 interface with an existing library---is to write a file (named, for
8255 example, @file{fred.f}) of dummy Fortran
8256 skeletons comprising just the declaration of the routine(s) and dummy
8257 arguments plus @code{END} statements.
8258 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8259 into which you can edit
8260 useful code, confident the calling sequence is correct, at least.
8261 (There are some errors otherwise commonly made in generating C
8262 interfaces with @code{f2c} conventions,
8263 such as not using @code{doublereal}
8264 as the return type of a @code{REAL} @code{FUNCTION}.)
8267 @code{f2c} also can help with calling Fortran from C, using its
8268 @samp{-P} option to generate C prototypes appropriate for calling the
8269 Fortran.@footnote{The files generated like this can also be used for
8270 inter-unit consistency checking of dummy and actual arguments, although
8271 the @code{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8272 or @uref{ftp://ftp.dsm.fordham.edu} is
8273 probably better for this purpose.}
8274 If the Fortran code containing any
8275 routines to be called from C is in file @file{joe.f}, use the command
8276 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8277 prototype information.
8278 @code{#include} this in the C which has to call
8279 the Fortran routines to make sure you get it right.
8281 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
8282 between the way Fortran (including compilers like @code{g77}) and
8285 @node C++ Considerations
8286 @subsection C++ Considerations
8289 @code{f2c} can be used to generate suitable code for compilation with a
8290 C++ system using the @samp{-C++} option.
8291 The important thing about linking @code{g77}-compiled
8292 code with C++ is that the prototypes for the @code{g77}
8293 routines must specify C linkage to avoid name mangling.
8294 So, use an @samp{extern "C"} declaration.
8295 @code{f2c}'s @samp{-C++} option will take care
8296 of this when generating skeletons or prototype files as above, and also
8297 avoid clashes with C++ reserved words in addition to those in C@.
8300 @subsection Startup Code
8302 @cindex startup code
8303 @cindex run-time, initialization
8304 @cindex initialization, run-time
8305 Unlike with some runtime systems,
8306 it shouldn't be necessary
8307 (unless there are bugs)
8308 to use a Fortran main program unit to ensure the
8309 runtime---specifically the I/O system---is initialized.
8311 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8312 either the @code{main} routine from the @file{libg2c} library must be used,
8313 or the @code{f_setarg} routine
8314 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8315 must be called with the appropriate @code{argc} and @code{argv} arguments
8316 prior to the program calling @code{GETARG} or @code{IARGC}.
8318 To provide more flexibility for mixed-language programming
8319 involving @code{g77} while allowing for shared libraries,
8320 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8321 @code{g77}'s @code{main} routine in @code{libg2c}
8322 does the following, in order:
8326 Calls @code{f_setarg}
8327 with the incoming @code{argc} and @code{argv} arguments,
8328 in the same order as for @code{main} itself.
8330 This sets up the command-line environment
8331 for @code{GETARG} and @code{IARGC}.
8334 Calls @code{f_setsig} (with no arguments).
8336 This sets up the signaling and exception environment.
8339 Calls @code{f_init} (with no arguments).
8341 This initializes the I/O environment,
8342 though that should not be necessary,
8343 as all I/O functions in @code{libf2c}
8344 are believed to call @code{f_init} automatically,
8347 (A future version of @code{g77} might skip this explicit step,
8348 to speed up normal exit of a program.)
8351 Arranges for @code{f_exit} to be called (with no arguments)
8352 when the program exits.
8354 This ensures that the I/O environment is properly shut down
8355 before the program exits normally.
8356 Otherwise, output buffers might not be fully flushed,
8357 scratch files might not be deleted, and so on.
8359 The simple way @code{main} does this is
8360 to call @code{f_exit} itself after calling
8361 @code{MAIN__} (in the next step).
8363 However, this does not catch the cases where the program
8364 might call @code{exit} directly,
8365 instead of using the @code{EXIT} intrinsic
8366 (implemented as @code{exit_} in @code{libf2c}).
8368 So, @code{main} attempts to use
8369 the operating environment's @code{onexit} or @code{atexit}
8370 facility, if available,
8371 to cause @code{f_exit} to be called automatically
8372 upon any invocation of @code{exit}.
8375 Calls @code{MAIN__} (with no arguments).
8377 This starts executing the Fortran main program unit for
8379 (Both @code{g77} and @code{f2c} currently compile a main
8380 program unit so that its global name is @code{MAIN__}.)
8383 If no @code{onexit} or @code{atexit} is provided by the system,
8384 calls @code{f_exit}.
8387 Calls @code{exit} with a zero argument,
8388 to signal a successful program termination.
8391 Returns a zero value to the caller,
8392 to signal a successful program termination,
8393 in case @code{exit} doesn't exit on the system.
8396 All of the above names are C @code{extern} names,
8399 When using the @code{main} procedure provided by @code{g77}
8400 without a Fortran main program unit,
8401 you need to provide @code{MAIN__}
8402 as the entry point for your C code.
8403 (Make sure you link the object file that defines that
8404 entry point with the rest of your program.)
8406 To provide your own @code{main} procedure
8407 in place of @code{g77}'s,
8408 make sure you specify the object file defining that procedure
8409 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8410 Since the @samp{-lg2c} option is implicitly provided,
8411 this is usually straightforward.
8412 (Use the @samp{--verbose} option to see how and where
8413 @code{g77} implicitly adds @samp{-lg2c} in a command line
8414 that will link the program.
8415 Feel free to specify @samp{-lg2c} explicitly,
8418 However, when providing your own @code{main},
8419 make sure you perform the appropriate tasks in the
8421 For example, if your @code{main} does not call @code{f_setarg},
8422 make sure the rest of your application does not call
8423 @code{GETARG} or @code{IARGC}.
8425 And, if your @code{main} fails to ensure that @code{f_exit}
8426 is called upon program exit,
8427 some files might end up incompletely written,
8428 some scratch files might be left lying around,
8429 and some existing files being written might be left
8430 with old data not properly truncated at the end.
8432 Note that, generally, the @code{g77} operating environment
8433 does not depend on a procedure named @code{MAIN__} actually
8434 being called prior to any other @code{g77}-compiled code.
8435 That is, @code{MAIN__} does not, itself,
8436 set up any important operating-environment characteristics
8437 upon which other code might depend.
8438 This might change in future versions of @code{g77},
8439 with appropriate notification in the release notes.
8441 For more information, consult the source code for the above routines.
8442 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8443 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8445 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8446 uses to open-code (inline) references to @code{IARGC}.
8448 @include g77install.texi
8450 @node Debugging and Interfacing
8451 @chapter Debugging and Interfacing
8454 @cindex calling C routines
8455 @cindex C routines calling Fortran
8456 @cindex f2c compatibility
8458 GNU Fortran currently generates code that is object-compatible with
8459 the @code{f2c} converter.
8460 Also, it avoids limitations in the current GBE, such as the
8461 inability to generate a procedure with
8462 multiple entry points, by generating code that is structured
8463 differently (in terms of procedure names, scopes, arguments, and
8464 so on) than might be expected.
8466 As a result, writing code in other languages that calls on, is
8467 called by, or shares in-memory data with @code{g77}-compiled code generally
8468 requires some understanding of the way @code{g77} compiles code for
8471 Similarly, using a debugger to debug @code{g77}-compiled
8472 code, even if that debugger supports native Fortran debugging, generally
8473 requires this sort of information.
8475 This section describes some of the basic information on how
8476 @code{g77} compiles code for constructs involving interfaces to other
8477 languages and to debuggers.
8479 @emph{Caution:} Much or all of this information pertains to only the current
8480 release of @code{g77}, sometimes even to using certain compiler options
8481 with @code{g77} (such as @samp{-fno-f2c}).
8482 Do not write code that depends on this
8483 information without clearly marking said code as nonportable and
8484 subject to review for every new release of @code{g77}.
8486 is provided primarily to make debugging of code generated by this
8487 particular release of @code{g77} easier for the user, and partly to make
8488 writing (generally nonportable) interface code easier.
8490 activities require tracking changes in new version of @code{g77} as they
8491 are installed, because new versions can change the behaviors
8492 described in this section.
8495 * Main Program Unit:: How @code{g77} compiles a main program unit.
8496 * Procedures:: How @code{g77} constructs parameter lists
8498 * Functions:: Functions returning floating-point or character data.
8499 * Names:: Naming of user-defined variables, procedures, etc.
8500 * Common Blocks:: Accessing common variables while debugging.
8501 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8502 * Complex Variables:: How @code{g77} performs complex arithmetic.
8503 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8504 * Adjustable Arrays:: Special consideration for adjustable arrays.
8505 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8506 * Alternate Returns:: How @code{g77} handles alternate returns.
8507 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8508 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8511 @node Main Program Unit
8512 @section Main Program Unit (PROGRAM)
8513 @cindex PROGRAM statement
8514 @cindex statements, PROGRAM
8516 When @code{g77} compiles a main program unit, it gives it the public
8517 procedure name @code{MAIN__}.
8518 The @code{libg2c} library has the actual @code{main()} procedure
8519 as is typical of C-based environments, and
8520 it is this procedure that performs some initial start-up
8521 activity and then calls @code{MAIN__}.
8523 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8524 include a main program unit written in Fortran in your program---it
8525 can be written in C or some other language.
8526 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8527 includes a bug fix for @code{libg2c} that solved a problem with using the
8528 @code{OPEN} statement as the first Fortran I/O activity in a program
8529 without a Fortran main program unit.
8531 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8532 your main program unit---that is, if you intend to compile a @code{main()}
8533 procedure using some other language---you should carefully
8534 examine the code for @code{main()} in @code{libg2c}, found in the source
8535 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8536 might need to be done by your @code{main()} in order to provide the
8537 Fortran environment your Fortran code is expecting.
8539 @cindex @code{IArgC} intrinsic
8540 @cindex intrinsics, @code{IArgC}
8541 @cindex @code{GetArg} intrinsic
8542 @cindex intrinsics, @code{GetArg}
8543 For example, @code{libg2c}'s @code{main()} sets up the information used by
8544 the @code{IARGC} and @code{GETARG} intrinsics.
8545 Bypassing @code{libg2c}'s @code{main()}
8546 without providing a substitute for this activity would mean
8547 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8551 @cindex main program unit, debugging
8555 When debugging, one implication of the fact that @code{main()}, which
8556 is the place where the debugged program ``starts'' from the
8557 debugger's point of view, is in @code{libg2c} is that you won't be
8558 starting your Fortran program at a point you recognize as your
8561 The standard way to get around this problem is to set a break
8562 point (a one-time, or temporary, break point will do) at
8563 the entrance to @code{MAIN__}, and then run the program.
8564 A convenient way to do so is to add the @code{gdb} command
8571 to the file @file{.gdbinit} in the directory in which you're debugging
8574 After doing this, the debugger will see the current execution
8575 point of the program as at the beginning of the main program
8576 unit of your program.
8578 Of course, if you really want to set a break point at some
8579 other place in your program and just start the program
8580 running, without first breaking at @code{MAIN__},
8581 that should work fine.
8584 @section Procedures (SUBROUTINE and FUNCTION)
8586 @cindex SUBROUTINE statement
8587 @cindex statements, SUBROUTINE
8588 @cindex FUNCTION statement
8589 @cindex statements, FUNCTION
8590 @cindex signature of procedures
8592 Currently, @code{g77} passes arguments via reference---specifically,
8593 by passing a pointer to the location in memory of a variable, array,
8594 array element, a temporary location that holds the result of evaluating an
8595 expression, or a temporary or permanent location that holds the value
8598 Procedures that accept @code{CHARACTER} arguments are implemented by
8599 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8601 The first argument occupies the expected position in the
8602 argument list and has the user-specified name.
8604 is a pointer to an array of characters, passed by the caller.
8606 The second argument is appended to the end of the user-specified
8607 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8608 is the user-specified name.
8609 This argument is of the C type @code{ftnlen}
8610 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8611 is the number of characters the caller has allocated in the
8612 array pointed to by the first argument.
8614 A procedure will ignore the length argument if @samp{X} is not declared
8615 @code{CHARACTER*(*)}, because for other declarations, it knows the
8617 Not all callers necessarily ``know'' this, however, which
8618 is why they all pass the extra argument.
8620 The contents of the @code{CHARACTER} argument are specified by the
8621 address passed in the first argument (named after it).
8622 The procedure can read or write these contents as appropriate.
8624 When more than one @code{CHARACTER} argument is present in the argument
8625 list, the length arguments are appended in the order
8626 the original arguments appear.
8627 So @samp{CALL FOO('HI','THERE')} is implemented in
8628 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8629 does not provide the trailing null bytes on the constant
8630 strings (@code{f2c} does provide them, but they are unnecessary in
8631 a Fortran environment, and you should not expect them to be
8634 Note that the above information applies to @code{CHARACTER} variables and
8635 arrays @strong{only}.
8636 It does @strong{not} apply to external @code{CHARACTER}
8637 functions or to intrinsic @code{CHARACTER} functions.
8638 That is, no second length argument is passed to @samp{FOO} in this case:
8647 Nor does @samp{FOO} expect such an argument in this case:
8655 Because of this implementation detail, if a program has a bug
8656 such that there is disagreement as to whether an argument is
8657 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8658 symptoms might appear.
8661 @section Functions (FUNCTION and RETURN)
8663 @cindex FUNCTION statement
8664 @cindex statements, FUNCTION
8665 @cindex RETURN statement
8666 @cindex statements, RETURN
8667 @cindex return type of functions
8669 @code{g77} handles in a special way functions that return the following
8681 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8682 returning @code{void})
8683 with two arguments prepended: @samp{__g77_result}, which the caller passes
8684 as a pointer to a @code{char} array expected to hold the return value,
8685 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8686 specifying the length of the return value as declared in the calling
8688 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8689 to determine the size of the array that @samp{__g77_result} points to;
8690 otherwise, it ignores that argument.
8692 For @code{COMPLEX}, when @samp{-ff2c} is in
8693 force, @code{g77} implements
8694 a subroutine with one argument prepended: @samp{__g77_result}, which the
8695 caller passes as a pointer to a variable of the type of the function.
8696 The called function writes the return value into this variable instead
8697 of returning it as a function value.
8698 When @samp{-fno-f2c} is in force,
8699 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8700 @samp{__complex__ float} or @samp{__complex__ double} function
8701 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8702 returning the result of the function in the same way as @code{gcc} would.
8704 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8705 a function that actually returns @code{REAL(KIND=2)} (typically
8706 C's @code{double} type).
8707 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8708 functions return @code{float}.
8712 @cindex symbol names
8713 @cindex transforming symbol names
8715 Fortran permits each implementation to decide how to represent
8716 names as far as how they're seen in other contexts, such as debuggers
8717 and when interfacing to other languages, and especially as far
8718 as how casing is handled.
8720 External names---names of entities that are public, or ``accessible'',
8721 to all modules in a program---normally have an underscore (@samp{_})
8722 appended by @code{g77},
8723 to generate code that is compatible with @code{f2c}.
8724 External names include names of Fortran things like common blocks,
8725 external procedures (subroutines and functions, but not including
8726 statement functions, which are internal procedures), and entry point
8729 However, use of the @samp{-fno-underscoring} option
8730 disables this kind of transformation of external names (though inhibiting
8731 the transformation certainly improves the chances of colliding with
8732 incompatible externals written in other languages---but that
8733 might be intentional.
8735 @cindex -fno-underscoring option
8736 @cindex options, -fno-underscoring
8737 @cindex -fno-second-underscore option
8738 @cindex options, -fno-underscoring
8739 When @samp{-funderscoring} is in force, any name (external or local)
8740 that already has at least one underscore in it is
8741 implemented by @code{g77} by appending two underscores.
8742 (This second underscore can be disabled via the
8743 @samp{-fno-second-underscore} option.)
8744 External names are changed this way for @code{f2c} compatibility.
8745 Local names are changed this way to avoid collisions with external names
8746 that are different in the source code---@code{f2c} does the same thing, but
8747 there's no compatibility issue there except for user expectations while
8758 Here, a user would, in the debugger, refer to this variable using the
8759 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8760 as described below).
8761 (We hope to improve @code{g77} in this regard in the future---don't
8762 write scripts depending on this behavior!
8763 Also, consider experimenting with the @samp{-fno-underscoring}
8764 option to try out debugging without having to massage names by
8767 @code{g77} provides a number of command-line options that allow the user
8768 to control how case mapping is handled for source files.
8769 The default is the traditional UNIX model for Fortran compilers---names
8770 are mapped to lower case.
8771 Other command-line options can be specified to map names to upper
8772 case, or to leave them exactly as written in the source file.
8781 Here, it is normally the case that the variable assigned will be named
8783 This would be the name to enter when using a debugger to
8784 access the variable.
8786 However, depending on the command-line options specified, the
8787 name implemented by @code{g77} might instead be @samp{FOO} or even
8788 @samp{Foo}, thus affecting how debugging is done.
8797 This would normally call a procedure that, if it were in a separate C program,
8798 be defined starting with the line:
8805 However, @code{g77} command-line options could be used to change the casing
8806 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8807 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8808 could be used to inhibit the appending of the underscore to the name.
8811 @section Common Blocks (COMMON)
8812 @cindex common blocks
8813 @cindex @code{COMMON} statement
8814 @cindex statements, @code{COMMON}
8816 @code{g77} names and lays out @code{COMMON} areas
8817 the same way @code{f2c} does,
8818 for compatibility with @code{f2c}.
8820 Currently, @code{g77} does not emit ``true'' debugging information for
8821 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8823 (As of Version 0.5.19, @code{g77} emits debugging information for such
8824 members in the form of a constant string specifying the base name of
8825 the aggregate area and the offset of the member in bytes from the start
8827 Use the @samp{-fdebug-kludge} option to enable this behavior.
8828 In @code{gdb}, use @samp{set language c} before printing the value
8829 of the member, then @samp{set language fortran} to restore the default
8830 language, since @code{gdb} doesn't provide a way to print a readable
8831 version of a character string in Fortran language mode.
8833 This kludge will be removed in a future version of @code{g77} that,
8834 in conjunction with a contemporary version of @code{gdb},
8835 properly supports Fortran-language debugging, including access
8836 to members of @code{COMMON} areas.)
8838 @xref{Code Gen Options,,Options for Code Generation Conventions},
8839 for information on the @samp{-fdebug-kludge} option.
8841 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8842 type is an array of the C @code{char} data type.
8844 So, when debugging, you must know the offset into a @code{COMMON} area
8845 for a particular item in that area, and you have to take into
8846 account the appropriate multiplier for the respective sizes
8847 of the types (as declared in your code) for the items preceding
8848 the item in question as compared to the size of the @code{char} type.
8850 For example, using default implicit typing, the statement
8853 COMMON I(15), R(20), T
8857 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8858 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8859 and @samp{T} at @samp{_BLNK__[140]}.
8860 (This is assuming that the target machine for
8861 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8864 @node Local Equivalence Areas
8865 @section Local Equivalence Areas (EQUIVALENCE)
8866 @cindex equivalence areas
8867 @cindex local equivalence areas
8868 @cindex EQUIVALENCE statement
8869 @cindex statements, EQUIVALENCE
8871 @code{g77} treats storage-associated areas involving a @code{COMMON}
8872 block as explained in the section on common blocks.
8874 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8875 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8876 listed in a @code{COMMON} statement.
8878 Currently, @code{g77} does not emit ``true'' debugging information for
8879 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8881 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8882 members in the form of a constant string specifying the base name of
8883 the aggregate area and the offset of the member in bytes from the start
8885 Use the @samp{-fdebug-kludge} option to enable this behavior.
8886 In @code{gdb}, use @samp{set language c} before printing the value
8887 of the member, then @samp{set language fortran} to restore the default
8888 language, since @code{gdb} doesn't provide a way to print a readable
8889 version of a character string in Fortran language mode.
8891 This kludge will be removed in a future version of @code{g77} that,
8892 in conjunction with a contemporary version of @code{gdb},
8893 properly supports Fortran-language debugging, including access
8894 to members of @code{EQUIVALENCE} areas.)
8896 @xref{Code Gen Options,,Options for Code Generation Conventions},
8897 for information on the @samp{-fdebug-kludge} option.
8899 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8900 type is an array of the C @code{char} data type.
8902 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8903 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8905 If more than one such item is placed at the beginning, @var{x} is
8906 the name that sorts to the top in an alphabetical sort of the list of
8909 When debugging, you must therefore access members of @code{EQUIVALENCE}
8910 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8911 array section with the appropriate offset.
8912 See the explanation of debugging @code{COMMON} blocks
8913 for info applicable to debugging local @code{EQUIVALENCE} areas.
8915 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8916 for @var{x} using a different method when more than one name was
8917 in the list of names of entities placed at the beginning of the
8919 Though the documentation specified that the first name listed in
8920 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8921 in fact chose the name using a method that was so complicated,
8922 it seemed easier to change it to an alphabetical sort than to describe the
8923 previous method in the documentation.)
8925 @node Complex Variables
8926 @section Complex Variables (COMPLEX)
8927 @cindex complex variables
8928 @cindex imaginary part
8929 @cindex COMPLEX statement
8930 @cindex statements, COMPLEX
8932 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8933 (and related intrinsics, constants, functions, and so on)
8935 makes direct debugging involving these types in Fortran
8936 language mode difficult.
8938 Essentially, @code{g77} implements these types using an
8939 internal construct similar to C's @code{struct}, at least
8940 as seen by the @code{gcc} back end.
8942 Currently, the back end, when outputting debugging info with
8943 the compiled code for the assembler to digest, does not detect
8944 these @code{struct} types as being substitutes for Fortran
8946 As a result, the Fortran language modes of debuggers such as
8947 @code{gdb} see these types as C @code{struct} types, which
8948 they might or might not support.
8950 Until this is fixed, switch to C language mode to work with
8951 entities of @code{COMPLEX} type and then switch back to Fortran language
8953 (In @code{gdb}, this is accomplished via @samp{set lang c} and
8954 either @samp{set lang fortran} or @samp{set lang auto}.)
8957 @section Arrays (DIMENSION)
8958 @cindex DIMENSION statement
8959 @cindex statements, DIMENSION
8960 @cindex array ordering
8961 @cindex ordering, array
8962 @cindex column-major ordering
8963 @cindex row-major ordering
8966 Fortran uses ``column-major ordering'' in its arrays.
8967 This differs from other languages, such as C, which use ``row-major ordering''.
8968 The difference is that, with Fortran, array elements adjacent to
8969 each other in memory differ in the @emph{first} subscript instead of
8970 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
8971 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
8974 affects not only interfacing with and debugging Fortran code,
8975 it can greatly affect how code is designed and written, especially
8976 when code speed and size is a concern.
8978 Fortran also differs from C, a popular language for interfacing and
8979 to support directly in debuggers, in the way arrays are treated.
8980 In C, arrays are single-dimensional and have interesting relationships
8981 to pointers, neither of which is true for Fortran.
8982 As a result, dealing with Fortran arrays from within
8983 an environment limited to C concepts can be challenging.
8985 For example, accessing the array element @samp{A(5,10,20)} is easy enough
8986 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
8988 First, C would treat the A array as a single-dimension array.
8989 Second, C does not understand low bounds for arrays as does Fortran.
8990 Third, C assumes a low bound of zero (0), while Fortran defaults to a
8991 low bound of one (1) and can supports an arbitrary low bound.
8992 Therefore, calculations must be done
8993 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
8994 calculations require knowing the dimensions of @samp{A}.
8996 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
8997 @samp{A(5,10,20)} would be:
9002 + (20-0)*(11-2+1)*(21-1+1)
9007 So the C equivalent in this case would be @samp{a[4293]}.
9009 When using a debugger directly on Fortran code, the C equivalent
9010 might not work, because some debuggers cannot understand the notion
9011 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
9012 does inform the GBE that a multi-dimensional array (like @samp{A}
9013 in the above example) is really multi-dimensional, rather than a
9014 single-dimensional array, so at least the dimensionality of the array
9017 Debuggers that understand Fortran should have no trouble with
9018 non-zero low bounds, but for non-Fortran debuggers, especially
9019 C debuggers, the above example might have a C equivalent of
9021 This calculation is arrived at by eliminating the subtraction
9022 of the lower bound in the first parenthesized expression on each
9023 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
9024 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
9025 Actually, the implication of
9026 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
9027 but that @samp{a[20][10][5]} produces the equivalent of
9028 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
9030 Come to think of it, perhaps
9031 the behavior is due to the debugger internally compensating for
9032 the lower bounds by offsetting the base address of @samp{a}, leaving
9033 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
9034 its first element as identified by subscripts equal to the
9035 corresponding lower bounds).
9037 You know, maybe nobody really needs to use arrays.
9039 @node Adjustable Arrays
9040 @section Adjustable Arrays (DIMENSION)
9041 @cindex arrays, adjustable
9042 @cindex adjustable arrays
9043 @cindex arrays, automatic
9044 @cindex automatic arrays
9045 @cindex DIMENSION statement
9046 @cindex statements, DIMENSION
9047 @cindex dimensioning arrays
9048 @cindex arrays, dimensioning
9050 Adjustable and automatic arrays in Fortran require the implementation
9052 case, the @code{g77} compiler) to ``memorize'' the expressions that
9053 dimension the arrays each time the procedure is invoked.
9054 This is so that subsequent changes to variables used in those
9055 expressions, made during execution of the procedure, do not
9056 have any effect on the dimensions of those arrays.
9073 Here, the implementation should, when running the program, print something
9081 Note that this shows that while the value of @samp{N} was successfully
9082 changed, the size of the @samp{A} array remained at 5 elements.
9084 To support this, @code{g77} generates code that executes before any user
9085 code (and before the internally generated computed @code{GOTO} to handle
9086 alternate entry points, as described below) that evaluates each
9087 (nonconstant) expression in the list of subscripts for an
9088 array, and saves the result of each such evaluation to be used when
9089 determining the size of the array (instead of re-evaluating the
9092 So, in the above example, when @samp{X} is first invoked, code is
9093 executed that copies the value of @samp{N} to a temporary.
9094 And that same temporary serves as the actual high bound for the single
9095 dimension of the @samp{A} array (the low bound being the constant 1).
9096 Since the user program cannot (legitimately) change the value
9097 of the temporary during execution of the procedure, the size
9098 of the array remains constant during each invocation.
9100 For alternate entry points, the code @code{g77} generates takes into
9101 account the possibility that a dummy adjustable array is not actually
9102 passed to the actual entry point being invoked at that time.
9103 In that case, the public procedure implementing the entry point
9104 passes to the master private procedure implementing all the
9105 code for the entry points a @code{NULL} pointer where a pointer to that
9106 adjustable array would be expected.
9107 The @code{g77}-generated code
9108 doesn't attempt to evaluate any of the expressions in the subscripts
9109 for an array if the pointer to that array is @code{NULL} at run time in
9111 (Don't depend on this particular implementation
9112 by writing code that purposely passes @code{NULL} pointers where the
9113 callee expects adjustable arrays, even if you know the callee
9114 won't reference the arrays---nor should you pass @code{NULL} pointers
9115 for any dummy arguments used in calculating the bounds of such
9116 arrays or leave undefined any values used for that purpose in
9117 COMMON---because the way @code{g77} implements these things might
9118 change in the future!)
9120 @node Alternate Entry Points
9121 @section Alternate Entry Points (ENTRY)
9122 @cindex alternate entry points
9123 @cindex entry points
9124 @cindex ENTRY statement
9125 @cindex statements, ENTRY
9127 The GBE does not understand the general concept of
9128 alternate entry points as Fortran provides via the ENTRY statement.
9129 @code{g77} gets around this by using an approach to compiling procedures
9130 having at least one @code{ENTRY} statement that is almost identical to the
9131 approach used by @code{f2c}.
9132 (An alternate approach could be used that
9133 would probably generate faster, but larger, code that would also
9134 be a bit easier to debug.)
9136 Information on how @code{g77} implements @code{ENTRY} is provided for those
9137 trying to debug such code.
9138 The choice of implementation seems
9139 unlikely to affect code (compiled in other languages) that interfaces
9142 @code{g77} compiles exactly one public procedure for the primary entry
9143 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9144 That is, in terms of the public interface, there is no difference
9163 The difference between the above two cases lies in the code compiled
9164 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9165 for the second case, an extra internal procedure is compiled.
9167 For every Fortran procedure with at least one @code{ENTRY}
9168 statement, @code{g77} compiles an extra procedure
9169 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9170 the name of the primary entry point (which, in the above case,
9171 using the standard compiler options, would be @samp{x_} in C).
9173 This extra procedure is compiled as a private procedure---that is,
9174 a procedure not accessible by name to separately compiled modules.
9175 It contains all the code in the program unit, including the code
9176 for the primary entry point plus for every entry point.
9177 (The code for each public procedure is quite short, and explained later.)
9179 The extra procedure has some other interesting characteristics.
9181 The argument list for this procedure is invented by @code{g77}.
9183 a single integer argument named @samp{__g77_which_entrypoint},
9184 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9185 entry point index---0 for the primary entry point, 1 for the
9186 first entry point (the first @code{ENTRY} statement encountered), 2 for
9187 the second entry point, and so on.
9189 It also contains, for functions returning @code{CHARACTER} and
9190 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9191 and for functions returning different types among the
9192 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9193 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9194 is expected at run time to contain a pointer to where to store
9195 the result of the entry point.
9196 For @code{CHARACTER} functions, this
9197 storage area is an array of the appropriate number of characters;
9198 for @code{COMPLEX} functions, it is the appropriate area for the return
9199 type; for multiple-return-type functions, it is a union of all the supported return
9200 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9201 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9202 is not supported by @code{g77}).
9204 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9205 by yet another argument named @samp{__g77_length} that, at run time,
9206 specifies the caller's expected length of the returned value.
9207 Note that only @code{CHARACTER*(*)} functions and entry points actually
9208 make use of this argument, even though it is always passed by
9209 all callers of public @code{CHARACTER} functions (since the caller does not
9210 generally know whether such a function is @code{CHARACTER*(*)} or whether
9211 there are any other callers that don't have that information).
9213 The rest of the argument list is the union of all the arguments
9214 specified for all the entry points (in their usual forms, e.g.
9215 @code{CHARACTER} arguments have extra length arguments, all appended at
9216 the end of this list).
9217 This is considered the ``master list'' of
9220 The code for this procedure has, before the code for the first
9221 executable statement, code much like that for the following Fortran
9225 GOTO (100000,100001,100002), __g77_which_entrypoint
9226 100000 @dots{}code for primary entry point@dots{}
9227 100001 @dots{}code immediately following first ENTRY statement@dots{}
9228 100002 @dots{}code immediately following second ENTRY statement@dots{}
9232 (Note that invalid Fortran statement labels and variable names
9233 are used in the above example to highlight the fact that it
9234 represents code generated by the @code{g77} internals, not code to be
9235 written by the user.)
9237 It is this code that, when the procedure is called, picks which
9238 entry point to start executing.
9240 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9241 example), those procedures are fairly simple.
9243 are just like they would be if they were self-contained procedures
9244 (without @code{ENTRY}), of course, since that is what the callers
9246 Their code consists of simply calling the private
9247 procedure, described above, with the appropriate extra arguments
9248 (the entry point index, and perhaps a pointer to a multiple-type-
9249 return variable, local to the public procedure, that contains
9250 all the supported returnable non-character types).
9252 that are not listed for a given entry point that are listed for
9253 other entry points, and therefore that are in the ``master list''
9254 for the private procedure, null pointers (in C, the @code{NULL} macro)
9256 Also, for entry points that are part of a multiple-type-
9257 returning function, code is compiled after the call of the private
9258 procedure to extract from the multi-type union the appropriate result,
9259 depending on the type of the entry point in question, returning
9260 that result to the original caller.
9262 When debugging a procedure containing alternate entry points, you
9263 can either set a break point on the public procedure itself (e.g.
9264 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9265 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9266 If you do the former, you should use the debugger's command to
9267 ``step into'' the called procedure to get to the actual code; with
9268 the latter approach, the break point leaves you right at the
9269 actual code, skipping over the public entry point and its call
9270 to the private procedure (unless you have set a break point there
9271 as well, of course).
9273 Further, the list of dummy arguments that is visible when the
9274 private procedure is active is going to be the expanded version
9275 of the list for whichever particular entry point is active,
9276 as explained above, and the way in which return values are
9277 handled might well be different from how they would be handled
9278 for an equivalent single-entry function.
9280 @node Alternate Returns
9281 @section Alternate Returns (SUBROUTINE and RETURN)
9283 @cindex alternate returns
9284 @cindex SUBROUTINE statement
9285 @cindex statements, SUBROUTINE
9286 @cindex RETURN statement
9287 @cindex statements, RETURN
9289 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9290 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9291 the C @code{int} type.
9292 The actual alternate-return arguments are omitted from the calling sequence.
9293 Instead, the caller uses
9294 the return value to do a rough equivalent of the Fortran
9295 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9296 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9297 function), and the callee just returns whatever integer
9298 is specified in the @code{RETURN} statement for the subroutine
9299 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9301 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9303 @node Assigned Statement Labels
9304 @section Assigned Statement Labels (ASSIGN and GOTO)
9305 @cindex assigned statement labels
9306 @cindex statement labels, assigned
9307 @cindex ASSIGN statement
9308 @cindex statements, ASSIGN
9309 @cindex GOTO statement
9310 @cindex statements, GOTO
9312 For portability to machines where a pointer (such as to a label,
9313 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9314 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9315 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9316 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9317 than it does the numerical value in that variable, unless the
9318 variable is wide enough (can hold enough bits).
9320 In particular, while @code{g77} implements
9327 as, in C notation, @samp{i = 10;}, it implements
9334 as, in GNU's extended C notation (for the label syntax),
9335 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9336 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9337 actually generate the name @samp{L10} or any other name like that,
9338 since debuggers cannot access labels anyway).
9340 While this currently means that an @code{ASSIGN} statement does not
9341 overwrite the numeric contents of its target variable, @emph{do not}
9342 write any code depending on this feature.
9343 @code{g77} has already changed this implementation across
9344 versions and might do so in the future.
9345 This information is provided only to make debugging Fortran programs
9346 compiled with the current version of @code{g77} somewhat easier.
9347 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9348 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9349 means @code{g77} has decided it can store the pointer to the label directly
9350 into @samp{I} itself.
9352 @xref{Ugly Assigned Labels}, for information on a command-line option
9353 to force @code{g77} to use the same storage for both normal and
9354 assigned-label uses of a variable.
9356 @node Run-time Library Errors
9357 @section Run-time Library Errors
9359 @cindex error values
9360 @cindex error messages
9361 @cindex messages, run-time
9364 The @code{libg2c} library currently has the following table to relate
9365 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9366 This information should, in future versions of this document, be
9367 expanded upon to include detailed descriptions of each message.
9369 In line with good coding practices, any of the numbers in the
9370 list below should @emph{not} be directly written into Fortran
9372 Instead, make a separate @code{INCLUDE} file that defines
9373 @code{PARAMETER} names for them, and use those in your code,
9374 so you can more easily change the actual numbers in the future.
9376 The information below is culled from the definition
9377 of @code{F_err} in @file{f/runtime/libI77/err.c} in the
9378 @code{g77} source tree.
9381 100: "error in format"
9382 101: "illegal unit number"
9383 102: "formatted io not allowed"
9384 103: "unformatted io not allowed"
9385 104: "direct io not allowed"
9386 105: "sequential io not allowed"
9387 106: "can't backspace file"
9388 107: "null file name"
9389 108: "can't stat file"
9390 109: "unit not connected"
9391 110: "off end of record"
9392 111: "truncation failed in endfile"
9393 112: "incomprehensible list input"
9394 113: "out of free space"
9395 114: "unit not connected"
9396 115: "read unexpected character"
9397 116: "bad logical input field"
9398 117: "bad variable type"
9399 118: "bad namelist name"
9400 119: "variable not in namelist"
9401 120: "no end record"
9402 121: "variable count incorrect"
9403 122: "subscript for scalar variable"
9404 123: "invalid array section"
9405 124: "substring out of bounds"
9406 125: "subscript out of bounds"
9407 126: "can't read file"
9408 127: "can't write file"
9409 128: "'new' file exists"
9410 129: "can't append to file"
9411 130: "non-positive record number"
9412 131: "I/O started while already doing I/O"
9415 @node Collected Fortran Wisdom
9416 @chapter Collected Fortran Wisdom
9419 @cindex code, legacy
9420 @cindex writing code
9421 @cindex code, writing
9423 Most users of @code{g77} can be divided into two camps:
9427 Those writing new Fortran code to be compiled by @code{g77}.
9430 Those using @code{g77} to compile existing, ``legacy'' code.
9433 Users writing new code generally understand most of the necessary
9434 aspects of Fortran to write ``mainstream'' code, but often need
9435 help deciding how to handle problems, such as the construction
9436 of libraries containing @code{BLOCK DATA}.
9438 Users dealing with ``legacy'' code sometimes don't have much
9439 experience with Fortran, but believe that the code they're compiling
9440 already works when compiled by other compilers (and might
9441 not understand why, as is sometimes the case, it doesn't work
9442 when compiled by @code{g77}).
9444 The following information is designed to help users do a better job
9445 coping with existing, ``legacy'' Fortran code, and with writing
9449 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9450 * Block Data and Libraries:: How @code{g77} solves a common problem.
9451 * Loops:: Fortran @code{DO} loops surprise many people.
9452 * Working Programs:: Getting programs to work should be done first.
9453 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9454 * Faster Programs:: Everybody wants these, but at what cost?
9457 @node Advantages Over f2c
9458 @section Advantages Over f2c
9460 Without @code{f2c}, @code{g77} would have taken much longer to
9461 do and probably not been as good for quite a while.
9462 Sometimes people who notice how much @code{g77} depends on, and
9463 documents encouragement to use, @code{f2c} ask why @code{g77}
9464 was created if @code{f2c} already existed.
9466 This section gives some basic answers to these questions, though it
9467 is not intended to be comprehensive.
9470 * Language Extensions:: Features used by Fortran code.
9471 * Compiler Options:: Features helpful during development.
9472 * Compiler Speed:: Speed of the compilation process.
9473 * Program Speed:: Speed of the generated, optimized code.
9474 * Ease of Debugging:: Debugging ease-of-use at the source level.
9475 * Character and Hollerith Constants:: A byte saved is a byte earned.
9478 @node Language Extensions
9479 @subsection Language Extensions
9481 @code{g77} offers several extensions to the Fortran language that @code{f2c}
9484 However, @code{f2c} offers a few that @code{g77} doesn't, like
9485 fairly complete support for @code{INTEGER*2}.
9486 It is expected that @code{g77} will offer some or all of these missing
9487 features at some time in the future.
9488 (Version 0.5.18 of @code{g77} offers some rudimentary support for some
9491 @node Compiler Options
9492 @subsection Compiler Options
9494 @code{g77} offers a whole bunch of compiler options that @code{f2c} doesn't.
9496 However, @code{f2c} offers a few that @code{g77} doesn't,
9497 like an option to have @code{REAL} default to @code{REAL*8}.
9498 It is expected that @code{g77} will offer all of the
9499 missing options pertinent to being a Fortran compiler
9500 at some time in the future.
9502 @node Compiler Speed
9503 @subsection Compiler Speed
9505 Saving the steps of writing and then rereading C code is a big reason
9506 why @code{g77} should be able to compile code much faster than using
9507 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9509 However, due to @code{g77}'s youth, lots of self-checking is still being
9511 As a result, this improvement is as yet unrealized
9512 (though the potential seems to be there for quite a big speedup
9514 It is possible that, as of version 0.5.18, @code{g77}
9515 is noticeably faster compiling many Fortran source files than using
9516 @code{f2c} in conjunction with @code{gcc}.
9519 @subsection Program Speed
9521 @code{g77} has the potential to better optimize code than @code{f2c},
9522 even when @code{gcc} is used to compile the output of @code{f2c},
9523 because @code{f2c} must necessarily
9524 translate Fortran into a somewhat lower-level language (C) that cannot
9525 preserve all the information that is potentially useful for optimization,
9526 while @code{g77} can gather, preserve, and transmit that information directly
9529 For example, @code{g77} implements @code{ASSIGN} and assigned
9530 @code{GOTO} using direct assignment of pointers to labels and direct
9531 jumps to labels, whereas @code{f2c} maps the assigned labels to
9532 integer values and then uses a C @code{switch} statement to encode
9533 the assigned @code{GOTO} statements.
9535 However, as is typical, theory and reality don't quite match, at least
9536 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9537 can generate code that is faster than @code{g77}.
9539 Version 0.5.18 of @code{g77} offered default
9540 settings and options, via patches to the @code{gcc}
9541 back end, that allow for better program speed, though
9542 some of these improvements also affected the performance
9543 of programs translated by @code{f2c} and then compiled
9544 by @code{g77}'s version of @code{gcc}.
9546 Version 0.5.20 of @code{g77} offers further performance
9547 improvements, at least one of which (alias analysis) is
9548 not generally applicable to @code{f2c} (though @code{f2c}
9549 could presumably be changed to also take advantage of
9550 this new capability of the @code{gcc} back end, assuming
9551 this is made available in an upcoming release of @code{gcc}).
9553 @node Ease of Debugging
9554 @subsection Ease of Debugging
9556 Because @code{g77} compiles directly to assembler code like @code{gcc},
9557 instead of translating to an intermediate language (C) as does @code{f2c},
9558 support for debugging can be better for @code{g77} than @code{f2c}.
9560 However, although @code{g77} might be somewhat more ``native'' in terms of
9561 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9562 of things ``not quite right''.
9563 Many of the important ones should be resolved in the near future.
9565 For example, @code{g77} doesn't have to worry about reserved names
9566 like @code{f2c} does.
9567 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9568 translate this to something @emph{other} than
9569 @samp{for = while;}, because C reserves those words.
9571 However, @code{g77} does still uses things like an extra level of indirection
9572 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9573 yet support multiple entry points.
9575 Another example is that, given
9583 the @code{g77} user should be able to access the variables directly, by name,
9584 without having to traverse C-like structures and unions, while @code{f2c}
9585 is unlikely to ever offer this ability (due to limitations in the
9588 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9589 take advantage of this facility at all---it doesn't emit any debugging
9590 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9591 other than information
9592 on the array of @code{char} it creates (and, in the case
9593 of local @code{EQUIVALENCE}, names) for each such area.
9595 Yet another example is arrays.
9596 @code{g77} represents them to the debugger
9597 using the same ``dimensionality'' as in the source code, while @code{f2c}
9598 must necessarily convert them all to one-dimensional arrays to fit
9599 into the confines of the C language.
9600 However, the level of support
9601 offered by debuggers for interactive Fortran-style access to arrays
9602 as compiled by @code{g77} can vary widely.
9603 In some cases, it can actually
9604 be an advantage that @code{f2c} converts everything to widely supported
9607 In fairness, @code{g77} could do many of the things @code{f2c} does
9608 to get things working at least as well as @code{f2c}---for now,
9609 the developers prefer making @code{g77} work the
9610 way they think it is supposed to, and finding help improving the
9611 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9612 to get things working properly.
9614 @node Character and Hollerith Constants
9615 @subsection Character and Hollerith Constants
9616 @cindex character constants
9617 @cindex constants, character
9618 @cindex Hollerith constants
9619 @cindex constants, Hollerith
9620 @cindex trailing null byte
9621 @cindex null byte, trailing
9622 @cindex zero byte, trailing
9624 To avoid the extensive hassle that would be needed to avoid this,
9625 @code{f2c} uses C character constants to encode character and Hollerith
9627 That means a constant like @samp{'HELLO'} is translated to
9628 @samp{"hello"} in C, which further means that an extra null byte is
9629 present at the end of the constant.
9630 This null byte is superfluous.
9632 @code{g77} does not generate such null bytes.
9633 This represents significant
9634 savings of resources, such as on systems where @file{/dev/null} or
9635 @file{/dev/zero} represent bottlenecks in the systems' performance,
9636 because @code{g77} simply asks for fewer zeros from the operating
9637 system than @code{f2c}.
9638 (Avoiding spurious use of zero bytes, each byte typically have
9639 eight zero bits, also reduces the liabilities in case
9640 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9642 @node Block Data and Libraries
9643 @section Block Data and Libraries
9644 @cindex block data and libraries
9645 @cindex BLOCK DATA statement
9646 @cindex statements, BLOCK DATA
9647 @cindex libraries, containing BLOCK DATA
9648 @cindex f2c compatibility
9649 @cindex compatibility, f2c
9651 To ensure that block data program units are linked, especially a concern
9652 when they are put into libraries, give each one a name (as in
9653 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9654 statement in every program unit that uses any common block
9655 initialized by the corresponding @code{BLOCK DATA}.
9656 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9658 that is, it generates an actual procedure having the appropriate name.
9659 The procedure does nothing but return immediately if it happens to be
9661 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9662 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9663 in the program and ensures that by generating a
9664 reference to it so the linker will make sure it is present.
9665 (Specifically, @code{g77} outputs in the data section a static pointer to the
9666 external name @samp{FOO}.)
9668 The implementation @code{g77} currently uses to make this work is
9669 one of the few things not compatible with @code{f2c} as currently
9671 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9672 issue a warning that @samp{FOO} is not otherwise referenced,
9673 and, for @samp{BLOCK DATA FOO},
9674 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9675 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9676 this particular case.
9677 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9678 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9679 will result in an unresolved reference when linked.
9681 opposite, then @samp{FOO} might not be linked in under various
9682 circumstances (such as when @samp{FOO} is in a library, or you're
9683 using a ``clever'' linker---so clever, it produces a broken program
9684 with little or no warning by omitting initializations of global data
9685 because they are contained in unreferenced procedures).
9687 The changes you make to your code to make @code{g77} handle this situation,
9688 however, appear to be a widely portable way to handle it.
9689 That is, many systems permit it (as they should, since the
9690 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9691 is a block data program unit), and of the ones
9692 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9693 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9696 Here is the recommended approach to modifying a program containing
9697 a program unit such as the following:
9701 COMMON /VARS/ X, Y, Z
9702 DATA X, Y, Z / 3., 4., 5. /
9707 If the above program unit might be placed in a library module, then
9708 ensure that every program unit in every program that references that
9709 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9710 to force the area to be initialized.
9712 For example, change a program unit that starts with
9715 INTEGER FUNCTION CURX()
9716 COMMON /VARS/ X, Y, Z
9722 so that it uses the @code{EXTERNAL} statement, as in:
9725 INTEGER FUNCTION CURX()
9726 COMMON /VARS/ X, Y, Z
9733 That way, @samp{CURX} is compiled by @code{g77} (and many other
9734 compilers) so that the linker knows it must include @samp{FOO},
9735 the @code{BLOCK DATA} program unit that sets the initial values
9736 for the variables in @samp{VAR}, in the executable program.
9740 @cindex DO statement
9741 @cindex statements, DO
9742 @cindex trips, number of
9743 @cindex number of trips
9745 The meaning of a @code{DO} loop in Fortran is precisely specified
9746 in the Fortran standard@dots{}and is quite different from what
9747 many programmers might expect.
9749 In particular, Fortran iterative @code{DO} loops are implemented as if
9750 the number of trips through the loop is calculated @emph{before}
9751 the loop is entered.
9753 The number of trips for a loop is calculated from the @var{start},
9754 @var{end}, and @var{increment} values specified in a statement such as:
9757 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9761 The trip count is evaluated using a fairly simple formula
9762 based on the three values following the @samp{=} in the
9763 statement, and it is that trip count that is effectively
9764 decremented during each iteration of the loop.
9765 If, at the beginning of an iteration of the loop, the
9766 trip count is zero or negative, the loop terminates.
9767 The per-loop-iteration modifications to @var{iter} are not
9768 related to determining whether to terminate the loop.
9770 There are two important things to remember about the trip
9775 It can be @emph{negative}, in which case it is
9776 treated as if it was zero---meaning the loop is
9777 not executed at all.
9780 The type used to @emph{calculate} the trip count
9781 is the same type as @var{iter}, but the final
9782 calculation, and thus the type of the trip
9783 count itself, always is @code{INTEGER(KIND=1)}.
9786 These two items mean that there are loops that cannot
9787 be written in straightforward fashion using the Fortran @code{DO}.
9789 For example, on a system with the canonical 32-bit two's-complement
9790 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9793 DO I = -2000000000, 2000000000
9797 Although the @var{start} and @var{end} values are well within
9798 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9799 The expected trip count is 40000000001, which is outside
9800 the range of @code{INTEGER(KIND=1)} on many systems.
9802 Instead, the above loop should be constructed this way:
9807 IF (I .GT. 2000000000) EXIT
9814 The simple @code{DO} construct and the @code{EXIT} statement
9815 (used to leave the innermost loop)
9816 are F90 features that @code{g77} supports.
9818 Some Fortran compilers have buggy implementations of @code{DO},
9819 in that they don't follow the standard.
9820 They implement @code{DO} as a straightforward translation
9821 to what, in C, would be a @code{for} statement.
9822 Instead of creating a temporary variable to hold the trip count
9823 as calculated at run time, these compilers
9824 use the iteration variable @var{iter} to control
9825 whether the loop continues at each iteration.
9827 The bug in such an implementation shows up when the
9828 trip count is within the range of the type of @var{iter},
9829 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9830 exceeds that range. For example:
9833 DO I = 2147483600, 2147483647
9837 A loop started by the above statement will work as implemented
9838 by @code{g77}, but the use, by some compilers, of a
9839 more C-like implementation akin to
9842 for (i = 2147483600; i <= 2147483647; ++i)
9846 produces a loop that does not terminate, because @samp{i}
9847 can never be greater than 2147483647, since incrementing it
9848 beyond that value overflows @samp{i}, setting it to -2147483648.
9849 This is a large, negative number that still is less than 2147483647.
9851 Another example of unexpected behavior of @code{DO} involves
9852 using a nonintegral iteration variable @var{iter}, that is,
9853 a @code{REAL} variable.
9854 Consider the following program:
9857 DATA BEGIN, END, STEP /.1, .31, .007/
9858 DO 10 R = BEGIN, END, STEP
9859 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9863 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9868 A C-like view of @code{DO} would hold that the two ``exclamatory''
9869 @code{PRINT} statements are never executed.
9870 However, this is the output of running the above program
9871 as compiled by @code{g77} on a GNU/Linux ix86 system:
9883 .310000002 .LE. .310000002!!
9886 Note that one of the two checks in the program turned up
9887 an apparent violation of the programmer's expectation---yet,
9888 the loop is correctly implemented by @code{g77}, in that
9889 it has 30 iterations.
9890 This trip count of 30 is correct when evaluated using
9891 the floating-point representations for the @var{begin},
9892 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
9894 On other systems, an apparently more accurate trip count
9895 of 31 might result, but, nevertheless, @code{g77} is
9896 faithfully following the Fortran standard, and the result
9897 is not what the author of the sample program above
9898 apparently expected.
9899 (Such other systems might, for different values in the @code{DATA}
9900 statement, violate the other programmer's expectation,
9903 Due to this combination of imprecise representation
9904 of floating-point values and the often-misunderstood
9905 interpretation of @code{DO} by standard-conforming
9906 compilers such as @code{g77}, use of @code{DO} loops
9907 with @code{REAL} iteration
9908 variables is not recommended.
9909 Such use can be caught by specifying @samp{-Wsurprising}.
9910 @xref{Warning Options}, for more information on this
9913 @node Working Programs
9914 @section Working Programs
9916 Getting Fortran programs to work in the first place can be
9917 quite a challenge---even when the programs already work on
9918 other systems, or when using other compilers.
9920 @code{g77} offers some facilities that might be useful for
9921 tracking down bugs in such programs.
9925 * Variables Assumed To Be Zero::
9926 * Variables Assumed To Be Saved::
9927 * Unwanted Variables::
9928 * Unused Arguments::
9929 * Surprising Interpretations of Code::
9930 * Aliasing Assumed To Work::
9931 * Output Assumed To Flush::
9932 * Large File Unit Numbers::
9933 * Floating-point precision::
9934 * Inconsistent Calling Sequences::
9938 @subsection Not My Type
9939 @cindex mistyped variables
9940 @cindex variables, mistyped
9941 @cindex mistyped functions
9942 @cindex functions, mistyped
9943 @cindex implicit typing
9945 A fruitful source of bugs in Fortran source code is use, or
9946 mis-use, of Fortran's implicit-typing feature, whereby the
9947 type of a variable, array, or function is determined by the
9948 first character of its name.
9950 Simple cases of this include statements like @samp{LOGX=9.227},
9951 without a statement such as @samp{REAL LOGX}.
9952 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
9953 type, with the result of the assignment being that it is given
9956 More involved cases include a function that is defined starting
9957 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
9958 Any caller of this function that does not also declare @samp{IPS}
9959 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
9960 is likely to assume it returns
9961 @code{INTEGER}, or some other type, leading to invalid results
9962 or even program crashes.
9964 The @samp{-Wimplicit} option might catch failures to
9965 properly specify the types of
9966 variables, arrays, and functions in the code.
9968 However, in code that makes heavy use of Fortran's
9969 implicit-typing facility, this option might produce so
9970 many warnings about cases that are working, it would be
9971 hard to find the one or two that represent bugs.
9972 This is why so many experienced Fortran programmers strongly
9973 recommend widespread use of the @code{IMPLICIT NONE} statement,
9974 despite it not being standard FORTRAN 77, to completely turn
9975 off implicit typing.
9976 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
9977 FORTRAN 77 compilers.)
9979 Note that @samp{-Wimplicit} catches only implicit typing of
9981 It does not catch implicit typing of expressions such
9983 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
9984 is equivalent to @samp{X**0}, due to the way Fortran expressions
9985 are given types and then evaluated.
9986 (In this particular case, the programmer probably wanted
9989 @node Variables Assumed To Be Zero
9990 @subsection Variables Assumed To Be Zero
9991 @cindex zero-initialized variables
9992 @cindex variables, assumed to be zero
9993 @cindex uninitialized variables
9995 Many Fortran programs were developed on systems that provided
9996 automatic initialization of all, or some, variables and arrays
9998 As a result, many of these programs depend, sometimes
9999 inadvertently, on this behavior, though to do so violates
10000 the Fortran standards.
10002 You can ask @code{g77} for this behavior by specifying the
10003 @samp{-finit-local-zero} option when compiling Fortran code.
10004 (You might want to specify @samp{-fno-automatic} as well,
10005 to avoid code-size inflation for non-optimized compilations.)
10007 Note that a program that works better when compiled with the
10008 @samp{-finit-local-zero} option
10009 is almost certainly depending on a particular system's,
10010 or compiler's, tendency to initialize some variables to zero.
10011 It might be worthwhile finding such cases and fixing them,
10012 using techniques such as compiling with the @samp{-O -Wuninitialized}
10013 options using @code{g77}.
10015 @node Variables Assumed To Be Saved
10016 @subsection Variables Assumed To Be Saved
10017 @cindex variables, retaining values across calls
10018 @cindex saved variables
10019 @cindex static variables
10021 Many Fortran programs were developed on systems that
10022 saved the values of all, or some, variables and arrays
10023 across procedure calls.
10024 As a result, many of these programs depend, sometimes
10025 inadvertently, on being able to assign a value to a
10026 variable, perform a @code{RETURN} to a calling procedure,
10027 and, upon subsequent invocation, reference the previously
10028 assigned variable to obtain the value.
10030 They expect this despite not using the @code{SAVE} statement
10031 to specify that the value in a variable is expected to survive
10032 procedure returns and calls.
10033 Depending on variables and arrays to retain values across
10034 procedure calls without using @code{SAVE} to require it violates
10035 the Fortran standards.
10037 You can ask @code{g77} to assume @code{SAVE} is specified for all
10038 relevant (local) variables and arrays by using the
10039 @samp{-fno-automatic} option.
10041 Note that a program that works better when compiled with the
10042 @samp{-fno-automatic} option
10043 is almost certainly depending on not having to use
10044 the @code{SAVE} statement as required by the Fortran standard.
10045 It might be worthwhile finding such cases and fixing them,
10046 using techniques such as compiling with the @samp{-O -Wuninitialized}
10047 options using @code{g77}.
10049 @node Unwanted Variables
10050 @subsection Unwanted Variables
10052 The @samp{-Wunused} option can find bugs involving
10053 implicit typing, sometimes
10054 more easily than using @samp{-Wimplicit} in code that makes
10055 heavy use of implicit typing.
10056 An unused variable or array might indicate that the
10057 spelling for its declaration is different from that of
10060 Other than cases involving typos, unused variables rarely
10061 indicate actual bugs in a program.
10062 However, investigating such cases thoroughly has, on occasion,
10063 led to the discovery of code that had not been completely
10064 written---where the programmer wrote declarations as needed
10065 for the whole algorithm, wrote some or even most of the code
10066 for that algorithm, then got distracted and forgot that the
10067 job was not complete.
10069 @node Unused Arguments
10070 @subsection Unused Arguments
10071 @cindex unused arguments
10072 @cindex arguments, unused
10074 As with unused variables, It is possible that unused arguments
10075 to a procedure might indicate a bug.
10076 Compile with @samp{-W -Wunused} option to catch cases of
10079 Note that @samp{-W} also enables warnings regarding overflow
10080 of floating-point constants under certain circumstances.
10082 @node Surprising Interpretations of Code
10083 @subsection Surprising Interpretations of Code
10085 The @samp{-Wsurprising} option can help find bugs involving
10086 expression evaluation or in
10087 the way @code{DO} loops with non-integral iteration variables
10089 Cases found by this option might indicate a difference of
10090 interpretation between the author of the code involved, and
10091 a standard-conforming compiler such as @code{g77}.
10092 Such a difference might produce actual bugs.
10094 In any case, changing the code to explicitly do what the
10095 programmer might have expected it to do, so @code{g77} and
10096 other compilers are more likely to follow the programmer's
10097 expectations, might be worthwhile, especially if such changes
10098 make the program work better.
10100 @node Aliasing Assumed To Work
10101 @subsection Aliasing Assumed To Work
10102 @cindex -falias-check option
10103 @cindex options, -falias-check
10104 @cindex -fargument-alias option
10105 @cindex options, -fargument-alias
10106 @cindex -fargument-noalias option
10107 @cindex options, -fargument-noalias
10108 @cindex -fno-argument-noalias-global option
10109 @cindex options, -fno-argument-noalias-global
10111 @cindex anti-aliasing
10112 @cindex overlapping arguments
10114 @cindex association, storage
10115 @cindex storage association
10116 @cindex scheduling of reads and writes
10117 @cindex reads and writes, scheduling
10119 The @samp{-falias-check}, @samp{-fargument-alias},
10120 @samp{-fargument-noalias},
10121 and @samp{-fno-argument-noalias-global} options,
10122 introduced in version 0.5.20 and
10123 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10124 were withdrawn as of @code{g77} version 0.5.23
10125 due to their not being supported by @code{gcc} version 2.8.
10127 These options, which control the assumptions regarding aliasing
10128 (overlapping) of writes and reads to main memory (core) made
10129 by the @code{gcc} back end,
10130 might well be added back (in some form) in a future version
10133 However, these options @emph{are} supported by @code{egcs}.
10135 The information below still is useful, but applies to
10136 only those versions of @code{g77} that support the
10137 alias analysis implied by support for these options.
10139 These options are effective only when compiling with @samp{-O}
10140 (specifying any level other than @samp{-O0})
10141 or with @samp{-falias-check}.
10143 The default for Fortran code is @samp{-fargument-noalias-global}.
10144 (The default for C code and code written in other C-based languages
10145 is @samp{-fargument-alias}.
10146 These defaults apply regardless of whether you use @code{g77} or
10147 @code{gcc} to compile your code.)
10149 Note that, on some systems, compiling with @samp{-fforce-addr} in
10150 effect can produce more optimal code when the default aliasing
10151 options are in effect (and when optimization is enabled).
10153 If your program is not working when compiled with optimization,
10154 it is possible it is violating the Fortran standards (77 and 90)
10155 by relying on the ability to ``safely'' modify variables and
10156 arrays that are aliased, via procedure calls, to other variables
10157 and arrays, without using @code{EQUIVALENCE} to explicitly
10158 set up this kind of aliasing.
10160 (The FORTRAN 77 standard's prohibition of this sort of
10161 overlap, generally referred to therein as ``storage
10162 assocation'', appears in Sections 15.9.3.6.
10163 This prohibition allows implementations, such as @code{g77},
10164 to, for example, implement the passing of procedures and
10165 even values in @code{COMMON} via copy operations into local,
10166 perhaps more efficiently accessed temporaries at entry to a
10167 procedure, and, where appropriate, via copy operations back
10168 out to their original locations in memory at exit from that
10169 procedure, without having to take into consideration the
10170 order in which the local copies are updated by the code,
10171 among other things.)
10173 To test this hypothesis, try compiling your program with
10174 the @samp{-fargument-alias} option, which causes the
10175 compiler to revert to assumptions essentially the same as
10176 made by versions of @code{g77} prior to 0.5.20.
10178 If the program works using this option, that strongly suggests
10179 that the bug is in your program.
10180 Finding and fixing the bug(s) should result in a program that
10181 is more standard-conforming and that can be compiled by @code{g77}
10182 in a way that results in a faster executable.
10184 (You might want to try compiling with @samp{-fargument-noalias},
10185 a kind of half-way point, to see if the problem is limited to
10186 aliasing between dummy arguments and @code{COMMON} variables---this
10187 option assumes that such aliasing is not done, while still allowing
10188 aliasing among dummy arguments.)
10190 An example of aliasing that is invalid according to the standards
10191 is shown in the following program, which might @emph{not} produce
10192 the expected results when executed:
10200 SUBROUTINE FOO(J, K)
10207 The above program attempts to use the temporary aliasing of the
10208 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10209 pathological behavior---the simultaneous changing of the values
10210 of @emph{both} @samp{J} and @samp{K} when either one of them
10213 The programmer likely expects the program to print these values:
10220 However, since the program is not standard-conforming, an
10221 implementation's behavior when running it is undefined, because
10222 subroutine @samp{FOO} modifies at least one of the arguments,
10223 and they are aliased with each other.
10224 (Even if one of the assignment statements was deleted, the
10225 program would still violate these rules.
10226 This kind of on-the-fly aliasing is permitted by the standard
10227 only when none of the aliased items are defined, or written,
10228 while the aliasing is in effect.)
10230 As a practical example, an optimizing compiler might schedule
10231 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10232 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10233 resulting in the following output:
10240 Essentially, compilers are promised (by the standard and, therefore,
10241 by programmers who write code they claim to be standard-conforming)
10242 that if they cannot detect aliasing via static analysis of a single
10243 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10244 such aliasing exists.
10245 In such cases, compilers are free to assume that an assignment to
10246 one variable will not change the value of another variable, allowing
10247 it to avoid generating code to re-read the value of the other
10248 variable, to re-schedule reads and writes, and so on, to produce
10249 a faster executable.
10251 The same promise holds true for arrays (as seen by the called
10252 procedure)---an element of one dummy array cannot be aliased
10253 with, or overlap, any element of another dummy array or be
10254 in a @code{COMMON} area known to the procedure.
10256 (These restrictions apply only when the procedure defines, or
10257 writes to, one of the aliased variables or arrays.)
10259 Unfortunately, there is no way to find @emph{all} possible cases of
10260 violations of the prohibitions against aliasing in Fortran code.
10261 Static analysis is certainly imperfect, as is run-time analysis,
10262 since neither can catch all violations.
10263 (Static analysis can catch all likely violations, and some that
10264 might never actually happen, while run-time analysis can catch
10265 only those violations that actually happen during a particular run.
10266 Neither approach can cope with programs mixing Fortran code with
10267 routines written in other languages, however.)
10269 Currently, @code{g77} provides neither static nor run-time facilities
10270 to detect any cases of this problem, although other products might.
10271 Run-time facilities are more likely to be offered by future
10272 versions of @code{g77}, though patches improving @code{g77} so that
10273 it provides either form of detection are welcome.
10275 @node Output Assumed To Flush
10276 @subsection Output Assumed To Flush
10277 @cindex ALWAYS_FLUSH
10278 @cindex synchronous write errors
10280 @cindex flushing output
10282 @cindex I/O, flushing
10283 @cindex output, flushing
10284 @cindex writes, flushing
10286 @cindex network file system
10288 For several versions prior to 0.5.20, @code{g77} configured its
10289 version of the @code{libf2c} run-time library so that one of
10290 its configuration macros, @code{ALWAYS_FLUSH}, was defined.
10292 This was done as a result of a belief that many programs expected
10293 output to be flushed to the operating system (under UNIX, via
10294 the @code{fflush()} library call) with the result that errors,
10295 such as disk full, would be immediately flagged via the
10296 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10298 Because of the adverse effects this approach had on the performance
10299 of many programs, @code{g77} no longer configures @code{libf2c}
10300 (now named @code{libg2c} in its @code{g77} incarnation)
10301 to always flush output.
10303 If your program depends on this behavior, either insert the
10304 appropriate @samp{CALL FLUSH} statements, or modify the sources
10305 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10306 relink your programs with the modified library.
10308 (Ideally, @code{libg2c} would offer the choice at run-time, so
10309 that a compile-time option to @code{g77} or @code{f2c} could
10310 result in generating the appropriate calls to flushing or
10311 non-flushing library routines.)
10313 @xref{Always Flush Output}, for information on how to modify
10314 the @code{g77} source tree so that a version of @code{libg2c}
10315 can be built and installed with the @code{ALWAYS_FLUSH} macro defined.
10317 @node Large File Unit Numbers
10318 @subsection Large File Unit Numbers
10320 @cindex unit numbers
10321 @cindex maximum unit number
10322 @cindex illegal unit number
10323 @cindex increasing maximum unit number
10325 If your program crashes at run time with a message including
10326 the text @samp{illegal unit number}, that probably is
10327 a message from the run-time library, @code{libg2c}.
10329 The message means that your program has attempted to use a
10330 file unit number that is out of the range accepted by
10332 Normally, this range is 0 through 99, and the high end
10333 of the range is controlled by a @code{libg2c} source-file
10334 macro named @code{MXUNIT}.
10336 If you can easily change your program to use unit numbers
10337 in the range 0 through 99, you should do so.
10339 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10340 to change @code{MXUNIT} in @code{libg2c} so you can build and
10341 install a new version of @code{libg2c} that supports the larger
10342 unit numbers you need.
10344 @emph{Note:} While @code{libg2c} places a limit on the range
10345 of Fortran file-unit numbers, the underlying library and operating
10346 system might impose different kinds of limits.
10347 For example, some systems limit the number of files simultaneously
10348 open by a running program.
10349 Information on how to increase these limits should be found
10350 in your system's documentation.
10352 @node Floating-point precision
10353 @subsection Floating-point precision
10355 @cindex IEEE 754 conformance
10356 @cindex conformance, IEEE 754
10357 @cindex floating-point, precision
10358 @cindex ix86 floating-point
10359 @cindex x86 floating-point
10360 If your program depends on exact IEEE 754 floating-point handling it may
10361 help on some systems---specifically x86 or m68k hardware---to use
10362 the @samp{-ffloat-store} option or to reset the precision flag on the
10363 floating-point unit @xref{Optimize Options}.
10365 However, it might be better simply to put the FPU into double precision
10366 mode and not take the performance hit of @samp{-ffloat-store}. On x86
10367 and m68k GNU systems you can do this with a technique similar to that
10368 for turning on floating-point exceptions @xref{Floating-point Exception
10369 Handling}. The control word could be set to double precision by
10370 replacing the @code{__setfpucw} call with one like this:
10372 __setfpucw ((_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE);
10374 (It is not clear whether this has any effect on the operation of the GNU
10375 maths library, but we have no evidence of it causing trouble.)
10377 Some targets (such as the Alpha) may need special options for full IEEE
10378 conformance @xref{Submodel Options,,Hardware Models and
10379 Configurations,gcc,Using and Porting GNU CC}.
10381 @node Inconsistent Calling Sequences
10382 @subsection Inconsistent Calling Sequences
10385 @cindex floating-point, errors
10386 @cindex ix86 FPU stack
10387 @cindex x86 FPU stack
10388 Code containing inconsistent calling sequences in the same file is
10389 normally rejected @xref{GLOBALS}. (Use, say, @code{ftnchek} to ensure
10390 consistency across source files
10391 @c makeinfo 1.68 objects to the nested parens
10393 @xref{f2c Skeletons and Prototypes}.)
10396 @xref{f2c Skeletons and Prototypes,,
10397 {Generating Skeletons and Prototypes with @code{f2c}}}.)
10400 Mysterious errors, which may appear to be code generation problems, can
10401 appear specifically on the x86 architecture with some such
10402 inconsistencies. On x86 hardware, floating-point return values of
10403 functions are placed on the floating-point unit's register stack, not
10404 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
10405 @code{FUNCTION} as some other sort of procedure, or vice versa,
10406 scrambles the floating-point stack. This may break unrelated code
10407 executed later. Similarly if, say, external C routines are written
10410 @node Overly Convenient Options
10411 @section Overly Convenient Command-line Options
10412 @cindex overly convenient options
10413 @cindex options, overly convenient
10415 These options should be used only as a quick-and-dirty way to determine
10416 how well your program will run under different compilation models
10417 without having to change the source.
10418 Some are more problematic
10419 than others, depending on how portable and maintainable you want the
10420 program to be (and, of course, whether you are allowed to change it
10421 at all is crucial).
10423 You should not continue to use these command-line options to compile
10424 a given program, but rather should make changes to the source code:
10427 @cindex -finit-local-zero option
10428 @cindex options, -finit-local-zero
10429 @item -finit-local-zero
10430 (This option specifies that any uninitialized local variables
10431 and arrays have default initialization to binary zeros.)
10433 Many other compilers do this automatically, which means lots of
10434 Fortran code developed with those compilers depends on it.
10436 It is safer (and probably
10437 would produce a faster program) to find the variables and arrays that
10438 need such initialization and provide it explicitly via @code{DATA}, so that
10439 @samp{-finit-local-zero} is not needed.
10441 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10442 find likely candidates, but
10443 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10444 or this technique won't work.
10446 @cindex -fno-automatic option
10447 @cindex options, -fno-automatic
10448 @item -fno-automatic
10449 (This option specifies that all local variables and arrays
10450 are to be treated as if they were named in @code{SAVE} statements.)
10452 Many other compilers do this automatically, which means lots of
10453 Fortran code developed with those compilers depends on it.
10455 The effect of this is that all non-automatic variables and arrays
10456 are made static, that is, not placed on the stack or in heap storage.
10457 This might cause a buggy program to appear to work better.
10458 If so, rather than relying on this command-line option (and hoping all
10459 compilers provide the equivalent one), add @code{SAVE}
10460 statements to some or all program unit sources, as appropriate.
10461 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10462 to find likely candidates, but
10463 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10464 or this technique won't work.
10466 The default is @samp{-fautomatic}, which tells @code{g77} to try
10467 and put variables and arrays on the stack (or in fast registers)
10468 where possible and reasonable.
10469 This tends to make programs faster.
10471 @cindex automatic arrays
10472 @cindex arrays, automatic
10473 @emph{Note:} Automatic variables and arrays are not affected
10475 These are variables and arrays that are @emph{necessarily} automatic,
10476 either due to explicit statements, or due to the way they are
10478 Examples include local variables and arrays not given the
10479 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10480 and local arrays declared with non-constant bounds (automatic
10482 Currently, @code{g77} supports only automatic arrays, not
10483 @code{RECURSIVE} procedures or other means of explicitly
10484 specifying that variables or arrays are automatic.
10486 @cindex -f@var{group}-intrinsics-hide option
10487 @cindex options, -f@var{group}-intrinsics-hide
10488 @item -f@var{group}-intrinsics-hide
10489 Change the source code to use @code{EXTERNAL} for any external procedure
10490 that might be the name of an intrinsic.
10491 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10494 @node Faster Programs
10495 @section Faster Programs
10496 @cindex speed, of programs
10497 @cindex programs, speeding up
10499 Aside from the usual @code{gcc} options, such as @samp{-O},
10500 @samp{-ffast-math}, and so on, consider trying some of the
10501 following approaches to speed up your program (once you get
10506 * Prefer Automatic Uninitialized Variables::
10507 * Avoid f2c Compatibility::
10508 * Use Submodel Options::
10512 @subsection Aligned Data
10514 @cindex data, aligned
10515 @cindex stack, aligned
10516 @cindex aligned data
10517 @cindex aligned stack
10518 @cindex Pentium optimizations
10519 @cindex optimization, for Pentium
10521 On some systems, such as those with Pentium Pro CPUs, programs
10522 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10523 might run much slower
10524 than possible due to the compiler not aligning these 64-bit
10525 values to 64-bit boundaries in memory.
10526 (The effect also is present, though
10527 to a lesser extent, on the 586 (Pentium) architecture.)
10529 The Intel x86 architecture generally ensures that these programs will
10530 work on all its implementations,
10531 but particular implementations (such as Pentium Pro)
10532 perform better with more strict alignment.
10533 (Such behavior isn't unique to the Intel x86 architecture.)
10534 Other architectures might @emph{demand} 64-bit alignment
10537 There are a variety of approaches to use to address this problem:
10541 @cindex @code{COMMON} layout
10542 @cindex layout of @code{COMMON} blocks
10543 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10544 that the variables and arrays with the widest alignment
10545 guidelines come first.
10547 For example, on most systems, this would mean placing
10548 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10549 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10550 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10551 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10552 and @code{INTEGER(KIND=3)} entities.
10554 The reason to use such placement is it makes it more likely
10555 that your data will be aligned properly, without requiring
10556 you to do detailed analysis of each aggregate (@code{COMMON}
10557 and @code{EQUIVALENCE}) area.
10559 Specifically, on systems where the above guidelines are
10560 appropriate, placing @code{CHARACTER} entities before
10561 @code{REAL(KIND=2)} entities can work just as well,
10562 but only if the number of bytes occupied by the @code{CHARACTER}
10563 entities is divisible by the recommended alignment for
10564 @code{REAL(KIND=2)}.
10566 By ordering the placement of entities in aggregate
10567 areas according to the simple guidelines above, you
10568 avoid having to carefully count the number of bytes
10569 occupied by each entity to determine whether the
10570 actual alignment of each subsequent entity meets the
10571 alignment guidelines for the type of that entity.
10573 If you don't ensure correct alignment of @code{COMMON} elements, the
10574 compiler may be forced by some systems to violate the Fortran semantics by
10575 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10576 If the unfortunate practice is employed of overlaying different types of
10577 data in the @code{COMMON} block, the different variants
10578 of this block may become misaligned with respect to each other.
10579 Even if your platform doesn't require strict alignment,
10580 @code{COMMON} should be laid out as above for portability.
10581 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10582 possible requirement, which is compiler-independent on a given platform.)
10585 @cindex -malign-double option
10586 @cindex options, -malign-double
10587 Use the (x86-specific) @samp{-malign-double} option when compiling
10588 programs for the Pentium and Pentium Pro architectures (called 586
10589 and 686 in the @code{gcc} configuration subsystem).
10590 The warning about this in the @code{gcc} manual isn't
10591 generally relevant to Fortran,
10592 but using it will force @code{COMMON} to be padded if necessary to align
10593 @code{DOUBLE PRECISION} data.
10595 When @code{DOUBLE PRECISION} data is forcibly aligned
10596 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10597 @code{g77} issues a warning about the need to
10600 In this case, each and every program unit that uses
10601 the same @code{COMMON} area
10602 must specify the same layout of variables and their types
10604 and be compiled with @samp{-malign-double} as well.
10605 @code{g77} will issue warnings in each case,
10606 but as long as every program unit using that area
10607 is compiled with the same warnings,
10608 the resulting object files should work when linked together
10609 unless the program makes additional assumptions about
10610 @code{COMMON} area layouts that are outside the scope
10611 of the FORTRAN 77 standard,
10612 or uses @code{EQUIVALENCE} or different layouts
10613 in ways that assume no padding is ever inserted by the compiler.
10616 Ensure that @file{crt0.o} or @file{crt1.o}
10617 on your system guarantees a 64-bit
10618 aligned stack for @code{main()}.
10619 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10620 but we don't know of any other x86 setups where it will be right.
10621 Read your system's documentation to determine if
10622 it is appropriate to upgrade to a more recent version
10623 to obtain the optimal alignment.
10626 Progress is being made on making this work
10627 ``out of the box'' on future versions of @code{g77},
10628 @code{gcc}, and some of the relevant operating systems
10629 (such as GNU/Linux).
10631 @cindex alignment testing
10632 @cindex testing alignment
10633 A package that tests the degree to which a Fortran compiler
10634 (such as @code{g77})
10635 aligns 64-bit floating-point variables and arrays
10636 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
10638 @node Prefer Automatic Uninitialized Variables
10639 @subsection Prefer Automatic Uninitialized Variables
10641 If you're using @samp{-fno-automatic} already, you probably
10642 should change your code to allow compilation with @samp{-fautomatic}
10643 (the default), to allow the program to run faster.
10645 Similarly, you should be able to use @samp{-fno-init-local-zero}
10646 (the default) instead of @samp{-finit-local-zero}.
10647 This is because it is rare that every variable affected by these
10648 options in a given program actually needs to
10651 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10652 every local non-automatic variable and array, affects even things like
10653 @code{DO} iteration
10654 variables, which rarely need to be @code{SAVE}d, and this often reduces
10655 run-time performances.
10656 Similarly, @samp{-fno-init-local-zero} forces such
10657 variables to be initialized to zero---when @code{SAVE}d (such as when
10658 @samp{-fno-automatic}), this by itself generally affects only
10659 startup time for a program, but when not @code{SAVE}d,
10660 it can slow down the procedure every time it is called.
10662 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10663 for information on the @samp{-fno-automatic} and
10664 @samp{-finit-local-zero} options and how to convert
10665 their use into selective changes in your own code.
10667 @node Avoid f2c Compatibility
10668 @subsection Avoid f2c Compatibility
10669 @cindex -fno-f2c option
10670 @cindex options, -fno-f2c
10671 @cindex @code{f2c} compatibility
10672 @cindex compatibility, @code{f2c}
10674 If you aren't linking with any code compiled using
10675 @code{f2c}, try using the @samp{-fno-f2c} option when
10676 compiling @emph{all} the code in your program.
10677 (Note that @code{libf2c} is @emph{not} an example of code
10678 that is compiled using @code{f2c}---it is compiled by a C
10679 compiler, typically @code{gcc}.)
10681 @node Use Submodel Options
10682 @subsection Use Submodel Options
10683 @cindex Pentium optimizations
10684 @cindex optimization, for Pentium
10685 @cindex 586/686 CPUs
10688 Using an appropriate @samp{-m} option to generate specific code for your
10689 CPU may be worthwhile, though it may mean the executable won't run on
10690 other versions of the CPU that don't support the same instruction set.
10691 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10694 For recent CPUs that don't have explicit support in
10695 the released version of @code{gcc}, it may still be possible to get
10697 For instance, the flags recommended for 586/686
10698 (Pentium(Pro)) chips for building the Linux kernel are:
10701 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
10702 -fomit-frame-pointer
10705 @noindent @samp{-fomit-frame-pointer} will, however, inhibit debugging
10709 @chapter Known Causes of Trouble with GNU Fortran
10710 @cindex bugs, known
10711 @cindex installation trouble
10712 @cindex known causes of trouble
10714 This section describes known problems that affect users of GNU Fortran.
10715 Most of these are not GNU Fortran bugs per se---if they were, we would
10717 But the result for a user might be like the result of a bug.
10719 Some of these problems are due to bugs in other software, some are
10720 missing features that are too much work to add, and some are places
10721 where people's opinions differ as to what is best.
10723 Information on bugs that show up when configuring, porting, building,
10724 or installing @code{g77} is not provided here.
10725 @xref{Problems Installing}.
10727 To find out about major bugs discovered in the current release and
10728 possible workarounds for them, see
10729 @uref{ftp://alpha.gnu.org/g77.plan}.
10731 (Note that some of this portion of the manual is lifted
10732 directly from the @code{gcc} manual, with minor modifications
10733 to tailor it to users of @code{g77}.
10734 Anytime a bug seems to have more to do with the @code{gcc}
10735 portion of @code{g77},
10736 @xref{Trouble,,Known Causes of Trouble with GNU CC,
10737 gcc,Using and Porting GNU CC}.)
10740 * But-bugs:: Bugs really in other programs or elsewhere.
10741 * Known Bugs:: Bugs known to be in this version of @code{g77}.
10742 * Missing Features:: Features we already know we want to add later.
10743 * Disappointments:: Regrettable things we can't change.
10744 * Non-bugs:: Things we think are right, but some others disagree.
10745 * Warnings and Errors:: Which problems in your code get warnings,
10746 and which get errors.
10750 @section Bugs Not In GNU Fortran
10753 These are bugs to which the maintainers often have to reply,
10754 ``but that isn't a bug in @code{g77}@dots{}''.
10755 Some of these already are fixed in new versions of other
10756 software; some still need to be fixed; some are problems
10757 with how @code{g77} is installed or is being used;
10758 some are the result of bad hardware that causes software
10759 to misbehave in sometimes bizarre ways;
10760 some just cannot be addressed at this time until more
10761 is known about the problem.
10763 Please don't re-report these bugs to the @code{g77} maintainers---if
10764 you must remind someone how important it is to you that the problem
10765 be fixed, talk to the people responsible for the other products
10766 identified below, but preferably only after you've tried the
10767 latest versions of those products.
10768 The @code{g77} maintainers have their hands full working on
10769 just fixing and improving @code{g77}, without serving as a
10770 clearinghouse for all bugs that happen to affect @code{g77}
10773 @xref{Collected Fortran Wisdom}, for information on behavior
10774 of Fortran programs, and the programs that compile them, that
10775 might be @emph{thought} to indicate bugs.
10778 * Signal 11 and Friends:: Strange behavior by any software.
10779 * Cannot Link Fortran Programs:: Unresolved references.
10780 * Large Common Blocks:: Problems on older GNU/Linux systems.
10781 * Debugger Problems:: When the debugger crashes.
10782 * NeXTStep Problems:: Misbehaving executables.
10783 * Stack Overflow:: More misbehaving executables.
10784 * Nothing Happens:: Less behaving executables.
10785 * Strange Behavior at Run Time:: Executables misbehaving due to
10786 bugs in your program.
10787 * Floating-point Errors:: The results look wrong, but@dots{}.
10790 @node Signal 11 and Friends
10791 @subsection Signal 11 and Friends
10793 @cindex hardware errors
10795 A whole variety of strange behaviors can occur when the
10796 software, or the way you are using the software,
10797 stresses the hardware in a way that triggers hardware bugs.
10798 This might seem hard to believe, but it happens frequently
10799 enough that there exist documents explaining in detail
10800 what the various causes of the problems are, what
10801 typical symptoms look like, and so on.
10803 Generally these problems are referred to in this document
10804 as ``signal 11'' crashes, because the Linux kernel, running
10805 on the most popular hardware (the Intel x86 line), often
10806 stresses the hardware more than other popular operating
10808 When hardware problems do occur under GNU/Linux on x86
10809 systems, these often manifest themselves as ``signal 11''
10810 problems, as illustrated by the following diagnostic:
10813 sh# @kbd{g77 myprog.f}
10814 gcc: Internal compiler error: program f771 got fatal signal 11
10818 It is @emph{very} important to remember that the above
10819 message is @emph{not} the only one that indicates a
10820 hardware problem, nor does it always indicate a hardware
10823 In particular, on systems other than those running the Linux
10824 kernel, the message might appear somewhat or very different,
10825 as it will if the error manifests itself while running a
10826 program other than the @code{g77} compiler.
10828 it will appear somewhat different when running your program,
10829 when running Emacs, and so on.
10831 How to cope with such problems is well beyond the scope
10834 However, users of Linux-based systems (such as GNU/Linux)
10835 should review @uref{http://www.bitwizard.nl/sig11}, a source
10836 of detailed information on diagnosing hardware problems,
10837 by recognizing their common symptoms.
10839 Users of other operating systems and hardware might
10840 find this reference useful as well.
10841 If you know of similar material for another hardware/software
10842 combination, please let us know so we can consider including
10843 a reference to it in future versions of this manual.
10845 @node Cannot Link Fortran Programs
10846 @subsection Cannot Link Fortran Programs
10847 @cindex unresolved reference (various)
10848 @cindex linking error for user code
10850 @cindex @code{ld}, error linking user code
10851 @cindex @code{ld}, can't find strange names
10852 On some systems, perhaps just those with out-of-date (shared?)
10853 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10854 programs (which should be done using @code{g77}).
10856 If this happens to you, try appending @samp{-lc} to the command you
10857 use to link the program, e.g. @samp{g77 foo.f -lc}.
10858 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10859 but it cannot also specify @samp{-lc} because not all systems have a
10860 file named @file{libc.a}.
10862 It is unclear at this point whether there are legitimately installed
10863 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10866 @cindex undefined reference (_main)
10867 @cindex linking error, user code
10868 @cindex @code{ld}, error linking user code
10870 @cindex @code{ld}, can't find @samp{_main}
10871 If your program doesn't link due to unresolved references to names
10872 like @samp{_main}, make sure you're using the @code{g77} command to do the
10873 link, since this command ensures that the necessary libraries are
10874 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10875 command to do the actual link.
10876 (Use the @samp{-v} option to discover
10877 more about what actually happens when you use the @code{g77} and @code{gcc}
10880 Also, try specifying @samp{-lc} as the last item on the @code{g77}
10881 command line, in case that helps.
10883 @node Large Common Blocks
10884 @subsection Large Common Blocks
10885 @cindex common blocks, large
10886 @cindex large common blocks
10887 @cindex linking, errors
10888 @cindex @code{ld}, errors
10889 @cindex errors, linker
10890 On some older GNU/Linux systems, programs with common blocks larger
10891 than 16MB cannot be linked without some kind of error
10892 message being produced.
10894 This is a bug in older versions of @code{ld}, fixed in
10895 more recent versions of @code{binutils}, such as version 2.6.
10897 @node Debugger Problems
10898 @subsection Debugger Problems
10899 @cindex @code{gdb}, support
10900 @cindex support, @code{gdb}
10901 There are some known problems when using @code{gdb} on code
10902 compiled by @code{g77}.
10903 Inadequate investigation as of the release of 0.5.16 results in not
10904 knowing which products are the culprit, but @file{gdb-4.14} definitely
10905 crashes when, for example, an attempt is made to print the contents
10906 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
10907 machines, plus some others.
10908 Attempts to access assumed-size arrays are
10909 also known to crash recent versions of @code{gdb}.
10910 (@code{gdb}'s Fortran support was done for a different compiler
10911 and isn't properly compatible with @code{g77}.)
10913 @node NeXTStep Problems
10914 @subsection NeXTStep Problems
10915 @cindex NeXTStep problems
10917 @cindex segmentation violation
10918 Developers of Fortran code on NeXTStep (all architectures) have to
10919 watch out for the following problem when writing programs with
10920 large, statically allocated (i.e. non-stack based) data structures
10921 (common blocks, saved arrays).
10923 Due to the way the native loader (@file{/bin/ld}) lays out
10924 data structures in virtual memory, it is very easy to create an
10925 executable wherein the @samp{__DATA} segment overlaps (has addresses in
10926 common) with the @samp{UNIX STACK} segment.
10928 This leads to all sorts of trouble, from the executable simply not
10929 executing, to bus errors.
10930 The NeXTStep command line tool @code{ebadexec} points to
10931 the problem as follows:
10934 % @kbd{/bin/ebadexec a.out}
10935 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
10936 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
10937 STACK segment (truncated address = 0x400000 rounded size =
10938 0x3c00000) of executable file: a.out
10941 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
10944 This can be cured by assigning the @samp{__DATA} segment
10945 (virtual) addresses beyond the stack segment.
10947 estimate for this is from address 6000000 (hexadecimal) onwards---this
10948 has always worked for me [Toon Moene]:
10951 % @kbd{g77 -segaddr __DATA 6000000 test.f}
10952 % @kbd{ebadexec a.out}
10953 ebadexec: file: a.out appears to be executable
10957 Browsing through @file{@value{path-g77}/Makefile.in},
10958 you will find that the @code{f771} program itself also has to be
10959 linked with these flags---it has large statically allocated
10961 (Version 0.5.18 reduces this somewhat, but probably
10964 (The above item was contributed by Toon Moene
10965 (@email{toon@@moene.indiv.nluug.nl}).)
10967 @node Stack Overflow
10968 @subsection Stack Overflow
10969 @cindex stack, overflow
10970 @cindex segmentation violation
10971 @code{g77} code might fail at runtime (probably with a ``segmentation
10972 violation'') due to overflowing the stack.
10973 This happens most often on systems with an environment
10974 that provides substantially more heap space (for use
10975 when arbitrarily allocating and freeing memory) than stack
10978 Often this can be cured by
10979 increasing or removing your shell's limit on stack usage, typically
10980 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
10981 @kbd{ulimit -s} (in @code{sh} and derivatives).
10983 Increasing the allowed stack size might, however, require
10984 changing some operating system or system configuration parameters.
10986 You might be able to work around the problem by compiling with the
10987 @samp{-fno-automatic} option to reduce stack usage, probably at the
10990 @xref{Maximum Stackable Size}, for information on patching
10991 @code{g77} to use different criteria for placing local
10992 non-automatic variables and arrays on the stack.
10994 @cindex automatic arrays
10995 @cindex arrays, automatic
10996 However, if your program uses large automatic arrays
10997 (for example, has declarations like @samp{REAL A(N)} where
10998 @samp{A} is a local array and @samp{N} is a dummy or
10999 @code{COMMON} variable that can have a large value),
11000 neither use of @samp{-fno-automatic},
11001 nor changing the cut-off point for @code{g77} for using the stack,
11002 will solve the problem by changing the placement of these
11003 large arrays, as they are @emph{necessarily} automatic.
11005 @code{g77} currently provides no means to specify that
11006 automatic arrays are to be allocated on the heap instead
11008 So, other than increasing the stack size, your best bet is to
11009 change your source code to avoid large automatic arrays.
11010 Methods for doing this currently are outside the scope of
11013 (@emph{Note:} If your system puts stack and heap space in the
11014 same memory area, such that they are effectively combined, then
11015 a stack overflow probably indicates a program that is either
11016 simply too large for the system, or buggy.)
11018 @node Nothing Happens
11019 @subsection Nothing Happens
11020 @cindex nothing happens
11021 @cindex naming programs
11022 @cindex @code{test} programs
11023 @cindex programs, @code{test}
11024 It is occasionally reported that a ``simple'' program,
11025 such as a ``Hello, World!'' program, does nothing when
11026 it is run, even though the compiler reported no errors,
11027 despite the program containing nothing other than a
11028 simple @code{PRINT} statement.
11030 This most often happens because the program has been
11031 compiled and linked on a UNIX system and named @code{test},
11032 though other names can lead to similarly unexpected
11033 run-time behavior on various systems.
11035 Essentially this problem boils down to giving
11036 your program a name that is already known to
11037 the shell you are using to identify some other program,
11038 which the shell continues to execute instead of your
11039 program when you invoke it via, for example:
11046 Under UNIX and many other system, a simple command name
11047 invokes a searching mechanism that might well not choose
11048 the program located in the current working directory if
11049 there is another alternative (such as the @code{test}
11050 command commonly installed on UNIX systems).
11052 The reliable way to invoke a program you just linked in
11053 the current directory under UNIX is to specify it using
11054 an explicit pathname, as in:
11062 Users who encounter this problem should take the time to
11063 read up on how their shell searches for commands, how to
11064 set their search path, and so on.
11065 The relevant UNIX commands to learn about include
11066 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
11067 @code{set} and @code{env}), @code{which}, and @code{find}.
11069 @node Strange Behavior at Run Time
11070 @subsection Strange Behavior at Run Time
11071 @cindex segmentation violation
11073 @cindex overwritten data
11074 @cindex data, overwritten
11075 @code{g77} code might fail at runtime with ``segmentation violation'',
11076 ``bus error'', or even something as subtle as a procedure call
11077 overwriting a variable or array element that it is not supposed
11080 These can be symptoms of a wide variety of actual bugs that
11081 occurred earlier during the program's run, but manifested
11082 themselves as @emph{visible} problems some time later.
11084 Overflowing the bounds of an array---usually by writing beyond
11085 the end of it---is one of two kinds of bug that often occurs
11087 (Compile your code with the @samp{-fsubscript-check} option
11088 to catch many of these kinds of errors at program run time.)
11090 The other kind of bug is a mismatch between the actual arguments
11091 passed to a procedure and the dummy arguments as declared by that
11094 Both of these kinds of bugs, and some others as well, can be
11095 difficult to track down, because the bug can change its behavior,
11096 or even appear to not occur, when using a debugger.
11098 That is, these bugs can be quite sensitive to data, including
11099 data representing the placement of other data in memory (that is,
11100 pointers, such as the placement of stack frames in memory).
11102 @code{g77} now offers the
11103 ability to catch and report some of these problems at compile, link, or
11104 run time, such as by generating code to detect references to
11105 beyond the bounds of most arrays (except assumed-size arrays),
11106 and checking for agreement between calling and called procedures.
11107 Future improvements are likely to be made in the procedure-mismatch area,
11110 In the meantime, finding and fixing the programming
11111 bugs that lead to these behaviors is, ultimately, the user's
11112 responsibility, as difficult as that task can sometimes be.
11114 @cindex infinite spaces printed
11115 @cindex space, endless printing of
11116 @cindex libc, non-ANSI or non-default
11118 @cindex linking against non-standard library
11120 One runtime problem that has been observed might have a simple solution.
11121 If a formatted @code{WRITE} produces an endless stream of spaces, check
11122 that your program is linked against the correct version of the C library.
11123 The configuration process takes care to account for your
11124 system's normal @file{libc} not being ANSI-standard, which will
11125 otherwise cause this behaviour.
11126 If your system's default library is
11127 ANSI-standard and you subsequently link against a non-ANSI one, there
11128 might be problems such as this one.
11130 Specifically, on Solaris2 systems,
11131 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
11133 @node Floating-point Errors
11134 @subsection Floating-point Errors
11135 @cindex floating-point errors
11136 @cindex rounding errors
11137 @cindex inconsistent floating-point results
11138 @cindex results, inconsistent
11139 Some programs appear to produce inconsistent floating-point
11140 results compiled by @code{g77} versus by other compilers.
11142 Often the reason for this behavior is the fact that floating-point
11143 values are represented on almost all Fortran systems by
11144 @emph{approximations}, and these approximations are inexact
11145 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
11146 0.7, 0.8, 0.9, 1.1, and so on.
11147 Most Fortran systems, including all current ports of @code{g77},
11148 use binary arithmetic to represent these approximations.
11150 Therefore, the exact value of any floating-point approximation
11151 as manipulated by @code{g77}-compiled code is representable by
11152 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11153 so on (just keep dividing by two) through the precision of the
11154 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11155 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11156 power of two (in Fortran, by @samp{2**N}) that typically is between
11157 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11158 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11161 So, a value like 0.2 is exactly represented in decimal---since
11162 it is a fraction, @samp{2/10}, with a denominator that is compatible
11163 with the base of the number system (base 10).
11164 However, @samp{2/10} cannot be represented by any finite number
11165 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11166 be exactly represented in binary notation.
11168 (On the other hand, decimal notation can represent any binary
11169 number in a finite number of digits.
11170 Decimal notation cannot do so with ternary, or base-3,
11171 notation, which would represent floating-point numbers as
11172 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11173 After all, no finite number of decimal digits can exactly
11174 represent @samp{1/3}.
11175 Fortunately, few systems use ternary notation.)
11177 Moreover, differences in the way run-time I/O libraries convert
11178 between these approximations and the decimal representation often
11179 used by programmers and the programs they write can result in
11180 apparent differences between results that do not actually exist,
11181 or exist to such a small degree that they usually are not worth
11184 For example, consider the following program:
11191 When compiled by @code{g77}, the above program might output
11192 @samp{0.20000003}, while another compiler might produce a
11193 executable that outputs @samp{0.2}.
11195 This particular difference is due to the fact that, currently,
11196 conversion of floating-point values by the @code{libg2c} library,
11197 used by @code{g77}, handles only double-precision values.
11199 Since @samp{0.2} in the program is a single-precision value, it
11200 is converted to double precision (still in binary notation)
11201 before being converted back to decimal.
11202 The conversion to binary appends @emph{binary} zero digits to the
11203 original value---which, again, is an inexact approximation of
11204 0.2---resulting in an approximation that is much less exact
11205 than is connoted by the use of double precision.
11207 (The appending of binary zero digits has essentially the same
11208 effect as taking a particular decimal approximation of
11209 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11210 zeros to it, producing @samp{0.33333330000000000}.
11211 Treating the resulting decimal approximation as if it really
11212 had 18 or so digits of valid precision would make it seem
11213 a very poor approximation of @samp{1/3}.)
11215 As a result of converting the single-precision approximation
11216 to double precision by appending binary zeros, the conversion
11217 of the resulting double-precision
11218 value to decimal produces what looks like an incorrect
11219 result, when in fact the result is @emph{inexact}, and
11220 is probably no less inaccurate or imprecise an approximation
11221 of 0.2 than is produced by other compilers that happen to output
11222 the converted value as ``exactly'' @samp{0.2}.
11223 (Some compilers behave in a way that can make them appear
11224 to retain more accuracy across a conversion of a single-precision
11225 constant to double precision.
11226 @xref{Context-Sensitive Constants}, to see why
11227 this practice is illusory and even dangerous.)
11229 Note that a more exact approximation of the constant is
11230 computed when the program is changed to specify a
11231 double-precision constant:
11238 Future versions of @code{g77} and/or @code{libg2c} might convert
11239 single-precision values directly to decimal,
11240 instead of converting them to double precision first.
11241 This would tend to result in output that is more consistent
11242 with that produced by some other Fortran implementations.
11244 A useful source of information on floating-point computation is David
11245 Goldberg, `What Every Computer Scientist Should Know About
11246 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
11248 An online version is available at
11249 @uref{http://docs.sun.com},
11250 and there is a supplemented version, in PostScript form, at
11251 @uref{http://www.validgh.com/goldberg/paper.ps}.
11253 Information related to the IEEE 754
11254 floating-point standard by a leading light can be found at
11255 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status};
11256 see also slides from the short course referenced from
11257 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
11258 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
11259 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
11260 and library code for GNU/Linux x86 systems.
11262 The supplement to the PostScript-formatted Goldberg document,
11263 referenced above, is available in HTML format.
11264 See `Differences Among IEEE 754 Implementations' by Doug Priest,
11265 available online at
11266 @uref{http://www.validgh.com/goldberg/addendum.html}.
11267 This document explores some of the issues surrounding computing
11268 of extended (80-bit) results on processors such as the x86,
11269 especially when those results are arbitrarily truncated
11270 to 32-bit or 64-bit values by the compiler
11273 @cindex spills of floating-point results
11274 @cindex 80-bit spills
11275 @cindex truncation, of floating-point values
11276 (@emph{Note:} @code{g77} specifically, and @code{gcc} generally,
11277 does arbitrarily truncate 80-bit results during spills
11278 as of this writing.
11279 It is not yet clear whether a future version of
11280 the GNU compiler suite will offer 80-bit spills
11281 as an option, or perhaps even as the default behavior.)
11283 @c xref would be different between editions:
11284 The GNU C library provides routines for controlling the FPU, and other
11285 documentation about this.
11287 @xref{Floating-point precision}, regarding IEEE 754 conformance.
11291 @node Missing Features
11292 @section Missing Features
11294 This section lists features we know are missing from @code{g77},
11295 and which we want to add someday.
11296 (There is no priority implied in the ordering below.)
11299 GNU Fortran language:
11300 * Better Source Model::
11301 * Fortran 90 Support::
11302 * Intrinsics in PARAMETER Statements::
11303 * SELECT CASE on CHARACTER Type::
11304 * RECURSIVE Keyword::
11305 * Popular Non-standard Types::
11306 * Full Support for Compiler Types::
11307 * Array Bounds Expressions::
11308 * POINTER Statements::
11309 * Sensible Non-standard Constructs::
11310 * READONLY Keyword::
11311 * FLUSH Statement::
11312 * Expressions in FORMAT Statements::
11313 * Explicit Assembler Code::
11314 * Q Edit Descriptor::
11316 GNU Fortran dialects:
11317 * Old-style PARAMETER Statements::
11318 * TYPE and ACCEPT I/O Statements::
11319 * STRUCTURE UNION RECORD MAP::
11320 * OPEN CLOSE and INQUIRE Keywords::
11321 * ENCODE and DECODE::
11322 * AUTOMATIC Statement::
11323 * Suppressing Space Padding::
11324 * Fortran Preprocessor::
11325 * Bit Operations on Floating-point Data::
11329 * Floating-point Exception Handling::
11330 * Nonportable Conversions::
11331 * Large Automatic Arrays::
11332 * Support for Threads::
11333 * Increasing Precision/Range::
11335 Better diagnostics:
11336 * Gracefully Handle Sensible Bad Code::
11337 * Non-standard Conversions::
11338 * Non-standard Intrinsics::
11339 * Modifying DO Variable::
11340 * Better Pedantic Compilation::
11341 * Warn About Implicit Conversions::
11342 * Invalid Use of Hollerith Constant::
11343 * Dummy Array Without Dimensioning Dummy::
11344 * Invalid FORMAT Specifiers::
11345 * Ambiguous Dialects::
11347 * Informational Messages::
11349 Run-time facilities:
11350 * Uninitialized Variables at Run Time::
11351 * Portable Unformatted Files::
11354 * Labels Visible to Debugger::
11357 @node Better Source Model
11358 @subsection Better Source Model
11360 @code{g77} needs to provide, as the default source-line model,
11361 a ``pure visual'' mode, where
11362 the interpretation of a source program in this mode can be accurately
11363 determined by a user looking at a traditionally displayed rendition
11364 of the program (assuming the user knows whether the program is fixed
11367 The design should assume the user cannot tell tabs from spaces
11368 and cannot see trailing spaces on lines, but has canonical tab stops
11369 and, for fixed-form source, has the ability to always know exactly
11370 where column 72 is (since the Fortran standard itself requires
11371 this for fixed-form source).
11373 This would change the default treatment of fixed-form source
11374 to not treat lines with tabs as if they were infinitely long---instead,
11375 they would end at column 72 just as if the tabs were replaced
11376 by spaces in the canonical way.
11378 As part of this, provide common alternate models (Digital, @code{f2c},
11379 and so on) via command-line options.
11380 This includes allowing arbitrarily long
11381 lines for free-form source as well as fixed-form source and providing
11382 various limits and diagnostics as appropriate.
11384 @cindex sequence numbers
11385 @cindex columns 73 through 80
11386 Also, @code{g77} should offer, perhaps even default to, warnings
11387 when characters beyond the last valid column are anything other
11389 This would mean code with ``sequence numbers'' in columns 73 through 80
11390 would be rejected, and there's a lot of that kind of code around,
11391 but one of the most frequent bugs encountered by new users is
11392 accidentally writing fixed-form source code into and beyond
11394 So, maybe the users of old code would be able to more easily handle
11395 having to specify, say, a @samp{-Wno-col73to80} option.
11397 @node Fortran 90 Support
11398 @subsection Fortran 90 Support
11399 @cindex Fortran 90, support
11400 @cindex support, Fortran 90
11402 @code{g77} does not support many of the features that
11403 distinguish Fortran 90 (and, now, Fortran 95) from
11406 Some Fortran 90 features are supported, because they
11407 make sense to offer even to die-hard users of F77.
11408 For example, many of them codify various ways F77 has
11409 been extended to meet users' needs during its tenure,
11410 so @code{g77} might as well offer them as the primary
11411 way to meet those same needs, even if it offers compatibility
11412 with one or more of the ways those needs were met
11413 by other F77 compilers in the industry.
11415 Still, many important F90 features are not supported,
11416 because no attempt has been made to research each and
11417 every feature and assess its viability in @code{g77}.
11418 In the meantime, users who need those features must
11419 use Fortran 90 compilers anyway, and the best approach
11420 to adding some F90 features to GNU Fortran might well be
11421 to fund a comprehensive project to create GNU Fortran 95.
11423 @node Intrinsics in PARAMETER Statements
11424 @subsection Intrinsics in @code{PARAMETER} Statements
11425 @cindex PARAMETER statement
11426 @cindex statements, PARAMETER
11428 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11429 This feature is considered to be absolutely vital, even though it
11430 is not standard-conforming, and is scheduled for version 0.6.
11432 Related to this, @code{g77} doesn't allow non-integral
11433 exponentiation in @code{PARAMETER} statements, such as
11434 @samp{PARAMETER (R=2**.25)}.
11435 It is unlikely @code{g77} will ever support this feature,
11436 as doing it properly requires complete emulation of
11437 a target computer's floating-point facilities when
11438 building @code{g77} as a cross-compiler.
11439 But, if the @code{gcc} back end is enhanced to provide
11440 such a facility, @code{g77} will likely use that facility
11441 in implementing this feature soon afterwards.
11443 @node SELECT CASE on CHARACTER Type
11444 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11446 Character-type selector/cases for @code{SELECT CASE} currently
11449 @node RECURSIVE Keyword
11450 @subsection @code{RECURSIVE} Keyword
11451 @cindex RECURSIVE keyword
11452 @cindex keywords, RECURSIVE
11453 @cindex recursion, lack of
11454 @cindex lack of recursion
11456 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11458 Nor does it provide any means for compiling procedures
11459 designed to do recursion.
11461 All recursive code can be rewritten to not use recursion,
11462 but the result is not pretty.
11464 @node Increasing Precision/Range
11465 @subsection Increasing Precision/Range
11467 @cindex -qrealsize=8
11470 @cindex increasing precision
11471 @cindex precision, increasing
11472 @cindex increasing range
11473 @cindex range, increasing
11477 Some compilers, such as @code{f2c}, have an option (@samp{-r8},
11478 @samp{-qrealsize=8} or
11479 similar) that provides automatic treatment of @code{REAL}
11480 entities such that they have twice the storage size, and
11481 a corresponding increase in the range and precision, of what
11482 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11483 (This affects @code{COMPLEX} the same way.)
11485 They also typically offer another option (@samp{-i8}) to increase
11486 @code{INTEGER} entities so they are twice as large
11487 (with roughly twice as much range).
11489 (There are potential pitfalls in using these options.)
11491 @code{g77} does not yet offer any option that performs these
11492 kinds of transformations.
11493 Part of the problem is the lack of detailed specifications regarding
11494 exactly how these options affect the interpretation of constants,
11495 intrinsics, and so on.
11497 Until @code{g77} addresses this need, programmers could improve
11498 the portability of their code by modifying it to not require
11499 compile-time options to produce correct results.
11500 Some free tools are available which may help, specifically
11501 in Toolpack (which one would expect to be sound) and the @file{fortran}
11502 section of the Netlib repository.
11504 Use of preprocessors can provide a fairly portable means
11505 to work around the lack of widely portable methods in the Fortran
11506 language itself (though increasing acceptance of Fortran 90 would
11507 alleviate this problem).
11509 @node Popular Non-standard Types
11510 @subsection Popular Non-standard Types
11511 @cindex @code{INTEGER*2} support
11512 @cindex types, @code{INTEGER*2}
11513 @cindex @code{LOGICAL*1} support
11514 @cindex types, @code{LOGICAL*1}
11516 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11518 Version 0.6 will provide full support for this very
11519 popular set of features.
11520 In the meantime, version 0.5.18 provides rudimentary support
11523 @node Full Support for Compiler Types
11524 @subsection Full Support for Compiler Types
11526 @cindex @code{REAL*16} support
11527 @cindex types, @code{REAL*16}
11528 @cindex @code{INTEGER*8} support
11529 @cindex types, @code{INTEGER*8}
11530 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11531 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11532 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11533 This means providing intrinsic support, and maybe constant
11534 support (using F90 syntax) as well, and, for most
11535 machines will result in automatic support of @code{INTEGER*1},
11536 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11538 This is scheduled for version 0.6.
11540 @node Array Bounds Expressions
11541 @subsection Array Bounds Expressions
11542 @cindex array elements, in adjustable array bounds
11543 @cindex function references, in adjustable array bounds
11544 @cindex array bounds, adjustable
11545 @cindex @code{DIMENSION} statement
11546 @cindex statements, @code{DIMENSION}
11548 @code{g77} doesn't support more general expressions to dimension
11549 arrays, such as array element references, function
11552 For example, @code{g77} currently does not accept the following:
11556 INTEGER N(10), M(N(2), N(1))
11559 @node POINTER Statements
11560 @subsection POINTER Statements
11561 @cindex POINTER statement
11562 @cindex statements, POINTER
11563 @cindex Cray pointers
11565 @code{g77} doesn't support pointers or allocatable objects
11566 (other than automatic arrays).
11567 This set of features is
11568 probably considered just behind intrinsics
11569 in @code{PARAMETER} statements on the list of large,
11570 important things to add to @code{g77}.
11572 In the meantime, consider using the @code{INTEGER(KIND=7)}
11573 declaration to specify that a variable must be
11574 able to hold a pointer.
11575 This construct is not portable to other non-GNU compilers,
11576 but it is portable to all machines GNU Fortran supports
11577 when @code{g77} is used.
11579 @xref{Functions and Subroutines}, for information on
11580 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11581 constructs, which are useful for passing pointers to
11582 procedures written in languages other than Fortran.
11584 @node Sensible Non-standard Constructs
11585 @subsection Sensible Non-standard Constructs
11587 @code{g77} rejects things other compilers accept,
11588 like @samp{INTRINSIC SQRT,SQRT}.
11589 As time permits in the future, some of these things that are easy for
11590 humans to read and write and unlikely to be intended to mean something
11591 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11592 trigger warnings about such non-standard constructs).
11594 Until @code{g77} no longer gratuitously rejects sensible code,
11595 you might as well fix your code
11596 to be more standard-conforming and portable.
11598 The kind of case that is important to except from the
11599 recommendation to change your code is one where following
11600 good coding rules would force you to write non-standard
11601 code that nevertheless has a clear meaning.
11603 For example, when writing an @code{INCLUDE} file that
11604 defines a common block, it might be appropriate to
11605 include a @code{SAVE} statement for the common block
11606 (such as @samp{SAVE /CBLOCK/}), so that variables
11607 defined in the common block retain their values even
11608 when all procedures declaring the common block become
11609 inactive (return to their callers).
11611 However, putting @code{SAVE} statements in an @code{INCLUDE}
11612 file would prevent otherwise standard-conforming code
11613 from also specifying the @code{SAVE} statement, by itself,
11614 to indicate that all local variables and arrays are to
11615 have the @code{SAVE} attribute.
11617 For this reason, @code{g77} already has been changed to
11618 allow this combination, because although the general
11619 problem of gratuitously rejecting unambiguous and
11620 ``safe'' constructs still exists in @code{g77}, this
11621 particular construct was deemed useful enough that
11622 it was worth fixing @code{g77} for just this case.
11624 So, while there is no need to change your code
11625 to avoid using this particular construct, there
11626 might be other, equally appropriate but non-standard
11627 constructs, that you shouldn't have to stop using
11628 just because @code{g77} (or any other compiler)
11629 gratuitously rejects it.
11631 Until the general problem is solved, if you have
11632 any such construct you believe is worthwhile
11633 using (e.g. not just an arbitrary, redundant
11634 specification of an attribute), please submit a
11635 bug report with an explanation, so we can consider
11636 fixing @code{g77} just for cases like yours.
11638 @node READONLY Keyword
11639 @subsection @code{READONLY} Keyword
11642 Support for @code{READONLY}, in @code{OPEN} statements,
11643 requires @code{libg2c} support,
11644 to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
11645 does not delete a file opened on a unit
11646 with the @code{READONLY} keyword,
11647 and perhaps to trigger a fatal diagnostic
11648 if a @code{WRITE} or @code{PRINT}
11649 to such a unit is attempted.
11651 @emph{Note:} It is not sufficient for @code{g77} and @code{libg2c}
11652 (its version of @code{libf2c})
11653 to assume that @code{READONLY} does not need some kind of explicit support
11655 due to UNIX systems not (generally) needing it.
11656 @code{g77} is not just a UNIX-based compiler!
11658 Further, mounting of non-UNIX filesystems on UNIX systems
11660 might require proper @code{READONLY} support.
11663 (Similar issues might be involved with supporting the @code{SHARED}
11666 @node FLUSH Statement
11667 @subsection @code{FLUSH} Statement
11669 @code{g77} could perhaps use a @code{FLUSH} statement that
11670 does what @samp{CALL FLUSH} does,
11671 but that supports @samp{*} as the unit designator (same unit as for
11672 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11675 @node Expressions in FORMAT Statements
11676 @subsection Expressions in @code{FORMAT} Statements
11677 @cindex FORMAT statement
11678 @cindex statements, FORMAT
11680 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11681 Supporting this requires a significant redesign or replacement
11684 However, @code{g77} does support
11685 this construct when the expression is constant
11686 (as of version 0.5.22).
11690 PARAMETER (IWIDTH = 12)
11691 10 FORMAT (I<IWIDTH>)
11694 Otherwise, at least for output (@code{PRINT} and
11695 @code{WRITE}), Fortran code making use of this feature can
11696 be rewritten to avoid it by constructing the @code{FORMAT}
11697 string in a @code{CHARACTER} variable or array, then
11698 using that variable or array in place of the @code{FORMAT}
11699 statement label to do the original @code{PRINT} or @code{WRITE}.
11701 Many uses of this feature on input can be rewritten this way
11702 as well, but not all can.
11703 For example, this can be rewritten:
11710 However, this cannot, in general, be rewritten, especially
11711 when @code{ERR=} and @code{END=} constructs are employed:
11718 @node Explicit Assembler Code
11719 @subsection Explicit Assembler Code
11721 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11722 code to specify explicit assembler code.
11724 @node Q Edit Descriptor
11725 @subsection Q Edit Descriptor
11726 @cindex FORMAT statement
11727 @cindex Q edit descriptor
11728 @cindex edit descriptor, Q
11730 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11731 (This is meant to get the number of characters remaining in an input record.)
11732 Supporting this requires a significant redesign or replacement
11735 A workaround might be using internal I/O or the stream-based intrinsics.
11736 @xref{FGetC Intrinsic (subroutine)}.
11738 @node Old-style PARAMETER Statements
11739 @subsection Old-style PARAMETER Statements
11740 @cindex PARAMETER statement
11741 @cindex statements, PARAMETER
11743 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11744 Supporting this obsolete form of
11745 the @code{PARAMETER} statement would not be particularly hard, as most of the
11746 parsing code is already in place and working.
11748 Until time/money is
11749 spent implementing it, you might as well fix your code to use the
11750 standard form, @samp{PARAMETER (I=1)} (possibly needing
11751 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11752 otherwise, in the obsolete form of @code{PARAMETER}, the
11753 type of the variable is set from the type of the constant being
11756 @node TYPE and ACCEPT I/O Statements
11757 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11758 @cindex TYPE statement
11759 @cindex statements, TYPE
11760 @cindex ACCEPT statement
11761 @cindex statements, ACCEPT
11763 @code{g77} doesn't support the I/O statements @code{TYPE} and
11765 These are common extensions that should be easy to support,
11766 but also are fairly easy to work around in user code.
11768 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11769 by @samp{PRINT fmt,list}.
11770 And, any @samp{ACCEPT fmt,list} statement can be
11771 replaced by @samp{READ fmt,list}.
11773 @node STRUCTURE UNION RECORD MAP
11774 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11775 @cindex STRUCTURE statement
11776 @cindex statements, STRUCTURE
11777 @cindex UNION statement
11778 @cindex statements, UNION
11779 @cindex RECORD statement
11780 @cindex statements, RECORD
11781 @cindex MAP statement
11782 @cindex statements, MAP
11784 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11786 This set of extensions is quite a bit
11787 lower on the list of large, important things to add to @code{g77}, partly
11788 because it requires a great deal of work either upgrading or
11789 replacing @code{libg2c}.
11791 @node OPEN CLOSE and INQUIRE Keywords
11792 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11793 @cindex disposition of files
11794 @cindex OPEN statement
11795 @cindex statements, OPEN
11796 @cindex CLOSE statement
11797 @cindex statements, CLOSE
11798 @cindex INQUIRE statement
11799 @cindex statements, INQUIRE
11801 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11802 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11803 These extensions are easy to add to @code{g77} itself, but
11804 require much more work on @code{libg2c}.
11806 @cindex FORM='PRINT'
11807 @cindex ANS carriage control
11808 @cindex carriage control
11811 @code{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
11812 translate the traditional `carriage control' characters in column 1 of
11813 output to use backspaces, carriage returns and the like. However
11814 programs exist to translate them in output files (or standard output).
11815 These are typically called either @code{fpr} or @code{asa}. You can get
11816 a version of @code{asa} from
11817 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
11818 systems which will probably build easily on other systems.
11819 Alternatively, @code{fpr} is in BSD distributions in various archive
11822 @c (Can both programs can be used in a pipeline,
11823 @c with a named input file,
11824 @c and/or with a named output file???)
11826 @node ENCODE and DECODE
11827 @subsection @code{ENCODE} and @code{DECODE}
11828 @cindex ENCODE statement
11829 @cindex statements, ENCODE
11830 @cindex DECODE statement
11831 @cindex statements, DECODE
11833 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11835 These statements are best replaced by READ and WRITE statements
11836 involving internal files (CHARACTER variables and arrays).
11838 For example, replace a code fragment like
11843 DECODE (80, 9000, LINE) A, B, C
11845 9000 FORMAT (1X, 3(F10.5))
11854 READ (UNIT=LINE, FMT=9000) A, B, C
11856 9000 FORMAT (1X, 3(F10.5))
11859 Similarly, replace a code fragment like
11864 ENCODE (80, 9000, LINE) A, B, C
11866 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11875 WRITE (UNIT=LINE, FMT=9000) A, B, C
11877 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11880 It is entirely possible that @code{ENCODE} and @code{DECODE} will
11881 be supported by a future version of @code{g77}.
11883 @node AUTOMATIC Statement
11884 @subsection @code{AUTOMATIC} Statement
11885 @cindex @code{AUTOMATIC} statement
11886 @cindex statements, @code{AUTOMATIC}
11887 @cindex automatic variables
11888 @cindex variables, automatic
11890 @code{g77} doesn't support the @code{AUTOMATIC} statement that
11893 @code{AUTOMATIC} would identify a variable or array
11894 as not being @code{SAVE}'d, which is normally the default,
11895 but which would be especially useful for code that, @emph{generally},
11896 needed to be compiled with the @samp{-fno-automatic} option.
11898 @code{AUTOMATIC} also would serve as a hint to the compiler that placing
11899 the variable or array---even a very large array--on the stack is acceptable.
11901 @code{AUTOMATIC} would not, by itself, designate the containing procedure
11904 @code{AUTOMATIC} should work syntactically like @code{SAVE},
11905 in that @code{AUTOMATIC} with no variables listed should apply to
11906 all pertinent variables and arrays
11907 (which would not include common blocks or their members).
11909 Variables and arrays denoted as @code{AUTOMATIC}
11910 would not be permitted to be initialized via @code{DATA}
11911 or other specification of any initial values,
11912 requiring explicit initialization,
11913 such as via assignment statements.
11917 Perhaps @code{UNSAVE} and @code{STATIC},
11918 as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
11919 should be provided as well.
11921 @node Suppressing Space Padding
11922 @subsection Suppressing Space Padding of Source Lines
11924 @code{g77} should offer VXT-Fortran-style suppression of virtual
11925 spaces at the end of a source line
11926 if an appropriate command-line option is specified.
11928 This affects cases where
11929 a character constant is continued onto the next line in a fixed-form
11930 source file, as in the following example:
11933 10 PRINT *,'HOW MANY
11938 @code{g77}, and many other compilers, virtually extend
11939 the continued line through column 72 with spaces that become part
11940 of the character constant, but Digital Fortran normally didn't,
11941 leaving only one space between @samp{MANY} and @samp{SPACES?}
11942 in the output of the above statement.
11944 Fairly recently, at least one version of Digital Fortran
11945 was enhanced to provide the other behavior when a
11946 command-line option is specified, apparently due to demand
11947 from readers of the USENET group @file{comp.lang.fortran}
11948 to offer conformance to this widespread practice in the
11950 @code{g77} should return the favor by offering conformance
11951 to Digital's approach to handling the above example.
11953 @node Fortran Preprocessor
11954 @subsection Fortran Preprocessor
11956 @code{g77} should offer a preprocessor designed specifically
11957 for Fortran to replace @samp{cpp -traditional}.
11958 There are several out there worth evaluating, at least.
11960 Such a preprocessor would recognize Hollerith constants,
11961 properly parse comments and character constants, and so on.
11962 It might also recognize, process, and thus preprocess
11963 files included via the @code{INCLUDE} directive.
11965 @node Bit Operations on Floating-point Data
11966 @subsection Bit Operations on Floating-point Data
11967 @cindex @code{And} intrinsic
11968 @cindex intrinsics, @code{And}
11969 @cindex @code{Or} intrinsic
11970 @cindex intrinsics, @code{Or}
11971 @cindex @code{Shift} intrinsic
11972 @cindex intrinsics, @code{Shift}
11974 @code{g77} does not allow @code{REAL} and other non-integral types for
11975 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
11977 For example, this program is rejected by @code{g77}, because
11978 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
11981 DATA A/7.54/, B/9.112/
11982 PRINT *, IAND(A, B)
11986 @node POSIX Standard
11987 @subsection @code{POSIX} Standard
11989 @code{g77} should support the POSIX standard for Fortran.
11991 @node Floating-point Exception Handling
11992 @subsection Floating-point Exception Handling
11993 @cindex floating-point, exceptions
11994 @cindex exceptions, floating-point
11995 @cindex FPE handling
11998 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
11999 general control over whether or not floating-point exceptions are trapped or
12001 (Ignoring them typically results in NaN values being
12002 propagated in systems that conform to IEEE 754.)
12003 The behaviour is normally inherited from the system-dependent startup
12004 code, though some targets, such as the Alpha, have code generation
12005 options which change the behaviour.
12007 Most systems provide some C-callable mechanism to change this; this can
12008 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
12009 For example, just compiling and linking the following C code with your
12010 program will turn on exception trapping for the ``common'' exceptions
12011 on an x86-based GNU system:
12014 #include <fpu_control.h>
12015 static void __attribute__ ((constructor))
12018 __setfpucw (_FPU_DEFAULT &
12019 ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
12023 A convenient trick is to compile this something like:
12025 gcc -o libtrapfpe.a trapfpe.c
12027 and then use it by adding @samp{-trapfpe} to the @code{g77} command line
12030 @node Nonportable Conversions
12031 @subsection Nonportable Conversions
12032 @cindex nonportable conversions
12033 @cindex conversions, nonportable
12035 @code{g77} doesn't accept some particularly nonportable,
12036 silent data-type conversions such as @code{LOGICAL}
12037 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
12038 is type @code{REAL}), that other compilers might
12041 Some of these conversions are accepted by @code{g77}
12042 when the @samp{-fugly-logint} option is specified.
12043 Perhaps it should accept more or all of them.
12045 @node Large Automatic Arrays
12046 @subsection Large Automatic Arrays
12047 @cindex automatic arrays
12048 @cindex arrays, automatic
12050 Currently, automatic arrays always are allocated on the stack.
12051 For situations where the stack cannot be made large enough,
12052 @code{g77} should offer a compiler option that specifies
12053 allocation of automatic arrays in heap storage.
12055 @node Support for Threads
12056 @subsection Support for Threads
12058 @cindex parallel processing
12060 Neither the code produced by @code{g77} nor the @code{libg2c} library
12061 are thread-safe, nor does @code{g77} have support for parallel processing
12062 (other than the instruction-level parallelism available on some
12064 A package such as PVM might help here.
12066 @node Gracefully Handle Sensible Bad Code
12067 @subsection Gracefully Handle Sensible Bad Code
12069 @code{g77} generally should continue processing for
12070 warnings and recoverable (user) errors whenever possible---that
12071 is, it shouldn't gratuitously make bad or useless code.
12082 When compiling the above with @samp{-ff2c-intrinsics-disable},
12083 @code{g77} should indeed complain about passing @code{ZABS},
12084 but it still should compile, instead of rejecting
12085 the entire @code{CALL} statement.
12086 (Some of this is related to improving
12087 the compiler internals to improve how statements are analyzed.)
12089 @node Non-standard Conversions
12090 @subsection Non-standard Conversions
12092 @samp{-Wconversion} and related should flag places where non-standard
12093 conversions are found.
12094 Perhaps much of this would be part of @samp{-Wugly*}.
12096 @node Non-standard Intrinsics
12097 @subsection Non-standard Intrinsics
12099 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
12100 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
12101 This would help find code that might fail silently when ported to another
12104 @node Modifying DO Variable
12105 @subsection Modifying @code{DO} Variable
12107 @code{g77} should warn about modifying @code{DO} variables
12108 via @code{EQUIVALENCE}.
12109 (The internal information gathered to produce this warning
12110 might also be useful in setting the
12111 internal ``doiter'' flag for a variable or even array
12112 reference within a loop, since that might produce faster code someday.)
12114 For example, this code is invalid, so @code{g77} should warn about
12115 the invalid assignment to @samp{NOTHER}:
12118 EQUIVALENCE (I, NOTHER)
12120 IF (I.EQ. 10) NOTHER = 20
12124 @node Better Pedantic Compilation
12125 @subsection Better Pedantic Compilation
12127 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
12128 and use it only to generate
12129 warnings instead of rejecting constructs outright.
12131 if a variable that dimensions an array is not a dummy or placed
12132 explicitly in @code{COMMON} (F77 does not allow it to be
12133 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
12134 follow statement-function-definition statements; about all sorts of
12135 syntactic extensions.
12137 @node Warn About Implicit Conversions
12138 @subsection Warn About Implicit Conversions
12140 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
12141 to expect automatic, silent, and
12142 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
12143 constants to @code{REAL(KIND=2)} based on context.
12145 For example, it would warn about cases like this:
12148 DOUBLE PRECISION FOO
12149 PARAMETER (TZPHI = 9.435784839284958)
12153 @node Invalid Use of Hollerith Constant
12154 @subsection Invalid Use of Hollerith Constant
12156 @code{g77} should disallow statements like @samp{RETURN 2HAB},
12157 which are invalid in both source forms
12158 (unlike @samp{RETURN (2HAB)},
12159 which probably still makes no sense but at least can
12160 be reliably parsed).
12161 Fixed-form processing rejects it, but not free-form, except
12162 in a way that is a bit difficult to understand.
12164 @node Dummy Array Without Dimensioning Dummy
12165 @subsection Dummy Array Without Dimensioning Dummy
12167 @code{g77} should complain when a list of dummy arguments containing an
12168 adjustable dummy array does
12169 not also contain every variable listed in the dimension list of the
12172 Currently, @code{g77} does complain about a variable that
12173 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
12174 area, but this needs to be extended to catch cases where it doesn't appear in
12175 every dummy list that also lists any arrays it dimensions.
12177 For example, @code{g77} should warn about the entry point @samp{ALT}
12178 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
12182 SUBROUTINE PRIMARY(ARRAY, ISIZE)
12187 @node Invalid FORMAT Specifiers
12188 @subsection Invalid FORMAT Specifiers
12190 @code{g77} should check @code{FORMAT} specifiers for validity
12191 as it does @code{FORMAT} statements.
12193 For example, a diagnostic would be produced for:
12196 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
12199 @node Ambiguous Dialects
12200 @subsection Ambiguous Dialects
12202 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
12203 @samp{-Wvxt}, @samp{-Wf90}, and so on.
12204 These would warn about places in the user's source where ambiguities
12205 are found, helpful in resolving ambiguities in the program's
12206 dialect or dialects.
12208 @node Unused Labels
12209 @subsection Unused Labels
12211 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
12213 @node Informational Messages
12214 @subsection Informational Messages
12216 @code{g77} needs an option to suppress information messages (notes).
12217 @samp{-w} does this but also suppresses warnings.
12218 The default should be to suppress info messages.
12220 Perhaps info messages should simply be eliminated.
12222 @node Uninitialized Variables at Run Time
12223 @subsection Uninitialized Variables at Run Time
12225 @code{g77} needs an option to initialize everything (not otherwise
12226 explicitly initialized) to ``weird''
12227 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
12228 largest-magnitude integers, would help track down references to
12229 some kinds of uninitialized variables at run time.
12231 Note that use of the options @samp{-O -Wuninitialized} can catch
12232 many such bugs at compile time.
12234 @node Portable Unformatted Files
12235 @subsection Portable Unformatted Files
12237 @cindex unformatted files
12238 @cindex file formats
12239 @cindex binary data
12240 @cindex byte ordering
12241 @code{g77} has no facility for exchanging unformatted files with systems
12242 using different number formats---even differing only in endianness (byte
12243 order)---or written by other compilers. Some compilers provide
12244 facilities at least for doing byte-swapping during unformatted I/O.
12246 It is unrealistic to expect to cope with exchanging unformatted files
12247 with arbitrary other compiler runtimes, but the @code{g77} runtime
12248 should at least be able to read files written by @code{g77} on systems
12249 with different number formats, particularly if they differ only in byte
12252 In case you do need to write a program to translate to or from
12253 @code{g77} (@code{libf2c}) unformatted files, they are written as
12257 Unformatted sequential records consist of
12260 A number giving the length of the record contents;
12262 the length of record contents again (for backspace).
12265 The record length is of C type
12266 @code{long}; this means that it is 8 bytes on 64-bit systems such as
12267 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
12268 Consequently such files cannot be exchanged between 64-bit and 32-bit
12269 systems, even with the same basic number format.
12270 @item Direct access
12271 Unformatted direct access files form a byte stream of length
12272 @var{records}*@var{recl} bytes, where @var{records} is the maximum
12273 record number (@code{REC=@var{records}}) written and @var{recl} is the
12274 record length in bytes specified in the @code{OPEN} statement
12275 (@code{RECL=@var{recl}}). Data appear in the records as determined by
12276 the relevant @code{WRITE} statement. Dummy records with arbitrary
12277 contents appear in the file in place of records which haven't been
12281 Thus for exchanging a sequential or direct access unformatted file
12282 between big- and little-endian 32-bit systems using IEEE 754 floating
12283 point it would be sufficient to reverse the bytes in consecutive words
12284 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
12285 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
12288 If necessary, it is possible to do byte-oriented i/o with @code{g77}'s
12289 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
12290 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
12291 array or a set of scalars.
12295 If you need to exchange binary data between arbitrary system and
12296 compiler variations, we recommend using a portable binary format with
12297 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
12298 or PACT's PDB@footnote{No, not @emph{that} one.}
12299 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
12300 say, CDF or XDR, HDF-like systems write in the native number formats and
12301 only incur overhead when they are read on a system with a different
12302 format.) A future @code{g77} runtime library should use such
12305 @node Labels Visible to Debugger
12306 @subsection Labels Visible to Debugger
12308 @code{g77} should output debugging information for statements labels,
12309 for use by debuggers that know how to support them.
12310 Same with weirder things like construct names.
12311 It is not yet known if any debug formats or debuggers support these.
12313 @node Disappointments
12314 @section Disappointments and Misunderstandings
12316 These problems are perhaps regrettable, but we don't know any practical
12317 way around them for now.
12320 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
12321 external name @samp{foo_}.
12322 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
12323 and @samp{SUBROUTINE FOO}.
12324 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
12327 @node Mangling of Names
12328 @subsection Mangling of Names in Source Code
12329 @cindex naming issues
12330 @cindex external names
12331 @cindex common blocks
12335 The current external-interface design, which includes naming of
12336 external procedures, COMMON blocks, and the library interface,
12337 has various usability problems, including things like adding
12338 underscores where not really necessary (and preventing easier
12339 inter-language operability) and yet not providing complete
12340 namespace freedom for user C code linked with Fortran apps (due
12341 to the naming of functions in the library, among other things).
12343 Project GNU should at least get all this ``right'' for systems
12344 it fully controls, such as the Hurd, and provide defaults and
12345 options for compatibility with existing systems and interoperability
12346 with popular existing compilers.
12348 @node Multiple Definitions of External Names
12349 @subsection Multiple Definitions of External Names
12351 @cindex BLOCK DATA statement
12352 @cindex statements, BLOCK DATA
12353 @cindex @code{COMMON} statement
12354 @cindex statements, @code{COMMON}
12355 @cindex naming conflicts
12357 @code{g77} doesn't allow a common block and an external procedure or
12358 @code{BLOCK DATA} to have the same name.
12359 Some systems allow this, but @code{g77} does not,
12360 to be compatible with @code{f2c}.
12362 @code{g77} could special-case the way it handles
12363 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12364 particular area (necessarily, since @code{g77} offers an
12365 important feature here), but
12366 it is likely that such special-casing would be very annoying to people
12367 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12368 @samp{FOO} in the same program unit, to refer to external procedures, since
12369 the result would be that @code{g77} would treat these references as requests to
12370 force-load BLOCK DATA program units.
12372 In that case, if @code{g77} modified
12373 names of @code{BLOCK DATA} so they could have the same names as
12374 @code{COMMON}, users
12375 would find that their programs wouldn't link because the @samp{FOO} procedure
12376 didn't have its name translated the same way.
12378 (Strictly speaking,
12379 @code{g77} could emit a null-but-externally-satisfying definition of
12380 @samp{FOO} with its name transformed as if it had been a
12381 @code{BLOCK DATA}, but that probably invites more trouble than it's
12384 @node Limitation on Implicit Declarations
12385 @subsection Limitation on Implicit Declarations
12386 @cindex IMPLICIT CHARACTER*(*) statement
12387 @cindex statements, IMPLICIT CHARACTER*(*)
12389 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12390 This is not standard-conforming.
12393 @section Certain Changes We Don't Want to Make
12395 This section lists changes that people frequently request, but which
12396 we do not make because we think GNU Fortran is better without them.
12399 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12400 is one, not two, characters long.
12401 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12403 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12404 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12405 single-precision constant,
12406 and might be interpreted as
12407 @samp{9.435785} or similar.
12408 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12409 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12410 not behave as expected.
12413 @node Backslash in Constants
12414 @subsection Backslash in Constants
12416 @cindex @code{f77} support
12417 @cindex support, @code{f77}
12419 In the opinion of many experienced Fortran users,
12420 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12421 as currently set by @code{g77}.
12423 First of all, you can always specify
12424 @samp{-fno-backslash} to turn off this processing.
12426 Despite not being within the spirit (though apparently within the
12427 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12428 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12429 default to, and apparently lots of code depends on this feature.
12431 This is a particularly troubling issue.
12432 The use of a C construct in the midst of Fortran code
12433 is bad enough, worse when it makes existing Fortran
12434 programs stop working (as happens when programs written
12435 for non-UNIX systems are ported to UNIX systems with
12436 compilers that provide the @samp{-fbackslash} feature
12437 as the default---sometimes with no option to turn it off).
12439 The author of GNU Fortran wished, for reasons of linguistic
12440 purity, to make @samp{-fno-backslash} the default for GNU
12441 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12442 to specify @samp{-fbackslash} to get the UNIX behavior.
12444 However, the realization that @code{g77} is intended as
12445 a replacement for @emph{UNIX} @code{f77}, caused the author
12446 to choose to make @code{g77} as compatible with
12447 @code{f77} as feasible, which meant making @samp{-fbackslash}
12450 The primary focus on compatibility is at the source-code
12451 level, and the question became ``What will users expect
12452 a replacement for @code{f77} to do, by default?''
12453 Although at least one UNIX @code{f77} does not provide
12454 @samp{-fbackslash} as a default, it appears that
12455 the majority of them do, which suggests that
12456 the majority of code that is compiled by UNIX @code{f77}
12457 compilers expects @samp{-fbackslash} to be the default.
12459 It is probably the case that more code exists
12460 that would @emph{not} work with @samp{-fbackslash}
12461 in force than code that requires it be in force.
12463 However, most of @emph{that} code is not being compiled
12465 and when it is, new build procedures (shell scripts,
12466 makefiles, and so on) must be set up anyway so that
12467 they work under UNIX.
12468 That makes a much more natural and safe opportunity for
12469 non-UNIX users to adapt their build procedures for
12470 @code{g77}'s default of @samp{-fbackslash} than would
12471 exist for the majority of UNIX @code{f77} users who
12472 would have to modify existing, working build procedures
12473 to explicitly specify @samp{-fbackslash} if that was
12476 One suggestion has been to configure the default for
12477 @samp{-fbackslash} (and perhaps other options as well)
12478 based on the configuration of @code{g77}.
12480 This is technically quite straightforward, but will be avoided
12481 even in cases where not configuring defaults to be
12482 dependent on a particular configuration greatly inconveniences
12483 some users of legacy code.
12485 Many users appreciate the GNU compilers because they provide an
12486 environment that is uniform across machines.
12487 These users would be
12488 inconvenienced if the compiler treated things like the
12489 format of the source code differently on certain machines.
12491 Occasionally users write programs intended only for a particular machine
12493 On these occasions, the users would benefit if the GNU Fortran compiler
12494 were to support by default the same dialect as the other compilers on
12496 But such applications are rare.
12497 And users writing a
12498 program to run on more than one type of machine cannot possibly benefit
12499 from this kind of compatibility.
12500 (This is consistent with the design goals for @code{gcc}.
12501 To change them for @code{g77}, you must first change them
12503 Do not ask the maintainers of @code{g77} to do this for you,
12504 or to disassociate @code{g77} from the widely understood, if
12505 not widely agreed-upon, goals for GNU compilers in general.)
12507 This is why GNU Fortran does and will treat backslashes in the same
12508 fashion on all types of machines (by default).
12509 @xref{Direction of Language Development}, for more information on
12510 this overall philosophy guiding the development of the GNU Fortran
12513 Of course, users strongly concerned about portability should indicate
12514 explicitly in their build procedures which options are expected
12515 by their source code, or write source code that has as few such
12516 expectations as possible.
12518 For example, avoid writing code that depends on backslash (@samp{\})
12519 being interpreted either way in particular, such as by
12520 starting a program unit with:
12524 PARAMETER (BACKSL = '\\')
12528 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12530 In this way, users can write programs which have the same meaning
12531 in many Fortran dialects.
12533 (However, this technique does not work for Hollerith constants---which
12534 is just as well, since the only generally portable uses for Hollerith
12535 constants are in places where character constants can and should
12536 be used instead, for readability.)
12538 @node Initializing Before Specifying
12539 @subsection Initializing Before Specifying
12540 @cindex initialization, statement placement
12541 @cindex placing initialization statements
12543 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12544 source code before @samp{COMMON VAR},
12545 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12546 In general, @code{g77} requires initialization of a variable
12547 or array to be specified @emph{after} all other specifications
12548 of attributes (type, size, placement, and so on) of that variable
12549 or array are specified (though @emph{confirmation} of data type is
12552 It is @emph{possible} @code{g77} will someday allow all of this,
12553 even though it is not allowed by the FORTRAN 77 standard.
12555 Then again, maybe it is better to have
12556 @code{g77} always require placement of @code{DATA}
12557 so that it can possibly immediately write constants
12558 to the output file, thus saving time and space.
12560 That is, @samp{DATA A/1000000*1/} should perhaps always
12561 be immediately writable to canonical assembler, unless it's already known
12562 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12563 and to do this it cannot be followed by @samp{COMMON A}.
12565 @node Context-Sensitive Intrinsicness
12566 @subsection Context-Sensitive Intrinsicness
12567 @cindex intrinsics, context-sensitive
12568 @cindex context-sensitive intrinsics
12570 @code{g77} treats procedure references to @emph{possible} intrinsic
12571 names as always enabling their intrinsic nature, regardless of
12572 whether the @emph{form} of the reference is valid for that
12575 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12576 an invalid reference to the @code{SQRT} intrinsic function,
12577 because the reference is a subroutine invocation.
12579 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12580 as a reference to a @emph{procedure} named @samp{SQRT}, not
12581 to a @emph{variable} with that name (as it would for a statement
12582 such as @samp{V = SQRT}).
12584 Next, @code{g77} establishes that, in the program unit being compiled,
12585 @code{SQRT} is an intrinsic---not a subroutine that
12586 happens to have the same name as an intrinsic (as would be
12587 the case if, for example, @samp{EXTERNAL SQRT} was present).
12589 Finally, @code{g77} recognizes that the @emph{form} of the
12590 reference is invalid for that particular intrinsic.
12591 That is, it recognizes that it is invalid for an intrinsic
12592 @emph{function}, such as @code{SQRT}, to be invoked as
12593 a @emph{subroutine}.
12595 At that point, @code{g77} issues a diagnostic.
12597 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12598 references an external subroutine of their own, not an
12599 intrinsic function.
12601 However, @code{g77} knows about intrinsic
12602 subroutines, not just functions, and is able to support both having
12603 the same names, for example.
12605 As a result of this, @code{g77} rejects calls
12606 to intrinsics that are not subroutines, and function invocations
12607 of intrinsics that are not functions, just as it (and most compilers)
12608 rejects invocations of intrinsics with the wrong number (or types)
12611 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12612 a user-written subroutine named @samp{SQRT}.
12614 @node Context-Sensitive Constants
12615 @subsection Context-Sensitive Constants
12616 @cindex constants, context-sensitive
12617 @cindex context-sensitive constants
12619 @code{g77} does not use context to determine the types of
12620 constants or named constants (@code{PARAMETER}), except
12621 for (non-standard) typeless constants such as @samp{'123'O}.
12623 For example, consider the following statement:
12626 PRINT *, 9.435784839284958 * 2D0
12630 @code{g77} will interpret the (truncated) constant
12631 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12632 constant, because the suffix @code{D0} is not specified.
12634 As a result, the output of the above statement when
12635 compiled by @code{g77} will appear to have ``less precision''
12636 than when compiled by other compilers.
12638 In these and other cases, some compilers detect the
12639 fact that a single-precision constant is used in
12640 a double-precision context and therefore interpret the
12641 single-precision constant as if it was @emph{explicitly}
12642 specified as a double-precision constant.
12643 (This has the effect of appending @emph{decimal}, not
12644 @emph{binary}, zeros to the fractional part of the
12645 number---producing different computational results.)
12647 The reason this misfeature is dangerous is that a slight,
12648 apparently innocuous change to the source code can change
12649 the computational results.
12654 DOUBLE PRECISION FIVE
12655 PARAMETER (ALMOST = 5.000000000001)
12657 CLOSE = 5.000000000001
12658 PRINT *, 5.000000000001 - FIVE
12659 PRINT *, ALMOST - FIVE
12660 PRINT *, CLOSE - FIVE
12665 Running the above program should
12666 result in the same value being
12667 printed three times.
12668 With @code{g77} as the compiler,
12671 However, compiled by many other compilers,
12672 running the above program would print
12673 two or three distinct values, because
12674 in two or three of the statements, the
12675 constant @samp{5.000000000001}, which
12676 on most systems is exactly equal to @samp{5.}
12677 when interpreted as a single-precision constant,
12678 is instead interpreted as a double-precision
12679 constant, preserving the represented
12681 However, this ``clever'' promotion of
12682 type does not extend to variables or,
12683 in some compilers, to named constants.
12685 Since programmers often are encouraged to replace manifest
12686 constants or permanently-assigned variables with named
12687 constants (@code{PARAMETER} in Fortran), and might need
12688 to replace some constants with variables having the same
12689 values for pertinent portions of code,
12690 it is important that compilers treat code so modified in the
12691 same way so that the results of such programs are the same.
12692 @code{g77} helps in this regard by treating constants just
12693 the same as variables in terms of determining their types
12694 in a context-independent way.
12696 Still, there is a lot of existing Fortran code that has
12697 been written to depend on the way other compilers freely
12698 interpret constants' types based on context, so anything
12699 @code{g77} can do to help flag cases of this in such code
12700 could be very helpful.
12702 @node Equivalence Versus Equality
12703 @subsection Equivalence Versus Equality
12704 @cindex .EQV., with integer operands
12705 @cindex comparing logical expressions
12706 @cindex logical expressions, comparing
12708 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12709 is not supported, except via @samp{-fugly-logint}, which is not
12710 recommended except for legacy code (where the behavior expected
12711 by the @emph{code} is assumed).
12713 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12714 and @code{.NEQV.} instead, as these are permitted by the various
12717 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12718 to work if either of its operands is @code{LOGICAL}.
12720 The problem with supporting this ``feature'' is that there is
12721 unlikely to be consensus on how it works, as illustrated by the
12722 following sample program:
12726 DATA L,M,N /3*.FALSE./
12727 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
12731 The issue raised by the above sample program is: what is the
12732 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
12733 @code{LOGICAL} operands?
12735 Some programmers will argue that it is the same as the precedence
12736 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
12738 By this interpretation, the subexpression @samp{M.EQ.N} must be
12739 evaluated first in the above program, resulting in a program that,
12740 when run, does not execute the @code{PRINT} statement.
12742 Other programmers will argue that the precedence is the same as
12743 the precedence for @code{.EQV.}, which is restricted by the standards
12744 to @code{LOGICAL} operands.
12745 By this interpretation, the subexpression @samp{L.AND.M} must be
12746 evaluated first, resulting in a program that @emph{does} execute
12747 the @code{PRINT} statement.
12749 Assigning arbitrary semantic interpretations to syntactic expressions
12750 that might legitimately have more than one ``obvious'' interpretation
12751 is generally unwise.
12753 The creators of the various Fortran standards have done a good job
12754 in this case, requiring a distinct set of operators (which have their
12755 own distinct precedence) to compare @code{LOGICAL} operands.
12756 This requirement results in expression syntax with more certain
12757 precedence (without requiring substantial context), making it easier
12758 for programmers to read existing code.
12759 @code{g77} will avoid muddying up elements of the Fortran language
12760 that were well-designed in the first place.
12762 (Ask C programmers about the precedence of expressions such as
12763 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
12764 you, without knowing more context, whether the @samp{&} and @samp{-}
12765 operators are infix (binary) or unary!)
12767 Most dangerous of all is the fact that,
12768 even assuming consensus on its meaning,
12769 an expression like @samp{L.AND.M.EQ.N},
12770 if it is the result of a typographical error,
12771 doesn't @emph{look} like it has such a typo.
12772 Even experienced Fortran programmers would not likely notice that
12773 @samp{L.AND.M.EQV.N} was, in fact, intended.
12775 So, this is a prime example of a circumstance in which
12776 a quality compiler diagnoses the code,
12777 instead of leaving it up to someone debugging it
12778 to know to turn on special compiler options
12779 that might diagnose it.
12781 @node Order of Side Effects
12782 @subsection Order of Side Effects
12783 @cindex side effects, order of evaluation
12784 @cindex order of evaluation, side effects
12786 @code{g77} does not necessarily produce code that, when run, performs
12787 side effects (such as those performed by function invocations)
12788 in the same order as in some other compiler---or even in the same
12789 order as another version, port, or invocation (using different
12790 command-line options) of @code{g77}.
12792 It is never safe to depend on the order of evaluation of side effects.
12793 For example, an expression like this may very well behave differently
12794 from one compiler to another:
12797 J = IFUNC() - IFUNC()
12801 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
12803 Either invocation might happen first.
12804 If @samp{IFUNC} returns 5 the first time it is invoked, and
12805 returns 12 the second time, @samp{J} might end up with the
12806 value @samp{7}, or it might end up with @samp{-7}.
12808 Generally, in Fortran, procedures with side-effects intended to
12809 be visible to the caller are best designed as @emph{subroutines},
12811 Examples of such side-effects include:
12815 The generation of random numbers
12816 that are intended to influence return values.
12820 (other than internal I/O to local variables).
12823 Updating information in common blocks.
12826 An example of a side-effect that is not intended to be visible
12827 to the caller is a function that maintains a cache of recently
12828 calculated results, intended solely to speed repeated invocations
12829 of the function with identical arguments.
12830 Such a function can be safely used in expressions, because
12831 if the compiler optimizes away one or more calls to the
12832 function, operation of the program is unaffected (aside
12833 from being speeded up).
12835 @node Warnings and Errors
12836 @section Warning Messages and Error Messages
12838 @cindex error messages
12839 @cindex warnings vs errors
12840 @cindex messages, warning and error
12841 The GNU compiler can produce two kinds of diagnostics: errors and
12843 Each kind has a different purpose:
12847 @emph{Errors} report problems that make it impossible to compile your
12849 GNU Fortran reports errors with the source file name, line
12850 number, and column within the line where the problem is apparent.
12853 @emph{Warnings} report other unusual conditions in your code that
12854 @emph{might} indicate a problem, although compilation can (and does)
12856 Warning messages also report the source file name, line number,
12857 and column information,
12858 but include the text @samp{warning:} to distinguish them
12859 from error messages.
12862 Warnings might indicate danger points where you should check to make sure
12863 that your program really does what you intend; or the use of obsolete
12864 features; or the use of nonstandard features of GNU Fortran.
12865 Many warnings are issued only if you ask for them, with one of the
12866 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
12869 @emph{Note:} Currently, the text of the line and a pointer to the column
12870 is printed in most @code{g77} diagnostics.
12871 Probably, as of version 0.6, @code{g77} will
12872 no longer print the text of the source line, instead printing
12873 the column number following the file name and line number in
12874 a form that GNU Emacs recognizes.
12875 This change is expected to speed up and reduce the memory usage
12876 of the @code{g77} compiler.
12878 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
12880 @c GNU Fortran always tries to compile your program if possible; it never
12881 @c gratuitously rejects a program whose meaning is clear merely because
12882 @c (for instance) it fails to conform to a standard. In some cases,
12883 @c however, the Fortran standard specifies that certain extensions are
12884 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
12885 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
12886 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
12887 @c This does not mean that @emph{all} non-ANSI constructs get warnings
12890 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
12891 more detail on these and related command-line options.
12893 @node Open Questions
12894 @chapter Open Questions
12896 Please consider offering useful answers to these questions!
12900 @code{LOC()} and other intrinsics are probably somewhat misclassified.
12901 Is the a need for more precise classification of intrinsics, and if so,
12902 what are the appropriate groupings?
12903 Is there a need to individually
12904 enable/disable/delete/hide intrinsics from the command line?
12908 @chapter Reporting Bugs
12910 @cindex reporting bugs
12912 Your bug reports play an essential role in making GNU Fortran reliable.
12914 When you encounter a problem, the first thing to do is to see if it is
12917 If it isn't known, then you should report the problem.
12919 Reporting a bug might help you by bringing a solution to your problem, or
12921 (If it does not, look in the service directory; see
12923 In any case, the principal function of a bug report is
12924 to help the entire community by making the next version of GNU Fortran work
12926 Bug reports are your contribution to the maintenance of GNU Fortran.
12928 Since the maintainers are very overloaded, we cannot respond to every
12930 However, if the bug has not been fixed, we are likely to
12931 send you a patch and ask you to tell us whether it works.
12933 In order for a bug report to serve its purpose, you must include the
12934 information that makes for fixing the bug.
12937 * Criteria: Bug Criteria. Have you really found a bug?
12938 * Where: Bug Lists. Where to send your bug report.
12939 * Reporting: Bug Reporting. How to report a bug effectively.
12940 * Patches: Sending Patches. How to send a patch for GNU Fortran.
12943 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
12944 for information on problems we already know about.
12946 @xref{Service,,How To Get Help with GNU Fortran},
12947 for information on where to ask for help.
12950 @section Have You Found a Bug?
12951 @cindex bug criteria
12953 If you are not sure whether you have found a bug, here are some guidelines:
12956 @cindex fatal signal
12959 If the compiler gets a fatal signal, for any input whatever, that is a
12961 Reliable compilers never crash---they just remain obsolete.
12963 @cindex invalid assembly code
12964 @cindex assembly code, invalid
12966 If the compiler produces invalid assembly code, for any input whatever,
12967 @c (except an @code{asm} statement),
12968 that is a compiler bug, unless the
12969 compiler reports errors (not just warnings) which would ordinarily
12970 prevent the assembler from being run.
12972 @cindex undefined behavior
12973 @cindex undefined function value
12975 If the compiler produces valid assembly code that does not correctly
12976 execute the input source code, that is a compiler bug.
12978 However, you must double-check to make sure, because you might have run
12979 into an incompatibility between GNU Fortran and traditional Fortran.
12980 @c (@pxref{Incompatibilities}).
12981 These incompatibilities might be considered
12982 bugs, but they are inescapable consequences of valuable features.
12984 Or you might have a program whose behavior is undefined, which happened
12985 by chance to give the desired results with another Fortran compiler.
12986 It is best to check the relevant Fortran standard thoroughly if
12987 it is possible that the program indeed does something undefined.
12989 After you have localized the error to a single source line, it should
12990 be easy to check for these things.
12991 If your program is correct and well defined, you have found
12994 It might help if, in your submission, you identified the specific
12995 language in the relevant Fortran standard that specifies the
12996 desired behavior, if it isn't likely to be obvious and agreed-upon
12997 by all Fortran users.
13000 If the compiler produces an error message for valid input, that is a
13003 @cindex invalid input
13005 If the compiler does not produce an error message for invalid input,
13006 that is a compiler bug.
13007 However, you should note that your idea of
13008 ``invalid input'' might be someone else's idea
13009 of ``an extension'' or ``support for traditional practice''.
13012 If you are an experienced user of Fortran compilers, your suggestions
13013 for improvement of GNU Fortran are welcome in any case.
13016 Many, perhaps most, bug reports against @code{g77} turn out to
13017 be bugs in the user's code.
13018 While we find such bug reports educational, they sometimes take
13019 a considerable amount of time to track down or at least respond
13020 to---time we could be spending making @code{g77}, not some user's
13023 Some steps you can take to verify that the bug is not certainly
13024 in the code you're compiling with @code{g77}:
13028 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
13029 These options enable many useful warning; the @samp{-O} option
13030 enables flow analysis that enables the uninitialized-variable
13033 If you investigate the warnings and find evidence of possible bugs
13034 in your code, fix them first and retry @code{g77}.
13037 Compile your code using the @code{g77} options @samp{-finit-local-zero},
13038 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
13039 combinations thereof.
13041 If your code works with any of these combinations, that is not
13042 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
13043 by your code might simply be avoided, or have a different, more subtle
13044 effect, when different options are used---but it can be a
13045 strong indicator that your code is making unwarranted assumptions
13046 about the Fortran dialect and/or underlying machine it is
13047 being compiled and run on.
13049 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
13050 for information on the @samp{-fno-automatic} and
13051 @samp{-finit-local-zero} options and how to convert
13052 their use into selective changes in your own code.
13056 Validate your code with @code{ftnchek} or a similar code-checking
13058 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
13059 or @uref{ftp://ftp.dsm.fordham.edu}.
13062 @cindex Makefile example
13063 Here are some sample @file{Makefile} rules using @code{ftnchek}
13064 ``project'' files to do cross-file checking and @code{sfmakedepend}
13065 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
13066 to maintain dependencies automatically.
13067 These assume the use of GNU @code{make}.
13070 # Dummy suffix for ftnchek targets:
13074 # How to compile .f files (for implicit rule):
13076 # Assume `include' directory:
13077 FFLAGS = -Iinclude -g -O -Wall
13079 # Flags for ftnchek:
13080 CHEK1 = -array=0 -include=includes -noarray
13081 CHEK2 = -nonovice -usage=1 -notruncation
13082 CHEKFLAGS = $(CHEK1) $(CHEK2)
13084 # Run ftnchek with all the .prj files except the one corresponding
13085 # to the target's root:
13087 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
13088 -noextern -library $<
13090 # Derive a project file from a source file:
13092 ftnchek $(CHEKFLAGS) -noextern -project -library $<
13094 # The list of objects is assumed to be in variable OBJS.
13095 # Sources corresponding to the objects:
13096 SRCS = $(OBJS:%.o=%.f)
13097 # ftnchek project files:
13098 PRJS = $(OBJS:%.o=%.prj)
13100 # Build the program
13102 $(FC) -o $@ $(OBJS)
13104 chekall: $(PRJS) ; \
13105 ftnchek $(CHEKFLAGS) $(PRJS)
13109 # For Emacs M-x find-tag:
13113 # Rebuild dependencies:
13115 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
13119 Try your code out using other Fortran compilers, such as @code{f2c}.
13120 If it does not work on at least one other compiler (assuming the
13121 compiler supports the features the code needs), that is a strong
13122 indicator of a bug in the code.
13124 However, even if your code works on many compilers @emph{except}
13125 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
13126 It might mean the bug is in your code, and that @code{g77} simply
13127 exposes it more readily than other compilers.
13131 @section Where to Report Bugs
13132 @cindex bug report mailing lists
13133 @kindex @value{email-bugs}
13134 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
13136 Often people think of posting bug reports to a newsgroup instead of
13138 This sometimes appears to work, but it has one problem which can be
13139 crucial: a newsgroup posting does not contain a mail path back to the
13141 Thus, if maintainers need more information, they might be unable
13142 to reach you. For this reason, you should always send bug reports by
13143 mail to the proper mailing list.
13145 As a last resort, send bug reports on paper to:
13149 Free Software Foundation
13150 59 Temple Place - Suite 330
13151 Boston, MA 02111-1307, USA
13154 @node Bug Reporting
13155 @section How to Report Bugs
13156 @cindex compiler bugs, reporting
13158 The fundamental principle of reporting bugs usefully is this:
13159 @strong{report all the facts}.
13160 If you are not sure whether to state a
13161 fact or leave it out, state it!
13163 Often people omit facts because they think they know what causes the
13164 problem and they conclude that some details don't matter.
13166 assume that the name of the variable you use in an example does not matter.
13167 Well, probably it doesn't, but one cannot be sure.
13168 Perhaps the bug is a
13169 stray memory reference which happens to fetch from the location where that
13170 name is stored in memory; perhaps, if the name were different, the contents
13171 of that location would fool the compiler into doing the right thing despite
13173 Play it safe and give a specific, complete example.
13175 easiest thing for you to do, and the most helpful.
13177 Keep in mind that the purpose of a bug report is to enable someone to
13178 fix the bug if it is not known.
13179 It isn't very important what happens if
13180 the bug is already known.
13181 Therefore, always write your bug reports on
13182 the assumption that the bug is not known.
13184 Sometimes people give a few sketchy facts and ask, ``Does this ring a
13186 This cannot help us fix a bug, so it is rarely helpful.
13187 We respond by asking for enough details to enable us to investigate.
13188 You might as well expedite matters by sending them to begin with.
13189 (Besides, there are enough bells ringing around here as it is.)
13191 Try to make your bug report self-contained.
13192 If we have to ask you for
13193 more information, it is best if you include all the previous information
13194 in your response, as well as the information that was missing.
13196 Please report each bug in a separate message.
13197 This makes it easier for
13198 us to track which bugs have been fixed and to forward your bugs reports
13199 to the appropriate maintainer.
13201 Do not compress and encode any part of your bug report using programs
13202 such as @file{uuencode}.
13203 If you do so it will slow down the processing
13205 If you must submit multiple large files, use @file{shar},
13206 which allows us to read your message without having to run any
13207 decompression programs.
13209 (As a special exception for GNU Fortran bug-reporting, at least
13210 for now, if you are sending more than a few lines of code, if
13211 your program's source file format contains ``interesting'' things
13212 like trailing spaces or strange characters, or if you need to
13213 include binary data files, it is acceptable to put all the
13214 files together in a @code{tar} archive, and, whether you need to
13215 do that, it is acceptable to then compress the single file (@code{tar}
13216 archive or source file)
13217 using @code{gzip} and encode it via @code{uuencode}.
13218 Do not use any MIME stuff---the current maintainer can't decode this.
13219 Using @code{compress} instead of @code{gzip} is acceptable, assuming
13220 you have licensed the use of the patented algorithm in
13221 @code{compress} from Unisys.)
13223 To enable someone to investigate the bug, you should include all these
13228 The version of GNU Fortran.
13229 You can get this by running @code{g77} with the @samp{-v} option.
13230 (Ignore any error messages that might be displayed
13231 when the linker is run.)
13233 Without this, we won't know whether there is any point in looking for
13234 the bug in the current version of GNU Fortran.
13237 @cindex preprocessor
13238 @cindex cpp program
13239 @cindex programs, cpp
13241 A complete input file that will reproduce the bug.
13243 If your source file(s) require preprocessing
13244 (for example, their names have suffixes like
13245 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
13246 and the bug is in the compiler proper (@file{f771})
13247 or in a subsequent phase of processing,
13248 run your source file through the C preprocessor
13249 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
13250 Then, include the contents of @var{newfile} in the bug report.
13251 (When you do this, use the same preprocessor options---such as
13252 @samp{-I}, @samp{-D}, and @samp{-U}---that you used in actual
13255 A single statement is not enough of an example.
13256 In order to compile it,
13257 it must be embedded in a complete file of compiler input.
13258 The bug might depend on the details of how this is done.
13260 Without a real example one can compile,
13261 all anyone can do about your bug report is wish you luck.
13262 It would be futile to try to guess how to provoke the bug.
13263 For example, bugs in register allocation and reloading
13264 can depend on every little detail of the source and include files
13268 @cindex included files
13269 @cindex INCLUDE directive
13270 @cindex directive, INCLUDE
13271 @cindex #include directive
13272 @cindex directive, #include
13273 Note that you should include with your bug report any files
13274 included by the source file
13275 (via the @code{#include} or @code{INCLUDE} directive)
13276 that you send, and any files they include, and so on.
13278 It is not necessary to replace
13279 the @code{#include} and @code{INCLUDE} directives
13280 with the actual files in the version of the source file that
13281 you send, but it might make submitting the bug report easier
13283 However, be sure to @emph{reproduce} the bug using the @emph{exact}
13284 version of the source material you submit, to avoid wild-goose
13288 The command arguments you gave GNU Fortran to compile that example
13289 and observe the bug. For example, did you use @samp{-O}? To guarantee
13290 you won't omit something important, list all the options.
13292 If we were to try to guess the arguments, we would probably guess wrong
13293 and then we would not encounter the bug.
13296 The type of machine you are using, and the operating system name and
13298 (Much of this information is printed by @samp{g77 -v}---if you
13299 include that, send along any additional info you have that you
13300 don't see clearly represented in that output.)
13303 The operands you gave to the @code{configure} command when you installed
13307 A complete list of any modifications you have made to the compiler
13308 source. (We don't promise to investigate the bug unless it happens in
13309 an unmodified compiler. But if you've made modifications and don't tell
13310 us, then you are sending us on a wild-goose chase.)
13312 Be precise about these changes. A description in English is not
13313 enough---send a context diff for them.
13315 Adding files of your own (such as a machine description for a machine we
13316 don't support) is a modification of the compiler source.
13319 Details of any other deviations from the standard procedure for installing
13323 A description of what behavior you observe that you believe is
13324 incorrect. For example, ``The compiler gets a fatal signal,'' or,
13325 ``The assembler instruction at line 208 in the output is incorrect.''
13327 Of course, if the bug is that the compiler gets a fatal signal, then one
13328 can't miss it. But if the bug is incorrect output, the maintainer might
13329 not notice unless it is glaringly wrong. None of us has time to study
13330 all the assembler code from a 50-line Fortran program just on the chance that
13331 one instruction might be wrong. We need @emph{you} to do this part!
13333 Even if the problem you experience is a fatal signal, you should still
13334 say so explicitly. Suppose something strange is going on, such as, your
13335 copy of the compiler is out of synch, or you have encountered a bug in
13336 the C library on your system. (This has happened!) Your copy might
13337 crash and the copy here would not. If you @i{said} to expect a crash,
13338 then when the compiler here fails to crash, we would know that the bug
13339 was not happening. If you don't say to expect a crash, then we would
13340 not know whether the bug was happening. We would not be able to draw
13341 any conclusion from our observations.
13343 If the problem is a diagnostic when building GNU Fortran with some other
13344 compiler, say whether it is a warning or an error.
13346 Often the observed symptom is incorrect output when your program is run.
13347 Sad to say, this is not enough information unless the program is short
13348 and simple. None of us has time to study a large program to figure out
13349 how it would work if compiled correctly, much less which line of it was
13350 compiled wrong. So you will have to do that. Tell us which source line
13351 it is, and what incorrect result happens when that line is executed. A
13352 person who understands the program can find this as easily as finding a
13353 bug in the program itself.
13356 If you send examples of assembler code output from GNU Fortran,
13357 please use @samp{-g} when you make them. The debugging information
13358 includes source line numbers which are essential for correlating the
13359 output with the input.
13362 If you wish to mention something in the GNU Fortran source, refer to it by
13363 context, not by line number.
13365 The line numbers in the development sources don't match those in your
13366 sources. Your line numbers would convey no convenient information to the
13370 Additional information from a debugger might enable someone to find a
13371 problem on a machine which he does not have available. However, you
13372 need to think when you collect this information if you want it to have
13373 any chance of being useful.
13375 @cindex backtrace for bug reports
13376 For example, many people send just a backtrace, but that is never
13377 useful by itself. A simple backtrace with arguments conveys little
13378 about GNU Fortran because the compiler is largely data-driven; the same
13379 functions are called over and over for different RTL insns, doing
13380 different things depending on the details of the insn.
13382 Most of the arguments listed in the backtrace are useless because they
13383 are pointers to RTL list structure. The numeric values of the
13384 pointers, which the debugger prints in the backtrace, have no
13385 significance whatever; all that matters is the contents of the objects
13386 they point to (and most of the contents are other such pointers).
13388 In addition, most compiler passes consist of one or more loops that
13389 scan the RTL insn sequence. The most vital piece of information about
13390 such a loop---which insn it has reached---is usually in a local variable,
13391 not in an argument.
13394 What you need to provide in addition to a backtrace are the values of
13395 the local variables for several stack frames up. When a local
13396 variable or an argument is an RTX, first print its value and then use
13397 the GDB command @code{pr} to print the RTL expression that it points
13398 to. (If GDB doesn't run on your machine, use your debugger to call
13399 the function @code{debug_rtx} with the RTX as an argument.) In
13400 general, whenever a variable is a pointer, its value is no use
13401 without the data it points to.
13404 Here are some things that are not necessary:
13408 A description of the envelope of the bug.
13410 Often people who encounter a bug spend a lot of time investigating
13411 which changes to the input file will make the bug go away and which
13412 changes will not affect it.
13414 This is often time consuming and not very useful, because the way we
13415 will find the bug is by running a single example under the debugger with
13416 breakpoints, not by pure deduction from a series of examples. You might
13417 as well save your time for something else.
13419 Of course, if you can find a simpler example to report @emph{instead} of
13420 the original one, that is a convenience. Errors in the output will be
13421 easier to spot, running under the debugger will take less time, etc.
13422 Most GNU Fortran bugs involve just one function, so the most straightforward
13423 way to simplify an example is to delete all the function definitions
13424 except the one where the bug occurs. Those earlier in the file may be
13425 replaced by external declarations if the crucial function depends on
13426 them. (Exception: inline functions might affect compilation of functions
13427 defined later in the file.)
13429 However, simplification is not vital; if you don't want to do this,
13430 report the bug anyway and send the entire test case you used.
13433 In particular, some people insert conditionals @samp{#ifdef BUG} around
13434 a statement which, if removed, makes the bug not happen. These are just
13435 clutter; we won't pay any attention to them anyway. Besides, you should
13436 send us preprocessor output, and that can't have conditionals.
13439 A patch for the bug.
13441 A patch for the bug is useful if it is a good one. But don't omit the
13442 necessary information, such as the test case, on the assumption that a
13443 patch is all we need. We might see problems with your patch and decide
13444 to fix the problem another way, or we might not understand it at all.
13446 Sometimes with a program as complicated as GNU Fortran it is very hard to
13447 construct an example that will make the program follow a certain path
13448 through the code. If you don't send the example, we won't be able to
13449 construct one, so we won't be able to verify that the bug is fixed.
13451 And if we can't understand what bug you are trying to fix, or why your
13452 patch should be an improvement, we won't install it. A test case will
13453 help us to understand.
13455 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13456 understand and install your patches.
13459 A guess about what the bug is or what it depends on.
13461 Such guesses are usually wrong. Even the maintainer can't guess right
13462 about such things without first using the debugger to find the facts.
13467 We have no way of examining a core dump for your type of machine
13468 unless we have an identical system---and if we do have one,
13469 we should be able to reproduce the crash ourselves.
13472 @node Sending Patches
13473 @section Sending Patches for GNU Fortran
13475 If you would like to write bug fixes or improvements for the GNU Fortran
13476 compiler, that is very helpful.
13477 Send suggested fixes to the bug report
13478 mailing list, @email{@value{email-bugs}}.
13480 Please follow these guidelines so we can study your patches efficiently.
13481 If you don't follow these guidelines, your information might still be
13482 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13483 of work in the best of circumstances, and we can't keep up unless you do
13488 Send an explanation with your changes of what problem they fix or what
13489 improvement they bring about. For a bug fix, just include a copy of the
13490 bug report, and explain why the change fixes the bug.
13492 (Referring to a bug report is not as good as including it, because then
13493 we will have to look it up, and we have probably already deleted it if
13494 we've already fixed the bug.)
13497 Always include a proper bug report for the problem you think you have
13498 fixed. We need to convince ourselves that the change is right before
13499 installing it. Even if it is right, we might have trouble judging it if
13500 we don't have a way to reproduce the problem.
13503 Include all the comments that are appropriate to help people reading the
13504 source in the future understand why this change was needed.
13507 Don't mix together changes made for different reasons.
13508 Send them @emph{individually}.
13510 If you make two changes for separate reasons, then we might not want to
13511 install them both. We might want to install just one. If you send them
13512 all jumbled together in a single set of diffs, we have to do extra work
13513 to disentangle them---to figure out which parts of the change serve
13514 which purpose. If we don't have time for this, we might have to ignore
13515 your changes entirely.
13517 If you send each change as soon as you have written it, with its own
13518 explanation, then the two changes never get tangled up, and we can
13519 consider each one properly without any extra work to disentangle them.
13521 Ideally, each change you send should be impossible to subdivide into
13522 parts that we might want to consider separately, because each of its
13523 parts gets its motivation from the other parts.
13526 Send each change as soon as that change is finished. Sometimes people
13527 think they are helping us by accumulating many changes to send them all
13528 together. As explained above, this is absolutely the worst thing you
13531 Since you should send each change separately, you might as well send it
13532 right away. That gives us the option of installing it immediately if it
13536 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13537 for us to install reliably. More than that, they make it hard for us to
13538 study the diffs to decide whether we want to install them. Unidiff
13539 format is better than contextless diffs, but not as easy to read as
13542 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13543 function that each change occurs in.
13544 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13547 Write the change log entries for your changes. We get lots of changes,
13548 and we don't have time to do all the change log writing ourselves.
13550 Read the @file{ChangeLog} file to see what sorts of information to put
13551 in, and to learn the style that we use. The purpose of the change log
13552 is to show people where to find what was changed. So you need to be
13553 specific about what functions you changed; in large functions, it's
13554 often helpful to indicate where within the function the change was.
13556 On the other hand, once you have shown people where to find the change,
13557 you need not explain its purpose. Thus, if you add a new function, all
13558 you need to say about it is that it is new. If you feel that the
13559 purpose needs explaining, it probably does---but the explanation will be
13560 much more useful if you put it in comments in the code.
13562 If you would like your name to appear in the header line for who made
13563 the change, send us the header line.
13566 When you write the fix, keep in mind that we can't install a change that
13567 would break other systems.
13569 People often suggest fixing a problem by changing machine-independent
13570 files such as @file{toplev.c} to do something special that a particular
13571 system needs. Sometimes it is totally obvious that such changes would
13572 break GNU Fortran for almost all users. We can't possibly make a change like
13573 that. At best it might tell us how to write another patch that would
13574 solve the problem acceptably.
13576 Sometimes people send fixes that @emph{might} be an improvement in
13577 general---but it is hard to be sure of this. It's hard to install
13578 such changes because we have to study them very carefully. Of course,
13579 a good explanation of the reasoning by which you concluded the change
13580 was correct can help convince us.
13582 The safest changes are changes to the configuration files for a
13583 particular machine. These are safe because they can't create new bugs
13586 Please help us keep up with the workload by designing the patch in a
13587 form that is good to install.
13591 @chapter How To Get Help with GNU Fortran
13593 If you need help installing, using or changing GNU Fortran, there are two
13598 Look in the service directory for someone who might help you for a fee.
13599 The service directory is found in the file named @file{SERVICE} in the
13600 GNU CC distribution.
13603 Send a message to @email{@value{email-general}}.
13608 @node Adding Options
13609 @chapter Adding Options
13610 @cindex options, adding
13611 @cindex adding options
13613 To add a new command-line option to @code{g77}, first decide
13614 what kind of option you wish to add.
13615 Search the @code{g77} and @code{gcc} documentation for one
13616 or more options that is most closely like the one you want to add
13617 (in terms of what kind of effect it has, and so on) to
13618 help clarify its nature.
13622 @emph{Fortran options} are options that apply only
13623 when compiling Fortran programs.
13624 They are accepted by @code{g77} and @code{gcc}, but
13625 they apply only when compiling Fortran programs.
13628 @emph{Compiler options} are options that apply
13629 when compiling most any kind of program.
13632 @emph{Fortran options} are listed in the file
13633 @file{@value{path-g77}/lang-options.h},
13634 which is used during the build of @code{gcc} to
13635 build a list of all options that are accepted by
13636 at least one language's compiler.
13637 This list goes into the @code{lang_options} array
13638 in @file{gcc/toplev.c}, which uses this array to
13639 determine whether a particular option should be
13640 offered to the linked-in front end for processing
13641 by calling @code{lang_option_decode}, which, for
13642 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13643 calls @code{ffe_decode_option}.
13645 If the linked-in front end ``rejects'' a
13646 particular option passed to it, @file{toplev.c}
13647 just ignores the option, because @emph{some}
13648 language's compiler is willing to accept it.
13650 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13651 to work, even though Fortran compilation does
13652 not currently support the @samp{-fno-asm} option;
13653 even though the @code{f771} version of @code{lang_decode_option}
13654 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13655 produce a diagnostic because some other language (C)
13658 This also means that commands like
13659 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13660 despite the fact that no phase of the command was
13661 able to recognize and process @samp{-fno-asm}---perhaps
13662 a warning about this would be helpful if it were
13665 Code that processes Fortran options is found in
13666 @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
13667 This code needs to check positive and negative forms
13670 The defaults for Fortran options are set in their
13671 global definitions, also found in @file{@value{path-g77}/top.c}.
13672 Many of these defaults are actually macros defined
13673 in @file{@value{path-g77}/target.h}, since they might be
13675 However, since, in practice, GNU compilers
13676 should behave the same way on all configurations
13677 (especially when it comes to language constructs),
13678 the practice of setting defaults in @file{target.h}
13679 is likely to be deprecated and, ultimately, stopped
13680 in future versions of @code{g77}.
13682 Accessor macros for Fortran options, used by code
13683 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13685 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13686 in the array @code{f_options}.
13687 An option not listed in @code{lang_options} is
13688 looked up in @code{f_options} and handled from there.
13690 The defaults for compiler options are set in the
13691 global definitions for the corresponding variables,
13692 some of which are in @file{gcc/toplev.c}.
13694 You can set different defaults for @emph{Fortran-oriented}
13695 or @emph{Fortran-reticent} compiler options by changing
13696 the source code of @code{g77} and rebuilding.
13697 How to do this depends on the version of @code{g77}:
13702 Change the way @code{f771} handles the @samp{-fset-g77-defaults}
13703 option, which is always provided as the first option when
13704 called by @code{g77} or @code{gcc}.
13706 This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13707 Have it change just the variables that you want to default
13708 to a different setting for Fortran compiles compared to
13709 compiles of other languages.
13711 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13712 automatically because of the specification information
13713 kept in @file{@value{path-g77}/lang-specs.h}.
13714 This file tells the @code{gcc} command how to recognize,
13715 in this case, Fortran source files (those to be preprocessed,
13716 and those that are not), and further, how to invoke the
13717 appropriate programs (including @code{f771}) to process
13718 those source files.
13720 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
13721 @samp{-fversion}, and other options are passed, as appropriate,
13722 even when the user has not explicitly specified them.
13723 Other ``internal'' options such as @samp{-quiet} also
13724 are passed via this mechanism.
13728 Change the @code{lang_init_options} routine in @file{egcs/gcc/f/com.c}.
13730 (Note that these versions of @code{g77}
13731 perform internal consistency checking automatically
13732 when the @samp{-fversion} option is specified.)
13739 If you want to contribute to @code{g77} by doing research,
13740 design, specification, documentation, coding, or testing,
13741 the following information should give you some ideas.
13742 More relevant information might be available from
13743 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
13746 * Efficiency:: Make @code{g77} itself compile code faster.
13747 * Better Optimization:: Teach @code{g77} to generate faster code.
13748 * Simplify Porting:: Make @code{g77} easier to configure, build,
13750 * More Extensions:: Features many users won't know to ask for.
13751 * Machine Model:: @code{g77} should better leverage @code{gcc}.
13752 * Internals Documentation:: Make maintenance easier.
13753 * Internals Improvements:: Make internals more robust.
13754 * Better Diagnostics:: Make using @code{g77} on new code easier.
13758 @section Improve Efficiency
13761 Don't bother doing any performance analysis until most of the
13762 following items are taken care of, because there's no question
13763 they represent serious space/time problems, although some of
13764 them show up only given certain kinds of (popular) input.
13768 Improve @code{malloc} package and its uses to specify more info about
13769 memory pools and, where feasible, use obstacks to implement them.
13772 Skip over uninitialized portions of aggregate areas (arrays,
13773 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
13774 This would reduce memory usage for large initialized aggregate
13775 areas, even ones with only one initialized element.
13777 As of version 0.5.18, a portion of this item has already been
13781 Prescan the statement (in @file{sta.c}) so that the nature of the statement
13782 is determined as much as possible by looking entirely at its form,
13783 and not looking at any context (previous statements, including types
13785 This would allow ripping out of the statement-confirmation,
13786 symbol retraction/confirmation, and diagnostic inhibition
13788 Plus, it would result in much-improved diagnostics.
13789 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
13790 is not a subroutine intrinsic, would result actual error instead of the
13791 unimplemented-statement catch-all.
13794 Throughout @code{g77}, don't pass line/column pairs where
13795 a simple @code{ffewhere} type, which points to the error as much as is
13796 desired by the configuration, will do, and don't pass @code{ffelexToken} types
13797 where a simple @code{ffewhere} type will do.
13798 Then, allow new default
13799 configuration of @code{ffewhere} such that the source line text is not
13800 preserved, and leave it to things like Emacs' next-error function
13801 to point to them (now that @samp{next-error} supports column,
13802 or, perhaps, character-offset, numbers).
13803 The change in calling sequences should improve performance somewhat,
13804 as should not having to save source lines.
13805 (Whether this whole
13806 item will improve performance is questionable, but it should
13807 improve maintainability.)
13810 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
13811 as regards the assembly output.
13812 Some of this might require improving
13813 the back end, but lots of improvement in space/time required in @code{g77}
13814 itself can be fairly easily obtained without touching the back end.
13815 Maybe type-conversion, where necessary, can be speeded up as well in
13816 cases like the one shown (converting the @samp{2} into @samp{2.}).
13819 If analysis shows it to be worthwhile, optimize @file{lex.c}.
13822 Consider redesigning @file{lex.c} to not need any feedback
13823 during tokenization, by keeping track of enough parse state on its
13827 @node Better Optimization
13828 @section Better Optimization
13829 @cindex optimization, better
13830 @cindex code generation, improving
13832 Much of this work should be put off until after @code{g77} has
13833 all the features necessary for its widespread acceptance as a
13834 useful F77 compiler.
13835 However, perhaps this work can be done in parallel during
13836 the feature-adding work.
13840 Do the equivalent of the trick of putting @samp{extern inline} in front
13841 of every function definition in @code{libg2c} and #include'ing the resulting
13842 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
13843 that are at all worth inlining.
13844 (Some of this has already been done, such as for integral exponentiation.)
13847 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
13848 and it's clear that types line up
13849 and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
13850 make @samp{CHAR_VAR}, not a
13851 temporary, be the receiver for @samp{CHAR_FUNC}.
13852 (This is now done for @code{COMPLEX} variables.)
13855 Design and implement Fortran-specific optimizations that don't
13856 really belong in the back end, or where the front end needs to
13857 give the back end more info than it currently does.
13860 Design and implement a new run-time library interface, with the
13861 code going into @code{libgcc} so no special linking is required to
13862 link Fortran programs using standard language features.
13864 would speed up lots of things, from I/O (using precompiled formats,
13865 doing just one, or, at most, very few, calls for arrays or array sections,
13866 and so on) to general computing (array/section implementations of
13867 various intrinsics, implementation of commonly performed loops that
13868 aren't likely to be optimally compiled otherwise, etc.).
13870 Among the important things the library would do are:
13874 Be a one-stop-shop-type
13875 library, hence shareable and usable by all, in that what are now
13876 library-build-time options in @code{libg2c} would be moved at least to the
13877 @code{g77} compile phase, if not to finer grains (such as choosing how
13878 list-directed I/O formatting is done by default at @code{OPEN} time, for
13879 preconnected units via options or even statements in the main program
13880 unit, maybe even on a per-I/O basis with appropriate pragma-like
13885 Probably requiring the new library design, change interface to
13886 normally have @code{COMPLEX} functions return their values in the way
13887 @code{gcc} would if they were declared @code{__complex__ float},
13889 the mechanism currently used by @code{CHARACTER} functions (whereby the
13890 functions are compiled as returning void and their first arg is
13891 a pointer to where to store the result).
13892 (Don't append underscores to
13893 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
13894 @code{gcc} rather than @code{f2c} calling conventions.)
13897 Do something useful with @code{doiter} references where possible.
13898 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
13899 a @code{DO} loop that uses @samp{I} as the
13900 iteration variable, and the back end might find that info useful
13901 in determining whether it needs to read @samp{I} back into a register after
13903 (It normally has to do that, unless it knows @samp{FOO} never
13904 modifies its passed-by-reference argument, which is rarely the case
13905 for Fortran-77 code.)
13908 @node Simplify Porting
13909 @section Simplify Porting
13910 @cindex porting, simplify
13911 @cindex simplify porting
13913 Making @code{g77} easier to configure, port, build, and install, either
13914 as a single-system compiler or as a cross-compiler, would be
13919 A new library (replacing @code{libg2c}) should improve portability as well as
13920 produce more optimal code.
13921 Further, @code{g77} and the new library should
13922 conspire to simplify naming of externals, such as by removing unnecessarily
13923 added underscores, and to reduce/eliminate the possibility of naming
13924 conflicts, while making debugger more straightforward.
13927 make multi-language applications more feasible, such as by providing
13928 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
13932 Possibly related to a new library, @code{g77} should produce the equivalent
13933 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
13934 main program unit, instead of compiling something that must be
13935 called by a library
13936 implementation of @code{main()}.
13938 This would do many useful things such as
13939 provide more flexibility in terms of setting up exception handling,
13940 not requiring programmers to start their debugging sessions with
13941 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
13944 The GBE needs to understand the difference between alignment
13945 requirements and desires.
13946 For example, on Intel x86 machines, @code{g77} currently imposes
13947 overly strict alignment requirements, due to the back end, but it
13948 would be useful for Fortran and C programmers to be able to override
13949 these @emph{recommendations} as long as they don't violate the actual
13950 processor @emph{requirements}.
13953 @node More Extensions
13954 @section More Extensions
13955 @cindex extensions, more
13957 These extensions are not the sort of things users ask for ``by name'',
13958 but they might improve the usability of @code{g77}, and Fortran in
13959 general, in the long run.
13960 Some of these items really pertain to improving @code{g77} internals
13961 so that some popular extensions can be more easily supported.
13965 Look through all the documentation on the GNU Fortran language,
13966 dialects, compiler, missing features, bugs, and so on.
13967 Many mentions of incomplete or missing features are
13968 sprinkled throughout.
13969 It is not worth repeating them here.
13972 @cindex concatenation
13973 @cindex CHARACTER*(*)
13974 @cindex run-time, dynamic allocation
13975 Support arbitrary operands for concatenation, even in contexts where
13976 run-time allocation is required.
13982 CALL FOO(A // 'suffix')
13986 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
13988 The idea is to provide a forward-looking, effective
13989 replacement for things like the old-style @code{PARAMETER} statement
13991 really need typelessness in a maintainable, portable, clearly documented
13993 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
13994 and whatever else might come along.
13995 (This is not really a call for polymorphism per se, just
13996 an ability to express limited, syntactic polymorphism.)
13999 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
14002 Support arbitrary file unit numbers, instead of limiting them
14003 to 0 through @samp{MXUNIT-1}.
14004 (This is a @code{libg2c} issue.)
14007 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
14008 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
14009 later @code{UNIT=} in the first example is invalid.
14010 Make sure this is what users of this feature would expect.
14013 Currently @code{g77} disallows @samp{READ(1'10)} since
14014 it is an obnoxious syntax, but
14015 supporting it might be pretty easy if needed.
14016 More details are needed, such
14017 as whether general expressions separated by an apostrophe are supported,
14018 or maybe the record number can be a general expression, and so on.
14021 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
14023 Currently there is no support at all
14024 for @code{%FILL} in @code{STRUCTURE} and related syntax,
14025 whereas the rest of the
14026 stuff has at least some parsing support.
14027 This requires either major
14028 changes to @code{libg2c} or its replacement.
14031 F90 and @code{g77} probably disagree about label scoping relative to
14032 @code{INTERFACE} and @code{END INTERFACE}, and their contained
14033 procedure interface bodies (blocks?).
14036 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
14037 since that was added after S8.112.
14040 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
14041 with the final form of the standard (it was vague at S8.112).
14044 It seems to be an ``open'' question whether a file, immediately after being
14045 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
14046 might be nice to offer an option of opening to ``undefined'' status, requiring
14047 an explicit absolute-positioning operation to be performed before any
14048 other (besides @code{CLOSE}) to assist in making applications port to systems
14049 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
14052 @node Machine Model
14053 @section Machine Model
14055 This items pertain to generalizing @code{g77}'s view of
14056 the machine model to more fully accept whatever the GBE
14057 provides it via its configuration.
14061 Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
14062 exclusively so the target float format need not be required.
14064 means changing the way @code{g77} handles initialization of aggregate areas
14065 having more than one type, such as @code{REAL} and @code{INTEGER},
14067 it initializes them as if they were arrays of @code{char} and uses the
14068 bit patterns of the constants of the various types in them to determine
14069 what to stuff in elements of the arrays.
14072 Rely more and more on back-end info and capabilities, especially in the
14073 area of constants (where having the @code{g77} front-end's IL just store
14074 the appropriate tree nodes containing constants might be best).
14077 Suite of C and Fortran programs that a user/administrator can run on a
14078 machine to help determine the configuration for @code{g77} before building
14079 and help determine if the compiler works (especially with whatever
14080 libraries are installed) after building.
14083 @node Internals Documentation
14084 @section Internals Documentation
14086 Better info on how @code{g77} works and how to port it is needed.
14087 Much of this should be done only after the redesign planned for
14090 @node Internals Improvements
14091 @section Internals Improvements
14093 Some more items that would make @code{g77} more reliable
14094 and easier to maintain:
14098 Generally make expression handling focus
14099 more on critical syntax stuff, leaving semantics to callers.
14101 anything a caller can check, semantically, let it do so, rather
14102 than having @file{expr.c} do it.
14103 (Exceptions might include things like
14104 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
14106 important to preserve the left-to-right-in-source order of production
14110 Come up with better naming conventions for @samp{-D} to establish requirements
14111 to achieve desired implementation dialect via @file{proj.h}.
14114 Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
14117 Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
14120 Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
14121 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
14122 (after determining if there is indeed no real need for it).
14125 Utility to read and check @file{bad.def} messages and their references in the
14126 code, to make sure calls are consistent with message templates.
14129 Search and fix @samp{&ffe@dots{}} and similar so that
14130 @samp{ffe@dots{}ptr@dots{}} macros are
14131 available instead (a good argument for wishing this could have written all
14132 this stuff in C++, perhaps).
14133 On the other hand, it's questionable whether this sort of
14134 improvement is really necessary, given the availability of
14135 tools such as Emacs and Perl, which make finding any
14136 address-taking of structure members easy enough?
14139 Some modules truly export the member names of their structures (and the
14140 structures themselves), maybe fix this, and fix other modules that just
14141 appear to as well (by appending @samp{_}, though it'd be ugly and probably
14142 not worth the time).
14145 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
14147 and use them throughout @code{g77} source code (especially in the definitions
14148 of access macros in @samp{.h} files) so they can be tailored
14149 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
14152 Decorate throughout with @code{const} and other such stuff.
14155 All F90 notational derivations in the source code are still based
14156 on the S8.112 version of the draft standard.
14157 Probably should update
14158 to the official standard, or put documentation of the rules as used
14159 in the code@dots{}uh@dots{}in the code.
14162 Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
14163 inside but invoked via paths not involving @code{ffeexpr_lhs} or
14164 @code{ffeexpr_rhs}) might be creating things
14165 in improper pools, leading to such things staying around too long or
14166 (doubtful, but possible and dangerous) not long enough.
14169 Some @code{ffebld_list_new} (or whatever) calls might not be matched by
14170 @code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
14171 (It definitely is not a problem just yet.)
14174 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
14175 due to alignment/mismatch or other problems---they end up without
14176 @code{ffestorag} objects, so maybe the backend (and other parts of the front
14177 end) can notice that and handle like an @code{opANY} (do what it wants, just
14178 don't complain or crash).
14179 Most of this seems to have been addressed
14180 by now, but a code review wouldn't hurt.
14183 @node Better Diagnostics
14184 @section Better Diagnostics
14186 These are things users might not ask about, or that need to
14187 be looked into, before worrying about.
14188 Also here are items that involve reducing unnecessary diagnostic
14193 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
14194 lengths, type classes, and so on),
14195 @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
14199 Speed up and improve error handling for data when repeat-count is
14201 For example, don't output 20 unnecessary messages after the
14202 first necessary one for:
14207 DATA (X(I), J= 1, 20) /20*5/
14212 (The @code{CONTINUE} statement ensures the @code{DATA} statement
14213 is processed in the context of executable, not specification,
14223 @chapter Diagnostics
14224 @cindex diagnostics
14226 Some diagnostics produced by @code{g77} require sufficient explanation
14227 that the explanations are given below, and the diagnostics themselves
14228 identify the appropriate explanation.
14230 Identification uses the GNU Info format---specifically, the @code{info}
14231 command that displays the explanation is given within square
14232 brackets in the diagnostic.
14236 foo.f:5: Invalid statement [info -f g77 M FOOEY]
14239 More details about the above diagnostic is found in the @code{g77} Info
14240 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
14241 which is displayed by typing the UNIX command
14242 @samp{info -f g77 M FOOEY}.
14244 Other Info readers, such as EMACS, may be just as easily used to display
14245 the pertinent node.
14246 In the above example, @samp{g77} is the Info document name,
14247 @samp{M} is the top-level menu item to select,
14248 and, in that node (named @samp{Diagnostics}, the name of
14249 this chapter, which is the very text you're reading now),
14250 @samp{FOOEY} is the menu item to select.
14253 In this printed version of the @code{g77} manual, the above example
14254 points to a section, below, entitled @samp{FOOEY}---though, of course,
14255 as the above is just a sample, no such section exists.
14259 * CMPAMBIG:: Ambiguous use of intrinsic.
14260 * EXPIMP:: Intrinsic used explicitly and implicitly.
14261 * INTGLOB:: Intrinsic also used as name of global.
14262 * LEX:: Various lexer messages
14263 * GLOBALS:: Disagreements about globals.
14264 * LINKFAIL:: When linking @code{f771} fails.
14265 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
14269 @section @code{CMPAMBIG}
14273 Ambiguous use of intrinsic @var{intrinsic} @dots{}
14276 The type of the argument to the invocation of the @var{intrinsic}
14277 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
14278 Typically, it is @code{COMPLEX(KIND=2)}, also known as
14279 @code{DOUBLE COMPLEX}.
14281 The interpretation of this invocation depends on the particular
14282 dialect of Fortran for which the code was written.
14283 Some dialects convert the real part of the argument to
14284 @code{REAL(KIND=1)}, thus losing precision; other dialects,
14285 and Fortran 90, do no such conversion.
14287 So, GNU Fortran rejects such invocations except under certain
14288 circumstances, to avoid making an incorrect assumption that results
14289 in generating the wrong code.
14291 To determine the dialect of the program unit, perhaps even whether
14292 that particular invocation is properly coded, determine how the
14293 result of the intrinsic is used.
14295 The result of @var{intrinsic} is expected (by the original programmer)
14296 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
14300 It is passed as an argument to a procedure that explicitly or
14301 implicitly declares that argument @code{REAL(KIND=1)}.
14304 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
14305 statement specifying the dummy argument corresponding to an
14306 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14307 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14308 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
14309 of @code{REAL(KIND=2)}.
14312 It is used in a context that would otherwise not include
14313 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
14314 invocation as @code{REAL(KIND=2)} would result in unnecessary
14315 promotions and (typically) more expensive operations on the
14326 The above example suggests the programmer expected the real part
14327 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
14328 multiplied by @samp{T} (presumed, along with @samp{R} above, to
14329 be type @code{REAL(KIND=1)}).
14331 Otherwise, the conversion would have to be delayed until after
14332 the multiplication, requiring not only an extra conversion
14333 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
14334 expensive multiplication (a double-precision multiplication instead
14335 of a single-precision one).
14338 The result of @var{intrinsic} is expected (by the original programmer)
14339 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
14343 It is passed as an argument to a procedure that explicitly or
14344 implicitly declares that argument @code{REAL(KIND=2)}.
14346 For example, a procedure specifying a @code{DOUBLE PRECISION}
14347 dummy argument corresponding to an
14348 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14349 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14350 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
14351 of @code{REAL(KIND=1)}.
14354 It is used in an expression context that includes
14355 other @code{REAL(KIND=2)} operands,
14356 or is assigned to a @code{REAL(KIND=2)} variable or array element.
14362 DOUBLE PRECISION R, T
14367 The above example suggests the programmer expected the real part
14368 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
14369 by the @code{REAL()} intrinsic.
14371 Otherwise, the conversion would have to be immediately followed
14372 by a conversion back to @code{REAL(KIND=2)}, losing
14373 the original, full precision of the real part of @code{Z},
14374 before being multiplied by @samp{T}.
14377 Once you have determined whether a particular invocation of @var{intrinsic}
14378 expects the Fortran 90 interpretation, you can:
14382 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
14383 @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
14385 if it expected the Fortran 90 interpretation.
14387 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
14388 some other type, such as @code{COMPLEX*32}, you should use the
14389 appropriate intrinsic, such as the one to convert to @code{REAL*16}
14390 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
14391 @code{QIMAG()} in place of @code{DIMAG()}).
14394 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
14396 This converts to @code{REAL(KIND=1)} in all working
14400 If you don't want to change the code, and you are certain that all
14401 ambiguous invocations of @var{intrinsic} in the source file have
14402 the same expectation regarding interpretation, you can:
14406 Compile with the @code{g77} option @samp{-ff90}, to enable the
14407 Fortran 90 interpretation.
14410 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
14411 to enable the non-Fortran-90 interpretations.
14414 @xref{REAL() and AIMAG() of Complex}, for more information on this
14417 Note: If the above suggestions don't produce enough evidence
14418 as to whether a particular program expects the Fortran 90
14419 interpretation of this ambiguous invocation of @var{intrinsic},
14420 there is one more thing you can try.
14422 If you have access to most or all the compilers used on the
14423 program to create successfully tested and deployed executables,
14424 read the documentation for, and @emph{also} test out, each compiler
14425 to determine how it treats the @var{intrinsic} intrinsic in
14427 (If all the compilers don't agree on an interpretation, there
14428 might be lurking bugs in the deployed versions of the program.)
14430 The following sample program might help:
14432 @cindex JCB003 program
14436 C Written by James Craig Burley 1997-02-23.
14438 C Determine how compilers handle non-standard REAL
14439 C and AIMAG on DOUBLE COMPLEX operands.
14447 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14448 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14452 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14453 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14456 C Just to make sure compiler doesn't use naive flow
14457 C analysis to optimize away careful work above,
14458 C which might invalidate results....
14460 SUBROUTINE DUMDUM(Z, R)
14466 If the above program prints contradictory results on a
14467 particular compiler, run away!
14470 @section @code{EXPIMP}
14474 Intrinsic @var{intrinsic} referenced @dots{}
14477 The @var{intrinsic} is explicitly declared in one program
14478 unit in the source file and implicitly used as an intrinsic
14479 in another program unit in the same source file.
14481 This diagnostic is designed to catch cases where a program
14482 might depend on using the name @var{intrinsic} as an intrinsic
14483 in one program unit and as a global name (such as the name
14484 of a subroutine or function) in another, but @code{g77} recognizes
14485 the name as an intrinsic in both cases.
14487 After verifying that the program unit making implicit use
14488 of the intrinsic is indeed written expecting the intrinsic,
14489 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14490 program unit to prevent this warning.
14492 This and related warnings are disabled by using
14493 the @samp{-Wno-globals} option when compiling.
14495 Note that this warning is not issued for standard intrinsics.
14496 Standard intrinsics include those described in the FORTRAN 77
14497 standard and, if @samp{-ff90} is specified, those described
14498 in the Fortran 90 standard.
14499 Such intrinsics are not as likely to be confused with user
14500 procedures as intrinsics provided as extensions to the
14501 standard by @code{g77}.
14504 @section @code{INTGLOB}
14508 Same name `@var{intrinsic}' given @dots{}
14511 The name @var{intrinsic} is used for a global entity (a common
14512 block or a program unit) in one program unit and implicitly
14513 used as an intrinsic in another program unit.
14515 This diagnostic is designed to catch cases where a program
14516 intends to use a name entirely as a global name, but @code{g77}
14517 recognizes the name as an intrinsic in the program unit that
14518 references the name, a situation that would likely produce
14524 INTEGER FUNCTION TIME()
14530 PRINT *, 'Time is ', TIME()
14534 The above example defines a program unit named @samp{TIME}, but
14535 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14536 is normally treated by @code{g77} as a reference to the intrinsic
14537 @code{TIME()} (unless a command-line option that prevents such
14538 treatment has been specified).
14540 As a result, the program @samp{SAMP} will @emph{not}
14541 invoke the @samp{TIME} function in the same source file.
14543 Since @code{g77} recognizes @code{libU77} procedures as
14544 intrinsics, and since some existing code uses the same names
14545 for its own procedures as used by some @code{libU77}
14546 procedures, this situation is expected to arise often enough
14547 to make this sort of warning worth issuing.
14549 After verifying that the program unit making implicit use
14550 of the intrinsic is indeed written expecting the intrinsic,
14551 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14552 program unit to prevent this warning.
14554 Or, if you believe the program unit is designed to invoke the
14555 program-defined procedure instead of the intrinsic (as
14556 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14557 statement to the program unit that references the name to
14558 prevent this warning.
14560 This and related warnings are disabled by using
14561 the @samp{-Wno-globals} option when compiling.
14563 Note that this warning is not issued for standard intrinsics.
14564 Standard intrinsics include those described in the FORTRAN 77
14565 standard and, if @samp{-ff90} is specified, those described
14566 in the Fortran 90 standard.
14567 Such intrinsics are not as likely to be confused with user
14568 procedures as intrinsics provided as extensions to the
14569 standard by @code{g77}.
14572 @section @code{LEX}
14576 Unrecognized character @dots{}
14577 Invalid first character @dots{}
14578 Line too long @dots{}
14579 Non-numeric character @dots{}
14580 Continuation indicator @dots{}
14581 Label at @dots{} invalid with continuation line indicator @dots{}
14582 Character constant @dots{}
14583 Continuation line @dots{}
14584 Statement at @dots{} begins with invalid token
14587 Although the diagnostics identify specific problems, they can
14588 be produced when general problems such as the following occur:
14592 The source file contains something other than Fortran code.
14594 If the code in the file does not look like many of the examples
14595 elsewhere in this document, it might not be Fortran code.
14596 (Note that Fortran code often is written in lower case letters,
14597 while the examples in this document use upper case letters,
14598 for stylistic reasons.)
14600 For example, if the file contains lots of strange-looking
14601 characters, it might be APL source code; if it contains lots
14602 of parentheses, it might be Lisp source code; if it
14603 contains lots of bugs, it might be C++ source code.
14606 The source file contains free-form Fortran code, but @samp{-ffree-form}
14607 was not specified on the command line to compile it.
14609 Free form is a newer form for Fortran code.
14610 The older, classic form is called fixed form.
14612 @cindex continuation character
14613 @cindex characters, continuation
14614 Fixed-form code is visually fairly distinctive, because
14615 numerical labels and comments are all that appear in
14616 the first five columns of a line, the sixth column is
14617 reserved to denote continuation lines,
14618 and actual statements start at or beyond column 7.
14619 Spaces generally are not significant, so if you
14620 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14621 you are looking at fixed-form code.
14624 Comment lines are indicated by the letter @samp{C} or the symbol
14625 @samp{*} in column 1.
14626 @cindex trailing comment
14628 @cindex characters, comment
14630 @cindex exclamation point
14631 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14632 which many compilers support.)
14634 Free-form code is distinguished from fixed-form source
14635 primarily by the fact that statements may start anywhere.
14636 (If lots of statements start in columns 1 through 6,
14637 that's a strong indicator of free-form source.)
14638 Consecutive keywords must be separated by spaces, so
14639 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14640 There are no comment lines per se, but @samp{!} starts a
14641 comment anywhere in a line (other than within a character or
14642 Hollerith constant).
14644 @xref{Source Form}, for more information.
14647 The source file is in fixed form and has been edited without
14648 sensitivity to the column requirements.
14650 Statements in fixed-form code must be entirely contained within
14651 columns 7 through 72 on a given line.
14652 Starting them ``early'' is more likely to result in diagnostics
14653 than finishing them ``late'', though both kinds of errors are
14654 often caught at compile time.
14656 For example, if the following code fragment is edited by following
14657 the commented instructions literally, the result, shown afterward,
14658 would produce a diagnostic when compiled:
14661 C On XYZZY systems, remove "C" on next line:
14665 The result of editing the above line might be:
14668 C On XYZZY systems, remove "C" on next line:
14672 However, that leaves the first @samp{C} in the @code{CALL}
14673 statement in column 6, making it a comment line, which is
14674 not really what the author intended, and which is likely
14675 to result in one of the above-listed diagnostics.
14677 @emph{Replacing} the @samp{C} in column 1 with a space
14678 is the proper change to make, to ensure the @code{CALL}
14679 keyword starts in or after column 7.
14681 Another common mistake like this is to forget that fixed-form
14682 source lines are significant through only column 72, and that,
14683 normally, any text beyond column 72 is ignored or is diagnosed
14686 @xref{Source Form}, for more information.
14689 The source file requires preprocessing, and the preprocessing
14690 is not being specified at compile time.
14692 A source file containing lines beginning with @code{#define},
14693 @code{#include}, @code{#if}, and so on is likely one that
14694 requires preprocessing.
14696 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
14697 the file normally will be compiled @emph{without} preprocessing
14700 Change the file's suffix from @samp{.f} to @samp{.F}
14701 (or, on systems with case-insensitive file names,
14702 to @samp{.fpp} or @samp{.FPP}),
14703 from @samp{.for} to @samp{.fpp},
14704 or from @samp{.FOR} to @samp{.FPP}.
14705 @code{g77} compiles files with such names @emph{with}
14709 @cindex preprocessor
14710 @cindex cpp program
14711 @cindex programs, cpp
14712 @cindex @samp{-x f77-cpp-input} option
14713 @cindex options, @samp{-x f77-cpp-input}
14714 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14715 the language @samp{f77-cpp-input} for Fortran files that
14716 require preprocessing.
14717 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14720 The source file is preprocessed, and the results of preprocessing
14721 result in syntactic errors that are not necessarily obvious to
14722 someone examining the source file itself.
14724 Examples of errors resulting from preprocessor macro expansion
14725 include exceeding the line-length limit, improperly starting,
14726 terminating, or incorporating the apostrophe or double-quote in
14727 a character constant, improperly forming a Hollerith constant,
14730 @xref{Overall Options,,Options Controlling the Kind of Output},
14731 for suggestions about how to use, and not use, preprocessing
14736 @section @code{GLOBALS}
14740 Global name @var{name} defined at @dots{} already defined@dots{}
14741 Global name @var{name} at @dots{} has different type@dots{}
14742 Too many arguments passed to @var{name} at @dots{}
14743 Too few arguments passed to @var{name} at @dots{}
14744 Argument #@var{n} of @var{name} is @dots{}
14747 These messages all identify disagreements about the
14748 global procedure named @var{name} among different program units
14749 (usually including @var{name} itself).
14751 Whether a particular disagreement is reported
14752 as a warning or an error
14753 can depend on the relative order
14754 of the disagreeing portions of the source file.
14756 Disagreements between a procedure invocation
14757 and the @emph{subsequent} procedure itself
14758 are, usually, diagnosed as errors
14759 when the procedure itself @emph{precedes} the invocation.
14760 Other disagreements are diagnosed via warnings.
14762 @cindex forward references
14763 @cindex in-line code
14764 @cindex compilation, in-line
14765 This distinction, between warnings and errors,
14766 is due primarily to the present tendency of the @code{gcc} back end
14767 to inline only those procedure invocations that are
14768 @emph{preceded} by the corresponding procedure definitions.
14769 If the @code{gcc} back end is changed
14770 to inline ``forward references'',
14771 in which invocations precede definitions,
14772 the @code{g77} front end will be changed
14773 to treat both orderings as errors, accordingly.
14775 The sorts of disagreements that are diagnosed by @code{g77} include
14776 whether a procedure is a subroutine or function;
14777 if it is a function, the type of the return value of the procedure;
14778 the number of arguments the procedure accepts;
14779 and the type of each argument.
14781 Disagreements regarding global names among program units
14782 in a Fortran program @emph{should} be fixed in the code itself.
14783 However, if that is not immediately practical,
14784 and the code has been working for some time,
14785 it is possible it will work
14786 when compiled with the @samp{-fno-globals} option.
14788 The @samp{-fno-globals} option
14789 causes these diagnostics to all be warnings
14790 and disables all inlining of references to global procedures
14791 (to avoid subsequent compiler crashes and bad-code generation).
14792 Use of the @samp{-Wno-globals} option as well as @samp{-fno-globals}
14793 suppresses all of these diagnostics.
14794 (@samp{-Wno-globals} by itself disables only the warnings,
14797 After using @samp{-fno-globals} to work around these problems,
14798 it is wise to stop using that option and address them by fixing
14799 the Fortran code, because such problems, while they might not
14800 actually result in bugs on some systems, indicate that the code
14801 is not as portable as it could be.
14802 In particular, the code might appear to work on a particular
14803 system, but have bugs that affect the reliability of the data
14804 without exhibiting any other outward manifestations of the bugs.
14807 @section @code{LINKFAIL}
14811 If the above command failed due to an unresolved reference
14812 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
14813 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
14814 for information on what causes this, how to work around
14815 the problem by editing $@{srcdir@}/proj.c, and what else to do.
14818 @xref{Missing strtoul or bsearch}, for more information on
14820 which occurs only in releases of @code{g77}
14821 based on @code{gcc}.
14822 (It does not occur in @code{egcs}.)
14824 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
14825 due to a linker bug in coping with the @samp{-bbigtoc} option which
14826 leads to a @samp{Relocation overflow} error. The GNU linker is not
14827 recommended on current AIX versions, though; it was developed under a
14828 now-unsupported version. This bug is said to be fixed by `update PTF
14829 U455193 for APAR IX75823'.
14831 Compiling with @samp{-mminimal-toc}
14832 might solve this problem, e.g.@: by adding
14834 BOOT_CFLAGS='-mminimal-toc -O2 -g'
14836 to the @code{make bootstrap} command line.
14839 @section @code{Y2KBAD}
14840 @cindex Y2K compliance
14841 @cindex Year 2000 compliance
14845 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
14848 This diagnostic indicates that
14849 the specific intrinsic invoked by the name @var{name}
14850 is known to have an interface
14851 that is not Year-2000 (Y2K) compliant.
14853 @xref{Year 2000 (Y2K) Problems}.