1 \input texinfo @c -*-texinfo-*-
5 @set last-update 2000-12-21
6 @set copyrights-g77 1995,1996,1997,1998,1999,2000
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) @var{year} @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) @var{year} @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, had 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---see @ref{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 -funsafe-math-optimizations -fno-trapping-math
1450 -fexpensive-optimizations -fdelayed-branch
1451 -fschedule-insns -fschedule-insn2 -fcaller-saves
1452 -funroll-loops -funroll-all-loops
1453 -fno-move-all-movables -fno-reduce-all-givs
1457 @item Directory Options
1458 @xref{Directory Options,,Options for Directory Search}.
1463 @item Code Generation Options
1464 @xref{Code Gen Options,,Options for Code Generation Conventions}.
1466 -fno-automatic -finit-local-zero -fno-f2c
1467 -ff2c-library -fno-underscoring -fno-ident
1468 -fpcc-struct-return -freg-struct-return
1469 -fshort-double -fno-common -fpack-struct
1470 -fzeros -fno-second-underscore
1471 -fdebug-kludge -femulate-complex
1472 -falias-check -fargument-alias
1473 -fargument-noalias -fno-argument-noalias-global
1474 -fno-globals -fflatten-arrays
1475 -fbounds-check -ffortran-bounds-check
1480 * Overall Options:: Controlling the kind of output:
1481 an executable, object files, assembler files,
1482 or preprocessed source.
1483 * Shorthand Options:: Options that are shorthand for other options.
1484 * Fortran Dialect Options:: Controlling the variant of Fortran language
1486 * Warning Options:: How picky should the compiler be?
1487 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1488 * Optimize Options:: How much optimization?
1489 * Preprocessor Options:: Controlling header files and macro definitions.
1490 Also, getting dependency information for Make.
1491 * Directory Options:: Where to find header files and libraries.
1492 Where to find the compiler executable files.
1493 * Code Gen Options:: Specifying conventions for function calls, data layout
1497 @node Overall Options
1498 @section Options Controlling the Kind of Output
1499 @cindex overall options
1500 @cindex options, overall
1502 Compilation can involve as many as four stages: preprocessing, code
1503 generation (often what is really meant by the term ``compilation''),
1504 assembly, and linking, always in that order. The first three
1505 stages apply to an individual source file, and end by producing an
1506 object file; linking combines all the object files (those newly
1507 compiled, and those specified as input) into an executable file.
1509 @cindex file name suffix
1510 @cindex suffixes, file name
1511 @cindex file name extension
1512 @cindex extensions, file name
1515 For any given input file, the file name suffix determines what kind of
1516 program is contained in the file---that is, the language in which the
1517 program is written is generally indicated by the suffix.
1518 Suffixes specific to GNU Fortran are listed below.
1519 @xref{Overall Options,,gcc,Using and Porting GNU CC}, for
1520 information on suffixes recognized by GNU CC.
1523 @cindex .f filename suffix
1524 @cindex .for filename suffix
1525 @cindex .FOR filename suffix
1527 @item @var{file}.for
1528 @item @var{file}.FOR
1529 Fortran source code that should not be preprocessed.
1531 Such source code cannot contain any preprocessor directives, such
1532 as @code{#include}, @code{#define}, @code{#if}, and so on.
1534 You can force @samp{.f} files to be preprocessed by @code{cpp} by using
1535 @samp{-x f77-cpp-input}.
1538 @cindex preprocessor
1539 @cindex C preprocessor
1540 @cindex cpp preprocessor
1541 @cindex Fortran preprocessor
1543 @cindex programs, cpp
1544 @cindex .F filename suffix
1545 @cindex .fpp filename suffix
1546 @cindex .FPP filename suffix
1548 @item @var{file}.fpp
1549 @item @var{file}.FPP
1550 Fortran source code that must be preprocessed (by the C preprocessor
1551 @code{cpp}, which is part of GNU CC).
1553 Note that preprocessing is not extended to the contents of
1554 files included by the @code{INCLUDE} directive---the @code{#include}
1555 preprocessor directive must be used instead.
1557 @cindex Ratfor preprocessor
1558 @cindex programs, @code{ratfor}
1559 @cindex @samp{.r} filename suffix
1560 @cindex @code{ratfor}
1562 Ratfor source code, which must be preprocessed by the @code{ratfor}
1563 command, which is available separately (as it is not yet part of the GNU
1564 Fortran distribution).
1565 One version in Fortran, adapted for use with @code{g77}, is at
1566 @uref{ftp://members.aol.com/n8tm/rat7.uue} (of uncertain copyright
1567 status). Another, public domain version in C is at
1568 @uref{http://sepwww.stanford.edu/sep/prof/ratfor.shar.2}.
1571 UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
1573 Users of other operating systems, especially those that cannot
1574 distinguish upper-case
1575 letters from lower-case letters in their file names, typically use
1576 the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.
1581 Use of the preprocessor @code{cpp} allows use of C-like
1582 constructs such as @code{#define} and @code{#include}, but can
1583 lead to unexpected, even mistaken, results due to Fortran's source file
1585 It is recommended that use of the C preprocessor
1586 be limited to @code{#include} and, in
1587 conjunction with @code{#define}, only @code{#if} and related directives,
1588 thus avoiding in-line macro expansion entirely.
1589 This recommendation applies especially
1590 when using the traditional fixed source form.
1591 With free source form,
1592 fewer unexpected transformations are likely to happen, but use of
1593 constructs such as Hollerith and character constants can nevertheless
1594 present problems, especially when these are continued across multiple
1596 These problems result, primarily, from differences between the way
1597 such constants are interpreted by the C preprocessor and by a Fortran
1600 Another example of a problem that results from using the C preprocessor
1601 is that a Fortran comment line that happens to contain any
1602 characters ``interesting'' to the C preprocessor,
1603 such as a backslash at the end of the line,
1604 is not recognized by the preprocessor as a comment line,
1605 so instead of being passed through ``raw'',
1606 the line is edited according to the rules for the preprocessor.
1607 For example, the backslash at the end of the line is removed,
1608 along with the subsequent newline, resulting in the next
1609 line being effectively commented out---unfortunate if that
1610 line is a non-comment line of important code!
1612 @emph{Note:} The @samp{-traditional} and @samp{-undef} flags are supplied
1613 to @code{cpp} by default, to help avoid unpleasant surprises.
1614 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
1615 gcc,Using and Porting GNU CC}.
1616 This means that ANSI C preprocessor features (such as the @samp{#}
1617 operator) aren't available, and only variables in the C reserved
1618 namespace (generally, names with a leading underscore) are liable to
1619 substitution by C predefines.
1620 Thus, if you want to do system-specific
1621 tests, use, for example, @samp{#ifdef __linux__} rather than @samp{#ifdef linux}.
1622 Use the @samp{-v} option to see exactly how the preprocessor is invoked.
1625 Unfortunately, the @samp{-traditional} flag will not avoid an error from
1626 anything that @code{cpp} sees as an unterminated C comment, such as:
1628 C Some Fortran compilers accept /* as starting
1629 C an inline comment.
1631 @xref{Trailing Comment}.
1633 The following options that affect overall processing are recognized
1634 by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:
1637 @cindex -fversion option
1638 @cindex options, -fversion
1639 @cindex printing version information
1640 @cindex version information, printing
1641 @cindex consistency checks
1642 @cindex internal consistency checks
1643 @cindex checks, of internal consistency
1645 Ensure that the @code{g77}-specific version of the compiler phase is reported,
1647 and, starting in @code{egcs} version 1.1,
1648 that internal consistency checks in the @file{f771} program are run.
1650 This option is supplied automatically when @samp{-v} or @samp{--verbose}
1651 is specified as a command-line option for @code{g77} or @code{gcc}
1652 and when the resulting commands compile Fortran source files.
1654 @cindex -fset-g77-defaults option
1655 @cindex options, -fset-g77-defaults
1656 @item -fset-g77-defaults
1657 @emph{Version info:}
1658 This option was obsolete as of @code{egcs}
1660 The effect is instead achieved
1661 by the @code{lang_init_options} routine
1662 in @file{gcc/gcc/f/com.c}.
1664 @cindex consistency checks
1665 @cindex internal consistency checks
1666 @cindex checks, of internal consistency
1667 Set up whatever @code{gcc} options are to apply to Fortran
1668 compilations, and avoid running internal consistency checks
1669 that might take some time.
1671 This option is supplied automatically when compiling Fortran code
1672 via the @code{g77} or @code{gcc} command.
1673 The description of this option is provided so that users seeing
1674 it in the output of, say, @samp{g77 -v} understand why it is
1677 @cindex modifying g77
1678 @cindex code, modifying
1679 Also, developers who run @code{f771} directly might want to specify it
1680 by hand to get the same defaults as they would running @code{f771}
1681 via @code{g77} or @code{gcc}.
1682 However, such developers should, after linking a new @code{f771}
1683 executable, invoke it without this option once,
1684 e.g. via @kbd{./f771 -quiet < /dev/null},
1685 to ensure that they have not introduced any
1686 internal inconsistencies (such as in the table of
1687 intrinsics) before proceeding---@code{g77} will crash
1688 with a diagnostic if it detects an inconsistency.
1690 @cindex -fno-silent option
1691 @cindex options, -fno-silent
1692 @cindex f2c compatibility
1693 @cindex compatibility, f2c
1694 @cindex status, compilation
1695 @cindex compilation, status
1696 @cindex reporting compilation status
1697 @cindex printing compilation status
1699 Print (to @code{stderr}) the names of the program units as
1700 they are compiled, in a form similar to that used by popular
1701 UNIX @code{f77} implementations and @code{f2c}.
1704 @xref{Overall Options,,Options Controlling the Kind of Output,
1705 gcc,Using and Porting GNU CC}, for information
1706 on more options that control the overall operation of the @code{gcc} command
1707 (and, by extension, the @code{g77} command).
1709 @node Shorthand Options
1710 @section Shorthand Options
1711 @cindex shorthand options
1712 @cindex options, shorthand
1713 @cindex macro options
1714 @cindex options, macro
1716 The following options serve as ``shorthand''
1717 for other options accepted by the compiler:
1720 @cindex -fugly option
1721 @cindex options, -fugly
1723 @cindex ugly features
1724 @cindex features, ugly
1725 @emph{Note:} This option is no longer supported.
1726 The information, below, is provided to aid
1727 in the conversion of old scripts.
1729 Specify that certain ``ugly'' constructs are to be quietly accepted.
1733 -fugly-args -fugly-assign -fugly-assumed
1734 -fugly-comma -fugly-complex -fugly-init
1738 These constructs are considered inappropriate to use in new
1739 or well-maintained portable Fortran code, but widely used
1741 @xref{Distensions}, for more information.
1743 @cindex -fno-ugly option
1744 @cindex options, -fno-ugly
1746 @cindex ugly features
1747 @cindex features, ugly
1748 Specify that all ``ugly'' constructs are to be noisily rejected.
1752 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1753 -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
1757 @xref{Distensions}, for more information.
1759 @cindex -ff66 option
1760 @cindex options, -ff66
1763 @cindex compatibility, FORTRAN 66
1764 Specify that the program is written in idiomatic FORTRAN 66.
1765 Same as @samp{-fonetrip -fugly-assumed}.
1767 The @samp{-fno-f66} option is the inverse of @samp{-ff66}.
1768 As such, it is the same as @samp{-fno-onetrip -fno-ugly-assumed}.
1770 The meaning of this option is likely to be refined as future
1771 versions of @code{g77} provide more compatibility with other
1772 existing and obsolete Fortran implementations.
1774 @cindex -ff77 option
1775 @cindex options, -ff77
1778 @cindex f2c compatibility
1779 @cindex compatibility, f2c
1780 @cindex f77 compatibility
1781 @cindex compatibility, f77
1782 Specify that the program is written in idiomatic UNIX FORTRAN 77
1783 and/or the dialect accepted by the @code{f2c} product.
1784 Same as @samp{-fbackslash -fno-typeless-boz}.
1786 The meaning of this option is likely to be refined as future
1787 versions of @code{g77} provide more compatibility with other
1788 existing and obsolete Fortran implementations.
1790 @cindex -fno-f77 option
1791 @cindex options, -fno-f77
1794 The @samp{-fno-f77} option is @emph{not} the inverse
1796 It specifies that the program is not written in idiomatic UNIX
1797 FORTRAN 77 or @code{f2c}, but in a more widely portable dialect.
1798 @samp{-fno-f77} is the same as @samp{-fno-backslash}.
1800 The meaning of this option is likely to be refined as future
1801 versions of @code{g77} provide more compatibility with other
1802 existing and obsolete Fortran implementations.
1805 @node Fortran Dialect Options
1806 @section Options Controlling Fortran Dialect
1807 @cindex dialect options
1808 @cindex language, dialect options
1809 @cindex options, dialect
1811 The following options control the dialect of Fortran
1812 that the compiler accepts:
1815 @cindex -ffree-form option
1816 @cindex options, -ffree-form
1817 @cindex -fno-fixed-form option
1818 @cindex options, -fno-fixed-form
1819 @cindex source file format
1822 @cindex Fortran 90, features
1824 @item -fno-fixed-form
1825 Specify that the source file is written in free form
1826 (introduced in Fortran 90) instead of the more-traditional fixed form.
1828 @cindex -ff90 option
1829 @cindex options, -ff90
1830 @cindex Fortran 90, features
1832 Allow certain Fortran-90 constructs.
1834 This option controls whether certain
1835 Fortran 90 constructs are recognized.
1836 (Other Fortran 90 constructs
1837 might or might not be recognized depending on other options such as
1838 @samp{-fvxt}, @samp{-ff90-intrinsics-enable}, and the
1839 current level of support for Fortran 90.)
1841 @xref{Fortran 90}, for more information.
1843 @cindex -fvxt option
1844 @cindex options, -fvxt
1846 @cindex Fortran 90, features
1847 @cindex VXT extensions
1848 Specify the treatment of certain constructs that have different
1849 meanings depending on whether the code is written in
1850 GNU Fortran (based on FORTRAN 77 and akin to Fortran 90)
1851 or VXT Fortran (more like VAX FORTRAN).
1853 The default is @samp{-fno-vxt}.
1854 @samp{-fvxt} specifies that the VXT Fortran interpretations
1855 for those constructs are to be chosen.
1857 @xref{VXT Fortran}, for more information.
1859 @cindex -fdollar-ok option
1860 @cindex options, -fdollar-ok
1863 @cindex symbol names
1864 @cindex character set
1865 Allow @samp{$} as a valid character in a symbol name.
1867 @cindex -fno-backslash option
1868 @cindex options, -fno-backslash
1869 @item -fno-backslash
1871 @cindex character constants
1872 @cindex Hollerith constants
1873 Specify that @samp{\} is not to be specially interpreted in character
1874 and Hollerith constants a la C and many UNIX Fortran compilers.
1876 For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
1877 three characters, with the second one being newline.
1878 With @samp{-fno-backslash}, it specifies four characters,
1879 @samp{A}, @samp{\}, @samp{n}, and @samp{B}.
1881 Note that @code{g77} implements a fairly general form of backslash
1882 processing that is incompatible with the narrower forms supported
1883 by some other compilers.
1884 For example, @samp{'A\003B'} is a three-character string in @code{g77},
1885 whereas other compilers that support backslash might not support
1886 the three-octal-digit form, and thus treat that string as longer
1887 than three characters.
1889 @xref{Backslash in Constants}, for
1890 information on why @samp{-fbackslash} is the default
1891 instead of @samp{-fno-backslash}.
1893 @cindex -fno-ugly-args option
1894 @cindex options, -fno-ugly-args
1895 @item -fno-ugly-args
1896 Disallow passing Hollerith and typeless constants as actual
1897 arguments (for example, @samp{CALL FOO(4HABCD)}).
1899 @xref{Ugly Implicit Argument Conversion}, for more information.
1901 @cindex -fugly-assign option
1902 @cindex options, -fugly-assign
1904 Use the same storage for a given variable regardless of
1905 whether it is used to hold an assigned-statement label
1906 (as in @samp{ASSIGN 10 TO I}) or used to hold numeric data
1907 (as in @samp{I = 3}).
1909 @xref{Ugly Assigned Labels}, for more information.
1911 @cindex -fugly-assumed option
1912 @cindex options, -fugly-assumed
1913 @item -fugly-assumed
1914 Assume any dummy array with a final dimension specified as @samp{1}
1915 is really an assumed-size array, as if @samp{*} had been specified
1916 for the final dimension instead of @samp{1}.
1918 For example, @samp{DIMENSION X(1)} is treated as if it
1919 had read @samp{DIMENSION X(*)}.
1921 @xref{Ugly Assumed-Size Arrays}, for more information.
1923 @cindex -fugly-comma option
1924 @cindex options, -fugly-comma
1926 In an external-procedure invocation,
1927 treat a trailing comma in the argument list
1928 as specification of a trailing null argument,
1929 and treat an empty argument list
1930 as specification of a single null argument.
1932 For example, @samp{CALL FOO(,)} is treated as
1933 @samp{CALL FOO(%VAL(0), %VAL(0))}.
1934 That is, @emph{two} null arguments are specified
1935 by the procedure call when @samp{-fugly-comma} is in force.
1936 And @samp{F = FUNC()} is treated as @samp{F = FUNC(%VAL(0))}.
1938 The default behavior, @samp{-fno-ugly-comma}, is to ignore
1939 a single trailing comma in an argument list.
1940 So, by default, @samp{CALL FOO(X,)} is treated
1941 exactly the same as @samp{CALL FOO(X)}.
1943 @xref{Ugly Null Arguments}, for more information.
1945 @cindex -fugly-complex option
1946 @cindex options, -fugly-complex
1947 @item -fugly-complex
1948 Do not complain about @samp{REAL(@var{expr})} or
1949 @samp{AIMAG(@var{expr})} when @var{expr} is a @code{COMPLEX}
1950 type other than @code{COMPLEX(KIND=1)}---usually
1951 this is used to permit @code{COMPLEX(KIND=2)}
1952 (@code{DOUBLE COMPLEX}) operands.
1954 The @samp{-ff90} option controls the interpretation
1957 @xref{Ugly Complex Part Extraction}, for more information.
1959 @cindex -fno-ugly-init option
1960 @cindex options, -fno-ugly-init
1961 @item -fno-ugly-init
1962 Disallow use of Hollerith and typeless constants as initial
1963 values (in @code{PARAMETER} and @code{DATA} statements), and
1964 use of character constants to
1965 initialize numeric types and vice versa.
1967 For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
1968 @samp{-fno-ugly-init}.
1970 @xref{Ugly Conversion of Initializers}, for more information.
1972 @cindex -fugly-logint option
1973 @cindex options, -fugly-logint
1975 Treat @code{INTEGER} and @code{LOGICAL} variables and
1976 expressions as potential stand-ins for each other.
1978 For example, automatic conversion between @code{INTEGER} and
1979 @code{LOGICAL} is enabled, for many contexts, via this option.
1981 @xref{Ugly Integer Conversions}, for more information.
1983 @cindex -fonetrip option
1984 @cindex options, -fonetrip
1987 @cindex @code{DO} loops, one-trip
1988 @cindex one-trip @code{DO} loops
1989 @cindex @code{DO} loops, zero-trip
1990 @cindex zero-trip @code{DO} loops
1991 @cindex compatibility, FORTRAN 66
1992 Executable iterative @code{DO} loops are to be executed at
1993 least once each time they are reached.
1995 ANSI FORTRAN 77 and more recent versions of the Fortran standard
1996 specify that the body of an iterative @code{DO} loop is not executed
1997 if the number of iterations calculated from the parameters of the
1998 loop is less than 1.
1999 (For example, @samp{DO 10 I = 1, 0}.)
2000 Such a loop is called a @dfn{zero-trip loop}.
2002 Prior to ANSI FORTRAN 77, many compilers implemented @code{DO} loops
2003 such that the body of a loop would be executed at least once, even
2004 if the iteration count was zero.
2005 Fortran code written assuming this behavior is said to require
2006 @dfn{one-trip loops}.
2007 For example, some code written to the FORTRAN 66 standard
2008 expects this behavior from its @code{DO} loops, although that
2009 standard did not specify this behavior.
2011 The @samp{-fonetrip} option specifies that the source file(s) being
2012 compiled require one-trip loops.
2014 This option affects only those loops specified by the (iterative) @code{DO}
2015 statement and by implied-@code{DO} lists in I/O statements.
2016 Loops specified by implied-@code{DO} lists in @code{DATA} and
2017 specification (non-executable) statements are not affected.
2019 @cindex -ftypeless-boz option
2020 @cindex options, -ftypeless-boz
2021 @cindex prefix-radix constants
2022 @cindex constants, prefix-radix
2023 @cindex constants, types
2024 @cindex types, constants
2025 @item -ftypeless-boz
2026 Specifies that prefix-radix non-decimal constants, such as
2027 @samp{Z'ABCD'}, are typeless instead of @code{INTEGER(KIND=1)}.
2029 You can test for yourself whether a particular compiler treats
2030 the prefix form as @code{INTEGER(KIND=1)} or typeless by running the
2037 IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
2038 IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
2042 Reports indicate that many compilers process this form as
2043 @code{INTEGER(KIND=1)}, though a few as typeless, and at least one
2044 based on a command-line option specifying some kind of
2047 @cindex -fintrin-case-initcap option
2048 @cindex options, -fintrin-case-initcap
2049 @item -fintrin-case-initcap
2050 @cindex -fintrin-case-upper option
2051 @cindex options, -fintrin-case-upper
2052 @item -fintrin-case-upper
2053 @cindex -fintrin-case-lower option
2054 @cindex options, -fintrin-case-lower
2055 @item -fintrin-case-lower
2056 @cindex -fintrin-case-any option
2057 @cindex options, -fintrin-case-any
2058 @item -fintrin-case-any
2059 Specify expected case for intrinsic names.
2060 @samp{-fintrin-case-lower} is the default.
2062 @cindex -fmatch-case-initcap option
2063 @cindex options, -fmatch-case-initcap
2064 @item -fmatch-case-initcap
2065 @cindex -fmatch-case-upper option
2066 @cindex options, -fmatch-case-upper
2067 @item -fmatch-case-upper
2068 @cindex -fmatch-case-lower option
2069 @cindex options, -fmatch-case-lower
2070 @item -fmatch-case-lower
2071 @cindex -fmatch-case-any option
2072 @cindex options, -fmatch-case-any
2073 @item -fmatch-case-any
2074 Specify expected case for keywords.
2075 @samp{-fmatch-case-lower} is the default.
2077 @cindex -fsource-case-upper option
2078 @cindex options, -fsource-case-upper
2079 @item -fsource-case-upper
2080 @cindex -fsource-case-lower option
2081 @cindex options, -fsource-case-lower
2082 @item -fsource-case-lower
2083 @cindex -fsource-case-preserve option
2084 @cindex options, -fsource-case-preserve
2085 @item -fsource-case-preserve
2086 Specify whether source text other than character and Hollerith constants
2087 is to be translated to uppercase, to lowercase, or preserved as is.
2088 @samp{-fsource-case-lower} is the default.
2090 @cindex -fsymbol-case-initcap option
2091 @cindex options, -fsymbol-case-initcap
2092 @item -fsymbol-case-initcap
2093 @cindex -fsymbol-case-upper option
2094 @cindex options, -fsymbol-case-upper
2095 @item -fsymbol-case-upper
2096 @cindex -fsymbol-case-lower option
2097 @cindex options, -fsymbol-case-lower
2098 @item -fsymbol-case-lower
2099 @cindex -fsymbol-case-any option
2100 @cindex options, -fsymbol-case-any
2101 @item -fsymbol-case-any
2102 Specify valid cases for user-defined symbol names.
2103 @samp{-fsymbol-case-any} is the default.
2105 @cindex -fcase-strict-upper option
2106 @cindex options, -fcase-strict-upper
2107 @item -fcase-strict-upper
2108 Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
2109 -fsymbol-case-upper}.
2110 (Requires all pertinent source to be in uppercase.)
2112 @cindex -fcase-strict-lower option
2113 @cindex options, -fcase-strict-lower
2114 @item -fcase-strict-lower
2115 Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
2116 -fsymbol-case-lower}.
2117 (Requires all pertinent source to be in lowercase.)
2119 @cindex -fcase-initcap option
2120 @cindex options, -fcase-initcap
2121 @item -fcase-initcap
2122 Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
2123 -fsymbol-case-initcap}.
2124 (Requires all pertinent source to be in initial capitals,
2125 as in @samp{Print *,SqRt(Value)}.)
2127 @cindex -fcase-upper option
2128 @cindex options, -fcase-upper
2130 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
2132 (Maps all pertinent source to uppercase.)
2134 @cindex -fcase-lower option
2135 @cindex options, -fcase-lower
2137 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
2139 (Maps all pertinent source to lowercase.)
2141 @cindex -fcase-preserve option
2142 @cindex options, -fcase-preserve
2143 @item -fcase-preserve
2144 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
2146 (Preserves all case in user-defined symbols,
2147 while allowing any-case matching of intrinsics and keywords.
2148 For example, @samp{call Foo(i,I)} would pass two @emph{different}
2149 variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)
2151 @cindex -fbadu77-intrinsics-delete option
2152 @cindex options, -fbadu77-intrinsics-delete
2153 @item -fbadu77-intrinsics-delete
2154 @cindex -fbadu77-intrinsics-hide option
2155 @cindex options, -fbadu77-intrinsics-hide
2156 @item -fbadu77-intrinsics-hide
2157 @cindex -fbadu77-intrinsics-disable option
2158 @cindex options, -fbadu77-intrinsics-disable
2159 @item -fbadu77-intrinsics-disable
2160 @cindex -fbadu77-intrinsics-enable option
2161 @cindex options, -fbadu77-intrinsics-enable
2162 @item -fbadu77-intrinsics-enable
2163 @cindex @code{badu77} intrinsics
2164 @cindex intrinsics, @code{badu77}
2165 Specify status of UNIX intrinsics having inappropriate forms.
2166 @samp{-fbadu77-intrinsics-enable} is the default.
2167 @xref{Intrinsic Groups}.
2169 @cindex -ff2c-intrinsics-delete option
2170 @cindex options, -ff2c-intrinsics-delete
2171 @item -ff2c-intrinsics-delete
2172 @cindex -ff2c-intrinsics-hide option
2173 @cindex options, -ff2c-intrinsics-hide
2174 @item -ff2c-intrinsics-hide
2175 @cindex -ff2c-intrinsics-disable option
2176 @cindex options, -ff2c-intrinsics-disable
2177 @item -ff2c-intrinsics-disable
2178 @cindex -ff2c-intrinsics-enable option
2179 @cindex options, -ff2c-intrinsics-enable
2180 @item -ff2c-intrinsics-enable
2181 @cindex @code{f2c} intrinsics
2182 @cindex intrinsics, @code{f2c}
2183 Specify status of f2c-specific intrinsics.
2184 @samp{-ff2c-intrinsics-enable} is the default.
2185 @xref{Intrinsic Groups}.
2187 @cindex -ff90-intrinsics-delete option
2188 @cindex options, -ff90-intrinsics-delete
2189 @item -ff90-intrinsics-delete
2190 @cindex -ff90-intrinsics-hide option
2191 @cindex options, -ff90-intrinsics-hide
2192 @item -ff90-intrinsics-hide
2193 @cindex -ff90-intrinsics-disable option
2194 @cindex options, -ff90-intrinsics-disable
2195 @item -ff90-intrinsics-disable
2196 @cindex -ff90-intrinsics-enable option
2197 @cindex options, -ff90-intrinsics-enable
2198 @item -ff90-intrinsics-enable
2199 @cindex Fortran 90, intrinsics
2200 @cindex intrinsics, Fortran 90
2201 Specify status of F90-specific intrinsics.
2202 @samp{-ff90-intrinsics-enable} is the default.
2203 @xref{Intrinsic Groups}.
2205 @cindex -fgnu-intrinsics-delete option
2206 @cindex options, -fgnu-intrinsics-delete
2207 @item -fgnu-intrinsics-delete
2208 @cindex -fgnu-intrinsics-hide option
2209 @cindex options, -fgnu-intrinsics-hide
2210 @item -fgnu-intrinsics-hide
2211 @cindex -fgnu-intrinsics-disable option
2212 @cindex options, -fgnu-intrinsics-disable
2213 @item -fgnu-intrinsics-disable
2214 @cindex -fgnu-intrinsics-enable option
2215 @cindex options, -fgnu-intrinsics-enable
2216 @item -fgnu-intrinsics-enable
2217 @cindex Digital Fortran features
2218 @cindex @code{COMPLEX} intrinsics
2219 @cindex intrinsics, @code{COMPLEX}
2220 Specify status of Digital's COMPLEX-related intrinsics.
2221 @samp{-fgnu-intrinsics-enable} is the default.
2222 @xref{Intrinsic Groups}.
2224 @cindex -fmil-intrinsics-delete option
2225 @cindex options, -fmil-intrinsics-delete
2226 @item -fmil-intrinsics-delete
2227 @cindex -fmil-intrinsics-hide option
2228 @cindex options, -fmil-intrinsics-hide
2229 @item -fmil-intrinsics-hide
2230 @cindex -fmil-intrinsics-disable option
2231 @cindex options, -fmil-intrinsics-disable
2232 @item -fmil-intrinsics-disable
2233 @cindex -fmil-intrinsics-enable option
2234 @cindex options, -fmil-intrinsics-enable
2235 @item -fmil-intrinsics-enable
2236 @cindex MIL-STD 1753
2237 @cindex intrinsics, MIL-STD 1753
2238 Specify status of MIL-STD-1753-specific intrinsics.
2239 @samp{-fmil-intrinsics-enable} is the default.
2240 @xref{Intrinsic Groups}.
2242 @cindex -funix-intrinsics-delete option
2243 @cindex options, -funix-intrinsics-delete
2244 @item -funix-intrinsics-delete
2245 @cindex -funix-intrinsics-hide option
2246 @cindex options, -funix-intrinsics-hide
2247 @item -funix-intrinsics-hide
2248 @cindex -funix-intrinsics-disable option
2249 @cindex options, -funix-intrinsics-disable
2250 @item -funix-intrinsics-disable
2251 @cindex -funix-intrinsics-enable option
2252 @cindex options, -funix-intrinsics-enable
2253 @item -funix-intrinsics-enable
2254 @cindex UNIX intrinsics
2255 @cindex intrinsics, UNIX
2256 Specify status of UNIX intrinsics.
2257 @samp{-funix-intrinsics-enable} is the default.
2258 @xref{Intrinsic Groups}.
2260 @cindex -fvxt-intrinsics-delete option
2261 @cindex options, -fvxt-intrinsics-delete
2262 @item -fvxt-intrinsics-delete
2263 @cindex -fvxt-intrinsics-hide option
2264 @cindex options, -fvxt-intrinsics-hide
2265 @item -fvxt-intrinsics-hide
2266 @cindex -fvxt-intrinsics-disable option
2267 @cindex options, -fvxt-intrinsics-disable
2268 @item -fvxt-intrinsics-disable
2269 @cindex -fvxt-intrinsics-enable option
2270 @cindex options, -fvxt-intrinsics-enable
2271 @item -fvxt-intrinsics-enable
2272 @cindex VXT intrinsics
2273 @cindex intrinsics, VXT
2274 Specify status of VXT intrinsics.
2275 @samp{-fvxt-intrinsics-enable} is the default.
2276 @xref{Intrinsic Groups}.
2278 @cindex -ffixed-line-length-@var{n} option
2279 @cindex options, -ffixed-line-length-@var{n}
2280 @item -ffixed-line-length-@var{n}
2281 @cindex source file format
2282 @cindex lines, length
2283 @cindex length of source lines
2285 @cindex limits, lengths of source lines
2286 Set column after which characters are ignored in typical fixed-form
2287 lines in the source file, and through which spaces are assumed (as
2288 if padded to that length) after the ends of short fixed-form lines.
2291 @cindex extended-source option
2292 Popular values for @var{n} include 72 (the
2293 standard and the default), 80 (card image), and 132 (corresponds
2294 to ``extended-source'' options in some popular compilers).
2295 @var{n} may be @samp{none}, meaning that the entire line is meaningful
2296 and that continued character constants never have implicit spaces appended
2297 to them to fill out the line.
2298 @samp{-ffixed-line-length-0} means the same thing as
2299 @samp{-ffixed-line-length-none}.
2301 @xref{Source Form}, for more information.
2304 @node Warning Options
2305 @section Options to Request or Suppress Warnings
2306 @cindex options, warnings
2307 @cindex warnings, suppressing
2308 @cindex messages, warning
2309 @cindex suppressing warnings
2311 Warnings are diagnostic messages that report constructions which
2312 are not inherently erroneous but which are risky or suggest there
2313 might have been an error.
2315 You can request many specific warnings with options beginning @samp{-W},
2316 for example @samp{-Wimplicit} to request warnings on implicit
2317 declarations. Each of these specific warning options also has a
2318 negative form beginning @samp{-Wno-} to turn off warnings;
2319 for example, @samp{-Wno-implicit}. This manual lists only one of the
2320 two forms, whichever is not the default.
2322 These options control the amount and kinds of warnings produced by GNU
2326 @cindex syntax checking
2327 @cindex -fsyntax-only option
2328 @cindex options, -fsyntax-only
2330 Check the code for syntax errors, but don't do anything beyond that.
2332 @cindex -pedantic option
2333 @cindex options, -pedantic
2335 Issue warnings for uses of extensions to ANSI FORTRAN 77.
2336 @samp{-pedantic} also applies to C-language constructs where they
2337 occur in GNU Fortran source files, such as use of @samp{\e} in a
2338 character constant within a directive like @samp{#include}.
2340 Valid ANSI FORTRAN 77 programs should compile properly with or without
2342 However, without this option, certain GNU extensions and traditional
2343 Fortran features are supported as well.
2344 With this option, many of them are rejected.
2346 Some users try to use @samp{-pedantic} to check programs for strict ANSI
2348 They soon find that it does not do quite what they want---it finds some
2349 non-ANSI practices, but not all.
2350 However, improvements to @code{g77} in this area are welcome.
2352 @cindex -pedantic-errors option
2353 @cindex options, -pedantic-errors
2354 @item -pedantic-errors
2355 Like @samp{-pedantic}, except that errors are produced rather than
2358 @cindex -fpedantic option
2359 @cindex options, -fpedantic
2361 Like @samp{-pedantic}, but applies only to Fortran constructs.
2366 Inhibit all warning messages.
2368 @cindex -Wno-globals option
2369 @cindex options, -Wno-globals
2371 @cindex global names, warning
2372 @cindex warnings, global names
2373 Inhibit warnings about use of a name as both a global name
2374 (a subroutine, function, or block data program unit, or a
2375 common block) and implicitly as the name of an intrinsic
2378 Also inhibit warnings about inconsistent invocations and/or
2379 definitions of global procedures (function and subroutines).
2380 Such inconsistencies include different numbers of arguments
2381 and different types of arguments.
2383 @cindex -Wimplicit option
2384 @cindex options, -Wimplicit
2386 @cindex implicit declaration, warning
2387 @cindex warnings, implicit declaration
2389 @cindex /WARNINGS=DECLARATIONS switch
2390 @cindex IMPLICIT NONE, similar effect
2391 @cindex effecting IMPLICIT NONE
2392 Warn whenever a variable, array, or function is implicitly
2394 Has an effect similar to using the @code{IMPLICIT NONE} statement
2395 in every program unit.
2396 (Some Fortran compilers provide this feature by an option
2397 named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)
2399 @cindex -Wunused option
2400 @cindex options, -Wunused
2402 @cindex unused variables
2403 @cindex variables, unused
2404 Warn whenever a variable is unused aside from its declaration.
2406 @cindex -Wuninitialized option
2407 @cindex options, -Wuninitialized
2408 @item -Wuninitialized
2409 @cindex uninitialized variables
2410 @cindex variables, uninitialized
2411 Warn whenever an automatic variable is used without first being initialized.
2413 These warnings are possible only in optimizing compilation,
2414 because they require data-flow information that is computed only
2415 when optimizing. If you don't specify @samp{-O}, you simply won't
2418 These warnings occur only for variables that are candidates for
2419 register allocation. Therefore, they do not occur for a variable
2420 @c that is declared @code{VOLATILE}, or
2421 whose address is taken, or whose size
2422 is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
2423 arrays, even when they are in registers.
2425 Note that there might be no warning about a variable that is used only
2426 to compute a value that itself is never used, because such
2427 computations may be deleted by data-flow analysis before the warnings
2430 These warnings are made optional because GNU Fortran is not smart
2431 enough to see all the reasons why the code might be correct
2432 despite appearing to have an error. Here is one example of how
2436 SUBROUTINE DISPAT(J)
2445 If the value of @code{J} is always 1, 2 or 3, then @code{I} is
2446 always initialized, but GNU Fortran doesn't know this. Here is
2447 another common case:
2450 SUBROUTINE MAYBE(FLAG)
2452 IF (FLAG) VALUE = 9.4
2454 IF (FLAG) PRINT *, VALUE
2459 This has no bug because @code{VALUE} is used only if it is set.
2461 @cindex -Wall option
2462 @cindex options, -Wall
2464 @cindex all warnings
2465 @cindex warnings, all
2466 The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
2468 options which pertain to usage that we recommend avoiding and that we
2469 believe is easy to avoid.
2470 (As more warnings are added to @code{g77}, some might
2471 be added to the list enabled by @samp{-Wall}.)
2474 The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
2475 because they warn about constructions that we consider reasonable to
2476 use, on occasion, in clean programs.
2480 @c Print extra warning messages for these events:
2484 @c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
2489 @cindex -Wsurprising option
2490 @cindex options, -Wsurprising
2492 Warn about ``suspicious'' constructs that are interpreted
2493 by the compiler in a way that might well be surprising to
2494 someone reading the code.
2495 These differences can result in subtle, compiler-dependent
2496 (even machine-dependent) behavioral differences.
2497 The constructs warned about include:
2501 Expressions having two arithmetic operators in a row, such
2503 Such a construct is nonstandard, and can produce
2504 unexpected results in more complicated situations such
2506 @code{g77}, along with many other compilers, interprets
2507 this example differently than many programmers, and a few
2509 Specifically, @code{g77} interprets @samp{X**-Y*Z} as
2510 @samp{(X**(-Y))*Z}, while others might think it should
2511 be interpreted as @samp{X**(-(Y*Z))}.
2513 A revealing example is the constant expression @samp{2**-2*1.},
2514 which @code{g77} evaluates to .25, while others might evaluate
2515 it to 0., the difference resulting from the way precedence affects
2518 (The @samp{-fpedantic} option also warns about expressions
2519 having two arithmetic operators in a row.)
2522 Expressions with a unary minus followed by an operand and then
2523 a binary operator other than plus or minus.
2524 For example, @samp{-2**2} produces a warning, because
2525 the precedence is @samp{-(2**2)}, yielding -4, not
2526 @samp{(-2)**2}, which yields 4, and which might represent
2527 what a programmer expects.
2529 An example of an expression producing different results
2530 in a surprising way is @samp{-I*S}, where @var{I} holds
2531 the value @samp{-2147483648} and @var{S} holds @samp{0.5}.
2532 On many systems, negating @var{I} results in the same
2533 value, not a positive number, because it is already the
2534 lower bound of what an @code{INTEGER(KIND=1)} variable can hold.
2535 So, the expression evaluates to a positive number, while
2536 the ``expected'' interpretation, @samp{(-I)*S}, would
2537 evaluate to a negative number.
2539 Even cases such as @samp{-I*J} produce warnings,
2540 even though, in most configurations and situations,
2541 there is no computational difference between the
2542 results of the two interpretations---the purpose
2543 of this warning is to warn about differing interpretations
2544 and encourage a better style of coding, not to identify
2545 only those places where bugs might exist in the user's
2548 @cindex DO statement
2549 @cindex statements, DO
2551 @code{DO} loops with @code{DO} variables that are not
2552 of integral type---that is, using @code{REAL}
2553 variables as loop control variables.
2554 Although such loops can be written to work in the
2555 ``obvious'' way, the way @code{g77} is required by the
2556 Fortran standard to interpret such code is likely to
2557 be quite different from the way many programmers expect.
2558 (This is true of all @code{DO} loops, but the differences
2559 are pronounced for non-integral loop control variables.)
2561 @xref{Loops}, for more information.
2564 @cindex -Werror option
2565 @cindex options, -Werror
2567 Make all warnings into errors.
2572 @cindex extra warnings
2573 @cindex warnings, extra
2574 Turns on ``extra warnings'' and, if optimization is specified
2575 via @samp{-O}, the @samp{-Wuninitialized} option.
2576 (This might change in future versions of @code{g77}.)
2578 ``Extra warnings'' are issued for:
2582 @cindex unused parameters
2583 @cindex parameters, unused
2584 @cindex unused arguments
2585 @cindex arguments, unused
2586 @cindex unused dummies
2587 @cindex dummies, unused
2588 Unused parameters to a procedure (when @samp{-Wunused} also is
2593 Overflows involving floating-point constants (not available
2594 for certain configurations).
2598 @xref{Warning Options,,Options to Request or Suppress Warnings,
2599 gcc,Using and Porting GNU CC}, for information on more options offered
2600 by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.
2602 Some of these have no effect when compiling programs written in Fortran:
2605 @cindex -Wcomment option
2606 @cindex options, -Wcomment
2608 @cindex -Wformat option
2609 @cindex options, -Wformat
2611 @cindex -Wparentheses option
2612 @cindex options, -Wparentheses
2614 @cindex -Wswitch option
2615 @cindex options, -Wswitch
2617 @cindex -Wtraditional option
2618 @cindex options, -Wtraditional
2620 @cindex -Wshadow option
2621 @cindex options, -Wshadow
2623 @cindex -Wid-clash-@var{len} option
2624 @cindex options, -Wid-clash-@var{len}
2625 @item -Wid-clash-@var{len}
2626 @cindex -Wlarger-than-@var{len} option
2627 @cindex options, -Wlarger-than-@var{len}
2628 @item -Wlarger-than-@var{len}
2629 @cindex -Wconversion option
2630 @cindex options, -Wconversion
2632 @cindex -Waggregate-return option
2633 @cindex options, -Waggregate-return
2634 @item -Waggregate-return
2635 @cindex -Wredundant-decls option
2636 @cindex options, -Wredundant-decls
2637 @item -Wredundant-decls
2638 @cindex unsupported warnings
2639 @cindex warnings, unsupported
2640 These options all could have some relevant meaning for
2641 GNU Fortran programs, but are not yet supported.
2644 @node Debugging Options
2645 @section Options for Debugging Your Program or GNU Fortran
2646 @cindex options, debugging
2647 @cindex debugging information options
2649 GNU Fortran has various special options that are used for debugging
2650 either your program or @code{g77}.
2656 Produce debugging information in the operating system's native format
2657 (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
2660 @cindex common blocks
2661 @cindex equivalence areas
2662 @cindex missing debug features
2663 Support for this option in Fortran programs was incomplete up till
2664 version 0.5.26 of @code{g77}.
2665 In particular, names of variables and arrays in common blocks
2666 or that are storage-associated via @code{EQUIVALENCE} were
2667 unavailable to the debugger.
2669 However, version 0.5.19 of @code{g77} does provide this information
2670 in a rudimentary way, as controlled by the
2671 @samp{-fdebug-kludge} option.
2673 Because version 0.5.26 of @code{g77} enables full debug information
2674 of COMMON BLOCK and EQUIVALENCE items, this option has been disabled.
2676 @xref{Code Gen Options,,Options for Code Generation Conventions},
2677 for more information.
2680 @xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
2681 gcc,Using and Porting GNU CC}, for more information on debugging options.
2683 @node Optimize Options
2684 @section Options That Control Optimization
2685 @cindex optimize options
2686 @cindex options, optimization
2688 Most Fortran users will want to use no optimization when
2689 developing and testing programs, and use @samp{-O} or @samp{-O2} when
2690 compiling programs for late-cycle testing and for production use.
2691 However, note that certain diagnostics---such as for uninitialized
2692 variables---depend on the flow analysis done by @samp{-O}, i.e.@: you
2693 must use @samp{-O} or @samp{-O2} to get such diagnostics.
2695 The following flags have particular applicability when
2696 compiling Fortran programs:
2699 @cindex -malign-double option
2700 @cindex options, -malign-double
2701 @item -malign-double
2702 (Intel x86 architecture only.)
2704 Noticeably improves performance of @code{g77} programs making
2705 heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data
2707 In particular, systems using Pentium, Pentium Pro, 586, and
2709 of the i386 architecture execute programs faster when
2710 @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data are
2711 aligned on 64-bit boundaries
2714 This option can, at least, make benchmark results more consistent
2715 across various system configurations, versions of the program,
2718 @emph{Note:} The warning in the @code{gcc} documentation about
2719 this option does not apply, generally speaking, to Fortran
2720 code compiled by @code{g77}.
2722 @xref{Aligned Data}, for more information on alignment issues.
2724 @emph{Also also note:} The negative form of @samp{-malign-double}
2725 is @samp{-mno-align-double}, not @samp{-benign-double}.
2727 @cindex -ffloat-store option
2728 @cindex options, -ffloat-store
2730 @cindex IEEE 754 conformance
2731 @cindex conformance, IEEE 754
2732 @cindex floating-point, precision
2733 Might help a Fortran program that depends on exact IEEE conformance on
2734 some machines, but might slow down a program that doesn't.
2736 This option is effective when the floating-point unit is set to work in
2737 IEEE 854 `extended precision'---as it typically is on x86 and m68k GNU
2738 systems---rather than IEEE 754 double precision. @samp{-ffloat-store}
2739 tries to remove the extra precision by spilling data from floating-point
2740 registers into memory and this typically involves a big performance
2741 hit. However, it doesn't affect intermediate results, so that it is
2742 only partially effective. `Excess precision' is avoided in code like:
2747 but not in code like:
2752 For another, potentially better, way of controlling the precision,
2753 see @ref{Floating-point precision}.
2755 @cindex -fforce-mem option
2756 @cindex options, -fforce-mem
2758 @cindex -fforce-addr option
2759 @cindex options, -fforce-addr
2761 @cindex loops, speeding up
2762 @cindex speed, of loops
2763 Might improve optimization of loops.
2765 @cindex -fno-inline option
2766 @cindex options, -fno-inline
2768 @cindex in-line code
2769 @cindex compilation, in-line
2770 @c DL: Only relevant for -O3?
2771 Don't compile statement functions inline.
2772 Might reduce the size of a program unit---which might be at
2773 expense of some speed (though it should compile faster).
2774 Note that if you are not optimizing, no functions can be expanded inline.
2776 @cindex -ffast-math option
2777 @cindex options, -ffast-math
2779 @cindex IEEE 754 conformance
2780 @cindex conformance, IEEE 754
2781 Might allow some programs designed to not be too dependent
2782 on IEEE behavior for floating-point to run faster, or die trying.
2783 Sets @samp{-funsafe-math-optimizations}, and
2784 @samp{-fno-trapping-math}.
2786 @cindex -funsafe-math-optimizations option
2787 @cindex options, -funsafe-math-optimizations
2788 @item -funsafe-math-optimizations
2789 Allow optimizations that may be give incorrect results
2790 for certain IEEE inputs.
2792 @cindex -fno-trapping-math option
2793 @cindex options, -fno-trapping-math
2794 @item -fno-trapping-math
2795 Allow the compiler to assume that floating-point arithmetic
2796 will not generate traps on any inputs. This is useful, for
2797 example, when running a program using IEEE "non-stop"
2798 floating-point arithmetic.
2800 @cindex -fstrength-reduce option
2801 @cindex options, -fstrength-reduce
2802 @item -fstrength-reduce
2803 @cindex loops, speeding up
2804 @cindex speed, of loops
2805 @c DL: normally defaulted?
2806 Might make some loops run faster.
2808 @cindex -frerun-cse-after-loop option
2809 @cindex options, -frerun-cse-after-loop
2810 @item -frerun-cse-after-loop
2811 @cindex -fexpensive-optimizations option
2812 @cindex options, -fexpensive-optimizations
2814 @item -fexpensive-optimizations
2815 @cindex -fdelayed-branch option
2816 @cindex options, -fdelayed-branch
2817 @item -fdelayed-branch
2818 @cindex -fschedule-insns option
2819 @cindex options, -fschedule-insns
2820 @item -fschedule-insns
2821 @cindex -fschedule-insns2 option
2822 @cindex options, -fschedule-insns2
2823 @item -fschedule-insns2
2824 @cindex -fcaller-saves option
2825 @cindex options, -fcaller-saves
2826 @item -fcaller-saves
2827 Might improve performance on some code.
2829 @cindex -funroll-loops option
2830 @cindex options, -funroll-loops
2831 @item -funroll-loops
2832 @cindex loops, unrolling
2833 @cindex unrolling loops
2834 @cindex loops, optimizing
2835 @cindex indexed (iterative) @code{DO}
2836 @cindex iterative @code{DO}
2837 @c DL: fixme: Craig doesn't like `indexed' but f95 doesn't seem to
2838 @c provide a suitable term
2839 @c CB: I've decided on `iterative', for the time being, and changed
2840 @c my previous, rather bizarre, use of `imperative' to that
2841 @c (though `precomputed-trip' would be a more precise adjective)
2842 Typically improves performance on code using iterative @code{DO} loops by
2843 unrolling them and is probably generally appropriate for Fortran, though
2844 it is not turned on at any optimization level.
2845 Note that outer loop unrolling isn't done specifically; decisions about
2846 whether to unroll a loop are made on the basis of its instruction count.
2848 @c DL: Fixme: This should obviously go somewhere else...
2849 Also, no `loop discovery'@footnote{@dfn{loop discovery} refers to the
2850 process by which a compiler, or indeed any reader of a program,
2851 determines which portions of the program are more likely to be executed
2852 repeatedly as it is being run. Such discovery typically is done early
2853 when compiling using optimization techniques, so the ``discovered''
2854 loops get more attention---and more run-time resources, such as
2855 registers---from the compiler. It is easy to ``discover'' loops that are
2856 constructed out of looping constructs in the language
2857 (such as Fortran's @code{DO}). For some programs, ``discovering'' loops
2858 constructed out of lower-level constructs (such as @code{IF} and
2859 @code{GOTO}) can lead to generation of more optimal code
2860 than otherwise.} is done, so only loops written with @code{DO}
2861 benefit from loop optimizations, including---but not limited
2862 to---unrolling. Loops written with @code{IF} and @code{GOTO} are not
2863 currently recognized as such. This option unrolls only iterative
2864 @code{DO} loops, not @code{DO WHILE} loops.
2866 @cindex -funroll-all-loops option
2867 @cindex options, -funroll-all-loops
2869 @item -funroll-all-loops
2870 @c DL: Check my understanding of -funroll-all-loops v. -funroll-loops is correct.
2871 Probably improves performance on code using @code{DO WHILE} loops by
2872 unrolling them in addition to iterative @code{DO} loops. In the absence
2873 of @code{DO WHILE}, this option is equivalent to @samp{-funroll-loops}
2874 but possibly slower.
2876 @item -fno-move-all-movables
2877 @cindex -fno-move-all-movables option
2878 @cindex options, -fno-move-all-movables
2879 @item -fno-reduce-all-givs
2880 @cindex -fno-reduce-all-givs option
2881 @cindex options, -fno-reduce-all-givs
2882 @item -fno-rerun-loop-opt
2883 @cindex -fno-rerun-loop-opt option
2884 @cindex options, -fno-rerun-loop-opt
2885 @emph{Version info:}
2886 These options are not supported by
2887 versions of @code{g77} based on @code{gcc} version 2.8.
2889 Each of these might improve performance on some code.
2891 Analysis of Fortran code optimization and the resulting
2892 optimizations triggered by the above options were
2893 contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).
2895 These three options are intended to be removed someday, once
2896 they have helped determine the efficacy of various
2897 approaches to improving the performance of Fortran code.
2899 Please let us know how use of these options affects
2900 the performance of your production code.
2901 We're particularly interested in code that runs faster
2902 when these options are @emph{disabled}, and in
2903 non-Fortran code that benefits when they are
2904 @emph{enabled} via the above @code{gcc} command-line options.
2907 @xref{Optimize Options,,Options That Control Optimization,
2908 gcc,Using and Porting GNU CC}, for more information on options
2909 to optimize the generated machine code.
2911 @node Preprocessor Options
2912 @section Options Controlling the Preprocessor
2913 @cindex preprocessor options
2914 @cindex options, preprocessor
2916 @cindex programs, cpp
2918 These options control the C preprocessor, which is run on each C source
2919 file before actual compilation.
2921 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
2922 gcc,Using and Porting GNU CC}, for information on C preprocessor options.
2924 @cindex INCLUDE directive
2925 @cindex directive, INCLUDE
2926 Some of these options also affect how @code{g77} processes the
2927 @code{INCLUDE} directive.
2928 Since this directive is processed even when preprocessing
2929 is not requested, it is not described in this section.
2930 @xref{Directory Options,,Options for Directory Search}, for
2931 information on how @code{g77} processes the @code{INCLUDE} directive.
2933 However, the @code{INCLUDE} directive does not apply
2934 preprocessing to the contents of the included file itself.
2936 Therefore, any file that contains preprocessor directives
2937 (such as @code{#include}, @code{#define}, and @code{#if})
2938 must be included via the @code{#include} directive, not
2939 via the @code{INCLUDE} directive.
2940 Therefore, any file containing preprocessor directives,
2941 if included, is necessarily included by a file that itself
2942 contains preprocessor directives.
2944 @node Directory Options
2945 @section Options for Directory Search
2946 @cindex directory, options
2947 @cindex options, directory search
2950 These options affect how the @code{cpp} preprocessor searches
2951 for files specified via the @code{#include} directive.
2952 Therefore, when compiling Fortran programs, they are meaningful
2953 when the preprocessor is used.
2955 @cindex INCLUDE directive
2956 @cindex directive, INCLUDE
2957 Some of these options also affect how @code{g77} searches
2958 for files specified via the @code{INCLUDE} directive,
2959 although files included by that directive are not,
2960 themselves, preprocessed.
2965 @cindex options, -I-
2967 @cindex -Idir option
2968 @cindex options, -Idir
2970 @cindex directory, search paths for inclusion
2971 @cindex inclusion, directory search paths for
2972 @cindex search paths, for included files
2973 @cindex paths, search
2974 These affect interpretation of the @code{INCLUDE} directive
2975 (as well as of the @code{#include} directive of the @code{cpp}
2978 Note that @samp{-I@var{dir}} must be specified @emph{without} any
2979 spaces between @samp{-I} and the directory name---that is,
2980 @samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
2981 is rejected by the @code{g77} compiler (though the preprocessor supports
2983 @c this is due to toplev.c's inflexible option processing
2984 Also note that the general behavior of @samp{-I} and
2985 @code{INCLUDE} is pretty much the same as of @samp{-I} with
2986 @code{#include} in the @code{cpp} preprocessor, with regard to
2987 looking for @file{header.gcc} files and other such things.
2989 @xref{Directory Options,,Options for Directory Search,
2990 gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
2993 @node Code Gen Options
2994 @section Options for Code Generation Conventions
2995 @cindex code generation, conventions
2996 @cindex options, code generation
2997 @cindex run-time, options
2999 These machine-independent options control the interface conventions
3000 used in code generation.
3002 Most of them have both positive and negative forms; the negative form
3003 of @samp{-ffoo} would be @samp{-fno-foo}. In the table below, only
3004 one of the forms is listed---the one which is not the default. You
3005 can figure out the other form by either removing @samp{no-} or adding
3009 @cindex -fno-automatic option
3010 @cindex options, -fno-automatic
3011 @item -fno-automatic
3012 @cindex SAVE statement
3013 @cindex statements, SAVE
3014 Treat each program unit as if the @code{SAVE} statement was specified
3015 for every local variable and array referenced in it.
3016 Does not affect common blocks.
3017 (Some Fortran compilers provide this option under
3018 the name @samp{-static}.)
3020 @cindex -finit-local-zero option
3021 @cindex options, -finit-local-zero
3022 @item -finit-local-zero
3023 @cindex DATA statement
3024 @cindex statements, DATA
3025 @cindex initialization, of local variables
3026 @cindex variables, initialization of
3027 @cindex uninitialized variables
3028 @cindex variables, uninitialized
3029 Specify that variables and arrays that are local to a program unit
3030 (not in a common block and not passed as an argument) are to be initialized
3033 Since there is a run-time penalty for initialization of variables
3034 that are not given the @code{SAVE} attribute, it might be a
3035 good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.
3037 @cindex -fno-f2c option
3038 @cindex options, -fno-f2c
3040 @cindex @code{f2c} compatibility
3041 @cindex compatibility, @code{f2c}
3042 Do not generate code designed to be compatible with code generated
3043 by @code{f2c}; use the GNU calling conventions instead.
3045 The @code{f2c} calling conventions require functions that return
3046 type @code{REAL(KIND=1)} to actually return the C type @code{double},
3047 and functions that return type @code{COMPLEX} to return the
3048 values via an extra argument in the calling sequence that points
3049 to where to store the return value.
3050 Under the GNU calling conventions, such functions simply return
3051 their results as they would in GNU C---@code{REAL(KIND=1)} functions
3052 return the C type @code{float}, and @code{COMPLEX} functions
3053 return the GNU C type @code{complex} (or its @code{struct}
3056 This does not affect the generation of code that interfaces with the
3057 @code{libg2c} library.
3059 However, because the @code{libg2c} library uses @code{f2c}
3060 calling conventions, @code{g77} rejects attempts to pass
3061 intrinsics implemented by routines in this library as actual
3062 arguments when @samp{-fno-f2c} is used, to avoid bugs when
3063 they are actually called by code expecting the GNU calling
3064 conventions to work.
3066 For example, @samp{INTRINSIC ABS;CALL FOO(ABS)} is
3067 rejected when @samp{-fno-f2c} is in force.
3068 (Future versions of the @code{g77} run-time library might
3069 offer routines that provide GNU-callable versions of the
3070 routines that implement the @code{f2c}-callable intrinsics
3071 that may be passed as actual arguments, so that
3072 valid programs need not be rejected when @samp{-fno-f2c}
3075 @strong{Caution:} If @samp{-fno-f2c} is used when compiling any
3076 source file used in a program, it must be used when compiling
3077 @emph{all} Fortran source files used in that program.
3079 @c seems kinda dumb to tell people about an option they can't use -- jcb
3080 @c then again, we want users building future-compatible libraries with it.
3081 @cindex -ff2c-library option
3082 @cindex options, -ff2c-library
3084 Specify that use of @code{libg2c} (or the original @code{libf2c})
3086 This is the default for the current version of @code{g77}.
3089 valid to specify @samp{-fno-f2c-library}.
3090 This option is provided so users can specify it in shell
3091 scripts that build programs and libraries that require the
3092 @code{libf2c} library, even when being compiled by future
3093 versions of @code{g77} that might otherwise default to
3094 generating code for an incompatible library.
3096 @cindex -fno-underscoring option
3097 @cindex options, -fno-underscoring
3098 @item -fno-underscoring
3100 @cindex symbol names, underscores
3101 @cindex transforming symbol names
3102 @cindex symbol names, transforming
3103 Do not transform names of entities specified in the Fortran
3104 source file by appending underscores to them.
3106 With @samp{-funderscoring} in effect, @code{g77} appends two underscores
3107 to names with underscores and one underscore to external names with
3108 no underscores. (@code{g77} also appends two underscores to internal
3109 names with underscores to avoid naming collisions with external names.
3110 The @samp{-fno-second-underscore} option disables appending of the
3111 second underscore in all cases.)
3113 This is done to ensure compatibility with code produced by many
3114 UNIX Fortran compilers, including @code{f2c}, which perform the
3115 same transformations.
3117 Use of @samp{-fno-underscoring} is not recommended unless you are
3118 experimenting with issues such as integration of (GNU) Fortran into
3119 existing system environments (vis-a-vis existing libraries, tools, and
3122 For example, with @samp{-funderscoring}, and assuming other defaults like
3123 @samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
3124 external functions while @samp{my_var} and @samp{lvar} are local variables,
3128 I = J() + MAX_COUNT (MY_VAR, LVAR)
3132 is implemented as something akin to:
3135 i = j_() + max_count__(&my_var__, &lvar);
3138 With @samp{-fno-underscoring}, the same statement is implemented as:
3141 i = j() + max_count(&my_var, &lvar);
3144 Use of @samp{-fno-underscoring} allows direct specification of
3145 user-defined names while debugging and when interfacing @code{g77}-compiled
3146 code with other languages.
3148 Note that just because the names match does @emph{not} mean that the
3149 interface implemented by @code{g77} for an external name matches the
3150 interface implemented by some other language for that same name.
3151 That is, getting code produced by @code{g77} to link to code produced
3152 by some other compiler using this or any other method can be only a
3153 small part of the overall solution---getting the code generated by
3154 both compilers to agree on issues other than naming can require
3155 significant effort, and, unlike naming disagreements, linkers normally
3156 cannot detect disagreements in these other areas.
3158 Also, note that with @samp{-fno-underscoring}, the lack of appended
3159 underscores introduces the very real possibility that a user-defined
3160 external name will conflict with a name in a system library, which
3161 could make finding unresolved-reference bugs quite difficult in some
3162 cases---they might occur at program run time, and show up only as
3163 buggy behavior at run time.
3165 In future versions of @code{g77}, we hope to improve naming and linking
3166 issues so that debugging always involves using the names as they appear
3167 in the source, even if the names as seen by the linker are mangled to
3168 prevent accidental linking between procedures with incompatible
3171 @cindex -fno-second-underscore option
3172 @cindex options, -fno-second-underscore
3173 @item -fno-second-underscore
3175 @cindex symbol names, underscores
3176 @cindex transforming symbol names
3177 @cindex symbol names, transforming
3178 Do not append a second underscore to names of entities specified
3179 in the Fortran source file.
3181 This option has no effect if @samp{-fno-underscoring} is
3184 Otherwise, with this option, an external name such as @samp{MAX_COUNT}
3185 is implemented as a reference to the link-time external symbol
3186 @samp{max_count_}, instead of @samp{max_count__}.
3188 @cindex -fno-ident option
3189 @cindex options, -fno-ident
3191 Ignore the @samp{#ident} directive.
3193 @cindex -fzeros option
3194 @cindex options, -fzeros
3196 Treat initial values of zero as if they were any other value.
3198 As of version 0.5.18, @code{g77} normally treats @code{DATA} and
3199 other statements that are used to specify initial values of zero
3200 for variables and arrays as if no values were actually specified,
3201 in the sense that no diagnostics regarding multiple initializations
3204 This is done to speed up compiling of programs that initialize
3205 large arrays to zeros.
3207 Use @samp{-fzeros} to revert to the simpler, slower behavior
3208 that can catch multiple initializations by keeping track of
3209 all initializations, zero or otherwise.
3211 @emph{Caution:} Future versions of @code{g77} might disregard this option
3212 (and its negative form, the default) or interpret it somewhat
3214 The interpretation changes will affect only non-standard
3215 programs; standard-conforming programs should not be affected.
3217 @cindex -fdebug-kludge option
3218 @cindex options, -fdebug-kludge
3219 @item -fdebug-kludge
3220 Emit information on @code{COMMON} and @code{EQUIVALENCE} members
3221 that might help users of debuggers work around lack of proper debugging
3222 information on such members.
3224 As of version 0.5.19, @code{g77} offers this option to emit
3225 information on members of aggregate areas to help users while debugging.
3226 This information consists of establishing the type and contents of each
3227 such member so that, when a debugger is asked to print the contents,
3228 the printed information provides rudimentary debugging information.
3229 This information identifies the name of the aggregate area (either the
3230 @code{COMMON} block name, or the @code{g77}-assigned name for the
3231 @code{EQUIVALENCE} name) and the offset, in bytes, of the member from
3232 the beginning of the area.
3234 Using @code{gdb}, this information is not coherently displayed in the Fortran
3235 language mode, so temporarily switching to the C language mode to display the
3236 information is suggested.
3237 Use @samp{set language c} and @samp{set language fortran} to accomplish this.
3239 As of version 0.5.26 of @code{g77} this option has been disabled, as the
3240 compiler is now able to emit correct and complete debug information
3241 for COMMON BLOCK and EQUIVALENCE items.
3249 EQUIVALENCE (I,XX(20:20))
3252 GDB is free software and you are welcome to distribute copies of it
3253 under certain conditions; type "show copying" to see the conditions.
3254 There is absolutely no warranty for GDB; type "show warranty" for details.
3255 GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
3257 Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
3259 Starting program: /home/user/a.out
3261 Breakpoint 1, MAIN__ () at cd.f:5
3262 Current language: auto; currently fortran
3263 (gdb) set language c
3264 Warning: the current language does not match this frame.
3266 $2 = "At (COMMON) `x_' plus 0 bytes"
3268 $3 = "At (COMMON) `x_' plus 4 bytes"
3270 $4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3272 $5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3274 $6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
3276 $7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
3277 (gdb) set language fortran
3282 Use @samp{-fdebug-kludge} to generate this information,
3283 which might make some programs noticeably larger.
3285 @emph{Caution:} Future versions of @code{g77} might disregard this option
3286 (and its negative form).
3287 Current plans call for this to happen when published versions of @code{g77}
3288 and @code{gdb} exist that provide proper access to debugging information on
3289 @code{COMMON} and @code{EQUIVALENCE} members. This is believed to have
3290 happened as of version 0.5.26 of @code{g77}, so that this option has been
3291 disabled starting with this release.
3293 @cindex -femulate-complex option
3294 @cindex options, -femulate-complex
3295 @item -femulate-complex
3296 Implement @code{COMPLEX} arithmetic via emulation,
3297 instead of using the facilities of
3298 the @code{gcc} back end that provide direct support of
3299 @code{complex} arithmetic.
3301 (@code{gcc} had some bugs in its back-end support
3302 for @code{complex} arithmetic, due primarily to the support not being
3303 completed as of version 2.8.1 and @code{egcs} 1.1.2.)
3305 Use @samp{-femulate-complex} if you suspect code-generation bugs,
3306 or experience compiler crashes,
3307 that might result from @code{g77} using the @code{COMPLEX} support
3308 in the @code{gcc} back end.
3309 If using that option fixes the bugs or crashes you are seeing,
3310 that indicates a likely @code{g77} bugs
3311 (though, all compiler crashes are considered bugs),
3312 so, please report it.
3313 (Note that the known bugs, now believed fixed, produced compiler crashes
3314 rather than causing the generation of incorrect code.)
3316 Use of this option should not affect how Fortran code compiled
3317 by @code{g77} works in terms of its interfaces to other code,
3318 e.g. that compiled by @code{f2c}.
3320 @emph{Caution:} Future versions of @code{g77} might ignore both forms
3323 @cindex -falias-check option
3324 @cindex options, -falias-check
3325 @cindex -fargument-alias option
3326 @cindex options, -fargument-alias
3327 @cindex -fargument-noalias option
3328 @cindex options, -fargument-noalias
3329 @cindex -fno-argument-noalias-global option
3330 @cindex options, -fno-argument-noalias-global
3332 @item -fargument-alias
3333 @item -fargument-noalias
3334 @item -fno-argument-noalias-global
3335 @emph{Version info:}
3336 These options are not supported by
3337 versions of @code{g77} based on @code{gcc} version 2.8.
3339 These options specify to what degree aliasing
3341 is permitted between
3342 arguments (passed as pointers) and @code{COMMON} (external, or
3345 The default for Fortran code, as mandated by the FORTRAN 77 and
3346 Fortran 90 standards, is @samp{-fargument-noalias-global}.
3347 The default for code written in the C language family is
3348 @samp{-fargument-alias}.
3350 Note that, on some systems, compiling with @samp{-fforce-addr} in
3351 effect can produce more optimal code when the default aliasing
3352 options are in effect (and when optimization is enabled).
3354 @xref{Aliasing Assumed To Work}, for detailed information on the implications
3355 of compiling Fortran code that depends on the ability to alias dummy
3358 @cindex -fno-globals option
3359 @cindex options, -fno-globals
3361 @cindex global names, warning
3362 @cindex warnings, global names
3363 @cindex in-line code
3364 @cindex compilation, in-line
3365 Disable diagnostics about inter-procedural
3366 analysis problems, such as disagreements about the
3367 type of a function or a procedure's argument,
3368 that might cause a compiler crash when attempting
3369 to inline a reference to a procedure within a
3371 (The diagnostics themselves are still produced, but
3372 as warnings, unless @samp{-Wno-globals} is specified,
3373 in which case no relevant diagnostics are produced.)
3375 Further, this option disables such inlining, to
3376 avoid compiler crashes resulting from incorrect
3377 code that would otherwise be diagnosed.
3379 As such, this option might be quite useful when
3380 compiling existing, ``working'' code that happens
3381 to have a few bugs that do not generally show themselves,
3382 but which @code{g77} diagnoses.
3384 Use of this option therefore has the effect of
3385 instructing @code{g77} to behave more like it did
3386 up through version 0.5.19.1, when it paid little or
3387 no attention to disagreements between program units
3388 about a procedure's type and argument information,
3389 and when it performed no inlining of procedures
3390 (except statement functions).
3392 Without this option, @code{g77} defaults to performing
3393 the potentially inlining procedures as it started doing
3394 in version 0.5.20, but as of version 0.5.21, it also
3395 diagnoses disagreements that might cause such inlining
3396 to crash the compiler as (fatal) errors,
3397 and warns about similar disagreements
3398 that are currently believed to not
3399 likely to result in the compiler later crashing
3400 or producing incorrect code.
3402 @cindex -fflatten-arrays option
3403 @item -fflatten-arrays
3404 @cindex array performance
3405 @cindex arrays, flattening
3406 Use back end's C-like constructs
3407 (pointer plus offset)
3408 instead of its @code{ARRAY_REF} construct
3409 to handle all array references.
3411 @emph{Note:} This option is not supported.
3412 It is intended for use only by @code{g77} developers,
3413 to evaluate code-generation issues.
3414 It might be removed at any time.
3416 @cindex -fbounds-check option
3417 @cindex -ffortran-bounds-check option
3418 @item -fbounds-check
3419 @itemx -ffortran-bounds-check
3420 @cindex bounds checking
3421 @cindex range checking
3422 @cindex array bounds checking
3423 @cindex subscript checking
3424 @cindex substring checking
3425 @cindex checking subscripts
3426 @cindex checking substrings
3427 Enable generation of run-time checks for array subscripts
3428 and substring start and end points
3429 against the (locally) declared minimum and maximum values.
3431 The current implementation uses the @code{libf2c}
3432 library routine @code{s_rnge} to print the diagnostic.
3434 However, whereas @code{f2c} generates a single check per
3435 reference for a multi-dimensional array, of the computed
3436 offset against the valid offset range (0 through the size of the array),
3437 @code{g77} generates a single check per @emph{subscript} expression.
3438 This catches some cases of potential bugs that @code{f2c} does not,
3439 such as references to below the beginning of an assumed-size array.
3441 @code{g77} also generates checks for @code{CHARACTER} substring references,
3442 something @code{f2c} currently does not do.
3444 Use the new @samp{-ffortran-bounds-check} option
3445 to specify bounds-checking for only the Fortran code you are compiling,
3446 not necessarily for code written in other languages.
3448 @emph{Note:} To provide more detailed information on the offending subscript,
3449 @code{g77} provides the @code{libg2c} run-time library routine @code{s_rnge}
3450 with somewhat differently-formatted information.
3451 Here's a sample diagnostic:
3454 Subscript out of range on file line 4, procedure rnge.f/bf.
3455 Attempt to access the -6-th element of variable b[subscript-2-of-2].
3459 The above message indicates that the offending source line is
3460 line 4 of the file @file{rnge.f},
3461 within the program unit (or statement function) named @samp{bf}.
3462 The offended array is named @samp{b}.
3463 The offended array dimension is the second for a two-dimensional array,
3464 and the offending, computed subscript expression was @samp{-6}.
3466 For a @code{CHARACTER} substring reference, the second line has
3470 Attempt to access the 11-th element of variable a[start-substring].
3473 This indicates that the offended @code{CHARACTER} variable or array
3475 the offended substring position is the starting (leftmost) position,
3476 and the offending substring expression is @samp{11}.
3478 (Though the verbage of @code{s_rnge} is not ideal
3479 for the purpose of the @code{g77} compiler,
3480 the above information should provide adequate diagnostic abilities
3484 @xref{Code Gen Options,,Options for Code Generation Conventions,
3485 gcc,Using and Porting GNU CC}, for information on more options
3487 shared by @code{g77}, @code{gcc}, and other GNU compilers.
3489 Some of these do @emph{not} work when compiling programs written in Fortran:
3492 @cindex -fpcc-struct-return option
3493 @cindex options, -fpcc-struct-return
3494 @item -fpcc-struct-return
3495 @cindex -freg-struct-return option
3496 @cindex options, -freg-struct-return
3497 @item -freg-struct-return
3498 You should not use these except strictly the same way as you
3499 used them to build the version of @code{libg2c} with which
3500 you will be linking all code compiled by @code{g77} with the
3503 @cindex -fshort-double option
3504 @cindex options, -fshort-double
3505 @item -fshort-double
3506 This probably either has no effect on Fortran programs, or
3507 makes them act loopy.
3509 @cindex -fno-common option
3510 @cindex options, -fno-common
3512 Do not use this when compiling Fortran programs,
3513 or there will be Trouble.
3515 @cindex -fpack-struct option
3516 @cindex options, -fpack-struct
3518 This probably will break any calls to the @code{libg2c} library,
3519 at the very least, even if it is built with the same option.
3522 @node Environment Variables
3523 @section Environment Variables Affecting GNU Fortran
3524 @cindex environment variables
3526 GNU Fortran currently does not make use of any environment
3527 variables to control its operation above and beyond those
3528 that affect the operation of @code{gcc}.
3530 @xref{Environment Variables,,Environment Variables Affecting GNU CC,
3531 gcc,Using and Porting GNU CC}, for information on environment
3541 @chapter The GNU Fortran Language
3543 @cindex standard, ANSI FORTRAN 77
3544 @cindex ANSI FORTRAN 77 standard
3545 @cindex reference works
3546 GNU Fortran supports a variety of extensions to, and dialects
3547 of, the Fortran language.
3548 Its primary base is the ANSI FORTRAN 77 standard, currently available on
3550 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
3551 or as monolithic text at
3552 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
3553 It offers some extensions that are popular among users
3554 of UNIX @code{f77} and @code{f2c} compilers, some that
3555 are popular among users of other compilers (such as Digital
3556 products), some that are popular among users of the
3557 newer Fortran 90 standard, and some that are introduced
3561 (If you need a text on Fortran,
3562 a few freely available electronic references have pointers from
3563 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
3564 net project', @cite{User Notes on Fortran Programming} at
3565 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
3566 material might not apply specifically to @code{g77}.)
3568 Part of what defines a particular implementation of a Fortran
3569 system, such as @code{g77}, is the particular characteristics
3570 of how it supports types, constants, and so on.
3571 Much of this is left up to the implementation by the various
3572 Fortran standards and accepted practice in the industry.
3574 The GNU Fortran @emph{language} is described below.
3575 Much of the material is organized along the same lines
3576 as the ANSI FORTRAN 77 standard itself.
3578 @xref{Other Dialects}, for information on features @code{g77} supports
3579 that are not part of the GNU Fortran language.
3581 @emph{Note}: This portion of the documentation definitely needs a lot
3585 Relationship to the ANSI FORTRAN 77 standard:
3586 * Direction of Language Development:: Where GNU Fortran is headed.
3587 * Standard Support:: Degree of support for the standard.
3589 Extensions to the ANSI FORTRAN 77 standard:
3592 * Terms and Concepts::
3593 * Characters Lines Sequence::
3594 * Data Types and Constants::
3596 * Specification Statements::
3597 * Control Statements::
3598 * Functions and Subroutines::
3599 * Scope and Classes of Names::
3601 * Fortran 90 Features::
3604 @node Direction of Language Development
3605 @section Direction of Language Development
3606 @cindex direction of language development
3607 @cindex features, language
3608 @cindex language, features
3610 The purpose of the following description of the GNU Fortran
3611 language is to promote wide portability of GNU Fortran programs.
3613 GNU Fortran is an evolving language, due to the
3614 fact that @code{g77} itself is in beta test.
3615 Some current features of the language might later
3616 be redefined as dialects of Fortran supported by @code{g77}
3617 when better ways to express these features are added to @code{g77},
3619 Such features would still be supported by
3620 @code{g77}, but would be available only when
3621 one or more command-line options were used.
3623 The GNU Fortran @emph{language} is distinct from the
3624 GNU Fortran @emph{compilation system} (@code{g77}).
3626 For example, @code{g77} supports various dialects of
3627 Fortran---in a sense, these are languages other than
3628 GNU Fortran---though its primary
3629 purpose is to support the GNU Fortran language, which also is
3630 described in its documentation and by its implementation.
3632 On the other hand, non-GNU compilers might offer
3633 support for the GNU Fortran language, and are encouraged
3636 Currently, the GNU Fortran language is a fairly fuzzy object.
3637 It represents something of a cross between what @code{g77} accepts
3638 when compiling using the prevailing defaults and what this
3639 document describes as being part of the language.
3641 Future versions of @code{g77} are expected to clarify the
3642 definition of the language in the documentation.
3643 Often, this will mean adding new features to the language, in the form
3644 of both new documentation and new support in @code{g77}.
3645 However, it might occasionally mean removing a feature
3646 from the language itself to ``dialect'' status.
3647 In such a case, the documentation would be adjusted
3648 to reflect the change, and @code{g77} itself would likely be changed
3649 to require one or more command-line options to continue supporting
3652 The development of the GNU Fortran language is intended to strike
3657 Serving as a mostly-upwards-compatible language from the
3658 de facto UNIX Fortran dialect as supported by @code{f77}.
3661 Offering new, well-designed language features.
3662 Attributes of such features include
3663 not making existing code any harder to read
3664 (for those who might be unaware that the new
3665 features are not in use) and
3666 not making state-of-the-art
3667 compilers take longer to issue diagnostics,
3671 Supporting existing, well-written code without gratuitously
3672 rejecting non-standard constructs, regardless of the origin
3673 of the code (its dialect).
3676 Offering default behavior and command-line options to reduce
3677 and, where reasonable, eliminate the need for programmers to make
3678 any modifications to code that already works in existing
3679 production environments.
3682 Diagnosing constructs that have different meanings in different
3683 systems, languages, and dialects, while offering clear,
3684 less ambiguous ways to express each of the different meanings
3685 so programmers can change their code appropriately.
3688 One of the biggest practical challenges for the developers of the
3689 GNU Fortran language is meeting the sometimes contradictory demands
3692 For example, a feature might be widely used in one popular environment,
3693 but the exact same code that utilizes that feature might not work
3694 as expected---perhaps it might mean something entirely different---in
3695 another popular environment.
3697 Traditionally, Fortran compilers---even portable ones---have solved this
3698 problem by simply offering the appropriate feature to users of
3699 the respective systems.
3700 This approach treats users of various Fortran systems and dialects
3701 as remote ``islands'', or camps, of programmers, and assume that these
3702 camps rarely come into contact with each other (or,
3703 especially, with each other's code).
3705 Project GNU takes a radically different approach to software and language
3706 design, in that it assumes that users of GNU software do not necessarily
3707 care what kind of underlying system they are using, regardless
3708 of whether they are using software (at the user-interface
3709 level) or writing it (for example, writing Fortran or C code).
3711 As such, GNU users rarely need consider just what kind of underlying
3712 hardware (or, in many cases, operating system) they are using at any
3714 They can use and write software designed for a general-purpose,
3715 widely portable, heterogenous environment---the GNU environment.
3717 In line with this philosophy, GNU Fortran must evolve into a product
3718 that is widely ported and portable not only in the sense that it can
3719 be successfully built, installed, and run by users, but in the larger
3720 sense that its users can use it in the same way, and expect largely the
3721 same behaviors from it, regardless of the kind of system they are using
3722 at any particular time.
3724 This approach constrains the solutions @code{g77} can use to resolve
3725 conflicts between various camps of Fortran users.
3726 If these two camps disagree about what a particular construct should
3727 mean, @code{g77} cannot simply be changed to treat that particular construct as
3728 having one meaning without comment (such as a warning), lest the users
3729 expecting it to have the other meaning are unpleasantly surprised that
3730 their code misbehaves when executed.
3732 The use of the ASCII backslash character in character constants is
3733 an excellent (and still somewhat unresolved) example of this kind of
3735 @xref{Backslash in Constants}.
3736 Other examples are likely to arise in the future, as @code{g77} developers
3737 strive to improve its ability to accept an ever-wider variety of existing
3738 Fortran code without requiring significant modifications to said code.
3740 Development of GNU Fortran is further constrained by the desire
3741 to avoid requiring programmers to change their code.
3742 This is important because it allows programmers, administrators,
3743 and others to more faithfully evaluate and validate @code{g77}
3744 (as an overall product and as new versions are distributed)
3745 without having to support multiple versions of their programs
3746 so that they continue to work the same way on their existing
3747 systems (non-GNU perhaps, but possibly also earlier versions
3750 @node Standard Support
3751 @section ANSI FORTRAN 77 Standard Support
3752 @cindex ANSI FORTRAN 77 support
3753 @cindex standard, support for
3754 @cindex support, FORTRAN 77
3755 @cindex compatibility, FORTRAN 77
3756 @cindex FORTRAN 77 compatibility
3758 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
3759 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
3760 support are those that are probably rarely used in actual code,
3761 some of which are explicitly disallowed by the Fortran 90 standard.
3764 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
3765 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
3766 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
3767 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
3770 @node No Passing External Assumed-length
3771 @subsection No Passing External Assumed-length
3773 @code{g77} disallows passing of an external procedure
3774 as an actual argument if the procedure's
3775 type is declared @code{CHARACTER*(*)}. For example:
3785 It isn't clear whether the standard considers this conforming.
3787 @node No Passing Dummy Assumed-length
3788 @subsection No Passing Dummy Assumed-length
3790 @code{g77} disallows passing of a dummy procedure
3791 as an actual argument if the procedure's
3792 type is declared @code{CHARACTER*(*)}.
3795 SUBROUTINE BAR(CFUNC)
3803 It isn't clear whether the standard considers this conforming.
3805 @node No Pathological Implied-DO
3806 @subsection No Pathological Implied-DO
3808 The @code{DO} variable for an implied-@code{DO} construct in a
3809 @code{DATA} statement may not be used as the @code{DO} variable
3810 for an outer implied-@code{DO} construct. For example, this
3811 fragment is disallowed by @code{g77}:
3814 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
3818 This also is disallowed by Fortran 90, as it offers no additional
3819 capabilities and would have a variety of possible meanings.
3821 Note that it is @emph{very} unlikely that any production Fortran code
3822 tries to use this unsupported construct.
3824 @node No Useless Implied-DO
3825 @subsection No Useless Implied-DO
3827 An array element initializer in an implied-@code{DO} construct in a
3828 @code{DATA} statement must contain at least one reference to the @code{DO}
3829 variables of each outer implied-@code{DO} construct. For example,
3830 this fragment is disallowed by @code{g77}:
3833 DATA (A, I= 1, 1) /1./
3837 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
3838 requirements offer no additional capabilities.
3839 However, @code{g77} doesn't necessarily diagnose all cases
3840 where this requirement is not met.
3842 Note that it is @emph{very} unlikely that any production Fortran code
3843 tries to use this unsupported construct.
3846 @section Conformance
3848 (The following information augments or overrides the information in
3849 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3851 Chapter 1 of that document otherwise serves as the basis
3852 for the relevant aspects of GNU Fortran.)
3854 The definition of the GNU Fortran language is akin to that of
3855 the ANSI FORTRAN 77 language in that it does not generally require
3856 conforming implementations to diagnose cases where programs do
3857 not conform to the language.
3859 However, @code{g77} as a compiler is being developed in a way that
3860 is intended to enable it to diagnose such cases in an easy-to-understand
3863 A program that conforms to the GNU Fortran language should, when
3864 compiled, linked, and executed using a properly installed @code{g77}
3865 system, perform as described by the GNU Fortran language definition.
3866 Reasons for different behavior include, among others:
3870 Use of resources (memory---heap, stack, and so on; disk space; CPU
3871 time; etc.) exceeds those of the system.
3874 Range and/or precision of calculations required by the program
3875 exceeds that of the system.
3878 Excessive reliance on behaviors that are system-dependent
3879 (non-portable Fortran code).
3882 Bugs in the program.
3891 Despite these ``loopholes'', the availability of a clear specification
3892 of the language of programs submitted to @code{g77}, as this document
3893 is intended to provide, is considered an important aspect of providing
3894 a robust, clean, predictable Fortran implementation.
3896 The definition of the GNU Fortran language, while having no special
3897 legal status, can therefore be viewed as a sort of contract, or agreement.
3898 This agreement says, in essence, ``if you write a program in this language,
3899 and run it in an environment (such as a @code{g77} system) that supports
3900 this language, the program should behave in a largely predictable way''.
3903 @section Notation Used in This Chapter
3905 (The following information augments or overrides the information in
3906 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3908 Chapter 1 of that document otherwise serves as the basis
3909 for the relevant aspects of GNU Fortran.)
3911 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
3912 and ``must not'' and ``may not'' denote prohibition.
3913 Terms such as ``might'', ``should'', and ``can'' generally add little or
3914 nothing in the way of weight to the GNU Fortran language itself,
3915 but are used to explain or illustrate the language.
3920 ``The @code{FROBNITZ} statement must precede all executable
3921 statements in a program unit, and may not specify any dummy
3922 arguments. It may specify local or common variables and arrays.
3923 Its use should be limited to portions of the program designed to
3924 be non-portable and system-specific, because it might cause the
3925 containing program unit to behave quite differently on different
3929 Insofar as the GNU Fortran language is specified,
3930 the requirements and permissions denoted by the above sample statement
3931 are limited to the placement of the statement and the kinds of
3932 things it may specify.
3933 The rest of the statement---the content regarding non-portable portions
3934 of the program and the differing behavior of program units containing
3935 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
3937 That content offers advice and warnings about the @code{FROBNITZ}
3940 @emph{Remember:} The GNU Fortran language definition specifies
3941 both what constitutes a valid GNU Fortran program and how,
3942 given such a program, a valid GNU Fortran implementation is
3943 to interpret that program.
3945 It is @emph{not} incumbent upon a valid GNU Fortran implementation
3946 to behave in any particular way, any consistent way, or any
3947 predictable way when it is asked to interpret input that is
3948 @emph{not} a valid GNU Fortran program.
3950 Such input is said to have @dfn{undefined} behavior when
3951 interpreted by a valid GNU Fortran implementation, though
3952 an implementation may choose to specify behaviors for some
3953 cases of inputs that are not valid GNU Fortran programs.
3955 Other notation used herein is that of the GNU texinfo format,
3956 which is used to generate printed hardcopy, on-line hypertext
3957 (Info), and on-line HTML versions, all from a single source
3959 This notation is used as follows:
3963 Keywords defined by the GNU Fortran language are shown
3964 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
3967 Note that, in practice, many Fortran programs are written
3968 in lowercase---uppercase is used in this manual as a
3969 means to readily distinguish keywords and sample Fortran-related
3970 text from the prose in this document.
3973 Portions of actual sample program, input, or output text
3974 look like this: @samp{Actual program text}.
3976 Generally, uppercase is used for all Fortran-specific and
3977 Fortran-related text, though this does not always include
3978 literal text within Fortran code.
3980 For example: @samp{PRINT *, 'My name is Bob'}.
3983 A metasyntactic variable---that is, a name used in this document
3984 to serve as a placeholder for whatever text is used by the
3985 user or programmer---appears as shown in the following example:
3987 ``The @code{INTEGER @var{ivar}} statement specifies that
3988 @var{ivar} is a variable or array of type @code{INTEGER}.''
3990 In the above example, any valid text may be substituted for
3991 the metasyntactic variable @var{ivar} to make the statement
3992 apply to a specific instance, as long as the same text is
3993 substituted for @emph{both} occurrences of @var{ivar}.
3996 Ellipses (``@dots{}'') are used to indicate further text that
3997 is either unimportant or expanded upon further, elsewhere.
4000 Names of data types are in the style of Fortran 90, in most
4003 @xref{Kind Notation}, for information on the relationship
4004 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
4005 and the more traditional, less portably concise nomenclature
4006 (such as @code{INTEGER*4}).
4009 @node Terms and Concepts
4010 @section Fortran Terms and Concepts
4012 (The following information augments or overrides the information in
4013 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4015 Chapter 2 of that document otherwise serves as the basis
4016 for the relevant aspects of GNU Fortran.)
4020 * Statements Comments Lines::
4021 * Scope of Names and Labels::
4024 @node Syntactic Items
4025 @subsection Syntactic Items
4027 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
4029 @cindex limits, lengths of names
4030 In GNU Fortran, a symbolic name is at least one character long,
4031 and has no arbitrary upper limit on length.
4032 However, names of entities requiring external linkage (such as
4033 external functions, external subroutines, and @code{COMMON} areas)
4034 might be restricted to some arbitrary length by the system.
4035 Such a restriction is no more constrained than that of one
4036 through six characters.
4038 Underscores (@samp{_}) are accepted in symbol names after the first
4039 character (which must be a letter).
4041 @node Statements Comments Lines
4042 @subsection Statements, Comments, and Lines
4044 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
4046 @cindex trailing comment
4048 @cindex characters, comment
4050 @cindex exclamation point
4051 @cindex continuation character
4052 @cindex characters, continuation
4053 Use of an exclamation point (@samp{!}) to begin a
4054 trailing comment (a comment that extends to the end of the same
4055 source line) is permitted under the following conditions:
4059 The exclamation point does not appear in column 6.
4060 Otherwise, it is treated as an indicator of a continuation
4064 The exclamation point appears outside a character or Hollerith
4066 Otherwise, the exclamation point is considered part of the
4070 The exclamation point appears to the left of any other possible
4072 That is, a trailing comment may contain exclamation points
4073 in their commentary text.
4078 @cindex statements, separated by semicolon
4079 Use of a semicolon (@samp{;}) as a statement separator
4080 is permitted under the following conditions:
4084 The semicolon appears outside a character or Hollerith
4086 Otherwise, the semicolon is considered part of the
4090 The semicolon appears to the left of a trailing comment.
4091 Otherwise, the semicolon is considered part of that
4095 Neither a logical @code{IF} statement nor a non-construct
4096 @code{WHERE} statement (a Fortran 90 feature) may be
4097 followed (in the same, possibly continued, line) by
4098 a semicolon used as a statement separator.
4100 This restriction avoids the confusion
4101 that can result when reading a line such as:
4104 IF (VALIDP) CALL FOO; CALL BAR
4108 Some readers might think the @samp{CALL BAR} is executed
4109 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4110 assume its execution is unconditional.
4112 (At present, @code{g77} does not diagnose code that
4113 violates this restriction.)
4116 @node Scope of Names and Labels
4117 @subsection Scope of Symbolic Names and Statement Labels
4120 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4122 Included in the list of entities that have a scope of a
4123 program unit are construct names (a Fortran 90 feature).
4124 @xref{Construct Names}, for more information.
4126 @node Characters Lines Sequence
4127 @section Characters, Lines, and Execution Sequence
4129 (The following information augments or overrides the information in
4130 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4132 Chapter 3 of that document otherwise serves as the basis
4133 for the relevant aspects of GNU Fortran.)
4138 * Continuation Line::
4140 * Statement Labels::
4143 * Cpp-style directives::
4147 @subsection GNU Fortran Character Set
4150 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4152 Letters include uppercase letters (the twenty-six characters
4153 of the English alphabet) and lowercase letters (their lowercase
4155 Generally, lowercase letters may be used in place of uppercase
4156 letters, though in character and Hollerith constants, they
4159 Special characters include:
4165 Semicolon (@samp{;})
4169 @cindex exclamation point
4170 Exclamation point (@samp{!})
4174 @cindex double quote
4175 Double quote (@samp{"})
4180 Backslash (@samp{\})
4184 @cindex question mark
4185 Question mark (@samp{?})
4191 Hash mark (@samp{#})
4196 Ampersand (@samp{&})
4200 @cindex percent sign
4201 Percent sign (@samp{%})
4206 Underscore (@samp{_})
4212 @cindex open bracket
4213 @cindex left bracket
4214 Open angle (@samp{<})
4220 @cindex close bracket
4221 @cindex right bracket
4222 Close angle (@samp{>})
4225 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4226 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4227 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4234 Note that this document refers to @key{SPC} as @dfn{space},
4235 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4240 @cindex source file format
4241 @cindex source format
4242 @cindex file, source
4244 @cindex code, source
4248 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4250 The way a Fortran compiler views source files depends entirely on the
4251 implementation choices made for the compiler, since those choices
4252 are explicitly left to the implementation by the published Fortran
4255 The GNU Fortran language mandates a view applicable to UNIX-like
4256 text files---files that are made up of an arbitrary number of lines,
4257 each with an arbitrary number of characters (sometimes called stream-based
4260 This view does not apply to types of files that are specified as
4261 having a particular number of characters on every single line (sometimes
4262 referred to as record-based files).
4264 Because a ``line in a program unit is a sequence of 72 characters'',
4265 to quote X3.9-1978, the GNU Fortran language specifies that a
4266 stream-based text file is translated to GNU Fortran lines as follows:
4270 A newline in the file is the character that represents the end of
4271 a line of text to the underlying system.
4272 For example, on ASCII-based systems, a newline is the @key{NL}
4273 character, which has ASCII value 10 (decimal).
4276 Each newline in the file serves to end the line of text that precedes
4277 it (and that does not contain a newline).
4280 The end-of-file marker (@code{EOF}) also serves to end the line
4281 of text that precedes it (and that does not contain a newline).
4287 Any line of text that is shorter than 72 characters is padded to that length
4288 with spaces (called ``blanks'' in the standard).
4291 Any line of text that is longer than 72 characters is truncated to that
4292 length, but the truncated remainder must consist entirely of spaces.
4295 Characters other than newline and the GNU Fortran character set
4299 For the purposes of the remainder of this description of the GNU
4300 Fortran language, the translation described above has already
4301 taken place, unless otherwise specified.
4303 The result of the above translation is that the source file appears,
4304 in terms of the remainder of this description of the GNU Fortran language,
4305 as if it had an arbitrary
4306 number of 72-character lines, each character being among the GNU Fortran
4309 For example, if the source file itself has two newlines in a row,
4310 the second newline becomes, after the above translation, a single
4311 line containing 72 spaces.
4313 @node Continuation Line
4314 @subsection Continuation Line
4315 @cindex continuation line, number of
4316 @cindex lines, continuation
4317 @cindex number of continuation lines
4318 @cindex limits, continuation lines
4320 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4322 A continuation line is any line that both
4326 Contains a continuation character, and
4329 Contains only spaces in columns 1 through 5
4332 A continuation character is any character of the GNU Fortran character set
4333 other than space (@key{SPC}) or zero (@samp{0})
4334 in column 6, or a digit (@samp{0} through @samp{9}) in column
4335 7 through 72 of a line that has only spaces to the left of that
4338 The continuation character is ignored as far as the content of
4339 the statement is concerned.
4341 The GNU Fortran language places no limit on the number of
4342 continuation lines in a statement.
4343 In practice, the limit depends on a variety of factors, such as
4344 available memory, statement content, and so on, but no
4345 GNU Fortran system may impose an arbitrary limit.
4348 @subsection Statements
4350 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4352 Statements may be written using an arbitrary number of continuation
4355 Statements may be separated using the semicolon (@samp{;}), except
4356 that the logical @code{IF} and non-construct @code{WHERE} statements
4357 may not be separated from subsequent statements using only a semicolon
4358 as statement separator.
4360 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4361 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4363 These alternatives may be written as normal statements---they are not
4364 subject to the restrictions of the @code{END} statement.
4366 However, no statement other than @code{END} may have an initial line
4367 that appears to be an @code{END} statement---even @code{END PROGRAM},
4368 for example, must not be written as:
4375 @node Statement Labels
4376 @subsection Statement Labels
4378 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4380 A statement separated from its predecessor via a semicolon may be
4385 The semicolon is followed by the label for the statement,
4386 which in turn follows the label.
4389 The label must be no more than five digits in length.
4392 The first digit of the label for the statement is not
4393 the first non-space character on a line.
4394 Otherwise, that character is treated as a continuation
4398 A statement may have only one label defined for it.
4401 @subsection Order of Statements and Lines
4403 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4405 Generally, @code{DATA} statements may precede executable statements.
4406 However, specification statements pertaining to any entities
4407 initialized by a @code{DATA} statement must precede that @code{DATA}
4410 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4411 @samp{INTEGER J} is permitted.
4413 The last line of a program unit may be an @code{END} statement,
4418 An @code{END PROGRAM} statement, if the program unit is a main program.
4421 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4424 An @code{END FUNCTION} statement, if the program unit is a function.
4427 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4431 @subsection Including Source Text
4432 @cindex INCLUDE directive
4434 Additional source text may be included in the processing of
4435 the source file via the @code{INCLUDE} directive:
4438 INCLUDE @var{filename}
4442 The source text to be included is identified by @var{filename},
4443 which is a literal GNU Fortran character constant.
4444 The meaning and interpretation of @var{filename} depends on the
4445 implementation, but typically is a filename.
4447 (@code{g77} treats it as a filename that it searches for
4448 in the current directory and/or directories specified
4449 via the @samp{-I} command-line option.)
4451 The effect of the @code{INCLUDE} directive is as if the
4452 included text directly replaced the directive in the source
4453 file prior to interpretation of the program.
4454 Included text may itself use @code{INCLUDE}.
4455 The depth of nested @code{INCLUDE} references depends on
4456 the implementation, but typically is a positive integer.
4458 This virtual replacement treats the statements and @code{INCLUDE}
4459 directives in the included text as syntactically distinct from
4460 those in the including text.
4462 Therefore, the first non-comment line of the included text
4463 must not be a continuation line.
4464 The included text must therefore have, after the non-comment
4465 lines, either an initial line (statement), an @code{INCLUDE}
4466 directive, or nothing (the end of the included text).
4468 Similarly, the including text may end the @code{INCLUDE}
4469 directive with a semicolon or the end of the line, but it
4470 cannot follow an @code{INCLUDE} directive at the end of its
4471 line with a continuation line.
4472 Thus, the last statement in an included text may not be
4475 Any statements between two @code{INCLUDE} directives on the
4476 same line are treated as if they appeared in between the
4477 respective included texts.
4481 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4485 If the text included by @samp{INCLUDE 'A'} constitutes
4486 a @samp{PRINT *, 'A'} statement and the text included by
4487 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4488 then the output of the above sample program would be
4497 (with suitable allowances for how an implementation defines
4498 its handling of output).
4500 Included text must not include itself directly or indirectly,
4501 regardless of whether the @var{filename} used to reference
4502 the text is the same.
4504 Note that @code{INCLUDE} is @emph{not} a statement.
4505 As such, it is neither a non-executable or executable
4507 However, if the text it includes constitutes one or more
4508 executable statements, then the placement of @code{INCLUDE}
4509 is subject to effectively the same restrictions as those
4510 on executable statements.
4512 An @code{INCLUDE} directive may be continued across multiple
4513 lines as if it were a statement.
4514 This permits long names to be used for @var{filename}.
4516 @node Cpp-style directives
4517 @subsection Cpp-style directives
4519 @cindex preprocessor
4521 @code{cpp} output-style @code{#} directives
4522 (@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
4523 are recognized by the compiler even
4524 when the preprocessor isn't run on the input (as it is when compiling
4525 @samp{.F} files). (Note the distinction between these @code{cpp}
4526 @code{#} @emph{output} directives and @code{#line} @emph{input}
4529 @node Data Types and Constants
4530 @section Data Types and Constants
4532 (The following information augments or overrides the information in
4533 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4535 Chapter 4 of that document otherwise serves as the basis
4536 for the relevant aspects of GNU Fortran.)
4538 To more concisely express the appropriate types for
4539 entities, this document uses the more concise
4540 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
4541 instead of the more traditional, but less portably concise,
4542 byte-size-based nomenclature such as @code{INTEGER*4},
4543 wherever reasonable.
4545 When referring to generic types---in contexts where the
4546 specific precision and range of a type are not important---this
4547 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
4548 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
4550 In some cases, the context requires specification of a
4552 This document uses the @samp{KIND=} notation to accomplish
4553 this throughout, sometimes supplying the more traditional
4554 notation for clarification, though the traditional notation
4555 might not work the same way on all GNU Fortran implementations.
4557 Use of @samp{KIND=} makes this document more concise because
4558 @code{g77} is able to define values for @samp{KIND=} that
4559 have the same meanings on all systems, due to the way the
4560 Fortran 90 standard specifies these values are to be used.
4562 (In particular, that standard permits an implementation to
4563 arbitrarily assign nonnegative values.
4564 There are four distinct sets of assignments: one to the @code{CHARACTER}
4565 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
4566 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
4567 Implementations are free to assign these values in any order,
4568 leave gaps in the ordering of assignments, and assign more than
4569 one value to a representation.)
4571 This makes @samp{KIND=} values superior to the values used
4572 in non-standard statements such as @samp{INTEGER*4}, because
4573 the meanings of the values in those statements vary from machine
4574 to machine, compiler to compiler, even operating system to
4577 However, use of @samp{KIND=} is @emph{not} generally recommended
4578 when writing portable code (unless, for example, the code is
4579 going to be compiled only via @code{g77}, which is a widely
4581 GNU Fortran does not yet have adequate language constructs to
4582 permit use of @samp{KIND=} in a fashion that would make the
4583 code portable to Fortran 90 implementations; and, this construct
4584 is known to @emph{not} be accepted by many popular FORTRAN 77
4585 implementations, so it cannot be used in code that is to be ported
4588 The distinction here is that this document is able to use
4589 specific values for @samp{KIND=} to concisely document the
4590 types of various operations and operands.
4592 A Fortran program should use the FORTRAN 77 designations for the
4593 appropriate GNU Fortran types---such as @code{INTEGER} for
4594 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
4595 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
4596 where no such designations exist, make use of appropriate
4597 techniques (preprocessor macros, parameters, and so on)
4598 to specify the types in a fashion that may be easily adjusted
4599 to suit each particular implementation to which the program
4601 (These types generally won't need to be adjusted for ports of
4604 Further details regarding GNU Fortran data types and constants
4615 @subsection Data Types
4617 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
4619 GNU Fortran supports these types:
4623 Integer (generic type @code{INTEGER})
4626 Real (generic type @code{REAL})
4632 Complex (generic type @code{COMPLEX})
4635 Logical (generic type @code{LOGICAL})
4638 Character (generic type @code{CHARACTER})
4644 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
4646 The generic types shown above are referred to in this document
4647 using only their generic type names.
4648 Such references usually indicate that any specific type (kind)
4649 of that generic type is valid.
4651 For example, a context described in this document as accepting
4652 the @code{COMPLEX} type also is likely to accept the
4653 @code{DOUBLE COMPLEX} type.
4655 The GNU Fortran language supports three ways to specify
4656 a specific kind of a generic type.
4659 * Double Notation:: As in @code{DOUBLE COMPLEX}.
4660 * Star Notation:: As in @code{INTEGER*4}.
4661 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
4664 @node Double Notation
4665 @subsubsection Double Notation
4667 The GNU Fortran language supports two uses of the keyword
4668 @code{DOUBLE} to specify a specific kind of type:
4672 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
4675 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
4678 Use one of the above forms where a type name is valid.
4680 While use of this notation is popular, it doesn't scale
4681 well in a language or dialect rich in intrinsic types,
4682 as is the case for the GNU Fortran language (especially
4683 planned future versions of it).
4685 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
4686 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
4687 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
4688 often are substituted for these, respectively, even though they
4689 do not always have the same meanings on all systems.
4690 (And, the fact that @samp{DOUBLE REAL} does not exist as such
4691 is an inconsistency.)
4693 Therefore, this document uses ``double notation'' only on occasion
4694 for the benefit of those readers who are accustomed to it.
4697 @subsubsection Star Notation
4698 @cindex *@var{n} notation
4700 The following notation specifies the storage size for a type:
4703 @var{generic-type}*@var{n}
4707 @var{generic-type} must be a generic type---one of
4708 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4709 or @code{CHARACTER}.
4710 @var{n} must be one or more digits comprising a decimal
4711 integer number greater than zero.
4713 Use the above form where a type name is valid.
4715 The @samp{*@var{n}} notation specifies that the amount of storage
4716 occupied by variables and array elements of that type is @var{n}
4717 times the storage occupied by a @code{CHARACTER*1} variable.
4719 This notation might indicate a different degree of precision and/or
4720 range for such variables and array elements, and the functions that
4721 return values of types using this notation.
4722 It does not limit the precision or range of values of that type
4723 in any particular way---use explicit code to do that.
4725 Further, the GNU Fortran language requires no particular values
4726 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
4728 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
4729 on all systems, for example,
4730 but not all implementations are required to do so, and @code{g77}
4731 is known to not support @code{REAL*1} on most (or all) systems.
4733 As a result, except for @var{generic-type} of @code{CHARACTER},
4734 uses of this notation should be limited to isolated
4735 portions of a program that are intended to handle system-specific
4736 tasks and are expected to be non-portable.
4738 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
4739 only @code{CHARACTER}, where it signifies not only the amount
4740 of storage occupied, but the number of characters in entities
4742 However, almost all Fortran compilers have supported this
4743 notation for generic types, though with a variety of meanings
4746 Specifications of types using the @samp{*@var{n}} notation
4747 always are interpreted as specifications of the appropriate
4748 types described in this document using the @samp{KIND=@var{n}}
4749 notation, described below.
4751 While use of this notation is popular, it doesn't serve well
4752 in the context of a widely portable dialect of Fortran, such as
4753 the GNU Fortran language.
4755 For example, even on one particular machine, two or more popular
4756 Fortran compilers might well disagree on the size of a type
4757 declared @code{INTEGER*2} or @code{REAL*16}.
4759 is known to be disagreement over such things among Fortran
4760 compilers on @emph{different} systems.
4762 Further, this notation offers no elegant way to specify sizes
4763 that are not even multiples of the ``byte size'' typically
4764 designated by @code{INTEGER*1}.
4765 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
4766 certainly be possible, but would perhaps be stretching the original
4767 intent of this notation beyond the breaking point in terms
4768 of widespread readability of documentation and code making use
4771 Therefore, this document uses ``star notation'' only on occasion
4772 for the benefit of those readers who are accustomed to it.
4775 @subsubsection Kind Notation
4776 @cindex KIND= notation
4778 The following notation specifies the kind-type selector of a type:
4781 @var{generic-type}(KIND=@var{n})
4785 Use the above form where a type name is valid.
4787 @var{generic-type} must be a generic type---one of
4788 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4789 or @code{CHARACTER}.
4790 @var{n} must be an integer initialization expression that
4791 is a positive, nonzero value.
4793 Programmers are discouraged from writing these values directly
4795 Future versions of the GNU Fortran language will offer
4796 facilities that will make the writing of code portable
4797 to @code{g77} @emph{and} Fortran 90 implementations simpler.
4799 However, writing code that ports to existing FORTRAN 77
4800 implementations depends on avoiding the @samp{KIND=} construct.
4802 The @samp{KIND=} construct is thus useful in the context
4803 of GNU Fortran for two reasons:
4807 It provides a means to specify a type in a fashion that
4808 is portable across all GNU Fortran implementations (though
4809 not other FORTRAN 77 and Fortran 90 implementations).
4812 It provides a sort of Rosetta stone for this document to use
4813 to concisely describe the types of various operations and
4817 The values of @var{n} in the GNU Fortran language are
4818 assigned using a scheme that:
4822 Attempts to maximize the ability of readers
4823 of this document to quickly familiarize themselves
4824 with assignments for popular types
4827 Provides a unique value for each specific desired
4831 Provides a means to automatically assign new values so
4832 they have a ``natural'' relationship to existing values,
4833 if appropriate, or, if no such relationship exists, will
4834 not interfere with future values assigned on the basis
4835 of such relationships
4838 Avoids using values that are similar to values used
4839 in the existing, popular @samp{*@var{n}} notation,
4840 to prevent readers from expecting that these implied
4841 correspondences work on all GNU Fortran implementations
4844 The assignment system accomplishes this by assigning
4845 to each ``fundamental meaning'' of a specific type a
4846 unique prime number.
4847 Combinations of fundamental meanings---for example, a type
4848 that is two times the size of some other type---are assigned
4849 values of @var{n} that are the products of the values for
4850 those fundamental meanings.
4852 A prime value of @var{n} is never given more than one fundamental
4853 meaning, to avoid situations where some code or system
4854 cannot reasonably provide those meanings in the form of a
4857 The values of @var{n} assigned so far are:
4861 This value is reserved for future use.
4863 The planned future use is for this value to designate,
4864 explicitly, context-sensitive kind-type selection.
4865 For example, the expression @samp{1D0 * 0.1_0} would
4866 be equivalent to @samp{1D0 * 0.1D0}.
4869 This corresponds to the default types for
4870 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
4871 and @code{CHARACTER}, as appropriate.
4873 These are the ``default'' types described in the Fortran 90 standard,
4874 though that standard does not assign any particular @samp{KIND=}
4875 value to these types.
4877 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
4878 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
4881 This corresponds to types that occupy twice as much
4882 storage as the default types.
4883 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
4884 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
4886 These are the ``double precision'' types described in the Fortran 90
4888 though that standard does not assign any particular @samp{KIND=}
4889 value to these types.
4891 @var{n} of 4 thus corresponds to types that occupy four times
4892 as much storage as the default types, @var{n} of 8 to types that
4893 occupy eight times as much storage, and so on.
4895 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
4896 are not necessarily supported by every GNU Fortran implementation.
4899 This corresponds to types that occupy as much
4900 storage as the default @code{CHARACTER} type,
4901 which is the same effective type as @code{CHARACTER(KIND=1)}
4902 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
4904 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
4906 @var{n} of 6 thus corresponds to types that occupy twice as
4907 much storage as the @var{n}=3 types, @var{n} of 12 to types
4908 that occupy four times as much storage, and so on.
4910 These are not necessarily supported by every GNU Fortran
4914 This corresponds to types that occupy half the
4915 storage as the default (@var{n}=1) types.
4917 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
4919 @var{n} of 25 thus corresponds to types that occupy one-quarter
4920 as much storage as the default types.
4922 These are not necessarily supported by every GNU Fortran
4927 This is valid only as @code{INTEGER(KIND=7)} and
4928 denotes the @code{INTEGER} type that has the smallest
4929 storage size that holds a pointer on the system.
4931 A pointer representable by this type is capable of uniquely
4932 addressing a @code{CHARACTER*1} variable, array, array element,
4935 (Typically this is equivalent to @code{INTEGER*4} or,
4936 on 64-bit systems, @code{INTEGER*8}.
4937 In a compatible C implementation, it typically would
4938 be the same size and semantics of the C type @code{void *}.)
4941 Note that these are @emph{proposed} correspondences and might change
4942 in future versions of @code{g77}---avoid writing code depending
4943 on them while @code{g77}, and therefore the GNU Fortran language
4944 it defines, is in beta testing.
4946 Values not specified in the above list are reserved to
4947 future versions of the GNU Fortran language.
4949 Implementation-dependent meanings will be assigned new,
4950 unique prime numbers so as to not interfere with other
4951 implementation-dependent meanings, and offer the possibility
4952 of increasing the portability of code depending on such
4953 types by offering support for them in other GNU Fortran
4956 Other meanings that might be given unique values are:
4960 Types that make use of only half their storage size for
4961 representing precision and range.
4963 For example, some compilers offer options that cause
4964 @code{INTEGER} types to occupy the amount of storage
4965 that would be needed for @code{INTEGER(KIND=2)} types, but the
4966 range remains that of @code{INTEGER(KIND=1)}.
4969 The IEEE single floating-point type.
4972 Types with a specific bit pattern (endianness), such as the
4973 little-endian form of @code{INTEGER(KIND=1)}.
4974 These could permit, conceptually, use of portable code and
4975 implementations on data files written by existing systems.
4978 Future @emph{prime} numbers should be given meanings in as incremental
4979 a fashion as possible, to allow for flexibility and
4980 expressiveness in combining types.
4982 For example, instead of defining a prime number for little-endian
4983 IEEE doubles, one prime number might be assigned the meaning
4984 ``little-endian'', another the meaning ``IEEE double'', and the
4985 value of @var{n} for a little-endian IEEE double would thus
4986 naturally be the product of those two respective assigned values.
4987 (It could even be reasonable to have IEEE values result from the
4988 products of prime values denoting exponent and fraction sizes
4989 and meanings, hidden bit usage, availability and representations
4990 of special values such as subnormals, infinities, and Not-A-Numbers
4993 This assignment mechanism, while not inherently required for
4994 future versions of the GNU Fortran language, is worth using
4995 because it could ease management of the ``space'' of supported
4996 types much easier in the long run.
4998 The above approach suggests a mechanism for specifying inheritance
4999 of intrinsic (built-in) types for an entire, widely portable
5001 It is certainly reasonable that, unlike programmers of other languages
5002 offering inheritance mechanisms that employ verbose names for classes
5003 and subclasses, along with graphical browsers to elucidate the
5004 relationships, Fortran programmers would employ
5005 a mechanism that works by multiplying prime numbers together
5006 and finding the prime factors of such products.
5008 Most of the advantages for the above scheme have been explained
5010 One disadvantage is that it could lead to the defining,
5011 by the GNU Fortran language, of some fairly large prime numbers.
5012 This could lead to the GNU Fortran language being declared
5013 ``munitions'' by the United States Department of Defense.
5016 @subsection Constants
5018 @cindex types, constants
5020 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
5022 A @dfn{typeless constant} has one of the following forms:
5025 '@var{binary-digits}'B
5026 '@var{octal-digits}'O
5027 '@var{hexadecimal-digits}'Z
5028 '@var{hexadecimal-digits}'X
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 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
5039 treated as typeless. @xref{Fortran Dialect Options,, Options
5040 Controlling Fortran Dialect}, for information on the
5041 @samp{-ftypeless-boz} option.
5043 Typeless constants have values that depend on the context in which
5046 All other constants, called @dfn{typed constants}, are interpreted---converted
5047 to internal form---according to their inherent type.
5048 Thus, context is @emph{never} a determining factor for the type, and hence
5049 the interpretation, of a typed constant.
5050 (All constants in the ANSI FORTRAN 77 language are typed constants.)
5052 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
5053 Fortran (called default INTEGER in Fortran 90),
5054 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
5055 additional precision specified is lost, and even when used in a
5056 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
5057 and @samp{1D0} is always type @code{REAL(KIND=2)}.
5060 @subsection Integer Type
5062 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
5064 An integer constant also may have one of the following forms:
5067 B'@var{binary-digits}'
5068 O'@var{octal-digits}'
5069 Z'@var{hexadecimal-digits}'
5070 X'@var{hexadecimal-digits}'
5074 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5075 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5076 and @samp{0123456789ABCDEFabcdef}, respectively.
5077 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5080 @node Character Type
5081 @subsection Character Type
5083 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
5085 @cindex double quoted character constants
5086 A character constant may be delimited by a pair of double quotes
5087 (@samp{"}) instead of apostrophes.
5088 In this case, an apostrophe within the constant represents
5089 a single apostrophe, while a double quote is represented in
5090 the source text of the constant by two consecutive double
5091 quotes with no intervening spaces.
5093 @cindex zero-length CHARACTER
5094 @cindex null CHARACTER strings
5095 @cindex empty CHARACTER strings
5096 @cindex strings, empty
5097 @cindex CHARACTER, null
5098 A character constant may be empty (have a length of zero).
5100 A character constant may include a substring specification,
5101 The value of such a constant is the value of the substring---for
5102 example, the value of @samp{'hello'(3:5)} is the same
5103 as the value of @samp{'llo'}.
5106 @section Expressions
5108 (The following information augments or overrides the information in
5109 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5111 Chapter 6 of that document otherwise serves as the basis
5112 for the relevant aspects of GNU Fortran.)
5119 @subsection The @code{%LOC()} Construct
5120 @cindex %LOC() construct
5126 The @code{%LOC()} construct is an expression
5127 that yields the value of the location of its argument,
5128 @var{arg}, in memory.
5129 The size of the type of the expression depends on the system---typically,
5130 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5131 though it is actually type @code{INTEGER(KIND=7)}.
5133 The argument to @code{%LOC()} must be suitable as the
5134 left-hand side of an assignment statement.
5135 That is, it may not be a general expression involving
5136 operators such as addition, subtraction, and so on,
5137 nor may it be a constant.
5139 Use of @code{%LOC()} is recommended only for code that
5140 is accessing facilities outside of GNU Fortran, such as
5141 operating system or windowing facilities.
5142 It is best to constrain such uses to isolated portions of
5143 a program---portions that deal specifically and exclusively
5144 with low-level, system-dependent facilities.
5145 Such portions might well provide a portable interface for
5146 use by the program as a whole, but are themselves not
5147 portable, and should be thoroughly tested each time they
5148 are rebuilt using a new compiler or version of a compiler.
5150 Do not depend on @code{%LOC()} returning a pointer that
5151 can be safely used to @emph{define} (change) the argument.
5152 While this might work in some circumstances, it is hard
5153 to predict whether it will continue to work when a program
5154 (that works using this unsafe behavior)
5155 is recompiled using different command-line options or
5156 a different version of @code{g77}.
5158 Generally, @code{%LOC()} is safe when used as an argument
5159 to a procedure that makes use of the value of the corresponding
5160 dummy argument only during its activation, and only when
5161 such use is restricted to referencing (reading) the value
5162 of the argument to @code{%LOC()}.
5164 @emph{Implementation Note:} Currently, @code{g77} passes
5165 arguments (those not passed using a construct such as @code{%VAL()})
5166 by reference or descriptor, depending on the type of
5167 the actual argument.
5168 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5169 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5170 in fact might compile to identical code.
5172 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5173 ``pass, by value, the address of @samp{I} in memory''.
5174 While @samp{CALL FOO(I)} might use that same approach in a
5175 particular version of @code{g77}, another version or compiler
5176 might choose a different implementation, such as copy-in/copy-out,
5177 to effect the desired behavior---and which will therefore not
5178 necessarily compile to the same code as would
5179 @samp{CALL FOO(%VAL(%LOC(I)))}
5180 using the same version or compiler.
5182 @xref{Debugging and Interfacing}, for detailed information on
5183 how this particular version of @code{g77} implements various
5186 @node Specification Statements
5187 @section Specification Statements
5189 (The following information augments or overrides the information in
5190 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5192 Chapter 8 of that document otherwise serves as the basis
5193 for the relevant aspects of GNU Fortran.)
5201 @subsection @code{NAMELIST} Statement
5202 @cindex NAMELIST statement
5203 @cindex statements, NAMELIST
5205 The @code{NAMELIST} statement, and related I/O constructs, are
5206 supported by the GNU Fortran language in essentially the same
5207 way as they are by @code{f2c}.
5209 This follows Fortran 90 with the restriction that on @code{NAMELIST}
5210 input, subscripts must have the form
5212 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
5216 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
5218 is allowed, but not, say,
5220 &xx x(:3,8::2)=1,2,3,4,5,6/
5223 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
5224 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
5226 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
5228 could be used instead of the example above.
5230 @node DOUBLE COMPLEX
5231 @subsection @code{DOUBLE COMPLEX} Statement
5232 @cindex DOUBLE COMPLEX
5234 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5235 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5237 @node Control Statements
5238 @section Control Statements
5240 (The following information augments or overrides the information in
5241 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5243 Chapter 11 of that document otherwise serves as the basis
5244 for the relevant aspects of GNU Fortran.)
5254 @subsection DO WHILE
5257 @cindex MIL-STD 1753
5259 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5260 Fortran 90 standards, is provided by the GNU Fortran language.
5261 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
5267 @cindex MIL-STD 1753
5269 The @code{END DO} statement is provided by the GNU Fortran language.
5271 This statement is used in one of two ways:
5275 The Fortran 90 meaning, in which it specifies the termination
5276 point of a single @code{DO} loop started with a @code{DO} statement
5277 that specifies no termination label.
5280 The MIL-STD 1753 meaning, in which it specifies the termination
5281 point of one or more @code{DO} loops, all of which start with a
5282 @code{DO} statement that specify the label defined for the
5283 @code{END DO} statement.
5285 This kind of @code{END DO} statement is merely a synonym for
5286 @code{CONTINUE}, except it is permitted only when the statement
5287 is labeled and a target of one or more labeled @code{DO} loops.
5289 It is expected that this use of @code{END DO} will be removed from
5290 the GNU Fortran language in the future, though it is likely that
5291 it will long be supported by @code{g77} as a dialect form.
5294 @node Construct Names
5295 @subsection Construct Names
5296 @cindex construct names
5298 The GNU Fortran language supports construct names as defined
5299 by the Fortran 90 standard.
5300 These names are local to the program unit and are defined
5304 @var{construct-name}: @var{block-statement}
5308 Here, @var{construct-name} is the construct name itself;
5309 its definition is connoted by the single colon (@samp{:}); and
5310 @var{block-statement} is an @code{IF}, @code{DO},
5311 or @code{SELECT CASE} statement that begins a block.
5313 A block that is given a construct name must also specify the
5314 same construct name in its termination statement:
5317 END @var{block} @var{construct-name}
5321 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5324 @node CYCLE and EXIT
5325 @subsection The @code{CYCLE} and @code{EXIT} Statements
5327 @cindex CYCLE statement
5328 @cindex EXIT statement
5329 @cindex statements, CYCLE
5330 @cindex statements, EXIT
5331 The @code{CYCLE} and @code{EXIT} statements specify that
5332 the remaining statements in the current iteration of a
5333 particular active (enclosing) @code{DO} loop are to be skipped.
5335 @code{CYCLE} specifies that these statements are skipped,
5336 but the @code{END DO} statement that marks the end of the
5337 @code{DO} loop be executed---that is, the next iteration,
5338 if any, is to be started.
5339 If the statement marking the end of the @code{DO} loop is
5340 not @code{END DO}---in other words, if the loop is not
5341 a block @code{DO}---the @code{CYCLE} statement does not
5342 execute that statement, but does start the next iteration (if any).
5344 @code{EXIT} specifies that the loop specified by the
5345 @code{DO} construct is terminated.
5347 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5348 is the innermost enclosing @code{DO} loop when the following
5356 Otherwise, the following forms specify the construct name
5357 of the pertinent @code{DO} loop:
5360 CYCLE @var{construct-name}
5361 EXIT @var{construct-name}
5364 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5366 However, they cannot be easily thought of as @code{GO TO} statements
5367 in obscure cases involving FORTRAN 77 loops.
5376 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5381 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5382 above are equivalent to a @code{GO TO} statement to either label
5383 @samp{10} or @samp{20}.
5385 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5386 above fragment, it is helpful to first translate it to its equivalent
5387 using only block @code{DO} loops:
5395 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5402 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5403 to @code{GO TO} so they may be more easily understood by programmers
5404 accustomed to FORTRAN coding:
5409 IF (J .EQ. 5) GOTO 18
5411 IF (K .EQ. 3) GO TO 12
5412 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5420 Thus, the @code{CYCLE} statement in the innermost loop skips over
5421 the @code{PRINT} statement as it begins the next iteration of the
5422 loop, while the @code{EXIT} statement in the middle loop ends that
5423 loop but @emph{not} the outermost loop.
5425 @node Functions and Subroutines
5426 @section Functions and Subroutines
5428 (The following information augments or overrides the information in
5429 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5431 Chapter 15 of that document otherwise serves as the basis
5432 for the relevant aspects of GNU Fortran.)
5438 * Generics and Specifics::
5439 * REAL() and AIMAG() of Complex::
5440 * CMPLX() of DOUBLE PRECISION::
5442 * f77/f2c Intrinsics::
5443 * Table of Intrinsic Functions::
5447 @subsection The @code{%VAL()} Construct
5448 @cindex %VAL() construct
5454 The @code{%VAL()} construct specifies that an argument,
5455 @var{arg}, is to be passed by value, instead of by reference
5458 @code{%VAL()} is restricted to actual arguments in
5459 invocations of external procedures.
5461 Use of @code{%VAL()} is recommended only for code that
5462 is accessing facilities outside of GNU Fortran, such as
5463 operating system or windowing facilities.
5464 It is best to constrain such uses to isolated portions of
5465 a program---portions the deal specifically and exclusively
5466 with low-level, system-dependent facilities.
5467 Such portions might well provide a portable interface for
5468 use by the program as a whole, but are themselves not
5469 portable, and should be thoroughly tested each time they
5470 are rebuilt using a new compiler or version of a compiler.
5472 @emph{Implementation Note:} Currently, @code{g77} passes
5473 all arguments either by reference or by descriptor.
5475 Thus, use of @code{%VAL()} tends to be restricted to cases
5476 where the called procedure is written in a language other
5477 than Fortran that supports call-by-value semantics.
5478 (C is an example of such a language.)
5480 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5481 for detailed information on
5482 how this particular version of @code{g77} passes arguments
5486 @subsection The @code{%REF()} Construct
5487 @cindex %REF() construct
5493 The @code{%REF()} construct specifies that an argument,
5494 @var{arg}, is to be passed by reference, instead of by
5495 value or descriptor.
5497 @code{%REF()} is restricted to actual arguments in
5498 invocations of external procedures.
5500 Use of @code{%REF()} is recommended only for code that
5501 is accessing facilities outside of GNU Fortran, such as
5502 operating system or windowing facilities.
5503 It is best to constrain such uses to isolated portions of
5504 a program---portions the deal specifically and exclusively
5505 with low-level, system-dependent facilities.
5506 Such portions might well provide a portable interface for
5507 use by the program as a whole, but are themselves not
5508 portable, and should be thoroughly tested each time they
5509 are rebuilt using a new compiler or version of a compiler.
5511 Do not depend on @code{%REF()} supplying a pointer to the
5512 procedure being invoked.
5513 While that is a likely implementation choice, other
5514 implementation choices are available that preserve Fortran
5515 pass-by-reference semantics without passing a pointer to
5516 the argument, @var{arg}.
5517 (For example, a copy-in/copy-out implementation.)
5519 @emph{Implementation Note:} Currently, @code{g77} passes
5521 (other than variables and arrays of type @code{CHARACTER})
5523 Future versions of, or dialects supported by, @code{g77} might
5524 not pass @code{CHARACTER} functions by reference.
5526 Thus, use of @code{%REF()} tends to be restricted to cases
5527 where @var{arg} is type @code{CHARACTER} but the called
5528 procedure accesses it via a means other than the method
5529 used for Fortran @code{CHARACTER} arguments.
5531 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5532 how this particular version of @code{g77} passes arguments
5536 @subsection The @code{%DESCR()} Construct
5537 @cindex %DESCR() construct
5543 The @code{%DESCR()} construct specifies that an argument,
5544 @var{arg}, is to be passed by descriptor, instead of by
5547 @code{%DESCR()} is restricted to actual arguments in
5548 invocations of external procedures.
5550 Use of @code{%DESCR()} is recommended only for code that
5551 is accessing facilities outside of GNU Fortran, such as
5552 operating system or windowing facilities.
5553 It is best to constrain such uses to isolated portions of
5554 a program---portions the deal specifically and exclusively
5555 with low-level, system-dependent facilities.
5556 Such portions might well provide a portable interface for
5557 use by the program as a whole, but are themselves not
5558 portable, and should be thoroughly tested each time they
5559 are rebuilt using a new compiler or version of a compiler.
5561 Do not depend on @code{%DESCR()} supplying a pointer
5562 and/or a length passed by value
5563 to the procedure being invoked.
5564 While that is a likely implementation choice, other
5565 implementation choices are available that preserve the
5566 pass-by-reference semantics without passing a pointer to
5567 the argument, @var{arg}.
5568 (For example, a copy-in/copy-out implementation.)
5569 And, future versions of @code{g77} might change the
5570 way descriptors are implemented, such as passing a
5571 single argument pointing to a record containing the
5572 pointer/length information instead of passing that same
5573 information via two arguments as it currently does.
5575 @emph{Implementation Note:} Currently, @code{g77} passes
5576 all variables and arrays of type @code{CHARACTER}
5578 Future versions of, or dialects supported by, @code{g77} might
5579 pass @code{CHARACTER} functions by descriptor as well.
5581 Thus, use of @code{%DESCR()} tends to be restricted to cases
5582 where @var{arg} is not type @code{CHARACTER} but the called
5583 procedure accesses it via a means similar to the method
5584 used for Fortran @code{CHARACTER} arguments.
5586 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5587 how this particular version of @code{g77} passes arguments
5590 @node Generics and Specifics
5591 @subsection Generics and Specifics
5592 @cindex generic intrinsics
5593 @cindex intrinsics, generic
5595 The ANSI FORTRAN 77 language defines generic and specific
5597 In short, the distinctions are:
5601 @emph{Specific} intrinsics have
5602 specific types for their arguments and a specific return
5606 @emph{Generic} intrinsics are treated,
5607 on a case-by-case basis in the program's source code,
5608 as one of several possible specific intrinsics.
5610 Typically, a generic intrinsic has a return type that
5611 is determined by the type of one or more of its arguments.
5614 The GNU Fortran language generalizes these concepts somewhat,
5615 especially by providing intrinsic subroutines and generic
5616 intrinsics that are treated as either a specific intrinsic subroutine
5617 or a specific intrinsic function (e.g. @code{SECOND}).
5619 However, GNU Fortran avoids generalizing this concept to
5620 the point where existing code would be accepted as meaning
5621 something possibly different than what was intended.
5623 For example, @code{ABS} is a generic intrinsic, so all working
5624 code written using @code{ABS} of an @code{INTEGER} argument
5625 expects an @code{INTEGER} return value.
5626 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
5627 argument returns an @code{INTEGER*2} return value.
5629 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
5630 an @code{INTEGER(KIND=1)} argument.
5631 Code that passes something other than an @code{INTEGER(KIND=1)}
5632 argument to @code{IABS} is not valid GNU Fortran code, because
5633 it is not clear what the author intended.
5635 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
5636 is not defined by the GNU Fortran language, because the programmer
5637 might have used that construct to mean any of the following, subtly
5642 Convert @samp{J} to @code{INTEGER(KIND=1)} first
5643 (as if @samp{IABS(INT(J))} had been written).
5646 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
5647 (as if @samp{INT(ABS(J))} had been written).
5650 No conversion (as if @samp{ABS(J)} had been written).
5653 The distinctions matter especially when types and values wider than
5654 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
5655 operations performing more ``arithmetic'' than absolute-value, are involved.
5657 The following sample program is not a valid GNU Fortran program, but
5658 might be accepted by other compilers.
5659 If so, the output is likely to be revealing in terms of how a given
5660 compiler treats intrinsics (that normally are specific) when they
5661 are given arguments that do not conform to their stated requirements:
5663 @cindex JCB002 program
5667 C Modified 1999-02-15 (Burley) to delete my email address.
5668 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
5669 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
5672 C Written by James Craig Burley 1997-02-20.
5675 C Determine how compilers handle non-standard IDIM
5676 C on INTEGER*2 operands, which presumably can be
5677 C extrapolated into understanding how the compiler
5678 C generally treats specific intrinsics that are passed
5679 C arguments not of the correct types.
5681 C If your compiler implements INTEGER*2 and INTEGER
5682 C as the same type, change all INTEGER*2 below to
5687 INTEGER*2 ISMALL, ILARGE
5688 INTEGER*2 ITOOLG, ITWO
5692 C Find smallest INTEGER*2 number.
5696 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
5701 C Find largest INTEGER*2 number.
5705 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
5710 C Multiplying by two adds stress to the situation.
5714 C Need a number that, added to -2, is too wide to fit in I*2.
5718 C Use IDIM the straightforward way.
5720 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
5722 C Calculate result for first interpretation.
5724 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
5726 C Calculate result for second interpretation.
5728 ITMP = ILARGE - ISMALL
5729 I3 = (INT (ITMP)) * ITWO + ITOOLG
5731 C Calculate result for third interpretation.
5733 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
5737 PRINT *, 'ILARGE=', ILARGE
5738 PRINT *, 'ITWO=', ITWO
5739 PRINT *, 'ITOOLG=', ITOOLG
5740 PRINT *, 'ISMALL=', ISMALL
5749 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
5750 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
5753 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
5754 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
5757 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
5758 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
5761 PRINT *, 'Results need careful analysis.'
5765 No future version of the GNU Fortran language
5766 will likely permit specific intrinsic invocations with wrong-typed
5767 arguments (such as @code{IDIM} in the above example), since
5768 it has been determined that disagreements exist among
5769 many production compilers on the interpretation of
5771 These disagreements strongly suggest that Fortran programmers,
5772 and certainly existing Fortran programs, disagree about the
5773 meaning of such invocations.
5775 The first version of @code{JCB002} didn't accommodate some compilers'
5776 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
5778 In such a case, these compilers apparently convert both
5779 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
5780 instead of doing an @code{INTEGER*2} subtraction on the
5781 original values in @samp{I1} and @samp{I2}.
5783 However, the results of the careful analyses done on the outputs
5784 of programs compiled by these various compilers show that they
5785 all implement either @samp{Interp 1} or @samp{Interp 2} above.
5787 Specifically, it is believed that the new version of @code{JCB002}
5788 above will confirm that:
5792 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
5793 @code{f77} compilers all implement @samp{Interp 1}.
5796 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
5799 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
5800 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
5803 If you get different results than the above for the stated
5804 compilers, or have results for other compilers that might be
5805 worth adding to the above list, please let us know the details
5806 (compiler product, version, machine, results, and so on).
5808 @node REAL() and AIMAG() of Complex
5809 @subsection @code{REAL()} and @code{AIMAG()} of Complex
5810 @cindex @code{Real} intrinsic
5811 @cindex intrinsics, @code{Real}
5812 @cindex @code{AImag} intrinsic
5813 @cindex intrinsics, @code{AImag}
5815 The GNU Fortran language disallows @code{REAL(@var{expr})}
5816 and @code{AIMAG(@var{expr})},
5817 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
5818 except when they are used in the following way:
5821 REAL(REAL(@var{expr}))
5822 REAL(AIMAG(@var{expr}))
5826 The above forms explicitly specify that the desired effect
5827 is to convert the real or imaginary part of @var{expr}, which might
5828 be some @code{REAL} type other than @code{REAL(KIND=1)},
5829 to type @code{REAL(KIND=1)},
5830 and have that serve as the value of the expression.
5832 The GNU Fortran language offers clearly named intrinsics to extract the
5833 real and imaginary parts of a complex entity without any
5837 REALPART(@var{expr})
5838 IMAGPART(@var{expr})
5841 To express the above using typical extended FORTRAN 77,
5842 use the following constructs
5843 (when @var{expr} is @code{COMPLEX(KIND=2)}):
5850 The FORTRAN 77 language offers no way
5851 to explicitly specify the real and imaginary parts of a complex expression of
5852 arbitrary type, apparently as a result of requiring support for
5853 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
5854 The concepts of converting an expression to type @code{REAL(KIND=1)} and
5855 of extracting the real part of a complex expression were
5856 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
5857 they happened to have the exact same effect in that language
5858 (due to having only one @code{COMPLEX} type).
5860 @emph{Note:} When @samp{-ff90} is in effect,
5861 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
5862 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
5863 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
5864 treated as @samp{REAL(REALPART(@var{expr}))}.
5866 @xref{Ugly Complex Part Extraction}, for more information.
5868 @node CMPLX() of DOUBLE PRECISION
5869 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
5870 @cindex @code{Cmplx} intrinsic
5871 @cindex intrinsics, @code{Cmplx}
5873 In accordance with Fortran 90 and at least some (perhaps all)
5874 other compilers, the GNU Fortran language defines @code{CMPLX()}
5875 as always returning a result that is type @code{COMPLEX(KIND=1)}.
5877 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
5878 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
5881 CMPLX(SNGL(D1), SNGL(D2))
5884 (It was necessary for Fortran 90 to specify this behavior
5885 for @code{DOUBLE PRECISION} arguments, since that is
5886 the behavior mandated by FORTRAN 77.)
5888 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
5889 which is provided by some FORTRAN 77 compilers to construct
5890 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
5892 However, this solution does not scale well when more @code{COMPLEX} types
5893 (having various precisions and ranges) are offered by Fortran implementations.
5895 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
5896 an extra argument used to specify the desired kind of complex
5898 However, this solution is somewhat awkward to use, and
5899 @code{g77} currently does not support it.
5901 The GNU Fortran language provides a simple way to build a complex
5902 value out of two numbers, with the precise type of the value
5903 determined by the types of the two numbers (via the usual
5904 type-promotion mechanism):
5907 COMPLEX(@var{real}, @var{imag})
5910 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
5911 performs no conversion other than to put them together to form a
5912 complex result of the same (complex version of real) type.
5914 @xref{Complex Intrinsic}, for more information.
5917 @subsection MIL-STD 1753 Support
5918 @cindex MIL-STD 1753
5920 The GNU Fortran language includes the MIL-STD 1753 intrinsics
5921 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
5922 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
5923 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
5925 @node f77/f2c Intrinsics
5926 @subsection @code{f77}/@code{f2c} Intrinsics
5928 The bit-manipulation intrinsics supported by traditional
5929 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
5930 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
5933 Also supported are the intrinsics @code{CDABS},
5934 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
5935 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
5936 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
5937 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
5940 @node Table of Intrinsic Functions
5941 @subsection Table of Intrinsic Functions
5942 @cindex intrinsics, table of
5943 @cindex table of intrinsics
5945 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
5947 The GNU Fortran language adds various functions, subroutines, types,
5948 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
5949 The complete set of intrinsics supported by the GNU Fortran language
5952 Note that a name is not treated as that of an intrinsic if it is
5953 specified in an @code{EXTERNAL} statement in the same program unit;
5954 if a command-line option is used to disable the groups to which
5955 the intrinsic belongs; or if the intrinsic is not named in an
5956 @code{INTRINSIC} statement and a command-line option is used to
5957 hide the groups to which the intrinsic belongs.
5959 So, it is recommended that any reference in a program unit to
5960 an intrinsic procedure that is not a standard FORTRAN 77
5961 intrinsic be accompanied by an appropriate @code{INTRINSIC}
5962 statement in that program unit.
5963 This sort of defensive programming makes it more
5964 likely that an implementation will issue a diagnostic rather
5965 than generate incorrect code for such a reference.
5967 The terminology used below is based on that of the Fortran 90
5968 standard, so that the text may be more concise and accurate:
5972 @code{OPTIONAL} means the argument may be omitted.
5975 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
5976 (generally named @samp{A}) may be specified.
5979 @samp{scalar} means the argument must not be an array (must
5980 be a variable or array element, or perhaps a constant if expressions
5984 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
5987 @code{INTENT(IN)} means the argument must be an expression
5988 (such as a constant or a variable that is defined upon invocation
5992 @code{INTENT(OUT)} means the argument must be definable by the
5993 invocation of the intrinsic (that is, must not be a constant nor
5994 an expression involving operators other than array reference and
5995 substring reference).
5998 @code{INTENT(INOUT)} means the argument must be defined prior to,
5999 and definable by, invocation of the intrinsic (a combination of
6000 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
6003 @xref{Kind Notation}, for an explanation of @code{KIND}.
6007 (Note that the empty lines appearing in the menu below
6008 are not intentional---they result from a bug in the
6009 GNU @code{makeinfo} program@dots{}a program that, if it
6010 did not exist, would leave this document in far worse shape!)
6013 @c The actual documentation for intrinsics comes from
6014 @c intdoc.texi, which in turn is automatically generated
6015 @c from the internal g77 tables in intrin.def _and_ the
6016 @c largely hand-written text in intdoc.h. So, if you want
6017 @c to change or add to existing documentation on intrinsics,
6018 @c you probably want to edit intdoc.h.
6030 @include intdoc.texi
6032 @node Scope and Classes of Names
6033 @section Scope and Classes of Symbolic Names
6034 @cindex symbol names, scope and classes
6037 (The following information augments or overrides the information in
6038 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
6040 Chapter 18 of that document otherwise serves as the basis
6041 for the relevant aspects of GNU Fortran.)
6044 * Underscores in Symbol Names::
6047 @node Underscores in Symbol Names
6048 @subsection Underscores in Symbol Names
6051 Underscores (@samp{_}) are accepted in symbol names after the first
6052 character (which must be a letter).
6058 A dollar sign at the end of an output format specification suppresses
6059 the newline at the end of the output.
6061 @cindex <> edit descriptor
6062 @cindex edit descriptor, <>
6063 Edit descriptors in @code{FORMAT} statements may contain compile-time
6064 @code{INTEGER} constant expressions in angle brackets, such as
6066 10 FORMAT (I<WIDTH>)
6069 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
6071 These Fortran 90 features are supported:
6074 @cindex FORMAT descriptors
6075 @cindex Z edit descriptor
6076 @cindex edit descriptor, Z
6077 @cindex O edit descriptor
6078 @cindex edit descriptor, O
6079 The @code{O} and @code{Z} edit descriptors are supported for I/O of
6080 integers in octal and hexadecimal formats, respectively.
6082 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6083 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
6084 specifier is supported.
6087 @node Fortran 90 Features
6088 @section Fortran 90 Features
6090 @cindex extensions, from Fortran 90
6092 For convenience this section collects a list (probably incomplete) of
6093 the Fortran 90 features supported by the GNU Fortran language, even if
6094 they are documented elsewhere.
6095 @xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
6096 for information on additional fixed source form lexical issues.
6097 @cindex @samp{-ffree-form}
6098 Further, the free source form is supported through the
6099 @samp{-ffree-form} option.
6100 @cindex @samp{-ff90}
6101 Other Fortran 90 features can be turned on by the @samp{-ff90} option;
6102 see @ref{Fortran 90}.
6103 For information on the Fortran 90 intrinsics available,
6104 see @ref{Table of Intrinsic Functions}.
6107 @item Automatic arrays in procedures
6108 @item Character assignments
6109 @cindex character assignments
6110 In character assignments, the variable being assigned may occur on the
6111 right hand side of the assignment.
6112 @item Character strings
6113 @cindex double quoted character constants
6114 Strings may have zero length and substrings of character constants are
6115 permitted. Character constants may be enclosed in double quotes
6116 (@code{"}) as well as single quotes. @xref{Character Type}.
6117 @item Construct names
6118 (Symbolic tags on blocks.) @xref{Construct Names}.
6119 @item @code{CYCLE} and @code{EXIT}
6120 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
6121 @item @code{DOUBLE COMPLEX}
6122 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
6123 @item @code{DO WHILE}
6125 @item @code{END} decoration
6130 @item @code{IMPLICIT NONE}
6131 @item @code{INCLUDE} statements
6133 @item List-directed and namelist I/O on internal files
6134 @item Binary, octal and hexadecimal constants
6135 These are supported more generally than required by Fortran 90.
6136 @xref{Integer Type}.
6137 @item @samp{O} and @samp{Z} edit descriptors
6138 @item @code{NAMELIST}
6140 @item @code{OPEN} specifiers
6141 @code{STATUS='REPLACE'} is supported.
6142 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6143 @code{STATUS='SCRATCH'} is supplied.
6144 @item @code{FORMAT} edit descriptors
6145 @cindex FORMAT descriptors
6146 @cindex Z edit descriptor
6147 @cindex edit descriptor, Z
6148 The @code{Z} edit descriptor is supported.
6149 @item Relational operators
6150 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
6151 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
6152 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
6153 @item @code{SELECT CASE}
6154 Not fully implemented.
6155 @xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
6156 @item Specification statements
6157 A limited subset of the Fortran 90 syntax and semantics for variable
6158 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
6159 (@code{KIND} is of limited usefulness in the absence of the
6160 @code{KIND}-related intrinsics, since these intrinsics permit writing
6161 more widely portable code.) An example of supported @code{KIND} usage
6164 INTEGER (KIND=1) :: FOO=1, BAR=2
6165 CHARACTER (LEN=3) FOO
6167 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
6170 @node Other Dialects
6171 @chapter Other Dialects
6173 GNU Fortran supports a variety of features that are not
6174 considered part of the GNU Fortran language itself, but
6175 are representative of various dialects of Fortran that
6176 @code{g77} supports in whole or in part.
6178 Any of the features listed below might be disallowed by
6179 @code{g77} unless some command-line option is specified.
6180 Currently, some of the features are accepted using the
6181 default invocation of @code{g77}, but that might change
6184 @emph{Note: This portion of the documentation definitely needs a lot
6188 * Source Form:: Details of fixed-form and free-form source.
6189 * Trailing Comment:: Use of @samp{/*} to start a comment.
6190 * Debug Line:: Use of @samp{D} in column 1.
6191 * Dollar Signs:: Use of @samp{$} in symbolic names.
6192 * Case Sensitivity:: Uppercase and lowercase in source files.
6193 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6194 * Fortran 90:: @dots{}versus the GNU Fortran language.
6195 * Pedantic Compilation:: Enforcing the standard.
6196 * Distensions:: Misfeatures supported by GNU Fortran.
6200 @section Source Form
6201 @cindex source file format
6202 @cindex source format
6203 @cindex file, source
6205 @cindex code, source
6209 GNU Fortran accepts programs written in either fixed form or
6213 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6214 allowing tabs) and Fortran 90's fixed form.
6216 Free form corresponds to
6217 Fortran 90's free form (though possibly not entirely up-to-date, and
6218 without complaining about some things that for which Fortran 90 requires
6219 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6221 The way a Fortran compiler views source files depends entirely on the
6222 implementation choices made for the compiler, since those choices
6223 are explicitly left to the implementation by the published Fortran
6225 GNU Fortran currently tries to be somewhat like a few popular compilers
6226 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6227 definition along with more
6228 flexibility offered by command-line options is likely to be offered
6231 This section describes how @code{g77} interprets source lines.
6234 * Carriage Returns:: Carriage returns ignored.
6235 * Tabs:: Tabs converted to spaces.
6236 * Short Lines:: Short lines padded with spaces (fixed-form only).
6237 * Long Lines:: Long lines truncated.
6238 * Ampersands:: Special Continuation Lines.
6241 @node Carriage Returns
6242 @subsection Carriage Returns
6243 @cindex carriage returns
6245 Carriage returns (@samp{\r}) in source lines are ignored.
6246 This is somewhat different from @code{f2c}, which seems to treat them as
6247 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6248 inside such constants.
6252 @cindex tab character
6253 @cindex horizontal tab
6255 A source line with a @key{TAB} character anywhere in it is treated as
6256 entirely significant---however long it is---instead of ending in
6257 column 72 (for fixed-form source) or 132 (for free-form source).
6258 This also is different from @code{f2c}, which encodes tabs as
6259 @samp{\t} (the ASCII @key{TAB} character) inside character
6260 and Hollerith constants, but nevertheless seems to treat the column
6261 position as if it had been affected by the canonical tab positioning.
6263 @code{g77} effectively
6264 translates tabs to the appropriate number of spaces (a la the default
6265 for the UNIX @code{expand} command) before doing any other processing, other
6266 than (currently) noting whether a tab was found on a line and using this
6267 information to decide how to interpret the length of the line and continued
6270 Note that this default behavior probably will change for version 0.6,
6271 when it will presumably be available via a command-line option.
6272 The default as of version 0.6 is planned to be a ``pure visual''
6273 model, where tabs are immediately
6274 converted to spaces and otherwise have no effect, so the way a typical
6275 user sees source lines produces a consistent result no matter how the
6276 spacing in those source lines is actually implemented via tabs, spaces,
6277 and trailing tabs/spaces before newline.
6278 Command-line options are likely to be added to specify whether all or
6279 just-tabbed lines are to be extended to 132 or full input-line length,
6280 and perhaps even an option will be added to specify the truncated-line
6281 behavior to which some Digital compilers default (and which affects
6282 the way continued character/Hollerith constants are interpreted).
6285 @subsection Short Lines
6286 @cindex short source lines
6287 @cindex space, padding with
6288 @cindex source lines, short
6289 @cindex lines, short
6291 Source lines shorter than the applicable fixed-form length are treated as
6292 if they were padded with spaces to that length.
6293 (None of this is relevant to source files written in free form.)
6296 continued character and Hollerith constants, and is a different
6297 interpretation than provided by some other popular compilers
6298 (although a bit more consistent with the traditional punched-card
6299 basis of Fortran and the way the Fortran standard expressed fixed
6302 @code{g77} might someday offer an option to warn about cases where differences
6303 might be seen as a result of this treatment, and perhaps an option to
6304 specify the alternate behavior as well.
6306 Note that this padding cannot apply to lines that are effectively of
6307 infinite length---such lines are specified using command-line options
6308 like @samp{-ffixed-line-length-none}, for example.
6311 @subsection Long Lines
6312 @cindex long source lines
6313 @cindex truncation, of long lines
6315 @cindex source lines, long
6317 Source lines longer than the applicable length are truncated to that
6319 Currently, @code{g77} does not warn if the truncated characters are
6320 not spaces, to accommodate existing code written for systems that
6321 treated truncated text as commentary (especially in columns 73 through 80).
6323 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6324 for information on the @samp{-ffixed-line-length-@var{n}} option,
6325 which can be used to set the line length applicable to fixed-form
6329 @subsection Ampersand Continuation Line
6330 @cindex ampersand continuation line
6331 @cindex continuation line, ampersand
6333 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6334 continuation line, imitating the behavior of @code{f2c}.
6336 @node Trailing Comment
6337 @section Trailing Comment
6339 @cindex trailing comment
6341 @cindex characters, comment
6344 @cindex exclamation point
6345 @code{g77} supports use of @samp{/*} to start a trailing
6347 In the GNU Fortran language, @samp{!} is used for this purpose.
6349 @samp{/*} is not in the GNU Fortran language
6350 because the use of @samp{/*} in a program might
6351 suggest to some readers that a block, not trailing, comment is
6352 started (and thus ended by @samp{*/}, not end of line),
6353 since that is the meaning of @samp{/*} in C.
6355 Also, such readers might think they can use @samp{//} to start
6356 a trailing comment as an alternative to @samp{/*}, but
6357 @samp{//} already denotes concatenation, and such a ``comment''
6358 might actually result in a program that compiles without
6359 error (though it would likely behave incorrectly).
6364 @cindex comment line, debug
6366 Use of @samp{D} or @samp{d} as the first character (column 1) of
6367 a source line denotes a debug line.
6369 In turn, a debug line is treated as either a comment line
6370 or a normal line, depending on whether debug lines are enabled.
6372 When treated as a comment line, a line beginning with @samp{D} or
6373 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6374 When treated as a normal line, such a line is treated as if
6375 the first character was @key{SPC} (space).
6377 (Currently, @code{g77} provides no means for treating debug
6378 lines as normal lines.)
6381 @section Dollar Signs in Symbol Names
6385 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6386 when the @samp{-fdollar-ok} option is specified.
6388 @node Case Sensitivity
6389 @section Case Sensitivity
6390 @cindex case sensitivity
6391 @cindex source file format
6392 @cindex code, source
6394 @cindex uppercase letters
6395 @cindex lowercase letters
6396 @cindex letters, uppercase
6397 @cindex letters, lowercase
6399 GNU Fortran offers the programmer way too much flexibility in deciding
6400 how source files are to be treated vis-a-vis uppercase and lowercase
6402 There are 66 useful settings that affect case sensitivity, plus 10
6403 settings that are nearly useless, with the remaining 116 settings
6404 being either redundant or useless.
6406 None of these settings have any effect on the contents of comments
6407 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6408 or of character or Hollerith constants.
6409 Note that things like the @samp{E} in the statement
6410 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6411 are considered built-in keywords, and so are affected by
6414 Low-level switches are identified in this section as follows:
6418 Source Case Conversion:
6422 Preserve (see Note 1)
6424 Convert to Upper Case
6426 Convert to Lower Case
6430 Built-in Keyword Matching:
6434 Match Any Case (per-character basis)
6436 Match Upper Case Only
6438 Match Lower Case Only
6440 Match InitialCaps Only (see tables for spellings)
6444 Built-in Intrinsic Matching:
6448 Match Any Case (per-character basis)
6450 Match Upper Case Only
6452 Match Lower Case Only
6454 Match InitialCaps Only (see tables for spellings)
6458 User-defined Symbol Possibilities (warnings only):
6462 Allow Any Case (per-character basis)
6464 Allow Upper Case Only
6466 Allow Lower Case Only
6468 Allow InitialCaps Only (see Note 2)
6472 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6473 consistent with these source switches---in the sense that input will be
6474 expected to meet the same requirements as source code in terms
6475 of matching symbol names and keywords (for the exponent letters).
6477 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6478 which uppercases @code{NAMELIST} input and symbol names for matching.
6479 This means not only that @code{NAMELIST} output currently shows symbol
6480 (and keyword) names in uppercase even if lower-case source
6481 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6482 adequately supported when source case preservation (option A0)
6485 If A0 is selected, a warning message will be
6486 output for each @code{NAMELIST} statement to this effect.
6488 of the program is undefined at run time if two or more symbol names
6489 appear in a given @code{NAMELIST} such that the names are identical
6490 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6491 For complete and total elegance, perhaps there should be a warning
6492 when option A2 is selected, since the output of NAMELIST is currently
6493 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6494 but that seems to be overkill for a product in beta test.
6496 Note 2: Rules for InitialCaps names are:
6500 Must be a single uppercase letter, @strong{or}
6502 Must start with an uppercase letter and contain at least one
6506 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6507 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6509 Note that most, but not all, built-in names meet these
6510 requirements---the exceptions are some of the two-letter format
6511 specifiers, such as @code{BN} and @code{BZ}.
6513 Here are the names of the corresponding command-line options:
6516 A0: -fsource-case-preserve
6517 A1: -fsource-case-upper
6518 A2: -fsource-case-lower
6520 B0: -fmatch-case-any
6521 B1: -fmatch-case-upper
6522 B2: -fmatch-case-lower
6523 B3: -fmatch-case-initcap
6525 C0: -fintrin-case-any
6526 C1: -fintrin-case-upper
6527 C2: -fintrin-case-lower
6528 C3: -fintrin-case-initcap
6530 D0: -fsymbol-case-any
6531 D1: -fsymbol-case-upper
6532 D2: -fsymbol-case-lower
6533 D3: -fsymbol-case-initcap
6536 Useful combinations of the above settings, along with abbreviated
6537 option names that set some of these combinations all at once:
6540 1: A0-- B0--- C0--- D0--- -fcase-preserve
6541 2: A0-- B0--- C0--- D-1--
6542 3: A0-- B0--- C0--- D--2-
6543 4: A0-- B0--- C0--- D---3
6544 5: A0-- B0--- C-1-- D0---
6545 6: A0-- B0--- C-1-- D-1--
6546 7: A0-- B0--- C-1-- D--2-
6547 8: A0-- B0--- C-1-- D---3
6548 9: A0-- B0--- C--2- D0---
6549 10: A0-- B0--- C--2- D-1--
6550 11: A0-- B0--- C--2- D--2-
6551 12: A0-- B0--- C--2- D---3
6552 13: A0-- B0--- C---3 D0---
6553 14: A0-- B0--- C---3 D-1--
6554 15: A0-- B0--- C---3 D--2-
6555 16: A0-- B0--- C---3 D---3
6556 17: A0-- B-1-- C0--- D0---
6557 18: A0-- B-1-- C0--- D-1--
6558 19: A0-- B-1-- C0--- D--2-
6559 20: A0-- B-1-- C0--- D---3
6560 21: A0-- B-1-- C-1-- D0---
6561 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6562 23: A0-- B-1-- C-1-- D--2-
6563 24: A0-- B-1-- C-1-- D---3
6564 25: A0-- B-1-- C--2- D0---
6565 26: A0-- B-1-- C--2- D-1--
6566 27: A0-- B-1-- C--2- D--2-
6567 28: A0-- B-1-- C--2- D---3
6568 29: A0-- B-1-- C---3 D0---
6569 30: A0-- B-1-- C---3 D-1--
6570 31: A0-- B-1-- C---3 D--2-
6571 32: A0-- B-1-- C---3 D---3
6572 33: A0-- B--2- C0--- D0---
6573 34: A0-- B--2- C0--- D-1--
6574 35: A0-- B--2- C0--- D--2-
6575 36: A0-- B--2- C0--- D---3
6576 37: A0-- B--2- C-1-- D0---
6577 38: A0-- B--2- C-1-- D-1--
6578 39: A0-- B--2- C-1-- D--2-
6579 40: A0-- B--2- C-1-- D---3
6580 41: A0-- B--2- C--2- D0---
6581 42: A0-- B--2- C--2- D-1--
6582 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6583 44: A0-- B--2- C--2- D---3
6584 45: A0-- B--2- C---3 D0---
6585 46: A0-- B--2- C---3 D-1--
6586 47: A0-- B--2- C---3 D--2-
6587 48: A0-- B--2- C---3 D---3
6588 49: A0-- B---3 C0--- D0---
6589 50: A0-- B---3 C0--- D-1--
6590 51: A0-- B---3 C0--- D--2-
6591 52: A0-- B---3 C0--- D---3
6592 53: A0-- B---3 C-1-- D0---
6593 54: A0-- B---3 C-1-- D-1--
6594 55: A0-- B---3 C-1-- D--2-
6595 56: A0-- B---3 C-1-- D---3
6596 57: A0-- B---3 C--2- D0---
6597 58: A0-- B---3 C--2- D-1--
6598 59: A0-- B---3 C--2- D--2-
6599 60: A0-- B---3 C--2- D---3
6600 61: A0-- B---3 C---3 D0---
6601 62: A0-- B---3 C---3 D-1--
6602 63: A0-- B---3 C---3 D--2-
6603 64: A0-- B---3 C---3 D---3 -fcase-initcap
6604 65: A-1- B01-- C01-- D01-- -fcase-upper
6605 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6608 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6609 (except comments, character constants, and Hollerith strings) must
6610 be entered in uppercase.
6611 Use @samp{-fcase-strict-upper} to specify this
6614 Number 43 is like Number 22 except all input must be lowercase. Use
6615 @samp{-fcase-strict-lower} to specify this combination.
6617 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6618 non-UNIX machines whereby all the source is translated to uppercase.
6619 Use @samp{-fcase-upper} to specify this combination.
6621 Number 66 is the ``canonical'' UNIX model whereby all the source is
6622 translated to lowercase.
6623 Use @samp{-fcase-lower} to specify this combination.
6625 There are a few nearly useless combinations:
6628 67: A-1- B01-- C01-- D--2-
6629 68: A-1- B01-- C01-- D---3
6630 69: A-1- B01-- C--23 D01--
6631 70: A-1- B01-- C--23 D--2-
6632 71: A-1- B01-- C--23 D---3
6633 72: A--2 B01-- C0-2- D-1--
6634 73: A--2 B01-- C0-2- D---3
6635 74: A--2 B01-- C-1-3 D0-2-
6636 75: A--2 B01-- C-1-3 D-1--
6637 76: A--2 B01-- C-1-3 D---3
6640 The above allow some programs to be compiled but with restrictions that
6641 make most useful programs impossible: Numbers 67 and 72 warn about
6642 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6644 68 and 73 warn about any user-defined symbol names longer than one
6645 character that don't have at least one non-alphabetic character after
6647 Numbers 69 and 74 disallow any references to intrinsics;
6648 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6649 67+69, 68+69, 72+74, and 73+74, respectively.
6651 All redundant combinations are shown in the above tables anyplace
6652 where more than one setting is shown for a low-level switch.
6653 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6654 The ``proper'' setting in such a case is the one that copies the setting
6655 of switch A---any other setting might slightly reduce the speed of
6656 the compiler, though possibly to an unmeasurable extent.
6658 All remaining combinations are useless in that they prevent successful
6659 compilation of non-null source files (source files with something other
6663 @section VXT Fortran
6665 @cindex VXT extensions
6666 @cindex extensions, VXT
6667 @code{g77} supports certain constructs that
6668 have different meanings in VXT Fortran than they
6669 do in the GNU Fortran language.
6671 Generally, this manual uses the invented term VXT Fortran to refer
6672 VAX FORTRAN (circa v4).
6673 That compiler offered many popular features, though not necessarily
6674 those that are specific to the VAX processor architecture,
6675 the VMS operating system,
6676 or Digital Equipment Corporation's Fortran product line.
6677 (VAX and VMS probably are trademarks of Digital Equipment
6680 An extension offered by a Digital Fortran product that also is
6681 offered by several other Fortran products for different kinds of
6682 systems is probably going to be considered for inclusion in @code{g77}
6683 someday, and is considered a VXT Fortran feature.
6685 The @samp{-fvxt} option generally specifies that, where
6686 the meaning of a construct is ambiguous (means one thing
6687 in GNU Fortran and another in VXT Fortran), the VXT Fortran
6688 meaning is to be assumed.
6691 * Double Quote Meaning:: @samp{"2000} as octal constant.
6692 * Exclamation Point:: @samp{!} in column 6.
6695 @node Double Quote Meaning
6696 @subsection Meaning of Double Quote
6697 @cindex double quotes
6698 @cindex character constants
6699 @cindex constants, character
6700 @cindex octal constants
6701 @cindex constants, octal
6703 @code{g77} treats double-quote (@samp{"})
6704 as beginning an octal constant of @code{INTEGER(KIND=1)} type
6705 when the @samp{-fvxt} option is specified.
6706 The form of this octal constant is
6713 where @var{octal-digits} is a nonempty string of characters in
6714 the set @samp{01234567}.
6716 For example, the @samp{-fvxt} option permits this:
6724 The above program would print the value @samp{16}.
6726 @xref{Integer Type}, for information on the preferred construct
6727 for integer constants specified using GNU Fortran's octal notation.
6729 (In the GNU Fortran language, the double-quote character (@samp{"})
6730 delimits a character constant just as does apostrophe (@samp{'}).
6731 There is no way to allow
6732 both constructs in the general case, since statements like
6733 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
6735 @node Exclamation Point
6736 @subsection Meaning of Exclamation Point in Column 6
6738 @cindex exclamation point
6739 @cindex continuation character
6740 @cindex characters, continuation
6741 @cindex comment character
6742 @cindex characters, comment
6744 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
6745 a fixed-form source file
6746 as a continuation character rather than
6747 as the beginning of a comment
6748 (as it does in any other column)
6749 when the @samp{-fvxt} option is specified.
6751 The following program, when run, prints a message indicating
6752 whether it is interpreted according to GNU Fortran (and Fortran 90)
6753 rules or VXT Fortran rules:
6756 C234567 (This line begins in column 1.)
6759 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
6760 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
6761 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
6765 (In the GNU Fortran and Fortran 90 languages, exclamation point is
6766 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
6767 marks a line as a continuation line when it appears in column 6.)
6771 @cindex compatibility, Fortran 90
6772 @cindex Fortran 90, compatibility
6774 The GNU Fortran language includes a number of features that are
6775 part of Fortran 90, even when the @samp{-ff90} option is not specified.
6776 The features enabled by @samp{-ff90} are intended to be those that,
6777 when @samp{-ff90} is not specified, would have another
6778 meaning to @code{g77}---usually meaning something invalid in the
6779 GNU Fortran language.
6781 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
6782 to gratuitously reject Fortran 90 constructs.
6783 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
6784 to do that, although its implementation is certainly incomplete at
6787 When @samp{-ff90} is specified:
6791 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
6792 where @var{expr} is @code{COMPLEX} type,
6793 is the same type as the real part of @var{expr}.
6795 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
6796 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
6797 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
6800 @node Pedantic Compilation
6801 @section Pedantic Compilation
6802 @cindex pedantic compilation
6803 @cindex compilation, pedantic
6805 The @samp{-fpedantic} command-line option specifies that @code{g77}
6806 is to warn about code that is not standard-conforming.
6807 This is useful for finding
6808 some extensions @code{g77} accepts that other compilers might not accept.
6809 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
6810 always imply @samp{-fpedantic}.)
6812 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
6813 for conforming code.
6814 With @samp{-ff90} in force, Fortran 90 is used.
6816 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
6817 and @samp{-fno-f90} are in force are:
6821 Automatic arrays, as in
6830 where @samp{A} is not listed in any @code{ENTRY} statement,
6831 and thus is not a dummy argument.
6834 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
6836 These commas are disallowed by FORTRAN 77, but, while strictly
6837 superfluous, are syntactically elegant,
6838 especially given that commas are required in statements such
6839 as @samp{READ 99, I} and @samp{PRINT *, J}.
6840 Many compilers permit the superfluous commas for this reason.
6843 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
6845 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
6846 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
6848 An example of an implicit use is the expression @samp{C*D},
6849 where @samp{C} is @code{COMPLEX(KIND=1)}
6850 and @samp{D} is @code{DOUBLE PRECISION}.
6851 This expression is prohibited by ANSI FORTRAN 77
6852 because the rules of promotion would suggest that it
6853 produce a @code{DOUBLE COMPLEX} result---a type not
6854 provided for by that standard.
6857 Automatic conversion of numeric
6858 expressions to @code{INTEGER(KIND=1)} in contexts such as:
6862 Array-reference indexes.
6864 Alternate-return values.
6866 Computed @code{GOTO}.
6868 @code{FORMAT} run-time expressions (not yet supported).
6870 Dimension lists in specification statements.
6872 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
6874 Sizes of @code{CHARACTER} entities in specification statements.
6876 Kind types in specification entities (a Fortran 90 feature).
6878 Initial, terminal, and incrementation parameters for implied-@code{DO}
6879 constructs in @code{DATA} statements.
6883 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
6884 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
6885 expressions are disallowed anyway).
6888 Zero-size array dimensions, as in:
6891 INTEGER I(10,20,4:2)
6895 Zero-length @code{CHARACTER} entities, as in:
6902 Substring operators applied to character constants and named
6906 PRINT *, 'hello'(3:5)
6910 Null arguments passed to statement function, as in:
6917 Disagreement among program units regarding whether a given @code{COMMON}
6918 area is @code{SAVE}d (for targets where program units in a single source
6919 file are ``glued'' together as they typically are for UNIX development
6923 Disagreement among program units regarding the size of a
6924 named @code{COMMON} block.
6927 Specification statements following first @code{DATA} statement.
6929 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
6930 but not @samp{INTEGER I}.
6931 The @samp{-fpedantic} option disallows both of these.)
6934 Semicolon as statement separator, as in:
6941 @c Comma before list of I/O items in @code{WRITE}
6942 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
6943 @c statements, as with @code{READ} (as explained above).
6946 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
6949 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
6953 Expressions having two arithmetic operators in a row, such
6957 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
6958 following constructs result in diagnostics:
6962 Use of semicolon as a statement separator on a line
6963 that has an @code{INCLUDE} directive.
6967 @section Distensions
6969 @cindex ugly features
6970 @cindex features, ugly
6972 The @samp{-fugly-*} command-line options determine whether certain
6973 features supported by VAX FORTRAN and other such compilers, but considered
6974 too ugly to be in code that can be changed to use safer and/or more
6975 portable constructs, are accepted.
6976 These are humorously referred to as ``distensions'',
6977 extensions that just plain look ugly in the harsh light of day.
6980 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
6981 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
6982 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
6983 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
6984 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
6985 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
6986 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
6989 @node Ugly Implicit Argument Conversion
6990 @subsection Implicit Argument Conversion
6991 @cindex Hollerith constants
6992 @cindex constants, Hollerith
6994 The @samp{-fno-ugly-args} option disables
6995 passing typeless and Hollerith constants as actual arguments
6996 in procedure invocations.
7005 These constructs can be too easily used to create non-portable
7006 code, but are not considered as ``ugly'' as others.
7007 Further, they are widely used in existing Fortran source code
7008 in ways that often are quite portable.
7009 Therefore, they are enabled by default.
7011 @node Ugly Assumed-Size Arrays
7012 @subsection Ugly Assumed-Size Arrays
7013 @cindex arrays, assumed-size
7014 @cindex assumed-size arrays
7015 @cindex DIMENSION X(1)
7017 The @samp{-fugly-assumed} option enables
7018 the treatment of any array with a final dimension specified as @samp{1}
7019 as an assumed-size array, as if @samp{*} had been specified
7022 For example, @samp{DIMENSION X(1)} is treated as if it
7023 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
7024 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
7025 or @code{ENTRY} statement in the same program unit.
7027 Use an explicit lower bound to avoid this interpretation.
7028 For example, @samp{DIMENSION X(1:1)} is never treated as if
7029 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
7030 Nor is @samp{DIMENSION X(2-1)} affected by this option,
7031 since that kind of expression is unlikely to have been
7032 intended to designate an assumed-size array.
7034 This option is used to prevent warnings being issued about apparent
7035 out-of-bounds reference such as @samp{X(2) = 99}.
7037 It also prevents the array from being used in contexts that
7038 disallow assumed-size arrays, such as @samp{PRINT *,X}.
7039 In such cases, a diagnostic is generated and the source file is
7042 The construct affected by this option is used only in old code
7043 that pre-exists the widespread acceptance of adjustable and assumed-size
7044 arrays in the Fortran community.
7046 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
7047 treated if @samp{X} is listed as a dummy argument only
7048 @emph{after} the @code{DIMENSION} statement (presumably in
7049 an @code{ENTRY} statement).
7050 For example, @samp{-fugly-assumed} has no effect on the
7051 following program unit:
7062 @node Ugly Complex Part Extraction
7063 @subsection Ugly Complex Part Extraction
7064 @cindex complex values
7066 @cindex imaginary part
7068 The @samp{-fugly-complex} option enables
7069 use of the @code{REAL()} and @code{AIMAG()}
7070 intrinsics with arguments that are
7071 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
7073 With @samp{-ff90} in effect, these intrinsics return
7074 the unconverted real and imaginary parts (respectively)
7077 With @samp{-fno-f90} in effect, these intrinsics convert
7078 the real and imaginary parts to @code{REAL(KIND=1)}, and return
7079 the result of that conversion.
7081 Due to this ambiguity, the GNU Fortran language defines
7082 these constructs as invalid, except in the specific
7083 case where they are entirely and solely passed as an
7084 argument to an invocation of the @code{REAL()} intrinsic.
7092 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7093 and @samp{-fno-ugly-complex} is in effect, because the
7096 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7097 is specified, in which case the appropriate interpretation is
7098 chosen and no diagnostic is issued.
7100 @xref{CMPAMBIG}, for information on how to cope with existing
7101 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7102 with @code{COMPLEX(KIND=2)} arguments.
7104 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7105 intrinsic, used to extract the real part of a complex expression
7107 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7108 intrinsic, used to extract the imaginary part of a complex expression
7111 @node Ugly Null Arguments
7112 @subsection Ugly Null Arguments
7113 @cindex trailing comma
7114 @cindex comma, trailing
7115 @cindex characters, comma
7116 @cindex null arguments
7117 @cindex arguments, null
7119 The @samp{-fugly-comma} option enables use of a single trailing comma
7120 to mean ``pass an extra trailing null argument''
7121 in a list of actual arguments to an external procedure,
7122 and use of an empty list of arguments to such a procedure
7123 to mean ``pass a single null argument''.
7125 @cindex omitting arguments
7126 @cindex arguments, omitting
7127 (Null arguments often are used in some procedure-calling
7128 schemes to indicate omitted arguments.)
7130 For example, @samp{CALL FOO(,)} means ``pass
7131 two null arguments'', rather than ``pass one null argument''.
7132 Also, @samp{CALL BAR()} means ``pass one null argument''.
7134 This construct is considered ``ugly'' because it does not
7135 provide an elegant way to pass a single null argument
7136 that is syntactically distinct from passing no arguments.
7137 That is, this construct changes the meaning of code that
7138 makes no use of the construct.
7140 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7141 and @samp{I = JFUNC()} pass a single null argument, instead
7142 of passing no arguments as required by the Fortran 77 and
7145 @emph{Note:} Many systems gracefully allow the case
7146 where a procedure call passes one extra argument that the
7147 called procedure does not expect.
7149 So, in practice, there might be no difference in
7150 the behavior of a program that does @samp{CALL FOO()}
7151 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7152 in force as compared to its behavior when compiled
7153 with the default, @samp{-fno-ugly-comma}, in force,
7154 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7155 arguments to be passed.
7157 @node Ugly Conversion of Initializers
7158 @subsection Ugly Conversion of Initializers
7160 The constructs disabled by @samp{-fno-ugly-init} are:
7163 @cindex Hollerith constants
7164 @cindex constants, Hollerith
7166 Use of Hollerith and typeless constants in contexts where they set
7167 initial (compile-time) values for variables, arrays, and named
7168 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7169 type-declaration statements specifying initial values.
7171 Here are some sample initializations that are disabled by the
7172 @samp{-fno-ugly-init} option:
7175 PARAMETER (VAL='9A304FFE'X)
7176 REAL*8 STRING/8HOUTPUT00/
7180 @cindex character constants
7181 @cindex constants, character
7183 In the same contexts as above, use of character constants to initialize
7184 numeric items and vice versa (one constant per item).
7186 Here are more sample initializations that are disabled by the
7187 @samp{-fno-ugly-init} option:
7192 PARAMETER (IA = 'A')
7193 PARAMETER (BELL = 7)
7197 Use of Hollerith and typeless constants on the right-hand side
7198 of assignment statements to numeric types, and in other
7199 contexts (such as passing arguments in invocations of
7200 intrinsic procedures and statement functions) that
7201 are treated as assignments to known types (the dummy
7202 arguments, in these cases).
7204 Here are sample statements that are disabled by the
7205 @samp{-fno-ugly-init} option:
7209 PRINT *, IMAX0(2HAB, 2HBA)
7213 The above constructs, when used,
7214 can tend to result in non-portable code.
7215 But, they are widely used in existing Fortran code in ways
7216 that often are quite portable.
7217 Therefore, they are enabled by default.
7219 @node Ugly Integer Conversions
7220 @subsection Ugly Integer Conversions
7222 The constructs enabled via @samp{-fugly-logint} are:
7226 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7228 context (typically implies nonportable dependencies on how a
7229 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7232 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7236 The above constructs are disabled by default because use
7237 of them tends to lead to non-portable code.
7238 Even existing Fortran code that uses that often turns out
7239 to be non-portable, if not outright buggy.
7241 Some of this is due to differences among implementations as
7242 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7243 @code{INTEGER} values---Fortran code that assumes a particular
7244 coding is likely to use one of the above constructs, and is
7245 also likely to not work correctly on implementations using
7246 different encodings.
7248 @xref{Equivalence Versus Equality}, for more information.
7250 @node Ugly Assigned Labels
7251 @subsection Ugly Assigned Labels
7252 @cindex ASSIGN statement
7253 @cindex statements, ASSIGN
7254 @cindex assigned labels
7257 The @samp{-fugly-assign} option forces @code{g77} to use the
7258 same storage for assigned labels as it would for a normal
7259 assignment to the same variable.
7261 For example, consider the following code fragment:
7269 Normally, for portability and improved diagnostics, @code{g77}
7270 reserves distinct storage for a ``sibling'' of @samp{I}, used
7271 only for @code{ASSIGN} statements to that variable (along with
7272 the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
7273 statements that reference the variable).
7275 However, some code (that violates the ANSI FORTRAN 77 standard)
7276 attempts to copy assigned labels among variables involved with
7277 @code{ASSIGN} statements, as in:
7288 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7289 is specified on the command-line, ensuring that the value of @code{I}
7290 referenced in the second line is whatever value @code{g77} uses
7291 to designate statement label @samp{10}, so the value may be
7292 copied into the @samp{ISTATE} array, later retrieved into a
7293 variable of the appropriate type (@samp{J}), and used as the target of
7294 an assigned-@code{GOTO} statement.
7296 @emph{Note:} To avoid subtle program bugs,
7297 when @samp{-fugly-assign} is specified,
7298 @code{g77} requires the type of variables
7299 specified in assigned-label contexts
7300 @emph{must} be the same type returned by @code{%LOC()}.
7301 On many systems, this type is effectively the same
7302 as @code{INTEGER(KIND=1)}, while, on others, it is
7303 effectively the same as @code{INTEGER(KIND=2)}.
7305 Do @emph{not} depend on @code{g77} actually writing valid pointers
7306 to these variables, however.
7307 While @code{g77} currently chooses that implementation, it might
7308 be changed in the future.
7310 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7311 for implementation details on assigned-statement labels.
7314 @chapter The GNU Fortran Compiler
7316 The GNU Fortran compiler, @code{g77}, supports programs written
7317 in the GNU Fortran language and in some other dialects of Fortran.
7319 Some aspects of how @code{g77} works are universal regardless
7320 of dialect, and yet are not properly part of the GNU Fortran
7322 These are described below.
7324 @emph{Note: This portion of the documentation definitely needs a lot
7329 * Run-time Environment Limits::
7331 * Compiler Constants::
7332 * Compiler Intrinsics::
7335 @node Compiler Limits
7336 @section Compiler Limits
7337 @cindex limits, compiler
7338 @cindex compiler limits
7340 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7341 on lengths of identifiers, number of continuation lines, number of external
7342 symbols in a program, and so on.
7344 @cindex options, -Nl
7346 @cindex options, -Nx
7348 @cindex limits, continuation lines
7349 @cindex limits, lengths of names
7350 For example, some other Fortran compiler have an option
7351 (such as @samp{-Nl@var{x}}) to increase the limit on the
7352 number of continuation lines.
7353 Also, some Fortran compilation systems have an option
7354 (such as @samp{-Nx@var{x}}) to increase the limit on the
7355 number of external symbols.
7357 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7358 no equivalent options, since they do not impose arbitrary
7359 limits in these areas.
7361 @cindex rank, maximum
7362 @cindex maximum rank
7363 @cindex number of dimensions, maximum
7364 @cindex maximum number of dimensions
7365 @cindex limits, rank
7366 @cindex limits, array dimensions
7367 @code{g77} does currently limit the number of dimensions in an array
7368 to the same degree as do the Fortran standards---seven (7).
7369 This restriction might be lifted in a future version.
7371 @node Run-time Environment Limits
7372 @section Run-time Environment Limits
7373 @cindex limits, run-time library
7376 As a portable Fortran implementation,
7377 @code{g77} offers its users direct access to,
7378 and otherwise depends upon,
7379 the underlying facilities of the system
7380 used to build @code{g77},
7381 the system on which @code{g77} itself is used to compile programs,
7382 and the system on which the @code{g77}-compiled program is actually run.
7383 (For most users, the three systems are of the same
7384 type---combination of operating environment and hardware---often
7385 the same physical system.)
7387 The run-time environment for a particular system
7388 inevitably imposes some limits on a program's use
7389 of various system facilities.
7390 These limits vary from system to system.
7392 Even when such limits might be well beyond the
7393 possibility of being encountered on a particular system,
7394 the @code{g77} run-time environment
7395 has certain built-in limits,
7396 usually, but not always, stemming from intrinsics
7397 with inherently limited interfaces.
7399 Currently, the @code{g77} run-time environment
7400 does not generally offer a less-limiting environment
7401 by augmenting the underlying system's own environment.
7403 Therefore, code written in the GNU Fortran language,
7404 while syntactically and semantically portable,
7405 might nevertheless make non-portable assumptions
7406 about the run-time environment---assumptions that
7407 prove to be false for some particular environments.
7409 The GNU Fortran language,
7410 the @code{g77} compiler and run-time environment,
7411 and the @code{g77} documentation
7412 do not yet offer comprehensive portable work-arounds for such limits,
7413 though programmers should be able to
7414 find their own in specific instances.
7416 Not all of the limitations are described in this document.
7417 Some of the known limitations include:
7420 * Timer Wraparounds::
7421 * Year 2000 (Y2K) Problems::
7423 * Character-variable Length::
7424 * Year 10000 (Y10K) Problems::
7427 @node Timer Wraparounds
7428 @subsection Timer Wraparounds
7430 Intrinsics that return values computed from system timers,
7431 whether elapsed (wall-clock) timers,
7433 or other kinds of timers,
7434 are prone to experiencing wrap-around errors
7435 (or returning wrapped-around values from successive calls)
7436 due to insufficient ranges
7437 offered by the underlying system's timers.
7439 @cindex negative time
7442 Some of the symptoms of such behaviors include
7443 apparently negative time being computed for a duration,
7444 an extremely short amount of time being computed for a long duration,
7445 and an extremely long amount of time being computed for a short duration.
7447 See the following for intrinsics
7448 known to have potential problems in these areas
7449 on at least some systems:
7450 @ref{CPU_Time Intrinsic},
7451 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
7452 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
7453 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
7454 @ref{Secnds Intrinsic},
7455 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
7456 @ref{System_Clock Intrinsic},
7457 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
7458 @ref{Time8 Intrinsic}.
7460 @node Year 2000 (Y2K) Problems
7461 @subsection Year 2000 (Y2K) Problems
7462 @cindex Y2K compliance
7463 @cindex Year 2000 compliance
7465 While the @code{g77} compiler itself is believed to
7466 be Year-2000 (Y2K) compliant,
7467 some intrinsics are not,
7468 and, potentially, some underlying systems are not,
7469 perhaps rendering some Y2K-compliant intrinsics
7470 non-compliant when used on those particular systems.
7472 Fortran code that uses non-Y2K-compliant intrinsics
7474 is, itself, almost certainly not compliant,
7475 and should be modified to use Y2K-compliant intrinsics instead.
7477 Fortran code that uses no non-Y2K-compliant intrinsics,
7478 but which currently is running on a non-Y2K-compliant system,
7479 can be made more Y2K compliant by compiling and
7480 linking it for use on a new Y2K-compliant system,
7481 such as a new version of an old, non-Y2K-compliant, system.
7483 Currently, information on Y2K and related issues
7484 is being maintained at
7485 @uref{http://www.gnu.org/software/year2000-list.html}.
7487 See the following for intrinsics
7488 known to have potential problems in these areas
7489 on at least some systems:
7490 @ref{Date Intrinsic},
7491 @ref{IDate Intrinsic (VXT)}.
7494 @cindex date_y2kbuggy_0
7495 @cindex vxtidate_y2kbuggy_0
7496 @cindex G77_date_y2kbuggy_0
7497 @cindex G77_vxtidate_y2kbuggy_0
7498 The @code{libg2c} library
7499 shipped with any @code{g77} that warns
7500 about invocation of a non-Y2K-compliant intrinsic
7501 has renamed the @code{EXTERNAL} procedure names
7502 of those intrinsics.
7503 This is done so that
7504 the @code{libg2c} implementations of these intrinsics
7505 cannot be directly linked to
7506 as @code{EXTERNAL} names
7507 (which normally would avoid the non-Y2K-intrinsic warning).
7509 The renamed forms of the @code{EXTERNAL} names
7510 of these renamed procedures
7512 by appending the string @samp{_y2kbug}
7513 to the name of the procedure
7520 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
7521 CALL DATE_Y2KBUG (STR)
7522 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
7525 (Note that the @code{EXTERNAL} statement
7526 is not actually required,
7527 since the modified names are not recognized as intrinsics
7528 by the current version of @code{g77}.
7529 But it is shown in this specific case,
7530 for purposes of illustration.)
7532 The renaming of @code{EXTERNAL} procedure names of these intrinsics
7533 causes unresolved references at link time.
7534 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
7535 is normally compiled by @code{g77}
7536 as, in C, @samp{date_(&str, 20);}.
7537 This, in turn, links to the @code{date_} procedure
7538 in the @code{libE77} portion of @code{libg2c},
7539 which purposely calls a nonexistent procedure
7540 named @code{G77_date_y2kbuggy_0}.
7541 The resulting link-time error is designed, via this name,
7542 to encourage the programmer to look up the
7543 index entries to this portion of the @code{g77} documentation.
7545 Generally, we recommend that the @code{EXTERNAL} method
7546 of invoking procedures in @code{libg2c}
7548 When used, some of the correctness checking
7549 normally performed by @code{g77}
7552 In particular, it is probably better to use the
7553 @code{INTRINSIC} method of invoking
7554 non-Y2K-compliant procedures,
7555 so anyone compiling the code
7556 can quickly notice the potential Y2K problems
7557 (via the warnings printing by @code{g77})
7558 without having to even look at the code itself.
7560 If there are problems linking @code{libg2c}
7561 to code compiled by @code{g77}
7562 that involve the string @samp{y2kbug},
7563 and these are not explained above,
7564 that probably indicates
7565 that a version of @code{libg2c}
7566 older than @code{g77}
7568 or that the new library is being linked
7569 to code compiled by an older version of @code{g77}.
7571 That's because, as of the version that warns about
7572 non-Y2K-compliant intrinsic invocation,
7573 @code{g77} references the @code{libg2c} implementations
7575 using new names, containing the string @samp{y2kbug}.
7577 So, linking newly-compiled code
7578 (invoking one of the intrinsics in question)
7580 might yield an unresolved reference
7581 to @code{G77_date_y2kbug_0}.
7582 (The old library calls it @code{G77_date_0}.)
7584 Similarly, linking previously-compiled code
7586 might yield an unresolved reference
7587 to @code{G77_vxtidate_0}.
7588 (The new library calls it @code{G77_vxtidate_y2kbug_0}.)
7590 The proper fix for the above problems
7591 is to obtain the latest release of @code{g77}
7592 and related products
7593 (including @code{libg2c})
7594 and install them on all systems,
7595 then recompile, relink, and install
7597 all existing Fortran programs.
7599 (Normally, this sort of renaming is steadfastly avoided.
7600 In this case, however, it seems more important to highlight
7601 potential Y2K problems
7602 than to ease the transition
7603 of potentially non-Y2K-compliant code
7604 to new versions of @code{g77} and @code{libg2c}.)
7607 @subsection Array Size
7608 @cindex limits, array size
7611 Currently, @code{g77} uses the default @code{INTEGER} type
7613 which limits the sizes of single-dimension arrays
7614 on systems offering a larger address space
7615 than can be addressed by that type.
7616 (That @code{g77} puts all arrays in memory
7617 could be considered another limitation---it
7618 could use large temporary files---but that decision
7619 is left to the programmer as an implementation choice
7620 by most Fortran implementations.)
7622 @c ??? Investigate this, to offer a more clear statement
7623 @c than the following paragraphs do. -- burley 1999-02-17
7624 It is not yet clear whether this limitation
7625 never, sometimes, or always applies to the
7626 sizes of multiple-dimension arrays as a whole.
7628 For example, on a system with 64-bit addresses
7629 and 32-bit default @code{INTEGER},
7630 an array with a size greater than can be addressed
7632 can be declared using multiple dimensions.
7633 Such an array is therefore larger
7634 than a single-dimension array can be,
7637 @cindex limits, multi-dimension arrays
7638 @cindex multi-dimension arrays
7639 @cindex arrays, dimensioning
7640 Whether large multiple-dimension arrays are reliably supported
7641 depends mostly on the @code{gcc} back end (code generator)
7642 used by @code{g77}, and has not yet been fully investigated.
7644 @node Character-variable Length
7645 @subsection Character-variable Length
7646 @cindex limits, on character-variable length
7647 @cindex character-variable length
7649 Currently, @code{g77} uses the default @code{INTEGER} type
7650 for the lengths of @code{CHARACTER} variables
7653 This means that, for example,
7654 a system with a 64-bit address space
7655 and a 32-bit default @code{INTEGER} type
7656 does not, under @code{g77},
7657 support a @code{CHARACTER*@var{n}} declaration
7658 where @var{n} is greater than 2147483647.
7660 @node Year 10000 (Y10K) Problems
7661 @subsection Year 10000 (Y10K) Problems
7662 @cindex Y10K compliance
7663 @cindex Year 10000 compliance
7665 Most intrinsics returning, or computing values based on,
7666 date information are prone to Year-10000 (Y10K) problems,
7667 due to supporting only 4 digits for the year.
7669 See the following for examples:
7670 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
7671 @ref{IDate Intrinsic (UNIX)},
7672 @ref{Time Intrinsic (VXT)},
7673 @ref{Date_and_Time Intrinsic}.
7675 @node Compiler Types
7676 @section Compiler Types
7677 @cindex types, of data
7680 Fortran implementations have a fair amount of freedom given them by the
7681 standard as far as how much storage space is used and how much precision
7682 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7683 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7684 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7685 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7686 the interpretation of @var{n} varies across compilers and target architectures.
7688 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7689 and @code{REAL(KIND=1)}
7690 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7691 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7692 Further, it requires that @code{COMPLEX(KIND=1)}
7693 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7694 storage-associated (such as via @code{EQUIVALENCE})
7695 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7696 corresponds to the real element and @samp{R(2)} to the imaginary
7697 element of the @code{COMPLEX(KIND=1)} variable.
7699 (Few requirements as to precision or ranges of any of these are
7700 placed on the implementation, nor is the relationship of storage sizes of
7701 these types to the @code{CHARACTER} type specified, by the standard.)
7703 @code{g77} follows the above requirements, warning when compiling
7704 a program requires placement of items in memory that contradict the
7705 requirements of the target architecture.
7706 (For example, a program can require placement of a @code{REAL(KIND=2)}
7707 on a boundary that is not an even multiple of its size, but still an
7708 even multiple of the size of a @code{REAL(KIND=1)} variable.
7709 On some target architectures, using the canonical
7710 mapping of Fortran types to underlying architectural types, such
7711 placement is prohibited by the machine definition or
7712 the Application Binary Interface (ABI) in force for
7713 the configuration defined for building @code{gcc} and @code{g77}.
7714 @code{g77} warns about such
7715 situations when it encounters them.)
7717 @code{g77} follows consistent rules for configuring the mapping between Fortran
7718 types, including the @samp{*@var{n}} notation, and the underlying architectural
7719 types as accessed by a similarly-configured applicable version of the
7720 @code{gcc} compiler.
7721 These rules offer a widely portable, consistent Fortran/C
7722 environment, although they might well conflict with the expectations of
7723 users of Fortran compilers designed and written for particular
7726 These rules are based on the configuration that is in force for the
7727 version of @code{gcc} built in the same release as @code{g77} (and
7728 which was therefore used to build both the @code{g77} compiler
7729 components and the @code{libg2c} run-time library):
7732 @cindex REAL(KIND=1) type
7733 @cindex types, REAL(KIND=1)
7735 Same as @code{float} type.
7737 @cindex REAL(KIND=2) type
7738 @cindex types, REAL(KIND=2)
7740 Same as whatever floating-point type that is twice the size
7741 of a @code{float}---usually, this is a @code{double}.
7743 @cindex INTEGER(KIND=1) type
7744 @cindex types, INTEGER(KIND=1)
7745 @item INTEGER(KIND=1)
7746 Same as an integral type that is occupies the same amount
7747 of memory storage as @code{float}---usually, this is either
7748 an @code{int} or a @code{long int}.
7750 @cindex LOGICAL(KIND=1) type
7751 @cindex types, LOGICAL(KIND=1)
7752 @item LOGICAL(KIND=1)
7753 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7755 @cindex INTEGER(KIND=2) type
7756 @cindex types, INTEGER(KIND=2)
7757 @item INTEGER(KIND=2)
7758 Twice the size, and usually nearly twice the range,
7759 as @code{INTEGER(KIND=1)}---usually, this is either
7760 a @code{long int} or a @code{long long int}.
7762 @cindex LOGICAL(KIND=2) type
7763 @cindex types, LOGICAL(KIND=2)
7764 @item LOGICAL(KIND=2)
7765 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7767 @cindex INTEGER(KIND=3) type
7768 @cindex types, INTEGER(KIND=3)
7769 @item INTEGER(KIND=3)
7770 Same @code{gcc} type as signed @code{char}.
7772 @cindex LOGICAL(KIND=3) type
7773 @cindex types, LOGICAL(KIND=3)
7774 @item LOGICAL(KIND=3)
7775 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7777 @cindex INTEGER(KIND=6) type
7778 @cindex types, INTEGER(KIND=6)
7779 @item INTEGER(KIND=6)
7780 Twice the size, and usually nearly twice the range,
7781 as @code{INTEGER(KIND=3)}---usually, this is
7784 @cindex LOGICAL(KIND=6) type
7785 @cindex types, LOGICAL(KIND=6)
7786 @item LOGICAL(KIND=6)
7787 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7789 @cindex COMPLEX(KIND=1) type
7790 @cindex types, COMPLEX(KIND=1)
7791 @item COMPLEX(KIND=1)
7792 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7793 one for the imaginary part).
7795 @cindex COMPLEX(KIND=2) type
7796 @cindex types, COMPLEX(KIND=2)
7797 @item COMPLEX(KIND=2)
7798 Two @code{REAL(KIND=2)} scalars.
7800 @cindex *@var{n} notation
7801 @item @var{numeric-type}*@var{n}
7802 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7803 Same as whatever @code{gcc} type occupies @var{n} times the storage
7804 space of a @code{gcc} @code{char} item.
7806 @cindex DOUBLE PRECISION type
7807 @cindex types, DOUBLE PRECISION
7808 @item DOUBLE PRECISION
7809 Same as @code{REAL(KIND=2)}.
7811 @cindex DOUBLE COMPLEX type
7812 @cindex types, DOUBLE COMPLEX
7813 @item DOUBLE COMPLEX
7814 Same as @code{COMPLEX(KIND=2)}.
7817 Note that the above are proposed correspondences and might change
7818 in future versions of @code{g77}---avoid writing code depending
7821 Other types supported by @code{g77}
7822 are derived from gcc types such as @code{char}, @code{short},
7823 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7825 That is, whatever types @code{gcc} already supports, @code{g77} supports
7826 now or probably will support in a future version.
7827 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7828 apply to these types,
7829 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7830 assigned in a way that encourages clarity, consistency, and portability.
7832 @node Compiler Constants
7833 @section Compiler Constants
7835 @cindex types, constants
7837 @code{g77} strictly assigns types to @emph{all} constants not
7838 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7840 Many other Fortran compilers attempt to assign types to typed constants
7841 based on their context.
7842 This results in hard-to-find bugs, nonportable
7843 code, and is not in the spirit (though it strictly follows the letter)
7844 of the 77 and 90 standards.
7846 @code{g77} might offer, in a future release, explicit constructs by
7847 which a wider variety of typeless constants may be specified, and/or
7848 user-requested warnings indicating places where @code{g77} might differ
7849 from how other compilers assign types to constants.
7851 @xref{Context-Sensitive Constants}, for more information on this issue.
7853 @node Compiler Intrinsics
7854 @section Compiler Intrinsics
7856 @code{g77} offers an ever-widening set of intrinsics.
7857 Currently these all are procedures (functions and subroutines).
7859 Some of these intrinsics are unimplemented, but their names reserved
7860 to reduce future problems with existing code as they are implemented.
7861 Others are implemented as part of the GNU Fortran language, while
7862 yet others are provided for compatibility with other dialects of
7863 Fortran but are not part of the GNU Fortran language.
7865 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7866 a facility that is simply an extension of the intrinsic groups provided
7867 by the GNU Fortran language.
7870 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7871 * Other Intrinsics:: Intrinsics other than those in the GNU
7875 @node Intrinsic Groups
7876 @subsection Intrinsic Groups
7877 @cindex groups of intrinsics
7878 @cindex intrinsics, groups
7880 A given specific intrinsic belongs in one or more groups.
7881 Each group is deleted, disabled, hidden, or enabled
7882 by default or a command-line option.
7883 The meaning of each term follows.
7886 @cindex deleted intrinsics
7887 @cindex intrinsics, deleted
7889 No intrinsics are recognized as belonging to that group.
7891 @cindex disabled intrinsics
7892 @cindex intrinsics, disabled
7894 Intrinsics are recognized as belonging to the group, but
7895 references to them (other than via the @code{INTRINSIC} statement)
7896 are disallowed through that group.
7898 @cindex hidden intrinsics
7899 @cindex intrinsics, hidden
7901 Intrinsics in that group are recognized and enabled (if implemented)
7902 @emph{only} if the first mention of the actual name of an intrinsic
7903 in a program unit is in an @code{INTRINSIC} statement.
7905 @cindex enabled intrinsics
7906 @cindex intrinsics, enabled
7908 Intrinsics in that group are recognized and enabled (if implemented).
7911 The distinction between deleting and disabling a group is illustrated
7912 by the following example.
7913 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7914 If group @samp{FGR} is deleted, the following program unit will
7915 successfully compile, because @samp{FOO()} will be seen as a
7916 reference to an external function named @samp{FOO}:
7924 If group @samp{FGR} is disabled, compiling the above program will produce
7925 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7926 or, if properly invoked, it is not enabled.
7927 To change the above program so it references an external function @samp{FOO}
7928 instead of the disabled @samp{FOO} intrinsic,
7929 add the following line to the top:
7936 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7937 that group do not exist at all, whereas disabling it tells @code{g77} to
7938 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7940 Hiding a group is like enabling it, but the intrinsic must be first
7941 named in an @code{INTRINSIC} statement to be considered a reference to the
7942 intrinsic rather than to an external procedure.
7943 This might be the ``safest'' way to treat a new group of intrinsics
7945 code, because it allows the old code to be generally written as if
7946 those new intrinsics never existed, but to be changed to use them
7947 by inserting @code{INTRINSIC} statements in the appropriate places.
7948 However, it should be the goal of development to use @code{EXTERNAL}
7949 for all names of external procedures that might be intrinsic names.
7951 If an intrinsic is in more than one group, it is enabled if any of its
7952 containing groups are enabled; if not so enabled, it is hidden if
7953 any of its containing groups are hidden; if not so hidden, it is disabled
7954 if any of its containing groups are disabled; if not so disabled, it is
7956 This extra complication is necessary because some intrinsics,
7957 such as @code{IBITS}, belong to more than one group, and hence should be
7958 enabled if any of the groups to which they belong are enabled, and so
7963 @cindex intrinsics, groups of
7964 @cindex groups of intrinsics
7966 @cindex @code{badu77} intrinsics group
7968 UNIX intrinsics having inappropriate forms (usually functions that
7969 have intended side effects).
7971 @cindex @code{gnu} intrinsics group
7973 Intrinsics the GNU Fortran language supports that are extensions to
7974 the Fortran standards (77 and 90).
7976 @cindex @code{f2c} intrinsics group
7978 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
7980 @cindex @code{f90} intrinsics group
7982 Fortran 90 intrinsics.
7984 @cindex @code{mil} intrinsics group
7986 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
7988 @cindex @code{mil} intrinsics group
7990 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
7992 @cindex @code{mil} intrinsics group
7994 VAX/VMS FORTRAN (current as of v4) intrinsics.
7997 @node Other Intrinsics
7998 @subsection Other Intrinsics
7999 @cindex intrinsics, others
8000 @cindex other intrinsics
8002 @code{g77} supports intrinsics other than those in the GNU Fortran
8004 This set of intrinsics is described below.
8007 (Note that the empty lines appearing in the menu below
8008 are not intentional---they result from a bug in the
8009 @code{makeinfo} program.)
8012 @c The actual documentation for intrinsics comes from
8013 @c intdoc.texi, which in turn is automatically generated
8014 @c from the internal g77 tables in intrin.def _and_ the
8015 @c largely hand-written text in intdoc.h. So, if you want
8016 @c to change or add to existing documentation on intrinsics,
8017 @c you probably want to edit intdoc.h.
8029 @include intdoc.texi
8031 @node Other Compilers
8032 @chapter Other Compilers
8034 An individual Fortran source file can be compiled to
8035 an object (@file{*.o}) file instead of to the final
8037 This allows several portions of a program to be compiled
8038 at different times and linked together whenever a new
8039 version of the program is needed.
8040 However, it introduces the issue of @dfn{object compatibility}
8041 across the various object files (and libraries, or @file{*.a}
8042 files) that are linked together to produce any particular
8045 Object compatibility is an issue when combining, in one
8046 program, Fortran code compiled by more than one compiler
8047 (or more than one configuration of a compiler).
8049 disagree on how to transform the names of procedures, there
8050 will normally be errors when linking such programs.
8051 Worse, if the compilers agree on naming, but disagree on issues
8052 like how to pass parameters, return arguments, and lay out
8053 @code{COMMON} areas, the earliest detected errors might be the
8054 incorrect results produced by the program (and that assumes
8055 these errors are detected, which is not always the case).
8057 Normally, @code{g77} generates code that is
8058 object-compatible with code generated by a version of
8059 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
8060 to be generally compatible with @code{g77} as built by @code{gcc}.
8061 (Normally, @code{f2c} will, by default, conform to the appropriate
8062 configuration, but it is possible that older or perhaps even newer
8063 versions of @code{f2c}, or versions having certain configuration changes
8064 to @code{f2c} internals, will produce object files that are
8065 incompatible with @code{g77}.)
8067 For example, a Fortran string subroutine
8068 argument will become two arguments on the C side: a @code{char *}
8069 and an @code{int} length.
8071 Much of this compatibility results from the fact that
8072 @code{g77} uses the same run-time library,
8073 @code{libf2c}, used by @code{f2c},
8074 though @code{g77} gives its version the name @code{libg2c}
8075 so as to avoid conflicts when linking,
8076 installing them in the same directories,
8079 Other compilers might or might not generate code that
8080 is object-compatible with @code{libg2c} and current @code{g77},
8081 and some might offer such compatibility only when explicitly
8082 selected via a command-line option to the compiler.
8084 @emph{Note: This portion of the documentation definitely needs a lot
8088 * Dropping f2c Compatibility:: When speed is more important.
8089 * Compilers Other Than f2c:: Interoperation with code from other compilers.
8092 @node Dropping f2c Compatibility
8093 @section Dropping @code{f2c} Compatibility
8095 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
8096 some cases, faster code, by not needing to allow to the possibility
8097 of linking with code compiled by @code{f2c}.
8099 For example, this affects how @code{REAL(KIND=1)},
8100 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
8101 With @samp{-fno-f2c}, they are
8102 compiled as returning the appropriate @code{gcc} type
8103 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
8104 in many configurations).
8106 With @samp{-ff2c} in force, they
8107 are compiled differently (with perhaps slower run-time performance)
8108 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
8109 C as an intermediate language---@code{REAL(KIND=1)} functions
8110 return C's @code{double} type, while @code{COMPLEX} functions return
8111 @code{void} and use an extra argument pointing to a place for the functions to
8112 return their values.
8114 It is possible that, in some cases, leaving @samp{-ff2c} in force
8115 might produce faster code than using @samp{-fno-f2c}.
8116 Feel free to experiment, but remember to experiment with changing the way
8117 @emph{entire programs and their Fortran libraries are compiled} at
8118 a time, since this sort of experimentation affects the interface
8119 of code generated for a Fortran source file---that is, it affects
8120 object compatibility.
8122 Note that @code{f2c} compatibility is a fairly static target to achieve,
8123 though not necessarily perfectly so, since, like @code{g77}, it is
8124 still being improved.
8125 However, specifying @samp{-fno-f2c} causes @code{g77}
8126 to generate code that will probably be incompatible with code
8127 generated by future versions of @code{g77} when the same option
8129 You should make sure you are always able to recompile complete
8130 programs from source code when upgrading to new versions of @code{g77}
8131 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8133 Therefore, if you are using @code{g77} to compile libraries and other
8134 object files for possible future use and you don't want to require
8135 recompilation for future use with subsequent versions of @code{g77},
8136 you might want to stick with @code{f2c} compatibility for now, and
8137 carefully watch for any announcements about changes to the
8138 @code{f2c}/@code{libf2c} interface that might affect existing programs
8139 (thus requiring recompilation).
8141 It is probable that a future version of @code{g77} will not,
8142 by default, generate object files compatible with @code{f2c},
8143 and that version probably would no longer use @code{libf2c}.
8144 If you expect to depend on this compatibility in the
8145 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8146 all of the applicable code.
8147 This should cause future versions of @code{g77} either to produce
8148 compatible code (at the expense of the availability of some features and
8149 performance), or at the very least, to produce diagnostics.
8151 (The library @code{g77} produces will no longer be named @file{libg2c}
8152 when it is no longer generally compatible with @file{libf2c}.
8153 It will likely be referred to, and, if installed as a distinct
8154 library, named @code{libg77}, or some other as-yet-unused name.)
8156 @node Compilers Other Than f2c
8157 @section Compilers Other Than @code{f2c}
8159 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8160 code compiled by @code{g77} is not expected to work
8161 well with code compiled by the native compiler.
8162 (This is true for @code{f2c}-compiled objects as well.)
8163 Libraries compiled with the native compiler probably will have
8164 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8166 Reasons for such incompatibilities include:
8170 There might be differences in the way names of Fortran procedures
8171 are translated for use in the system's object-file format.
8172 For example, the statement @samp{CALL FOO} might be compiled
8173 by @code{g77} to call a procedure the linker @code{ld} sees
8174 given the name @samp{_foo_}, while the apparently corresponding
8175 statement @samp{SUBROUTINE FOO} might be compiled by the
8176 native compiler to define the linker-visible name @samp{_foo},
8177 or @samp{_FOO_}, and so on.
8180 There might be subtle type mismatches which cause subroutine arguments
8181 and function return values to get corrupted.
8183 This is why simply getting @code{g77} to
8184 transform procedure names the same way a native
8185 compiler does is not usually a good idea---unless
8186 some effort has been made to ensure that, aside
8187 from the way the two compilers transform procedure
8188 names, everything else about the way they generate
8189 code for procedure interfaces is identical.
8193 use libraries of private I/O routines which will not be available
8194 at link time unless you have the native compiler---and you would
8195 have to explicitly ask for them.
8197 For example, on the Sun you
8198 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8202 @node Other Languages
8203 @chapter Other Languages
8205 @emph{Note: This portion of the documentation definitely needs a lot
8209 * Interoperating with C and C++::
8212 @node Interoperating with C and C++
8213 @section Tools and advice for interoperating with C and C++
8215 @cindex C, linking with
8216 @cindex C++, linking with
8217 @cindex linking with C
8218 The following discussion assumes that you are running @code{g77} in @code{f2c}
8219 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8221 advice about quick and simple techniques for linking Fortran and C (or
8222 C++), the most common requirement.
8223 For the full story consult the
8224 description of code generation.
8225 @xref{Debugging and Interfacing}.
8227 When linking Fortran and C, it's usually best to use @code{g77} to do
8228 the linking so that the correct libraries are included (including the
8230 If you're linking with C++ you will want to add
8231 @samp{-lstdc++}, @samp{-lg++} or whatever.
8232 If you need to use another
8233 driver program (or @code{ld} directly),
8234 you can find out what linkage
8235 options @code{g77} passes by running @samp{g77 -v}.
8238 * C Interfacing Tools::
8239 * C Access to Type Information::
8240 * f2c Skeletons and Prototypes::
8241 * C++ Considerations::
8245 @node C Interfacing Tools
8246 @subsection C Interfacing Tools
8250 Even if you don't actually use it as a compiler, @code{f2c} from
8251 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8252 interfacing (linking) Fortran and C@.
8253 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8255 To use @code{f2c} for this purpose you only need retrieve and
8256 build the @file{src} directory from the distribution, consult the
8257 @file{README} instructions there for machine-specifics, and install the
8258 @code{f2c} program on your path.
8260 Something else that might be useful is @samp{cfortran.h} from
8261 @uref{ftp://zebra.desy.de/cfortran}.
8262 This is a fairly general tool which
8263 can be used to generate interfaces for calling in both directions
8264 between Fortran and C@.
8265 It can be used in @code{f2c} mode with
8266 @code{g77}---consult its documentation for details.
8268 @node C Access to Type Information
8269 @subsection Accessing Type Information in C
8271 @cindex types, Fortran/C
8272 Generally, C code written to link with
8273 @code{g77} code---calling and/or being
8274 called from Fortran---should @samp{#include <g2c.h>} to define the C
8275 versions of the Fortran types.
8276 Don't assume Fortran @code{INTEGER} types
8277 correspond to C @code{int}s, for instance; instead, declare them as
8278 @code{integer}, a type defined by @file{g2c.h}.
8279 @file{g2c.h} is installed where @code{gcc} will find it by
8280 default, assuming you use a copy of @code{gcc} compatible with
8281 @code{g77}, probably built at the same time as @code{g77}.
8283 @node f2c Skeletons and Prototypes
8284 @subsection Generating Skeletons and Prototypes with @code{f2c}
8287 @cindex -fno-second-underscore
8288 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8289 interface with an existing library---is to write a file (named, for
8290 example, @file{fred.f}) of dummy Fortran
8291 skeletons comprising just the declaration of the routine(s) and dummy
8292 arguments plus @code{END} statements.
8293 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8294 into which you can edit
8295 useful code, confident the calling sequence is correct, at least.
8296 (There are some errors otherwise commonly made in generating C
8297 interfaces with @code{f2c} conventions,
8298 such as not using @code{doublereal}
8299 as the return type of a @code{REAL} @code{FUNCTION}.)
8302 @code{f2c} also can help with calling Fortran from C, using its
8303 @samp{-P} option to generate C prototypes appropriate for calling the
8304 Fortran.@footnote{The files generated like this can also be used for
8305 inter-unit consistency checking of dummy and actual arguments, although
8306 the @code{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8307 or @uref{ftp://ftp.dsm.fordham.edu} is
8308 probably better for this purpose.}
8309 If the Fortran code containing any
8310 routines to be called from C is in file @file{joe.f}, use the command
8311 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8312 prototype information.
8313 @code{#include} this in the C which has to call
8314 the Fortran routines to make sure you get it right.
8316 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
8317 between the way Fortran (including compilers like @code{g77}) and
8320 @node C++ Considerations
8321 @subsection C++ Considerations
8324 @code{f2c} can be used to generate suitable code for compilation with a
8325 C++ system using the @samp{-C++} option.
8326 The important thing about linking @code{g77}-compiled
8327 code with C++ is that the prototypes for the @code{g77}
8328 routines must specify C linkage to avoid name mangling.
8329 So, use an @samp{extern "C"} declaration.
8330 @code{f2c}'s @samp{-C++} option will take care
8331 of this when generating skeletons or prototype files as above, and also
8332 avoid clashes with C++ reserved words in addition to those in C@.
8335 @subsection Startup Code
8337 @cindex startup code
8338 @cindex run-time, initialization
8339 @cindex initialization, run-time
8340 Unlike with some runtime systems,
8341 it shouldn't be necessary
8342 (unless there are bugs)
8343 to use a Fortran main program unit to ensure the
8344 runtime---specifically the I/O system---is initialized.
8346 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8347 either the @code{main} routine from the @file{libg2c} library must be used,
8348 or the @code{f_setarg} routine
8349 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8350 must be called with the appropriate @code{argc} and @code{argv} arguments
8351 prior to the program calling @code{GETARG} or @code{IARGC}.
8353 To provide more flexibility for mixed-language programming
8354 involving @code{g77} while allowing for shared libraries,
8355 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8356 @code{g77}'s @code{main} routine in @code{libg2c}
8357 does the following, in order:
8361 Calls @code{f_setarg}
8362 with the incoming @code{argc} and @code{argv} arguments,
8363 in the same order as for @code{main} itself.
8365 This sets up the command-line environment
8366 for @code{GETARG} and @code{IARGC}.
8369 Calls @code{f_setsig} (with no arguments).
8371 This sets up the signaling and exception environment.
8374 Calls @code{f_init} (with no arguments).
8376 This initializes the I/O environment,
8377 though that should not be necessary,
8378 as all I/O functions in @code{libf2c}
8379 are believed to call @code{f_init} automatically,
8382 (A future version of @code{g77} might skip this explicit step,
8383 to speed up normal exit of a program.)
8386 Arranges for @code{f_exit} to be called (with no arguments)
8387 when the program exits.
8389 This ensures that the I/O environment is properly shut down
8390 before the program exits normally.
8391 Otherwise, output buffers might not be fully flushed,
8392 scratch files might not be deleted, and so on.
8394 The simple way @code{main} does this is
8395 to call @code{f_exit} itself after calling
8396 @code{MAIN__} (in the next step).
8398 However, this does not catch the cases where the program
8399 might call @code{exit} directly,
8400 instead of using the @code{EXIT} intrinsic
8401 (implemented as @code{exit_} in @code{libf2c}).
8403 So, @code{main} attempts to use
8404 the operating environment's @code{onexit} or @code{atexit}
8405 facility, if available,
8406 to cause @code{f_exit} to be called automatically
8407 upon any invocation of @code{exit}.
8410 Calls @code{MAIN__} (with no arguments).
8412 This starts executing the Fortran main program unit for
8414 (Both @code{g77} and @code{f2c} currently compile a main
8415 program unit so that its global name is @code{MAIN__}.)
8418 If no @code{onexit} or @code{atexit} is provided by the system,
8419 calls @code{f_exit}.
8422 Calls @code{exit} with a zero argument,
8423 to signal a successful program termination.
8426 Returns a zero value to the caller,
8427 to signal a successful program termination,
8428 in case @code{exit} doesn't exit on the system.
8431 All of the above names are C @code{extern} names,
8434 When using the @code{main} procedure provided by @code{g77}
8435 without a Fortran main program unit,
8436 you need to provide @code{MAIN__}
8437 as the entry point for your C code.
8438 (Make sure you link the object file that defines that
8439 entry point with the rest of your program.)
8441 To provide your own @code{main} procedure
8442 in place of @code{g77}'s,
8443 make sure you specify the object file defining that procedure
8444 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8445 Since the @samp{-lg2c} option is implicitly provided,
8446 this is usually straightforward.
8447 (Use the @samp{--verbose} option to see how and where
8448 @code{g77} implicitly adds @samp{-lg2c} in a command line
8449 that will link the program.
8450 Feel free to specify @samp{-lg2c} explicitly,
8453 However, when providing your own @code{main},
8454 make sure you perform the appropriate tasks in the
8456 For example, if your @code{main} does not call @code{f_setarg},
8457 make sure the rest of your application does not call
8458 @code{GETARG} or @code{IARGC}.
8460 And, if your @code{main} fails to ensure that @code{f_exit}
8461 is called upon program exit,
8462 some files might end up incompletely written,
8463 some scratch files might be left lying around,
8464 and some existing files being written might be left
8465 with old data not properly truncated at the end.
8467 Note that, generally, the @code{g77} operating environment
8468 does not depend on a procedure named @code{MAIN__} actually
8469 being called prior to any other @code{g77}-compiled code.
8470 That is, @code{MAIN__} does not, itself,
8471 set up any important operating-environment characteristics
8472 upon which other code might depend.
8473 This might change in future versions of @code{g77},
8474 with appropriate notification in the release notes.
8476 For more information, consult the source code for the above routines.
8477 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8478 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8480 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8481 uses to open-code (inline) references to @code{IARGC}.
8483 @include g77install.texi
8485 @node Debugging and Interfacing
8486 @chapter Debugging and Interfacing
8489 @cindex calling C routines
8490 @cindex C routines calling Fortran
8491 @cindex f2c compatibility
8493 GNU Fortran currently generates code that is object-compatible with
8494 the @code{f2c} converter.
8495 Also, it avoids limitations in the current GBE, such as the
8496 inability to generate a procedure with
8497 multiple entry points, by generating code that is structured
8498 differently (in terms of procedure names, scopes, arguments, and
8499 so on) than might be expected.
8501 As a result, writing code in other languages that calls on, is
8502 called by, or shares in-memory data with @code{g77}-compiled code generally
8503 requires some understanding of the way @code{g77} compiles code for
8506 Similarly, using a debugger to debug @code{g77}-compiled
8507 code, even if that debugger supports native Fortran debugging, generally
8508 requires this sort of information.
8510 This section describes some of the basic information on how
8511 @code{g77} compiles code for constructs involving interfaces to other
8512 languages and to debuggers.
8514 @emph{Caution:} Much or all of this information pertains to only the current
8515 release of @code{g77}, sometimes even to using certain compiler options
8516 with @code{g77} (such as @samp{-fno-f2c}).
8517 Do not write code that depends on this
8518 information without clearly marking said code as nonportable and
8519 subject to review for every new release of @code{g77}.
8521 is provided primarily to make debugging of code generated by this
8522 particular release of @code{g77} easier for the user, and partly to make
8523 writing (generally nonportable) interface code easier.
8525 activities require tracking changes in new version of @code{g77} as they
8526 are installed, because new versions can change the behaviors
8527 described in this section.
8530 * Main Program Unit:: How @code{g77} compiles a main program unit.
8531 * Procedures:: How @code{g77} constructs parameter lists
8533 * Functions:: Functions returning floating-point or character data.
8534 * Names:: Naming of user-defined variables, procedures, etc.
8535 * Common Blocks:: Accessing common variables while debugging.
8536 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8537 * Complex Variables:: How @code{g77} performs complex arithmetic.
8538 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8539 * Adjustable Arrays:: Special consideration for adjustable arrays.
8540 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8541 * Alternate Returns:: How @code{g77} handles alternate returns.
8542 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8543 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8546 @node Main Program Unit
8547 @section Main Program Unit (PROGRAM)
8548 @cindex PROGRAM statement
8549 @cindex statements, PROGRAM
8551 When @code{g77} compiles a main program unit, it gives it the public
8552 procedure name @code{MAIN__}.
8553 The @code{libg2c} library has the actual @code{main()} procedure
8554 as is typical of C-based environments, and
8555 it is this procedure that performs some initial start-up
8556 activity and then calls @code{MAIN__}.
8558 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8559 include a main program unit written in Fortran in your program---it
8560 can be written in C or some other language.
8561 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8562 includes a bug fix for @code{libg2c} that solved a problem with using the
8563 @code{OPEN} statement as the first Fortran I/O activity in a program
8564 without a Fortran main program unit.
8566 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8567 your main program unit---that is, if you intend to compile a @code{main()}
8568 procedure using some other language---you should carefully
8569 examine the code for @code{main()} in @code{libg2c}, found in the source
8570 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8571 might need to be done by your @code{main()} in order to provide the
8572 Fortran environment your Fortran code is expecting.
8574 @cindex @code{IArgC} intrinsic
8575 @cindex intrinsics, @code{IArgC}
8576 @cindex @code{GetArg} intrinsic
8577 @cindex intrinsics, @code{GetArg}
8578 For example, @code{libg2c}'s @code{main()} sets up the information used by
8579 the @code{IARGC} and @code{GETARG} intrinsics.
8580 Bypassing @code{libg2c}'s @code{main()}
8581 without providing a substitute for this activity would mean
8582 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8586 @cindex main program unit, debugging
8590 When debugging, one implication of the fact that @code{main()}, which
8591 is the place where the debugged program ``starts'' from the
8592 debugger's point of view, is in @code{libg2c} is that you won't be
8593 starting your Fortran program at a point you recognize as your
8596 The standard way to get around this problem is to set a break
8597 point (a one-time, or temporary, break point will do) at
8598 the entrance to @code{MAIN__}, and then run the program.
8599 A convenient way to do so is to add the @code{gdb} command
8606 to the file @file{.gdbinit} in the directory in which you're debugging
8609 After doing this, the debugger will see the current execution
8610 point of the program as at the beginning of the main program
8611 unit of your program.
8613 Of course, if you really want to set a break point at some
8614 other place in your program and just start the program
8615 running, without first breaking at @code{MAIN__},
8616 that should work fine.
8619 @section Procedures (SUBROUTINE and FUNCTION)
8621 @cindex SUBROUTINE statement
8622 @cindex statements, SUBROUTINE
8623 @cindex FUNCTION statement
8624 @cindex statements, FUNCTION
8625 @cindex signature of procedures
8627 Currently, @code{g77} passes arguments via reference---specifically,
8628 by passing a pointer to the location in memory of a variable, array,
8629 array element, a temporary location that holds the result of evaluating an
8630 expression, or a temporary or permanent location that holds the value
8633 Procedures that accept @code{CHARACTER} arguments are implemented by
8634 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8636 The first argument occupies the expected position in the
8637 argument list and has the user-specified name.
8639 is a pointer to an array of characters, passed by the caller.
8641 The second argument is appended to the end of the user-specified
8642 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8643 is the user-specified name.
8644 This argument is of the C type @code{ftnlen}
8645 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8646 is the number of characters the caller has allocated in the
8647 array pointed to by the first argument.
8649 A procedure will ignore the length argument if @samp{X} is not declared
8650 @code{CHARACTER*(*)}, because for other declarations, it knows the
8652 Not all callers necessarily ``know'' this, however, which
8653 is why they all pass the extra argument.
8655 The contents of the @code{CHARACTER} argument are specified by the
8656 address passed in the first argument (named after it).
8657 The procedure can read or write these contents as appropriate.
8659 When more than one @code{CHARACTER} argument is present in the argument
8660 list, the length arguments are appended in the order
8661 the original arguments appear.
8662 So @samp{CALL FOO('HI','THERE')} is implemented in
8663 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8664 does not provide the trailing null bytes on the constant
8665 strings (@code{f2c} does provide them, but they are unnecessary in
8666 a Fortran environment, and you should not expect them to be
8669 Note that the above information applies to @code{CHARACTER} variables and
8670 arrays @strong{only}.
8671 It does @strong{not} apply to external @code{CHARACTER}
8672 functions or to intrinsic @code{CHARACTER} functions.
8673 That is, no second length argument is passed to @samp{FOO} in this case:
8682 Nor does @samp{FOO} expect such an argument in this case:
8690 Because of this implementation detail, if a program has a bug
8691 such that there is disagreement as to whether an argument is
8692 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8693 symptoms might appear.
8696 @section Functions (FUNCTION and RETURN)
8698 @cindex FUNCTION statement
8699 @cindex statements, FUNCTION
8700 @cindex RETURN statement
8701 @cindex statements, RETURN
8702 @cindex return type of functions
8704 @code{g77} handles in a special way functions that return the following
8716 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8717 returning @code{void})
8718 with two arguments prepended: @samp{__g77_result}, which the caller passes
8719 as a pointer to a @code{char} array expected to hold the return value,
8720 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8721 specifying the length of the return value as declared in the calling
8723 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8724 to determine the size of the array that @samp{__g77_result} points to;
8725 otherwise, it ignores that argument.
8727 For @code{COMPLEX}, when @samp{-ff2c} is in
8728 force, @code{g77} implements
8729 a subroutine with one argument prepended: @samp{__g77_result}, which the
8730 caller passes as a pointer to a variable of the type of the function.
8731 The called function writes the return value into this variable instead
8732 of returning it as a function value.
8733 When @samp{-fno-f2c} is in force,
8734 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8735 @samp{__complex__ float} or @samp{__complex__ double} function
8736 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8737 returning the result of the function in the same way as @code{gcc} would.
8739 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8740 a function that actually returns @code{REAL(KIND=2)} (typically
8741 C's @code{double} type).
8742 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8743 functions return @code{float}.
8747 @cindex symbol names
8748 @cindex transforming symbol names
8750 Fortran permits each implementation to decide how to represent
8751 names as far as how they're seen in other contexts, such as debuggers
8752 and when interfacing to other languages, and especially as far
8753 as how casing is handled.
8755 External names---names of entities that are public, or ``accessible'',
8756 to all modules in a program---normally have an underscore (@samp{_})
8757 appended by @code{g77},
8758 to generate code that is compatible with @code{f2c}.
8759 External names include names of Fortran things like common blocks,
8760 external procedures (subroutines and functions, but not including
8761 statement functions, which are internal procedures), and entry point
8764 However, use of the @samp{-fno-underscoring} option
8765 disables this kind of transformation of external names (though inhibiting
8766 the transformation certainly improves the chances of colliding with
8767 incompatible externals written in other languages---but that
8768 might be intentional.
8770 @cindex -fno-underscoring option
8771 @cindex options, -fno-underscoring
8772 @cindex -fno-second-underscore option
8773 @cindex options, -fno-underscoring
8774 When @samp{-funderscoring} is in force, any name (external or local)
8775 that already has at least one underscore in it is
8776 implemented by @code{g77} by appending two underscores.
8777 (This second underscore can be disabled via the
8778 @samp{-fno-second-underscore} option.)
8779 External names are changed this way for @code{f2c} compatibility.
8780 Local names are changed this way to avoid collisions with external names
8781 that are different in the source code---@code{f2c} does the same thing, but
8782 there's no compatibility issue there except for user expectations while
8793 Here, a user would, in the debugger, refer to this variable using the
8794 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8795 as described below).
8796 (We hope to improve @code{g77} in this regard in the future---don't
8797 write scripts depending on this behavior!
8798 Also, consider experimenting with the @samp{-fno-underscoring}
8799 option to try out debugging without having to massage names by
8802 @code{g77} provides a number of command-line options that allow the user
8803 to control how case mapping is handled for source files.
8804 The default is the traditional UNIX model for Fortran compilers---names
8805 are mapped to lower case.
8806 Other command-line options can be specified to map names to upper
8807 case, or to leave them exactly as written in the source file.
8816 Here, it is normally the case that the variable assigned will be named
8818 This would be the name to enter when using a debugger to
8819 access the variable.
8821 However, depending on the command-line options specified, the
8822 name implemented by @code{g77} might instead be @samp{FOO} or even
8823 @samp{Foo}, thus affecting how debugging is done.
8832 This would normally call a procedure that, if it were in a separate C program,
8833 be defined starting with the line:
8840 However, @code{g77} command-line options could be used to change the casing
8841 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8842 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8843 could be used to inhibit the appending of the underscore to the name.
8846 @section Common Blocks (COMMON)
8847 @cindex common blocks
8848 @cindex @code{COMMON} statement
8849 @cindex statements, @code{COMMON}
8851 @code{g77} names and lays out @code{COMMON} areas
8852 the same way @code{f2c} does,
8853 for compatibility with @code{f2c}.
8855 Currently, @code{g77} does not emit ``true'' debugging information for
8856 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8858 (As of Version 0.5.19, @code{g77} emits debugging information for such
8859 members in the form of a constant string specifying the base name of
8860 the aggregate area and the offset of the member in bytes from the start
8862 Use the @samp{-fdebug-kludge} option to enable this behavior.
8863 In @code{gdb}, use @samp{set language c} before printing the value
8864 of the member, then @samp{set language fortran} to restore the default
8865 language, since @code{gdb} doesn't provide a way to print a readable
8866 version of a character string in Fortran language mode.
8868 This kludge will be removed in a future version of @code{g77} that,
8869 in conjunction with a contemporary version of @code{gdb},
8870 properly supports Fortran-language debugging, including access
8871 to members of @code{COMMON} areas.)
8873 Version 0.5.26 of @code{g77} is believed to provide correct and
8874 complete debug information for COMMON BLOCK and EQUIVALENCE items -
8875 hence the @samp{-fdebug-kludge} option has been disabled.
8877 @xref{Code Gen Options,,Options for Code Generation Conventions},
8878 for information on the @samp{-fdebug-kludge} option.
8880 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8881 type is an array of the C @code{char} data type.
8883 So, when debugging, you must know the offset into a @code{COMMON} area
8884 for a particular item in that area, and you have to take into
8885 account the appropriate multiplier for the respective sizes
8886 of the types (as declared in your code) for the items preceding
8887 the item in question as compared to the size of the @code{char} type.
8889 For example, using default implicit typing, the statement
8892 COMMON I(15), R(20), T
8896 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8897 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8898 and @samp{T} at @samp{_BLNK__[140]}.
8899 (This is assuming that the target machine for
8900 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8903 @node Local Equivalence Areas
8904 @section Local Equivalence Areas (EQUIVALENCE)
8905 @cindex equivalence areas
8906 @cindex local equivalence areas
8907 @cindex EQUIVALENCE statement
8908 @cindex statements, EQUIVALENCE
8910 @code{g77} treats storage-associated areas involving a @code{COMMON}
8911 block as explained in the section on common blocks.
8913 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8914 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8915 listed in a @code{COMMON} statement.
8917 Currently, @code{g77} does not emit ``true'' debugging information for
8918 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8920 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8921 members in the form of a constant string specifying the base name of
8922 the aggregate area and the offset of the member in bytes from the start
8924 Use the @samp{-fdebug-kludge} option to enable this behavior.
8925 In @code{gdb}, use @samp{set language c} before printing the value
8926 of the member, then @samp{set language fortran} to restore the default
8927 language, since @code{gdb} doesn't provide a way to print a readable
8928 version of a character string in Fortran language mode.
8930 This kludge will be removed in a future version of @code{g77} that,
8931 in conjunction with a contemporary version of @code{gdb},
8932 properly supports Fortran-language debugging, including access
8933 to members of @code{EQUIVALENCE} areas.)
8935 @xref{Code Gen Options,,Options for Code Generation Conventions},
8936 for information on the @samp{-fdebug-kludge} option.
8938 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8939 type is an array of the C @code{char} data type.
8941 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8942 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8944 If more than one such item is placed at the beginning, @var{x} is
8945 the name that sorts to the top in an alphabetical sort of the list of
8948 When debugging, you must therefore access members of @code{EQUIVALENCE}
8949 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8950 array section with the appropriate offset.
8951 See the explanation of debugging @code{COMMON} blocks
8952 for info applicable to debugging local @code{EQUIVALENCE} areas.
8954 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8955 for @var{x} using a different method when more than one name was
8956 in the list of names of entities placed at the beginning of the
8958 Though the documentation specified that the first name listed in
8959 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8960 in fact chose the name using a method that was so complicated,
8961 it seemed easier to change it to an alphabetical sort than to describe the
8962 previous method in the documentation.)
8964 @node Complex Variables
8965 @section Complex Variables (COMPLEX)
8966 @cindex complex variables
8967 @cindex imaginary part
8968 @cindex COMPLEX statement
8969 @cindex statements, COMPLEX
8971 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8972 (and related intrinsics, constants, functions, and so on)
8974 makes direct debugging involving these types in Fortran
8975 language mode difficult.
8977 Essentially, @code{g77} implements these types using an
8978 internal construct similar to C's @code{struct}, at least
8979 as seen by the @code{gcc} back end.
8981 Currently, the back end, when outputting debugging info with
8982 the compiled code for the assembler to digest, does not detect
8983 these @code{struct} types as being substitutes for Fortran
8985 As a result, the Fortran language modes of debuggers such as
8986 @code{gdb} see these types as C @code{struct} types, which
8987 they might or might not support.
8989 Until this is fixed, switch to C language mode to work with
8990 entities of @code{COMPLEX} type and then switch back to Fortran language
8992 (In @code{gdb}, this is accomplished via @samp{set lang c} and
8993 either @samp{set lang fortran} or @samp{set lang auto}.)
8996 @section Arrays (DIMENSION)
8997 @cindex DIMENSION statement
8998 @cindex statements, DIMENSION
8999 @cindex array ordering
9000 @cindex ordering, array
9001 @cindex column-major ordering
9002 @cindex row-major ordering
9005 Fortran uses ``column-major ordering'' in its arrays.
9006 This differs from other languages, such as C, which use ``row-major ordering''.
9007 The difference is that, with Fortran, array elements adjacent to
9008 each other in memory differ in the @emph{first} subscript instead of
9009 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
9010 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
9013 affects not only interfacing with and debugging Fortran code,
9014 it can greatly affect how code is designed and written, especially
9015 when code speed and size is a concern.
9017 Fortran also differs from C, a popular language for interfacing and
9018 to support directly in debuggers, in the way arrays are treated.
9019 In C, arrays are single-dimensional and have interesting relationships
9020 to pointers, neither of which is true for Fortran.
9021 As a result, dealing with Fortran arrays from within
9022 an environment limited to C concepts can be challenging.
9024 For example, accessing the array element @samp{A(5,10,20)} is easy enough
9025 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
9027 First, C would treat the A array as a single-dimension array.
9028 Second, C does not understand low bounds for arrays as does Fortran.
9029 Third, C assumes a low bound of zero (0), while Fortran defaults to a
9030 low bound of one (1) and can supports an arbitrary low bound.
9031 Therefore, calculations must be done
9032 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
9033 calculations require knowing the dimensions of @samp{A}.
9035 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
9036 @samp{A(5,10,20)} would be:
9041 + (20-0)*(11-2+1)*(21-1+1)
9046 So the C equivalent in this case would be @samp{a[4293]}.
9048 When using a debugger directly on Fortran code, the C equivalent
9049 might not work, because some debuggers cannot understand the notion
9050 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
9051 does inform the GBE that a multi-dimensional array (like @samp{A}
9052 in the above example) is really multi-dimensional, rather than a
9053 single-dimensional array, so at least the dimensionality of the array
9056 Debuggers that understand Fortran should have no trouble with
9057 non-zero low bounds, but for non-Fortran debuggers, especially
9058 C debuggers, the above example might have a C equivalent of
9060 This calculation is arrived at by eliminating the subtraction
9061 of the lower bound in the first parenthesized expression on each
9062 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
9063 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
9064 Actually, the implication of
9065 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
9066 but that @samp{a[20][10][5]} produces the equivalent of
9067 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
9069 Come to think of it, perhaps
9070 the behavior is due to the debugger internally compensating for
9071 the lower bounds by offsetting the base address of @samp{a}, leaving
9072 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
9073 its first element as identified by subscripts equal to the
9074 corresponding lower bounds).
9076 You know, maybe nobody really needs to use arrays.
9078 @node Adjustable Arrays
9079 @section Adjustable Arrays (DIMENSION)
9080 @cindex arrays, adjustable
9081 @cindex adjustable arrays
9082 @cindex arrays, automatic
9083 @cindex automatic arrays
9084 @cindex DIMENSION statement
9085 @cindex statements, DIMENSION
9086 @cindex dimensioning arrays
9087 @cindex arrays, dimensioning
9089 Adjustable and automatic arrays in Fortran require the implementation
9091 case, the @code{g77} compiler) to ``memorize'' the expressions that
9092 dimension the arrays each time the procedure is invoked.
9093 This is so that subsequent changes to variables used in those
9094 expressions, made during execution of the procedure, do not
9095 have any effect on the dimensions of those arrays.
9112 Here, the implementation should, when running the program, print something
9120 Note that this shows that while the value of @samp{N} was successfully
9121 changed, the size of the @samp{A} array remained at 5 elements.
9123 To support this, @code{g77} generates code that executes before any user
9124 code (and before the internally generated computed @code{GOTO} to handle
9125 alternate entry points, as described below) that evaluates each
9126 (nonconstant) expression in the list of subscripts for an
9127 array, and saves the result of each such evaluation to be used when
9128 determining the size of the array (instead of re-evaluating the
9131 So, in the above example, when @samp{X} is first invoked, code is
9132 executed that copies the value of @samp{N} to a temporary.
9133 And that same temporary serves as the actual high bound for the single
9134 dimension of the @samp{A} array (the low bound being the constant 1).
9135 Since the user program cannot (legitimately) change the value
9136 of the temporary during execution of the procedure, the size
9137 of the array remains constant during each invocation.
9139 For alternate entry points, the code @code{g77} generates takes into
9140 account the possibility that a dummy adjustable array is not actually
9141 passed to the actual entry point being invoked at that time.
9142 In that case, the public procedure implementing the entry point
9143 passes to the master private procedure implementing all the
9144 code for the entry points a @code{NULL} pointer where a pointer to that
9145 adjustable array would be expected.
9146 The @code{g77}-generated code
9147 doesn't attempt to evaluate any of the expressions in the subscripts
9148 for an array if the pointer to that array is @code{NULL} at run time in
9150 (Don't depend on this particular implementation
9151 by writing code that purposely passes @code{NULL} pointers where the
9152 callee expects adjustable arrays, even if you know the callee
9153 won't reference the arrays---nor should you pass @code{NULL} pointers
9154 for any dummy arguments used in calculating the bounds of such
9155 arrays or leave undefined any values used for that purpose in
9156 COMMON---because the way @code{g77} implements these things might
9157 change in the future!)
9159 @node Alternate Entry Points
9160 @section Alternate Entry Points (ENTRY)
9161 @cindex alternate entry points
9162 @cindex entry points
9163 @cindex ENTRY statement
9164 @cindex statements, ENTRY
9166 The GBE does not understand the general concept of
9167 alternate entry points as Fortran provides via the ENTRY statement.
9168 @code{g77} gets around this by using an approach to compiling procedures
9169 having at least one @code{ENTRY} statement that is almost identical to the
9170 approach used by @code{f2c}.
9171 (An alternate approach could be used that
9172 would probably generate faster, but larger, code that would also
9173 be a bit easier to debug.)
9175 Information on how @code{g77} implements @code{ENTRY} is provided for those
9176 trying to debug such code.
9177 The choice of implementation seems
9178 unlikely to affect code (compiled in other languages) that interfaces
9181 @code{g77} compiles exactly one public procedure for the primary entry
9182 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9183 That is, in terms of the public interface, there is no difference
9202 The difference between the above two cases lies in the code compiled
9203 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9204 for the second case, an extra internal procedure is compiled.
9206 For every Fortran procedure with at least one @code{ENTRY}
9207 statement, @code{g77} compiles an extra procedure
9208 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9209 the name of the primary entry point (which, in the above case,
9210 using the standard compiler options, would be @samp{x_} in C).
9212 This extra procedure is compiled as a private procedure---that is,
9213 a procedure not accessible by name to separately compiled modules.
9214 It contains all the code in the program unit, including the code
9215 for the primary entry point plus for every entry point.
9216 (The code for each public procedure is quite short, and explained later.)
9218 The extra procedure has some other interesting characteristics.
9220 The argument list for this procedure is invented by @code{g77}.
9222 a single integer argument named @samp{__g77_which_entrypoint},
9223 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9224 entry point index---0 for the primary entry point, 1 for the
9225 first entry point (the first @code{ENTRY} statement encountered), 2 for
9226 the second entry point, and so on.
9228 It also contains, for functions returning @code{CHARACTER} and
9229 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9230 and for functions returning different types among the
9231 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9232 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9233 is expected at run time to contain a pointer to where to store
9234 the result of the entry point.
9235 For @code{CHARACTER} functions, this
9236 storage area is an array of the appropriate number of characters;
9237 for @code{COMPLEX} functions, it is the appropriate area for the return
9238 type; for multiple-return-type functions, it is a union of all the supported return
9239 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9240 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9241 is not supported by @code{g77}).
9243 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9244 by yet another argument named @samp{__g77_length} that, at run time,
9245 specifies the caller's expected length of the returned value.
9246 Note that only @code{CHARACTER*(*)} functions and entry points actually
9247 make use of this argument, even though it is always passed by
9248 all callers of public @code{CHARACTER} functions (since the caller does not
9249 generally know whether such a function is @code{CHARACTER*(*)} or whether
9250 there are any other callers that don't have that information).
9252 The rest of the argument list is the union of all the arguments
9253 specified for all the entry points (in their usual forms, e.g.
9254 @code{CHARACTER} arguments have extra length arguments, all appended at
9255 the end of this list).
9256 This is considered the ``master list'' of
9259 The code for this procedure has, before the code for the first
9260 executable statement, code much like that for the following Fortran
9264 GOTO (100000,100001,100002), __g77_which_entrypoint
9265 100000 @dots{}code for primary entry point@dots{}
9266 100001 @dots{}code immediately following first ENTRY statement@dots{}
9267 100002 @dots{}code immediately following second ENTRY statement@dots{}
9271 (Note that invalid Fortran statement labels and variable names
9272 are used in the above example to highlight the fact that it
9273 represents code generated by the @code{g77} internals, not code to be
9274 written by the user.)
9276 It is this code that, when the procedure is called, picks which
9277 entry point to start executing.
9279 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9280 example), those procedures are fairly simple.
9282 are just like they would be if they were self-contained procedures
9283 (without @code{ENTRY}), of course, since that is what the callers
9285 Their code consists of simply calling the private
9286 procedure, described above, with the appropriate extra arguments
9287 (the entry point index, and perhaps a pointer to a multiple-type-
9288 return variable, local to the public procedure, that contains
9289 all the supported returnable non-character types).
9291 that are not listed for a given entry point that are listed for
9292 other entry points, and therefore that are in the ``master list''
9293 for the private procedure, null pointers (in C, the @code{NULL} macro)
9295 Also, for entry points that are part of a multiple-type-
9296 returning function, code is compiled after the call of the private
9297 procedure to extract from the multi-type union the appropriate result,
9298 depending on the type of the entry point in question, returning
9299 that result to the original caller.
9301 When debugging a procedure containing alternate entry points, you
9302 can either set a break point on the public procedure itself (e.g.
9303 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9304 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9305 If you do the former, you should use the debugger's command to
9306 ``step into'' the called procedure to get to the actual code; with
9307 the latter approach, the break point leaves you right at the
9308 actual code, skipping over the public entry point and its call
9309 to the private procedure (unless you have set a break point there
9310 as well, of course).
9312 Further, the list of dummy arguments that is visible when the
9313 private procedure is active is going to be the expanded version
9314 of the list for whichever particular entry point is active,
9315 as explained above, and the way in which return values are
9316 handled might well be different from how they would be handled
9317 for an equivalent single-entry function.
9319 @node Alternate Returns
9320 @section Alternate Returns (SUBROUTINE and RETURN)
9322 @cindex alternate returns
9323 @cindex SUBROUTINE statement
9324 @cindex statements, SUBROUTINE
9325 @cindex RETURN statement
9326 @cindex statements, RETURN
9328 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9329 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9330 the C @code{int} type.
9331 The actual alternate-return arguments are omitted from the calling sequence.
9332 Instead, the caller uses
9333 the return value to do a rough equivalent of the Fortran
9334 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9335 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9336 function), and the callee just returns whatever integer
9337 is specified in the @code{RETURN} statement for the subroutine
9338 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9340 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9342 @node Assigned Statement Labels
9343 @section Assigned Statement Labels (ASSIGN and GOTO)
9344 @cindex assigned statement labels
9345 @cindex statement labels, assigned
9346 @cindex ASSIGN statement
9347 @cindex statements, ASSIGN
9348 @cindex GOTO statement
9349 @cindex statements, GOTO
9351 For portability to machines where a pointer (such as to a label,
9352 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9353 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9354 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9355 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9356 than it does the numerical value in that variable, unless the
9357 variable is wide enough (can hold enough bits).
9359 In particular, while @code{g77} implements
9366 as, in C notation, @samp{i = 10;}, it implements
9373 as, in GNU's extended C notation (for the label syntax),
9374 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9375 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9376 actually generate the name @samp{L10} or any other name like that,
9377 since debuggers cannot access labels anyway).
9379 While this currently means that an @code{ASSIGN} statement does not
9380 overwrite the numeric contents of its target variable, @emph{do not}
9381 write any code depending on this feature.
9382 @code{g77} has already changed this implementation across
9383 versions and might do so in the future.
9384 This information is provided only to make debugging Fortran programs
9385 compiled with the current version of @code{g77} somewhat easier.
9386 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9387 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9388 means @code{g77} has decided it can store the pointer to the label directly
9389 into @samp{I} itself.
9391 @xref{Ugly Assigned Labels}, for information on a command-line option
9392 to force @code{g77} to use the same storage for both normal and
9393 assigned-label uses of a variable.
9395 @node Run-time Library Errors
9396 @section Run-time Library Errors
9398 @cindex error values
9399 @cindex error messages
9400 @cindex messages, run-time
9403 The @code{libg2c} library currently has the following table to relate
9404 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9405 This information should, in future versions of this document, be
9406 expanded upon to include detailed descriptions of each message.
9408 In line with good coding practices, any of the numbers in the
9409 list below should @emph{not} be directly written into Fortran
9411 Instead, make a separate @code{INCLUDE} file that defines
9412 @code{PARAMETER} names for them, and use those in your code,
9413 so you can more easily change the actual numbers in the future.
9415 The information below is culled from the definition
9416 of @code{F_err} in @file{f/runtime/libI77/err.c} in the
9417 @code{g77} source tree.
9420 100: "error in format"
9421 101: "illegal unit number"
9422 102: "formatted io not allowed"
9423 103: "unformatted io not allowed"
9424 104: "direct io not allowed"
9425 105: "sequential io not allowed"
9426 106: "can't backspace file"
9427 107: "null file name"
9428 108: "can't stat file"
9429 109: "unit not connected"
9430 110: "off end of record"
9431 111: "truncation failed in endfile"
9432 112: "incomprehensible list input"
9433 113: "out of free space"
9434 114: "unit not connected"
9435 115: "read unexpected character"
9436 116: "bad logical input field"
9437 117: "bad variable type"
9438 118: "bad namelist name"
9439 119: "variable not in namelist"
9440 120: "no end record"
9441 121: "variable count incorrect"
9442 122: "subscript for scalar variable"
9443 123: "invalid array section"
9444 124: "substring out of bounds"
9445 125: "subscript out of bounds"
9446 126: "can't read file"
9447 127: "can't write file"
9448 128: "'new' file exists"
9449 129: "can't append to file"
9450 130: "non-positive record number"
9451 131: "I/O started while already doing I/O"
9454 @node Collected Fortran Wisdom
9455 @chapter Collected Fortran Wisdom
9458 @cindex code, legacy
9459 @cindex writing code
9460 @cindex code, writing
9462 Most users of @code{g77} can be divided into two camps:
9466 Those writing new Fortran code to be compiled by @code{g77}.
9469 Those using @code{g77} to compile existing, ``legacy'' code.
9472 Users writing new code generally understand most of the necessary
9473 aspects of Fortran to write ``mainstream'' code, but often need
9474 help deciding how to handle problems, such as the construction
9475 of libraries containing @code{BLOCK DATA}.
9477 Users dealing with ``legacy'' code sometimes don't have much
9478 experience with Fortran, but believe that the code they're compiling
9479 already works when compiled by other compilers (and might
9480 not understand why, as is sometimes the case, it doesn't work
9481 when compiled by @code{g77}).
9483 The following information is designed to help users do a better job
9484 coping with existing, ``legacy'' Fortran code, and with writing
9488 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9489 * Block Data and Libraries:: How @code{g77} solves a common problem.
9490 * Loops:: Fortran @code{DO} loops surprise many people.
9491 * Working Programs:: Getting programs to work should be done first.
9492 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9493 * Faster Programs:: Everybody wants these, but at what cost?
9496 @node Advantages Over f2c
9497 @section Advantages Over f2c
9499 Without @code{f2c}, @code{g77} would have taken much longer to
9500 do and probably not been as good for quite a while.
9501 Sometimes people who notice how much @code{g77} depends on, and
9502 documents encouragement to use, @code{f2c} ask why @code{g77}
9503 was created if @code{f2c} already existed.
9505 This section gives some basic answers to these questions, though it
9506 is not intended to be comprehensive.
9509 * Language Extensions:: Features used by Fortran code.
9510 * Diagnostic Abilities:: Abilities to spot problems early.
9511 * Compiler Options:: Features helpful to accommodate legacy code, etc.
9512 * Compiler Speed:: Speed of the compilation process.
9513 * Program Speed:: Speed of the generated, optimized code.
9514 * Ease of Debugging:: Debugging ease-of-use at the source level.
9515 * Character and Hollerith Constants:: A byte saved is a byte earned.
9518 @node Language Extensions
9519 @subsection Language Extensions
9521 @code{g77} offers several extensions to FORTRAN 77 language that @code{f2c}
9529 @code{CYCLE} and @code{EXIT}
9538 @code{KIND=} and @code{LEN=} notation
9541 Semicolon as statement separator
9544 Constant expressions in @code{FORMAT} statements
9545 (such as @samp{FORMAT(I<J>)},
9546 where @samp{J} is a @code{PARAMETER} named constant)
9549 @code{MvBits} intrinsic
9552 @code{libU77} (Unix-compatibility) library,
9553 with routines known to compiler as intrinsics
9554 (so they work even when compiler options are used
9555 to change the interfaces used by Fortran routines)
9558 @code{g77} also implements iterative @code{DO} loops
9559 so that they work even in the presence of certain ``extreme'' inputs,
9563 However, @code{f2c} offers a few that @code{g77} doesn't, such as:
9567 Intrinsics in @code{PARAMETER} statements
9570 Array bounds expressions (such as @samp{REAL M(N(2))})
9573 @code{AUTOMATIC} statement
9576 It is expected that @code{g77} will offer some or all of these missing
9577 features at some time in the future.
9579 @node Diagnostic Abilities
9580 @subsection Diagnostic Abilities
9582 @code{g77} offers better diagnosis of problems in @code{FORMAT} statements.
9583 @code{f2c} doesn't, for example, emit any diagnostic for
9584 @samp{FORMAT(XZFAJG10324)},
9585 leaving that to be diagnosed, at run time, by
9586 the @code{libf2c} run-time library.
9588 @node Compiler Options
9589 @subsection Compiler Options
9591 @code{g77} offers compiler options that @code{f2c} doesn't,
9592 most of which are designed to more easily accommodate
9597 Two that control the automatic appending of extra
9598 underscores to external names
9601 One that allows dollar signs (@samp{$}) in symbol names
9604 A variety that control acceptance of various
9608 Several that specify acceptable use of upper and lower case
9612 Many that enable, disable, delete, or hide
9613 groups of intrinsics
9616 One to specify the length of fixed-form source lines
9620 One to specify the the source code is written in
9621 Fortran-90-style free-form
9624 However, @code{f2c} offers a few that @code{g77} doesn't,
9625 like an option to have @code{REAL} default to @code{REAL*8}.
9626 It is expected that @code{g77} will offer all of the
9627 missing options pertinent to being a Fortran compiler
9628 at some time in the future.
9630 @node Compiler Speed
9631 @subsection Compiler Speed
9633 Saving the steps of writing and then rereading C code is a big reason
9634 why @code{g77} should be able to compile code much faster than using
9635 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9637 However, due to @code{g77}'s youth, lots of self-checking is still being
9639 As a result, this improvement is as yet unrealized
9640 (though the potential seems to be there for quite a big speedup
9642 It is possible that, as of version 0.5.18, @code{g77}
9643 is noticeably faster compiling many Fortran source files than using
9644 @code{f2c} in conjunction with @code{gcc}.
9647 @subsection Program Speed
9649 @code{g77} has the potential to better optimize code than @code{f2c},
9650 even when @code{gcc} is used to compile the output of @code{f2c},
9651 because @code{f2c} must necessarily
9652 translate Fortran into a somewhat lower-level language (C) that cannot
9653 preserve all the information that is potentially useful for optimization,
9654 while @code{g77} can gather, preserve, and transmit that information directly
9657 For example, @code{g77} implements @code{ASSIGN} and assigned
9658 @code{GOTO} using direct assignment of pointers to labels and direct
9659 jumps to labels, whereas @code{f2c} maps the assigned labels to
9660 integer values and then uses a C @code{switch} statement to encode
9661 the assigned @code{GOTO} statements.
9663 However, as is typical, theory and reality don't quite match, at least
9664 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9665 can generate code that is faster than @code{g77}.
9667 Version 0.5.18 of @code{g77} offered default
9668 settings and options, via patches to the @code{gcc}
9669 back end, that allow for better program speed, though
9670 some of these improvements also affected the performance
9671 of programs translated by @code{f2c} and then compiled
9672 by @code{g77}'s version of @code{gcc}.
9674 Version 0.5.20 of @code{g77} offers further performance
9675 improvements, at least one of which (alias analysis) is
9676 not generally applicable to @code{f2c} (though @code{f2c}
9677 could presumably be changed to also take advantage of
9678 this new capability of the @code{gcc} back end, assuming
9679 this is made available in an upcoming release of @code{gcc}).
9681 @node Ease of Debugging
9682 @subsection Ease of Debugging
9684 Because @code{g77} compiles directly to assembler code like @code{gcc},
9685 instead of translating to an intermediate language (C) as does @code{f2c},
9686 support for debugging can be better for @code{g77} than @code{f2c}.
9688 However, although @code{g77} might be somewhat more ``native'' in terms of
9689 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9690 of things ``not quite right''.
9691 Many of the important ones should be resolved in the near future.
9693 For example, @code{g77} doesn't have to worry about reserved names
9694 like @code{f2c} does.
9695 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9696 translate this to something @emph{other} than
9697 @samp{for = while;}, because C reserves those words.
9699 However, @code{g77} does still uses things like an extra level of indirection
9700 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9701 yet support multiple entry points.
9703 Another example is that, given
9711 the @code{g77} user should be able to access the variables directly, by name,
9712 without having to traverse C-like structures and unions, while @code{f2c}
9713 is unlikely to ever offer this ability (due to limitations in the
9716 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9717 take advantage of this facility at all---it doesn't emit any debugging
9718 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9719 other than information
9720 on the array of @code{char} it creates (and, in the case
9721 of local @code{EQUIVALENCE}, names) for each such area.
9723 Yet another example is arrays.
9724 @code{g77} represents them to the debugger
9725 using the same ``dimensionality'' as in the source code, while @code{f2c}
9726 must necessarily convert them all to one-dimensional arrays to fit
9727 into the confines of the C language.
9728 However, the level of support
9729 offered by debuggers for interactive Fortran-style access to arrays
9730 as compiled by @code{g77} can vary widely.
9731 In some cases, it can actually
9732 be an advantage that @code{f2c} converts everything to widely supported
9735 In fairness, @code{g77} could do many of the things @code{f2c} does
9736 to get things working at least as well as @code{f2c}---for now,
9737 the developers prefer making @code{g77} work the
9738 way they think it is supposed to, and finding help improving the
9739 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9740 to get things working properly.
9742 @node Character and Hollerith Constants
9743 @subsection Character and Hollerith Constants
9744 @cindex character constants
9745 @cindex constants, character
9746 @cindex Hollerith constants
9747 @cindex constants, Hollerith
9748 @cindex trailing null byte
9749 @cindex null byte, trailing
9750 @cindex zero byte, trailing
9752 To avoid the extensive hassle that would be needed to avoid this,
9753 @code{f2c} uses C character constants to encode character and Hollerith
9755 That means a constant like @samp{'HELLO'} is translated to
9756 @samp{"hello"} in C, which further means that an extra null byte is
9757 present at the end of the constant.
9758 This null byte is superfluous.
9760 @code{g77} does not generate such null bytes.
9761 This represents significant
9762 savings of resources, such as on systems where @file{/dev/null} or
9763 @file{/dev/zero} represent bottlenecks in the systems' performance,
9764 because @code{g77} simply asks for fewer zeros from the operating
9765 system than @code{f2c}.
9766 (Avoiding spurious use of zero bytes, each byte typically have
9767 eight zero bits, also reduces the liabilities in case
9768 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9770 @node Block Data and Libraries
9771 @section Block Data and Libraries
9772 @cindex block data and libraries
9773 @cindex BLOCK DATA statement
9774 @cindex statements, BLOCK DATA
9775 @cindex libraries, containing BLOCK DATA
9776 @cindex f2c compatibility
9777 @cindex compatibility, f2c
9779 To ensure that block data program units are linked, especially a concern
9780 when they are put into libraries, give each one a name (as in
9781 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9782 statement in every program unit that uses any common block
9783 initialized by the corresponding @code{BLOCK DATA}.
9784 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9786 that is, it generates an actual procedure having the appropriate name.
9787 The procedure does nothing but return immediately if it happens to be
9789 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9790 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9791 in the program and ensures that by generating a
9792 reference to it so the linker will make sure it is present.
9793 (Specifically, @code{g77} outputs in the data section a static pointer to the
9794 external name @samp{FOO}.)
9796 The implementation @code{g77} currently uses to make this work is
9797 one of the few things not compatible with @code{f2c} as currently
9799 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9800 issue a warning that @samp{FOO} is not otherwise referenced,
9801 and, for @samp{BLOCK DATA FOO},
9802 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9803 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9804 this particular case.
9805 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9806 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9807 will result in an unresolved reference when linked.
9809 opposite, then @samp{FOO} might not be linked in under various
9810 circumstances (such as when @samp{FOO} is in a library, or you're
9811 using a ``clever'' linker---so clever, it produces a broken program
9812 with little or no warning by omitting initializations of global data
9813 because they are contained in unreferenced procedures).
9815 The changes you make to your code to make @code{g77} handle this situation,
9816 however, appear to be a widely portable way to handle it.
9817 That is, many systems permit it (as they should, since the
9818 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9819 is a block data program unit), and of the ones
9820 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9821 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9824 Here is the recommended approach to modifying a program containing
9825 a program unit such as the following:
9829 COMMON /VARS/ X, Y, Z
9830 DATA X, Y, Z / 3., 4., 5. /
9835 If the above program unit might be placed in a library module, then
9836 ensure that every program unit in every program that references that
9837 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9838 to force the area to be initialized.
9840 For example, change a program unit that starts with
9843 INTEGER FUNCTION CURX()
9844 COMMON /VARS/ X, Y, Z
9850 so that it uses the @code{EXTERNAL} statement, as in:
9853 INTEGER FUNCTION CURX()
9854 COMMON /VARS/ X, Y, Z
9861 That way, @samp{CURX} is compiled by @code{g77} (and many other
9862 compilers) so that the linker knows it must include @samp{FOO},
9863 the @code{BLOCK DATA} program unit that sets the initial values
9864 for the variables in @samp{VAR}, in the executable program.
9868 @cindex DO statement
9869 @cindex statements, DO
9870 @cindex trips, number of
9871 @cindex number of trips
9873 The meaning of a @code{DO} loop in Fortran is precisely specified
9874 in the Fortran standard@dots{}and is quite different from what
9875 many programmers might expect.
9877 In particular, Fortran iterative @code{DO} loops are implemented as if
9878 the number of trips through the loop is calculated @emph{before}
9879 the loop is entered.
9881 The number of trips for a loop is calculated from the @var{start},
9882 @var{end}, and @var{increment} values specified in a statement such as:
9885 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9889 The trip count is evaluated using a fairly simple formula
9890 based on the three values following the @samp{=} in the
9891 statement, and it is that trip count that is effectively
9892 decremented during each iteration of the loop.
9893 If, at the beginning of an iteration of the loop, the
9894 trip count is zero or negative, the loop terminates.
9895 The per-loop-iteration modifications to @var{iter} are not
9896 related to determining whether to terminate the loop.
9898 There are two important things to remember about the trip
9903 It can be @emph{negative}, in which case it is
9904 treated as if it was zero---meaning the loop is
9905 not executed at all.
9908 The type used to @emph{calculate} the trip count
9909 is the same type as @var{iter}, but the final
9910 calculation, and thus the type of the trip
9911 count itself, always is @code{INTEGER(KIND=1)}.
9914 These two items mean that there are loops that cannot
9915 be written in straightforward fashion using the Fortran @code{DO}.
9917 For example, on a system with the canonical 32-bit two's-complement
9918 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9921 DO I = -2000000000, 2000000000
9925 Although the @var{start} and @var{end} values are well within
9926 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9927 The expected trip count is 40000000001, which is outside
9928 the range of @code{INTEGER(KIND=1)} on many systems.
9930 Instead, the above loop should be constructed this way:
9935 IF (I .GT. 2000000000) EXIT
9942 The simple @code{DO} construct and the @code{EXIT} statement
9943 (used to leave the innermost loop)
9944 are F90 features that @code{g77} supports.
9946 Some Fortran compilers have buggy implementations of @code{DO},
9947 in that they don't follow the standard.
9948 They implement @code{DO} as a straightforward translation
9949 to what, in C, would be a @code{for} statement.
9950 Instead of creating a temporary variable to hold the trip count
9951 as calculated at run time, these compilers
9952 use the iteration variable @var{iter} to control
9953 whether the loop continues at each iteration.
9955 The bug in such an implementation shows up when the
9956 trip count is within the range of the type of @var{iter},
9957 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9958 exceeds that range. For example:
9961 DO I = 2147483600, 2147483647
9965 A loop started by the above statement will work as implemented
9966 by @code{g77}, but the use, by some compilers, of a
9967 more C-like implementation akin to
9970 for (i = 2147483600; i <= 2147483647; ++i)
9974 produces a loop that does not terminate, because @samp{i}
9975 can never be greater than 2147483647, since incrementing it
9976 beyond that value overflows @samp{i}, setting it to -2147483648.
9977 This is a large, negative number that still is less than 2147483647.
9979 Another example of unexpected behavior of @code{DO} involves
9980 using a nonintegral iteration variable @var{iter}, that is,
9981 a @code{REAL} variable.
9982 Consider the following program:
9985 DATA BEGIN, END, STEP /.1, .31, .007/
9986 DO 10 R = BEGIN, END, STEP
9987 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9991 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9996 A C-like view of @code{DO} would hold that the two ``exclamatory''
9997 @code{PRINT} statements are never executed.
9998 However, this is the output of running the above program
9999 as compiled by @code{g77} on a GNU/Linux ix86 system:
10011 .310000002 .LE. .310000002!!
10014 Note that one of the two checks in the program turned up
10015 an apparent violation of the programmer's expectation---yet,
10016 the loop is correctly implemented by @code{g77}, in that
10017 it has 30 iterations.
10018 This trip count of 30 is correct when evaluated using
10019 the floating-point representations for the @var{begin},
10020 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
10022 On other systems, an apparently more accurate trip count
10023 of 31 might result, but, nevertheless, @code{g77} is
10024 faithfully following the Fortran standard, and the result
10025 is not what the author of the sample program above
10026 apparently expected.
10027 (Such other systems might, for different values in the @code{DATA}
10028 statement, violate the other programmer's expectation,
10031 Due to this combination of imprecise representation
10032 of floating-point values and the often-misunderstood
10033 interpretation of @code{DO} by standard-conforming
10034 compilers such as @code{g77}, use of @code{DO} loops
10035 with @code{REAL} iteration
10036 variables is not recommended.
10037 Such use can be caught by specifying @samp{-Wsurprising}.
10038 @xref{Warning Options}, for more information on this
10041 @node Working Programs
10042 @section Working Programs
10044 Getting Fortran programs to work in the first place can be
10045 quite a challenge---even when the programs already work on
10046 other systems, or when using other compilers.
10048 @code{g77} offers some facilities that might be useful for
10049 tracking down bugs in such programs.
10053 * Variables Assumed To Be Zero::
10054 * Variables Assumed To Be Saved::
10055 * Unwanted Variables::
10056 * Unused Arguments::
10057 * Surprising Interpretations of Code::
10058 * Aliasing Assumed To Work::
10059 * Output Assumed To Flush::
10060 * Large File Unit Numbers::
10061 * Floating-point precision::
10062 * Inconsistent Calling Sequences::
10066 @subsection Not My Type
10067 @cindex mistyped variables
10068 @cindex variables, mistyped
10069 @cindex mistyped functions
10070 @cindex functions, mistyped
10071 @cindex implicit typing
10073 A fruitful source of bugs in Fortran source code is use, or
10074 mis-use, of Fortran's implicit-typing feature, whereby the
10075 type of a variable, array, or function is determined by the
10076 first character of its name.
10078 Simple cases of this include statements like @samp{LOGX=9.227},
10079 without a statement such as @samp{REAL LOGX}.
10080 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
10081 type, with the result of the assignment being that it is given
10082 the value @samp{9}.
10084 More involved cases include a function that is defined starting
10085 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
10086 Any caller of this function that does not also declare @samp{IPS}
10087 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
10088 is likely to assume it returns
10089 @code{INTEGER}, or some other type, leading to invalid results
10090 or even program crashes.
10092 The @samp{-Wimplicit} option might catch failures to
10093 properly specify the types of
10094 variables, arrays, and functions in the code.
10096 However, in code that makes heavy use of Fortran's
10097 implicit-typing facility, this option might produce so
10098 many warnings about cases that are working, it would be
10099 hard to find the one or two that represent bugs.
10100 This is why so many experienced Fortran programmers strongly
10101 recommend widespread use of the @code{IMPLICIT NONE} statement,
10102 despite it not being standard FORTRAN 77, to completely turn
10103 off implicit typing.
10104 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
10105 FORTRAN 77 compilers.)
10107 Note that @samp{-Wimplicit} catches only implicit typing of
10109 It does not catch implicit typing of expressions such
10110 as @samp{X**(2/3)}.
10111 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
10112 is equivalent to @samp{X**0}, due to the way Fortran expressions
10113 are given types and then evaluated.
10114 (In this particular case, the programmer probably wanted
10115 @samp{X**(2./3.)}.)
10117 @node Variables Assumed To Be Zero
10118 @subsection Variables Assumed To Be Zero
10119 @cindex zero-initialized variables
10120 @cindex variables, assumed to be zero
10121 @cindex uninitialized variables
10123 Many Fortran programs were developed on systems that provided
10124 automatic initialization of all, or some, variables and arrays
10126 As a result, many of these programs depend, sometimes
10127 inadvertently, on this behavior, though to do so violates
10128 the Fortran standards.
10130 You can ask @code{g77} for this behavior by specifying the
10131 @samp{-finit-local-zero} option when compiling Fortran code.
10132 (You might want to specify @samp{-fno-automatic} as well,
10133 to avoid code-size inflation for non-optimized compilations.)
10135 Note that a program that works better when compiled with the
10136 @samp{-finit-local-zero} option
10137 is almost certainly depending on a particular system's,
10138 or compiler's, tendency to initialize some variables to zero.
10139 It might be worthwhile finding such cases and fixing them,
10140 using techniques such as compiling with the @samp{-O -Wuninitialized}
10141 options using @code{g77}.
10143 @node Variables Assumed To Be Saved
10144 @subsection Variables Assumed To Be Saved
10145 @cindex variables, retaining values across calls
10146 @cindex saved variables
10147 @cindex static variables
10149 Many Fortran programs were developed on systems that
10150 saved the values of all, or some, variables and arrays
10151 across procedure calls.
10152 As a result, many of these programs depend, sometimes
10153 inadvertently, on being able to assign a value to a
10154 variable, perform a @code{RETURN} to a calling procedure,
10155 and, upon subsequent invocation, reference the previously
10156 assigned variable to obtain the value.
10158 They expect this despite not using the @code{SAVE} statement
10159 to specify that the value in a variable is expected to survive
10160 procedure returns and calls.
10161 Depending on variables and arrays to retain values across
10162 procedure calls without using @code{SAVE} to require it violates
10163 the Fortran standards.
10165 You can ask @code{g77} to assume @code{SAVE} is specified for all
10166 relevant (local) variables and arrays by using the
10167 @samp{-fno-automatic} option.
10169 Note that a program that works better when compiled with the
10170 @samp{-fno-automatic} option
10171 is almost certainly depending on not having to use
10172 the @code{SAVE} statement as required by the Fortran standard.
10173 It might be worthwhile finding such cases and fixing them,
10174 using techniques such as compiling with the @samp{-O -Wuninitialized}
10175 options using @code{g77}.
10177 @node Unwanted Variables
10178 @subsection Unwanted Variables
10180 The @samp{-Wunused} option can find bugs involving
10181 implicit typing, sometimes
10182 more easily than using @samp{-Wimplicit} in code that makes
10183 heavy use of implicit typing.
10184 An unused variable or array might indicate that the
10185 spelling for its declaration is different from that of
10188 Other than cases involving typos, unused variables rarely
10189 indicate actual bugs in a program.
10190 However, investigating such cases thoroughly has, on occasion,
10191 led to the discovery of code that had not been completely
10192 written---where the programmer wrote declarations as needed
10193 for the whole algorithm, wrote some or even most of the code
10194 for that algorithm, then got distracted and forgot that the
10195 job was not complete.
10197 @node Unused Arguments
10198 @subsection Unused Arguments
10199 @cindex unused arguments
10200 @cindex arguments, unused
10202 As with unused variables, It is possible that unused arguments
10203 to a procedure might indicate a bug.
10204 Compile with @samp{-W -Wunused} option to catch cases of
10207 Note that @samp{-W} also enables warnings regarding overflow
10208 of floating-point constants under certain circumstances.
10210 @node Surprising Interpretations of Code
10211 @subsection Surprising Interpretations of Code
10213 The @samp{-Wsurprising} option can help find bugs involving
10214 expression evaluation or in
10215 the way @code{DO} loops with non-integral iteration variables
10217 Cases found by this option might indicate a difference of
10218 interpretation between the author of the code involved, and
10219 a standard-conforming compiler such as @code{g77}.
10220 Such a difference might produce actual bugs.
10222 In any case, changing the code to explicitly do what the
10223 programmer might have expected it to do, so @code{g77} and
10224 other compilers are more likely to follow the programmer's
10225 expectations, might be worthwhile, especially if such changes
10226 make the program work better.
10228 @node Aliasing Assumed To Work
10229 @subsection Aliasing Assumed To Work
10230 @cindex -falias-check option
10231 @cindex options, -falias-check
10232 @cindex -fargument-alias option
10233 @cindex options, -fargument-alias
10234 @cindex -fargument-noalias option
10235 @cindex options, -fargument-noalias
10236 @cindex -fno-argument-noalias-global option
10237 @cindex options, -fno-argument-noalias-global
10239 @cindex anti-aliasing
10240 @cindex overlapping arguments
10242 @cindex association, storage
10243 @cindex storage association
10244 @cindex scheduling of reads and writes
10245 @cindex reads and writes, scheduling
10247 The @samp{-falias-check}, @samp{-fargument-alias},
10248 @samp{-fargument-noalias},
10249 and @samp{-fno-argument-noalias-global} options,
10250 introduced in version 0.5.20 and
10251 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10252 were withdrawn as of @code{g77} version 0.5.23
10253 due to their not being supported by @code{gcc} version 2.8.
10255 These options control the assumptions regarding aliasing
10256 (overlapping) of writes and reads to main memory (core) made
10257 by the @code{gcc} back end.
10259 The information below still is useful, but applies to
10260 only those versions of @code{g77} that support the
10261 alias analysis implied by support for these options.
10263 These options are effective only when compiling with @samp{-O}
10264 (specifying any level other than @samp{-O0})
10265 or with @samp{-falias-check}.
10267 The default for Fortran code is @samp{-fargument-noalias-global}.
10268 (The default for C code and code written in other C-based languages
10269 is @samp{-fargument-alias}.
10270 These defaults apply regardless of whether you use @code{g77} or
10271 @code{gcc} to compile your code.)
10273 Note that, on some systems, compiling with @samp{-fforce-addr} in
10274 effect can produce more optimal code when the default aliasing
10275 options are in effect (and when optimization is enabled).
10277 If your program is not working when compiled with optimization,
10278 it is possible it is violating the Fortran standards (77 and 90)
10279 by relying on the ability to ``safely'' modify variables and
10280 arrays that are aliased, via procedure calls, to other variables
10281 and arrays, without using @code{EQUIVALENCE} to explicitly
10282 set up this kind of aliasing.
10284 (The FORTRAN 77 standard's prohibition of this sort of
10285 overlap, generally referred to therein as ``storage
10286 assocation'', appears in Sections 15.9.3.6.
10287 This prohibition allows implementations, such as @code{g77},
10288 to, for example, implement the passing of procedures and
10289 even values in @code{COMMON} via copy operations into local,
10290 perhaps more efficiently accessed temporaries at entry to a
10291 procedure, and, where appropriate, via copy operations back
10292 out to their original locations in memory at exit from that
10293 procedure, without having to take into consideration the
10294 order in which the local copies are updated by the code,
10295 among other things.)
10297 To test this hypothesis, try compiling your program with
10298 the @samp{-fargument-alias} option, which causes the
10299 compiler to revert to assumptions essentially the same as
10300 made by versions of @code{g77} prior to 0.5.20.
10302 If the program works using this option, that strongly suggests
10303 that the bug is in your program.
10304 Finding and fixing the bug(s) should result in a program that
10305 is more standard-conforming and that can be compiled by @code{g77}
10306 in a way that results in a faster executable.
10308 (You might want to try compiling with @samp{-fargument-noalias},
10309 a kind of half-way point, to see if the problem is limited to
10310 aliasing between dummy arguments and @code{COMMON} variables---this
10311 option assumes that such aliasing is not done, while still allowing
10312 aliasing among dummy arguments.)
10314 An example of aliasing that is invalid according to the standards
10315 is shown in the following program, which might @emph{not} produce
10316 the expected results when executed:
10324 SUBROUTINE FOO(J, K)
10331 The above program attempts to use the temporary aliasing of the
10332 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10333 pathological behavior---the simultaneous changing of the values
10334 of @emph{both} @samp{J} and @samp{K} when either one of them
10337 The programmer likely expects the program to print these values:
10344 However, since the program is not standard-conforming, an
10345 implementation's behavior when running it is undefined, because
10346 subroutine @samp{FOO} modifies at least one of the arguments,
10347 and they are aliased with each other.
10348 (Even if one of the assignment statements was deleted, the
10349 program would still violate these rules.
10350 This kind of on-the-fly aliasing is permitted by the standard
10351 only when none of the aliased items are defined, or written,
10352 while the aliasing is in effect.)
10354 As a practical example, an optimizing compiler might schedule
10355 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10356 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10357 resulting in the following output:
10364 Essentially, compilers are promised (by the standard and, therefore,
10365 by programmers who write code they claim to be standard-conforming)
10366 that if they cannot detect aliasing via static analysis of a single
10367 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10368 such aliasing exists.
10369 In such cases, compilers are free to assume that an assignment to
10370 one variable will not change the value of another variable, allowing
10371 it to avoid generating code to re-read the value of the other
10372 variable, to re-schedule reads and writes, and so on, to produce
10373 a faster executable.
10375 The same promise holds true for arrays (as seen by the called
10376 procedure)---an element of one dummy array cannot be aliased
10377 with, or overlap, any element of another dummy array or be
10378 in a @code{COMMON} area known to the procedure.
10380 (These restrictions apply only when the procedure defines, or
10381 writes to, one of the aliased variables or arrays.)
10383 Unfortunately, there is no way to find @emph{all} possible cases of
10384 violations of the prohibitions against aliasing in Fortran code.
10385 Static analysis is certainly imperfect, as is run-time analysis,
10386 since neither can catch all violations.
10387 (Static analysis can catch all likely violations, and some that
10388 might never actually happen, while run-time analysis can catch
10389 only those violations that actually happen during a particular run.
10390 Neither approach can cope with programs mixing Fortran code with
10391 routines written in other languages, however.)
10393 Currently, @code{g77} provides neither static nor run-time facilities
10394 to detect any cases of this problem, although other products might.
10395 Run-time facilities are more likely to be offered by future
10396 versions of @code{g77}, though patches improving @code{g77} so that
10397 it provides either form of detection are welcome.
10399 @node Output Assumed To Flush
10400 @subsection Output Assumed To Flush
10401 @cindex ALWAYS_FLUSH
10402 @cindex synchronous write errors
10404 @cindex flushing output
10406 @cindex I/O, flushing
10407 @cindex output, flushing
10408 @cindex writes, flushing
10410 @cindex network file system
10412 For several versions prior to 0.5.20, @code{g77} configured its
10413 version of the @code{libf2c} run-time library so that one of
10414 its configuration macros, @code{ALWAYS_FLUSH}, was defined.
10416 This was done as a result of a belief that many programs expected
10417 output to be flushed to the operating system (under UNIX, via
10418 the @code{fflush()} library call) with the result that errors,
10419 such as disk full, would be immediately flagged via the
10420 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10422 Because of the adverse effects this approach had on the performance
10423 of many programs, @code{g77} no longer configures @code{libf2c}
10424 (now named @code{libg2c} in its @code{g77} incarnation)
10425 to always flush output.
10427 If your program depends on this behavior, either insert the
10428 appropriate @samp{CALL FLUSH} statements, or modify the sources
10429 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10430 relink your programs with the modified library.
10432 (Ideally, @code{libg2c} would offer the choice at run-time, so
10433 that a compile-time option to @code{g77} or @code{f2c} could
10434 result in generating the appropriate calls to flushing or
10435 non-flushing library routines.)
10437 @xref{Always Flush Output}, for information on how to modify
10438 the @code{g77} source tree so that a version of @code{libg2c}
10439 can be built and installed with the @code{ALWAYS_FLUSH} macro defined.
10441 @node Large File Unit Numbers
10442 @subsection Large File Unit Numbers
10444 @cindex unit numbers
10445 @cindex maximum unit number
10446 @cindex illegal unit number
10447 @cindex increasing maximum unit number
10449 If your program crashes at run time with a message including
10450 the text @samp{illegal unit number}, that probably is
10451 a message from the run-time library, @code{libg2c}.
10453 The message means that your program has attempted to use a
10454 file unit number that is out of the range accepted by
10456 Normally, this range is 0 through 99, and the high end
10457 of the range is controlled by a @code{libg2c} source-file
10458 macro named @code{MXUNIT}.
10460 If you can easily change your program to use unit numbers
10461 in the range 0 through 99, you should do so.
10463 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10464 to change @code{MXUNIT} in @code{libg2c} so you can build and
10465 install a new version of @code{libg2c} that supports the larger
10466 unit numbers you need.
10468 @emph{Note:} While @code{libg2c} places a limit on the range
10469 of Fortran file-unit numbers, the underlying library and operating
10470 system might impose different kinds of limits.
10471 For example, some systems limit the number of files simultaneously
10472 open by a running program.
10473 Information on how to increase these limits should be found
10474 in your system's documentation.
10476 @node Floating-point precision
10477 @subsection Floating-point precision
10479 @cindex IEEE 754 conformance
10480 @cindex conformance, IEEE 754
10481 @cindex floating-point, precision
10482 @cindex ix86 floating-point
10483 @cindex x86 floating-point
10484 If your program depends on exact IEEE 754 floating-point handling it may
10485 help on some systems---specifically x86 or m68k hardware---to use
10486 the @samp{-ffloat-store} option or to reset the precision flag on the
10487 floating-point unit.
10488 @xref{Optimize Options}.
10490 However, it might be better simply to put the FPU into double precision
10491 mode and not take the performance hit of @samp{-ffloat-store}. On x86
10492 and m68k GNU systems you can do this with a technique similar to that
10493 for turning on floating-point exceptions
10494 (@pxref{Floating-point Exception Handling}).
10495 The control word could be set to double precision by some code like this
10498 #include <fpu_control.h>
10500 fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
10504 (It is not clear whether this has any effect on the operation of the GNU
10505 maths library, but we have no evidence of it causing trouble.)
10507 Some targets (such as the Alpha) may need special options for full IEEE
10509 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and Porting GNU CC}.
10511 @node Inconsistent Calling Sequences
10512 @subsection Inconsistent Calling Sequences
10515 @cindex floating-point, errors
10516 @cindex ix86 FPU stack
10517 @cindex x86 FPU stack
10518 Code containing inconsistent calling sequences in the same file is
10519 normally rejected---see @ref{GLOBALS}.
10520 (Use, say, @code{ftnchek} to ensure
10521 consistency across source files.
10522 @xref{f2c Skeletons and Prototypes,,
10523 Generating Skeletons and Prototypes with @code{f2c}}.)
10525 Mysterious errors, which may appear to be code generation problems, can
10526 appear specifically on the x86 architecture with some such
10527 inconsistencies. On x86 hardware, floating-point return values of
10528 functions are placed on the floating-point unit's register stack, not
10529 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
10530 @code{FUNCTION} as some other sort of procedure, or vice versa,
10531 scrambles the floating-point stack. This may break unrelated code
10532 executed later. Similarly if, say, external C routines are written
10535 @node Overly Convenient Options
10536 @section Overly Convenient Command-line Options
10537 @cindex overly convenient options
10538 @cindex options, overly convenient
10540 These options should be used only as a quick-and-dirty way to determine
10541 how well your program will run under different compilation models
10542 without having to change the source.
10543 Some are more problematic
10544 than others, depending on how portable and maintainable you want the
10545 program to be (and, of course, whether you are allowed to change it
10546 at all is crucial).
10548 You should not continue to use these command-line options to compile
10549 a given program, but rather should make changes to the source code:
10552 @cindex -finit-local-zero option
10553 @cindex options, -finit-local-zero
10554 @item -finit-local-zero
10555 (This option specifies that any uninitialized local variables
10556 and arrays have default initialization to binary zeros.)
10558 Many other compilers do this automatically, which means lots of
10559 Fortran code developed with those compilers depends on it.
10561 It is safer (and probably
10562 would produce a faster program) to find the variables and arrays that
10563 need such initialization and provide it explicitly via @code{DATA}, so that
10564 @samp{-finit-local-zero} is not needed.
10566 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10567 find likely candidates, but
10568 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10569 or this technique won't work.
10571 @cindex -fno-automatic option
10572 @cindex options, -fno-automatic
10573 @item -fno-automatic
10574 (This option specifies that all local variables and arrays
10575 are to be treated as if they were named in @code{SAVE} statements.)
10577 Many other compilers do this automatically, which means lots of
10578 Fortran code developed with those compilers depends on it.
10580 The effect of this is that all non-automatic variables and arrays
10581 are made static, that is, not placed on the stack or in heap storage.
10582 This might cause a buggy program to appear to work better.
10583 If so, rather than relying on this command-line option (and hoping all
10584 compilers provide the equivalent one), add @code{SAVE}
10585 statements to some or all program unit sources, as appropriate.
10586 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10587 to find likely candidates, but
10588 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10589 or this technique won't work.
10591 The default is @samp{-fautomatic}, which tells @code{g77} to try
10592 and put variables and arrays on the stack (or in fast registers)
10593 where possible and reasonable.
10594 This tends to make programs faster.
10596 @cindex automatic arrays
10597 @cindex arrays, automatic
10598 @emph{Note:} Automatic variables and arrays are not affected
10600 These are variables and arrays that are @emph{necessarily} automatic,
10601 either due to explicit statements, or due to the way they are
10603 Examples include local variables and arrays not given the
10604 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10605 and local arrays declared with non-constant bounds (automatic
10607 Currently, @code{g77} supports only automatic arrays, not
10608 @code{RECURSIVE} procedures or other means of explicitly
10609 specifying that variables or arrays are automatic.
10611 @cindex -f@var{group}-intrinsics-hide option
10612 @cindex options, -f@var{group}-intrinsics-hide
10613 @item -f@var{group}-intrinsics-hide
10614 Change the source code to use @code{EXTERNAL} for any external procedure
10615 that might be the name of an intrinsic.
10616 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10619 @node Faster Programs
10620 @section Faster Programs
10621 @cindex speed, of programs
10622 @cindex programs, speeding up
10624 Aside from the usual @code{gcc} options, such as @samp{-O},
10625 @samp{-ffast-math}, and so on, consider trying some of the
10626 following approaches to speed up your program (once you get
10631 * Prefer Automatic Uninitialized Variables::
10632 * Avoid f2c Compatibility::
10633 * Use Submodel Options::
10637 @subsection Aligned Data
10639 @cindex data, aligned
10640 @cindex stack, aligned
10641 @cindex aligned data
10642 @cindex aligned stack
10643 @cindex Pentium optimizations
10644 @cindex optimization, for Pentium
10646 On some systems, such as those with Pentium Pro CPUs, programs
10647 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10648 might run much slower
10649 than possible due to the compiler not aligning these 64-bit
10650 values to 64-bit boundaries in memory.
10651 (The effect also is present, though
10652 to a lesser extent, on the 586 (Pentium) architecture.)
10654 The Intel x86 architecture generally ensures that these programs will
10655 work on all its implementations,
10656 but particular implementations (such as Pentium Pro)
10657 perform better with more strict alignment.
10658 (Such behavior isn't unique to the Intel x86 architecture.)
10659 Other architectures might @emph{demand} 64-bit alignment
10662 There are a variety of approaches to use to address this problem:
10666 @cindex @code{COMMON} layout
10667 @cindex layout of @code{COMMON} blocks
10668 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10669 that the variables and arrays with the widest alignment
10670 guidelines come first.
10672 For example, on most systems, this would mean placing
10673 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10674 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10675 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10676 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10677 and @code{INTEGER(KIND=3)} entities.
10679 The reason to use such placement is it makes it more likely
10680 that your data will be aligned properly, without requiring
10681 you to do detailed analysis of each aggregate (@code{COMMON}
10682 and @code{EQUIVALENCE}) area.
10684 Specifically, on systems where the above guidelines are
10685 appropriate, placing @code{CHARACTER} entities before
10686 @code{REAL(KIND=2)} entities can work just as well,
10687 but only if the number of bytes occupied by the @code{CHARACTER}
10688 entities is divisible by the recommended alignment for
10689 @code{REAL(KIND=2)}.
10691 By ordering the placement of entities in aggregate
10692 areas according to the simple guidelines above, you
10693 avoid having to carefully count the number of bytes
10694 occupied by each entity to determine whether the
10695 actual alignment of each subsequent entity meets the
10696 alignment guidelines for the type of that entity.
10698 If you don't ensure correct alignment of @code{COMMON} elements, the
10699 compiler may be forced by some systems to violate the Fortran semantics by
10700 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10701 If the unfortunate practice is employed of overlaying different types of
10702 data in the @code{COMMON} block, the different variants
10703 of this block may become misaligned with respect to each other.
10704 Even if your platform doesn't require strict alignment,
10705 @code{COMMON} should be laid out as above for portability.
10706 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10707 possible requirement, which is compiler-independent on a given platform.)
10710 @cindex -malign-double option
10711 @cindex options, -malign-double
10712 Use the (x86-specific) @samp{-malign-double} option when compiling
10713 programs for the Pentium and Pentium Pro architectures (called 586
10714 and 686 in the @code{gcc} configuration subsystem).
10715 The warning about this in the @code{gcc} manual isn't
10716 generally relevant to Fortran,
10717 but using it will force @code{COMMON} to be padded if necessary to align
10718 @code{DOUBLE PRECISION} data.
10720 When @code{DOUBLE PRECISION} data is forcibly aligned
10721 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10722 @code{g77} issues a warning about the need to
10725 In this case, each and every program unit that uses
10726 the same @code{COMMON} area
10727 must specify the same layout of variables and their types
10729 and be compiled with @samp{-malign-double} as well.
10730 @code{g77} will issue warnings in each case,
10731 but as long as every program unit using that area
10732 is compiled with the same warnings,
10733 the resulting object files should work when linked together
10734 unless the program makes additional assumptions about
10735 @code{COMMON} area layouts that are outside the scope
10736 of the FORTRAN 77 standard,
10737 or uses @code{EQUIVALENCE} or different layouts
10738 in ways that assume no padding is ever inserted by the compiler.
10741 Ensure that @file{crt0.o} or @file{crt1.o}
10742 on your system guarantees a 64-bit
10743 aligned stack for @code{main()}.
10744 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10745 but we don't know of any other x86 setups where it will be right.
10746 Read your system's documentation to determine if
10747 it is appropriate to upgrade to a more recent version
10748 to obtain the optimal alignment.
10751 Progress is being made on making this work
10752 ``out of the box'' on future versions of @code{g77},
10753 @code{gcc}, and some of the relevant operating systems
10754 (such as GNU/Linux).
10756 @cindex alignment testing
10757 @cindex testing alignment
10758 A package that tests the degree to which a Fortran compiler
10759 (such as @code{g77})
10760 aligns 64-bit floating-point variables and arrays
10761 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
10763 @node Prefer Automatic Uninitialized Variables
10764 @subsection Prefer Automatic Uninitialized Variables
10766 If you're using @samp{-fno-automatic} already, you probably
10767 should change your code to allow compilation with @samp{-fautomatic}
10768 (the default), to allow the program to run faster.
10770 Similarly, you should be able to use @samp{-fno-init-local-zero}
10771 (the default) instead of @samp{-finit-local-zero}.
10772 This is because it is rare that every variable affected by these
10773 options in a given program actually needs to
10776 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10777 every local non-automatic variable and array, affects even things like
10778 @code{DO} iteration
10779 variables, which rarely need to be @code{SAVE}d, and this often reduces
10780 run-time performances.
10781 Similarly, @samp{-fno-init-local-zero} forces such
10782 variables to be initialized to zero---when @code{SAVE}d (such as when
10783 @samp{-fno-automatic}), this by itself generally affects only
10784 startup time for a program, but when not @code{SAVE}d,
10785 it can slow down the procedure every time it is called.
10787 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10788 for information on the @samp{-fno-automatic} and
10789 @samp{-finit-local-zero} options and how to convert
10790 their use into selective changes in your own code.
10792 @node Avoid f2c Compatibility
10793 @subsection Avoid f2c Compatibility
10794 @cindex -fno-f2c option
10795 @cindex options, -fno-f2c
10796 @cindex @code{f2c} compatibility
10797 @cindex compatibility, @code{f2c}
10799 If you aren't linking with any code compiled using
10800 @code{f2c}, try using the @samp{-fno-f2c} option when
10801 compiling @emph{all} the code in your program.
10802 (Note that @code{libf2c} is @emph{not} an example of code
10803 that is compiled using @code{f2c}---it is compiled by a C
10804 compiler, typically @code{gcc}.)
10806 @node Use Submodel Options
10807 @subsection Use Submodel Options
10810 Using an appropriate @samp{-m} option to generate specific code for your
10811 CPU may be worthwhile, though it may mean the executable won't run on
10812 other versions of the CPU that don't support the same instruction set.
10813 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10814 Porting GNU CC}. For instance on an x86 system the compiler might have
10815 been built---as shown by @samp{g77 -v}---for the target
10816 @samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
10817 generate code best optimized for a Pentium you could use the option
10818 @samp{-march=pentium}.
10820 For recent CPUs that don't have explicit support in the released version
10821 of @code{gcc}, it @emph{might} still be possible to get improvements
10822 with certain @samp{-m} options.
10824 @samp{-fomit-frame-pointer} can help performance on x86 systems and
10825 others. It will, however, inhibit debugging on the systems on which it
10826 is not turned on anyway by @samp{-O}.
10829 @chapter Known Causes of Trouble with GNU Fortran
10830 @cindex bugs, known
10831 @cindex installation trouble
10832 @cindex known causes of trouble
10834 This section describes known problems that affect users of GNU Fortran.
10835 Most of these are not GNU Fortran bugs per se---if they were, we would
10837 But the result for a user might be like the result of a bug.
10839 Some of these problems are due to bugs in other software, some are
10840 missing features that are too much work to add, and some are places
10841 where people's opinions differ as to what is best.
10843 Information on bugs that show up when configuring, porting, building,
10844 or installing @code{g77} is not provided here.
10845 @xref{Problems Installing}.
10847 To find out about major bugs discovered in the current release and
10848 possible workarounds for them, see
10849 @uref{ftp://alpha.gnu.org/g77.plan}.
10851 (Note that some of this portion of the manual is lifted
10852 directly from the @code{gcc} manual, with minor modifications
10853 to tailor it to users of @code{g77}.
10854 Anytime a bug seems to have more to do with the @code{gcc}
10855 portion of @code{g77}, see
10856 @ref{Trouble,,Known Causes of Trouble with GNU CC,
10857 gcc,Using and Porting GNU CC}.)
10860 * But-bugs:: Bugs really in other programs or elsewhere.
10861 * Known Bugs:: Bugs known to be in this version of @code{g77}.
10862 * Missing Features:: Features we already know we want to add later.
10863 * Disappointments:: Regrettable things we can't change.
10864 * Non-bugs:: Things we think are right, but some others disagree.
10865 * Warnings and Errors:: Which problems in your code get warnings,
10866 and which get errors.
10870 @section Bugs Not In GNU Fortran
10873 These are bugs to which the maintainers often have to reply,
10874 ``but that isn't a bug in @code{g77}@dots{}''.
10875 Some of these already are fixed in new versions of other
10876 software; some still need to be fixed; some are problems
10877 with how @code{g77} is installed or is being used;
10878 some are the result of bad hardware that causes software
10879 to misbehave in sometimes bizarre ways;
10880 some just cannot be addressed at this time until more
10881 is known about the problem.
10883 Please don't re-report these bugs to the @code{g77} maintainers---if
10884 you must remind someone how important it is to you that the problem
10885 be fixed, talk to the people responsible for the other products
10886 identified below, but preferably only after you've tried the
10887 latest versions of those products.
10888 The @code{g77} maintainers have their hands full working on
10889 just fixing and improving @code{g77}, without serving as a
10890 clearinghouse for all bugs that happen to affect @code{g77}
10893 @xref{Collected Fortran Wisdom}, for information on behavior
10894 of Fortran programs, and the programs that compile them, that
10895 might be @emph{thought} to indicate bugs.
10898 * Signal 11 and Friends:: Strange behavior by any software.
10899 * Cannot Link Fortran Programs:: Unresolved references.
10900 * Large Common Blocks:: Problems on older GNU/Linux systems.
10901 * Debugger Problems:: When the debugger crashes.
10902 * NeXTStep Problems:: Misbehaving executables.
10903 * Stack Overflow:: More misbehaving executables.
10904 * Nothing Happens:: Less behaving executables.
10905 * Strange Behavior at Run Time:: Executables misbehaving due to
10906 bugs in your program.
10907 * Floating-point Errors:: The results look wrong, but@dots{}.
10910 @node Signal 11 and Friends
10911 @subsection Signal 11 and Friends
10913 @cindex hardware errors
10915 A whole variety of strange behaviors can occur when the
10916 software, or the way you are using the software,
10917 stresses the hardware in a way that triggers hardware bugs.
10918 This might seem hard to believe, but it happens frequently
10919 enough that there exist documents explaining in detail
10920 what the various causes of the problems are, what
10921 typical symptoms look like, and so on.
10923 Generally these problems are referred to in this document
10924 as ``signal 11'' crashes, because the Linux kernel, running
10925 on the most popular hardware (the Intel x86 line), often
10926 stresses the hardware more than other popular operating
10928 When hardware problems do occur under GNU/Linux on x86
10929 systems, these often manifest themselves as ``signal 11''
10930 problems, as illustrated by the following diagnostic:
10933 sh# @kbd{g77 myprog.f}
10934 gcc: Internal compiler error: program f771 got fatal signal 11
10938 It is @emph{very} important to remember that the above
10939 message is @emph{not} the only one that indicates a
10940 hardware problem, nor does it always indicate a hardware
10943 In particular, on systems other than those running the Linux
10944 kernel, the message might appear somewhat or very different,
10945 as it will if the error manifests itself while running a
10946 program other than the @code{g77} compiler.
10948 it will appear somewhat different when running your program,
10949 when running Emacs, and so on.
10951 How to cope with such problems is well beyond the scope
10954 However, users of Linux-based systems (such as GNU/Linux)
10955 should review @uref{http://www.bitwizard.nl/sig11/}, a source
10956 of detailed information on diagnosing hardware problems,
10957 by recognizing their common symptoms.
10959 Users of other operating systems and hardware might
10960 find this reference useful as well.
10961 If you know of similar material for another hardware/software
10962 combination, please let us know so we can consider including
10963 a reference to it in future versions of this manual.
10965 @node Cannot Link Fortran Programs
10966 @subsection Cannot Link Fortran Programs
10967 @cindex unresolved reference (various)
10968 @cindex linking error for user code
10970 @cindex @code{ld}, error linking user code
10971 @cindex @code{ld}, can't find strange names
10972 On some systems, perhaps just those with out-of-date (shared?)
10973 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10974 programs (which should be done using @code{g77}).
10976 If this happens to you, try appending @samp{-lc} to the command you
10977 use to link the program, e.g. @samp{g77 foo.f -lc}.
10978 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10979 but it cannot also specify @samp{-lc} because not all systems have a
10980 file named @file{libc.a}.
10982 It is unclear at this point whether there are legitimately installed
10983 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10986 @cindex undefined reference (_main)
10987 @cindex linking error, user code
10988 @cindex @code{ld}, error linking user code
10990 @cindex @code{ld}, can't find @samp{_main}
10991 If your program doesn't link due to unresolved references to names
10992 like @samp{_main}, make sure you're using the @code{g77} command to do the
10993 link, since this command ensures that the necessary libraries are
10994 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10995 command to do the actual link.
10996 (Use the @samp{-v} option to discover
10997 more about what actually happens when you use the @code{g77} and @code{gcc}
11000 Also, try specifying @samp{-lc} as the last item on the @code{g77}
11001 command line, in case that helps.
11003 @node Large Common Blocks
11004 @subsection Large Common Blocks
11005 @cindex common blocks, large
11006 @cindex large common blocks
11007 @cindex linking, errors
11008 @cindex @code{ld}, errors
11009 @cindex errors, linker
11010 On some older GNU/Linux systems, programs with common blocks larger
11011 than 16MB cannot be linked without some kind of error
11012 message being produced.
11014 This is a bug in older versions of @code{ld}, fixed in
11015 more recent versions of @code{binutils}, such as version 2.6.
11017 @node Debugger Problems
11018 @subsection Debugger Problems
11019 @cindex @code{gdb}, support
11020 @cindex support, @code{gdb}
11021 There are some known problems when using @code{gdb} on code
11022 compiled by @code{g77}.
11023 Inadequate investigation as of the release of 0.5.16 results in not
11024 knowing which products are the culprit, but @file{gdb-4.14} definitely
11025 crashes when, for example, an attempt is made to print the contents
11026 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
11027 machines, plus some others.
11028 Attempts to access assumed-size arrays are
11029 also known to crash recent versions of @code{gdb}.
11030 (@code{gdb}'s Fortran support was done for a different compiler
11031 and isn't properly compatible with @code{g77}.)
11033 @node NeXTStep Problems
11034 @subsection NeXTStep Problems
11035 @cindex NeXTStep problems
11037 @cindex segmentation violation
11038 Developers of Fortran code on NeXTStep (all architectures) have to
11039 watch out for the following problem when writing programs with
11040 large, statically allocated (i.e. non-stack based) data structures
11041 (common blocks, saved arrays).
11043 Due to the way the native loader (@file{/bin/ld}) lays out
11044 data structures in virtual memory, it is very easy to create an
11045 executable wherein the @samp{__DATA} segment overlaps (has addresses in
11046 common) with the @samp{UNIX STACK} segment.
11048 This leads to all sorts of trouble, from the executable simply not
11049 executing, to bus errors.
11050 The NeXTStep command line tool @code{ebadexec} points to
11051 the problem as follows:
11054 % @kbd{/bin/ebadexec a.out}
11055 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
11056 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
11057 STACK segment (truncated address = 0x400000 rounded size =
11058 0x3c00000) of executable file: a.out
11061 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
11064 This can be cured by assigning the @samp{__DATA} segment
11065 (virtual) addresses beyond the stack segment.
11067 estimate for this is from address 6000000 (hexadecimal) onwards---this
11068 has always worked for me [Toon Moene]:
11071 % @kbd{g77 -segaddr __DATA 6000000 test.f}
11072 % @kbd{ebadexec a.out}
11073 ebadexec: file: a.out appears to be executable
11077 Browsing through @file{@value{path-g77}/Makefile.in},
11078 you will find that the @code{f771} program itself also has to be
11079 linked with these flags---it has large statically allocated
11081 (Version 0.5.18 reduces this somewhat, but probably
11084 (The above item was contributed by Toon Moene
11085 (@email{toon@@moene.indiv.nluug.nl}).)
11087 @node Stack Overflow
11088 @subsection Stack Overflow
11089 @cindex stack, overflow
11090 @cindex segmentation violation
11091 @code{g77} code might fail at runtime (probably with a ``segmentation
11092 violation'') due to overflowing the stack.
11093 This happens most often on systems with an environment
11094 that provides substantially more heap space (for use
11095 when arbitrarily allocating and freeing memory) than stack
11098 Often this can be cured by
11099 increasing or removing your shell's limit on stack usage, typically
11100 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
11101 @kbd{ulimit -s} (in @code{sh} and derivatives).
11103 Increasing the allowed stack size might, however, require
11104 changing some operating system or system configuration parameters.
11106 You might be able to work around the problem by compiling with the
11107 @samp{-fno-automatic} option to reduce stack usage, probably at the
11110 @xref{Maximum Stackable Size}, for information on patching
11111 @code{g77} to use different criteria for placing local
11112 non-automatic variables and arrays on the stack.
11114 @cindex automatic arrays
11115 @cindex arrays, automatic
11116 However, if your program uses large automatic arrays
11117 (for example, has declarations like @samp{REAL A(N)} where
11118 @samp{A} is a local array and @samp{N} is a dummy or
11119 @code{COMMON} variable that can have a large value),
11120 neither use of @samp{-fno-automatic},
11121 nor changing the cut-off point for @code{g77} for using the stack,
11122 will solve the problem by changing the placement of these
11123 large arrays, as they are @emph{necessarily} automatic.
11125 @code{g77} currently provides no means to specify that
11126 automatic arrays are to be allocated on the heap instead
11128 So, other than increasing the stack size, your best bet is to
11129 change your source code to avoid large automatic arrays.
11130 Methods for doing this currently are outside the scope of
11133 (@emph{Note:} If your system puts stack and heap space in the
11134 same memory area, such that they are effectively combined, then
11135 a stack overflow probably indicates a program that is either
11136 simply too large for the system, or buggy.)
11138 @node Nothing Happens
11139 @subsection Nothing Happens
11140 @cindex nothing happens
11141 @cindex naming programs
11142 @cindex @code{test} programs
11143 @cindex programs, @code{test}
11144 It is occasionally reported that a ``simple'' program,
11145 such as a ``Hello, World!'' program, does nothing when
11146 it is run, even though the compiler reported no errors,
11147 despite the program containing nothing other than a
11148 simple @code{PRINT} statement.
11150 This most often happens because the program has been
11151 compiled and linked on a UNIX system and named @code{test},
11152 though other names can lead to similarly unexpected
11153 run-time behavior on various systems.
11155 Essentially this problem boils down to giving
11156 your program a name that is already known to
11157 the shell you are using to identify some other program,
11158 which the shell continues to execute instead of your
11159 program when you invoke it via, for example:
11166 Under UNIX and many other system, a simple command name
11167 invokes a searching mechanism that might well not choose
11168 the program located in the current working directory if
11169 there is another alternative (such as the @code{test}
11170 command commonly installed on UNIX systems).
11172 The reliable way to invoke a program you just linked in
11173 the current directory under UNIX is to specify it using
11174 an explicit pathname, as in:
11182 Users who encounter this problem should take the time to
11183 read up on how their shell searches for commands, how to
11184 set their search path, and so on.
11185 The relevant UNIX commands to learn about include
11186 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
11187 @code{set} and @code{env}), @code{which}, and @code{find}.
11189 @node Strange Behavior at Run Time
11190 @subsection Strange Behavior at Run Time
11191 @cindex segmentation violation
11193 @cindex overwritten data
11194 @cindex data, overwritten
11195 @code{g77} code might fail at runtime with ``segmentation violation'',
11196 ``bus error'', or even something as subtle as a procedure call
11197 overwriting a variable or array element that it is not supposed
11200 These can be symptoms of a wide variety of actual bugs that
11201 occurred earlier during the program's run, but manifested
11202 themselves as @emph{visible} problems some time later.
11204 Overflowing the bounds of an array---usually by writing beyond
11205 the end of it---is one of two kinds of bug that often occurs
11207 (Compile your code with the @samp{-fbounds-check} option
11208 to catch many of these kinds of errors at program run time.)
11210 The other kind of bug is a mismatch between the actual arguments
11211 passed to a procedure and the dummy arguments as declared by that
11214 Both of these kinds of bugs, and some others as well, can be
11215 difficult to track down, because the bug can change its behavior,
11216 or even appear to not occur, when using a debugger.
11218 That is, these bugs can be quite sensitive to data, including
11219 data representing the placement of other data in memory (that is,
11220 pointers, such as the placement of stack frames in memory).
11222 @code{g77} now offers the
11223 ability to catch and report some of these problems at compile, link, or
11224 run time, such as by generating code to detect references to
11225 beyond the bounds of most arrays (except assumed-size arrays),
11226 and checking for agreement between calling and called procedures.
11227 Future improvements are likely to be made in the procedure-mismatch area,
11230 In the meantime, finding and fixing the programming
11231 bugs that lead to these behaviors is, ultimately, the user's
11232 responsibility, as difficult as that task can sometimes be.
11234 @cindex infinite spaces printed
11235 @cindex space, endless printing of
11236 @cindex libc, non-ANSI or non-default
11238 @cindex linking against non-standard library
11240 One runtime problem that has been observed might have a simple solution.
11241 If a formatted @code{WRITE} produces an endless stream of spaces, check
11242 that your program is linked against the correct version of the C library.
11243 The configuration process takes care to account for your
11244 system's normal @file{libc} not being ANSI-standard, which will
11245 otherwise cause this behaviour.
11246 If your system's default library is
11247 ANSI-standard and you subsequently link against a non-ANSI one, there
11248 might be problems such as this one.
11250 Specifically, on Solaris2 systems,
11251 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
11253 @node Floating-point Errors
11254 @subsection Floating-point Errors
11255 @cindex floating-point errors
11256 @cindex rounding errors
11257 @cindex inconsistent floating-point results
11258 @cindex results, inconsistent
11259 Some programs appear to produce inconsistent floating-point
11260 results compiled by @code{g77} versus by other compilers.
11262 Often the reason for this behavior is the fact that floating-point
11263 values are represented on almost all Fortran systems by
11264 @emph{approximations}, and these approximations are inexact
11265 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
11266 0.7, 0.8, 0.9, 1.1, and so on.
11267 Most Fortran systems, including all current ports of @code{g77},
11268 use binary arithmetic to represent these approximations.
11270 Therefore, the exact value of any floating-point approximation
11271 as manipulated by @code{g77}-compiled code is representable by
11272 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11273 so on (just keep dividing by two) through the precision of the
11274 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11275 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11276 power of two (in Fortran, by @samp{2**N}) that typically is between
11277 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11278 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11281 So, a value like 0.2 is exactly represented in decimal---since
11282 it is a fraction, @samp{2/10}, with a denominator that is compatible
11283 with the base of the number system (base 10).
11284 However, @samp{2/10} cannot be represented by any finite number
11285 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11286 be exactly represented in binary notation.
11288 (On the other hand, decimal notation can represent any binary
11289 number in a finite number of digits.
11290 Decimal notation cannot do so with ternary, or base-3,
11291 notation, which would represent floating-point numbers as
11292 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11293 After all, no finite number of decimal digits can exactly
11294 represent @samp{1/3}.
11295 Fortunately, few systems use ternary notation.)
11297 Moreover, differences in the way run-time I/O libraries convert
11298 between these approximations and the decimal representation often
11299 used by programmers and the programs they write can result in
11300 apparent differences between results that do not actually exist,
11301 or exist to such a small degree that they usually are not worth
11304 For example, consider the following program:
11311 When compiled by @code{g77}, the above program might output
11312 @samp{0.20000003}, while another compiler might produce a
11313 executable that outputs @samp{0.2}.
11315 This particular difference is due to the fact that, currently,
11316 conversion of floating-point values by the @code{libg2c} library,
11317 used by @code{g77}, handles only double-precision values.
11319 Since @samp{0.2} in the program is a single-precision value, it
11320 is converted to double precision (still in binary notation)
11321 before being converted back to decimal.
11322 The conversion to binary appends @emph{binary} zero digits to the
11323 original value---which, again, is an inexact approximation of
11324 0.2---resulting in an approximation that is much less exact
11325 than is connoted by the use of double precision.
11327 (The appending of binary zero digits has essentially the same
11328 effect as taking a particular decimal approximation of
11329 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11330 zeros to it, producing @samp{0.33333330000000000}.
11331 Treating the resulting decimal approximation as if it really
11332 had 18 or so digits of valid precision would make it seem
11333 a very poor approximation of @samp{1/3}.)
11335 As a result of converting the single-precision approximation
11336 to double precision by appending binary zeros, the conversion
11337 of the resulting double-precision
11338 value to decimal produces what looks like an incorrect
11339 result, when in fact the result is @emph{inexact}, and
11340 is probably no less inaccurate or imprecise an approximation
11341 of 0.2 than is produced by other compilers that happen to output
11342 the converted value as ``exactly'' @samp{0.2}.
11343 (Some compilers behave in a way that can make them appear
11344 to retain more accuracy across a conversion of a single-precision
11345 constant to double precision.
11346 @xref{Context-Sensitive Constants}, to see why
11347 this practice is illusory and even dangerous.)
11349 Note that a more exact approximation of the constant is
11350 computed when the program is changed to specify a
11351 double-precision constant:
11358 Future versions of @code{g77} and/or @code{libg2c} might convert
11359 single-precision values directly to decimal,
11360 instead of converting them to double precision first.
11361 This would tend to result in output that is more consistent
11362 with that produced by some other Fortran implementations.
11364 A useful source of information on floating-point computation is David
11365 Goldberg, `What Every Computer Scientist Should Know About
11366 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
11368 An online version is available at
11369 @uref{http://docs.sun.com/},
11370 and there is a supplemented version, in PostScript form, at
11371 @uref{http://www.validgh.com/goldberg/paper.ps}.
11373 Information related to the IEEE 754
11374 floating-point standard by a leading light can be found at
11375 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
11376 see also slides from the short course referenced from
11377 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
11378 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
11379 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
11380 and library code for GNU/Linux x86 systems.
11382 The supplement to the PostScript-formatted Goldberg document,
11383 referenced above, is available in HTML format.
11384 See `Differences Among IEEE 754 Implementations' by Doug Priest,
11385 available online at
11386 @uref{http://www.validgh.com/goldberg/addendum.html}.
11387 This document explores some of the issues surrounding computing
11388 of extended (80-bit) results on processors such as the x86,
11389 especially when those results are arbitrarily truncated
11390 to 32-bit or 64-bit values by the compiler
11393 @cindex spills of floating-point results
11394 @cindex 80-bit spills
11395 @cindex truncation, of floating-point values
11396 (@emph{Note:} @code{g77} specifically, and @code{gcc} generally,
11397 does arbitrarily truncate 80-bit results during spills
11398 as of this writing.
11399 It is not yet clear whether a future version of
11400 the GNU compiler suite will offer 80-bit spills
11401 as an option, or perhaps even as the default behavior.)
11403 @c xref would be different between editions:
11404 The GNU C library provides routines for controlling the FPU, and other
11405 documentation about this.
11407 @xref{Floating-point precision}, regarding IEEE 754 conformance.
11411 @node Missing Features
11412 @section Missing Features
11414 This section lists features we know are missing from @code{g77},
11415 and which we want to add someday.
11416 (There is no priority implied in the ordering below.)
11419 GNU Fortran language:
11420 * Better Source Model::
11421 * Fortran 90 Support::
11422 * Intrinsics in PARAMETER Statements::
11423 * Arbitrary Concatenation::
11424 * SELECT CASE on CHARACTER Type::
11425 * RECURSIVE Keyword::
11426 * Popular Non-standard Types::
11427 * Full Support for Compiler Types::
11428 * Array Bounds Expressions::
11429 * POINTER Statements::
11430 * Sensible Non-standard Constructs::
11431 * READONLY Keyword::
11432 * FLUSH Statement::
11433 * Expressions in FORMAT Statements::
11434 * Explicit Assembler Code::
11435 * Q Edit Descriptor::
11437 GNU Fortran dialects:
11438 * Old-style PARAMETER Statements::
11439 * TYPE and ACCEPT I/O Statements::
11440 * STRUCTURE UNION RECORD MAP::
11441 * OPEN CLOSE and INQUIRE Keywords::
11442 * ENCODE and DECODE::
11443 * AUTOMATIC Statement::
11444 * Suppressing Space Padding::
11445 * Fortran Preprocessor::
11446 * Bit Operations on Floating-point Data::
11447 * Really Ugly Character Assignments::
11451 * Floating-point Exception Handling::
11452 * Nonportable Conversions::
11453 * Large Automatic Arrays::
11454 * Support for Threads::
11455 * Increasing Precision/Range::
11456 * Enabling Debug Lines::
11458 Better diagnostics:
11459 * Better Warnings::
11460 * Gracefully Handle Sensible Bad Code::
11461 * Non-standard Conversions::
11462 * Non-standard Intrinsics::
11463 * Modifying DO Variable::
11464 * Better Pedantic Compilation::
11465 * Warn About Implicit Conversions::
11466 * Invalid Use of Hollerith Constant::
11467 * Dummy Array Without Dimensioning Dummy::
11468 * Invalid FORMAT Specifiers::
11469 * Ambiguous Dialects::
11471 * Informational Messages::
11473 Run-time facilities:
11474 * Uninitialized Variables at Run Time::
11475 * Portable Unformatted Files::
11476 * Better List-directed I/O::
11477 * Default to Console I/O::
11480 * Labels Visible to Debugger::
11483 @node Better Source Model
11484 @subsection Better Source Model
11486 @code{g77} needs to provide, as the default source-line model,
11487 a ``pure visual'' mode, where
11488 the interpretation of a source program in this mode can be accurately
11489 determined by a user looking at a traditionally displayed rendition
11490 of the program (assuming the user knows whether the program is fixed
11493 The design should assume the user cannot tell tabs from spaces
11494 and cannot see trailing spaces on lines, but has canonical tab stops
11495 and, for fixed-form source, has the ability to always know exactly
11496 where column 72 is (since the Fortran standard itself requires
11497 this for fixed-form source).
11499 This would change the default treatment of fixed-form source
11500 to not treat lines with tabs as if they were infinitely long---instead,
11501 they would end at column 72 just as if the tabs were replaced
11502 by spaces in the canonical way.
11504 As part of this, provide common alternate models (Digital, @code{f2c},
11505 and so on) via command-line options.
11506 This includes allowing arbitrarily long
11507 lines for free-form source as well as fixed-form source and providing
11508 various limits and diagnostics as appropriate.
11510 @cindex sequence numbers
11511 @cindex columns 73 through 80
11512 Also, @code{g77} should offer, perhaps even default to, warnings
11513 when characters beyond the last valid column are anything other
11515 This would mean code with ``sequence numbers'' in columns 73 through 80
11516 would be rejected, and there's a lot of that kind of code around,
11517 but one of the most frequent bugs encountered by new users is
11518 accidentally writing fixed-form source code into and beyond
11520 So, maybe the users of old code would be able to more easily handle
11521 having to specify, say, a @samp{-Wno-col73to80} option.
11523 @node Fortran 90 Support
11524 @subsection Fortran 90 Support
11525 @cindex Fortran 90, support
11526 @cindex support, Fortran 90
11528 @code{g77} does not support many of the features that
11529 distinguish Fortran 90 (and, now, Fortran 95) from
11532 Some Fortran 90 features are supported, because they
11533 make sense to offer even to die-hard users of F77.
11534 For example, many of them codify various ways F77 has
11535 been extended to meet users' needs during its tenure,
11536 so @code{g77} might as well offer them as the primary
11537 way to meet those same needs, even if it offers compatibility
11538 with one or more of the ways those needs were met
11539 by other F77 compilers in the industry.
11541 Still, many important F90 features are not supported,
11542 because no attempt has been made to research each and
11543 every feature and assess its viability in @code{g77}.
11544 In the meantime, users who need those features must
11545 use Fortran 90 compilers anyway, and the best approach
11546 to adding some F90 features to GNU Fortran might well be
11547 to fund a comprehensive project to create GNU Fortran 95.
11549 @node Intrinsics in PARAMETER Statements
11550 @subsection Intrinsics in @code{PARAMETER} Statements
11551 @cindex PARAMETER statement
11552 @cindex statements, PARAMETER
11554 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11555 This feature is considered to be absolutely vital, even though it
11556 is not standard-conforming, and is scheduled for version 0.6.
11558 Related to this, @code{g77} doesn't allow non-integral
11559 exponentiation in @code{PARAMETER} statements, such as
11560 @samp{PARAMETER (R=2**.25)}.
11561 It is unlikely @code{g77} will ever support this feature,
11562 as doing it properly requires complete emulation of
11563 a target computer's floating-point facilities when
11564 building @code{g77} as a cross-compiler.
11565 But, if the @code{gcc} back end is enhanced to provide
11566 such a facility, @code{g77} will likely use that facility
11567 in implementing this feature soon afterwards.
11569 @node Arbitrary Concatenation
11570 @subsection Arbitrary Concatenation
11571 @cindex concatenation
11572 @cindex CHARACTER*(*)
11573 @cindex run-time, dynamic allocation
11575 @code{g77} doesn't support arbitrary operands for concatenation
11576 in contexts where run-time allocation is required.
11582 CALL FOO(A // 'suffix')
11585 @node SELECT CASE on CHARACTER Type
11586 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11588 Character-type selector/cases for @code{SELECT CASE} currently
11591 @node RECURSIVE Keyword
11592 @subsection @code{RECURSIVE} Keyword
11593 @cindex RECURSIVE keyword
11594 @cindex keywords, RECURSIVE
11595 @cindex recursion, lack of
11596 @cindex lack of recursion
11598 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11600 Nor does it provide any means for compiling procedures
11601 designed to do recursion.
11603 All recursive code can be rewritten to not use recursion,
11604 but the result is not pretty.
11606 @node Increasing Precision/Range
11607 @subsection Increasing Precision/Range
11609 @cindex -qrealsize=8
11612 @cindex increasing precision
11613 @cindex precision, increasing
11614 @cindex increasing range
11615 @cindex range, increasing
11619 Some compilers, such as @code{f2c}, have an option (@samp{-r8},
11620 @samp{-qrealsize=8} or
11621 similar) that provides automatic treatment of @code{REAL}
11622 entities such that they have twice the storage size, and
11623 a corresponding increase in the range and precision, of what
11624 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11625 (This affects @code{COMPLEX} the same way.)
11627 They also typically offer another option (@samp{-i8}) to increase
11628 @code{INTEGER} entities so they are twice as large
11629 (with roughly twice as much range).
11631 (There are potential pitfalls in using these options.)
11633 @code{g77} does not yet offer any option that performs these
11634 kinds of transformations.
11635 Part of the problem is the lack of detailed specifications regarding
11636 exactly how these options affect the interpretation of constants,
11637 intrinsics, and so on.
11639 Until @code{g77} addresses this need, programmers could improve
11640 the portability of their code by modifying it to not require
11641 compile-time options to produce correct results.
11642 Some free tools are available which may help, specifically
11643 in Toolpack (which one would expect to be sound) and the @file{fortran}
11644 section of the Netlib repository.
11646 Use of preprocessors can provide a fairly portable means
11647 to work around the lack of widely portable methods in the Fortran
11648 language itself (though increasing acceptance of Fortran 90 would
11649 alleviate this problem).
11651 @node Popular Non-standard Types
11652 @subsection Popular Non-standard Types
11653 @cindex @code{INTEGER*2} support
11654 @cindex types, @code{INTEGER*2}
11655 @cindex @code{LOGICAL*1} support
11656 @cindex types, @code{LOGICAL*1}
11658 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11660 Version 0.6 will provide full support for this very
11661 popular set of features.
11662 In the meantime, version 0.5.18 provides rudimentary support
11665 @node Full Support for Compiler Types
11666 @subsection Full Support for Compiler Types
11668 @cindex @code{REAL*16} support
11669 @cindex types, @code{REAL*16}
11670 @cindex @code{INTEGER*8} support
11671 @cindex types, @code{INTEGER*8}
11672 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11673 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11674 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11675 This means providing intrinsic support, and maybe constant
11676 support (using F90 syntax) as well, and, for most
11677 machines will result in automatic support of @code{INTEGER*1},
11678 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11680 This is scheduled for version 0.6.
11682 @node Array Bounds Expressions
11683 @subsection Array Bounds Expressions
11684 @cindex array elements, in adjustable array bounds
11685 @cindex function references, in adjustable array bounds
11686 @cindex array bounds, adjustable
11687 @cindex @code{DIMENSION} statement
11688 @cindex statements, @code{DIMENSION}
11690 @code{g77} doesn't support more general expressions to dimension
11691 arrays, such as array element references, function
11694 For example, @code{g77} currently does not accept the following:
11698 INTEGER N(10), M(N(2), N(1))
11701 @node POINTER Statements
11702 @subsection POINTER Statements
11703 @cindex POINTER statement
11704 @cindex statements, POINTER
11705 @cindex Cray pointers
11707 @code{g77} doesn't support pointers or allocatable objects
11708 (other than automatic arrays).
11709 This set of features is
11710 probably considered just behind intrinsics
11711 in @code{PARAMETER} statements on the list of large,
11712 important things to add to @code{g77}.
11714 In the meantime, consider using the @code{INTEGER(KIND=7)}
11715 declaration to specify that a variable must be
11716 able to hold a pointer.
11717 This construct is not portable to other non-GNU compilers,
11718 but it is portable to all machines GNU Fortran supports
11719 when @code{g77} is used.
11721 @xref{Functions and Subroutines}, for information on
11722 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11723 constructs, which are useful for passing pointers to
11724 procedures written in languages other than Fortran.
11726 @node Sensible Non-standard Constructs
11727 @subsection Sensible Non-standard Constructs
11729 @code{g77} rejects things other compilers accept,
11730 like @samp{INTRINSIC SQRT,SQRT}.
11731 As time permits in the future, some of these things that are easy for
11732 humans to read and write and unlikely to be intended to mean something
11733 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11734 trigger warnings about such non-standard constructs).
11736 Until @code{g77} no longer gratuitously rejects sensible code,
11737 you might as well fix your code
11738 to be more standard-conforming and portable.
11740 The kind of case that is important to except from the
11741 recommendation to change your code is one where following
11742 good coding rules would force you to write non-standard
11743 code that nevertheless has a clear meaning.
11745 For example, when writing an @code{INCLUDE} file that
11746 defines a common block, it might be appropriate to
11747 include a @code{SAVE} statement for the common block
11748 (such as @samp{SAVE /CBLOCK/}), so that variables
11749 defined in the common block retain their values even
11750 when all procedures declaring the common block become
11751 inactive (return to their callers).
11753 However, putting @code{SAVE} statements in an @code{INCLUDE}
11754 file would prevent otherwise standard-conforming code
11755 from also specifying the @code{SAVE} statement, by itself,
11756 to indicate that all local variables and arrays are to
11757 have the @code{SAVE} attribute.
11759 For this reason, @code{g77} already has been changed to
11760 allow this combination, because although the general
11761 problem of gratuitously rejecting unambiguous and
11762 ``safe'' constructs still exists in @code{g77}, this
11763 particular construct was deemed useful enough that
11764 it was worth fixing @code{g77} for just this case.
11766 So, while there is no need to change your code
11767 to avoid using this particular construct, there
11768 might be other, equally appropriate but non-standard
11769 constructs, that you shouldn't have to stop using
11770 just because @code{g77} (or any other compiler)
11771 gratuitously rejects it.
11773 Until the general problem is solved, if you have
11774 any such construct you believe is worthwhile
11775 using (e.g. not just an arbitrary, redundant
11776 specification of an attribute), please submit a
11777 bug report with an explanation, so we can consider
11778 fixing @code{g77} just for cases like yours.
11780 @node READONLY Keyword
11781 @subsection @code{READONLY} Keyword
11784 Support for @code{READONLY}, in @code{OPEN} statements,
11785 requires @code{libg2c} support,
11786 to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
11787 does not delete a file opened on a unit
11788 with the @code{READONLY} keyword,
11789 and perhaps to trigger a fatal diagnostic
11790 if a @code{WRITE} or @code{PRINT}
11791 to such a unit is attempted.
11793 @emph{Note:} It is not sufficient for @code{g77} and @code{libg2c}
11794 (its version of @code{libf2c})
11795 to assume that @code{READONLY} does not need some kind of explicit support
11797 due to UNIX systems not (generally) needing it.
11798 @code{g77} is not just a UNIX-based compiler!
11800 Further, mounting of non-UNIX filesystems on UNIX systems
11802 might require proper @code{READONLY} support.
11805 (Similar issues might be involved with supporting the @code{SHARED}
11808 @node FLUSH Statement
11809 @subsection @code{FLUSH} Statement
11811 @code{g77} could perhaps use a @code{FLUSH} statement that
11812 does what @samp{CALL FLUSH} does,
11813 but that supports @samp{*} as the unit designator (same unit as for
11814 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11817 @node Expressions in FORMAT Statements
11818 @subsection Expressions in @code{FORMAT} Statements
11819 @cindex FORMAT statement
11820 @cindex statements, FORMAT
11822 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11823 Supporting this requires a significant redesign or replacement
11826 However, @code{g77} does support
11827 this construct when the expression is constant
11828 (as of version 0.5.22).
11832 PARAMETER (IWIDTH = 12)
11833 10 FORMAT (I<IWIDTH>)
11836 Otherwise, at least for output (@code{PRINT} and
11837 @code{WRITE}), Fortran code making use of this feature can
11838 be rewritten to avoid it by constructing the @code{FORMAT}
11839 string in a @code{CHARACTER} variable or array, then
11840 using that variable or array in place of the @code{FORMAT}
11841 statement label to do the original @code{PRINT} or @code{WRITE}.
11843 Many uses of this feature on input can be rewritten this way
11844 as well, but not all can.
11845 For example, this can be rewritten:
11852 However, this cannot, in general, be rewritten, especially
11853 when @code{ERR=} and @code{END=} constructs are employed:
11860 @node Explicit Assembler Code
11861 @subsection Explicit Assembler Code
11863 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11864 code to specify explicit assembler code.
11866 @node Q Edit Descriptor
11867 @subsection Q Edit Descriptor
11868 @cindex FORMAT statement
11869 @cindex Q edit descriptor
11870 @cindex edit descriptor, Q
11872 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11873 (This is meant to get the number of characters remaining in an input record.)
11874 Supporting this requires a significant redesign or replacement
11877 A workaround might be using internal I/O or the stream-based intrinsics.
11878 @xref{FGetC Intrinsic (subroutine)}.
11880 @node Old-style PARAMETER Statements
11881 @subsection Old-style PARAMETER Statements
11882 @cindex PARAMETER statement
11883 @cindex statements, PARAMETER
11885 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11886 Supporting this obsolete form of
11887 the @code{PARAMETER} statement would not be particularly hard, as most of the
11888 parsing code is already in place and working.
11890 Until time/money is
11891 spent implementing it, you might as well fix your code to use the
11892 standard form, @samp{PARAMETER (I=1)} (possibly needing
11893 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11894 otherwise, in the obsolete form of @code{PARAMETER}, the
11895 type of the variable is set from the type of the constant being
11898 @node TYPE and ACCEPT I/O Statements
11899 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11900 @cindex TYPE statement
11901 @cindex statements, TYPE
11902 @cindex ACCEPT statement
11903 @cindex statements, ACCEPT
11905 @code{g77} doesn't support the I/O statements @code{TYPE} and
11907 These are common extensions that should be easy to support,
11908 but also are fairly easy to work around in user code.
11910 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11911 by @samp{PRINT fmt,list}.
11912 And, any @samp{ACCEPT fmt,list} statement can be
11913 replaced by @samp{READ fmt,list}.
11915 @node STRUCTURE UNION RECORD MAP
11916 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11917 @cindex STRUCTURE statement
11918 @cindex statements, STRUCTURE
11919 @cindex UNION statement
11920 @cindex statements, UNION
11921 @cindex RECORD statement
11922 @cindex statements, RECORD
11923 @cindex MAP statement
11924 @cindex statements, MAP
11926 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11928 This set of extensions is quite a bit
11929 lower on the list of large, important things to add to @code{g77}, partly
11930 because it requires a great deal of work either upgrading or
11931 replacing @code{libg2c}.
11933 @node OPEN CLOSE and INQUIRE Keywords
11934 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11935 @cindex disposition of files
11936 @cindex OPEN statement
11937 @cindex statements, OPEN
11938 @cindex CLOSE statement
11939 @cindex statements, CLOSE
11940 @cindex INQUIRE statement
11941 @cindex statements, INQUIRE
11943 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11944 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11945 These extensions are easy to add to @code{g77} itself, but
11946 require much more work on @code{libg2c}.
11948 @cindex FORM='PRINT'
11949 @cindex ANS carriage control
11950 @cindex carriage control
11953 @code{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
11954 translate the traditional `carriage control' characters in column 1 of
11955 output to use backspaces, carriage returns and the like. However
11956 programs exist to translate them in output files (or standard output).
11957 These are typically called either @code{fpr} or @code{asa}. You can get
11958 a version of @code{asa} from
11959 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
11960 systems which will probably build easily on other systems.
11961 Alternatively, @code{fpr} is in BSD distributions in various archive
11964 @c (Can both programs can be used in a pipeline,
11965 @c with a named input file,
11966 @c and/or with a named output file???)
11968 @node ENCODE and DECODE
11969 @subsection @code{ENCODE} and @code{DECODE}
11970 @cindex ENCODE statement
11971 @cindex statements, ENCODE
11972 @cindex DECODE statement
11973 @cindex statements, DECODE
11975 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11977 These statements are best replaced by READ and WRITE statements
11978 involving internal files (CHARACTER variables and arrays).
11980 For example, replace a code fragment like
11985 DECODE (80, 9000, LINE) A, B, C
11987 9000 FORMAT (1X, 3(F10.5))
11996 READ (UNIT=LINE, FMT=9000) A, B, C
11998 9000 FORMAT (1X, 3(F10.5))
12001 Similarly, replace a code fragment like
12006 ENCODE (80, 9000, LINE) A, B, C
12008 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
12017 WRITE (UNIT=LINE, FMT=9000) A, B, C
12019 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
12022 It is entirely possible that @code{ENCODE} and @code{DECODE} will
12023 be supported by a future version of @code{g77}.
12025 @node AUTOMATIC Statement
12026 @subsection @code{AUTOMATIC} Statement
12027 @cindex @code{AUTOMATIC} statement
12028 @cindex statements, @code{AUTOMATIC}
12029 @cindex automatic variables
12030 @cindex variables, automatic
12032 @code{g77} doesn't support the @code{AUTOMATIC} statement that
12035 @code{AUTOMATIC} would identify a variable or array
12036 as not being @code{SAVE}'d, which is normally the default,
12037 but which would be especially useful for code that, @emph{generally},
12038 needed to be compiled with the @samp{-fno-automatic} option.
12040 @code{AUTOMATIC} also would serve as a hint to the compiler that placing
12041 the variable or array---even a very large array--on the stack is acceptable.
12043 @code{AUTOMATIC} would not, by itself, designate the containing procedure
12046 @code{AUTOMATIC} should work syntactically like @code{SAVE},
12047 in that @code{AUTOMATIC} with no variables listed should apply to
12048 all pertinent variables and arrays
12049 (which would not include common blocks or their members).
12051 Variables and arrays denoted as @code{AUTOMATIC}
12052 would not be permitted to be initialized via @code{DATA}
12053 or other specification of any initial values,
12054 requiring explicit initialization,
12055 such as via assignment statements.
12059 Perhaps @code{UNSAVE} and @code{STATIC},
12060 as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
12061 should be provided as well.
12063 @node Suppressing Space Padding
12064 @subsection Suppressing Space Padding of Source Lines
12066 @code{g77} should offer VXT-Fortran-style suppression of virtual
12067 spaces at the end of a source line
12068 if an appropriate command-line option is specified.
12070 This affects cases where
12071 a character constant is continued onto the next line in a fixed-form
12072 source file, as in the following example:
12075 10 PRINT *,'HOW MANY
12080 @code{g77}, and many other compilers, virtually extend
12081 the continued line through column 72 with spaces that become part
12082 of the character constant, but Digital Fortran normally didn't,
12083 leaving only one space between @samp{MANY} and @samp{SPACES?}
12084 in the output of the above statement.
12086 Fairly recently, at least one version of Digital Fortran
12087 was enhanced to provide the other behavior when a
12088 command-line option is specified, apparently due to demand
12089 from readers of the USENET group @file{comp.lang.fortran}
12090 to offer conformance to this widespread practice in the
12092 @code{g77} should return the favor by offering conformance
12093 to Digital's approach to handling the above example.
12095 @node Fortran Preprocessor
12096 @subsection Fortran Preprocessor
12098 @code{g77} should offer a preprocessor designed specifically
12099 for Fortran to replace @samp{cpp -traditional}.
12100 There are several out there worth evaluating, at least.
12102 Such a preprocessor would recognize Hollerith constants,
12103 properly parse comments and character constants, and so on.
12104 It might also recognize, process, and thus preprocess
12105 files included via the @code{INCLUDE} directive.
12107 @node Bit Operations on Floating-point Data
12108 @subsection Bit Operations on Floating-point Data
12109 @cindex @code{And} intrinsic
12110 @cindex intrinsics, @code{And}
12111 @cindex @code{Or} intrinsic
12112 @cindex intrinsics, @code{Or}
12113 @cindex @code{Shift} intrinsic
12114 @cindex intrinsics, @code{Shift}
12116 @code{g77} does not allow @code{REAL} and other non-integral types for
12117 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
12119 For example, this program is rejected by @code{g77}, because
12120 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
12123 DATA A/7.54/, B/9.112/
12124 PRINT *, IAND(A, B)
12128 @node Really Ugly Character Assignments
12129 @subsection Really Ugly Character Assignments
12131 An option such as @samp{-fugly-char} should be provided
12136 DATA A1 / '12345678' /
12146 @node POSIX Standard
12147 @subsection @code{POSIX} Standard
12149 @code{g77} should support the POSIX standard for Fortran.
12151 @node Floating-point Exception Handling
12152 @subsection Floating-point Exception Handling
12153 @cindex floating-point, exceptions
12154 @cindex exceptions, floating-point
12155 @cindex FPE handling
12158 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
12159 general control over whether or not floating-point exceptions are trapped or
12161 (Ignoring them typically results in NaN values being
12162 propagated in systems that conform to IEEE 754.)
12163 The behaviour is normally inherited from the system-dependent startup
12164 code, though some targets, such as the Alpha, have code generation
12165 options which change the behaviour.
12167 Most systems provide some C-callable mechanism to change this; this can
12168 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
12169 For example, just compiling and linking the following C code with your
12170 program will turn on exception trapping for the ``common'' exceptions
12171 on a GNU system using glibc 2.2 or newer:
12174 #define _GNU_SOURCE 1
12176 static void __attribute__ ((constructor))
12179 /* Enable some exceptions. At startup all exceptions are masked. */
12181 feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
12185 A convenient trick is to compile this something like:
12187 gcc -o libtrapfpe.a trapfpe.c
12189 and then use it by adding @samp{-trapfpe} to the @code{g77} command line
12192 @node Nonportable Conversions
12193 @subsection Nonportable Conversions
12194 @cindex nonportable conversions
12195 @cindex conversions, nonportable
12197 @code{g77} doesn't accept some particularly nonportable,
12198 silent data-type conversions such as @code{LOGICAL}
12199 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
12200 is type @code{REAL}), that other compilers might
12203 Some of these conversions are accepted by @code{g77}
12204 when the @samp{-fugly-logint} option is specified.
12205 Perhaps it should accept more or all of them.
12207 @node Large Automatic Arrays
12208 @subsection Large Automatic Arrays
12209 @cindex automatic arrays
12210 @cindex arrays, automatic
12212 Currently, automatic arrays always are allocated on the stack.
12213 For situations where the stack cannot be made large enough,
12214 @code{g77} should offer a compiler option that specifies
12215 allocation of automatic arrays in heap storage.
12217 @node Support for Threads
12218 @subsection Support for Threads
12220 @cindex parallel processing
12222 Neither the code produced by @code{g77} nor the @code{libg2c} library
12223 are thread-safe, nor does @code{g77} have support for parallel processing
12224 (other than the instruction-level parallelism available on some
12226 A package such as PVM might help here.
12228 @node Enabling Debug Lines
12229 @subsection Enabling Debug Lines
12231 @cindex comment line, debug
12233 An option such as @samp{-fdebug-lines} should be provided
12234 to turn fixed-form lines beginning with @samp{D}
12235 to be treated as if they began with a space,
12236 instead of as if they began with a @samp{C}
12237 (as comment lines).
12239 @node Better Warnings
12240 @subsection Better Warnings
12242 Because of how @code{g77} generates code via the back end,
12243 it doesn't always provide warnings the user wants.
12252 Currently, the above is not flagged as a case of
12253 using an uninitialized variable,
12254 because @code{g77} generates a run-time library call that looks,
12255 to the GBE, like it might actually @emph{modify} @samp{A} at run time.
12256 (And, in fact, depending on the previous run-time library call,
12259 Fixing this requires one of the following:
12263 Switch to new library, @code{libg77}, that provides
12264 a more ``clean'' interface,
12265 vis-a-vis input, output, and modified arguments,
12266 so the GBE can tell what's going on.
12268 This would provide a pretty big performance improvement,
12269 at least theoretically, and, ultimately, in practice,
12270 for some types of code.
12273 Have @code{g77} pass a pointer to a temporary
12274 containing a copy of @samp{A},
12275 instead of to @samp{A} itself.
12276 The GBE would then complain about the copy operation
12277 involving a potentially uninitialized variable.
12279 This might also provide a performance boost for some code,
12280 because @samp{A} might then end up living in a register,
12281 which could help with inner loops.
12284 Have @code{g77} use a GBE construct similar to @code{ADDR_EXPR}
12285 but with extra information on the fact that the
12286 item pointed to won't be modified
12287 (a la @code{const} in C).
12289 Probably the best solution for now, but not quite trivial
12290 to implement in the general case.
12291 Worth considering after @code{g77} 0.6 is considered
12295 @node Gracefully Handle Sensible Bad Code
12296 @subsection Gracefully Handle Sensible Bad Code
12298 @code{g77} generally should continue processing for
12299 warnings and recoverable (user) errors whenever possible---that
12300 is, it shouldn't gratuitously make bad or useless code.
12311 When compiling the above with @samp{-ff2c-intrinsics-disable},
12312 @code{g77} should indeed complain about passing @code{ZABS},
12313 but it still should compile, instead of rejecting
12314 the entire @code{CALL} statement.
12315 (Some of this is related to improving
12316 the compiler internals to improve how statements are analyzed.)
12318 @node Non-standard Conversions
12319 @subsection Non-standard Conversions
12321 @samp{-Wconversion} and related should flag places where non-standard
12322 conversions are found.
12323 Perhaps much of this would be part of @samp{-Wugly*}.
12325 @node Non-standard Intrinsics
12326 @subsection Non-standard Intrinsics
12328 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
12329 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
12330 This would help find code that might fail silently when ported to another
12333 @node Modifying DO Variable
12334 @subsection Modifying @code{DO} Variable
12336 @code{g77} should warn about modifying @code{DO} variables
12337 via @code{EQUIVALENCE}.
12338 (The internal information gathered to produce this warning
12339 might also be useful in setting the
12340 internal ``doiter'' flag for a variable or even array
12341 reference within a loop, since that might produce faster code someday.)
12343 For example, this code is invalid, so @code{g77} should warn about
12344 the invalid assignment to @samp{NOTHER}:
12347 EQUIVALENCE (I, NOTHER)
12349 IF (I.EQ. 10) NOTHER = 20
12353 @node Better Pedantic Compilation
12354 @subsection Better Pedantic Compilation
12356 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
12357 and use it only to generate
12358 warnings instead of rejecting constructs outright.
12360 if a variable that dimensions an array is not a dummy or placed
12361 explicitly in @code{COMMON} (F77 does not allow it to be
12362 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
12363 follow statement-function-definition statements; about all sorts of
12364 syntactic extensions.
12366 @node Warn About Implicit Conversions
12367 @subsection Warn About Implicit Conversions
12369 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
12370 to expect automatic, silent, and
12371 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
12372 constants to @code{REAL(KIND=2)} based on context.
12374 For example, it would warn about cases like this:
12377 DOUBLE PRECISION FOO
12378 PARAMETER (TZPHI = 9.435784839284958)
12382 @node Invalid Use of Hollerith Constant
12383 @subsection Invalid Use of Hollerith Constant
12385 @code{g77} should disallow statements like @samp{RETURN 2HAB},
12386 which are invalid in both source forms
12387 (unlike @samp{RETURN (2HAB)},
12388 which probably still makes no sense but at least can
12389 be reliably parsed).
12390 Fixed-form processing rejects it, but not free-form, except
12391 in a way that is a bit difficult to understand.
12393 @node Dummy Array Without Dimensioning Dummy
12394 @subsection Dummy Array Without Dimensioning Dummy
12396 @code{g77} should complain when a list of dummy arguments containing an
12397 adjustable dummy array does
12398 not also contain every variable listed in the dimension list of the
12401 Currently, @code{g77} does complain about a variable that
12402 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
12403 area, but this needs to be extended to catch cases where it doesn't appear in
12404 every dummy list that also lists any arrays it dimensions.
12406 For example, @code{g77} should warn about the entry point @samp{ALT}
12407 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
12411 SUBROUTINE PRIMARY(ARRAY, ISIZE)
12416 @node Invalid FORMAT Specifiers
12417 @subsection Invalid FORMAT Specifiers
12419 @code{g77} should check @code{FORMAT} specifiers for validity
12420 as it does @code{FORMAT} statements.
12422 For example, a diagnostic would be produced for:
12425 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
12428 @node Ambiguous Dialects
12429 @subsection Ambiguous Dialects
12431 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
12432 @samp{-Wvxt}, @samp{-Wf90}, and so on.
12433 These would warn about places in the user's source where ambiguities
12434 are found, helpful in resolving ambiguities in the program's
12435 dialect or dialects.
12437 @node Unused Labels
12438 @subsection Unused Labels
12440 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
12442 @node Informational Messages
12443 @subsection Informational Messages
12445 @code{g77} needs an option to suppress information messages (notes).
12446 @samp{-w} does this but also suppresses warnings.
12447 The default should be to suppress info messages.
12449 Perhaps info messages should simply be eliminated.
12451 @node Uninitialized Variables at Run Time
12452 @subsection Uninitialized Variables at Run Time
12454 @code{g77} needs an option to initialize everything (not otherwise
12455 explicitly initialized) to ``weird''
12456 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
12457 largest-magnitude integers, would help track down references to
12458 some kinds of uninitialized variables at run time.
12460 Note that use of the options @samp{-O -Wuninitialized} can catch
12461 many such bugs at compile time.
12463 @node Portable Unformatted Files
12464 @subsection Portable Unformatted Files
12466 @cindex unformatted files
12467 @cindex file formats
12468 @cindex binary data
12469 @cindex byte ordering
12470 @code{g77} has no facility for exchanging unformatted files with systems
12471 using different number formats---even differing only in endianness (byte
12472 order)---or written by other compilers. Some compilers provide
12473 facilities at least for doing byte-swapping during unformatted I/O.
12475 It is unrealistic to expect to cope with exchanging unformatted files
12476 with arbitrary other compiler runtimes, but the @code{g77} runtime
12477 should at least be able to read files written by @code{g77} on systems
12478 with different number formats, particularly if they differ only in byte
12481 In case you do need to write a program to translate to or from
12482 @code{g77} (@code{libf2c}) unformatted files, they are written as
12486 Unformatted sequential records consist of
12489 A number giving the length of the record contents;
12491 the length of record contents again (for backspace).
12494 The record length is of C type
12495 @code{long}; this means that it is 8 bytes on 64-bit systems such as
12496 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
12497 Consequently such files cannot be exchanged between 64-bit and 32-bit
12498 systems, even with the same basic number format.
12499 @item Direct access
12500 Unformatted direct access files form a byte stream of length
12501 @var{records}*@var{recl} bytes, where @var{records} is the maximum
12502 record number (@code{REC=@var{records}}) written and @var{recl} is the
12503 record length in bytes specified in the @code{OPEN} statement
12504 (@code{RECL=@var{recl}}). Data appear in the records as determined by
12505 the relevant @code{WRITE} statement. Dummy records with arbitrary
12506 contents appear in the file in place of records which haven't been
12510 Thus for exchanging a sequential or direct access unformatted file
12511 between big- and little-endian 32-bit systems using IEEE 754 floating
12512 point it would be sufficient to reverse the bytes in consecutive words
12513 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
12514 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
12517 If necessary, it is possible to do byte-oriented i/o with @code{g77}'s
12518 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
12519 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
12520 array or a set of scalars.
12524 If you need to exchange binary data between arbitrary system and
12525 compiler variations, we recommend using a portable binary format with
12526 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
12527 or PACT's PDB@footnote{No, not @emph{that} one.}
12528 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
12529 say, CDF or XDR, HDF-like systems write in the native number formats and
12530 only incur overhead when they are read on a system with a different
12531 format.) A future @code{g77} runtime library should use such
12534 @node Better List-directed I/O
12535 @subsection Better List-directed I/O
12537 Values output using list-directed I/O
12538 (@samp{PRINT *, R, D})
12539 should be written with a field width, precision, and so on
12540 appropriate for the type (precision) of each value.
12542 (Currently, no distinction is made between single-precision
12543 and double-precision values
12546 It is likely this item will require the @code{libg77} project
12549 In the meantime, use of formatted I/O is recommended.
12550 While it might be of little consolation,
12551 @code{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
12552 as long as @samp{WIDTH} is defined as a named constant
12553 (via @code{PARAMETER}).
12554 That at least allows some compile-time specification
12555 of the precision of a data type,
12556 perhaps controlled by preprocessing directives.
12558 @node Default to Console I/O
12559 @subsection Default to Console I/O
12561 The default I/O units,
12562 specified by @samp{READ @var{fmt}},
12563 @samp{READ (UNIT=*)},
12564 @samp{WRITE (UNIT=*)}, and
12565 @samp{PRINT @var{fmt}},
12566 should not be units 5 (input) and 6 (output),
12567 but, rather, unit numbers not normally available
12568 for use in statements such as @code{OPEN} and @code{CLOSE}.
12570 Changing this would allow a program to connect units 5 and 6
12571 to files via @code{OPEN},
12572 but still use @samp{READ (UNIT=*)} and @samp{PRINT}
12573 to do I/O to the ``console''.
12575 This change probably requires the @code{libg77} project.
12577 @node Labels Visible to Debugger
12578 @subsection Labels Visible to Debugger
12580 @code{g77} should output debugging information for statements labels,
12581 for use by debuggers that know how to support them.
12582 Same with weirder things like construct names.
12583 It is not yet known if any debug formats or debuggers support these.
12585 @node Disappointments
12586 @section Disappointments and Misunderstandings
12588 These problems are perhaps regrettable, but we don't know any practical
12589 way around them for now.
12592 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
12593 external name @samp{foo_}.
12594 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
12595 and @samp{SUBROUTINE FOO}.
12596 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
12599 @node Mangling of Names
12600 @subsection Mangling of Names in Source Code
12601 @cindex naming issues
12602 @cindex external names
12603 @cindex common blocks
12607 The current external-interface design, which includes naming of
12608 external procedures, COMMON blocks, and the library interface,
12609 has various usability problems, including things like adding
12610 underscores where not really necessary (and preventing easier
12611 inter-language operability) and yet not providing complete
12612 namespace freedom for user C code linked with Fortran apps (due
12613 to the naming of functions in the library, among other things).
12615 Project GNU should at least get all this ``right'' for systems
12616 it fully controls, such as the Hurd, and provide defaults and
12617 options for compatibility with existing systems and interoperability
12618 with popular existing compilers.
12620 @node Multiple Definitions of External Names
12621 @subsection Multiple Definitions of External Names
12623 @cindex BLOCK DATA statement
12624 @cindex statements, BLOCK DATA
12625 @cindex @code{COMMON} statement
12626 @cindex statements, @code{COMMON}
12627 @cindex naming conflicts
12629 @code{g77} doesn't allow a common block and an external procedure or
12630 @code{BLOCK DATA} to have the same name.
12631 Some systems allow this, but @code{g77} does not,
12632 to be compatible with @code{f2c}.
12634 @code{g77} could special-case the way it handles
12635 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12636 particular area (necessarily, since @code{g77} offers an
12637 important feature here), but
12638 it is likely that such special-casing would be very annoying to people
12639 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12640 @samp{FOO} in the same program unit, to refer to external procedures, since
12641 the result would be that @code{g77} would treat these references as requests to
12642 force-load BLOCK DATA program units.
12644 In that case, if @code{g77} modified
12645 names of @code{BLOCK DATA} so they could have the same names as
12646 @code{COMMON}, users
12647 would find that their programs wouldn't link because the @samp{FOO} procedure
12648 didn't have its name translated the same way.
12650 (Strictly speaking,
12651 @code{g77} could emit a null-but-externally-satisfying definition of
12652 @samp{FOO} with its name transformed as if it had been a
12653 @code{BLOCK DATA}, but that probably invites more trouble than it's
12656 @node Limitation on Implicit Declarations
12657 @subsection Limitation on Implicit Declarations
12658 @cindex IMPLICIT CHARACTER*(*) statement
12659 @cindex statements, IMPLICIT CHARACTER*(*)
12661 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12662 This is not standard-conforming.
12665 @section Certain Changes We Don't Want to Make
12667 This section lists changes that people frequently request, but which
12668 we do not make because we think GNU Fortran is better without them.
12671 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12672 is one, not two, characters long.
12673 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12675 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12676 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12677 single-precision constant,
12678 and might be interpreted as
12679 @samp{9.435785} or similar.
12680 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12681 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12682 not behave as expected.
12685 @node Backslash in Constants
12686 @subsection Backslash in Constants
12688 @cindex @code{f77} support
12689 @cindex support, @code{f77}
12691 In the opinion of many experienced Fortran users,
12692 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12693 as currently set by @code{g77}.
12695 First of all, you can always specify
12696 @samp{-fno-backslash} to turn off this processing.
12698 Despite not being within the spirit (though apparently within the
12699 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12700 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12701 default to, and apparently lots of code depends on this feature.
12703 This is a particularly troubling issue.
12704 The use of a C construct in the midst of Fortran code
12705 is bad enough, worse when it makes existing Fortran
12706 programs stop working (as happens when programs written
12707 for non-UNIX systems are ported to UNIX systems with
12708 compilers that provide the @samp{-fbackslash} feature
12709 as the default---sometimes with no option to turn it off).
12711 The author of GNU Fortran wished, for reasons of linguistic
12712 purity, to make @samp{-fno-backslash} the default for GNU
12713 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12714 to specify @samp{-fbackslash} to get the UNIX behavior.
12716 However, the realization that @code{g77} is intended as
12717 a replacement for @emph{UNIX} @code{f77}, caused the author
12718 to choose to make @code{g77} as compatible with
12719 @code{f77} as feasible, which meant making @samp{-fbackslash}
12722 The primary focus on compatibility is at the source-code
12723 level, and the question became ``What will users expect
12724 a replacement for @code{f77} to do, by default?''
12725 Although at least one UNIX @code{f77} does not provide
12726 @samp{-fbackslash} as a default, it appears that
12727 the majority of them do, which suggests that
12728 the majority of code that is compiled by UNIX @code{f77}
12729 compilers expects @samp{-fbackslash} to be the default.
12731 It is probably the case that more code exists
12732 that would @emph{not} work with @samp{-fbackslash}
12733 in force than code that requires it be in force.
12735 However, most of @emph{that} code is not being compiled
12737 and when it is, new build procedures (shell scripts,
12738 makefiles, and so on) must be set up anyway so that
12739 they work under UNIX.
12740 That makes a much more natural and safe opportunity for
12741 non-UNIX users to adapt their build procedures for
12742 @code{g77}'s default of @samp{-fbackslash} than would
12743 exist for the majority of UNIX @code{f77} users who
12744 would have to modify existing, working build procedures
12745 to explicitly specify @samp{-fbackslash} if that was
12748 One suggestion has been to configure the default for
12749 @samp{-fbackslash} (and perhaps other options as well)
12750 based on the configuration of @code{g77}.
12752 This is technically quite straightforward, but will be avoided
12753 even in cases where not configuring defaults to be
12754 dependent on a particular configuration greatly inconveniences
12755 some users of legacy code.
12757 Many users appreciate the GNU compilers because they provide an
12758 environment that is uniform across machines.
12759 These users would be
12760 inconvenienced if the compiler treated things like the
12761 format of the source code differently on certain machines.
12763 Occasionally users write programs intended only for a particular machine
12765 On these occasions, the users would benefit if the GNU Fortran compiler
12766 were to support by default the same dialect as the other compilers on
12768 But such applications are rare.
12769 And users writing a
12770 program to run on more than one type of machine cannot possibly benefit
12771 from this kind of compatibility.
12772 (This is consistent with the design goals for @code{gcc}.
12773 To change them for @code{g77}, you must first change them
12775 Do not ask the maintainers of @code{g77} to do this for you,
12776 or to disassociate @code{g77} from the widely understood, if
12777 not widely agreed-upon, goals for GNU compilers in general.)
12779 This is why GNU Fortran does and will treat backslashes in the same
12780 fashion on all types of machines (by default).
12781 @xref{Direction of Language Development}, for more information on
12782 this overall philosophy guiding the development of the GNU Fortran
12785 Of course, users strongly concerned about portability should indicate
12786 explicitly in their build procedures which options are expected
12787 by their source code, or write source code that has as few such
12788 expectations as possible.
12790 For example, avoid writing code that depends on backslash (@samp{\})
12791 being interpreted either way in particular, such as by
12792 starting a program unit with:
12796 PARAMETER (BACKSL = '\\')
12800 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12802 In this way, users can write programs which have the same meaning
12803 in many Fortran dialects.
12805 (However, this technique does not work for Hollerith constants---which
12806 is just as well, since the only generally portable uses for Hollerith
12807 constants are in places where character constants can and should
12808 be used instead, for readability.)
12810 @node Initializing Before Specifying
12811 @subsection Initializing Before Specifying
12812 @cindex initialization, statement placement
12813 @cindex placing initialization statements
12815 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12816 source code before @samp{COMMON VAR},
12817 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12818 In general, @code{g77} requires initialization of a variable
12819 or array to be specified @emph{after} all other specifications
12820 of attributes (type, size, placement, and so on) of that variable
12821 or array are specified (though @emph{confirmation} of data type is
12824 It is @emph{possible} @code{g77} will someday allow all of this,
12825 even though it is not allowed by the FORTRAN 77 standard.
12827 Then again, maybe it is better to have
12828 @code{g77} always require placement of @code{DATA}
12829 so that it can possibly immediately write constants
12830 to the output file, thus saving time and space.
12832 That is, @samp{DATA A/1000000*1/} should perhaps always
12833 be immediately writable to canonical assembler, unless it's already known
12834 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12835 and to do this it cannot be followed by @samp{COMMON A}.
12837 @node Context-Sensitive Intrinsicness
12838 @subsection Context-Sensitive Intrinsicness
12839 @cindex intrinsics, context-sensitive
12840 @cindex context-sensitive intrinsics
12842 @code{g77} treats procedure references to @emph{possible} intrinsic
12843 names as always enabling their intrinsic nature, regardless of
12844 whether the @emph{form} of the reference is valid for that
12847 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12848 an invalid reference to the @code{SQRT} intrinsic function,
12849 because the reference is a subroutine invocation.
12851 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12852 as a reference to a @emph{procedure} named @samp{SQRT}, not
12853 to a @emph{variable} with that name (as it would for a statement
12854 such as @samp{V = SQRT}).
12856 Next, @code{g77} establishes that, in the program unit being compiled,
12857 @code{SQRT} is an intrinsic---not a subroutine that
12858 happens to have the same name as an intrinsic (as would be
12859 the case if, for example, @samp{EXTERNAL SQRT} was present).
12861 Finally, @code{g77} recognizes that the @emph{form} of the
12862 reference is invalid for that particular intrinsic.
12863 That is, it recognizes that it is invalid for an intrinsic
12864 @emph{function}, such as @code{SQRT}, to be invoked as
12865 a @emph{subroutine}.
12867 At that point, @code{g77} issues a diagnostic.
12869 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12870 references an external subroutine of their own, not an
12871 intrinsic function.
12873 However, @code{g77} knows about intrinsic
12874 subroutines, not just functions, and is able to support both having
12875 the same names, for example.
12877 As a result of this, @code{g77} rejects calls
12878 to intrinsics that are not subroutines, and function invocations
12879 of intrinsics that are not functions, just as it (and most compilers)
12880 rejects invocations of intrinsics with the wrong number (or types)
12883 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12884 a user-written subroutine named @samp{SQRT}.
12886 @node Context-Sensitive Constants
12887 @subsection Context-Sensitive Constants
12888 @cindex constants, context-sensitive
12889 @cindex context-sensitive constants
12891 @code{g77} does not use context to determine the types of
12892 constants or named constants (@code{PARAMETER}), except
12893 for (non-standard) typeless constants such as @samp{'123'O}.
12895 For example, consider the following statement:
12898 PRINT *, 9.435784839284958 * 2D0
12902 @code{g77} will interpret the (truncated) constant
12903 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12904 constant, because the suffix @code{D0} is not specified.
12906 As a result, the output of the above statement when
12907 compiled by @code{g77} will appear to have ``less precision''
12908 than when compiled by other compilers.
12910 In these and other cases, some compilers detect the
12911 fact that a single-precision constant is used in
12912 a double-precision context and therefore interpret the
12913 single-precision constant as if it was @emph{explicitly}
12914 specified as a double-precision constant.
12915 (This has the effect of appending @emph{decimal}, not
12916 @emph{binary}, zeros to the fractional part of the
12917 number---producing different computational results.)
12919 The reason this misfeature is dangerous is that a slight,
12920 apparently innocuous change to the source code can change
12921 the computational results.
12926 DOUBLE PRECISION FIVE
12927 PARAMETER (ALMOST = 5.000000000001)
12929 CLOSE = 5.000000000001
12930 PRINT *, 5.000000000001 - FIVE
12931 PRINT *, ALMOST - FIVE
12932 PRINT *, CLOSE - FIVE
12937 Running the above program should
12938 result in the same value being
12939 printed three times.
12940 With @code{g77} as the compiler,
12943 However, compiled by many other compilers,
12944 running the above program would print
12945 two or three distinct values, because
12946 in two or three of the statements, the
12947 constant @samp{5.000000000001}, which
12948 on most systems is exactly equal to @samp{5.}
12949 when interpreted as a single-precision constant,
12950 is instead interpreted as a double-precision
12951 constant, preserving the represented
12953 However, this ``clever'' promotion of
12954 type does not extend to variables or,
12955 in some compilers, to named constants.
12957 Since programmers often are encouraged to replace manifest
12958 constants or permanently-assigned variables with named
12959 constants (@code{PARAMETER} in Fortran), and might need
12960 to replace some constants with variables having the same
12961 values for pertinent portions of code,
12962 it is important that compilers treat code so modified in the
12963 same way so that the results of such programs are the same.
12964 @code{g77} helps in this regard by treating constants just
12965 the same as variables in terms of determining their types
12966 in a context-independent way.
12968 Still, there is a lot of existing Fortran code that has
12969 been written to depend on the way other compilers freely
12970 interpret constants' types based on context, so anything
12971 @code{g77} can do to help flag cases of this in such code
12972 could be very helpful.
12974 @node Equivalence Versus Equality
12975 @subsection Equivalence Versus Equality
12976 @cindex .EQV., with integer operands
12977 @cindex comparing logical expressions
12978 @cindex logical expressions, comparing
12980 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12981 is not supported, except via @samp{-fugly-logint}, which is not
12982 recommended except for legacy code (where the behavior expected
12983 by the @emph{code} is assumed).
12985 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12986 and @code{.NEQV.} instead, as these are permitted by the various
12989 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12990 to work if either of its operands is @code{LOGICAL}.
12992 The problem with supporting this ``feature'' is that there is
12993 unlikely to be consensus on how it works, as illustrated by the
12994 following sample program:
12998 DATA L,M,N /3*.FALSE./
12999 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
13003 The issue raised by the above sample program is: what is the
13004 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
13005 @code{LOGICAL} operands?
13007 Some programmers will argue that it is the same as the precedence
13008 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
13010 By this interpretation, the subexpression @samp{M.EQ.N} must be
13011 evaluated first in the above program, resulting in a program that,
13012 when run, does not execute the @code{PRINT} statement.
13014 Other programmers will argue that the precedence is the same as
13015 the precedence for @code{.EQV.}, which is restricted by the standards
13016 to @code{LOGICAL} operands.
13017 By this interpretation, the subexpression @samp{L.AND.M} must be
13018 evaluated first, resulting in a program that @emph{does} execute
13019 the @code{PRINT} statement.
13021 Assigning arbitrary semantic interpretations to syntactic expressions
13022 that might legitimately have more than one ``obvious'' interpretation
13023 is generally unwise.
13025 The creators of the various Fortran standards have done a good job
13026 in this case, requiring a distinct set of operators (which have their
13027 own distinct precedence) to compare @code{LOGICAL} operands.
13028 This requirement results in expression syntax with more certain
13029 precedence (without requiring substantial context), making it easier
13030 for programmers to read existing code.
13031 @code{g77} will avoid muddying up elements of the Fortran language
13032 that were well-designed in the first place.
13034 (Ask C programmers about the precedence of expressions such as
13035 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
13036 you, without knowing more context, whether the @samp{&} and @samp{-}
13037 operators are infix (binary) or unary!)
13039 Most dangerous of all is the fact that,
13040 even assuming consensus on its meaning,
13041 an expression like @samp{L.AND.M.EQ.N},
13042 if it is the result of a typographical error,
13043 doesn't @emph{look} like it has such a typo.
13044 Even experienced Fortran programmers would not likely notice that
13045 @samp{L.AND.M.EQV.N} was, in fact, intended.
13047 So, this is a prime example of a circumstance in which
13048 a quality compiler diagnoses the code,
13049 instead of leaving it up to someone debugging it
13050 to know to turn on special compiler options
13051 that might diagnose it.
13053 @node Order of Side Effects
13054 @subsection Order of Side Effects
13055 @cindex side effects, order of evaluation
13056 @cindex order of evaluation, side effects
13058 @code{g77} does not necessarily produce code that, when run, performs
13059 side effects (such as those performed by function invocations)
13060 in the same order as in some other compiler---or even in the same
13061 order as another version, port, or invocation (using different
13062 command-line options) of @code{g77}.
13064 It is never safe to depend on the order of evaluation of side effects.
13065 For example, an expression like this may very well behave differently
13066 from one compiler to another:
13069 J = IFUNC() - IFUNC()
13073 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
13075 Either invocation might happen first.
13076 If @samp{IFUNC} returns 5 the first time it is invoked, and
13077 returns 12 the second time, @samp{J} might end up with the
13078 value @samp{7}, or it might end up with @samp{-7}.
13080 Generally, in Fortran, procedures with side-effects intended to
13081 be visible to the caller are best designed as @emph{subroutines},
13083 Examples of such side-effects include:
13087 The generation of random numbers
13088 that are intended to influence return values.
13092 (other than internal I/O to local variables).
13095 Updating information in common blocks.
13098 An example of a side-effect that is not intended to be visible
13099 to the caller is a function that maintains a cache of recently
13100 calculated results, intended solely to speed repeated invocations
13101 of the function with identical arguments.
13102 Such a function can be safely used in expressions, because
13103 if the compiler optimizes away one or more calls to the
13104 function, operation of the program is unaffected (aside
13105 from being speeded up).
13107 @node Warnings and Errors
13108 @section Warning Messages and Error Messages
13110 @cindex error messages
13111 @cindex warnings vs errors
13112 @cindex messages, warning and error
13113 The GNU compiler can produce two kinds of diagnostics: errors and
13115 Each kind has a different purpose:
13119 @emph{Errors} report problems that make it impossible to compile your
13121 GNU Fortran reports errors with the source file name, line
13122 number, and column within the line where the problem is apparent.
13125 @emph{Warnings} report other unusual conditions in your code that
13126 @emph{might} indicate a problem, although compilation can (and does)
13128 Warning messages also report the source file name, line number,
13129 and column information,
13130 but include the text @samp{warning:} to distinguish them
13131 from error messages.
13134 Warnings might indicate danger points where you should check to make sure
13135 that your program really does what you intend; or the use of obsolete
13136 features; or the use of nonstandard features of GNU Fortran.
13137 Many warnings are issued only if you ask for them, with one of the
13138 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
13141 @emph{Note:} Currently, the text of the line and a pointer to the column
13142 is printed in most @code{g77} diagnostics.
13143 Probably, as of version 0.6, @code{g77} will
13144 no longer print the text of the source line, instead printing
13145 the column number following the file name and line number in
13146 a form that GNU Emacs recognizes.
13147 This change is expected to speed up and reduce the memory usage
13148 of the @code{g77} compiler.
13150 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
13152 @c GNU Fortran always tries to compile your program if possible; it never
13153 @c gratuitously rejects a program whose meaning is clear merely because
13154 @c (for instance) it fails to conform to a standard. In some cases,
13155 @c however, the Fortran standard specifies that certain extensions are
13156 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
13157 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
13158 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
13159 @c This does not mean that @emph{all} non-ANSI constructs get warnings
13162 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
13163 more detail on these and related command-line options.
13165 @node Open Questions
13166 @chapter Open Questions
13168 Please consider offering useful answers to these questions!
13172 @code{LOC()} and other intrinsics are probably somewhat misclassified.
13173 Is the a need for more precise classification of intrinsics, and if so,
13174 what are the appropriate groupings?
13175 Is there a need to individually
13176 enable/disable/delete/hide intrinsics from the command line?
13180 @chapter Reporting Bugs
13182 @cindex reporting bugs
13184 Your bug reports play an essential role in making GNU Fortran reliable.
13186 When you encounter a problem, the first thing to do is to see if it is
13189 If it isn't known, then you should report the problem.
13191 Reporting a bug might help you by bringing a solution to your problem, or
13193 (If it does not, look in the service directory; see
13195 In any case, the principal function of a bug report is
13196 to help the entire community by making the next version of GNU Fortran work
13198 Bug reports are your contribution to the maintenance of GNU Fortran.
13200 Since the maintainers are very overloaded, we cannot respond to every
13202 However, if the bug has not been fixed, we are likely to
13203 send you a patch and ask you to tell us whether it works.
13205 In order for a bug report to serve its purpose, you must include the
13206 information that makes for fixing the bug.
13209 * Criteria: Bug Criteria. Have you really found a bug?
13210 * Where: Bug Lists. Where to send your bug report.
13211 * Reporting: Bug Reporting. How to report a bug effectively.
13212 * Patches: Sending Patches. How to send a patch for GNU Fortran.
13215 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
13216 for information on problems we already know about.
13218 @xref{Service,,How To Get Help with GNU Fortran},
13219 for information on where to ask for help.
13222 @section Have You Found a Bug?
13223 @cindex bug criteria
13225 If you are not sure whether you have found a bug, here are some guidelines:
13228 @cindex fatal signal
13231 If the compiler gets a fatal signal, for any input whatever, that is a
13233 Reliable compilers never crash---they just remain obsolete.
13235 @cindex invalid assembly code
13236 @cindex assembly code, invalid
13238 If the compiler produces invalid assembly code, for any input whatever,
13239 @c (except an @code{asm} statement),
13240 that is a compiler bug, unless the
13241 compiler reports errors (not just warnings) which would ordinarily
13242 prevent the assembler from being run.
13244 @cindex undefined behavior
13245 @cindex undefined function value
13247 If the compiler produces valid assembly code that does not correctly
13248 execute the input source code, that is a compiler bug.
13250 However, you must double-check to make sure, because you might have run
13251 into an incompatibility between GNU Fortran and traditional Fortran.
13252 @c (@pxref{Incompatibilities}).
13253 These incompatibilities might be considered
13254 bugs, but they are inescapable consequences of valuable features.
13256 Or you might have a program whose behavior is undefined, which happened
13257 by chance to give the desired results with another Fortran compiler.
13258 It is best to check the relevant Fortran standard thoroughly if
13259 it is possible that the program indeed does something undefined.
13261 After you have localized the error to a single source line, it should
13262 be easy to check for these things.
13263 If your program is correct and well defined, you have found
13266 It might help if, in your submission, you identified the specific
13267 language in the relevant Fortran standard that specifies the
13268 desired behavior, if it isn't likely to be obvious and agreed-upon
13269 by all Fortran users.
13272 If the compiler produces an error message for valid input, that is a
13275 @cindex invalid input
13277 If the compiler does not produce an error message for invalid input,
13278 that is a compiler bug.
13279 However, you should note that your idea of
13280 ``invalid input'' might be someone else's idea
13281 of ``an extension'' or ``support for traditional practice''.
13284 If you are an experienced user of Fortran compilers, your suggestions
13285 for improvement of GNU Fortran are welcome in any case.
13288 Many, perhaps most, bug reports against @code{g77} turn out to
13289 be bugs in the user's code.
13290 While we find such bug reports educational, they sometimes take
13291 a considerable amount of time to track down or at least respond
13292 to---time we could be spending making @code{g77}, not some user's
13295 Some steps you can take to verify that the bug is not certainly
13296 in the code you're compiling with @code{g77}:
13300 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
13301 These options enable many useful warning; the @samp{-O} option
13302 enables flow analysis that enables the uninitialized-variable
13305 If you investigate the warnings and find evidence of possible bugs
13306 in your code, fix them first and retry @code{g77}.
13309 Compile your code using the @code{g77} options @samp{-finit-local-zero},
13310 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
13311 combinations thereof.
13313 If your code works with any of these combinations, that is not
13314 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
13315 by your code might simply be avoided, or have a different, more subtle
13316 effect, when different options are used---but it can be a
13317 strong indicator that your code is making unwarranted assumptions
13318 about the Fortran dialect and/or underlying machine it is
13319 being compiled and run on.
13321 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
13322 for information on the @samp{-fno-automatic} and
13323 @samp{-finit-local-zero} options and how to convert
13324 their use into selective changes in your own code.
13328 Validate your code with @code{ftnchek} or a similar code-checking
13330 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
13331 or @uref{ftp://ftp.dsm.fordham.edu}.
13334 @cindex Makefile example
13335 Here are some sample @file{Makefile} rules using @code{ftnchek}
13336 ``project'' files to do cross-file checking and @code{sfmakedepend}
13337 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
13338 to maintain dependencies automatically.
13339 These assume the use of GNU @code{make}.
13342 # Dummy suffix for ftnchek targets:
13346 # How to compile .f files (for implicit rule):
13348 # Assume `include' directory:
13349 FFLAGS = -Iinclude -g -O -Wall
13351 # Flags for ftnchek:
13352 CHEK1 = -array=0 -include=includes -noarray
13353 CHEK2 = -nonovice -usage=1 -notruncation
13354 CHEKFLAGS = $(CHEK1) $(CHEK2)
13356 # Run ftnchek with all the .prj files except the one corresponding
13357 # to the target's root:
13359 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
13360 -noextern -library $<
13362 # Derive a project file from a source file:
13364 ftnchek $(CHEKFLAGS) -noextern -project -library $<
13366 # The list of objects is assumed to be in variable OBJS.
13367 # Sources corresponding to the objects:
13368 SRCS = $(OBJS:%.o=%.f)
13369 # ftnchek project files:
13370 PRJS = $(OBJS:%.o=%.prj)
13372 # Build the program
13374 $(FC) -o $@ $(OBJS)
13376 chekall: $(PRJS) ; \
13377 ftnchek $(CHEKFLAGS) $(PRJS)
13381 # For Emacs M-x find-tag:
13385 # Rebuild dependencies:
13387 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
13391 Try your code out using other Fortran compilers, such as @code{f2c}.
13392 If it does not work on at least one other compiler (assuming the
13393 compiler supports the features the code needs), that is a strong
13394 indicator of a bug in the code.
13396 However, even if your code works on many compilers @emph{except}
13397 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
13398 It might mean the bug is in your code, and that @code{g77} simply
13399 exposes it more readily than other compilers.
13403 @section Where to Report Bugs
13404 @cindex bug report mailing lists
13405 @kindex @value{email-bugs}
13406 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
13408 Often people think of posting bug reports to a newsgroup instead of
13410 This sometimes appears to work, but it has one problem which can be
13411 crucial: a newsgroup posting does not contain a mail path back to the
13413 Thus, if maintainers need more information, they might be unable
13414 to reach you. For this reason, you should always send bug reports by
13415 mail to the proper mailing list.
13417 As a last resort, send bug reports on paper to:
13421 Free Software Foundation
13422 59 Temple Place - Suite 330
13423 Boston, MA 02111-1307, USA
13426 @node Bug Reporting
13427 @section How to Report Bugs
13428 @cindex compiler bugs, reporting
13430 The fundamental principle of reporting bugs usefully is this:
13431 @strong{report all the facts}.
13432 If you are not sure whether to state a
13433 fact or leave it out, state it!
13435 Often people omit facts because they think they know what causes the
13436 problem and they conclude that some details don't matter.
13438 assume that the name of the variable you use in an example does not matter.
13439 Well, probably it doesn't, but one cannot be sure.
13440 Perhaps the bug is a
13441 stray memory reference which happens to fetch from the location where that
13442 name is stored in memory; perhaps, if the name were different, the contents
13443 of that location would fool the compiler into doing the right thing despite
13445 Play it safe and give a specific, complete example.
13447 easiest thing for you to do, and the most helpful.
13449 Keep in mind that the purpose of a bug report is to enable someone to
13450 fix the bug if it is not known.
13451 It isn't very important what happens if
13452 the bug is already known.
13453 Therefore, always write your bug reports on
13454 the assumption that the bug is not known.
13456 Sometimes people give a few sketchy facts and ask, ``Does this ring a
13458 This cannot help us fix a bug, so it is rarely helpful.
13459 We respond by asking for enough details to enable us to investigate.
13460 You might as well expedite matters by sending them to begin with.
13461 (Besides, there are enough bells ringing around here as it is.)
13463 Try to make your bug report self-contained.
13464 If we have to ask you for
13465 more information, it is best if you include all the previous information
13466 in your response, as well as the information that was missing.
13468 Please report each bug in a separate message.
13469 This makes it easier for
13470 us to track which bugs have been fixed and to forward your bugs reports
13471 to the appropriate maintainer.
13473 Do not compress and encode any part of your bug report using programs
13474 such as @file{uuencode}.
13475 If you do so it will slow down the processing
13477 If you must submit multiple large files, use @file{shar},
13478 which allows us to read your message without having to run any
13479 decompression programs.
13481 (As a special exception for GNU Fortran bug-reporting, at least
13482 for now, if you are sending more than a few lines of code, if
13483 your program's source file format contains ``interesting'' things
13484 like trailing spaces or strange characters, or if you need to
13485 include binary data files, it is acceptable to put all the
13486 files together in a @code{tar} archive, and, whether you need to
13487 do that, it is acceptable to then compress the single file (@code{tar}
13488 archive or source file)
13489 using @code{gzip} and encode it via @code{uuencode}.
13490 Do not use any MIME stuff---the current maintainer can't decode this.
13491 Using @code{compress} instead of @code{gzip} is acceptable, assuming
13492 you have licensed the use of the patented algorithm in
13493 @code{compress} from Unisys.)
13495 To enable someone to investigate the bug, you should include all these
13500 The version of GNU Fortran.
13501 You can get this by running @code{g77} with the @samp{-v} option.
13502 (Ignore any error messages that might be displayed
13503 when the linker is run.)
13505 Without this, we won't know whether there is any point in looking for
13506 the bug in the current version of GNU Fortran.
13509 @cindex preprocessor
13510 @cindex cpp program
13511 @cindex programs, cpp
13513 A complete input file that will reproduce the bug.
13515 If your source file(s) require preprocessing
13516 (for example, their names have suffixes like
13517 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
13518 and the bug is in the compiler proper (@file{f771})
13519 or in a subsequent phase of processing,
13520 run your source file through the C preprocessor
13521 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
13522 Then, include the contents of @var{newfile} in the bug report.
13523 (When you do this, use the same preprocessor options---such as
13524 @samp{-I}, @samp{-D}, and @samp{-U}---that you used in actual
13527 A single statement is not enough of an example.
13528 In order to compile it,
13529 it must be embedded in a complete file of compiler input.
13530 The bug might depend on the details of how this is done.
13532 Without a real example one can compile,
13533 all anyone can do about your bug report is wish you luck.
13534 It would be futile to try to guess how to provoke the bug.
13535 For example, bugs in register allocation and reloading
13536 can depend on every little detail of the source and include files
13540 @cindex included files
13541 @cindex INCLUDE directive
13542 @cindex directive, INCLUDE
13543 @cindex #include directive
13544 @cindex directive, #include
13545 Note that you should include with your bug report any files
13546 included by the source file
13547 (via the @code{#include} or @code{INCLUDE} directive)
13548 that you send, and any files they include, and so on.
13550 It is not necessary to replace
13551 the @code{#include} and @code{INCLUDE} directives
13552 with the actual files in the version of the source file that
13553 you send, but it might make submitting the bug report easier
13555 However, be sure to @emph{reproduce} the bug using the @emph{exact}
13556 version of the source material you submit, to avoid wild-goose
13560 The command arguments you gave GNU Fortran to compile that example
13561 and observe the bug. For example, did you use @samp{-O}? To guarantee
13562 you won't omit something important, list all the options.
13564 If we were to try to guess the arguments, we would probably guess wrong
13565 and then we would not encounter the bug.
13568 The type of machine you are using, and the operating system name and
13570 (Much of this information is printed by @samp{g77 -v}---if you
13571 include that, send along any additional info you have that you
13572 don't see clearly represented in that output.)
13575 The operands you gave to the @code{configure} command when you installed
13579 A complete list of any modifications you have made to the compiler
13580 source. (We don't promise to investigate the bug unless it happens in
13581 an unmodified compiler. But if you've made modifications and don't tell
13582 us, then you are sending us on a wild-goose chase.)
13584 Be precise about these changes. A description in English is not
13585 enough---send a context diff for them.
13587 Adding files of your own (such as a machine description for a machine we
13588 don't support) is a modification of the compiler source.
13591 Details of any other deviations from the standard procedure for installing
13595 A description of what behavior you observe that you believe is
13596 incorrect. For example, ``The compiler gets a fatal signal,'' or,
13597 ``The assembler instruction at line 208 in the output is incorrect.''
13599 Of course, if the bug is that the compiler gets a fatal signal, then one
13600 can't miss it. But if the bug is incorrect output, the maintainer might
13601 not notice unless it is glaringly wrong. None of us has time to study
13602 all the assembler code from a 50-line Fortran program just on the chance that
13603 one instruction might be wrong. We need @emph{you} to do this part!
13605 Even if the problem you experience is a fatal signal, you should still
13606 say so explicitly. Suppose something strange is going on, such as, your
13607 copy of the compiler is out of synch, or you have encountered a bug in
13608 the C library on your system. (This has happened!) Your copy might
13609 crash and the copy here would not. If you @i{said} to expect a crash,
13610 then when the compiler here fails to crash, we would know that the bug
13611 was not happening. If you don't say to expect a crash, then we would
13612 not know whether the bug was happening. We would not be able to draw
13613 any conclusion from our observations.
13615 If the problem is a diagnostic when building GNU Fortran with some other
13616 compiler, say whether it is a warning or an error.
13618 Often the observed symptom is incorrect output when your program is run.
13619 Sad to say, this is not enough information unless the program is short
13620 and simple. None of us has time to study a large program to figure out
13621 how it would work if compiled correctly, much less which line of it was
13622 compiled wrong. So you will have to do that. Tell us which source line
13623 it is, and what incorrect result happens when that line is executed. A
13624 person who understands the program can find this as easily as finding a
13625 bug in the program itself.
13628 If you send examples of assembler code output from GNU Fortran,
13629 please use @samp{-g} when you make them. The debugging information
13630 includes source line numbers which are essential for correlating the
13631 output with the input.
13634 If you wish to mention something in the GNU Fortran source, refer to it by
13635 context, not by line number.
13637 The line numbers in the development sources don't match those in your
13638 sources. Your line numbers would convey no convenient information to the
13642 Additional information from a debugger might enable someone to find a
13643 problem on a machine which he does not have available. However, you
13644 need to think when you collect this information if you want it to have
13645 any chance of being useful.
13647 @cindex backtrace for bug reports
13648 For example, many people send just a backtrace, but that is never
13649 useful by itself. A simple backtrace with arguments conveys little
13650 about GNU Fortran because the compiler is largely data-driven; the same
13651 functions are called over and over for different RTL insns, doing
13652 different things depending on the details of the insn.
13654 Most of the arguments listed in the backtrace are useless because they
13655 are pointers to RTL list structure. The numeric values of the
13656 pointers, which the debugger prints in the backtrace, have no
13657 significance whatever; all that matters is the contents of the objects
13658 they point to (and most of the contents are other such pointers).
13660 In addition, most compiler passes consist of one or more loops that
13661 scan the RTL insn sequence. The most vital piece of information about
13662 such a loop---which insn it has reached---is usually in a local variable,
13663 not in an argument.
13666 What you need to provide in addition to a backtrace are the values of
13667 the local variables for several stack frames up. When a local
13668 variable or an argument is an RTX, first print its value and then use
13669 the GDB command @code{pr} to print the RTL expression that it points
13670 to. (If GDB doesn't run on your machine, use your debugger to call
13671 the function @code{debug_rtx} with the RTX as an argument.) In
13672 general, whenever a variable is a pointer, its value is no use
13673 without the data it points to.
13676 Here are some things that are not necessary:
13680 A description of the envelope of the bug.
13682 Often people who encounter a bug spend a lot of time investigating
13683 which changes to the input file will make the bug go away and which
13684 changes will not affect it.
13686 This is often time consuming and not very useful, because the way we
13687 will find the bug is by running a single example under the debugger with
13688 breakpoints, not by pure deduction from a series of examples. You might
13689 as well save your time for something else.
13691 Of course, if you can find a simpler example to report @emph{instead} of
13692 the original one, that is a convenience. Errors in the output will be
13693 easier to spot, running under the debugger will take less time, etc.
13694 Most GNU Fortran bugs involve just one function, so the most straightforward
13695 way to simplify an example is to delete all the function definitions
13696 except the one where the bug occurs. Those earlier in the file may be
13697 replaced by external declarations if the crucial function depends on
13698 them. (Exception: inline functions might affect compilation of functions
13699 defined later in the file.)
13701 However, simplification is not vital; if you don't want to do this,
13702 report the bug anyway and send the entire test case you used.
13705 In particular, some people insert conditionals @samp{#ifdef BUG} around
13706 a statement which, if removed, makes the bug not happen. These are just
13707 clutter; we won't pay any attention to them anyway. Besides, you should
13708 send us preprocessor output, and that can't have conditionals.
13711 A patch for the bug.
13713 A patch for the bug is useful if it is a good one. But don't omit the
13714 necessary information, such as the test case, on the assumption that a
13715 patch is all we need. We might see problems with your patch and decide
13716 to fix the problem another way, or we might not understand it at all.
13718 Sometimes with a program as complicated as GNU Fortran it is very hard to
13719 construct an example that will make the program follow a certain path
13720 through the code. If you don't send the example, we won't be able to
13721 construct one, so we won't be able to verify that the bug is fixed.
13723 And if we can't understand what bug you are trying to fix, or why your
13724 patch should be an improvement, we won't install it. A test case will
13725 help us to understand.
13727 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13728 understand and install your patches.
13731 A guess about what the bug is or what it depends on.
13733 Such guesses are usually wrong. Even the maintainer can't guess right
13734 about such things without first using the debugger to find the facts.
13739 We have no way of examining a core dump for your type of machine
13740 unless we have an identical system---and if we do have one,
13741 we should be able to reproduce the crash ourselves.
13744 @node Sending Patches
13745 @section Sending Patches for GNU Fortran
13747 If you would like to write bug fixes or improvements for the GNU Fortran
13748 compiler, that is very helpful.
13749 Send suggested fixes to the bug report
13750 mailing list, @email{@value{email-bugs}}.
13752 Please follow these guidelines so we can study your patches efficiently.
13753 If you don't follow these guidelines, your information might still be
13754 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13755 of work in the best of circumstances, and we can't keep up unless you do
13760 Send an explanation with your changes of what problem they fix or what
13761 improvement they bring about. For a bug fix, just include a copy of the
13762 bug report, and explain why the change fixes the bug.
13764 (Referring to a bug report is not as good as including it, because then
13765 we will have to look it up, and we have probably already deleted it if
13766 we've already fixed the bug.)
13769 Always include a proper bug report for the problem you think you have
13770 fixed. We need to convince ourselves that the change is right before
13771 installing it. Even if it is right, we might have trouble judging it if
13772 we don't have a way to reproduce the problem.
13775 Include all the comments that are appropriate to help people reading the
13776 source in the future understand why this change was needed.
13779 Don't mix together changes made for different reasons.
13780 Send them @emph{individually}.
13782 If you make two changes for separate reasons, then we might not want to
13783 install them both. We might want to install just one. If you send them
13784 all jumbled together in a single set of diffs, we have to do extra work
13785 to disentangle them---to figure out which parts of the change serve
13786 which purpose. If we don't have time for this, we might have to ignore
13787 your changes entirely.
13789 If you send each change as soon as you have written it, with its own
13790 explanation, then the two changes never get tangled up, and we can
13791 consider each one properly without any extra work to disentangle them.
13793 Ideally, each change you send should be impossible to subdivide into
13794 parts that we might want to consider separately, because each of its
13795 parts gets its motivation from the other parts.
13798 Send each change as soon as that change is finished. Sometimes people
13799 think they are helping us by accumulating many changes to send them all
13800 together. As explained above, this is absolutely the worst thing you
13803 Since you should send each change separately, you might as well send it
13804 right away. That gives us the option of installing it immediately if it
13808 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13809 for us to install reliably. More than that, they make it hard for us to
13810 study the diffs to decide whether we want to install them. Unidiff
13811 format is better than contextless diffs, but not as easy to read as
13814 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13815 function that each change occurs in.
13816 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13819 Write the change log entries for your changes. We get lots of changes,
13820 and we don't have time to do all the change log writing ourselves.
13822 Read the @file{ChangeLog} file to see what sorts of information to put
13823 in, and to learn the style that we use. The purpose of the change log
13824 is to show people where to find what was changed. So you need to be
13825 specific about what functions you changed; in large functions, it's
13826 often helpful to indicate where within the function the change was.
13828 On the other hand, once you have shown people where to find the change,
13829 you need not explain its purpose. Thus, if you add a new function, all
13830 you need to say about it is that it is new. If you feel that the
13831 purpose needs explaining, it probably does---but the explanation will be
13832 much more useful if you put it in comments in the code.
13834 If you would like your name to appear in the header line for who made
13835 the change, send us the header line.
13838 When you write the fix, keep in mind that we can't install a change that
13839 would break other systems.
13841 People often suggest fixing a problem by changing machine-independent
13842 files such as @file{toplev.c} to do something special that a particular
13843 system needs. Sometimes it is totally obvious that such changes would
13844 break GNU Fortran for almost all users. We can't possibly make a change like
13845 that. At best it might tell us how to write another patch that would
13846 solve the problem acceptably.
13848 Sometimes people send fixes that @emph{might} be an improvement in
13849 general---but it is hard to be sure of this. It's hard to install
13850 such changes because we have to study them very carefully. Of course,
13851 a good explanation of the reasoning by which you concluded the change
13852 was correct can help convince us.
13854 The safest changes are changes to the configuration files for a
13855 particular machine. These are safe because they can't create new bugs
13858 Please help us keep up with the workload by designing the patch in a
13859 form that is good to install.
13863 @chapter How To Get Help with GNU Fortran
13865 If you need help installing, using or changing GNU Fortran, there are two
13870 Look in the service directory for someone who might help you for a fee.
13871 The service directory is found in the file named @file{SERVICE} in the
13872 GNU CC distribution.
13875 Send a message to @email{@value{email-general}}.
13880 @node Adding Options
13881 @chapter Adding Options
13882 @cindex options, adding
13883 @cindex adding options
13885 To add a new command-line option to @code{g77}, first decide
13886 what kind of option you wish to add.
13887 Search the @code{g77} and @code{gcc} documentation for one
13888 or more options that is most closely like the one you want to add
13889 (in terms of what kind of effect it has, and so on) to
13890 help clarify its nature.
13894 @emph{Fortran options} are options that apply only
13895 when compiling Fortran programs.
13896 They are accepted by @code{g77} and @code{gcc}, but
13897 they apply only when compiling Fortran programs.
13900 @emph{Compiler options} are options that apply
13901 when compiling most any kind of program.
13904 @emph{Fortran options} are listed in the file
13905 @file{@value{path-g77}/lang-options.h},
13906 which is used during the build of @code{gcc} to
13907 build a list of all options that are accepted by
13908 at least one language's compiler.
13909 This list goes into the @code{documented_lang_options} array
13910 in @file{gcc/toplev.c}, which uses this array to
13911 determine whether a particular option should be
13912 offered to the linked-in front end for processing
13913 by calling @code{lang_option_decode}, which, for
13914 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13915 calls @code{ffe_decode_option}.
13917 If the linked-in front end ``rejects'' a
13918 particular option passed to it, @file{toplev.c}
13919 just ignores the option, because @emph{some}
13920 language's compiler is willing to accept it.
13922 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13923 to work, even though Fortran compilation does
13924 not currently support the @samp{-fno-asm} option;
13925 even though the @code{f771} version of @code{lang_decode_option}
13926 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13927 produce a diagnostic because some other language (C)
13930 This also means that commands like
13931 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13932 despite the fact that no phase of the command was
13933 able to recognize and process @samp{-fno-asm}---perhaps
13934 a warning about this would be helpful if it were
13937 Code that processes Fortran options is found in
13938 @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
13939 This code needs to check positive and negative forms
13942 The defaults for Fortran options are set in their
13943 global definitions, also found in @file{@value{path-g77}/top.c}.
13944 Many of these defaults are actually macros defined
13945 in @file{@value{path-g77}/target.h}, since they might be
13947 However, since, in practice, GNU compilers
13948 should behave the same way on all configurations
13949 (especially when it comes to language constructs),
13950 the practice of setting defaults in @file{target.h}
13951 is likely to be deprecated and, ultimately, stopped
13952 in future versions of @code{g77}.
13954 Accessor macros for Fortran options, used by code
13955 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13957 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13958 in the array @code{f_options}.
13959 An option not listed in @code{lang_options} is
13960 looked up in @code{f_options} and handled from there.
13962 The defaults for compiler options are set in the
13963 global definitions for the corresponding variables,
13964 some of which are in @file{gcc/toplev.c}.
13966 You can set different defaults for @emph{Fortran-oriented}
13967 or @emph{Fortran-reticent} compiler options by changing
13968 the source code of @code{g77} and rebuilding.
13969 How to do this depends on the version of @code{g77}:
13972 @item G77 0.5.24 (EGCS 1.1)
13973 @itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
13974 Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.
13976 (Note that these versions of @code{g77}
13977 perform internal consistency checking automatically
13978 when the @samp{-fversion} option is specified.)
13981 @itemx G77 0.5.24 (EGCS 1.0)
13982 Change the way @code{f771} handles the @samp{-fset-g77-defaults}
13983 option, which is always provided as the first option when
13984 called by @code{g77} or @code{gcc}.
13986 This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13987 Have it change just the variables that you want to default
13988 to a different setting for Fortran compiles compared to
13989 compiles of other languages.
13991 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13992 automatically because of the specification information
13993 kept in @file{@value{path-g77}/lang-specs.h}.
13994 This file tells the @code{gcc} command how to recognize,
13995 in this case, Fortran source files (those to be preprocessed,
13996 and those that are not), and further, how to invoke the
13997 appropriate programs (including @code{f771}) to process
13998 those source files.
14000 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
14001 @samp{-fversion}, and other options are passed, as appropriate,
14002 even when the user has not explicitly specified them.
14003 Other ``internal'' options such as @samp{-quiet} also
14004 are passed via this mechanism.
14011 If you want to contribute to @code{g77} by doing research,
14012 design, specification, documentation, coding, or testing,
14013 the following information should give you some ideas.
14014 More relevant information might be available from
14015 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
14018 * Efficiency:: Make @code{g77} itself compile code faster.
14019 * Better Optimization:: Teach @code{g77} to generate faster code.
14020 * Simplify Porting:: Make @code{g77} easier to configure, build,
14022 * More Extensions:: Features many users won't know to ask for.
14023 * Machine Model:: @code{g77} should better leverage @code{gcc}.
14024 * Internals Documentation:: Make maintenance easier.
14025 * Internals Improvements:: Make internals more robust.
14026 * Better Diagnostics:: Make using @code{g77} on new code easier.
14030 @section Improve Efficiency
14033 Don't bother doing any performance analysis until most of the
14034 following items are taken care of, because there's no question
14035 they represent serious space/time problems, although some of
14036 them show up only given certain kinds of (popular) input.
14040 Improve @code{malloc} package and its uses to specify more info about
14041 memory pools and, where feasible, use obstacks to implement them.
14044 Skip over uninitialized portions of aggregate areas (arrays,
14045 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
14046 This would reduce memory usage for large initialized aggregate
14047 areas, even ones with only one initialized element.
14049 As of version 0.5.18, a portion of this item has already been
14053 Prescan the statement (in @file{sta.c}) so that the nature of the statement
14054 is determined as much as possible by looking entirely at its form,
14055 and not looking at any context (previous statements, including types
14057 This would allow ripping out of the statement-confirmation,
14058 symbol retraction/confirmation, and diagnostic inhibition
14060 Plus, it would result in much-improved diagnostics.
14061 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
14062 is not a subroutine intrinsic, would result actual error instead of the
14063 unimplemented-statement catch-all.
14066 Throughout @code{g77}, don't pass line/column pairs where
14067 a simple @code{ffewhere} type, which points to the error as much as is
14068 desired by the configuration, will do, and don't pass @code{ffelexToken} types
14069 where a simple @code{ffewhere} type will do.
14070 Then, allow new default
14071 configuration of @code{ffewhere} such that the source line text is not
14072 preserved, and leave it to things like Emacs' next-error function
14073 to point to them (now that @samp{next-error} supports column,
14074 or, perhaps, character-offset, numbers).
14075 The change in calling sequences should improve performance somewhat,
14076 as should not having to save source lines.
14077 (Whether this whole
14078 item will improve performance is questionable, but it should
14079 improve maintainability.)
14082 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
14083 as regards the assembly output.
14084 Some of this might require improving
14085 the back end, but lots of improvement in space/time required in @code{g77}
14086 itself can be fairly easily obtained without touching the back end.
14087 Maybe type-conversion, where necessary, can be speeded up as well in
14088 cases like the one shown (converting the @samp{2} into @samp{2.}).
14091 If analysis shows it to be worthwhile, optimize @file{lex.c}.
14094 Consider redesigning @file{lex.c} to not need any feedback
14095 during tokenization, by keeping track of enough parse state on its
14099 @node Better Optimization
14100 @section Better Optimization
14101 @cindex optimization, better
14102 @cindex code generation, improving
14104 Much of this work should be put off until after @code{g77} has
14105 all the features necessary for its widespread acceptance as a
14106 useful F77 compiler.
14107 However, perhaps this work can be done in parallel during
14108 the feature-adding work.
14112 Do the equivalent of the trick of putting @samp{extern inline} in front
14113 of every function definition in @code{libg2c} and #include'ing the resulting
14114 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
14115 that are at all worth inlining.
14116 (Some of this has already been done, such as for integral exponentiation.)
14119 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
14120 and it's clear that types line up
14121 and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
14122 make @samp{CHAR_VAR}, not a
14123 temporary, be the receiver for @samp{CHAR_FUNC}.
14124 (This is now done for @code{COMPLEX} variables.)
14127 Design and implement Fortran-specific optimizations that don't
14128 really belong in the back end, or where the front end needs to
14129 give the back end more info than it currently does.
14132 Design and implement a new run-time library interface, with the
14133 code going into @code{libgcc} so no special linking is required to
14134 link Fortran programs using standard language features.
14136 would speed up lots of things, from I/O (using precompiled formats,
14137 doing just one, or, at most, very few, calls for arrays or array sections,
14138 and so on) to general computing (array/section implementations of
14139 various intrinsics, implementation of commonly performed loops that
14140 aren't likely to be optimally compiled otherwise, etc.).
14142 Among the important things the library would do are:
14146 Be a one-stop-shop-type
14147 library, hence shareable and usable by all, in that what are now
14148 library-build-time options in @code{libg2c} would be moved at least to the
14149 @code{g77} compile phase, if not to finer grains (such as choosing how
14150 list-directed I/O formatting is done by default at @code{OPEN} time, for
14151 preconnected units via options or even statements in the main program
14152 unit, maybe even on a per-I/O basis with appropriate pragma-like
14157 Probably requiring the new library design, change interface to
14158 normally have @code{COMPLEX} functions return their values in the way
14159 @code{gcc} would if they were declared @code{__complex__ float},
14161 the mechanism currently used by @code{CHARACTER} functions (whereby the
14162 functions are compiled as returning void and their first arg is
14163 a pointer to where to store the result).
14164 (Don't append underscores to
14165 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
14166 @code{gcc} rather than @code{f2c} calling conventions.)
14169 Do something useful with @code{doiter} references where possible.
14170 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
14171 a @code{DO} loop that uses @samp{I} as the
14172 iteration variable, and the back end might find that info useful
14173 in determining whether it needs to read @samp{I} back into a register after
14175 (It normally has to do that, unless it knows @samp{FOO} never
14176 modifies its passed-by-reference argument, which is rarely the case
14177 for Fortran-77 code.)
14180 @node Simplify Porting
14181 @section Simplify Porting
14182 @cindex porting, simplify
14183 @cindex simplify porting
14185 Making @code{g77} easier to configure, port, build, and install, either
14186 as a single-system compiler or as a cross-compiler, would be
14191 A new library (replacing @code{libg2c}) should improve portability as well as
14192 produce more optimal code.
14193 Further, @code{g77} and the new library should
14194 conspire to simplify naming of externals, such as by removing unnecessarily
14195 added underscores, and to reduce/eliminate the possibility of naming
14196 conflicts, while making debugger more straightforward.
14199 make multi-language applications more feasible, such as by providing
14200 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
14204 Possibly related to a new library, @code{g77} should produce the equivalent
14205 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
14206 main program unit, instead of compiling something that must be
14207 called by a library
14208 implementation of @code{main()}.
14210 This would do many useful things such as
14211 provide more flexibility in terms of setting up exception handling,
14212 not requiring programmers to start their debugging sessions with
14213 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
14216 The GBE needs to understand the difference between alignment
14217 requirements and desires.
14218 For example, on Intel x86 machines, @code{g77} currently imposes
14219 overly strict alignment requirements, due to the back end, but it
14220 would be useful for Fortran and C programmers to be able to override
14221 these @emph{recommendations} as long as they don't violate the actual
14222 processor @emph{requirements}.
14225 @node More Extensions
14226 @section More Extensions
14227 @cindex extensions, more
14229 These extensions are not the sort of things users ask for ``by name'',
14230 but they might improve the usability of @code{g77}, and Fortran in
14231 general, in the long run.
14232 Some of these items really pertain to improving @code{g77} internals
14233 so that some popular extensions can be more easily supported.
14237 Look through all the documentation on the GNU Fortran language,
14238 dialects, compiler, missing features, bugs, and so on.
14239 Many mentions of incomplete or missing features are
14240 sprinkled throughout.
14241 It is not worth repeating them here.
14244 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
14246 The idea is to provide a forward-looking, effective
14247 replacement for things like the old-style @code{PARAMETER} statement
14249 really need typelessness in a maintainable, portable, clearly documented
14251 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
14252 and whatever else might come along.
14253 (This is not really a call for polymorphism per se, just
14254 an ability to express limited, syntactic polymorphism.)
14257 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
14260 Support arbitrary file unit numbers, instead of limiting them
14261 to 0 through @samp{MXUNIT-1}.
14262 (This is a @code{libg2c} issue.)
14265 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
14266 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
14267 later @code{UNIT=} in the first example is invalid.
14268 Make sure this is what users of this feature would expect.
14271 Currently @code{g77} disallows @samp{READ(1'10)} since
14272 it is an obnoxious syntax, but
14273 supporting it might be pretty easy if needed.
14274 More details are needed, such
14275 as whether general expressions separated by an apostrophe are supported,
14276 or maybe the record number can be a general expression, and so on.
14279 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
14281 Currently there is no support at all
14282 for @code{%FILL} in @code{STRUCTURE} and related syntax,
14283 whereas the rest of the
14284 stuff has at least some parsing support.
14285 This requires either major
14286 changes to @code{libg2c} or its replacement.
14289 F90 and @code{g77} probably disagree about label scoping relative to
14290 @code{INTERFACE} and @code{END INTERFACE}, and their contained
14291 procedure interface bodies (blocks?).
14294 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
14295 since that was added after S8.112.
14298 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
14299 with the final form of the standard (it was vague at S8.112).
14302 It seems to be an ``open'' question whether a file, immediately after being
14303 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
14304 might be nice to offer an option of opening to ``undefined'' status, requiring
14305 an explicit absolute-positioning operation to be performed before any
14306 other (besides @code{CLOSE}) to assist in making applications port to systems
14307 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
14310 @node Machine Model
14311 @section Machine Model
14313 This items pertain to generalizing @code{g77}'s view of
14314 the machine model to more fully accept whatever the GBE
14315 provides it via its configuration.
14319 Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
14320 exclusively so the target float format need not be required.
14322 means changing the way @code{g77} handles initialization of aggregate areas
14323 having more than one type, such as @code{REAL} and @code{INTEGER},
14325 it initializes them as if they were arrays of @code{char} and uses the
14326 bit patterns of the constants of the various types in them to determine
14327 what to stuff in elements of the arrays.
14330 Rely more and more on back-end info and capabilities, especially in the
14331 area of constants (where having the @code{g77} front-end's IL just store
14332 the appropriate tree nodes containing constants might be best).
14335 Suite of C and Fortran programs that a user/administrator can run on a
14336 machine to help determine the configuration for @code{g77} before building
14337 and help determine if the compiler works (especially with whatever
14338 libraries are installed) after building.
14341 @node Internals Documentation
14342 @section Internals Documentation
14344 Better info on how @code{g77} works and how to port it is needed.
14345 Much of this should be done only after the redesign planned for
14348 @xref{Front End}, which contains some information
14349 on @code{g77} internals.
14351 @node Internals Improvements
14352 @section Internals Improvements
14354 Some more items that would make @code{g77} more reliable
14355 and easier to maintain:
14359 Generally make expression handling focus
14360 more on critical syntax stuff, leaving semantics to callers.
14362 anything a caller can check, semantically, let it do so, rather
14363 than having @file{expr.c} do it.
14364 (Exceptions might include things like
14365 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
14367 important to preserve the left-to-right-in-source order of production
14371 Come up with better naming conventions for @samp{-D} to establish requirements
14372 to achieve desired implementation dialect via @file{proj.h}.
14375 Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
14378 Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
14381 Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
14382 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
14383 (after determining if there is indeed no real need for it).
14386 Utility to read and check @file{bad.def} messages and their references in the
14387 code, to make sure calls are consistent with message templates.
14390 Search and fix @samp{&ffe@dots{}} and similar so that
14391 @samp{ffe@dots{}ptr@dots{}} macros are
14392 available instead (a good argument for wishing this could have written all
14393 this stuff in C++, perhaps).
14394 On the other hand, it's questionable whether this sort of
14395 improvement is really necessary, given the availability of
14396 tools such as Emacs and Perl, which make finding any
14397 address-taking of structure members easy enough?
14400 Some modules truly export the member names of their structures (and the
14401 structures themselves), maybe fix this, and fix other modules that just
14402 appear to as well (by appending @samp{_}, though it'd be ugly and probably
14403 not worth the time).
14406 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
14408 and use them throughout @code{g77} source code (especially in the definitions
14409 of access macros in @samp{.h} files) so they can be tailored
14410 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
14413 Decorate throughout with @code{const} and other such stuff.
14416 All F90 notational derivations in the source code are still based
14417 on the S8.112 version of the draft standard.
14418 Probably should update
14419 to the official standard, or put documentation of the rules as used
14420 in the code@dots{}uh@dots{}in the code.
14423 Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
14424 inside but invoked via paths not involving @code{ffeexpr_lhs} or
14425 @code{ffeexpr_rhs}) might be creating things
14426 in improper pools, leading to such things staying around too long or
14427 (doubtful, but possible and dangerous) not long enough.
14430 Some @code{ffebld_list_new} (or whatever) calls might not be matched by
14431 @code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
14432 (It definitely is not a problem just yet.)
14435 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
14436 due to alignment/mismatch or other problems---they end up without
14437 @code{ffestorag} objects, so maybe the backend (and other parts of the front
14438 end) can notice that and handle like an @code{opANY} (do what it wants, just
14439 don't complain or crash).
14440 Most of this seems to have been addressed
14441 by now, but a code review wouldn't hurt.
14444 @node Better Diagnostics
14445 @section Better Diagnostics
14447 These are things users might not ask about, or that need to
14448 be looked into, before worrying about.
14449 Also here are items that involve reducing unnecessary diagnostic
14454 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
14455 lengths, type classes, and so on),
14456 @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
14460 Speed up and improve error handling for data when repeat-count is
14462 For example, don't output 20 unnecessary messages after the
14463 first necessary one for:
14468 DATA (X(I), J= 1, 20) /20*5/
14473 (The @code{CONTINUE} statement ensures the @code{DATA} statement
14474 is processed in the context of executable, not specification,
14484 @chapter Diagnostics
14485 @cindex diagnostics
14487 Some diagnostics produced by @code{g77} require sufficient explanation
14488 that the explanations are given below, and the diagnostics themselves
14489 identify the appropriate explanation.
14491 Identification uses the GNU Info format---specifically, the @code{info}
14492 command that displays the explanation is given within square
14493 brackets in the diagnostic.
14497 foo.f:5: Invalid statement [info -f g77 M FOOEY]
14500 More details about the above diagnostic is found in the @code{g77} Info
14501 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
14502 which is displayed by typing the UNIX command
14503 @samp{info -f g77 M FOOEY}.
14505 Other Info readers, such as EMACS, may be just as easily used to display
14506 the pertinent node.
14507 In the above example, @samp{g77} is the Info document name,
14508 @samp{M} is the top-level menu item to select,
14509 and, in that node (named @samp{Diagnostics}, the name of
14510 this chapter, which is the very text you're reading now),
14511 @samp{FOOEY} is the menu item to select.
14514 In this printed version of the @code{g77} manual, the above example
14515 points to a section, below, entitled @samp{FOOEY}---though, of course,
14516 as the above is just a sample, no such section exists.
14520 * CMPAMBIG:: Ambiguous use of intrinsic.
14521 * EXPIMP:: Intrinsic used explicitly and implicitly.
14522 * INTGLOB:: Intrinsic also used as name of global.
14523 * LEX:: Various lexer messages
14524 * GLOBALS:: Disagreements about globals.
14525 * LINKFAIL:: When linking @code{f771} fails.
14526 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
14530 @section @code{CMPAMBIG}
14534 Ambiguous use of intrinsic @var{intrinsic} @dots{}
14537 The type of the argument to the invocation of the @var{intrinsic}
14538 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
14539 Typically, it is @code{COMPLEX(KIND=2)}, also known as
14540 @code{DOUBLE COMPLEX}.
14542 The interpretation of this invocation depends on the particular
14543 dialect of Fortran for which the code was written.
14544 Some dialects convert the real part of the argument to
14545 @code{REAL(KIND=1)}, thus losing precision; other dialects,
14546 and Fortran 90, do no such conversion.
14548 So, GNU Fortran rejects such invocations except under certain
14549 circumstances, to avoid making an incorrect assumption that results
14550 in generating the wrong code.
14552 To determine the dialect of the program unit, perhaps even whether
14553 that particular invocation is properly coded, determine how the
14554 result of the intrinsic is used.
14556 The result of @var{intrinsic} is expected (by the original programmer)
14557 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
14561 It is passed as an argument to a procedure that explicitly or
14562 implicitly declares that argument @code{REAL(KIND=1)}.
14565 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
14566 statement specifying the dummy argument corresponding to an
14567 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14568 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14569 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
14570 of @code{REAL(KIND=2)}.
14573 It is used in a context that would otherwise not include
14574 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
14575 invocation as @code{REAL(KIND=2)} would result in unnecessary
14576 promotions and (typically) more expensive operations on the
14587 The above example suggests the programmer expected the real part
14588 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
14589 multiplied by @samp{T} (presumed, along with @samp{R} above, to
14590 be type @code{REAL(KIND=1)}).
14592 Otherwise, the conversion would have to be delayed until after
14593 the multiplication, requiring not only an extra conversion
14594 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
14595 expensive multiplication (a double-precision multiplication instead
14596 of a single-precision one).
14599 The result of @var{intrinsic} is expected (by the original programmer)
14600 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
14604 It is passed as an argument to a procedure that explicitly or
14605 implicitly declares that argument @code{REAL(KIND=2)}.
14607 For example, a procedure specifying a @code{DOUBLE PRECISION}
14608 dummy argument corresponding to an
14609 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14610 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14611 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
14612 of @code{REAL(KIND=1)}.
14615 It is used in an expression context that includes
14616 other @code{REAL(KIND=2)} operands,
14617 or is assigned to a @code{REAL(KIND=2)} variable or array element.
14623 DOUBLE PRECISION R, T
14628 The above example suggests the programmer expected the real part
14629 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
14630 by the @code{REAL()} intrinsic.
14632 Otherwise, the conversion would have to be immediately followed
14633 by a conversion back to @code{REAL(KIND=2)}, losing
14634 the original, full precision of the real part of @code{Z},
14635 before being multiplied by @samp{T}.
14638 Once you have determined whether a particular invocation of @var{intrinsic}
14639 expects the Fortran 90 interpretation, you can:
14643 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
14644 @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
14646 if it expected the Fortran 90 interpretation.
14648 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
14649 some other type, such as @code{COMPLEX*32}, you should use the
14650 appropriate intrinsic, such as the one to convert to @code{REAL*16}
14651 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
14652 @code{QIMAG()} in place of @code{DIMAG()}).
14655 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
14657 This converts to @code{REAL(KIND=1)} in all working
14661 If you don't want to change the code, and you are certain that all
14662 ambiguous invocations of @var{intrinsic} in the source file have
14663 the same expectation regarding interpretation, you can:
14667 Compile with the @code{g77} option @samp{-ff90}, to enable the
14668 Fortran 90 interpretation.
14671 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
14672 to enable the non-Fortran-90 interpretations.
14675 @xref{REAL() and AIMAG() of Complex}, for more information on this
14678 Note: If the above suggestions don't produce enough evidence
14679 as to whether a particular program expects the Fortran 90
14680 interpretation of this ambiguous invocation of @var{intrinsic},
14681 there is one more thing you can try.
14683 If you have access to most or all the compilers used on the
14684 program to create successfully tested and deployed executables,
14685 read the documentation for, and @emph{also} test out, each compiler
14686 to determine how it treats the @var{intrinsic} intrinsic in
14688 (If all the compilers don't agree on an interpretation, there
14689 might be lurking bugs in the deployed versions of the program.)
14691 The following sample program might help:
14693 @cindex JCB003 program
14697 C Written by James Craig Burley 1997-02-23.
14699 C Determine how compilers handle non-standard REAL
14700 C and AIMAG on DOUBLE COMPLEX operands.
14708 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14709 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14713 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14714 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14717 C Just to make sure compiler doesn't use naive flow
14718 C analysis to optimize away careful work above,
14719 C which might invalidate results....
14721 SUBROUTINE DUMDUM(Z, R)
14727 If the above program prints contradictory results on a
14728 particular compiler, run away!
14731 @section @code{EXPIMP}
14735 Intrinsic @var{intrinsic} referenced @dots{}
14738 The @var{intrinsic} is explicitly declared in one program
14739 unit in the source file and implicitly used as an intrinsic
14740 in another program unit in the same source file.
14742 This diagnostic is designed to catch cases where a program
14743 might depend on using the name @var{intrinsic} as an intrinsic
14744 in one program unit and as a global name (such as the name
14745 of a subroutine or function) in another, but @code{g77} recognizes
14746 the name as an intrinsic in both cases.
14748 After verifying that the program unit making implicit use
14749 of the intrinsic is indeed written expecting the intrinsic,
14750 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14751 program unit to prevent this warning.
14753 This and related warnings are disabled by using
14754 the @samp{-Wno-globals} option when compiling.
14756 Note that this warning is not issued for standard intrinsics.
14757 Standard intrinsics include those described in the FORTRAN 77
14758 standard and, if @samp{-ff90} is specified, those described
14759 in the Fortran 90 standard.
14760 Such intrinsics are not as likely to be confused with user
14761 procedures as intrinsics provided as extensions to the
14762 standard by @code{g77}.
14765 @section @code{INTGLOB}
14769 Same name `@var{intrinsic}' given @dots{}
14772 The name @var{intrinsic} is used for a global entity (a common
14773 block or a program unit) in one program unit and implicitly
14774 used as an intrinsic in another program unit.
14776 This diagnostic is designed to catch cases where a program
14777 intends to use a name entirely as a global name, but @code{g77}
14778 recognizes the name as an intrinsic in the program unit that
14779 references the name, a situation that would likely produce
14785 INTEGER FUNCTION TIME()
14791 PRINT *, 'Time is ', TIME()
14795 The above example defines a program unit named @samp{TIME}, but
14796 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14797 is normally treated by @code{g77} as a reference to the intrinsic
14798 @code{TIME()} (unless a command-line option that prevents such
14799 treatment has been specified).
14801 As a result, the program @samp{SAMP} will @emph{not}
14802 invoke the @samp{TIME} function in the same source file.
14804 Since @code{g77} recognizes @code{libU77} procedures as
14805 intrinsics, and since some existing code uses the same names
14806 for its own procedures as used by some @code{libU77}
14807 procedures, this situation is expected to arise often enough
14808 to make this sort of warning worth issuing.
14810 After verifying that the program unit making implicit use
14811 of the intrinsic is indeed written expecting the intrinsic,
14812 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14813 program unit to prevent this warning.
14815 Or, if you believe the program unit is designed to invoke the
14816 program-defined procedure instead of the intrinsic (as
14817 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14818 statement to the program unit that references the name to
14819 prevent this warning.
14821 This and related warnings are disabled by using
14822 the @samp{-Wno-globals} option when compiling.
14824 Note that this warning is not issued for standard intrinsics.
14825 Standard intrinsics include those described in the FORTRAN 77
14826 standard and, if @samp{-ff90} is specified, those described
14827 in the Fortran 90 standard.
14828 Such intrinsics are not as likely to be confused with user
14829 procedures as intrinsics provided as extensions to the
14830 standard by @code{g77}.
14833 @section @code{LEX}
14837 Unrecognized character @dots{}
14838 Invalid first character @dots{}
14839 Line too long @dots{}
14840 Non-numeric character @dots{}
14841 Continuation indicator @dots{}
14842 Label at @dots{} invalid with continuation line indicator @dots{}
14843 Character constant @dots{}
14844 Continuation line @dots{}
14845 Statement at @dots{} begins with invalid token
14848 Although the diagnostics identify specific problems, they can
14849 be produced when general problems such as the following occur:
14853 The source file contains something other than Fortran code.
14855 If the code in the file does not look like many of the examples
14856 elsewhere in this document, it might not be Fortran code.
14857 (Note that Fortran code often is written in lower case letters,
14858 while the examples in this document use upper case letters,
14859 for stylistic reasons.)
14861 For example, if the file contains lots of strange-looking
14862 characters, it might be APL source code; if it contains lots
14863 of parentheses, it might be Lisp source code; if it
14864 contains lots of bugs, it might be C++ source code.
14867 The source file contains free-form Fortran code, but @samp{-ffree-form}
14868 was not specified on the command line to compile it.
14870 Free form is a newer form for Fortran code.
14871 The older, classic form is called fixed form.
14873 @cindex continuation character
14874 @cindex characters, continuation
14875 Fixed-form code is visually fairly distinctive, because
14876 numerical labels and comments are all that appear in
14877 the first five columns of a line, the sixth column is
14878 reserved to denote continuation lines,
14879 and actual statements start at or beyond column 7.
14880 Spaces generally are not significant, so if you
14881 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14882 you are looking at fixed-form code.
14885 Comment lines are indicated by the letter @samp{C} or the symbol
14886 @samp{*} in column 1.
14887 @cindex trailing comment
14889 @cindex characters, comment
14891 @cindex exclamation point
14892 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14893 which many compilers support.)
14895 Free-form code is distinguished from fixed-form source
14896 primarily by the fact that statements may start anywhere.
14897 (If lots of statements start in columns 1 through 6,
14898 that's a strong indicator of free-form source.)
14899 Consecutive keywords must be separated by spaces, so
14900 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14901 There are no comment lines per se, but @samp{!} starts a
14902 comment anywhere in a line (other than within a character or
14903 Hollerith constant).
14905 @xref{Source Form}, for more information.
14908 The source file is in fixed form and has been edited without
14909 sensitivity to the column requirements.
14911 Statements in fixed-form code must be entirely contained within
14912 columns 7 through 72 on a given line.
14913 Starting them ``early'' is more likely to result in diagnostics
14914 than finishing them ``late'', though both kinds of errors are
14915 often caught at compile time.
14917 For example, if the following code fragment is edited by following
14918 the commented instructions literally, the result, shown afterward,
14919 would produce a diagnostic when compiled:
14922 C On XYZZY systems, remove "C" on next line:
14926 The result of editing the above line might be:
14929 C On XYZZY systems, remove "C" on next line:
14933 However, that leaves the first @samp{C} in the @code{CALL}
14934 statement in column 6, making it a comment line, which is
14935 not really what the author intended, and which is likely
14936 to result in one of the above-listed diagnostics.
14938 @emph{Replacing} the @samp{C} in column 1 with a space
14939 is the proper change to make, to ensure the @code{CALL}
14940 keyword starts in or after column 7.
14942 Another common mistake like this is to forget that fixed-form
14943 source lines are significant through only column 72, and that,
14944 normally, any text beyond column 72 is ignored or is diagnosed
14947 @xref{Source Form}, for more information.
14950 The source file requires preprocessing, and the preprocessing
14951 is not being specified at compile time.
14953 A source file containing lines beginning with @code{#define},
14954 @code{#include}, @code{#if}, and so on is likely one that
14955 requires preprocessing.
14957 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
14958 the file normally will be compiled @emph{without} preprocessing
14961 Change the file's suffix from @samp{.f} to @samp{.F}
14962 (or, on systems with case-insensitive file names,
14963 to @samp{.fpp} or @samp{.FPP}),
14964 from @samp{.for} to @samp{.fpp},
14965 or from @samp{.FOR} to @samp{.FPP}.
14966 @code{g77} compiles files with such names @emph{with}
14970 @cindex preprocessor
14971 @cindex cpp program
14972 @cindex programs, cpp
14973 @cindex @samp{-x f77-cpp-input} option
14974 @cindex options, @samp{-x f77-cpp-input}
14975 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14976 the language @samp{f77-cpp-input} for Fortran files that
14977 require preprocessing.
14978 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14981 The source file is preprocessed, and the results of preprocessing
14982 result in syntactic errors that are not necessarily obvious to
14983 someone examining the source file itself.
14985 Examples of errors resulting from preprocessor macro expansion
14986 include exceeding the line-length limit, improperly starting,
14987 terminating, or incorporating the apostrophe or double-quote in
14988 a character constant, improperly forming a Hollerith constant,
14991 @xref{Overall Options,,Options Controlling the Kind of Output},
14992 for suggestions about how to use, and not use, preprocessing
14997 @section @code{GLOBALS}
15001 Global name @var{name} defined at @dots{} already defined@dots{}
15002 Global name @var{name} at @dots{} has different type@dots{}
15003 Too many arguments passed to @var{name} at @dots{}
15004 Too few arguments passed to @var{name} at @dots{}
15005 Argument #@var{n} of @var{name} is @dots{}
15008 These messages all identify disagreements about the
15009 global procedure named @var{name} among different program units
15010 (usually including @var{name} itself).
15012 Whether a particular disagreement is reported
15013 as a warning or an error
15014 can depend on the relative order
15015 of the disagreeing portions of the source file.
15017 Disagreements between a procedure invocation
15018 and the @emph{subsequent} procedure itself
15019 are, usually, diagnosed as errors
15020 when the procedure itself @emph{precedes} the invocation.
15021 Other disagreements are diagnosed via warnings.
15023 @cindex forward references
15024 @cindex in-line code
15025 @cindex compilation, in-line
15026 This distinction, between warnings and errors,
15027 is due primarily to the present tendency of the @code{gcc} back end
15028 to inline only those procedure invocations that are
15029 @emph{preceded} by the corresponding procedure definitions.
15030 If the @code{gcc} back end is changed
15031 to inline ``forward references'',
15032 in which invocations precede definitions,
15033 the @code{g77} front end will be changed
15034 to treat both orderings as errors, accordingly.
15036 The sorts of disagreements that are diagnosed by @code{g77} include
15037 whether a procedure is a subroutine or function;
15038 if it is a function, the type of the return value of the procedure;
15039 the number of arguments the procedure accepts;
15040 and the type of each argument.
15042 Disagreements regarding global names among program units
15043 in a Fortran program @emph{should} be fixed in the code itself.
15044 However, if that is not immediately practical,
15045 and the code has been working for some time,
15046 it is possible it will work
15047 when compiled with the @samp{-fno-globals} option.
15049 The @samp{-fno-globals} option
15050 causes these diagnostics to all be warnings
15051 and disables all inlining of references to global procedures
15052 (to avoid subsequent compiler crashes and bad-code generation).
15053 Use of the @samp{-Wno-globals} option as well as @samp{-fno-globals}
15054 suppresses all of these diagnostics.
15055 (@samp{-Wno-globals} by itself disables only the warnings,
15058 After using @samp{-fno-globals} to work around these problems,
15059 it is wise to stop using that option and address them by fixing
15060 the Fortran code, because such problems, while they might not
15061 actually result in bugs on some systems, indicate that the code
15062 is not as portable as it could be.
15063 In particular, the code might appear to work on a particular
15064 system, but have bugs that affect the reliability of the data
15065 without exhibiting any other outward manifestations of the bugs.
15068 @section @code{LINKFAIL}
15072 If the above command failed due to an unresolved reference
15073 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
15074 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
15075 for information on what causes this, how to work around
15076 the problem by editing $@{srcdir@}/proj.c, and what else to do.
15079 @xref{Missing strtoul or bsearch}, for more information on
15081 which occurs only in releases of @code{g77}
15082 based on @code{gcc}.
15083 (It did not occur in @code{egcs}.)
15085 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
15086 due to a linker bug in coping with the @samp{-bbigtoc} option which
15087 leads to a @samp{Relocation overflow} error. The GNU linker is not
15088 recommended on current AIX versions, though; it was developed under a
15089 now-unsupported version. This bug is said to be fixed by `update PTF
15090 U455193 for APAR IX75823'.
15092 Compiling with @samp{-mminimal-toc}
15093 might solve this problem, e.g.@: by adding
15095 BOOT_CFLAGS='-mminimal-toc -O2 -g'
15097 to the @code{make bootstrap} command line.
15100 @section @code{Y2KBAD}
15101 @cindex Y2K compliance
15102 @cindex Year 2000 compliance
15106 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
15109 This diagnostic indicates that
15110 the specific intrinsic invoked by the name @var{name}
15111 is known to have an interface
15112 that is not Year-2000 (Y2K) compliant.
15114 @xref{Year 2000 (Y2K) Problems}.