1 \input texinfo @c -*-texinfo-*-
5 @set last-update 1999-06-06
6 @set copyrights-g77 1995-1999
10 @c This tells @include'd files that they're part of the overall G77 doc
11 @c set. (They might be part of a higher-level doc set too.)
14 @c @setfilename useg77.info
15 @c @setfilename portg77.info
16 @c To produce the full manual, use the "g77.info" setfilename, and
17 @c make sure the following do NOT begin with '@c' (and the @clear lines DO)
20 @c To produce a user-only manual, use the "useg77.info" setfilename, and
21 @c make sure the following does NOT begin with '@c':
23 @c To produce a porter-only manual, use the "portg77.info" setfilename,
24 @c and make sure the following does NOT begin with '@c':
27 @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi)
30 @c i also commented out the finalout command, so if there *are* any
31 @c overfulls, you'll (hopefully) see the rectangle in the right hand
32 @c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi).
37 @settitle Using and Porting GNU Fortran
40 @c seems reasonable to assume at least one of INTERNALS or USING is set...
42 @settitle Using GNU Fortran
45 @settitle Porting GNU Fortran
47 @c then again, have some fun
50 @settitle Doing Squat with GNU Fortran
58 @c Cause even numbered pages to be printed on the left hand side of
59 @c the page and odd numbered pages to be printed on the right hand
60 @c side of the page. Using this, you can print on both sides of a
61 @c sheet of paper and have the text on the same part of the sheet.
63 @c The text on right hand pages is pushed towards the right hand
64 @c margin and the text on left hand pages is pushed toward the left
66 @c (To provide the reverse effect, set bindingoffset to -0.75in.)
69 @c \global\bindingoffset=0.75in
70 @c \global\normaloffset =0.75in
74 @dircategory Programming
76 * g77: (g77). The GNU Fortran compiler.
80 This file documents the use and the internals of the GNU Fortran (@code{g77})
82 It corresponds to the @value{which-g77} version of @code{g77}.
86 This file documents the internals of the GNU Fortran (@code{g77}) compiler.
87 It corresponds to the @value{which-g77} version of @code{g77}.
90 This file documents the use of the GNU Fortran (@code{g77}) compiler.
91 It corresponds to the @value{which-g77} version of @code{g77}.
94 Published by the Free Software Foundation
95 59 Temple Place - Suite 330
96 Boston, MA 02111-1307 USA
98 Copyright (C) @value{copyrights-g77} Free Software Foundation, Inc.
100 Permission is granted to make and distribute verbatim copies of
101 this manual provided the copyright notice and this permission notice
102 are preserved on all copies.
105 Permission is granted to process this file through Tex and print the
106 results, provided the printed document carries copying permission
107 notice identical to this one except for the removal of this paragraph
108 (this paragraph not being relevant to the printed manual).
111 Permission is granted to copy and distribute modified versions of this
112 manual under the conditions for verbatim copying, provided also that the
113 sections entitled ``GNU General Public License,'' ``Funding for Free
114 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
115 included exactly as in the original, and provided that the entire
116 resulting derived work is distributed under the terms of a permission
117 notice identical to this one.
119 Permission is granted to copy and distribute translations of this manual
120 into another language, under the above conditions for modified versions,
121 except that the sections entitled ``GNU General Public License,''
122 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
123 And Feel'@w{}'', and this permission notice, may be included in
124 translations approved by the Free Software Foundation instead of in the
128 Contributed by James Craig Burley (@email{@value{email-burley}}).
129 Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
130 was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).
132 @setchapternewpage odd
137 @center @titlefont{Using and Porting GNU Fortran}
142 @title Using GNU Fortran
145 @title Porting GNU Fortran
148 @center James Craig Burley
150 @center Last updated @value{last-update}
152 @center for version @value{version-g77}
154 @vskip 0pt plus 1filll
155 Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.
157 For the @value{which-g77} Version*
159 Published by the Free Software Foundation @*
160 59 Temple Place - Suite 330@*
161 Boston, MA 02111-1307, USA@*
162 @c Last printed ??ber, 19??.@*
163 @c Printed copies are available for $? each.@*
166 Permission is granted to make and distribute verbatim copies of
167 this manual provided the copyright notice and this permission notice
168 are preserved on all copies.
170 Permission is granted to copy and distribute modified versions of this
171 manual under the conditions for verbatim copying, provided also that the
172 sections entitled ``GNU General Public License,'' ``Funding for Free
173 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
174 included exactly as in the original, and provided that the entire
175 resulting derived work is distributed under the terms of a permission
176 notice identical to this one.
178 Permission is granted to copy and distribute translations of this manual
179 into another language, under the above conditions for modified versions,
180 except that the sections entitled ``GNU General Public License,''
181 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
182 And Feel'@w{}'', and this permission notice, may be included in
183 translations approved by the Free Software Foundation instead of in the
190 @node Top, Copying,, (DIR)
196 This manual documents how to run, install and port @code{g77},
197 as well as its new features and incompatibilities,
198 and how to report bugs.
199 It corresponds to the @value{which-g77} version of @code{g77}.
204 This manual documents how to run and install @code{g77},
205 as well as its new features and incompatibilities, and how to report
207 It corresponds to the @value{which-g77} version of @code{g77}.
210 This manual documents how to port @code{g77},
211 as well as its new features and incompatibilities,
212 and how to report bugs.
213 It corresponds to the @value{which-g77} version of @code{g77}.
219 @emph{Warning:} This document is still under development,
220 and might not accurately reflect the @code{g77} code base
221 of which it is a part.
222 Efforts are made to keep it somewhat up-to-date,
223 but they are particularly concentrated
224 on any version of this information
225 that is distributed as part of a @emph{released} @code{g77}.
227 In particular, while this document is intended to apply to
228 the @value{which-g77} version of @code{g77},
229 only an official @emph{release} of that version
230 is expected to contain documentation that is
231 most consistent with the @code{g77} product in that version.
235 * Copying:: GNU General Public License says
236 how you can copy and share GNU Fortran.
237 * Contributors:: People who have contributed to GNU Fortran.
238 * Funding:: How to help assure continued work for free software.
239 * Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
240 * Look and Feel:: Protect your freedom---fight ``look and feel''.
242 * Getting Started:: Finding your way around this manual.
243 * What is GNU Fortran?:: How @code{g77} fits into the universe.
244 * G77 and GCC:: You can compile Fortran, C, or other programs.
245 * Invoking G77:: Command options supported by @code{g77}.
246 * News:: News about recent releases of @code{g77}.
247 * Changes:: User-visible changes to recent releases of @code{g77}.
248 * Language:: The GNU Fortran language.
249 * Compiler:: The GNU Fortran compiler.
250 * Other Dialects:: Dialects of Fortran supported by @code{g77}.
251 * Other Compilers:: Fortran compilers other than @code{g77}.
252 * Other Languages:: Languages other than Fortran.
253 * Installation:: How to configure, compile and install GNU Fortran.
254 * Debugging and Interfacing:: How @code{g77} generates code.
255 * Collected Fortran Wisdom:: How to avoid Trouble.
256 * Trouble:: If you have trouble with GNU Fortran.
257 * Open Questions:: Things we'd like to know.
258 * Bugs:: How, why, and where to report bugs.
259 * Service:: How to find suppliers of support for GNU Fortran.
262 * Adding Options:: Guidance on teaching @code{g77} about new options.
263 * Projects:: Projects for @code{g77} internals hackers.
264 * Front End:: Design and implementation of the @code{g77} front end.
267 * M: Diagnostics. Diagnostics produced by @code{g77}.
269 * Index:: Index of concepts and symbol names.
271 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
274 @unnumbered GNU GENERAL PUBLIC LICENSE
275 @center Version 2, June 1991
278 Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
279 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
281 Everyone is permitted to copy and distribute verbatim copies
282 of this license document, but changing it is not allowed.
285 @unnumberedsec Preamble
287 The licenses for most software are designed to take away your
288 freedom to share and change it. By contrast, the GNU General Public
289 License is intended to guarantee your freedom to share and change free
290 software---to make sure the software is free for all its users. This
291 General Public License applies to most of the Free Software
292 Foundation's software and to any other program whose authors commit to
293 using it. (Some other Free Software Foundation software is covered by
294 the GNU Library General Public License instead.) You can apply it to
297 When we speak of free software, we are referring to freedom, not
298 price. Our General Public Licenses are designed to make sure that you
299 have the freedom to distribute copies of free software (and charge for
300 this service if you wish), that you receive source code or can get it
301 if you want it, that you can change the software or use pieces of it
302 in new free programs; and that you know you can do these things.
304 To protect your rights, we need to make restrictions that forbid
305 anyone to deny you these rights or to ask you to surrender the rights.
306 These restrictions translate to certain responsibilities for you if you
307 distribute copies of the software, or if you modify it.
309 For example, if you distribute copies of such a program, whether
310 gratis or for a fee, you must give the recipients all the rights that
311 you have. You must make sure that they, too, receive or can get the
312 source code. And you must show them these terms so they know their
315 We protect your rights with two steps: (1) copyright the software, and
316 (2) offer you this license which gives you legal permission to copy,
317 distribute and/or modify the software.
319 Also, for each author's protection and ours, we want to make certain
320 that everyone understands that there is no warranty for this free
321 software. If the software is modified by someone else and passed on, we
322 want its recipients to know that what they have is not the original, so
323 that any problems introduced by others will not reflect on the original
324 authors' reputations.
326 Finally, any free program is threatened constantly by software
327 patents. We wish to avoid the danger that redistributors of a free
328 program will individually obtain patent licenses, in effect making the
329 program proprietary. To prevent this, we have made it clear that any
330 patent must be licensed for everyone's free use or not licensed at all.
332 The precise terms and conditions for copying, distribution and
336 @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
339 @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
344 This License applies to any program or other work which contains
345 a notice placed by the copyright holder saying it may be distributed
346 under the terms of this General Public License. The ``Program'', below,
347 refers to any such program or work, and a ``work based on the Program''
348 means either the Program or any derivative work under copyright law:
349 that is to say, a work containing the Program or a portion of it,
350 either verbatim or with modifications and/or translated into another
351 language. (Hereinafter, translation is included without limitation in
352 the term ``modification''.) Each licensee is addressed as ``you''.
354 Activities other than copying, distribution and modification are not
355 covered by this License; they are outside its scope. The act of
356 running the Program is not restricted, and the output from the Program
357 is covered only if its contents constitute a work based on the
358 Program (independent of having been made by running the Program).
359 Whether that is true depends on what the Program does.
362 You may copy and distribute verbatim copies of the Program's
363 source code as you receive it, in any medium, provided that you
364 conspicuously and appropriately publish on each copy an appropriate
365 copyright notice and disclaimer of warranty; keep intact all the
366 notices that refer to this License and to the absence of any warranty;
367 and give any other recipients of the Program a copy of this License
368 along with the Program.
370 You may charge a fee for the physical act of transferring a copy, and
371 you may at your option offer warranty protection in exchange for a fee.
374 You may modify your copy or copies of the Program or any portion
375 of it, thus forming a work based on the Program, and copy and
376 distribute such modifications or work under the terms of Section 1
377 above, provided that you also meet all of these conditions:
381 You must cause the modified files to carry prominent notices
382 stating that you changed the files and the date of any change.
385 You must cause any work that you distribute or publish, that in
386 whole or in part contains or is derived from the Program or any
387 part thereof, to be licensed as a whole at no charge to all third
388 parties under the terms of this License.
391 If the modified program normally reads commands interactively
392 when run, you must cause it, when started running for such
393 interactive use in the most ordinary way, to print or display an
394 announcement including an appropriate copyright notice and a
395 notice that there is no warranty (or else, saying that you provide
396 a warranty) and that users may redistribute the program under
397 these conditions, and telling the user how to view a copy of this
398 License. (Exception: if the Program itself is interactive but
399 does not normally print such an announcement, your work based on
400 the Program is not required to print an announcement.)
403 These requirements apply to the modified work as a whole. If
404 identifiable sections of that work are not derived from the Program,
405 and can be reasonably considered independent and separate works in
406 themselves, then this License, and its terms, do not apply to those
407 sections when you distribute them as separate works. But when you
408 distribute the same sections as part of a whole which is a work based
409 on the Program, the distribution of the whole must be on the terms of
410 this License, whose permissions for other licensees extend to the
411 entire whole, and thus to each and every part regardless of who wrote it.
413 Thus, it is not the intent of this section to claim rights or contest
414 your rights to work written entirely by you; rather, the intent is to
415 exercise the right to control the distribution of derivative or
416 collective works based on the Program.
418 In addition, mere aggregation of another work not based on the Program
419 with the Program (or with a work based on the Program) on a volume of
420 a storage or distribution medium does not bring the other work under
421 the scope of this License.
424 You may copy and distribute the Program (or a work based on it,
425 under Section 2) in object code or executable form under the terms of
426 Sections 1 and 2 above provided that you also do one of the following:
430 Accompany it with the complete corresponding machine-readable
431 source code, which must be distributed under the terms of Sections
432 1 and 2 above on a medium customarily used for software interchange; or,
435 Accompany it with a written offer, valid for at least three
436 years, to give any third party, for a charge no more than your
437 cost of physically performing source distribution, a complete
438 machine-readable copy of the corresponding source code, to be
439 distributed under the terms of Sections 1 and 2 above on a medium
440 customarily used for software interchange; or,
443 Accompany it with the information you received as to the offer
444 to distribute corresponding source code. (This alternative is
445 allowed only for noncommercial distribution and only if you
446 received the program in object code or executable form with such
447 an offer, in accord with Subsection b above.)
450 The source code for a work means the preferred form of the work for
451 making modifications to it. For an executable work, complete source
452 code means all the source code for all modules it contains, plus any
453 associated interface definition files, plus the scripts used to
454 control compilation and installation of the executable. However, as a
455 special exception, the source code distributed need not include
456 anything that is normally distributed (in either source or binary
457 form) with the major components (compiler, kernel, and so on) of the
458 operating system on which the executable runs, unless that component
459 itself accompanies the executable.
461 If distribution of executable or object code is made by offering
462 access to copy from a designated place, then offering equivalent
463 access to copy the source code from the same place counts as
464 distribution of the source code, even though third parties are not
465 compelled to copy the source along with the object code.
468 You may not copy, modify, sublicense, or distribute the Program
469 except as expressly provided under this License. Any attempt
470 otherwise to copy, modify, sublicense or distribute the Program is
471 void, and will automatically terminate your rights under this License.
472 However, parties who have received copies, or rights, from you under
473 this License will not have their licenses terminated so long as such
474 parties remain in full compliance.
477 You are not required to accept this License, since you have not
478 signed it. However, nothing else grants you permission to modify or
479 distribute the Program or its derivative works. These actions are
480 prohibited by law if you do not accept this License. Therefore, by
481 modifying or distributing the Program (or any work based on the
482 Program), you indicate your acceptance of this License to do so, and
483 all its terms and conditions for copying, distributing or modifying
484 the Program or works based on it.
487 Each time you redistribute the Program (or any work based on the
488 Program), the recipient automatically receives a license from the
489 original licensor to copy, distribute or modify the Program subject to
490 these terms and conditions. You may not impose any further
491 restrictions on the recipients' exercise of the rights granted herein.
492 You are not responsible for enforcing compliance by third parties to
496 If, as a consequence of a court judgment or allegation of patent
497 infringement or for any other reason (not limited to patent issues),
498 conditions are imposed on you (whether by court order, agreement or
499 otherwise) that contradict the conditions of this License, they do not
500 excuse you from the conditions of this License. If you cannot
501 distribute so as to satisfy simultaneously your obligations under this
502 License and any other pertinent obligations, then as a consequence you
503 may not distribute the Program at all. For example, if a patent
504 license would not permit royalty-free redistribution of the Program by
505 all those who receive copies directly or indirectly through you, then
506 the only way you could satisfy both it and this License would be to
507 refrain entirely from distribution of the Program.
509 If any portion of this section is held invalid or unenforceable under
510 any particular circumstance, the balance of the section is intended to
511 apply and the section as a whole is intended to apply in other
514 It is not the purpose of this section to induce you to infringe any
515 patents or other property right claims or to contest validity of any
516 such claims; this section has the sole purpose of protecting the
517 integrity of the free software distribution system, which is
518 implemented by public license practices. Many people have made
519 generous contributions to the wide range of software distributed
520 through that system in reliance on consistent application of that
521 system; it is up to the author/donor to decide if he or she is willing
522 to distribute software through any other system and a licensee cannot
525 This section is intended to make thoroughly clear what is believed to
526 be a consequence of the rest of this License.
529 If the distribution and/or use of the Program is restricted in
530 certain countries either by patents or by copyrighted interfaces, the
531 original copyright holder who places the Program under this License
532 may add an explicit geographical distribution limitation excluding
533 those countries, so that distribution is permitted only in or among
534 countries not thus excluded. In such case, this License incorporates
535 the limitation as if written in the body of this License.
538 The Free Software Foundation may publish revised and/or new versions
539 of the General Public License from time to time. Such new versions will
540 be similar in spirit to the present version, but may differ in detail to
541 address new problems or concerns.
543 Each version is given a distinguishing version number. If the Program
544 specifies a version number of this License which applies to it and ``any
545 later version'', you have the option of following the terms and conditions
546 either of that version or of any later version published by the Free
547 Software Foundation. If the Program does not specify a version number of
548 this License, you may choose any version ever published by the Free Software
552 If you wish to incorporate parts of the Program into other free
553 programs whose distribution conditions are different, write to the author
554 to ask for permission. For software which is copyrighted by the Free
555 Software Foundation, write to the Free Software Foundation; we sometimes
556 make exceptions for this. Our decision will be guided by the two goals
557 of preserving the free status of all derivatives of our free software and
558 of promoting the sharing and reuse of software generally.
568 BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
569 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
570 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
571 PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
572 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
573 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
574 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
575 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
576 REPAIR OR CORRECTION.
579 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
580 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
581 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
582 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
583 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
584 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
585 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
586 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
587 POSSIBILITY OF SUCH DAMAGES.
591 @heading END OF TERMS AND CONDITIONS
594 @center END OF TERMS AND CONDITIONS
598 @unnumberedsec How to Apply These Terms to Your New Programs
600 If you develop a new program, and you want it to be of the greatest
601 possible use to the public, the best way to achieve this is to make it
602 free software which everyone can redistribute and change under these terms.
604 To do so, attach the following notices to the program. It is safest
605 to attach them to the start of each source file to most effectively
606 convey the exclusion of warranty; and each file should have at least
607 the ``copyright'' line and a pointer to where the full notice is found.
610 @var{one line to give the program's name and a brief idea of what it does.}
611 Copyright (C) 19@var{yy} @var{name of author}
613 This program is free software; you can redistribute it and/or modify
614 it under the terms of the GNU General Public License as published by
615 the Free Software Foundation; either version 2 of the License, or
616 (at your option) any later version.
618 This program is distributed in the hope that it will be useful,
619 but WITHOUT ANY WARRANTY; without even the implied warranty of
620 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
621 GNU General Public License for more details.
623 You should have received a copy of the GNU General Public License
624 along with this program; if not, write to the Free Software
625 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
628 Also add information on how to contact you by electronic and paper mail.
630 If the program is interactive, make it output a short notice like this
631 when it starts in an interactive mode:
634 Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
635 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
637 This is free software, and you are welcome to redistribute it
638 under certain conditions; type `show c' for details.
641 The hypothetical commands @samp{show w} and @samp{show c} should show
642 the appropriate parts of the General Public License. Of course, the
643 commands you use may be called something other than @samp{show w} and
644 @samp{show c}; they could even be mouse-clicks or menu items---whatever
647 You should also get your employer (if you work as a programmer) or your
648 school, if any, to sign a ``copyright disclaimer'' for the program, if
649 necessary. Here is a sample; alter the names:
652 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
653 `Gnomovision' (which makes passes at compilers) written by James Hacker.
655 @var{signature of Ty Coon}, 1 April 1989
656 Ty Coon, President of Vice
659 This General Public License does not permit incorporating your program into
660 proprietary programs. If your program is a subroutine library, you may
661 consider it more useful to permit linking proprietary applications with the
662 library. If this is what you want to do, use the GNU Library General
663 Public License instead of this License.
666 @unnumbered Contributors to GNU Fortran
670 In addition to James Craig Burley, who wrote the front end,
671 many people have helped create and improve GNU Fortran.
675 The packaging and compiler portions of GNU Fortran are based largely
676 on the GNU CC compiler.
677 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
678 for more information.
681 The run-time library used by GNU Fortran is a repackaged version
682 of the @code{libf2c} library (combined from the @code{libF77} and
683 @code{libI77} libraries) provided as part of @code{f2c}, available for
684 free from @code{netlib} sites on the Internet.
687 Cygnus Support and The Free Software Foundation contributed
688 significant money and/or equipment to Craig's efforts.
691 The following individuals served as alpha testers prior to @code{g77}'s
692 public release. This work consisted of testing, researching, sometimes
693 debugging, and occasionally providing small amounts of code and fixes
694 for @code{g77}, plus offering plenty of helpful advice to Craig:
700 Dr.@: Mark Fernyhough
702 Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
706 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
708 Dr.@: A. O. V. Le Blanc
730 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
731 provided the patch to add rudimentary support
732 for @code{INTEGER*1}, @code{INTEGER*2}, and
734 This inspired Craig to add further support,
735 even though the resulting support
736 would still be incomplete, because version 0.6 is still
740 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
741 and encouraged Craig to rewrite the documentation in texinfo
742 format by contributing a first pass at a translation of the
743 old @file{g77-0.5.16/f/DOC} file.
746 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
747 some analysis of generated code as part of an overall project
748 to improve @code{g77} code generation to at least be as good
749 as @code{f2c} used in conjunction with @code{gcc}.
750 So far, this has resulted in the three, somewhat
751 experimental, options added by @code{g77} to the @code{gcc}
752 compiler and its back end.
754 (These, in turn, have made their way into the @code{egcs}
755 version of the compiler, and do not exist in @code{gcc}
756 version 2.8 or versions of @code{g77} based on that version
760 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
763 Thanks to Mary Cortani and the staff at Craftwork Solutions
764 (@email{support@@craftwork.com}) for all of their support.
767 Many other individuals have helped debug, test, and improve @code{g77}
768 over the past several years, and undoubtedly more people
769 will be doing so in the future.
770 If you have done so, and would like
771 to see your name listed in the above list, please ask!
772 The default is that people wish to remain anonymous.
776 @chapter Funding Free Software
778 If you want to have more free software a few years from now, it makes
779 sense for you to help encourage people to contribute funds for its
780 development. The most effective approach known is to encourage
781 commercial redistributors to donate.
783 Users of free software systems can boost the pace of development by
784 encouraging for-a-fee distributors to donate part of their selling price
785 to free software developers---the Free Software Foundation, and others.
787 The way to convince distributors to do this is to demand it and expect
788 it from them. So when you compare distributors, judge them partly by
789 how much they give to free software development. Show distributors
790 they must compete to be the one who gives the most.
792 To make this approach work, you must insist on numbers that you can
793 compare, such as, ``We will donate ten dollars to the Frobnitz project
794 for each disk sold.'' Don't be satisfied with a vague promise, such as
795 ``A portion of the profits are donated,'' since it doesn't give a basis
798 Even a precise fraction ``of the profits from this disk'' is not very
799 meaningful, since creative accounting and unrelated business decisions
800 can greatly alter what fraction of the sales price counts as profit.
801 If the price you pay is $50, ten percent of the profit is probably
802 less than a dollar; it might be a few cents, or nothing at all.
804 Some redistributors do development work themselves. This is useful too;
805 but to keep everyone honest, you need to inquire how much they do, and
806 what kind. Some kinds of development make much more long-term
807 difference than others. For example, maintaining a separate version of
808 a program contributes very little; maintaining the standard version of a
809 program for the whole community contributes much. Easy new ports
810 contribute little, since someone else would surely do them; difficult
811 ports such as adding a new CPU to the GNU C compiler contribute more;
812 major new features or packages contribute the most.
814 By establishing the idea that supporting further development is ``the
815 proper thing to do'' when distributing free software for a fee, we can
816 assure a steady flow of resources into making more free software.
819 Copyright (C) 1994 Free Software Foundation, Inc.
820 Verbatim copying and redistribution of this section is permitted
821 without royalty; alteration is not permitted.
824 @node Funding GNU Fortran
825 @chapter Funding GNU Fortran
826 @cindex funding improvements
827 @cindex improvements, funding
829 Work on GNU Fortran is still being done mostly by its author,
830 James Craig Burley (@email{@value{email-burley}}), who is a volunteer
831 for, not an employee of, the Free Software Foundation (FSF).
832 (He has a web page at @uref{@value{www-burley}}.)
834 As with other GNU software, funding is important because it can pay for
835 needed equipment, personnel, and so on.
837 @cindex FSF, funding the
838 @cindex funding the FSF
839 The FSF provides information on the best way to fund ongoing
840 development of GNU software (such as GNU Fortran) in documents
841 such as the ``GNUS Bulletin''.
842 Email @email{gnu@@gnu.org} for information on funding the FSF.
844 To fund specific GNU Fortran work in particular, the FSF might
845 provide a means for that, but the FSF does not provide direct funding
846 to the author of GNU Fortran to continue his work. The FSF has
847 employee salary restrictions that can be incompatible with the
848 financial needs of some volunteers, who therefore choose to
849 remain volunteers and thus be able to be free to do contract work
850 and otherwise make their own schedules for doing GNU work.
852 Still, funding the FSF at least indirectly benefits work
853 on specific projects like GNU Fortran because it ensures the
854 continuing operation of the FSF offices, their workstations, their
855 network connections, and so on, which are invaluable to volunteers.
856 (Similarly, hiring Cygnus Support can help a project like GNU
857 Fortran---Cygnus has been a long-time donor of equipment usage to the author
858 of GNU Fortran, and this too has been invaluable---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 -fexpensive-optimizations -fdelayed-branch
1450 -fschedule-insns -fschedule-insn2 -fcaller-saves
1451 -funroll-loops -funroll-all-loops
1452 -fno-move-all-movables -fno-reduce-all-givs
1456 @item Directory Options
1457 @xref{Directory Options,,Options for Directory Search}.
1462 @item Code Generation Options
1463 @xref{Code Gen Options,,Options for Code Generation Conventions}.
1465 -fno-automatic -finit-local-zero -fno-f2c
1466 -ff2c-library -fno-underscoring -fno-ident
1467 -fpcc-struct-return -freg-struct-return
1468 -fshort-double -fno-common -fpack-struct
1469 -fzeros -fno-second-underscore
1470 -fdebug-kludge -femulate-complex
1471 -falias-check -fargument-alias
1472 -fargument-noalias -fno-argument-noalias-global
1473 -fno-globals -fflatten-arrays
1474 -fbounds-check -ffortran-bounds-check
1479 * Overall Options:: Controlling the kind of output:
1480 an executable, object files, assembler files,
1481 or preprocessed source.
1482 * Shorthand Options:: Options that are shorthand for other options.
1483 * Fortran Dialect Options:: Controlling the variant of Fortran language
1485 * Warning Options:: How picky should the compiler be?
1486 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1487 * Optimize Options:: How much optimization?
1488 * Preprocessor Options:: Controlling header files and macro definitions.
1489 Also, getting dependency information for Make.
1490 * Directory Options:: Where to find header files and libraries.
1491 Where to find the compiler executable files.
1492 * Code Gen Options:: Specifying conventions for function calls, data layout
1496 @node Overall Options
1497 @section Options Controlling the Kind of Output
1498 @cindex overall options
1499 @cindex options, overall
1501 Compilation can involve as many as four stages: preprocessing, code
1502 generation (often what is really meant by the term ``compilation''),
1503 assembly, and linking, always in that order. The first three
1504 stages apply to an individual source file, and end by producing an
1505 object file; linking combines all the object files (those newly
1506 compiled, and those specified as input) into an executable file.
1508 @cindex file name suffix
1509 @cindex suffixes, file name
1510 @cindex file name extension
1511 @cindex extensions, file name
1514 For any given input file, the file name suffix determines what kind of
1515 program is contained in the file---that is, the language in which the
1516 program is written is generally indicated by the suffix.
1517 Suffixes specific to GNU Fortran are listed below.
1518 @xref{Overall Options,,gcc,Using and Porting GNU CC}, for
1519 information on suffixes recognized by GNU CC.
1522 @cindex .f filename suffix
1523 @cindex .for filename suffix
1524 @cindex .FOR filename suffix
1526 @item @var{file}.for
1527 @item @var{file}.FOR
1528 Fortran source code that should not be preprocessed.
1530 Such source code cannot contain any preprocessor directives, such
1531 as @code{#include}, @code{#define}, @code{#if}, and so on.
1533 You can force @samp{.f} files to be preprocessed by @code{cpp} by using
1534 @samp{-x f77-cpp-input}.
1537 @cindex preprocessor
1538 @cindex C preprocessor
1539 @cindex cpp preprocessor
1540 @cindex Fortran preprocessor
1542 @cindex programs, cpp
1543 @cindex .F filename suffix
1544 @cindex .fpp filename suffix
1545 @cindex .FPP filename suffix
1547 @item @var{file}.fpp
1548 @item @var{file}.FPP
1549 Fortran source code that must be preprocessed (by the C preprocessor
1550 @code{cpp}, which is part of GNU CC).
1552 Note that preprocessing is not extended to the contents of
1553 files included by the @code{INCLUDE} directive---the @code{#include}
1554 preprocessor directive must be used instead.
1556 @cindex Ratfor preprocessor
1557 @cindex programs, @code{ratfor}
1558 @cindex @samp{.r} filename suffix
1559 @cindex @code{ratfor}
1561 Ratfor source code, which must be preprocessed by the @code{ratfor}
1562 command, which is available separately (as it is not yet part of the GNU
1563 Fortran distribution).
1564 One version in Fortran, adapted for use with @code{g77}, is at
1565 @uref{ftp://members.aol.com/n8tm/rat7.uue} (of uncertain copyright
1566 status). Another, public domain version in C is at
1567 @uref{http://sepwww.stanford.edu/sep/prof/ratfor.shar.2}.
1570 UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
1572 Users of other operating systems, especially those that cannot
1573 distinguish upper-case
1574 letters from lower-case letters in their file names, typically use
1575 the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.
1580 Use of the preprocessor @code{cpp} allows use of C-like
1581 constructs such as @code{#define} and @code{#include}, but can
1582 lead to unexpected, even mistaken, results due to Fortran's source file
1584 It is recommended that use of the C preprocessor
1585 be limited to @code{#include} and, in
1586 conjunction with @code{#define}, only @code{#if} and related directives,
1587 thus avoiding in-line macro expansion entirely.
1588 This recommendation applies especially
1589 when using the traditional fixed source form.
1590 With free source form,
1591 fewer unexpected transformations are likely to happen, but use of
1592 constructs such as Hollerith and character constants can nevertheless
1593 present problems, especially when these are continued across multiple
1595 These problems result, primarily, from differences between the way
1596 such constants are interpreted by the C preprocessor and by a Fortran
1599 Another example of a problem that results from using the C preprocessor
1600 is that a Fortran comment line that happens to contain any
1601 characters ``interesting'' to the C preprocessor,
1602 such as a backslash at the end of the line,
1603 is not recognized by the preprocessor as a comment line,
1604 so instead of being passed through ``raw'',
1605 the line is edited according to the rules for the preprocessor.
1606 For example, the backslash at the end of the line is removed,
1607 along with the subsequent newline, resulting in the next
1608 line being effectively commented out---unfortunate if that
1609 line is a non-comment line of important code!
1611 @emph{Note:} The @samp{-traditional} and @samp{-undef} flags are supplied
1612 to @code{cpp} by default, to help avoid unpleasant surprises.
1613 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
1614 gcc,Using and Porting GNU CC}.
1615 This means that ANSI C preprocessor features (such as the @samp{#}
1616 operator) aren't available, and only variables in the C reserved
1617 namespace (generally, names with a leading underscore) are liable to
1618 substitution by C predefines.
1619 Thus, if you want to do system-specific
1620 tests, use, for example, @samp{#ifdef __linux__} rather than @samp{#ifdef linux}.
1621 Use the @samp{-v} option to see exactly how the preprocessor is invoked.
1624 Unfortunately, the @samp{-traditional} flag will not avoid an error from
1625 anything that @code{cpp} sees as an unterminated C comment, such as:
1627 C Some Fortran compilers accept /* as starting
1628 C an inline comment.
1630 @xref{Trailing Comment}.
1632 The following options that affect overall processing are recognized
1633 by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:
1636 @cindex -fversion option
1637 @cindex options, -fversion
1638 @cindex printing version information
1639 @cindex version information, printing
1640 @cindex consistency checks
1641 @cindex internal consistency checks
1642 @cindex checks, of internal consistency
1644 Ensure that the @code{g77}-specific version of the compiler phase is reported,
1646 and, starting in @code{egcs} version 1.1,
1647 that internal consistency checks in the @file{f771} program are run.
1649 This option is supplied automatically when @samp{-v} or @samp{--verbose}
1650 is specified as a command-line option for @code{g77} or @code{gcc}
1651 and when the resulting commands compile Fortran source files.
1653 @cindex -fset-g77-defaults option
1654 @cindex options, -fset-g77-defaults
1655 @item -fset-g77-defaults
1656 @emph{Version info:}
1657 This option is obsolete in @code{egcs}
1659 The effect is instead achieved
1660 by the @code{lang_init_options} routine
1661 in @file{egcs/gcc/f/com.c}.
1663 @cindex consistency checks
1664 @cindex internal consistency checks
1665 @cindex checks, of internal consistency
1666 Set up whatever @code{gcc} options are to apply to Fortran
1667 compilations, and avoid running internal consistency checks
1668 that might take some time.
1670 This option is supplied automatically when compiling Fortran code
1671 via the @code{g77} or @code{gcc} command.
1672 The description of this option is provided so that users seeing
1673 it in the output of, say, @samp{g77 -v} understand why it is
1676 @cindex modifying g77
1677 @cindex code, modifying
1678 Also, developers who run @code{f771} directly might want to specify it
1679 by hand to get the same defaults as they would running @code{f771}
1680 via @code{g77} or @code{gcc}.
1681 However, such developers should, after linking a new @code{f771}
1682 executable, invoke it without this option once,
1683 e.g. via @kbd{./f771 -quiet < /dev/null},
1684 to ensure that they have not introduced any
1685 internal inconsistencies (such as in the table of
1686 intrinsics) before proceeding---@code{g77} will crash
1687 with a diagnostic if it detects an inconsistency.
1689 @cindex -fno-silent option
1690 @cindex options, -fno-silent
1691 @cindex f2c compatibility
1692 @cindex compatibility, f2c
1693 @cindex status, compilation
1694 @cindex compilation, status
1695 @cindex reporting compilation status
1696 @cindex printing compilation status
1698 Print (to @code{stderr}) the names of the program units as
1699 they are compiled, in a form similar to that used by popular
1700 UNIX @code{f77} implementations and @code{f2c}.
1703 @xref{Overall Options,,Options Controlling the Kind of Output,
1704 gcc,Using and Porting GNU CC}, for information
1705 on more options that control the overall operation of the @code{gcc} command
1706 (and, by extension, the @code{g77} command).
1708 @node Shorthand Options
1709 @section Shorthand Options
1710 @cindex shorthand options
1711 @cindex options, shorthand
1712 @cindex macro options
1713 @cindex options, macro
1715 The following options serve as ``shorthand''
1716 for other options accepted by the compiler:
1719 @cindex -fugly option
1720 @cindex options, -fugly
1722 @cindex ugly features
1723 @cindex features, ugly
1724 @emph{Note:} This option is no longer supported.
1725 The information, below, is provided to aid
1726 in the conversion of old scripts.
1728 Specify that certain ``ugly'' constructs are to be quietly accepted.
1732 -fugly-args -fugly-assign -fugly-assumed
1733 -fugly-comma -fugly-complex -fugly-init
1737 These constructs are considered inappropriate to use in new
1738 or well-maintained portable Fortran code, but widely used
1740 @xref{Distensions}, for more information.
1742 @cindex -fno-ugly option
1743 @cindex options, -fno-ugly
1745 @cindex ugly features
1746 @cindex features, ugly
1747 Specify that all ``ugly'' constructs are to be noisily rejected.
1751 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1752 -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
1756 @xref{Distensions}, for more information.
1758 @cindex -ff66 option
1759 @cindex options, -ff66
1762 @cindex compatibility, FORTRAN 66
1763 Specify that the program is written in idiomatic FORTRAN 66.
1764 Same as @samp{-fonetrip -fugly-assumed}.
1766 The @samp{-fno-f66} option is the inverse of @samp{-ff66}.
1767 As such, it is the same as @samp{-fno-onetrip -fno-ugly-assumed}.
1769 The meaning of this option is likely to be refined as future
1770 versions of @code{g77} provide more compatibility with other
1771 existing and obsolete Fortran implementations.
1773 @cindex -ff77 option
1774 @cindex options, -ff77
1777 @cindex f2c compatibility
1778 @cindex compatibility, f2c
1779 @cindex f77 compatibility
1780 @cindex compatibility, f77
1781 Specify that the program is written in idiomatic UNIX FORTRAN 77
1782 and/or the dialect accepted by the @code{f2c} product.
1783 Same as @samp{-fbackslash -fno-typeless-boz}.
1785 The meaning of this option is likely to be refined as future
1786 versions of @code{g77} provide more compatibility with other
1787 existing and obsolete Fortran implementations.
1789 @cindex -fno-f77 option
1790 @cindex options, -fno-f77
1793 The @samp{-fno-f77} option is @emph{not} the inverse
1795 It specifies that the program is not written in idiomatic UNIX
1796 FORTRAN 77 or @code{f2c}, but in a more widely portable dialect.
1797 @samp{-fno-f77} is the same as @samp{-fno-backslash}.
1799 The meaning of this option is likely to be refined as future
1800 versions of @code{g77} provide more compatibility with other
1801 existing and obsolete Fortran implementations.
1804 @node Fortran Dialect Options
1805 @section Options Controlling Fortran Dialect
1806 @cindex dialect options
1807 @cindex language, dialect options
1808 @cindex options, dialect
1810 The following options control the dialect of Fortran
1811 that the compiler accepts:
1814 @cindex -ffree-form option
1815 @cindex options, -ffree-form
1816 @cindex -fno-fixed-form option
1817 @cindex options, -fno-fixed-form
1818 @cindex source file format
1821 @cindex Fortran 90, features
1823 @item -fno-fixed-form
1824 Specify that the source file is written in free form
1825 (introduced in Fortran 90) instead of the more-traditional fixed form.
1827 @cindex -ff90 option
1828 @cindex options, -ff90
1829 @cindex Fortran 90, features
1831 Allow certain Fortran-90 constructs.
1833 This option controls whether certain
1834 Fortran 90 constructs are recognized.
1835 (Other Fortran 90 constructs
1836 might or might not be recognized depending on other options such as
1837 @samp{-fvxt}, @samp{-ff90-intrinsics-enable}, and the
1838 current level of support for Fortran 90.)
1840 @xref{Fortran 90}, for more information.
1842 @cindex -fvxt option
1843 @cindex options, -fvxt
1845 @cindex Fortran 90, features
1846 @cindex VXT extensions
1847 Specify the treatment of certain constructs that have different
1848 meanings depending on whether the code is written in
1849 GNU Fortran (based on FORTRAN 77 and akin to Fortran 90)
1850 or VXT Fortran (more like VAX FORTRAN).
1852 The default is @samp{-fno-vxt}.
1853 @samp{-fvxt} specifies that the VXT Fortran interpretations
1854 for those constructs are to be chosen.
1856 @xref{VXT Fortran}, for more information.
1858 @cindex -fdollar-ok option
1859 @cindex options, -fdollar-ok
1862 @cindex symbol names
1863 @cindex character set
1864 Allow @samp{$} as a valid character in a symbol name.
1866 @cindex -fno-backslash option
1867 @cindex options, -fno-backslash
1868 @item -fno-backslash
1870 @cindex character constants
1871 @cindex Hollerith constants
1872 Specify that @samp{\} is not to be specially interpreted in character
1873 and Hollerith constants a la C and many UNIX Fortran compilers.
1875 For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
1876 three characters, with the second one being newline.
1877 With @samp{-fno-backslash}, it specifies four characters,
1878 @samp{A}, @samp{\}, @samp{n}, and @samp{B}.
1880 Note that @code{g77} implements a fairly general form of backslash
1881 processing that is incompatible with the narrower forms supported
1882 by some other compilers.
1883 For example, @samp{'A\003B'} is a three-character string in @code{g77},
1884 whereas other compilers that support backslash might not support
1885 the three-octal-digit form, and thus treat that string as longer
1886 than three characters.
1888 @xref{Backslash in Constants}, for
1889 information on why @samp{-fbackslash} is the default
1890 instead of @samp{-fno-backslash}.
1892 @cindex -fno-ugly-args option
1893 @cindex options, -fno-ugly-args
1894 @item -fno-ugly-args
1895 Disallow passing Hollerith and typeless constants as actual
1896 arguments (for example, @samp{CALL FOO(4HABCD)}).
1898 @xref{Ugly Implicit Argument Conversion}, for more information.
1900 @cindex -fugly-assign option
1901 @cindex options, -fugly-assign
1903 Use the same storage for a given variable regardless of
1904 whether it is used to hold an assigned-statement label
1905 (as in @samp{ASSIGN 10 TO I}) or used to hold numeric data
1906 (as in @samp{I = 3}).
1908 @xref{Ugly Assigned Labels}, for more information.
1910 @cindex -fugly-assumed option
1911 @cindex options, -fugly-assumed
1912 @item -fugly-assumed
1913 Assume any dummy array with a final dimension specified as @samp{1}
1914 is really an assumed-size array, as if @samp{*} had been specified
1915 for the final dimension instead of @samp{1}.
1917 For example, @samp{DIMENSION X(1)} is treated as if it
1918 had read @samp{DIMENSION X(*)}.
1920 @xref{Ugly Assumed-Size Arrays}, for more information.
1922 @cindex -fugly-comma option
1923 @cindex options, -fugly-comma
1925 In an external-procedure invocation,
1926 treat a trailing comma in the argument list
1927 as specification of a trailing null argument,
1928 and treat an empty argument list
1929 as specification of a single null argument.
1931 For example, @samp{CALL FOO(,)} is treated as
1932 @samp{CALL FOO(%VAL(0), %VAL(0))}.
1933 That is, @emph{two} null arguments are specified
1934 by the procedure call when @samp{-fugly-comma} is in force.
1935 And @samp{F = FUNC()} is treated as @samp{F = FUNC(%VAL(0))}.
1937 The default behavior, @samp{-fno-ugly-comma}, is to ignore
1938 a single trailing comma in an argument list.
1939 So, by default, @samp{CALL FOO(X,)} is treated
1940 exactly the same as @samp{CALL FOO(X)}.
1942 @xref{Ugly Null Arguments}, for more information.
1944 @cindex -fugly-complex option
1945 @cindex options, -fugly-complex
1946 @item -fugly-complex
1947 Do not complain about @samp{REAL(@var{expr})} or
1948 @samp{AIMAG(@var{expr})} when @var{expr} is a @code{COMPLEX}
1949 type other than @code{COMPLEX(KIND=1)}---usually
1950 this is used to permit @code{COMPLEX(KIND=2)}
1951 (@code{DOUBLE COMPLEX}) operands.
1953 The @samp{-ff90} option controls the interpretation
1956 @xref{Ugly Complex Part Extraction}, for more information.
1958 @cindex -fno-ugly-init option
1959 @cindex options, -fno-ugly-init
1960 @item -fno-ugly-init
1961 Disallow use of Hollerith and typeless constants as initial
1962 values (in @code{PARAMETER} and @code{DATA} statements), and
1963 use of character constants to
1964 initialize numeric types and vice versa.
1966 For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
1967 @samp{-fno-ugly-init}.
1969 @xref{Ugly Conversion of Initializers}, for more information.
1971 @cindex -fugly-logint option
1972 @cindex options, -fugly-logint
1974 Treat @code{INTEGER} and @code{LOGICAL} variables and
1975 expressions as potential stand-ins for each other.
1977 For example, automatic conversion between @code{INTEGER} and
1978 @code{LOGICAL} is enabled, for many contexts, via this option.
1980 @xref{Ugly Integer Conversions}, for more information.
1982 @cindex -fonetrip option
1983 @cindex options, -fonetrip
1986 @cindex @code{DO} loops, one-trip
1987 @cindex one-trip @code{DO} loops
1988 @cindex @code{DO} loops, zero-trip
1989 @cindex zero-trip @code{DO} loops
1990 @cindex compatibility, FORTRAN 66
1991 Executable iterative @code{DO} loops are to be executed at
1992 least once each time they are reached.
1994 ANSI FORTRAN 77 and more recent versions of the Fortran standard
1995 specify that the body of an iterative @code{DO} loop is not executed
1996 if the number of iterations calculated from the parameters of the
1997 loop is less than 1.
1998 (For example, @samp{DO 10 I = 1, 0}.)
1999 Such a loop is called a @dfn{zero-trip loop}.
2001 Prior to ANSI FORTRAN 77, many compilers implemented @code{DO} loops
2002 such that the body of a loop would be executed at least once, even
2003 if the iteration count was zero.
2004 Fortran code written assuming this behavior is said to require
2005 @dfn{one-trip loops}.
2006 For example, some code written to the FORTRAN 66 standard
2007 expects this behavior from its @code{DO} loops, although that
2008 standard did not specify this behavior.
2010 The @samp{-fonetrip} option specifies that the source file(s) being
2011 compiled require one-trip loops.
2013 This option affects only those loops specified by the (iterative) @code{DO}
2014 statement and by implied-@code{DO} lists in I/O statements.
2015 Loops specified by implied-@code{DO} lists in @code{DATA} and
2016 specification (non-executable) statements are not affected.
2018 @cindex -ftypeless-boz option
2019 @cindex options, -ftypeless-boz
2020 @cindex prefix-radix constants
2021 @cindex constants, prefix-radix
2022 @cindex constants, types
2023 @cindex types, constants
2024 @item -ftypeless-boz
2025 Specifies that prefix-radix non-decimal constants, such as
2026 @samp{Z'ABCD'}, are typeless instead of @code{INTEGER(KIND=1)}.
2028 You can test for yourself whether a particular compiler treats
2029 the prefix form as @code{INTEGER(KIND=1)} or typeless by running the
2036 IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
2037 IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
2041 Reports indicate that many compilers process this form as
2042 @code{INTEGER(KIND=1)}, though a few as typeless, and at least one
2043 based on a command-line option specifying some kind of
2046 @cindex -fintrin-case-initcap option
2047 @cindex options, -fintrin-case-initcap
2048 @item -fintrin-case-initcap
2049 @cindex -fintrin-case-upper option
2050 @cindex options, -fintrin-case-upper
2051 @item -fintrin-case-upper
2052 @cindex -fintrin-case-lower option
2053 @cindex options, -fintrin-case-lower
2054 @item -fintrin-case-lower
2055 @cindex -fintrin-case-any option
2056 @cindex options, -fintrin-case-any
2057 @item -fintrin-case-any
2058 Specify expected case for intrinsic names.
2059 @samp{-fintrin-case-lower} is the default.
2061 @cindex -fmatch-case-initcap option
2062 @cindex options, -fmatch-case-initcap
2063 @item -fmatch-case-initcap
2064 @cindex -fmatch-case-upper option
2065 @cindex options, -fmatch-case-upper
2066 @item -fmatch-case-upper
2067 @cindex -fmatch-case-lower option
2068 @cindex options, -fmatch-case-lower
2069 @item -fmatch-case-lower
2070 @cindex -fmatch-case-any option
2071 @cindex options, -fmatch-case-any
2072 @item -fmatch-case-any
2073 Specify expected case for keywords.
2074 @samp{-fmatch-case-lower} is the default.
2076 @cindex -fsource-case-upper option
2077 @cindex options, -fsource-case-upper
2078 @item -fsource-case-upper
2079 @cindex -fsource-case-lower option
2080 @cindex options, -fsource-case-lower
2081 @item -fsource-case-lower
2082 @cindex -fsource-case-preserve option
2083 @cindex options, -fsource-case-preserve
2084 @item -fsource-case-preserve
2085 Specify whether source text other than character and Hollerith constants
2086 is to be translated to uppercase, to lowercase, or preserved as is.
2087 @samp{-fsource-case-lower} is the default.
2089 @cindex -fsymbol-case-initcap option
2090 @cindex options, -fsymbol-case-initcap
2091 @item -fsymbol-case-initcap
2092 @cindex -fsymbol-case-upper option
2093 @cindex options, -fsymbol-case-upper
2094 @item -fsymbol-case-upper
2095 @cindex -fsymbol-case-lower option
2096 @cindex options, -fsymbol-case-lower
2097 @item -fsymbol-case-lower
2098 @cindex -fsymbol-case-any option
2099 @cindex options, -fsymbol-case-any
2100 @item -fsymbol-case-any
2101 Specify valid cases for user-defined symbol names.
2102 @samp{-fsymbol-case-any} is the default.
2104 @cindex -fcase-strict-upper option
2105 @cindex options, -fcase-strict-upper
2106 @item -fcase-strict-upper
2107 Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
2108 -fsymbol-case-upper}.
2109 (Requires all pertinent source to be in uppercase.)
2111 @cindex -fcase-strict-lower option
2112 @cindex options, -fcase-strict-lower
2113 @item -fcase-strict-lower
2114 Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
2115 -fsymbol-case-lower}.
2116 (Requires all pertinent source to be in lowercase.)
2118 @cindex -fcase-initcap option
2119 @cindex options, -fcase-initcap
2120 @item -fcase-initcap
2121 Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
2122 -fsymbol-case-initcap}.
2123 (Requires all pertinent source to be in initial capitals,
2124 as in @samp{Print *,SqRt(Value)}.)
2126 @cindex -fcase-upper option
2127 @cindex options, -fcase-upper
2129 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
2131 (Maps all pertinent source to uppercase.)
2133 @cindex -fcase-lower option
2134 @cindex options, -fcase-lower
2136 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
2138 (Maps all pertinent source to lowercase.)
2140 @cindex -fcase-preserve option
2141 @cindex options, -fcase-preserve
2142 @item -fcase-preserve
2143 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
2145 (Preserves all case in user-defined symbols,
2146 while allowing any-case matching of intrinsics and keywords.
2147 For example, @samp{call Foo(i,I)} would pass two @emph{different}
2148 variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)
2150 @cindex -fbadu77-intrinsics-delete option
2151 @cindex options, -fbadu77-intrinsics-delete
2152 @item -fbadu77-intrinsics-delete
2153 @cindex -fbadu77-intrinsics-hide option
2154 @cindex options, -fbadu77-intrinsics-hide
2155 @item -fbadu77-intrinsics-hide
2156 @cindex -fbadu77-intrinsics-disable option
2157 @cindex options, -fbadu77-intrinsics-disable
2158 @item -fbadu77-intrinsics-disable
2159 @cindex -fbadu77-intrinsics-enable option
2160 @cindex options, -fbadu77-intrinsics-enable
2161 @item -fbadu77-intrinsics-enable
2162 @cindex @code{badu77} intrinsics
2163 @cindex intrinsics, @code{badu77}
2164 Specify status of UNIX intrinsics having inappropriate forms.
2165 @samp{-fbadu77-intrinsics-enable} is the default.
2166 @xref{Intrinsic Groups}.
2168 @cindex -ff2c-intrinsics-delete option
2169 @cindex options, -ff2c-intrinsics-delete
2170 @item -ff2c-intrinsics-delete
2171 @cindex -ff2c-intrinsics-hide option
2172 @cindex options, -ff2c-intrinsics-hide
2173 @item -ff2c-intrinsics-hide
2174 @cindex -ff2c-intrinsics-disable option
2175 @cindex options, -ff2c-intrinsics-disable
2176 @item -ff2c-intrinsics-disable
2177 @cindex -ff2c-intrinsics-enable option
2178 @cindex options, -ff2c-intrinsics-enable
2179 @item -ff2c-intrinsics-enable
2180 @cindex @code{f2c} intrinsics
2181 @cindex intrinsics, @code{f2c}
2182 Specify status of f2c-specific intrinsics.
2183 @samp{-ff2c-intrinsics-enable} is the default.
2184 @xref{Intrinsic Groups}.
2186 @cindex -ff90-intrinsics-delete option
2187 @cindex options, -ff90-intrinsics-delete
2188 @item -ff90-intrinsics-delete
2189 @cindex -ff90-intrinsics-hide option
2190 @cindex options, -ff90-intrinsics-hide
2191 @item -ff90-intrinsics-hide
2192 @cindex -ff90-intrinsics-disable option
2193 @cindex options, -ff90-intrinsics-disable
2194 @item -ff90-intrinsics-disable
2195 @cindex -ff90-intrinsics-enable option
2196 @cindex options, -ff90-intrinsics-enable
2197 @item -ff90-intrinsics-enable
2198 @cindex Fortran 90, intrinsics
2199 @cindex intrinsics, Fortran 90
2200 Specify status of F90-specific intrinsics.
2201 @samp{-ff90-intrinsics-enable} is the default.
2202 @xref{Intrinsic Groups}.
2204 @cindex -fgnu-intrinsics-delete option
2205 @cindex options, -fgnu-intrinsics-delete
2206 @item -fgnu-intrinsics-delete
2207 @cindex -fgnu-intrinsics-hide option
2208 @cindex options, -fgnu-intrinsics-hide
2209 @item -fgnu-intrinsics-hide
2210 @cindex -fgnu-intrinsics-disable option
2211 @cindex options, -fgnu-intrinsics-disable
2212 @item -fgnu-intrinsics-disable
2213 @cindex -fgnu-intrinsics-enable option
2214 @cindex options, -fgnu-intrinsics-enable
2215 @item -fgnu-intrinsics-enable
2216 @cindex Digital Fortran features
2217 @cindex @code{COMPLEX} intrinsics
2218 @cindex intrinsics, @code{COMPLEX}
2219 Specify status of Digital's COMPLEX-related intrinsics.
2220 @samp{-fgnu-intrinsics-enable} is the default.
2221 @xref{Intrinsic Groups}.
2223 @cindex -fmil-intrinsics-delete option
2224 @cindex options, -fmil-intrinsics-delete
2225 @item -fmil-intrinsics-delete
2226 @cindex -fmil-intrinsics-hide option
2227 @cindex options, -fmil-intrinsics-hide
2228 @item -fmil-intrinsics-hide
2229 @cindex -fmil-intrinsics-disable option
2230 @cindex options, -fmil-intrinsics-disable
2231 @item -fmil-intrinsics-disable
2232 @cindex -fmil-intrinsics-enable option
2233 @cindex options, -fmil-intrinsics-enable
2234 @item -fmil-intrinsics-enable
2235 @cindex MIL-STD 1753
2236 @cindex intrinsics, MIL-STD 1753
2237 Specify status of MIL-STD-1753-specific intrinsics.
2238 @samp{-fmil-intrinsics-enable} is the default.
2239 @xref{Intrinsic Groups}.
2241 @cindex -funix-intrinsics-delete option
2242 @cindex options, -funix-intrinsics-delete
2243 @item -funix-intrinsics-delete
2244 @cindex -funix-intrinsics-hide option
2245 @cindex options, -funix-intrinsics-hide
2246 @item -funix-intrinsics-hide
2247 @cindex -funix-intrinsics-disable option
2248 @cindex options, -funix-intrinsics-disable
2249 @item -funix-intrinsics-disable
2250 @cindex -funix-intrinsics-enable option
2251 @cindex options, -funix-intrinsics-enable
2252 @item -funix-intrinsics-enable
2253 @cindex UNIX intrinsics
2254 @cindex intrinsics, UNIX
2255 Specify status of UNIX intrinsics.
2256 @samp{-funix-intrinsics-enable} is the default.
2257 @xref{Intrinsic Groups}.
2259 @cindex -fvxt-intrinsics-delete option
2260 @cindex options, -fvxt-intrinsics-delete
2261 @item -fvxt-intrinsics-delete
2262 @cindex -fvxt-intrinsics-hide option
2263 @cindex options, -fvxt-intrinsics-hide
2264 @item -fvxt-intrinsics-hide
2265 @cindex -fvxt-intrinsics-disable option
2266 @cindex options, -fvxt-intrinsics-disable
2267 @item -fvxt-intrinsics-disable
2268 @cindex -fvxt-intrinsics-enable option
2269 @cindex options, -fvxt-intrinsics-enable
2270 @item -fvxt-intrinsics-enable
2271 @cindex VXT intrinsics
2272 @cindex intrinsics, VXT
2273 Specify status of VXT intrinsics.
2274 @samp{-fvxt-intrinsics-enable} is the default.
2275 @xref{Intrinsic Groups}.
2277 @cindex -ffixed-line-length-@var{n} option
2278 @cindex options, -ffixed-line-length-@var{n}
2279 @item -ffixed-line-length-@var{n}
2280 @cindex source file format
2281 @cindex lines, length
2282 @cindex length of source lines
2284 @cindex limits, lengths of source lines
2285 Set column after which characters are ignored in typical fixed-form
2286 lines in the source file, and through which spaces are assumed (as
2287 if padded to that length) after the ends of short fixed-form lines.
2290 @cindex extended-source option
2291 Popular values for @var{n} include 72 (the
2292 standard and the default), 80 (card image), and 132 (corresponds
2293 to ``extended-source'' options in some popular compilers).
2294 @var{n} may be @samp{none}, meaning that the entire line is meaningful
2295 and that continued character constants never have implicit spaces appended
2296 to them to fill out the line.
2297 @samp{-ffixed-line-length-0} means the same thing as
2298 @samp{-ffixed-line-length-none}.
2300 @xref{Source Form}, for more information.
2303 @node Warning Options
2304 @section Options to Request or Suppress Warnings
2305 @cindex options, warnings
2306 @cindex warnings, suppressing
2307 @cindex messages, warning
2308 @cindex suppressing warnings
2310 Warnings are diagnostic messages that report constructions which
2311 are not inherently erroneous but which are risky or suggest there
2312 might have been an error.
2314 You can request many specific warnings with options beginning @samp{-W},
2315 for example @samp{-Wimplicit} to request warnings on implicit
2316 declarations. Each of these specific warning options also has a
2317 negative form beginning @samp{-Wno-} to turn off warnings;
2318 for example, @samp{-Wno-implicit}. This manual lists only one of the
2319 two forms, whichever is not the default.
2321 These options control the amount and kinds of warnings produced by GNU
2325 @cindex syntax checking
2326 @cindex -fsyntax-only option
2327 @cindex options, -fsyntax-only
2329 Check the code for syntax errors, but don't do anything beyond that.
2331 @cindex -pedantic option
2332 @cindex options, -pedantic
2334 Issue warnings for uses of extensions to ANSI FORTRAN 77.
2335 @samp{-pedantic} also applies to C-language constructs where they
2336 occur in GNU Fortran source files, such as use of @samp{\e} in a
2337 character constant within a directive like @samp{#include}.
2339 Valid ANSI FORTRAN 77 programs should compile properly with or without
2341 However, without this option, certain GNU extensions and traditional
2342 Fortran features are supported as well.
2343 With this option, many of them are rejected.
2345 Some users try to use @samp{-pedantic} to check programs for strict ANSI
2347 They soon find that it does not do quite what they want---it finds some
2348 non-ANSI practices, but not all.
2349 However, improvements to @code{g77} in this area are welcome.
2351 @cindex -pedantic-errors option
2352 @cindex options, -pedantic-errors
2353 @item -pedantic-errors
2354 Like @samp{-pedantic}, except that errors are produced rather than
2357 @cindex -fpedantic option
2358 @cindex options, -fpedantic
2360 Like @samp{-pedantic}, but applies only to Fortran constructs.
2365 Inhibit all warning messages.
2367 @cindex -Wno-globals option
2368 @cindex options, -Wno-globals
2370 @cindex global names, warning
2371 @cindex warnings, global names
2372 Inhibit warnings about use of a name as both a global name
2373 (a subroutine, function, or block data program unit, or a
2374 common block) and implicitly as the name of an intrinsic
2377 Also inhibit warnings about inconsistent invocations and/or
2378 definitions of global procedures (function and subroutines).
2379 Such inconsistencies include different numbers of arguments
2380 and different types of arguments.
2382 @cindex -Wimplicit option
2383 @cindex options, -Wimplicit
2385 @cindex implicit declaration, warning
2386 @cindex warnings, implicit declaration
2388 @cindex /WARNINGS=DECLARATIONS switch
2389 @cindex IMPLICIT NONE, similar effect
2390 @cindex effecting IMPLICIT NONE
2391 Warn whenever a variable, array, or function is implicitly
2393 Has an effect similar to using the @code{IMPLICIT NONE} statement
2394 in every program unit.
2395 (Some Fortran compilers provide this feature by an option
2396 named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)
2398 @cindex -Wunused option
2399 @cindex options, -Wunused
2401 @cindex unused variables
2402 @cindex variables, unused
2403 Warn whenever a variable is unused aside from its declaration.
2405 @cindex -Wuninitialized option
2406 @cindex options, -Wuninitialized
2407 @item -Wuninitialized
2408 @cindex uninitialized variables
2409 @cindex variables, uninitialized
2410 Warn whenever an automatic variable is used without first being initialized.
2412 These warnings are possible only in optimizing compilation,
2413 because they require data-flow information that is computed only
2414 when optimizing. If you don't specify @samp{-O}, you simply won't
2417 These warnings occur only for variables that are candidates for
2418 register allocation. Therefore, they do not occur for a variable
2419 @c that is declared @code{VOLATILE}, or
2420 whose address is taken, or whose size
2421 is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
2422 arrays, even when they are in registers.
2424 Note that there might be no warning about a variable that is used only
2425 to compute a value that itself is never used, because such
2426 computations may be deleted by data-flow analysis before the warnings
2429 These warnings are made optional because GNU Fortran is not smart
2430 enough to see all the reasons why the code might be correct
2431 despite appearing to have an error. Here is one example of how
2435 SUBROUTINE DISPAT(J)
2444 If the value of @code{J} is always 1, 2 or 3, then @code{I} is
2445 always initialized, but GNU Fortran doesn't know this. Here is
2446 another common case:
2449 SUBROUTINE MAYBE(FLAG)
2451 IF (FLAG) VALUE = 9.4
2453 IF (FLAG) PRINT *, VALUE
2458 This has no bug because @code{VALUE} is used only if it is set.
2460 @cindex -Wall option
2461 @cindex options, -Wall
2463 @cindex all warnings
2464 @cindex warnings, all
2465 The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
2467 options which pertain to usage that we recommend avoiding and that we
2468 believe is easy to avoid.
2469 (As more warnings are added to @code{g77}, some might
2470 be added to the list enabled by @samp{-Wall}.)
2473 The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
2474 because they warn about constructions that we consider reasonable to
2475 use, on occasion, in clean programs.
2479 @c Print extra warning messages for these events:
2483 @c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
2488 @cindex -Wsurprising option
2489 @cindex options, -Wsurprising
2491 Warn about ``suspicious'' constructs that are interpreted
2492 by the compiler in a way that might well be surprising to
2493 someone reading the code.
2494 These differences can result in subtle, compiler-dependent
2495 (even machine-dependent) behavioral differences.
2496 The constructs warned about include:
2500 Expressions having two arithmetic operators in a row, such
2502 Such a construct is nonstandard, and can produce
2503 unexpected results in more complicated situations such
2505 @code{g77}, along with many other compilers, interprets
2506 this example differently than many programmers, and a few
2508 Specifically, @code{g77} interprets @samp{X**-Y*Z} as
2509 @samp{(X**(-Y))*Z}, while others might think it should
2510 be interpreted as @samp{X**(-(Y*Z))}.
2512 A revealing example is the constant expression @samp{2**-2*1.},
2513 which @code{g77} evaluates to .25, while others might evaluate
2514 it to 0., the difference resulting from the way precedence affects
2517 (The @samp{-fpedantic} option also warns about expressions
2518 having two arithmetic operators in a row.)
2521 Expressions with a unary minus followed by an operand and then
2522 a binary operator other than plus or minus.
2523 For example, @samp{-2**2} produces a warning, because
2524 the precedence is @samp{-(2**2)}, yielding -4, not
2525 @samp{(-2)**2}, which yields 4, and which might represent
2526 what a programmer expects.
2528 An example of an expression producing different results
2529 in a surprising way is @samp{-I*S}, where @var{I} holds
2530 the value @samp{-2147483648} and @var{S} holds @samp{0.5}.
2531 On many systems, negating @var{I} results in the same
2532 value, not a positive number, because it is already the
2533 lower bound of what an @code{INTEGER(KIND=1)} variable can hold.
2534 So, the expression evaluates to a positive number, while
2535 the ``expected'' interpretation, @samp{(-I)*S}, would
2536 evaluate to a negative number.
2538 Even cases such as @samp{-I*J} produce warnings,
2539 even though, in most configurations and situations,
2540 there is no computational difference between the
2541 results of the two interpretations---the purpose
2542 of this warning is to warn about differing interpretations
2543 and encourage a better style of coding, not to identify
2544 only those places where bugs might exist in the user's
2547 @cindex DO statement
2548 @cindex statements, DO
2550 @code{DO} loops with @code{DO} variables that are not
2551 of integral type---that is, using @code{REAL}
2552 variables as loop control variables.
2553 Although such loops can be written to work in the
2554 ``obvious'' way, the way @code{g77} is required by the
2555 Fortran standard to interpret such code is likely to
2556 be quite different from the way many programmers expect.
2557 (This is true of all @code{DO} loops, but the differences
2558 are pronounced for non-integral loop control variables.)
2560 @xref{Loops}, for more information.
2563 @cindex -Werror option
2564 @cindex options, -Werror
2566 Make all warnings into errors.
2571 @cindex extra warnings
2572 @cindex warnings, extra
2573 Turns on ``extra warnings'' and, if optimization is specified
2574 via @samp{-O}, the @samp{-Wuninitialized} option.
2575 (This might change in future versions of @code{g77}.)
2577 ``Extra warnings'' are issued for:
2581 @cindex unused parameters
2582 @cindex parameters, unused
2583 @cindex unused arguments
2584 @cindex arguments, unused
2585 @cindex unused dummies
2586 @cindex dummies, unused
2587 Unused parameters to a procedure (when @samp{-Wunused} also is
2592 Overflows involving floating-point constants (not available
2593 for certain configurations).
2597 @xref{Warning Options,,Options to Request or Suppress Warnings,
2598 gcc,Using and Porting GNU CC}, for information on more options offered
2599 by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.
2601 Some of these have no effect when compiling programs written in Fortran:
2604 @cindex -Wcomment option
2605 @cindex options, -Wcomment
2607 @cindex -Wformat option
2608 @cindex options, -Wformat
2610 @cindex -Wparentheses option
2611 @cindex options, -Wparentheses
2613 @cindex -Wswitch option
2614 @cindex options, -Wswitch
2616 @cindex -Wtraditional option
2617 @cindex options, -Wtraditional
2619 @cindex -Wshadow option
2620 @cindex options, -Wshadow
2622 @cindex -Wid-clash-@var{len} option
2623 @cindex options, -Wid-clash-@var{len}
2624 @item -Wid-clash-@var{len}
2625 @cindex -Wlarger-than-@var{len} option
2626 @cindex options, -Wlarger-than-@var{len}
2627 @item -Wlarger-than-@var{len}
2628 @cindex -Wconversion option
2629 @cindex options, -Wconversion
2631 @cindex -Waggregate-return option
2632 @cindex options, -Waggregate-return
2633 @item -Waggregate-return
2634 @cindex -Wredundant-decls option
2635 @cindex options, -Wredundant-decls
2636 @item -Wredundant-decls
2637 @cindex unsupported warnings
2638 @cindex warnings, unsupported
2639 These options all could have some relevant meaning for
2640 GNU Fortran programs, but are not yet supported.
2643 @node Debugging Options
2644 @section Options for Debugging Your Program or GNU Fortran
2645 @cindex options, debugging
2646 @cindex debugging information options
2648 GNU Fortran has various special options that are used for debugging
2649 either your program or @code{g77}.
2655 Produce debugging information in the operating system's native format
2656 (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
2659 @cindex common blocks
2660 @cindex equivalence areas
2661 @cindex missing debug features
2662 Support for this option in Fortran programs was incomplete up till
2663 version 0.5.26 of @code{g77}.
2664 In particular, names of variables and arrays in common blocks
2665 or that are storage-associated via @code{EQUIVALENCE} were
2666 unavailable to the debugger.
2668 However, version 0.5.19 of @code{g77} does provide this information
2669 in a rudimentary way, as controlled by the
2670 @samp{-fdebug-kludge} option.
2672 Because version 0.5.26 of @code{g77} enables full debug information
2673 of COMMON BLOCK and EQUIVALENCE items, this option has been disabled.
2675 @xref{Code Gen Options,,Options for Code Generation Conventions},
2676 for more information.
2679 @xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
2680 gcc,Using and Porting GNU CC}, for more information on debugging options.
2682 @node Optimize Options
2683 @section Options That Control Optimization
2684 @cindex optimize options
2685 @cindex options, optimization
2687 Most Fortran users will want to use no optimization when
2688 developing and testing programs, and use @samp{-O} or @samp{-O2} when
2689 compiling programs for late-cycle testing and for production use.
2690 However, note that certain diagnostics---such as for uninitialized
2691 variables---depend on the flow analysis done by @samp{-O}, i.e.@: you
2692 must use @samp{-O} or @samp{-O2} to get such diagnostics.
2694 The following flags have particular applicability when
2695 compiling Fortran programs:
2698 @cindex -malign-double option
2699 @cindex options, -malign-double
2700 @item -malign-double
2701 (Intel x86 architecture only.)
2703 Noticeably improves performance of @code{g77} programs making
2704 heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data
2706 In particular, systems using Pentium, Pentium Pro, 586, and
2708 of the i386 architecture execute programs faster when
2709 @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data are
2710 aligned on 64-bit boundaries
2713 This option can, at least, make benchmark results more consistent
2714 across various system configurations, versions of the program,
2717 @emph{Note:} The warning in the @code{gcc} documentation about
2718 this option does not apply, generally speaking, to Fortran
2719 code compiled by @code{g77}.
2721 @xref{Aligned Data}, for more information on alignment issues.
2723 @emph{Also also note:} The negative form of @samp{-malign-double}
2724 is @samp{-mno-align-double}, not @samp{-benign-double}.
2726 @cindex -ffloat-store option
2727 @cindex options, -ffloat-store
2729 @cindex IEEE 754 conformance
2730 @cindex conformance, IEEE 754
2731 @cindex floating-point, precision
2732 Might help a Fortran program that depends on exact IEEE conformance on
2733 some machines, but might slow down a program that doesn't.
2735 This option is effective when the floating-point unit is set to work in
2736 IEEE 854 `extended precision'---as it typically is on x86 and m68k GNU
2737 systems---rather than IEEE 754 double precision. @samp{-ffloat-store}
2738 tries to remove the extra precision by spilling data from floating-point
2739 registers into memory and this typically involves a big performance
2740 hit. However, it doesn't affect intermediate results, so that it is
2741 only partially effective. `Excess precision' is avoided in code like:
2746 but not in code like:
2751 For another, potentially better, way of controlling the precision,
2752 see @ref{Floating-point precision}.
2754 @cindex -fforce-mem option
2755 @cindex options, -fforce-mem
2757 @cindex -fforce-addr option
2758 @cindex options, -fforce-addr
2760 @cindex loops, speeding up
2761 @cindex speed, of loops
2762 Might improve optimization of loops.
2764 @cindex -fno-inline option
2765 @cindex options, -fno-inline
2767 @cindex in-line code
2768 @cindex compilation, in-line
2769 @c DL: Only relevant for -O3?
2770 Don't compile statement functions inline.
2771 Might reduce the size of a program unit---which might be at
2772 expense of some speed (though it should compile faster).
2773 Note that if you are not optimizing, no functions can be expanded inline.
2775 @cindex -ffast-math option
2776 @cindex options, -ffast-math
2778 @cindex IEEE 754 conformance
2779 @cindex conformance, IEEE 754
2780 Might allow some programs designed to not be too dependent
2781 on IEEE behavior for floating-point to run faster, or die trying.
2783 @cindex -fstrength-reduce option
2784 @cindex options, -fstrength-reduce
2785 @item -fstrength-reduce
2786 @cindex loops, speeding up
2787 @cindex speed, of loops
2788 @c DL: normally defaulted?
2789 Might make some loops run faster.
2791 @cindex -frerun-cse-after-loop option
2792 @cindex options, -frerun-cse-after-loop
2793 @item -frerun-cse-after-loop
2794 @cindex -fexpensive-optimizations option
2795 @cindex options, -fexpensive-optimizations
2797 @item -fexpensive-optimizations
2798 @cindex -fdelayed-branch option
2799 @cindex options, -fdelayed-branch
2800 @item -fdelayed-branch
2801 @cindex -fschedule-insns option
2802 @cindex options, -fschedule-insns
2803 @item -fschedule-insns
2804 @cindex -fschedule-insns2 option
2805 @cindex options, -fschedule-insns2
2806 @item -fschedule-insns2
2807 @cindex -fcaller-saves option
2808 @cindex options, -fcaller-saves
2809 @item -fcaller-saves
2810 Might improve performance on some code.
2812 @cindex -funroll-loops option
2813 @cindex options, -funroll-loops
2814 @item -funroll-loops
2815 @cindex loops, unrolling
2816 @cindex unrolling loops
2817 @cindex loops, optimizing
2818 @cindex indexed (iterative) @code{DO}
2819 @cindex iterative @code{DO}
2820 @c DL: fixme: Craig doesn't like `indexed' but f95 doesn't seem to
2821 @c provide a suitable term
2822 @c CB: I've decided on `iterative', for the time being, and changed
2823 @c my previous, rather bizarre, use of `imperative' to that
2824 @c (though `precomputed-trip' would be a more precise adjective)
2825 Typically improves performance on code using iterative @code{DO} loops by
2826 unrolling them and is probably generally appropriate for Fortran, though
2827 it is not turned on at any optimization level.
2828 Note that outer loop unrolling isn't done specifically; decisions about
2829 whether to unroll a loop are made on the basis of its instruction count.
2831 @c DL: Fixme: This should obviously go somewhere else...
2832 Also, no `loop discovery'@footnote{@dfn{loop discovery} refers to the
2833 process by which a compiler, or indeed any reader of a program,
2834 determines which portions of the program are more likely to be executed
2835 repeatedly as it is being run. Such discovery typically is done early
2836 when compiling using optimization techniques, so the ``discovered''
2837 loops get more attention---and more run-time resources, such as
2838 registers---from the compiler. It is easy to ``discover'' loops that are
2839 constructed out of looping constructs in the language
2840 (such as Fortran's @code{DO}). For some programs, ``discovering'' loops
2841 constructed out of lower-level constructs (such as @code{IF} and
2842 @code{GOTO}) can lead to generation of more optimal code
2843 than otherwise.} is done, so only loops written with @code{DO}
2844 benefit from loop optimizations, including---but not limited
2845 to---unrolling. Loops written with @code{IF} and @code{GOTO} are not
2846 currently recognized as such. This option unrolls only iterative
2847 @code{DO} loops, not @code{DO WHILE} loops.
2849 @cindex -funroll-all-loops option
2850 @cindex options, -funroll-all-loops
2852 @item -funroll-all-loops
2853 @c DL: Check my understanding of -funroll-all-loops v. -funroll-loops is correct.
2854 Probably improves performance on code using @code{DO WHILE} loops by
2855 unrolling them in addition to iterative @code{DO} loops. In the absence
2856 of @code{DO WHILE}, this option is equivalent to @samp{-funroll-loops}
2857 but possibly slower.
2859 @item -fno-move-all-movables
2860 @cindex -fno-move-all-movables option
2861 @cindex options, -fno-move-all-movables
2862 @item -fno-reduce-all-givs
2863 @cindex -fno-reduce-all-givs option
2864 @cindex options, -fno-reduce-all-givs
2865 @item -fno-rerun-loop-opt
2866 @cindex -fno-rerun-loop-opt option
2867 @cindex options, -fno-rerun-loop-opt
2868 @emph{Version info:}
2869 These options are not supported by
2870 versions of @code{g77} based on @code{gcc} version 2.8.
2872 Each of these might improve performance on some code.
2874 Analysis of Fortran code optimization and the resulting
2875 optimizations triggered by the above options were
2876 contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).
2878 These three options are intended to be removed someday, once
2879 they have helped determine the efficacy of various
2880 approaches to improving the performance of Fortran code.
2882 Please let us know how use of these options affects
2883 the performance of your production code.
2884 We're particularly interested in code that runs faster
2885 when these options are @emph{disabled}, and in
2886 non-Fortran code that benefits when they are
2887 @emph{enabled} via the above @code{gcc} command-line options.
2890 @xref{Optimize Options,,Options That Control Optimization,
2891 gcc,Using and Porting GNU CC}, for more information on options
2892 to optimize the generated machine code.
2894 @node Preprocessor Options
2895 @section Options Controlling the Preprocessor
2896 @cindex preprocessor options
2897 @cindex options, preprocessor
2899 @cindex programs, cpp
2901 These options control the C preprocessor, which is run on each C source
2902 file before actual compilation.
2904 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
2905 gcc,Using and Porting GNU CC}, for information on C preprocessor options.
2907 @cindex INCLUDE directive
2908 @cindex directive, INCLUDE
2909 Some of these options also affect how @code{g77} processes the
2910 @code{INCLUDE} directive.
2911 Since this directive is processed even when preprocessing
2912 is not requested, it is not described in this section.
2913 @xref{Directory Options,,Options for Directory Search}, for
2914 information on how @code{g77} processes the @code{INCLUDE} directive.
2916 However, the @code{INCLUDE} directive does not apply
2917 preprocessing to the contents of the included file itself.
2919 Therefore, any file that contains preprocessor directives
2920 (such as @code{#include}, @code{#define}, and @code{#if})
2921 must be included via the @code{#include} directive, not
2922 via the @code{INCLUDE} directive.
2923 Therefore, any file containing preprocessor directives,
2924 if included, is necessarily included by a file that itself
2925 contains preprocessor directives.
2927 @node Directory Options
2928 @section Options for Directory Search
2929 @cindex directory, options
2930 @cindex options, directory search
2933 These options affect how the @code{cpp} preprocessor searches
2934 for files specified via the @code{#include} directive.
2935 Therefore, when compiling Fortran programs, they are meaningful
2936 when the preprocessor is used.
2938 @cindex INCLUDE directive
2939 @cindex directive, INCLUDE
2940 Some of these options also affect how @code{g77} searches
2941 for files specified via the @code{INCLUDE} directive,
2942 although files included by that directive are not,
2943 themselves, preprocessed.
2948 @cindex options, -I-
2950 @cindex -Idir option
2951 @cindex options, -Idir
2953 @cindex directory, search paths for inclusion
2954 @cindex inclusion, directory search paths for
2955 @cindex search paths, for included files
2956 @cindex paths, search
2957 These affect interpretation of the @code{INCLUDE} directive
2958 (as well as of the @code{#include} directive of the @code{cpp}
2961 Note that @samp{-I@var{dir}} must be specified @emph{without} any
2962 spaces between @samp{-I} and the directory name---that is,
2963 @samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
2964 is rejected by the @code{g77} compiler (though the preprocessor supports
2966 @c this is due to toplev.c's inflexible option processing
2967 Also note that the general behavior of @samp{-I} and
2968 @code{INCLUDE} is pretty much the same as of @samp{-I} with
2969 @code{#include} in the @code{cpp} preprocessor, with regard to
2970 looking for @file{header.gcc} files and other such things.
2972 @xref{Directory Options,,Options for Directory Search,
2973 gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
2976 @node Code Gen Options
2977 @section Options for Code Generation Conventions
2978 @cindex code generation, conventions
2979 @cindex options, code generation
2980 @cindex run-time, options
2982 These machine-independent options control the interface conventions
2983 used in code generation.
2985 Most of them have both positive and negative forms; the negative form
2986 of @samp{-ffoo} would be @samp{-fno-foo}. In the table below, only
2987 one of the forms is listed---the one which is not the default. You
2988 can figure out the other form by either removing @samp{no-} or adding
2992 @cindex -fno-automatic option
2993 @cindex options, -fno-automatic
2994 @item -fno-automatic
2995 @cindex SAVE statement
2996 @cindex statements, SAVE
2997 Treat each program unit as if the @code{SAVE} statement was specified
2998 for every local variable and array referenced in it.
2999 Does not affect common blocks.
3000 (Some Fortran compilers provide this option under
3001 the name @samp{-static}.)
3003 @cindex -finit-local-zero option
3004 @cindex options, -finit-local-zero
3005 @item -finit-local-zero
3006 @cindex DATA statement
3007 @cindex statements, DATA
3008 @cindex initialization, of local variables
3009 @cindex variables, initialization of
3010 @cindex uninitialized variables
3011 @cindex variables, uninitialized
3012 Specify that variables and arrays that are local to a program unit
3013 (not in a common block and not passed as an argument) are to be initialized
3016 Since there is a run-time penalty for initialization of variables
3017 that are not given the @code{SAVE} attribute, it might be a
3018 good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.
3020 @cindex -fno-f2c option
3021 @cindex options, -fno-f2c
3023 @cindex @code{f2c} compatibility
3024 @cindex compatibility, @code{f2c}
3025 Do not generate code designed to be compatible with code generated
3026 by @code{f2c}; use the GNU calling conventions instead.
3028 The @code{f2c} calling conventions require functions that return
3029 type @code{REAL(KIND=1)} to actually return the C type @code{double},
3030 and functions that return type @code{COMPLEX} to return the
3031 values via an extra argument in the calling sequence that points
3032 to where to store the return value.
3033 Under the GNU calling conventions, such functions simply return
3034 their results as they would in GNU C---@code{REAL(KIND=1)} functions
3035 return the C type @code{float}, and @code{COMPLEX} functions
3036 return the GNU C type @code{complex} (or its @code{struct}
3039 This does not affect the generation of code that interfaces with the
3040 @code{libg2c} library.
3042 However, because the @code{libg2c} library uses @code{f2c}
3043 calling conventions, @code{g77} rejects attempts to pass
3044 intrinsics implemented by routines in this library as actual
3045 arguments when @samp{-fno-f2c} is used, to avoid bugs when
3046 they are actually called by code expecting the GNU calling
3047 conventions to work.
3049 For example, @samp{INTRINSIC ABS;CALL FOO(ABS)} is
3050 rejected when @samp{-fno-f2c} is in force.
3051 (Future versions of the @code{g77} run-time library might
3052 offer routines that provide GNU-callable versions of the
3053 routines that implement the @code{f2c}-callable intrinsics
3054 that may be passed as actual arguments, so that
3055 valid programs need not be rejected when @samp{-fno-f2c}
3058 @strong{Caution:} If @samp{-fno-f2c} is used when compiling any
3059 source file used in a program, it must be used when compiling
3060 @emph{all} Fortran source files used in that program.
3062 @c seems kinda dumb to tell people about an option they can't use -- jcb
3063 @c then again, we want users building future-compatible libraries with it.
3064 @cindex -ff2c-library option
3065 @cindex options, -ff2c-library
3067 Specify that use of @code{libg2c} (or the original @code{libf2c})
3069 This is the default for the current version of @code{g77}.
3072 valid to specify @samp{-fno-f2c-library}.
3073 This option is provided so users can specify it in shell
3074 scripts that build programs and libraries that require the
3075 @code{libf2c} library, even when being compiled by future
3076 versions of @code{g77} that might otherwise default to
3077 generating code for an incompatible library.
3079 @cindex -fno-underscoring option
3080 @cindex options, -fno-underscoring
3081 @item -fno-underscoring
3083 @cindex symbol names, underscores
3084 @cindex transforming symbol names
3085 @cindex symbol names, transforming
3086 Do not transform names of entities specified in the Fortran
3087 source file by appending underscores to them.
3089 With @samp{-funderscoring} in effect, @code{g77} appends two underscores
3090 to names with underscores and one underscore to external names with
3091 no underscores. (@code{g77} also appends two underscores to internal
3092 names with underscores to avoid naming collisions with external names.
3093 The @samp{-fno-second-underscore} option disables appending of the
3094 second underscore in all cases.)
3096 This is done to ensure compatibility with code produced by many
3097 UNIX Fortran compilers, including @code{f2c}, which perform the
3098 same transformations.
3100 Use of @samp{-fno-underscoring} is not recommended unless you are
3101 experimenting with issues such as integration of (GNU) Fortran into
3102 existing system environments (vis-a-vis existing libraries, tools, and
3105 For example, with @samp{-funderscoring}, and assuming other defaults like
3106 @samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
3107 external functions while @samp{my_var} and @samp{lvar} are local variables,
3111 I = J() + MAX_COUNT (MY_VAR, LVAR)
3115 is implemented as something akin to:
3118 i = j_() + max_count__(&my_var__, &lvar);
3121 With @samp{-fno-underscoring}, the same statement is implemented as:
3124 i = j() + max_count(&my_var, &lvar);
3127 Use of @samp{-fno-underscoring} allows direct specification of
3128 user-defined names while debugging and when interfacing @code{g77}-compiled
3129 code with other languages.
3131 Note that just because the names match does @emph{not} mean that the
3132 interface implemented by @code{g77} for an external name matches the
3133 interface implemented by some other language for that same name.
3134 That is, getting code produced by @code{g77} to link to code produced
3135 by some other compiler using this or any other method can be only a
3136 small part of the overall solution---getting the code generated by
3137 both compilers to agree on issues other than naming can require
3138 significant effort, and, unlike naming disagreements, linkers normally
3139 cannot detect disagreements in these other areas.
3141 Also, note that with @samp{-fno-underscoring}, the lack of appended
3142 underscores introduces the very real possibility that a user-defined
3143 external name will conflict with a name in a system library, which
3144 could make finding unresolved-reference bugs quite difficult in some
3145 cases---they might occur at program run time, and show up only as
3146 buggy behavior at run time.
3148 In future versions of @code{g77}, we hope to improve naming and linking
3149 issues so that debugging always involves using the names as they appear
3150 in the source, even if the names as seen by the linker are mangled to
3151 prevent accidental linking between procedures with incompatible
3154 @cindex -fno-second-underscore option
3155 @cindex options, -fno-second-underscore
3156 @item -fno-second-underscore
3158 @cindex symbol names, underscores
3159 @cindex transforming symbol names
3160 @cindex symbol names, transforming
3161 Do not append a second underscore to names of entities specified
3162 in the Fortran source file.
3164 This option has no effect if @samp{-fno-underscoring} is
3167 Otherwise, with this option, an external name such as @samp{MAX_COUNT}
3168 is implemented as a reference to the link-time external symbol
3169 @samp{max_count_}, instead of @samp{max_count__}.
3171 @cindex -fno-ident option
3172 @cindex options, -fno-ident
3174 Ignore the @samp{#ident} directive.
3176 @cindex -fzeros option
3177 @cindex options, -fzeros
3179 Treat initial values of zero as if they were any other value.
3181 As of version 0.5.18, @code{g77} normally treats @code{DATA} and
3182 other statements that are used to specify initial values of zero
3183 for variables and arrays as if no values were actually specified,
3184 in the sense that no diagnostics regarding multiple initializations
3187 This is done to speed up compiling of programs that initialize
3188 large arrays to zeros.
3190 Use @samp{-fzeros} to revert to the simpler, slower behavior
3191 that can catch multiple initializations by keeping track of
3192 all initializations, zero or otherwise.
3194 @emph{Caution:} Future versions of @code{g77} might disregard this option
3195 (and its negative form, the default) or interpret it somewhat
3197 The interpretation changes will affect only non-standard
3198 programs; standard-conforming programs should not be affected.
3200 @cindex -fdebug-kludge option
3201 @cindex options, -fdebug-kludge
3202 @item -fdebug-kludge
3203 Emit information on @code{COMMON} and @code{EQUIVALENCE} members
3204 that might help users of debuggers work around lack of proper debugging
3205 information on such members.
3207 As of version 0.5.19, @code{g77} offers this option to emit
3208 information on members of aggregate areas to help users while debugging.
3209 This information consists of establishing the type and contents of each
3210 such member so that, when a debugger is asked to print the contents,
3211 the printed information provides rudimentary debugging information.
3212 This information identifies the name of the aggregate area (either the
3213 @code{COMMON} block name, or the @code{g77}-assigned name for the
3214 @code{EQUIVALENCE} name) and the offset, in bytes, of the member from
3215 the beginning of the area.
3217 Using @code{gdb}, this information is not coherently displayed in the Fortran
3218 language mode, so temporarily switching to the C language mode to display the
3219 information is suggested.
3220 Use @samp{set language c} and @samp{set language fortran} to accomplish this.
3222 As of version 0.5.26 of @code{g77} this option has been disabled, as the
3223 compiler is now able to emit correct and complete debug information
3224 for COMMON BLOCK and EQUIVALENCE items.
3232 EQUIVALENCE (I,XX(20:20))
3235 GDB is free software and you are welcome to distribute copies of it
3236 under certain conditions; type "show copying" to see the conditions.
3237 There is absolutely no warranty for GDB; type "show warranty" for details.
3238 GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
3240 Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
3242 Starting program: /home/user/a.out
3244 Breakpoint 1, MAIN__ () at cd.f:5
3245 Current language: auto; currently fortran
3246 (gdb) set language c
3247 Warning: the current language does not match this frame.
3249 $2 = "At (COMMON) `x_' plus 0 bytes"
3251 $3 = "At (COMMON) `x_' plus 4 bytes"
3253 $4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3255 $5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3257 $6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
3259 $7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
3260 (gdb) set language fortran
3265 Use @samp{-fdebug-kludge} to generate this information,
3266 which might make some programs noticeably larger.
3268 @emph{Caution:} Future versions of @code{g77} might disregard this option
3269 (and its negative form).
3270 Current plans call for this to happen when published versions of @code{g77}
3271 and @code{gdb} exist that provide proper access to debugging information on
3272 @code{COMMON} and @code{EQUIVALENCE} members. This is believed to have
3273 happened as of version 0.5.26 of @code{g77}, so that this option has been
3274 disabled starting with this release.
3276 @cindex -femulate-complex option
3277 @cindex options, -femulate-complex
3278 @item -femulate-complex
3279 Implement @code{COMPLEX} arithmetic via emulation,
3280 instead of using the facilities of
3281 the @code{gcc} back end that provide direct support of
3282 @code{complex} arithmetic.
3284 (@code{gcc} had some bugs in its back-end support
3285 for @code{complex} arithmetic, due primarily to the support not being
3286 completed as of version 2.8.1 and @code{egcs} 1.1.2.)
3288 Use @samp{-femulate-complex} if you suspect code-generation bugs,
3289 or experience compiler crashes,
3290 that might result from @code{g77} using the @code{COMPLEX} support
3291 in the @code{gcc} back end.
3292 If using that option fixes the bugs or crashes you are seeing,
3293 that indicates a likely @code{g77} bugs
3294 (though, all compiler crashes are considered bugs),
3295 so, please report it.
3296 (Note that the known bugs, now believed fixed, produced compiler crashes
3297 rather than causing the generation of incorrect code.)
3299 Use of this option should not affect how Fortran code compiled
3300 by @code{g77} works in terms of its interfaces to other code,
3301 e.g. that compiled by @code{f2c}.
3303 @emph{Caution:} Future versions of @code{g77} might ignore both forms
3306 @cindex -falias-check option
3307 @cindex options, -falias-check
3308 @cindex -fargument-alias option
3309 @cindex options, -fargument-alias
3310 @cindex -fargument-noalias option
3311 @cindex options, -fargument-noalias
3312 @cindex -fno-argument-noalias-global option
3313 @cindex options, -fno-argument-noalias-global
3315 @item -fargument-alias
3316 @item -fargument-noalias
3317 @item -fno-argument-noalias-global
3318 @emph{Version info:}
3319 These options are not supported by
3320 versions of @code{g77} based on @code{gcc} version 2.8.
3322 These options specify to what degree aliasing
3324 is permitted between
3325 arguments (passed as pointers) and @code{COMMON} (external, or
3328 The default for Fortran code, as mandated by the FORTRAN 77 and
3329 Fortran 90 standards, is @samp{-fargument-noalias-global}.
3330 The default for code written in the C language family is
3331 @samp{-fargument-alias}.
3333 Note that, on some systems, compiling with @samp{-fforce-addr} in
3334 effect can produce more optimal code when the default aliasing
3335 options are in effect (and when optimization is enabled).
3337 @xref{Aliasing Assumed To Work}, for detailed information on the implications
3338 of compiling Fortran code that depends on the ability to alias dummy
3341 @cindex -fno-globals option
3342 @cindex options, -fno-globals
3344 @cindex global names, warning
3345 @cindex warnings, global names
3346 @cindex in-line code
3347 @cindex compilation, in-line
3348 Disable diagnostics about inter-procedural
3349 analysis problems, such as disagreements about the
3350 type of a function or a procedure's argument,
3351 that might cause a compiler crash when attempting
3352 to inline a reference to a procedure within a
3354 (The diagnostics themselves are still produced, but
3355 as warnings, unless @samp{-Wno-globals} is specified,
3356 in which case no relevant diagnostics are produced.)
3358 Further, this option disables such inlining, to
3359 avoid compiler crashes resulting from incorrect
3360 code that would otherwise be diagnosed.
3362 As such, this option might be quite useful when
3363 compiling existing, ``working'' code that happens
3364 to have a few bugs that do not generally show themselves,
3365 but which @code{g77} diagnoses.
3367 Use of this option therefore has the effect of
3368 instructing @code{g77} to behave more like it did
3369 up through version 0.5.19.1, when it paid little or
3370 no attention to disagreements between program units
3371 about a procedure's type and argument information,
3372 and when it performed no inlining of procedures
3373 (except statement functions).
3375 Without this option, @code{g77} defaults to performing
3376 the potentially inlining procedures as it started doing
3377 in version 0.5.20, but as of version 0.5.21, it also
3378 diagnoses disagreements that might cause such inlining
3379 to crash the compiler as (fatal) errors,
3380 and warns about similar disagreements
3381 that are currently believed to not
3382 likely to result in the compiler later crashing
3383 or producing incorrect code.
3385 @cindex -fflatten-arrays option
3386 @item -fflatten-arrays
3387 @cindex array performance
3388 @cindex arrays, flattening
3389 Use back end's C-like constructs
3390 (pointer plus offset)
3391 instead of its @code{ARRAY_REF} construct
3392 to handle all array references.
3394 @emph{Note:} This option is not supported.
3395 It is intended for use only by @code{g77} developers,
3396 to evaluate code-generation issues.
3397 It might be removed at any time.
3399 @cindex -fbounds-check option
3400 @cindex -ffortran-bounds-check option
3401 @item -fbounds-check
3402 @itemx -ffortran-bounds-check
3403 @cindex bounds checking
3404 @cindex range checking
3405 @cindex array bounds checking
3406 @cindex subscript checking
3407 @cindex substring checking
3408 @cindex checking subscripts
3409 @cindex checking substrings
3410 Enable generation of run-time checks for array subscripts
3411 and substring start and end points
3412 against the (locally) declared minimum and maximum values.
3414 The current implementation uses the @code{libf2c}
3415 library routine @code{s_rnge} to print the diagnostic.
3417 However, whereas @code{f2c} generates a single check per
3418 reference for a multi-dimensional array, of the computed
3419 offset against the valid offset range (0 through the size of the array),
3420 @code{g77} generates a single check per @emph{subscript} expression.
3421 This catches some cases of potential bugs that @code{f2c} does not,
3422 such as references to below the beginning of an assumed-size array.
3424 @code{g77} also generates checks for @code{CHARACTER} substring references,
3425 something @code{f2c} currently does not do.
3427 Use the new @samp{-ffortran-bounds-check} option
3428 to specify bounds-checking for only the Fortran code you are compiling,
3429 not necessarily for code written in other languages.
3431 @emph{Note:} To provide more detailed information on the offending subscript,
3432 @code{g77} provides the @code{libg2c} run-time library routine @code{s_rnge}
3433 with somewhat differently-formatted information.
3434 Here's a sample diagnostic:
3437 Subscript out of range on file line 4, procedure rnge.f/bf.
3438 Attempt to access the -6-th element of variable b[subscript-2-of-2].
3442 The above message indicates that the offending source line is
3443 line 4 of the file @file{rnge.f},
3444 within the program unit (or statement function) named @samp{bf}.
3445 The offended array is named @samp{b}.
3446 The offended array dimension is the second for a two-dimensional array,
3447 and the offending, computed subscript expression was @samp{-6}.
3449 For a @code{CHARACTER} substring reference, the second line has
3453 Attempt to access the 11-th element of variable a[start-substring].
3456 This indicates that the offended @code{CHARACTER} variable or array
3458 the offended substring position is the starting (leftmost) position,
3459 and the offending substring expression is @samp{11}.
3461 (Though the verbage of @code{s_rnge} is not ideal
3462 for the purpose of the @code{g77} compiler,
3463 the above information should provide adequate diagnostic abilities
3467 @xref{Code Gen Options,,Options for Code Generation Conventions,
3468 gcc,Using and Porting GNU CC}, for information on more options
3470 shared by @code{g77}, @code{gcc}, and other GNU compilers.
3472 Some of these do @emph{not} work when compiling programs written in Fortran:
3475 @cindex -fpcc-struct-return option
3476 @cindex options, -fpcc-struct-return
3477 @item -fpcc-struct-return
3478 @cindex -freg-struct-return option
3479 @cindex options, -freg-struct-return
3480 @item -freg-struct-return
3481 You should not use these except strictly the same way as you
3482 used them to build the version of @code{libg2c} with which
3483 you will be linking all code compiled by @code{g77} with the
3486 @cindex -fshort-double option
3487 @cindex options, -fshort-double
3488 @item -fshort-double
3489 This probably either has no effect on Fortran programs, or
3490 makes them act loopy.
3492 @cindex -fno-common option
3493 @cindex options, -fno-common
3495 Do not use this when compiling Fortran programs,
3496 or there will be Trouble.
3498 @cindex -fpack-struct option
3499 @cindex options, -fpack-struct
3501 This probably will break any calls to the @code{libg2c} library,
3502 at the very least, even if it is built with the same option.
3505 @node Environment Variables
3506 @section Environment Variables Affecting GNU Fortran
3507 @cindex environment variables
3509 GNU Fortran currently does not make use of any environment
3510 variables to control its operation above and beyond those
3511 that affect the operation of @code{gcc}.
3513 @xref{Environment Variables,,Environment Variables Affecting GNU CC,
3514 gcc,Using and Porting GNU CC}, for information on environment
3524 @chapter The GNU Fortran Language
3526 @cindex standard, ANSI FORTRAN 77
3527 @cindex ANSI FORTRAN 77 standard
3528 @cindex reference works
3529 GNU Fortran supports a variety of extensions to, and dialects
3530 of, the Fortran language.
3531 Its primary base is the ANSI FORTRAN 77 standard, currently available on
3533 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
3534 or as monolithic text at
3535 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
3536 It offers some extensions that are popular among users
3537 of UNIX @code{f77} and @code{f2c} compilers, some that
3538 are popular among users of other compilers (such as Digital
3539 products), some that are popular among users of the
3540 newer Fortran 90 standard, and some that are introduced
3544 (If you need a text on Fortran,
3545 a few freely available electronic references have pointers from
3546 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
3547 net project', @cite{User Notes on Fortran Programming} at
3548 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
3549 material might not apply specifically to @code{g77}.)
3551 Part of what defines a particular implementation of a Fortran
3552 system, such as @code{g77}, is the particular characteristics
3553 of how it supports types, constants, and so on.
3554 Much of this is left up to the implementation by the various
3555 Fortran standards and accepted practice in the industry.
3557 The GNU Fortran @emph{language} is described below.
3558 Much of the material is organized along the same lines
3559 as the ANSI FORTRAN 77 standard itself.
3561 @xref{Other Dialects}, for information on features @code{g77} supports
3562 that are not part of the GNU Fortran language.
3564 @emph{Note}: This portion of the documentation definitely needs a lot
3568 Relationship to the ANSI FORTRAN 77 standard:
3569 * Direction of Language Development:: Where GNU Fortran is headed.
3570 * Standard Support:: Degree of support for the standard.
3572 Extensions to the ANSI FORTRAN 77 standard:
3575 * Terms and Concepts::
3576 * Characters Lines Sequence::
3577 * Data Types and Constants::
3579 * Specification Statements::
3580 * Control Statements::
3581 * Functions and Subroutines::
3582 * Scope and Classes of Names::
3584 * Fortran 90 Features::
3587 @node Direction of Language Development
3588 @section Direction of Language Development
3589 @cindex direction of language development
3590 @cindex features, language
3591 @cindex language, features
3593 The purpose of the following description of the GNU Fortran
3594 language is to promote wide portability of GNU Fortran programs.
3596 GNU Fortran is an evolving language, due to the
3597 fact that @code{g77} itself is in beta test.
3598 Some current features of the language might later
3599 be redefined as dialects of Fortran supported by @code{g77}
3600 when better ways to express these features are added to @code{g77},
3602 Such features would still be supported by
3603 @code{g77}, but would be available only when
3604 one or more command-line options were used.
3606 The GNU Fortran @emph{language} is distinct from the
3607 GNU Fortran @emph{compilation system} (@code{g77}).
3609 For example, @code{g77} supports various dialects of
3610 Fortran---in a sense, these are languages other than
3611 GNU Fortran---though its primary
3612 purpose is to support the GNU Fortran language, which also is
3613 described in its documentation and by its implementation.
3615 On the other hand, non-GNU compilers might offer
3616 support for the GNU Fortran language, and are encouraged
3619 Currently, the GNU Fortran language is a fairly fuzzy object.
3620 It represents something of a cross between what @code{g77} accepts
3621 when compiling using the prevailing defaults and what this
3622 document describes as being part of the language.
3624 Future versions of @code{g77} are expected to clarify the
3625 definition of the language in the documentation.
3626 Often, this will mean adding new features to the language, in the form
3627 of both new documentation and new support in @code{g77}.
3628 However, it might occasionally mean removing a feature
3629 from the language itself to ``dialect'' status.
3630 In such a case, the documentation would be adjusted
3631 to reflect the change, and @code{g77} itself would likely be changed
3632 to require one or more command-line options to continue supporting
3635 The development of the GNU Fortran language is intended to strike
3640 Serving as a mostly-upwards-compatible language from the
3641 de facto UNIX Fortran dialect as supported by @code{f77}.
3644 Offering new, well-designed language features.
3645 Attributes of such features include
3646 not making existing code any harder to read
3647 (for those who might be unaware that the new
3648 features are not in use) and
3649 not making state-of-the-art
3650 compilers take longer to issue diagnostics,
3654 Supporting existing, well-written code without gratuitously
3655 rejecting non-standard constructs, regardless of the origin
3656 of the code (its dialect).
3659 Offering default behavior and command-line options to reduce
3660 and, where reasonable, eliminate the need for programmers to make
3661 any modifications to code that already works in existing
3662 production environments.
3665 Diagnosing constructs that have different meanings in different
3666 systems, languages, and dialects, while offering clear,
3667 less ambiguous ways to express each of the different meanings
3668 so programmers can change their code appropriately.
3671 One of the biggest practical challenges for the developers of the
3672 GNU Fortran language is meeting the sometimes contradictory demands
3675 For example, a feature might be widely used in one popular environment,
3676 but the exact same code that utilizes that feature might not work
3677 as expected---perhaps it might mean something entirely different---in
3678 another popular environment.
3680 Traditionally, Fortran compilers---even portable ones---have solved this
3681 problem by simply offering the appropriate feature to users of
3682 the respective systems.
3683 This approach treats users of various Fortran systems and dialects
3684 as remote ``islands'', or camps, of programmers, and assume that these
3685 camps rarely come into contact with each other (or,
3686 especially, with each other's code).
3688 Project GNU takes a radically different approach to software and language
3689 design, in that it assumes that users of GNU software do not necessarily
3690 care what kind of underlying system they are using, regardless
3691 of whether they are using software (at the user-interface
3692 level) or writing it (for example, writing Fortran or C code).
3694 As such, GNU users rarely need consider just what kind of underlying
3695 hardware (or, in many cases, operating system) they are using at any
3697 They can use and write software designed for a general-purpose,
3698 widely portable, heterogenous environment---the GNU environment.
3700 In line with this philosophy, GNU Fortran must evolve into a product
3701 that is widely ported and portable not only in the sense that it can
3702 be successfully built, installed, and run by users, but in the larger
3703 sense that its users can use it in the same way, and expect largely the
3704 same behaviors from it, regardless of the kind of system they are using
3705 at any particular time.
3707 This approach constrains the solutions @code{g77} can use to resolve
3708 conflicts between various camps of Fortran users.
3709 If these two camps disagree about what a particular construct should
3710 mean, @code{g77} cannot simply be changed to treat that particular construct as
3711 having one meaning without comment (such as a warning), lest the users
3712 expecting it to have the other meaning are unpleasantly surprised that
3713 their code misbehaves when executed.
3715 The use of the ASCII backslash character in character constants is
3716 an excellent (and still somewhat unresolved) example of this kind of
3718 @xref{Backslash in Constants}.
3719 Other examples are likely to arise in the future, as @code{g77} developers
3720 strive to improve its ability to accept an ever-wider variety of existing
3721 Fortran code without requiring significant modifications to said code.
3723 Development of GNU Fortran is further constrained by the desire
3724 to avoid requiring programmers to change their code.
3725 This is important because it allows programmers, administrators,
3726 and others to more faithfully evaluate and validate @code{g77}
3727 (as an overall product and as new versions are distributed)
3728 without having to support multiple versions of their programs
3729 so that they continue to work the same way on their existing
3730 systems (non-GNU perhaps, but possibly also earlier versions
3733 @node Standard Support
3734 @section ANSI FORTRAN 77 Standard Support
3735 @cindex ANSI FORTRAN 77 support
3736 @cindex standard, support for
3737 @cindex support, FORTRAN 77
3738 @cindex compatibility, FORTRAN 77
3739 @cindex FORTRAN 77 compatibility
3741 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
3742 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
3743 support are those that are probably rarely used in actual code,
3744 some of which are explicitly disallowed by the Fortran 90 standard.
3747 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
3748 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
3749 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
3750 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
3753 @node No Passing External Assumed-length
3754 @subsection No Passing External Assumed-length
3756 @code{g77} disallows passing of an external procedure
3757 as an actual argument if the procedure's
3758 type is declared @code{CHARACTER*(*)}. For example:
3768 It isn't clear whether the standard considers this conforming.
3770 @node No Passing Dummy Assumed-length
3771 @subsection No Passing Dummy Assumed-length
3773 @code{g77} disallows passing of a dummy procedure
3774 as an actual argument if the procedure's
3775 type is declared @code{CHARACTER*(*)}.
3778 SUBROUTINE BAR(CFUNC)
3786 It isn't clear whether the standard considers this conforming.
3788 @node No Pathological Implied-DO
3789 @subsection No Pathological Implied-DO
3791 The @code{DO} variable for an implied-@code{DO} construct in a
3792 @code{DATA} statement may not be used as the @code{DO} variable
3793 for an outer implied-@code{DO} construct. For example, this
3794 fragment is disallowed by @code{g77}:
3797 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
3801 This also is disallowed by Fortran 90, as it offers no additional
3802 capabilities and would have a variety of possible meanings.
3804 Note that it is @emph{very} unlikely that any production Fortran code
3805 tries to use this unsupported construct.
3807 @node No Useless Implied-DO
3808 @subsection No Useless Implied-DO
3810 An array element initializer in an implied-@code{DO} construct in a
3811 @code{DATA} statement must contain at least one reference to the @code{DO}
3812 variables of each outer implied-@code{DO} construct. For example,
3813 this fragment is disallowed by @code{g77}:
3816 DATA (A, I= 1, 1) /1./
3820 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
3821 requirements offer no additional capabilities.
3822 However, @code{g77} doesn't necessarily diagnose all cases
3823 where this requirement is not met.
3825 Note that it is @emph{very} unlikely that any production Fortran code
3826 tries to use this unsupported construct.
3829 @section Conformance
3831 (The following information augments or overrides the information in
3832 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3834 Chapter 1 of that document otherwise serves as the basis
3835 for the relevant aspects of GNU Fortran.)
3837 The definition of the GNU Fortran language is akin to that of
3838 the ANSI FORTRAN 77 language in that it does not generally require
3839 conforming implementations to diagnose cases where programs do
3840 not conform to the language.
3842 However, @code{g77} as a compiler is being developed in a way that
3843 is intended to enable it to diagnose such cases in an easy-to-understand
3846 A program that conforms to the GNU Fortran language should, when
3847 compiled, linked, and executed using a properly installed @code{g77}
3848 system, perform as described by the GNU Fortran language definition.
3849 Reasons for different behavior include, among others:
3853 Use of resources (memory---heap, stack, and so on; disk space; CPU
3854 time; etc.) exceeds those of the system.
3857 Range and/or precision of calculations required by the program
3858 exceeds that of the system.
3861 Excessive reliance on behaviors that are system-dependent
3862 (non-portable Fortran code).
3865 Bugs in the program.
3874 Despite these ``loopholes'', the availability of a clear specification
3875 of the language of programs submitted to @code{g77}, as this document
3876 is intended to provide, is considered an important aspect of providing
3877 a robust, clean, predictable Fortran implementation.
3879 The definition of the GNU Fortran language, while having no special
3880 legal status, can therefore be viewed as a sort of contract, or agreement.
3881 This agreement says, in essence, ``if you write a program in this language,
3882 and run it in an environment (such as a @code{g77} system) that supports
3883 this language, the program should behave in a largely predictable way''.
3886 @section Notation Used in This Chapter
3888 (The following information augments or overrides the information in
3889 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3891 Chapter 1 of that document otherwise serves as the basis
3892 for the relevant aspects of GNU Fortran.)
3894 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
3895 and ``must not'' and ``may not'' denote prohibition.
3896 Terms such as ``might'', ``should'', and ``can'' generally add little or
3897 nothing in the way of weight to the GNU Fortran language itself,
3898 but are used to explain or illustrate the language.
3903 ``The @code{FROBNITZ} statement must precede all executable
3904 statements in a program unit, and may not specify any dummy
3905 arguments. It may specify local or common variables and arrays.
3906 Its use should be limited to portions of the program designed to
3907 be non-portable and system-specific, because it might cause the
3908 containing program unit to behave quite differently on different
3912 Insofar as the GNU Fortran language is specified,
3913 the requirements and permissions denoted by the above sample statement
3914 are limited to the placement of the statement and the kinds of
3915 things it may specify.
3916 The rest of the statement---the content regarding non-portable portions
3917 of the program and the differing behavior of program units containing
3918 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
3920 That content offers advice and warnings about the @code{FROBNITZ}
3923 @emph{Remember:} The GNU Fortran language definition specifies
3924 both what constitutes a valid GNU Fortran program and how,
3925 given such a program, a valid GNU Fortran implementation is
3926 to interpret that program.
3928 It is @emph{not} incumbent upon a valid GNU Fortran implementation
3929 to behave in any particular way, any consistent way, or any
3930 predictable way when it is asked to interpret input that is
3931 @emph{not} a valid GNU Fortran program.
3933 Such input is said to have @dfn{undefined} behavior when
3934 interpreted by a valid GNU Fortran implementation, though
3935 an implementation may choose to specify behaviors for some
3936 cases of inputs that are not valid GNU Fortran programs.
3938 Other notation used herein is that of the GNU texinfo format,
3939 which is used to generate printed hardcopy, on-line hypertext
3940 (Info), and on-line HTML versions, all from a single source
3942 This notation is used as follows:
3946 Keywords defined by the GNU Fortran language are shown
3947 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
3950 Note that, in practice, many Fortran programs are written
3951 in lowercase---uppercase is used in this manual as a
3952 means to readily distinguish keywords and sample Fortran-related
3953 text from the prose in this document.
3956 Portions of actual sample program, input, or output text
3957 look like this: @samp{Actual program text}.
3959 Generally, uppercase is used for all Fortran-specific and
3960 Fortran-related text, though this does not always include
3961 literal text within Fortran code.
3963 For example: @samp{PRINT *, 'My name is Bob'}.
3966 A metasyntactic variable---that is, a name used in this document
3967 to serve as a placeholder for whatever text is used by the
3968 user or programmer---appears as shown in the following example:
3970 ``The @code{INTEGER @var{ivar}} statement specifies that
3971 @var{ivar} is a variable or array of type @code{INTEGER}.''
3973 In the above example, any valid text may be substituted for
3974 the metasyntactic variable @var{ivar} to make the statement
3975 apply to a specific instance, as long as the same text is
3976 substituted for @emph{both} occurrences of @var{ivar}.
3979 Ellipses (``@dots{}'') are used to indicate further text that
3980 is either unimportant or expanded upon further, elsewhere.
3983 Names of data types are in the style of Fortran 90, in most
3986 @xref{Kind Notation}, for information on the relationship
3987 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
3988 and the more traditional, less portably concise nomenclature
3989 (such as @code{INTEGER*4}).
3992 @node Terms and Concepts
3993 @section Fortran Terms and Concepts
3995 (The following information augments or overrides the information in
3996 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3998 Chapter 2 of that document otherwise serves as the basis
3999 for the relevant aspects of GNU Fortran.)
4003 * Statements Comments Lines::
4004 * Scope of Names and Labels::
4007 @node Syntactic Items
4008 @subsection Syntactic Items
4010 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
4012 @cindex limits, lengths of names
4013 In GNU Fortran, a symbolic name is at least one character long,
4014 and has no arbitrary upper limit on length.
4015 However, names of entities requiring external linkage (such as
4016 external functions, external subroutines, and @code{COMMON} areas)
4017 might be restricted to some arbitrary length by the system.
4018 Such a restriction is no more constrained than that of one
4019 through six characters.
4021 Underscores (@samp{_}) are accepted in symbol names after the first
4022 character (which must be a letter).
4024 @node Statements Comments Lines
4025 @subsection Statements, Comments, and Lines
4027 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
4029 @cindex trailing comment
4031 @cindex characters, comment
4033 @cindex exclamation point
4034 @cindex continuation character
4035 @cindex characters, continuation
4036 Use of an exclamation point (@samp{!}) to begin a
4037 trailing comment (a comment that extends to the end of the same
4038 source line) is permitted under the following conditions:
4042 The exclamation point does not appear in column 6.
4043 Otherwise, it is treated as an indicator of a continuation
4047 The exclamation point appears outside a character or Hollerith
4049 Otherwise, the exclamation point is considered part of the
4053 The exclamation point appears to the left of any other possible
4055 That is, a trailing comment may contain exclamation points
4056 in their commentary text.
4061 @cindex statements, separated by semicolon
4062 Use of a semicolon (@samp{;}) as a statement separator
4063 is permitted under the following conditions:
4067 The semicolon appears outside a character or Hollerith
4069 Otherwise, the semicolon is considered part of the
4073 The semicolon appears to the left of a trailing comment.
4074 Otherwise, the semicolon is considered part of that
4078 Neither a logical @code{IF} statement nor a non-construct
4079 @code{WHERE} statement (a Fortran 90 feature) may be
4080 followed (in the same, possibly continued, line) by
4081 a semicolon used as a statement separator.
4083 This restriction avoids the confusion
4084 that can result when reading a line such as:
4087 IF (VALIDP) CALL FOO; CALL BAR
4091 Some readers might think the @samp{CALL BAR} is executed
4092 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4093 assume its execution is unconditional.
4095 (At present, @code{g77} does not diagnose code that
4096 violates this restriction.)
4099 @node Scope of Names and Labels
4100 @subsection Scope of Symbolic Names and Statement Labels
4103 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4105 Included in the list of entities that have a scope of a
4106 program unit are construct names (a Fortran 90 feature).
4107 @xref{Construct Names}, for more information.
4109 @node Characters Lines Sequence
4110 @section Characters, Lines, and Execution Sequence
4112 (The following information augments or overrides the information in
4113 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4115 Chapter 3 of that document otherwise serves as the basis
4116 for the relevant aspects of GNU Fortran.)
4121 * Continuation Line::
4123 * Statement Labels::
4126 * Cpp-style directives::
4130 @subsection GNU Fortran Character Set
4133 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4135 Letters include uppercase letters (the twenty-six characters
4136 of the English alphabet) and lowercase letters (their lowercase
4138 Generally, lowercase letters may be used in place of uppercase
4139 letters, though in character and Hollerith constants, they
4142 Special characters include:
4148 Semicolon (@samp{;})
4152 @cindex exclamation point
4153 Exclamation point (@samp{!})
4157 @cindex double quote
4158 Double quote (@samp{"})
4163 Backslash (@samp{\})
4167 @cindex question mark
4168 Question mark (@samp{?})
4174 Hash mark (@samp{#})
4179 Ampersand (@samp{&})
4183 @cindex percent sign
4184 Percent sign (@samp{%})
4189 Underscore (@samp{_})
4195 @cindex open bracket
4196 @cindex left bracket
4197 Open angle (@samp{<})
4203 @cindex close bracket
4204 @cindex right bracket
4205 Close angle (@samp{>})
4208 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4209 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4210 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4217 Note that this document refers to @key{SPC} as @dfn{space},
4218 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4223 @cindex source file format
4224 @cindex source format
4225 @cindex file, source
4227 @cindex code, source
4231 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4233 The way a Fortran compiler views source files depends entirely on the
4234 implementation choices made for the compiler, since those choices
4235 are explicitly left to the implementation by the published Fortran
4238 The GNU Fortran language mandates a view applicable to UNIX-like
4239 text files---files that are made up of an arbitrary number of lines,
4240 each with an arbitrary number of characters (sometimes called stream-based
4243 This view does not apply to types of files that are specified as
4244 having a particular number of characters on every single line (sometimes
4245 referred to as record-based files).
4247 Because a ``line in a program unit is a sequence of 72 characters'',
4248 to quote X3.9-1978, the GNU Fortran language specifies that a
4249 stream-based text file is translated to GNU Fortran lines as follows:
4253 A newline in the file is the character that represents the end of
4254 a line of text to the underlying system.
4255 For example, on ASCII-based systems, a newline is the @key{NL}
4256 character, which has ASCII value 10 (decimal).
4259 Each newline in the file serves to end the line of text that precedes
4260 it (and that does not contain a newline).
4263 The end-of-file marker (@code{EOF}) also serves to end the line
4264 of text that precedes it (and that does not contain a newline).
4270 Any line of text that is shorter than 72 characters is padded to that length
4271 with spaces (called ``blanks'' in the standard).
4274 Any line of text that is longer than 72 characters is truncated to that
4275 length, but the truncated remainder must consist entirely of spaces.
4278 Characters other than newline and the GNU Fortran character set
4282 For the purposes of the remainder of this description of the GNU
4283 Fortran language, the translation described above has already
4284 taken place, unless otherwise specified.
4286 The result of the above translation is that the source file appears,
4287 in terms of the remainder of this description of the GNU Fortran language,
4288 as if it had an arbitrary
4289 number of 72-character lines, each character being among the GNU Fortran
4292 For example, if the source file itself has two newlines in a row,
4293 the second newline becomes, after the above translation, a single
4294 line containing 72 spaces.
4296 @node Continuation Line
4297 @subsection Continuation Line
4298 @cindex continuation line, number of
4299 @cindex lines, continuation
4300 @cindex number of continuation lines
4301 @cindex limits, continuation lines
4303 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4305 A continuation line is any line that both
4309 Contains a continuation character, and
4312 Contains only spaces in columns 1 through 5
4315 A continuation character is any character of the GNU Fortran character set
4316 other than space (@key{SPC}) or zero (@samp{0})
4317 in column 6, or a digit (@samp{0} through @samp{9}) in column
4318 7 through 72 of a line that has only spaces to the left of that
4321 The continuation character is ignored as far as the content of
4322 the statement is concerned.
4324 The GNU Fortran language places no limit on the number of
4325 continuation lines in a statement.
4326 In practice, the limit depends on a variety of factors, such as
4327 available memory, statement content, and so on, but no
4328 GNU Fortran system may impose an arbitrary limit.
4331 @subsection Statements
4333 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4335 Statements may be written using an arbitrary number of continuation
4338 Statements may be separated using the semicolon (@samp{;}), except
4339 that the logical @code{IF} and non-construct @code{WHERE} statements
4340 may not be separated from subsequent statements using only a semicolon
4341 as statement separator.
4343 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4344 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4346 These alternatives may be written as normal statements---they are not
4347 subject to the restrictions of the @code{END} statement.
4349 However, no statement other than @code{END} may have an initial line
4350 that appears to be an @code{END} statement---even @code{END PROGRAM},
4351 for example, must not be written as:
4358 @node Statement Labels
4359 @subsection Statement Labels
4361 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4363 A statement separated from its predecessor via a semicolon may be
4368 The semicolon is followed by the label for the statement,
4369 which in turn follows the label.
4372 The label must be no more than five digits in length.
4375 The first digit of the label for the statement is not
4376 the first non-space character on a line.
4377 Otherwise, that character is treated as a continuation
4381 A statement may have only one label defined for it.
4384 @subsection Order of Statements and Lines
4386 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4388 Generally, @code{DATA} statements may precede executable statements.
4389 However, specification statements pertaining to any entities
4390 initialized by a @code{DATA} statement must precede that @code{DATA}
4393 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4394 @samp{INTEGER J} is permitted.
4396 The last line of a program unit may be an @code{END} statement,
4401 An @code{END PROGRAM} statement, if the program unit is a main program.
4404 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4407 An @code{END FUNCTION} statement, if the program unit is a function.
4410 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4414 @subsection Including Source Text
4415 @cindex INCLUDE directive
4417 Additional source text may be included in the processing of
4418 the source file via the @code{INCLUDE} directive:
4421 INCLUDE @var{filename}
4425 The source text to be included is identified by @var{filename},
4426 which is a literal GNU Fortran character constant.
4427 The meaning and interpretation of @var{filename} depends on the
4428 implementation, but typically is a filename.
4430 (@code{g77} treats it as a filename that it searches for
4431 in the current directory and/or directories specified
4432 via the @samp{-I} command-line option.)
4434 The effect of the @code{INCLUDE} directive is as if the
4435 included text directly replaced the directive in the source
4436 file prior to interpretation of the program.
4437 Included text may itself use @code{INCLUDE}.
4438 The depth of nested @code{INCLUDE} references depends on
4439 the implementation, but typically is a positive integer.
4441 This virtual replacement treats the statements and @code{INCLUDE}
4442 directives in the included text as syntactically distinct from
4443 those in the including text.
4445 Therefore, the first non-comment line of the included text
4446 must not be a continuation line.
4447 The included text must therefore have, after the non-comment
4448 lines, either an initial line (statement), an @code{INCLUDE}
4449 directive, or nothing (the end of the included text).
4451 Similarly, the including text may end the @code{INCLUDE}
4452 directive with a semicolon or the end of the line, but it
4453 cannot follow an @code{INCLUDE} directive at the end of its
4454 line with a continuation line.
4455 Thus, the last statement in an included text may not be
4458 Any statements between two @code{INCLUDE} directives on the
4459 same line are treated as if they appeared in between the
4460 respective included texts.
4464 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4468 If the text included by @samp{INCLUDE 'A'} constitutes
4469 a @samp{PRINT *, 'A'} statement and the text included by
4470 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4471 then the output of the above sample program would be
4480 (with suitable allowances for how an implementation defines
4481 its handling of output).
4483 Included text must not include itself directly or indirectly,
4484 regardless of whether the @var{filename} used to reference
4485 the text is the same.
4487 Note that @code{INCLUDE} is @emph{not} a statement.
4488 As such, it is neither a non-executable or executable
4490 However, if the text it includes constitutes one or more
4491 executable statements, then the placement of @code{INCLUDE}
4492 is subject to effectively the same restrictions as those
4493 on executable statements.
4495 An @code{INCLUDE} directive may be continued across multiple
4496 lines as if it were a statement.
4497 This permits long names to be used for @var{filename}.
4499 @node Cpp-style directives
4500 @subsection Cpp-style directives
4502 @cindex preprocessor
4504 @code{cpp} output-style @code{#} directives
4505 (@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
4506 are recognized by the compiler even
4507 when the preprocessor isn't run on the input (as it is when compiling
4508 @samp{.F} files). (Note the distinction between these @code{cpp}
4509 @code{#} @emph{output} directives and @code{#line} @emph{input}
4512 @node Data Types and Constants
4513 @section Data Types and Constants
4515 (The following information augments or overrides the information in
4516 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4518 Chapter 4 of that document otherwise serves as the basis
4519 for the relevant aspects of GNU Fortran.)
4521 To more concisely express the appropriate types for
4522 entities, this document uses the more concise
4523 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
4524 instead of the more traditional, but less portably concise,
4525 byte-size-based nomenclature such as @code{INTEGER*4},
4526 wherever reasonable.
4528 When referring to generic types---in contexts where the
4529 specific precision and range of a type are not important---this
4530 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
4531 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
4533 In some cases, the context requires specification of a
4535 This document uses the @samp{KIND=} notation to accomplish
4536 this throughout, sometimes supplying the more traditional
4537 notation for clarification, though the traditional notation
4538 might not work the same way on all GNU Fortran implementations.
4540 Use of @samp{KIND=} makes this document more concise because
4541 @code{g77} is able to define values for @samp{KIND=} that
4542 have the same meanings on all systems, due to the way the
4543 Fortran 90 standard specifies these values are to be used.
4545 (In particular, that standard permits an implementation to
4546 arbitrarily assign nonnegative values.
4547 There are four distinct sets of assignments: one to the @code{CHARACTER}
4548 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
4549 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
4550 Implementations are free to assign these values in any order,
4551 leave gaps in the ordering of assignments, and assign more than
4552 one value to a representation.)
4554 This makes @samp{KIND=} values superior to the values used
4555 in non-standard statements such as @samp{INTEGER*4}, because
4556 the meanings of the values in those statements vary from machine
4557 to machine, compiler to compiler, even operating system to
4560 However, use of @samp{KIND=} is @emph{not} generally recommended
4561 when writing portable code (unless, for example, the code is
4562 going to be compiled only via @code{g77}, which is a widely
4564 GNU Fortran does not yet have adequate language constructs to
4565 permit use of @samp{KIND=} in a fashion that would make the
4566 code portable to Fortran 90 implementations; and, this construct
4567 is known to @emph{not} be accepted by many popular FORTRAN 77
4568 implementations, so it cannot be used in code that is to be ported
4571 The distinction here is that this document is able to use
4572 specific values for @samp{KIND=} to concisely document the
4573 types of various operations and operands.
4575 A Fortran program should use the FORTRAN 77 designations for the
4576 appropriate GNU Fortran types---such as @code{INTEGER} for
4577 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
4578 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
4579 where no such designations exist, make use of appropriate
4580 techniques (preprocessor macros, parameters, and so on)
4581 to specify the types in a fashion that may be easily adjusted
4582 to suit each particular implementation to which the program
4584 (These types generally won't need to be adjusted for ports of
4587 Further details regarding GNU Fortran data types and constants
4598 @subsection Data Types
4600 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
4602 GNU Fortran supports these types:
4606 Integer (generic type @code{INTEGER})
4609 Real (generic type @code{REAL})
4615 Complex (generic type @code{COMPLEX})
4618 Logical (generic type @code{LOGICAL})
4621 Character (generic type @code{CHARACTER})
4627 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
4629 The generic types shown above are referred to in this document
4630 using only their generic type names.
4631 Such references usually indicate that any specific type (kind)
4632 of that generic type is valid.
4634 For example, a context described in this document as accepting
4635 the @code{COMPLEX} type also is likely to accept the
4636 @code{DOUBLE COMPLEX} type.
4638 The GNU Fortran language supports three ways to specify
4639 a specific kind of a generic type.
4642 * Double Notation:: As in @code{DOUBLE COMPLEX}.
4643 * Star Notation:: As in @code{INTEGER*4}.
4644 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
4647 @node Double Notation
4648 @subsubsection Double Notation
4650 The GNU Fortran language supports two uses of the keyword
4651 @code{DOUBLE} to specify a specific kind of type:
4655 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
4658 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
4661 Use one of the above forms where a type name is valid.
4663 While use of this notation is popular, it doesn't scale
4664 well in a language or dialect rich in intrinsic types,
4665 as is the case for the GNU Fortran language (especially
4666 planned future versions of it).
4668 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
4669 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
4670 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
4671 often are substituted for these, respectively, even though they
4672 do not always have the same meanings on all systems.
4673 (And, the fact that @samp{DOUBLE REAL} does not exist as such
4674 is an inconsistency.)
4676 Therefore, this document uses ``double notation'' only on occasion
4677 for the benefit of those readers who are accustomed to it.
4680 @subsubsection Star Notation
4681 @cindex *@var{n} notation
4683 The following notation specifies the storage size for a type:
4686 @var{generic-type}*@var{n}
4690 @var{generic-type} must be a generic type---one of
4691 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4692 or @code{CHARACTER}.
4693 @var{n} must be one or more digits comprising a decimal
4694 integer number greater than zero.
4696 Use the above form where a type name is valid.
4698 The @samp{*@var{n}} notation specifies that the amount of storage
4699 occupied by variables and array elements of that type is @var{n}
4700 times the storage occupied by a @code{CHARACTER*1} variable.
4702 This notation might indicate a different degree of precision and/or
4703 range for such variables and array elements, and the functions that
4704 return values of types using this notation.
4705 It does not limit the precision or range of values of that type
4706 in any particular way---use explicit code to do that.
4708 Further, the GNU Fortran language requires no particular values
4709 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
4711 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
4712 on all systems, for example,
4713 but not all implementations are required to do so, and @code{g77}
4714 is known to not support @code{REAL*1} on most (or all) systems.
4716 As a result, except for @var{generic-type} of @code{CHARACTER},
4717 uses of this notation should be limited to isolated
4718 portions of a program that are intended to handle system-specific
4719 tasks and are expected to be non-portable.
4721 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
4722 only @code{CHARACTER}, where it signifies not only the amount
4723 of storage occupied, but the number of characters in entities
4725 However, almost all Fortran compilers have supported this
4726 notation for generic types, though with a variety of meanings
4729 Specifications of types using the @samp{*@var{n}} notation
4730 always are interpreted as specifications of the appropriate
4731 types described in this document using the @samp{KIND=@var{n}}
4732 notation, described below.
4734 While use of this notation is popular, it doesn't serve well
4735 in the context of a widely portable dialect of Fortran, such as
4736 the GNU Fortran language.
4738 For example, even on one particular machine, two or more popular
4739 Fortran compilers might well disagree on the size of a type
4740 declared @code{INTEGER*2} or @code{REAL*16}.
4742 is known to be disagreement over such things among Fortran
4743 compilers on @emph{different} systems.
4745 Further, this notation offers no elegant way to specify sizes
4746 that are not even multiples of the ``byte size'' typically
4747 designated by @code{INTEGER*1}.
4748 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
4749 certainly be possible, but would perhaps be stretching the original
4750 intent of this notation beyond the breaking point in terms
4751 of widespread readability of documentation and code making use
4754 Therefore, this document uses ``star notation'' only on occasion
4755 for the benefit of those readers who are accustomed to it.
4758 @subsubsection Kind Notation
4759 @cindex KIND= notation
4761 The following notation specifies the kind-type selector of a type:
4764 @var{generic-type}(KIND=@var{n})
4768 Use the above form where a type name is valid.
4770 @var{generic-type} must be a generic type---one of
4771 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4772 or @code{CHARACTER}.
4773 @var{n} must be an integer initialization expression that
4774 is a positive, nonzero value.
4776 Programmers are discouraged from writing these values directly
4778 Future versions of the GNU Fortran language will offer
4779 facilities that will make the writing of code portable
4780 to @code{g77} @emph{and} Fortran 90 implementations simpler.
4782 However, writing code that ports to existing FORTRAN 77
4783 implementations depends on avoiding the @samp{KIND=} construct.
4785 The @samp{KIND=} construct is thus useful in the context
4786 of GNU Fortran for two reasons:
4790 It provides a means to specify a type in a fashion that
4791 is portable across all GNU Fortran implementations (though
4792 not other FORTRAN 77 and Fortran 90 implementations).
4795 It provides a sort of Rosetta stone for this document to use
4796 to concisely describe the types of various operations and
4800 The values of @var{n} in the GNU Fortran language are
4801 assigned using a scheme that:
4805 Attempts to maximize the ability of readers
4806 of this document to quickly familiarize themselves
4807 with assignments for popular types
4810 Provides a unique value for each specific desired
4814 Provides a means to automatically assign new values so
4815 they have a ``natural'' relationship to existing values,
4816 if appropriate, or, if no such relationship exists, will
4817 not interfere with future values assigned on the basis
4818 of such relationships
4821 Avoids using values that are similar to values used
4822 in the existing, popular @samp{*@var{n}} notation,
4823 to prevent readers from expecting that these implied
4824 correspondences work on all GNU Fortran implementations
4827 The assignment system accomplishes this by assigning
4828 to each ``fundamental meaning'' of a specific type a
4829 unique prime number.
4830 Combinations of fundamental meanings---for example, a type
4831 that is two times the size of some other type---are assigned
4832 values of @var{n} that are the products of the values for
4833 those fundamental meanings.
4835 A prime value of @var{n} is never given more than one fundamental
4836 meaning, to avoid situations where some code or system
4837 cannot reasonably provide those meanings in the form of a
4840 The values of @var{n} assigned so far are:
4844 This value is reserved for future use.
4846 The planned future use is for this value to designate,
4847 explicitly, context-sensitive kind-type selection.
4848 For example, the expression @samp{1D0 * 0.1_0} would
4849 be equivalent to @samp{1D0 * 0.1D0}.
4852 This corresponds to the default types for
4853 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
4854 and @code{CHARACTER}, as appropriate.
4856 These are the ``default'' types described in the Fortran 90 standard,
4857 though that standard does not assign any particular @samp{KIND=}
4858 value to these types.
4860 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
4861 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
4864 This corresponds to types that occupy twice as much
4865 storage as the default types.
4866 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
4867 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
4869 These are the ``double precision'' types described in the Fortran 90
4871 though that standard does not assign any particular @samp{KIND=}
4872 value to these types.
4874 @var{n} of 4 thus corresponds to types that occupy four times
4875 as much storage as the default types, @var{n} of 8 to types that
4876 occupy eight times as much storage, and so on.
4878 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
4879 are not necessarily supported by every GNU Fortran implementation.
4882 This corresponds to types that occupy as much
4883 storage as the default @code{CHARACTER} type,
4884 which is the same effective type as @code{CHARACTER(KIND=1)}
4885 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
4887 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
4889 @var{n} of 6 thus corresponds to types that occupy twice as
4890 much storage as the @var{n}=3 types, @var{n} of 12 to types
4891 that occupy four times as much storage, and so on.
4893 These are not necessarily supported by every GNU Fortran
4897 This corresponds to types that occupy half the
4898 storage as the default (@var{n}=1) types.
4900 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
4902 @var{n} of 25 thus corresponds to types that occupy one-quarter
4903 as much storage as the default types.
4905 These are not necessarily supported by every GNU Fortran
4910 This is valid only as @code{INTEGER(KIND=7)} and
4911 denotes the @code{INTEGER} type that has the smallest
4912 storage size that holds a pointer on the system.
4914 A pointer representable by this type is capable of uniquely
4915 addressing a @code{CHARACTER*1} variable, array, array element,
4918 (Typically this is equivalent to @code{INTEGER*4} or,
4919 on 64-bit systems, @code{INTEGER*8}.
4920 In a compatible C implementation, it typically would
4921 be the same size and semantics of the C type @code{void *}.)
4924 Note that these are @emph{proposed} correspondences and might change
4925 in future versions of @code{g77}---avoid writing code depending
4926 on them while @code{g77}, and therefore the GNU Fortran language
4927 it defines, is in beta testing.
4929 Values not specified in the above list are reserved to
4930 future versions of the GNU Fortran language.
4932 Implementation-dependent meanings will be assigned new,
4933 unique prime numbers so as to not interfere with other
4934 implementation-dependent meanings, and offer the possibility
4935 of increasing the portability of code depending on such
4936 types by offering support for them in other GNU Fortran
4939 Other meanings that might be given unique values are:
4943 Types that make use of only half their storage size for
4944 representing precision and range.
4946 For example, some compilers offer options that cause
4947 @code{INTEGER} types to occupy the amount of storage
4948 that would be needed for @code{INTEGER(KIND=2)} types, but the
4949 range remains that of @code{INTEGER(KIND=1)}.
4952 The IEEE single floating-point type.
4955 Types with a specific bit pattern (endianness), such as the
4956 little-endian form of @code{INTEGER(KIND=1)}.
4957 These could permit, conceptually, use of portable code and
4958 implementations on data files written by existing systems.
4961 Future @emph{prime} numbers should be given meanings in as incremental
4962 a fashion as possible, to allow for flexibility and
4963 expressiveness in combining types.
4965 For example, instead of defining a prime number for little-endian
4966 IEEE doubles, one prime number might be assigned the meaning
4967 ``little-endian'', another the meaning ``IEEE double'', and the
4968 value of @var{n} for a little-endian IEEE double would thus
4969 naturally be the product of those two respective assigned values.
4970 (It could even be reasonable to have IEEE values result from the
4971 products of prime values denoting exponent and fraction sizes
4972 and meanings, hidden bit usage, availability and representations
4973 of special values such as subnormals, infinities, and Not-A-Numbers
4976 This assignment mechanism, while not inherently required for
4977 future versions of the GNU Fortran language, is worth using
4978 because it could ease management of the ``space'' of supported
4979 types much easier in the long run.
4981 The above approach suggests a mechanism for specifying inheritance
4982 of intrinsic (built-in) types for an entire, widely portable
4984 It is certainly reasonable that, unlike programmers of other languages
4985 offering inheritance mechanisms that employ verbose names for classes
4986 and subclasses, along with graphical browsers to elucidate the
4987 relationships, Fortran programmers would employ
4988 a mechanism that works by multiplying prime numbers together
4989 and finding the prime factors of such products.
4991 Most of the advantages for the above scheme have been explained
4993 One disadvantage is that it could lead to the defining,
4994 by the GNU Fortran language, of some fairly large prime numbers.
4995 This could lead to the GNU Fortran language being declared
4996 ``munitions'' by the United States Department of Defense.
4999 @subsection Constants
5001 @cindex types, constants
5003 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
5005 A @dfn{typeless constant} has one of the following forms:
5008 '@var{binary-digits}'B
5009 '@var{octal-digits}'O
5010 '@var{hexadecimal-digits}'Z
5011 '@var{hexadecimal-digits}'X
5015 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5016 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5017 and @samp{0123456789ABCDEFabcdef}, respectively.
5018 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5021 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
5022 treated as typeless. @xref{Fortran Dialect Options,, Options
5023 Controlling Fortran Dialect}, for information on the
5024 @samp{-ftypeless-boz} option.
5026 Typeless constants have values that depend on the context in which
5029 All other constants, called @dfn{typed constants}, are interpreted---converted
5030 to internal form---according to their inherent type.
5031 Thus, context is @emph{never} a determining factor for the type, and hence
5032 the interpretation, of a typed constant.
5033 (All constants in the ANSI FORTRAN 77 language are typed constants.)
5035 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
5036 Fortran (called default INTEGER in Fortran 90),
5037 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
5038 additional precision specified is lost, and even when used in a
5039 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
5040 and @samp{1D0} is always type @code{REAL(KIND=2)}.
5043 @subsection Integer Type
5045 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
5047 An integer constant also may have one of the following forms:
5050 B'@var{binary-digits}'
5051 O'@var{octal-digits}'
5052 Z'@var{hexadecimal-digits}'
5053 X'@var{hexadecimal-digits}'
5057 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5058 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5059 and @samp{0123456789ABCDEFabcdef}, respectively.
5060 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5063 @node Character Type
5064 @subsection Character Type
5066 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
5068 @cindex double quoted character constants
5069 A character constant may be delimited by a pair of double quotes
5070 (@samp{"}) instead of apostrophes.
5071 In this case, an apostrophe within the constant represents
5072 a single apostrophe, while a double quote is represented in
5073 the source text of the constant by two consecutive double
5074 quotes with no intervening spaces.
5076 @cindex zero-length CHARACTER
5077 @cindex null CHARACTER strings
5078 @cindex empty CHARACTER strings
5079 @cindex strings, empty
5080 @cindex CHARACTER, null
5081 A character constant may be empty (have a length of zero).
5083 A character constant may include a substring specification,
5084 The value of such a constant is the value of the substring---for
5085 example, the value of @samp{'hello'(3:5)} is the same
5086 as the value of @samp{'llo'}.
5089 @section Expressions
5091 (The following information augments or overrides the information in
5092 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5094 Chapter 6 of that document otherwise serves as the basis
5095 for the relevant aspects of GNU Fortran.)
5102 @subsection The @code{%LOC()} Construct
5103 @cindex %LOC() construct
5109 The @code{%LOC()} construct is an expression
5110 that yields the value of the location of its argument,
5111 @var{arg}, in memory.
5112 The size of the type of the expression depends on the system---typically,
5113 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5114 though it is actually type @code{INTEGER(KIND=7)}.
5116 The argument to @code{%LOC()} must be suitable as the
5117 left-hand side of an assignment statement.
5118 That is, it may not be a general expression involving
5119 operators such as addition, subtraction, and so on,
5120 nor may it be a constant.
5122 Use of @code{%LOC()} is recommended only for code that
5123 is accessing facilities outside of GNU Fortran, such as
5124 operating system or windowing facilities.
5125 It is best to constrain such uses to isolated portions of
5126 a program---portions that deal specifically and exclusively
5127 with low-level, system-dependent facilities.
5128 Such portions might well provide a portable interface for
5129 use by the program as a whole, but are themselves not
5130 portable, and should be thoroughly tested each time they
5131 are rebuilt using a new compiler or version of a compiler.
5133 Do not depend on @code{%LOC()} returning a pointer that
5134 can be safely used to @emph{define} (change) the argument.
5135 While this might work in some circumstances, it is hard
5136 to predict whether it will continue to work when a program
5137 (that works using this unsafe behavior)
5138 is recompiled using different command-line options or
5139 a different version of @code{g77}.
5141 Generally, @code{%LOC()} is safe when used as an argument
5142 to a procedure that makes use of the value of the corresponding
5143 dummy argument only during its activation, and only when
5144 such use is restricted to referencing (reading) the value
5145 of the argument to @code{%LOC()}.
5147 @emph{Implementation Note:} Currently, @code{g77} passes
5148 arguments (those not passed using a construct such as @code{%VAL()})
5149 by reference or descriptor, depending on the type of
5150 the actual argument.
5151 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5152 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5153 in fact might compile to identical code.
5155 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5156 ``pass, by value, the address of @samp{I} in memory''.
5157 While @samp{CALL FOO(I)} might use that same approach in a
5158 particular version of @code{g77}, another version or compiler
5159 might choose a different implementation, such as copy-in/copy-out,
5160 to effect the desired behavior---and which will therefore not
5161 necessarily compile to the same code as would
5162 @samp{CALL FOO(%VAL(%LOC(I)))}
5163 using the same version or compiler.
5165 @xref{Debugging and Interfacing}, for detailed information on
5166 how this particular version of @code{g77} implements various
5169 @node Specification Statements
5170 @section Specification Statements
5172 (The following information augments or overrides the information in
5173 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5175 Chapter 8 of that document otherwise serves as the basis
5176 for the relevant aspects of GNU Fortran.)
5184 @subsection @code{NAMELIST} Statement
5185 @cindex NAMELIST statement
5186 @cindex statements, NAMELIST
5188 The @code{NAMELIST} statement, and related I/O constructs, are
5189 supported by the GNU Fortran language in essentially the same
5190 way as they are by @code{f2c}.
5192 This follows Fortran 90 with the restriction that on @code{NAMELIST}
5193 input, subscripts must have the form
5195 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
5199 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
5201 is allowed, but not, say,
5203 &xx x(:3,8::2)=1,2,3,4,5,6/
5206 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
5207 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
5209 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
5211 could be used instead of the example above.
5213 @node DOUBLE COMPLEX
5214 @subsection @code{DOUBLE COMPLEX} Statement
5215 @cindex DOUBLE COMPLEX
5217 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5218 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5220 @node Control Statements
5221 @section Control Statements
5223 (The following information augments or overrides the information in
5224 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5226 Chapter 11 of that document otherwise serves as the basis
5227 for the relevant aspects of GNU Fortran.)
5237 @subsection DO WHILE
5240 @cindex MIL-STD 1753
5242 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5243 Fortran 90 standards, is provided by the GNU Fortran language.
5244 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
5250 @cindex MIL-STD 1753
5252 The @code{END DO} statement is provided by the GNU Fortran language.
5254 This statement is used in one of two ways:
5258 The Fortran 90 meaning, in which it specifies the termination
5259 point of a single @code{DO} loop started with a @code{DO} statement
5260 that specifies no termination label.
5263 The MIL-STD 1753 meaning, in which it specifies the termination
5264 point of one or more @code{DO} loops, all of which start with a
5265 @code{DO} statement that specify the label defined for the
5266 @code{END DO} statement.
5268 This kind of @code{END DO} statement is merely a synonym for
5269 @code{CONTINUE}, except it is permitted only when the statement
5270 is labeled and a target of one or more labeled @code{DO} loops.
5272 It is expected that this use of @code{END DO} will be removed from
5273 the GNU Fortran language in the future, though it is likely that
5274 it will long be supported by @code{g77} as a dialect form.
5277 @node Construct Names
5278 @subsection Construct Names
5279 @cindex construct names
5281 The GNU Fortran language supports construct names as defined
5282 by the Fortran 90 standard.
5283 These names are local to the program unit and are defined
5287 @var{construct-name}: @var{block-statement}
5291 Here, @var{construct-name} is the construct name itself;
5292 its definition is connoted by the single colon (@samp{:}); and
5293 @var{block-statement} is an @code{IF}, @code{DO},
5294 or @code{SELECT CASE} statement that begins a block.
5296 A block that is given a construct name must also specify the
5297 same construct name in its termination statement:
5300 END @var{block} @var{construct-name}
5304 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5307 @node CYCLE and EXIT
5308 @subsection The @code{CYCLE} and @code{EXIT} Statements
5310 @cindex CYCLE statement
5311 @cindex EXIT statement
5312 @cindex statements, CYCLE
5313 @cindex statements, EXIT
5314 The @code{CYCLE} and @code{EXIT} statements specify that
5315 the remaining statements in the current iteration of a
5316 particular active (enclosing) @code{DO} loop are to be skipped.
5318 @code{CYCLE} specifies that these statements are skipped,
5319 but the @code{END DO} statement that marks the end of the
5320 @code{DO} loop be executed---that is, the next iteration,
5321 if any, is to be started.
5322 If the statement marking the end of the @code{DO} loop is
5323 not @code{END DO}---in other words, if the loop is not
5324 a block @code{DO}---the @code{CYCLE} statement does not
5325 execute that statement, but does start the next iteration (if any).
5327 @code{EXIT} specifies that the loop specified by the
5328 @code{DO} construct is terminated.
5330 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5331 is the innermost enclosing @code{DO} loop when the following
5339 Otherwise, the following forms specify the construct name
5340 of the pertinent @code{DO} loop:
5343 CYCLE @var{construct-name}
5344 EXIT @var{construct-name}
5347 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5349 However, they cannot be easily thought of as @code{GO TO} statements
5350 in obscure cases involving FORTRAN 77 loops.
5359 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5364 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5365 above are equivalent to a @code{GO TO} statement to either label
5366 @samp{10} or @samp{20}.
5368 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5369 above fragment, it is helpful to first translate it to its equivalent
5370 using only block @code{DO} loops:
5378 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5385 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5386 to @code{GO TO} so they may be more easily understood by programmers
5387 accustomed to FORTRAN coding:
5392 IF (J .EQ. 5) GOTO 18
5394 IF (K .EQ. 3) GO TO 12
5395 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5403 Thus, the @code{CYCLE} statement in the innermost loop skips over
5404 the @code{PRINT} statement as it begins the next iteration of the
5405 loop, while the @code{EXIT} statement in the middle loop ends that
5406 loop but @emph{not} the outermost loop.
5408 @node Functions and Subroutines
5409 @section Functions and Subroutines
5411 (The following information augments or overrides the information in
5412 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5414 Chapter 15 of that document otherwise serves as the basis
5415 for the relevant aspects of GNU Fortran.)
5421 * Generics and Specifics::
5422 * REAL() and AIMAG() of Complex::
5423 * CMPLX() of DOUBLE PRECISION::
5425 * f77/f2c Intrinsics::
5426 * Table of Intrinsic Functions::
5430 @subsection The @code{%VAL()} Construct
5431 @cindex %VAL() construct
5437 The @code{%VAL()} construct specifies that an argument,
5438 @var{arg}, is to be passed by value, instead of by reference
5441 @code{%VAL()} is restricted to actual arguments in
5442 invocations of external procedures.
5444 Use of @code{%VAL()} is recommended only for code that
5445 is accessing facilities outside of GNU Fortran, such as
5446 operating system or windowing facilities.
5447 It is best to constrain such uses to isolated portions of
5448 a program---portions the deal specifically and exclusively
5449 with low-level, system-dependent facilities.
5450 Such portions might well provide a portable interface for
5451 use by the program as a whole, but are themselves not
5452 portable, and should be thoroughly tested each time they
5453 are rebuilt using a new compiler or version of a compiler.
5455 @emph{Implementation Note:} Currently, @code{g77} passes
5456 all arguments either by reference or by descriptor.
5458 Thus, use of @code{%VAL()} tends to be restricted to cases
5459 where the called procedure is written in a language other
5460 than Fortran that supports call-by-value semantics.
5461 (C is an example of such a language.)
5463 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5464 for detailed information on
5465 how this particular version of @code{g77} passes arguments
5469 @subsection The @code{%REF()} Construct
5470 @cindex %REF() construct
5476 The @code{%REF()} construct specifies that an argument,
5477 @var{arg}, is to be passed by reference, instead of by
5478 value or descriptor.
5480 @code{%REF()} is restricted to actual arguments in
5481 invocations of external procedures.
5483 Use of @code{%REF()} is recommended only for code that
5484 is accessing facilities outside of GNU Fortran, such as
5485 operating system or windowing facilities.
5486 It is best to constrain such uses to isolated portions of
5487 a program---portions the deal specifically and exclusively
5488 with low-level, system-dependent facilities.
5489 Such portions might well provide a portable interface for
5490 use by the program as a whole, but are themselves not
5491 portable, and should be thoroughly tested each time they
5492 are rebuilt using a new compiler or version of a compiler.
5494 Do not depend on @code{%REF()} supplying a pointer to the
5495 procedure being invoked.
5496 While that is a likely implementation choice, other
5497 implementation choices are available that preserve Fortran
5498 pass-by-reference semantics without passing a pointer to
5499 the argument, @var{arg}.
5500 (For example, a copy-in/copy-out implementation.)
5502 @emph{Implementation Note:} Currently, @code{g77} passes
5504 (other than variables and arrays of type @code{CHARACTER})
5506 Future versions of, or dialects supported by, @code{g77} might
5507 not pass @code{CHARACTER} functions by reference.
5509 Thus, use of @code{%REF()} tends to be restricted to cases
5510 where @var{arg} is type @code{CHARACTER} but the called
5511 procedure accesses it via a means other than the method
5512 used for Fortran @code{CHARACTER} arguments.
5514 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5515 how this particular version of @code{g77} passes arguments
5519 @subsection The @code{%DESCR()} Construct
5520 @cindex %DESCR() construct
5526 The @code{%DESCR()} construct specifies that an argument,
5527 @var{arg}, is to be passed by descriptor, instead of by
5530 @code{%DESCR()} is restricted to actual arguments in
5531 invocations of external procedures.
5533 Use of @code{%DESCR()} is recommended only for code that
5534 is accessing facilities outside of GNU Fortran, such as
5535 operating system or windowing facilities.
5536 It is best to constrain such uses to isolated portions of
5537 a program---portions the deal specifically and exclusively
5538 with low-level, system-dependent facilities.
5539 Such portions might well provide a portable interface for
5540 use by the program as a whole, but are themselves not
5541 portable, and should be thoroughly tested each time they
5542 are rebuilt using a new compiler or version of a compiler.
5544 Do not depend on @code{%DESCR()} supplying a pointer
5545 and/or a length passed by value
5546 to the procedure being invoked.
5547 While that is a likely implementation choice, other
5548 implementation choices are available that preserve the
5549 pass-by-reference semantics without passing a pointer to
5550 the argument, @var{arg}.
5551 (For example, a copy-in/copy-out implementation.)
5552 And, future versions of @code{g77} might change the
5553 way descriptors are implemented, such as passing a
5554 single argument pointing to a record containing the
5555 pointer/length information instead of passing that same
5556 information via two arguments as it currently does.
5558 @emph{Implementation Note:} Currently, @code{g77} passes
5559 all variables and arrays of type @code{CHARACTER}
5561 Future versions of, or dialects supported by, @code{g77} might
5562 pass @code{CHARACTER} functions by descriptor as well.
5564 Thus, use of @code{%DESCR()} tends to be restricted to cases
5565 where @var{arg} is not type @code{CHARACTER} but the called
5566 procedure accesses it via a means similar to the method
5567 used for Fortran @code{CHARACTER} arguments.
5569 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5570 how this particular version of @code{g77} passes arguments
5573 @node Generics and Specifics
5574 @subsection Generics and Specifics
5575 @cindex generic intrinsics
5576 @cindex intrinsics, generic
5578 The ANSI FORTRAN 77 language defines generic and specific
5580 In short, the distinctions are:
5584 @emph{Specific} intrinsics have
5585 specific types for their arguments and a specific return
5589 @emph{Generic} intrinsics are treated,
5590 on a case-by-case basis in the program's source code,
5591 as one of several possible specific intrinsics.
5593 Typically, a generic intrinsic has a return type that
5594 is determined by the type of one or more of its arguments.
5597 The GNU Fortran language generalizes these concepts somewhat,
5598 especially by providing intrinsic subroutines and generic
5599 intrinsics that are treated as either a specific intrinsic subroutine
5600 or a specific intrinsic function (e.g. @code{SECOND}).
5602 However, GNU Fortran avoids generalizing this concept to
5603 the point where existing code would be accepted as meaning
5604 something possibly different than what was intended.
5606 For example, @code{ABS} is a generic intrinsic, so all working
5607 code written using @code{ABS} of an @code{INTEGER} argument
5608 expects an @code{INTEGER} return value.
5609 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
5610 argument returns an @code{INTEGER*2} return value.
5612 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
5613 an @code{INTEGER(KIND=1)} argument.
5614 Code that passes something other than an @code{INTEGER(KIND=1)}
5615 argument to @code{IABS} is not valid GNU Fortran code, because
5616 it is not clear what the author intended.
5618 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
5619 is not defined by the GNU Fortran language, because the programmer
5620 might have used that construct to mean any of the following, subtly
5625 Convert @samp{J} to @code{INTEGER(KIND=1)} first
5626 (as if @samp{IABS(INT(J))} had been written).
5629 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
5630 (as if @samp{INT(ABS(J))} had been written).
5633 No conversion (as if @samp{ABS(J)} had been written).
5636 The distinctions matter especially when types and values wider than
5637 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
5638 operations performing more ``arithmetic'' than absolute-value, are involved.
5640 The following sample program is not a valid GNU Fortran program, but
5641 might be accepted by other compilers.
5642 If so, the output is likely to be revealing in terms of how a given
5643 compiler treats intrinsics (that normally are specific) when they
5644 are given arguments that do not conform to their stated requirements:
5646 @cindex JCB002 program
5650 C Modified 1999-02-15 (Burley) to delete my email address.
5651 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
5652 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
5655 C Written by James Craig Burley 1997-02-20.
5658 C Determine how compilers handle non-standard IDIM
5659 C on INTEGER*2 operands, which presumably can be
5660 C extrapolated into understanding how the compiler
5661 C generally treats specific intrinsics that are passed
5662 C arguments not of the correct types.
5664 C If your compiler implements INTEGER*2 and INTEGER
5665 C as the same type, change all INTEGER*2 below to
5670 INTEGER*2 ISMALL, ILARGE
5671 INTEGER*2 ITOOLG, ITWO
5675 C Find smallest INTEGER*2 number.
5679 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
5684 C Find largest INTEGER*2 number.
5688 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
5693 C Multiplying by two adds stress to the situation.
5697 C Need a number that, added to -2, is too wide to fit in I*2.
5701 C Use IDIM the straightforward way.
5703 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
5705 C Calculate result for first interpretation.
5707 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
5709 C Calculate result for second interpretation.
5711 ITMP = ILARGE - ISMALL
5712 I3 = (INT (ITMP)) * ITWO + ITOOLG
5714 C Calculate result for third interpretation.
5716 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
5720 PRINT *, 'ILARGE=', ILARGE
5721 PRINT *, 'ITWO=', ITWO
5722 PRINT *, 'ITOOLG=', ITOOLG
5723 PRINT *, 'ISMALL=', ISMALL
5732 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
5733 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
5736 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
5737 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
5740 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
5741 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
5744 PRINT *, 'Results need careful analysis.'
5748 No future version of the GNU Fortran language
5749 will likely permit specific intrinsic invocations with wrong-typed
5750 arguments (such as @code{IDIM} in the above example), since
5751 it has been determined that disagreements exist among
5752 many production compilers on the interpretation of
5754 These disagreements strongly suggest that Fortran programmers,
5755 and certainly existing Fortran programs, disagree about the
5756 meaning of such invocations.
5758 The first version of @code{JCB002} didn't accommodate some compilers'
5759 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
5761 In such a case, these compilers apparently convert both
5762 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
5763 instead of doing an @code{INTEGER*2} subtraction on the
5764 original values in @samp{I1} and @samp{I2}.
5766 However, the results of the careful analyses done on the outputs
5767 of programs compiled by these various compilers show that they
5768 all implement either @samp{Interp 1} or @samp{Interp 2} above.
5770 Specifically, it is believed that the new version of @code{JCB002}
5771 above will confirm that:
5775 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
5776 @code{f77} compilers all implement @samp{Interp 1}.
5779 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
5782 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
5783 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
5786 If you get different results than the above for the stated
5787 compilers, or have results for other compilers that might be
5788 worth adding to the above list, please let us know the details
5789 (compiler product, version, machine, results, and so on).
5791 @node REAL() and AIMAG() of Complex
5792 @subsection @code{REAL()} and @code{AIMAG()} of Complex
5793 @cindex @code{Real} intrinsic
5794 @cindex intrinsics, @code{Real}
5795 @cindex @code{AImag} intrinsic
5796 @cindex intrinsics, @code{AImag}
5798 The GNU Fortran language disallows @code{REAL(@var{expr})}
5799 and @code{AIMAG(@var{expr})},
5800 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
5801 except when they are used in the following way:
5804 REAL(REAL(@var{expr}))
5805 REAL(AIMAG(@var{expr}))
5809 The above forms explicitly specify that the desired effect
5810 is to convert the real or imaginary part of @var{expr}, which might
5811 be some @code{REAL} type other than @code{REAL(KIND=1)},
5812 to type @code{REAL(KIND=1)},
5813 and have that serve as the value of the expression.
5815 The GNU Fortran language offers clearly named intrinsics to extract the
5816 real and imaginary parts of a complex entity without any
5820 REALPART(@var{expr})
5821 IMAGPART(@var{expr})
5824 To express the above using typical extended FORTRAN 77,
5825 use the following constructs
5826 (when @var{expr} is @code{COMPLEX(KIND=2)}):
5833 The FORTRAN 77 language offers no way
5834 to explicitly specify the real and imaginary parts of a complex expression of
5835 arbitrary type, apparently as a result of requiring support for
5836 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
5837 The concepts of converting an expression to type @code{REAL(KIND=1)} and
5838 of extracting the real part of a complex expression were
5839 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
5840 they happened to have the exact same effect in that language
5841 (due to having only one @code{COMPLEX} type).
5843 @emph{Note:} When @samp{-ff90} is in effect,
5844 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
5845 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
5846 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
5847 treated as @samp{REAL(REALPART(@var{expr}))}.
5849 @xref{Ugly Complex Part Extraction}, for more information.
5851 @node CMPLX() of DOUBLE PRECISION
5852 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
5853 @cindex @code{Cmplx} intrinsic
5854 @cindex intrinsics, @code{Cmplx}
5856 In accordance with Fortran 90 and at least some (perhaps all)
5857 other compilers, the GNU Fortran language defines @code{CMPLX()}
5858 as always returning a result that is type @code{COMPLEX(KIND=1)}.
5860 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
5861 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
5864 CMPLX(SNGL(D1), SNGL(D2))
5867 (It was necessary for Fortran 90 to specify this behavior
5868 for @code{DOUBLE PRECISION} arguments, since that is
5869 the behavior mandated by FORTRAN 77.)
5871 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
5872 which is provided by some FORTRAN 77 compilers to construct
5873 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
5875 However, this solution does not scale well when more @code{COMPLEX} types
5876 (having various precisions and ranges) are offered by Fortran implementations.
5878 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
5879 an extra argument used to specify the desired kind of complex
5881 However, this solution is somewhat awkward to use, and
5882 @code{g77} currently does not support it.
5884 The GNU Fortran language provides a simple way to build a complex
5885 value out of two numbers, with the precise type of the value
5886 determined by the types of the two numbers (via the usual
5887 type-promotion mechanism):
5890 COMPLEX(@var{real}, @var{imag})
5893 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
5894 performs no conversion other than to put them together to form a
5895 complex result of the same (complex version of real) type.
5897 @xref{Complex Intrinsic}, for more information.
5900 @subsection MIL-STD 1753 Support
5901 @cindex MIL-STD 1753
5903 The GNU Fortran language includes the MIL-STD 1753 intrinsics
5904 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
5905 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
5906 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
5908 @node f77/f2c Intrinsics
5909 @subsection @code{f77}/@code{f2c} Intrinsics
5911 The bit-manipulation intrinsics supported by traditional
5912 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
5913 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
5916 Also supported are the intrinsics @code{CDABS},
5917 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
5918 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
5919 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
5920 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
5923 @node Table of Intrinsic Functions
5924 @subsection Table of Intrinsic Functions
5925 @cindex intrinsics, table of
5926 @cindex table of intrinsics
5928 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
5930 The GNU Fortran language adds various functions, subroutines, types,
5931 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
5932 The complete set of intrinsics supported by the GNU Fortran language
5935 Note that a name is not treated as that of an intrinsic if it is
5936 specified in an @code{EXTERNAL} statement in the same program unit;
5937 if a command-line option is used to disable the groups to which
5938 the intrinsic belongs; or if the intrinsic is not named in an
5939 @code{INTRINSIC} statement and a command-line option is used to
5940 hide the groups to which the intrinsic belongs.
5942 So, it is recommended that any reference in a program unit to
5943 an intrinsic procedure that is not a standard FORTRAN 77
5944 intrinsic be accompanied by an appropriate @code{INTRINSIC}
5945 statement in that program unit.
5946 This sort of defensive programming makes it more
5947 likely that an implementation will issue a diagnostic rather
5948 than generate incorrect code for such a reference.
5950 The terminology used below is based on that of the Fortran 90
5951 standard, so that the text may be more concise and accurate:
5955 @code{OPTIONAL} means the argument may be omitted.
5958 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
5959 (generally named @samp{A}) may be specified.
5962 @samp{scalar} means the argument must not be an array (must
5963 be a variable or array element, or perhaps a constant if expressions
5967 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
5970 @code{INTENT(IN)} means the argument must be an expression
5971 (such as a constant or a variable that is defined upon invocation
5975 @code{INTENT(OUT)} means the argument must be definable by the
5976 invocation of the intrinsic (that is, must not be a constant nor
5977 an expression involving operators other than array reference and
5978 substring reference).
5981 @code{INTENT(INOUT)} means the argument must be defined prior to,
5982 and definable by, invocation of the intrinsic (a combination of
5983 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
5986 @xref{Kind Notation}, for an explanation of @code{KIND}.
5990 (Note that the empty lines appearing in the menu below
5991 are not intentional---they result from a bug in the
5992 GNU @code{makeinfo} program@dots{}a program that, if it
5993 did not exist, would leave this document in far worse shape!)
5996 @c The actual documentation for intrinsics comes from
5997 @c intdoc.texi, which in turn is automatically generated
5998 @c from the internal g77 tables in intrin.def _and_ the
5999 @c largely hand-written text in intdoc.h. So, if you want
6000 @c to change or add to existing documentation on intrinsics,
6001 @c you probably want to edit intdoc.h.
6013 @include intdoc.texi
6015 @node Scope and Classes of Names
6016 @section Scope and Classes of Symbolic Names
6017 @cindex symbol names, scope and classes
6020 (The following information augments or overrides the information in
6021 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
6023 Chapter 18 of that document otherwise serves as the basis
6024 for the relevant aspects of GNU Fortran.)
6027 * Underscores in Symbol Names::
6030 @node Underscores in Symbol Names
6031 @subsection Underscores in Symbol Names
6034 Underscores (@samp{_}) are accepted in symbol names after the first
6035 character (which must be a letter).
6041 A dollar sign at the end of an output format specification suppresses
6042 the newline at the end of the output.
6044 @cindex <> edit descriptor
6045 @cindex edit descriptor, <>
6046 Edit descriptors in @code{FORMAT} statements may contain compile-time
6047 @code{INTEGER} constant expressions in angle brackets, such as
6049 10 FORMAT (I<WIDTH>)
6052 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
6054 These Fortran 90 features are supported:
6057 @cindex FORMAT descriptors
6058 @cindex Z edit descriptor
6059 @cindex edit descriptor, Z
6060 @cindex O edit descriptor
6061 @cindex edit descriptor, O
6062 The @code{O} and @code{Z} edit descriptors are supported for I/O of
6063 integers in octal and hexadecimal formats, respectively.
6065 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6066 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
6067 specifier is supported.
6070 @node Fortran 90 Features
6071 @section Fortran 90 Features
6073 @cindex extensions, from Fortran 90
6075 For convenience this section collects a list (probably incomplete) of
6076 the Fortran 90 features supported by the GNU Fortran language, even if
6077 they are documented elsewhere.
6078 @xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
6079 for information on additional fixed source form lexical issues.
6080 @cindex @samp{-ffree-form}
6081 Further, the free source form is supported through the
6082 @samp{-ffree-form} option.
6083 @cindex @samp{-ff90}
6084 Other Fortran 90 features can be turned on by the @samp{-ff90} option;
6085 see @ref{Fortran 90}.
6086 For information on the Fortran 90 intrinsics available,
6087 see @ref{Table of Intrinsic Functions}.
6090 @item Automatic arrays in procedures
6091 @item Character assignments
6092 @cindex character assignments
6093 In character assignments, the variable being assigned may occur on the
6094 right hand side of the assignment.
6095 @item Character strings
6096 @cindex double quoted character constants
6097 Strings may have zero length and substrings of character constants are
6098 permitted. Character constants may be enclosed in double quotes
6099 (@code{"}) as well as single quotes. @xref{Character Type}.
6100 @item Construct names
6101 (Symbolic tags on blocks.) @xref{Construct Names}.
6102 @item @code{CYCLE} and @code{EXIT}
6103 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
6104 @item @code{DOUBLE COMPLEX}
6105 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
6106 @item @code{DO WHILE}
6108 @item @code{END} decoration
6113 @item @code{IMPLICIT NONE}
6114 @item @code{INCLUDE} statements
6116 @item List-directed and namelist I/O on internal files
6117 @item Binary, octal and hexadecimal constants
6118 These are supported more generally than required by Fortran 90.
6119 @xref{Integer Type}.
6120 @item @samp{O} and @samp{Z} edit descriptors
6121 @item @code{NAMELIST}
6123 @item @code{OPEN} specifiers
6124 @code{STATUS='REPLACE'} is supported.
6125 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6126 @code{STATUS='SCRATCH'} is supplied.
6127 @item @code{FORMAT} edit descriptors
6128 @cindex FORMAT descriptors
6129 @cindex Z edit descriptor
6130 @cindex edit descriptor, Z
6131 The @code{Z} edit descriptor is supported.
6132 @item Relational operators
6133 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
6134 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
6135 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
6136 @item @code{SELECT CASE}
6137 Not fully implemented.
6138 @xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
6139 @item Specification statements
6140 A limited subset of the Fortran 90 syntax and semantics for variable
6141 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
6142 (@code{KIND} is of limited usefulness in the absence of the
6143 @code{KIND}-related intrinsics, since these intrinsics permit writing
6144 more widely portable code.) An example of supported @code{KIND} usage
6147 INTEGER (KIND=1) :: FOO=1, BAR=2
6148 CHARACTER (LEN=3) FOO
6150 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
6153 @node Other Dialects
6154 @chapter Other Dialects
6156 GNU Fortran supports a variety of features that are not
6157 considered part of the GNU Fortran language itself, but
6158 are representative of various dialects of Fortran that
6159 @code{g77} supports in whole or in part.
6161 Any of the features listed below might be disallowed by
6162 @code{g77} unless some command-line option is specified.
6163 Currently, some of the features are accepted using the
6164 default invocation of @code{g77}, but that might change
6167 @emph{Note: This portion of the documentation definitely needs a lot
6171 * Source Form:: Details of fixed-form and free-form source.
6172 * Trailing Comment:: Use of @samp{/*} to start a comment.
6173 * Debug Line:: Use of @samp{D} in column 1.
6174 * Dollar Signs:: Use of @samp{$} in symbolic names.
6175 * Case Sensitivity:: Uppercase and lowercase in source files.
6176 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6177 * Fortran 90:: @dots{}versus the GNU Fortran language.
6178 * Pedantic Compilation:: Enforcing the standard.
6179 * Distensions:: Misfeatures supported by GNU Fortran.
6183 @section Source Form
6184 @cindex source file format
6185 @cindex source format
6186 @cindex file, source
6188 @cindex code, source
6192 GNU Fortran accepts programs written in either fixed form or
6196 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6197 allowing tabs) and Fortran 90's fixed form.
6199 Free form corresponds to
6200 Fortran 90's free form (though possibly not entirely up-to-date, and
6201 without complaining about some things that for which Fortran 90 requires
6202 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6204 The way a Fortran compiler views source files depends entirely on the
6205 implementation choices made for the compiler, since those choices
6206 are explicitly left to the implementation by the published Fortran
6208 GNU Fortran currently tries to be somewhat like a few popular compilers
6209 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6210 definition along with more
6211 flexibility offered by command-line options is likely to be offered
6214 This section describes how @code{g77} interprets source lines.
6217 * Carriage Returns:: Carriage returns ignored.
6218 * Tabs:: Tabs converted to spaces.
6219 * Short Lines:: Short lines padded with spaces (fixed-form only).
6220 * Long Lines:: Long lines truncated.
6221 * Ampersands:: Special Continuation Lines.
6224 @node Carriage Returns
6225 @subsection Carriage Returns
6226 @cindex carriage returns
6228 Carriage returns (@samp{\r}) in source lines are ignored.
6229 This is somewhat different from @code{f2c}, which seems to treat them as
6230 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6231 inside such constants.
6235 @cindex tab character
6236 @cindex horizontal tab
6238 A source line with a @key{TAB} character anywhere in it is treated as
6239 entirely significant---however long it is---instead of ending in
6240 column 72 (for fixed-form source) or 132 (for free-form source).
6241 This also is different from @code{f2c}, which encodes tabs as
6242 @samp{\t} (the ASCII @key{TAB} character) inside character
6243 and Hollerith constants, but nevertheless seems to treat the column
6244 position as if it had been affected by the canonical tab positioning.
6246 @code{g77} effectively
6247 translates tabs to the appropriate number of spaces (a la the default
6248 for the UNIX @code{expand} command) before doing any other processing, other
6249 than (currently) noting whether a tab was found on a line and using this
6250 information to decide how to interpret the length of the line and continued
6253 Note that this default behavior probably will change for version 0.6,
6254 when it will presumably be available via a command-line option.
6255 The default as of version 0.6 is planned to be a ``pure visual''
6256 model, where tabs are immediately
6257 converted to spaces and otherwise have no effect, so the way a typical
6258 user sees source lines produces a consistent result no matter how the
6259 spacing in those source lines is actually implemented via tabs, spaces,
6260 and trailing tabs/spaces before newline.
6261 Command-line options are likely to be added to specify whether all or
6262 just-tabbed lines are to be extended to 132 or full input-line length,
6263 and perhaps even an option will be added to specify the truncated-line
6264 behavior to which some Digital compilers default (and which affects
6265 the way continued character/Hollerith constants are interpreted).
6268 @subsection Short Lines
6269 @cindex short source lines
6270 @cindex space, padding with
6271 @cindex source lines, short
6272 @cindex lines, short
6274 Source lines shorter than the applicable fixed-form length are treated as
6275 if they were padded with spaces to that length.
6276 (None of this is relevant to source files written in free form.)
6279 continued character and Hollerith constants, and is a different
6280 interpretation than provided by some other popular compilers
6281 (although a bit more consistent with the traditional punched-card
6282 basis of Fortran and the way the Fortran standard expressed fixed
6285 @code{g77} might someday offer an option to warn about cases where differences
6286 might be seen as a result of this treatment, and perhaps an option to
6287 specify the alternate behavior as well.
6289 Note that this padding cannot apply to lines that are effectively of
6290 infinite length---such lines are specified using command-line options
6291 like @samp{-ffixed-line-length-none}, for example.
6294 @subsection Long Lines
6295 @cindex long source lines
6296 @cindex truncation, of long lines
6298 @cindex source lines, long
6300 Source lines longer than the applicable length are truncated to that
6302 Currently, @code{g77} does not warn if the truncated characters are
6303 not spaces, to accommodate existing code written for systems that
6304 treated truncated text as commentary (especially in columns 73 through 80).
6306 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6307 for information on the @samp{-ffixed-line-length-@var{n}} option,
6308 which can be used to set the line length applicable to fixed-form
6312 @subsection Ampersand Continuation Line
6313 @cindex ampersand continuation line
6314 @cindex continuation line, ampersand
6316 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6317 continuation line, imitating the behavior of @code{f2c}.
6319 @node Trailing Comment
6320 @section Trailing Comment
6322 @cindex trailing comment
6324 @cindex characters, comment
6327 @cindex exclamation point
6328 @code{g77} supports use of @samp{/*} to start a trailing
6330 In the GNU Fortran language, @samp{!} is used for this purpose.
6332 @samp{/*} is not in the GNU Fortran language
6333 because the use of @samp{/*} in a program might
6334 suggest to some readers that a block, not trailing, comment is
6335 started (and thus ended by @samp{*/}, not end of line),
6336 since that is the meaning of @samp{/*} in C.
6338 Also, such readers might think they can use @samp{//} to start
6339 a trailing comment as an alternative to @samp{/*}, but
6340 @samp{//} already denotes concatenation, and such a ``comment''
6341 might actually result in a program that compiles without
6342 error (though it would likely behave incorrectly).
6347 @cindex comment line, debug
6349 Use of @samp{D} or @samp{d} as the first character (column 1) of
6350 a source line denotes a debug line.
6352 In turn, a debug line is treated as either a comment line
6353 or a normal line, depending on whether debug lines are enabled.
6355 When treated as a comment line, a line beginning with @samp{D} or
6356 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6357 When treated as a normal line, such a line is treated as if
6358 the first character was @key{SPC} (space).
6360 (Currently, @code{g77} provides no means for treating debug
6361 lines as normal lines.)
6364 @section Dollar Signs in Symbol Names
6368 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6369 when the @samp{-fdollar-ok} option is specified.
6371 @node Case Sensitivity
6372 @section Case Sensitivity
6373 @cindex case sensitivity
6374 @cindex source file format
6375 @cindex code, source
6377 @cindex uppercase letters
6378 @cindex lowercase letters
6379 @cindex letters, uppercase
6380 @cindex letters, lowercase
6382 GNU Fortran offers the programmer way too much flexibility in deciding
6383 how source files are to be treated vis-a-vis uppercase and lowercase
6385 There are 66 useful settings that affect case sensitivity, plus 10
6386 settings that are nearly useless, with the remaining 116 settings
6387 being either redundant or useless.
6389 None of these settings have any effect on the contents of comments
6390 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6391 or of character or Hollerith constants.
6392 Note that things like the @samp{E} in the statement
6393 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6394 are considered built-in keywords, and so are affected by
6397 Low-level switches are identified in this section as follows:
6401 Source Case Conversion:
6405 Preserve (see Note 1)
6407 Convert to Upper Case
6409 Convert to Lower Case
6413 Built-in Keyword Matching:
6417 Match Any Case (per-character basis)
6419 Match Upper Case Only
6421 Match Lower Case Only
6423 Match InitialCaps Only (see tables for spellings)
6427 Built-in Intrinsic Matching:
6431 Match Any Case (per-character basis)
6433 Match Upper Case Only
6435 Match Lower Case Only
6437 Match InitialCaps Only (see tables for spellings)
6441 User-defined Symbol Possibilities (warnings only):
6445 Allow Any Case (per-character basis)
6447 Allow Upper Case Only
6449 Allow Lower Case Only
6451 Allow InitialCaps Only (see Note 2)
6455 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6456 consistent with these source switches---in the sense that input will be
6457 expected to meet the same requirements as source code in terms
6458 of matching symbol names and keywords (for the exponent letters).
6460 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6461 which uppercases @code{NAMELIST} input and symbol names for matching.
6462 This means not only that @code{NAMELIST} output currently shows symbol
6463 (and keyword) names in uppercase even if lower-case source
6464 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6465 adequately supported when source case preservation (option A0)
6468 If A0 is selected, a warning message will be
6469 output for each @code{NAMELIST} statement to this effect.
6471 of the program is undefined at run time if two or more symbol names
6472 appear in a given @code{NAMELIST} such that the names are identical
6473 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6474 For complete and total elegance, perhaps there should be a warning
6475 when option A2 is selected, since the output of NAMELIST is currently
6476 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6477 but that seems to be overkill for a product in beta test.
6479 Note 2: Rules for InitialCaps names are:
6483 Must be a single uppercase letter, @strong{or}
6485 Must start with an uppercase letter and contain at least one
6489 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6490 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6492 Note that most, but not all, built-in names meet these
6493 requirements---the exceptions are some of the two-letter format
6494 specifiers, such as @code{BN} and @code{BZ}.
6496 Here are the names of the corresponding command-line options:
6499 A0: -fsource-case-preserve
6500 A1: -fsource-case-upper
6501 A2: -fsource-case-lower
6503 B0: -fmatch-case-any
6504 B1: -fmatch-case-upper
6505 B2: -fmatch-case-lower
6506 B3: -fmatch-case-initcap
6508 C0: -fintrin-case-any
6509 C1: -fintrin-case-upper
6510 C2: -fintrin-case-lower
6511 C3: -fintrin-case-initcap
6513 D0: -fsymbol-case-any
6514 D1: -fsymbol-case-upper
6515 D2: -fsymbol-case-lower
6516 D3: -fsymbol-case-initcap
6519 Useful combinations of the above settings, along with abbreviated
6520 option names that set some of these combinations all at once:
6523 1: A0-- B0--- C0--- D0--- -fcase-preserve
6524 2: A0-- B0--- C0--- D-1--
6525 3: A0-- B0--- C0--- D--2-
6526 4: A0-- B0--- C0--- D---3
6527 5: A0-- B0--- C-1-- D0---
6528 6: A0-- B0--- C-1-- D-1--
6529 7: A0-- B0--- C-1-- D--2-
6530 8: A0-- B0--- C-1-- D---3
6531 9: A0-- B0--- C--2- D0---
6532 10: A0-- B0--- C--2- D-1--
6533 11: A0-- B0--- C--2- D--2-
6534 12: A0-- B0--- C--2- D---3
6535 13: A0-- B0--- C---3 D0---
6536 14: A0-- B0--- C---3 D-1--
6537 15: A0-- B0--- C---3 D--2-
6538 16: A0-- B0--- C---3 D---3
6539 17: A0-- B-1-- C0--- D0---
6540 18: A0-- B-1-- C0--- D-1--
6541 19: A0-- B-1-- C0--- D--2-
6542 20: A0-- B-1-- C0--- D---3
6543 21: A0-- B-1-- C-1-- D0---
6544 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6545 23: A0-- B-1-- C-1-- D--2-
6546 24: A0-- B-1-- C-1-- D---3
6547 25: A0-- B-1-- C--2- D0---
6548 26: A0-- B-1-- C--2- D-1--
6549 27: A0-- B-1-- C--2- D--2-
6550 28: A0-- B-1-- C--2- D---3
6551 29: A0-- B-1-- C---3 D0---
6552 30: A0-- B-1-- C---3 D-1--
6553 31: A0-- B-1-- C---3 D--2-
6554 32: A0-- B-1-- C---3 D---3
6555 33: A0-- B--2- C0--- D0---
6556 34: A0-- B--2- C0--- D-1--
6557 35: A0-- B--2- C0--- D--2-
6558 36: A0-- B--2- C0--- D---3
6559 37: A0-- B--2- C-1-- D0---
6560 38: A0-- B--2- C-1-- D-1--
6561 39: A0-- B--2- C-1-- D--2-
6562 40: A0-- B--2- C-1-- D---3
6563 41: A0-- B--2- C--2- D0---
6564 42: A0-- B--2- C--2- D-1--
6565 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6566 44: A0-- B--2- C--2- D---3
6567 45: A0-- B--2- C---3 D0---
6568 46: A0-- B--2- C---3 D-1--
6569 47: A0-- B--2- C---3 D--2-
6570 48: A0-- B--2- C---3 D---3
6571 49: A0-- B---3 C0--- D0---
6572 50: A0-- B---3 C0--- D-1--
6573 51: A0-- B---3 C0--- D--2-
6574 52: A0-- B---3 C0--- D---3
6575 53: A0-- B---3 C-1-- D0---
6576 54: A0-- B---3 C-1-- D-1--
6577 55: A0-- B---3 C-1-- D--2-
6578 56: A0-- B---3 C-1-- D---3
6579 57: A0-- B---3 C--2- D0---
6580 58: A0-- B---3 C--2- D-1--
6581 59: A0-- B---3 C--2- D--2-
6582 60: A0-- B---3 C--2- D---3
6583 61: A0-- B---3 C---3 D0---
6584 62: A0-- B---3 C---3 D-1--
6585 63: A0-- B---3 C---3 D--2-
6586 64: A0-- B---3 C---3 D---3 -fcase-initcap
6587 65: A-1- B01-- C01-- D01-- -fcase-upper
6588 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6591 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6592 (except comments, character constants, and Hollerith strings) must
6593 be entered in uppercase.
6594 Use @samp{-fcase-strict-upper} to specify this
6597 Number 43 is like Number 22 except all input must be lowercase. Use
6598 @samp{-fcase-strict-lower} to specify this combination.
6600 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6601 non-UNIX machines whereby all the source is translated to uppercase.
6602 Use @samp{-fcase-upper} to specify this combination.
6604 Number 66 is the ``canonical'' UNIX model whereby all the source is
6605 translated to lowercase.
6606 Use @samp{-fcase-lower} to specify this combination.
6608 There are a few nearly useless combinations:
6611 67: A-1- B01-- C01-- D--2-
6612 68: A-1- B01-- C01-- D---3
6613 69: A-1- B01-- C--23 D01--
6614 70: A-1- B01-- C--23 D--2-
6615 71: A-1- B01-- C--23 D---3
6616 72: A--2 B01-- C0-2- D-1--
6617 73: A--2 B01-- C0-2- D---3
6618 74: A--2 B01-- C-1-3 D0-2-
6619 75: A--2 B01-- C-1-3 D-1--
6620 76: A--2 B01-- C-1-3 D---3
6623 The above allow some programs to be compiled but with restrictions that
6624 make most useful programs impossible: Numbers 67 and 72 warn about
6625 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6627 68 and 73 warn about any user-defined symbol names longer than one
6628 character that don't have at least one non-alphabetic character after
6630 Numbers 69 and 74 disallow any references to intrinsics;
6631 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6632 67+69, 68+69, 72+74, and 73+74, respectively.
6634 All redundant combinations are shown in the above tables anyplace
6635 where more than one setting is shown for a low-level switch.
6636 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6637 The ``proper'' setting in such a case is the one that copies the setting
6638 of switch A---any other setting might slightly reduce the speed of
6639 the compiler, though possibly to an unmeasurable extent.
6641 All remaining combinations are useless in that they prevent successful
6642 compilation of non-null source files (source files with something other
6646 @section VXT Fortran
6648 @cindex VXT extensions
6649 @cindex extensions, VXT
6650 @code{g77} supports certain constructs that
6651 have different meanings in VXT Fortran than they
6652 do in the GNU Fortran language.
6654 Generally, this manual uses the invented term VXT Fortran to refer
6655 VAX FORTRAN (circa v4).
6656 That compiler offered many popular features, though not necessarily
6657 those that are specific to the VAX processor architecture,
6658 the VMS operating system,
6659 or Digital Equipment Corporation's Fortran product line.
6660 (VAX and VMS probably are trademarks of Digital Equipment
6663 An extension offered by a Digital Fortran product that also is
6664 offered by several other Fortran products for different kinds of
6665 systems is probably going to be considered for inclusion in @code{g77}
6666 someday, and is considered a VXT Fortran feature.
6668 The @samp{-fvxt} option generally specifies that, where
6669 the meaning of a construct is ambiguous (means one thing
6670 in GNU Fortran and another in VXT Fortran), the VXT Fortran
6671 meaning is to be assumed.
6674 * Double Quote Meaning:: @samp{"2000} as octal constant.
6675 * Exclamation Point:: @samp{!} in column 6.
6678 @node Double Quote Meaning
6679 @subsection Meaning of Double Quote
6680 @cindex double quotes
6681 @cindex character constants
6682 @cindex constants, character
6683 @cindex octal constants
6684 @cindex constants, octal
6686 @code{g77} treats double-quote (@samp{"})
6687 as beginning an octal constant of @code{INTEGER(KIND=1)} type
6688 when the @samp{-fvxt} option is specified.
6689 The form of this octal constant is
6696 where @var{octal-digits} is a nonempty string of characters in
6697 the set @samp{01234567}.
6699 For example, the @samp{-fvxt} option permits this:
6707 The above program would print the value @samp{16}.
6709 @xref{Integer Type}, for information on the preferred construct
6710 for integer constants specified using GNU Fortran's octal notation.
6712 (In the GNU Fortran language, the double-quote character (@samp{"})
6713 delimits a character constant just as does apostrophe (@samp{'}).
6714 There is no way to allow
6715 both constructs in the general case, since statements like
6716 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
6718 @node Exclamation Point
6719 @subsection Meaning of Exclamation Point in Column 6
6721 @cindex exclamation point
6722 @cindex continuation character
6723 @cindex characters, continuation
6724 @cindex comment character
6725 @cindex characters, comment
6727 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
6728 a fixed-form source file
6729 as a continuation character rather than
6730 as the beginning of a comment
6731 (as it does in any other column)
6732 when the @samp{-fvxt} option is specified.
6734 The following program, when run, prints a message indicating
6735 whether it is interpreted according to GNU Fortran (and Fortran 90)
6736 rules or VXT Fortran rules:
6739 C234567 (This line begins in column 1.)
6742 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
6743 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
6744 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
6748 (In the GNU Fortran and Fortran 90 languages, exclamation point is
6749 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
6750 marks a line as a continuation line when it appears in column 6.)
6754 @cindex compatibility, Fortran 90
6755 @cindex Fortran 90, compatibility
6757 The GNU Fortran language includes a number of features that are
6758 part of Fortran 90, even when the @samp{-ff90} option is not specified.
6759 The features enabled by @samp{-ff90} are intended to be those that,
6760 when @samp{-ff90} is not specified, would have another
6761 meaning to @code{g77}---usually meaning something invalid in the
6762 GNU Fortran language.
6764 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
6765 to gratuitously reject Fortran 90 constructs.
6766 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
6767 to do that, although its implementation is certainly incomplete at
6770 When @samp{-ff90} is specified:
6774 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
6775 where @var{expr} is @code{COMPLEX} type,
6776 is the same type as the real part of @var{expr}.
6778 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
6779 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
6780 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
6783 @node Pedantic Compilation
6784 @section Pedantic Compilation
6785 @cindex pedantic compilation
6786 @cindex compilation, pedantic
6788 The @samp{-fpedantic} command-line option specifies that @code{g77}
6789 is to warn about code that is not standard-conforming.
6790 This is useful for finding
6791 some extensions @code{g77} accepts that other compilers might not accept.
6792 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
6793 always imply @samp{-fpedantic}.)
6795 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
6796 for conforming code.
6797 With @samp{-ff90} in force, Fortran 90 is used.
6799 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
6800 and @samp{-fno-f90} are in force are:
6804 Automatic arrays, as in
6813 where @samp{A} is not listed in any @code{ENTRY} statement,
6814 and thus is not a dummy argument.
6817 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
6819 These commas are disallowed by FORTRAN 77, but, while strictly
6820 superfluous, are syntactically elegant,
6821 especially given that commas are required in statements such
6822 as @samp{READ 99, I} and @samp{PRINT *, J}.
6823 Many compilers permit the superfluous commas for this reason.
6826 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
6828 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
6829 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
6831 An example of an implicit use is the expression @samp{C*D},
6832 where @samp{C} is @code{COMPLEX(KIND=1)}
6833 and @samp{D} is @code{DOUBLE PRECISION}.
6834 This expression is prohibited by ANSI FORTRAN 77
6835 because the rules of promotion would suggest that it
6836 produce a @code{DOUBLE COMPLEX} result---a type not
6837 provided for by that standard.
6840 Automatic conversion of numeric
6841 expressions to @code{INTEGER(KIND=1)} in contexts such as:
6845 Array-reference indexes.
6847 Alternate-return values.
6849 Computed @code{GOTO}.
6851 @code{FORMAT} run-time expressions (not yet supported).
6853 Dimension lists in specification statements.
6855 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
6857 Sizes of @code{CHARACTER} entities in specification statements.
6859 Kind types in specification entities (a Fortran 90 feature).
6861 Initial, terminal, and incrementation parameters for implied-@code{DO}
6862 constructs in @code{DATA} statements.
6866 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
6867 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
6868 expressions are disallowed anyway).
6871 Zero-size array dimensions, as in:
6874 INTEGER I(10,20,4:2)
6878 Zero-length @code{CHARACTER} entities, as in:
6885 Substring operators applied to character constants and named
6889 PRINT *, 'hello'(3:5)
6893 Null arguments passed to statement function, as in:
6900 Disagreement among program units regarding whether a given @code{COMMON}
6901 area is @code{SAVE}d (for targets where program units in a single source
6902 file are ``glued'' together as they typically are for UNIX development
6906 Disagreement among program units regarding the size of a
6907 named @code{COMMON} block.
6910 Specification statements following first @code{DATA} statement.
6912 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
6913 but not @samp{INTEGER I}.
6914 The @samp{-fpedantic} option disallows both of these.)
6917 Semicolon as statement separator, as in:
6924 @c Comma before list of I/O items in @code{WRITE}
6925 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
6926 @c statements, as with @code{READ} (as explained above).
6929 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
6932 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
6936 Expressions having two arithmetic operators in a row, such
6940 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
6941 following constructs result in diagnostics:
6945 Use of semicolon as a statement separator on a line
6946 that has an @code{INCLUDE} directive.
6950 @section Distensions
6952 @cindex ugly features
6953 @cindex features, ugly
6955 The @samp{-fugly-*} command-line options determine whether certain
6956 features supported by VAX FORTRAN and other such compilers, but considered
6957 too ugly to be in code that can be changed to use safer and/or more
6958 portable constructs, are accepted.
6959 These are humorously referred to as ``distensions'',
6960 extensions that just plain look ugly in the harsh light of day.
6963 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
6964 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
6965 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
6966 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
6967 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
6968 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
6969 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
6972 @node Ugly Implicit Argument Conversion
6973 @subsection Implicit Argument Conversion
6974 @cindex Hollerith constants
6975 @cindex constants, Hollerith
6977 The @samp{-fno-ugly-args} option disables
6978 passing typeless and Hollerith constants as actual arguments
6979 in procedure invocations.
6988 These constructs can be too easily used to create non-portable
6989 code, but are not considered as ``ugly'' as others.
6990 Further, they are widely used in existing Fortran source code
6991 in ways that often are quite portable.
6992 Therefore, they are enabled by default.
6994 @node Ugly Assumed-Size Arrays
6995 @subsection Ugly Assumed-Size Arrays
6996 @cindex arrays, assumed-size
6997 @cindex assumed-size arrays
6998 @cindex DIMENSION X(1)
7000 The @samp{-fugly-assumed} option enables
7001 the treatment of any array with a final dimension specified as @samp{1}
7002 as an assumed-size array, as if @samp{*} had been specified
7005 For example, @samp{DIMENSION X(1)} is treated as if it
7006 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
7007 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
7008 or @code{ENTRY} statement in the same program unit.
7010 Use an explicit lower bound to avoid this interpretation.
7011 For example, @samp{DIMENSION X(1:1)} is never treated as if
7012 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
7013 Nor is @samp{DIMENSION X(2-1)} affected by this option,
7014 since that kind of expression is unlikely to have been
7015 intended to designate an assumed-size array.
7017 This option is used to prevent warnings being issued about apparent
7018 out-of-bounds reference such as @samp{X(2) = 99}.
7020 It also prevents the array from being used in contexts that
7021 disallow assumed-size arrays, such as @samp{PRINT *,X}.
7022 In such cases, a diagnostic is generated and the source file is
7025 The construct affected by this option is used only in old code
7026 that pre-exists the widespread acceptance of adjustable and assumed-size
7027 arrays in the Fortran community.
7029 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
7030 treated if @samp{X} is listed as a dummy argument only
7031 @emph{after} the @code{DIMENSION} statement (presumably in
7032 an @code{ENTRY} statement).
7033 For example, @samp{-fugly-assumed} has no effect on the
7034 following program unit:
7045 @node Ugly Complex Part Extraction
7046 @subsection Ugly Complex Part Extraction
7047 @cindex complex values
7049 @cindex imaginary part
7051 The @samp{-fugly-complex} option enables
7052 use of the @code{REAL()} and @code{AIMAG()}
7053 intrinsics with arguments that are
7054 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
7056 With @samp{-ff90} in effect, these intrinsics return
7057 the unconverted real and imaginary parts (respectively)
7060 With @samp{-fno-f90} in effect, these intrinsics convert
7061 the real and imaginary parts to @code{REAL(KIND=1)}, and return
7062 the result of that conversion.
7064 Due to this ambiguity, the GNU Fortran language defines
7065 these constructs as invalid, except in the specific
7066 case where they are entirely and solely passed as an
7067 argument to an invocation of the @code{REAL()} intrinsic.
7075 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7076 and @samp{-fno-ugly-complex} is in effect, because the
7079 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7080 is specified, in which case the appropriate interpretation is
7081 chosen and no diagnostic is issued.
7083 @xref{CMPAMBIG}, for information on how to cope with existing
7084 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7085 with @code{COMPLEX(KIND=2)} arguments.
7087 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7088 intrinsic, used to extract the real part of a complex expression
7090 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7091 intrinsic, used to extract the imaginary part of a complex expression
7094 @node Ugly Null Arguments
7095 @subsection Ugly Null Arguments
7096 @cindex trailing comma
7097 @cindex comma, trailing
7098 @cindex characters, comma
7099 @cindex null arguments
7100 @cindex arguments, null
7102 The @samp{-fugly-comma} option enables use of a single trailing comma
7103 to mean ``pass an extra trailing null argument''
7104 in a list of actual arguments to an external procedure,
7105 and use of an empty list of arguments to such a procedure
7106 to mean ``pass a single null argument''.
7108 @cindex omitting arguments
7109 @cindex arguments, omitting
7110 (Null arguments often are used in some procedure-calling
7111 schemes to indicate omitted arguments.)
7113 For example, @samp{CALL FOO(,)} means ``pass
7114 two null arguments'', rather than ``pass one null argument''.
7115 Also, @samp{CALL BAR()} means ``pass one null argument''.
7117 This construct is considered ``ugly'' because it does not
7118 provide an elegant way to pass a single null argument
7119 that is syntactically distinct from passing no arguments.
7120 That is, this construct changes the meaning of code that
7121 makes no use of the construct.
7123 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7124 and @samp{I = JFUNC()} pass a single null argument, instead
7125 of passing no arguments as required by the Fortran 77 and
7128 @emph{Note:} Many systems gracefully allow the case
7129 where a procedure call passes one extra argument that the
7130 called procedure does not expect.
7132 So, in practice, there might be no difference in
7133 the behavior of a program that does @samp{CALL FOO()}
7134 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7135 in force as compared to its behavior when compiled
7136 with the default, @samp{-fno-ugly-comma}, in force,
7137 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7138 arguments to be passed.
7140 @node Ugly Conversion of Initializers
7141 @subsection Ugly Conversion of Initializers
7143 The constructs disabled by @samp{-fno-ugly-init} are:
7146 @cindex Hollerith constants
7147 @cindex constants, Hollerith
7149 Use of Hollerith and typeless constants in contexts where they set
7150 initial (compile-time) values for variables, arrays, and named
7151 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7152 type-declaration statements specifying initial values.
7154 Here are some sample initializations that are disabled by the
7155 @samp{-fno-ugly-init} option:
7158 PARAMETER (VAL='9A304FFE'X)
7159 REAL*8 STRING/8HOUTPUT00/
7163 @cindex character constants
7164 @cindex constants, character
7166 In the same contexts as above, use of character constants to initialize
7167 numeric items and vice versa (one constant per item).
7169 Here are more sample initializations that are disabled by the
7170 @samp{-fno-ugly-init} option:
7175 PARAMETER (IA = 'A')
7176 PARAMETER (BELL = 7)
7180 Use of Hollerith and typeless constants on the right-hand side
7181 of assignment statements to numeric types, and in other
7182 contexts (such as passing arguments in invocations of
7183 intrinsic procedures and statement functions) that
7184 are treated as assignments to known types (the dummy
7185 arguments, in these cases).
7187 Here are sample statements that are disabled by the
7188 @samp{-fno-ugly-init} option:
7192 PRINT *, IMAX0(2HAB, 2HBA)
7196 The above constructs, when used,
7197 can tend to result in non-portable code.
7198 But, they are widely used in existing Fortran code in ways
7199 that often are quite portable.
7200 Therefore, they are enabled by default.
7202 @node Ugly Integer Conversions
7203 @subsection Ugly Integer Conversions
7205 The constructs enabled via @samp{-fugly-logint} are:
7209 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7211 context (typically implies nonportable dependencies on how a
7212 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7215 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7219 The above constructs are disabled by default because use
7220 of them tends to lead to non-portable code.
7221 Even existing Fortran code that uses that often turns out
7222 to be non-portable, if not outright buggy.
7224 Some of this is due to differences among implementations as
7225 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7226 @code{INTEGER} values---Fortran code that assumes a particular
7227 coding is likely to use one of the above constructs, and is
7228 also likely to not work correctly on implementations using
7229 different encodings.
7231 @xref{Equivalence Versus Equality}, for more information.
7233 @node Ugly Assigned Labels
7234 @subsection Ugly Assigned Labels
7235 @cindex ASSIGN statement
7236 @cindex statements, ASSIGN
7237 @cindex assigned labels
7240 The @samp{-fugly-assign} option forces @code{g77} to use the
7241 same storage for assigned labels as it would for a normal
7242 assignment to the same variable.
7244 For example, consider the following code fragment:
7252 Normally, for portability and improved diagnostics, @code{g77}
7253 reserves distinct storage for a ``sibling'' of @samp{I}, used
7254 only for @code{ASSIGN} statements to that variable (along with
7255 the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
7256 statements that reference the variable).
7258 However, some code (that violates the ANSI FORTRAN 77 standard)
7259 attempts to copy assigned labels among variables involved with
7260 @code{ASSIGN} statements, as in:
7271 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7272 is specified on the command-line, ensuring that the value of @code{I}
7273 referenced in the second line is whatever value @code{g77} uses
7274 to designate statement label @samp{10}, so the value may be
7275 copied into the @samp{ISTATE} array, later retrieved into a
7276 variable of the appropriate type (@samp{J}), and used as the target of
7277 an assigned-@code{GOTO} statement.
7279 @emph{Note:} To avoid subtle program bugs,
7280 when @samp{-fugly-assign} is specified,
7281 @code{g77} requires the type of variables
7282 specified in assigned-label contexts
7283 @emph{must} be the same type returned by @code{%LOC()}.
7284 On many systems, this type is effectively the same
7285 as @code{INTEGER(KIND=1)}, while, on others, it is
7286 effectively the same as @code{INTEGER(KIND=2)}.
7288 Do @emph{not} depend on @code{g77} actually writing valid pointers
7289 to these variables, however.
7290 While @code{g77} currently chooses that implementation, it might
7291 be changed in the future.
7293 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7294 for implementation details on assigned-statement labels.
7297 @chapter The GNU Fortran Compiler
7299 The GNU Fortran compiler, @code{g77}, supports programs written
7300 in the GNU Fortran language and in some other dialects of Fortran.
7302 Some aspects of how @code{g77} works are universal regardless
7303 of dialect, and yet are not properly part of the GNU Fortran
7305 These are described below.
7307 @emph{Note: This portion of the documentation definitely needs a lot
7312 * Run-time Environment Limits::
7314 * Compiler Constants::
7315 * Compiler Intrinsics::
7318 @node Compiler Limits
7319 @section Compiler Limits
7320 @cindex limits, compiler
7321 @cindex compiler limits
7323 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7324 on lengths of identifiers, number of continuation lines, number of external
7325 symbols in a program, and so on.
7327 @cindex options, -Nl
7329 @cindex options, -Nx
7331 @cindex limits, continuation lines
7332 @cindex limits, lengths of names
7333 For example, some other Fortran compiler have an option
7334 (such as @samp{-Nl@var{x}}) to increase the limit on the
7335 number of continuation lines.
7336 Also, some Fortran compilation systems have an option
7337 (such as @samp{-Nx@var{x}}) to increase the limit on the
7338 number of external symbols.
7340 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7341 no equivalent options, since they do not impose arbitrary
7342 limits in these areas.
7344 @cindex rank, maximum
7345 @cindex maximum rank
7346 @cindex number of dimensions, maximum
7347 @cindex maximum number of dimensions
7348 @cindex limits, rank
7349 @cindex limits, array dimensions
7350 @code{g77} does currently limit the number of dimensions in an array
7351 to the same degree as do the Fortran standards---seven (7).
7352 This restriction might be lifted in a future version.
7354 @node Run-time Environment Limits
7355 @section Run-time Environment Limits
7356 @cindex limits, run-time library
7359 As a portable Fortran implementation,
7360 @code{g77} offers its users direct access to,
7361 and otherwise depends upon,
7362 the underlying facilities of the system
7363 used to build @code{g77},
7364 the system on which @code{g77} itself is used to compile programs,
7365 and the system on which the @code{g77}-compiled program is actually run.
7366 (For most users, the three systems are of the same
7367 type---combination of operating environment and hardware---often
7368 the same physical system.)
7370 The run-time environment for a particular system
7371 inevitably imposes some limits on a program's use
7372 of various system facilities.
7373 These limits vary from system to system.
7375 Even when such limits might be well beyond the
7376 possibility of being encountered on a particular system,
7377 the @code{g77} run-time environment
7378 has certain built-in limits,
7379 usually, but not always, stemming from intrinsics
7380 with inherently limited interfaces.
7382 Currently, the @code{g77} run-time environment
7383 does not generally offer a less-limiting environment
7384 by augmenting the underlying system's own environment.
7386 Therefore, code written in the GNU Fortran language,
7387 while syntactically and semantically portable,
7388 might nevertheless make non-portable assumptions
7389 about the run-time environment---assumptions that
7390 prove to be false for some particular environments.
7392 The GNU Fortran language,
7393 the @code{g77} compiler and run-time environment,
7394 and the @code{g77} documentation
7395 do not yet offer comprehensive portable work-arounds for such limits,
7396 though programmers should be able to
7397 find their own in specific instances.
7399 Not all of the limitations are described in this document.
7400 Some of the known limitations include:
7403 * Timer Wraparounds::
7404 * Year 2000 (Y2K) Problems::
7406 * Character-variable Length::
7407 * Year 10000 (Y10K) Problems::
7410 @node Timer Wraparounds
7411 @subsection Timer Wraparounds
7413 Intrinsics that return values computed from system timers,
7414 whether elapsed (wall-clock) timers,
7416 or other kinds of timers,
7417 are prone to experiencing wrap-around errors
7418 (or returning wrapped-around values from successive calls)
7419 due to insufficient ranges
7420 offered by the underlying system's timers.
7422 @cindex negative time
7425 Some of the symptoms of such behaviors include
7426 apparently negative time being computed for a duration,
7427 an extremely short amount of time being computed for a long duration,
7428 and an extremely long amount of time being computed for a short duration.
7430 See the following for intrinsics
7431 known to have potential problems in these areas
7432 on at least some systems:
7433 @ref{CPU_Time Intrinsic},
7434 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
7435 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
7436 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
7437 @ref{Secnds Intrinsic},
7438 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
7439 @ref{System_Clock Intrinsic},
7440 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
7441 @ref{Time8 Intrinsic}.
7443 @node Year 2000 (Y2K) Problems
7444 @subsection Year 2000 (Y2K) Problems
7445 @cindex Y2K compliance
7446 @cindex Year 2000 compliance
7448 While the @code{g77} compiler itself is believed to
7449 be Year-2000 (Y2K) compliant,
7450 some intrinsics are not,
7451 and, potentially, some underlying systems are not,
7452 perhaps rendering some Y2K-compliant intrinsics
7453 non-compliant when used on those particular systems.
7455 Fortran code that uses non-Y2K-compliant intrinsics
7457 is, itself, almost certainly not compliant,
7458 and should be modified to use Y2K-compliant intrinsics instead.
7460 Fortran code that uses no non-Y2K-compliant intrinsics,
7461 but which currently is running on a non-Y2K-compliant system,
7462 can be made more Y2K compliant by compiling and
7463 linking it for use on a new Y2K-compliant system,
7464 such as a new version of an old, non-Y2K-compliant, system.
7466 Currently, information on Y2K and related issues
7467 is being maintained at
7468 @uref{http://www.gnu.org/software/year2000-list.html}.
7470 See the following for intrinsics
7471 known to have potential problems in these areas
7472 on at least some systems:
7473 @ref{Date Intrinsic},
7474 @ref{IDate Intrinsic (VXT)}.
7477 @cindex date_y2kbuggy_0
7478 @cindex vxtidate_y2kbuggy_0
7479 @cindex G77_date_y2kbuggy_0
7480 @cindex G77_vxtidate_y2kbuggy_0
7481 The @code{libg2c} library
7482 shipped with any @code{g77} that warns
7483 about invocation of a non-Y2K-compliant intrinsic
7484 has renamed the @code{EXTERNAL} procedure names
7485 of those intrinsics.
7486 This is done so that
7487 the @code{libg2c} implementations of these intrinsics
7488 cannot be directly linked to
7489 as @code{EXTERNAL} names
7490 (which normally would avoid the non-Y2K-intrinsic warning).
7492 The renamed forms of the @code{EXTERNAL} names
7493 of these renamed procedures
7495 by appending the string @samp{_y2kbug}
7496 to the name of the procedure
7503 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
7504 CALL DATE_Y2KBUG (STR)
7505 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
7508 (Note that the @code{EXTERNAL} statement
7509 is not actually required,
7510 since the modified names are not recognized as intrinsics
7511 by the current version of @code{g77}.
7512 But it is shown in this specific case,
7513 for purposes of illustration.)
7515 The renaming of @code{EXTERNAL} procedure names of these intrinsics
7516 causes unresolved references at link time.
7517 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
7518 is normally compiled by @code{g77}
7519 as, in C, @samp{date_(&str, 20);}.
7520 This, in turn, links to the @code{date_} procedure
7521 in the @code{libE77} portion of @code{libg2c},
7522 which purposely calls a nonexistent procedure
7523 named @code{G77_date_y2kbuggy_0}.
7524 The resulting link-time error is designed, via this name,
7525 to encourage the programmer to look up the
7526 index entries to this portion of the @code{g77} documentation.
7528 Generally, we recommend that the @code{EXTERNAL} method
7529 of invoking procedures in @code{libg2c}
7531 When used, some of the correctness checking
7532 normally performed by @code{g77}
7535 In particular, it is probably better to use the
7536 @code{INTRINSIC} method of invoking
7537 non-Y2K-compliant procedures,
7538 so anyone compiling the code
7539 can quickly notice the potential Y2K problems
7540 (via the warnings printing by @code{g77})
7541 without having to even look at the code itself.
7543 If there are problems linking @code{libg2c}
7544 to code compiled by @code{g77}
7545 that involve the string @samp{y2kbug},
7546 and these are not explained above,
7547 that probably indicates
7548 that a version of @code{libg2c}
7549 older than @code{g77}
7551 or that the new library is being linked
7552 to code compiled by an older version of @code{g77}.
7554 That's because, as of the version that warns about
7555 non-Y2K-compliant intrinsic invocation,
7556 @code{g77} references the @code{libg2c} implementations
7558 using new names, containing the string @samp{y2kbug}.
7560 So, linking newly-compiled code
7561 (invoking one of the intrinsics in question)
7563 might yield an unresolved reference
7564 to @code{G77_date_y2kbug_0}.
7565 (The old library calls it @code{G77_date_0}.)
7567 Similarly, linking previously-compiled code
7569 might yield an unresolved reference
7570 to @code{G77_vxtidate_0}.
7571 (The new library calls it @code{G77_vxtidate_y2kbug_0}.)
7573 The proper fix for the above problems
7574 is to obtain the latest release of @code{g77}
7575 and related products
7576 (including @code{libg2c})
7577 and install them on all systems,
7578 then recompile, relink, and install
7580 all existing Fortran programs.
7582 (Normally, this sort of renaming is steadfastly avoided.
7583 In this case, however, it seems more important to highlight
7584 potential Y2K problems
7585 than to ease the transition
7586 of potentially non-Y2K-compliant code
7587 to new versions of @code{g77} and @code{libg2c}.)
7590 @subsection Array Size
7591 @cindex limits, array size
7594 Currently, @code{g77} uses the default @code{INTEGER} type
7596 which limits the sizes of single-dimension arrays
7597 on systems offering a larger address space
7598 than can be addressed by that type.
7599 (That @code{g77} puts all arrays in memory
7600 could be considered another limitation---it
7601 could use large temporary files---but that decision
7602 is left to the programmer as an implementation choice
7603 by most Fortran implementations.)
7605 @c ??? Investigate this, to offer a more clear statement
7606 @c than the following paragraphs do. -- burley 1999-02-17
7607 It is not yet clear whether this limitation
7608 never, sometimes, or always applies to the
7609 sizes of multiple-dimension arrays as a whole.
7611 For example, on a system with 64-bit addresses
7612 and 32-bit default @code{INTEGER},
7613 an array with a size greater than can be addressed
7615 can be declared using multiple dimensions.
7616 Such an array is therefore larger
7617 than a single-dimension array can be,
7620 @cindex limits, multi-dimension arrays
7621 @cindex multi-dimension arrays
7622 @cindex arrays, dimensioning
7623 Whether large multiple-dimension arrays are reliably supported
7624 depends mostly on the @code{gcc} back end (code generator)
7625 used by @code{g77}, and has not yet been fully investigated.
7627 @node Character-variable Length
7628 @subsection Character-variable Length
7629 @cindex limits, on character-variable length
7630 @cindex character-variable length
7632 Currently, @code{g77} uses the default @code{INTEGER} type
7633 for the lengths of @code{CHARACTER} variables
7636 This means that, for example,
7637 a system with a 64-bit address space
7638 and a 32-bit default @code{INTEGER} type
7639 does not, under @code{g77},
7640 support a @code{CHARACTER*@var{n}} declaration
7641 where @var{n} is greater than 2147483647.
7643 @node Year 10000 (Y10K) Problems
7644 @subsection Year 10000 (Y10K) Problems
7645 @cindex Y10K compliance
7646 @cindex Year 10000 compliance
7648 Most intrinsics returning, or computing values based on,
7649 date information are prone to Year-10000 (Y10K) problems,
7650 due to supporting only 4 digits for the year.
7652 See the following for examples:
7653 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
7654 @ref{IDate Intrinsic (UNIX)},
7655 @ref{Time Intrinsic (VXT)},
7656 @ref{Date_and_Time Intrinsic}.
7658 @node Compiler Types
7659 @section Compiler Types
7660 @cindex types, of data
7663 Fortran implementations have a fair amount of freedom given them by the
7664 standard as far as how much storage space is used and how much precision
7665 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7666 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7667 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7668 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7669 the interpretation of @var{n} varies across compilers and target architectures.
7671 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7672 and @code{REAL(KIND=1)}
7673 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7674 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7675 Further, it requires that @code{COMPLEX(KIND=1)}
7676 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7677 storage-associated (such as via @code{EQUIVALENCE})
7678 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7679 corresponds to the real element and @samp{R(2)} to the imaginary
7680 element of the @code{COMPLEX(KIND=1)} variable.
7682 (Few requirements as to precision or ranges of any of these are
7683 placed on the implementation, nor is the relationship of storage sizes of
7684 these types to the @code{CHARACTER} type specified, by the standard.)
7686 @code{g77} follows the above requirements, warning when compiling
7687 a program requires placement of items in memory that contradict the
7688 requirements of the target architecture.
7689 (For example, a program can require placement of a @code{REAL(KIND=2)}
7690 on a boundary that is not an even multiple of its size, but still an
7691 even multiple of the size of a @code{REAL(KIND=1)} variable.
7692 On some target architectures, using the canonical
7693 mapping of Fortran types to underlying architectural types, such
7694 placement is prohibited by the machine definition or
7695 the Application Binary Interface (ABI) in force for
7696 the configuration defined for building @code{gcc} and @code{g77}.
7697 @code{g77} warns about such
7698 situations when it encounters them.)
7700 @code{g77} follows consistent rules for configuring the mapping between Fortran
7701 types, including the @samp{*@var{n}} notation, and the underlying architectural
7702 types as accessed by a similarly-configured applicable version of the
7703 @code{gcc} compiler.
7704 These rules offer a widely portable, consistent Fortran/C
7705 environment, although they might well conflict with the expectations of
7706 users of Fortran compilers designed and written for particular
7709 These rules are based on the configuration that is in force for the
7710 version of @code{gcc} built in the same release as @code{g77} (and
7711 which was therefore used to build both the @code{g77} compiler
7712 components and the @code{libg2c} run-time library):
7715 @cindex REAL(KIND=1) type
7716 @cindex types, REAL(KIND=1)
7718 Same as @code{float} type.
7720 @cindex REAL(KIND=2) type
7721 @cindex types, REAL(KIND=2)
7723 Same as whatever floating-point type that is twice the size
7724 of a @code{float}---usually, this is a @code{double}.
7726 @cindex INTEGER(KIND=1) type
7727 @cindex types, INTEGER(KIND=1)
7728 @item INTEGER(KIND=1)
7729 Same as an integral type that is occupies the same amount
7730 of memory storage as @code{float}---usually, this is either
7731 an @code{int} or a @code{long int}.
7733 @cindex LOGICAL(KIND=1) type
7734 @cindex types, LOGICAL(KIND=1)
7735 @item LOGICAL(KIND=1)
7736 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7738 @cindex INTEGER(KIND=2) type
7739 @cindex types, INTEGER(KIND=2)
7740 @item INTEGER(KIND=2)
7741 Twice the size, and usually nearly twice the range,
7742 as @code{INTEGER(KIND=1)}---usually, this is either
7743 a @code{long int} or a @code{long long int}.
7745 @cindex LOGICAL(KIND=2) type
7746 @cindex types, LOGICAL(KIND=2)
7747 @item LOGICAL(KIND=2)
7748 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7750 @cindex INTEGER(KIND=3) type
7751 @cindex types, INTEGER(KIND=3)
7752 @item INTEGER(KIND=3)
7753 Same @code{gcc} type as signed @code{char}.
7755 @cindex LOGICAL(KIND=3) type
7756 @cindex types, LOGICAL(KIND=3)
7757 @item LOGICAL(KIND=3)
7758 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7760 @cindex INTEGER(KIND=6) type
7761 @cindex types, INTEGER(KIND=6)
7762 @item INTEGER(KIND=6)
7763 Twice the size, and usually nearly twice the range,
7764 as @code{INTEGER(KIND=3)}---usually, this is
7767 @cindex LOGICAL(KIND=6) type
7768 @cindex types, LOGICAL(KIND=6)
7769 @item LOGICAL(KIND=6)
7770 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7772 @cindex COMPLEX(KIND=1) type
7773 @cindex types, COMPLEX(KIND=1)
7774 @item COMPLEX(KIND=1)
7775 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7776 one for the imaginary part).
7778 @cindex COMPLEX(KIND=2) type
7779 @cindex types, COMPLEX(KIND=2)
7780 @item COMPLEX(KIND=2)
7781 Two @code{REAL(KIND=2)} scalars.
7783 @cindex *@var{n} notation
7784 @item @var{numeric-type}*@var{n}
7785 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7786 Same as whatever @code{gcc} type occupies @var{n} times the storage
7787 space of a @code{gcc} @code{char} item.
7789 @cindex DOUBLE PRECISION type
7790 @cindex types, DOUBLE PRECISION
7791 @item DOUBLE PRECISION
7792 Same as @code{REAL(KIND=2)}.
7794 @cindex DOUBLE COMPLEX type
7795 @cindex types, DOUBLE COMPLEX
7796 @item DOUBLE COMPLEX
7797 Same as @code{COMPLEX(KIND=2)}.
7800 Note that the above are proposed correspondences and might change
7801 in future versions of @code{g77}---avoid writing code depending
7804 Other types supported by @code{g77}
7805 are derived from gcc types such as @code{char}, @code{short},
7806 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7808 That is, whatever types @code{gcc} already supports, @code{g77} supports
7809 now or probably will support in a future version.
7810 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7811 apply to these types,
7812 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7813 assigned in a way that encourages clarity, consistency, and portability.
7815 @node Compiler Constants
7816 @section Compiler Constants
7818 @cindex types, constants
7820 @code{g77} strictly assigns types to @emph{all} constants not
7821 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7823 Many other Fortran compilers attempt to assign types to typed constants
7824 based on their context.
7825 This results in hard-to-find bugs, nonportable
7826 code, and is not in the spirit (though it strictly follows the letter)
7827 of the 77 and 90 standards.
7829 @code{g77} might offer, in a future release, explicit constructs by
7830 which a wider variety of typeless constants may be specified, and/or
7831 user-requested warnings indicating places where @code{g77} might differ
7832 from how other compilers assign types to constants.
7834 @xref{Context-Sensitive Constants}, for more information on this issue.
7836 @node Compiler Intrinsics
7837 @section Compiler Intrinsics
7839 @code{g77} offers an ever-widening set of intrinsics.
7840 Currently these all are procedures (functions and subroutines).
7842 Some of these intrinsics are unimplemented, but their names reserved
7843 to reduce future problems with existing code as they are implemented.
7844 Others are implemented as part of the GNU Fortran language, while
7845 yet others are provided for compatibility with other dialects of
7846 Fortran but are not part of the GNU Fortran language.
7848 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7849 a facility that is simply an extension of the intrinsic groups provided
7850 by the GNU Fortran language.
7853 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7854 * Other Intrinsics:: Intrinsics other than those in the GNU
7858 @node Intrinsic Groups
7859 @subsection Intrinsic Groups
7860 @cindex groups of intrinsics
7861 @cindex intrinsics, groups
7863 A given specific intrinsic belongs in one or more groups.
7864 Each group is deleted, disabled, hidden, or enabled
7865 by default or a command-line option.
7866 The meaning of each term follows.
7869 @cindex deleted intrinsics
7870 @cindex intrinsics, deleted
7872 No intrinsics are recognized as belonging to that group.
7874 @cindex disabled intrinsics
7875 @cindex intrinsics, disabled
7877 Intrinsics are recognized as belonging to the group, but
7878 references to them (other than via the @code{INTRINSIC} statement)
7879 are disallowed through that group.
7881 @cindex hidden intrinsics
7882 @cindex intrinsics, hidden
7884 Intrinsics in that group are recognized and enabled (if implemented)
7885 @emph{only} if the first mention of the actual name of an intrinsic
7886 in a program unit is in an @code{INTRINSIC} statement.
7888 @cindex enabled intrinsics
7889 @cindex intrinsics, enabled
7891 Intrinsics in that group are recognized and enabled (if implemented).
7894 The distinction between deleting and disabling a group is illustrated
7895 by the following example.
7896 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7897 If group @samp{FGR} is deleted, the following program unit will
7898 successfully compile, because @samp{FOO()} will be seen as a
7899 reference to an external function named @samp{FOO}:
7907 If group @samp{FGR} is disabled, compiling the above program will produce
7908 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7909 or, if properly invoked, it is not enabled.
7910 To change the above program so it references an external function @samp{FOO}
7911 instead of the disabled @samp{FOO} intrinsic,
7912 add the following line to the top:
7919 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7920 that group do not exist at all, whereas disabling it tells @code{g77} to
7921 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7923 Hiding a group is like enabling it, but the intrinsic must be first
7924 named in an @code{INTRINSIC} statement to be considered a reference to the
7925 intrinsic rather than to an external procedure.
7926 This might be the ``safest'' way to treat a new group of intrinsics
7928 code, because it allows the old code to be generally written as if
7929 those new intrinsics never existed, but to be changed to use them
7930 by inserting @code{INTRINSIC} statements in the appropriate places.
7931 However, it should be the goal of development to use @code{EXTERNAL}
7932 for all names of external procedures that might be intrinsic names.
7934 If an intrinsic is in more than one group, it is enabled if any of its
7935 containing groups are enabled; if not so enabled, it is hidden if
7936 any of its containing groups are hidden; if not so hidden, it is disabled
7937 if any of its containing groups are disabled; if not so disabled, it is
7939 This extra complication is necessary because some intrinsics,
7940 such as @code{IBITS}, belong to more than one group, and hence should be
7941 enabled if any of the groups to which they belong are enabled, and so
7946 @cindex intrinsics, groups of
7947 @cindex groups of intrinsics
7949 @cindex @code{badu77} intrinsics group
7951 UNIX intrinsics having inappropriate forms (usually functions that
7952 have intended side effects).
7954 @cindex @code{gnu} intrinsics group
7956 Intrinsics the GNU Fortran language supports that are extensions to
7957 the Fortran standards (77 and 90).
7959 @cindex @code{f2c} intrinsics group
7961 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
7963 @cindex @code{f90} intrinsics group
7965 Fortran 90 intrinsics.
7967 @cindex @code{mil} intrinsics group
7969 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
7971 @cindex @code{mil} intrinsics group
7973 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
7975 @cindex @code{mil} intrinsics group
7977 VAX/VMS FORTRAN (current as of v4) intrinsics.
7980 @node Other Intrinsics
7981 @subsection Other Intrinsics
7982 @cindex intrinsics, others
7983 @cindex other intrinsics
7985 @code{g77} supports intrinsics other than those in the GNU Fortran
7987 This set of intrinsics is described below.
7990 (Note that the empty lines appearing in the menu below
7991 are not intentional---they result from a bug in the
7992 @code{makeinfo} program.)
7995 @c The actual documentation for intrinsics comes from
7996 @c intdoc.texi, which in turn is automatically generated
7997 @c from the internal g77 tables in intrin.def _and_ the
7998 @c largely hand-written text in intdoc.h. So, if you want
7999 @c to change or add to existing documentation on intrinsics,
8000 @c you probably want to edit intdoc.h.
8012 @include intdoc.texi
8014 @node Other Compilers
8015 @chapter Other Compilers
8017 An individual Fortran source file can be compiled to
8018 an object (@file{*.o}) file instead of to the final
8020 This allows several portions of a program to be compiled
8021 at different times and linked together whenever a new
8022 version of the program is needed.
8023 However, it introduces the issue of @dfn{object compatibility}
8024 across the various object files (and libraries, or @file{*.a}
8025 files) that are linked together to produce any particular
8028 Object compatibility is an issue when combining, in one
8029 program, Fortran code compiled by more than one compiler
8030 (or more than one configuration of a compiler).
8032 disagree on how to transform the names of procedures, there
8033 will normally be errors when linking such programs.
8034 Worse, if the compilers agree on naming, but disagree on issues
8035 like how to pass parameters, return arguments, and lay out
8036 @code{COMMON} areas, the earliest detected errors might be the
8037 incorrect results produced by the program (and that assumes
8038 these errors are detected, which is not always the case).
8040 Normally, @code{g77} generates code that is
8041 object-compatible with code generated by a version of
8042 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
8043 to be generally compatible with @code{g77} as built by @code{gcc}.
8044 (Normally, @code{f2c} will, by default, conform to the appropriate
8045 configuration, but it is possible that older or perhaps even newer
8046 versions of @code{f2c}, or versions having certain configuration changes
8047 to @code{f2c} internals, will produce object files that are
8048 incompatible with @code{g77}.)
8050 For example, a Fortran string subroutine
8051 argument will become two arguments on the C side: a @code{char *}
8052 and an @code{int} length.
8054 Much of this compatibility results from the fact that
8055 @code{g77} uses the same run-time library,
8056 @code{libf2c}, used by @code{f2c},
8057 though @code{g77} gives its version the name @code{libg2c}
8058 so as to avoid conflicts when linking,
8059 installing them in the same directories,
8062 Other compilers might or might not generate code that
8063 is object-compatible with @code{libg2c} and current @code{g77},
8064 and some might offer such compatibility only when explicitly
8065 selected via a command-line option to the compiler.
8067 @emph{Note: This portion of the documentation definitely needs a lot
8071 * Dropping f2c Compatibility:: When speed is more important.
8072 * Compilers Other Than f2c:: Interoperation with code from other compilers.
8075 @node Dropping f2c Compatibility
8076 @section Dropping @code{f2c} Compatibility
8078 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
8079 some cases, faster code, by not needing to allow to the possibility
8080 of linking with code compiled by @code{f2c}.
8082 For example, this affects how @code{REAL(KIND=1)},
8083 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
8084 With @samp{-fno-f2c}, they are
8085 compiled as returning the appropriate @code{gcc} type
8086 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
8087 in many configurations).
8089 With @samp{-ff2c} in force, they
8090 are compiled differently (with perhaps slower run-time performance)
8091 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
8092 C as an intermediate language---@code{REAL(KIND=1)} functions
8093 return C's @code{double} type, while @code{COMPLEX} functions return
8094 @code{void} and use an extra argument pointing to a place for the functions to
8095 return their values.
8097 It is possible that, in some cases, leaving @samp{-ff2c} in force
8098 might produce faster code than using @samp{-fno-f2c}.
8099 Feel free to experiment, but remember to experiment with changing the way
8100 @emph{entire programs and their Fortran libraries are compiled} at
8101 a time, since this sort of experimentation affects the interface
8102 of code generated for a Fortran source file---that is, it affects
8103 object compatibility.
8105 Note that @code{f2c} compatibility is a fairly static target to achieve,
8106 though not necessarily perfectly so, since, like @code{g77}, it is
8107 still being improved.
8108 However, specifying @samp{-fno-f2c} causes @code{g77}
8109 to generate code that will probably be incompatible with code
8110 generated by future versions of @code{g77} when the same option
8112 You should make sure you are always able to recompile complete
8113 programs from source code when upgrading to new versions of @code{g77}
8114 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8116 Therefore, if you are using @code{g77} to compile libraries and other
8117 object files for possible future use and you don't want to require
8118 recompilation for future use with subsequent versions of @code{g77},
8119 you might want to stick with @code{f2c} compatibility for now, and
8120 carefully watch for any announcements about changes to the
8121 @code{f2c}/@code{libf2c} interface that might affect existing programs
8122 (thus requiring recompilation).
8124 It is probable that a future version of @code{g77} will not,
8125 by default, generate object files compatible with @code{f2c},
8126 and that version probably would no longer use @code{libf2c}.
8127 If you expect to depend on this compatibility in the
8128 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8129 all of the applicable code.
8130 This should cause future versions of @code{g77} either to produce
8131 compatible code (at the expense of the availability of some features and
8132 performance), or at the very least, to produce diagnostics.
8134 (The library @code{g77} produces will no longer be named @file{libg2c}
8135 when it is no longer generally compatible with @file{libf2c}.
8136 It will likely be referred to, and, if installed as a distinct
8137 library, named @code{libg77}, or some other as-yet-unused name.)
8139 @node Compilers Other Than f2c
8140 @section Compilers Other Than @code{f2c}
8142 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8143 code compiled by @code{g77} is not expected to work
8144 well with code compiled by the native compiler.
8145 (This is true for @code{f2c}-compiled objects as well.)
8146 Libraries compiled with the native compiler probably will have
8147 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8149 Reasons for such incompatibilities include:
8153 There might be differences in the way names of Fortran procedures
8154 are translated for use in the system's object-file format.
8155 For example, the statement @samp{CALL FOO} might be compiled
8156 by @code{g77} to call a procedure the linker @code{ld} sees
8157 given the name @samp{_foo_}, while the apparently corresponding
8158 statement @samp{SUBROUTINE FOO} might be compiled by the
8159 native compiler to define the linker-visible name @samp{_foo},
8160 or @samp{_FOO_}, and so on.
8163 There might be subtle type mismatches which cause subroutine arguments
8164 and function return values to get corrupted.
8166 This is why simply getting @code{g77} to
8167 transform procedure names the same way a native
8168 compiler does is not usually a good idea---unless
8169 some effort has been made to ensure that, aside
8170 from the way the two compilers transform procedure
8171 names, everything else about the way they generate
8172 code for procedure interfaces is identical.
8176 use libraries of private I/O routines which will not be available
8177 at link time unless you have the native compiler---and you would
8178 have to explicitly ask for them.
8180 For example, on the Sun you
8181 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8185 @node Other Languages
8186 @chapter Other Languages
8188 @emph{Note: This portion of the documentation definitely needs a lot
8192 * Interoperating with C and C++::
8195 @node Interoperating with C and C++
8196 @section Tools and advice for interoperating with C and C++
8198 @cindex C, linking with
8199 @cindex C++, linking with
8200 @cindex linking with C
8201 The following discussion assumes that you are running @code{g77} in @code{f2c}
8202 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8204 advice about quick and simple techniques for linking Fortran and C (or
8205 C++), the most common requirement.
8206 For the full story consult the
8207 description of code generation.
8208 @xref{Debugging and Interfacing}.
8210 When linking Fortran and C, it's usually best to use @code{g77} to do
8211 the linking so that the correct libraries are included (including the
8213 If you're linking with C++ you will want to add
8214 @samp{-lstdc++}, @samp{-lg++} or whatever.
8215 If you need to use another
8216 driver program (or @code{ld} directly),
8217 you can find out what linkage
8218 options @code{g77} passes by running @samp{g77 -v}.
8221 * C Interfacing Tools::
8222 * C Access to Type Information::
8223 * f2c Skeletons and Prototypes::
8224 * C++ Considerations::
8228 @node C Interfacing Tools
8229 @subsection C Interfacing Tools
8233 Even if you don't actually use it as a compiler, @code{f2c} from
8234 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8235 interfacing (linking) Fortran and C@.
8236 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8238 To use @code{f2c} for this purpose you only need retrieve and
8239 build the @file{src} directory from the distribution, consult the
8240 @file{README} instructions there for machine-specifics, and install the
8241 @code{f2c} program on your path.
8243 Something else that might be useful is @samp{cfortran.h} from
8244 @uref{ftp://zebra.desy.de/cfortran}.
8245 This is a fairly general tool which
8246 can be used to generate interfaces for calling in both directions
8247 between Fortran and C@.
8248 It can be used in @code{f2c} mode with
8249 @code{g77}---consult its documentation for details.
8251 @node C Access to Type Information
8252 @subsection Accessing Type Information in C
8254 @cindex types, Fortran/C
8255 Generally, C code written to link with
8256 @code{g77} code---calling and/or being
8257 called from Fortran---should @samp{#include <g2c.h>} to define the C
8258 versions of the Fortran types.
8259 Don't assume Fortran @code{INTEGER} types
8260 correspond to C @code{int}s, for instance; instead, declare them as
8261 @code{integer}, a type defined by @file{g2c.h}.
8262 @file{g2c.h} is installed where @code{gcc} will find it by
8263 default, assuming you use a copy of @code{gcc} compatible with
8264 @code{g77}, probably built at the same time as @code{g77}.
8266 @node f2c Skeletons and Prototypes
8267 @subsection Generating Skeletons and Prototypes with @code{f2c}
8270 @cindex -fno-second-underscore
8271 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8272 interface with an existing library---is to write a file (named, for
8273 example, @file{fred.f}) of dummy Fortran
8274 skeletons comprising just the declaration of the routine(s) and dummy
8275 arguments plus @code{END} statements.
8276 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8277 into which you can edit
8278 useful code, confident the calling sequence is correct, at least.
8279 (There are some errors otherwise commonly made in generating C
8280 interfaces with @code{f2c} conventions,
8281 such as not using @code{doublereal}
8282 as the return type of a @code{REAL} @code{FUNCTION}.)
8285 @code{f2c} also can help with calling Fortran from C, using its
8286 @samp{-P} option to generate C prototypes appropriate for calling the
8287 Fortran.@footnote{The files generated like this can also be used for
8288 inter-unit consistency checking of dummy and actual arguments, although
8289 the @code{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8290 or @uref{ftp://ftp.dsm.fordham.edu} is
8291 probably better for this purpose.}
8292 If the Fortran code containing any
8293 routines to be called from C is in file @file{joe.f}, use the command
8294 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8295 prototype information.
8296 @code{#include} this in the C which has to call
8297 the Fortran routines to make sure you get it right.
8299 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
8300 between the way Fortran (including compilers like @code{g77}) and
8303 @node C++ Considerations
8304 @subsection C++ Considerations
8307 @code{f2c} can be used to generate suitable code for compilation with a
8308 C++ system using the @samp{-C++} option.
8309 The important thing about linking @code{g77}-compiled
8310 code with C++ is that the prototypes for the @code{g77}
8311 routines must specify C linkage to avoid name mangling.
8312 So, use an @samp{extern "C"} declaration.
8313 @code{f2c}'s @samp{-C++} option will take care
8314 of this when generating skeletons or prototype files as above, and also
8315 avoid clashes with C++ reserved words in addition to those in C@.
8318 @subsection Startup Code
8320 @cindex startup code
8321 @cindex run-time, initialization
8322 @cindex initialization, run-time
8323 Unlike with some runtime systems,
8324 it shouldn't be necessary
8325 (unless there are bugs)
8326 to use a Fortran main program unit to ensure the
8327 runtime---specifically the I/O system---is initialized.
8329 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8330 either the @code{main} routine from the @file{libg2c} library must be used,
8331 or the @code{f_setarg} routine
8332 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8333 must be called with the appropriate @code{argc} and @code{argv} arguments
8334 prior to the program calling @code{GETARG} or @code{IARGC}.
8336 To provide more flexibility for mixed-language programming
8337 involving @code{g77} while allowing for shared libraries,
8338 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8339 @code{g77}'s @code{main} routine in @code{libg2c}
8340 does the following, in order:
8344 Calls @code{f_setarg}
8345 with the incoming @code{argc} and @code{argv} arguments,
8346 in the same order as for @code{main} itself.
8348 This sets up the command-line environment
8349 for @code{GETARG} and @code{IARGC}.
8352 Calls @code{f_setsig} (with no arguments).
8354 This sets up the signaling and exception environment.
8357 Calls @code{f_init} (with no arguments).
8359 This initializes the I/O environment,
8360 though that should not be necessary,
8361 as all I/O functions in @code{libf2c}
8362 are believed to call @code{f_init} automatically,
8365 (A future version of @code{g77} might skip this explicit step,
8366 to speed up normal exit of a program.)
8369 Arranges for @code{f_exit} to be called (with no arguments)
8370 when the program exits.
8372 This ensures that the I/O environment is properly shut down
8373 before the program exits normally.
8374 Otherwise, output buffers might not be fully flushed,
8375 scratch files might not be deleted, and so on.
8377 The simple way @code{main} does this is
8378 to call @code{f_exit} itself after calling
8379 @code{MAIN__} (in the next step).
8381 However, this does not catch the cases where the program
8382 might call @code{exit} directly,
8383 instead of using the @code{EXIT} intrinsic
8384 (implemented as @code{exit_} in @code{libf2c}).
8386 So, @code{main} attempts to use
8387 the operating environment's @code{onexit} or @code{atexit}
8388 facility, if available,
8389 to cause @code{f_exit} to be called automatically
8390 upon any invocation of @code{exit}.
8393 Calls @code{MAIN__} (with no arguments).
8395 This starts executing the Fortran main program unit for
8397 (Both @code{g77} and @code{f2c} currently compile a main
8398 program unit so that its global name is @code{MAIN__}.)
8401 If no @code{onexit} or @code{atexit} is provided by the system,
8402 calls @code{f_exit}.
8405 Calls @code{exit} with a zero argument,
8406 to signal a successful program termination.
8409 Returns a zero value to the caller,
8410 to signal a successful program termination,
8411 in case @code{exit} doesn't exit on the system.
8414 All of the above names are C @code{extern} names,
8417 When using the @code{main} procedure provided by @code{g77}
8418 without a Fortran main program unit,
8419 you need to provide @code{MAIN__}
8420 as the entry point for your C code.
8421 (Make sure you link the object file that defines that
8422 entry point with the rest of your program.)
8424 To provide your own @code{main} procedure
8425 in place of @code{g77}'s,
8426 make sure you specify the object file defining that procedure
8427 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8428 Since the @samp{-lg2c} option is implicitly provided,
8429 this is usually straightforward.
8430 (Use the @samp{--verbose} option to see how and where
8431 @code{g77} implicitly adds @samp{-lg2c} in a command line
8432 that will link the program.
8433 Feel free to specify @samp{-lg2c} explicitly,
8436 However, when providing your own @code{main},
8437 make sure you perform the appropriate tasks in the
8439 For example, if your @code{main} does not call @code{f_setarg},
8440 make sure the rest of your application does not call
8441 @code{GETARG} or @code{IARGC}.
8443 And, if your @code{main} fails to ensure that @code{f_exit}
8444 is called upon program exit,
8445 some files might end up incompletely written,
8446 some scratch files might be left lying around,
8447 and some existing files being written might be left
8448 with old data not properly truncated at the end.
8450 Note that, generally, the @code{g77} operating environment
8451 does not depend on a procedure named @code{MAIN__} actually
8452 being called prior to any other @code{g77}-compiled code.
8453 That is, @code{MAIN__} does not, itself,
8454 set up any important operating-environment characteristics
8455 upon which other code might depend.
8456 This might change in future versions of @code{g77},
8457 with appropriate notification in the release notes.
8459 For more information, consult the source code for the above routines.
8460 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8461 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8463 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8464 uses to open-code (inline) references to @code{IARGC}.
8466 @include g77install.texi
8468 @node Debugging and Interfacing
8469 @chapter Debugging and Interfacing
8472 @cindex calling C routines
8473 @cindex C routines calling Fortran
8474 @cindex f2c compatibility
8476 GNU Fortran currently generates code that is object-compatible with
8477 the @code{f2c} converter.
8478 Also, it avoids limitations in the current GBE, such as the
8479 inability to generate a procedure with
8480 multiple entry points, by generating code that is structured
8481 differently (in terms of procedure names, scopes, arguments, and
8482 so on) than might be expected.
8484 As a result, writing code in other languages that calls on, is
8485 called by, or shares in-memory data with @code{g77}-compiled code generally
8486 requires some understanding of the way @code{g77} compiles code for
8489 Similarly, using a debugger to debug @code{g77}-compiled
8490 code, even if that debugger supports native Fortran debugging, generally
8491 requires this sort of information.
8493 This section describes some of the basic information on how
8494 @code{g77} compiles code for constructs involving interfaces to other
8495 languages and to debuggers.
8497 @emph{Caution:} Much or all of this information pertains to only the current
8498 release of @code{g77}, sometimes even to using certain compiler options
8499 with @code{g77} (such as @samp{-fno-f2c}).
8500 Do not write code that depends on this
8501 information without clearly marking said code as nonportable and
8502 subject to review for every new release of @code{g77}.
8504 is provided primarily to make debugging of code generated by this
8505 particular release of @code{g77} easier for the user, and partly to make
8506 writing (generally nonportable) interface code easier.
8508 activities require tracking changes in new version of @code{g77} as they
8509 are installed, because new versions can change the behaviors
8510 described in this section.
8513 * Main Program Unit:: How @code{g77} compiles a main program unit.
8514 * Procedures:: How @code{g77} constructs parameter lists
8516 * Functions:: Functions returning floating-point or character data.
8517 * Names:: Naming of user-defined variables, procedures, etc.
8518 * Common Blocks:: Accessing common variables while debugging.
8519 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8520 * Complex Variables:: How @code{g77} performs complex arithmetic.
8521 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8522 * Adjustable Arrays:: Special consideration for adjustable arrays.
8523 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8524 * Alternate Returns:: How @code{g77} handles alternate returns.
8525 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8526 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8529 @node Main Program Unit
8530 @section Main Program Unit (PROGRAM)
8531 @cindex PROGRAM statement
8532 @cindex statements, PROGRAM
8534 When @code{g77} compiles a main program unit, it gives it the public
8535 procedure name @code{MAIN__}.
8536 The @code{libg2c} library has the actual @code{main()} procedure
8537 as is typical of C-based environments, and
8538 it is this procedure that performs some initial start-up
8539 activity and then calls @code{MAIN__}.
8541 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8542 include a main program unit written in Fortran in your program---it
8543 can be written in C or some other language.
8544 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8545 includes a bug fix for @code{libg2c} that solved a problem with using the
8546 @code{OPEN} statement as the first Fortran I/O activity in a program
8547 without a Fortran main program unit.
8549 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8550 your main program unit---that is, if you intend to compile a @code{main()}
8551 procedure using some other language---you should carefully
8552 examine the code for @code{main()} in @code{libg2c}, found in the source
8553 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8554 might need to be done by your @code{main()} in order to provide the
8555 Fortran environment your Fortran code is expecting.
8557 @cindex @code{IArgC} intrinsic
8558 @cindex intrinsics, @code{IArgC}
8559 @cindex @code{GetArg} intrinsic
8560 @cindex intrinsics, @code{GetArg}
8561 For example, @code{libg2c}'s @code{main()} sets up the information used by
8562 the @code{IARGC} and @code{GETARG} intrinsics.
8563 Bypassing @code{libg2c}'s @code{main()}
8564 without providing a substitute for this activity would mean
8565 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8569 @cindex main program unit, debugging
8573 When debugging, one implication of the fact that @code{main()}, which
8574 is the place where the debugged program ``starts'' from the
8575 debugger's point of view, is in @code{libg2c} is that you won't be
8576 starting your Fortran program at a point you recognize as your
8579 The standard way to get around this problem is to set a break
8580 point (a one-time, or temporary, break point will do) at
8581 the entrance to @code{MAIN__}, and then run the program.
8582 A convenient way to do so is to add the @code{gdb} command
8589 to the file @file{.gdbinit} in the directory in which you're debugging
8592 After doing this, the debugger will see the current execution
8593 point of the program as at the beginning of the main program
8594 unit of your program.
8596 Of course, if you really want to set a break point at some
8597 other place in your program and just start the program
8598 running, without first breaking at @code{MAIN__},
8599 that should work fine.
8602 @section Procedures (SUBROUTINE and FUNCTION)
8604 @cindex SUBROUTINE statement
8605 @cindex statements, SUBROUTINE
8606 @cindex FUNCTION statement
8607 @cindex statements, FUNCTION
8608 @cindex signature of procedures
8610 Currently, @code{g77} passes arguments via reference---specifically,
8611 by passing a pointer to the location in memory of a variable, array,
8612 array element, a temporary location that holds the result of evaluating an
8613 expression, or a temporary or permanent location that holds the value
8616 Procedures that accept @code{CHARACTER} arguments are implemented by
8617 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8619 The first argument occupies the expected position in the
8620 argument list and has the user-specified name.
8622 is a pointer to an array of characters, passed by the caller.
8624 The second argument is appended to the end of the user-specified
8625 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8626 is the user-specified name.
8627 This argument is of the C type @code{ftnlen}
8628 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8629 is the number of characters the caller has allocated in the
8630 array pointed to by the first argument.
8632 A procedure will ignore the length argument if @samp{X} is not declared
8633 @code{CHARACTER*(*)}, because for other declarations, it knows the
8635 Not all callers necessarily ``know'' this, however, which
8636 is why they all pass the extra argument.
8638 The contents of the @code{CHARACTER} argument are specified by the
8639 address passed in the first argument (named after it).
8640 The procedure can read or write these contents as appropriate.
8642 When more than one @code{CHARACTER} argument is present in the argument
8643 list, the length arguments are appended in the order
8644 the original arguments appear.
8645 So @samp{CALL FOO('HI','THERE')} is implemented in
8646 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8647 does not provide the trailing null bytes on the constant
8648 strings (@code{f2c} does provide them, but they are unnecessary in
8649 a Fortran environment, and you should not expect them to be
8652 Note that the above information applies to @code{CHARACTER} variables and
8653 arrays @strong{only}.
8654 It does @strong{not} apply to external @code{CHARACTER}
8655 functions or to intrinsic @code{CHARACTER} functions.
8656 That is, no second length argument is passed to @samp{FOO} in this case:
8665 Nor does @samp{FOO} expect such an argument in this case:
8673 Because of this implementation detail, if a program has a bug
8674 such that there is disagreement as to whether an argument is
8675 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8676 symptoms might appear.
8679 @section Functions (FUNCTION and RETURN)
8681 @cindex FUNCTION statement
8682 @cindex statements, FUNCTION
8683 @cindex RETURN statement
8684 @cindex statements, RETURN
8685 @cindex return type of functions
8687 @code{g77} handles in a special way functions that return the following
8699 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8700 returning @code{void})
8701 with two arguments prepended: @samp{__g77_result}, which the caller passes
8702 as a pointer to a @code{char} array expected to hold the return value,
8703 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8704 specifying the length of the return value as declared in the calling
8706 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8707 to determine the size of the array that @samp{__g77_result} points to;
8708 otherwise, it ignores that argument.
8710 For @code{COMPLEX}, when @samp{-ff2c} is in
8711 force, @code{g77} implements
8712 a subroutine with one argument prepended: @samp{__g77_result}, which the
8713 caller passes as a pointer to a variable of the type of the function.
8714 The called function writes the return value into this variable instead
8715 of returning it as a function value.
8716 When @samp{-fno-f2c} is in force,
8717 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8718 @samp{__complex__ float} or @samp{__complex__ double} function
8719 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8720 returning the result of the function in the same way as @code{gcc} would.
8722 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8723 a function that actually returns @code{REAL(KIND=2)} (typically
8724 C's @code{double} type).
8725 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8726 functions return @code{float}.
8730 @cindex symbol names
8731 @cindex transforming symbol names
8733 Fortran permits each implementation to decide how to represent
8734 names as far as how they're seen in other contexts, such as debuggers
8735 and when interfacing to other languages, and especially as far
8736 as how casing is handled.
8738 External names---names of entities that are public, or ``accessible'',
8739 to all modules in a program---normally have an underscore (@samp{_})
8740 appended by @code{g77},
8741 to generate code that is compatible with @code{f2c}.
8742 External names include names of Fortran things like common blocks,
8743 external procedures (subroutines and functions, but not including
8744 statement functions, which are internal procedures), and entry point
8747 However, use of the @samp{-fno-underscoring} option
8748 disables this kind of transformation of external names (though inhibiting
8749 the transformation certainly improves the chances of colliding with
8750 incompatible externals written in other languages---but that
8751 might be intentional.
8753 @cindex -fno-underscoring option
8754 @cindex options, -fno-underscoring
8755 @cindex -fno-second-underscore option
8756 @cindex options, -fno-underscoring
8757 When @samp{-funderscoring} is in force, any name (external or local)
8758 that already has at least one underscore in it is
8759 implemented by @code{g77} by appending two underscores.
8760 (This second underscore can be disabled via the
8761 @samp{-fno-second-underscore} option.)
8762 External names are changed this way for @code{f2c} compatibility.
8763 Local names are changed this way to avoid collisions with external names
8764 that are different in the source code---@code{f2c} does the same thing, but
8765 there's no compatibility issue there except for user expectations while
8776 Here, a user would, in the debugger, refer to this variable using the
8777 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8778 as described below).
8779 (We hope to improve @code{g77} in this regard in the future---don't
8780 write scripts depending on this behavior!
8781 Also, consider experimenting with the @samp{-fno-underscoring}
8782 option to try out debugging without having to massage names by
8785 @code{g77} provides a number of command-line options that allow the user
8786 to control how case mapping is handled for source files.
8787 The default is the traditional UNIX model for Fortran compilers---names
8788 are mapped to lower case.
8789 Other command-line options can be specified to map names to upper
8790 case, or to leave them exactly as written in the source file.
8799 Here, it is normally the case that the variable assigned will be named
8801 This would be the name to enter when using a debugger to
8802 access the variable.
8804 However, depending on the command-line options specified, the
8805 name implemented by @code{g77} might instead be @samp{FOO} or even
8806 @samp{Foo}, thus affecting how debugging is done.
8815 This would normally call a procedure that, if it were in a separate C program,
8816 be defined starting with the line:
8823 However, @code{g77} command-line options could be used to change the casing
8824 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8825 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8826 could be used to inhibit the appending of the underscore to the name.
8829 @section Common Blocks (COMMON)
8830 @cindex common blocks
8831 @cindex @code{COMMON} statement
8832 @cindex statements, @code{COMMON}
8834 @code{g77} names and lays out @code{COMMON} areas
8835 the same way @code{f2c} does,
8836 for compatibility with @code{f2c}.
8838 Currently, @code{g77} does not emit ``true'' debugging information for
8839 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8841 (As of Version 0.5.19, @code{g77} emits debugging information for such
8842 members in the form of a constant string specifying the base name of
8843 the aggregate area and the offset of the member in bytes from the start
8845 Use the @samp{-fdebug-kludge} option to enable this behavior.
8846 In @code{gdb}, use @samp{set language c} before printing the value
8847 of the member, then @samp{set language fortran} to restore the default
8848 language, since @code{gdb} doesn't provide a way to print a readable
8849 version of a character string in Fortran language mode.
8851 This kludge will be removed in a future version of @code{g77} that,
8852 in conjunction with a contemporary version of @code{gdb},
8853 properly supports Fortran-language debugging, including access
8854 to members of @code{COMMON} areas.)
8856 Version 0.5.26 of @code{g77} is believed to provide correct and
8857 complete debug information for COMMON BLOCK and EQUIVALENCE items -
8858 hence the @samp{-fdebug-kludge} option has been disabled.
8860 @xref{Code Gen Options,,Options for Code Generation Conventions},
8861 for information on the @samp{-fdebug-kludge} option.
8863 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8864 type is an array of the C @code{char} data type.
8866 So, when debugging, you must know the offset into a @code{COMMON} area
8867 for a particular item in that area, and you have to take into
8868 account the appropriate multiplier for the respective sizes
8869 of the types (as declared in your code) for the items preceding
8870 the item in question as compared to the size of the @code{char} type.
8872 For example, using default implicit typing, the statement
8875 COMMON I(15), R(20), T
8879 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8880 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8881 and @samp{T} at @samp{_BLNK__[140]}.
8882 (This is assuming that the target machine for
8883 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8886 @node Local Equivalence Areas
8887 @section Local Equivalence Areas (EQUIVALENCE)
8888 @cindex equivalence areas
8889 @cindex local equivalence areas
8890 @cindex EQUIVALENCE statement
8891 @cindex statements, EQUIVALENCE
8893 @code{g77} treats storage-associated areas involving a @code{COMMON}
8894 block as explained in the section on common blocks.
8896 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8897 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8898 listed in a @code{COMMON} statement.
8900 Currently, @code{g77} does not emit ``true'' debugging information for
8901 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8903 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8904 members in the form of a constant string specifying the base name of
8905 the aggregate area and the offset of the member in bytes from the start
8907 Use the @samp{-fdebug-kludge} option to enable this behavior.
8908 In @code{gdb}, use @samp{set language c} before printing the value
8909 of the member, then @samp{set language fortran} to restore the default
8910 language, since @code{gdb} doesn't provide a way to print a readable
8911 version of a character string in Fortran language mode.
8913 This kludge will be removed in a future version of @code{g77} that,
8914 in conjunction with a contemporary version of @code{gdb},
8915 properly supports Fortran-language debugging, including access
8916 to members of @code{EQUIVALENCE} areas.)
8918 @xref{Code Gen Options,,Options for Code Generation Conventions},
8919 for information on the @samp{-fdebug-kludge} option.
8921 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8922 type is an array of the C @code{char} data type.
8924 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8925 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8927 If more than one such item is placed at the beginning, @var{x} is
8928 the name that sorts to the top in an alphabetical sort of the list of
8931 When debugging, you must therefore access members of @code{EQUIVALENCE}
8932 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8933 array section with the appropriate offset.
8934 See the explanation of debugging @code{COMMON} blocks
8935 for info applicable to debugging local @code{EQUIVALENCE} areas.
8937 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8938 for @var{x} using a different method when more than one name was
8939 in the list of names of entities placed at the beginning of the
8941 Though the documentation specified that the first name listed in
8942 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8943 in fact chose the name using a method that was so complicated,
8944 it seemed easier to change it to an alphabetical sort than to describe the
8945 previous method in the documentation.)
8947 @node Complex Variables
8948 @section Complex Variables (COMPLEX)
8949 @cindex complex variables
8950 @cindex imaginary part
8951 @cindex COMPLEX statement
8952 @cindex statements, COMPLEX
8954 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8955 (and related intrinsics, constants, functions, and so on)
8957 makes direct debugging involving these types in Fortran
8958 language mode difficult.
8960 Essentially, @code{g77} implements these types using an
8961 internal construct similar to C's @code{struct}, at least
8962 as seen by the @code{gcc} back end.
8964 Currently, the back end, when outputting debugging info with
8965 the compiled code for the assembler to digest, does not detect
8966 these @code{struct} types as being substitutes for Fortran
8968 As a result, the Fortran language modes of debuggers such as
8969 @code{gdb} see these types as C @code{struct} types, which
8970 they might or might not support.
8972 Until this is fixed, switch to C language mode to work with
8973 entities of @code{COMPLEX} type and then switch back to Fortran language
8975 (In @code{gdb}, this is accomplished via @samp{set lang c} and
8976 either @samp{set lang fortran} or @samp{set lang auto}.)
8979 @section Arrays (DIMENSION)
8980 @cindex DIMENSION statement
8981 @cindex statements, DIMENSION
8982 @cindex array ordering
8983 @cindex ordering, array
8984 @cindex column-major ordering
8985 @cindex row-major ordering
8988 Fortran uses ``column-major ordering'' in its arrays.
8989 This differs from other languages, such as C, which use ``row-major ordering''.
8990 The difference is that, with Fortran, array elements adjacent to
8991 each other in memory differ in the @emph{first} subscript instead of
8992 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
8993 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
8996 affects not only interfacing with and debugging Fortran code,
8997 it can greatly affect how code is designed and written, especially
8998 when code speed and size is a concern.
9000 Fortran also differs from C, a popular language for interfacing and
9001 to support directly in debuggers, in the way arrays are treated.
9002 In C, arrays are single-dimensional and have interesting relationships
9003 to pointers, neither of which is true for Fortran.
9004 As a result, dealing with Fortran arrays from within
9005 an environment limited to C concepts can be challenging.
9007 For example, accessing the array element @samp{A(5,10,20)} is easy enough
9008 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
9010 First, C would treat the A array as a single-dimension array.
9011 Second, C does not understand low bounds for arrays as does Fortran.
9012 Third, C assumes a low bound of zero (0), while Fortran defaults to a
9013 low bound of one (1) and can supports an arbitrary low bound.
9014 Therefore, calculations must be done
9015 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
9016 calculations require knowing the dimensions of @samp{A}.
9018 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
9019 @samp{A(5,10,20)} would be:
9024 + (20-0)*(11-2+1)*(21-1+1)
9029 So the C equivalent in this case would be @samp{a[4293]}.
9031 When using a debugger directly on Fortran code, the C equivalent
9032 might not work, because some debuggers cannot understand the notion
9033 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
9034 does inform the GBE that a multi-dimensional array (like @samp{A}
9035 in the above example) is really multi-dimensional, rather than a
9036 single-dimensional array, so at least the dimensionality of the array
9039 Debuggers that understand Fortran should have no trouble with
9040 non-zero low bounds, but for non-Fortran debuggers, especially
9041 C debuggers, the above example might have a C equivalent of
9043 This calculation is arrived at by eliminating the subtraction
9044 of the lower bound in the first parenthesized expression on each
9045 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
9046 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
9047 Actually, the implication of
9048 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
9049 but that @samp{a[20][10][5]} produces the equivalent of
9050 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
9052 Come to think of it, perhaps
9053 the behavior is due to the debugger internally compensating for
9054 the lower bounds by offsetting the base address of @samp{a}, leaving
9055 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
9056 its first element as identified by subscripts equal to the
9057 corresponding lower bounds).
9059 You know, maybe nobody really needs to use arrays.
9061 @node Adjustable Arrays
9062 @section Adjustable Arrays (DIMENSION)
9063 @cindex arrays, adjustable
9064 @cindex adjustable arrays
9065 @cindex arrays, automatic
9066 @cindex automatic arrays
9067 @cindex DIMENSION statement
9068 @cindex statements, DIMENSION
9069 @cindex dimensioning arrays
9070 @cindex arrays, dimensioning
9072 Adjustable and automatic arrays in Fortran require the implementation
9074 case, the @code{g77} compiler) to ``memorize'' the expressions that
9075 dimension the arrays each time the procedure is invoked.
9076 This is so that subsequent changes to variables used in those
9077 expressions, made during execution of the procedure, do not
9078 have any effect on the dimensions of those arrays.
9095 Here, the implementation should, when running the program, print something
9103 Note that this shows that while the value of @samp{N} was successfully
9104 changed, the size of the @samp{A} array remained at 5 elements.
9106 To support this, @code{g77} generates code that executes before any user
9107 code (and before the internally generated computed @code{GOTO} to handle
9108 alternate entry points, as described below) that evaluates each
9109 (nonconstant) expression in the list of subscripts for an
9110 array, and saves the result of each such evaluation to be used when
9111 determining the size of the array (instead of re-evaluating the
9114 So, in the above example, when @samp{X} is first invoked, code is
9115 executed that copies the value of @samp{N} to a temporary.
9116 And that same temporary serves as the actual high bound for the single
9117 dimension of the @samp{A} array (the low bound being the constant 1).
9118 Since the user program cannot (legitimately) change the value
9119 of the temporary during execution of the procedure, the size
9120 of the array remains constant during each invocation.
9122 For alternate entry points, the code @code{g77} generates takes into
9123 account the possibility that a dummy adjustable array is not actually
9124 passed to the actual entry point being invoked at that time.
9125 In that case, the public procedure implementing the entry point
9126 passes to the master private procedure implementing all the
9127 code for the entry points a @code{NULL} pointer where a pointer to that
9128 adjustable array would be expected.
9129 The @code{g77}-generated code
9130 doesn't attempt to evaluate any of the expressions in the subscripts
9131 for an array if the pointer to that array is @code{NULL} at run time in
9133 (Don't depend on this particular implementation
9134 by writing code that purposely passes @code{NULL} pointers where the
9135 callee expects adjustable arrays, even if you know the callee
9136 won't reference the arrays---nor should you pass @code{NULL} pointers
9137 for any dummy arguments used in calculating the bounds of such
9138 arrays or leave undefined any values used for that purpose in
9139 COMMON---because the way @code{g77} implements these things might
9140 change in the future!)
9142 @node Alternate Entry Points
9143 @section Alternate Entry Points (ENTRY)
9144 @cindex alternate entry points
9145 @cindex entry points
9146 @cindex ENTRY statement
9147 @cindex statements, ENTRY
9149 The GBE does not understand the general concept of
9150 alternate entry points as Fortran provides via the ENTRY statement.
9151 @code{g77} gets around this by using an approach to compiling procedures
9152 having at least one @code{ENTRY} statement that is almost identical to the
9153 approach used by @code{f2c}.
9154 (An alternate approach could be used that
9155 would probably generate faster, but larger, code that would also
9156 be a bit easier to debug.)
9158 Information on how @code{g77} implements @code{ENTRY} is provided for those
9159 trying to debug such code.
9160 The choice of implementation seems
9161 unlikely to affect code (compiled in other languages) that interfaces
9164 @code{g77} compiles exactly one public procedure for the primary entry
9165 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9166 That is, in terms of the public interface, there is no difference
9185 The difference between the above two cases lies in the code compiled
9186 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9187 for the second case, an extra internal procedure is compiled.
9189 For every Fortran procedure with at least one @code{ENTRY}
9190 statement, @code{g77} compiles an extra procedure
9191 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9192 the name of the primary entry point (which, in the above case,
9193 using the standard compiler options, would be @samp{x_} in C).
9195 This extra procedure is compiled as a private procedure---that is,
9196 a procedure not accessible by name to separately compiled modules.
9197 It contains all the code in the program unit, including the code
9198 for the primary entry point plus for every entry point.
9199 (The code for each public procedure is quite short, and explained later.)
9201 The extra procedure has some other interesting characteristics.
9203 The argument list for this procedure is invented by @code{g77}.
9205 a single integer argument named @samp{__g77_which_entrypoint},
9206 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9207 entry point index---0 for the primary entry point, 1 for the
9208 first entry point (the first @code{ENTRY} statement encountered), 2 for
9209 the second entry point, and so on.
9211 It also contains, for functions returning @code{CHARACTER} and
9212 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9213 and for functions returning different types among the
9214 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9215 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9216 is expected at run time to contain a pointer to where to store
9217 the result of the entry point.
9218 For @code{CHARACTER} functions, this
9219 storage area is an array of the appropriate number of characters;
9220 for @code{COMPLEX} functions, it is the appropriate area for the return
9221 type; for multiple-return-type functions, it is a union of all the supported return
9222 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9223 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9224 is not supported by @code{g77}).
9226 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9227 by yet another argument named @samp{__g77_length} that, at run time,
9228 specifies the caller's expected length of the returned value.
9229 Note that only @code{CHARACTER*(*)} functions and entry points actually
9230 make use of this argument, even though it is always passed by
9231 all callers of public @code{CHARACTER} functions (since the caller does not
9232 generally know whether such a function is @code{CHARACTER*(*)} or whether
9233 there are any other callers that don't have that information).
9235 The rest of the argument list is the union of all the arguments
9236 specified for all the entry points (in their usual forms, e.g.
9237 @code{CHARACTER} arguments have extra length arguments, all appended at
9238 the end of this list).
9239 This is considered the ``master list'' of
9242 The code for this procedure has, before the code for the first
9243 executable statement, code much like that for the following Fortran
9247 GOTO (100000,100001,100002), __g77_which_entrypoint
9248 100000 @dots{}code for primary entry point@dots{}
9249 100001 @dots{}code immediately following first ENTRY statement@dots{}
9250 100002 @dots{}code immediately following second ENTRY statement@dots{}
9254 (Note that invalid Fortran statement labels and variable names
9255 are used in the above example to highlight the fact that it
9256 represents code generated by the @code{g77} internals, not code to be
9257 written by the user.)
9259 It is this code that, when the procedure is called, picks which
9260 entry point to start executing.
9262 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9263 example), those procedures are fairly simple.
9265 are just like they would be if they were self-contained procedures
9266 (without @code{ENTRY}), of course, since that is what the callers
9268 Their code consists of simply calling the private
9269 procedure, described above, with the appropriate extra arguments
9270 (the entry point index, and perhaps a pointer to a multiple-type-
9271 return variable, local to the public procedure, that contains
9272 all the supported returnable non-character types).
9274 that are not listed for a given entry point that are listed for
9275 other entry points, and therefore that are in the ``master list''
9276 for the private procedure, null pointers (in C, the @code{NULL} macro)
9278 Also, for entry points that are part of a multiple-type-
9279 returning function, code is compiled after the call of the private
9280 procedure to extract from the multi-type union the appropriate result,
9281 depending on the type of the entry point in question, returning
9282 that result to the original caller.
9284 When debugging a procedure containing alternate entry points, you
9285 can either set a break point on the public procedure itself (e.g.
9286 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9287 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9288 If you do the former, you should use the debugger's command to
9289 ``step into'' the called procedure to get to the actual code; with
9290 the latter approach, the break point leaves you right at the
9291 actual code, skipping over the public entry point and its call
9292 to the private procedure (unless you have set a break point there
9293 as well, of course).
9295 Further, the list of dummy arguments that is visible when the
9296 private procedure is active is going to be the expanded version
9297 of the list for whichever particular entry point is active,
9298 as explained above, and the way in which return values are
9299 handled might well be different from how they would be handled
9300 for an equivalent single-entry function.
9302 @node Alternate Returns
9303 @section Alternate Returns (SUBROUTINE and RETURN)
9305 @cindex alternate returns
9306 @cindex SUBROUTINE statement
9307 @cindex statements, SUBROUTINE
9308 @cindex RETURN statement
9309 @cindex statements, RETURN
9311 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9312 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9313 the C @code{int} type.
9314 The actual alternate-return arguments are omitted from the calling sequence.
9315 Instead, the caller uses
9316 the return value to do a rough equivalent of the Fortran
9317 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9318 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9319 function), and the callee just returns whatever integer
9320 is specified in the @code{RETURN} statement for the subroutine
9321 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9323 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9325 @node Assigned Statement Labels
9326 @section Assigned Statement Labels (ASSIGN and GOTO)
9327 @cindex assigned statement labels
9328 @cindex statement labels, assigned
9329 @cindex ASSIGN statement
9330 @cindex statements, ASSIGN
9331 @cindex GOTO statement
9332 @cindex statements, GOTO
9334 For portability to machines where a pointer (such as to a label,
9335 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9336 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9337 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9338 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9339 than it does the numerical value in that variable, unless the
9340 variable is wide enough (can hold enough bits).
9342 In particular, while @code{g77} implements
9349 as, in C notation, @samp{i = 10;}, it implements
9356 as, in GNU's extended C notation (for the label syntax),
9357 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9358 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9359 actually generate the name @samp{L10} or any other name like that,
9360 since debuggers cannot access labels anyway).
9362 While this currently means that an @code{ASSIGN} statement does not
9363 overwrite the numeric contents of its target variable, @emph{do not}
9364 write any code depending on this feature.
9365 @code{g77} has already changed this implementation across
9366 versions and might do so in the future.
9367 This information is provided only to make debugging Fortran programs
9368 compiled with the current version of @code{g77} somewhat easier.
9369 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9370 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9371 means @code{g77} has decided it can store the pointer to the label directly
9372 into @samp{I} itself.
9374 @xref{Ugly Assigned Labels}, for information on a command-line option
9375 to force @code{g77} to use the same storage for both normal and
9376 assigned-label uses of a variable.
9378 @node Run-time Library Errors
9379 @section Run-time Library Errors
9381 @cindex error values
9382 @cindex error messages
9383 @cindex messages, run-time
9386 The @code{libg2c} library currently has the following table to relate
9387 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9388 This information should, in future versions of this document, be
9389 expanded upon to include detailed descriptions of each message.
9391 In line with good coding practices, any of the numbers in the
9392 list below should @emph{not} be directly written into Fortran
9394 Instead, make a separate @code{INCLUDE} file that defines
9395 @code{PARAMETER} names for them, and use those in your code,
9396 so you can more easily change the actual numbers in the future.
9398 The information below is culled from the definition
9399 of @code{F_err} in @file{f/runtime/libI77/err.c} in the
9400 @code{g77} source tree.
9403 100: "error in format"
9404 101: "illegal unit number"
9405 102: "formatted io not allowed"
9406 103: "unformatted io not allowed"
9407 104: "direct io not allowed"
9408 105: "sequential io not allowed"
9409 106: "can't backspace file"
9410 107: "null file name"
9411 108: "can't stat file"
9412 109: "unit not connected"
9413 110: "off end of record"
9414 111: "truncation failed in endfile"
9415 112: "incomprehensible list input"
9416 113: "out of free space"
9417 114: "unit not connected"
9418 115: "read unexpected character"
9419 116: "bad logical input field"
9420 117: "bad variable type"
9421 118: "bad namelist name"
9422 119: "variable not in namelist"
9423 120: "no end record"
9424 121: "variable count incorrect"
9425 122: "subscript for scalar variable"
9426 123: "invalid array section"
9427 124: "substring out of bounds"
9428 125: "subscript out of bounds"
9429 126: "can't read file"
9430 127: "can't write file"
9431 128: "'new' file exists"
9432 129: "can't append to file"
9433 130: "non-positive record number"
9434 131: "I/O started while already doing I/O"
9437 @node Collected Fortran Wisdom
9438 @chapter Collected Fortran Wisdom
9441 @cindex code, legacy
9442 @cindex writing code
9443 @cindex code, writing
9445 Most users of @code{g77} can be divided into two camps:
9449 Those writing new Fortran code to be compiled by @code{g77}.
9452 Those using @code{g77} to compile existing, ``legacy'' code.
9455 Users writing new code generally understand most of the necessary
9456 aspects of Fortran to write ``mainstream'' code, but often need
9457 help deciding how to handle problems, such as the construction
9458 of libraries containing @code{BLOCK DATA}.
9460 Users dealing with ``legacy'' code sometimes don't have much
9461 experience with Fortran, but believe that the code they're compiling
9462 already works when compiled by other compilers (and might
9463 not understand why, as is sometimes the case, it doesn't work
9464 when compiled by @code{g77}).
9466 The following information is designed to help users do a better job
9467 coping with existing, ``legacy'' Fortran code, and with writing
9471 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9472 * Block Data and Libraries:: How @code{g77} solves a common problem.
9473 * Loops:: Fortran @code{DO} loops surprise many people.
9474 * Working Programs:: Getting programs to work should be done first.
9475 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9476 * Faster Programs:: Everybody wants these, but at what cost?
9479 @node Advantages Over f2c
9480 @section Advantages Over f2c
9482 Without @code{f2c}, @code{g77} would have taken much longer to
9483 do and probably not been as good for quite a while.
9484 Sometimes people who notice how much @code{g77} depends on, and
9485 documents encouragement to use, @code{f2c} ask why @code{g77}
9486 was created if @code{f2c} already existed.
9488 This section gives some basic answers to these questions, though it
9489 is not intended to be comprehensive.
9492 * Language Extensions:: Features used by Fortran code.
9493 * Diagnostic Abilities:: Abilities to spot problems early.
9494 * Compiler Options:: Features helpful to accommodate legacy code, etc.
9495 * Compiler Speed:: Speed of the compilation process.
9496 * Program Speed:: Speed of the generated, optimized code.
9497 * Ease of Debugging:: Debugging ease-of-use at the source level.
9498 * Character and Hollerith Constants:: A byte saved is a byte earned.
9501 @node Language Extensions
9502 @subsection Language Extensions
9504 @code{g77} offers several extensions to FORTRAN 77 language that @code{f2c}
9512 @code{CYCLE} and @code{EXIT}
9521 @code{KIND=} and @code{LEN=} notation
9524 Semicolon as statement separator
9527 Constant expressions in @code{FORMAT} statements
9528 (such as @samp{FORMAT(I<J>)},
9529 where @samp{J} is a @code{PARAMETER} named constant)
9532 @code{MvBits} intrinsic
9535 @code{libU77} (Unix-compatibility) library,
9536 with routines known to compiler as intrinsics
9537 (so they work even when compiler options are used
9538 to change the interfaces used by Fortran routines)
9541 @code{g77} also implements iterative @code{DO} loops
9542 so that they work even in the presence of certain ``extreme'' inputs,
9546 However, @code{f2c} offers a few that @code{g77} doesn't, such as:
9550 Intrinsics in @code{PARAMETER} statements
9553 Array bounds expressions (such as @samp{REAL M(N(2))})
9556 @code{AUTOMATIC} statement
9559 It is expected that @code{g77} will offer some or all of these missing
9560 features at some time in the future.
9562 @node Diagnostic Abilities
9563 @subsection Diagnostic Abilities
9565 @code{g77} offers better diagnosis of problems in @code{FORMAT} statements.
9566 @code{f2c} doesn't, for example, emit any diagnostic for
9567 @samp{FORMAT(XZFAJG10324)},
9568 leaving that to be diagnosed, at run time, by
9569 the @code{libf2c} run-time library.
9571 @node Compiler Options
9572 @subsection Compiler Options
9574 @code{g77} offers compiler options that @code{f2c} doesn't,
9575 most of which are designed to more easily accommodate
9580 Two that control the automatic appending of extra
9581 underscores to external names
9584 One that allows dollar signs (@samp{$}) in symbol names
9587 A variety that control acceptance of various
9591 Several that specify acceptable use of upper and lower case
9595 Many that enable, disable, delete, or hide
9596 groups of intrinsics
9599 One to specify the length of fixed-form source lines
9603 One to specify the the source code is written in
9604 Fortran-90-style free-form
9607 However, @code{f2c} offers a few that @code{g77} doesn't,
9608 like an option to have @code{REAL} default to @code{REAL*8}.
9609 It is expected that @code{g77} will offer all of the
9610 missing options pertinent to being a Fortran compiler
9611 at some time in the future.
9613 @node Compiler Speed
9614 @subsection Compiler Speed
9616 Saving the steps of writing and then rereading C code is a big reason
9617 why @code{g77} should be able to compile code much faster than using
9618 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9620 However, due to @code{g77}'s youth, lots of self-checking is still being
9622 As a result, this improvement is as yet unrealized
9623 (though the potential seems to be there for quite a big speedup
9625 It is possible that, as of version 0.5.18, @code{g77}
9626 is noticeably faster compiling many Fortran source files than using
9627 @code{f2c} in conjunction with @code{gcc}.
9630 @subsection Program Speed
9632 @code{g77} has the potential to better optimize code than @code{f2c},
9633 even when @code{gcc} is used to compile the output of @code{f2c},
9634 because @code{f2c} must necessarily
9635 translate Fortran into a somewhat lower-level language (C) that cannot
9636 preserve all the information that is potentially useful for optimization,
9637 while @code{g77} can gather, preserve, and transmit that information directly
9640 For example, @code{g77} implements @code{ASSIGN} and assigned
9641 @code{GOTO} using direct assignment of pointers to labels and direct
9642 jumps to labels, whereas @code{f2c} maps the assigned labels to
9643 integer values and then uses a C @code{switch} statement to encode
9644 the assigned @code{GOTO} statements.
9646 However, as is typical, theory and reality don't quite match, at least
9647 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9648 can generate code that is faster than @code{g77}.
9650 Version 0.5.18 of @code{g77} offered default
9651 settings and options, via patches to the @code{gcc}
9652 back end, that allow for better program speed, though
9653 some of these improvements also affected the performance
9654 of programs translated by @code{f2c} and then compiled
9655 by @code{g77}'s version of @code{gcc}.
9657 Version 0.5.20 of @code{g77} offers further performance
9658 improvements, at least one of which (alias analysis) is
9659 not generally applicable to @code{f2c} (though @code{f2c}
9660 could presumably be changed to also take advantage of
9661 this new capability of the @code{gcc} back end, assuming
9662 this is made available in an upcoming release of @code{gcc}).
9664 @node Ease of Debugging
9665 @subsection Ease of Debugging
9667 Because @code{g77} compiles directly to assembler code like @code{gcc},
9668 instead of translating to an intermediate language (C) as does @code{f2c},
9669 support for debugging can be better for @code{g77} than @code{f2c}.
9671 However, although @code{g77} might be somewhat more ``native'' in terms of
9672 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9673 of things ``not quite right''.
9674 Many of the important ones should be resolved in the near future.
9676 For example, @code{g77} doesn't have to worry about reserved names
9677 like @code{f2c} does.
9678 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9679 translate this to something @emph{other} than
9680 @samp{for = while;}, because C reserves those words.
9682 However, @code{g77} does still uses things like an extra level of indirection
9683 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9684 yet support multiple entry points.
9686 Another example is that, given
9694 the @code{g77} user should be able to access the variables directly, by name,
9695 without having to traverse C-like structures and unions, while @code{f2c}
9696 is unlikely to ever offer this ability (due to limitations in the
9699 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9700 take advantage of this facility at all---it doesn't emit any debugging
9701 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9702 other than information
9703 on the array of @code{char} it creates (and, in the case
9704 of local @code{EQUIVALENCE}, names) for each such area.
9706 Yet another example is arrays.
9707 @code{g77} represents them to the debugger
9708 using the same ``dimensionality'' as in the source code, while @code{f2c}
9709 must necessarily convert them all to one-dimensional arrays to fit
9710 into the confines of the C language.
9711 However, the level of support
9712 offered by debuggers for interactive Fortran-style access to arrays
9713 as compiled by @code{g77} can vary widely.
9714 In some cases, it can actually
9715 be an advantage that @code{f2c} converts everything to widely supported
9718 In fairness, @code{g77} could do many of the things @code{f2c} does
9719 to get things working at least as well as @code{f2c}---for now,
9720 the developers prefer making @code{g77} work the
9721 way they think it is supposed to, and finding help improving the
9722 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9723 to get things working properly.
9725 @node Character and Hollerith Constants
9726 @subsection Character and Hollerith Constants
9727 @cindex character constants
9728 @cindex constants, character
9729 @cindex Hollerith constants
9730 @cindex constants, Hollerith
9731 @cindex trailing null byte
9732 @cindex null byte, trailing
9733 @cindex zero byte, trailing
9735 To avoid the extensive hassle that would be needed to avoid this,
9736 @code{f2c} uses C character constants to encode character and Hollerith
9738 That means a constant like @samp{'HELLO'} is translated to
9739 @samp{"hello"} in C, which further means that an extra null byte is
9740 present at the end of the constant.
9741 This null byte is superfluous.
9743 @code{g77} does not generate such null bytes.
9744 This represents significant
9745 savings of resources, such as on systems where @file{/dev/null} or
9746 @file{/dev/zero} represent bottlenecks in the systems' performance,
9747 because @code{g77} simply asks for fewer zeros from the operating
9748 system than @code{f2c}.
9749 (Avoiding spurious use of zero bytes, each byte typically have
9750 eight zero bits, also reduces the liabilities in case
9751 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9753 @node Block Data and Libraries
9754 @section Block Data and Libraries
9755 @cindex block data and libraries
9756 @cindex BLOCK DATA statement
9757 @cindex statements, BLOCK DATA
9758 @cindex libraries, containing BLOCK DATA
9759 @cindex f2c compatibility
9760 @cindex compatibility, f2c
9762 To ensure that block data program units are linked, especially a concern
9763 when they are put into libraries, give each one a name (as in
9764 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9765 statement in every program unit that uses any common block
9766 initialized by the corresponding @code{BLOCK DATA}.
9767 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9769 that is, it generates an actual procedure having the appropriate name.
9770 The procedure does nothing but return immediately if it happens to be
9772 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9773 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9774 in the program and ensures that by generating a
9775 reference to it so the linker will make sure it is present.
9776 (Specifically, @code{g77} outputs in the data section a static pointer to the
9777 external name @samp{FOO}.)
9779 The implementation @code{g77} currently uses to make this work is
9780 one of the few things not compatible with @code{f2c} as currently
9782 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9783 issue a warning that @samp{FOO} is not otherwise referenced,
9784 and, for @samp{BLOCK DATA FOO},
9785 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9786 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9787 this particular case.
9788 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9789 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9790 will result in an unresolved reference when linked.
9792 opposite, then @samp{FOO} might not be linked in under various
9793 circumstances (such as when @samp{FOO} is in a library, or you're
9794 using a ``clever'' linker---so clever, it produces a broken program
9795 with little or no warning by omitting initializations of global data
9796 because they are contained in unreferenced procedures).
9798 The changes you make to your code to make @code{g77} handle this situation,
9799 however, appear to be a widely portable way to handle it.
9800 That is, many systems permit it (as they should, since the
9801 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9802 is a block data program unit), and of the ones
9803 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9804 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9807 Here is the recommended approach to modifying a program containing
9808 a program unit such as the following:
9812 COMMON /VARS/ X, Y, Z
9813 DATA X, Y, Z / 3., 4., 5. /
9818 If the above program unit might be placed in a library module, then
9819 ensure that every program unit in every program that references that
9820 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9821 to force the area to be initialized.
9823 For example, change a program unit that starts with
9826 INTEGER FUNCTION CURX()
9827 COMMON /VARS/ X, Y, Z
9833 so that it uses the @code{EXTERNAL} statement, as in:
9836 INTEGER FUNCTION CURX()
9837 COMMON /VARS/ X, Y, Z
9844 That way, @samp{CURX} is compiled by @code{g77} (and many other
9845 compilers) so that the linker knows it must include @samp{FOO},
9846 the @code{BLOCK DATA} program unit that sets the initial values
9847 for the variables in @samp{VAR}, in the executable program.
9851 @cindex DO statement
9852 @cindex statements, DO
9853 @cindex trips, number of
9854 @cindex number of trips
9856 The meaning of a @code{DO} loop in Fortran is precisely specified
9857 in the Fortran standard@dots{}and is quite different from what
9858 many programmers might expect.
9860 In particular, Fortran iterative @code{DO} loops are implemented as if
9861 the number of trips through the loop is calculated @emph{before}
9862 the loop is entered.
9864 The number of trips for a loop is calculated from the @var{start},
9865 @var{end}, and @var{increment} values specified in a statement such as:
9868 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9872 The trip count is evaluated using a fairly simple formula
9873 based on the three values following the @samp{=} in the
9874 statement, and it is that trip count that is effectively
9875 decremented during each iteration of the loop.
9876 If, at the beginning of an iteration of the loop, the
9877 trip count is zero or negative, the loop terminates.
9878 The per-loop-iteration modifications to @var{iter} are not
9879 related to determining whether to terminate the loop.
9881 There are two important things to remember about the trip
9886 It can be @emph{negative}, in which case it is
9887 treated as if it was zero---meaning the loop is
9888 not executed at all.
9891 The type used to @emph{calculate} the trip count
9892 is the same type as @var{iter}, but the final
9893 calculation, and thus the type of the trip
9894 count itself, always is @code{INTEGER(KIND=1)}.
9897 These two items mean that there are loops that cannot
9898 be written in straightforward fashion using the Fortran @code{DO}.
9900 For example, on a system with the canonical 32-bit two's-complement
9901 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9904 DO I = -2000000000, 2000000000
9908 Although the @var{start} and @var{end} values are well within
9909 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9910 The expected trip count is 40000000001, which is outside
9911 the range of @code{INTEGER(KIND=1)} on many systems.
9913 Instead, the above loop should be constructed this way:
9918 IF (I .GT. 2000000000) EXIT
9925 The simple @code{DO} construct and the @code{EXIT} statement
9926 (used to leave the innermost loop)
9927 are F90 features that @code{g77} supports.
9929 Some Fortran compilers have buggy implementations of @code{DO},
9930 in that they don't follow the standard.
9931 They implement @code{DO} as a straightforward translation
9932 to what, in C, would be a @code{for} statement.
9933 Instead of creating a temporary variable to hold the trip count
9934 as calculated at run time, these compilers
9935 use the iteration variable @var{iter} to control
9936 whether the loop continues at each iteration.
9938 The bug in such an implementation shows up when the
9939 trip count is within the range of the type of @var{iter},
9940 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9941 exceeds that range. For example:
9944 DO I = 2147483600, 2147483647
9948 A loop started by the above statement will work as implemented
9949 by @code{g77}, but the use, by some compilers, of a
9950 more C-like implementation akin to
9953 for (i = 2147483600; i <= 2147483647; ++i)
9957 produces a loop that does not terminate, because @samp{i}
9958 can never be greater than 2147483647, since incrementing it
9959 beyond that value overflows @samp{i}, setting it to -2147483648.
9960 This is a large, negative number that still is less than 2147483647.
9962 Another example of unexpected behavior of @code{DO} involves
9963 using a nonintegral iteration variable @var{iter}, that is,
9964 a @code{REAL} variable.
9965 Consider the following program:
9968 DATA BEGIN, END, STEP /.1, .31, .007/
9969 DO 10 R = BEGIN, END, STEP
9970 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9974 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9979 A C-like view of @code{DO} would hold that the two ``exclamatory''
9980 @code{PRINT} statements are never executed.
9981 However, this is the output of running the above program
9982 as compiled by @code{g77} on a GNU/Linux ix86 system:
9994 .310000002 .LE. .310000002!!
9997 Note that one of the two checks in the program turned up
9998 an apparent violation of the programmer's expectation---yet,
9999 the loop is correctly implemented by @code{g77}, in that
10000 it has 30 iterations.
10001 This trip count of 30 is correct when evaluated using
10002 the floating-point representations for the @var{begin},
10003 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
10005 On other systems, an apparently more accurate trip count
10006 of 31 might result, but, nevertheless, @code{g77} is
10007 faithfully following the Fortran standard, and the result
10008 is not what the author of the sample program above
10009 apparently expected.
10010 (Such other systems might, for different values in the @code{DATA}
10011 statement, violate the other programmer's expectation,
10014 Due to this combination of imprecise representation
10015 of floating-point values and the often-misunderstood
10016 interpretation of @code{DO} by standard-conforming
10017 compilers such as @code{g77}, use of @code{DO} loops
10018 with @code{REAL} iteration
10019 variables is not recommended.
10020 Such use can be caught by specifying @samp{-Wsurprising}.
10021 @xref{Warning Options}, for more information on this
10024 @node Working Programs
10025 @section Working Programs
10027 Getting Fortran programs to work in the first place can be
10028 quite a challenge---even when the programs already work on
10029 other systems, or when using other compilers.
10031 @code{g77} offers some facilities that might be useful for
10032 tracking down bugs in such programs.
10036 * Variables Assumed To Be Zero::
10037 * Variables Assumed To Be Saved::
10038 * Unwanted Variables::
10039 * Unused Arguments::
10040 * Surprising Interpretations of Code::
10041 * Aliasing Assumed To Work::
10042 * Output Assumed To Flush::
10043 * Large File Unit Numbers::
10044 * Floating-point precision::
10045 * Inconsistent Calling Sequences::
10049 @subsection Not My Type
10050 @cindex mistyped variables
10051 @cindex variables, mistyped
10052 @cindex mistyped functions
10053 @cindex functions, mistyped
10054 @cindex implicit typing
10056 A fruitful source of bugs in Fortran source code is use, or
10057 mis-use, of Fortran's implicit-typing feature, whereby the
10058 type of a variable, array, or function is determined by the
10059 first character of its name.
10061 Simple cases of this include statements like @samp{LOGX=9.227},
10062 without a statement such as @samp{REAL LOGX}.
10063 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
10064 type, with the result of the assignment being that it is given
10065 the value @samp{9}.
10067 More involved cases include a function that is defined starting
10068 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
10069 Any caller of this function that does not also declare @samp{IPS}
10070 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
10071 is likely to assume it returns
10072 @code{INTEGER}, or some other type, leading to invalid results
10073 or even program crashes.
10075 The @samp{-Wimplicit} option might catch failures to
10076 properly specify the types of
10077 variables, arrays, and functions in the code.
10079 However, in code that makes heavy use of Fortran's
10080 implicit-typing facility, this option might produce so
10081 many warnings about cases that are working, it would be
10082 hard to find the one or two that represent bugs.
10083 This is why so many experienced Fortran programmers strongly
10084 recommend widespread use of the @code{IMPLICIT NONE} statement,
10085 despite it not being standard FORTRAN 77, to completely turn
10086 off implicit typing.
10087 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
10088 FORTRAN 77 compilers.)
10090 Note that @samp{-Wimplicit} catches only implicit typing of
10092 It does not catch implicit typing of expressions such
10093 as @samp{X**(2/3)}.
10094 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
10095 is equivalent to @samp{X**0}, due to the way Fortran expressions
10096 are given types and then evaluated.
10097 (In this particular case, the programmer probably wanted
10098 @samp{X**(2./3.)}.)
10100 @node Variables Assumed To Be Zero
10101 @subsection Variables Assumed To Be Zero
10102 @cindex zero-initialized variables
10103 @cindex variables, assumed to be zero
10104 @cindex uninitialized variables
10106 Many Fortran programs were developed on systems that provided
10107 automatic initialization of all, or some, variables and arrays
10109 As a result, many of these programs depend, sometimes
10110 inadvertently, on this behavior, though to do so violates
10111 the Fortran standards.
10113 You can ask @code{g77} for this behavior by specifying the
10114 @samp{-finit-local-zero} option when compiling Fortran code.
10115 (You might want to specify @samp{-fno-automatic} as well,
10116 to avoid code-size inflation for non-optimized compilations.)
10118 Note that a program that works better when compiled with the
10119 @samp{-finit-local-zero} option
10120 is almost certainly depending on a particular system's,
10121 or compiler's, tendency to initialize some variables to zero.
10122 It might be worthwhile finding such cases and fixing them,
10123 using techniques such as compiling with the @samp{-O -Wuninitialized}
10124 options using @code{g77}.
10126 @node Variables Assumed To Be Saved
10127 @subsection Variables Assumed To Be Saved
10128 @cindex variables, retaining values across calls
10129 @cindex saved variables
10130 @cindex static variables
10132 Many Fortran programs were developed on systems that
10133 saved the values of all, or some, variables and arrays
10134 across procedure calls.
10135 As a result, many of these programs depend, sometimes
10136 inadvertently, on being able to assign a value to a
10137 variable, perform a @code{RETURN} to a calling procedure,
10138 and, upon subsequent invocation, reference the previously
10139 assigned variable to obtain the value.
10141 They expect this despite not using the @code{SAVE} statement
10142 to specify that the value in a variable is expected to survive
10143 procedure returns and calls.
10144 Depending on variables and arrays to retain values across
10145 procedure calls without using @code{SAVE} to require it violates
10146 the Fortran standards.
10148 You can ask @code{g77} to assume @code{SAVE} is specified for all
10149 relevant (local) variables and arrays by using the
10150 @samp{-fno-automatic} option.
10152 Note that a program that works better when compiled with the
10153 @samp{-fno-automatic} option
10154 is almost certainly depending on not having to use
10155 the @code{SAVE} statement as required by the Fortran standard.
10156 It might be worthwhile finding such cases and fixing them,
10157 using techniques such as compiling with the @samp{-O -Wuninitialized}
10158 options using @code{g77}.
10160 @node Unwanted Variables
10161 @subsection Unwanted Variables
10163 The @samp{-Wunused} option can find bugs involving
10164 implicit typing, sometimes
10165 more easily than using @samp{-Wimplicit} in code that makes
10166 heavy use of implicit typing.
10167 An unused variable or array might indicate that the
10168 spelling for its declaration is different from that of
10171 Other than cases involving typos, unused variables rarely
10172 indicate actual bugs in a program.
10173 However, investigating such cases thoroughly has, on occasion,
10174 led to the discovery of code that had not been completely
10175 written---where the programmer wrote declarations as needed
10176 for the whole algorithm, wrote some or even most of the code
10177 for that algorithm, then got distracted and forgot that the
10178 job was not complete.
10180 @node Unused Arguments
10181 @subsection Unused Arguments
10182 @cindex unused arguments
10183 @cindex arguments, unused
10185 As with unused variables, It is possible that unused arguments
10186 to a procedure might indicate a bug.
10187 Compile with @samp{-W -Wunused} option to catch cases of
10190 Note that @samp{-W} also enables warnings regarding overflow
10191 of floating-point constants under certain circumstances.
10193 @node Surprising Interpretations of Code
10194 @subsection Surprising Interpretations of Code
10196 The @samp{-Wsurprising} option can help find bugs involving
10197 expression evaluation or in
10198 the way @code{DO} loops with non-integral iteration variables
10200 Cases found by this option might indicate a difference of
10201 interpretation between the author of the code involved, and
10202 a standard-conforming compiler such as @code{g77}.
10203 Such a difference might produce actual bugs.
10205 In any case, changing the code to explicitly do what the
10206 programmer might have expected it to do, so @code{g77} and
10207 other compilers are more likely to follow the programmer's
10208 expectations, might be worthwhile, especially if such changes
10209 make the program work better.
10211 @node Aliasing Assumed To Work
10212 @subsection Aliasing Assumed To Work
10213 @cindex -falias-check option
10214 @cindex options, -falias-check
10215 @cindex -fargument-alias option
10216 @cindex options, -fargument-alias
10217 @cindex -fargument-noalias option
10218 @cindex options, -fargument-noalias
10219 @cindex -fno-argument-noalias-global option
10220 @cindex options, -fno-argument-noalias-global
10222 @cindex anti-aliasing
10223 @cindex overlapping arguments
10225 @cindex association, storage
10226 @cindex storage association
10227 @cindex scheduling of reads and writes
10228 @cindex reads and writes, scheduling
10230 The @samp{-falias-check}, @samp{-fargument-alias},
10231 @samp{-fargument-noalias},
10232 and @samp{-fno-argument-noalias-global} options,
10233 introduced in version 0.5.20 and
10234 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10235 were withdrawn as of @code{g77} version 0.5.23
10236 due to their not being supported by @code{gcc} version 2.8.
10238 These options, which control the assumptions regarding aliasing
10239 (overlapping) of writes and reads to main memory (core) made
10240 by the @code{gcc} back end,
10241 might well be added back (in some form) in a future version
10244 However, these options @emph{are} supported by @code{egcs}.
10246 The information below still is useful, but applies to
10247 only those versions of @code{g77} that support the
10248 alias analysis implied by support for these options.
10250 These options are effective only when compiling with @samp{-O}
10251 (specifying any level other than @samp{-O0})
10252 or with @samp{-falias-check}.
10254 The default for Fortran code is @samp{-fargument-noalias-global}.
10255 (The default for C code and code written in other C-based languages
10256 is @samp{-fargument-alias}.
10257 These defaults apply regardless of whether you use @code{g77} or
10258 @code{gcc} to compile your code.)
10260 Note that, on some systems, compiling with @samp{-fforce-addr} in
10261 effect can produce more optimal code when the default aliasing
10262 options are in effect (and when optimization is enabled).
10264 If your program is not working when compiled with optimization,
10265 it is possible it is violating the Fortran standards (77 and 90)
10266 by relying on the ability to ``safely'' modify variables and
10267 arrays that are aliased, via procedure calls, to other variables
10268 and arrays, without using @code{EQUIVALENCE} to explicitly
10269 set up this kind of aliasing.
10271 (The FORTRAN 77 standard's prohibition of this sort of
10272 overlap, generally referred to therein as ``storage
10273 assocation'', appears in Sections 15.9.3.6.
10274 This prohibition allows implementations, such as @code{g77},
10275 to, for example, implement the passing of procedures and
10276 even values in @code{COMMON} via copy operations into local,
10277 perhaps more efficiently accessed temporaries at entry to a
10278 procedure, and, where appropriate, via copy operations back
10279 out to their original locations in memory at exit from that
10280 procedure, without having to take into consideration the
10281 order in which the local copies are updated by the code,
10282 among other things.)
10284 To test this hypothesis, try compiling your program with
10285 the @samp{-fargument-alias} option, which causes the
10286 compiler to revert to assumptions essentially the same as
10287 made by versions of @code{g77} prior to 0.5.20.
10289 If the program works using this option, that strongly suggests
10290 that the bug is in your program.
10291 Finding and fixing the bug(s) should result in a program that
10292 is more standard-conforming and that can be compiled by @code{g77}
10293 in a way that results in a faster executable.
10295 (You might want to try compiling with @samp{-fargument-noalias},
10296 a kind of half-way point, to see if the problem is limited to
10297 aliasing between dummy arguments and @code{COMMON} variables---this
10298 option assumes that such aliasing is not done, while still allowing
10299 aliasing among dummy arguments.)
10301 An example of aliasing that is invalid according to the standards
10302 is shown in the following program, which might @emph{not} produce
10303 the expected results when executed:
10311 SUBROUTINE FOO(J, K)
10318 The above program attempts to use the temporary aliasing of the
10319 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10320 pathological behavior---the simultaneous changing of the values
10321 of @emph{both} @samp{J} and @samp{K} when either one of them
10324 The programmer likely expects the program to print these values:
10331 However, since the program is not standard-conforming, an
10332 implementation's behavior when running it is undefined, because
10333 subroutine @samp{FOO} modifies at least one of the arguments,
10334 and they are aliased with each other.
10335 (Even if one of the assignment statements was deleted, the
10336 program would still violate these rules.
10337 This kind of on-the-fly aliasing is permitted by the standard
10338 only when none of the aliased items are defined, or written,
10339 while the aliasing is in effect.)
10341 As a practical example, an optimizing compiler might schedule
10342 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10343 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10344 resulting in the following output:
10351 Essentially, compilers are promised (by the standard and, therefore,
10352 by programmers who write code they claim to be standard-conforming)
10353 that if they cannot detect aliasing via static analysis of a single
10354 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10355 such aliasing exists.
10356 In such cases, compilers are free to assume that an assignment to
10357 one variable will not change the value of another variable, allowing
10358 it to avoid generating code to re-read the value of the other
10359 variable, to re-schedule reads and writes, and so on, to produce
10360 a faster executable.
10362 The same promise holds true for arrays (as seen by the called
10363 procedure)---an element of one dummy array cannot be aliased
10364 with, or overlap, any element of another dummy array or be
10365 in a @code{COMMON} area known to the procedure.
10367 (These restrictions apply only when the procedure defines, or
10368 writes to, one of the aliased variables or arrays.)
10370 Unfortunately, there is no way to find @emph{all} possible cases of
10371 violations of the prohibitions against aliasing in Fortran code.
10372 Static analysis is certainly imperfect, as is run-time analysis,
10373 since neither can catch all violations.
10374 (Static analysis can catch all likely violations, and some that
10375 might never actually happen, while run-time analysis can catch
10376 only those violations that actually happen during a particular run.
10377 Neither approach can cope with programs mixing Fortran code with
10378 routines written in other languages, however.)
10380 Currently, @code{g77} provides neither static nor run-time facilities
10381 to detect any cases of this problem, although other products might.
10382 Run-time facilities are more likely to be offered by future
10383 versions of @code{g77}, though patches improving @code{g77} so that
10384 it provides either form of detection are welcome.
10386 @node Output Assumed To Flush
10387 @subsection Output Assumed To Flush
10388 @cindex ALWAYS_FLUSH
10389 @cindex synchronous write errors
10391 @cindex flushing output
10393 @cindex I/O, flushing
10394 @cindex output, flushing
10395 @cindex writes, flushing
10397 @cindex network file system
10399 For several versions prior to 0.5.20, @code{g77} configured its
10400 version of the @code{libf2c} run-time library so that one of
10401 its configuration macros, @code{ALWAYS_FLUSH}, was defined.
10403 This was done as a result of a belief that many programs expected
10404 output to be flushed to the operating system (under UNIX, via
10405 the @code{fflush()} library call) with the result that errors,
10406 such as disk full, would be immediately flagged via the
10407 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10409 Because of the adverse effects this approach had on the performance
10410 of many programs, @code{g77} no longer configures @code{libf2c}
10411 (now named @code{libg2c} in its @code{g77} incarnation)
10412 to always flush output.
10414 If your program depends on this behavior, either insert the
10415 appropriate @samp{CALL FLUSH} statements, or modify the sources
10416 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10417 relink your programs with the modified library.
10419 (Ideally, @code{libg2c} would offer the choice at run-time, so
10420 that a compile-time option to @code{g77} or @code{f2c} could
10421 result in generating the appropriate calls to flushing or
10422 non-flushing library routines.)
10424 @xref{Always Flush Output}, for information on how to modify
10425 the @code{g77} source tree so that a version of @code{libg2c}
10426 can be built and installed with the @code{ALWAYS_FLUSH} macro defined.
10428 @node Large File Unit Numbers
10429 @subsection Large File Unit Numbers
10431 @cindex unit numbers
10432 @cindex maximum unit number
10433 @cindex illegal unit number
10434 @cindex increasing maximum unit number
10436 If your program crashes at run time with a message including
10437 the text @samp{illegal unit number}, that probably is
10438 a message from the run-time library, @code{libg2c}.
10440 The message means that your program has attempted to use a
10441 file unit number that is out of the range accepted by
10443 Normally, this range is 0 through 99, and the high end
10444 of the range is controlled by a @code{libg2c} source-file
10445 macro named @code{MXUNIT}.
10447 If you can easily change your program to use unit numbers
10448 in the range 0 through 99, you should do so.
10450 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10451 to change @code{MXUNIT} in @code{libg2c} so you can build and
10452 install a new version of @code{libg2c} that supports the larger
10453 unit numbers you need.
10455 @emph{Note:} While @code{libg2c} places a limit on the range
10456 of Fortran file-unit numbers, the underlying library and operating
10457 system might impose different kinds of limits.
10458 For example, some systems limit the number of files simultaneously
10459 open by a running program.
10460 Information on how to increase these limits should be found
10461 in your system's documentation.
10463 @node Floating-point precision
10464 @subsection Floating-point precision
10466 @cindex IEEE 754 conformance
10467 @cindex conformance, IEEE 754
10468 @cindex floating-point, precision
10469 @cindex ix86 floating-point
10470 @cindex x86 floating-point
10471 If your program depends on exact IEEE 754 floating-point handling it may
10472 help on some systems---specifically x86 or m68k hardware---to use
10473 the @samp{-ffloat-store} option or to reset the precision flag on the
10474 floating-point unit.
10475 @xref{Optimize Options}.
10477 However, it might be better simply to put the FPU into double precision
10478 mode and not take the performance hit of @samp{-ffloat-store}. On x86
10479 and m68k GNU systems you can do this with a technique similar to that
10480 for turning on floating-point exceptions
10481 (@pxref{Floating-point Exception Handling}).
10482 The control word could be set to double precision by
10483 replacing the @code{__setfpucw} call with one like this:
10485 __setfpucw ((_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE);
10487 (It is not clear whether this has any effect on the operation of the GNU
10488 maths library, but we have no evidence of it causing trouble.)
10490 Some targets (such as the Alpha) may need special options for full IEEE
10492 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and Porting GNU CC}.
10494 @node Inconsistent Calling Sequences
10495 @subsection Inconsistent Calling Sequences
10498 @cindex floating-point, errors
10499 @cindex ix86 FPU stack
10500 @cindex x86 FPU stack
10501 Code containing inconsistent calling sequences in the same file is
10502 normally rejected---see @ref{GLOBALS}.
10503 (Use, say, @code{ftnchek} to ensure
10504 consistency across source files.
10505 @xref{f2c Skeletons and Prototypes,,
10506 Generating Skeletons and Prototypes with @code{f2c}}.)
10508 Mysterious errors, which may appear to be code generation problems, can
10509 appear specifically on the x86 architecture with some such
10510 inconsistencies. On x86 hardware, floating-point return values of
10511 functions are placed on the floating-point unit's register stack, not
10512 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
10513 @code{FUNCTION} as some other sort of procedure, or vice versa,
10514 scrambles the floating-point stack. This may break unrelated code
10515 executed later. Similarly if, say, external C routines are written
10518 @node Overly Convenient Options
10519 @section Overly Convenient Command-line Options
10520 @cindex overly convenient options
10521 @cindex options, overly convenient
10523 These options should be used only as a quick-and-dirty way to determine
10524 how well your program will run under different compilation models
10525 without having to change the source.
10526 Some are more problematic
10527 than others, depending on how portable and maintainable you want the
10528 program to be (and, of course, whether you are allowed to change it
10529 at all is crucial).
10531 You should not continue to use these command-line options to compile
10532 a given program, but rather should make changes to the source code:
10535 @cindex -finit-local-zero option
10536 @cindex options, -finit-local-zero
10537 @item -finit-local-zero
10538 (This option specifies that any uninitialized local variables
10539 and arrays have default initialization to binary zeros.)
10541 Many other compilers do this automatically, which means lots of
10542 Fortran code developed with those compilers depends on it.
10544 It is safer (and probably
10545 would produce a faster program) to find the variables and arrays that
10546 need such initialization and provide it explicitly via @code{DATA}, so that
10547 @samp{-finit-local-zero} is not needed.
10549 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10550 find likely candidates, but
10551 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10552 or this technique won't work.
10554 @cindex -fno-automatic option
10555 @cindex options, -fno-automatic
10556 @item -fno-automatic
10557 (This option specifies that all local variables and arrays
10558 are to be treated as if they were named in @code{SAVE} statements.)
10560 Many other compilers do this automatically, which means lots of
10561 Fortran code developed with those compilers depends on it.
10563 The effect of this is that all non-automatic variables and arrays
10564 are made static, that is, not placed on the stack or in heap storage.
10565 This might cause a buggy program to appear to work better.
10566 If so, rather than relying on this command-line option (and hoping all
10567 compilers provide the equivalent one), add @code{SAVE}
10568 statements to some or all program unit sources, as appropriate.
10569 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10570 to find likely candidates, but
10571 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10572 or this technique won't work.
10574 The default is @samp{-fautomatic}, which tells @code{g77} to try
10575 and put variables and arrays on the stack (or in fast registers)
10576 where possible and reasonable.
10577 This tends to make programs faster.
10579 @cindex automatic arrays
10580 @cindex arrays, automatic
10581 @emph{Note:} Automatic variables and arrays are not affected
10583 These are variables and arrays that are @emph{necessarily} automatic,
10584 either due to explicit statements, or due to the way they are
10586 Examples include local variables and arrays not given the
10587 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10588 and local arrays declared with non-constant bounds (automatic
10590 Currently, @code{g77} supports only automatic arrays, not
10591 @code{RECURSIVE} procedures or other means of explicitly
10592 specifying that variables or arrays are automatic.
10594 @cindex -f@var{group}-intrinsics-hide option
10595 @cindex options, -f@var{group}-intrinsics-hide
10596 @item -f@var{group}-intrinsics-hide
10597 Change the source code to use @code{EXTERNAL} for any external procedure
10598 that might be the name of an intrinsic.
10599 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10602 @node Faster Programs
10603 @section Faster Programs
10604 @cindex speed, of programs
10605 @cindex programs, speeding up
10607 Aside from the usual @code{gcc} options, such as @samp{-O},
10608 @samp{-ffast-math}, and so on, consider trying some of the
10609 following approaches to speed up your program (once you get
10614 * Prefer Automatic Uninitialized Variables::
10615 * Avoid f2c Compatibility::
10616 * Use Submodel Options::
10620 @subsection Aligned Data
10622 @cindex data, aligned
10623 @cindex stack, aligned
10624 @cindex aligned data
10625 @cindex aligned stack
10626 @cindex Pentium optimizations
10627 @cindex optimization, for Pentium
10629 On some systems, such as those with Pentium Pro CPUs, programs
10630 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10631 might run much slower
10632 than possible due to the compiler not aligning these 64-bit
10633 values to 64-bit boundaries in memory.
10634 (The effect also is present, though
10635 to a lesser extent, on the 586 (Pentium) architecture.)
10637 The Intel x86 architecture generally ensures that these programs will
10638 work on all its implementations,
10639 but particular implementations (such as Pentium Pro)
10640 perform better with more strict alignment.
10641 (Such behavior isn't unique to the Intel x86 architecture.)
10642 Other architectures might @emph{demand} 64-bit alignment
10645 There are a variety of approaches to use to address this problem:
10649 @cindex @code{COMMON} layout
10650 @cindex layout of @code{COMMON} blocks
10651 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10652 that the variables and arrays with the widest alignment
10653 guidelines come first.
10655 For example, on most systems, this would mean placing
10656 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10657 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10658 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10659 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10660 and @code{INTEGER(KIND=3)} entities.
10662 The reason to use such placement is it makes it more likely
10663 that your data will be aligned properly, without requiring
10664 you to do detailed analysis of each aggregate (@code{COMMON}
10665 and @code{EQUIVALENCE}) area.
10667 Specifically, on systems where the above guidelines are
10668 appropriate, placing @code{CHARACTER} entities before
10669 @code{REAL(KIND=2)} entities can work just as well,
10670 but only if the number of bytes occupied by the @code{CHARACTER}
10671 entities is divisible by the recommended alignment for
10672 @code{REAL(KIND=2)}.
10674 By ordering the placement of entities in aggregate
10675 areas according to the simple guidelines above, you
10676 avoid having to carefully count the number of bytes
10677 occupied by each entity to determine whether the
10678 actual alignment of each subsequent entity meets the
10679 alignment guidelines for the type of that entity.
10681 If you don't ensure correct alignment of @code{COMMON} elements, the
10682 compiler may be forced by some systems to violate the Fortran semantics by
10683 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10684 If the unfortunate practice is employed of overlaying different types of
10685 data in the @code{COMMON} block, the different variants
10686 of this block may become misaligned with respect to each other.
10687 Even if your platform doesn't require strict alignment,
10688 @code{COMMON} should be laid out as above for portability.
10689 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10690 possible requirement, which is compiler-independent on a given platform.)
10693 @cindex -malign-double option
10694 @cindex options, -malign-double
10695 Use the (x86-specific) @samp{-malign-double} option when compiling
10696 programs for the Pentium and Pentium Pro architectures (called 586
10697 and 686 in the @code{gcc} configuration subsystem).
10698 The warning about this in the @code{gcc} manual isn't
10699 generally relevant to Fortran,
10700 but using it will force @code{COMMON} to be padded if necessary to align
10701 @code{DOUBLE PRECISION} data.
10703 When @code{DOUBLE PRECISION} data is forcibly aligned
10704 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10705 @code{g77} issues a warning about the need to
10708 In this case, each and every program unit that uses
10709 the same @code{COMMON} area
10710 must specify the same layout of variables and their types
10712 and be compiled with @samp{-malign-double} as well.
10713 @code{g77} will issue warnings in each case,
10714 but as long as every program unit using that area
10715 is compiled with the same warnings,
10716 the resulting object files should work when linked together
10717 unless the program makes additional assumptions about
10718 @code{COMMON} area layouts that are outside the scope
10719 of the FORTRAN 77 standard,
10720 or uses @code{EQUIVALENCE} or different layouts
10721 in ways that assume no padding is ever inserted by the compiler.
10724 Ensure that @file{crt0.o} or @file{crt1.o}
10725 on your system guarantees a 64-bit
10726 aligned stack for @code{main()}.
10727 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10728 but we don't know of any other x86 setups where it will be right.
10729 Read your system's documentation to determine if
10730 it is appropriate to upgrade to a more recent version
10731 to obtain the optimal alignment.
10734 Progress is being made on making this work
10735 ``out of the box'' on future versions of @code{g77},
10736 @code{gcc}, and some of the relevant operating systems
10737 (such as GNU/Linux).
10739 @cindex alignment testing
10740 @cindex testing alignment
10741 A package that tests the degree to which a Fortran compiler
10742 (such as @code{g77})
10743 aligns 64-bit floating-point variables and arrays
10744 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
10746 @node Prefer Automatic Uninitialized Variables
10747 @subsection Prefer Automatic Uninitialized Variables
10749 If you're using @samp{-fno-automatic} already, you probably
10750 should change your code to allow compilation with @samp{-fautomatic}
10751 (the default), to allow the program to run faster.
10753 Similarly, you should be able to use @samp{-fno-init-local-zero}
10754 (the default) instead of @samp{-finit-local-zero}.
10755 This is because it is rare that every variable affected by these
10756 options in a given program actually needs to
10759 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10760 every local non-automatic variable and array, affects even things like
10761 @code{DO} iteration
10762 variables, which rarely need to be @code{SAVE}d, and this often reduces
10763 run-time performances.
10764 Similarly, @samp{-fno-init-local-zero} forces such
10765 variables to be initialized to zero---when @code{SAVE}d (such as when
10766 @samp{-fno-automatic}), this by itself generally affects only
10767 startup time for a program, but when not @code{SAVE}d,
10768 it can slow down the procedure every time it is called.
10770 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10771 for information on the @samp{-fno-automatic} and
10772 @samp{-finit-local-zero} options and how to convert
10773 their use into selective changes in your own code.
10775 @node Avoid f2c Compatibility
10776 @subsection Avoid f2c Compatibility
10777 @cindex -fno-f2c option
10778 @cindex options, -fno-f2c
10779 @cindex @code{f2c} compatibility
10780 @cindex compatibility, @code{f2c}
10782 If you aren't linking with any code compiled using
10783 @code{f2c}, try using the @samp{-fno-f2c} option when
10784 compiling @emph{all} the code in your program.
10785 (Note that @code{libf2c} is @emph{not} an example of code
10786 that is compiled using @code{f2c}---it is compiled by a C
10787 compiler, typically @code{gcc}.)
10789 @node Use Submodel Options
10790 @subsection Use Submodel Options
10793 Using an appropriate @samp{-m} option to generate specific code for your
10794 CPU may be worthwhile, though it may mean the executable won't run on
10795 other versions of the CPU that don't support the same instruction set.
10796 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10797 Porting GNU CC}. For instance on an x86 system the compiler might have
10798 been built---as shown by @samp{g77 -v}---for the target
10799 @samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
10800 generate code best optimized for a Pentium you could use the option
10801 @samp{-march=pentium}.
10803 For recent CPUs that don't have explicit support in the released version
10804 of @code{gcc}, it @emph{might} still be possible to get improvements
10805 with certain @samp{-m} options.
10807 @samp{-fomit-frame-pointer} can help performance on x86 systems and
10808 others. It will, however, inhibit debugging on the systems on which it
10809 is not turned on anyway by @samp{-O}.
10812 @chapter Known Causes of Trouble with GNU Fortran
10813 @cindex bugs, known
10814 @cindex installation trouble
10815 @cindex known causes of trouble
10817 This section describes known problems that affect users of GNU Fortran.
10818 Most of these are not GNU Fortran bugs per se---if they were, we would
10820 But the result for a user might be like the result of a bug.
10822 Some of these problems are due to bugs in other software, some are
10823 missing features that are too much work to add, and some are places
10824 where people's opinions differ as to what is best.
10826 Information on bugs that show up when configuring, porting, building,
10827 or installing @code{g77} is not provided here.
10828 @xref{Problems Installing}.
10830 To find out about major bugs discovered in the current release and
10831 possible workarounds for them, see
10832 @uref{ftp://alpha.gnu.org/g77.plan}.
10834 (Note that some of this portion of the manual is lifted
10835 directly from the @code{gcc} manual, with minor modifications
10836 to tailor it to users of @code{g77}.
10837 Anytime a bug seems to have more to do with the @code{gcc}
10838 portion of @code{g77}, see
10839 @ref{Trouble,,Known Causes of Trouble with GNU CC,
10840 gcc,Using and Porting GNU CC}.)
10843 * But-bugs:: Bugs really in other programs or elsewhere.
10844 * Known Bugs:: Bugs known to be in this version of @code{g77}.
10845 * Missing Features:: Features we already know we want to add later.
10846 * Disappointments:: Regrettable things we can't change.
10847 * Non-bugs:: Things we think are right, but some others disagree.
10848 * Warnings and Errors:: Which problems in your code get warnings,
10849 and which get errors.
10853 @section Bugs Not In GNU Fortran
10856 These are bugs to which the maintainers often have to reply,
10857 ``but that isn't a bug in @code{g77}@dots{}''.
10858 Some of these already are fixed in new versions of other
10859 software; some still need to be fixed; some are problems
10860 with how @code{g77} is installed or is being used;
10861 some are the result of bad hardware that causes software
10862 to misbehave in sometimes bizarre ways;
10863 some just cannot be addressed at this time until more
10864 is known about the problem.
10866 Please don't re-report these bugs to the @code{g77} maintainers---if
10867 you must remind someone how important it is to you that the problem
10868 be fixed, talk to the people responsible for the other products
10869 identified below, but preferably only after you've tried the
10870 latest versions of those products.
10871 The @code{g77} maintainers have their hands full working on
10872 just fixing and improving @code{g77}, without serving as a
10873 clearinghouse for all bugs that happen to affect @code{g77}
10876 @xref{Collected Fortran Wisdom}, for information on behavior
10877 of Fortran programs, and the programs that compile them, that
10878 might be @emph{thought} to indicate bugs.
10881 * Signal 11 and Friends:: Strange behavior by any software.
10882 * Cannot Link Fortran Programs:: Unresolved references.
10883 * Large Common Blocks:: Problems on older GNU/Linux systems.
10884 * Debugger Problems:: When the debugger crashes.
10885 * NeXTStep Problems:: Misbehaving executables.
10886 * Stack Overflow:: More misbehaving executables.
10887 * Nothing Happens:: Less behaving executables.
10888 * Strange Behavior at Run Time:: Executables misbehaving due to
10889 bugs in your program.
10890 * Floating-point Errors:: The results look wrong, but@dots{}.
10893 @node Signal 11 and Friends
10894 @subsection Signal 11 and Friends
10896 @cindex hardware errors
10898 A whole variety of strange behaviors can occur when the
10899 software, or the way you are using the software,
10900 stresses the hardware in a way that triggers hardware bugs.
10901 This might seem hard to believe, but it happens frequently
10902 enough that there exist documents explaining in detail
10903 what the various causes of the problems are, what
10904 typical symptoms look like, and so on.
10906 Generally these problems are referred to in this document
10907 as ``signal 11'' crashes, because the Linux kernel, running
10908 on the most popular hardware (the Intel x86 line), often
10909 stresses the hardware more than other popular operating
10911 When hardware problems do occur under GNU/Linux on x86
10912 systems, these often manifest themselves as ``signal 11''
10913 problems, as illustrated by the following diagnostic:
10916 sh# @kbd{g77 myprog.f}
10917 gcc: Internal compiler error: program f771 got fatal signal 11
10921 It is @emph{very} important to remember that the above
10922 message is @emph{not} the only one that indicates a
10923 hardware problem, nor does it always indicate a hardware
10926 In particular, on systems other than those running the Linux
10927 kernel, the message might appear somewhat or very different,
10928 as it will if the error manifests itself while running a
10929 program other than the @code{g77} compiler.
10931 it will appear somewhat different when running your program,
10932 when running Emacs, and so on.
10934 How to cope with such problems is well beyond the scope
10937 However, users of Linux-based systems (such as GNU/Linux)
10938 should review @uref{http://www.bitwizard.nl/sig11/}, a source
10939 of detailed information on diagnosing hardware problems,
10940 by recognizing their common symptoms.
10942 Users of other operating systems and hardware might
10943 find this reference useful as well.
10944 If you know of similar material for another hardware/software
10945 combination, please let us know so we can consider including
10946 a reference to it in future versions of this manual.
10948 @node Cannot Link Fortran Programs
10949 @subsection Cannot Link Fortran Programs
10950 @cindex unresolved reference (various)
10951 @cindex linking error for user code
10953 @cindex @code{ld}, error linking user code
10954 @cindex @code{ld}, can't find strange names
10955 On some systems, perhaps just those with out-of-date (shared?)
10956 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10957 programs (which should be done using @code{g77}).
10959 If this happens to you, try appending @samp{-lc} to the command you
10960 use to link the program, e.g. @samp{g77 foo.f -lc}.
10961 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10962 but it cannot also specify @samp{-lc} because not all systems have a
10963 file named @file{libc.a}.
10965 It is unclear at this point whether there are legitimately installed
10966 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10969 @cindex undefined reference (_main)
10970 @cindex linking error, user code
10971 @cindex @code{ld}, error linking user code
10973 @cindex @code{ld}, can't find @samp{_main}
10974 If your program doesn't link due to unresolved references to names
10975 like @samp{_main}, make sure you're using the @code{g77} command to do the
10976 link, since this command ensures that the necessary libraries are
10977 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10978 command to do the actual link.
10979 (Use the @samp{-v} option to discover
10980 more about what actually happens when you use the @code{g77} and @code{gcc}
10983 Also, try specifying @samp{-lc} as the last item on the @code{g77}
10984 command line, in case that helps.
10986 @node Large Common Blocks
10987 @subsection Large Common Blocks
10988 @cindex common blocks, large
10989 @cindex large common blocks
10990 @cindex linking, errors
10991 @cindex @code{ld}, errors
10992 @cindex errors, linker
10993 On some older GNU/Linux systems, programs with common blocks larger
10994 than 16MB cannot be linked without some kind of error
10995 message being produced.
10997 This is a bug in older versions of @code{ld}, fixed in
10998 more recent versions of @code{binutils}, such as version 2.6.
11000 @node Debugger Problems
11001 @subsection Debugger Problems
11002 @cindex @code{gdb}, support
11003 @cindex support, @code{gdb}
11004 There are some known problems when using @code{gdb} on code
11005 compiled by @code{g77}.
11006 Inadequate investigation as of the release of 0.5.16 results in not
11007 knowing which products are the culprit, but @file{gdb-4.14} definitely
11008 crashes when, for example, an attempt is made to print the contents
11009 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
11010 machines, plus some others.
11011 Attempts to access assumed-size arrays are
11012 also known to crash recent versions of @code{gdb}.
11013 (@code{gdb}'s Fortran support was done for a different compiler
11014 and isn't properly compatible with @code{g77}.)
11016 @node NeXTStep Problems
11017 @subsection NeXTStep Problems
11018 @cindex NeXTStep problems
11020 @cindex segmentation violation
11021 Developers of Fortran code on NeXTStep (all architectures) have to
11022 watch out for the following problem when writing programs with
11023 large, statically allocated (i.e. non-stack based) data structures
11024 (common blocks, saved arrays).
11026 Due to the way the native loader (@file{/bin/ld}) lays out
11027 data structures in virtual memory, it is very easy to create an
11028 executable wherein the @samp{__DATA} segment overlaps (has addresses in
11029 common) with the @samp{UNIX STACK} segment.
11031 This leads to all sorts of trouble, from the executable simply not
11032 executing, to bus errors.
11033 The NeXTStep command line tool @code{ebadexec} points to
11034 the problem as follows:
11037 % @kbd{/bin/ebadexec a.out}
11038 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
11039 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
11040 STACK segment (truncated address = 0x400000 rounded size =
11041 0x3c00000) of executable file: a.out
11044 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
11047 This can be cured by assigning the @samp{__DATA} segment
11048 (virtual) addresses beyond the stack segment.
11050 estimate for this is from address 6000000 (hexadecimal) onwards---this
11051 has always worked for me [Toon Moene]:
11054 % @kbd{g77 -segaddr __DATA 6000000 test.f}
11055 % @kbd{ebadexec a.out}
11056 ebadexec: file: a.out appears to be executable
11060 Browsing through @file{@value{path-g77}/Makefile.in},
11061 you will find that the @code{f771} program itself also has to be
11062 linked with these flags---it has large statically allocated
11064 (Version 0.5.18 reduces this somewhat, but probably
11067 (The above item was contributed by Toon Moene
11068 (@email{toon@@moene.indiv.nluug.nl}).)
11070 @node Stack Overflow
11071 @subsection Stack Overflow
11072 @cindex stack, overflow
11073 @cindex segmentation violation
11074 @code{g77} code might fail at runtime (probably with a ``segmentation
11075 violation'') due to overflowing the stack.
11076 This happens most often on systems with an environment
11077 that provides substantially more heap space (for use
11078 when arbitrarily allocating and freeing memory) than stack
11081 Often this can be cured by
11082 increasing or removing your shell's limit on stack usage, typically
11083 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
11084 @kbd{ulimit -s} (in @code{sh} and derivatives).
11086 Increasing the allowed stack size might, however, require
11087 changing some operating system or system configuration parameters.
11089 You might be able to work around the problem by compiling with the
11090 @samp{-fno-automatic} option to reduce stack usage, probably at the
11093 @xref{Maximum Stackable Size}, for information on patching
11094 @code{g77} to use different criteria for placing local
11095 non-automatic variables and arrays on the stack.
11097 @cindex automatic arrays
11098 @cindex arrays, automatic
11099 However, if your program uses large automatic arrays
11100 (for example, has declarations like @samp{REAL A(N)} where
11101 @samp{A} is a local array and @samp{N} is a dummy or
11102 @code{COMMON} variable that can have a large value),
11103 neither use of @samp{-fno-automatic},
11104 nor changing the cut-off point for @code{g77} for using the stack,
11105 will solve the problem by changing the placement of these
11106 large arrays, as they are @emph{necessarily} automatic.
11108 @code{g77} currently provides no means to specify that
11109 automatic arrays are to be allocated on the heap instead
11111 So, other than increasing the stack size, your best bet is to
11112 change your source code to avoid large automatic arrays.
11113 Methods for doing this currently are outside the scope of
11116 (@emph{Note:} If your system puts stack and heap space in the
11117 same memory area, such that they are effectively combined, then
11118 a stack overflow probably indicates a program that is either
11119 simply too large for the system, or buggy.)
11121 @node Nothing Happens
11122 @subsection Nothing Happens
11123 @cindex nothing happens
11124 @cindex naming programs
11125 @cindex @code{test} programs
11126 @cindex programs, @code{test}
11127 It is occasionally reported that a ``simple'' program,
11128 such as a ``Hello, World!'' program, does nothing when
11129 it is run, even though the compiler reported no errors,
11130 despite the program containing nothing other than a
11131 simple @code{PRINT} statement.
11133 This most often happens because the program has been
11134 compiled and linked on a UNIX system and named @code{test},
11135 though other names can lead to similarly unexpected
11136 run-time behavior on various systems.
11138 Essentially this problem boils down to giving
11139 your program a name that is already known to
11140 the shell you are using to identify some other program,
11141 which the shell continues to execute instead of your
11142 program when you invoke it via, for example:
11149 Under UNIX and many other system, a simple command name
11150 invokes a searching mechanism that might well not choose
11151 the program located in the current working directory if
11152 there is another alternative (such as the @code{test}
11153 command commonly installed on UNIX systems).
11155 The reliable way to invoke a program you just linked in
11156 the current directory under UNIX is to specify it using
11157 an explicit pathname, as in:
11165 Users who encounter this problem should take the time to
11166 read up on how their shell searches for commands, how to
11167 set their search path, and so on.
11168 The relevant UNIX commands to learn about include
11169 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
11170 @code{set} and @code{env}), @code{which}, and @code{find}.
11172 @node Strange Behavior at Run Time
11173 @subsection Strange Behavior at Run Time
11174 @cindex segmentation violation
11176 @cindex overwritten data
11177 @cindex data, overwritten
11178 @code{g77} code might fail at runtime with ``segmentation violation'',
11179 ``bus error'', or even something as subtle as a procedure call
11180 overwriting a variable or array element that it is not supposed
11183 These can be symptoms of a wide variety of actual bugs that
11184 occurred earlier during the program's run, but manifested
11185 themselves as @emph{visible} problems some time later.
11187 Overflowing the bounds of an array---usually by writing beyond
11188 the end of it---is one of two kinds of bug that often occurs
11190 (Compile your code with the @samp{-fbounds-check} option
11191 to catch many of these kinds of errors at program run time.)
11193 The other kind of bug is a mismatch between the actual arguments
11194 passed to a procedure and the dummy arguments as declared by that
11197 Both of these kinds of bugs, and some others as well, can be
11198 difficult to track down, because the bug can change its behavior,
11199 or even appear to not occur, when using a debugger.
11201 That is, these bugs can be quite sensitive to data, including
11202 data representing the placement of other data in memory (that is,
11203 pointers, such as the placement of stack frames in memory).
11205 @code{g77} now offers the
11206 ability to catch and report some of these problems at compile, link, or
11207 run time, such as by generating code to detect references to
11208 beyond the bounds of most arrays (except assumed-size arrays),
11209 and checking for agreement between calling and called procedures.
11210 Future improvements are likely to be made in the procedure-mismatch area,
11213 In the meantime, finding and fixing the programming
11214 bugs that lead to these behaviors is, ultimately, the user's
11215 responsibility, as difficult as that task can sometimes be.
11217 @cindex infinite spaces printed
11218 @cindex space, endless printing of
11219 @cindex libc, non-ANSI or non-default
11221 @cindex linking against non-standard library
11223 One runtime problem that has been observed might have a simple solution.
11224 If a formatted @code{WRITE} produces an endless stream of spaces, check
11225 that your program is linked against the correct version of the C library.
11226 The configuration process takes care to account for your
11227 system's normal @file{libc} not being ANSI-standard, which will
11228 otherwise cause this behaviour.
11229 If your system's default library is
11230 ANSI-standard and you subsequently link against a non-ANSI one, there
11231 might be problems such as this one.
11233 Specifically, on Solaris2 systems,
11234 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
11236 @node Floating-point Errors
11237 @subsection Floating-point Errors
11238 @cindex floating-point errors
11239 @cindex rounding errors
11240 @cindex inconsistent floating-point results
11241 @cindex results, inconsistent
11242 Some programs appear to produce inconsistent floating-point
11243 results compiled by @code{g77} versus by other compilers.
11245 Often the reason for this behavior is the fact that floating-point
11246 values are represented on almost all Fortran systems by
11247 @emph{approximations}, and these approximations are inexact
11248 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
11249 0.7, 0.8, 0.9, 1.1, and so on.
11250 Most Fortran systems, including all current ports of @code{g77},
11251 use binary arithmetic to represent these approximations.
11253 Therefore, the exact value of any floating-point approximation
11254 as manipulated by @code{g77}-compiled code is representable by
11255 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11256 so on (just keep dividing by two) through the precision of the
11257 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11258 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11259 power of two (in Fortran, by @samp{2**N}) that typically is between
11260 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11261 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11264 So, a value like 0.2 is exactly represented in decimal---since
11265 it is a fraction, @samp{2/10}, with a denominator that is compatible
11266 with the base of the number system (base 10).
11267 However, @samp{2/10} cannot be represented by any finite number
11268 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11269 be exactly represented in binary notation.
11271 (On the other hand, decimal notation can represent any binary
11272 number in a finite number of digits.
11273 Decimal notation cannot do so with ternary, or base-3,
11274 notation, which would represent floating-point numbers as
11275 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11276 After all, no finite number of decimal digits can exactly
11277 represent @samp{1/3}.
11278 Fortunately, few systems use ternary notation.)
11280 Moreover, differences in the way run-time I/O libraries convert
11281 between these approximations and the decimal representation often
11282 used by programmers and the programs they write can result in
11283 apparent differences between results that do not actually exist,
11284 or exist to such a small degree that they usually are not worth
11287 For example, consider the following program:
11294 When compiled by @code{g77}, the above program might output
11295 @samp{0.20000003}, while another compiler might produce a
11296 executable that outputs @samp{0.2}.
11298 This particular difference is due to the fact that, currently,
11299 conversion of floating-point values by the @code{libg2c} library,
11300 used by @code{g77}, handles only double-precision values.
11302 Since @samp{0.2} in the program is a single-precision value, it
11303 is converted to double precision (still in binary notation)
11304 before being converted back to decimal.
11305 The conversion to binary appends @emph{binary} zero digits to the
11306 original value---which, again, is an inexact approximation of
11307 0.2---resulting in an approximation that is much less exact
11308 than is connoted by the use of double precision.
11310 (The appending of binary zero digits has essentially the same
11311 effect as taking a particular decimal approximation of
11312 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11313 zeros to it, producing @samp{0.33333330000000000}.
11314 Treating the resulting decimal approximation as if it really
11315 had 18 or so digits of valid precision would make it seem
11316 a very poor approximation of @samp{1/3}.)
11318 As a result of converting the single-precision approximation
11319 to double precision by appending binary zeros, the conversion
11320 of the resulting double-precision
11321 value to decimal produces what looks like an incorrect
11322 result, when in fact the result is @emph{inexact}, and
11323 is probably no less inaccurate or imprecise an approximation
11324 of 0.2 than is produced by other compilers that happen to output
11325 the converted value as ``exactly'' @samp{0.2}.
11326 (Some compilers behave in a way that can make them appear
11327 to retain more accuracy across a conversion of a single-precision
11328 constant to double precision.
11329 @xref{Context-Sensitive Constants}, to see why
11330 this practice is illusory and even dangerous.)
11332 Note that a more exact approximation of the constant is
11333 computed when the program is changed to specify a
11334 double-precision constant:
11341 Future versions of @code{g77} and/or @code{libg2c} might convert
11342 single-precision values directly to decimal,
11343 instead of converting them to double precision first.
11344 This would tend to result in output that is more consistent
11345 with that produced by some other Fortran implementations.
11347 A useful source of information on floating-point computation is David
11348 Goldberg, `What Every Computer Scientist Should Know About
11349 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
11351 An online version is available at
11352 @uref{http://docs.sun.com/},
11353 and there is a supplemented version, in PostScript form, at
11354 @uref{http://www.validgh.com/goldberg/paper.ps}.
11356 Information related to the IEEE 754
11357 floating-point standard by a leading light can be found at
11358 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
11359 see also slides from the short course referenced from
11360 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
11361 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
11362 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
11363 and library code for GNU/Linux x86 systems.
11365 The supplement to the PostScript-formatted Goldberg document,
11366 referenced above, is available in HTML format.
11367 See `Differences Among IEEE 754 Implementations' by Doug Priest,
11368 available online at
11369 @uref{http://www.validgh.com/goldberg/addendum.html}.
11370 This document explores some of the issues surrounding computing
11371 of extended (80-bit) results on processors such as the x86,
11372 especially when those results are arbitrarily truncated
11373 to 32-bit or 64-bit values by the compiler
11376 @cindex spills of floating-point results
11377 @cindex 80-bit spills
11378 @cindex truncation, of floating-point values
11379 (@emph{Note:} @code{g77} specifically, and @code{gcc} generally,
11380 does arbitrarily truncate 80-bit results during spills
11381 as of this writing.
11382 It is not yet clear whether a future version of
11383 the GNU compiler suite will offer 80-bit spills
11384 as an option, or perhaps even as the default behavior.)
11386 @c xref would be different between editions:
11387 The GNU C library provides routines for controlling the FPU, and other
11388 documentation about this.
11390 @xref{Floating-point precision}, regarding IEEE 754 conformance.
11394 @node Missing Features
11395 @section Missing Features
11397 This section lists features we know are missing from @code{g77},
11398 and which we want to add someday.
11399 (There is no priority implied in the ordering below.)
11402 GNU Fortran language:
11403 * Better Source Model::
11404 * Fortran 90 Support::
11405 * Intrinsics in PARAMETER Statements::
11406 * Arbitrary Concatenation::
11407 * SELECT CASE on CHARACTER Type::
11408 * RECURSIVE Keyword::
11409 * Popular Non-standard Types::
11410 * Full Support for Compiler Types::
11411 * Array Bounds Expressions::
11412 * POINTER Statements::
11413 * Sensible Non-standard Constructs::
11414 * READONLY Keyword::
11415 * FLUSH Statement::
11416 * Expressions in FORMAT Statements::
11417 * Explicit Assembler Code::
11418 * Q Edit Descriptor::
11420 GNU Fortran dialects:
11421 * Old-style PARAMETER Statements::
11422 * TYPE and ACCEPT I/O Statements::
11423 * STRUCTURE UNION RECORD MAP::
11424 * OPEN CLOSE and INQUIRE Keywords::
11425 * ENCODE and DECODE::
11426 * AUTOMATIC Statement::
11427 * Suppressing Space Padding::
11428 * Fortran Preprocessor::
11429 * Bit Operations on Floating-point Data::
11430 * Really Ugly Character Assignments::
11434 * Floating-point Exception Handling::
11435 * Nonportable Conversions::
11436 * Large Automatic Arrays::
11437 * Support for Threads::
11438 * Increasing Precision/Range::
11439 * Enabling Debug Lines::
11441 Better diagnostics:
11442 * Better Warnings::
11443 * Gracefully Handle Sensible Bad Code::
11444 * Non-standard Conversions::
11445 * Non-standard Intrinsics::
11446 * Modifying DO Variable::
11447 * Better Pedantic Compilation::
11448 * Warn About Implicit Conversions::
11449 * Invalid Use of Hollerith Constant::
11450 * Dummy Array Without Dimensioning Dummy::
11451 * Invalid FORMAT Specifiers::
11452 * Ambiguous Dialects::
11454 * Informational Messages::
11456 Run-time facilities:
11457 * Uninitialized Variables at Run Time::
11458 * Portable Unformatted Files::
11459 * Better List-directed I/O::
11460 * Default to Console I/O::
11463 * Labels Visible to Debugger::
11466 @node Better Source Model
11467 @subsection Better Source Model
11469 @code{g77} needs to provide, as the default source-line model,
11470 a ``pure visual'' mode, where
11471 the interpretation of a source program in this mode can be accurately
11472 determined by a user looking at a traditionally displayed rendition
11473 of the program (assuming the user knows whether the program is fixed
11476 The design should assume the user cannot tell tabs from spaces
11477 and cannot see trailing spaces on lines, but has canonical tab stops
11478 and, for fixed-form source, has the ability to always know exactly
11479 where column 72 is (since the Fortran standard itself requires
11480 this for fixed-form source).
11482 This would change the default treatment of fixed-form source
11483 to not treat lines with tabs as if they were infinitely long---instead,
11484 they would end at column 72 just as if the tabs were replaced
11485 by spaces in the canonical way.
11487 As part of this, provide common alternate models (Digital, @code{f2c},
11488 and so on) via command-line options.
11489 This includes allowing arbitrarily long
11490 lines for free-form source as well as fixed-form source and providing
11491 various limits and diagnostics as appropriate.
11493 @cindex sequence numbers
11494 @cindex columns 73 through 80
11495 Also, @code{g77} should offer, perhaps even default to, warnings
11496 when characters beyond the last valid column are anything other
11498 This would mean code with ``sequence numbers'' in columns 73 through 80
11499 would be rejected, and there's a lot of that kind of code around,
11500 but one of the most frequent bugs encountered by new users is
11501 accidentally writing fixed-form source code into and beyond
11503 So, maybe the users of old code would be able to more easily handle
11504 having to specify, say, a @samp{-Wno-col73to80} option.
11506 @node Fortran 90 Support
11507 @subsection Fortran 90 Support
11508 @cindex Fortran 90, support
11509 @cindex support, Fortran 90
11511 @code{g77} does not support many of the features that
11512 distinguish Fortran 90 (and, now, Fortran 95) from
11515 Some Fortran 90 features are supported, because they
11516 make sense to offer even to die-hard users of F77.
11517 For example, many of them codify various ways F77 has
11518 been extended to meet users' needs during its tenure,
11519 so @code{g77} might as well offer them as the primary
11520 way to meet those same needs, even if it offers compatibility
11521 with one or more of the ways those needs were met
11522 by other F77 compilers in the industry.
11524 Still, many important F90 features are not supported,
11525 because no attempt has been made to research each and
11526 every feature and assess its viability in @code{g77}.
11527 In the meantime, users who need those features must
11528 use Fortran 90 compilers anyway, and the best approach
11529 to adding some F90 features to GNU Fortran might well be
11530 to fund a comprehensive project to create GNU Fortran 95.
11532 @node Intrinsics in PARAMETER Statements
11533 @subsection Intrinsics in @code{PARAMETER} Statements
11534 @cindex PARAMETER statement
11535 @cindex statements, PARAMETER
11537 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11538 This feature is considered to be absolutely vital, even though it
11539 is not standard-conforming, and is scheduled for version 0.6.
11541 Related to this, @code{g77} doesn't allow non-integral
11542 exponentiation in @code{PARAMETER} statements, such as
11543 @samp{PARAMETER (R=2**.25)}.
11544 It is unlikely @code{g77} will ever support this feature,
11545 as doing it properly requires complete emulation of
11546 a target computer's floating-point facilities when
11547 building @code{g77} as a cross-compiler.
11548 But, if the @code{gcc} back end is enhanced to provide
11549 such a facility, @code{g77} will likely use that facility
11550 in implementing this feature soon afterwards.
11552 @node Arbitrary Concatenation
11553 @subsection Arbitrary Concatenation
11554 @cindex concatenation
11555 @cindex CHARACTER*(*)
11556 @cindex run-time, dynamic allocation
11558 @code{g77} doesn't support arbitrary operands for concatenation
11559 in contexts where run-time allocation is required.
11565 CALL FOO(A // 'suffix')
11568 @node SELECT CASE on CHARACTER Type
11569 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11571 Character-type selector/cases for @code{SELECT CASE} currently
11574 @node RECURSIVE Keyword
11575 @subsection @code{RECURSIVE} Keyword
11576 @cindex RECURSIVE keyword
11577 @cindex keywords, RECURSIVE
11578 @cindex recursion, lack of
11579 @cindex lack of recursion
11581 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11583 Nor does it provide any means for compiling procedures
11584 designed to do recursion.
11586 All recursive code can be rewritten to not use recursion,
11587 but the result is not pretty.
11589 @node Increasing Precision/Range
11590 @subsection Increasing Precision/Range
11592 @cindex -qrealsize=8
11595 @cindex increasing precision
11596 @cindex precision, increasing
11597 @cindex increasing range
11598 @cindex range, increasing
11602 Some compilers, such as @code{f2c}, have an option (@samp{-r8},
11603 @samp{-qrealsize=8} or
11604 similar) that provides automatic treatment of @code{REAL}
11605 entities such that they have twice the storage size, and
11606 a corresponding increase in the range and precision, of what
11607 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11608 (This affects @code{COMPLEX} the same way.)
11610 They also typically offer another option (@samp{-i8}) to increase
11611 @code{INTEGER} entities so they are twice as large
11612 (with roughly twice as much range).
11614 (There are potential pitfalls in using these options.)
11616 @code{g77} does not yet offer any option that performs these
11617 kinds of transformations.
11618 Part of the problem is the lack of detailed specifications regarding
11619 exactly how these options affect the interpretation of constants,
11620 intrinsics, and so on.
11622 Until @code{g77} addresses this need, programmers could improve
11623 the portability of their code by modifying it to not require
11624 compile-time options to produce correct results.
11625 Some free tools are available which may help, specifically
11626 in Toolpack (which one would expect to be sound) and the @file{fortran}
11627 section of the Netlib repository.
11629 Use of preprocessors can provide a fairly portable means
11630 to work around the lack of widely portable methods in the Fortran
11631 language itself (though increasing acceptance of Fortran 90 would
11632 alleviate this problem).
11634 @node Popular Non-standard Types
11635 @subsection Popular Non-standard Types
11636 @cindex @code{INTEGER*2} support
11637 @cindex types, @code{INTEGER*2}
11638 @cindex @code{LOGICAL*1} support
11639 @cindex types, @code{LOGICAL*1}
11641 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11643 Version 0.6 will provide full support for this very
11644 popular set of features.
11645 In the meantime, version 0.5.18 provides rudimentary support
11648 @node Full Support for Compiler Types
11649 @subsection Full Support for Compiler Types
11651 @cindex @code{REAL*16} support
11652 @cindex types, @code{REAL*16}
11653 @cindex @code{INTEGER*8} support
11654 @cindex types, @code{INTEGER*8}
11655 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11656 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11657 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11658 This means providing intrinsic support, and maybe constant
11659 support (using F90 syntax) as well, and, for most
11660 machines will result in automatic support of @code{INTEGER*1},
11661 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11663 This is scheduled for version 0.6.
11665 @node Array Bounds Expressions
11666 @subsection Array Bounds Expressions
11667 @cindex array elements, in adjustable array bounds
11668 @cindex function references, in adjustable array bounds
11669 @cindex array bounds, adjustable
11670 @cindex @code{DIMENSION} statement
11671 @cindex statements, @code{DIMENSION}
11673 @code{g77} doesn't support more general expressions to dimension
11674 arrays, such as array element references, function
11677 For example, @code{g77} currently does not accept the following:
11681 INTEGER N(10), M(N(2), N(1))
11684 @node POINTER Statements
11685 @subsection POINTER Statements
11686 @cindex POINTER statement
11687 @cindex statements, POINTER
11688 @cindex Cray pointers
11690 @code{g77} doesn't support pointers or allocatable objects
11691 (other than automatic arrays).
11692 This set of features is
11693 probably considered just behind intrinsics
11694 in @code{PARAMETER} statements on the list of large,
11695 important things to add to @code{g77}.
11697 In the meantime, consider using the @code{INTEGER(KIND=7)}
11698 declaration to specify that a variable must be
11699 able to hold a pointer.
11700 This construct is not portable to other non-GNU compilers,
11701 but it is portable to all machines GNU Fortran supports
11702 when @code{g77} is used.
11704 @xref{Functions and Subroutines}, for information on
11705 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11706 constructs, which are useful for passing pointers to
11707 procedures written in languages other than Fortran.
11709 @node Sensible Non-standard Constructs
11710 @subsection Sensible Non-standard Constructs
11712 @code{g77} rejects things other compilers accept,
11713 like @samp{INTRINSIC SQRT,SQRT}.
11714 As time permits in the future, some of these things that are easy for
11715 humans to read and write and unlikely to be intended to mean something
11716 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11717 trigger warnings about such non-standard constructs).
11719 Until @code{g77} no longer gratuitously rejects sensible code,
11720 you might as well fix your code
11721 to be more standard-conforming and portable.
11723 The kind of case that is important to except from the
11724 recommendation to change your code is one where following
11725 good coding rules would force you to write non-standard
11726 code that nevertheless has a clear meaning.
11728 For example, when writing an @code{INCLUDE} file that
11729 defines a common block, it might be appropriate to
11730 include a @code{SAVE} statement for the common block
11731 (such as @samp{SAVE /CBLOCK/}), so that variables
11732 defined in the common block retain their values even
11733 when all procedures declaring the common block become
11734 inactive (return to their callers).
11736 However, putting @code{SAVE} statements in an @code{INCLUDE}
11737 file would prevent otherwise standard-conforming code
11738 from also specifying the @code{SAVE} statement, by itself,
11739 to indicate that all local variables and arrays are to
11740 have the @code{SAVE} attribute.
11742 For this reason, @code{g77} already has been changed to
11743 allow this combination, because although the general
11744 problem of gratuitously rejecting unambiguous and
11745 ``safe'' constructs still exists in @code{g77}, this
11746 particular construct was deemed useful enough that
11747 it was worth fixing @code{g77} for just this case.
11749 So, while there is no need to change your code
11750 to avoid using this particular construct, there
11751 might be other, equally appropriate but non-standard
11752 constructs, that you shouldn't have to stop using
11753 just because @code{g77} (or any other compiler)
11754 gratuitously rejects it.
11756 Until the general problem is solved, if you have
11757 any such construct you believe is worthwhile
11758 using (e.g. not just an arbitrary, redundant
11759 specification of an attribute), please submit a
11760 bug report with an explanation, so we can consider
11761 fixing @code{g77} just for cases like yours.
11763 @node READONLY Keyword
11764 @subsection @code{READONLY} Keyword
11767 Support for @code{READONLY}, in @code{OPEN} statements,
11768 requires @code{libg2c} support,
11769 to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
11770 does not delete a file opened on a unit
11771 with the @code{READONLY} keyword,
11772 and perhaps to trigger a fatal diagnostic
11773 if a @code{WRITE} or @code{PRINT}
11774 to such a unit is attempted.
11776 @emph{Note:} It is not sufficient for @code{g77} and @code{libg2c}
11777 (its version of @code{libf2c})
11778 to assume that @code{READONLY} does not need some kind of explicit support
11780 due to UNIX systems not (generally) needing it.
11781 @code{g77} is not just a UNIX-based compiler!
11783 Further, mounting of non-UNIX filesystems on UNIX systems
11785 might require proper @code{READONLY} support.
11788 (Similar issues might be involved with supporting the @code{SHARED}
11791 @node FLUSH Statement
11792 @subsection @code{FLUSH} Statement
11794 @code{g77} could perhaps use a @code{FLUSH} statement that
11795 does what @samp{CALL FLUSH} does,
11796 but that supports @samp{*} as the unit designator (same unit as for
11797 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11800 @node Expressions in FORMAT Statements
11801 @subsection Expressions in @code{FORMAT} Statements
11802 @cindex FORMAT statement
11803 @cindex statements, FORMAT
11805 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11806 Supporting this requires a significant redesign or replacement
11809 However, @code{g77} does support
11810 this construct when the expression is constant
11811 (as of version 0.5.22).
11815 PARAMETER (IWIDTH = 12)
11816 10 FORMAT (I<IWIDTH>)
11819 Otherwise, at least for output (@code{PRINT} and
11820 @code{WRITE}), Fortran code making use of this feature can
11821 be rewritten to avoid it by constructing the @code{FORMAT}
11822 string in a @code{CHARACTER} variable or array, then
11823 using that variable or array in place of the @code{FORMAT}
11824 statement label to do the original @code{PRINT} or @code{WRITE}.
11826 Many uses of this feature on input can be rewritten this way
11827 as well, but not all can.
11828 For example, this can be rewritten:
11835 However, this cannot, in general, be rewritten, especially
11836 when @code{ERR=} and @code{END=} constructs are employed:
11843 @node Explicit Assembler Code
11844 @subsection Explicit Assembler Code
11846 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11847 code to specify explicit assembler code.
11849 @node Q Edit Descriptor
11850 @subsection Q Edit Descriptor
11851 @cindex FORMAT statement
11852 @cindex Q edit descriptor
11853 @cindex edit descriptor, Q
11855 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11856 (This is meant to get the number of characters remaining in an input record.)
11857 Supporting this requires a significant redesign or replacement
11860 A workaround might be using internal I/O or the stream-based intrinsics.
11861 @xref{FGetC Intrinsic (subroutine)}.
11863 @node Old-style PARAMETER Statements
11864 @subsection Old-style PARAMETER Statements
11865 @cindex PARAMETER statement
11866 @cindex statements, PARAMETER
11868 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11869 Supporting this obsolete form of
11870 the @code{PARAMETER} statement would not be particularly hard, as most of the
11871 parsing code is already in place and working.
11873 Until time/money is
11874 spent implementing it, you might as well fix your code to use the
11875 standard form, @samp{PARAMETER (I=1)} (possibly needing
11876 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11877 otherwise, in the obsolete form of @code{PARAMETER}, the
11878 type of the variable is set from the type of the constant being
11881 @node TYPE and ACCEPT I/O Statements
11882 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11883 @cindex TYPE statement
11884 @cindex statements, TYPE
11885 @cindex ACCEPT statement
11886 @cindex statements, ACCEPT
11888 @code{g77} doesn't support the I/O statements @code{TYPE} and
11890 These are common extensions that should be easy to support,
11891 but also are fairly easy to work around in user code.
11893 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11894 by @samp{PRINT fmt,list}.
11895 And, any @samp{ACCEPT fmt,list} statement can be
11896 replaced by @samp{READ fmt,list}.
11898 @node STRUCTURE UNION RECORD MAP
11899 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11900 @cindex STRUCTURE statement
11901 @cindex statements, STRUCTURE
11902 @cindex UNION statement
11903 @cindex statements, UNION
11904 @cindex RECORD statement
11905 @cindex statements, RECORD
11906 @cindex MAP statement
11907 @cindex statements, MAP
11909 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11911 This set of extensions is quite a bit
11912 lower on the list of large, important things to add to @code{g77}, partly
11913 because it requires a great deal of work either upgrading or
11914 replacing @code{libg2c}.
11916 @node OPEN CLOSE and INQUIRE Keywords
11917 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11918 @cindex disposition of files
11919 @cindex OPEN statement
11920 @cindex statements, OPEN
11921 @cindex CLOSE statement
11922 @cindex statements, CLOSE
11923 @cindex INQUIRE statement
11924 @cindex statements, INQUIRE
11926 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11927 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11928 These extensions are easy to add to @code{g77} itself, but
11929 require much more work on @code{libg2c}.
11931 @cindex FORM='PRINT'
11932 @cindex ANS carriage control
11933 @cindex carriage control
11936 @code{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
11937 translate the traditional `carriage control' characters in column 1 of
11938 output to use backspaces, carriage returns and the like. However
11939 programs exist to translate them in output files (or standard output).
11940 These are typically called either @code{fpr} or @code{asa}. You can get
11941 a version of @code{asa} from
11942 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
11943 systems which will probably build easily on other systems.
11944 Alternatively, @code{fpr} is in BSD distributions in various archive
11947 @c (Can both programs can be used in a pipeline,
11948 @c with a named input file,
11949 @c and/or with a named output file???)
11951 @node ENCODE and DECODE
11952 @subsection @code{ENCODE} and @code{DECODE}
11953 @cindex ENCODE statement
11954 @cindex statements, ENCODE
11955 @cindex DECODE statement
11956 @cindex statements, DECODE
11958 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11960 These statements are best replaced by READ and WRITE statements
11961 involving internal files (CHARACTER variables and arrays).
11963 For example, replace a code fragment like
11968 DECODE (80, 9000, LINE) A, B, C
11970 9000 FORMAT (1X, 3(F10.5))
11979 READ (UNIT=LINE, FMT=9000) A, B, C
11981 9000 FORMAT (1X, 3(F10.5))
11984 Similarly, replace a code fragment like
11989 ENCODE (80, 9000, LINE) A, B, C
11991 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
12000 WRITE (UNIT=LINE, FMT=9000) A, B, C
12002 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
12005 It is entirely possible that @code{ENCODE} and @code{DECODE} will
12006 be supported by a future version of @code{g77}.
12008 @node AUTOMATIC Statement
12009 @subsection @code{AUTOMATIC} Statement
12010 @cindex @code{AUTOMATIC} statement
12011 @cindex statements, @code{AUTOMATIC}
12012 @cindex automatic variables
12013 @cindex variables, automatic
12015 @code{g77} doesn't support the @code{AUTOMATIC} statement that
12018 @code{AUTOMATIC} would identify a variable or array
12019 as not being @code{SAVE}'d, which is normally the default,
12020 but which would be especially useful for code that, @emph{generally},
12021 needed to be compiled with the @samp{-fno-automatic} option.
12023 @code{AUTOMATIC} also would serve as a hint to the compiler that placing
12024 the variable or array---even a very large array--on the stack is acceptable.
12026 @code{AUTOMATIC} would not, by itself, designate the containing procedure
12029 @code{AUTOMATIC} should work syntactically like @code{SAVE},
12030 in that @code{AUTOMATIC} with no variables listed should apply to
12031 all pertinent variables and arrays
12032 (which would not include common blocks or their members).
12034 Variables and arrays denoted as @code{AUTOMATIC}
12035 would not be permitted to be initialized via @code{DATA}
12036 or other specification of any initial values,
12037 requiring explicit initialization,
12038 such as via assignment statements.
12042 Perhaps @code{UNSAVE} and @code{STATIC},
12043 as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
12044 should be provided as well.
12046 @node Suppressing Space Padding
12047 @subsection Suppressing Space Padding of Source Lines
12049 @code{g77} should offer VXT-Fortran-style suppression of virtual
12050 spaces at the end of a source line
12051 if an appropriate command-line option is specified.
12053 This affects cases where
12054 a character constant is continued onto the next line in a fixed-form
12055 source file, as in the following example:
12058 10 PRINT *,'HOW MANY
12063 @code{g77}, and many other compilers, virtually extend
12064 the continued line through column 72 with spaces that become part
12065 of the character constant, but Digital Fortran normally didn't,
12066 leaving only one space between @samp{MANY} and @samp{SPACES?}
12067 in the output of the above statement.
12069 Fairly recently, at least one version of Digital Fortran
12070 was enhanced to provide the other behavior when a
12071 command-line option is specified, apparently due to demand
12072 from readers of the USENET group @file{comp.lang.fortran}
12073 to offer conformance to this widespread practice in the
12075 @code{g77} should return the favor by offering conformance
12076 to Digital's approach to handling the above example.
12078 @node Fortran Preprocessor
12079 @subsection Fortran Preprocessor
12081 @code{g77} should offer a preprocessor designed specifically
12082 for Fortran to replace @samp{cpp -traditional}.
12083 There are several out there worth evaluating, at least.
12085 Such a preprocessor would recognize Hollerith constants,
12086 properly parse comments and character constants, and so on.
12087 It might also recognize, process, and thus preprocess
12088 files included via the @code{INCLUDE} directive.
12090 @node Bit Operations on Floating-point Data
12091 @subsection Bit Operations on Floating-point Data
12092 @cindex @code{And} intrinsic
12093 @cindex intrinsics, @code{And}
12094 @cindex @code{Or} intrinsic
12095 @cindex intrinsics, @code{Or}
12096 @cindex @code{Shift} intrinsic
12097 @cindex intrinsics, @code{Shift}
12099 @code{g77} does not allow @code{REAL} and other non-integral types for
12100 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
12102 For example, this program is rejected by @code{g77}, because
12103 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
12106 DATA A/7.54/, B/9.112/
12107 PRINT *, IAND(A, B)
12111 @node Really Ugly Character Assignments
12112 @subsection Really Ugly Character Assignments
12114 An option such as @samp{-fugly-char} should be provided
12119 DATA A1 / '12345678' /
12129 @node POSIX Standard
12130 @subsection @code{POSIX} Standard
12132 @code{g77} should support the POSIX standard for Fortran.
12134 @node Floating-point Exception Handling
12135 @subsection Floating-point Exception Handling
12136 @cindex floating-point, exceptions
12137 @cindex exceptions, floating-point
12138 @cindex FPE handling
12141 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
12142 general control over whether or not floating-point exceptions are trapped or
12144 (Ignoring them typically results in NaN values being
12145 propagated in systems that conform to IEEE 754.)
12146 The behaviour is normally inherited from the system-dependent startup
12147 code, though some targets, such as the Alpha, have code generation
12148 options which change the behaviour.
12150 Most systems provide some C-callable mechanism to change this; this can
12151 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
12152 For example, just compiling and linking the following C code with your
12153 program will turn on exception trapping for the ``common'' exceptions
12154 on an x86-based GNU system:
12157 #include <fpu_control.h>
12158 static void __attribute__ ((constructor))
12161 __setfpucw (_FPU_DEFAULT &
12162 ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
12166 A convenient trick is to compile this something like:
12168 gcc -o libtrapfpe.a trapfpe.c
12170 and then use it by adding @samp{-trapfpe} to the @code{g77} command line
12173 @node Nonportable Conversions
12174 @subsection Nonportable Conversions
12175 @cindex nonportable conversions
12176 @cindex conversions, nonportable
12178 @code{g77} doesn't accept some particularly nonportable,
12179 silent data-type conversions such as @code{LOGICAL}
12180 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
12181 is type @code{REAL}), that other compilers might
12184 Some of these conversions are accepted by @code{g77}
12185 when the @samp{-fugly-logint} option is specified.
12186 Perhaps it should accept more or all of them.
12188 @node Large Automatic Arrays
12189 @subsection Large Automatic Arrays
12190 @cindex automatic arrays
12191 @cindex arrays, automatic
12193 Currently, automatic arrays always are allocated on the stack.
12194 For situations where the stack cannot be made large enough,
12195 @code{g77} should offer a compiler option that specifies
12196 allocation of automatic arrays in heap storage.
12198 @node Support for Threads
12199 @subsection Support for Threads
12201 @cindex parallel processing
12203 Neither the code produced by @code{g77} nor the @code{libg2c} library
12204 are thread-safe, nor does @code{g77} have support for parallel processing
12205 (other than the instruction-level parallelism available on some
12207 A package such as PVM might help here.
12209 @node Enabling Debug Lines
12210 @subsection Enabling Debug Lines
12212 @cindex comment line, debug
12214 An option such as @samp{-fdebug-lines} should be provided
12215 to turn fixed-form lines beginning with @samp{D}
12216 to be treated as if they began with a space,
12217 instead of as if they began with a @samp{C}
12218 (as comment lines).
12220 @node Better Warnings
12221 @subsection Better Warnings
12223 Because of how @code{g77} generates code via the back end,
12224 it doesn't always provide warnings the user wants.
12233 Currently, the above is not flagged as a case of
12234 using an uninitialized variable,
12235 because @code{g77} generates a run-time library call that looks,
12236 to the GBE, like it might actually @emph{modify} @samp{A} at run time.
12237 (And, in fact, depending on the previous run-time library call,
12240 Fixing this requires one of the following:
12244 Switch to new library, @code{libg77}, that provides
12245 a more ``clean'' interface,
12246 vis-a-vis input, output, and modified arguments,
12247 so the GBE can tell what's going on.
12249 This would provide a pretty big performance improvement,
12250 at least theoretically, and, ultimately, in practice,
12251 for some types of code.
12254 Have @code{g77} pass a pointer to a temporary
12255 containing a copy of @samp{A},
12256 instead of to @samp{A} itself.
12257 The GBE would then complain about the copy operation
12258 involving a potentially uninitialized variable.
12260 This might also provide a performance boost for some code,
12261 because @samp{A} might then end up living in a register,
12262 which could help with inner loops.
12265 Have @code{g77} use a GBE construct similar to @code{ADDR_EXPR}
12266 but with extra information on the fact that the
12267 item pointed to won't be modified
12268 (a la @code{const} in C).
12270 Probably the best solution for now, but not quite trivial
12271 to implement in the general case.
12272 Worth considering after @code{g77} 0.6 is considered
12276 @node Gracefully Handle Sensible Bad Code
12277 @subsection Gracefully Handle Sensible Bad Code
12279 @code{g77} generally should continue processing for
12280 warnings and recoverable (user) errors whenever possible---that
12281 is, it shouldn't gratuitously make bad or useless code.
12292 When compiling the above with @samp{-ff2c-intrinsics-disable},
12293 @code{g77} should indeed complain about passing @code{ZABS},
12294 but it still should compile, instead of rejecting
12295 the entire @code{CALL} statement.
12296 (Some of this is related to improving
12297 the compiler internals to improve how statements are analyzed.)
12299 @node Non-standard Conversions
12300 @subsection Non-standard Conversions
12302 @samp{-Wconversion} and related should flag places where non-standard
12303 conversions are found.
12304 Perhaps much of this would be part of @samp{-Wugly*}.
12306 @node Non-standard Intrinsics
12307 @subsection Non-standard Intrinsics
12309 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
12310 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
12311 This would help find code that might fail silently when ported to another
12314 @node Modifying DO Variable
12315 @subsection Modifying @code{DO} Variable
12317 @code{g77} should warn about modifying @code{DO} variables
12318 via @code{EQUIVALENCE}.
12319 (The internal information gathered to produce this warning
12320 might also be useful in setting the
12321 internal ``doiter'' flag for a variable or even array
12322 reference within a loop, since that might produce faster code someday.)
12324 For example, this code is invalid, so @code{g77} should warn about
12325 the invalid assignment to @samp{NOTHER}:
12328 EQUIVALENCE (I, NOTHER)
12330 IF (I.EQ. 10) NOTHER = 20
12334 @node Better Pedantic Compilation
12335 @subsection Better Pedantic Compilation
12337 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
12338 and use it only to generate
12339 warnings instead of rejecting constructs outright.
12341 if a variable that dimensions an array is not a dummy or placed
12342 explicitly in @code{COMMON} (F77 does not allow it to be
12343 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
12344 follow statement-function-definition statements; about all sorts of
12345 syntactic extensions.
12347 @node Warn About Implicit Conversions
12348 @subsection Warn About Implicit Conversions
12350 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
12351 to expect automatic, silent, and
12352 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
12353 constants to @code{REAL(KIND=2)} based on context.
12355 For example, it would warn about cases like this:
12358 DOUBLE PRECISION FOO
12359 PARAMETER (TZPHI = 9.435784839284958)
12363 @node Invalid Use of Hollerith Constant
12364 @subsection Invalid Use of Hollerith Constant
12366 @code{g77} should disallow statements like @samp{RETURN 2HAB},
12367 which are invalid in both source forms
12368 (unlike @samp{RETURN (2HAB)},
12369 which probably still makes no sense but at least can
12370 be reliably parsed).
12371 Fixed-form processing rejects it, but not free-form, except
12372 in a way that is a bit difficult to understand.
12374 @node Dummy Array Without Dimensioning Dummy
12375 @subsection Dummy Array Without Dimensioning Dummy
12377 @code{g77} should complain when a list of dummy arguments containing an
12378 adjustable dummy array does
12379 not also contain every variable listed in the dimension list of the
12382 Currently, @code{g77} does complain about a variable that
12383 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
12384 area, but this needs to be extended to catch cases where it doesn't appear in
12385 every dummy list that also lists any arrays it dimensions.
12387 For example, @code{g77} should warn about the entry point @samp{ALT}
12388 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
12392 SUBROUTINE PRIMARY(ARRAY, ISIZE)
12397 @node Invalid FORMAT Specifiers
12398 @subsection Invalid FORMAT Specifiers
12400 @code{g77} should check @code{FORMAT} specifiers for validity
12401 as it does @code{FORMAT} statements.
12403 For example, a diagnostic would be produced for:
12406 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
12409 @node Ambiguous Dialects
12410 @subsection Ambiguous Dialects
12412 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
12413 @samp{-Wvxt}, @samp{-Wf90}, and so on.
12414 These would warn about places in the user's source where ambiguities
12415 are found, helpful in resolving ambiguities in the program's
12416 dialect or dialects.
12418 @node Unused Labels
12419 @subsection Unused Labels
12421 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
12423 @node Informational Messages
12424 @subsection Informational Messages
12426 @code{g77} needs an option to suppress information messages (notes).
12427 @samp{-w} does this but also suppresses warnings.
12428 The default should be to suppress info messages.
12430 Perhaps info messages should simply be eliminated.
12432 @node Uninitialized Variables at Run Time
12433 @subsection Uninitialized Variables at Run Time
12435 @code{g77} needs an option to initialize everything (not otherwise
12436 explicitly initialized) to ``weird''
12437 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
12438 largest-magnitude integers, would help track down references to
12439 some kinds of uninitialized variables at run time.
12441 Note that use of the options @samp{-O -Wuninitialized} can catch
12442 many such bugs at compile time.
12444 @node Portable Unformatted Files
12445 @subsection Portable Unformatted Files
12447 @cindex unformatted files
12448 @cindex file formats
12449 @cindex binary data
12450 @cindex byte ordering
12451 @code{g77} has no facility for exchanging unformatted files with systems
12452 using different number formats---even differing only in endianness (byte
12453 order)---or written by other compilers. Some compilers provide
12454 facilities at least for doing byte-swapping during unformatted I/O.
12456 It is unrealistic to expect to cope with exchanging unformatted files
12457 with arbitrary other compiler runtimes, but the @code{g77} runtime
12458 should at least be able to read files written by @code{g77} on systems
12459 with different number formats, particularly if they differ only in byte
12462 In case you do need to write a program to translate to or from
12463 @code{g77} (@code{libf2c}) unformatted files, they are written as
12467 Unformatted sequential records consist of
12470 A number giving the length of the record contents;
12472 the length of record contents again (for backspace).
12475 The record length is of C type
12476 @code{long}; this means that it is 8 bytes on 64-bit systems such as
12477 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
12478 Consequently such files cannot be exchanged between 64-bit and 32-bit
12479 systems, even with the same basic number format.
12480 @item Direct access
12481 Unformatted direct access files form a byte stream of length
12482 @var{records}*@var{recl} bytes, where @var{records} is the maximum
12483 record number (@code{REC=@var{records}}) written and @var{recl} is the
12484 record length in bytes specified in the @code{OPEN} statement
12485 (@code{RECL=@var{recl}}). Data appear in the records as determined by
12486 the relevant @code{WRITE} statement. Dummy records with arbitrary
12487 contents appear in the file in place of records which haven't been
12491 Thus for exchanging a sequential or direct access unformatted file
12492 between big- and little-endian 32-bit systems using IEEE 754 floating
12493 point it would be sufficient to reverse the bytes in consecutive words
12494 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
12495 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
12498 If necessary, it is possible to do byte-oriented i/o with @code{g77}'s
12499 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
12500 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
12501 array or a set of scalars.
12505 If you need to exchange binary data between arbitrary system and
12506 compiler variations, we recommend using a portable binary format with
12507 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
12508 or PACT's PDB@footnote{No, not @emph{that} one.}
12509 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
12510 say, CDF or XDR, HDF-like systems write in the native number formats and
12511 only incur overhead when they are read on a system with a different
12512 format.) A future @code{g77} runtime library should use such
12515 @node Better List-directed I/O
12516 @subsection Better List-directed I/O
12518 Values output using list-directed I/O
12519 (@samp{PRINT *, R, D})
12520 should be written with a field width, precision, and so on
12521 appropriate for the type (precision) of each value.
12523 (Currently, no distinction is made between single-precision
12524 and double-precision values
12527 It is likely this item will require the @code{libg77} project
12530 In the meantime, use of formatted I/O is recommended.
12531 While it might be of little consolation,
12532 @code{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
12533 as long as @samp{WIDTH} is defined as a named constant
12534 (via @code{PARAMETER}).
12535 That at least allows some compile-time specification
12536 of the precision of a data type,
12537 perhaps controlled by preprocessing directives.
12539 @node Default to Console I/O
12540 @subsection Default to Console I/O
12542 The default I/O units,
12543 specified by @samp{READ @var{fmt}},
12544 @samp{READ (UNIT=*)},
12545 @samp{WRITE (UNIT=*)}, and
12546 @samp{PRINT @var{fmt}},
12547 should not be units 5 (input) and 6 (output),
12548 but, rather, unit numbers not normally available
12549 for use in statements such as @code{OPEN} and @code{CLOSE}.
12551 Changing this would allow a program to connect units 5 and 6
12552 to files via @code{OPEN},
12553 but still use @samp{READ (UNIT=*)} and @samp{PRINT}
12554 to do I/O to the ``console''.
12556 This change probably requires the @code{libg77} project.
12558 @node Labels Visible to Debugger
12559 @subsection Labels Visible to Debugger
12561 @code{g77} should output debugging information for statements labels,
12562 for use by debuggers that know how to support them.
12563 Same with weirder things like construct names.
12564 It is not yet known if any debug formats or debuggers support these.
12566 @node Disappointments
12567 @section Disappointments and Misunderstandings
12569 These problems are perhaps regrettable, but we don't know any practical
12570 way around them for now.
12573 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
12574 external name @samp{foo_}.
12575 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
12576 and @samp{SUBROUTINE FOO}.
12577 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
12580 @node Mangling of Names
12581 @subsection Mangling of Names in Source Code
12582 @cindex naming issues
12583 @cindex external names
12584 @cindex common blocks
12588 The current external-interface design, which includes naming of
12589 external procedures, COMMON blocks, and the library interface,
12590 has various usability problems, including things like adding
12591 underscores where not really necessary (and preventing easier
12592 inter-language operability) and yet not providing complete
12593 namespace freedom for user C code linked with Fortran apps (due
12594 to the naming of functions in the library, among other things).
12596 Project GNU should at least get all this ``right'' for systems
12597 it fully controls, such as the Hurd, and provide defaults and
12598 options for compatibility with existing systems and interoperability
12599 with popular existing compilers.
12601 @node Multiple Definitions of External Names
12602 @subsection Multiple Definitions of External Names
12604 @cindex BLOCK DATA statement
12605 @cindex statements, BLOCK DATA
12606 @cindex @code{COMMON} statement
12607 @cindex statements, @code{COMMON}
12608 @cindex naming conflicts
12610 @code{g77} doesn't allow a common block and an external procedure or
12611 @code{BLOCK DATA} to have the same name.
12612 Some systems allow this, but @code{g77} does not,
12613 to be compatible with @code{f2c}.
12615 @code{g77} could special-case the way it handles
12616 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12617 particular area (necessarily, since @code{g77} offers an
12618 important feature here), but
12619 it is likely that such special-casing would be very annoying to people
12620 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12621 @samp{FOO} in the same program unit, to refer to external procedures, since
12622 the result would be that @code{g77} would treat these references as requests to
12623 force-load BLOCK DATA program units.
12625 In that case, if @code{g77} modified
12626 names of @code{BLOCK DATA} so they could have the same names as
12627 @code{COMMON}, users
12628 would find that their programs wouldn't link because the @samp{FOO} procedure
12629 didn't have its name translated the same way.
12631 (Strictly speaking,
12632 @code{g77} could emit a null-but-externally-satisfying definition of
12633 @samp{FOO} with its name transformed as if it had been a
12634 @code{BLOCK DATA}, but that probably invites more trouble than it's
12637 @node Limitation on Implicit Declarations
12638 @subsection Limitation on Implicit Declarations
12639 @cindex IMPLICIT CHARACTER*(*) statement
12640 @cindex statements, IMPLICIT CHARACTER*(*)
12642 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12643 This is not standard-conforming.
12646 @section Certain Changes We Don't Want to Make
12648 This section lists changes that people frequently request, but which
12649 we do not make because we think GNU Fortran is better without them.
12652 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12653 is one, not two, characters long.
12654 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12656 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12657 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12658 single-precision constant,
12659 and might be interpreted as
12660 @samp{9.435785} or similar.
12661 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12662 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12663 not behave as expected.
12666 @node Backslash in Constants
12667 @subsection Backslash in Constants
12669 @cindex @code{f77} support
12670 @cindex support, @code{f77}
12672 In the opinion of many experienced Fortran users,
12673 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12674 as currently set by @code{g77}.
12676 First of all, you can always specify
12677 @samp{-fno-backslash} to turn off this processing.
12679 Despite not being within the spirit (though apparently within the
12680 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12681 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12682 default to, and apparently lots of code depends on this feature.
12684 This is a particularly troubling issue.
12685 The use of a C construct in the midst of Fortran code
12686 is bad enough, worse when it makes existing Fortran
12687 programs stop working (as happens when programs written
12688 for non-UNIX systems are ported to UNIX systems with
12689 compilers that provide the @samp{-fbackslash} feature
12690 as the default---sometimes with no option to turn it off).
12692 The author of GNU Fortran wished, for reasons of linguistic
12693 purity, to make @samp{-fno-backslash} the default for GNU
12694 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12695 to specify @samp{-fbackslash} to get the UNIX behavior.
12697 However, the realization that @code{g77} is intended as
12698 a replacement for @emph{UNIX} @code{f77}, caused the author
12699 to choose to make @code{g77} as compatible with
12700 @code{f77} as feasible, which meant making @samp{-fbackslash}
12703 The primary focus on compatibility is at the source-code
12704 level, and the question became ``What will users expect
12705 a replacement for @code{f77} to do, by default?''
12706 Although at least one UNIX @code{f77} does not provide
12707 @samp{-fbackslash} as a default, it appears that
12708 the majority of them do, which suggests that
12709 the majority of code that is compiled by UNIX @code{f77}
12710 compilers expects @samp{-fbackslash} to be the default.
12712 It is probably the case that more code exists
12713 that would @emph{not} work with @samp{-fbackslash}
12714 in force than code that requires it be in force.
12716 However, most of @emph{that} code is not being compiled
12718 and when it is, new build procedures (shell scripts,
12719 makefiles, and so on) must be set up anyway so that
12720 they work under UNIX.
12721 That makes a much more natural and safe opportunity for
12722 non-UNIX users to adapt their build procedures for
12723 @code{g77}'s default of @samp{-fbackslash} than would
12724 exist for the majority of UNIX @code{f77} users who
12725 would have to modify existing, working build procedures
12726 to explicitly specify @samp{-fbackslash} if that was
12729 One suggestion has been to configure the default for
12730 @samp{-fbackslash} (and perhaps other options as well)
12731 based on the configuration of @code{g77}.
12733 This is technically quite straightforward, but will be avoided
12734 even in cases where not configuring defaults to be
12735 dependent on a particular configuration greatly inconveniences
12736 some users of legacy code.
12738 Many users appreciate the GNU compilers because they provide an
12739 environment that is uniform across machines.
12740 These users would be
12741 inconvenienced if the compiler treated things like the
12742 format of the source code differently on certain machines.
12744 Occasionally users write programs intended only for a particular machine
12746 On these occasions, the users would benefit if the GNU Fortran compiler
12747 were to support by default the same dialect as the other compilers on
12749 But such applications are rare.
12750 And users writing a
12751 program to run on more than one type of machine cannot possibly benefit
12752 from this kind of compatibility.
12753 (This is consistent with the design goals for @code{gcc}.
12754 To change them for @code{g77}, you must first change them
12756 Do not ask the maintainers of @code{g77} to do this for you,
12757 or to disassociate @code{g77} from the widely understood, if
12758 not widely agreed-upon, goals for GNU compilers in general.)
12760 This is why GNU Fortran does and will treat backslashes in the same
12761 fashion on all types of machines (by default).
12762 @xref{Direction of Language Development}, for more information on
12763 this overall philosophy guiding the development of the GNU Fortran
12766 Of course, users strongly concerned about portability should indicate
12767 explicitly in their build procedures which options are expected
12768 by their source code, or write source code that has as few such
12769 expectations as possible.
12771 For example, avoid writing code that depends on backslash (@samp{\})
12772 being interpreted either way in particular, such as by
12773 starting a program unit with:
12777 PARAMETER (BACKSL = '\\')
12781 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12783 In this way, users can write programs which have the same meaning
12784 in many Fortran dialects.
12786 (However, this technique does not work for Hollerith constants---which
12787 is just as well, since the only generally portable uses for Hollerith
12788 constants are in places where character constants can and should
12789 be used instead, for readability.)
12791 @node Initializing Before Specifying
12792 @subsection Initializing Before Specifying
12793 @cindex initialization, statement placement
12794 @cindex placing initialization statements
12796 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12797 source code before @samp{COMMON VAR},
12798 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12799 In general, @code{g77} requires initialization of a variable
12800 or array to be specified @emph{after} all other specifications
12801 of attributes (type, size, placement, and so on) of that variable
12802 or array are specified (though @emph{confirmation} of data type is
12805 It is @emph{possible} @code{g77} will someday allow all of this,
12806 even though it is not allowed by the FORTRAN 77 standard.
12808 Then again, maybe it is better to have
12809 @code{g77} always require placement of @code{DATA}
12810 so that it can possibly immediately write constants
12811 to the output file, thus saving time and space.
12813 That is, @samp{DATA A/1000000*1/} should perhaps always
12814 be immediately writable to canonical assembler, unless it's already known
12815 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12816 and to do this it cannot be followed by @samp{COMMON A}.
12818 @node Context-Sensitive Intrinsicness
12819 @subsection Context-Sensitive Intrinsicness
12820 @cindex intrinsics, context-sensitive
12821 @cindex context-sensitive intrinsics
12823 @code{g77} treats procedure references to @emph{possible} intrinsic
12824 names as always enabling their intrinsic nature, regardless of
12825 whether the @emph{form} of the reference is valid for that
12828 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12829 an invalid reference to the @code{SQRT} intrinsic function,
12830 because the reference is a subroutine invocation.
12832 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12833 as a reference to a @emph{procedure} named @samp{SQRT}, not
12834 to a @emph{variable} with that name (as it would for a statement
12835 such as @samp{V = SQRT}).
12837 Next, @code{g77} establishes that, in the program unit being compiled,
12838 @code{SQRT} is an intrinsic---not a subroutine that
12839 happens to have the same name as an intrinsic (as would be
12840 the case if, for example, @samp{EXTERNAL SQRT} was present).
12842 Finally, @code{g77} recognizes that the @emph{form} of the
12843 reference is invalid for that particular intrinsic.
12844 That is, it recognizes that it is invalid for an intrinsic
12845 @emph{function}, such as @code{SQRT}, to be invoked as
12846 a @emph{subroutine}.
12848 At that point, @code{g77} issues a diagnostic.
12850 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12851 references an external subroutine of their own, not an
12852 intrinsic function.
12854 However, @code{g77} knows about intrinsic
12855 subroutines, not just functions, and is able to support both having
12856 the same names, for example.
12858 As a result of this, @code{g77} rejects calls
12859 to intrinsics that are not subroutines, and function invocations
12860 of intrinsics that are not functions, just as it (and most compilers)
12861 rejects invocations of intrinsics with the wrong number (or types)
12864 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12865 a user-written subroutine named @samp{SQRT}.
12867 @node Context-Sensitive Constants
12868 @subsection Context-Sensitive Constants
12869 @cindex constants, context-sensitive
12870 @cindex context-sensitive constants
12872 @code{g77} does not use context to determine the types of
12873 constants or named constants (@code{PARAMETER}), except
12874 for (non-standard) typeless constants such as @samp{'123'O}.
12876 For example, consider the following statement:
12879 PRINT *, 9.435784839284958 * 2D0
12883 @code{g77} will interpret the (truncated) constant
12884 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12885 constant, because the suffix @code{D0} is not specified.
12887 As a result, the output of the above statement when
12888 compiled by @code{g77} will appear to have ``less precision''
12889 than when compiled by other compilers.
12891 In these and other cases, some compilers detect the
12892 fact that a single-precision constant is used in
12893 a double-precision context and therefore interpret the
12894 single-precision constant as if it was @emph{explicitly}
12895 specified as a double-precision constant.
12896 (This has the effect of appending @emph{decimal}, not
12897 @emph{binary}, zeros to the fractional part of the
12898 number---producing different computational results.)
12900 The reason this misfeature is dangerous is that a slight,
12901 apparently innocuous change to the source code can change
12902 the computational results.
12907 DOUBLE PRECISION FIVE
12908 PARAMETER (ALMOST = 5.000000000001)
12910 CLOSE = 5.000000000001
12911 PRINT *, 5.000000000001 - FIVE
12912 PRINT *, ALMOST - FIVE
12913 PRINT *, CLOSE - FIVE
12918 Running the above program should
12919 result in the same value being
12920 printed three times.
12921 With @code{g77} as the compiler,
12924 However, compiled by many other compilers,
12925 running the above program would print
12926 two or three distinct values, because
12927 in two or three of the statements, the
12928 constant @samp{5.000000000001}, which
12929 on most systems is exactly equal to @samp{5.}
12930 when interpreted as a single-precision constant,
12931 is instead interpreted as a double-precision
12932 constant, preserving the represented
12934 However, this ``clever'' promotion of
12935 type does not extend to variables or,
12936 in some compilers, to named constants.
12938 Since programmers often are encouraged to replace manifest
12939 constants or permanently-assigned variables with named
12940 constants (@code{PARAMETER} in Fortran), and might need
12941 to replace some constants with variables having the same
12942 values for pertinent portions of code,
12943 it is important that compilers treat code so modified in the
12944 same way so that the results of such programs are the same.
12945 @code{g77} helps in this regard by treating constants just
12946 the same as variables in terms of determining their types
12947 in a context-independent way.
12949 Still, there is a lot of existing Fortran code that has
12950 been written to depend on the way other compilers freely
12951 interpret constants' types based on context, so anything
12952 @code{g77} can do to help flag cases of this in such code
12953 could be very helpful.
12955 @node Equivalence Versus Equality
12956 @subsection Equivalence Versus Equality
12957 @cindex .EQV., with integer operands
12958 @cindex comparing logical expressions
12959 @cindex logical expressions, comparing
12961 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12962 is not supported, except via @samp{-fugly-logint}, which is not
12963 recommended except for legacy code (where the behavior expected
12964 by the @emph{code} is assumed).
12966 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12967 and @code{.NEQV.} instead, as these are permitted by the various
12970 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12971 to work if either of its operands is @code{LOGICAL}.
12973 The problem with supporting this ``feature'' is that there is
12974 unlikely to be consensus on how it works, as illustrated by the
12975 following sample program:
12979 DATA L,M,N /3*.FALSE./
12980 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
12984 The issue raised by the above sample program is: what is the
12985 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
12986 @code{LOGICAL} operands?
12988 Some programmers will argue that it is the same as the precedence
12989 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
12991 By this interpretation, the subexpression @samp{M.EQ.N} must be
12992 evaluated first in the above program, resulting in a program that,
12993 when run, does not execute the @code{PRINT} statement.
12995 Other programmers will argue that the precedence is the same as
12996 the precedence for @code{.EQV.}, which is restricted by the standards
12997 to @code{LOGICAL} operands.
12998 By this interpretation, the subexpression @samp{L.AND.M} must be
12999 evaluated first, resulting in a program that @emph{does} execute
13000 the @code{PRINT} statement.
13002 Assigning arbitrary semantic interpretations to syntactic expressions
13003 that might legitimately have more than one ``obvious'' interpretation
13004 is generally unwise.
13006 The creators of the various Fortran standards have done a good job
13007 in this case, requiring a distinct set of operators (which have their
13008 own distinct precedence) to compare @code{LOGICAL} operands.
13009 This requirement results in expression syntax with more certain
13010 precedence (without requiring substantial context), making it easier
13011 for programmers to read existing code.
13012 @code{g77} will avoid muddying up elements of the Fortran language
13013 that were well-designed in the first place.
13015 (Ask C programmers about the precedence of expressions such as
13016 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
13017 you, without knowing more context, whether the @samp{&} and @samp{-}
13018 operators are infix (binary) or unary!)
13020 Most dangerous of all is the fact that,
13021 even assuming consensus on its meaning,
13022 an expression like @samp{L.AND.M.EQ.N},
13023 if it is the result of a typographical error,
13024 doesn't @emph{look} like it has such a typo.
13025 Even experienced Fortran programmers would not likely notice that
13026 @samp{L.AND.M.EQV.N} was, in fact, intended.
13028 So, this is a prime example of a circumstance in which
13029 a quality compiler diagnoses the code,
13030 instead of leaving it up to someone debugging it
13031 to know to turn on special compiler options
13032 that might diagnose it.
13034 @node Order of Side Effects
13035 @subsection Order of Side Effects
13036 @cindex side effects, order of evaluation
13037 @cindex order of evaluation, side effects
13039 @code{g77} does not necessarily produce code that, when run, performs
13040 side effects (such as those performed by function invocations)
13041 in the same order as in some other compiler---or even in the same
13042 order as another version, port, or invocation (using different
13043 command-line options) of @code{g77}.
13045 It is never safe to depend on the order of evaluation of side effects.
13046 For example, an expression like this may very well behave differently
13047 from one compiler to another:
13050 J = IFUNC() - IFUNC()
13054 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
13056 Either invocation might happen first.
13057 If @samp{IFUNC} returns 5 the first time it is invoked, and
13058 returns 12 the second time, @samp{J} might end up with the
13059 value @samp{7}, or it might end up with @samp{-7}.
13061 Generally, in Fortran, procedures with side-effects intended to
13062 be visible to the caller are best designed as @emph{subroutines},
13064 Examples of such side-effects include:
13068 The generation of random numbers
13069 that are intended to influence return values.
13073 (other than internal I/O to local variables).
13076 Updating information in common blocks.
13079 An example of a side-effect that is not intended to be visible
13080 to the caller is a function that maintains a cache of recently
13081 calculated results, intended solely to speed repeated invocations
13082 of the function with identical arguments.
13083 Such a function can be safely used in expressions, because
13084 if the compiler optimizes away one or more calls to the
13085 function, operation of the program is unaffected (aside
13086 from being speeded up).
13088 @node Warnings and Errors
13089 @section Warning Messages and Error Messages
13091 @cindex error messages
13092 @cindex warnings vs errors
13093 @cindex messages, warning and error
13094 The GNU compiler can produce two kinds of diagnostics: errors and
13096 Each kind has a different purpose:
13100 @emph{Errors} report problems that make it impossible to compile your
13102 GNU Fortran reports errors with the source file name, line
13103 number, and column within the line where the problem is apparent.
13106 @emph{Warnings} report other unusual conditions in your code that
13107 @emph{might} indicate a problem, although compilation can (and does)
13109 Warning messages also report the source file name, line number,
13110 and column information,
13111 but include the text @samp{warning:} to distinguish them
13112 from error messages.
13115 Warnings might indicate danger points where you should check to make sure
13116 that your program really does what you intend; or the use of obsolete
13117 features; or the use of nonstandard features of GNU Fortran.
13118 Many warnings are issued only if you ask for them, with one of the
13119 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
13122 @emph{Note:} Currently, the text of the line and a pointer to the column
13123 is printed in most @code{g77} diagnostics.
13124 Probably, as of version 0.6, @code{g77} will
13125 no longer print the text of the source line, instead printing
13126 the column number following the file name and line number in
13127 a form that GNU Emacs recognizes.
13128 This change is expected to speed up and reduce the memory usage
13129 of the @code{g77} compiler.
13131 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
13133 @c GNU Fortran always tries to compile your program if possible; it never
13134 @c gratuitously rejects a program whose meaning is clear merely because
13135 @c (for instance) it fails to conform to a standard. In some cases,
13136 @c however, the Fortran standard specifies that certain extensions are
13137 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
13138 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
13139 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
13140 @c This does not mean that @emph{all} non-ANSI constructs get warnings
13143 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
13144 more detail on these and related command-line options.
13146 @node Open Questions
13147 @chapter Open Questions
13149 Please consider offering useful answers to these questions!
13153 @code{LOC()} and other intrinsics are probably somewhat misclassified.
13154 Is the a need for more precise classification of intrinsics, and if so,
13155 what are the appropriate groupings?
13156 Is there a need to individually
13157 enable/disable/delete/hide intrinsics from the command line?
13161 @chapter Reporting Bugs
13163 @cindex reporting bugs
13165 Your bug reports play an essential role in making GNU Fortran reliable.
13167 When you encounter a problem, the first thing to do is to see if it is
13170 If it isn't known, then you should report the problem.
13172 Reporting a bug might help you by bringing a solution to your problem, or
13174 (If it does not, look in the service directory; see
13176 In any case, the principal function of a bug report is
13177 to help the entire community by making the next version of GNU Fortran work
13179 Bug reports are your contribution to the maintenance of GNU Fortran.
13181 Since the maintainers are very overloaded, we cannot respond to every
13183 However, if the bug has not been fixed, we are likely to
13184 send you a patch and ask you to tell us whether it works.
13186 In order for a bug report to serve its purpose, you must include the
13187 information that makes for fixing the bug.
13190 * Criteria: Bug Criteria. Have you really found a bug?
13191 * Where: Bug Lists. Where to send your bug report.
13192 * Reporting: Bug Reporting. How to report a bug effectively.
13193 * Patches: Sending Patches. How to send a patch for GNU Fortran.
13196 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
13197 for information on problems we already know about.
13199 @xref{Service,,How To Get Help with GNU Fortran},
13200 for information on where to ask for help.
13203 @section Have You Found a Bug?
13204 @cindex bug criteria
13206 If you are not sure whether you have found a bug, here are some guidelines:
13209 @cindex fatal signal
13212 If the compiler gets a fatal signal, for any input whatever, that is a
13214 Reliable compilers never crash---they just remain obsolete.
13216 @cindex invalid assembly code
13217 @cindex assembly code, invalid
13219 If the compiler produces invalid assembly code, for any input whatever,
13220 @c (except an @code{asm} statement),
13221 that is a compiler bug, unless the
13222 compiler reports errors (not just warnings) which would ordinarily
13223 prevent the assembler from being run.
13225 @cindex undefined behavior
13226 @cindex undefined function value
13228 If the compiler produces valid assembly code that does not correctly
13229 execute the input source code, that is a compiler bug.
13231 However, you must double-check to make sure, because you might have run
13232 into an incompatibility between GNU Fortran and traditional Fortran.
13233 @c (@pxref{Incompatibilities}).
13234 These incompatibilities might be considered
13235 bugs, but they are inescapable consequences of valuable features.
13237 Or you might have a program whose behavior is undefined, which happened
13238 by chance to give the desired results with another Fortran compiler.
13239 It is best to check the relevant Fortran standard thoroughly if
13240 it is possible that the program indeed does something undefined.
13242 After you have localized the error to a single source line, it should
13243 be easy to check for these things.
13244 If your program is correct and well defined, you have found
13247 It might help if, in your submission, you identified the specific
13248 language in the relevant Fortran standard that specifies the
13249 desired behavior, if it isn't likely to be obvious and agreed-upon
13250 by all Fortran users.
13253 If the compiler produces an error message for valid input, that is a
13256 @cindex invalid input
13258 If the compiler does not produce an error message for invalid input,
13259 that is a compiler bug.
13260 However, you should note that your idea of
13261 ``invalid input'' might be someone else's idea
13262 of ``an extension'' or ``support for traditional practice''.
13265 If you are an experienced user of Fortran compilers, your suggestions
13266 for improvement of GNU Fortran are welcome in any case.
13269 Many, perhaps most, bug reports against @code{g77} turn out to
13270 be bugs in the user's code.
13271 While we find such bug reports educational, they sometimes take
13272 a considerable amount of time to track down or at least respond
13273 to---time we could be spending making @code{g77}, not some user's
13276 Some steps you can take to verify that the bug is not certainly
13277 in the code you're compiling with @code{g77}:
13281 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
13282 These options enable many useful warning; the @samp{-O} option
13283 enables flow analysis that enables the uninitialized-variable
13286 If you investigate the warnings and find evidence of possible bugs
13287 in your code, fix them first and retry @code{g77}.
13290 Compile your code using the @code{g77} options @samp{-finit-local-zero},
13291 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
13292 combinations thereof.
13294 If your code works with any of these combinations, that is not
13295 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
13296 by your code might simply be avoided, or have a different, more subtle
13297 effect, when different options are used---but it can be a
13298 strong indicator that your code is making unwarranted assumptions
13299 about the Fortran dialect and/or underlying machine it is
13300 being compiled and run on.
13302 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
13303 for information on the @samp{-fno-automatic} and
13304 @samp{-finit-local-zero} options and how to convert
13305 their use into selective changes in your own code.
13309 Validate your code with @code{ftnchek} or a similar code-checking
13311 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
13312 or @uref{ftp://ftp.dsm.fordham.edu}.
13315 @cindex Makefile example
13316 Here are some sample @file{Makefile} rules using @code{ftnchek}
13317 ``project'' files to do cross-file checking and @code{sfmakedepend}
13318 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
13319 to maintain dependencies automatically.
13320 These assume the use of GNU @code{make}.
13323 # Dummy suffix for ftnchek targets:
13327 # How to compile .f files (for implicit rule):
13329 # Assume `include' directory:
13330 FFLAGS = -Iinclude -g -O -Wall
13332 # Flags for ftnchek:
13333 CHEK1 = -array=0 -include=includes -noarray
13334 CHEK2 = -nonovice -usage=1 -notruncation
13335 CHEKFLAGS = $(CHEK1) $(CHEK2)
13337 # Run ftnchek with all the .prj files except the one corresponding
13338 # to the target's root:
13340 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
13341 -noextern -library $<
13343 # Derive a project file from a source file:
13345 ftnchek $(CHEKFLAGS) -noextern -project -library $<
13347 # The list of objects is assumed to be in variable OBJS.
13348 # Sources corresponding to the objects:
13349 SRCS = $(OBJS:%.o=%.f)
13350 # ftnchek project files:
13351 PRJS = $(OBJS:%.o=%.prj)
13353 # Build the program
13355 $(FC) -o $@ $(OBJS)
13357 chekall: $(PRJS) ; \
13358 ftnchek $(CHEKFLAGS) $(PRJS)
13362 # For Emacs M-x find-tag:
13366 # Rebuild dependencies:
13368 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
13372 Try your code out using other Fortran compilers, such as @code{f2c}.
13373 If it does not work on at least one other compiler (assuming the
13374 compiler supports the features the code needs), that is a strong
13375 indicator of a bug in the code.
13377 However, even if your code works on many compilers @emph{except}
13378 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
13379 It might mean the bug is in your code, and that @code{g77} simply
13380 exposes it more readily than other compilers.
13384 @section Where to Report Bugs
13385 @cindex bug report mailing lists
13386 @kindex @value{email-bugs}
13387 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
13389 Often people think of posting bug reports to a newsgroup instead of
13391 This sometimes appears to work, but it has one problem which can be
13392 crucial: a newsgroup posting does not contain a mail path back to the
13394 Thus, if maintainers need more information, they might be unable
13395 to reach you. For this reason, you should always send bug reports by
13396 mail to the proper mailing list.
13398 As a last resort, send bug reports on paper to:
13402 Free Software Foundation
13403 59 Temple Place - Suite 330
13404 Boston, MA 02111-1307, USA
13407 @node Bug Reporting
13408 @section How to Report Bugs
13409 @cindex compiler bugs, reporting
13411 The fundamental principle of reporting bugs usefully is this:
13412 @strong{report all the facts}.
13413 If you are not sure whether to state a
13414 fact or leave it out, state it!
13416 Often people omit facts because they think they know what causes the
13417 problem and they conclude that some details don't matter.
13419 assume that the name of the variable you use in an example does not matter.
13420 Well, probably it doesn't, but one cannot be sure.
13421 Perhaps the bug is a
13422 stray memory reference which happens to fetch from the location where that
13423 name is stored in memory; perhaps, if the name were different, the contents
13424 of that location would fool the compiler into doing the right thing despite
13426 Play it safe and give a specific, complete example.
13428 easiest thing for you to do, and the most helpful.
13430 Keep in mind that the purpose of a bug report is to enable someone to
13431 fix the bug if it is not known.
13432 It isn't very important what happens if
13433 the bug is already known.
13434 Therefore, always write your bug reports on
13435 the assumption that the bug is not known.
13437 Sometimes people give a few sketchy facts and ask, ``Does this ring a
13439 This cannot help us fix a bug, so it is rarely helpful.
13440 We respond by asking for enough details to enable us to investigate.
13441 You might as well expedite matters by sending them to begin with.
13442 (Besides, there are enough bells ringing around here as it is.)
13444 Try to make your bug report self-contained.
13445 If we have to ask you for
13446 more information, it is best if you include all the previous information
13447 in your response, as well as the information that was missing.
13449 Please report each bug in a separate message.
13450 This makes it easier for
13451 us to track which bugs have been fixed and to forward your bugs reports
13452 to the appropriate maintainer.
13454 Do not compress and encode any part of your bug report using programs
13455 such as @file{uuencode}.
13456 If you do so it will slow down the processing
13458 If you must submit multiple large files, use @file{shar},
13459 which allows us to read your message without having to run any
13460 decompression programs.
13462 (As a special exception for GNU Fortran bug-reporting, at least
13463 for now, if you are sending more than a few lines of code, if
13464 your program's source file format contains ``interesting'' things
13465 like trailing spaces or strange characters, or if you need to
13466 include binary data files, it is acceptable to put all the
13467 files together in a @code{tar} archive, and, whether you need to
13468 do that, it is acceptable to then compress the single file (@code{tar}
13469 archive or source file)
13470 using @code{gzip} and encode it via @code{uuencode}.
13471 Do not use any MIME stuff---the current maintainer can't decode this.
13472 Using @code{compress} instead of @code{gzip} is acceptable, assuming
13473 you have licensed the use of the patented algorithm in
13474 @code{compress} from Unisys.)
13476 To enable someone to investigate the bug, you should include all these
13481 The version of GNU Fortran.
13482 You can get this by running @code{g77} with the @samp{-v} option.
13483 (Ignore any error messages that might be displayed
13484 when the linker is run.)
13486 Without this, we won't know whether there is any point in looking for
13487 the bug in the current version of GNU Fortran.
13490 @cindex preprocessor
13491 @cindex cpp program
13492 @cindex programs, cpp
13494 A complete input file that will reproduce the bug.
13496 If your source file(s) require preprocessing
13497 (for example, their names have suffixes like
13498 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
13499 and the bug is in the compiler proper (@file{f771})
13500 or in a subsequent phase of processing,
13501 run your source file through the C preprocessor
13502 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
13503 Then, include the contents of @var{newfile} in the bug report.
13504 (When you do this, use the same preprocessor options---such as
13505 @samp{-I}, @samp{-D}, and @samp{-U}---that you used in actual
13508 A single statement is not enough of an example.
13509 In order to compile it,
13510 it must be embedded in a complete file of compiler input.
13511 The bug might depend on the details of how this is done.
13513 Without a real example one can compile,
13514 all anyone can do about your bug report is wish you luck.
13515 It would be futile to try to guess how to provoke the bug.
13516 For example, bugs in register allocation and reloading
13517 can depend on every little detail of the source and include files
13521 @cindex included files
13522 @cindex INCLUDE directive
13523 @cindex directive, INCLUDE
13524 @cindex #include directive
13525 @cindex directive, #include
13526 Note that you should include with your bug report any files
13527 included by the source file
13528 (via the @code{#include} or @code{INCLUDE} directive)
13529 that you send, and any files they include, and so on.
13531 It is not necessary to replace
13532 the @code{#include} and @code{INCLUDE} directives
13533 with the actual files in the version of the source file that
13534 you send, but it might make submitting the bug report easier
13536 However, be sure to @emph{reproduce} the bug using the @emph{exact}
13537 version of the source material you submit, to avoid wild-goose
13541 The command arguments you gave GNU Fortran to compile that example
13542 and observe the bug. For example, did you use @samp{-O}? To guarantee
13543 you won't omit something important, list all the options.
13545 If we were to try to guess the arguments, we would probably guess wrong
13546 and then we would not encounter the bug.
13549 The type of machine you are using, and the operating system name and
13551 (Much of this information is printed by @samp{g77 -v}---if you
13552 include that, send along any additional info you have that you
13553 don't see clearly represented in that output.)
13556 The operands you gave to the @code{configure} command when you installed
13560 A complete list of any modifications you have made to the compiler
13561 source. (We don't promise to investigate the bug unless it happens in
13562 an unmodified compiler. But if you've made modifications and don't tell
13563 us, then you are sending us on a wild-goose chase.)
13565 Be precise about these changes. A description in English is not
13566 enough---send a context diff for them.
13568 Adding files of your own (such as a machine description for a machine we
13569 don't support) is a modification of the compiler source.
13572 Details of any other deviations from the standard procedure for installing
13576 A description of what behavior you observe that you believe is
13577 incorrect. For example, ``The compiler gets a fatal signal,'' or,
13578 ``The assembler instruction at line 208 in the output is incorrect.''
13580 Of course, if the bug is that the compiler gets a fatal signal, then one
13581 can't miss it. But if the bug is incorrect output, the maintainer might
13582 not notice unless it is glaringly wrong. None of us has time to study
13583 all the assembler code from a 50-line Fortran program just on the chance that
13584 one instruction might be wrong. We need @emph{you} to do this part!
13586 Even if the problem you experience is a fatal signal, you should still
13587 say so explicitly. Suppose something strange is going on, such as, your
13588 copy of the compiler is out of synch, or you have encountered a bug in
13589 the C library on your system. (This has happened!) Your copy might
13590 crash and the copy here would not. If you @i{said} to expect a crash,
13591 then when the compiler here fails to crash, we would know that the bug
13592 was not happening. If you don't say to expect a crash, then we would
13593 not know whether the bug was happening. We would not be able to draw
13594 any conclusion from our observations.
13596 If the problem is a diagnostic when building GNU Fortran with some other
13597 compiler, say whether it is a warning or an error.
13599 Often the observed symptom is incorrect output when your program is run.
13600 Sad to say, this is not enough information unless the program is short
13601 and simple. None of us has time to study a large program to figure out
13602 how it would work if compiled correctly, much less which line of it was
13603 compiled wrong. So you will have to do that. Tell us which source line
13604 it is, and what incorrect result happens when that line is executed. A
13605 person who understands the program can find this as easily as finding a
13606 bug in the program itself.
13609 If you send examples of assembler code output from GNU Fortran,
13610 please use @samp{-g} when you make them. The debugging information
13611 includes source line numbers which are essential for correlating the
13612 output with the input.
13615 If you wish to mention something in the GNU Fortran source, refer to it by
13616 context, not by line number.
13618 The line numbers in the development sources don't match those in your
13619 sources. Your line numbers would convey no convenient information to the
13623 Additional information from a debugger might enable someone to find a
13624 problem on a machine which he does not have available. However, you
13625 need to think when you collect this information if you want it to have
13626 any chance of being useful.
13628 @cindex backtrace for bug reports
13629 For example, many people send just a backtrace, but that is never
13630 useful by itself. A simple backtrace with arguments conveys little
13631 about GNU Fortran because the compiler is largely data-driven; the same
13632 functions are called over and over for different RTL insns, doing
13633 different things depending on the details of the insn.
13635 Most of the arguments listed in the backtrace are useless because they
13636 are pointers to RTL list structure. The numeric values of the
13637 pointers, which the debugger prints in the backtrace, have no
13638 significance whatever; all that matters is the contents of the objects
13639 they point to (and most of the contents are other such pointers).
13641 In addition, most compiler passes consist of one or more loops that
13642 scan the RTL insn sequence. The most vital piece of information about
13643 such a loop---which insn it has reached---is usually in a local variable,
13644 not in an argument.
13647 What you need to provide in addition to a backtrace are the values of
13648 the local variables for several stack frames up. When a local
13649 variable or an argument is an RTX, first print its value and then use
13650 the GDB command @code{pr} to print the RTL expression that it points
13651 to. (If GDB doesn't run on your machine, use your debugger to call
13652 the function @code{debug_rtx} with the RTX as an argument.) In
13653 general, whenever a variable is a pointer, its value is no use
13654 without the data it points to.
13657 Here are some things that are not necessary:
13661 A description of the envelope of the bug.
13663 Often people who encounter a bug spend a lot of time investigating
13664 which changes to the input file will make the bug go away and which
13665 changes will not affect it.
13667 This is often time consuming and not very useful, because the way we
13668 will find the bug is by running a single example under the debugger with
13669 breakpoints, not by pure deduction from a series of examples. You might
13670 as well save your time for something else.
13672 Of course, if you can find a simpler example to report @emph{instead} of
13673 the original one, that is a convenience. Errors in the output will be
13674 easier to spot, running under the debugger will take less time, etc.
13675 Most GNU Fortran bugs involve just one function, so the most straightforward
13676 way to simplify an example is to delete all the function definitions
13677 except the one where the bug occurs. Those earlier in the file may be
13678 replaced by external declarations if the crucial function depends on
13679 them. (Exception: inline functions might affect compilation of functions
13680 defined later in the file.)
13682 However, simplification is not vital; if you don't want to do this,
13683 report the bug anyway and send the entire test case you used.
13686 In particular, some people insert conditionals @samp{#ifdef BUG} around
13687 a statement which, if removed, makes the bug not happen. These are just
13688 clutter; we won't pay any attention to them anyway. Besides, you should
13689 send us preprocessor output, and that can't have conditionals.
13692 A patch for the bug.
13694 A patch for the bug is useful if it is a good one. But don't omit the
13695 necessary information, such as the test case, on the assumption that a
13696 patch is all we need. We might see problems with your patch and decide
13697 to fix the problem another way, or we might not understand it at all.
13699 Sometimes with a program as complicated as GNU Fortran it is very hard to
13700 construct an example that will make the program follow a certain path
13701 through the code. If you don't send the example, we won't be able to
13702 construct one, so we won't be able to verify that the bug is fixed.
13704 And if we can't understand what bug you are trying to fix, or why your
13705 patch should be an improvement, we won't install it. A test case will
13706 help us to understand.
13708 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13709 understand and install your patches.
13712 A guess about what the bug is or what it depends on.
13714 Such guesses are usually wrong. Even the maintainer can't guess right
13715 about such things without first using the debugger to find the facts.
13720 We have no way of examining a core dump for your type of machine
13721 unless we have an identical system---and if we do have one,
13722 we should be able to reproduce the crash ourselves.
13725 @node Sending Patches
13726 @section Sending Patches for GNU Fortran
13728 If you would like to write bug fixes or improvements for the GNU Fortran
13729 compiler, that is very helpful.
13730 Send suggested fixes to the bug report
13731 mailing list, @email{@value{email-bugs}}.
13733 Please follow these guidelines so we can study your patches efficiently.
13734 If you don't follow these guidelines, your information might still be
13735 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13736 of work in the best of circumstances, and we can't keep up unless you do
13741 Send an explanation with your changes of what problem they fix or what
13742 improvement they bring about. For a bug fix, just include a copy of the
13743 bug report, and explain why the change fixes the bug.
13745 (Referring to a bug report is not as good as including it, because then
13746 we will have to look it up, and we have probably already deleted it if
13747 we've already fixed the bug.)
13750 Always include a proper bug report for the problem you think you have
13751 fixed. We need to convince ourselves that the change is right before
13752 installing it. Even if it is right, we might have trouble judging it if
13753 we don't have a way to reproduce the problem.
13756 Include all the comments that are appropriate to help people reading the
13757 source in the future understand why this change was needed.
13760 Don't mix together changes made for different reasons.
13761 Send them @emph{individually}.
13763 If you make two changes for separate reasons, then we might not want to
13764 install them both. We might want to install just one. If you send them
13765 all jumbled together in a single set of diffs, we have to do extra work
13766 to disentangle them---to figure out which parts of the change serve
13767 which purpose. If we don't have time for this, we might have to ignore
13768 your changes entirely.
13770 If you send each change as soon as you have written it, with its own
13771 explanation, then the two changes never get tangled up, and we can
13772 consider each one properly without any extra work to disentangle them.
13774 Ideally, each change you send should be impossible to subdivide into
13775 parts that we might want to consider separately, because each of its
13776 parts gets its motivation from the other parts.
13779 Send each change as soon as that change is finished. Sometimes people
13780 think they are helping us by accumulating many changes to send them all
13781 together. As explained above, this is absolutely the worst thing you
13784 Since you should send each change separately, you might as well send it
13785 right away. That gives us the option of installing it immediately if it
13789 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13790 for us to install reliably. More than that, they make it hard for us to
13791 study the diffs to decide whether we want to install them. Unidiff
13792 format is better than contextless diffs, but not as easy to read as
13795 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13796 function that each change occurs in.
13797 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13800 Write the change log entries for your changes. We get lots of changes,
13801 and we don't have time to do all the change log writing ourselves.
13803 Read the @file{ChangeLog} file to see what sorts of information to put
13804 in, and to learn the style that we use. The purpose of the change log
13805 is to show people where to find what was changed. So you need to be
13806 specific about what functions you changed; in large functions, it's
13807 often helpful to indicate where within the function the change was.
13809 On the other hand, once you have shown people where to find the change,
13810 you need not explain its purpose. Thus, if you add a new function, all
13811 you need to say about it is that it is new. If you feel that the
13812 purpose needs explaining, it probably does---but the explanation will be
13813 much more useful if you put it in comments in the code.
13815 If you would like your name to appear in the header line for who made
13816 the change, send us the header line.
13819 When you write the fix, keep in mind that we can't install a change that
13820 would break other systems.
13822 People often suggest fixing a problem by changing machine-independent
13823 files such as @file{toplev.c} to do something special that a particular
13824 system needs. Sometimes it is totally obvious that such changes would
13825 break GNU Fortran for almost all users. We can't possibly make a change like
13826 that. At best it might tell us how to write another patch that would
13827 solve the problem acceptably.
13829 Sometimes people send fixes that @emph{might} be an improvement in
13830 general---but it is hard to be sure of this. It's hard to install
13831 such changes because we have to study them very carefully. Of course,
13832 a good explanation of the reasoning by which you concluded the change
13833 was correct can help convince us.
13835 The safest changes are changes to the configuration files for a
13836 particular machine. These are safe because they can't create new bugs
13839 Please help us keep up with the workload by designing the patch in a
13840 form that is good to install.
13844 @chapter How To Get Help with GNU Fortran
13846 If you need help installing, using or changing GNU Fortran, there are two
13851 Look in the service directory for someone who might help you for a fee.
13852 The service directory is found in the file named @file{SERVICE} in the
13853 GNU CC distribution.
13856 Send a message to @email{@value{email-general}}.
13861 @node Adding Options
13862 @chapter Adding Options
13863 @cindex options, adding
13864 @cindex adding options
13866 To add a new command-line option to @code{g77}, first decide
13867 what kind of option you wish to add.
13868 Search the @code{g77} and @code{gcc} documentation for one
13869 or more options that is most closely like the one you want to add
13870 (in terms of what kind of effect it has, and so on) to
13871 help clarify its nature.
13875 @emph{Fortran options} are options that apply only
13876 when compiling Fortran programs.
13877 They are accepted by @code{g77} and @code{gcc}, but
13878 they apply only when compiling Fortran programs.
13881 @emph{Compiler options} are options that apply
13882 when compiling most any kind of program.
13885 @emph{Fortran options} are listed in the file
13886 @file{@value{path-g77}/lang-options.h},
13887 which is used during the build of @code{gcc} to
13888 build a list of all options that are accepted by
13889 at least one language's compiler.
13890 This list goes into the @code{lang_options} array
13891 in @file{gcc/toplev.c}, which uses this array to
13892 determine whether a particular option should be
13893 offered to the linked-in front end for processing
13894 by calling @code{lang_option_decode}, which, for
13895 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13896 calls @code{ffe_decode_option}.
13898 If the linked-in front end ``rejects'' a
13899 particular option passed to it, @file{toplev.c}
13900 just ignores the option, because @emph{some}
13901 language's compiler is willing to accept it.
13903 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13904 to work, even though Fortran compilation does
13905 not currently support the @samp{-fno-asm} option;
13906 even though the @code{f771} version of @code{lang_decode_option}
13907 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13908 produce a diagnostic because some other language (C)
13911 This also means that commands like
13912 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13913 despite the fact that no phase of the command was
13914 able to recognize and process @samp{-fno-asm}---perhaps
13915 a warning about this would be helpful if it were
13918 Code that processes Fortran options is found in
13919 @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
13920 This code needs to check positive and negative forms
13923 The defaults for Fortran options are set in their
13924 global definitions, also found in @file{@value{path-g77}/top.c}.
13925 Many of these defaults are actually macros defined
13926 in @file{@value{path-g77}/target.h}, since they might be
13928 However, since, in practice, GNU compilers
13929 should behave the same way on all configurations
13930 (especially when it comes to language constructs),
13931 the practice of setting defaults in @file{target.h}
13932 is likely to be deprecated and, ultimately, stopped
13933 in future versions of @code{g77}.
13935 Accessor macros for Fortran options, used by code
13936 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13938 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13939 in the array @code{f_options}.
13940 An option not listed in @code{lang_options} is
13941 looked up in @code{f_options} and handled from there.
13943 The defaults for compiler options are set in the
13944 global definitions for the corresponding variables,
13945 some of which are in @file{gcc/toplev.c}.
13947 You can set different defaults for @emph{Fortran-oriented}
13948 or @emph{Fortran-reticent} compiler options by changing
13949 the source code of @code{g77} and rebuilding.
13950 How to do this depends on the version of @code{g77}:
13953 @item G77 0.5.24 (EGCS 1.1)
13954 @itemx G77 0.5.25 (EGCS 1.2)
13955 Change the @code{lang_init_options} routine in @file{egcs/gcc/f/com.c}.
13957 (Note that these versions of @code{g77}
13958 perform internal consistency checking automatically
13959 when the @samp{-fversion} option is specified.)
13962 @itemx G77 0.5.24 (EGCS 1.0)
13963 Change the way @code{f771} handles the @samp{-fset-g77-defaults}
13964 option, which is always provided as the first option when
13965 called by @code{g77} or @code{gcc}.
13967 This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13968 Have it change just the variables that you want to default
13969 to a different setting for Fortran compiles compared to
13970 compiles of other languages.
13972 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13973 automatically because of the specification information
13974 kept in @file{@value{path-g77}/lang-specs.h}.
13975 This file tells the @code{gcc} command how to recognize,
13976 in this case, Fortran source files (those to be preprocessed,
13977 and those that are not), and further, how to invoke the
13978 appropriate programs (including @code{f771}) to process
13979 those source files.
13981 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
13982 @samp{-fversion}, and other options are passed, as appropriate,
13983 even when the user has not explicitly specified them.
13984 Other ``internal'' options such as @samp{-quiet} also
13985 are passed via this mechanism.
13992 If you want to contribute to @code{g77} by doing research,
13993 design, specification, documentation, coding, or testing,
13994 the following information should give you some ideas.
13995 More relevant information might be available from
13996 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
13999 * Efficiency:: Make @code{g77} itself compile code faster.
14000 * Better Optimization:: Teach @code{g77} to generate faster code.
14001 * Simplify Porting:: Make @code{g77} easier to configure, build,
14003 * More Extensions:: Features many users won't know to ask for.
14004 * Machine Model:: @code{g77} should better leverage @code{gcc}.
14005 * Internals Documentation:: Make maintenance easier.
14006 * Internals Improvements:: Make internals more robust.
14007 * Better Diagnostics:: Make using @code{g77} on new code easier.
14011 @section Improve Efficiency
14014 Don't bother doing any performance analysis until most of the
14015 following items are taken care of, because there's no question
14016 they represent serious space/time problems, although some of
14017 them show up only given certain kinds of (popular) input.
14021 Improve @code{malloc} package and its uses to specify more info about
14022 memory pools and, where feasible, use obstacks to implement them.
14025 Skip over uninitialized portions of aggregate areas (arrays,
14026 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
14027 This would reduce memory usage for large initialized aggregate
14028 areas, even ones with only one initialized element.
14030 As of version 0.5.18, a portion of this item has already been
14034 Prescan the statement (in @file{sta.c}) so that the nature of the statement
14035 is determined as much as possible by looking entirely at its form,
14036 and not looking at any context (previous statements, including types
14038 This would allow ripping out of the statement-confirmation,
14039 symbol retraction/confirmation, and diagnostic inhibition
14041 Plus, it would result in much-improved diagnostics.
14042 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
14043 is not a subroutine intrinsic, would result actual error instead of the
14044 unimplemented-statement catch-all.
14047 Throughout @code{g77}, don't pass line/column pairs where
14048 a simple @code{ffewhere} type, which points to the error as much as is
14049 desired by the configuration, will do, and don't pass @code{ffelexToken} types
14050 where a simple @code{ffewhere} type will do.
14051 Then, allow new default
14052 configuration of @code{ffewhere} such that the source line text is not
14053 preserved, and leave it to things like Emacs' next-error function
14054 to point to them (now that @samp{next-error} supports column,
14055 or, perhaps, character-offset, numbers).
14056 The change in calling sequences should improve performance somewhat,
14057 as should not having to save source lines.
14058 (Whether this whole
14059 item will improve performance is questionable, but it should
14060 improve maintainability.)
14063 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
14064 as regards the assembly output.
14065 Some of this might require improving
14066 the back end, but lots of improvement in space/time required in @code{g77}
14067 itself can be fairly easily obtained without touching the back end.
14068 Maybe type-conversion, where necessary, can be speeded up as well in
14069 cases like the one shown (converting the @samp{2} into @samp{2.}).
14072 If analysis shows it to be worthwhile, optimize @file{lex.c}.
14075 Consider redesigning @file{lex.c} to not need any feedback
14076 during tokenization, by keeping track of enough parse state on its
14080 @node Better Optimization
14081 @section Better Optimization
14082 @cindex optimization, better
14083 @cindex code generation, improving
14085 Much of this work should be put off until after @code{g77} has
14086 all the features necessary for its widespread acceptance as a
14087 useful F77 compiler.
14088 However, perhaps this work can be done in parallel during
14089 the feature-adding work.
14093 Do the equivalent of the trick of putting @samp{extern inline} in front
14094 of every function definition in @code{libg2c} and #include'ing the resulting
14095 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
14096 that are at all worth inlining.
14097 (Some of this has already been done, such as for integral exponentiation.)
14100 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
14101 and it's clear that types line up
14102 and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
14103 make @samp{CHAR_VAR}, not a
14104 temporary, be the receiver for @samp{CHAR_FUNC}.
14105 (This is now done for @code{COMPLEX} variables.)
14108 Design and implement Fortran-specific optimizations that don't
14109 really belong in the back end, or where the front end needs to
14110 give the back end more info than it currently does.
14113 Design and implement a new run-time library interface, with the
14114 code going into @code{libgcc} so no special linking is required to
14115 link Fortran programs using standard language features.
14117 would speed up lots of things, from I/O (using precompiled formats,
14118 doing just one, or, at most, very few, calls for arrays or array sections,
14119 and so on) to general computing (array/section implementations of
14120 various intrinsics, implementation of commonly performed loops that
14121 aren't likely to be optimally compiled otherwise, etc.).
14123 Among the important things the library would do are:
14127 Be a one-stop-shop-type
14128 library, hence shareable and usable by all, in that what are now
14129 library-build-time options in @code{libg2c} would be moved at least to the
14130 @code{g77} compile phase, if not to finer grains (such as choosing how
14131 list-directed I/O formatting is done by default at @code{OPEN} time, for
14132 preconnected units via options or even statements in the main program
14133 unit, maybe even on a per-I/O basis with appropriate pragma-like
14138 Probably requiring the new library design, change interface to
14139 normally have @code{COMPLEX} functions return their values in the way
14140 @code{gcc} would if they were declared @code{__complex__ float},
14142 the mechanism currently used by @code{CHARACTER} functions (whereby the
14143 functions are compiled as returning void and their first arg is
14144 a pointer to where to store the result).
14145 (Don't append underscores to
14146 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
14147 @code{gcc} rather than @code{f2c} calling conventions.)
14150 Do something useful with @code{doiter} references where possible.
14151 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
14152 a @code{DO} loop that uses @samp{I} as the
14153 iteration variable, and the back end might find that info useful
14154 in determining whether it needs to read @samp{I} back into a register after
14156 (It normally has to do that, unless it knows @samp{FOO} never
14157 modifies its passed-by-reference argument, which is rarely the case
14158 for Fortran-77 code.)
14161 @node Simplify Porting
14162 @section Simplify Porting
14163 @cindex porting, simplify
14164 @cindex simplify porting
14166 Making @code{g77} easier to configure, port, build, and install, either
14167 as a single-system compiler or as a cross-compiler, would be
14172 A new library (replacing @code{libg2c}) should improve portability as well as
14173 produce more optimal code.
14174 Further, @code{g77} and the new library should
14175 conspire to simplify naming of externals, such as by removing unnecessarily
14176 added underscores, and to reduce/eliminate the possibility of naming
14177 conflicts, while making debugger more straightforward.
14180 make multi-language applications more feasible, such as by providing
14181 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
14185 Possibly related to a new library, @code{g77} should produce the equivalent
14186 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
14187 main program unit, instead of compiling something that must be
14188 called by a library
14189 implementation of @code{main()}.
14191 This would do many useful things such as
14192 provide more flexibility in terms of setting up exception handling,
14193 not requiring programmers to start their debugging sessions with
14194 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
14197 The GBE needs to understand the difference between alignment
14198 requirements and desires.
14199 For example, on Intel x86 machines, @code{g77} currently imposes
14200 overly strict alignment requirements, due to the back end, but it
14201 would be useful for Fortran and C programmers to be able to override
14202 these @emph{recommendations} as long as they don't violate the actual
14203 processor @emph{requirements}.
14206 @node More Extensions
14207 @section More Extensions
14208 @cindex extensions, more
14210 These extensions are not the sort of things users ask for ``by name'',
14211 but they might improve the usability of @code{g77}, and Fortran in
14212 general, in the long run.
14213 Some of these items really pertain to improving @code{g77} internals
14214 so that some popular extensions can be more easily supported.
14218 Look through all the documentation on the GNU Fortran language,
14219 dialects, compiler, missing features, bugs, and so on.
14220 Many mentions of incomplete or missing features are
14221 sprinkled throughout.
14222 It is not worth repeating them here.
14225 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
14227 The idea is to provide a forward-looking, effective
14228 replacement for things like the old-style @code{PARAMETER} statement
14230 really need typelessness in a maintainable, portable, clearly documented
14232 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
14233 and whatever else might come along.
14234 (This is not really a call for polymorphism per se, just
14235 an ability to express limited, syntactic polymorphism.)
14238 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
14241 Support arbitrary file unit numbers, instead of limiting them
14242 to 0 through @samp{MXUNIT-1}.
14243 (This is a @code{libg2c} issue.)
14246 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
14247 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
14248 later @code{UNIT=} in the first example is invalid.
14249 Make sure this is what users of this feature would expect.
14252 Currently @code{g77} disallows @samp{READ(1'10)} since
14253 it is an obnoxious syntax, but
14254 supporting it might be pretty easy if needed.
14255 More details are needed, such
14256 as whether general expressions separated by an apostrophe are supported,
14257 or maybe the record number can be a general expression, and so on.
14260 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
14262 Currently there is no support at all
14263 for @code{%FILL} in @code{STRUCTURE} and related syntax,
14264 whereas the rest of the
14265 stuff has at least some parsing support.
14266 This requires either major
14267 changes to @code{libg2c} or its replacement.
14270 F90 and @code{g77} probably disagree about label scoping relative to
14271 @code{INTERFACE} and @code{END INTERFACE}, and their contained
14272 procedure interface bodies (blocks?).
14275 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
14276 since that was added after S8.112.
14279 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
14280 with the final form of the standard (it was vague at S8.112).
14283 It seems to be an ``open'' question whether a file, immediately after being
14284 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
14285 might be nice to offer an option of opening to ``undefined'' status, requiring
14286 an explicit absolute-positioning operation to be performed before any
14287 other (besides @code{CLOSE}) to assist in making applications port to systems
14288 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
14291 @node Machine Model
14292 @section Machine Model
14294 This items pertain to generalizing @code{g77}'s view of
14295 the machine model to more fully accept whatever the GBE
14296 provides it via its configuration.
14300 Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
14301 exclusively so the target float format need not be required.
14303 means changing the way @code{g77} handles initialization of aggregate areas
14304 having more than one type, such as @code{REAL} and @code{INTEGER},
14306 it initializes them as if they were arrays of @code{char} and uses the
14307 bit patterns of the constants of the various types in them to determine
14308 what to stuff in elements of the arrays.
14311 Rely more and more on back-end info and capabilities, especially in the
14312 area of constants (where having the @code{g77} front-end's IL just store
14313 the appropriate tree nodes containing constants might be best).
14316 Suite of C and Fortran programs that a user/administrator can run on a
14317 machine to help determine the configuration for @code{g77} before building
14318 and help determine if the compiler works (especially with whatever
14319 libraries are installed) after building.
14322 @node Internals Documentation
14323 @section Internals Documentation
14325 Better info on how @code{g77} works and how to port it is needed.
14326 Much of this should be done only after the redesign planned for
14329 @xref{Front End}, which contains some information
14330 on @code{g77} internals.
14332 @node Internals Improvements
14333 @section Internals Improvements
14335 Some more items that would make @code{g77} more reliable
14336 and easier to maintain:
14340 Generally make expression handling focus
14341 more on critical syntax stuff, leaving semantics to callers.
14343 anything a caller can check, semantically, let it do so, rather
14344 than having @file{expr.c} do it.
14345 (Exceptions might include things like
14346 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
14348 important to preserve the left-to-right-in-source order of production
14352 Come up with better naming conventions for @samp{-D} to establish requirements
14353 to achieve desired implementation dialect via @file{proj.h}.
14356 Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
14359 Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
14362 Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
14363 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
14364 (after determining if there is indeed no real need for it).
14367 Utility to read and check @file{bad.def} messages and their references in the
14368 code, to make sure calls are consistent with message templates.
14371 Search and fix @samp{&ffe@dots{}} and similar so that
14372 @samp{ffe@dots{}ptr@dots{}} macros are
14373 available instead (a good argument for wishing this could have written all
14374 this stuff in C++, perhaps).
14375 On the other hand, it's questionable whether this sort of
14376 improvement is really necessary, given the availability of
14377 tools such as Emacs and Perl, which make finding any
14378 address-taking of structure members easy enough?
14381 Some modules truly export the member names of their structures (and the
14382 structures themselves), maybe fix this, and fix other modules that just
14383 appear to as well (by appending @samp{_}, though it'd be ugly and probably
14384 not worth the time).
14387 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
14389 and use them throughout @code{g77} source code (especially in the definitions
14390 of access macros in @samp{.h} files) so they can be tailored
14391 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
14394 Decorate throughout with @code{const} and other such stuff.
14397 All F90 notational derivations in the source code are still based
14398 on the S8.112 version of the draft standard.
14399 Probably should update
14400 to the official standard, or put documentation of the rules as used
14401 in the code@dots{}uh@dots{}in the code.
14404 Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
14405 inside but invoked via paths not involving @code{ffeexpr_lhs} or
14406 @code{ffeexpr_rhs}) might be creating things
14407 in improper pools, leading to such things staying around too long or
14408 (doubtful, but possible and dangerous) not long enough.
14411 Some @code{ffebld_list_new} (or whatever) calls might not be matched by
14412 @code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
14413 (It definitely is not a problem just yet.)
14416 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
14417 due to alignment/mismatch or other problems---they end up without
14418 @code{ffestorag} objects, so maybe the backend (and other parts of the front
14419 end) can notice that and handle like an @code{opANY} (do what it wants, just
14420 don't complain or crash).
14421 Most of this seems to have been addressed
14422 by now, but a code review wouldn't hurt.
14425 @node Better Diagnostics
14426 @section Better Diagnostics
14428 These are things users might not ask about, or that need to
14429 be looked into, before worrying about.
14430 Also here are items that involve reducing unnecessary diagnostic
14435 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
14436 lengths, type classes, and so on),
14437 @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
14441 Speed up and improve error handling for data when repeat-count is
14443 For example, don't output 20 unnecessary messages after the
14444 first necessary one for:
14449 DATA (X(I), J= 1, 20) /20*5/
14454 (The @code{CONTINUE} statement ensures the @code{DATA} statement
14455 is processed in the context of executable, not specification,
14465 @chapter Diagnostics
14466 @cindex diagnostics
14468 Some diagnostics produced by @code{g77} require sufficient explanation
14469 that the explanations are given below, and the diagnostics themselves
14470 identify the appropriate explanation.
14472 Identification uses the GNU Info format---specifically, the @code{info}
14473 command that displays the explanation is given within square
14474 brackets in the diagnostic.
14478 foo.f:5: Invalid statement [info -f g77 M FOOEY]
14481 More details about the above diagnostic is found in the @code{g77} Info
14482 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
14483 which is displayed by typing the UNIX command
14484 @samp{info -f g77 M FOOEY}.
14486 Other Info readers, such as EMACS, may be just as easily used to display
14487 the pertinent node.
14488 In the above example, @samp{g77} is the Info document name,
14489 @samp{M} is the top-level menu item to select,
14490 and, in that node (named @samp{Diagnostics}, the name of
14491 this chapter, which is the very text you're reading now),
14492 @samp{FOOEY} is the menu item to select.
14495 In this printed version of the @code{g77} manual, the above example
14496 points to a section, below, entitled @samp{FOOEY}---though, of course,
14497 as the above is just a sample, no such section exists.
14501 * CMPAMBIG:: Ambiguous use of intrinsic.
14502 * EXPIMP:: Intrinsic used explicitly and implicitly.
14503 * INTGLOB:: Intrinsic also used as name of global.
14504 * LEX:: Various lexer messages
14505 * GLOBALS:: Disagreements about globals.
14506 * LINKFAIL:: When linking @code{f771} fails.
14507 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
14511 @section @code{CMPAMBIG}
14515 Ambiguous use of intrinsic @var{intrinsic} @dots{}
14518 The type of the argument to the invocation of the @var{intrinsic}
14519 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
14520 Typically, it is @code{COMPLEX(KIND=2)}, also known as
14521 @code{DOUBLE COMPLEX}.
14523 The interpretation of this invocation depends on the particular
14524 dialect of Fortran for which the code was written.
14525 Some dialects convert the real part of the argument to
14526 @code{REAL(KIND=1)}, thus losing precision; other dialects,
14527 and Fortran 90, do no such conversion.
14529 So, GNU Fortran rejects such invocations except under certain
14530 circumstances, to avoid making an incorrect assumption that results
14531 in generating the wrong code.
14533 To determine the dialect of the program unit, perhaps even whether
14534 that particular invocation is properly coded, determine how the
14535 result of the intrinsic is used.
14537 The result of @var{intrinsic} is expected (by the original programmer)
14538 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
14542 It is passed as an argument to a procedure that explicitly or
14543 implicitly declares that argument @code{REAL(KIND=1)}.
14546 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
14547 statement specifying the dummy argument corresponding to an
14548 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14549 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14550 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
14551 of @code{REAL(KIND=2)}.
14554 It is used in a context that would otherwise not include
14555 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
14556 invocation as @code{REAL(KIND=2)} would result in unnecessary
14557 promotions and (typically) more expensive operations on the
14568 The above example suggests the programmer expected the real part
14569 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
14570 multiplied by @samp{T} (presumed, along with @samp{R} above, to
14571 be type @code{REAL(KIND=1)}).
14573 Otherwise, the conversion would have to be delayed until after
14574 the multiplication, requiring not only an extra conversion
14575 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
14576 expensive multiplication (a double-precision multiplication instead
14577 of a single-precision one).
14580 The result of @var{intrinsic} is expected (by the original programmer)
14581 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
14585 It is passed as an argument to a procedure that explicitly or
14586 implicitly declares that argument @code{REAL(KIND=2)}.
14588 For example, a procedure specifying a @code{DOUBLE PRECISION}
14589 dummy argument corresponding to an
14590 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14591 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14592 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
14593 of @code{REAL(KIND=1)}.
14596 It is used in an expression context that includes
14597 other @code{REAL(KIND=2)} operands,
14598 or is assigned to a @code{REAL(KIND=2)} variable or array element.
14604 DOUBLE PRECISION R, T
14609 The above example suggests the programmer expected the real part
14610 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
14611 by the @code{REAL()} intrinsic.
14613 Otherwise, the conversion would have to be immediately followed
14614 by a conversion back to @code{REAL(KIND=2)}, losing
14615 the original, full precision of the real part of @code{Z},
14616 before being multiplied by @samp{T}.
14619 Once you have determined whether a particular invocation of @var{intrinsic}
14620 expects the Fortran 90 interpretation, you can:
14624 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
14625 @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
14627 if it expected the Fortran 90 interpretation.
14629 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
14630 some other type, such as @code{COMPLEX*32}, you should use the
14631 appropriate intrinsic, such as the one to convert to @code{REAL*16}
14632 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
14633 @code{QIMAG()} in place of @code{DIMAG()}).
14636 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
14638 This converts to @code{REAL(KIND=1)} in all working
14642 If you don't want to change the code, and you are certain that all
14643 ambiguous invocations of @var{intrinsic} in the source file have
14644 the same expectation regarding interpretation, you can:
14648 Compile with the @code{g77} option @samp{-ff90}, to enable the
14649 Fortran 90 interpretation.
14652 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
14653 to enable the non-Fortran-90 interpretations.
14656 @xref{REAL() and AIMAG() of Complex}, for more information on this
14659 Note: If the above suggestions don't produce enough evidence
14660 as to whether a particular program expects the Fortran 90
14661 interpretation of this ambiguous invocation of @var{intrinsic},
14662 there is one more thing you can try.
14664 If you have access to most or all the compilers used on the
14665 program to create successfully tested and deployed executables,
14666 read the documentation for, and @emph{also} test out, each compiler
14667 to determine how it treats the @var{intrinsic} intrinsic in
14669 (If all the compilers don't agree on an interpretation, there
14670 might be lurking bugs in the deployed versions of the program.)
14672 The following sample program might help:
14674 @cindex JCB003 program
14678 C Written by James Craig Burley 1997-02-23.
14680 C Determine how compilers handle non-standard REAL
14681 C and AIMAG on DOUBLE COMPLEX operands.
14689 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14690 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14694 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14695 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14698 C Just to make sure compiler doesn't use naive flow
14699 C analysis to optimize away careful work above,
14700 C which might invalidate results....
14702 SUBROUTINE DUMDUM(Z, R)
14708 If the above program prints contradictory results on a
14709 particular compiler, run away!
14712 @section @code{EXPIMP}
14716 Intrinsic @var{intrinsic} referenced @dots{}
14719 The @var{intrinsic} is explicitly declared in one program
14720 unit in the source file and implicitly used as an intrinsic
14721 in another program unit in the same source file.
14723 This diagnostic is designed to catch cases where a program
14724 might depend on using the name @var{intrinsic} as an intrinsic
14725 in one program unit and as a global name (such as the name
14726 of a subroutine or function) in another, but @code{g77} recognizes
14727 the name as an intrinsic in both cases.
14729 After verifying that the program unit making implicit use
14730 of the intrinsic is indeed written expecting the intrinsic,
14731 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14732 program unit to prevent this warning.
14734 This and related warnings are disabled by using
14735 the @samp{-Wno-globals} option when compiling.
14737 Note that this warning is not issued for standard intrinsics.
14738 Standard intrinsics include those described in the FORTRAN 77
14739 standard and, if @samp{-ff90} is specified, those described
14740 in the Fortran 90 standard.
14741 Such intrinsics are not as likely to be confused with user
14742 procedures as intrinsics provided as extensions to the
14743 standard by @code{g77}.
14746 @section @code{INTGLOB}
14750 Same name `@var{intrinsic}' given @dots{}
14753 The name @var{intrinsic} is used for a global entity (a common
14754 block or a program unit) in one program unit and implicitly
14755 used as an intrinsic in another program unit.
14757 This diagnostic is designed to catch cases where a program
14758 intends to use a name entirely as a global name, but @code{g77}
14759 recognizes the name as an intrinsic in the program unit that
14760 references the name, a situation that would likely produce
14766 INTEGER FUNCTION TIME()
14772 PRINT *, 'Time is ', TIME()
14776 The above example defines a program unit named @samp{TIME}, but
14777 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14778 is normally treated by @code{g77} as a reference to the intrinsic
14779 @code{TIME()} (unless a command-line option that prevents such
14780 treatment has been specified).
14782 As a result, the program @samp{SAMP} will @emph{not}
14783 invoke the @samp{TIME} function in the same source file.
14785 Since @code{g77} recognizes @code{libU77} procedures as
14786 intrinsics, and since some existing code uses the same names
14787 for its own procedures as used by some @code{libU77}
14788 procedures, this situation is expected to arise often enough
14789 to make this sort of warning worth issuing.
14791 After verifying that the program unit making implicit use
14792 of the intrinsic is indeed written expecting the intrinsic,
14793 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14794 program unit to prevent this warning.
14796 Or, if you believe the program unit is designed to invoke the
14797 program-defined procedure instead of the intrinsic (as
14798 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14799 statement to the program unit that references the name to
14800 prevent this warning.
14802 This and related warnings are disabled by using
14803 the @samp{-Wno-globals} option when compiling.
14805 Note that this warning is not issued for standard intrinsics.
14806 Standard intrinsics include those described in the FORTRAN 77
14807 standard and, if @samp{-ff90} is specified, those described
14808 in the Fortran 90 standard.
14809 Such intrinsics are not as likely to be confused with user
14810 procedures as intrinsics provided as extensions to the
14811 standard by @code{g77}.
14814 @section @code{LEX}
14818 Unrecognized character @dots{}
14819 Invalid first character @dots{}
14820 Line too long @dots{}
14821 Non-numeric character @dots{}
14822 Continuation indicator @dots{}
14823 Label at @dots{} invalid with continuation line indicator @dots{}
14824 Character constant @dots{}
14825 Continuation line @dots{}
14826 Statement at @dots{} begins with invalid token
14829 Although the diagnostics identify specific problems, they can
14830 be produced when general problems such as the following occur:
14834 The source file contains something other than Fortran code.
14836 If the code in the file does not look like many of the examples
14837 elsewhere in this document, it might not be Fortran code.
14838 (Note that Fortran code often is written in lower case letters,
14839 while the examples in this document use upper case letters,
14840 for stylistic reasons.)
14842 For example, if the file contains lots of strange-looking
14843 characters, it might be APL source code; if it contains lots
14844 of parentheses, it might be Lisp source code; if it
14845 contains lots of bugs, it might be C++ source code.
14848 The source file contains free-form Fortran code, but @samp{-ffree-form}
14849 was not specified on the command line to compile it.
14851 Free form is a newer form for Fortran code.
14852 The older, classic form is called fixed form.
14854 @cindex continuation character
14855 @cindex characters, continuation
14856 Fixed-form code is visually fairly distinctive, because
14857 numerical labels and comments are all that appear in
14858 the first five columns of a line, the sixth column is
14859 reserved to denote continuation lines,
14860 and actual statements start at or beyond column 7.
14861 Spaces generally are not significant, so if you
14862 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14863 you are looking at fixed-form code.
14866 Comment lines are indicated by the letter @samp{C} or the symbol
14867 @samp{*} in column 1.
14868 @cindex trailing comment
14870 @cindex characters, comment
14872 @cindex exclamation point
14873 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14874 which many compilers support.)
14876 Free-form code is distinguished from fixed-form source
14877 primarily by the fact that statements may start anywhere.
14878 (If lots of statements start in columns 1 through 6,
14879 that's a strong indicator of free-form source.)
14880 Consecutive keywords must be separated by spaces, so
14881 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14882 There are no comment lines per se, but @samp{!} starts a
14883 comment anywhere in a line (other than within a character or
14884 Hollerith constant).
14886 @xref{Source Form}, for more information.
14889 The source file is in fixed form and has been edited without
14890 sensitivity to the column requirements.
14892 Statements in fixed-form code must be entirely contained within
14893 columns 7 through 72 on a given line.
14894 Starting them ``early'' is more likely to result in diagnostics
14895 than finishing them ``late'', though both kinds of errors are
14896 often caught at compile time.
14898 For example, if the following code fragment is edited by following
14899 the commented instructions literally, the result, shown afterward,
14900 would produce a diagnostic when compiled:
14903 C On XYZZY systems, remove "C" on next line:
14907 The result of editing the above line might be:
14910 C On XYZZY systems, remove "C" on next line:
14914 However, that leaves the first @samp{C} in the @code{CALL}
14915 statement in column 6, making it a comment line, which is
14916 not really what the author intended, and which is likely
14917 to result in one of the above-listed diagnostics.
14919 @emph{Replacing} the @samp{C} in column 1 with a space
14920 is the proper change to make, to ensure the @code{CALL}
14921 keyword starts in or after column 7.
14923 Another common mistake like this is to forget that fixed-form
14924 source lines are significant through only column 72, and that,
14925 normally, any text beyond column 72 is ignored or is diagnosed
14928 @xref{Source Form}, for more information.
14931 The source file requires preprocessing, and the preprocessing
14932 is not being specified at compile time.
14934 A source file containing lines beginning with @code{#define},
14935 @code{#include}, @code{#if}, and so on is likely one that
14936 requires preprocessing.
14938 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
14939 the file normally will be compiled @emph{without} preprocessing
14942 Change the file's suffix from @samp{.f} to @samp{.F}
14943 (or, on systems with case-insensitive file names,
14944 to @samp{.fpp} or @samp{.FPP}),
14945 from @samp{.for} to @samp{.fpp},
14946 or from @samp{.FOR} to @samp{.FPP}.
14947 @code{g77} compiles files with such names @emph{with}
14951 @cindex preprocessor
14952 @cindex cpp program
14953 @cindex programs, cpp
14954 @cindex @samp{-x f77-cpp-input} option
14955 @cindex options, @samp{-x f77-cpp-input}
14956 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14957 the language @samp{f77-cpp-input} for Fortran files that
14958 require preprocessing.
14959 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14962 The source file is preprocessed, and the results of preprocessing
14963 result in syntactic errors that are not necessarily obvious to
14964 someone examining the source file itself.
14966 Examples of errors resulting from preprocessor macro expansion
14967 include exceeding the line-length limit, improperly starting,
14968 terminating, or incorporating the apostrophe or double-quote in
14969 a character constant, improperly forming a Hollerith constant,
14972 @xref{Overall Options,,Options Controlling the Kind of Output},
14973 for suggestions about how to use, and not use, preprocessing
14978 @section @code{GLOBALS}
14982 Global name @var{name} defined at @dots{} already defined@dots{}
14983 Global name @var{name} at @dots{} has different type@dots{}
14984 Too many arguments passed to @var{name} at @dots{}
14985 Too few arguments passed to @var{name} at @dots{}
14986 Argument #@var{n} of @var{name} is @dots{}
14989 These messages all identify disagreements about the
14990 global procedure named @var{name} among different program units
14991 (usually including @var{name} itself).
14993 Whether a particular disagreement is reported
14994 as a warning or an error
14995 can depend on the relative order
14996 of the disagreeing portions of the source file.
14998 Disagreements between a procedure invocation
14999 and the @emph{subsequent} procedure itself
15000 are, usually, diagnosed as errors
15001 when the procedure itself @emph{precedes} the invocation.
15002 Other disagreements are diagnosed via warnings.
15004 @cindex forward references
15005 @cindex in-line code
15006 @cindex compilation, in-line
15007 This distinction, between warnings and errors,
15008 is due primarily to the present tendency of the @code{gcc} back end
15009 to inline only those procedure invocations that are
15010 @emph{preceded} by the corresponding procedure definitions.
15011 If the @code{gcc} back end is changed
15012 to inline ``forward references'',
15013 in which invocations precede definitions,
15014 the @code{g77} front end will be changed
15015 to treat both orderings as errors, accordingly.
15017 The sorts of disagreements that are diagnosed by @code{g77} include
15018 whether a procedure is a subroutine or function;
15019 if it is a function, the type of the return value of the procedure;
15020 the number of arguments the procedure accepts;
15021 and the type of each argument.
15023 Disagreements regarding global names among program units
15024 in a Fortran program @emph{should} be fixed in the code itself.
15025 However, if that is not immediately practical,
15026 and the code has been working for some time,
15027 it is possible it will work
15028 when compiled with the @samp{-fno-globals} option.
15030 The @samp{-fno-globals} option
15031 causes these diagnostics to all be warnings
15032 and disables all inlining of references to global procedures
15033 (to avoid subsequent compiler crashes and bad-code generation).
15034 Use of the @samp{-Wno-globals} option as well as @samp{-fno-globals}
15035 suppresses all of these diagnostics.
15036 (@samp{-Wno-globals} by itself disables only the warnings,
15039 After using @samp{-fno-globals} to work around these problems,
15040 it is wise to stop using that option and address them by fixing
15041 the Fortran code, because such problems, while they might not
15042 actually result in bugs on some systems, indicate that the code
15043 is not as portable as it could be.
15044 In particular, the code might appear to work on a particular
15045 system, but have bugs that affect the reliability of the data
15046 without exhibiting any other outward manifestations of the bugs.
15049 @section @code{LINKFAIL}
15053 If the above command failed due to an unresolved reference
15054 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
15055 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
15056 for information on what causes this, how to work around
15057 the problem by editing $@{srcdir@}/proj.c, and what else to do.
15060 @xref{Missing strtoul or bsearch}, for more information on
15062 which occurs only in releases of @code{g77}
15063 based on @code{gcc}.
15064 (It does not occur in @code{egcs}.)
15066 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
15067 due to a linker bug in coping with the @samp{-bbigtoc} option which
15068 leads to a @samp{Relocation overflow} error. The GNU linker is not
15069 recommended on current AIX versions, though; it was developed under a
15070 now-unsupported version. This bug is said to be fixed by `update PTF
15071 U455193 for APAR IX75823'.
15073 Compiling with @samp{-mminimal-toc}
15074 might solve this problem, e.g.@: by adding
15076 BOOT_CFLAGS='-mminimal-toc -O2 -g'
15078 to the @code{make bootstrap} command line.
15081 @section @code{Y2KBAD}
15082 @cindex Y2K compliance
15083 @cindex Year 2000 compliance
15087 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
15090 This diagnostic indicates that
15091 the specific intrinsic invoked by the name @var{name}
15092 is known to have an interface
15093 that is not Year-2000 (Y2K) compliant.
15095 @xref{Year 2000 (Y2K) Problems}.