12270 lines
428 KiB
Plaintext
12270 lines
428 KiB
Plaintext
\input texinfo @c -*-texinfo-*-
|
|
@c %**start of header
|
|
@setfilename g77.info
|
|
|
|
@set last-update 2002-04-29
|
|
@set copyrights-g77 1995,1996,1997,1998,1999,2000,2001,2002
|
|
|
|
@include root.texi
|
|
|
|
@c This tells @include'd files that they're part of the overall G77 doc
|
|
@c set. (They might be part of a higher-level doc set too.)
|
|
@set DOC-G77
|
|
|
|
@c @setfilename useg77.info
|
|
@c @setfilename portg77.info
|
|
@c To produce the full manual, use the "g77.info" setfilename, and
|
|
@c make sure the following do NOT begin with '@c' (and the @clear lines DO)
|
|
@set INTERNALS
|
|
@set USING
|
|
@c To produce a user-only manual, use the "useg77.info" setfilename, and
|
|
@c make sure the following does NOT begin with '@c':
|
|
@c @clear INTERNALS
|
|
@c To produce a porter-only manual, use the "portg77.info" setfilename,
|
|
@c and make sure the following does NOT begin with '@c':
|
|
@c @clear USING
|
|
|
|
@c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi)
|
|
@c @smallbook
|
|
|
|
@c i also commented out the finalout command, so if there *are* any
|
|
@c overfulls, you'll (hopefully) see the rectangle in the right hand
|
|
@c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi).
|
|
@c @finalout
|
|
|
|
@macro gcctabopt{body}
|
|
@code{\body\}
|
|
@end macro
|
|
@macro gccoptlist{body}
|
|
@smallexample
|
|
\body\
|
|
@end smallexample
|
|
@end macro
|
|
@c Makeinfo handles the above macro OK, TeX needs manual line breaks;
|
|
@c they get lost at some point in handling the macro. But if @macro is
|
|
@c used here rather than @alias, it produces double line breaks.
|
|
@iftex
|
|
@alias gol = *
|
|
@end iftex
|
|
@ifnottex
|
|
@macro gol
|
|
@end macro
|
|
@end ifnottex
|
|
|
|
@ifset INTERNALS
|
|
@ifset USING
|
|
@settitle Using and Porting GNU Fortran
|
|
@end ifset
|
|
@end ifset
|
|
@c seems reasonable to assume at least one of INTERNALS or USING is set...
|
|
@ifclear INTERNALS
|
|
@settitle Using GNU Fortran
|
|
@end ifclear
|
|
@ifclear USING
|
|
@settitle Porting GNU Fortran
|
|
@end ifclear
|
|
@c then again, have some fun
|
|
@ifclear INTERNALS
|
|
@ifclear USING
|
|
@settitle Doing Squat with GNU Fortran
|
|
@end ifclear
|
|
@end ifclear
|
|
|
|
@syncodeindex fn cp
|
|
@syncodeindex vr cp
|
|
@c %**end of header
|
|
|
|
@c Cause even numbered pages to be printed on the left hand side of
|
|
@c the page and odd numbered pages to be printed on the right hand
|
|
@c side of the page. Using this, you can print on both sides of a
|
|
@c sheet of paper and have the text on the same part of the sheet.
|
|
|
|
@c The text on right hand pages is pushed towards the right hand
|
|
@c margin and the text on left hand pages is pushed toward the left
|
|
@c hand margin.
|
|
@c (To provide the reverse effect, set bindingoffset to -0.75in.)
|
|
|
|
@c @tex
|
|
@c \global\bindingoffset=0.75in
|
|
@c \global\normaloffset =0.75in
|
|
@c @end tex
|
|
|
|
@ifinfo
|
|
@dircategory Programming
|
|
@direntry
|
|
* g77: (g77). The GNU Fortran compiler.
|
|
@end direntry
|
|
@ifset INTERNALS
|
|
@ifset USING
|
|
This file documents the use and the internals of the GNU Fortran (@command{g77})
|
|
compiler.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifset
|
|
@end ifset
|
|
@ifclear USING
|
|
This file documents the internals of the GNU Fortran (@command{g77}) compiler.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifclear
|
|
@ifclear INTERNALS
|
|
This file documents the use of the GNU Fortran (@command{g77}) compiler.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifclear
|
|
|
|
Published by the Free Software Foundation
|
|
59 Temple Place - Suite 330
|
|
Boston, MA 02111-1307 USA
|
|
|
|
Copyright (C) @value{copyrights-g77} Free Software Foundation, Inc.
|
|
|
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
|
any later version published by the Free Software Foundation; with the
|
|
Invariant Sections being ``GNU General Public License'' and ``Funding
|
|
Free Software'', the Front-Cover
|
|
texts being (a) (see below), and with the Back-Cover Texts being (b)
|
|
(see below). A copy of the license is included in the section entitled
|
|
``GNU Free Documentation License''.
|
|
|
|
(a) The FSF's Front-Cover Text is:
|
|
|
|
A GNU Manual
|
|
|
|
(b) The FSF's Back-Cover Text is:
|
|
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
|
software. Copies published by the Free Software Foundation raise
|
|
funds for GNU development.
|
|
@end ifinfo
|
|
|
|
Contributed by James Craig Burley (@email{@value{email-burley}}).
|
|
Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
|
|
was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).
|
|
|
|
@setchapternewpage odd
|
|
@c @finalout
|
|
@titlepage
|
|
@ifset INTERNALS
|
|
@ifset USING
|
|
@center @titlefont{Using and Porting GNU Fortran}
|
|
|
|
@end ifset
|
|
@end ifset
|
|
@ifclear INTERNALS
|
|
@title Using GNU Fortran
|
|
@end ifclear
|
|
@ifclear USING
|
|
@title Porting GNU Fortran
|
|
@end ifclear
|
|
@sp 2
|
|
@center James Craig Burley
|
|
@sp 3
|
|
@center Last updated @value{last-update}
|
|
@sp 1
|
|
@center for version @value{which-g77}
|
|
@page
|
|
@vskip 0pt plus 1filll
|
|
Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.
|
|
@sp 2
|
|
For the @value{which-g77} Version*
|
|
@sp 1
|
|
Published by the Free Software Foundation @*
|
|
59 Temple Place - Suite 330@*
|
|
Boston, MA 02111-1307, USA@*
|
|
@c Last printed ??ber, 19??.@*
|
|
@c Printed copies are available for $? each.@*
|
|
@c ISBN ???
|
|
@sp 1
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
|
any later version published by the Free Software Foundation; with the
|
|
Invariant Sections being ``GNU General Public License'' and ``Funding
|
|
Free Software'', the Front-Cover
|
|
texts being (a) (see below), and with the Back-Cover Texts being (b)
|
|
(see below). A copy of the license is included in the section entitled
|
|
``GNU Free Documentation License''.
|
|
|
|
(a) The FSF's Front-Cover Text is:
|
|
|
|
A GNU Manual
|
|
|
|
(b) The FSF's Back-Cover Text is:
|
|
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
|
software. Copies published by the Free Software Foundation raise
|
|
funds for GNU development.
|
|
@end titlepage
|
|
@summarycontents
|
|
@contents
|
|
@page
|
|
|
|
@node Top, Copying,, (DIR)
|
|
@top Introduction
|
|
@cindex Introduction
|
|
|
|
@ifset INTERNALS
|
|
@ifset USING
|
|
This manual documents how to run, install and port @command{g77},
|
|
as well as its new features and incompatibilities,
|
|
and how to report bugs.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifset
|
|
@end ifset
|
|
|
|
@ifclear INTERNALS
|
|
This manual documents how to run and install @command{g77},
|
|
as well as its new features and incompatibilities, and how to report
|
|
bugs.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifclear
|
|
@ifclear USING
|
|
This manual documents how to port @command{g77},
|
|
as well as its new features and incompatibilities,
|
|
and how to report bugs.
|
|
It corresponds to the @value{which-g77} version of @command{g77}.
|
|
@end ifclear
|
|
|
|
@ifset DEVELOPMENT
|
|
@emph{Warning:} This document is still under development,
|
|
and might not accurately reflect the @command{g77} code base
|
|
of which it is a part.
|
|
Efforts are made to keep it somewhat up-to-date,
|
|
but they are particularly concentrated
|
|
on any version of this information
|
|
that is distributed as part of a @emph{released} @command{g77}.
|
|
|
|
In particular, while this document is intended to apply to
|
|
the @value{which-g77} version of @command{g77},
|
|
only an official @emph{release} of that version
|
|
is expected to contain documentation that is
|
|
most consistent with the @command{g77} product in that version.
|
|
@end ifset
|
|
|
|
@menu
|
|
* Copying:: GNU General Public License says
|
|
how you can copy and share GNU Fortran.
|
|
* GNU Free Documentation License::
|
|
How you can copy and share this manual.
|
|
* Contributors:: People who have contributed to GNU Fortran.
|
|
* Funding:: How to help assure continued work for free software.
|
|
* Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
|
|
@ifset USING
|
|
* Getting Started:: Finding your way around this manual.
|
|
* What is GNU Fortran?:: How @command{g77} fits into the universe.
|
|
* G77 and GCC:: You can compile Fortran, C, or other programs.
|
|
* Invoking G77:: Command options supported by @command{g77}.
|
|
* News:: News about recent releases of @command{g77}.
|
|
* Changes:: User-visible changes to recent releases of @command{g77}.
|
|
* Language:: The GNU Fortran language.
|
|
* Compiler:: The GNU Fortran compiler.
|
|
* Other Dialects:: Dialects of Fortran supported by @command{g77}.
|
|
* Other Compilers:: Fortran compilers other than @command{g77}.
|
|
* Other Languages:: Languages other than Fortran.
|
|
* Debugging and Interfacing:: How @command{g77} generates code.
|
|
* Collected Fortran Wisdom:: How to avoid Trouble.
|
|
* Trouble:: If you have trouble with GNU Fortran.
|
|
* Open Questions:: Things we'd like to know.
|
|
* Bugs:: How, why, and where to report bugs.
|
|
* Service:: How to find suppliers of support for GNU Fortran.
|
|
@end ifset
|
|
@ifset INTERNALS
|
|
* Adding Options:: Guidance on teaching @command{g77} about new options.
|
|
* Projects:: Projects for @command{g77} internals hackers.
|
|
* Front End:: Design and implementation of the @command{g77} front end.
|
|
@end ifset
|
|
|
|
* M: Diagnostics. Diagnostics produced by @command{g77}.
|
|
|
|
* Index:: Index of concepts and symbol names.
|
|
@end menu
|
|
@c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
|
|
|
|
@include gpl.texi
|
|
|
|
@include fdl.texi
|
|
|
|
@node Contributors
|
|
@unnumbered Contributors to GNU Fortran
|
|
@cindex contributors
|
|
@cindex credits
|
|
|
|
In addition to James Craig Burley, who wrote the front end,
|
|
many people have helped create and improve GNU Fortran.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The packaging and compiler portions of GNU Fortran are based largely
|
|
on the GNU CC compiler.
|
|
@xref{Contributors,,Contributors to GCC,gcc,Using the GNU Compiler
|
|
Collection (GCC)},
|
|
for more information.
|
|
|
|
@item
|
|
The run-time library used by GNU Fortran is a repackaged version
|
|
of the @code{libf2c} library (combined from the @code{libF77} and
|
|
@code{libI77} libraries) provided as part of @command{f2c}, available for
|
|
free from @code{netlib} sites on the Internet.
|
|
|
|
@item
|
|
Cygnus Support and The Free Software Foundation contributed
|
|
significant money and/or equipment to Craig's efforts.
|
|
|
|
@item
|
|
The following individuals served as alpha testers prior to @command{g77}'s
|
|
public release. This work consisted of testing, researching, sometimes
|
|
debugging, and occasionally providing small amounts of code and fixes
|
|
for @command{g77}, plus offering plenty of helpful advice to Craig:
|
|
|
|
@itemize @w{}
|
|
@item
|
|
Jonathan Corbet
|
|
@item
|
|
Dr.@: Mark Fernyhough
|
|
@item
|
|
Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
|
|
@item
|
|
Kate Hedstrom
|
|
@item
|
|
Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
|
|
@item
|
|
Dr.@: A. O. V. Le Blanc
|
|
@item
|
|
Dave Love
|
|
@item
|
|
Rick Lutowski
|
|
@item
|
|
Toon Moene
|
|
@item
|
|
Rick Niles
|
|
@item
|
|
Derk Reefman
|
|
@item
|
|
Wayne K. Schroll
|
|
@item
|
|
Bill Thorson
|
|
@item
|
|
Pedro A. M. Vazquez
|
|
@item
|
|
Ian Watson
|
|
@end itemize
|
|
|
|
@item
|
|
Dave Love (@email{d.love@@dl.ac.uk})
|
|
wrote the libU77 part of the run-time library.
|
|
|
|
@item
|
|
Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
|
|
provided the patch to add rudimentary support
|
|
for @code{INTEGER*1}, @code{INTEGER*2}, and
|
|
@code{LOGICAL*1}.
|
|
This inspired Craig to add further support,
|
|
even though the resulting support
|
|
would still be incomplete.
|
|
|
|
@item
|
|
David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
|
|
and encouraged Craig to rewrite the documentation in texinfo
|
|
format by contributing a first pass at a translation of the
|
|
old @file{g77-0.5.16/f/DOC} file.
|
|
|
|
@item
|
|
Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
|
|
some analysis of generated code as part of an overall project
|
|
to improve @command{g77} code generation to at least be as good
|
|
as @command{f2c} used in conjunction with @command{gcc}.
|
|
So far, this has resulted in the three, somewhat
|
|
experimental, options added by @command{g77} to the @command{gcc}
|
|
compiler and its back end.
|
|
|
|
(These, in turn, had made their way into the @code{egcs}
|
|
version of the compiler, and do not exist in @command{gcc}
|
|
version 2.8 or versions of @command{g77} based on that version
|
|
of @command{gcc}.)
|
|
|
|
@item
|
|
John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
|
|
|
|
@item
|
|
Thanks to Mary Cortani and the staff at Craftwork Solutions
|
|
(@email{support@@craftwork.com}) for all of their support.
|
|
|
|
@item
|
|
Many other individuals have helped debug, test, and improve @command{g77}
|
|
over the past several years, and undoubtedly more people
|
|
will be doing so in the future.
|
|
If you have done so, and would like
|
|
to see your name listed in the above list, please ask!
|
|
The default is that people wish to remain anonymous.
|
|
@end itemize
|
|
|
|
@include funding.texi
|
|
|
|
@node Funding GNU Fortran
|
|
@chapter Funding GNU Fortran
|
|
@cindex funding improvements
|
|
@cindex improvements, funding
|
|
|
|
James Craig Burley (@email{@value{email-burley}}), the original author
|
|
of @command{g77}, stopped working on it in September 1999
|
|
(He has a web page at @uref{@value{www-burley}}.)
|
|
|
|
GNU Fortran is currently maintained by Toon Moene
|
|
(@email{toon@@moene.indiv.nluug.nl}), with the help of countless other
|
|
volunteers.
|
|
|
|
As with other GNU software, funding is important because it can pay for
|
|
needed equipment, personnel, and so on.
|
|
|
|
@cindex FSF, funding the
|
|
@cindex funding the FSF
|
|
The FSF provides information on the best way to fund ongoing
|
|
development of GNU software (such as GNU Fortran) in documents
|
|
such as the ``GNUS Bulletin''.
|
|
Email @email{gnu@@gnu.org} for information on funding the FSF.
|
|
|
|
Another important way to support work on GNU Fortran is to volunteer
|
|
to help out.
|
|
|
|
Email @email{@value{email-general}} to volunteer for this work.
|
|
|
|
However, we strongly expect that there will never be a version 0.6
|
|
of @command{g77}. Work on this compiler has stopped as of the release
|
|
of GCC 3.1, except for bug fixing. @command{g77} will be succeeded by
|
|
@command{g95} - see @uref{http://g95.sourceforge.net}.
|
|
|
|
@xref{Funding,,Funding Free Software}, for more information.
|
|
|
|
@node Getting Started
|
|
@chapter Getting Started
|
|
@cindex getting started
|
|
@cindex new users
|
|
@cindex newbies
|
|
@cindex beginners
|
|
|
|
If you don't need help getting started reading the portions
|
|
of this manual that are most important to you, you should skip
|
|
this portion of the manual.
|
|
|
|
If you are new to compilers, especially Fortran compilers, or
|
|
new to how compilers are structured under UNIX and UNIX-like
|
|
systems, you'll want to see @ref{What is GNU Fortran?}.
|
|
|
|
If you are new to GNU compilers, or have used only one GNU
|
|
compiler in the past and not had to delve into how it lets
|
|
you manage various versions and configurations of @command{gcc},
|
|
you should see @ref{G77 and GCC}.
|
|
|
|
Everyone except experienced @command{g77} users should
|
|
see @ref{Invoking G77}.
|
|
|
|
If you're acquainted with previous versions of @command{g77},
|
|
you should see @ref{News,,News About GNU Fortran}.
|
|
Further, if you've actually used previous versions of @command{g77},
|
|
especially if you've written or modified Fortran code to
|
|
be compiled by previous versions of @command{g77}, you
|
|
should see @ref{Changes}.
|
|
|
|
If you intend to write or otherwise compile code that is
|
|
not already strictly conforming ANSI FORTRAN 77---and this
|
|
is probably everyone---you should see @ref{Language}.
|
|
|
|
If you run into trouble getting Fortran code to compile,
|
|
link, run, or work properly, you might find answers
|
|
if you see @ref{Debugging and Interfacing},
|
|
see @ref{Collected Fortran Wisdom},
|
|
and see @ref{Trouble}.
|
|
You might also find that the problems you are encountering
|
|
are bugs in @command{g77}---see @ref{Bugs}, for information on
|
|
reporting them, after reading the other material.
|
|
|
|
If you need further help with @command{g77}, or with
|
|
freely redistributable software in general,
|
|
see @ref{Service}.
|
|
|
|
If you would like to help the @command{g77} project,
|
|
see @ref{Funding GNU Fortran}, for information on
|
|
helping financially, and see @ref{Projects}, for information
|
|
on helping in other ways.
|
|
|
|
If you're generally curious about the future of
|
|
@command{g77}, see @ref{Projects}.
|
|
If you're curious about its past,
|
|
see @ref{Contributors},
|
|
and see @ref{Funding GNU Fortran}.
|
|
|
|
To see a few of the questions maintainers of @command{g77} have,
|
|
and that you might be able to answer,
|
|
see @ref{Open Questions}.
|
|
|
|
@ifset USING
|
|
@node What is GNU Fortran?
|
|
@chapter What is GNU Fortran?
|
|
@cindex concepts, basic
|
|
@cindex basic concepts
|
|
|
|
GNU Fortran, or @command{g77}, is designed initially as a free replacement
|
|
for, or alternative to, the UNIX @command{f77} command.
|
|
(Similarly, @command{gcc} is designed as a replacement
|
|
for the UNIX @command{cc} command.)
|
|
|
|
@command{g77} also is designed to fit in well with the other
|
|
fine GNU compilers and tools.
|
|
|
|
Sometimes these design goals conflict---in such cases, resolution
|
|
often is made in favor of fitting in well with Project GNU.
|
|
These cases are usually identified in the appropriate
|
|
sections of this manual.
|
|
|
|
@cindex compilers
|
|
As compilers, @command{g77}, @command{gcc}, and @command{f77}
|
|
share the following characteristics:
|
|
|
|
@itemize @bullet
|
|
@cindex source code
|
|
@cindex file, source
|
|
@cindex code, source
|
|
@cindex source file
|
|
@item
|
|
They read a user's program, stored in a file and
|
|
containing instructions written in the appropriate
|
|
language (Fortran, C, and so on).
|
|
This file contains @dfn{source code}.
|
|
|
|
@cindex translation of user programs
|
|
@cindex machine code
|
|
@cindex code, machine
|
|
@cindex mistakes
|
|
@item
|
|
They translate the user's program into instructions
|
|
a computer can carry out more quickly than it takes
|
|
to translate the instructions in the first place.
|
|
These instructions are called @dfn{machine code}---code
|
|
designed to be efficiently translated and processed
|
|
by a machine such as a computer.
|
|
Humans usually aren't as good writing machine code
|
|
as they are at writing Fortran or C, because
|
|
it is easy to make tiny mistakes writing machine code.
|
|
When writing Fortran or C, it is easy
|
|
to make big mistakes.
|
|
|
|
@cindex debugger
|
|
@cindex bugs, finding
|
|
@cindex @command{gdb}, command
|
|
@cindex commands, @command{gdb}
|
|
@item
|
|
They provide information in the generated machine code
|
|
that can make it easier to find bugs in the program
|
|
(using a debugging tool, called a @dfn{debugger},
|
|
such as @command{gdb}).
|
|
|
|
@cindex libraries
|
|
@cindex linking
|
|
@cindex @command{ld} command
|
|
@cindex commands, @command{ld}
|
|
@item
|
|
They locate and gather machine code already generated
|
|
to perform actions requested by statements in
|
|
the user's program.
|
|
This machine code is organized
|
|
into @dfn{libraries} and is located and gathered
|
|
during the @dfn{link} phase of the compilation
|
|
process.
|
|
(Linking often is thought of as a separate
|
|
step, because it can be directly invoked via the
|
|
@command{ld} command.
|
|
However, the @command{g77} and @command{gcc}
|
|
commands, as with most compiler commands, automatically
|
|
perform the linking step by calling on @command{ld}
|
|
directly, unless asked to not do so by the user.)
|
|
|
|
@cindex language, incorrect use of
|
|
@cindex incorrect use of language
|
|
@item
|
|
They attempt to diagnose cases where the user's
|
|
program contains incorrect usages of the language.
|
|
The @dfn{diagnostics} produced by the compiler
|
|
indicate the problem and the location in the user's
|
|
source file where the problem was first noticed.
|
|
The user can use this information to locate and
|
|
fix the problem.
|
|
@cindex diagnostics, incorrect
|
|
@cindex incorrect diagnostics
|
|
@cindex error messages, incorrect
|
|
@cindex incorrect error messages
|
|
(Sometimes an incorrect usage
|
|
of the language leads to a situation where the
|
|
compiler can no longer make any sense of what
|
|
follows---while a human might be able to---and
|
|
thus ends up complaining about many ``problems''
|
|
it encounters that, in fact, stem from just one
|
|
problem, usually the first one reported.)
|
|
|
|
@cindex warnings
|
|
@cindex questionable instructions
|
|
@item
|
|
They attempt to diagnose cases where the user's
|
|
program contains a correct usage of the language,
|
|
but instructs the computer to do something questionable.
|
|
These diagnostics often are in the form of @dfn{warnings},
|
|
instead of the @dfn{errors} that indicate incorrect
|
|
usage of the language.
|
|
@end itemize
|
|
|
|
How these actions are performed is generally under the
|
|
control of the user.
|
|
Using command-line options, the user can specify
|
|
how persnickety the compiler is to be regarding
|
|
the program (whether to diagnose questionable usage
|
|
of the language), how much time to spend making
|
|
the generated machine code run faster, and so on.
|
|
|
|
@cindex components of @command{g77}
|
|
@cindex @command{g77}, components of
|
|
@command{g77} consists of several components:
|
|
|
|
@cindex @command{gcc}, command
|
|
@cindex commands, @command{gcc}
|
|
@itemize @bullet
|
|
@item
|
|
A modified version of the @command{gcc} command, which also might be
|
|
installed as the system's @command{cc} command.
|
|
(In many cases, @command{cc} refers to the
|
|
system's ``native'' C compiler, which
|
|
might be a non-GNU compiler, or an older version
|
|
of @command{gcc} considered more stable or that is
|
|
used to build the operating system kernel.)
|
|
|
|
@cindex @command{g77}, command
|
|
@cindex commands, @command{g77}
|
|
@item
|
|
The @command{g77} command itself, which also might be installed as the
|
|
system's @command{f77} command.
|
|
|
|
@cindex libg2c library
|
|
@cindex libf2c library
|
|
@cindex libraries, libf2c
|
|
@cindex libraries, libg2c
|
|
@cindex run-time, library
|
|
@item
|
|
The @code{libg2c} run-time library.
|
|
This library contains the machine code needed to support
|
|
capabilities of the Fortran language that are not directly
|
|
provided by the machine code generated by the @command{g77}
|
|
compilation phase.
|
|
|
|
@code{libg2c} is just the unique name @command{g77} gives
|
|
to its version of @code{libf2c} to distinguish it from
|
|
any copy of @code{libf2c} installed from @command{f2c}
|
|
(or versions of @command{g77} that built @code{libf2c} under
|
|
that same name)
|
|
on the system.
|
|
|
|
The maintainer of @code{libf2c} currently is
|
|
@email{dmg@@bell-labs.com}.
|
|
|
|
@cindex @code{f771}, program
|
|
@cindex programs, @code{f771}
|
|
@cindex assembler
|
|
@cindex @command{as} command
|
|
@cindex commands, @command{as}
|
|
@cindex assembly code
|
|
@cindex code, assembly
|
|
@item
|
|
The compiler itself, internally named @code{f771}.
|
|
|
|
Note that @code{f771} does not generate machine code directly---it
|
|
generates @dfn{assembly code} that is a more readable form
|
|
of machine code, leaving the conversion to actual machine code
|
|
to an @dfn{assembler}, usually named @command{as}.
|
|
@end itemize
|
|
|
|
@command{gcc} is often thought of as ``the C compiler'' only,
|
|
but it does more than that.
|
|
Based on command-line options and the names given for files
|
|
on the command line, @command{gcc} determines which actions to perform, including
|
|
preprocessing, compiling (in a variety of possible languages), assembling,
|
|
and linking.
|
|
|
|
@cindex driver, gcc command as
|
|
@cindex @command{gcc}, command as driver
|
|
@cindex executable file
|
|
@cindex files, executable
|
|
@cindex cc1 program
|
|
@cindex programs, cc1
|
|
@cindex preprocessor
|
|
@cindex cpp program
|
|
@cindex programs, cpp
|
|
For example, the command @samp{gcc foo.c} @dfn{drives} the file
|
|
@file{foo.c} through the preprocessor @command{cpp}, then
|
|
the C compiler (internally named
|
|
@code{cc1}), then the assembler (usually @command{as}), then the linker
|
|
(@command{ld}), producing an executable program named @file{a.out} (on
|
|
UNIX systems).
|
|
|
|
@cindex cc1plus program
|
|
@cindex programs, cc1plus
|
|
As another example, the command @samp{gcc foo.cc} would do much the same as
|
|
@samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
|
|
@command{gcc} would use the C++ compiler (named @code{cc1plus}).
|
|
|
|
@cindex @code{f771}, program
|
|
@cindex programs, @code{f771}
|
|
In a GNU Fortran installation, @command{gcc} recognizes Fortran source
|
|
files by name just like it does C and C++ source files.
|
|
It knows to use the Fortran compiler named @code{f771}, instead of
|
|
@code{cc1} or @code{cc1plus}, to compile Fortran files.
|
|
|
|
@cindex @command{gcc}, not recognizing Fortran source
|
|
@cindex unrecognized file format
|
|
@cindex file format not recognized
|
|
Non-Fortran-related operation of @command{gcc} is generally
|
|
unaffected by installing the GNU Fortran version of @command{gcc}.
|
|
However, without the installed version of @command{gcc} being the
|
|
GNU Fortran version, @command{gcc} will not be able to compile
|
|
and link Fortran programs---and since @command{g77} uses @command{gcc}
|
|
to do most of the actual work, neither will @command{g77}!
|
|
|
|
@cindex @command{g77}, command
|
|
@cindex commands, @command{g77}
|
|
The @command{g77} command is essentially just a front-end for
|
|
the @command{gcc} command.
|
|
Fortran users will normally use @command{g77} instead of @command{gcc},
|
|
because @command{g77}
|
|
knows how to specify the libraries needed to link with Fortran programs
|
|
(@code{libg2c} and @code{lm}).
|
|
@command{g77} can still compile and link programs and
|
|
source files written in other languages, just like @command{gcc}.
|
|
|
|
@cindex printing version information
|
|
@cindex version information, printing
|
|
The command @samp{g77 -v} is a quick
|
|
way to display lots of version information for the various programs
|
|
used to compile a typical preprocessed Fortran source file---this
|
|
produces much more output than @samp{gcc -v} currently does.
|
|
(If it produces an error message near the end of the output---diagnostics
|
|
from the linker, usually @command{ld}---you might
|
|
have an out-of-date @code{libf2c} that improperly handles
|
|
complex arithmetic.)
|
|
In the output of this command, the line beginning @samp{GNU Fortran Front
|
|
End} identifies the version number of GNU Fortran; immediately
|
|
preceding that line is a line identifying the version of @command{gcc}
|
|
with which that version of @command{g77} was built.
|
|
|
|
@cindex libf2c library
|
|
@cindex libraries, libf2c
|
|
The @code{libf2c} library is distributed with GNU Fortran for
|
|
the convenience of its users, but is not part of GNU Fortran.
|
|
It contains the procedures
|
|
needed by Fortran programs while they are running.
|
|
|
|
@cindex in-line code
|
|
@cindex code, in-line
|
|
For example, while code generated by @command{g77} is likely
|
|
to do additions, subtractions, and multiplications @dfn{in line}---in
|
|
the actual compiled code---it is not likely to do trigonometric
|
|
functions this way.
|
|
|
|
Instead, operations like trigonometric
|
|
functions are compiled by the @code{f771} compiler
|
|
(invoked by @command{g77} when compiling Fortran code) into machine
|
|
code that, when run, calls on functions in @code{libg2c}, so
|
|
@code{libg2c} must be linked with almost every useful program
|
|
having any component compiled by GNU Fortran.
|
|
(As mentioned above, the @command{g77} command takes
|
|
care of all this for you.)
|
|
|
|
The @code{f771} program represents most of what is unique to GNU Fortran.
|
|
While much of the @code{libg2c} component comes from
|
|
the @code{libf2c} component of @command{f2c},
|
|
a free Fortran-to-C converter distributed by Bellcore (AT&T),
|
|
plus @code{libU77}, provided by Dave Love,
|
|
and the @command{g77} command is just a small front-end to @command{gcc},
|
|
@code{f771} is a combination of two rather
|
|
large chunks of code.
|
|
|
|
@cindex GNU Back End (GBE)
|
|
@cindex GBE
|
|
@cindex @command{gcc}, back end
|
|
@cindex back end, gcc
|
|
@cindex code generator
|
|
One chunk is the so-called @dfn{GNU Back End}, or GBE,
|
|
which knows how to generate fast code for a wide variety of processors.
|
|
The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
|
|
@code{cc1plus}, and @code{f771}, plus others.
|
|
Often the GBE is referred to as the ``gcc back end'' or
|
|
even just ``gcc''---in this manual, the term GBE is used
|
|
whenever the distinction is important.
|
|
|
|
@cindex GNU Fortran Front End (FFE)
|
|
@cindex FFE
|
|
@cindex @command{g77}, front end
|
|
@cindex front end, @command{g77}
|
|
The other chunk of @code{f771} is the
|
|
majority of what is unique about GNU Fortran---the code that knows how
|
|
to interpret Fortran programs to determine what they are intending to
|
|
do, and then communicate that knowledge to the GBE for actual compilation
|
|
of those programs.
|
|
This chunk is called the @dfn{Fortran Front End} (FFE).
|
|
The @code{cc1} and @code{cc1plus} programs have their own front ends,
|
|
for the C and C++ languages, respectively.
|
|
These fronts ends are responsible for diagnosing
|
|
incorrect usage of their respective languages by the
|
|
programs the process, and are responsible for most of
|
|
the warnings about questionable constructs as well.
|
|
(The GBE handles producing some warnings, like those
|
|
concerning possible references to undefined variables.)
|
|
|
|
Because so much is shared among the compilers for various languages,
|
|
much of the behavior and many of the user-selectable options for these
|
|
compilers are similar.
|
|
For example, diagnostics (error messages and
|
|
warnings) are similar in appearance; command-line
|
|
options like @option{-Wall} have generally similar effects; and the quality
|
|
of generated code (in terms of speed and size) is roughly similar
|
|
(since that work is done by the shared GBE).
|
|
|
|
@node G77 and GCC
|
|
@chapter Compile Fortran, C, or Other Programs
|
|
@cindex compiling programs
|
|
@cindex programs, compiling
|
|
|
|
@cindex @command{gcc}, command
|
|
@cindex commands, @command{gcc}
|
|
A GNU Fortran installation includes a modified version of the @command{gcc}
|
|
command.
|
|
|
|
In a non-Fortran installation, @command{gcc} recognizes C, C++,
|
|
and Objective-C source files.
|
|
|
|
In a GNU Fortran installation, @command{gcc} also recognizes Fortran source
|
|
files and accepts Fortran-specific command-line options, plus some
|
|
command-line options that are designed to cater to Fortran users
|
|
but apply to other languages as well.
|
|
|
|
@xref{G++ and GCC,,Compile C; C++; Objective-C; Ada; Fortran;
|
|
or Java,gcc,Using the GNU Compiler Collection (GCC)},
|
|
for information on the way different languages are handled
|
|
by the GNU CC compiler (@command{gcc}).
|
|
|
|
@cindex @command{g77}, command
|
|
@cindex commands, @command{g77}
|
|
Also provided as part of GNU Fortran is the @command{g77} command.
|
|
The @command{g77} command is designed to make compiling and linking Fortran
|
|
programs somewhat easier than when using the @command{gcc} command for
|
|
these tasks.
|
|
It does this by analyzing the command line somewhat and changing it
|
|
appropriately before submitting it to the @command{gcc} command.
|
|
|
|
@cindex -v option
|
|
@cindex @command{g77} options, -v
|
|
@cindex options, -v
|
|
Use the @option{-v} option with @command{g77}
|
|
to see what is going on---the first line of output is the invocation
|
|
of the @command{gcc} command.
|
|
|
|
@include invoke.texi
|
|
|
|
@include news.texi
|
|
|
|
@set USERVISONLY
|
|
@include news.texi
|
|
@clear USERVISONLY
|
|
|
|
@node Language
|
|
@chapter The GNU Fortran Language
|
|
|
|
@cindex standard, ANSI FORTRAN 77
|
|
@cindex ANSI FORTRAN 77 standard
|
|
@cindex reference works
|
|
GNU Fortran supports a variety of extensions to, and dialects
|
|
of, the Fortran language.
|
|
Its primary base is the ANSI FORTRAN 77 standard, currently available on
|
|
the network at
|
|
@uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
|
|
or as monolithic text at
|
|
@uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
|
|
It offers some extensions that are popular among users
|
|
of UNIX @command{f77} and @command{f2c} compilers, some that
|
|
are popular among users of other compilers (such as Digital
|
|
products), some that are popular among users of the
|
|
newer Fortran 90 standard, and some that are introduced
|
|
by GNU Fortran.
|
|
|
|
@cindex textbooks
|
|
(If you need a text on Fortran,
|
|
a few freely available electronic references have pointers from
|
|
@uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
|
|
net project', @cite{User Notes on Fortran Programming} at
|
|
@uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
|
|
material might not apply specifically to @command{g77}.)
|
|
|
|
Part of what defines a particular implementation of a Fortran
|
|
system, such as @command{g77}, is the particular characteristics
|
|
of how it supports types, constants, and so on.
|
|
Much of this is left up to the implementation by the various
|
|
Fortran standards and accepted practice in the industry.
|
|
|
|
The GNU Fortran @emph{language} is described below.
|
|
Much of the material is organized along the same lines
|
|
as the ANSI FORTRAN 77 standard itself.
|
|
|
|
@xref{Other Dialects}, for information on features @command{g77} supports
|
|
that are not part of the GNU Fortran language.
|
|
|
|
@emph{Note}: This portion of the documentation definitely needs a lot
|
|
of work!
|
|
|
|
@menu
|
|
Relationship to the ANSI FORTRAN 77 standard:
|
|
* Direction of Language Development:: Where GNU Fortran is headed.
|
|
* Standard Support:: Degree of support for the standard.
|
|
|
|
Extensions to the ANSI FORTRAN 77 standard:
|
|
* Conformance::
|
|
* Notation Used::
|
|
* Terms and Concepts::
|
|
* Characters Lines Sequence::
|
|
* Data Types and Constants::
|
|
* Expressions::
|
|
* Specification Statements::
|
|
* Control Statements::
|
|
* Functions and Subroutines::
|
|
* Scope and Classes of Names::
|
|
* I/O::
|
|
* Fortran 90 Features::
|
|
@end menu
|
|
|
|
@node Direction of Language Development
|
|
@section Direction of Language Development
|
|
@cindex direction of language development
|
|
@cindex features, language
|
|
@cindex language, features
|
|
|
|
The purpose of the following description of the GNU Fortran
|
|
language is to promote wide portability of GNU Fortran programs.
|
|
|
|
GNU Fortran is an evolving language, due to the
|
|
fact that @command{g77} itself is in beta test.
|
|
Some current features of the language might later
|
|
be redefined as dialects of Fortran supported by @command{g77}
|
|
when better ways to express these features are added to @command{g77},
|
|
for example.
|
|
Such features would still be supported by
|
|
@command{g77}, but would be available only when
|
|
one or more command-line options were used.
|
|
|
|
The GNU Fortran @emph{language} is distinct from the
|
|
GNU Fortran @emph{compilation system} (@command{g77}).
|
|
|
|
For example, @command{g77} supports various dialects of
|
|
Fortran---in a sense, these are languages other than
|
|
GNU Fortran---though its primary
|
|
purpose is to support the GNU Fortran language, which also is
|
|
described in its documentation and by its implementation.
|
|
|
|
On the other hand, non-GNU compilers might offer
|
|
support for the GNU Fortran language, and are encouraged
|
|
to do so.
|
|
|
|
Currently, the GNU Fortran language is a fairly fuzzy object.
|
|
It represents something of a cross between what @command{g77} accepts
|
|
when compiling using the prevailing defaults and what this
|
|
document describes as being part of the language.
|
|
|
|
Future versions of @command{g77} are expected to clarify the
|
|
definition of the language in the documentation.
|
|
Often, this will mean adding new features to the language, in the form
|
|
of both new documentation and new support in @command{g77}.
|
|
However, it might occasionally mean removing a feature
|
|
from the language itself to ``dialect'' status.
|
|
In such a case, the documentation would be adjusted
|
|
to reflect the change, and @command{g77} itself would likely be changed
|
|
to require one or more command-line options to continue supporting
|
|
the feature.
|
|
|
|
The development of the GNU Fortran language is intended to strike
|
|
a balance between:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Serving as a mostly-upwards-compatible language from the
|
|
de facto UNIX Fortran dialect as supported by @command{f77}.
|
|
|
|
@item
|
|
Offering new, well-designed language features.
|
|
Attributes of such features include
|
|
not making existing code any harder to read
|
|
(for those who might be unaware that the new
|
|
features are not in use) and
|
|
not making state-of-the-art
|
|
compilers take longer to issue diagnostics,
|
|
among others.
|
|
|
|
@item
|
|
Supporting existing, well-written code without gratuitously
|
|
rejecting non-standard constructs, regardless of the origin
|
|
of the code (its dialect).
|
|
|
|
@item
|
|
Offering default behavior and command-line options to reduce
|
|
and, where reasonable, eliminate the need for programmers to make
|
|
any modifications to code that already works in existing
|
|
production environments.
|
|
|
|
@item
|
|
Diagnosing constructs that have different meanings in different
|
|
systems, languages, and dialects, while offering clear,
|
|
less ambiguous ways to express each of the different meanings
|
|
so programmers can change their code appropriately.
|
|
@end itemize
|
|
|
|
One of the biggest practical challenges for the developers of the
|
|
GNU Fortran language is meeting the sometimes contradictory demands
|
|
of the above items.
|
|
|
|
For example, a feature might be widely used in one popular environment,
|
|
but the exact same code that utilizes that feature might not work
|
|
as expected---perhaps it might mean something entirely different---in
|
|
another popular environment.
|
|
|
|
Traditionally, Fortran compilers---even portable ones---have solved this
|
|
problem by simply offering the appropriate feature to users of
|
|
the respective systems.
|
|
This approach treats users of various Fortran systems and dialects
|
|
as remote ``islands'', or camps, of programmers, and assume that these
|
|
camps rarely come into contact with each other (or,
|
|
especially, with each other's code).
|
|
|
|
Project GNU takes a radically different approach to software and language
|
|
design, in that it assumes that users of GNU software do not necessarily
|
|
care what kind of underlying system they are using, regardless
|
|
of whether they are using software (at the user-interface
|
|
level) or writing it (for example, writing Fortran or C code).
|
|
|
|
As such, GNU users rarely need consider just what kind of underlying
|
|
hardware (or, in many cases, operating system) they are using at any
|
|
particular time.
|
|
They can use and write software designed for a general-purpose,
|
|
widely portable, heterogenous environment---the GNU environment.
|
|
|
|
In line with this philosophy, GNU Fortran must evolve into a product
|
|
that is widely ported and portable not only in the sense that it can
|
|
be successfully built, installed, and run by users, but in the larger
|
|
sense that its users can use it in the same way, and expect largely the
|
|
same behaviors from it, regardless of the kind of system they are using
|
|
at any particular time.
|
|
|
|
This approach constrains the solutions @command{g77} can use to resolve
|
|
conflicts between various camps of Fortran users.
|
|
If these two camps disagree about what a particular construct should
|
|
mean, @command{g77} cannot simply be changed to treat that particular construct as
|
|
having one meaning without comment (such as a warning), lest the users
|
|
expecting it to have the other meaning are unpleasantly surprised that
|
|
their code misbehaves when executed.
|
|
|
|
The use of the ASCII backslash character in character constants is
|
|
an excellent (and still somewhat unresolved) example of this kind of
|
|
controversy.
|
|
@xref{Backslash in Constants}.
|
|
Other examples are likely to arise in the future, as @command{g77} developers
|
|
strive to improve its ability to accept an ever-wider variety of existing
|
|
Fortran code without requiring significant modifications to said code.
|
|
|
|
Development of GNU Fortran is further constrained by the desire
|
|
to avoid requiring programmers to change their code.
|
|
This is important because it allows programmers, administrators,
|
|
and others to more faithfully evaluate and validate @command{g77}
|
|
(as an overall product and as new versions are distributed)
|
|
without having to support multiple versions of their programs
|
|
so that they continue to work the same way on their existing
|
|
systems (non-GNU perhaps, but possibly also earlier versions
|
|
of @command{g77}).
|
|
|
|
@node Standard Support
|
|
@section ANSI FORTRAN 77 Standard Support
|
|
@cindex ANSI FORTRAN 77 support
|
|
@cindex standard, support for
|
|
@cindex support, FORTRAN 77
|
|
@cindex compatibility, FORTRAN 77
|
|
@cindex FORTRAN 77 compatibility
|
|
|
|
GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
|
|
In summary, the only ANSI FORTRAN 77 features @command{g77} doesn't
|
|
support are those that are probably rarely used in actual code,
|
|
some of which are explicitly disallowed by the Fortran 90 standard.
|
|
|
|
@menu
|
|
* No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
|
|
* No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
|
|
* No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
|
|
* No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
|
|
@end menu
|
|
|
|
@node No Passing External Assumed-length
|
|
@subsection No Passing External Assumed-length
|
|
|
|
@command{g77} disallows passing of an external procedure
|
|
as an actual argument if the procedure's
|
|
type is declared @code{CHARACTER*(*)}. For example:
|
|
|
|
@example
|
|
CHARACTER*(*) CFUNC
|
|
EXTERNAL CFUNC
|
|
CALL FOO(CFUNC)
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
It isn't clear whether the standard considers this conforming.
|
|
|
|
@node No Passing Dummy Assumed-length
|
|
@subsection No Passing Dummy Assumed-length
|
|
|
|
@command{g77} disallows passing of a dummy procedure
|
|
as an actual argument if the procedure's
|
|
type is declared @code{CHARACTER*(*)}.
|
|
|
|
@example
|
|
SUBROUTINE BAR(CFUNC)
|
|
CHARACTER*(*) CFUNC
|
|
EXTERNAL CFUNC
|
|
CALL FOO(CFUNC)
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
It isn't clear whether the standard considers this conforming.
|
|
|
|
@node No Pathological Implied-DO
|
|
@subsection No Pathological Implied-DO
|
|
|
|
The @code{DO} variable for an implied-@code{DO} construct in a
|
|
@code{DATA} statement may not be used as the @code{DO} variable
|
|
for an outer implied-@code{DO} construct. For example, this
|
|
fragment is disallowed by @command{g77}:
|
|
|
|
@smallexample
|
|
DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
|
|
@end smallexample
|
|
|
|
@noindent
|
|
This also is disallowed by Fortran 90, as it offers no additional
|
|
capabilities and would have a variety of possible meanings.
|
|
|
|
Note that it is @emph{very} unlikely that any production Fortran code
|
|
tries to use this unsupported construct.
|
|
|
|
@node No Useless Implied-DO
|
|
@subsection No Useless Implied-DO
|
|
|
|
An array element initializer in an implied-@code{DO} construct in a
|
|
@code{DATA} statement must contain at least one reference to the @code{DO}
|
|
variables of each outer implied-@code{DO} construct. For example,
|
|
this fragment is disallowed by @command{g77}:
|
|
|
|
@smallexample
|
|
DATA (A, I= 1, 1) /1./
|
|
@end smallexample
|
|
|
|
@noindent
|
|
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
|
|
requirements offer no additional capabilities.
|
|
However, @command{g77} doesn't necessarily diagnose all cases
|
|
where this requirement is not met.
|
|
|
|
Note that it is @emph{very} unlikely that any production Fortran code
|
|
tries to use this unsupported construct.
|
|
|
|
@node Conformance
|
|
@section Conformance
|
|
|
|
(The following information augments or overrides the information in
|
|
Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 1 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
The definition of the GNU Fortran language is akin to that of
|
|
the ANSI FORTRAN 77 language in that it does not generally require
|
|
conforming implementations to diagnose cases where programs do
|
|
not conform to the language.
|
|
|
|
However, @command{g77} as a compiler is being developed in a way that
|
|
is intended to enable it to diagnose such cases in an easy-to-understand
|
|
manner.
|
|
|
|
A program that conforms to the GNU Fortran language should, when
|
|
compiled, linked, and executed using a properly installed @command{g77}
|
|
system, perform as described by the GNU Fortran language definition.
|
|
Reasons for different behavior include, among others:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Use of resources (memory---heap, stack, and so on; disk space; CPU
|
|
time; etc.) exceeds those of the system.
|
|
|
|
@item
|
|
Range and/or precision of calculations required by the program
|
|
exceeds that of the system.
|
|
|
|
@item
|
|
Excessive reliance on behaviors that are system-dependent
|
|
(non-portable Fortran code).
|
|
|
|
@item
|
|
Bugs in the program.
|
|
|
|
@item
|
|
Bug in @command{g77}.
|
|
|
|
@item
|
|
Bugs in the system.
|
|
@end itemize
|
|
|
|
Despite these ``loopholes'', the availability of a clear specification
|
|
of the language of programs submitted to @command{g77}, as this document
|
|
is intended to provide, is considered an important aspect of providing
|
|
a robust, clean, predictable Fortran implementation.
|
|
|
|
The definition of the GNU Fortran language, while having no special
|
|
legal status, can therefore be viewed as a sort of contract, or agreement.
|
|
This agreement says, in essence, ``if you write a program in this language,
|
|
and run it in an environment (such as a @command{g77} system) that supports
|
|
this language, the program should behave in a largely predictable way''.
|
|
|
|
@node Notation Used
|
|
@section Notation Used in This Chapter
|
|
|
|
(The following information augments or overrides the information in
|
|
Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 1 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
|
|
and ``must not'' and ``may not'' denote prohibition.
|
|
Terms such as ``might'', ``should'', and ``can'' generally add little or
|
|
nothing in the way of weight to the GNU Fortran language itself,
|
|
but are used to explain or illustrate the language.
|
|
|
|
For example:
|
|
|
|
@display
|
|
``The @code{FROBNITZ} statement must precede all executable
|
|
statements in a program unit, and may not specify any dummy
|
|
arguments. It may specify local or common variables and arrays.
|
|
Its use should be limited to portions of the program designed to
|
|
be non-portable and system-specific, because it might cause the
|
|
containing program unit to behave quite differently on different
|
|
systems.''
|
|
@end display
|
|
|
|
Insofar as the GNU Fortran language is specified,
|
|
the requirements and permissions denoted by the above sample statement
|
|
are limited to the placement of the statement and the kinds of
|
|
things it may specify.
|
|
The rest of the statement---the content regarding non-portable portions
|
|
of the program and the differing behavior of program units containing
|
|
the @code{FROBNITZ} statement---does not pertain the GNU Fortran
|
|
language itself.
|
|
That content offers advice and warnings about the @code{FROBNITZ}
|
|
statement.
|
|
|
|
@emph{Remember:} The GNU Fortran language definition specifies
|
|
both what constitutes a valid GNU Fortran program and how,
|
|
given such a program, a valid GNU Fortran implementation is
|
|
to interpret that program.
|
|
|
|
It is @emph{not} incumbent upon a valid GNU Fortran implementation
|
|
to behave in any particular way, any consistent way, or any
|
|
predictable way when it is asked to interpret input that is
|
|
@emph{not} a valid GNU Fortran program.
|
|
|
|
Such input is said to have @dfn{undefined} behavior when
|
|
interpreted by a valid GNU Fortran implementation, though
|
|
an implementation may choose to specify behaviors for some
|
|
cases of inputs that are not valid GNU Fortran programs.
|
|
|
|
Other notation used herein is that of the GNU texinfo format,
|
|
which is used to generate printed hardcopy, on-line hypertext
|
|
(Info), and on-line HTML versions, all from a single source
|
|
document.
|
|
This notation is used as follows:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Keywords defined by the GNU Fortran language are shown
|
|
in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
|
|
@code{BLOCK DATA}.
|
|
|
|
Note that, in practice, many Fortran programs are written
|
|
in lowercase---uppercase is used in this manual as a
|
|
means to readily distinguish keywords and sample Fortran-related
|
|
text from the prose in this document.
|
|
|
|
@item
|
|
Portions of actual sample program, input, or output text
|
|
look like this: @samp{Actual program text}.
|
|
|
|
Generally, uppercase is used for all Fortran-specific and
|
|
Fortran-related text, though this does not always include
|
|
literal text within Fortran code.
|
|
|
|
For example: @samp{PRINT *, 'My name is Bob'}.
|
|
|
|
@item
|
|
A metasyntactic variable---that is, a name used in this document
|
|
to serve as a placeholder for whatever text is used by the
|
|
user or programmer---appears as shown in the following example:
|
|
|
|
``The @code{INTEGER @var{ivar}} statement specifies that
|
|
@var{ivar} is a variable or array of type @code{INTEGER}.''
|
|
|
|
In the above example, any valid text may be substituted for
|
|
the metasyntactic variable @var{ivar} to make the statement
|
|
apply to a specific instance, as long as the same text is
|
|
substituted for @emph{both} occurrences of @var{ivar}.
|
|
|
|
@item
|
|
Ellipses (``@dots{}'') are used to indicate further text that
|
|
is either unimportant or expanded upon further, elsewhere.
|
|
|
|
@item
|
|
Names of data types are in the style of Fortran 90, in most
|
|
cases.
|
|
|
|
@xref{Kind Notation}, for information on the relationship
|
|
between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
|
|
and the more traditional, less portably concise nomenclature
|
|
(such as @code{INTEGER*4}).
|
|
@end itemize
|
|
|
|
@node Terms and Concepts
|
|
@section Fortran Terms and Concepts
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 2 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* Syntactic Items::
|
|
* Statements Comments Lines::
|
|
* Scope of Names and Labels::
|
|
@end menu
|
|
|
|
@node Syntactic Items
|
|
@subsection Syntactic Items
|
|
|
|
(Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
@cindex limits, lengths of names
|
|
In GNU Fortran, a symbolic name is at least one character long,
|
|
and has no arbitrary upper limit on length.
|
|
However, names of entities requiring external linkage (such as
|
|
external functions, external subroutines, and @code{COMMON} areas)
|
|
might be restricted to some arbitrary length by the system.
|
|
Such a restriction is no more constrained than that of one
|
|
through six characters.
|
|
|
|
Underscores (@samp{_}) are accepted in symbol names after the first
|
|
character (which must be a letter).
|
|
|
|
@node Statements Comments Lines
|
|
@subsection Statements, Comments, and Lines
|
|
|
|
(Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
@cindex trailing comment
|
|
@cindex comment
|
|
@cindex characters, comment
|
|
@cindex !
|
|
@cindex exclamation point
|
|
@cindex continuation character
|
|
@cindex characters, continuation
|
|
Use of an exclamation point (@samp{!}) to begin a
|
|
trailing comment (a comment that extends to the end of the same
|
|
source line) is permitted under the following conditions:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The exclamation point does not appear in column 6.
|
|
Otherwise, it is treated as an indicator of a continuation
|
|
line.
|
|
|
|
@item
|
|
The exclamation point appears outside a character or Hollerith
|
|
constant.
|
|
Otherwise, the exclamation point is considered part of the
|
|
constant.
|
|
|
|
@item
|
|
The exclamation point appears to the left of any other possible
|
|
trailing comment.
|
|
That is, a trailing comment may contain exclamation points
|
|
in their commentary text.
|
|
@end itemize
|
|
|
|
@cindex ;
|
|
@cindex semicolon
|
|
@cindex statements, separated by semicolon
|
|
Use of a semicolon (@samp{;}) as a statement separator
|
|
is permitted under the following conditions:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The semicolon appears outside a character or Hollerith
|
|
constant.
|
|
Otherwise, the semicolon is considered part of the
|
|
constant.
|
|
|
|
@item
|
|
The semicolon appears to the left of a trailing comment.
|
|
Otherwise, the semicolon is considered part of that
|
|
comment.
|
|
|
|
@item
|
|
Neither a logical @code{IF} statement nor a non-construct
|
|
@code{WHERE} statement (a Fortran 90 feature) may be
|
|
followed (in the same, possibly continued, line) by
|
|
a semicolon used as a statement separator.
|
|
|
|
This restriction avoids the confusion
|
|
that can result when reading a line such as:
|
|
|
|
@smallexample
|
|
IF (VALIDP) CALL FOO; CALL BAR
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Some readers might think the @samp{CALL BAR} is executed
|
|
only if @samp{VALIDP} is @code{.TRUE.}, while others might
|
|
assume its execution is unconditional.
|
|
|
|
(At present, @command{g77} does not diagnose code that
|
|
violates this restriction.)
|
|
@end itemize
|
|
|
|
@node Scope of Names and Labels
|
|
@subsection Scope of Symbolic Names and Statement Labels
|
|
@cindex scope
|
|
|
|
(Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
Included in the list of entities that have a scope of a
|
|
program unit are construct names (a Fortran 90 feature).
|
|
@xref{Construct Names}, for more information.
|
|
|
|
@node Characters Lines Sequence
|
|
@section Characters, Lines, and Execution Sequence
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 3 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* Character Set::
|
|
* Lines::
|
|
* Continuation Line::
|
|
* Statements::
|
|
* Statement Labels::
|
|
* Order::
|
|
* INCLUDE::
|
|
* Cpp-style directives::
|
|
@end menu
|
|
|
|
@node Character Set
|
|
@subsection GNU Fortran Character Set
|
|
@cindex characters
|
|
|
|
(Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
Letters include uppercase letters (the twenty-six characters
|
|
of the English alphabet) and lowercase letters (their lowercase
|
|
equivalent).
|
|
Generally, lowercase letters may be used in place of uppercase
|
|
letters, though in character and Hollerith constants, they
|
|
are distinct.
|
|
|
|
Special characters include:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cindex ;
|
|
@cindex semicolon
|
|
Semicolon (@samp{;})
|
|
|
|
@item
|
|
@cindex !
|
|
@cindex exclamation point
|
|
Exclamation point (@samp{!})
|
|
|
|
@item
|
|
@cindex "
|
|
@cindex double quote
|
|
Double quote (@samp{"})
|
|
|
|
@item
|
|
@cindex \
|
|
@cindex backslash
|
|
Backslash (@samp{\})
|
|
|
|
@item
|
|
@cindex ?
|
|
@cindex question mark
|
|
Question mark (@samp{?})
|
|
|
|
@item
|
|
@cindex #
|
|
@cindex hash mark
|
|
@cindex pound sign
|
|
Hash mark (@samp{#})
|
|
|
|
@item
|
|
@cindex &
|
|
@cindex ampersand
|
|
Ampersand (@samp{&})
|
|
|
|
@item
|
|
@cindex %
|
|
@cindex percent sign
|
|
Percent sign (@samp{%})
|
|
|
|
@item
|
|
@cindex _
|
|
@cindex underscore
|
|
Underscore (@samp{_})
|
|
|
|
@item
|
|
@cindex <
|
|
@cindex open angle
|
|
@cindex left angle
|
|
@cindex open bracket
|
|
@cindex left bracket
|
|
Open angle (@samp{<})
|
|
|
|
@item
|
|
@cindex >
|
|
@cindex close angle
|
|
@cindex right angle
|
|
@cindex close bracket
|
|
@cindex right bracket
|
|
Close angle (@samp{>})
|
|
|
|
@item
|
|
The FORTRAN 77 special characters (@key{SPC}, @samp{=},
|
|
@samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
|
|
@samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
|
|
and @samp{:})
|
|
@end itemize
|
|
|
|
@cindex blank
|
|
@cindex space
|
|
@cindex SPC
|
|
Note that this document refers to @key{SPC} as @dfn{space},
|
|
while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
|
|
|
|
@node Lines
|
|
@subsection Lines
|
|
@cindex lines
|
|
@cindex source file format
|
|
@cindex source format
|
|
@cindex file, source
|
|
@cindex source code
|
|
@cindex code, source
|
|
@cindex fixed form
|
|
@cindex free form
|
|
|
|
(Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
The way a Fortran compiler views source files depends entirely on the
|
|
implementation choices made for the compiler, since those choices
|
|
are explicitly left to the implementation by the published Fortran
|
|
standards.
|
|
|
|
The GNU Fortran language mandates a view applicable to UNIX-like
|
|
text files---files that are made up of an arbitrary number of lines,
|
|
each with an arbitrary number of characters (sometimes called stream-based
|
|
files).
|
|
|
|
This view does not apply to types of files that are specified as
|
|
having a particular number of characters on every single line (sometimes
|
|
referred to as record-based files).
|
|
|
|
Because a ``line in a program unit is a sequence of 72 characters'',
|
|
to quote X3.9-1978, the GNU Fortran language specifies that a
|
|
stream-based text file is translated to GNU Fortran lines as follows:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
A newline in the file is the character that represents the end of
|
|
a line of text to the underlying system.
|
|
For example, on ASCII-based systems, a newline is the @key{NL}
|
|
character, which has ASCII value 10 (decimal).
|
|
|
|
@item
|
|
Each newline in the file serves to end the line of text that precedes
|
|
it (and that does not contain a newline).
|
|
|
|
@item
|
|
The end-of-file marker (@code{EOF}) also serves to end the line
|
|
of text that precedes it (and that does not contain a newline).
|
|
|
|
@item
|
|
@cindex blank
|
|
@cindex space
|
|
@cindex SPC
|
|
Any line of text that is shorter than 72 characters is padded to that length
|
|
with spaces (called ``blanks'' in the standard).
|
|
|
|
@item
|
|
Any line of text that is longer than 72 characters is truncated to that
|
|
length, but the truncated remainder must consist entirely of spaces.
|
|
|
|
@item
|
|
Characters other than newline and the GNU Fortran character set
|
|
are invalid.
|
|
@end itemize
|
|
|
|
For the purposes of the remainder of this description of the GNU
|
|
Fortran language, the translation described above has already
|
|
taken place, unless otherwise specified.
|
|
|
|
The result of the above translation is that the source file appears,
|
|
in terms of the remainder of this description of the GNU Fortran language,
|
|
as if it had an arbitrary
|
|
number of 72-character lines, each character being among the GNU Fortran
|
|
character set.
|
|
|
|
For example, if the source file itself has two newlines in a row,
|
|
the second newline becomes, after the above translation, a single
|
|
line containing 72 spaces.
|
|
|
|
@node Continuation Line
|
|
@subsection Continuation Line
|
|
@cindex continuation line, number of
|
|
@cindex lines, continuation
|
|
@cindex number of continuation lines
|
|
@cindex limits, continuation lines
|
|
|
|
(Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
A continuation line is any line that both
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Contains a continuation character, and
|
|
|
|
@item
|
|
Contains only spaces in columns 1 through 5
|
|
@end itemize
|
|
|
|
A continuation character is any character of the GNU Fortran character set
|
|
other than space (@key{SPC}) or zero (@samp{0})
|
|
in column 6, or a digit (@samp{0} through @samp{9}) in column
|
|
7 through 72 of a line that has only spaces to the left of that
|
|
digit.
|
|
|
|
The continuation character is ignored as far as the content of
|
|
the statement is concerned.
|
|
|
|
The GNU Fortran language places no limit on the number of
|
|
continuation lines in a statement.
|
|
In practice, the limit depends on a variety of factors, such as
|
|
available memory, statement content, and so on, but no
|
|
GNU Fortran system may impose an arbitrary limit.
|
|
|
|
@node Statements
|
|
@subsection Statements
|
|
|
|
(Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
Statements may be written using an arbitrary number of continuation
|
|
lines.
|
|
|
|
Statements may be separated using the semicolon (@samp{;}), except
|
|
that the logical @code{IF} and non-construct @code{WHERE} statements
|
|
may not be separated from subsequent statements using only a semicolon
|
|
as statement separator.
|
|
|
|
The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
|
|
and @code{END BLOCK DATA} statements are alternatives to the @code{END}
|
|
statement.
|
|
These alternatives may be written as normal statements---they are not
|
|
subject to the restrictions of the @code{END} statement.
|
|
|
|
However, no statement other than @code{END} may have an initial line
|
|
that appears to be an @code{END} statement---even @code{END PROGRAM},
|
|
for example, must not be written as:
|
|
|
|
@example
|
|
END
|
|
&PROGRAM
|
|
@end example
|
|
|
|
@node Statement Labels
|
|
@subsection Statement Labels
|
|
|
|
(Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
A statement separated from its predecessor via a semicolon may be
|
|
labeled as follows:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The semicolon is followed by the label for the statement,
|
|
which in turn follows the label.
|
|
|
|
@item
|
|
The label must be no more than five digits in length.
|
|
|
|
@item
|
|
The first digit of the label for the statement is not
|
|
the first non-space character on a line.
|
|
Otherwise, that character is treated as a continuation
|
|
character.
|
|
@end itemize
|
|
|
|
A statement may have only one label defined for it.
|
|
|
|
@node Order
|
|
@subsection Order of Statements and Lines
|
|
|
|
(Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
Generally, @code{DATA} statements may precede executable statements.
|
|
However, specification statements pertaining to any entities
|
|
initialized by a @code{DATA} statement must precede that @code{DATA}
|
|
statement.
|
|
For example,
|
|
after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
|
|
@samp{INTEGER J} is permitted.
|
|
|
|
The last line of a program unit may be an @code{END} statement,
|
|
or may be:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
An @code{END PROGRAM} statement, if the program unit is a main program.
|
|
|
|
@item
|
|
An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
|
|
|
|
@item
|
|
An @code{END FUNCTION} statement, if the program unit is a function.
|
|
|
|
@item
|
|
An @code{END BLOCK DATA} statement, if the program unit is a block data.
|
|
@end itemize
|
|
|
|
@node INCLUDE
|
|
@subsection Including Source Text
|
|
@cindex INCLUDE directive
|
|
|
|
Additional source text may be included in the processing of
|
|
the source file via the @code{INCLUDE} directive:
|
|
|
|
@example
|
|
INCLUDE @var{filename}
|
|
@end example
|
|
|
|
@noindent
|
|
The source text to be included is identified by @var{filename},
|
|
which is a literal GNU Fortran character constant.
|
|
The meaning and interpretation of @var{filename} depends on the
|
|
implementation, but typically is a filename.
|
|
|
|
(@command{g77} treats it as a filename that it searches for
|
|
in the current directory and/or directories specified
|
|
via the @option{-I} command-line option.)
|
|
|
|
The effect of the @code{INCLUDE} directive is as if the
|
|
included text directly replaced the directive in the source
|
|
file prior to interpretation of the program.
|
|
Included text may itself use @code{INCLUDE}.
|
|
The depth of nested @code{INCLUDE} references depends on
|
|
the implementation, but typically is a positive integer.
|
|
|
|
This virtual replacement treats the statements and @code{INCLUDE}
|
|
directives in the included text as syntactically distinct from
|
|
those in the including text.
|
|
|
|
Therefore, the first non-comment line of the included text
|
|
must not be a continuation line.
|
|
The included text must therefore have, after the non-comment
|
|
lines, either an initial line (statement), an @code{INCLUDE}
|
|
directive, or nothing (the end of the included text).
|
|
|
|
Similarly, the including text may end the @code{INCLUDE}
|
|
directive with a semicolon or the end of the line, but it
|
|
cannot follow an @code{INCLUDE} directive at the end of its
|
|
line with a continuation line.
|
|
Thus, the last statement in an included text may not be
|
|
continued.
|
|
|
|
Any statements between two @code{INCLUDE} directives on the
|
|
same line are treated as if they appeared in between the
|
|
respective included texts.
|
|
For example:
|
|
|
|
@smallexample
|
|
INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
|
|
@end smallexample
|
|
|
|
@noindent
|
|
If the text included by @samp{INCLUDE 'A'} constitutes
|
|
a @samp{PRINT *, 'A'} statement and the text included by
|
|
@samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
|
|
then the output of the above sample program would be
|
|
|
|
@example
|
|
A
|
|
B
|
|
C
|
|
@end example
|
|
|
|
@noindent
|
|
(with suitable allowances for how an implementation defines
|
|
its handling of output).
|
|
|
|
Included text must not include itself directly or indirectly,
|
|
regardless of whether the @var{filename} used to reference
|
|
the text is the same.
|
|
|
|
Note that @code{INCLUDE} is @emph{not} a statement.
|
|
As such, it is neither a non-executable or executable
|
|
statement.
|
|
However, if the text it includes constitutes one or more
|
|
executable statements, then the placement of @code{INCLUDE}
|
|
is subject to effectively the same restrictions as those
|
|
on executable statements.
|
|
|
|
An @code{INCLUDE} directive may be continued across multiple
|
|
lines as if it were a statement.
|
|
This permits long names to be used for @var{filename}.
|
|
|
|
@node Cpp-style directives
|
|
@subsection Cpp-style directives
|
|
@cindex #
|
|
@cindex preprocessor
|
|
|
|
@code{cpp} output-style @code{#} directives
|
|
(@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
|
|
are recognized by the compiler even
|
|
when the preprocessor isn't run on the input (as it is when compiling
|
|
@samp{.F} files). (Note the distinction between these @command{cpp}
|
|
@code{#} @emph{output} directives and @code{#line} @emph{input}
|
|
directives.)
|
|
|
|
@node Data Types and Constants
|
|
@section Data Types and Constants
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 4 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
To more concisely express the appropriate types for
|
|
entities, this document uses the more concise
|
|
Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
|
|
instead of the more traditional, but less portably concise,
|
|
byte-size-based nomenclature such as @code{INTEGER*4},
|
|
wherever reasonable.
|
|
|
|
When referring to generic types---in contexts where the
|
|
specific precision and range of a type are not important---this
|
|
document uses the generic type names @code{INTEGER}, @code{LOGICAL},
|
|
@code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
|
|
|
|
In some cases, the context requires specification of a
|
|
particular type.
|
|
This document uses the @samp{KIND=} notation to accomplish
|
|
this throughout, sometimes supplying the more traditional
|
|
notation for clarification, though the traditional notation
|
|
might not work the same way on all GNU Fortran implementations.
|
|
|
|
Use of @samp{KIND=} makes this document more concise because
|
|
@command{g77} is able to define values for @samp{KIND=} that
|
|
have the same meanings on all systems, due to the way the
|
|
Fortran 90 standard specifies these values are to be used.
|
|
|
|
(In particular, that standard permits an implementation to
|
|
arbitrarily assign nonnegative values.
|
|
There are four distinct sets of assignments: one to the @code{CHARACTER}
|
|
type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
|
|
and the fourth to both the @code{REAL} and @code{COMPLEX} types.
|
|
Implementations are free to assign these values in any order,
|
|
leave gaps in the ordering of assignments, and assign more than
|
|
one value to a representation.)
|
|
|
|
This makes @samp{KIND=} values superior to the values used
|
|
in non-standard statements such as @samp{INTEGER*4}, because
|
|
the meanings of the values in those statements vary from machine
|
|
to machine, compiler to compiler, even operating system to
|
|
operating system.
|
|
|
|
However, use of @samp{KIND=} is @emph{not} generally recommended
|
|
when writing portable code (unless, for example, the code is
|
|
going to be compiled only via @command{g77}, which is a widely
|
|
ported compiler).
|
|
GNU Fortran does not yet have adequate language constructs to
|
|
permit use of @samp{KIND=} in a fashion that would make the
|
|
code portable to Fortran 90 implementations; and, this construct
|
|
is known to @emph{not} be accepted by many popular FORTRAN 77
|
|
implementations, so it cannot be used in code that is to be ported
|
|
to those.
|
|
|
|
The distinction here is that this document is able to use
|
|
specific values for @samp{KIND=} to concisely document the
|
|
types of various operations and operands.
|
|
|
|
A Fortran program should use the FORTRAN 77 designations for the
|
|
appropriate GNU Fortran types---such as @code{INTEGER} for
|
|
@code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
|
|
and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
|
|
where no such designations exist, make use of appropriate
|
|
techniques (preprocessor macros, parameters, and so on)
|
|
to specify the types in a fashion that may be easily adjusted
|
|
to suit each particular implementation to which the program
|
|
is ported.
|
|
(These types generally won't need to be adjusted for ports of
|
|
@command{g77}.)
|
|
|
|
Further details regarding GNU Fortran data types and constants
|
|
are provided below.
|
|
|
|
@menu
|
|
* Types::
|
|
* Constants::
|
|
* Integer Type::
|
|
* Character Type::
|
|
@end menu
|
|
|
|
@node Types
|
|
@subsection Data Types
|
|
|
|
(Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
GNU Fortran supports these types:
|
|
|
|
@enumerate
|
|
@item
|
|
Integer (generic type @code{INTEGER})
|
|
|
|
@item
|
|
Real (generic type @code{REAL})
|
|
|
|
@item
|
|
Double precision
|
|
|
|
@item
|
|
Complex (generic type @code{COMPLEX})
|
|
|
|
@item
|
|
Logical (generic type @code{LOGICAL})
|
|
|
|
@item
|
|
Character (generic type @code{CHARACTER})
|
|
|
|
@item
|
|
Double Complex
|
|
@end enumerate
|
|
|
|
(The types numbered 1 through 6 above are standard FORTRAN 77 types.)
|
|
|
|
The generic types shown above are referred to in this document
|
|
using only their generic type names.
|
|
Such references usually indicate that any specific type (kind)
|
|
of that generic type is valid.
|
|
|
|
For example, a context described in this document as accepting
|
|
the @code{COMPLEX} type also is likely to accept the
|
|
@code{DOUBLE COMPLEX} type.
|
|
|
|
The GNU Fortran language supports three ways to specify
|
|
a specific kind of a generic type.
|
|
|
|
@menu
|
|
* Double Notation:: As in @code{DOUBLE COMPLEX}.
|
|
* Star Notation:: As in @code{INTEGER*4}.
|
|
* Kind Notation:: As in @code{INTEGER(KIND=1)}.
|
|
@end menu
|
|
|
|
@node Double Notation
|
|
@subsubsection Double Notation
|
|
|
|
The GNU Fortran language supports two uses of the keyword
|
|
@code{DOUBLE} to specify a specific kind of type:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
|
|
|
|
@item
|
|
@code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
|
|
@end itemize
|
|
|
|
Use one of the above forms where a type name is valid.
|
|
|
|
While use of this notation is popular, it doesn't scale
|
|
well in a language or dialect rich in intrinsic types,
|
|
as is the case for the GNU Fortran language (especially
|
|
planned future versions of it).
|
|
|
|
After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
|
|
@samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
|
|
Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
|
|
often are substituted for these, respectively, even though they
|
|
do not always have the same meanings on all systems.
|
|
(And, the fact that @samp{DOUBLE REAL} does not exist as such
|
|
is an inconsistency.)
|
|
|
|
Therefore, this document uses ``double notation'' only on occasion
|
|
for the benefit of those readers who are accustomed to it.
|
|
|
|
@node Star Notation
|
|
@subsubsection Star Notation
|
|
@cindex *@var{n} notation
|
|
|
|
The following notation specifies the storage size for a type:
|
|
|
|
@smallexample
|
|
@var{generic-type}*@var{n}
|
|
@end smallexample
|
|
|
|
@noindent
|
|
@var{generic-type} must be a generic type---one of
|
|
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
|
|
or @code{CHARACTER}.
|
|
@var{n} must be one or more digits comprising a decimal
|
|
integer number greater than zero.
|
|
|
|
Use the above form where a type name is valid.
|
|
|
|
The @samp{*@var{n}} notation specifies that the amount of storage
|
|
occupied by variables and array elements of that type is @var{n}
|
|
times the storage occupied by a @code{CHARACTER*1} variable.
|
|
|
|
This notation might indicate a different degree of precision and/or
|
|
range for such variables and array elements, and the functions that
|
|
return values of types using this notation.
|
|
It does not limit the precision or range of values of that type
|
|
in any particular way---use explicit code to do that.
|
|
|
|
Further, the GNU Fortran language requires no particular values
|
|
for @var{n} to be supported by an implementation via the @samp{*@var{n}}
|
|
notation.
|
|
@command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
|
|
on all systems, for example,
|
|
but not all implementations are required to do so, and @command{g77}
|
|
is known to not support @code{REAL*1} on most (or all) systems.
|
|
|
|
As a result, except for @var{generic-type} of @code{CHARACTER},
|
|
uses of this notation should be limited to isolated
|
|
portions of a program that are intended to handle system-specific
|
|
tasks and are expected to be non-portable.
|
|
|
|
(Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
|
|
only @code{CHARACTER}, where it signifies not only the amount
|
|
of storage occupied, but the number of characters in entities
|
|
of that type.
|
|
However, almost all Fortran compilers have supported this
|
|
notation for generic types, though with a variety of meanings
|
|
for @var{n}.)
|
|
|
|
Specifications of types using the @samp{*@var{n}} notation
|
|
always are interpreted as specifications of the appropriate
|
|
types described in this document using the @samp{KIND=@var{n}}
|
|
notation, described below.
|
|
|
|
While use of this notation is popular, it doesn't serve well
|
|
in the context of a widely portable dialect of Fortran, such as
|
|
the GNU Fortran language.
|
|
|
|
For example, even on one particular machine, two or more popular
|
|
Fortran compilers might well disagree on the size of a type
|
|
declared @code{INTEGER*2} or @code{REAL*16}.
|
|
Certainly there
|
|
is known to be disagreement over such things among Fortran
|
|
compilers on @emph{different} systems.
|
|
|
|
Further, this notation offers no elegant way to specify sizes
|
|
that are not even multiples of the ``byte size'' typically
|
|
designated by @code{INTEGER*1}.
|
|
Use of ``absurd'' values (such as @code{INTEGER*1000}) would
|
|
certainly be possible, but would perhaps be stretching the original
|
|
intent of this notation beyond the breaking point in terms
|
|
of widespread readability of documentation and code making use
|
|
of it.
|
|
|
|
Therefore, this document uses ``star notation'' only on occasion
|
|
for the benefit of those readers who are accustomed to it.
|
|
|
|
@node Kind Notation
|
|
@subsubsection Kind Notation
|
|
@cindex KIND= notation
|
|
|
|
The following notation specifies the kind-type selector of a type:
|
|
|
|
@smallexample
|
|
@var{generic-type}(KIND=@var{n})
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Use the above form where a type name is valid.
|
|
|
|
@var{generic-type} must be a generic type---one of
|
|
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
|
|
or @code{CHARACTER}.
|
|
@var{n} must be an integer initialization expression that
|
|
is a positive, nonzero value.
|
|
|
|
Programmers are discouraged from writing these values directly
|
|
into their code.
|
|
Future versions of the GNU Fortran language will offer
|
|
facilities that will make the writing of code portable
|
|
to @command{g77} @emph{and} Fortran 90 implementations simpler.
|
|
|
|
However, writing code that ports to existing FORTRAN 77
|
|
implementations depends on avoiding the @samp{KIND=} construct.
|
|
|
|
The @samp{KIND=} construct is thus useful in the context
|
|
of GNU Fortran for two reasons:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
It provides a means to specify a type in a fashion that
|
|
is portable across all GNU Fortran implementations (though
|
|
not other FORTRAN 77 and Fortran 90 implementations).
|
|
|
|
@item
|
|
It provides a sort of Rosetta stone for this document to use
|
|
to concisely describe the types of various operations and
|
|
operands.
|
|
@end itemize
|
|
|
|
The values of @var{n} in the GNU Fortran language are
|
|
assigned using a scheme that:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Attempts to maximize the ability of readers
|
|
of this document to quickly familiarize themselves
|
|
with assignments for popular types
|
|
|
|
@item
|
|
Provides a unique value for each specific desired
|
|
meaning
|
|
|
|
@item
|
|
Provides a means to automatically assign new values so
|
|
they have a ``natural'' relationship to existing values,
|
|
if appropriate, or, if no such relationship exists, will
|
|
not interfere with future values assigned on the basis
|
|
of such relationships
|
|
|
|
@item
|
|
Avoids using values that are similar to values used
|
|
in the existing, popular @samp{*@var{n}} notation,
|
|
to prevent readers from expecting that these implied
|
|
correspondences work on all GNU Fortran implementations
|
|
@end itemize
|
|
|
|
The assignment system accomplishes this by assigning
|
|
to each ``fundamental meaning'' of a specific type a
|
|
unique prime number.
|
|
Combinations of fundamental meanings---for example, a type
|
|
that is two times the size of some other type---are assigned
|
|
values of @var{n} that are the products of the values for
|
|
those fundamental meanings.
|
|
|
|
A prime value of @var{n} is never given more than one fundamental
|
|
meaning, to avoid situations where some code or system
|
|
cannot reasonably provide those meanings in the form of a
|
|
single type.
|
|
|
|
The values of @var{n} assigned so far are:
|
|
|
|
@table @code
|
|
@item KIND=0
|
|
This value is reserved for future use.
|
|
|
|
The planned future use is for this value to designate,
|
|
explicitly, context-sensitive kind-type selection.
|
|
For example, the expression @samp{1D0 * 0.1_0} would
|
|
be equivalent to @samp{1D0 * 0.1D0}.
|
|
|
|
@item KIND=1
|
|
This corresponds to the default types for
|
|
@code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
|
|
and @code{CHARACTER}, as appropriate.
|
|
|
|
These are the ``default'' types described in the Fortran 90 standard,
|
|
though that standard does not assign any particular @samp{KIND=}
|
|
value to these types.
|
|
|
|
(Typically, these are @code{REAL*4}, @code{INTEGER*4},
|
|
@code{LOGICAL*4}, and @code{COMPLEX*8}.)
|
|
|
|
@item KIND=2
|
|
This corresponds to types that occupy twice as much
|
|
storage as the default types.
|
|
@code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
|
|
@code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
|
|
|
|
These are the ``double precision'' types described in the Fortran 90
|
|
standard,
|
|
though that standard does not assign any particular @samp{KIND=}
|
|
value to these types.
|
|
|
|
@var{n} of 4 thus corresponds to types that occupy four times
|
|
as much storage as the default types, @var{n} of 8 to types that
|
|
occupy eight times as much storage, and so on.
|
|
|
|
The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
|
|
are not necessarily supported by every GNU Fortran implementation.
|
|
|
|
@item KIND=3
|
|
This corresponds to types that occupy as much
|
|
storage as the default @code{CHARACTER} type,
|
|
which is the same effective type as @code{CHARACTER(KIND=1)}
|
|
(making that type effectively the same as @code{CHARACTER(KIND=3)}).
|
|
|
|
(Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
|
|
|
|
@var{n} of 6 thus corresponds to types that occupy twice as
|
|
much storage as the @var{n}=3 types, @var{n} of 12 to types
|
|
that occupy four times as much storage, and so on.
|
|
|
|
These are not necessarily supported by every GNU Fortran
|
|
implementation.
|
|
|
|
@item KIND=5
|
|
This corresponds to types that occupy half the
|
|
storage as the default (@var{n}=1) types.
|
|
|
|
(Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
|
|
|
|
@var{n} of 25 thus corresponds to types that occupy one-quarter
|
|
as much storage as the default types.
|
|
|
|
These are not necessarily supported by every GNU Fortran
|
|
implementation.
|
|
|
|
@item KIND=7
|
|
@cindex pointers
|
|
This is valid only as @code{INTEGER(KIND=7)} and
|
|
denotes the @code{INTEGER} type that has the smallest
|
|
storage size that holds a pointer on the system.
|
|
|
|
A pointer representable by this type is capable of uniquely
|
|
addressing a @code{CHARACTER*1} variable, array, array element,
|
|
or substring.
|
|
|
|
(Typically this is equivalent to @code{INTEGER*4} or,
|
|
on 64-bit systems, @code{INTEGER*8}.
|
|
In a compatible C implementation, it typically would
|
|
be the same size and semantics of the C type @code{void *}.)
|
|
@end table
|
|
|
|
Note that these are @emph{proposed} correspondences and might change
|
|
in future versions of @command{g77}---avoid writing code depending
|
|
on them while @command{g77}, and therefore the GNU Fortran language
|
|
it defines, is in beta testing.
|
|
|
|
Values not specified in the above list are reserved to
|
|
future versions of the GNU Fortran language.
|
|
|
|
Implementation-dependent meanings will be assigned new,
|
|
unique prime numbers so as to not interfere with other
|
|
implementation-dependent meanings, and offer the possibility
|
|
of increasing the portability of code depending on such
|
|
types by offering support for them in other GNU Fortran
|
|
implementations.
|
|
|
|
Other meanings that might be given unique values are:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Types that make use of only half their storage size for
|
|
representing precision and range.
|
|
|
|
For example, some compilers offer options that cause
|
|
@code{INTEGER} types to occupy the amount of storage
|
|
that would be needed for @code{INTEGER(KIND=2)} types, but the
|
|
range remains that of @code{INTEGER(KIND=1)}.
|
|
|
|
@item
|
|
The IEEE single floating-point type.
|
|
|
|
@item
|
|
Types with a specific bit pattern (endianness), such as the
|
|
little-endian form of @code{INTEGER(KIND=1)}.
|
|
These could permit, conceptually, use of portable code and
|
|
implementations on data files written by existing systems.
|
|
@end itemize
|
|
|
|
Future @emph{prime} numbers should be given meanings in as incremental
|
|
a fashion as possible, to allow for flexibility and
|
|
expressiveness in combining types.
|
|
|
|
For example, instead of defining a prime number for little-endian
|
|
IEEE doubles, one prime number might be assigned the meaning
|
|
``little-endian'', another the meaning ``IEEE double'', and the
|
|
value of @var{n} for a little-endian IEEE double would thus
|
|
naturally be the product of those two respective assigned values.
|
|
(It could even be reasonable to have IEEE values result from the
|
|
products of prime values denoting exponent and fraction sizes
|
|
and meanings, hidden bit usage, availability and representations
|
|
of special values such as subnormals, infinities, and Not-A-Numbers
|
|
(NaNs), and so on.)
|
|
|
|
This assignment mechanism, while not inherently required for
|
|
future versions of the GNU Fortran language, is worth using
|
|
because it could ease management of the ``space'' of supported
|
|
types much easier in the long run.
|
|
|
|
The above approach suggests a mechanism for specifying inheritance
|
|
of intrinsic (built-in) types for an entire, widely portable
|
|
product line.
|
|
It is certainly reasonable that, unlike programmers of other languages
|
|
offering inheritance mechanisms that employ verbose names for classes
|
|
and subclasses, along with graphical browsers to elucidate the
|
|
relationships, Fortran programmers would employ
|
|
a mechanism that works by multiplying prime numbers together
|
|
and finding the prime factors of such products.
|
|
|
|
Most of the advantages for the above scheme have been explained
|
|
above.
|
|
One disadvantage is that it could lead to the defining,
|
|
by the GNU Fortran language, of some fairly large prime numbers.
|
|
This could lead to the GNU Fortran language being declared
|
|
``munitions'' by the United States Department of Defense.
|
|
|
|
@node Constants
|
|
@subsection Constants
|
|
@cindex constants
|
|
@cindex types, constants
|
|
|
|
(Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
A @dfn{typeless constant} has one of the following forms:
|
|
|
|
@smallexample
|
|
'@var{binary-digits}'B
|
|
'@var{octal-digits}'O
|
|
'@var{hexadecimal-digits}'Z
|
|
'@var{hexadecimal-digits}'X
|
|
@end smallexample
|
|
|
|
@noindent
|
|
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
|
|
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
|
|
and @samp{0123456789ABCDEFabcdef}, respectively.
|
|
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
|
|
is 11, and so on.)
|
|
|
|
A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
|
|
treated as typeless. @xref{Fortran Dialect Options,, Options
|
|
Controlling Fortran Dialect}, for information on the
|
|
@option{-ftypeless-boz} option.
|
|
|
|
Typeless constants have values that depend on the context in which
|
|
they are used.
|
|
|
|
All other constants, called @dfn{typed constants}, are interpreted---converted
|
|
to internal form---according to their inherent type.
|
|
Thus, context is @emph{never} a determining factor for the type, and hence
|
|
the interpretation, of a typed constant.
|
|
(All constants in the ANSI FORTRAN 77 language are typed constants.)
|
|
|
|
For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
|
|
Fortran (called default INTEGER in Fortran 90),
|
|
@samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
|
|
additional precision specified is lost, and even when used in a
|
|
@code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
|
|
and @samp{1D0} is always type @code{REAL(KIND=2)}.
|
|
|
|
@node Integer Type
|
|
@subsection Integer Type
|
|
|
|
(Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
An integer constant also may have one of the following forms:
|
|
|
|
@smallexample
|
|
B'@var{binary-digits}'
|
|
O'@var{octal-digits}'
|
|
Z'@var{hexadecimal-digits}'
|
|
X'@var{hexadecimal-digits}'
|
|
@end smallexample
|
|
|
|
@noindent
|
|
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
|
|
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
|
|
and @samp{0123456789ABCDEFabcdef}, respectively.
|
|
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
|
|
is 11, and so on.)
|
|
|
|
@node Character Type
|
|
@subsection Character Type
|
|
|
|
(Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
@cindex double quoted character constants
|
|
A character constant may be delimited by a pair of double quotes
|
|
(@samp{"}) instead of apostrophes.
|
|
In this case, an apostrophe within the constant represents
|
|
a single apostrophe, while a double quote is represented in
|
|
the source text of the constant by two consecutive double
|
|
quotes with no intervening spaces.
|
|
|
|
@cindex zero-length CHARACTER
|
|
@cindex null CHARACTER strings
|
|
@cindex empty CHARACTER strings
|
|
@cindex strings, empty
|
|
@cindex CHARACTER, null
|
|
A character constant may be empty (have a length of zero).
|
|
|
|
A character constant may include a substring specification,
|
|
The value of such a constant is the value of the substring---for
|
|
example, the value of @samp{'hello'(3:5)} is the same
|
|
as the value of @samp{'llo'}.
|
|
|
|
@node Expressions
|
|
@section Expressions
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 6 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* %LOC()::
|
|
@end menu
|
|
|
|
@node %LOC()
|
|
@subsection The @code{%LOC()} Construct
|
|
@cindex %LOC() construct
|
|
|
|
@example
|
|
%LOC(@var{arg})
|
|
@end example
|
|
|
|
The @code{%LOC()} construct is an expression
|
|
that yields the value of the location of its argument,
|
|
@var{arg}, in memory.
|
|
The size of the type of the expression depends on the system---typically,
|
|
it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
|
|
though it is actually type @code{INTEGER(KIND=7)}.
|
|
|
|
The argument to @code{%LOC()} must be suitable as the
|
|
left-hand side of an assignment statement.
|
|
That is, it may not be a general expression involving
|
|
operators such as addition, subtraction, and so on,
|
|
nor may it be a constant.
|
|
|
|
Use of @code{%LOC()} is recommended only for code that
|
|
is accessing facilities outside of GNU Fortran, such as
|
|
operating system or windowing facilities.
|
|
It is best to constrain such uses to isolated portions of
|
|
a program---portions that deal specifically and exclusively
|
|
with low-level, system-dependent facilities.
|
|
Such portions might well provide a portable interface for
|
|
use by the program as a whole, but are themselves not
|
|
portable, and should be thoroughly tested each time they
|
|
are rebuilt using a new compiler or version of a compiler.
|
|
|
|
Do not depend on @code{%LOC()} returning a pointer that
|
|
can be safely used to @emph{define} (change) the argument.
|
|
While this might work in some circumstances, it is hard
|
|
to predict whether it will continue to work when a program
|
|
(that works using this unsafe behavior)
|
|
is recompiled using different command-line options or
|
|
a different version of @command{g77}.
|
|
|
|
Generally, @code{%LOC()} is safe when used as an argument
|
|
to a procedure that makes use of the value of the corresponding
|
|
dummy argument only during its activation, and only when
|
|
such use is restricted to referencing (reading) the value
|
|
of the argument to @code{%LOC()}.
|
|
|
|
@emph{Implementation Note:} Currently, @command{g77} passes
|
|
arguments (those not passed using a construct such as @code{%VAL()})
|
|
by reference or descriptor, depending on the type of
|
|
the actual argument.
|
|
Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
|
|
seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
|
|
in fact might compile to identical code.
|
|
|
|
However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
|
|
``pass, by value, the address of @samp{I} in memory''.
|
|
While @samp{CALL FOO(I)} might use that same approach in a
|
|
particular version of @command{g77}, another version or compiler
|
|
might choose a different implementation, such as copy-in/copy-out,
|
|
to effect the desired behavior---and which will therefore not
|
|
necessarily compile to the same code as would
|
|
@samp{CALL FOO(%VAL(%LOC(I)))}
|
|
using the same version or compiler.
|
|
|
|
@xref{Debugging and Interfacing}, for detailed information on
|
|
how this particular version of @command{g77} implements various
|
|
constructs.
|
|
|
|
@node Specification Statements
|
|
@section Specification Statements
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 8 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* NAMELIST::
|
|
* DOUBLE COMPLEX::
|
|
@end menu
|
|
|
|
@node NAMELIST
|
|
@subsection @code{NAMELIST} Statement
|
|
@cindex NAMELIST statement
|
|
@cindex statements, NAMELIST
|
|
|
|
The @code{NAMELIST} statement, and related I/O constructs, are
|
|
supported by the GNU Fortran language in essentially the same
|
|
way as they are by @command{f2c}.
|
|
|
|
This follows Fortran 90 with the restriction that on @code{NAMELIST}
|
|
input, subscripts must have the form
|
|
@smallexample
|
|
@var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
|
|
@end smallexample
|
|
i.e.@:
|
|
@smallexample
|
|
&xx x(1:3,8:10:2)=1,2,3,4,5,6/
|
|
@end smallexample
|
|
is allowed, but not, say,
|
|
@smallexample
|
|
&xx x(:3,8::2)=1,2,3,4,5,6/
|
|
@end smallexample
|
|
|
|
As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
|
|
used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
|
|
@smallexample
|
|
$&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
|
|
@end smallexample
|
|
could be used instead of the example above.
|
|
|
|
@node DOUBLE COMPLEX
|
|
@subsection @code{DOUBLE COMPLEX} Statement
|
|
@cindex DOUBLE COMPLEX
|
|
|
|
@code{DOUBLE COMPLEX} is a type-statement (and type) that
|
|
specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
|
|
|
|
@node Control Statements
|
|
@section Control Statements
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 11 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* DO WHILE::
|
|
* END DO::
|
|
* Construct Names::
|
|
* CYCLE and EXIT::
|
|
@end menu
|
|
|
|
@node DO WHILE
|
|
@subsection DO WHILE
|
|
@cindex DO WHILE
|
|
@cindex DO
|
|
@cindex MIL-STD 1753
|
|
|
|
The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
|
|
Fortran 90 standards, is provided by the GNU Fortran language.
|
|
The Fortran 90 ``do forever'' statement comprising just @code{DO} is
|
|
also supported.
|
|
|
|
@node END DO
|
|
@subsection END DO
|
|
@cindex END DO
|
|
@cindex MIL-STD 1753
|
|
|
|
The @code{END DO} statement is provided by the GNU Fortran language.
|
|
|
|
This statement is used in one of two ways:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The Fortran 90 meaning, in which it specifies the termination
|
|
point of a single @code{DO} loop started with a @code{DO} statement
|
|
that specifies no termination label.
|
|
|
|
@item
|
|
The MIL-STD 1753 meaning, in which it specifies the termination
|
|
point of one or more @code{DO} loops, all of which start with a
|
|
@code{DO} statement that specify the label defined for the
|
|
@code{END DO} statement.
|
|
|
|
This kind of @code{END DO} statement is merely a synonym for
|
|
@code{CONTINUE}, except it is permitted only when the statement
|
|
is labeled and a target of one or more labeled @code{DO} loops.
|
|
|
|
It is expected that this use of @code{END DO} will be removed from
|
|
the GNU Fortran language in the future, though it is likely that
|
|
it will long be supported by @command{g77} as a dialect form.
|
|
@end itemize
|
|
|
|
@node Construct Names
|
|
@subsection Construct Names
|
|
@cindex construct names
|
|
|
|
The GNU Fortran language supports construct names as defined
|
|
by the Fortran 90 standard.
|
|
These names are local to the program unit and are defined
|
|
as follows:
|
|
|
|
@smallexample
|
|
@var{construct-name}: @var{block-statement}
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Here, @var{construct-name} is the construct name itself;
|
|
its definition is connoted by the single colon (@samp{:}); and
|
|
@var{block-statement} is an @code{IF}, @code{DO},
|
|
or @code{SELECT CASE} statement that begins a block.
|
|
|
|
A block that is given a construct name must also specify the
|
|
same construct name in its termination statement:
|
|
|
|
@example
|
|
END @var{block} @var{construct-name}
|
|
@end example
|
|
|
|
@noindent
|
|
Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
|
|
as appropriate.
|
|
|
|
@node CYCLE and EXIT
|
|
@subsection The @code{CYCLE} and @code{EXIT} Statements
|
|
|
|
@cindex CYCLE statement
|
|
@cindex EXIT statement
|
|
@cindex statements, CYCLE
|
|
@cindex statements, EXIT
|
|
The @code{CYCLE} and @code{EXIT} statements specify that
|
|
the remaining statements in the current iteration of a
|
|
particular active (enclosing) @code{DO} loop are to be skipped.
|
|
|
|
@code{CYCLE} specifies that these statements are skipped,
|
|
but the @code{END DO} statement that marks the end of the
|
|
@code{DO} loop be executed---that is, the next iteration,
|
|
if any, is to be started.
|
|
If the statement marking the end of the @code{DO} loop is
|
|
not @code{END DO}---in other words, if the loop is not
|
|
a block @code{DO}---the @code{CYCLE} statement does not
|
|
execute that statement, but does start the next iteration (if any).
|
|
|
|
@code{EXIT} specifies that the loop specified by the
|
|
@code{DO} construct is terminated.
|
|
|
|
The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
|
|
is the innermost enclosing @code{DO} loop when the following
|
|
forms are used:
|
|
|
|
@example
|
|
CYCLE
|
|
EXIT
|
|
@end example
|
|
|
|
Otherwise, the following forms specify the construct name
|
|
of the pertinent @code{DO} loop:
|
|
|
|
@example
|
|
CYCLE @var{construct-name}
|
|
EXIT @var{construct-name}
|
|
@end example
|
|
|
|
@code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
|
|
statements.
|
|
However, they cannot be easily thought of as @code{GO TO} statements
|
|
in obscure cases involving FORTRAN 77 loops.
|
|
For example:
|
|
|
|
@smallexample
|
|
DO 10 I = 1, 5
|
|
DO 10 J = 1, 5
|
|
IF (J .EQ. 5) EXIT
|
|
DO 10 K = 1, 5
|
|
IF (K .EQ. 3) CYCLE
|
|
10 PRINT *, 'I=', I, ' J=', J, ' K=', K
|
|
20 CONTINUE
|
|
@end smallexample
|
|
|
|
@noindent
|
|
In particular, neither the @code{EXIT} nor @code{CYCLE} statements
|
|
above are equivalent to a @code{GO TO} statement to either label
|
|
@samp{10} or @samp{20}.
|
|
|
|
To understand the effect of @code{CYCLE} and @code{EXIT} in the
|
|
above fragment, it is helpful to first translate it to its equivalent
|
|
using only block @code{DO} loops:
|
|
|
|
@smallexample
|
|
DO I = 1, 5
|
|
DO J = 1, 5
|
|
IF (J .EQ. 5) EXIT
|
|
DO K = 1, 5
|
|
IF (K .EQ. 3) CYCLE
|
|
10 PRINT *, 'I=', I, ' J=', J, ' K=', K
|
|
END DO
|
|
END DO
|
|
END DO
|
|
20 CONTINUE
|
|
@end smallexample
|
|
|
|
Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
|
|
to @code{GO TO} so they may be more easily understood by programmers
|
|
accustomed to FORTRAN coding:
|
|
|
|
@smallexample
|
|
DO I = 1, 5
|
|
DO J = 1, 5
|
|
IF (J .EQ. 5) GOTO 18
|
|
DO K = 1, 5
|
|
IF (K .EQ. 3) GO TO 12
|
|
10 PRINT *, 'I=', I, ' J=', J, ' K=', K
|
|
12 END DO
|
|
END DO
|
|
18 END DO
|
|
20 CONTINUE
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Thus, the @code{CYCLE} statement in the innermost loop skips over
|
|
the @code{PRINT} statement as it begins the next iteration of the
|
|
loop, while the @code{EXIT} statement in the middle loop ends that
|
|
loop but @emph{not} the outermost loop.
|
|
|
|
@node Functions and Subroutines
|
|
@section Functions and Subroutines
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 15 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* %VAL()::
|
|
* %REF()::
|
|
* %DESCR()::
|
|
* Generics and Specifics::
|
|
* REAL() and AIMAG() of Complex::
|
|
* CMPLX() of DOUBLE PRECISION::
|
|
* MIL-STD 1753::
|
|
* f77/f2c Intrinsics::
|
|
* Table of Intrinsic Functions::
|
|
@end menu
|
|
|
|
@node %VAL()
|
|
@subsection The @code{%VAL()} Construct
|
|
@cindex %VAL() construct
|
|
|
|
@example
|
|
%VAL(@var{arg})
|
|
@end example
|
|
|
|
The @code{%VAL()} construct specifies that an argument,
|
|
@var{arg}, is to be passed by value, instead of by reference
|
|
or descriptor.
|
|
|
|
@code{%VAL()} is restricted to actual arguments in
|
|
invocations of external procedures.
|
|
|
|
Use of @code{%VAL()} is recommended only for code that
|
|
is accessing facilities outside of GNU Fortran, such as
|
|
operating system or windowing facilities.
|
|
It is best to constrain such uses to isolated portions of
|
|
a program---portions the deal specifically and exclusively
|
|
with low-level, system-dependent facilities.
|
|
Such portions might well provide a portable interface for
|
|
use by the program as a whole, but are themselves not
|
|
portable, and should be thoroughly tested each time they
|
|
are rebuilt using a new compiler or version of a compiler.
|
|
|
|
@emph{Implementation Note:} Currently, @command{g77} passes
|
|
all arguments either by reference or by descriptor.
|
|
|
|
Thus, use of @code{%VAL()} tends to be restricted to cases
|
|
where the called procedure is written in a language other
|
|
than Fortran that supports call-by-value semantics.
|
|
(C is an example of such a language.)
|
|
|
|
@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
|
|
for detailed information on
|
|
how this particular version of @command{g77} passes arguments
|
|
to procedures.
|
|
|
|
@node %REF()
|
|
@subsection The @code{%REF()} Construct
|
|
@cindex %REF() construct
|
|
|
|
@example
|
|
%REF(@var{arg})
|
|
@end example
|
|
|
|
The @code{%REF()} construct specifies that an argument,
|
|
@var{arg}, is to be passed by reference, instead of by
|
|
value or descriptor.
|
|
|
|
@code{%REF()} is restricted to actual arguments in
|
|
invocations of external procedures.
|
|
|
|
Use of @code{%REF()} is recommended only for code that
|
|
is accessing facilities outside of GNU Fortran, such as
|
|
operating system or windowing facilities.
|
|
It is best to constrain such uses to isolated portions of
|
|
a program---portions the deal specifically and exclusively
|
|
with low-level, system-dependent facilities.
|
|
Such portions might well provide a portable interface for
|
|
use by the program as a whole, but are themselves not
|
|
portable, and should be thoroughly tested each time they
|
|
are rebuilt using a new compiler or version of a compiler.
|
|
|
|
Do not depend on @code{%REF()} supplying a pointer to the
|
|
procedure being invoked.
|
|
While that is a likely implementation choice, other
|
|
implementation choices are available that preserve Fortran
|
|
pass-by-reference semantics without passing a pointer to
|
|
the argument, @var{arg}.
|
|
(For example, a copy-in/copy-out implementation.)
|
|
|
|
@emph{Implementation Note:} Currently, @command{g77} passes
|
|
all arguments
|
|
(other than variables and arrays of type @code{CHARACTER})
|
|
by reference.
|
|
Future versions of, or dialects supported by, @command{g77} might
|
|
not pass @code{CHARACTER} functions by reference.
|
|
|
|
Thus, use of @code{%REF()} tends to be restricted to cases
|
|
where @var{arg} is type @code{CHARACTER} but the called
|
|
procedure accesses it via a means other than the method
|
|
used for Fortran @code{CHARACTER} arguments.
|
|
|
|
@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
|
|
how this particular version of @command{g77} passes arguments
|
|
to procedures.
|
|
|
|
@node %DESCR()
|
|
@subsection The @code{%DESCR()} Construct
|
|
@cindex %DESCR() construct
|
|
|
|
@example
|
|
%DESCR(@var{arg})
|
|
@end example
|
|
|
|
The @code{%DESCR()} construct specifies that an argument,
|
|
@var{arg}, is to be passed by descriptor, instead of by
|
|
value or reference.
|
|
|
|
@code{%DESCR()} is restricted to actual arguments in
|
|
invocations of external procedures.
|
|
|
|
Use of @code{%DESCR()} is recommended only for code that
|
|
is accessing facilities outside of GNU Fortran, such as
|
|
operating system or windowing facilities.
|
|
It is best to constrain such uses to isolated portions of
|
|
a program---portions the deal specifically and exclusively
|
|
with low-level, system-dependent facilities.
|
|
Such portions might well provide a portable interface for
|
|
use by the program as a whole, but are themselves not
|
|
portable, and should be thoroughly tested each time they
|
|
are rebuilt using a new compiler or version of a compiler.
|
|
|
|
Do not depend on @code{%DESCR()} supplying a pointer
|
|
and/or a length passed by value
|
|
to the procedure being invoked.
|
|
While that is a likely implementation choice, other
|
|
implementation choices are available that preserve the
|
|
pass-by-reference semantics without passing a pointer to
|
|
the argument, @var{arg}.
|
|
(For example, a copy-in/copy-out implementation.)
|
|
And, future versions of @command{g77} might change the
|
|
way descriptors are implemented, such as passing a
|
|
single argument pointing to a record containing the
|
|
pointer/length information instead of passing that same
|
|
information via two arguments as it currently does.
|
|
|
|
@emph{Implementation Note:} Currently, @command{g77} passes
|
|
all variables and arrays of type @code{CHARACTER}
|
|
by descriptor.
|
|
Future versions of, or dialects supported by, @command{g77} might
|
|
pass @code{CHARACTER} functions by descriptor as well.
|
|
|
|
Thus, use of @code{%DESCR()} tends to be restricted to cases
|
|
where @var{arg} is not type @code{CHARACTER} but the called
|
|
procedure accesses it via a means similar to the method
|
|
used for Fortran @code{CHARACTER} arguments.
|
|
|
|
@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
|
|
how this particular version of @command{g77} passes arguments
|
|
to procedures.
|
|
|
|
@node Generics and Specifics
|
|
@subsection Generics and Specifics
|
|
@cindex generic intrinsics
|
|
@cindex intrinsics, generic
|
|
|
|
The ANSI FORTRAN 77 language defines generic and specific
|
|
intrinsics.
|
|
In short, the distinctions are:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@emph{Specific} intrinsics have
|
|
specific types for their arguments and a specific return
|
|
type.
|
|
|
|
@item
|
|
@emph{Generic} intrinsics are treated,
|
|
on a case-by-case basis in the program's source code,
|
|
as one of several possible specific intrinsics.
|
|
|
|
Typically, a generic intrinsic has a return type that
|
|
is determined by the type of one or more of its arguments.
|
|
@end itemize
|
|
|
|
The GNU Fortran language generalizes these concepts somewhat,
|
|
especially by providing intrinsic subroutines and generic
|
|
intrinsics that are treated as either a specific intrinsic subroutine
|
|
or a specific intrinsic function (e.g. @code{SECOND}).
|
|
|
|
However, GNU Fortran avoids generalizing this concept to
|
|
the point where existing code would be accepted as meaning
|
|
something possibly different than what was intended.
|
|
|
|
For example, @code{ABS} is a generic intrinsic, so all working
|
|
code written using @code{ABS} of an @code{INTEGER} argument
|
|
expects an @code{INTEGER} return value.
|
|
Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
|
|
argument returns an @code{INTEGER*2} return value.
|
|
|
|
Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
|
|
an @code{INTEGER(KIND=1)} argument.
|
|
Code that passes something other than an @code{INTEGER(KIND=1)}
|
|
argument to @code{IABS} is not valid GNU Fortran code, because
|
|
it is not clear what the author intended.
|
|
|
|
For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
|
|
is not defined by the GNU Fortran language, because the programmer
|
|
might have used that construct to mean any of the following, subtly
|
|
different, things:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Convert @samp{J} to @code{INTEGER(KIND=1)} first
|
|
(as if @samp{IABS(INT(J))} had been written).
|
|
|
|
@item
|
|
Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
|
|
(as if @samp{INT(ABS(J))} had been written).
|
|
|
|
@item
|
|
No conversion (as if @samp{ABS(J)} had been written).
|
|
@end itemize
|
|
|
|
The distinctions matter especially when types and values wider than
|
|
@code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
|
|
operations performing more ``arithmetic'' than absolute-value, are involved.
|
|
|
|
The following sample program is not a valid GNU Fortran program, but
|
|
might be accepted by other compilers.
|
|
If so, the output is likely to be revealing in terms of how a given
|
|
compiler treats intrinsics (that normally are specific) when they
|
|
are given arguments that do not conform to their stated requirements:
|
|
|
|
@cindex JCB002 program
|
|
@smallexample
|
|
PROGRAM JCB002
|
|
C Version 1:
|
|
C Modified 1999-02-15 (Burley) to delete my email address.
|
|
C Modified 1997-05-21 (Burley) to accommodate compilers that implement
|
|
C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
|
|
C
|
|
C Version 0:
|
|
C Written by James Craig Burley 1997-02-20.
|
|
C
|
|
C Purpose:
|
|
C Determine how compilers handle non-standard IDIM
|
|
C on INTEGER*2 operands, which presumably can be
|
|
C extrapolated into understanding how the compiler
|
|
C generally treats specific intrinsics that are passed
|
|
C arguments not of the correct types.
|
|
C
|
|
C If your compiler implements INTEGER*2 and INTEGER
|
|
C as the same type, change all INTEGER*2 below to
|
|
C INTEGER*1.
|
|
C
|
|
INTEGER*2 I0, I4
|
|
INTEGER I1, I2, I3
|
|
INTEGER*2 ISMALL, ILARGE
|
|
INTEGER*2 ITOOLG, ITWO
|
|
INTEGER*2 ITMP
|
|
LOGICAL L2, L3, L4
|
|
C
|
|
C Find smallest INTEGER*2 number.
|
|
C
|
|
ISMALL=0
|
|
10 I0 = ISMALL-1
|
|
IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
|
|
ISMALL = I0
|
|
GOTO 10
|
|
20 CONTINUE
|
|
C
|
|
C Find largest INTEGER*2 number.
|
|
C
|
|
ILARGE=0
|
|
30 I0 = ILARGE+1
|
|
IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
|
|
ILARGE = I0
|
|
GOTO 30
|
|
40 CONTINUE
|
|
C
|
|
C Multiplying by two adds stress to the situation.
|
|
C
|
|
ITWO = 2
|
|
C
|
|
C Need a number that, added to -2, is too wide to fit in I*2.
|
|
C
|
|
ITOOLG = ISMALL
|
|
C
|
|
C Use IDIM the straightforward way.
|
|
C
|
|
I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
|
|
C
|
|
C Calculate result for first interpretation.
|
|
C
|
|
I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
|
|
C
|
|
C Calculate result for second interpretation.
|
|
C
|
|
ITMP = ILARGE - ISMALL
|
|
I3 = (INT (ITMP)) * ITWO + ITOOLG
|
|
C
|
|
C Calculate result for third interpretation.
|
|
C
|
|
I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
|
|
C
|
|
C Print results.
|
|
C
|
|
PRINT *, 'ILARGE=', ILARGE
|
|
PRINT *, 'ITWO=', ITWO
|
|
PRINT *, 'ITOOLG=', ITOOLG
|
|
PRINT *, 'ISMALL=', ISMALL
|
|
PRINT *, 'I1=', I1
|
|
PRINT *, 'I2=', I2
|
|
PRINT *, 'I3=', I3
|
|
PRINT *, 'I4=', I4
|
|
PRINT *
|
|
L2 = (I1 .EQ. I2)
|
|
L3 = (I1 .EQ. I3)
|
|
L4 = (I1 .EQ. I4)
|
|
IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
|
|
PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
|
|
STOP
|
|
END IF
|
|
IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
|
|
PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
|
|
STOP
|
|
END IF
|
|
IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
|
|
PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
|
|
STOP
|
|
END IF
|
|
PRINT *, 'Results need careful analysis.'
|
|
END
|
|
@end smallexample
|
|
|
|
No future version of the GNU Fortran language
|
|
will likely permit specific intrinsic invocations with wrong-typed
|
|
arguments (such as @code{IDIM} in the above example), since
|
|
it has been determined that disagreements exist among
|
|
many production compilers on the interpretation of
|
|
such invocations.
|
|
These disagreements strongly suggest that Fortran programmers,
|
|
and certainly existing Fortran programs, disagree about the
|
|
meaning of such invocations.
|
|
|
|
The first version of @code{JCB002} didn't accommodate some compilers'
|
|
treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
|
|
@code{INTEGER*2}.
|
|
In such a case, these compilers apparently convert both
|
|
operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
|
|
instead of doing an @code{INTEGER*2} subtraction on the
|
|
original values in @samp{I1} and @samp{I2}.
|
|
|
|
However, the results of the careful analyses done on the outputs
|
|
of programs compiled by these various compilers show that they
|
|
all implement either @samp{Interp 1} or @samp{Interp 2} above.
|
|
|
|
Specifically, it is believed that the new version of @code{JCB002}
|
|
above will confirm that:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
|
|
@command{f77} compilers all implement @samp{Interp 1}.
|
|
|
|
@item
|
|
IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}.
|
|
|
|
@item
|
|
Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
|
|
and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}.
|
|
@end itemize
|
|
|
|
If you get different results than the above for the stated
|
|
compilers, or have results for other compilers that might be
|
|
worth adding to the above list, please let us know the details
|
|
(compiler product, version, machine, results, and so on).
|
|
|
|
@node REAL() and AIMAG() of Complex
|
|
@subsection @code{REAL()} and @code{AIMAG()} of Complex
|
|
@cindex @code{Real} intrinsic
|
|
@cindex intrinsics, @code{Real}
|
|
@cindex @code{AImag} intrinsic
|
|
@cindex intrinsics, @code{AImag}
|
|
|
|
The GNU Fortran language disallows @code{REAL(@var{expr})}
|
|
and @code{AIMAG(@var{expr})},
|
|
where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
|
|
except when they are used in the following way:
|
|
|
|
@example
|
|
REAL(REAL(@var{expr}))
|
|
REAL(AIMAG(@var{expr}))
|
|
@end example
|
|
|
|
@noindent
|
|
The above forms explicitly specify that the desired effect
|
|
is to convert the real or imaginary part of @var{expr}, which might
|
|
be some @code{REAL} type other than @code{REAL(KIND=1)},
|
|
to type @code{REAL(KIND=1)},
|
|
and have that serve as the value of the expression.
|
|
|
|
The GNU Fortran language offers clearly named intrinsics to extract the
|
|
real and imaginary parts of a complex entity without any
|
|
conversion:
|
|
|
|
@example
|
|
REALPART(@var{expr})
|
|
IMAGPART(@var{expr})
|
|
@end example
|
|
|
|
To express the above using typical extended FORTRAN 77,
|
|
use the following constructs
|
|
(when @var{expr} is @code{COMPLEX(KIND=2)}):
|
|
|
|
@example
|
|
DBLE(@var{expr})
|
|
DIMAG(@var{expr})
|
|
@end example
|
|
|
|
The FORTRAN 77 language offers no way
|
|
to explicitly specify the real and imaginary parts of a complex expression of
|
|
arbitrary type, apparently as a result of requiring support for
|
|
only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
|
|
The concepts of converting an expression to type @code{REAL(KIND=1)} and
|
|
of extracting the real part of a complex expression were
|
|
thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
|
|
they happened to have the exact same effect in that language
|
|
(due to having only one @code{COMPLEX} type).
|
|
|
|
@emph{Note:} When @option{-ff90} is in effect,
|
|
@command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
|
|
type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
|
|
whereas with @samp{-fugly-complex -fno-f90} in effect, it is
|
|
treated as @samp{REAL(REALPART(@var{expr}))}.
|
|
|
|
@xref{Ugly Complex Part Extraction}, for more information.
|
|
|
|
@node CMPLX() of DOUBLE PRECISION
|
|
@subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
|
|
@cindex @code{Cmplx} intrinsic
|
|
@cindex intrinsics, @code{Cmplx}
|
|
|
|
In accordance with Fortran 90 and at least some (perhaps all)
|
|
other compilers, the GNU Fortran language defines @code{CMPLX()}
|
|
as always returning a result that is type @code{COMPLEX(KIND=1)}.
|
|
|
|
This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
|
|
are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
|
|
|
|
@example
|
|
CMPLX(SNGL(D1), SNGL(D2))
|
|
@end example
|
|
|
|
(It was necessary for Fortran 90 to specify this behavior
|
|
for @code{DOUBLE PRECISION} arguments, since that is
|
|
the behavior mandated by FORTRAN 77.)
|
|
|
|
The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
|
|
which is provided by some FORTRAN 77 compilers to construct
|
|
a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
|
|
operands.
|
|
However, this solution does not scale well when more @code{COMPLEX} types
|
|
(having various precisions and ranges) are offered by Fortran implementations.
|
|
|
|
Fortran 90 extends the @code{CMPLX()} intrinsic by adding
|
|
an extra argument used to specify the desired kind of complex
|
|
result.
|
|
However, this solution is somewhat awkward to use, and
|
|
@command{g77} currently does not support it.
|
|
|
|
The GNU Fortran language provides a simple way to build a complex
|
|
value out of two numbers, with the precise type of the value
|
|
determined by the types of the two numbers (via the usual
|
|
type-promotion mechanism):
|
|
|
|
@example
|
|
COMPLEX(@var{real}, @var{imag})
|
|
@end example
|
|
|
|
When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
|
|
performs no conversion other than to put them together to form a
|
|
complex result of the same (complex version of real) type.
|
|
|
|
@xref{Complex Intrinsic}, for more information.
|
|
|
|
@node MIL-STD 1753
|
|
@subsection MIL-STD 1753 Support
|
|
@cindex MIL-STD 1753
|
|
|
|
The GNU Fortran language includes the MIL-STD 1753 intrinsics
|
|
@code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
|
|
@code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
|
|
@code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
|
|
|
|
@node f77/f2c Intrinsics
|
|
@subsection @command{f77}/@command{f2c} Intrinsics
|
|
|
|
The bit-manipulation intrinsics supported by traditional
|
|
@command{f77} and by @command{f2c} are available in the GNU Fortran language.
|
|
These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
|
|
and @code{XOR}.
|
|
|
|
Also supported are the intrinsics @code{CDABS},
|
|
@code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
|
|
@code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
|
|
@code{DIMAG}, @code{DREAL}, and @code{IMAG},
|
|
@code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
|
|
and @code{ZSQRT}.
|
|
|
|
@node Table of Intrinsic Functions
|
|
@subsection Table of Intrinsic Functions
|
|
@cindex intrinsics, table of
|
|
@cindex table of intrinsics
|
|
|
|
(Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
|
|
|
|
The GNU Fortran language adds various functions, subroutines, types,
|
|
and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
|
|
The complete set of intrinsics supported by the GNU Fortran language
|
|
is described below.
|
|
|
|
Note that a name is not treated as that of an intrinsic if it is
|
|
specified in an @code{EXTERNAL} statement in the same program unit;
|
|
if a command-line option is used to disable the groups to which
|
|
the intrinsic belongs; or if the intrinsic is not named in an
|
|
@code{INTRINSIC} statement and a command-line option is used to
|
|
hide the groups to which the intrinsic belongs.
|
|
|
|
So, it is recommended that any reference in a program unit to
|
|
an intrinsic procedure that is not a standard FORTRAN 77
|
|
intrinsic be accompanied by an appropriate @code{INTRINSIC}
|
|
statement in that program unit.
|
|
This sort of defensive programming makes it more
|
|
likely that an implementation will issue a diagnostic rather
|
|
than generate incorrect code for such a reference.
|
|
|
|
The terminology used below is based on that of the Fortran 90
|
|
standard, so that the text may be more concise and accurate:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@code{OPTIONAL} means the argument may be omitted.
|
|
|
|
@item
|
|
@samp{A-1, A-2, @dots{}, A-n} means more than one argument
|
|
(generally named @samp{A}) may be specified.
|
|
|
|
@item
|
|
@samp{scalar} means the argument must not be an array (must
|
|
be a variable or array element, or perhaps a constant if expressions
|
|
are permitted).
|
|
|
|
@item
|
|
@samp{DIMENSION(4)} means the argument must be an array having 4 elements.
|
|
|
|
@item
|
|
@code{INTENT(IN)} means the argument must be an expression
|
|
(such as a constant or a variable that is defined upon invocation
|
|
of the intrinsic).
|
|
|
|
@item
|
|
@code{INTENT(OUT)} means the argument must be definable by the
|
|
invocation of the intrinsic (that is, must not be a constant nor
|
|
an expression involving operators other than array reference and
|
|
substring reference).
|
|
|
|
@item
|
|
@code{INTENT(INOUT)} means the argument must be defined prior to,
|
|
and definable by, invocation of the intrinsic (a combination of
|
|
the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
|
|
|
|
@item
|
|
@xref{Kind Notation}, for an explanation of @code{KIND}.
|
|
@end itemize
|
|
|
|
@ifinfo
|
|
(Note that the empty lines appearing in the menu below
|
|
are not intentional---they result from a bug in the
|
|
GNU @command{makeinfo} program@dots{}a program that, if it
|
|
did not exist, would leave this document in far worse shape!)
|
|
@end ifinfo
|
|
|
|
@c The actual documentation for intrinsics comes from
|
|
@c intdoc.texi, which in turn is automatically generated
|
|
@c from the internal g77 tables in intrin.def _and_ the
|
|
@c largely hand-written text in intdoc.h. So, if you want
|
|
@c to change or add to existing documentation on intrinsics,
|
|
@c you probably want to edit intdoc.h.
|
|
@c
|
|
@set familyF77
|
|
@set familyGNU
|
|
@set familyASC
|
|
@set familyMIL
|
|
@set familyF90
|
|
@clear familyVXT
|
|
@clear familyFVZ
|
|
@set familyF2C
|
|
@set familyF2U
|
|
@clear familyBADU77
|
|
@include intdoc.texi
|
|
|
|
@node Scope and Classes of Names
|
|
@section Scope and Classes of Symbolic Names
|
|
@cindex symbol names, scope and classes
|
|
@cindex scope
|
|
|
|
(The following information augments or overrides the information in
|
|
Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
|
|
language.
|
|
Chapter 18 of that document otherwise serves as the basis
|
|
for the relevant aspects of GNU Fortran.)
|
|
|
|
@menu
|
|
* Underscores in Symbol Names::
|
|
@end menu
|
|
|
|
@node Underscores in Symbol Names
|
|
@subsection Underscores in Symbol Names
|
|
@cindex underscore
|
|
|
|
Underscores (@samp{_}) are accepted in symbol names after the first
|
|
character (which must be a letter).
|
|
|
|
@node I/O
|
|
@section I/O
|
|
|
|
@cindex dollar sign
|
|
A dollar sign at the end of an output format specification suppresses
|
|
the newline at the end of the output.
|
|
|
|
@cindex <> edit descriptor
|
|
@cindex edit descriptor, <>
|
|
Edit descriptors in @code{FORMAT} statements may contain compile-time
|
|
@code{INTEGER} constant expressions in angle brackets, such as
|
|
@smallexample
|
|
10 FORMAT (I<WIDTH>)
|
|
@end smallexample
|
|
|
|
The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
|
|
|
|
These Fortran 90 features are supported:
|
|
@itemize @bullet
|
|
@item
|
|
@cindex FORMAT descriptors
|
|
@cindex Z edit descriptor
|
|
@cindex edit descriptor, Z
|
|
@cindex O edit descriptor
|
|
@cindex edit descriptor, O
|
|
The @code{O} and @code{Z} edit descriptors are supported for I/O of
|
|
integers in octal and hexadecimal formats, respectively.
|
|
@item
|
|
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
|
|
@code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
|
|
specifier is supported.
|
|
@end itemize
|
|
|
|
@node Fortran 90 Features
|
|
@section Fortran 90 Features
|
|
@cindex Fortran 90
|
|
@cindex extensions, from Fortran 90
|
|
|
|
For convenience this section collects a list (probably incomplete) of
|
|
the Fortran 90 features supported by the GNU Fortran language, even if
|
|
they are documented elsewhere.
|
|
@xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
|
|
for information on additional fixed source form lexical issues.
|
|
@cindex @option{-ffree-form}
|
|
Further, the free source form is supported through the
|
|
@option{-ffree-form} option.
|
|
@cindex @option{-ff90}
|
|
Other Fortran 90 features can be turned on by the @option{-ff90} option;
|
|
see @ref{Fortran 90}.
|
|
For information on the Fortran 90 intrinsics available,
|
|
see @ref{Table of Intrinsic Functions}.
|
|
|
|
@table @asis
|
|
@item Automatic arrays in procedures
|
|
@item Character assignments
|
|
@cindex character assignments
|
|
In character assignments, the variable being assigned may occur on the
|
|
right hand side of the assignment.
|
|
@item Character strings
|
|
@cindex double quoted character constants
|
|
Strings may have zero length and substrings of character constants are
|
|
permitted. Character constants may be enclosed in double quotes
|
|
(@code{"}) as well as single quotes. @xref{Character Type}.
|
|
@item Construct names
|
|
(Symbolic tags on blocks.) @xref{Construct Names}.
|
|
@item @code{CYCLE} and @code{EXIT}
|
|
@xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
|
|
@item @code{DOUBLE COMPLEX}
|
|
@xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
|
|
@item @code{DO WHILE}
|
|
@xref{DO WHILE}.
|
|
@item @code{END} decoration
|
|
@xref{Statements}.
|
|
@item @code{END DO}
|
|
@xref{END DO}.
|
|
@item @code{KIND}
|
|
@item @code{IMPLICIT NONE}
|
|
@item @code{INCLUDE} statements
|
|
@xref{INCLUDE}.
|
|
@item List-directed and namelist I/O on internal files
|
|
@item Binary, octal and hexadecimal constants
|
|
These are supported more generally than required by Fortran 90.
|
|
@xref{Integer Type}.
|
|
@item @samp{O} and @samp{Z} edit descriptors
|
|
@item @code{NAMELIST}
|
|
@xref{NAMELIST}.
|
|
@item @code{OPEN} specifiers
|
|
@code{STATUS='REPLACE'} is supported.
|
|
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
|
|
@code{STATUS='SCRATCH'} is supplied.
|
|
@item @code{FORMAT} edit descriptors
|
|
@cindex FORMAT descriptors
|
|
@cindex Z edit descriptor
|
|
@cindex edit descriptor, Z
|
|
The @code{Z} edit descriptor is supported.
|
|
@item Relational operators
|
|
The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
|
|
@code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
|
|
@code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
|
|
@item @code{SELECT CASE}
|
|
Not fully implemented.
|
|
@xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
|
|
@item Specification statements
|
|
A limited subset of the Fortran 90 syntax and semantics for variable
|
|
declarations is supported, including @code{KIND}. @xref{Kind Notation}.
|
|
(@code{KIND} is of limited usefulness in the absence of the
|
|
@code{KIND}-related intrinsics, since these intrinsics permit writing
|
|
more widely portable code.) An example of supported @code{KIND} usage
|
|
is:
|
|
@smallexample
|
|
INTEGER (KIND=1) :: FOO=1, BAR=2
|
|
CHARACTER (LEN=3) FOO
|
|
@end smallexample
|
|
@code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
|
|
@end table
|
|
|
|
@node Other Dialects
|
|
@chapter Other Dialects
|
|
|
|
GNU Fortran supports a variety of features that are not
|
|
considered part of the GNU Fortran language itself, but
|
|
are representative of various dialects of Fortran that
|
|
@command{g77} supports in whole or in part.
|
|
|
|
Any of the features listed below might be disallowed by
|
|
@command{g77} unless some command-line option is specified.
|
|
Currently, some of the features are accepted using the
|
|
default invocation of @command{g77}, but that might change
|
|
in the future.
|
|
|
|
@emph{Note: This portion of the documentation definitely needs a lot
|
|
of work!}
|
|
|
|
@menu
|
|
* Source Form:: Details of fixed-form and free-form source.
|
|
* Trailing Comment:: Use of @samp{/*} to start a comment.
|
|
* Debug Line:: Use of @samp{D} in column 1.
|
|
* Dollar Signs:: Use of @samp{$} in symbolic names.
|
|
* Case Sensitivity:: Uppercase and lowercase in source files.
|
|
* VXT Fortran:: @dots{}versus the GNU Fortran language.
|
|
* Fortran 90:: @dots{}versus the GNU Fortran language.
|
|
* Pedantic Compilation:: Enforcing the standard.
|
|
* Distensions:: Misfeatures supported by GNU Fortran.
|
|
@end menu
|
|
|
|
@node Source Form
|
|
@section Source Form
|
|
@cindex source file format
|
|
@cindex source format
|
|
@cindex file, source
|
|
@cindex source code
|
|
@cindex code, source
|
|
@cindex fixed form
|
|
@cindex free form
|
|
|
|
GNU Fortran accepts programs written in either fixed form or
|
|
free form.
|
|
|
|
Fixed form
|
|
corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
|
|
allowing tabs) and Fortran 90's fixed form.
|
|
|
|
Free form corresponds to
|
|
Fortran 90's free form (though possibly not entirely up-to-date, and
|
|
without complaining about some things that for which Fortran 90 requires
|
|
diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
|
|
|
|
The way a Fortran compiler views source files depends entirely on the
|
|
implementation choices made for the compiler, since those choices
|
|
are explicitly left to the implementation by the published Fortran
|
|
standards.
|
|
GNU Fortran currently tries to be somewhat like a few popular compilers
|
|
(@command{f2c}, Digital (``DEC'') Fortran, and so on).
|
|
|
|
This section describes how @command{g77} interprets source lines.
|
|
|
|
@menu
|
|
* Carriage Returns:: Carriage returns ignored.
|
|
* Tabs:: Tabs converted to spaces.
|
|
* Short Lines:: Short lines padded with spaces (fixed-form only).
|
|
* Long Lines:: Long lines truncated.
|
|
* Ampersands:: Special Continuation Lines.
|
|
@end menu
|
|
|
|
@node Carriage Returns
|
|
@subsection Carriage Returns
|
|
@cindex carriage returns
|
|
|
|
Carriage returns (@samp{\r}) in source lines are ignored.
|
|
This is somewhat different from @command{f2c}, which seems to treat them as
|
|
spaces outside character/Hollerith constants, and encodes them as @samp{\r}
|
|
inside such constants.
|
|
|
|
@node Tabs
|
|
@subsection Tabs
|
|
@cindex tab character
|
|
@cindex horizontal tab
|
|
|
|
A source line with a @key{TAB} character anywhere in it is treated as
|
|
entirely significant---however long it is---instead of ending in
|
|
column 72 (for fixed-form source) or 132 (for free-form source).
|
|
This also is different from @command{f2c}, which encodes tabs as
|
|
@samp{\t} (the ASCII @key{TAB} character) inside character
|
|
and Hollerith constants, but nevertheless seems to treat the column
|
|
position as if it had been affected by the canonical tab positioning.
|
|
|
|
@command{g77} effectively
|
|
translates tabs to the appropriate number of spaces (a la the default
|
|
for the UNIX @command{expand} command) before doing any other processing, other
|
|
than (currently) noting whether a tab was found on a line and using this
|
|
information to decide how to interpret the length of the line and continued
|
|
constants.
|
|
|
|
@node Short Lines
|
|
@subsection Short Lines
|
|
@cindex short source lines
|
|
@cindex space, padding with
|
|
@cindex source lines, short
|
|
@cindex lines, short
|
|
|
|
Source lines shorter than the applicable fixed-form length are treated as
|
|
if they were padded with spaces to that length.
|
|
(None of this is relevant to source files written in free form.)
|
|
|
|
This affects only
|
|
continued character and Hollerith constants, and is a different
|
|
interpretation than provided by some other popular compilers
|
|
(although a bit more consistent with the traditional punched-card
|
|
basis of Fortran and the way the Fortran standard expressed fixed
|
|
source form).
|
|
|
|
@command{g77} might someday offer an option to warn about cases where differences
|
|
might be seen as a result of this treatment, and perhaps an option to
|
|
specify the alternate behavior as well.
|
|
|
|
Note that this padding cannot apply to lines that are effectively of
|
|
infinite length---such lines are specified using command-line options
|
|
like @option{-ffixed-line-length-none}, for example.
|
|
|
|
@node Long Lines
|
|
@subsection Long Lines
|
|
@cindex long source lines
|
|
@cindex truncation, of long lines
|
|
@cindex lines, long
|
|
@cindex source lines, long
|
|
|
|
Source lines longer than the applicable length are truncated to that
|
|
length.
|
|
Currently, @command{g77} does not warn if the truncated characters are
|
|
not spaces, to accommodate existing code written for systems that
|
|
treated truncated text as commentary (especially in columns 73 through 80).
|
|
|
|
@xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
|
|
for information on the @option{-ffixed-line-length-@var{n}} option,
|
|
which can be used to set the line length applicable to fixed-form
|
|
source files.
|
|
|
|
@node Ampersands
|
|
@subsection Ampersand Continuation Line
|
|
@cindex ampersand continuation line
|
|
@cindex continuation line, ampersand
|
|
|
|
A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
|
|
continuation line, imitating the behavior of @command{f2c}.
|
|
|
|
@node Trailing Comment
|
|
@section Trailing Comment
|
|
|
|
@cindex trailing comment
|
|
@cindex comment
|
|
@cindex characters, comment
|
|
@cindex /*
|
|
@cindex !
|
|
@cindex exclamation point
|
|
@command{g77} supports use of @samp{/*} to start a trailing
|
|
comment.
|
|
In the GNU Fortran language, @samp{!} is used for this purpose.
|
|
|
|
@samp{/*} is not in the GNU Fortran language
|
|
because the use of @samp{/*} in a program might
|
|
suggest to some readers that a block, not trailing, comment is
|
|
started (and thus ended by @samp{*/}, not end of line),
|
|
since that is the meaning of @samp{/*} in C.
|
|
|
|
Also, such readers might think they can use @samp{//} to start
|
|
a trailing comment as an alternative to @samp{/*}, but
|
|
@samp{//} already denotes concatenation, and such a ``comment''
|
|
might actually result in a program that compiles without
|
|
error (though it would likely behave incorrectly).
|
|
|
|
@node Debug Line
|
|
@section Debug Line
|
|
@cindex debug line
|
|
@cindex comment line, debug
|
|
|
|
Use of @samp{D} or @samp{d} as the first character (column 1) of
|
|
a source line denotes a debug line.
|
|
|
|
In turn, a debug line is treated as either a comment line
|
|
or a normal line, depending on whether debug lines are enabled.
|
|
|
|
When treated as a comment line, a line beginning with @samp{D} or
|
|
@samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
|
|
When treated as a normal line, such a line is treated as if
|
|
the first character was @key{SPC} (space).
|
|
|
|
(Currently, @command{g77} provides no means for treating debug
|
|
lines as normal lines.)
|
|
|
|
@node Dollar Signs
|
|
@section Dollar Signs in Symbol Names
|
|
@cindex dollar sign
|
|
@cindex $
|
|
|
|
Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
|
|
when the @option{-fdollar-ok} option is specified.
|
|
|
|
@node Case Sensitivity
|
|
@section Case Sensitivity
|
|
@cindex case sensitivity
|
|
@cindex source file format
|
|
@cindex code, source
|
|
@cindex source code
|
|
@cindex uppercase letters
|
|
@cindex lowercase letters
|
|
@cindex letters, uppercase
|
|
@cindex letters, lowercase
|
|
|
|
GNU Fortran offers the programmer way too much flexibility in deciding
|
|
how source files are to be treated vis-a-vis uppercase and lowercase
|
|
characters.
|
|
There are 66 useful settings that affect case sensitivity, plus 10
|
|
settings that are nearly useless, with the remaining 116 settings
|
|
being either redundant or useless.
|
|
|
|
None of these settings have any effect on the contents of comments
|
|
(the text after a @samp{c} or @samp{C} in Column 1, for example)
|
|
or of character or Hollerith constants.
|
|
Note that things like the @samp{E} in the statement
|
|
@samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
|
|
are considered built-in keywords, and so are affected by
|
|
these settings.
|
|
|
|
Low-level switches are identified in this section as follows:
|
|
|
|
@itemize @w{}
|
|
@item A
|
|
Source Case Conversion:
|
|
|
|
@itemize @w{}
|
|
@item 0
|
|
Preserve (see Note 1)
|
|
@item 1
|
|
Convert to Upper Case
|
|
@item 2
|
|
Convert to Lower Case
|
|
@end itemize
|
|
|
|
@item B
|
|
Built-in Keyword Matching:
|
|
|
|
@itemize @w{}
|
|
@item 0
|
|
Match Any Case (per-character basis)
|
|
@item 1
|
|
Match Upper Case Only
|
|
@item 2
|
|
Match Lower Case Only
|
|
@item 3
|
|
Match InitialCaps Only (see tables for spellings)
|
|
@end itemize
|
|
|
|
@item C
|
|
Built-in Intrinsic Matching:
|
|
|
|
@itemize @w{}
|
|
@item 0
|
|
Match Any Case (per-character basis)
|
|
@item 1
|
|
Match Upper Case Only
|
|
@item 2
|
|
Match Lower Case Only
|
|
@item 3
|
|
Match InitialCaps Only (see tables for spellings)
|
|
@end itemize
|
|
|
|
@item D
|
|
User-defined Symbol Possibilities (warnings only):
|
|
|
|
@itemize @w{}
|
|
@item 0
|
|
Allow Any Case (per-character basis)
|
|
@item 1
|
|
Allow Upper Case Only
|
|
@item 2
|
|
Allow Lower Case Only
|
|
@item 3
|
|
Allow InitialCaps Only (see Note 2)
|
|
@end itemize
|
|
@end itemize
|
|
|
|
Note 1: @command{g77} eventually will support @code{NAMELIST} in a manner that is
|
|
consistent with these source switches---in the sense that input will be
|
|
expected to meet the same requirements as source code in terms
|
|
of matching symbol names and keywords (for the exponent letters).
|
|
|
|
Currently, however, @code{NAMELIST} is supported by @code{libg2c},
|
|
which uppercases @code{NAMELIST} input and symbol names for matching.
|
|
This means not only that @code{NAMELIST} output currently shows symbol
|
|
(and keyword) names in uppercase even if lower-case source
|
|
conversion (option A2) is selected, but that @code{NAMELIST} cannot be
|
|
adequately supported when source case preservation (option A0)
|
|
is selected.
|
|
|
|
If A0 is selected, a warning message will be
|
|
output for each @code{NAMELIST} statement to this effect.
|
|
The behavior
|
|
of the program is undefined at run time if two or more symbol names
|
|
appear in a given @code{NAMELIST} such that the names are identical
|
|
when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
|
|
For complete and total elegance, perhaps there should be a warning
|
|
when option A2 is selected, since the output of NAMELIST is currently
|
|
in uppercase but will someday be lowercase (when a @code{libg77} is written),
|
|
but that seems to be overkill for a product in beta test.
|
|
|
|
Note 2: Rules for InitialCaps names are:
|
|
|
|
@itemize @minus
|
|
@item
|
|
Must be a single uppercase letter, @strong{or}
|
|
@item
|
|
Must start with an uppercase letter and contain at least one
|
|
lowercase letter.
|
|
@end itemize
|
|
|
|
So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
|
|
valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
|
|
not.
|
|
Note that most, but not all, built-in names meet these
|
|
requirements---the exceptions are some of the two-letter format
|
|
specifiers, such as @code{BN} and @code{BZ}.
|
|
|
|
Here are the names of the corresponding command-line options:
|
|
|
|
@smallexample
|
|
A0: -fsource-case-preserve
|
|
A1: -fsource-case-upper
|
|
A2: -fsource-case-lower
|
|
|
|
B0: -fmatch-case-any
|
|
B1: -fmatch-case-upper
|
|
B2: -fmatch-case-lower
|
|
B3: -fmatch-case-initcap
|
|
|
|
C0: -fintrin-case-any
|
|
C1: -fintrin-case-upper
|
|
C2: -fintrin-case-lower
|
|
C3: -fintrin-case-initcap
|
|
|
|
D0: -fsymbol-case-any
|
|
D1: -fsymbol-case-upper
|
|
D2: -fsymbol-case-lower
|
|
D3: -fsymbol-case-initcap
|
|
@end smallexample
|
|
|
|
Useful combinations of the above settings, along with abbreviated
|
|
option names that set some of these combinations all at once:
|
|
|
|
@smallexample
|
|
1: A0-- B0--- C0--- D0--- -fcase-preserve
|
|
2: A0-- B0--- C0--- D-1--
|
|
3: A0-- B0--- C0--- D--2-
|
|
4: A0-- B0--- C0--- D---3
|
|
5: A0-- B0--- C-1-- D0---
|
|
6: A0-- B0--- C-1-- D-1--
|
|
7: A0-- B0--- C-1-- D--2-
|
|
8: A0-- B0--- C-1-- D---3
|
|
9: A0-- B0--- C--2- D0---
|
|
10: A0-- B0--- C--2- D-1--
|
|
11: A0-- B0--- C--2- D--2-
|
|
12: A0-- B0--- C--2- D---3
|
|
13: A0-- B0--- C---3 D0---
|
|
14: A0-- B0--- C---3 D-1--
|
|
15: A0-- B0--- C---3 D--2-
|
|
16: A0-- B0--- C---3 D---3
|
|
17: A0-- B-1-- C0--- D0---
|
|
18: A0-- B-1-- C0--- D-1--
|
|
19: A0-- B-1-- C0--- D--2-
|
|
20: A0-- B-1-- C0--- D---3
|
|
21: A0-- B-1-- C-1-- D0---
|
|
22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
|
|
23: A0-- B-1-- C-1-- D--2-
|
|
24: A0-- B-1-- C-1-- D---3
|
|
25: A0-- B-1-- C--2- D0---
|
|
26: A0-- B-1-- C--2- D-1--
|
|
27: A0-- B-1-- C--2- D--2-
|
|
28: A0-- B-1-- C--2- D---3
|
|
29: A0-- B-1-- C---3 D0---
|
|
30: A0-- B-1-- C---3 D-1--
|
|
31: A0-- B-1-- C---3 D--2-
|
|
32: A0-- B-1-- C---3 D---3
|
|
33: A0-- B--2- C0--- D0---
|
|
34: A0-- B--2- C0--- D-1--
|
|
35: A0-- B--2- C0--- D--2-
|
|
36: A0-- B--2- C0--- D---3
|
|
37: A0-- B--2- C-1-- D0---
|
|
38: A0-- B--2- C-1-- D-1--
|
|
39: A0-- B--2- C-1-- D--2-
|
|
40: A0-- B--2- C-1-- D---3
|
|
41: A0-- B--2- C--2- D0---
|
|
42: A0-- B--2- C--2- D-1--
|
|
43: A0-- B--2- C--2- D--2- -fcase-strict-lower
|
|
44: A0-- B--2- C--2- D---3
|
|
45: A0-- B--2- C---3 D0---
|
|
46: A0-- B--2- C---3 D-1--
|
|
47: A0-- B--2- C---3 D--2-
|
|
48: A0-- B--2- C---3 D---3
|
|
49: A0-- B---3 C0--- D0---
|
|
50: A0-- B---3 C0--- D-1--
|
|
51: A0-- B---3 C0--- D--2-
|
|
52: A0-- B---3 C0--- D---3
|
|
53: A0-- B---3 C-1-- D0---
|
|
54: A0-- B---3 C-1-- D-1--
|
|
55: A0-- B---3 C-1-- D--2-
|
|
56: A0-- B---3 C-1-- D---3
|
|
57: A0-- B---3 C--2- D0---
|
|
58: A0-- B---3 C--2- D-1--
|
|
59: A0-- B---3 C--2- D--2-
|
|
60: A0-- B---3 C--2- D---3
|
|
61: A0-- B---3 C---3 D0---
|
|
62: A0-- B---3 C---3 D-1--
|
|
63: A0-- B---3 C---3 D--2-
|
|
64: A0-- B---3 C---3 D---3 -fcase-initcap
|
|
65: A-1- B01-- C01-- D01-- -fcase-upper
|
|
66: A--2 B0-2- C0-2- D0-2- -fcase-lower
|
|
@end smallexample
|
|
|
|
Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
|
|
(except comments, character constants, and Hollerith strings) must
|
|
be entered in uppercase.
|
|
Use @option{-fcase-strict-upper} to specify this
|
|
combination.
|
|
|
|
Number 43 is like Number 22 except all input must be lowercase. Use
|
|
@option{-fcase-strict-lower} to specify this combination.
|
|
|
|
Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
|
|
non-UNIX machines whereby all the source is translated to uppercase.
|
|
Use @option{-fcase-upper} to specify this combination.
|
|
|
|
Number 66 is the ``canonical'' UNIX model whereby all the source is
|
|
translated to lowercase.
|
|
Use @option{-fcase-lower} to specify this combination.
|
|
|
|
There are a few nearly useless combinations:
|
|
|
|
@smallexample
|
|
67: A-1- B01-- C01-- D--2-
|
|
68: A-1- B01-- C01-- D---3
|
|
69: A-1- B01-- C--23 D01--
|
|
70: A-1- B01-- C--23 D--2-
|
|
71: A-1- B01-- C--23 D---3
|
|
72: A--2 B01-- C0-2- D-1--
|
|
73: A--2 B01-- C0-2- D---3
|
|
74: A--2 B01-- C-1-3 D0-2-
|
|
75: A--2 B01-- C-1-3 D-1--
|
|
76: A--2 B01-- C-1-3 D---3
|
|
@end smallexample
|
|
|
|
The above allow some programs to be compiled but with restrictions that
|
|
make most useful programs impossible: Numbers 67 and 72 warn about
|
|
@emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
|
|
Numbers
|
|
68 and 73 warn about any user-defined symbol names longer than one
|
|
character that don't have at least one non-alphabetic character after
|
|
the first;
|
|
Numbers 69 and 74 disallow any references to intrinsics;
|
|
and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
|
|
67+69, 68+69, 72+74, and 73+74, respectively.
|
|
|
|
All redundant combinations are shown in the above tables anyplace
|
|
where more than one setting is shown for a low-level switch.
|
|
For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
|
|
The ``proper'' setting in such a case is the one that copies the setting
|
|
of switch A---any other setting might slightly reduce the speed of
|
|
the compiler, though possibly to an unmeasurable extent.
|
|
|
|
All remaining combinations are useless in that they prevent successful
|
|
compilation of non-null source files (source files with something other
|
|
than comments).
|
|
|
|
@node VXT Fortran
|
|
@section VXT Fortran
|
|
|
|
@cindex VXT extensions
|
|
@cindex extensions, VXT
|
|
@command{g77} supports certain constructs that
|
|
have different meanings in VXT Fortran than they
|
|
do in the GNU Fortran language.
|
|
|
|
Generally, this manual uses the invented term VXT Fortran to refer
|
|
VAX FORTRAN (circa v4).
|
|
That compiler offered many popular features, though not necessarily
|
|
those that are specific to the VAX processor architecture,
|
|
the VMS operating system,
|
|
or Digital Equipment Corporation's Fortran product line.
|
|
(VAX and VMS probably are trademarks of Digital Equipment
|
|
Corporation.)
|
|
|
|
An extension offered by a Digital Fortran product that also is
|
|
offered by several other Fortran products for different kinds of
|
|
systems is probably going to be considered for inclusion in @command{g77}
|
|
someday, and is considered a VXT Fortran feature.
|
|
|
|
The @option{-fvxt} option generally specifies that, where
|
|
the meaning of a construct is ambiguous (means one thing
|
|
in GNU Fortran and another in VXT Fortran), the VXT Fortran
|
|
meaning is to be assumed.
|
|
|
|
@menu
|
|
* Double Quote Meaning:: @samp{"2000} as octal constant.
|
|
* Exclamation Point:: @samp{!} in column 6.
|
|
@end menu
|
|
|
|
@node Double Quote Meaning
|
|
@subsection Meaning of Double Quote
|
|
@cindex double quotes
|
|
@cindex character constants
|
|
@cindex constants, character
|
|
@cindex octal constants
|
|
@cindex constants, octal
|
|
|
|
@command{g77} treats double-quote (@samp{"})
|
|
as beginning an octal constant of @code{INTEGER(KIND=1)} type
|
|
when the @option{-fvxt} option is specified.
|
|
The form of this octal constant is
|
|
|
|
@example
|
|
"@var{octal-digits}
|
|
@end example
|
|
|
|
@noindent
|
|
where @var{octal-digits} is a nonempty string of characters in
|
|
the set @samp{01234567}.
|
|
|
|
For example, the @option{-fvxt} option permits this:
|
|
|
|
@example
|
|
PRINT *, "20
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
The above program would print the value @samp{16}.
|
|
|
|
@xref{Integer Type}, for information on the preferred construct
|
|
for integer constants specified using GNU Fortran's octal notation.
|
|
|
|
(In the GNU Fortran language, the double-quote character (@samp{"})
|
|
delimits a character constant just as does apostrophe (@samp{'}).
|
|
There is no way to allow
|
|
both constructs in the general case, since statements like
|
|
@samp{PRINT *,"2000 !comment?"} would be ambiguous.)
|
|
|
|
@node Exclamation Point
|
|
@subsection Meaning of Exclamation Point in Column 6
|
|
@cindex !
|
|
@cindex exclamation point
|
|
@cindex continuation character
|
|
@cindex characters, continuation
|
|
@cindex comment character
|
|
@cindex characters, comment
|
|
|
|
@command{g77} treats an exclamation point (@samp{!}) in column 6 of
|
|
a fixed-form source file
|
|
as a continuation character rather than
|
|
as the beginning of a comment
|
|
(as it does in any other column)
|
|
when the @option{-fvxt} option is specified.
|
|
|
|
The following program, when run, prints a message indicating
|
|
whether it is interpreted according to GNU Fortran (and Fortran 90)
|
|
rules or VXT Fortran rules:
|
|
|
|
@smallexample
|
|
C234567 (This line begins in column 1.)
|
|
I = 0
|
|
!1
|
|
IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
|
|
IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
|
|
IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
|
|
END
|
|
@end smallexample
|
|
|
|
(In the GNU Fortran and Fortran 90 languages, exclamation point is
|
|
a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
|
|
marks a line as a continuation line when it appears in column 6.)
|
|
|
|
@node Fortran 90
|
|
@section Fortran 90
|
|
@cindex compatibility, Fortran 90
|
|
@cindex Fortran 90, compatibility
|
|
|
|
The GNU Fortran language includes a number of features that are
|
|
part of Fortran 90, even when the @option{-ff90} option is not specified.
|
|
The features enabled by @option{-ff90} are intended to be those that,
|
|
when @option{-ff90} is not specified, would have another
|
|
meaning to @command{g77}---usually meaning something invalid in the
|
|
GNU Fortran language.
|
|
|
|
So, the purpose of @option{-ff90} is not to specify whether @command{g77} is
|
|
to gratuitously reject Fortran 90 constructs.
|
|
The @option{-pedantic} option specified with @option{-fno-f90} is intended
|
|
to do that, although its implementation is certainly incomplete at
|
|
this point.
|
|
|
|
When @option{-ff90} is specified:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
|
|
where @var{expr} is @code{COMPLEX} type,
|
|
is the same type as the real part of @var{expr}.
|
|
|
|
For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
|
|
@samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
|
|
not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified.
|
|
@end itemize
|
|
|
|
@node Pedantic Compilation
|
|
@section Pedantic Compilation
|
|
@cindex pedantic compilation
|
|
@cindex compilation, pedantic
|
|
|
|
The @option{-fpedantic} command-line option specifies that @command{g77}
|
|
is to warn about code that is not standard-conforming.
|
|
This is useful for finding
|
|
some extensions @command{g77} accepts that other compilers might not accept.
|
|
(Note that the @option{-pedantic} and @option{-pedantic-errors} options
|
|
always imply @option{-fpedantic}.)
|
|
|
|
With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
|
|
for conforming code.
|
|
With @option{-ff90} in force, Fortran 90 is used.
|
|
|
|
The constructs for which @command{g77} issues diagnostics when @option{-fpedantic}
|
|
and @option{-fno-f90} are in force are:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Automatic arrays, as in
|
|
|
|
@example
|
|
SUBROUTINE X(N)
|
|
REAL A(N)
|
|
@dots{}
|
|
@end example
|
|
|
|
@noindent
|
|
where @samp{A} is not listed in any @code{ENTRY} statement,
|
|
and thus is not a dummy argument.
|
|
|
|
@item
|
|
The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
|
|
|
|
These commas are disallowed by FORTRAN 77, but, while strictly
|
|
superfluous, are syntactically elegant,
|
|
especially given that commas are required in statements such
|
|
as @samp{READ 99, I} and @samp{PRINT *, J}.
|
|
Many compilers permit the superfluous commas for this reason.
|
|
|
|
@item
|
|
@code{DOUBLE COMPLEX}, either explicitly or implicitly.
|
|
|
|
An explicit use of this type is via a @code{DOUBLE COMPLEX} or
|
|
@code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
|
|
|
|
An example of an implicit use is the expression @samp{C*D},
|
|
where @samp{C} is @code{COMPLEX(KIND=1)}
|
|
and @samp{D} is @code{DOUBLE PRECISION}.
|
|
This expression is prohibited by ANSI FORTRAN 77
|
|
because the rules of promotion would suggest that it
|
|
produce a @code{DOUBLE COMPLEX} result---a type not
|
|
provided for by that standard.
|
|
|
|
@item
|
|
Automatic conversion of numeric
|
|
expressions to @code{INTEGER(KIND=1)} in contexts such as:
|
|
|
|
@itemize @minus
|
|
@item
|
|
Array-reference indexes.
|
|
@item
|
|
Alternate-return values.
|
|
@item
|
|
Computed @code{GOTO}.
|
|
@item
|
|
@code{FORMAT} run-time expressions (not yet supported).
|
|
@item
|
|
Dimension lists in specification statements.
|
|
@item
|
|
Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
|
|
@item
|
|
Sizes of @code{CHARACTER} entities in specification statements.
|
|
@item
|
|
Kind types in specification entities (a Fortran 90 feature).
|
|
@item
|
|
Initial, terminal, and incrementation parameters for implied-@code{DO}
|
|
constructs in @code{DATA} statements.
|
|
@end itemize
|
|
|
|
@item
|
|
Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
|
|
in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
|
|
expressions are disallowed anyway).
|
|
|
|
@item
|
|
Zero-size array dimensions, as in:
|
|
|
|
@example
|
|
INTEGER I(10,20,4:2)
|
|
@end example
|
|
|
|
@item
|
|
Zero-length @code{CHARACTER} entities, as in:
|
|
|
|
@example
|
|
PRINT *, ''
|
|
@end example
|
|
|
|
@item
|
|
Substring operators applied to character constants and named
|
|
constants, as in:
|
|
|
|
@example
|
|
PRINT *, 'hello'(3:5)
|
|
@end example
|
|
|
|
@item
|
|
Null arguments passed to statement function, as in:
|
|
|
|
@example
|
|
PRINT *, FOO(,3)
|
|
@end example
|
|
|
|
@item
|
|
Disagreement among program units regarding whether a given @code{COMMON}
|
|
area is @code{SAVE}d (for targets where program units in a single source
|
|
file are ``glued'' together as they typically are for UNIX development
|
|
environments).
|
|
|
|
@item
|
|
Disagreement among program units regarding the size of a
|
|
named @code{COMMON} block.
|
|
|
|
@item
|
|
Specification statements following first @code{DATA} statement.
|
|
|
|
(In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
|
|
but not @samp{INTEGER I}.
|
|
The @option{-fpedantic} option disallows both of these.)
|
|
|
|
@item
|
|
Semicolon as statement separator, as in:
|
|
|
|
@example
|
|
CALL FOO; CALL BAR
|
|
@end example
|
|
@c
|
|
@c @item
|
|
@c Comma before list of I/O items in @code{WRITE}
|
|
@c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
|
|
@c statements, as with @code{READ} (as explained above).
|
|
|
|
@item
|
|
Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
|
|
|
|
@item
|
|
Use of @code{CHARACTER} constants to initialize numeric entities, and vice
|
|
versa.
|
|
|
|
@item
|
|
Expressions having two arithmetic operators in a row, such
|
|
as @samp{X*-Y}.
|
|
@end itemize
|
|
|
|
If @option{-fpedantic} is specified along with @option{-ff90}, the
|
|
following constructs result in diagnostics:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Use of semicolon as a statement separator on a line
|
|
that has an @code{INCLUDE} directive.
|
|
@end itemize
|
|
|
|
@node Distensions
|
|
@section Distensions
|
|
@cindex distensions
|
|
@cindex ugly features
|
|
@cindex features, ugly
|
|
|
|
The @option{-fugly-*} command-line options determine whether certain
|
|
features supported by VAX FORTRAN and other such compilers, but considered
|
|
too ugly to be in code that can be changed to use safer and/or more
|
|
portable constructs, are accepted.
|
|
These are humorously referred to as ``distensions'',
|
|
extensions that just plain look ugly in the harsh light of day.
|
|
|
|
@menu
|
|
* Ugly Implicit Argument Conversion:: Disabled via @option{-fno-ugly-args}.
|
|
* Ugly Assumed-Size Arrays:: Enabled via @option{-fugly-assumed}.
|
|
* Ugly Null Arguments:: Enabled via @option{-fugly-comma}.
|
|
* Ugly Complex Part Extraction:: Enabled via @option{-fugly-complex}.
|
|
* Ugly Conversion of Initializers:: Disabled via @option{-fno-ugly-init}.
|
|
* Ugly Integer Conversions:: Enabled via @option{-fugly-logint}.
|
|
* Ugly Assigned Labels:: Enabled via @option{-fugly-assign}.
|
|
@end menu
|
|
|
|
@node Ugly Implicit Argument Conversion
|
|
@subsection Implicit Argument Conversion
|
|
@cindex Hollerith constants
|
|
@cindex constants, Hollerith
|
|
|
|
The @option{-fno-ugly-args} option disables
|
|
passing typeless and Hollerith constants as actual arguments
|
|
in procedure invocations.
|
|
For example:
|
|
|
|
@example
|
|
CALL FOO(4HABCD)
|
|
CALL BAR('123'O)
|
|
@end example
|
|
|
|
@noindent
|
|
These constructs can be too easily used to create non-portable
|
|
code, but are not considered as ``ugly'' as others.
|
|
Further, they are widely used in existing Fortran source code
|
|
in ways that often are quite portable.
|
|
Therefore, they are enabled by default.
|
|
|
|
@node Ugly Assumed-Size Arrays
|
|
@subsection Ugly Assumed-Size Arrays
|
|
@cindex arrays, assumed-size
|
|
@cindex assumed-size arrays
|
|
@cindex DIMENSION X(1)
|
|
|
|
The @option{-fugly-assumed} option enables
|
|
the treatment of any array with a final dimension specified as @samp{1}
|
|
as an assumed-size array, as if @samp{*} had been specified
|
|
instead.
|
|
|
|
For example, @samp{DIMENSION X(1)} is treated as if it
|
|
had read @samp{DIMENSION X(*)} if @samp{X} is listed as
|
|
a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
|
|
or @code{ENTRY} statement in the same program unit.
|
|
|
|
Use an explicit lower bound to avoid this interpretation.
|
|
For example, @samp{DIMENSION X(1:1)} is never treated as if
|
|
it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
|
|
Nor is @samp{DIMENSION X(2-1)} affected by this option,
|
|
since that kind of expression is unlikely to have been
|
|
intended to designate an assumed-size array.
|
|
|
|
This option is used to prevent warnings being issued about apparent
|
|
out-of-bounds reference such as @samp{X(2) = 99}.
|
|
|
|
It also prevents the array from being used in contexts that
|
|
disallow assumed-size arrays, such as @samp{PRINT *,X}.
|
|
In such cases, a diagnostic is generated and the source file is
|
|
not compiled.
|
|
|
|
The construct affected by this option is used only in old code
|
|
that pre-exists the widespread acceptance of adjustable and assumed-size
|
|
arrays in the Fortran community.
|
|
|
|
@emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
|
|
treated if @samp{X} is listed as a dummy argument only
|
|
@emph{after} the @code{DIMENSION} statement (presumably in
|
|
an @code{ENTRY} statement).
|
|
For example, @option{-fugly-assumed} has no effect on the
|
|
following program unit:
|
|
|
|
@example
|
|
SUBROUTINE X
|
|
REAL A(1)
|
|
RETURN
|
|
ENTRY Y(A)
|
|
PRINT *, A
|
|
END
|
|
@end example
|
|
|
|
@node Ugly Complex Part Extraction
|
|
@subsection Ugly Complex Part Extraction
|
|
@cindex complex values
|
|
@cindex real part
|
|
@cindex imaginary part
|
|
|
|
The @option{-fugly-complex} option enables
|
|
use of the @code{REAL()} and @code{AIMAG()}
|
|
intrinsics with arguments that are
|
|
@code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
|
|
|
|
With @option{-ff90} in effect, these intrinsics return
|
|
the unconverted real and imaginary parts (respectively)
|
|
of their argument.
|
|
|
|
With @option{-fno-f90} in effect, these intrinsics convert
|
|
the real and imaginary parts to @code{REAL(KIND=1)}, and return
|
|
the result of that conversion.
|
|
|
|
Due to this ambiguity, the GNU Fortran language defines
|
|
these constructs as invalid, except in the specific
|
|
case where they are entirely and solely passed as an
|
|
argument to an invocation of the @code{REAL()} intrinsic.
|
|
For example,
|
|
|
|
@example
|
|
REAL(REAL(Z))
|
|
@end example
|
|
|
|
@noindent
|
|
is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
|
|
and @option{-fno-ugly-complex} is in effect, because the
|
|
meaning is clear.
|
|
|
|
@command{g77} enforces this restriction, unless @option{-fugly-complex}
|
|
is specified, in which case the appropriate interpretation is
|
|
chosen and no diagnostic is issued.
|
|
|
|
@xref{CMPAMBIG}, for information on how to cope with existing
|
|
code with unclear expectations of @code{REAL()} and @code{AIMAG()}
|
|
with @code{COMPLEX(KIND=2)} arguments.
|
|
|
|
@xref{RealPart Intrinsic}, for information on the @code{REALPART()}
|
|
intrinsic, used to extract the real part of a complex expression
|
|
without conversion.
|
|
@xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
|
|
intrinsic, used to extract the imaginary part of a complex expression
|
|
without conversion.
|
|
|
|
@node Ugly Null Arguments
|
|
@subsection Ugly Null Arguments
|
|
@cindex trailing comma
|
|
@cindex comma, trailing
|
|
@cindex characters, comma
|
|
@cindex null arguments
|
|
@cindex arguments, null
|
|
|
|
The @option{-fugly-comma} option enables use of a single trailing comma
|
|
to mean ``pass an extra trailing null argument''
|
|
in a list of actual arguments to an external procedure,
|
|
and use of an empty list of arguments to such a procedure
|
|
to mean ``pass a single null argument''.
|
|
|
|
@cindex omitting arguments
|
|
@cindex arguments, omitting
|
|
(Null arguments often are used in some procedure-calling
|
|
schemes to indicate omitted arguments.)
|
|
|
|
For example, @samp{CALL FOO(,)} means ``pass
|
|
two null arguments'', rather than ``pass one null argument''.
|
|
Also, @samp{CALL BAR()} means ``pass one null argument''.
|
|
|
|
This construct is considered ``ugly'' because it does not
|
|
provide an elegant way to pass a single null argument
|
|
that is syntactically distinct from passing no arguments.
|
|
That is, this construct changes the meaning of code that
|
|
makes no use of the construct.
|
|
|
|
So, with @option{-fugly-comma} in force, @samp{CALL FOO()}
|
|
and @samp{I = JFUNC()} pass a single null argument, instead
|
|
of passing no arguments as required by the Fortran 77 and
|
|
90 standards.
|
|
|
|
@emph{Note:} Many systems gracefully allow the case
|
|
where a procedure call passes one extra argument that the
|
|
called procedure does not expect.
|
|
|
|
So, in practice, there might be no difference in
|
|
the behavior of a program that does @samp{CALL FOO()}
|
|
or @samp{I = JFUNC()} and is compiled with @option{-fugly-comma}
|
|
in force as compared to its behavior when compiled
|
|
with the default, @option{-fno-ugly-comma}, in force,
|
|
assuming @samp{FOO} and @samp{JFUNC} do not expect any
|
|
arguments to be passed.
|
|
|
|
@node Ugly Conversion of Initializers
|
|
@subsection Ugly Conversion of Initializers
|
|
|
|
The constructs disabled by @option{-fno-ugly-init} are:
|
|
|
|
@itemize @bullet
|
|
@cindex Hollerith constants
|
|
@cindex constants, Hollerith
|
|
@item
|
|
Use of Hollerith and typeless constants in contexts where they set
|
|
initial (compile-time) values for variables, arrays, and named
|
|
constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
|
|
type-declaration statements specifying initial values.
|
|
|
|
Here are some sample initializations that are disabled by the
|
|
@option{-fno-ugly-init} option:
|
|
|
|
@example
|
|
PARAMETER (VAL='9A304FFE'X)
|
|
REAL*8 STRING/8HOUTPUT00/
|
|
DATA VAR/4HABCD/
|
|
@end example
|
|
|
|
@cindex character constants
|
|
@cindex constants, character
|
|
@item
|
|
In the same contexts as above, use of character constants to initialize
|
|
numeric items and vice versa (one constant per item).
|
|
|
|
Here are more sample initializations that are disabled by the
|
|
@option{-fno-ugly-init} option:
|
|
|
|
@example
|
|
INTEGER IA
|
|
CHARACTER BELL
|
|
PARAMETER (IA = 'A')
|
|
PARAMETER (BELL = 7)
|
|
@end example
|
|
|
|
@item
|
|
Use of Hollerith and typeless constants on the right-hand side
|
|
of assignment statements to numeric types, and in other
|
|
contexts (such as passing arguments in invocations of
|
|
intrinsic procedures and statement functions) that
|
|
are treated as assignments to known types (the dummy
|
|
arguments, in these cases).
|
|
|
|
Here are sample statements that are disabled by the
|
|
@option{-fno-ugly-init} option:
|
|
|
|
@example
|
|
IVAR = 4HABCD
|
|
PRINT *, IMAX0(2HAB, 2HBA)
|
|
@end example
|
|
@end itemize
|
|
|
|
The above constructs, when used,
|
|
can tend to result in non-portable code.
|
|
But, they are widely used in existing Fortran code in ways
|
|
that often are quite portable.
|
|
Therefore, they are enabled by default.
|
|
|
|
@node Ugly Integer Conversions
|
|
@subsection Ugly Integer Conversions
|
|
|
|
The constructs enabled via @option{-fugly-logint} are:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
|
|
dictated by
|
|
context (typically implies nonportable dependencies on how a
|
|
particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
|
|
|
|
@item
|
|
Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
|
|
statements.
|
|
@end itemize
|
|
|
|
The above constructs are disabled by default because use
|
|
of them tends to lead to non-portable code.
|
|
Even existing Fortran code that uses that often turns out
|
|
to be non-portable, if not outright buggy.
|
|
|
|
Some of this is due to differences among implementations as
|
|
far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
|
|
@code{INTEGER} values---Fortran code that assumes a particular
|
|
coding is likely to use one of the above constructs, and is
|
|
also likely to not work correctly on implementations using
|
|
different encodings.
|
|
|
|
@xref{Equivalence Versus Equality}, for more information.
|
|
|
|
@node Ugly Assigned Labels
|
|
@subsection Ugly Assigned Labels
|
|
@cindex ASSIGN statement
|
|
@cindex statements, ASSIGN
|
|
@cindex assigned labels
|
|
@cindex pointers
|
|
|
|
The @option{-fugly-assign} option forces @command{g77} to use the
|
|
same storage for assigned labels as it would for a normal
|
|
assignment to the same variable.
|
|
|
|
For example, consider the following code fragment:
|
|
|
|
@example
|
|
I = 3
|
|
ASSIGN 10 TO I
|
|
@end example
|
|
|
|
@noindent
|
|
Normally, for portability and improved diagnostics, @command{g77}
|
|
reserves distinct storage for a ``sibling'' of @samp{I}, used
|
|
only for @code{ASSIGN} statements to that variable (along with
|
|
the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
|
|
statements that reference the variable).
|
|
|
|
However, some code (that violates the ANSI FORTRAN 77 standard)
|
|
attempts to copy assigned labels among variables involved with
|
|
@code{ASSIGN} statements, as in:
|
|
|
|
@example
|
|
ASSIGN 10 TO I
|
|
ISTATE(5) = I
|
|
@dots{}
|
|
J = ISTATE(ICUR)
|
|
GOTO J
|
|
@end example
|
|
|
|
@noindent
|
|
Such code doesn't work under @command{g77} unless @option{-fugly-assign}
|
|
is specified on the command-line, ensuring that the value of @code{I}
|
|
referenced in the second line is whatever value @command{g77} uses
|
|
to designate statement label @samp{10}, so the value may be
|
|
copied into the @samp{ISTATE} array, later retrieved into a
|
|
variable of the appropriate type (@samp{J}), and used as the target of
|
|
an assigned-@code{GOTO} statement.
|
|
|
|
@emph{Note:} To avoid subtle program bugs,
|
|
when @option{-fugly-assign} is specified,
|
|
@command{g77} requires the type of variables
|
|
specified in assigned-label contexts
|
|
@emph{must} be the same type returned by @code{%LOC()}.
|
|
On many systems, this type is effectively the same
|
|
as @code{INTEGER(KIND=1)}, while, on others, it is
|
|
effectively the same as @code{INTEGER(KIND=2)}.
|
|
|
|
Do @emph{not} depend on @command{g77} actually writing valid pointers
|
|
to these variables, however.
|
|
While @command{g77} currently chooses that implementation, it might
|
|
be changed in the future.
|
|
|
|
@xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
|
|
for implementation details on assigned-statement labels.
|
|
|
|
@node Compiler
|
|
@chapter The GNU Fortran Compiler
|
|
|
|
The GNU Fortran compiler, @command{g77}, supports programs written
|
|
in the GNU Fortran language and in some other dialects of Fortran.
|
|
|
|
Some aspects of how @command{g77} works are universal regardless
|
|
of dialect, and yet are not properly part of the GNU Fortran
|
|
language itself.
|
|
These are described below.
|
|
|
|
@emph{Note: This portion of the documentation definitely needs a lot
|
|
of work!}
|
|
|
|
@menu
|
|
* Compiler Limits::
|
|
* Run-time Environment Limits::
|
|
* Compiler Types::
|
|
* Compiler Constants::
|
|
* Compiler Intrinsics::
|
|
@end menu
|
|
|
|
@node Compiler Limits
|
|
@section Compiler Limits
|
|
@cindex limits, compiler
|
|
@cindex compiler limits
|
|
|
|
@command{g77}, as with GNU tools in general, imposes few arbitrary restrictions
|
|
on lengths of identifiers, number of continuation lines, number of external
|
|
symbols in a program, and so on.
|
|
|
|
@cindex options, -Nl
|
|
@cindex -Nl option
|
|
@cindex options, -Nx
|
|
@cindex -Nx option
|
|
@cindex limits, continuation lines
|
|
@cindex limits, lengths of names
|
|
For example, some other Fortran compiler have an option
|
|
(such as @option{-Nl@var{x}}) to increase the limit on the
|
|
number of continuation lines.
|
|
Also, some Fortran compilation systems have an option
|
|
(such as @option{-Nx@var{x}}) to increase the limit on the
|
|
number of external symbols.
|
|
|
|
@command{g77}, @command{gcc}, and GNU @command{ld} (the GNU linker) have
|
|
no equivalent options, since they do not impose arbitrary
|
|
limits in these areas.
|
|
|
|
@cindex rank, maximum
|
|
@cindex maximum rank
|
|
@cindex number of dimensions, maximum
|
|
@cindex maximum number of dimensions
|
|
@cindex limits, rank
|
|
@cindex limits, array dimensions
|
|
@command{g77} does currently limit the number of dimensions in an array
|
|
to the same degree as do the Fortran standards---seven (7).
|
|
This restriction might be lifted in a future version.
|
|
|
|
@node Run-time Environment Limits
|
|
@section Run-time Environment Limits
|
|
@cindex limits, run-time library
|
|
@cindex wraparound
|
|
|
|
As a portable Fortran implementation,
|
|
@command{g77} offers its users direct access to,
|
|
and otherwise depends upon,
|
|
the underlying facilities of the system
|
|
used to build @command{g77},
|
|
the system on which @command{g77} itself is used to compile programs,
|
|
and the system on which the @command{g77}-compiled program is actually run.
|
|
(For most users, the three systems are of the same
|
|
type---combination of operating environment and hardware---often
|
|
the same physical system.)
|
|
|
|
The run-time environment for a particular system
|
|
inevitably imposes some limits on a program's use
|
|
of various system facilities.
|
|
These limits vary from system to system.
|
|
|
|
Even when such limits might be well beyond the
|
|
possibility of being encountered on a particular system,
|
|
the @command{g77} run-time environment
|
|
has certain built-in limits,
|
|
usually, but not always, stemming from intrinsics
|
|
with inherently limited interfaces.
|
|
|
|
Currently, the @command{g77} run-time environment
|
|
does not generally offer a less-limiting environment
|
|
by augmenting the underlying system's own environment.
|
|
|
|
Therefore, code written in the GNU Fortran language,
|
|
while syntactically and semantically portable,
|
|
might nevertheless make non-portable assumptions
|
|
about the run-time environment---assumptions that
|
|
prove to be false for some particular environments.
|
|
|
|
The GNU Fortran language,
|
|
the @command{g77} compiler and run-time environment,
|
|
and the @command{g77} documentation
|
|
do not yet offer comprehensive portable work-arounds for such limits,
|
|
though programmers should be able to
|
|
find their own in specific instances.
|
|
|
|
Not all of the limitations are described in this document.
|
|
Some of the known limitations include:
|
|
|
|
@menu
|
|
* Timer Wraparounds::
|
|
* Year 2000 (Y2K) Problems::
|
|
* Array Size::
|
|
* Character-variable Length::
|
|
* Year 10000 (Y10K) Problems::
|
|
@end menu
|
|
|
|
@node Timer Wraparounds
|
|
@subsection Timer Wraparounds
|
|
|
|
Intrinsics that return values computed from system timers,
|
|
whether elapsed (wall-clock) timers,
|
|
process CPU timers,
|
|
or other kinds of timers,
|
|
are prone to experiencing wrap-around errors
|
|
(or returning wrapped-around values from successive calls)
|
|
due to insufficient ranges
|
|
offered by the underlying system's timers.
|
|
|
|
@cindex negative time
|
|
@cindex short time
|
|
@cindex long time
|
|
Some of the symptoms of such behaviors include
|
|
apparently negative time being computed for a duration,
|
|
an extremely short amount of time being computed for a long duration,
|
|
and an extremely long amount of time being computed for a short duration.
|
|
|
|
See the following for intrinsics
|
|
known to have potential problems in these areas
|
|
on at least some systems:
|
|
@ref{CPU_Time Intrinsic},
|
|
@ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
|
|
@ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
|
|
@ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
|
|
@ref{Secnds Intrinsic},
|
|
@ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
|
|
@ref{System_Clock Intrinsic},
|
|
@ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
|
|
@ref{Time8 Intrinsic}.
|
|
|
|
@node Year 2000 (Y2K) Problems
|
|
@subsection Year 2000 (Y2K) Problems
|
|
@cindex Y2K compliance
|
|
@cindex Year 2000 compliance
|
|
|
|
While the @command{g77} compiler itself is believed to
|
|
be Year-2000 (Y2K) compliant,
|
|
some intrinsics are not,
|
|
and, potentially, some underlying systems are not,
|
|
perhaps rendering some Y2K-compliant intrinsics
|
|
non-compliant when used on those particular systems.
|
|
|
|
Fortran code that uses non-Y2K-compliant intrinsics
|
|
(listed below)
|
|
is, itself, almost certainly not compliant,
|
|
and should be modified to use Y2K-compliant intrinsics instead.
|
|
|
|
Fortran code that uses no non-Y2K-compliant intrinsics,
|
|
but which currently is running on a non-Y2K-compliant system,
|
|
can be made more Y2K compliant by compiling and
|
|
linking it for use on a new Y2K-compliant system,
|
|
such as a new version of an old, non-Y2K-compliant, system.
|
|
|
|
Currently, information on Y2K and related issues
|
|
is being maintained at
|
|
@uref{http://www.gnu.org/software/year2000-list.html}.
|
|
|
|
See the following for intrinsics
|
|
known to have potential problems in these areas
|
|
on at least some systems:
|
|
@ref{Date Intrinsic},
|
|
@ref{IDate Intrinsic (VXT)}.
|
|
|
|
@cindex y2kbuggy
|
|
@cindex date_y2kbuggy_0
|
|
@cindex vxtidate_y2kbuggy_0
|
|
@cindex G77_date_y2kbuggy_0
|
|
@cindex G77_vxtidate_y2kbuggy_0
|
|
The @code{libg2c} library
|
|
shipped with any @command{g77} that warns
|
|
about invocation of a non-Y2K-compliant intrinsic
|
|
has renamed the @code{EXTERNAL} procedure names
|
|
of those intrinsics.
|
|
This is done so that
|
|
the @code{libg2c} implementations of these intrinsics
|
|
cannot be directly linked to
|
|
as @code{EXTERNAL} names
|
|
(which normally would avoid the non-Y2K-intrinsic warning).
|
|
|
|
The renamed forms of the @code{EXTERNAL} names
|
|
of these renamed procedures
|
|
may be linked to
|
|
by appending the string @samp{_y2kbug}
|
|
to the name of the procedure
|
|
in the source code.
|
|
For example:
|
|
|
|
@smallexample
|
|
CHARACTER*20 STR
|
|
INTEGER YY, MM, DD
|
|
EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
|
|
CALL DATE_Y2KBUG (STR)
|
|
CALL VXTIDATE_Y2KBUG (MM, DD, YY)
|
|
@end smallexample
|
|
|
|
(Note that the @code{EXTERNAL} statement
|
|
is not actually required,
|
|
since the modified names are not recognized as intrinsics
|
|
by the current version of @command{g77}.
|
|
But it is shown in this specific case,
|
|
for purposes of illustration.)
|
|
|
|
The renaming of @code{EXTERNAL} procedure names of these intrinsics
|
|
causes unresolved references at link time.
|
|
For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
|
|
is normally compiled by @command{g77}
|
|
as, in C, @samp{date_(&str, 20);}.
|
|
This, in turn, links to the @code{date_} procedure
|
|
in the @code{libE77} portion of @code{libg2c},
|
|
which purposely calls a nonexistent procedure
|
|
named @code{G77_date_y2kbuggy_0}.
|
|
The resulting link-time error is designed, via this name,
|
|
to encourage the programmer to look up the
|
|
index entries to this portion of the @command{g77} documentation.
|
|
|
|
Generally, we recommend that the @code{EXTERNAL} method
|
|
of invoking procedures in @code{libg2c}
|
|
@emph{not} be used.
|
|
When used, some of the correctness checking
|
|
normally performed by @command{g77}
|
|
is skipped.
|
|
|
|
In particular, it is probably better to use the
|
|
@code{INTRINSIC} method of invoking
|
|
non-Y2K-compliant procedures,
|
|
so anyone compiling the code
|
|
can quickly notice the potential Y2K problems
|
|
(via the warnings printing by @command{g77})
|
|
without having to even look at the code itself.
|
|
|
|
If there are problems linking @code{libg2c}
|
|
to code compiled by @command{g77}
|
|
that involve the string @samp{y2kbug},
|
|
and these are not explained above,
|
|
that probably indicates
|
|
that a version of @code{libg2c}
|
|
older than @command{g77}
|
|
is being linked to,
|
|
or that the new library is being linked
|
|
to code compiled by an older version of @command{g77}.
|
|
|
|
That's because, as of the version that warns about
|
|
non-Y2K-compliant intrinsic invocation,
|
|
@command{g77} references the @code{libg2c} implementations
|
|
of those intrinsics
|
|
using new names, containing the string @samp{y2kbug}.
|
|
|
|
So, linking newly-compiled code
|
|
(invoking one of the intrinsics in question)
|
|
to an old library
|
|
might yield an unresolved reference
|
|
to @code{G77_date_y2kbug_0}.
|
|
(The old library calls it @code{G77_date_0}.)
|
|
|
|
Similarly, linking previously-compiled code
|
|
to a new library
|
|
might yield an unresolved reference
|
|
to @code{G77_vxtidate_0}.
|
|
(The new library calls it @code{G77_vxtidate_y2kbug_0}.)
|
|
|
|
The proper fix for the above problems
|
|
is to obtain the latest release of @command{g77}
|
|
and related products
|
|
(including @code{libg2c})
|
|
and install them on all systems,
|
|
then recompile, relink, and install
|
|
(as appropriate)
|
|
all existing Fortran programs.
|
|
|
|
(Normally, this sort of renaming is steadfastly avoided.
|
|
In this case, however, it seems more important to highlight
|
|
potential Y2K problems
|
|
than to ease the transition
|
|
of potentially non-Y2K-compliant code
|
|
to new versions of @command{g77} and @code{libg2c}.)
|
|
|
|
@node Array Size
|
|
@subsection Array Size
|
|
@cindex limits, array size
|
|
@cindex array size
|
|
|
|
Currently, @command{g77} uses the default @code{INTEGER} type
|
|
for array indexes,
|
|
which limits the sizes of single-dimension arrays
|
|
on systems offering a larger address space
|
|
than can be addressed by that type.
|
|
(That @command{g77} puts all arrays in memory
|
|
could be considered another limitation---it
|
|
could use large temporary files---but that decision
|
|
is left to the programmer as an implementation choice
|
|
by most Fortran implementations.)
|
|
|
|
@c ??? Investigate this, to offer a more clear statement
|
|
@c than the following paragraphs do. -- burley 1999-02-17
|
|
It is not yet clear whether this limitation
|
|
never, sometimes, or always applies to the
|
|
sizes of multiple-dimension arrays as a whole.
|
|
|
|
For example, on a system with 64-bit addresses
|
|
and 32-bit default @code{INTEGER},
|
|
an array with a size greater than can be addressed
|
|
by a 32-bit offset
|
|
can be declared using multiple dimensions.
|
|
Such an array is therefore larger
|
|
than a single-dimension array can be,
|
|
on the same system.
|
|
|
|
@cindex limits, multi-dimension arrays
|
|
@cindex multi-dimension arrays
|
|
@cindex arrays, dimensioning
|
|
Whether large multiple-dimension arrays are reliably supported
|
|
depends mostly on the @command{gcc} back end (code generator)
|
|
used by @command{g77}, and has not yet been fully investigated.
|
|
|
|
@node Character-variable Length
|
|
@subsection Character-variable Length
|
|
@cindex limits, on character-variable length
|
|
@cindex character-variable length
|
|
|
|
Currently, @command{g77} uses the default @code{INTEGER} type
|
|
for the lengths of @code{CHARACTER} variables
|
|
and array elements.
|
|
|
|
This means that, for example,
|
|
a system with a 64-bit address space
|
|
and a 32-bit default @code{INTEGER} type
|
|
does not, under @command{g77},
|
|
support a @code{CHARACTER*@var{n}} declaration
|
|
where @var{n} is greater than 2147483647.
|
|
|
|
@node Year 10000 (Y10K) Problems
|
|
@subsection Year 10000 (Y10K) Problems
|
|
@cindex Y10K compliance
|
|
@cindex Year 10000 compliance
|
|
|
|
Most intrinsics returning, or computing values based on,
|
|
date information are prone to Year-10000 (Y10K) problems,
|
|
due to supporting only 4 digits for the year.
|
|
|
|
See the following for examples:
|
|
@ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
|
|
@ref{IDate Intrinsic (UNIX)},
|
|
@ref{Time Intrinsic (VXT)},
|
|
@ref{Date_and_Time Intrinsic}.
|
|
|
|
@node Compiler Types
|
|
@section Compiler Types
|
|
@cindex types, of data
|
|
@cindex data types
|
|
|
|
Fortran implementations have a fair amount of freedom given them by the
|
|
standard as far as how much storage space is used and how much precision
|
|
and range is offered by the various types such as @code{LOGICAL(KIND=1)},
|
|
@code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
|
|
@code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
|
|
Further, many compilers offer so-called @samp{*@var{n}} notation, but
|
|
the interpretation of @var{n} varies across compilers and target architectures.
|
|
|
|
The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
|
|
and @code{REAL(KIND=1)}
|
|
occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
|
|
and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
|
|
Further, it requires that @code{COMPLEX(KIND=1)}
|
|
entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
|
|
storage-associated (such as via @code{EQUIVALENCE})
|
|
with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
|
|
corresponds to the real element and @samp{R(2)} to the imaginary
|
|
element of the @code{COMPLEX(KIND=1)} variable.
|
|
|
|
(Few requirements as to precision or ranges of any of these are
|
|
placed on the implementation, nor is the relationship of storage sizes of
|
|
these types to the @code{CHARACTER} type specified, by the standard.)
|
|
|
|
@command{g77} follows the above requirements, warning when compiling
|
|
a program requires placement of items in memory that contradict the
|
|
requirements of the target architecture.
|
|
(For example, a program can require placement of a @code{REAL(KIND=2)}
|
|
on a boundary that is not an even multiple of its size, but still an
|
|
even multiple of the size of a @code{REAL(KIND=1)} variable.
|
|
On some target architectures, using the canonical
|
|
mapping of Fortran types to underlying architectural types, such
|
|
placement is prohibited by the machine definition or
|
|
the Application Binary Interface (ABI) in force for
|
|
the configuration defined for building @command{gcc} and @command{g77}.
|
|
@command{g77} warns about such
|
|
situations when it encounters them.)
|
|
|
|
@command{g77} follows consistent rules for configuring the mapping between Fortran
|
|
types, including the @samp{*@var{n}} notation, and the underlying architectural
|
|
types as accessed by a similarly-configured applicable version of the
|
|
@command{gcc} compiler.
|
|
These rules offer a widely portable, consistent Fortran/C
|
|
environment, although they might well conflict with the expectations of
|
|
users of Fortran compilers designed and written for particular
|
|
architectures.
|
|
|
|
These rules are based on the configuration that is in force for the
|
|
version of @command{gcc} built in the same release as @command{g77} (and
|
|
which was therefore used to build both the @command{g77} compiler
|
|
components and the @code{libg2c} run-time library):
|
|
|
|
@table @code
|
|
@cindex REAL(KIND=1) type
|
|
@cindex types, REAL(KIND=1)
|
|
@item REAL(KIND=1)
|
|
Same as @code{float} type.
|
|
|
|
@cindex REAL(KIND=2) type
|
|
@cindex types, REAL(KIND=2)
|
|
@item REAL(KIND=2)
|
|
Same as whatever floating-point type that is twice the size
|
|
of a @code{float}---usually, this is a @code{double}.
|
|
|
|
@cindex INTEGER(KIND=1) type
|
|
@cindex types, INTEGER(KIND=1)
|
|
@item INTEGER(KIND=1)
|
|
Same as an integral type that is occupies the same amount
|
|
of memory storage as @code{float}---usually, this is either
|
|
an @code{int} or a @code{long int}.
|
|
|
|
@cindex LOGICAL(KIND=1) type
|
|
@cindex types, LOGICAL(KIND=1)
|
|
@item LOGICAL(KIND=1)
|
|
Same @command{gcc} type as @code{INTEGER(KIND=1)}.
|
|
|
|
@cindex INTEGER(KIND=2) type
|
|
@cindex types, INTEGER(KIND=2)
|
|
@item INTEGER(KIND=2)
|
|
Twice the size, and usually nearly twice the range,
|
|
as @code{INTEGER(KIND=1)}---usually, this is either
|
|
a @code{long int} or a @code{long long int}.
|
|
|
|
@cindex LOGICAL(KIND=2) type
|
|
@cindex types, LOGICAL(KIND=2)
|
|
@item LOGICAL(KIND=2)
|
|
Same @command{gcc} type as @code{INTEGER(KIND=2)}.
|
|
|
|
@cindex INTEGER(KIND=3) type
|
|
@cindex types, INTEGER(KIND=3)
|
|
@item INTEGER(KIND=3)
|
|
Same @command{gcc} type as signed @code{char}.
|
|
|
|
@cindex LOGICAL(KIND=3) type
|
|
@cindex types, LOGICAL(KIND=3)
|
|
@item LOGICAL(KIND=3)
|
|
Same @command{gcc} type as @code{INTEGER(KIND=3)}.
|
|
|
|
@cindex INTEGER(KIND=6) type
|
|
@cindex types, INTEGER(KIND=6)
|
|
@item INTEGER(KIND=6)
|
|
Twice the size, and usually nearly twice the range,
|
|
as @code{INTEGER(KIND=3)}---usually, this is
|
|
a @code{short}.
|
|
|
|
@cindex LOGICAL(KIND=6) type
|
|
@cindex types, LOGICAL(KIND=6)
|
|
@item LOGICAL(KIND=6)
|
|
Same @command{gcc} type as @code{INTEGER(KIND=6)}.
|
|
|
|
@cindex COMPLEX(KIND=1) type
|
|
@cindex types, COMPLEX(KIND=1)
|
|
@item COMPLEX(KIND=1)
|
|
Two @code{REAL(KIND=1)} scalars (one for the real part followed by
|
|
one for the imaginary part).
|
|
|
|
@cindex COMPLEX(KIND=2) type
|
|
@cindex types, COMPLEX(KIND=2)
|
|
@item COMPLEX(KIND=2)
|
|
Two @code{REAL(KIND=2)} scalars.
|
|
|
|
@cindex *@var{n} notation
|
|
@item @var{numeric-type}*@var{n}
|
|
(Where @var{numeric-type} is any type other than @code{CHARACTER}.)
|
|
Same as whatever @command{gcc} type occupies @var{n} times the storage
|
|
space of a @command{gcc} @code{char} item.
|
|
|
|
@cindex DOUBLE PRECISION type
|
|
@cindex types, DOUBLE PRECISION
|
|
@item DOUBLE PRECISION
|
|
Same as @code{REAL(KIND=2)}.
|
|
|
|
@cindex DOUBLE COMPLEX type
|
|
@cindex types, DOUBLE COMPLEX
|
|
@item DOUBLE COMPLEX
|
|
Same as @code{COMPLEX(KIND=2)}.
|
|
@end table
|
|
|
|
Note that the above are proposed correspondences and might change
|
|
in future versions of @command{g77}---avoid writing code depending
|
|
on them.
|
|
|
|
Other types supported by @command{g77}
|
|
are derived from gcc types such as @code{char}, @code{short},
|
|
@code{int}, @code{long int}, @code{long long int}, @code{long double},
|
|
and so on.
|
|
That is, whatever types @command{gcc} already supports, @command{g77} supports
|
|
now or probably will support in a future version.
|
|
The rules for the @samp{@var{numeric-type}*@var{n}} notation
|
|
apply to these types,
|
|
and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
|
|
assigned in a way that encourages clarity, consistency, and portability.
|
|
|
|
@node Compiler Constants
|
|
@section Compiler Constants
|
|
@cindex constants
|
|
@cindex types, constants
|
|
|
|
@command{g77} strictly assigns types to @emph{all} constants not
|
|
documented as ``typeless'' (typeless constants including @samp{'1'Z},
|
|
for example).
|
|
Many other Fortran compilers attempt to assign types to typed constants
|
|
based on their context.
|
|
This results in hard-to-find bugs, nonportable
|
|
code, and is not in the spirit (though it strictly follows the letter)
|
|
of the 77 and 90 standards.
|
|
|
|
@command{g77} might offer, in a future release, explicit constructs by
|
|
which a wider variety of typeless constants may be specified, and/or
|
|
user-requested warnings indicating places where @command{g77} might differ
|
|
from how other compilers assign types to constants.
|
|
|
|
@xref{Context-Sensitive Constants}, for more information on this issue.
|
|
|
|
@node Compiler Intrinsics
|
|
@section Compiler Intrinsics
|
|
|
|
@command{g77} offers an ever-widening set of intrinsics.
|
|
Currently these all are procedures (functions and subroutines).
|
|
|
|
Some of these intrinsics are unimplemented, but their names reserved
|
|
to reduce future problems with existing code as they are implemented.
|
|
Others are implemented as part of the GNU Fortran language, while
|
|
yet others are provided for compatibility with other dialects of
|
|
Fortran but are not part of the GNU Fortran language.
|
|
|
|
To manage these distinctions, @command{g77} provides intrinsic @emph{groups},
|
|
a facility that is simply an extension of the intrinsic groups provided
|
|
by the GNU Fortran language.
|
|
|
|
@menu
|
|
* Intrinsic Groups:: How intrinsics are grouped for easy management.
|
|
* Other Intrinsics:: Intrinsics other than those in the GNU
|
|
Fortran language.
|
|
@end menu
|
|
|
|
@node Intrinsic Groups
|
|
@subsection Intrinsic Groups
|
|
@cindex groups of intrinsics
|
|
@cindex intrinsics, groups
|
|
|
|
A given specific intrinsic belongs in one or more groups.
|
|
Each group is deleted, disabled, hidden, or enabled
|
|
by default or a command-line option.
|
|
The meaning of each term follows.
|
|
|
|
@table @b
|
|
@cindex deleted intrinsics
|
|
@cindex intrinsics, deleted
|
|
@item Deleted
|
|
No intrinsics are recognized as belonging to that group.
|
|
|
|
@cindex disabled intrinsics
|
|
@cindex intrinsics, disabled
|
|
@item Disabled
|
|
Intrinsics are recognized as belonging to the group, but
|
|
references to them (other than via the @code{INTRINSIC} statement)
|
|
are disallowed through that group.
|
|
|
|
@cindex hidden intrinsics
|
|
@cindex intrinsics, hidden
|
|
@item Hidden
|
|
Intrinsics in that group are recognized and enabled (if implemented)
|
|
@emph{only} if the first mention of the actual name of an intrinsic
|
|
in a program unit is in an @code{INTRINSIC} statement.
|
|
|
|
@cindex enabled intrinsics
|
|
@cindex intrinsics, enabled
|
|
@item Enabled
|
|
Intrinsics in that group are recognized and enabled (if implemented).
|
|
@end table
|
|
|
|
The distinction between deleting and disabling a group is illustrated
|
|
by the following example.
|
|
Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
|
|
If group @samp{FGR} is deleted, the following program unit will
|
|
successfully compile, because @samp{FOO()} will be seen as a
|
|
reference to an external function named @samp{FOO}:
|
|
|
|
@example
|
|
PRINT *, FOO()
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
If group @samp{FGR} is disabled, compiling the above program will produce
|
|
diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
|
|
or, if properly invoked, it is not enabled.
|
|
To change the above program so it references an external function @samp{FOO}
|
|
instead of the disabled @samp{FOO} intrinsic,
|
|
add the following line to the top:
|
|
|
|
@example
|
|
EXTERNAL FOO
|
|
@end example
|
|
|
|
@noindent
|
|
So, deleting a group tells @command{g77} to pretend as though the intrinsics in
|
|
that group do not exist at all, whereas disabling it tells @command{g77} to
|
|
recognize them as (disabled) intrinsics in intrinsic-like contexts.
|
|
|
|
Hiding a group is like enabling it, but the intrinsic must be first
|
|
named in an @code{INTRINSIC} statement to be considered a reference to the
|
|
intrinsic rather than to an external procedure.
|
|
This might be the ``safest'' way to treat a new group of intrinsics
|
|
when compiling old
|
|
code, because it allows the old code to be generally written as if
|
|
those new intrinsics never existed, but to be changed to use them
|
|
by inserting @code{INTRINSIC} statements in the appropriate places.
|
|
However, it should be the goal of development to use @code{EXTERNAL}
|
|
for all names of external procedures that might be intrinsic names.
|
|
|
|
If an intrinsic is in more than one group, it is enabled if any of its
|
|
containing groups are enabled; if not so enabled, it is hidden if
|
|
any of its containing groups are hidden; if not so hidden, it is disabled
|
|
if any of its containing groups are disabled; if not so disabled, it is
|
|
deleted.
|
|
This extra complication is necessary because some intrinsics,
|
|
such as @code{IBITS}, belong to more than one group, and hence should be
|
|
enabled if any of the groups to which they belong are enabled, and so
|
|
on.
|
|
|
|
The groups are:
|
|
|
|
@cindex intrinsics, groups of
|
|
@cindex groups of intrinsics
|
|
@table @code
|
|
@cindex @code{badu77} intrinsics group
|
|
@item badu77
|
|
UNIX intrinsics having inappropriate forms (usually functions that
|
|
have intended side effects).
|
|
|
|
@cindex @code{gnu} intrinsics group
|
|
@item gnu
|
|
Intrinsics the GNU Fortran language supports that are extensions to
|
|
the Fortran standards (77 and 90).
|
|
|
|
@cindex @command{f2c} intrinsics group
|
|
@item f2c
|
|
Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}.
|
|
|
|
@cindex @code{f90} intrinsics group
|
|
@item f90
|
|
Fortran 90 intrinsics.
|
|
|
|
@cindex @code{mil} intrinsics group
|
|
@item mil
|
|
MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
|
|
|
|
@cindex @code{mil} intrinsics group
|
|
@item unix
|
|
UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
|
|
|
|
@cindex @code{mil} intrinsics group
|
|
@item vxt
|
|
VAX/VMS FORTRAN (current as of v4) intrinsics.
|
|
@end table
|
|
|
|
@node Other Intrinsics
|
|
@subsection Other Intrinsics
|
|
@cindex intrinsics, others
|
|
@cindex other intrinsics
|
|
|
|
@command{g77} supports intrinsics other than those in the GNU Fortran
|
|
language proper.
|
|
This set of intrinsics is described below.
|
|
|
|
@ifinfo
|
|
(Note that the empty lines appearing in the menu below
|
|
are not intentional---they result from a bug in the
|
|
@code{makeinfo} program.)
|
|
@end ifinfo
|
|
|
|
@c The actual documentation for intrinsics comes from
|
|
@c intdoc.texi, which in turn is automatically generated
|
|
@c from the internal g77 tables in intrin.def _and_ the
|
|
@c largely hand-written text in intdoc.h. So, if you want
|
|
@c to change or add to existing documentation on intrinsics,
|
|
@c you probably want to edit intdoc.h.
|
|
@c
|
|
@clear familyF77
|
|
@clear familyGNU
|
|
@clear familyASC
|
|
@clear familyMIL
|
|
@clear familyF90
|
|
@set familyVXT
|
|
@set familyFVZ
|
|
@clear familyF2C
|
|
@clear familyF2U
|
|
@set familyBADU77
|
|
@include intdoc.texi
|
|
|
|
@node Other Compilers
|
|
@chapter Other Compilers
|
|
|
|
An individual Fortran source file can be compiled to
|
|
an object (@file{*.o}) file instead of to the final
|
|
program executable.
|
|
This allows several portions of a program to be compiled
|
|
at different times and linked together whenever a new
|
|
version of the program is needed.
|
|
However, it introduces the issue of @dfn{object compatibility}
|
|
across the various object files (and libraries, or @file{*.a}
|
|
files) that are linked together to produce any particular
|
|
executable file.
|
|
|
|
Object compatibility is an issue when combining, in one
|
|
program, Fortran code compiled by more than one compiler
|
|
(or more than one configuration of a compiler).
|
|
If the compilers
|
|
disagree on how to transform the names of procedures, there
|
|
will normally be errors when linking such programs.
|
|
Worse, if the compilers agree on naming, but disagree on issues
|
|
like how to pass parameters, return arguments, and lay out
|
|
@code{COMMON} areas, the earliest detected errors might be the
|
|
incorrect results produced by the program (and that assumes
|
|
these errors are detected, which is not always the case).
|
|
|
|
Normally, @command{g77} generates code that is
|
|
object-compatible with code generated by a version of
|
|
@command{f2c} configured (with, for example, @file{f2c.h} definitions)
|
|
to be generally compatible with @command{g77} as built by @command{gcc}.
|
|
(Normally, @command{f2c} will, by default, conform to the appropriate
|
|
configuration, but it is possible that older or perhaps even newer
|
|
versions of @command{f2c}, or versions having certain configuration changes
|
|
to @command{f2c} internals, will produce object files that are
|
|
incompatible with @command{g77}.)
|
|
|
|
For example, a Fortran string subroutine
|
|
argument will become two arguments on the C side: a @code{char *}
|
|
and an @code{int} length.
|
|
|
|
Much of this compatibility results from the fact that
|
|
@command{g77} uses the same run-time library,
|
|
@code{libf2c}, used by @command{f2c},
|
|
though @command{g77} gives its version the name @code{libg2c}
|
|
so as to avoid conflicts when linking,
|
|
installing them in the same directories,
|
|
and so on.
|
|
|
|
Other compilers might or might not generate code that
|
|
is object-compatible with @code{libg2c} and current @command{g77},
|
|
and some might offer such compatibility only when explicitly
|
|
selected via a command-line option to the compiler.
|
|
|
|
@emph{Note: This portion of the documentation definitely needs a lot
|
|
of work!}
|
|
|
|
@menu
|
|
* Dropping f2c Compatibility:: When speed is more important.
|
|
* Compilers Other Than f2c:: Interoperation with code from other compilers.
|
|
@end menu
|
|
|
|
@node Dropping f2c Compatibility
|
|
@section Dropping @command{f2c} Compatibility
|
|
|
|
Specifying @option{-fno-f2c} allows @command{g77} to generate, in
|
|
some cases, faster code, by not needing to allow to the possibility
|
|
of linking with code compiled by @command{f2c}.
|
|
|
|
For example, this affects how @code{REAL(KIND=1)},
|
|
@code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
|
|
With @option{-fno-f2c}, they are
|
|
compiled as returning the appropriate @command{gcc} type
|
|
(@code{float}, @code{__complex__ float}, @code{__complex__ double},
|
|
in many configurations).
|
|
|
|
With @option{-ff2c} in force, they
|
|
are compiled differently (with perhaps slower run-time performance)
|
|
to accommodate the restrictions inherent in @command{f2c}'s use of K&R
|
|
C as an intermediate language---@code{REAL(KIND=1)} functions
|
|
return C's @code{double} type, while @code{COMPLEX} functions return
|
|
@code{void} and use an extra argument pointing to a place for the functions to
|
|
return their values.
|
|
|
|
It is possible that, in some cases, leaving @option{-ff2c} in force
|
|
might produce faster code than using @option{-fno-f2c}.
|
|
Feel free to experiment, but remember to experiment with changing the way
|
|
@emph{entire programs and their Fortran libraries are compiled} at
|
|
a time, since this sort of experimentation affects the interface
|
|
of code generated for a Fortran source file---that is, it affects
|
|
object compatibility.
|
|
|
|
Note that @command{f2c} compatibility is a fairly static target to achieve,
|
|
though not necessarily perfectly so, since, like @command{g77}, it is
|
|
still being improved.
|
|
However, specifying @option{-fno-f2c} causes @command{g77}
|
|
to generate code that will probably be incompatible with code
|
|
generated by future versions of @command{g77} when the same option
|
|
is in force.
|
|
You should make sure you are always able to recompile complete
|
|
programs from source code when upgrading to new versions of @command{g77}
|
|
or @command{f2c}, especially when using options such as @option{-fno-f2c}.
|
|
|
|
Therefore, if you are using @command{g77} to compile libraries and other
|
|
object files for possible future use and you don't want to require
|
|
recompilation for future use with subsequent versions of @command{g77},
|
|
you might want to stick with @command{f2c} compatibility for now, and
|
|
carefully watch for any announcements about changes to the
|
|
@command{f2c}/@code{libf2c} interface that might affect existing programs
|
|
(thus requiring recompilation).
|
|
|
|
It is probable that a future version of @command{g77} will not,
|
|
by default, generate object files compatible with @command{f2c},
|
|
and that version probably would no longer use @code{libf2c}.
|
|
If you expect to depend on this compatibility in the
|
|
long term, use the options @samp{-ff2c -ff2c-library} when compiling
|
|
all of the applicable code.
|
|
This should cause future versions of @command{g77} either to produce
|
|
compatible code (at the expense of the availability of some features and
|
|
performance), or at the very least, to produce diagnostics.
|
|
|
|
(The library @command{g77} produces will no longer be named @file{libg2c}
|
|
when it is no longer generally compatible with @file{libf2c}.
|
|
It will likely be referred to, and, if installed as a distinct
|
|
library, named @code{libg77}, or some other as-yet-unused name.)
|
|
|
|
@node Compilers Other Than f2c
|
|
@section Compilers Other Than @command{f2c}
|
|
|
|
On systems with Fortran compilers other than @command{f2c} and @command{g77},
|
|
code compiled by @command{g77} is not expected to work
|
|
well with code compiled by the native compiler.
|
|
(This is true for @command{f2c}-compiled objects as well.)
|
|
Libraries compiled with the native compiler probably will have
|
|
to be recompiled with @command{g77} to be used with @command{g77}-compiled code.
|
|
|
|
Reasons for such incompatibilities include:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
There might be differences in the way names of Fortran procedures
|
|
are translated for use in the system's object-file format.
|
|
For example, the statement @samp{CALL FOO} might be compiled
|
|
by @command{g77} to call a procedure the linker @command{ld} sees
|
|
given the name @samp{_foo_}, while the apparently corresponding
|
|
statement @samp{SUBROUTINE FOO} might be compiled by the
|
|
native compiler to define the linker-visible name @samp{_foo},
|
|
or @samp{_FOO_}, and so on.
|
|
|
|
@item
|
|
There might be subtle type mismatches which cause subroutine arguments
|
|
and function return values to get corrupted.
|
|
|
|
This is why simply getting @command{g77} to
|
|
transform procedure names the same way a native
|
|
compiler does is not usually a good idea---unless
|
|
some effort has been made to ensure that, aside
|
|
from the way the two compilers transform procedure
|
|
names, everything else about the way they generate
|
|
code for procedure interfaces is identical.
|
|
|
|
@item
|
|
Native compilers
|
|
use libraries of private I/O routines which will not be available
|
|
at link time unless you have the native compiler---and you would
|
|
have to explicitly ask for them.
|
|
|
|
For example, on the Sun you
|
|
would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
|
|
command.
|
|
@end itemize
|
|
|
|
@node Other Languages
|
|
@chapter Other Languages
|
|
|
|
@emph{Note: This portion of the documentation definitely needs a lot
|
|
of work!}
|
|
|
|
@menu
|
|
* Interoperating with C and C++::
|
|
@end menu
|
|
|
|
@node Interoperating with C and C++
|
|
@section Tools and advice for interoperating with C and C++
|
|
|
|
@cindex C, linking with
|
|
@cindex C++, linking with
|
|
@cindex linking with C
|
|
The following discussion assumes that you are running @command{g77} in @command{f2c}
|
|
compatibility mode, i.e.@: not using @option{-fno-f2c}.
|
|
It provides some
|
|
advice about quick and simple techniques for linking Fortran and C (or
|
|
C++), the most common requirement.
|
|
For the full story consult the
|
|
description of code generation.
|
|
@xref{Debugging and Interfacing}.
|
|
|
|
When linking Fortran and C, it's usually best to use @command{g77} to do
|
|
the linking so that the correct libraries are included (including the
|
|
maths one).
|
|
If you're linking with C++ you will want to add
|
|
@option{-lstdc++}, @option{-lg++} or whatever.
|
|
If you need to use another
|
|
driver program (or @command{ld} directly),
|
|
you can find out what linkage
|
|
options @command{g77} passes by running @samp{g77 -v}.
|
|
|
|
@menu
|
|
* C Interfacing Tools::
|
|
* C Access to Type Information::
|
|
* f2c Skeletons and Prototypes::
|
|
* C++ Considerations::
|
|
* Startup Code::
|
|
@end menu
|
|
|
|
@node C Interfacing Tools
|
|
@subsection C Interfacing Tools
|
|
@pindex f2c
|
|
@cindex cfortran.h
|
|
@cindex Netlib
|
|
Even if you don't actually use it as a compiler, @command{f2c} from
|
|
@uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
|
|
interfacing (linking) Fortran and C@.
|
|
@xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}.
|
|
|
|
To use @command{f2c} for this purpose you only need retrieve and
|
|
build the @file{src} directory from the distribution, consult the
|
|
@file{README} instructions there for machine-specifics, and install the
|
|
@command{f2c} program on your path.
|
|
|
|
Something else that might be useful is @samp{cfortran.h} from
|
|
@uref{ftp://zebra.desy.de/cfortran}.
|
|
This is a fairly general tool which
|
|
can be used to generate interfaces for calling in both directions
|
|
between Fortran and C@.
|
|
It can be used in @command{f2c} mode with
|
|
@command{g77}---consult its documentation for details.
|
|
|
|
@node C Access to Type Information
|
|
@subsection Accessing Type Information in C
|
|
|
|
@cindex types, Fortran/C
|
|
Generally, C code written to link with
|
|
@command{g77} code---calling and/or being
|
|
called from Fortran---should @samp{#include <g2c.h>} to define the C
|
|
versions of the Fortran types.
|
|
Don't assume Fortran @code{INTEGER} types
|
|
correspond to C @code{int}s, for instance; instead, declare them as
|
|
@code{integer}, a type defined by @file{g2c.h}.
|
|
@file{g2c.h} is installed where @command{gcc} will find it by
|
|
default, assuming you use a copy of @command{gcc} compatible with
|
|
@command{g77}, probably built at the same time as @command{g77}.
|
|
|
|
@node f2c Skeletons and Prototypes
|
|
@subsection Generating Skeletons and Prototypes with @command{f2c}
|
|
|
|
@pindex f2c
|
|
@cindex -fno-second-underscore
|
|
A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to
|
|
interface with an existing library---is to write a file (named, for
|
|
example, @file{fred.f}) of dummy Fortran
|
|
skeletons comprising just the declaration of the routine(s) and dummy
|
|
arguments plus @code{END} statements.
|
|
Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c}
|
|
into which you can edit
|
|
useful code, confident the calling sequence is correct, at least.
|
|
(There are some errors otherwise commonly made in generating C
|
|
interfaces with @command{f2c} conventions,
|
|
such as not using @code{doublereal}
|
|
as the return type of a @code{REAL} @code{FUNCTION}.)
|
|
|
|
@pindex ftnchek
|
|
@command{f2c} also can help with calling Fortran from C, using its
|
|
@option{-P} option to generate C prototypes appropriate for calling the
|
|
Fortran.@footnote{The files generated like this can also be used for
|
|
inter-unit consistency checking of dummy and actual arguments, although
|
|
the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
|
|
or @uref{ftp://ftp.dsm.fordham.edu} is
|
|
probably better for this purpose.}
|
|
If the Fortran code containing any
|
|
routines to be called from C is in file @file{joe.f}, use the command
|
|
@kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
|
|
prototype information.
|
|
@code{#include} this in the C which has to call
|
|
the Fortran routines to make sure you get it right.
|
|
|
|
@xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
|
|
between the way Fortran (including compilers like @command{g77}) and
|
|
C handle arrays.
|
|
|
|
@node C++ Considerations
|
|
@subsection C++ Considerations
|
|
|
|
@cindex C++
|
|
@command{f2c} can be used to generate suitable code for compilation with a
|
|
C++ system using the @option{-C++} option.
|
|
The important thing about linking @command{g77}-compiled
|
|
code with C++ is that the prototypes for the @command{g77}
|
|
routines must specify C linkage to avoid name mangling.
|
|
So, use an @samp{extern "C"} declaration.
|
|
@command{f2c}'s @option{-C++} option will take care
|
|
of this when generating skeletons or prototype files as above, and also
|
|
avoid clashes with C++ reserved words in addition to those in C@.
|
|
|
|
@node Startup Code
|
|
@subsection Startup Code
|
|
|
|
@cindex startup code
|
|
@cindex run-time, initialization
|
|
@cindex initialization, run-time
|
|
Unlike with some runtime systems,
|
|
it shouldn't be necessary
|
|
(unless there are bugs)
|
|
to use a Fortran main program unit to ensure the
|
|
runtime---specifically the I/O system---is initialized.
|
|
|
|
However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC},
|
|
either the @code{main} routine from the @file{libg2c} library must be used,
|
|
or the @code{f_setarg} routine
|
|
(new as of @code{egcs} version 1.1 and @command{g77} version 0.5.23)
|
|
must be called with the appropriate @code{argc} and @code{argv} arguments
|
|
prior to the program calling @code{GETARG} or @code{IARGC}.
|
|
|
|
To provide more flexibility for mixed-language programming
|
|
involving @command{g77} while allowing for shared libraries,
|
|
as of @code{egcs} version 1.1 and @command{g77} version 0.5.23,
|
|
@command{g77}'s @code{main} routine in @code{libg2c}
|
|
does the following, in order:
|
|
|
|
@enumerate
|
|
@item
|
|
Calls @code{f_setarg}
|
|
with the incoming @code{argc} and @code{argv} arguments,
|
|
in the same order as for @code{main} itself.
|
|
|
|
This sets up the command-line environment
|
|
for @code{GETARG} and @code{IARGC}.
|
|
|
|
@item
|
|
Calls @code{f_setsig} (with no arguments).
|
|
|
|
This sets up the signaling and exception environment.
|
|
|
|
@item
|
|
Calls @code{f_init} (with no arguments).
|
|
|
|
This initializes the I/O environment,
|
|
though that should not be necessary,
|
|
as all I/O functions in @code{libf2c}
|
|
are believed to call @code{f_init} automatically,
|
|
if necessary.
|
|
|
|
(A future version of @command{g77} might skip this explicit step,
|
|
to speed up normal exit of a program.)
|
|
|
|
@item
|
|
Arranges for @code{f_exit} to be called (with no arguments)
|
|
when the program exits.
|
|
|
|
This ensures that the I/O environment is properly shut down
|
|
before the program exits normally.
|
|
Otherwise, output buffers might not be fully flushed,
|
|
scratch files might not be deleted, and so on.
|
|
|
|
The simple way @code{main} does this is
|
|
to call @code{f_exit} itself after calling
|
|
@code{MAIN__} (in the next step).
|
|
|
|
However, this does not catch the cases where the program
|
|
might call @code{exit} directly,
|
|
instead of using the @code{EXIT} intrinsic
|
|
(implemented as @code{exit_} in @code{libf2c}).
|
|
|
|
So, @code{main} attempts to use
|
|
the operating environment's @code{onexit} or @code{atexit}
|
|
facility, if available,
|
|
to cause @code{f_exit} to be called automatically
|
|
upon any invocation of @code{exit}.
|
|
|
|
@item
|
|
Calls @code{MAIN__} (with no arguments).
|
|
|
|
This starts executing the Fortran main program unit for
|
|
the application.
|
|
(Both @command{g77} and @command{f2c} currently compile a main
|
|
program unit so that its global name is @code{MAIN__}.)
|
|
|
|
@item
|
|
If no @code{onexit} or @code{atexit} is provided by the system,
|
|
calls @code{f_exit}.
|
|
|
|
@item
|
|
Calls @code{exit} with a zero argument,
|
|
to signal a successful program termination.
|
|
|
|
@item
|
|
Returns a zero value to the caller,
|
|
to signal a successful program termination,
|
|
in case @code{exit} doesn't exit on the system.
|
|
@end enumerate
|
|
|
|
All of the above names are C @code{extern} names,
|
|
i.e.@: not mangled.
|
|
|
|
When using the @code{main} procedure provided by @command{g77}
|
|
without a Fortran main program unit,
|
|
you need to provide @code{MAIN__}
|
|
as the entry point for your C code.
|
|
(Make sure you link the object file that defines that
|
|
entry point with the rest of your program.)
|
|
|
|
To provide your own @code{main} procedure
|
|
in place of @command{g77}'s,
|
|
make sure you specify the object file defining that procedure
|
|
@emph{before} @option{-lg2c} on the @command{g77} command line.
|
|
Since the @option{-lg2c} option is implicitly provided,
|
|
this is usually straightforward.
|
|
(Use the @option{--verbose} option to see how and where
|
|
@command{g77} implicitly adds @option{-lg2c} in a command line
|
|
that will link the program.
|
|
Feel free to specify @option{-lg2c} explicitly,
|
|
as appropriate.)
|
|
|
|
However, when providing your own @code{main},
|
|
make sure you perform the appropriate tasks in the
|
|
appropriate order.
|
|
For example, if your @code{main} does not call @code{f_setarg},
|
|
make sure the rest of your application does not call
|
|
@code{GETARG} or @code{IARGC}.
|
|
|
|
And, if your @code{main} fails to ensure that @code{f_exit}
|
|
is called upon program exit,
|
|
some files might end up incompletely written,
|
|
some scratch files might be left lying around,
|
|
and some existing files being written might be left
|
|
with old data not properly truncated at the end.
|
|
|
|
Note that, generally, the @command{g77} operating environment
|
|
does not depend on a procedure named @code{MAIN__} actually
|
|
being called prior to any other @command{g77}-compiled code.
|
|
That is, @code{MAIN__} does not, itself,
|
|
set up any important operating-environment characteristics
|
|
upon which other code might depend.
|
|
This might change in future versions of @command{g77},
|
|
with appropriate notification in the release notes.
|
|
|
|
For more information, consult the source code for the above routines.
|
|
These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
|
|
@file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
|
|
|
|
Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77}
|
|
uses to open-code (inline) references to @code{IARGC}.
|
|
|
|
@node Debugging and Interfacing
|
|
@chapter Debugging and Interfacing
|
|
@cindex debugging
|
|
@cindex interfacing
|
|
@cindex calling C routines
|
|
@cindex C routines calling Fortran
|
|
@cindex f2c compatibility
|
|
|
|
GNU Fortran currently generates code that is object-compatible with
|
|
the @command{f2c} converter.
|
|
Also, it avoids limitations in the current GBE, such as the
|
|
inability to generate a procedure with
|
|
multiple entry points, by generating code that is structured
|
|
differently (in terms of procedure names, scopes, arguments, and
|
|
so on) than might be expected.
|
|
|
|
As a result, writing code in other languages that calls on, is
|
|
called by, or shares in-memory data with @command{g77}-compiled code generally
|
|
requires some understanding of the way @command{g77} compiles code for
|
|
various constructs.
|
|
|
|
Similarly, using a debugger to debug @command{g77}-compiled
|
|
code, even if that debugger supports native Fortran debugging, generally
|
|
requires this sort of information.
|
|
|
|
This section describes some of the basic information on how
|
|
@command{g77} compiles code for constructs involving interfaces to other
|
|
languages and to debuggers.
|
|
|
|
@emph{Caution:} Much or all of this information pertains to only the current
|
|
release of @command{g77}, sometimes even to using certain compiler options
|
|
with @command{g77} (such as @option{-fno-f2c}).
|
|
Do not write code that depends on this
|
|
information without clearly marking said code as nonportable and
|
|
subject to review for every new release of @command{g77}.
|
|
This information
|
|
is provided primarily to make debugging of code generated by this
|
|
particular release of @command{g77} easier for the user, and partly to make
|
|
writing (generally nonportable) interface code easier.
|
|
Both of these
|
|
activities require tracking changes in new version of @command{g77} as they
|
|
are installed, because new versions can change the behaviors
|
|
described in this section.
|
|
|
|
@menu
|
|
* Main Program Unit:: How @command{g77} compiles a main program unit.
|
|
* Procedures:: How @command{g77} constructs parameter lists
|
|
for procedures.
|
|
* Functions:: Functions returning floating-point or character data.
|
|
* Names:: Naming of user-defined variables, procedures, etc.
|
|
* Common Blocks:: Accessing common variables while debugging.
|
|
* Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
|
|
* Complex Variables:: How @command{g77} performs complex arithmetic.
|
|
* Arrays:: Dealing with (possibly multi-dimensional) arrays.
|
|
* Adjustable Arrays:: Special consideration for adjustable arrays.
|
|
* Alternate Entry Points:: How @command{g77} implements alternate @code{ENTRY}.
|
|
* Alternate Returns:: How @command{g77} handles alternate returns.
|
|
* Assigned Statement Labels:: How @command{g77} handles @code{ASSIGN}.
|
|
* Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
|
|
@end menu
|
|
|
|
@node Main Program Unit
|
|
@section Main Program Unit (PROGRAM)
|
|
@cindex PROGRAM statement
|
|
@cindex statements, PROGRAM
|
|
|
|
When @command{g77} compiles a main program unit, it gives it the public
|
|
procedure name @code{MAIN__}.
|
|
The @code{libg2c} library has the actual @code{main()} procedure
|
|
as is typical of C-based environments, and
|
|
it is this procedure that performs some initial start-up
|
|
activity and then calls @code{MAIN__}.
|
|
|
|
Generally, @command{g77} and @code{libg2c} are designed so that you need not
|
|
include a main program unit written in Fortran in your program---it
|
|
can be written in C or some other language.
|
|
Especially for I/O handling, this is the case, although @command{g77} version 0.5.16
|
|
includes a bug fix for @code{libg2c} that solved a problem with using the
|
|
@code{OPEN} statement as the first Fortran I/O activity in a program
|
|
without a Fortran main program unit.
|
|
|
|
However, if you don't intend to use @command{g77} (or @command{f2c}) to compile
|
|
your main program unit---that is, if you intend to compile a @code{main()}
|
|
procedure using some other language---you should carefully
|
|
examine the code for @code{main()} in @code{libg2c}, found in the source
|
|
file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
|
|
might need to be done by your @code{main()} in order to provide the
|
|
Fortran environment your Fortran code is expecting.
|
|
|
|
@cindex @code{IArgC} intrinsic
|
|
@cindex intrinsics, @code{IArgC}
|
|
@cindex @code{GetArg} intrinsic
|
|
@cindex intrinsics, @code{GetArg}
|
|
For example, @code{libg2c}'s @code{main()} sets up the information used by
|
|
the @code{IARGC} and @code{GETARG} intrinsics.
|
|
Bypassing @code{libg2c}'s @code{main()}
|
|
without providing a substitute for this activity would mean
|
|
that invoking @code{IARGC} and @code{GETARG} would produce undefined
|
|
results.
|
|
|
|
@cindex debugging
|
|
@cindex main program unit, debugging
|
|
@cindex main()
|
|
@cindex MAIN__()
|
|
@cindex .gdbinit
|
|
When debugging, one implication of the fact that @code{main()}, which
|
|
is the place where the debugged program ``starts'' from the
|
|
debugger's point of view, is in @code{libg2c} is that you won't be
|
|
starting your Fortran program at a point you recognize as your
|
|
Fortran code.
|
|
|
|
The standard way to get around this problem is to set a break
|
|
point (a one-time, or temporary, break point will do) at
|
|
the entrance to @code{MAIN__}, and then run the program.
|
|
A convenient way to do so is to add the @command{gdb} command
|
|
|
|
@example
|
|
tbreak MAIN__
|
|
@end example
|
|
|
|
@noindent
|
|
to the file @file{.gdbinit} in the directory in which you're debugging
|
|
(using @command{gdb}).
|
|
|
|
After doing this, the debugger will see the current execution
|
|
point of the program as at the beginning of the main program
|
|
unit of your program.
|
|
|
|
Of course, if you really want to set a break point at some
|
|
other place in your program and just start the program
|
|
running, without first breaking at @code{MAIN__},
|
|
that should work fine.
|
|
|
|
@node Procedures
|
|
@section Procedures (SUBROUTINE and FUNCTION)
|
|
@cindex procedures
|
|
@cindex SUBROUTINE statement
|
|
@cindex statements, SUBROUTINE
|
|
@cindex FUNCTION statement
|
|
@cindex statements, FUNCTION
|
|
@cindex signature of procedures
|
|
|
|
Currently, @command{g77} passes arguments via reference---specifically,
|
|
by passing a pointer to the location in memory of a variable, array,
|
|
array element, a temporary location that holds the result of evaluating an
|
|
expression, or a temporary or permanent location that holds the value
|
|
of a constant.
|
|
|
|
Procedures that accept @code{CHARACTER} arguments are implemented by
|
|
@command{g77} so that each @code{CHARACTER} argument has two actual arguments.
|
|
|
|
The first argument occupies the expected position in the
|
|
argument list and has the user-specified name.
|
|
This argument
|
|
is a pointer to an array of characters, passed by the caller.
|
|
|
|
The second argument is appended to the end of the user-specified
|
|
calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
|
|
is the user-specified name.
|
|
This argument is of the C type @code{ftnlen}
|
|
(see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
|
|
is the number of characters the caller has allocated in the
|
|
array pointed to by the first argument.
|
|
|
|
A procedure will ignore the length argument if @samp{X} is not declared
|
|
@code{CHARACTER*(*)}, because for other declarations, it knows the
|
|
length.
|
|
Not all callers necessarily ``know'' this, however, which
|
|
is why they all pass the extra argument.
|
|
|
|
The contents of the @code{CHARACTER} argument are specified by the
|
|
address passed in the first argument (named after it).
|
|
The procedure can read or write these contents as appropriate.
|
|
|
|
When more than one @code{CHARACTER} argument is present in the argument
|
|
list, the length arguments are appended in the order
|
|
the original arguments appear.
|
|
So @samp{CALL FOO('HI','THERE')} is implemented in
|
|
C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77}
|
|
does not provide the trailing null bytes on the constant
|
|
strings (@command{f2c} does provide them, but they are unnecessary in
|
|
a Fortran environment, and you should not expect them to be
|
|
there).
|
|
|
|
Note that the above information applies to @code{CHARACTER} variables and
|
|
arrays @strong{only}.
|
|
It does @strong{not} apply to external @code{CHARACTER}
|
|
functions or to intrinsic @code{CHARACTER} functions.
|
|
That is, no second length argument is passed to @samp{FOO} in this case:
|
|
|
|
@example
|
|
CHARACTER X
|
|
EXTERNAL X
|
|
CALL FOO(X)
|
|
@end example
|
|
|
|
@noindent
|
|
Nor does @samp{FOO} expect such an argument in this case:
|
|
|
|
@example
|
|
SUBROUTINE FOO(X)
|
|
CHARACTER X
|
|
EXTERNAL X
|
|
@end example
|
|
|
|
Because of this implementation detail, if a program has a bug
|
|
such that there is disagreement as to whether an argument is
|
|
a procedure, and the type of the argument is @code{CHARACTER}, subtle
|
|
symptoms might appear.
|
|
|
|
@node Functions
|
|
@section Functions (FUNCTION and RETURN)
|
|
@cindex functions
|
|
@cindex FUNCTION statement
|
|
@cindex statements, FUNCTION
|
|
@cindex RETURN statement
|
|
@cindex statements, RETURN
|
|
@cindex return type of functions
|
|
|
|
@command{g77} handles in a special way functions that return the following
|
|
types:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@code{CHARACTER}
|
|
@item
|
|
@code{COMPLEX}
|
|
@item
|
|
@code{REAL(KIND=1)}
|
|
@end itemize
|
|
|
|
For @code{CHARACTER}, @command{g77} implements a subroutine (a C function
|
|
returning @code{void})
|
|
with two arguments prepended: @samp{__g77_result}, which the caller passes
|
|
as a pointer to a @code{char} array expected to hold the return value,
|
|
and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
|
|
specifying the length of the return value as declared in the calling
|
|
program.
|
|
For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
|
|
to determine the size of the array that @samp{__g77_result} points to;
|
|
otherwise, it ignores that argument.
|
|
|
|
For @code{COMPLEX}, when @option{-ff2c} is in
|
|
force, @command{g77} implements
|
|
a subroutine with one argument prepended: @samp{__g77_result}, which the
|
|
caller passes as a pointer to a variable of the type of the function.
|
|
The called function writes the return value into this variable instead
|
|
of returning it as a function value.
|
|
When @option{-fno-f2c} is in force,
|
|
@command{g77} implements a @code{COMPLEX} function as @command{gcc}'s
|
|
@samp{__complex__ float} or @samp{__complex__ double} function
|
|
(or an emulation thereof, when @option{-femulate-complex} is in effect),
|
|
returning the result of the function in the same way as @command{gcc} would.
|
|
|
|
For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements
|
|
a function that actually returns @code{REAL(KIND=2)} (typically
|
|
C's @code{double} type).
|
|
When @option{-fno-f2c} is in force, @code{REAL(KIND=1)}
|
|
functions return @code{float}.
|
|
|
|
@node Names
|
|
@section Names
|
|
@cindex symbol names
|
|
@cindex transforming symbol names
|
|
|
|
Fortran permits each implementation to decide how to represent
|
|
names as far as how they're seen in other contexts, such as debuggers
|
|
and when interfacing to other languages, and especially as far
|
|
as how casing is handled.
|
|
|
|
External names---names of entities that are public, or ``accessible'',
|
|
to all modules in a program---normally have an underscore (@samp{_})
|
|
appended by @command{g77},
|
|
to generate code that is compatible with @command{f2c}.
|
|
External names include names of Fortran things like common blocks,
|
|
external procedures (subroutines and functions, but not including
|
|
statement functions, which are internal procedures), and entry point
|
|
names.
|
|
|
|
However, use of the @option{-fno-underscoring} option
|
|
disables this kind of transformation of external names (though inhibiting
|
|
the transformation certainly improves the chances of colliding with
|
|
incompatible externals written in other languages---but that
|
|
might be intentional.
|
|
|
|
@cindex -fno-underscoring option
|
|
@cindex options, -fno-underscoring
|
|
@cindex -fno-second-underscore option
|
|
@cindex options, -fno-underscoring
|
|
When @option{-funderscoring} is in force, any name (external or local)
|
|
that already has at least one underscore in it is
|
|
implemented by @command{g77} by appending two underscores.
|
|
(This second underscore can be disabled via the
|
|
@option{-fno-second-underscore} option.)
|
|
External names are changed this way for @command{f2c} compatibility.
|
|
Local names are changed this way to avoid collisions with external names
|
|
that are different in the source code---@command{f2c} does the same thing, but
|
|
there's no compatibility issue there except for user expectations while
|
|
debugging.
|
|
|
|
For example:
|
|
|
|
@example
|
|
Max_Cost = 0
|
|
@end example
|
|
|
|
@cindex debugging
|
|
@noindent
|
|
Here, a user would, in the debugger, refer to this variable using the
|
|
name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
|
|
as described below).
|
|
(We hope to improve @command{g77} in this regard in the future---don't
|
|
write scripts depending on this behavior!
|
|
Also, consider experimenting with the @option{-fno-underscoring}
|
|
option to try out debugging without having to massage names by
|
|
hand like this.)
|
|
|
|
@command{g77} provides a number of command-line options that allow the user
|
|
to control how case mapping is handled for source files.
|
|
The default is the traditional UNIX model for Fortran compilers---names
|
|
are mapped to lower case.
|
|
Other command-line options can be specified to map names to upper
|
|
case, or to leave them exactly as written in the source file.
|
|
|
|
For example:
|
|
|
|
@example
|
|
Foo = 9.436
|
|
@end example
|
|
|
|
@noindent
|
|
Here, it is normally the case that the variable assigned will be named
|
|
@samp{foo}.
|
|
This would be the name to enter when using a debugger to
|
|
access the variable.
|
|
|
|
However, depending on the command-line options specified, the
|
|
name implemented by @command{g77} might instead be @samp{FOO} or even
|
|
@samp{Foo}, thus affecting how debugging is done.
|
|
|
|
Also:
|
|
|
|
@example
|
|
Call Foo
|
|
@end example
|
|
|
|
@noindent
|
|
This would normally call a procedure that, if it were in a separate C program,
|
|
be defined starting with the line:
|
|
|
|
@example
|
|
void foo_()
|
|
@end example
|
|
|
|
@noindent
|
|
However, @command{g77} command-line options could be used to change the casing
|
|
of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
|
|
procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option
|
|
could be used to inhibit the appending of the underscore to the name.
|
|
|
|
@node Common Blocks
|
|
@section Common Blocks (COMMON)
|
|
@cindex common blocks
|
|
@cindex @code{COMMON} statement
|
|
@cindex statements, @code{COMMON}
|
|
|
|
@command{g77} names and lays out @code{COMMON} areas
|
|
the same way @command{f2c} does,
|
|
for compatibility with @command{f2c}.
|
|
|
|
@node Local Equivalence Areas
|
|
@section Local Equivalence Areas (EQUIVALENCE)
|
|
@cindex equivalence areas
|
|
@cindex local equivalence areas
|
|
@cindex EQUIVALENCE statement
|
|
@cindex statements, EQUIVALENCE
|
|
|
|
@command{g77} treats storage-associated areas involving a @code{COMMON}
|
|
block as explained in the section on common blocks.
|
|
|
|
A local @code{EQUIVALENCE} area is a collection of variables and arrays
|
|
connected to each other in any way via @code{EQUIVALENCE}, none of which are
|
|
listed in a @code{COMMON} statement.
|
|
|
|
(@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name
|
|
for @var{x} using a different method when more than one name was
|
|
in the list of names of entities placed at the beginning of the
|
|
array.
|
|
Though the documentation specified that the first name listed in
|
|
the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77}
|
|
in fact chose the name using a method that was so complicated,
|
|
it seemed easier to change it to an alphabetical sort than to describe the
|
|
previous method in the documentation.)
|
|
|
|
@node Complex Variables
|
|
@section Complex Variables (COMPLEX)
|
|
@cindex complex variables
|
|
@cindex imaginary part
|
|
@cindex COMPLEX statement
|
|
@cindex statements, COMPLEX
|
|
|
|
As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types
|
|
(and related intrinsics, constants, functions, and so on)
|
|
in a manner that
|
|
makes direct debugging involving these types in Fortran
|
|
language mode difficult.
|
|
|
|
Essentially, @command{g77} implements these types using an
|
|
internal construct similar to C's @code{struct}, at least
|
|
as seen by the @command{gcc} back end.
|
|
|
|
Currently, the back end, when outputting debugging info with
|
|
the compiled code for the assembler to digest, does not detect
|
|
these @code{struct} types as being substitutes for Fortran
|
|
complex.
|
|
As a result, the Fortran language modes of debuggers such as
|
|
@command{gdb} see these types as C @code{struct} types, which
|
|
they might or might not support.
|
|
|
|
Until this is fixed, switch to C language mode to work with
|
|
entities of @code{COMPLEX} type and then switch back to Fortran language
|
|
mode afterward.
|
|
(In @command{gdb}, this is accomplished via @samp{set lang c} and
|
|
either @samp{set lang fortran} or @samp{set lang auto}.)
|
|
|
|
@node Arrays
|
|
@section Arrays (DIMENSION)
|
|
@cindex DIMENSION statement
|
|
@cindex statements, DIMENSION
|
|
@cindex array ordering
|
|
@cindex ordering, array
|
|
@cindex column-major ordering
|
|
@cindex row-major ordering
|
|
@cindex arrays
|
|
|
|
Fortran uses ``column-major ordering'' in its arrays.
|
|
This differs from other languages, such as C, which use ``row-major ordering''.
|
|
The difference is that, with Fortran, array elements adjacent to
|
|
each other in memory differ in the @emph{first} subscript instead of
|
|
the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
|
|
whereas with row-major ordering it would follow @samp{A(5,10,19)}.
|
|
|
|
This consideration
|
|
affects not only interfacing with and debugging Fortran code,
|
|
it can greatly affect how code is designed and written, especially
|
|
when code speed and size is a concern.
|
|
|
|
Fortran also differs from C, a popular language for interfacing and
|
|
to support directly in debuggers, in the way arrays are treated.
|
|
In C, arrays are single-dimensional and have interesting relationships
|
|
to pointers, neither of which is true for Fortran.
|
|
As a result, dealing with Fortran arrays from within
|
|
an environment limited to C concepts can be challenging.
|
|
|
|
For example, accessing the array element @samp{A(5,10,20)} is easy enough
|
|
in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
|
|
are needed.
|
|
First, C would treat the A array as a single-dimension array.
|
|
Second, C does not understand low bounds for arrays as does Fortran.
|
|
Third, C assumes a low bound of zero (0), while Fortran defaults to a
|
|
low bound of one (1) and can supports an arbitrary low bound.
|
|
Therefore, calculations must be done
|
|
to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
|
|
calculations require knowing the dimensions of @samp{A}.
|
|
|
|
For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
|
|
@samp{A(5,10,20)} would be:
|
|
|
|
@example
|
|
(5-2)
|
|
+ (10-1)*(11-2+1)
|
|
+ (20-0)*(11-2+1)*(21-1+1)
|
|
= 4293
|
|
@end example
|
|
|
|
@noindent
|
|
So the C equivalent in this case would be @samp{a[4293]}.
|
|
|
|
When using a debugger directly on Fortran code, the C equivalent
|
|
might not work, because some debuggers cannot understand the notion
|
|
of low bounds other than zero. However, unlike @command{f2c}, @command{g77}
|
|
does inform the GBE that a multi-dimensional array (like @samp{A}
|
|
in the above example) is really multi-dimensional, rather than a
|
|
single-dimensional array, so at least the dimensionality of the array
|
|
is preserved.
|
|
|
|
Debuggers that understand Fortran should have no trouble with
|
|
non-zero low bounds, but for non-Fortran debuggers, especially
|
|
C debuggers, the above example might have a C equivalent of
|
|
@samp{a[4305]}.
|
|
This calculation is arrived at by eliminating the subtraction
|
|
of the lower bound in the first parenthesized expression on each
|
|
line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
|
|
substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
|
|
Actually, the implication of
|
|
this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
|
|
but that @samp{a[20][10][5]} produces the equivalent of
|
|
@samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
|
|
|
|
Come to think of it, perhaps
|
|
the behavior is due to the debugger internally compensating for
|
|
the lower bounds by offsetting the base address of @samp{a}, leaving
|
|
@samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
|
|
its first element as identified by subscripts equal to the
|
|
corresponding lower bounds).
|
|
|
|
You know, maybe nobody really needs to use arrays.
|
|
|
|
@node Adjustable Arrays
|
|
@section Adjustable Arrays (DIMENSION)
|
|
@cindex arrays, adjustable
|
|
@cindex adjustable arrays
|
|
@cindex arrays, automatic
|
|
@cindex automatic arrays
|
|
@cindex DIMENSION statement
|
|
@cindex statements, DIMENSION
|
|
@cindex dimensioning arrays
|
|
@cindex arrays, dimensioning
|
|
|
|
Adjustable and automatic arrays in Fortran require the implementation
|
|
(in this
|
|
case, the @command{g77} compiler) to ``memorize'' the expressions that
|
|
dimension the arrays each time the procedure is invoked.
|
|
This is so that subsequent changes to variables used in those
|
|
expressions, made during execution of the procedure, do not
|
|
have any effect on the dimensions of those arrays.
|
|
|
|
For example:
|
|
|
|
@example
|
|
REAL ARRAY(5)
|
|
DATA ARRAY/5*2/
|
|
CALL X(ARRAY, 5)
|
|
END
|
|
SUBROUTINE X(A, N)
|
|
DIMENSION A(N)
|
|
N = 20
|
|
PRINT *, N, A
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
Here, the implementation should, when running the program, print something
|
|
like:
|
|
|
|
@example
|
|
20 2. 2. 2. 2. 2.
|
|
@end example
|
|
|
|
@noindent
|
|
Note that this shows that while the value of @samp{N} was successfully
|
|
changed, the size of the @samp{A} array remained at 5 elements.
|
|
|
|
To support this, @command{g77} generates code that executes before any user
|
|
code (and before the internally generated computed @code{GOTO} to handle
|
|
alternate entry points, as described below) that evaluates each
|
|
(nonconstant) expression in the list of subscripts for an
|
|
array, and saves the result of each such evaluation to be used when
|
|
determining the size of the array (instead of re-evaluating the
|
|
expressions).
|
|
|
|
So, in the above example, when @samp{X} is first invoked, code is
|
|
executed that copies the value of @samp{N} to a temporary.
|
|
And that same temporary serves as the actual high bound for the single
|
|
dimension of the @samp{A} array (the low bound being the constant 1).
|
|
Since the user program cannot (legitimately) change the value
|
|
of the temporary during execution of the procedure, the size
|
|
of the array remains constant during each invocation.
|
|
|
|
For alternate entry points, the code @command{g77} generates takes into
|
|
account the possibility that a dummy adjustable array is not actually
|
|
passed to the actual entry point being invoked at that time.
|
|
In that case, the public procedure implementing the entry point
|
|
passes to the master private procedure implementing all the
|
|
code for the entry points a @code{NULL} pointer where a pointer to that
|
|
adjustable array would be expected.
|
|
The @command{g77}-generated code
|
|
doesn't attempt to evaluate any of the expressions in the subscripts
|
|
for an array if the pointer to that array is @code{NULL} at run time in
|
|
such cases.
|
|
(Don't depend on this particular implementation
|
|
by writing code that purposely passes @code{NULL} pointers where the
|
|
callee expects adjustable arrays, even if you know the callee
|
|
won't reference the arrays---nor should you pass @code{NULL} pointers
|
|
for any dummy arguments used in calculating the bounds of such
|
|
arrays or leave undefined any values used for that purpose in
|
|
COMMON---because the way @command{g77} implements these things might
|
|
change in the future!)
|
|
|
|
@node Alternate Entry Points
|
|
@section Alternate Entry Points (ENTRY)
|
|
@cindex alternate entry points
|
|
@cindex entry points
|
|
@cindex ENTRY statement
|
|
@cindex statements, ENTRY
|
|
|
|
The GBE does not understand the general concept of
|
|
alternate entry points as Fortran provides via the ENTRY statement.
|
|
@command{g77} gets around this by using an approach to compiling procedures
|
|
having at least one @code{ENTRY} statement that is almost identical to the
|
|
approach used by @command{f2c}.
|
|
(An alternate approach could be used that
|
|
would probably generate faster, but larger, code that would also
|
|
be a bit easier to debug.)
|
|
|
|
Information on how @command{g77} implements @code{ENTRY} is provided for those
|
|
trying to debug such code.
|
|
The choice of implementation seems
|
|
unlikely to affect code (compiled in other languages) that interfaces
|
|
to such code.
|
|
|
|
@command{g77} compiles exactly one public procedure for the primary entry
|
|
point of a procedure plus each @code{ENTRY} point it specifies, as usual.
|
|
That is, in terms of the public interface, there is no difference
|
|
between
|
|
|
|
@example
|
|
SUBROUTINE X
|
|
END
|
|
SUBROUTINE Y
|
|
END
|
|
@end example
|
|
|
|
@noindent
|
|
and:
|
|
|
|
@example
|
|
SUBROUTINE X
|
|
ENTRY Y
|
|
END
|
|
@end example
|
|
|
|
The difference between the above two cases lies in the code compiled
|
|
for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
|
|
for the second case, an extra internal procedure is compiled.
|
|
|
|
For every Fortran procedure with at least one @code{ENTRY}
|
|
statement, @command{g77} compiles an extra procedure
|
|
named @samp{__g77_masterfun_@var{x}}, where @var{x} is
|
|
the name of the primary entry point (which, in the above case,
|
|
using the standard compiler options, would be @samp{x_} in C).
|
|
|
|
This extra procedure is compiled as a private procedure---that is,
|
|
a procedure not accessible by name to separately compiled modules.
|
|
It contains all the code in the program unit, including the code
|
|
for the primary entry point plus for every entry point.
|
|
(The code for each public procedure is quite short, and explained later.)
|
|
|
|
The extra procedure has some other interesting characteristics.
|
|
|
|
The argument list for this procedure is invented by @command{g77}.
|
|
It contains
|
|
a single integer argument named @samp{__g77_which_entrypoint},
|
|
passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
|
|
entry point index---0 for the primary entry point, 1 for the
|
|
first entry point (the first @code{ENTRY} statement encountered), 2 for
|
|
the second entry point, and so on.
|
|
|
|
It also contains, for functions returning @code{CHARACTER} and
|
|
(when @option{-ff2c} is in effect) @code{COMPLEX} functions,
|
|
and for functions returning different types among the
|
|
@code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
|
|
containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
|
|
is expected at run time to contain a pointer to where to store
|
|
the result of the entry point.
|
|
For @code{CHARACTER} functions, this
|
|
storage area is an array of the appropriate number of characters;
|
|
for @code{COMPLEX} functions, it is the appropriate area for the return
|
|
type; for multiple-return-type functions, it is a union of all the supported return
|
|
types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
|
|
and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
|
|
is not supported by @command{g77}).
|
|
|
|
For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
|
|
by yet another argument named @samp{__g77_length} that, at run time,
|
|
specifies the caller's expected length of the returned value.
|
|
Note that only @code{CHARACTER*(*)} functions and entry points actually
|
|
make use of this argument, even though it is always passed by
|
|
all callers of public @code{CHARACTER} functions (since the caller does not
|
|
generally know whether such a function is @code{CHARACTER*(*)} or whether
|
|
there are any other callers that don't have that information).
|
|
|
|
The rest of the argument list is the union of all the arguments
|
|
specified for all the entry points (in their usual forms, e.g.
|
|
@code{CHARACTER} arguments have extra length arguments, all appended at
|
|
the end of this list).
|
|
This is considered the ``master list'' of
|
|
arguments.
|
|
|
|
The code for this procedure has, before the code for the first
|
|
executable statement, code much like that for the following Fortran
|
|
statement:
|
|
|
|
@smallexample
|
|
GOTO (100000,100001,100002), __g77_which_entrypoint
|
|
100000 @dots{}code for primary entry point@dots{}
|
|
100001 @dots{}code immediately following first ENTRY statement@dots{}
|
|
100002 @dots{}code immediately following second ENTRY statement@dots{}
|
|
@end smallexample
|
|
|
|
@noindent
|
|
(Note that invalid Fortran statement labels and variable names
|
|
are used in the above example to highlight the fact that it
|
|
represents code generated by the @command{g77} internals, not code to be
|
|
written by the user.)
|
|
|
|
It is this code that, when the procedure is called, picks which
|
|
entry point to start executing.
|
|
|
|
Getting back to the public procedures (@samp{x} and @samp{Y} in the original
|
|
example), those procedures are fairly simple.
|
|
Their interfaces
|
|
are just like they would be if they were self-contained procedures
|
|
(without @code{ENTRY}), of course, since that is what the callers
|
|
expect.
|
|
Their code consists of simply calling the private
|
|
procedure, described above, with the appropriate extra arguments
|
|
(the entry point index, and perhaps a pointer to a multiple-type-
|
|
return variable, local to the public procedure, that contains
|
|
all the supported returnable non-character types).
|
|
For arguments
|
|
that are not listed for a given entry point that are listed for
|
|
other entry points, and therefore that are in the ``master list''
|
|
for the private procedure, null pointers (in C, the @code{NULL} macro)
|
|
are passed.
|
|
Also, for entry points that are part of a multiple-type-
|
|
returning function, code is compiled after the call of the private
|
|
procedure to extract from the multi-type union the appropriate result,
|
|
depending on the type of the entry point in question, returning
|
|
that result to the original caller.
|
|
|
|
When debugging a procedure containing alternate entry points, you
|
|
can either set a break point on the public procedure itself (e.g.
|
|
a break point on @samp{X} or @samp{Y}) or on the private procedure that
|
|
contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
|
|
If you do the former, you should use the debugger's command to
|
|
``step into'' the called procedure to get to the actual code; with
|
|
the latter approach, the break point leaves you right at the
|
|
actual code, skipping over the public entry point and its call
|
|
to the private procedure (unless you have set a break point there
|
|
as well, of course).
|
|
|
|
Further, the list of dummy arguments that is visible when the
|
|
private procedure is active is going to be the expanded version
|
|
of the list for whichever particular entry point is active,
|
|
as explained above, and the way in which return values are
|
|
handled might well be different from how they would be handled
|
|
for an equivalent single-entry function.
|
|
|
|
@node Alternate Returns
|
|
@section Alternate Returns (SUBROUTINE and RETURN)
|
|
@cindex subroutines
|
|
@cindex alternate returns
|
|
@cindex SUBROUTINE statement
|
|
@cindex statements, SUBROUTINE
|
|
@cindex RETURN statement
|
|
@cindex statements, RETURN
|
|
|
|
Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
|
|
@samp{CALL X(*50)}) are implemented by @command{g77} as functions returning
|
|
the C @code{int} type.
|
|
The actual alternate-return arguments are omitted from the calling sequence.
|
|
Instead, the caller uses
|
|
the return value to do a rough equivalent of the Fortran
|
|
computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
|
|
example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
|
|
function), and the callee just returns whatever integer
|
|
is specified in the @code{RETURN} statement for the subroutine
|
|
For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
|
|
by @samp{RETURN}
|
|
in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
|
|
|
|
@node Assigned Statement Labels
|
|
@section Assigned Statement Labels (ASSIGN and GOTO)
|
|
@cindex assigned statement labels
|
|
@cindex statement labels, assigned
|
|
@cindex ASSIGN statement
|
|
@cindex statements, ASSIGN
|
|
@cindex GOTO statement
|
|
@cindex statements, GOTO
|
|
|
|
For portability to machines where a pointer (such as to a label,
|
|
which is how @command{g77} implements @code{ASSIGN} and its relatives,
|
|
the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
|
|
is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77}
|
|
uses a different memory location to hold the @code{ASSIGN}ed value of a variable
|
|
than it does the numerical value in that variable, unless the
|
|
variable is wide enough (can hold enough bits).
|
|
|
|
In particular, while @command{g77} implements
|
|
|
|
@example
|
|
I = 10
|
|
@end example
|
|
|
|
@noindent
|
|
as, in C notation, @samp{i = 10;}, it implements
|
|
|
|
@example
|
|
ASSIGN 10 TO I
|
|
@end example
|
|
|
|
@noindent
|
|
as, in GNU's extended C notation (for the label syntax),
|
|
@samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
|
|
of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't
|
|
actually generate the name @samp{L10} or any other name like that,
|
|
since debuggers cannot access labels anyway).
|
|
|
|
While this currently means that an @code{ASSIGN} statement does not
|
|
overwrite the numeric contents of its target variable, @emph{do not}
|
|
write any code depending on this feature.
|
|
@command{g77} has already changed this implementation across
|
|
versions and might do so in the future.
|
|
This information is provided only to make debugging Fortran programs
|
|
compiled with the current version of @command{g77} somewhat easier.
|
|
If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
|
|
in a program unit that does @samp{ASSIGN 10 TO I}, that probably
|
|
means @command{g77} has decided it can store the pointer to the label directly
|
|
into @samp{I} itself.
|
|
|
|
@xref{Ugly Assigned Labels}, for information on a command-line option
|
|
to force @command{g77} to use the same storage for both normal and
|
|
assigned-label uses of a variable.
|
|
|
|
@node Run-time Library Errors
|
|
@section Run-time Library Errors
|
|
@cindex IOSTAT=
|
|
@cindex error values
|
|
@cindex error messages
|
|
@cindex messages, run-time
|
|
@cindex I/O, errors
|
|
|
|
The @code{libg2c} library currently has the following table to relate
|
|
error code numbers, returned in @code{IOSTAT=} variables, to messages.
|
|
This information should, in future versions of this document, be
|
|
expanded upon to include detailed descriptions of each message.
|
|
|
|
In line with good coding practices, any of the numbers in the
|
|
list below should @emph{not} be directly written into Fortran
|
|
code you write.
|
|
Instead, make a separate @code{INCLUDE} file that defines
|
|
@code{PARAMETER} names for them, and use those in your code,
|
|
so you can more easily change the actual numbers in the future.
|
|
|
|
The information below is culled from the definition
|
|
of @code{F_err} in @file{f/runtime/libI77/err.c} in the
|
|
@command{g77} source tree.
|
|
|
|
@smallexample
|
|
100: "error in format"
|
|
101: "illegal unit number"
|
|
102: "formatted io not allowed"
|
|
103: "unformatted io not allowed"
|
|
104: "direct io not allowed"
|
|
105: "sequential io not allowed"
|
|
106: "can't backspace file"
|
|
107: "null file name"
|
|
108: "can't stat file"
|
|
109: "unit not connected"
|
|
110: "off end of record"
|
|
111: "truncation failed in endfile"
|
|
112: "incomprehensible list input"
|
|
113: "out of free space"
|
|
114: "unit not connected"
|
|
115: "read unexpected character"
|
|
116: "bad logical input field"
|
|
117: "bad variable type"
|
|
118: "bad namelist name"
|
|
119: "variable not in namelist"
|
|
120: "no end record"
|
|
121: "variable count incorrect"
|
|
122: "subscript for scalar variable"
|
|
123: "invalid array section"
|
|
124: "substring out of bounds"
|
|
125: "subscript out of bounds"
|
|
126: "can't read file"
|
|
127: "can't write file"
|
|
128: "'new' file exists"
|
|
129: "can't append to file"
|
|
130: "non-positive record number"
|
|
131: "I/O started while already doing I/O"
|
|
@end smallexample
|
|
|
|
@node Collected Fortran Wisdom
|
|
@chapter Collected Fortran Wisdom
|
|
@cindex wisdom
|
|
@cindex legacy code
|
|
@cindex code, legacy
|
|
@cindex writing code
|
|
@cindex code, writing
|
|
|
|
Most users of @command{g77} can be divided into two camps:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Those writing new Fortran code to be compiled by @command{g77}.
|
|
|
|
@item
|
|
Those using @command{g77} to compile existing, ``legacy'' code.
|
|
@end itemize
|
|
|
|
Users writing new code generally understand most of the necessary
|
|
aspects of Fortran to write ``mainstream'' code, but often need
|
|
help deciding how to handle problems, such as the construction
|
|
of libraries containing @code{BLOCK DATA}.
|
|
|
|
Users dealing with ``legacy'' code sometimes don't have much
|
|
experience with Fortran, but believe that the code they're compiling
|
|
already works when compiled by other compilers (and might
|
|
not understand why, as is sometimes the case, it doesn't work
|
|
when compiled by @command{g77}).
|
|
|
|
The following information is designed to help users do a better job
|
|
coping with existing, ``legacy'' Fortran code, and with writing
|
|
new code as well.
|
|
|
|
@menu
|
|
* Advantages Over f2c:: If @command{f2c} is so great, why @command{g77}?
|
|
* Block Data and Libraries:: How @command{g77} solves a common problem.
|
|
* Loops:: Fortran @code{DO} loops surprise many people.
|
|
* Working Programs:: Getting programs to work should be done first.
|
|
* Overly Convenient Options:: Temptations to avoid, habits to not form.
|
|
* Faster Programs:: Everybody wants these, but at what cost?
|
|
@end menu
|
|
|
|
@node Advantages Over f2c
|
|
@section Advantages Over f2c
|
|
|
|
Without @command{f2c}, @command{g77} would have taken much longer to
|
|
do and probably not been as good for quite a while.
|
|
Sometimes people who notice how much @command{g77} depends on, and
|
|
documents encouragement to use, @command{f2c} ask why @command{g77}
|
|
was created if @command{f2c} already existed.
|
|
|
|
This section gives some basic answers to these questions, though it
|
|
is not intended to be comprehensive.
|
|
|
|
@menu
|
|
* Language Extensions:: Features used by Fortran code.
|
|
* Diagnostic Abilities:: Abilities to spot problems early.
|
|
* Compiler Options:: Features helpful to accommodate legacy code, etc.
|
|
* Compiler Speed:: Speed of the compilation process.
|
|
* Program Speed:: Speed of the generated, optimized code.
|
|
* Ease of Debugging:: Debugging ease-of-use at the source level.
|
|
* Character and Hollerith Constants:: A byte saved is a byte earned.
|
|
@end menu
|
|
|
|
@node Language Extensions
|
|
@subsection Language Extensions
|
|
|
|
@command{g77} offers several extensions to FORTRAN 77 language that @command{f2c}
|
|
doesn't:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Automatic arrays
|
|
|
|
@item
|
|
@code{CYCLE} and @code{EXIT}
|
|
|
|
@item
|
|
Construct names
|
|
|
|
@item
|
|
@code{SELECT CASE}
|
|
|
|
@item
|
|
@code{KIND=} and @code{LEN=} notation
|
|
|
|
@item
|
|
Semicolon as statement separator
|
|
|
|
@item
|
|
Constant expressions in @code{FORMAT} statements
|
|
(such as @samp{FORMAT(I<J>)},
|
|
where @samp{J} is a @code{PARAMETER} named constant)
|
|
|
|
@item
|
|
@code{MvBits} intrinsic
|
|
|
|
@item
|
|
@code{libU77} (Unix-compatibility) library,
|
|
with routines known to compiler as intrinsics
|
|
(so they work even when compiler options are used
|
|
to change the interfaces used by Fortran routines)
|
|
@end itemize
|
|
|
|
@command{g77} also implements iterative @code{DO} loops
|
|
so that they work even in the presence of certain ``extreme'' inputs,
|
|
unlike @command{f2c}.
|
|
@xref{Loops}.
|
|
|
|
However, @command{f2c} offers a few that @command{g77} doesn't, such as:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Intrinsics in @code{PARAMETER} statements
|
|
|
|
@item
|
|
Array bounds expressions (such as @samp{REAL M(N(2))})
|
|
|
|
@item
|
|
@code{AUTOMATIC} statement
|
|
@end itemize
|
|
|
|
It is expected that @command{g77} will offer some or all of these missing
|
|
features at some time in the future.
|
|
|
|
@node Diagnostic Abilities
|
|
@subsection Diagnostic Abilities
|
|
|
|
@command{g77} offers better diagnosis of problems in @code{FORMAT} statements.
|
|
@command{f2c} doesn't, for example, emit any diagnostic for
|
|
@samp{FORMAT(XZFAJG10324)},
|
|
leaving that to be diagnosed, at run time, by
|
|
the @code{libf2c} run-time library.
|
|
|
|
@node Compiler Options
|
|
@subsection Compiler Options
|
|
|
|
@command{g77} offers compiler options that @command{f2c} doesn't,
|
|
most of which are designed to more easily accommodate
|
|
legacy code:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Two that control the automatic appending of extra
|
|
underscores to external names
|
|
|
|
@item
|
|
One that allows dollar signs (@samp{$}) in symbol names
|
|
|
|
@item
|
|
A variety that control acceptance of various
|
|
``ugly'' constructs
|
|
|
|
@item
|
|
Several that specify acceptable use of upper and lower case
|
|
in the source code
|
|
|
|
@item
|
|
Many that enable, disable, delete, or hide
|
|
groups of intrinsics
|
|
|
|
@item
|
|
One to specify the length of fixed-form source lines
|
|
(normally 72)
|
|
|
|
@item
|
|
One to specify the the source code is written in
|
|
Fortran-90-style free-form
|
|
@end itemize
|
|
|
|
However, @command{f2c} offers a few that @command{g77} doesn't,
|
|
like an option to have @code{REAL} default to @code{REAL*8}.
|
|
It is expected that @command{g77} will offer all of the
|
|
missing options pertinent to being a Fortran compiler
|
|
at some time in the future.
|
|
|
|
@node Compiler Speed
|
|
@subsection Compiler Speed
|
|
|
|
Saving the steps of writing and then rereading C code is a big reason
|
|
why @command{g77} should be able to compile code much faster than using
|
|
@command{f2c} in conjunction with the equivalent invocation of @command{gcc}.
|
|
|
|
However, due to @command{g77}'s youth, lots of self-checking is still being
|
|
performed.
|
|
As a result, this improvement is as yet unrealized
|
|
(though the potential seems to be there for quite a big speedup
|
|
in the future).
|
|
It is possible that, as of version 0.5.18, @command{g77}
|
|
is noticeably faster compiling many Fortran source files than using
|
|
@command{f2c} in conjunction with @command{gcc}.
|
|
|
|
@node Program Speed
|
|
@subsection Program Speed
|
|
|
|
@command{g77} has the potential to better optimize code than @command{f2c},
|
|
even when @command{gcc} is used to compile the output of @command{f2c},
|
|
because @command{f2c} must necessarily
|
|
translate Fortran into a somewhat lower-level language (C) that cannot
|
|
preserve all the information that is potentially useful for optimization,
|
|
while @command{g77} can gather, preserve, and transmit that information directly
|
|
to the GBE.
|
|
|
|
For example, @command{g77} implements @code{ASSIGN} and assigned
|
|
@code{GOTO} using direct assignment of pointers to labels and direct
|
|
jumps to labels, whereas @command{f2c} maps the assigned labels to
|
|
integer values and then uses a C @code{switch} statement to encode
|
|
the assigned @code{GOTO} statements.
|
|
|
|
However, as is typical, theory and reality don't quite match, at least
|
|
not in all cases, so it is still the case that @command{f2c} plus @command{gcc}
|
|
can generate code that is faster than @command{g77}.
|
|
|
|
Version 0.5.18 of @command{g77} offered default
|
|
settings and options, via patches to the @command{gcc}
|
|
back end, that allow for better program speed, though
|
|
some of these improvements also affected the performance
|
|
of programs translated by @command{f2c} and then compiled
|
|
by @command{g77}'s version of @command{gcc}.
|
|
|
|
Version 0.5.20 of @command{g77} offers further performance
|
|
improvements, at least one of which (alias analysis) is
|
|
not generally applicable to @command{f2c} (though @command{f2c}
|
|
could presumably be changed to also take advantage of
|
|
this new capability of the @command{gcc} back end, assuming
|
|
this is made available in an upcoming release of @command{gcc}).
|
|
|
|
@node Ease of Debugging
|
|
@subsection Ease of Debugging
|
|
|
|
Because @command{g77} compiles directly to assembler code like @command{gcc},
|
|
instead of translating to an intermediate language (C) as does @command{f2c},
|
|
support for debugging can be better for @command{g77} than @command{f2c}.
|
|
|
|
However, although @command{g77} might be somewhat more ``native'' in terms of
|
|
debugging support than @command{f2c} plus @command{gcc}, there still are a lot
|
|
of things ``not quite right''.
|
|
Many of the important ones should be resolved in the near future.
|
|
|
|
For example, @command{g77} doesn't have to worry about reserved names
|
|
like @command{f2c} does.
|
|
Given @samp{FOR = WHILE}, @command{f2c} must necessarily
|
|
translate this to something @emph{other} than
|
|
@samp{for = while;}, because C reserves those words.
|
|
|
|
However, @command{g77} does still uses things like an extra level of indirection
|
|
for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
|
|
yet support multiple entry points.
|
|
|
|
Another example is that, given
|
|
|
|
@smallexample
|
|
COMMON A, B
|
|
EQUIVALENCE (B, C)
|
|
@end smallexample
|
|
|
|
@noindent
|
|
the @command{g77} user should be able to access the variables directly, by name,
|
|
without having to traverse C-like structures and unions, while @command{f2c}
|
|
is unlikely to ever offer this ability (due to limitations in the
|
|
C language).
|
|
|
|
However, due to apparent bugs in the back end, @command{g77} currently doesn't
|
|
take advantage of this facility at all---it doesn't emit any debugging
|
|
information for @code{COMMON} and @code{EQUIVALENCE} areas,
|
|
other than information
|
|
on the array of @code{char} it creates (and, in the case
|
|
of local @code{EQUIVALENCE}, names) for each such area.
|
|
|
|
Yet another example is arrays.
|
|
@command{g77} represents them to the debugger
|
|
using the same ``dimensionality'' as in the source code, while @command{f2c}
|
|
must necessarily convert them all to one-dimensional arrays to fit
|
|
into the confines of the C language.
|
|
However, the level of support
|
|
offered by debuggers for interactive Fortran-style access to arrays
|
|
as compiled by @command{g77} can vary widely.
|
|
In some cases, it can actually
|
|
be an advantage that @command{f2c} converts everything to widely supported
|
|
C semantics.
|
|
|
|
In fairness, @command{g77} could do many of the things @command{f2c} does
|
|
to get things working at least as well as @command{f2c}---for now,
|
|
the developers prefer making @command{g77} work the
|
|
way they think it is supposed to, and finding help improving the
|
|
other products (the back end of @command{gcc}; @command{gdb}; and so on)
|
|
to get things working properly.
|
|
|
|
@node Character and Hollerith Constants
|
|
@subsection Character and Hollerith Constants
|
|
@cindex character constants
|
|
@cindex constants, character
|
|
@cindex Hollerith constants
|
|
@cindex constants, Hollerith
|
|
@cindex trailing null byte
|
|
@cindex null byte, trailing
|
|
@cindex zero byte, trailing
|
|
|
|
To avoid the extensive hassle that would be needed to avoid this,
|
|
@command{f2c} uses C character constants to encode character and Hollerith
|
|
constants.
|
|
That means a constant like @samp{'HELLO'} is translated to
|
|
@samp{"hello"} in C, which further means that an extra null byte is
|
|
present at the end of the constant.
|
|
This null byte is superfluous.
|
|
|
|
@command{g77} does not generate such null bytes.
|
|
This represents significant
|
|
savings of resources, such as on systems where @file{/dev/null} or
|
|
@file{/dev/zero} represent bottlenecks in the systems' performance,
|
|
because @command{g77} simply asks for fewer zeros from the operating
|
|
system than @command{f2c}.
|
|
(Avoiding spurious use of zero bytes, each byte typically have
|
|
eight zero bits, also reduces the liabilities in case
|
|
Microsoft's rumored patent on the digits 0 and 1 is upheld.)
|
|
|
|
@node Block Data and Libraries
|
|
@section Block Data and Libraries
|
|
@cindex block data and libraries
|
|
@cindex BLOCK DATA statement
|
|
@cindex statements, BLOCK DATA
|
|
@cindex libraries, containing BLOCK DATA
|
|
@cindex f2c compatibility
|
|
@cindex compatibility, f2c
|
|
|
|
To ensure that block data program units are linked, especially a concern
|
|
when they are put into libraries, give each one a name (as in
|
|
@samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
|
|
statement in every program unit that uses any common block
|
|
initialized by the corresponding @code{BLOCK DATA}.
|
|
@command{g77} currently compiles a @code{BLOCK DATA} as if it were a
|
|
@code{SUBROUTINE},
|
|
that is, it generates an actual procedure having the appropriate name.
|
|
The procedure does nothing but return immediately if it happens to be
|
|
called.
|
|
For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
|
|
same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO}
|
|
in the program and ensures that by generating a
|
|
reference to it so the linker will make sure it is present.
|
|
(Specifically, @command{g77} outputs in the data section a static pointer to the
|
|
external name @samp{FOO}.)
|
|
|
|
The implementation @command{g77} currently uses to make this work is
|
|
one of the few things not compatible with @command{f2c} as currently
|
|
shipped.
|
|
@command{f2c} currently does nothing with @samp{EXTERNAL FOO} except
|
|
issue a warning that @samp{FOO} is not otherwise referenced,
|
|
and, for @samp{BLOCK DATA FOO},
|
|
@command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
|
|
The upshot is that you shouldn't mix @command{f2c} and @command{g77} in
|
|
this particular case.
|
|
If you use @command{f2c} to compile @samp{BLOCK DATA FOO},
|
|
then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO}
|
|
will result in an unresolved reference when linked.
|
|
If you do the
|
|
opposite, then @samp{FOO} might not be linked in under various
|
|
circumstances (such as when @samp{FOO} is in a library, or you're
|
|
using a ``clever'' linker---so clever, it produces a broken program
|
|
with little or no warning by omitting initializations of global data
|
|
because they are contained in unreferenced procedures).
|
|
|
|
The changes you make to your code to make @command{g77} handle this situation,
|
|
however, appear to be a widely portable way to handle it.
|
|
That is, many systems permit it (as they should, since the
|
|
FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
|
|
is a block data program unit), and of the ones
|
|
that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
|
|
them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
|
|
program units.
|
|
|
|
Here is the recommended approach to modifying a program containing
|
|
a program unit such as the following:
|
|
|
|
@smallexample
|
|
BLOCK DATA FOO
|
|
COMMON /VARS/ X, Y, Z
|
|
DATA X, Y, Z / 3., 4., 5. /
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
If the above program unit might be placed in a library module, then
|
|
ensure that every program unit in every program that references that
|
|
particular @code{COMMON} area uses the @code{EXTERNAL} statement
|
|
to force the area to be initialized.
|
|
|
|
For example, change a program unit that starts with
|
|
|
|
@smallexample
|
|
INTEGER FUNCTION CURX()
|
|
COMMON /VARS/ X, Y, Z
|
|
CURX = X
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
so that it uses the @code{EXTERNAL} statement, as in:
|
|
|
|
@smallexample
|
|
INTEGER FUNCTION CURX()
|
|
COMMON /VARS/ X, Y, Z
|
|
EXTERNAL FOO
|
|
CURX = X
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
That way, @samp{CURX} is compiled by @command{g77} (and many other
|
|
compilers) so that the linker knows it must include @samp{FOO},
|
|
the @code{BLOCK DATA} program unit that sets the initial values
|
|
for the variables in @samp{VAR}, in the executable program.
|
|
|
|
@node Loops
|
|
@section Loops
|
|
@cindex DO statement
|
|
@cindex statements, DO
|
|
@cindex trips, number of
|
|
@cindex number of trips
|
|
|
|
The meaning of a @code{DO} loop in Fortran is precisely specified
|
|
in the Fortran standard@dots{}and is quite different from what
|
|
many programmers might expect.
|
|
|
|
In particular, Fortran iterative @code{DO} loops are implemented as if
|
|
the number of trips through the loop is calculated @emph{before}
|
|
the loop is entered.
|
|
|
|
The number of trips for a loop is calculated from the @var{start},
|
|
@var{end}, and @var{increment} values specified in a statement such as:
|
|
|
|
@smallexample
|
|
DO @var{iter} = @var{start}, @var{end}, @var{increment}
|
|
@end smallexample
|
|
|
|
@noindent
|
|
The trip count is evaluated using a fairly simple formula
|
|
based on the three values following the @samp{=} in the
|
|
statement, and it is that trip count that is effectively
|
|
decremented during each iteration of the loop.
|
|
If, at the beginning of an iteration of the loop, the
|
|
trip count is zero or negative, the loop terminates.
|
|
The per-loop-iteration modifications to @var{iter} are not
|
|
related to determining whether to terminate the loop.
|
|
|
|
There are two important things to remember about the trip
|
|
count:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
It can be @emph{negative}, in which case it is
|
|
treated as if it was zero---meaning the loop is
|
|
not executed at all.
|
|
|
|
@item
|
|
The type used to @emph{calculate} the trip count
|
|
is the same type as @var{iter}, but the final
|
|
calculation, and thus the type of the trip
|
|
count itself, always is @code{INTEGER(KIND=1)}.
|
|
@end itemize
|
|
|
|
These two items mean that there are loops that cannot
|
|
be written in straightforward fashion using the Fortran @code{DO}.
|
|
|
|
For example, on a system with the canonical 32-bit two's-complement
|
|
implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
|
|
|
|
@smallexample
|
|
DO I = -2000000000, 2000000000
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Although the @var{start} and @var{end} values are well within
|
|
the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
|
|
The expected trip count is 40000000001, which is outside
|
|
the range of @code{INTEGER(KIND=1)} on many systems.
|
|
|
|
Instead, the above loop should be constructed this way:
|
|
|
|
@smallexample
|
|
I = -2000000000
|
|
DO
|
|
IF (I .GT. 2000000000) EXIT
|
|
@dots{}
|
|
I = I + 1
|
|
END DO
|
|
@end smallexample
|
|
|
|
@noindent
|
|
The simple @code{DO} construct and the @code{EXIT} statement
|
|
(used to leave the innermost loop)
|
|
are F90 features that @command{g77} supports.
|
|
|
|
Some Fortran compilers have buggy implementations of @code{DO},
|
|
in that they don't follow the standard.
|
|
They implement @code{DO} as a straightforward translation
|
|
to what, in C, would be a @code{for} statement.
|
|
Instead of creating a temporary variable to hold the trip count
|
|
as calculated at run time, these compilers
|
|
use the iteration variable @var{iter} to control
|
|
whether the loop continues at each iteration.
|
|
|
|
The bug in such an implementation shows up when the
|
|
trip count is within the range of the type of @var{iter},
|
|
but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
|
|
exceeds that range. For example:
|
|
|
|
@smallexample
|
|
DO I = 2147483600, 2147483647
|
|
@end smallexample
|
|
|
|
@noindent
|
|
A loop started by the above statement will work as implemented
|
|
by @command{g77}, but the use, by some compilers, of a
|
|
more C-like implementation akin to
|
|
|
|
@smallexample
|
|
for (i = 2147483600; i <= 2147483647; ++i)
|
|
@end smallexample
|
|
|
|
@noindent
|
|
produces a loop that does not terminate, because @samp{i}
|
|
can never be greater than 2147483647, since incrementing it
|
|
beyond that value overflows @samp{i}, setting it to -2147483648.
|
|
This is a large, negative number that still is less than 2147483647.
|
|
|
|
Another example of unexpected behavior of @code{DO} involves
|
|
using a nonintegral iteration variable @var{iter}, that is,
|
|
a @code{REAL} variable.
|
|
Consider the following program:
|
|
|
|
@smallexample
|
|
DATA BEGIN, END, STEP /.1, .31, .007/
|
|
DO 10 R = BEGIN, END, STEP
|
|
IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
|
|
PRINT *,R
|
|
10 CONTINUE
|
|
PRINT *,'LAST = ',R
|
|
IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
A C-like view of @code{DO} would hold that the two ``exclamatory''
|
|
@code{PRINT} statements are never executed.
|
|
However, this is the output of running the above program
|
|
as compiled by @command{g77} on a GNU/Linux ix86 system:
|
|
|
|
@smallexample
|
|
.100000001
|
|
.107000001
|
|
.114
|
|
.120999999
|
|
@dots{}
|
|
.289000005
|
|
.296000004
|
|
.303000003
|
|
LAST = .310000002
|
|
.310000002 .LE. .310000002!!
|
|
@end smallexample
|
|
|
|
Note that one of the two checks in the program turned up
|
|
an apparent violation of the programmer's expectation---yet,
|
|
the loop is correctly implemented by @command{g77}, in that
|
|
it has 30 iterations.
|
|
This trip count of 30 is correct when evaluated using
|
|
the floating-point representations for the @var{begin},
|
|
@var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
|
|
ix86 are used.
|
|
On other systems, an apparently more accurate trip count
|
|
of 31 might result, but, nevertheless, @command{g77} is
|
|
faithfully following the Fortran standard, and the result
|
|
is not what the author of the sample program above
|
|
apparently expected.
|
|
(Such other systems might, for different values in the @code{DATA}
|
|
statement, violate the other programmer's expectation,
|
|
for example.)
|
|
|
|
Due to this combination of imprecise representation
|
|
of floating-point values and the often-misunderstood
|
|
interpretation of @code{DO} by standard-conforming
|
|
compilers such as @command{g77}, use of @code{DO} loops
|
|
with @code{REAL} iteration
|
|
variables is not recommended.
|
|
Such use can be caught by specifying @option{-Wsurprising}.
|
|
@xref{Warning Options}, for more information on this
|
|
option.
|
|
|
|
@node Working Programs
|
|
@section Working Programs
|
|
|
|
Getting Fortran programs to work in the first place can be
|
|
quite a challenge---even when the programs already work on
|
|
other systems, or when using other compilers.
|
|
|
|
@command{g77} offers some facilities that might be useful for
|
|
tracking down bugs in such programs.
|
|
|
|
@menu
|
|
* Not My Type::
|
|
* Variables Assumed To Be Zero::
|
|
* Variables Assumed To Be Saved::
|
|
* Unwanted Variables::
|
|
* Unused Arguments::
|
|
* Surprising Interpretations of Code::
|
|
* Aliasing Assumed To Work::
|
|
* Output Assumed To Flush::
|
|
* Large File Unit Numbers::
|
|
* Floating-point precision::
|
|
* Inconsistent Calling Sequences::
|
|
@end menu
|
|
|
|
@node Not My Type
|
|
@subsection Not My Type
|
|
@cindex mistyped variables
|
|
@cindex variables, mistyped
|
|
@cindex mistyped functions
|
|
@cindex functions, mistyped
|
|
@cindex implicit typing
|
|
|
|
A fruitful source of bugs in Fortran source code is use, or
|
|
mis-use, of Fortran's implicit-typing feature, whereby the
|
|
type of a variable, array, or function is determined by the
|
|
first character of its name.
|
|
|
|
Simple cases of this include statements like @samp{LOGX=9.227},
|
|
without a statement such as @samp{REAL LOGX}.
|
|
In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
|
|
type, with the result of the assignment being that it is given
|
|
the value @samp{9}.
|
|
|
|
More involved cases include a function that is defined starting
|
|
with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
|
|
Any caller of this function that does not also declare @samp{IPS}
|
|
as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
|
|
is likely to assume it returns
|
|
@code{INTEGER}, or some other type, leading to invalid results
|
|
or even program crashes.
|
|
|
|
The @option{-Wimplicit} option might catch failures to
|
|
properly specify the types of
|
|
variables, arrays, and functions in the code.
|
|
|
|
However, in code that makes heavy use of Fortran's
|
|
implicit-typing facility, this option might produce so
|
|
many warnings about cases that are working, it would be
|
|
hard to find the one or two that represent bugs.
|
|
This is why so many experienced Fortran programmers strongly
|
|
recommend widespread use of the @code{IMPLICIT NONE} statement,
|
|
despite it not being standard FORTRAN 77, to completely turn
|
|
off implicit typing.
|
|
(@command{g77} supports @code{IMPLICIT NONE}, as do almost all
|
|
FORTRAN 77 compilers.)
|
|
|
|
Note that @option{-Wimplicit} catches only implicit typing of
|
|
@emph{names}.
|
|
It does not catch implicit typing of expressions such
|
|
as @samp{X**(2/3)}.
|
|
Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
|
|
is equivalent to @samp{X**0}, due to the way Fortran expressions
|
|
are given types and then evaluated.
|
|
(In this particular case, the programmer probably wanted
|
|
@samp{X**(2./3.)}.)
|
|
|
|
@node Variables Assumed To Be Zero
|
|
@subsection Variables Assumed To Be Zero
|
|
@cindex zero-initialized variables
|
|
@cindex variables, assumed to be zero
|
|
@cindex uninitialized variables
|
|
|
|
Many Fortran programs were developed on systems that provided
|
|
automatic initialization of all, or some, variables and arrays
|
|
to zero.
|
|
As a result, many of these programs depend, sometimes
|
|
inadvertently, on this behavior, though to do so violates
|
|
the Fortran standards.
|
|
|
|
You can ask @command{g77} for this behavior by specifying the
|
|
@option{-finit-local-zero} option when compiling Fortran code.
|
|
(You might want to specify @option{-fno-automatic} as well,
|
|
to avoid code-size inflation for non-optimized compilations.)
|
|
|
|
Note that a program that works better when compiled with the
|
|
@option{-finit-local-zero} option
|
|
is almost certainly depending on a particular system's,
|
|
or compiler's, tendency to initialize some variables to zero.
|
|
It might be worthwhile finding such cases and fixing them,
|
|
using techniques such as compiling with the @option{-O -Wuninitialized}
|
|
options using @command{g77}.
|
|
|
|
@node Variables Assumed To Be Saved
|
|
@subsection Variables Assumed To Be Saved
|
|
@cindex variables, retaining values across calls
|
|
@cindex saved variables
|
|
@cindex static variables
|
|
|
|
Many Fortran programs were developed on systems that
|
|
saved the values of all, or some, variables and arrays
|
|
across procedure calls.
|
|
As a result, many of these programs depend, sometimes
|
|
inadvertently, on being able to assign a value to a
|
|
variable, perform a @code{RETURN} to a calling procedure,
|
|
and, upon subsequent invocation, reference the previously
|
|
assigned variable to obtain the value.
|
|
|
|
They expect this despite not using the @code{SAVE} statement
|
|
to specify that the value in a variable is expected to survive
|
|
procedure returns and calls.
|
|
Depending on variables and arrays to retain values across
|
|
procedure calls without using @code{SAVE} to require it violates
|
|
the Fortran standards.
|
|
|
|
You can ask @command{g77} to assume @code{SAVE} is specified for all
|
|
relevant (local) variables and arrays by using the
|
|
@option{-fno-automatic} option.
|
|
|
|
Note that a program that works better when compiled with the
|
|
@option{-fno-automatic} option
|
|
is almost certainly depending on not having to use
|
|
the @code{SAVE} statement as required by the Fortran standard.
|
|
It might be worthwhile finding such cases and fixing them,
|
|
using techniques such as compiling with the @samp{-O -Wuninitialized}
|
|
options using @command{g77}.
|
|
|
|
@node Unwanted Variables
|
|
@subsection Unwanted Variables
|
|
|
|
The @option{-Wunused} option can find bugs involving
|
|
implicit typing, sometimes
|
|
more easily than using @option{-Wimplicit} in code that makes
|
|
heavy use of implicit typing.
|
|
An unused variable or array might indicate that the
|
|
spelling for its declaration is different from that of
|
|
its intended uses.
|
|
|
|
Other than cases involving typos, unused variables rarely
|
|
indicate actual bugs in a program.
|
|
However, investigating such cases thoroughly has, on occasion,
|
|
led to the discovery of code that had not been completely
|
|
written---where the programmer wrote declarations as needed
|
|
for the whole algorithm, wrote some or even most of the code
|
|
for that algorithm, then got distracted and forgot that the
|
|
job was not complete.
|
|
|
|
@node Unused Arguments
|
|
@subsection Unused Arguments
|
|
@cindex unused arguments
|
|
@cindex arguments, unused
|
|
|
|
As with unused variables, It is possible that unused arguments
|
|
to a procedure might indicate a bug.
|
|
Compile with @samp{-W -Wunused} option to catch cases of
|
|
unused arguments.
|
|
|
|
Note that @option{-W} also enables warnings regarding overflow
|
|
of floating-point constants under certain circumstances.
|
|
|
|
@node Surprising Interpretations of Code
|
|
@subsection Surprising Interpretations of Code
|
|
|
|
The @option{-Wsurprising} option can help find bugs involving
|
|
expression evaluation or in
|
|
the way @code{DO} loops with non-integral iteration variables
|
|
are handled.
|
|
Cases found by this option might indicate a difference of
|
|
interpretation between the author of the code involved, and
|
|
a standard-conforming compiler such as @command{g77}.
|
|
Such a difference might produce actual bugs.
|
|
|
|
In any case, changing the code to explicitly do what the
|
|
programmer might have expected it to do, so @command{g77} and
|
|
other compilers are more likely to follow the programmer's
|
|
expectations, might be worthwhile, especially if such changes
|
|
make the program work better.
|
|
|
|
@node Aliasing Assumed To Work
|
|
@subsection Aliasing Assumed To Work
|
|
@cindex -falias-check option
|
|
@cindex options, -falias-check
|
|
@cindex -fargument-alias option
|
|
@cindex options, -fargument-alias
|
|
@cindex -fargument-noalias option
|
|
@cindex options, -fargument-noalias
|
|
@cindex -fno-argument-noalias-global option
|
|
@cindex options, -fno-argument-noalias-global
|
|
@cindex aliasing
|
|
@cindex anti-aliasing
|
|
@cindex overlapping arguments
|
|
@cindex overlays
|
|
@cindex association, storage
|
|
@cindex storage association
|
|
@cindex scheduling of reads and writes
|
|
@cindex reads and writes, scheduling
|
|
|
|
The @option{-falias-check}, @option{-fargument-alias},
|
|
@option{-fargument-noalias},
|
|
and @option{-fno-argument-noalias-global} options,
|
|
introduced in version 0.5.20 and
|
|
@command{g77}'s version 2.7.2.2.f.2 of @command{gcc},
|
|
were withdrawn as of @command{g77} version 0.5.23
|
|
due to their not being supported by @command{gcc} version 2.8.
|
|
|
|
These options control the assumptions regarding aliasing
|
|
(overlapping) of writes and reads to main memory (core) made
|
|
by the @command{gcc} back end.
|
|
|
|
The information below still is useful, but applies to
|
|
only those versions of @command{g77} that support the
|
|
alias analysis implied by support for these options.
|
|
|
|
These options are effective only when compiling with @option{-O}
|
|
(specifying any level other than @option{-O0})
|
|
or with @option{-falias-check}.
|
|
|
|
The default for Fortran code is @option{-fargument-noalias-global}.
|
|
(The default for C code and code written in other C-based languages
|
|
is @option{-fargument-alias}.
|
|
These defaults apply regardless of whether you use @command{g77} or
|
|
@command{gcc} to compile your code.)
|
|
|
|
Note that, on some systems, compiling with @option{-fforce-addr} in
|
|
effect can produce more optimal code when the default aliasing
|
|
options are in effect (and when optimization is enabled).
|
|
|
|
If your program is not working when compiled with optimization,
|
|
it is possible it is violating the Fortran standards (77 and 90)
|
|
by relying on the ability to ``safely'' modify variables and
|
|
arrays that are aliased, via procedure calls, to other variables
|
|
and arrays, without using @code{EQUIVALENCE} to explicitly
|
|
set up this kind of aliasing.
|
|
|
|
(The FORTRAN 77 standard's prohibition of this sort of
|
|
overlap, generally referred to therein as ``storage
|
|
assocation'', appears in Sections 15.9.3.6.
|
|
This prohibition allows implementations, such as @command{g77},
|
|
to, for example, implement the passing of procedures and
|
|
even values in @code{COMMON} via copy operations into local,
|
|
perhaps more efficiently accessed temporaries at entry to a
|
|
procedure, and, where appropriate, via copy operations back
|
|
out to their original locations in memory at exit from that
|
|
procedure, without having to take into consideration the
|
|
order in which the local copies are updated by the code,
|
|
among other things.)
|
|
|
|
To test this hypothesis, try compiling your program with
|
|
the @option{-fargument-alias} option, which causes the
|
|
compiler to revert to assumptions essentially the same as
|
|
made by versions of @command{g77} prior to 0.5.20.
|
|
|
|
If the program works using this option, that strongly suggests
|
|
that the bug is in your program.
|
|
Finding and fixing the bug(s) should result in a program that
|
|
is more standard-conforming and that can be compiled by @command{g77}
|
|
in a way that results in a faster executable.
|
|
|
|
(You might want to try compiling with @option{-fargument-noalias},
|
|
a kind of half-way point, to see if the problem is limited to
|
|
aliasing between dummy arguments and @code{COMMON} variables---this
|
|
option assumes that such aliasing is not done, while still allowing
|
|
aliasing among dummy arguments.)
|
|
|
|
An example of aliasing that is invalid according to the standards
|
|
is shown in the following program, which might @emph{not} produce
|
|
the expected results when executed:
|
|
|
|
@smallexample
|
|
I = 1
|
|
CALL FOO(I, I)
|
|
PRINT *, I
|
|
END
|
|
|
|
SUBROUTINE FOO(J, K)
|
|
J = J + K
|
|
K = J * K
|
|
PRINT *, J, K
|
|
END
|
|
@end smallexample
|
|
|
|
The above program attempts to use the temporary aliasing of the
|
|
@samp{J} and @samp{K} arguments in @samp{FOO} to effect a
|
|
pathological behavior---the simultaneous changing of the values
|
|
of @emph{both} @samp{J} and @samp{K} when either one of them
|
|
is written.
|
|
|
|
The programmer likely expects the program to print these values:
|
|
|
|
@example
|
|
2 4
|
|
4
|
|
@end example
|
|
|
|
However, since the program is not standard-conforming, an
|
|
implementation's behavior when running it is undefined, because
|
|
subroutine @samp{FOO} modifies at least one of the arguments,
|
|
and they are aliased with each other.
|
|
(Even if one of the assignment statements was deleted, the
|
|
program would still violate these rules.
|
|
This kind of on-the-fly aliasing is permitted by the standard
|
|
only when none of the aliased items are defined, or written,
|
|
while the aliasing is in effect.)
|
|
|
|
As a practical example, an optimizing compiler might schedule
|
|
the @samp{J =} part of the second line of @samp{FOO} @emph{after}
|
|
the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
|
|
resulting in the following output:
|
|
|
|
@example
|
|
2 2
|
|
2
|
|
@end example
|
|
|
|
Essentially, compilers are promised (by the standard and, therefore,
|
|
by programmers who write code they claim to be standard-conforming)
|
|
that if they cannot detect aliasing via static analysis of a single
|
|
program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
|
|
such aliasing exists.
|
|
In such cases, compilers are free to assume that an assignment to
|
|
one variable will not change the value of another variable, allowing
|
|
it to avoid generating code to re-read the value of the other
|
|
variable, to re-schedule reads and writes, and so on, to produce
|
|
a faster executable.
|
|
|
|
The same promise holds true for arrays (as seen by the called
|
|
procedure)---an element of one dummy array cannot be aliased
|
|
with, or overlap, any element of another dummy array or be
|
|
in a @code{COMMON} area known to the procedure.
|
|
|
|
(These restrictions apply only when the procedure defines, or
|
|
writes to, one of the aliased variables or arrays.)
|
|
|
|
Unfortunately, there is no way to find @emph{all} possible cases of
|
|
violations of the prohibitions against aliasing in Fortran code.
|
|
Static analysis is certainly imperfect, as is run-time analysis,
|
|
since neither can catch all violations.
|
|
(Static analysis can catch all likely violations, and some that
|
|
might never actually happen, while run-time analysis can catch
|
|
only those violations that actually happen during a particular run.
|
|
Neither approach can cope with programs mixing Fortran code with
|
|
routines written in other languages, however.)
|
|
|
|
Currently, @command{g77} provides neither static nor run-time facilities
|
|
to detect any cases of this problem, although other products might.
|
|
Run-time facilities are more likely to be offered by future
|
|
versions of @command{g77}, though patches improving @command{g77} so that
|
|
it provides either form of detection are welcome.
|
|
|
|
@node Output Assumed To Flush
|
|
@subsection Output Assumed To Flush
|
|
@cindex ALWAYS_FLUSH
|
|
@cindex synchronous write errors
|
|
@cindex disk full
|
|
@cindex flushing output
|
|
@cindex fflush()
|
|
@cindex I/O, flushing
|
|
@cindex output, flushing
|
|
@cindex writes, flushing
|
|
@cindex NFS
|
|
@cindex network file system
|
|
|
|
For several versions prior to 0.5.20, @command{g77} configured its
|
|
version of the @code{libf2c} run-time library so that one of
|
|
its configuration macros, @code{ALWAYS_FLUSH}, was defined.
|
|
|
|
This was done as a result of a belief that many programs expected
|
|
output to be flushed to the operating system (under UNIX, via
|
|
the @code{fflush()} library call) with the result that errors,
|
|
such as disk full, would be immediately flagged via the
|
|
relevant @code{ERR=} and @code{IOSTAT=} mechanism.
|
|
|
|
Because of the adverse effects this approach had on the performance
|
|
of many programs, @command{g77} no longer configures @code{libf2c}
|
|
(now named @code{libg2c} in its @command{g77} incarnation)
|
|
to always flush output.
|
|
|
|
If your program depends on this behavior, either insert the
|
|
appropriate @samp{CALL FLUSH} statements, or modify the sources
|
|
to the @code{libg2c}, rebuild and reinstall @command{g77}, and
|
|
relink your programs with the modified library.
|
|
|
|
(Ideally, @code{libg2c} would offer the choice at run-time, so
|
|
that a compile-time option to @command{g77} or @command{f2c} could
|
|
result in generating the appropriate calls to flushing or
|
|
non-flushing library routines.)
|
|
|
|
Some Fortran programs require output
|
|
(writes) to be flushed to the operating system (under UNIX,
|
|
via the @code{fflush()} library call) so that errors,
|
|
such as disk full, are immediately flagged via the relevant
|
|
@code{ERR=} and @code{IOSTAT=} mechanism, instead of such
|
|
errors being flagged later as subsequent writes occur, forcing
|
|
the previously written data to disk, or when the file is
|
|
closed.
|
|
|
|
Essentially, the difference can be viewed as synchronous error
|
|
reporting (immediate flagging of errors during writes) versus
|
|
asynchronous, or, more precisely, buffered error reporting
|
|
(detection of errors might be delayed).
|
|
|
|
@code{libg2c} supports flagging write errors immediately when
|
|
it is built with the @code{ALWAYS_FLUSH} macro defined.
|
|
This results in a @code{libg2c} that runs slower, sometimes
|
|
quite a bit slower, under certain circumstances---for example,
|
|
accessing files via the networked file system NFS---but the
|
|
effect can be more reliable, robust file I/O.
|
|
|
|
If you know that Fortran programs requiring this level of precision
|
|
of error reporting are to be compiled using the
|
|
version of @command{g77} you are building, you might wish to
|
|
modify the @command{g77} source tree so that the version of
|
|
@code{libg2c} is built with the @code{ALWAYS_FLUSH} macro
|
|
defined, enabling this behavior.
|
|
|
|
To do this, find this line in @file{@value{path-libf2c}/f2c.h} in
|
|
your @command{g77} source tree:
|
|
|
|
@example
|
|
/* #define ALWAYS_FLUSH */
|
|
@end example
|
|
|
|
Remove the leading @samp{/*@w{ }},
|
|
so the line begins with @samp{#define},
|
|
and the trailing @samp{@w{ }*/}.
|
|
|
|
Then build or rebuild @command{g77} as appropriate.
|
|
|
|
@node Large File Unit Numbers
|
|
@subsection Large File Unit Numbers
|
|
@cindex MXUNIT
|
|
@cindex unit numbers
|
|
@cindex maximum unit number
|
|
@cindex illegal unit number
|
|
@cindex increasing maximum unit number
|
|
|
|
If your program crashes at run time with a message including
|
|
the text @samp{illegal unit number}, that probably is
|
|
a message from the run-time library, @code{libg2c}.
|
|
|
|
The message means that your program has attempted to use a
|
|
file unit number that is out of the range accepted by
|
|
@code{libg2c}.
|
|
Normally, this range is 0 through 99, and the high end
|
|
of the range is controlled by a @code{libg2c} source-file
|
|
macro named @code{MXUNIT}.
|
|
|
|
If you can easily change your program to use unit numbers
|
|
in the range 0 through 99, you should do so.
|
|
|
|
As distributed, whether as part of @command{f2c} or @command{g77},
|
|
@code{libf2c} accepts file unit numbers only in the range
|
|
0 through 99.
|
|
For example, a statement such as @samp{WRITE (UNIT=100)} causes
|
|
a run-time crash in @code{libf2c}, because the unit number,
|
|
100, is out of range.
|
|
|
|
If you know that Fortran programs at your installation require
|
|
the use of unit numbers higher than 99, you can change the
|
|
value of the @code{MXUNIT} macro, which represents the maximum unit
|
|
number, to an appropriately higher value.
|
|
|
|
To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your
|
|
@command{g77} source tree, changing the following line:
|
|
|
|
@example
|
|
#define MXUNIT 100
|
|
@end example
|
|
|
|
Change the line so that the value of @code{MXUNIT} is defined to be
|
|
at least one @emph{greater} than the maximum unit number used by
|
|
the Fortran programs on your system.
|
|
|
|
(For example, a program that does @samp{WRITE (UNIT=255)} would require
|
|
@code{MXUNIT} set to at least 256 to avoid crashing.)
|
|
|
|
Then build or rebuild @command{g77} as appropriate.
|
|
|
|
@emph{Note:} Changing this macro has @emph{no} effect on other limits
|
|
your system might place on the number of files open at the same time.
|
|
That is, the macro might allow a program to do @samp{WRITE (UNIT=100)},
|
|
but the library and operating system underlying @code{libf2c} might
|
|
disallow it if many other files have already been opened (via @code{OPEN} or
|
|
implicitly via @code{READ}, @code{WRITE}, and so on).
|
|
Information on how to increase these other limits should be found
|
|
in your system's documentation.
|
|
|
|
@node Floating-point precision
|
|
@subsection Floating-point precision
|
|
|
|
@cindex IEEE 754 conformance
|
|
@cindex conformance, IEEE 754
|
|
@cindex floating-point, precision
|
|
@cindex ix86 floating-point
|
|
@cindex x86 floating-point
|
|
If your program depends on exact IEEE 754 floating-point handling it may
|
|
help on some systems---specifically x86 or m68k hardware---to use
|
|
the @option{-ffloat-store} option or to reset the precision flag on the
|
|
floating-point unit.
|
|
@xref{Optimize Options}.
|
|
|
|
However, it might be better simply to put the FPU into double precision
|
|
mode and not take the performance hit of @option{-ffloat-store}. On x86
|
|
and m68k GNU systems you can do this with a technique similar to that
|
|
for turning on floating-point exceptions
|
|
(@pxref{Floating-point Exception Handling}).
|
|
The control word could be set to double precision by some code like this
|
|
one:
|
|
@smallexample
|
|
#include <fpu_control.h>
|
|
@{
|
|
fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
|
|
_FPU_SETCW(cw);
|
|
@}
|
|
@end smallexample
|
|
(It is not clear whether this has any effect on the operation of the GNU
|
|
maths library, but we have no evidence of it causing trouble.)
|
|
|
|
Some targets (such as the Alpha) may need special options for full IEEE
|
|
conformance.
|
|
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using
|
|
the GNU Compiler Collection (GCC)}.
|
|
|
|
@node Inconsistent Calling Sequences
|
|
@subsection Inconsistent Calling Sequences
|
|
|
|
@pindex ftnchek
|
|
@cindex floating-point, errors
|
|
@cindex ix86 FPU stack
|
|
@cindex x86 FPU stack
|
|
Code containing inconsistent calling sequences in the same file is
|
|
normally rejected---see @ref{GLOBALS}.
|
|
(Use, say, @command{ftnchek} to ensure
|
|
consistency across source files.
|
|
@xref{f2c Skeletons and Prototypes,,
|
|
Generating Skeletons and Prototypes with @command{f2c}}.)
|
|
|
|
Mysterious errors, which may appear to be code generation problems, can
|
|
appear specifically on the x86 architecture with some such
|
|
inconsistencies. On x86 hardware, floating-point return values of
|
|
functions are placed on the floating-point unit's register stack, not
|
|
the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
|
|
@code{FUNCTION} as some other sort of procedure, or vice versa,
|
|
scrambles the floating-point stack. This may break unrelated code
|
|
executed later. Similarly if, say, external C routines are written
|
|
incorrectly.
|
|
|
|
@node Overly Convenient Options
|
|
@section Overly Convenient Command-line Options
|
|
@cindex overly convenient options
|
|
@cindex options, overly convenient
|
|
|
|
These options should be used only as a quick-and-dirty way to determine
|
|
how well your program will run under different compilation models
|
|
without having to change the source.
|
|
Some are more problematic
|
|
than others, depending on how portable and maintainable you want the
|
|
program to be (and, of course, whether you are allowed to change it
|
|
at all is crucial).
|
|
|
|
You should not continue to use these command-line options to compile
|
|
a given program, but rather should make changes to the source code:
|
|
|
|
@table @code
|
|
@cindex -finit-local-zero option
|
|
@cindex options, -finit-local-zero
|
|
@item -finit-local-zero
|
|
(This option specifies that any uninitialized local variables
|
|
and arrays have default initialization to binary zeros.)
|
|
|
|
Many other compilers do this automatically, which means lots of
|
|
Fortran code developed with those compilers depends on it.
|
|
|
|
It is safer (and probably
|
|
would produce a faster program) to find the variables and arrays that
|
|
need such initialization and provide it explicitly via @code{DATA}, so that
|
|
@option{-finit-local-zero} is not needed.
|
|
|
|
Consider using @option{-Wuninitialized} (which requires @option{-O}) to
|
|
find likely candidates, but
|
|
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
|
|
or this technique won't work.
|
|
|
|
@cindex -fno-automatic option
|
|
@cindex options, -fno-automatic
|
|
@item -fno-automatic
|
|
(This option specifies that all local variables and arrays
|
|
are to be treated as if they were named in @code{SAVE} statements.)
|
|
|
|
Many other compilers do this automatically, which means lots of
|
|
Fortran code developed with those compilers depends on it.
|
|
|
|
The effect of this is that all non-automatic variables and arrays
|
|
are made static, that is, not placed on the stack or in heap storage.
|
|
This might cause a buggy program to appear to work better.
|
|
If so, rather than relying on this command-line option (and hoping all
|
|
compilers provide the equivalent one), add @code{SAVE}
|
|
statements to some or all program unit sources, as appropriate.
|
|
Consider using @option{-Wuninitialized} (which requires @option{-O})
|
|
to find likely candidates, but
|
|
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
|
|
or this technique won't work.
|
|
|
|
The default is @option{-fautomatic}, which tells @command{g77} to try
|
|
and put variables and arrays on the stack (or in fast registers)
|
|
where possible and reasonable.
|
|
This tends to make programs faster.
|
|
|
|
@cindex automatic arrays
|
|
@cindex arrays, automatic
|
|
@emph{Note:} Automatic variables and arrays are not affected
|
|
by this option.
|
|
These are variables and arrays that are @emph{necessarily} automatic,
|
|
either due to explicit statements, or due to the way they are
|
|
declared.
|
|
Examples include local variables and arrays not given the
|
|
@code{SAVE} attribute in procedures declared @code{RECURSIVE},
|
|
and local arrays declared with non-constant bounds (automatic
|
|
arrays).
|
|
Currently, @command{g77} supports only automatic arrays, not
|
|
@code{RECURSIVE} procedures or other means of explicitly
|
|
specifying that variables or arrays are automatic.
|
|
|
|
@cindex -f@var{group}-intrinsics-hide option
|
|
@cindex options, -f@var{group}-intrinsics-hide
|
|
@item -f@var{group}-intrinsics-hide
|
|
Change the source code to use @code{EXTERNAL} for any external procedure
|
|
that might be the name of an intrinsic.
|
|
It is easy to find these using @option{-f@var{group}-intrinsics-disable}.
|
|
@end table
|
|
|
|
@node Faster Programs
|
|
@section Faster Programs
|
|
@cindex speed, of programs
|
|
@cindex programs, speeding up
|
|
|
|
Aside from the usual @command{gcc} options, such as @option{-O},
|
|
@option{-ffast-math}, and so on, consider trying some of the
|
|
following approaches to speed up your program (once you get
|
|
it working).
|
|
|
|
@menu
|
|
* Aligned Data::
|
|
* Prefer Automatic Uninitialized Variables::
|
|
* Avoid f2c Compatibility::
|
|
* Use Submodel Options::
|
|
@end menu
|
|
|
|
@node Aligned Data
|
|
@subsection Aligned Data
|
|
@cindex alignment
|
|
@cindex data, aligned
|
|
@cindex stack, aligned
|
|
@cindex aligned data
|
|
@cindex aligned stack
|
|
@cindex Pentium optimizations
|
|
@cindex optimization, for Pentium
|
|
|
|
On some systems, such as those with Pentium Pro CPUs, programs
|
|
that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
|
|
might run much slower
|
|
than possible due to the compiler not aligning these 64-bit
|
|
values to 64-bit boundaries in memory.
|
|
(The effect also is present, though
|
|
to a lesser extent, on the 586 (Pentium) architecture.)
|
|
|
|
The Intel x86 architecture generally ensures that these programs will
|
|
work on all its implementations,
|
|
but particular implementations (such as Pentium Pro)
|
|
perform better with more strict alignment.
|
|
(Such behavior isn't unique to the Intel x86 architecture.)
|
|
Other architectures might @emph{demand} 64-bit alignment
|
|
of 64-bit data.
|
|
|
|
There are a variety of approaches to use to address this problem:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@cindex @code{COMMON} layout
|
|
@cindex layout of @code{COMMON} blocks
|
|
Order your @code{COMMON} and @code{EQUIVALENCE} areas such
|
|
that the variables and arrays with the widest alignment
|
|
guidelines come first.
|
|
|
|
For example, on most systems, this would mean placing
|
|
@code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
|
|
@code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
|
|
@code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
|
|
@code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
|
|
and @code{INTEGER(KIND=3)} entities.
|
|
|
|
The reason to use such placement is it makes it more likely
|
|
that your data will be aligned properly, without requiring
|
|
you to do detailed analysis of each aggregate (@code{COMMON}
|
|
and @code{EQUIVALENCE}) area.
|
|
|
|
Specifically, on systems where the above guidelines are
|
|
appropriate, placing @code{CHARACTER} entities before
|
|
@code{REAL(KIND=2)} entities can work just as well,
|
|
but only if the number of bytes occupied by the @code{CHARACTER}
|
|
entities is divisible by the recommended alignment for
|
|
@code{REAL(KIND=2)}.
|
|
|
|
By ordering the placement of entities in aggregate
|
|
areas according to the simple guidelines above, you
|
|
avoid having to carefully count the number of bytes
|
|
occupied by each entity to determine whether the
|
|
actual alignment of each subsequent entity meets the
|
|
alignment guidelines for the type of that entity.
|
|
|
|
If you don't ensure correct alignment of @code{COMMON} elements, the
|
|
compiler may be forced by some systems to violate the Fortran semantics by
|
|
adding padding to get @code{DOUBLE PRECISION} data properly aligned.
|
|
If the unfortunate practice is employed of overlaying different types of
|
|
data in the @code{COMMON} block, the different variants
|
|
of this block may become misaligned with respect to each other.
|
|
Even if your platform doesn't require strict alignment,
|
|
@code{COMMON} should be laid out as above for portability.
|
|
(Unfortunately the FORTRAN 77 standard didn't anticipate this
|
|
possible requirement, which is compiler-independent on a given platform.)
|
|
|
|
@item
|
|
@cindex -malign-double option
|
|
@cindex options, -malign-double
|
|
Use the (x86-specific) @option{-malign-double} option when compiling
|
|
programs for the Pentium and Pentium Pro architectures (called 586
|
|
and 686 in the @command{gcc} configuration subsystem).
|
|
The warning about this in the @command{gcc} manual isn't
|
|
generally relevant to Fortran,
|
|
but using it will force @code{COMMON} to be padded if necessary to align
|
|
@code{DOUBLE PRECISION} data.
|
|
|
|
When @code{DOUBLE PRECISION} data is forcibly aligned
|
|
in @code{COMMON} by @command{g77} due to specifying @option{-malign-double},
|
|
@command{g77} issues a warning about the need to
|
|
insert padding.
|
|
|
|
In this case, each and every program unit that uses
|
|
the same @code{COMMON} area
|
|
must specify the same layout of variables and their types
|
|
for that area
|
|
and be compiled with @option{-malign-double} as well.
|
|
@command{g77} will issue warnings in each case,
|
|
but as long as every program unit using that area
|
|
is compiled with the same warnings,
|
|
the resulting object files should work when linked together
|
|
unless the program makes additional assumptions about
|
|
@code{COMMON} area layouts that are outside the scope
|
|
of the FORTRAN 77 standard,
|
|
or uses @code{EQUIVALENCE} or different layouts
|
|
in ways that assume no padding is ever inserted by the compiler.
|
|
|
|
@item
|
|
Ensure that @file{crt0.o} or @file{crt1.o}
|
|
on your system guarantees a 64-bit
|
|
aligned stack for @code{main()}.
|
|
The recent one from GNU (@code{glibc2}) will do this on x86 systems,
|
|
but we don't know of any other x86 setups where it will be right.
|
|
Read your system's documentation to determine if
|
|
it is appropriate to upgrade to a more recent version
|
|
to obtain the optimal alignment.
|
|
@end itemize
|
|
|
|
Progress is being made on making this work
|
|
``out of the box'' on future versions of @command{g77},
|
|
@command{gcc}, and some of the relevant operating systems
|
|
(such as GNU/Linux).
|
|
|
|
@cindex alignment testing
|
|
@cindex testing alignment
|
|
A package that tests the degree to which a Fortran compiler
|
|
(such as @command{g77})
|
|
aligns 64-bit floating-point variables and arrays
|
|
is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
|
|
|
|
@node Prefer Automatic Uninitialized Variables
|
|
@subsection Prefer Automatic Uninitialized Variables
|
|
|
|
If you're using @option{-fno-automatic} already, you probably
|
|
should change your code to allow compilation with @option{-fautomatic}
|
|
(the default), to allow the program to run faster.
|
|
|
|
Similarly, you should be able to use @option{-fno-init-local-zero}
|
|
(the default) instead of @option{-finit-local-zero}.
|
|
This is because it is rare that every variable affected by these
|
|
options in a given program actually needs to
|
|
be so affected.
|
|
|
|
For example, @option{-fno-automatic}, which effectively @code{SAVE}s
|
|
every local non-automatic variable and array, affects even things like
|
|
@code{DO} iteration
|
|
variables, which rarely need to be @code{SAVE}d, and this often reduces
|
|
run-time performances.
|
|
Similarly, @option{-fno-init-local-zero} forces such
|
|
variables to be initialized to zero---when @code{SAVE}d (such as when
|
|
@option{-fno-automatic}), this by itself generally affects only
|
|
startup time for a program, but when not @code{SAVE}d,
|
|
it can slow down the procedure every time it is called.
|
|
|
|
@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
|
|
for information on the @option{-fno-automatic} and
|
|
@option{-finit-local-zero} options and how to convert
|
|
their use into selective changes in your own code.
|
|
|
|
@node Avoid f2c Compatibility
|
|
@subsection Avoid f2c Compatibility
|
|
@cindex -fno-f2c option
|
|
@cindex options, -fno-f2c
|
|
@cindex @command{f2c} compatibility
|
|
@cindex compatibility, @command{f2c}
|
|
|
|
If you aren't linking with any code compiled using
|
|
@command{f2c}, try using the @option{-fno-f2c} option when
|
|
compiling @emph{all} the code in your program.
|
|
(Note that @code{libf2c} is @emph{not} an example of code
|
|
that is compiled using @command{f2c}---it is compiled by a C
|
|
compiler, typically @command{gcc}.)
|
|
|
|
@node Use Submodel Options
|
|
@subsection Use Submodel Options
|
|
@cindex submodels
|
|
|
|
Using an appropriate @option{-m} option to generate specific code for your
|
|
CPU may be worthwhile, though it may mean the executable won't run on
|
|
other versions of the CPU that don't support the same instruction set.
|
|
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using the
|
|
GNU Compiler Collection (GCC)}. For instance on an x86 system the
|
|
compiler might have
|
|
been built---as shown by @samp{g77 -v}---for the target
|
|
@samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
|
|
generate code best optimized for a Pentium you could use the option
|
|
@option{-march=pentium}.
|
|
|
|
For recent CPUs that don't have explicit support in the released version
|
|
of @command{gcc}, it @emph{might} still be possible to get improvements
|
|
with certain @option{-m} options.
|
|
|
|
@option{-fomit-frame-pointer} can help performance on x86 systems and
|
|
others. It will, however, inhibit debugging on the systems on which it
|
|
is not turned on anyway by @option{-O}.
|
|
|
|
@node Trouble
|
|
@chapter Known Causes of Trouble with GNU Fortran
|
|
@cindex bugs, known
|
|
@cindex installation trouble
|
|
@cindex known causes of trouble
|
|
|
|
This section describes known problems that affect users of GNU Fortran.
|
|
Most of these are not GNU Fortran bugs per se---if they were, we would
|
|
fix them.
|
|
But the result for a user might be like the result of a bug.
|
|
|
|
Some of these problems are due to bugs in other software, some are
|
|
missing features that are too much work to add, and some are places
|
|
where people's opinions differ as to what is best.
|
|
|
|
To find out about major bugs discovered in the current release and
|
|
possible workarounds for them, see
|
|
@uref{ftp://alpha.gnu.org/g77.plan}.
|
|
|
|
(Note that some of this portion of the manual is lifted
|
|
directly from the @command{gcc} manual, with minor modifications
|
|
to tailor it to users of @command{g77}.
|
|
Anytime a bug seems to have more to do with the @command{gcc}
|
|
portion of @command{g77}, see
|
|
@ref{Trouble,,Known Causes of Trouble with GCC,
|
|
gcc,Using the GNU Compiler Collection (GCC)}.)
|
|
|
|
@menu
|
|
* But-bugs:: Bugs really in other programs or elsewhere.
|
|
* Known Bugs:: Bugs known to be in this version of @command{g77}.
|
|
* Missing Features:: Features we already know we want to add later.
|
|
* Disappointments:: Regrettable things we can't change.
|
|
* Non-bugs:: Things we think are right, but some others disagree.
|
|
* Warnings and Errors:: Which problems in your code get warnings,
|
|
and which get errors.
|
|
@end menu
|
|
|
|
@node But-bugs
|
|
@section Bugs Not In GNU Fortran
|
|
@cindex but-bugs
|
|
|
|
These are bugs to which the maintainers often have to reply,
|
|
``but that isn't a bug in @command{g77}@dots{}''.
|
|
Some of these already are fixed in new versions of other
|
|
software; some still need to be fixed; some are problems
|
|
with how @command{g77} is installed or is being used;
|
|
some are the result of bad hardware that causes software
|
|
to misbehave in sometimes bizarre ways;
|
|
some just cannot be addressed at this time until more
|
|
is known about the problem.
|
|
|
|
Please don't re-report these bugs to the @command{g77} maintainers---if
|
|
you must remind someone how important it is to you that the problem
|
|
be fixed, talk to the people responsible for the other products
|
|
identified below, but preferably only after you've tried the
|
|
latest versions of those products.
|
|
The @command{g77} maintainers have their hands full working on
|
|
just fixing and improving @command{g77}, without serving as a
|
|
clearinghouse for all bugs that happen to affect @command{g77}
|
|
users.
|
|
|
|
@xref{Collected Fortran Wisdom}, for information on behavior
|
|
of Fortran programs, and the programs that compile them, that
|
|
might be @emph{thought} to indicate bugs.
|
|
|
|
@menu
|
|
* Signal 11 and Friends:: Strange behavior by any software.
|
|
* Cannot Link Fortran Programs:: Unresolved references.
|
|
* Large Common Blocks:: Problems on older GNU/Linux systems.
|
|
* Debugger Problems:: When the debugger crashes.
|
|
* NeXTStep Problems:: Misbehaving executables.
|
|
* Stack Overflow:: More misbehaving executables.
|
|
* Nothing Happens:: Less behaving executables.
|
|
* Strange Behavior at Run Time:: Executables misbehaving due to
|
|
bugs in your program.
|
|
* Floating-point Errors:: The results look wrong, but@dots{}.
|
|
@end menu
|
|
|
|
@node Signal 11 and Friends
|
|
@subsection Signal 11 and Friends
|
|
@cindex signal 11
|
|
@cindex hardware errors
|
|
|
|
A whole variety of strange behaviors can occur when the
|
|
software, or the way you are using the software,
|
|
stresses the hardware in a way that triggers hardware bugs.
|
|
This might seem hard to believe, but it happens frequently
|
|
enough that there exist documents explaining in detail
|
|
what the various causes of the problems are, what
|
|
typical symptoms look like, and so on.
|
|
|
|
Generally these problems are referred to in this document
|
|
as ``signal 11'' crashes, because the Linux kernel, running
|
|
on the most popular hardware (the Intel x86 line), often
|
|
stresses the hardware more than other popular operating
|
|
systems.
|
|
When hardware problems do occur under GNU/Linux on x86
|
|
systems, these often manifest themselves as ``signal 11''
|
|
problems, as illustrated by the following diagnostic:
|
|
|
|
@smallexample
|
|
sh# @kbd{g77 myprog.f}
|
|
gcc: Internal compiler error: program f771 got fatal signal 11
|
|
sh#
|
|
@end smallexample
|
|
|
|
It is @emph{very} important to remember that the above
|
|
message is @emph{not} the only one that indicates a
|
|
hardware problem, nor does it always indicate a hardware
|
|
problem.
|
|
|
|
In particular, on systems other than those running the Linux
|
|
kernel, the message might appear somewhat or very different,
|
|
as it will if the error manifests itself while running a
|
|
program other than the @command{g77} compiler.
|
|
For example,
|
|
it will appear somewhat different when running your program,
|
|
when running Emacs, and so on.
|
|
|
|
How to cope with such problems is well beyond the scope
|
|
of this manual.
|
|
|
|
However, users of Linux-based systems (such as GNU/Linux)
|
|
should review @uref{http://www.bitwizard.nl/sig11/}, a source
|
|
of detailed information on diagnosing hardware problems,
|
|
by recognizing their common symptoms.
|
|
|
|
Users of other operating systems and hardware might
|
|
find this reference useful as well.
|
|
If you know of similar material for another hardware/software
|
|
combination, please let us know so we can consider including
|
|
a reference to it in future versions of this manual.
|
|
|
|
@node Cannot Link Fortran Programs
|
|
@subsection Cannot Link Fortran Programs
|
|
@cindex unresolved reference (various)
|
|
@cindex linking error for user code
|
|
@cindex code, user
|
|
@cindex @command{ld}, error linking user code
|
|
@cindex @command{ld}, can't find strange names
|
|
On some systems, perhaps just those with out-of-date (shared?)
|
|
libraries, unresolved-reference errors happen when linking @command{g77}-compiled
|
|
programs (which should be done using @command{g77}).
|
|
|
|
If this happens to you, try appending @option{-lc} to the command you
|
|
use to link the program, e.g. @samp{g77 foo.f -lc}.
|
|
@command{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
|
|
but it cannot also specify @option{-lc} because not all systems have a
|
|
file named @file{libc.a}.
|
|
|
|
It is unclear at this point whether there are legitimately installed
|
|
systems where @samp{-lg2c -lm} is insufficient to resolve code produced
|
|
by @command{g77}.
|
|
|
|
@cindex undefined reference (_main)
|
|
@cindex linking error, user code
|
|
@cindex @command{ld}, error linking user code
|
|
@cindex code, user
|
|
@cindex @command{ld}, can't find @samp{_main}
|
|
If your program doesn't link due to unresolved references to names
|
|
like @samp{_main}, make sure you're using the @command{g77} command to do the
|
|
link, since this command ensures that the necessary libraries are
|
|
loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc}
|
|
command to do the actual link.
|
|
(Use the @option{-v} option to discover
|
|
more about what actually happens when you use the @command{g77} and @command{gcc}
|
|
commands.)
|
|
|
|
Also, try specifying @option{-lc} as the last item on the @command{g77}
|
|
command line, in case that helps.
|
|
|
|
@node Large Common Blocks
|
|
@subsection Large Common Blocks
|
|
@cindex common blocks, large
|
|
@cindex large common blocks
|
|
@cindex linking, errors
|
|
@cindex @command{ld}, errors
|
|
@cindex errors, linker
|
|
On some older GNU/Linux systems, programs with common blocks larger
|
|
than 16MB cannot be linked without some kind of error
|
|
message being produced.
|
|
|
|
This is a bug in older versions of @command{ld}, fixed in
|
|
more recent versions of @code{binutils}, such as version 2.6.
|
|
|
|
@node Debugger Problems
|
|
@subsection Debugger Problems
|
|
@cindex @command{gdb}, support
|
|
@cindex support, @command{gdb}
|
|
There are some known problems when using @command{gdb} on code
|
|
compiled by @command{g77}.
|
|
Inadequate investigation as of the release of 0.5.16 results in not
|
|
knowing which products are the culprit, but @file{gdb-4.14} definitely
|
|
crashes when, for example, an attempt is made to print the contents
|
|
of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
|
|
machines, plus some others.
|
|
Attempts to access assumed-size arrays are
|
|
also known to crash recent versions of @command{gdb}.
|
|
(@command{gdb}'s Fortran support was done for a different compiler
|
|
and isn't properly compatible with @command{g77}.)
|
|
|
|
@node NeXTStep Problems
|
|
@subsection NeXTStep Problems
|
|
@cindex NeXTStep problems
|
|
@cindex bus error
|
|
@cindex segmentation violation
|
|
Developers of Fortran code on NeXTStep (all architectures) have to
|
|
watch out for the following problem when writing programs with
|
|
large, statically allocated (i.e. non-stack based) data structures
|
|
(common blocks, saved arrays).
|
|
|
|
Due to the way the native loader (@file{/bin/ld}) lays out
|
|
data structures in virtual memory, it is very easy to create an
|
|
executable wherein the @samp{__DATA} segment overlaps (has addresses in
|
|
common) with the @samp{UNIX STACK} segment.
|
|
|
|
This leads to all sorts of trouble, from the executable simply not
|
|
executing, to bus errors.
|
|
The NeXTStep command line tool @command{ebadexec} points to
|
|
the problem as follows:
|
|
|
|
@smallexample
|
|
% @kbd{/bin/ebadexec a.out}
|
|
/bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
|
|
rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
|
|
STACK segment (truncated address = 0x400000 rounded size =
|
|
0x3c00000) of executable file: a.out
|
|
@end smallexample
|
|
|
|
(In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
|
|
stack segment.)
|
|
|
|
This can be cured by assigning the @samp{__DATA} segment
|
|
(virtual) addresses beyond the stack segment.
|
|
A conservative
|
|
estimate for this is from address 6000000 (hexadecimal) onwards---this
|
|
has always worked for me [Toon Moene]:
|
|
|
|
@smallexample
|
|
% @kbd{g77 -segaddr __DATA 6000000 test.f}
|
|
% @kbd{ebadexec a.out}
|
|
ebadexec: file: a.out appears to be executable
|
|
%
|
|
@end smallexample
|
|
|
|
Browsing through @file{@value{path-g77}/Makefile.in},
|
|
you will find that the @code{f771} program itself also has to be
|
|
linked with these flags---it has large statically allocated
|
|
data structures.
|
|
(Version 0.5.18 reduces this somewhat, but probably
|
|
not enough.)
|
|
|
|
(The above item was contributed by Toon Moene
|
|
(@email{toon@@moene.indiv.nluug.nl}).)
|
|
|
|
@node Stack Overflow
|
|
@subsection Stack Overflow
|
|
@cindex stack, overflow
|
|
@cindex segmentation violation
|
|
@command{g77} code might fail at runtime (probably with a ``segmentation
|
|
violation'') due to overflowing the stack.
|
|
This happens most often on systems with an environment
|
|
that provides substantially more heap space (for use
|
|
when arbitrarily allocating and freeing memory) than stack
|
|
space.
|
|
|
|
Often this can be cured by
|
|
increasing or removing your shell's limit on stack usage, typically
|
|
using @kbd{limit stacksize} (in @command{csh} and derivatives) or
|
|
@kbd{ulimit -s} (in @command{sh} and derivatives).
|
|
|
|
Increasing the allowed stack size might, however, require
|
|
changing some operating system or system configuration parameters.
|
|
|
|
You might be able to work around the problem by compiling with the
|
|
@option{-fno-automatic} option to reduce stack usage, probably at the
|
|
expense of speed.
|
|
|
|
@command{g77}, on most machines, puts many variables and arrays on the stack
|
|
where possible, and can be configured (by changing
|
|
@code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force
|
|
smaller-sized entities into static storage (saving
|
|
on stack space) or permit larger-sized entities to be put on the
|
|
stack (which can improve run-time performance, as it presents
|
|
more opportunities for the GBE to optimize the generated code).
|
|
|
|
@emph{Note:} Putting more variables and arrays on the stack
|
|
might cause problems due to system-dependent limits on stack size.
|
|
Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no
|
|
effect on automatic variables and arrays.
|
|
@xref{But-bugs}, for more information.
|
|
@emph{Note:} While @code{libg2c} places a limit on the range
|
|
of Fortran file-unit numbers, the underlying library and operating
|
|
system might impose different kinds of limits.
|
|
For example, some systems limit the number of files simultaneously
|
|
open by a running program.
|
|
Information on how to increase these limits should be found
|
|
in your system's documentation.
|
|
|
|
@cindex automatic arrays
|
|
@cindex arrays, automatic
|
|
However, if your program uses large automatic arrays
|
|
(for example, has declarations like @samp{REAL A(N)} where
|
|
@samp{A} is a local array and @samp{N} is a dummy or
|
|
@code{COMMON} variable that can have a large value),
|
|
neither use of @option{-fno-automatic},
|
|
nor changing the cut-off point for @command{g77} for using the stack,
|
|
will solve the problem by changing the placement of these
|
|
large arrays, as they are @emph{necessarily} automatic.
|
|
|
|
@command{g77} currently provides no means to specify that
|
|
automatic arrays are to be allocated on the heap instead
|
|
of the stack.
|
|
So, other than increasing the stack size, your best bet is to
|
|
change your source code to avoid large automatic arrays.
|
|
Methods for doing this currently are outside the scope of
|
|
this document.
|
|
|
|
(@emph{Note:} If your system puts stack and heap space in the
|
|
same memory area, such that they are effectively combined, then
|
|
a stack overflow probably indicates a program that is either
|
|
simply too large for the system, or buggy.)
|
|
|
|
@node Nothing Happens
|
|
@subsection Nothing Happens
|
|
@cindex nothing happens
|
|
@cindex naming programs
|
|
@cindex @command{test} programs
|
|
@cindex programs, @command{test}
|
|
It is occasionally reported that a ``simple'' program,
|
|
such as a ``Hello, World!'' program, does nothing when
|
|
it is run, even though the compiler reported no errors,
|
|
despite the program containing nothing other than a
|
|
simple @code{PRINT} statement.
|
|
|
|
This most often happens because the program has been
|
|
compiled and linked on a UNIX system and named @command{test},
|
|
though other names can lead to similarly unexpected
|
|
run-time behavior on various systems.
|
|
|
|
Essentially this problem boils down to giving
|
|
your program a name that is already known to
|
|
the shell you are using to identify some other program,
|
|
which the shell continues to execute instead of your
|
|
program when you invoke it via, for example:
|
|
|
|
@smallexample
|
|
sh# @kbd{test}
|
|
sh#
|
|
@end smallexample
|
|
|
|
Under UNIX and many other system, a simple command name
|
|
invokes a searching mechanism that might well not choose
|
|
the program located in the current working directory if
|
|
there is another alternative (such as the @command{test}
|
|
command commonly installed on UNIX systems).
|
|
|
|
The reliable way to invoke a program you just linked in
|
|
the current directory under UNIX is to specify it using
|
|
an explicit pathname, as in:
|
|
|
|
@smallexample
|
|
sh# @kbd{./test}
|
|
Hello, World!
|
|
sh#
|
|
@end smallexample
|
|
|
|
Users who encounter this problem should take the time to
|
|
read up on how their shell searches for commands, how to
|
|
set their search path, and so on.
|
|
The relevant UNIX commands to learn about include
|
|
@command{man}, @command{info} (on GNU systems), @command{setenv} (or
|
|
@command{set} and @command{env}), @command{which}, and @command{find}.
|
|
|
|
@node Strange Behavior at Run Time
|
|
@subsection Strange Behavior at Run Time
|
|
@cindex segmentation violation
|
|
@cindex bus error
|
|
@cindex overwritten data
|
|
@cindex data, overwritten
|
|
@command{g77} code might fail at runtime with ``segmentation violation'',
|
|
``bus error'', or even something as subtle as a procedure call
|
|
overwriting a variable or array element that it is not supposed
|
|
to touch.
|
|
|
|
These can be symptoms of a wide variety of actual bugs that
|
|
occurred earlier during the program's run, but manifested
|
|
themselves as @emph{visible} problems some time later.
|
|
|
|
Overflowing the bounds of an array---usually by writing beyond
|
|
the end of it---is one of two kinds of bug that often occurs
|
|
in Fortran code.
|
|
(Compile your code with the @option{-fbounds-check} option
|
|
to catch many of these kinds of errors at program run time.)
|
|
|
|
The other kind of bug is a mismatch between the actual arguments
|
|
passed to a procedure and the dummy arguments as declared by that
|
|
procedure.
|
|
|
|
Both of these kinds of bugs, and some others as well, can be
|
|
difficult to track down, because the bug can change its behavior,
|
|
or even appear to not occur, when using a debugger.
|
|
|
|
That is, these bugs can be quite sensitive to data, including
|
|
data representing the placement of other data in memory (that is,
|
|
pointers, such as the placement of stack frames in memory).
|
|
|
|
@command{g77} now offers the
|
|
ability to catch and report some of these problems at compile, link, or
|
|
run time, such as by generating code to detect references to
|
|
beyond the bounds of most arrays (except assumed-size arrays),
|
|
and checking for agreement between calling and called procedures.
|
|
Future improvements are likely to be made in the procedure-mismatch area,
|
|
at least.
|
|
|
|
In the meantime, finding and fixing the programming
|
|
bugs that lead to these behaviors is, ultimately, the user's
|
|
responsibility, as difficult as that task can sometimes be.
|
|
|
|
@cindex infinite spaces printed
|
|
@cindex space, endless printing of
|
|
@cindex libc, non-ANSI or non-default
|
|
@cindex C library
|
|
@cindex linking against non-standard library
|
|
@cindex Solaris
|
|
One runtime problem that has been observed might have a simple solution.
|
|
If a formatted @code{WRITE} produces an endless stream of spaces, check
|
|
that your program is linked against the correct version of the C library.
|
|
The configuration process takes care to account for your
|
|
system's normal @file{libc} not being ANSI-standard, which will
|
|
otherwise cause this behaviour.
|
|
If your system's default library is
|
|
ANSI-standard and you subsequently link against a non-ANSI one, there
|
|
might be problems such as this one.
|
|
|
|
Specifically, on Solaris2 systems,
|
|
avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
|
|
|
|
@node Floating-point Errors
|
|
@subsection Floating-point Errors
|
|
@cindex floating-point errors
|
|
@cindex rounding errors
|
|
@cindex inconsistent floating-point results
|
|
@cindex results, inconsistent
|
|
Some programs appear to produce inconsistent floating-point
|
|
results compiled by @command{g77} versus by other compilers.
|
|
|
|
Often the reason for this behavior is the fact that floating-point
|
|
values are represented on almost all Fortran systems by
|
|
@emph{approximations}, and these approximations are inexact
|
|
even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
|
|
0.7, 0.8, 0.9, 1.1, and so on.
|
|
Most Fortran systems, including all current ports of @command{g77},
|
|
use binary arithmetic to represent these approximations.
|
|
|
|
Therefore, the exact value of any floating-point approximation
|
|
as manipulated by @command{g77}-compiled code is representable by
|
|
adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
|
|
so on (just keep dividing by two) through the precision of the
|
|
fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
|
|
@code{REAL(KIND=2)}), then multiplying the sum by a integral
|
|
power of two (in Fortran, by @samp{2**N}) that typically is between
|
|
-127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
|
|
@code{REAL(KIND=2)}, then multiplying by -1 if the number
|
|
is negative.
|
|
|
|
So, a value like 0.2 is exactly represented in decimal---since
|
|
it is a fraction, @samp{2/10}, with a denominator that is compatible
|
|
with the base of the number system (base 10).
|
|
However, @samp{2/10} cannot be represented by any finite number
|
|
of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
|
|
be exactly represented in binary notation.
|
|
|
|
(On the other hand, decimal notation can represent any binary
|
|
number in a finite number of digits.
|
|
Decimal notation cannot do so with ternary, or base-3,
|
|
notation, which would represent floating-point numbers as
|
|
sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
|
|
After all, no finite number of decimal digits can exactly
|
|
represent @samp{1/3}.
|
|
Fortunately, few systems use ternary notation.)
|
|
|
|
Moreover, differences in the way run-time I/O libraries convert
|
|
between these approximations and the decimal representation often
|
|
used by programmers and the programs they write can result in
|
|
apparent differences between results that do not actually exist,
|
|
or exist to such a small degree that they usually are not worth
|
|
worrying about.
|
|
|
|
For example, consider the following program:
|
|
|
|
@smallexample
|
|
PRINT *, 0.2
|
|
END
|
|
@end smallexample
|
|
|
|
When compiled by @command{g77}, the above program might output
|
|
@samp{0.20000003}, while another compiler might produce a
|
|
executable that outputs @samp{0.2}.
|
|
|
|
This particular difference is due to the fact that, currently,
|
|
conversion of floating-point values by the @code{libg2c} library,
|
|
used by @command{g77}, handles only double-precision values.
|
|
|
|
Since @samp{0.2} in the program is a single-precision value, it
|
|
is converted to double precision (still in binary notation)
|
|
before being converted back to decimal.
|
|
The conversion to binary appends @emph{binary} zero digits to the
|
|
original value---which, again, is an inexact approximation of
|
|
0.2---resulting in an approximation that is much less exact
|
|
than is connoted by the use of double precision.
|
|
|
|
(The appending of binary zero digits has essentially the same
|
|
effect as taking a particular decimal approximation of
|
|
@samp{1/3}, such as @samp{0.3333333}, and appending decimal
|
|
zeros to it, producing @samp{0.33333330000000000}.
|
|
Treating the resulting decimal approximation as if it really
|
|
had 18 or so digits of valid precision would make it seem
|
|
a very poor approximation of @samp{1/3}.)
|
|
|
|
As a result of converting the single-precision approximation
|
|
to double precision by appending binary zeros, the conversion
|
|
of the resulting double-precision
|
|
value to decimal produces what looks like an incorrect
|
|
result, when in fact the result is @emph{inexact}, and
|
|
is probably no less inaccurate or imprecise an approximation
|
|
of 0.2 than is produced by other compilers that happen to output
|
|
the converted value as ``exactly'' @samp{0.2}.
|
|
(Some compilers behave in a way that can make them appear
|
|
to retain more accuracy across a conversion of a single-precision
|
|
constant to double precision.
|
|
@xref{Context-Sensitive Constants}, to see why
|
|
this practice is illusory and even dangerous.)
|
|
|
|
Note that a more exact approximation of the constant is
|
|
computed when the program is changed to specify a
|
|
double-precision constant:
|
|
|
|
@smallexample
|
|
PRINT *, 0.2D0
|
|
END
|
|
@end smallexample
|
|
|
|
Future versions of @command{g77} and/or @code{libg2c} might convert
|
|
single-precision values directly to decimal,
|
|
instead of converting them to double precision first.
|
|
This would tend to result in output that is more consistent
|
|
with that produced by some other Fortran implementations.
|
|
|
|
A useful source of information on floating-point computation is David
|
|
Goldberg, `What Every Computer Scientist Should Know About
|
|
Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
|
|
5-48.
|
|
An online version is available at
|
|
@uref{http://docs.sun.com/},
|
|
and there is a supplemented version, in PostScript form, at
|
|
@uref{http://www.validgh.com/goldberg/paper.ps}.
|
|
|
|
Information related to the IEEE 754
|
|
floating-point standard by a leading light can be found at
|
|
@uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
|
|
see also slides from the short course referenced from
|
|
@uref{http://http.cs.berkeley.edu/%7Efateman/}.
|
|
@uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
|
|
guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
|
|
and library code for GNU/Linux x86 systems.
|
|
|
|
The supplement to the PostScript-formatted Goldberg document,
|
|
referenced above, is available in HTML format.
|
|
See `Differences Among IEEE 754 Implementations' by Doug Priest,
|
|
available online at
|
|
@uref{http://www.validgh.com/goldberg/addendum.html}.
|
|
This document explores some of the issues surrounding computing
|
|
of extended (80-bit) results on processors such as the x86,
|
|
especially when those results are arbitrarily truncated
|
|
to 32-bit or 64-bit values by the compiler
|
|
as ``spills''.
|
|
|
|
@cindex spills of floating-point results
|
|
@cindex 80-bit spills
|
|
@cindex truncation, of floating-point values
|
|
(@emph{Note:} @command{g77} specifically, and @command{gcc} generally,
|
|
does arbitrarily truncate 80-bit results during spills
|
|
as of this writing.
|
|
It is not yet clear whether a future version of
|
|
the GNU compiler suite will offer 80-bit spills
|
|
as an option, or perhaps even as the default behavior.)
|
|
|
|
@c xref would be different between editions:
|
|
The GNU C library provides routines for controlling the FPU, and other
|
|
documentation about this.
|
|
|
|
@xref{Floating-point precision}, regarding IEEE 754 conformance.
|
|
|
|
@include bugs.texi
|
|
|
|
@node Missing Features
|
|
@section Missing Features
|
|
|
|
This section lists features we know are missing from @command{g77},
|
|
and which we want to add someday.
|
|
(There is no priority implied in the ordering below.)
|
|
|
|
@menu
|
|
GNU Fortran language:
|
|
* Better Source Model::
|
|
* Fortran 90 Support::
|
|
* Intrinsics in PARAMETER Statements::
|
|
* Arbitrary Concatenation::
|
|
* SELECT CASE on CHARACTER Type::
|
|
* RECURSIVE Keyword::
|
|
* Popular Non-standard Types::
|
|
* Full Support for Compiler Types::
|
|
* Array Bounds Expressions::
|
|
* POINTER Statements::
|
|
* Sensible Non-standard Constructs::
|
|
* READONLY Keyword::
|
|
* FLUSH Statement::
|
|
* Expressions in FORMAT Statements::
|
|
* Explicit Assembler Code::
|
|
* Q Edit Descriptor::
|
|
|
|
GNU Fortran dialects:
|
|
* Old-style PARAMETER Statements::
|
|
* TYPE and ACCEPT I/O Statements::
|
|
* STRUCTURE UNION RECORD MAP::
|
|
* OPEN CLOSE and INQUIRE Keywords::
|
|
* ENCODE and DECODE::
|
|
* AUTOMATIC Statement::
|
|
* Suppressing Space Padding::
|
|
* Fortran Preprocessor::
|
|
* Bit Operations on Floating-point Data::
|
|
* Really Ugly Character Assignments::
|
|
|
|
New facilities:
|
|
* POSIX Standard::
|
|
* Floating-point Exception Handling::
|
|
* Nonportable Conversions::
|
|
* Large Automatic Arrays::
|
|
* Support for Threads::
|
|
* Increasing Precision/Range::
|
|
* Enabling Debug Lines::
|
|
|
|
Better diagnostics:
|
|
* Better Warnings::
|
|
* Gracefully Handle Sensible Bad Code::
|
|
* Non-standard Conversions::
|
|
* Non-standard Intrinsics::
|
|
* Modifying DO Variable::
|
|
* Better Pedantic Compilation::
|
|
* Warn About Implicit Conversions::
|
|
* Invalid Use of Hollerith Constant::
|
|
* Dummy Array Without Dimensioning Dummy::
|
|
* Invalid FORMAT Specifiers::
|
|
* Ambiguous Dialects::
|
|
* Unused Labels::
|
|
* Informational Messages::
|
|
|
|
Run-time facilities:
|
|
* Uninitialized Variables at Run Time::
|
|
* Portable Unformatted Files::
|
|
* Better List-directed I/O::
|
|
* Default to Console I/O::
|
|
|
|
Debugging:
|
|
* Labels Visible to Debugger::
|
|
@end menu
|
|
|
|
@node Better Source Model
|
|
@subsection Better Source Model
|
|
|
|
@command{g77} needs to provide, as the default source-line model,
|
|
a ``pure visual'' mode, where
|
|
the interpretation of a source program in this mode can be accurately
|
|
determined by a user looking at a traditionally displayed rendition
|
|
of the program (assuming the user knows whether the program is fixed
|
|
or free form).
|
|
|
|
The design should assume the user cannot tell tabs from spaces
|
|
and cannot see trailing spaces on lines, but has canonical tab stops
|
|
and, for fixed-form source, has the ability to always know exactly
|
|
where column 72 is (since the Fortran standard itself requires
|
|
this for fixed-form source).
|
|
|
|
This would change the default treatment of fixed-form source
|
|
to not treat lines with tabs as if they were infinitely long---instead,
|
|
they would end at column 72 just as if the tabs were replaced
|
|
by spaces in the canonical way.
|
|
|
|
As part of this, provide common alternate models (Digital, @command{f2c},
|
|
and so on) via command-line options.
|
|
This includes allowing arbitrarily long
|
|
lines for free-form source as well as fixed-form source and providing
|
|
various limits and diagnostics as appropriate.
|
|
|
|
@cindex sequence numbers
|
|
@cindex columns 73 through 80
|
|
Also, @command{g77} should offer, perhaps even default to, warnings
|
|
when characters beyond the last valid column are anything other
|
|
than spaces.
|
|
This would mean code with ``sequence numbers'' in columns 73 through 80
|
|
would be rejected, and there's a lot of that kind of code around,
|
|
but one of the most frequent bugs encountered by new users is
|
|
accidentally writing fixed-form source code into and beyond
|
|
column 73.
|
|
So, maybe the users of old code would be able to more easily handle
|
|
having to specify, say, a @option{-Wno-col73to80} option.
|
|
|
|
@node Fortran 90 Support
|
|
@subsection Fortran 90 Support
|
|
@cindex Fortran 90, support
|
|
@cindex support, Fortran 90
|
|
|
|
@command{g77} does not support many of the features that
|
|
distinguish Fortran 90 (and, now, Fortran 95) from
|
|
ANSI FORTRAN 77.
|
|
|
|
Some Fortran 90 features are supported, because they
|
|
make sense to offer even to die-hard users of F77.
|
|
For example, many of them codify various ways F77 has
|
|
been extended to meet users' needs during its tenure,
|
|
so @command{g77} might as well offer them as the primary
|
|
way to meet those same needs, even if it offers compatibility
|
|
with one or more of the ways those needs were met
|
|
by other F77 compilers in the industry.
|
|
|
|
Still, many important F90 features are not supported,
|
|
because no attempt has been made to research each and
|
|
every feature and assess its viability in @command{g77}.
|
|
In the meantime, users who need those features must
|
|
use Fortran 90 compilers anyway, and the best approach
|
|
to adding some F90 features to GNU Fortran might well be
|
|
to fund a comprehensive project to create GNU Fortran 95.
|
|
|
|
@node Intrinsics in PARAMETER Statements
|
|
@subsection Intrinsics in @code{PARAMETER} Statements
|
|
@cindex PARAMETER statement
|
|
@cindex statements, PARAMETER
|
|
|
|
@command{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
|
|
|
|
Related to this, @command{g77} doesn't allow non-integral
|
|
exponentiation in @code{PARAMETER} statements, such as
|
|
@samp{PARAMETER (R=2**.25)}.
|
|
It is unlikely @command{g77} will ever support this feature,
|
|
as doing it properly requires complete emulation of
|
|
a target computer's floating-point facilities when
|
|
building @command{g77} as a cross-compiler.
|
|
But, if the @command{gcc} back end is enhanced to provide
|
|
such a facility, @command{g77} will likely use that facility
|
|
in implementing this feature soon afterwards.
|
|
|
|
@node Arbitrary Concatenation
|
|
@subsection Arbitrary Concatenation
|
|
@cindex concatenation
|
|
@cindex CHARACTER*(*)
|
|
@cindex run-time, dynamic allocation
|
|
|
|
@command{g77} doesn't support arbitrary operands for concatenation
|
|
in contexts where run-time allocation is required.
|
|
For example:
|
|
|
|
@smallexample
|
|
SUBROUTINE X(A)
|
|
CHARACTER*(*) A
|
|
CALL FOO(A // 'suffix')
|
|
@end smallexample
|
|
|
|
@node SELECT CASE on CHARACTER Type
|
|
@subsection @code{SELECT CASE} on @code{CHARACTER} Type
|
|
|
|
Character-type selector/cases for @code{SELECT CASE} currently
|
|
are not supported.
|
|
|
|
@node RECURSIVE Keyword
|
|
@subsection @code{RECURSIVE} Keyword
|
|
@cindex RECURSIVE keyword
|
|
@cindex keywords, RECURSIVE
|
|
@cindex recursion, lack of
|
|
@cindex lack of recursion
|
|
|
|
@command{g77} doesn't support the @code{RECURSIVE} keyword that
|
|
F90 compilers do.
|
|
Nor does it provide any means for compiling procedures
|
|
designed to do recursion.
|
|
|
|
All recursive code can be rewritten to not use recursion,
|
|
but the result is not pretty.
|
|
|
|
@node Increasing Precision/Range
|
|
@subsection Increasing Precision/Range
|
|
@cindex -r8
|
|
@cindex -qrealsize=8
|
|
@cindex -i8
|
|
@cindex f2c
|
|
@cindex increasing precision
|
|
@cindex precision, increasing
|
|
@cindex increasing range
|
|
@cindex range, increasing
|
|
@cindex Toolpack
|
|
@cindex Netlib
|
|
|
|
Some compilers, such as @command{f2c}, have an option (@option{-r8},
|
|
@option{-qrealsize=8} or
|
|
similar) that provides automatic treatment of @code{REAL}
|
|
entities such that they have twice the storage size, and
|
|
a corresponding increase in the range and precision, of what
|
|
would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
|
|
(This affects @code{COMPLEX} the same way.)
|
|
|
|
They also typically offer another option (@option{-i8}) to increase
|
|
@code{INTEGER} entities so they are twice as large
|
|
(with roughly twice as much range).
|
|
|
|
(There are potential pitfalls in using these options.)
|
|
|
|
@command{g77} does not yet offer any option that performs these
|
|
kinds of transformations.
|
|
Part of the problem is the lack of detailed specifications regarding
|
|
exactly how these options affect the interpretation of constants,
|
|
intrinsics, and so on.
|
|
|
|
Until @command{g77} addresses this need, programmers could improve
|
|
the portability of their code by modifying it to not require
|
|
compile-time options to produce correct results.
|
|
Some free tools are available which may help, specifically
|
|
in Toolpack (which one would expect to be sound) and the @file{fortran}
|
|
section of the Netlib repository.
|
|
|
|
Use of preprocessors can provide a fairly portable means
|
|
to work around the lack of widely portable methods in the Fortran
|
|
language itself (though increasing acceptance of Fortran 90 would
|
|
alleviate this problem).
|
|
|
|
@node Popular Non-standard Types
|
|
@subsection Popular Non-standard Types
|
|
@cindex @code{INTEGER*2} support
|
|
@cindex types, @code{INTEGER*2}
|
|
@cindex @code{LOGICAL*1} support
|
|
@cindex types, @code{LOGICAL*1}
|
|
|
|
@command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
|
|
and similar.
|
|
In the meantime, version 0.5.18 provides rudimentary support
|
|
for them.
|
|
|
|
@node Full Support for Compiler Types
|
|
@subsection Full Support for Compiler Types
|
|
|
|
@cindex @code{REAL*16} support
|
|
@cindex types, @code{REAL*16}
|
|
@cindex @code{INTEGER*8} support
|
|
@cindex types, @code{INTEGER*8}
|
|
@command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
|
|
for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
|
|
@code{int}, @code{long int}, @code{long long int}, and @code{long double}).
|
|
This means providing intrinsic support, and maybe constant
|
|
support (using F90 syntax) as well, and, for most
|
|
machines will result in automatic support of @code{INTEGER*1},
|
|
@code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
|
|
and so on.
|
|
|
|
@node Array Bounds Expressions
|
|
@subsection Array Bounds Expressions
|
|
@cindex array elements, in adjustable array bounds
|
|
@cindex function references, in adjustable array bounds
|
|
@cindex array bounds, adjustable
|
|
@cindex @code{DIMENSION} statement
|
|
@cindex statements, @code{DIMENSION}
|
|
|
|
@command{g77} doesn't support more general expressions to dimension
|
|
arrays, such as array element references, function
|
|
references, etc.
|
|
|
|
For example, @command{g77} currently does not accept the following:
|
|
|
|
@smallexample
|
|
SUBROUTINE X(M, N)
|
|
INTEGER N(10), M(N(2), N(1))
|
|
@end smallexample
|
|
|
|
@node POINTER Statements
|
|
@subsection POINTER Statements
|
|
@cindex POINTER statement
|
|
@cindex statements, POINTER
|
|
@cindex Cray pointers
|
|
|
|
@command{g77} doesn't support pointers or allocatable objects
|
|
(other than automatic arrays).
|
|
This set of features is
|
|
probably considered just behind intrinsics
|
|
in @code{PARAMETER} statements on the list of large,
|
|
important things to add to @command{g77}.
|
|
|
|
In the meantime, consider using the @code{INTEGER(KIND=7)}
|
|
declaration to specify that a variable must be
|
|
able to hold a pointer.
|
|
This construct is not portable to other non-GNU compilers,
|
|
but it is portable to all machines GNU Fortran supports
|
|
when @command{g77} is used.
|
|
|
|
@xref{Functions and Subroutines}, for information on
|
|
@code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
|
|
constructs, which are useful for passing pointers to
|
|
procedures written in languages other than Fortran.
|
|
|
|
@node Sensible Non-standard Constructs
|
|
@subsection Sensible Non-standard Constructs
|
|
|
|
@command{g77} rejects things other compilers accept,
|
|
like @samp{INTRINSIC SQRT,SQRT}.
|
|
As time permits in the future, some of these things that are easy for
|
|
humans to read and write and unlikely to be intended to mean something
|
|
else will be accepted by @command{g77} (though @option{-fpedantic} should
|
|
trigger warnings about such non-standard constructs).
|
|
|
|
Until @command{g77} no longer gratuitously rejects sensible code,
|
|
you might as well fix your code
|
|
to be more standard-conforming and portable.
|
|
|
|
The kind of case that is important to except from the
|
|
recommendation to change your code is one where following
|
|
good coding rules would force you to write non-standard
|
|
code that nevertheless has a clear meaning.
|
|
|
|
For example, when writing an @code{INCLUDE} file that
|
|
defines a common block, it might be appropriate to
|
|
include a @code{SAVE} statement for the common block
|
|
(such as @samp{SAVE /CBLOCK/}), so that variables
|
|
defined in the common block retain their values even
|
|
when all procedures declaring the common block become
|
|
inactive (return to their callers).
|
|
|
|
However, putting @code{SAVE} statements in an @code{INCLUDE}
|
|
file would prevent otherwise standard-conforming code
|
|
from also specifying the @code{SAVE} statement, by itself,
|
|
to indicate that all local variables and arrays are to
|
|
have the @code{SAVE} attribute.
|
|
|
|
For this reason, @command{g77} already has been changed to
|
|
allow this combination, because although the general
|
|
problem of gratuitously rejecting unambiguous and
|
|
``safe'' constructs still exists in @command{g77}, this
|
|
particular construct was deemed useful enough that
|
|
it was worth fixing @command{g77} for just this case.
|
|
|
|
So, while there is no need to change your code
|
|
to avoid using this particular construct, there
|
|
might be other, equally appropriate but non-standard
|
|
constructs, that you shouldn't have to stop using
|
|
just because @command{g77} (or any other compiler)
|
|
gratuitously rejects it.
|
|
|
|
Until the general problem is solved, if you have
|
|
any such construct you believe is worthwhile
|
|
using (e.g. not just an arbitrary, redundant
|
|
specification of an attribute), please submit a
|
|
bug report with an explanation, so we can consider
|
|
fixing @command{g77} just for cases like yours.
|
|
|
|
@node READONLY Keyword
|
|
@subsection @code{READONLY} Keyword
|
|
@cindex READONLY
|
|
|
|
Support for @code{READONLY}, in @code{OPEN} statements,
|
|
requires @code{libg2c} support,
|
|
to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
|
|
does not delete a file opened on a unit
|
|
with the @code{READONLY} keyword,
|
|
and perhaps to trigger a fatal diagnostic
|
|
if a @code{WRITE} or @code{PRINT}
|
|
to such a unit is attempted.
|
|
|
|
@emph{Note:} It is not sufficient for @command{g77} and @code{libg2c}
|
|
(its version of @code{libf2c})
|
|
to assume that @code{READONLY} does not need some kind of explicit support
|
|
at run time,
|
|
due to UNIX systems not (generally) needing it.
|
|
@command{g77} is not just a UNIX-based compiler!
|
|
|
|
Further, mounting of non-UNIX filesystems on UNIX systems
|
|
(such as via NFS)
|
|
might require proper @code{READONLY} support.
|
|
|
|
@cindex SHARED
|
|
(Similar issues might be involved with supporting the @code{SHARED}
|
|
keyword.)
|
|
|
|
@node FLUSH Statement
|
|
@subsection @code{FLUSH} Statement
|
|
|
|
@command{g77} could perhaps use a @code{FLUSH} statement that
|
|
does what @samp{CALL FLUSH} does,
|
|
but that supports @samp{*} as the unit designator (same unit as for
|
|
@code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
|
|
specifiers.
|
|
|
|
@node Expressions in FORMAT Statements
|
|
@subsection Expressions in @code{FORMAT} Statements
|
|
@cindex FORMAT statement
|
|
@cindex statements, FORMAT
|
|
|
|
@command{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
|
|
Supporting this requires a significant redesign or replacement
|
|
of @code{libg2c}.
|
|
|
|
However, @command{g77} does support
|
|
this construct when the expression is constant
|
|
(as of version 0.5.22).
|
|
For example:
|
|
|
|
@smallexample
|
|
PARAMETER (IWIDTH = 12)
|
|
10 FORMAT (I<IWIDTH>)
|
|
@end smallexample
|
|
|
|
Otherwise, at least for output (@code{PRINT} and
|
|
@code{WRITE}), Fortran code making use of this feature can
|
|
be rewritten to avoid it by constructing the @code{FORMAT}
|
|
string in a @code{CHARACTER} variable or array, then
|
|
using that variable or array in place of the @code{FORMAT}
|
|
statement label to do the original @code{PRINT} or @code{WRITE}.
|
|
|
|
Many uses of this feature on input can be rewritten this way
|
|
as well, but not all can.
|
|
For example, this can be rewritten:
|
|
|
|
@smallexample
|
|
READ 20, I
|
|
20 FORMAT (I<J>)
|
|
@end smallexample
|
|
|
|
However, this cannot, in general, be rewritten, especially
|
|
when @code{ERR=} and @code{END=} constructs are employed:
|
|
|
|
@smallexample
|
|
READ 30, J, I
|
|
30 FORMAT (I<J>)
|
|
@end smallexample
|
|
|
|
@node Explicit Assembler Code
|
|
@subsection Explicit Assembler Code
|
|
|
|
@command{g77} needs to provide some way, a la @command{gcc}, for @command{g77}
|
|
code to specify explicit assembler code.
|
|
|
|
@node Q Edit Descriptor
|
|
@subsection Q Edit Descriptor
|
|
@cindex FORMAT statement
|
|
@cindex Q edit descriptor
|
|
@cindex edit descriptor, Q
|
|
|
|
The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
|
|
(This is meant to get the number of characters remaining in an input record.)
|
|
Supporting this requires a significant redesign or replacement
|
|
of @code{libg2c}.
|
|
|
|
A workaround might be using internal I/O or the stream-based intrinsics.
|
|
@xref{FGetC Intrinsic (subroutine)}.
|
|
|
|
@node Old-style PARAMETER Statements
|
|
@subsection Old-style PARAMETER Statements
|
|
@cindex PARAMETER statement
|
|
@cindex statements, PARAMETER
|
|
|
|
@command{g77} doesn't accept @samp{PARAMETER I=1}.
|
|
Supporting this obsolete form of
|
|
the @code{PARAMETER} statement would not be particularly hard, as most of the
|
|
parsing code is already in place and working.
|
|
|
|
Until time/money is
|
|
spent implementing it, you might as well fix your code to use the
|
|
standard form, @samp{PARAMETER (I=1)} (possibly needing
|
|
@samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
|
|
otherwise, in the obsolete form of @code{PARAMETER}, the
|
|
type of the variable is set from the type of the constant being
|
|
assigned to it).
|
|
|
|
@node TYPE and ACCEPT I/O Statements
|
|
@subsection @code{TYPE} and @code{ACCEPT} I/O Statements
|
|
@cindex TYPE statement
|
|
@cindex statements, TYPE
|
|
@cindex ACCEPT statement
|
|
@cindex statements, ACCEPT
|
|
|
|
@command{g77} doesn't support the I/O statements @code{TYPE} and
|
|
@code{ACCEPT}.
|
|
These are common extensions that should be easy to support,
|
|
but also are fairly easy to work around in user code.
|
|
|
|
Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
|
|
by @samp{PRINT fmt,list}.
|
|
And, any @samp{ACCEPT fmt,list} statement can be
|
|
replaced by @samp{READ fmt,list}.
|
|
|
|
@node STRUCTURE UNION RECORD MAP
|
|
@subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
|
|
@cindex STRUCTURE statement
|
|
@cindex statements, STRUCTURE
|
|
@cindex UNION statement
|
|
@cindex statements, UNION
|
|
@cindex RECORD statement
|
|
@cindex statements, RECORD
|
|
@cindex MAP statement
|
|
@cindex statements, MAP
|
|
|
|
@command{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
|
|
@code{MAP}.
|
|
This set of extensions is quite a bit
|
|
lower on the list of large, important things to add to @command{g77}, partly
|
|
because it requires a great deal of work either upgrading or
|
|
replacing @code{libg2c}.
|
|
|
|
@node OPEN CLOSE and INQUIRE Keywords
|
|
@subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
|
|
@cindex disposition of files
|
|
@cindex OPEN statement
|
|
@cindex statements, OPEN
|
|
@cindex CLOSE statement
|
|
@cindex statements, CLOSE
|
|
@cindex INQUIRE statement
|
|
@cindex statements, INQUIRE
|
|
|
|
@command{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
|
|
the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
|
|
These extensions are easy to add to @command{g77} itself, but
|
|
require much more work on @code{libg2c}.
|
|
|
|
@cindex FORM='PRINT'
|
|
@cindex ANS carriage control
|
|
@cindex carriage control
|
|
@pindex asa
|
|
@pindex fpr
|
|
@command{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
|
|
translate the traditional `carriage control' characters in column 1 of
|
|
output to use backspaces, carriage returns and the like. However
|
|
programs exist to translate them in output files (or standard output).
|
|
These are typically called either @command{fpr} or @command{asa}. You can get
|
|
a version of @command{asa} from
|
|
@uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
|
|
systems which will probably build easily on other systems.
|
|
Alternatively, @command{fpr} is in BSD distributions in various archive
|
|
sites.
|
|
|
|
@c (Can both programs can be used in a pipeline,
|
|
@c with a named input file,
|
|
@c and/or with a named output file???)
|
|
|
|
@node ENCODE and DECODE
|
|
@subsection @code{ENCODE} and @code{DECODE}
|
|
@cindex ENCODE statement
|
|
@cindex statements, ENCODE
|
|
@cindex DECODE statement
|
|
@cindex statements, DECODE
|
|
|
|
@command{g77} doesn't support @code{ENCODE} or @code{DECODE}.
|
|
|
|
These statements are best replaced by READ and WRITE statements
|
|
involving internal files (CHARACTER variables and arrays).
|
|
|
|
For example, replace a code fragment like
|
|
|
|
@smallexample
|
|
INTEGER*1 LINE(80)
|
|
@dots{}
|
|
DECODE (80, 9000, LINE) A, B, C
|
|
@dots{}
|
|
9000 FORMAT (1X, 3(F10.5))
|
|
@end smallexample
|
|
|
|
@noindent
|
|
with:
|
|
|
|
@smallexample
|
|
CHARACTER*80 LINE
|
|
@dots{}
|
|
READ (UNIT=LINE, FMT=9000) A, B, C
|
|
@dots{}
|
|
9000 FORMAT (1X, 3(F10.5))
|
|
@end smallexample
|
|
|
|
Similarly, replace a code fragment like
|
|
|
|
@smallexample
|
|
INTEGER*1 LINE(80)
|
|
@dots{}
|
|
ENCODE (80, 9000, LINE) A, B, C
|
|
@dots{}
|
|
9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
|
|
@end smallexample
|
|
|
|
@noindent
|
|
with:
|
|
|
|
@smallexample
|
|
CHARACTER*80 LINE
|
|
@dots{}
|
|
WRITE (UNIT=LINE, FMT=9000) A, B, C
|
|
@dots{}
|
|
9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
|
|
@end smallexample
|
|
|
|
It is entirely possible that @code{ENCODE} and @code{DECODE} will
|
|
be supported by a future version of @command{g77}.
|
|
|
|
@node AUTOMATIC Statement
|
|
@subsection @code{AUTOMATIC} Statement
|
|
@cindex @code{AUTOMATIC} statement
|
|
@cindex statements, @code{AUTOMATIC}
|
|
@cindex automatic variables
|
|
@cindex variables, automatic
|
|
|
|
@command{g77} doesn't support the @code{AUTOMATIC} statement that
|
|
@command{f2c} does.
|
|
|
|
@code{AUTOMATIC} would identify a variable or array
|
|
as not being @code{SAVE}'d, which is normally the default,
|
|
but which would be especially useful for code that, @emph{generally},
|
|
needed to be compiled with the @option{-fno-automatic} option.
|
|
|
|
@code{AUTOMATIC} also would serve as a hint to the compiler that placing
|
|
the variable or array---even a very large array--on the stack is acceptable.
|
|
|
|
@code{AUTOMATIC} would not, by itself, designate the containing procedure
|
|
as recursive.
|
|
|
|
@code{AUTOMATIC} should work syntactically like @code{SAVE},
|
|
in that @code{AUTOMATIC} with no variables listed should apply to
|
|
all pertinent variables and arrays
|
|
(which would not include common blocks or their members).
|
|
|
|
Variables and arrays denoted as @code{AUTOMATIC}
|
|
would not be permitted to be initialized via @code{DATA}
|
|
or other specification of any initial values,
|
|
requiring explicit initialization,
|
|
such as via assignment statements.
|
|
|
|
@cindex UNSAVE
|
|
@cindex STATIC
|
|
Perhaps @code{UNSAVE} and @code{STATIC},
|
|
as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
|
|
should be provided as well.
|
|
|
|
@node Suppressing Space Padding
|
|
@subsection Suppressing Space Padding of Source Lines
|
|
|
|
@command{g77} should offer VXT-Fortran-style suppression of virtual
|
|
spaces at the end of a source line
|
|
if an appropriate command-line option is specified.
|
|
|
|
This affects cases where
|
|
a character constant is continued onto the next line in a fixed-form
|
|
source file, as in the following example:
|
|
|
|
@smallexample
|
|
10 PRINT *,'HOW MANY
|
|
1 SPACES?'
|
|
@end smallexample
|
|
|
|
@noindent
|
|
@command{g77}, and many other compilers, virtually extend
|
|
the continued line through column 72 with spaces that become part
|
|
of the character constant, but Digital Fortran normally didn't,
|
|
leaving only one space between @samp{MANY} and @samp{SPACES?}
|
|
in the output of the above statement.
|
|
|
|
Fairly recently, at least one version of Digital Fortran
|
|
was enhanced to provide the other behavior when a
|
|
command-line option is specified, apparently due to demand
|
|
from readers of the USENET group @file{comp.lang.fortran}
|
|
to offer conformance to this widespread practice in the
|
|
industry.
|
|
@command{g77} should return the favor by offering conformance
|
|
to Digital's approach to handling the above example.
|
|
|
|
@node Fortran Preprocessor
|
|
@subsection Fortran Preprocessor
|
|
|
|
@command{g77} should offer a preprocessor designed specifically
|
|
for Fortran to replace @samp{cpp -traditional}.
|
|
There are several out there worth evaluating, at least.
|
|
|
|
Such a preprocessor would recognize Hollerith constants,
|
|
properly parse comments and character constants, and so on.
|
|
It might also recognize, process, and thus preprocess
|
|
files included via the @code{INCLUDE} directive.
|
|
|
|
@node Bit Operations on Floating-point Data
|
|
@subsection Bit Operations on Floating-point Data
|
|
@cindex @code{And} intrinsic
|
|
@cindex intrinsics, @code{And}
|
|
@cindex @code{Or} intrinsic
|
|
@cindex intrinsics, @code{Or}
|
|
@cindex @code{Shift} intrinsic
|
|
@cindex intrinsics, @code{Shift}
|
|
|
|
@command{g77} does not allow @code{REAL} and other non-integral types for
|
|
arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
|
|
|
|
For example, this program is rejected by @command{g77}, because
|
|
the intrinsic @code{Iand} does not accept @code{REAL} arguments:
|
|
|
|
@smallexample
|
|
DATA A/7.54/, B/9.112/
|
|
PRINT *, IAND(A, B)
|
|
END
|
|
@end smallexample
|
|
|
|
@node Really Ugly Character Assignments
|
|
@subsection Really Ugly Character Assignments
|
|
|
|
An option such as @option{-fugly-char} should be provided
|
|
to allow
|
|
|
|
@smallexample
|
|
REAL*8 A1
|
|
DATA A1 / '12345678' /
|
|
@end smallexample
|
|
|
|
and:
|
|
|
|
@smallexample
|
|
REAL*8 A1
|
|
A1 = 'ABCDEFGH'
|
|
@end smallexample
|
|
|
|
@node POSIX Standard
|
|
@subsection @code{POSIX} Standard
|
|
|
|
@command{g77} should support the POSIX standard for Fortran.
|
|
|
|
@node Floating-point Exception Handling
|
|
@subsection Floating-point Exception Handling
|
|
@cindex floating-point, exceptions
|
|
@cindex exceptions, floating-point
|
|
@cindex FPE handling
|
|
@cindex NaN values
|
|
|
|
The @command{gcc} backend and, consequently, @command{g77}, currently provides no
|
|
general control over whether or not floating-point exceptions are trapped or
|
|
ignored.
|
|
(Ignoring them typically results in NaN values being
|
|
propagated in systems that conform to IEEE 754.)
|
|
The behaviour is normally inherited from the system-dependent startup
|
|
code, though some targets, such as the Alpha, have code generation
|
|
options which change the behaviour.
|
|
|
|
Most systems provide some C-callable mechanism to change this; this can
|
|
be invoked at startup using @command{gcc}'s @code{constructor} attribute.
|
|
For example, just compiling and linking the following C code with your
|
|
program will turn on exception trapping for the ``common'' exceptions
|
|
on a GNU system using glibc 2.2 or newer:
|
|
|
|
@smallexample
|
|
#define _GNU_SOURCE 1
|
|
#include <fenv.h>
|
|
static void __attribute__ ((constructor))
|
|
trapfpe ()
|
|
@{
|
|
/* Enable some exceptions. At startup all exceptions are masked. */
|
|
|
|
feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
|
|
@}
|
|
@end smallexample
|
|
|
|
A convenient trick is to compile this something like:
|
|
@smallexample
|
|
gcc -o libtrapfpe.a trapfpe.c
|
|
@end smallexample
|
|
and then use it by adding @option{-trapfpe} to the @command{g77} command line
|
|
when linking.
|
|
|
|
@node Nonportable Conversions
|
|
@subsection Nonportable Conversions
|
|
@cindex nonportable conversions
|
|
@cindex conversions, nonportable
|
|
|
|
@command{g77} doesn't accept some particularly nonportable,
|
|
silent data-type conversions such as @code{LOGICAL}
|
|
to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
|
|
is type @code{REAL}), that other compilers might
|
|
quietly accept.
|
|
|
|
Some of these conversions are accepted by @command{g77}
|
|
when the @option{-fugly-logint} option is specified.
|
|
Perhaps it should accept more or all of them.
|
|
|
|
@node Large Automatic Arrays
|
|
@subsection Large Automatic Arrays
|
|
@cindex automatic arrays
|
|
@cindex arrays, automatic
|
|
|
|
Currently, automatic arrays always are allocated on the stack.
|
|
For situations where the stack cannot be made large enough,
|
|
@command{g77} should offer a compiler option that specifies
|
|
allocation of automatic arrays in heap storage.
|
|
|
|
@node Support for Threads
|
|
@subsection Support for Threads
|
|
@cindex threads
|
|
@cindex parallel processing
|
|
|
|
Neither the code produced by @command{g77} nor the @code{libg2c} library
|
|
are thread-safe, nor does @command{g77} have support for parallel processing
|
|
(other than the instruction-level parallelism available on some
|
|
processors).
|
|
A package such as PVM might help here.
|
|
|
|
@node Enabling Debug Lines
|
|
@subsection Enabling Debug Lines
|
|
@cindex debug line
|
|
@cindex comment line, debug
|
|
|
|
An option such as @option{-fdebug-lines} should be provided
|
|
to turn fixed-form lines beginning with @samp{D}
|
|
to be treated as if they began with a space,
|
|
instead of as if they began with a @samp{C}
|
|
(as comment lines).
|
|
|
|
@node Better Warnings
|
|
@subsection Better Warnings
|
|
|
|
Because of how @command{g77} generates code via the back end,
|
|
it doesn't always provide warnings the user wants.
|
|
Consider:
|
|
|
|
@smallexample
|
|
PROGRAM X
|
|
PRINT *, A
|
|
END
|
|
@end smallexample
|
|
|
|
Currently, the above is not flagged as a case of
|
|
using an uninitialized variable,
|
|
because @command{g77} generates a run-time library call that looks,
|
|
to the GBE, like it might actually @emph{modify} @samp{A} at run time.
|
|
(And, in fact, depending on the previous run-time library call,
|
|
it would!)
|
|
|
|
Fixing this requires one of the following:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Switch to new library, @code{libg77}, that provides
|
|
a more ``clean'' interface,
|
|
vis-a-vis input, output, and modified arguments,
|
|
so the GBE can tell what's going on.
|
|
|
|
This would provide a pretty big performance improvement,
|
|
at least theoretically, and, ultimately, in practice,
|
|
for some types of code.
|
|
|
|
@item
|
|
Have @command{g77} pass a pointer to a temporary
|
|
containing a copy of @samp{A},
|
|
instead of to @samp{A} itself.
|
|
The GBE would then complain about the copy operation
|
|
involving a potentially uninitialized variable.
|
|
|
|
This might also provide a performance boost for some code,
|
|
because @samp{A} might then end up living in a register,
|
|
which could help with inner loops.
|
|
|
|
@item
|
|
Have @command{g77} use a GBE construct similar to @code{ADDR_EXPR}
|
|
but with extra information on the fact that the
|
|
item pointed to won't be modified
|
|
(a la @code{const} in C).
|
|
|
|
Probably the best solution for now, but not quite trivial
|
|
to implement in the general case.
|
|
@end itemize
|
|
|
|
@node Gracefully Handle Sensible Bad Code
|
|
@subsection Gracefully Handle Sensible Bad Code
|
|
|
|
@command{g77} generally should continue processing for
|
|
warnings and recoverable (user) errors whenever possible---that
|
|
is, it shouldn't gratuitously make bad or useless code.
|
|
|
|
For example:
|
|
|
|
@smallexample
|
|
INTRINSIC ZABS
|
|
CALL FOO(ZABS)
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
When compiling the above with @option{-ff2c-intrinsics-disable},
|
|
@command{g77} should indeed complain about passing @code{ZABS},
|
|
but it still should compile, instead of rejecting
|
|
the entire @code{CALL} statement.
|
|
(Some of this is related to improving
|
|
the compiler internals to improve how statements are analyzed.)
|
|
|
|
@node Non-standard Conversions
|
|
@subsection Non-standard Conversions
|
|
|
|
@option{-Wconversion} and related should flag places where non-standard
|
|
conversions are found.
|
|
Perhaps much of this would be part of @option{-Wugly*}.
|
|
|
|
@node Non-standard Intrinsics
|
|
@subsection Non-standard Intrinsics
|
|
|
|
@command{g77} needs a new option, like @option{-Wintrinsics}, to warn about use of
|
|
non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
|
|
This would help find code that might fail silently when ported to another
|
|
compiler.
|
|
|
|
@node Modifying DO Variable
|
|
@subsection Modifying @code{DO} Variable
|
|
|
|
@command{g77} should warn about modifying @code{DO} variables
|
|
via @code{EQUIVALENCE}.
|
|
(The internal information gathered to produce this warning
|
|
might also be useful in setting the
|
|
internal ``doiter'' flag for a variable or even array
|
|
reference within a loop, since that might produce faster code someday.)
|
|
|
|
For example, this code is invalid, so @command{g77} should warn about
|
|
the invalid assignment to @samp{NOTHER}:
|
|
|
|
@smallexample
|
|
EQUIVALENCE (I, NOTHER)
|
|
DO I = 1, 100
|
|
IF (I.EQ. 10) NOTHER = 20
|
|
END DO
|
|
@end smallexample
|
|
|
|
@node Better Pedantic Compilation
|
|
@subsection Better Pedantic Compilation
|
|
|
|
@command{g77} needs to support @option{-fpedantic} more thoroughly,
|
|
and use it only to generate
|
|
warnings instead of rejecting constructs outright.
|
|
Have it warn:
|
|
if a variable that dimensions an array is not a dummy or placed
|
|
explicitly in @code{COMMON} (F77 does not allow it to be
|
|
placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
|
|
follow statement-function-definition statements; about all sorts of
|
|
syntactic extensions.
|
|
|
|
@node Warn About Implicit Conversions
|
|
@subsection Warn About Implicit Conversions
|
|
|
|
@command{g77} needs a @option{-Wpromotions} option to warn if source code appears
|
|
to expect automatic, silent, and
|
|
somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
|
|
constants to @code{REAL(KIND=2)} based on context.
|
|
|
|
For example, it would warn about cases like this:
|
|
|
|
@smallexample
|
|
DOUBLE PRECISION FOO
|
|
PARAMETER (TZPHI = 9.435784839284958)
|
|
FOO = TZPHI * 3D0
|
|
@end smallexample
|
|
|
|
@node Invalid Use of Hollerith Constant
|
|
@subsection Invalid Use of Hollerith Constant
|
|
|
|
@command{g77} should disallow statements like @samp{RETURN 2HAB},
|
|
which are invalid in both source forms
|
|
(unlike @samp{RETURN (2HAB)},
|
|
which probably still makes no sense but at least can
|
|
be reliably parsed).
|
|
Fixed-form processing rejects it, but not free-form, except
|
|
in a way that is a bit difficult to understand.
|
|
|
|
@node Dummy Array Without Dimensioning Dummy
|
|
@subsection Dummy Array Without Dimensioning Dummy
|
|
|
|
@command{g77} should complain when a list of dummy arguments containing an
|
|
adjustable dummy array does
|
|
not also contain every variable listed in the dimension list of the
|
|
adjustable array.
|
|
|
|
Currently, @command{g77} does complain about a variable that
|
|
dimensions an array but doesn't appear in any dummy list or @code{COMMON}
|
|
area, but this needs to be extended to catch cases where it doesn't appear in
|
|
every dummy list that also lists any arrays it dimensions.
|
|
|
|
For example, @command{g77} should warn about the entry point @samp{ALT}
|
|
below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
|
|
list of arguments:
|
|
|
|
@smallexample
|
|
SUBROUTINE PRIMARY(ARRAY, ISIZE)
|
|
REAL ARRAY(ISIZE)
|
|
ENTRY ALT(ARRAY)
|
|
@end smallexample
|
|
|
|
@node Invalid FORMAT Specifiers
|
|
@subsection Invalid FORMAT Specifiers
|
|
|
|
@command{g77} should check @code{FORMAT} specifiers for validity
|
|
as it does @code{FORMAT} statements.
|
|
|
|
For example, a diagnostic would be produced for:
|
|
|
|
@smallexample
|
|
PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
|
|
@end smallexample
|
|
|
|
@node Ambiguous Dialects
|
|
@subsection Ambiguous Dialects
|
|
|
|
@command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic},
|
|
@option{-Wvxt}, @option{-Wf90}, and so on.
|
|
These would warn about places in the user's source where ambiguities
|
|
are found, helpful in resolving ambiguities in the program's
|
|
dialect or dialects.
|
|
|
|
@node Unused Labels
|
|
@subsection Unused Labels
|
|
|
|
@command{g77} should warn about unused labels when @option{-Wunused} is in effect.
|
|
|
|
@node Informational Messages
|
|
@subsection Informational Messages
|
|
|
|
@command{g77} needs an option to suppress information messages (notes).
|
|
@option{-w} does this but also suppresses warnings.
|
|
The default should be to suppress info messages.
|
|
|
|
Perhaps info messages should simply be eliminated.
|
|
|
|
@node Uninitialized Variables at Run Time
|
|
@subsection Uninitialized Variables at Run Time
|
|
|
|
@command{g77} needs an option to initialize everything (not otherwise
|
|
explicitly initialized) to ``weird''
|
|
(machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
|
|
largest-magnitude integers, would help track down references to
|
|
some kinds of uninitialized variables at run time.
|
|
|
|
Note that use of the options @samp{-O -Wuninitialized} can catch
|
|
many such bugs at compile time.
|
|
|
|
@node Portable Unformatted Files
|
|
@subsection Portable Unformatted Files
|
|
|
|
@cindex unformatted files
|
|
@cindex file formats
|
|
@cindex binary data
|
|
@cindex byte ordering
|
|
@command{g77} has no facility for exchanging unformatted files with systems
|
|
using different number formats---even differing only in endianness (byte
|
|
order)---or written by other compilers. Some compilers provide
|
|
facilities at least for doing byte-swapping during unformatted I/O.
|
|
|
|
It is unrealistic to expect to cope with exchanging unformatted files
|
|
with arbitrary other compiler runtimes, but the @command{g77} runtime
|
|
should at least be able to read files written by @command{g77} on systems
|
|
with different number formats, particularly if they differ only in byte
|
|
order.
|
|
|
|
In case you do need to write a program to translate to or from
|
|
@command{g77} (@code{libf2c}) unformatted files, they are written as
|
|
follows:
|
|
@table @asis
|
|
@item Sequential
|
|
Unformatted sequential records consist of
|
|
@enumerate
|
|
@item
|
|
A number giving the length of the record contents;
|
|
@item
|
|
the length of record contents again (for backspace).
|
|
@end enumerate
|
|
|
|
The record length is of C type
|
|
@code{long}; this means that it is 8 bytes on 64-bit systems such as
|
|
Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
|
|
Consequently such files cannot be exchanged between 64-bit and 32-bit
|
|
systems, even with the same basic number format.
|
|
@item Direct access
|
|
Unformatted direct access files form a byte stream of length
|
|
@var{records}*@var{recl} bytes, where @var{records} is the maximum
|
|
record number (@code{REC=@var{records}}) written and @var{recl} is the
|
|
record length in bytes specified in the @code{OPEN} statement
|
|
(@code{RECL=@var{recl}}). Data appear in the records as determined by
|
|
the relevant @code{WRITE} statement. Dummy records with arbitrary
|
|
contents appear in the file in place of records which haven't been
|
|
written.
|
|
@end table
|
|
|
|
Thus for exchanging a sequential or direct access unformatted file
|
|
between big- and little-endian 32-bit systems using IEEE 754 floating
|
|
point it would be sufficient to reverse the bytes in consecutive words
|
|
in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
|
|
@code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
|
|
@command{g77}.
|
|
|
|
If necessary, it is possible to do byte-oriented i/o with @command{g77}'s
|
|
@code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
|
|
Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
|
|
array or a set of scalars.
|
|
|
|
@cindex HDF
|
|
@cindex PDB
|
|
If you need to exchange binary data between arbitrary system and
|
|
compiler variations, we recommend using a portable binary format with
|
|
Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
|
|
or PACT's PDB@footnote{No, not @emph{that} one.}
|
|
(@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
|
|
say, CDF or XDR, HDF-like systems write in the native number formats and
|
|
only incur overhead when they are read on a system with a different
|
|
format.) A future @command{g77} runtime library should use such
|
|
techniques.
|
|
|
|
@node Better List-directed I/O
|
|
@subsection Better List-directed I/O
|
|
|
|
Values output using list-directed I/O
|
|
(@samp{PRINT *, R, D})
|
|
should be written with a field width, precision, and so on
|
|
appropriate for the type (precision) of each value.
|
|
|
|
(Currently, no distinction is made between single-precision
|
|
and double-precision values
|
|
by @code{libf2c}.)
|
|
|
|
It is likely this item will require the @code{libg77} project
|
|
to be undertaken.
|
|
|
|
In the meantime, use of formatted I/O is recommended.
|
|
While it might be of little consolation,
|
|
@command{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
|
|
as long as @samp{WIDTH} is defined as a named constant
|
|
(via @code{PARAMETER}).
|
|
That at least allows some compile-time specification
|
|
of the precision of a data type,
|
|
perhaps controlled by preprocessing directives.
|
|
|
|
@node Default to Console I/O
|
|
@subsection Default to Console I/O
|
|
|
|
The default I/O units,
|
|
specified by @samp{READ @var{fmt}},
|
|
@samp{READ (UNIT=*)},
|
|
@samp{WRITE (UNIT=*)}, and
|
|
@samp{PRINT @var{fmt}},
|
|
should not be units 5 (input) and 6 (output),
|
|
but, rather, unit numbers not normally available
|
|
for use in statements such as @code{OPEN} and @code{CLOSE}.
|
|
|
|
Changing this would allow a program to connect units 5 and 6
|
|
to files via @code{OPEN},
|
|
but still use @samp{READ (UNIT=*)} and @samp{PRINT}
|
|
to do I/O to the ``console''.
|
|
|
|
This change probably requires the @code{libg77} project.
|
|
|
|
@node Labels Visible to Debugger
|
|
@subsection Labels Visible to Debugger
|
|
|
|
@command{g77} should output debugging information for statements labels,
|
|
for use by debuggers that know how to support them.
|
|
Same with weirder things like construct names.
|
|
It is not yet known if any debug formats or debuggers support these.
|
|
|
|
@node Disappointments
|
|
@section Disappointments and Misunderstandings
|
|
|
|
These problems are perhaps regrettable, but we don't know any practical
|
|
way around them for now.
|
|
|
|
@menu
|
|
* Mangling of Names:: @samp{SUBROUTINE FOO} is given
|
|
external name @samp{foo_}.
|
|
* Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
|
|
and @samp{SUBROUTINE FOO}.
|
|
* Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
|
|
@end menu
|
|
|
|
@node Mangling of Names
|
|
@subsection Mangling of Names in Source Code
|
|
@cindex naming issues
|
|
@cindex external names
|
|
@cindex common blocks
|
|
@cindex name space
|
|
@cindex underscore
|
|
|
|
The current external-interface design, which includes naming of
|
|
external procedures, COMMON blocks, and the library interface,
|
|
has various usability problems, including things like adding
|
|
underscores where not really necessary (and preventing easier
|
|
inter-language operability) and yet not providing complete
|
|
namespace freedom for user C code linked with Fortran apps (due
|
|
to the naming of functions in the library, among other things).
|
|
|
|
Project GNU should at least get all this ``right'' for systems
|
|
it fully controls, such as the Hurd, and provide defaults and
|
|
options for compatibility with existing systems and interoperability
|
|
with popular existing compilers.
|
|
|
|
@node Multiple Definitions of External Names
|
|
@subsection Multiple Definitions of External Names
|
|
@cindex block data
|
|
@cindex BLOCK DATA statement
|
|
@cindex statements, BLOCK DATA
|
|
@cindex @code{COMMON} statement
|
|
@cindex statements, @code{COMMON}
|
|
@cindex naming conflicts
|
|
|
|
@command{g77} doesn't allow a common block and an external procedure or
|
|
@code{BLOCK DATA} to have the same name.
|
|
Some systems allow this, but @command{g77} does not,
|
|
to be compatible with @command{f2c}.
|
|
|
|
@command{g77} could special-case the way it handles
|
|
@code{BLOCK DATA}, since it is not compatible with @command{f2c} in this
|
|
particular area (necessarily, since @command{g77} offers an
|
|
important feature here), but
|
|
it is likely that such special-casing would be very annoying to people
|
|
with programs that use @samp{EXTERNAL FOO}, with no other mention of
|
|
@samp{FOO} in the same program unit, to refer to external procedures, since
|
|
the result would be that @command{g77} would treat these references as requests to
|
|
force-load BLOCK DATA program units.
|
|
|
|
In that case, if @command{g77} modified
|
|
names of @code{BLOCK DATA} so they could have the same names as
|
|
@code{COMMON}, users
|
|
would find that their programs wouldn't link because the @samp{FOO} procedure
|
|
didn't have its name translated the same way.
|
|
|
|
(Strictly speaking,
|
|
@command{g77} could emit a null-but-externally-satisfying definition of
|
|
@samp{FOO} with its name transformed as if it had been a
|
|
@code{BLOCK DATA}, but that probably invites more trouble than it's
|
|
worth.)
|
|
|
|
@node Limitation on Implicit Declarations
|
|
@subsection Limitation on Implicit Declarations
|
|
@cindex IMPLICIT CHARACTER*(*) statement
|
|
@cindex statements, IMPLICIT CHARACTER*(*)
|
|
|
|
@command{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
|
|
This is not standard-conforming.
|
|
|
|
@node Non-bugs
|
|
@section Certain Changes We Don't Want to Make
|
|
|
|
This section lists changes that people frequently request, but which
|
|
we do not make because we think GNU Fortran is better without them.
|
|
|
|
@menu
|
|
* Backslash in Constants:: Why @samp{'\\'} is a constant that
|
|
is one, not two, characters long.
|
|
* Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
|
|
@samp{COMMON VAR}.
|
|
* Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
|
|
* Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
|
|
single-precision constant,
|
|
and might be interpreted as
|
|
@samp{9.435785} or similar.
|
|
* Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
|
|
* Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
|
|
not behave as expected.
|
|
@end menu
|
|
|
|
@node Backslash in Constants
|
|
@subsection Backslash in Constants
|
|
@cindex backslash
|
|
@cindex @command{f77} support
|
|
@cindex support, @command{f77}
|
|
|
|
In the opinion of many experienced Fortran users,
|
|
@option{-fno-backslash} should be the default, not @option{-fbackslash},
|
|
as currently set by @command{g77}.
|
|
|
|
First of all, you can always specify
|
|
@option{-fno-backslash} to turn off this processing.
|
|
|
|
Despite not being within the spirit (though apparently within the
|
|
letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to
|
|
@option{-fbackslash} because that is what most UNIX @command{f77} commands
|
|
default to, and apparently lots of code depends on this feature.
|
|
|
|
This is a particularly troubling issue.
|
|
The use of a C construct in the midst of Fortran code
|
|
is bad enough, worse when it makes existing Fortran
|
|
programs stop working (as happens when programs written
|
|
for non-UNIX systems are ported to UNIX systems with
|
|
compilers that provide the @option{-fbackslash} feature
|
|
as the default---sometimes with no option to turn it off).
|
|
|
|
The author of GNU Fortran wished, for reasons of linguistic
|
|
purity, to make @option{-fno-backslash} the default for GNU
|
|
Fortran and thus require users of UNIX @command{f77} and @command{f2c}
|
|
to specify @option{-fbackslash} to get the UNIX behavior.
|
|
|
|
However, the realization that @command{g77} is intended as
|
|
a replacement for @emph{UNIX} @command{f77}, caused the author
|
|
to choose to make @command{g77} as compatible with
|
|
@command{f77} as feasible, which meant making @option{-fbackslash}
|
|
the default.
|
|
|
|
The primary focus on compatibility is at the source-code
|
|
level, and the question became ``What will users expect
|
|
a replacement for @command{f77} to do, by default?''
|
|
Although at least one UNIX @command{f77} does not provide
|
|
@option{-fbackslash} as a default, it appears that
|
|
the majority of them do, which suggests that
|
|
the majority of code that is compiled by UNIX @command{f77}
|
|
compilers expects @option{-fbackslash} to be the default.
|
|
|
|
It is probably the case that more code exists
|
|
that would @emph{not} work with @option{-fbackslash}
|
|
in force than code that requires it be in force.
|
|
|
|
However, most of @emph{that} code is not being compiled
|
|
with @command{f77},
|
|
and when it is, new build procedures (shell scripts,
|
|
makefiles, and so on) must be set up anyway so that
|
|
they work under UNIX.
|
|
That makes a much more natural and safe opportunity for
|
|
non-UNIX users to adapt their build procedures for
|
|
@command{g77}'s default of @option{-fbackslash} than would
|
|
exist for the majority of UNIX @command{f77} users who
|
|
would have to modify existing, working build procedures
|
|
to explicitly specify @option{-fbackslash} if that was
|
|
not the default.
|
|
|
|
One suggestion has been to configure the default for
|
|
@option{-fbackslash} (and perhaps other options as well)
|
|
based on the configuration of @command{g77}.
|
|
|
|
This is technically quite straightforward, but will be avoided
|
|
even in cases where not configuring defaults to be
|
|
dependent on a particular configuration greatly inconveniences
|
|
some users of legacy code.
|
|
|
|
Many users appreciate the GNU compilers because they provide an
|
|
environment that is uniform across machines.
|
|
These users would be
|
|
inconvenienced if the compiler treated things like the
|
|
format of the source code differently on certain machines.
|
|
|
|
Occasionally users write programs intended only for a particular machine
|
|
type.
|
|
On these occasions, the users would benefit if the GNU Fortran compiler
|
|
were to support by default the same dialect as the other compilers on
|
|
that machine.
|
|
But such applications are rare.
|
|
And users writing a
|
|
program to run on more than one type of machine cannot possibly benefit
|
|
from this kind of compatibility.
|
|
(This is consistent with the design goals for @command{gcc}.
|
|
To change them for @command{g77}, you must first change them
|
|
for @command{gcc}.
|
|
Do not ask the maintainers of @command{g77} to do this for you,
|
|
or to disassociate @command{g77} from the widely understood, if
|
|
not widely agreed-upon, goals for GNU compilers in general.)
|
|
|
|
This is why GNU Fortran does and will treat backslashes in the same
|
|
fashion on all types of machines (by default).
|
|
@xref{Direction of Language Development}, for more information on
|
|
this overall philosophy guiding the development of the GNU Fortran
|
|
language.
|
|
|
|
Of course, users strongly concerned about portability should indicate
|
|
explicitly in their build procedures which options are expected
|
|
by their source code, or write source code that has as few such
|
|
expectations as possible.
|
|
|
|
For example, avoid writing code that depends on backslash (@samp{\})
|
|
being interpreted either way in particular, such as by
|
|
starting a program unit with:
|
|
|
|
@smallexample
|
|
CHARACTER BACKSL
|
|
PARAMETER (BACKSL = '\\')
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Then, use concatenation of @samp{BACKSL} anyplace a backslash
|
|
is desired.
|
|
In this way, users can write programs which have the same meaning
|
|
in many Fortran dialects.
|
|
|
|
(However, this technique does not work for Hollerith constants---which
|
|
is just as well, since the only generally portable uses for Hollerith
|
|
constants are in places where character constants can and should
|
|
be used instead, for readability.)
|
|
|
|
@node Initializing Before Specifying
|
|
@subsection Initializing Before Specifying
|
|
@cindex initialization, statement placement
|
|
@cindex placing initialization statements
|
|
|
|
@command{g77} does not allow @samp{DATA VAR/1/} to appear in the
|
|
source code before @samp{COMMON VAR},
|
|
@samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
|
|
In general, @command{g77} requires initialization of a variable
|
|
or array to be specified @emph{after} all other specifications
|
|
of attributes (type, size, placement, and so on) of that variable
|
|
or array are specified (though @emph{confirmation} of data type is
|
|
permitted).
|
|
|
|
It is @emph{possible} @command{g77} will someday allow all of this,
|
|
even though it is not allowed by the FORTRAN 77 standard.
|
|
|
|
Then again, maybe it is better to have
|
|
@command{g77} always require placement of @code{DATA}
|
|
so that it can possibly immediately write constants
|
|
to the output file, thus saving time and space.
|
|
|
|
That is, @samp{DATA A/1000000*1/} should perhaps always
|
|
be immediately writable to canonical assembler, unless it's already known
|
|
to be in a @code{COMMON} area following as-yet-uninitialized stuff,
|
|
and to do this it cannot be followed by @samp{COMMON A}.
|
|
|
|
@node Context-Sensitive Intrinsicness
|
|
@subsection Context-Sensitive Intrinsicness
|
|
@cindex intrinsics, context-sensitive
|
|
@cindex context-sensitive intrinsics
|
|
|
|
@command{g77} treats procedure references to @emph{possible} intrinsic
|
|
names as always enabling their intrinsic nature, regardless of
|
|
whether the @emph{form} of the reference is valid for that
|
|
intrinsic.
|
|
|
|
For example, @samp{CALL SQRT} is interpreted by @command{g77} as
|
|
an invalid reference to the @code{SQRT} intrinsic function,
|
|
because the reference is a subroutine invocation.
|
|
|
|
First, @command{g77} recognizes the statement @samp{CALL SQRT}
|
|
as a reference to a @emph{procedure} named @samp{SQRT}, not
|
|
to a @emph{variable} with that name (as it would for a statement
|
|
such as @samp{V = SQRT}).
|
|
|
|
Next, @command{g77} establishes that, in the program unit being compiled,
|
|
@code{SQRT} is an intrinsic---not a subroutine that
|
|
happens to have the same name as an intrinsic (as would be
|
|
the case if, for example, @samp{EXTERNAL SQRT} was present).
|
|
|
|
Finally, @command{g77} recognizes that the @emph{form} of the
|
|
reference is invalid for that particular intrinsic.
|
|
That is, it recognizes that it is invalid for an intrinsic
|
|
@emph{function}, such as @code{SQRT}, to be invoked as
|
|
a @emph{subroutine}.
|
|
|
|
At that point, @command{g77} issues a diagnostic.
|
|
|
|
Some users claim that it is ``obvious'' that @samp{CALL SQRT}
|
|
references an external subroutine of their own, not an
|
|
intrinsic function.
|
|
|
|
However, @command{g77} knows about intrinsic
|
|
subroutines, not just functions, and is able to support both having
|
|
the same names, for example.
|
|
|
|
As a result of this, @command{g77} rejects calls
|
|
to intrinsics that are not subroutines, and function invocations
|
|
of intrinsics that are not functions, just as it (and most compilers)
|
|
rejects invocations of intrinsics with the wrong number (or types)
|
|
of arguments.
|
|
|
|
So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
|
|
a user-written subroutine named @samp{SQRT}.
|
|
|
|
@node Context-Sensitive Constants
|
|
@subsection Context-Sensitive Constants
|
|
@cindex constants, context-sensitive
|
|
@cindex context-sensitive constants
|
|
|
|
@command{g77} does not use context to determine the types of
|
|
constants or named constants (@code{PARAMETER}), except
|
|
for (non-standard) typeless constants such as @samp{'123'O}.
|
|
|
|
For example, consider the following statement:
|
|
|
|
@smallexample
|
|
PRINT *, 9.435784839284958 * 2D0
|
|
@end smallexample
|
|
|
|
@noindent
|
|
@command{g77} will interpret the (truncated) constant
|
|
@samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
|
|
constant, because the suffix @code{D0} is not specified.
|
|
|
|
As a result, the output of the above statement when
|
|
compiled by @command{g77} will appear to have ``less precision''
|
|
than when compiled by other compilers.
|
|
|
|
In these and other cases, some compilers detect the
|
|
fact that a single-precision constant is used in
|
|
a double-precision context and therefore interpret the
|
|
single-precision constant as if it was @emph{explicitly}
|
|
specified as a double-precision constant.
|
|
(This has the effect of appending @emph{decimal}, not
|
|
@emph{binary}, zeros to the fractional part of the
|
|
number---producing different computational results.)
|
|
|
|
The reason this misfeature is dangerous is that a slight,
|
|
apparently innocuous change to the source code can change
|
|
the computational results.
|
|
Consider:
|
|
|
|
@smallexample
|
|
REAL ALMOST, CLOSE
|
|
DOUBLE PRECISION FIVE
|
|
PARAMETER (ALMOST = 5.000000000001)
|
|
FIVE = 5
|
|
CLOSE = 5.000000000001
|
|
PRINT *, 5.000000000001 - FIVE
|
|
PRINT *, ALMOST - FIVE
|
|
PRINT *, CLOSE - FIVE
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
Running the above program should
|
|
result in the same value being
|
|
printed three times.
|
|
With @command{g77} as the compiler,
|
|
it does.
|
|
|
|
However, compiled by many other compilers,
|
|
running the above program would print
|
|
two or three distinct values, because
|
|
in two or three of the statements, the
|
|
constant @samp{5.000000000001}, which
|
|
on most systems is exactly equal to @samp{5.}
|
|
when interpreted as a single-precision constant,
|
|
is instead interpreted as a double-precision
|
|
constant, preserving the represented
|
|
precision.
|
|
However, this ``clever'' promotion of
|
|
type does not extend to variables or,
|
|
in some compilers, to named constants.
|
|
|
|
Since programmers often are encouraged to replace manifest
|
|
constants or permanently-assigned variables with named
|
|
constants (@code{PARAMETER} in Fortran), and might need
|
|
to replace some constants with variables having the same
|
|
values for pertinent portions of code,
|
|
it is important that compilers treat code so modified in the
|
|
same way so that the results of such programs are the same.
|
|
@command{g77} helps in this regard by treating constants just
|
|
the same as variables in terms of determining their types
|
|
in a context-independent way.
|
|
|
|
Still, there is a lot of existing Fortran code that has
|
|
been written to depend on the way other compilers freely
|
|
interpret constants' types based on context, so anything
|
|
@command{g77} can do to help flag cases of this in such code
|
|
could be very helpful.
|
|
|
|
@node Equivalence Versus Equality
|
|
@subsection Equivalence Versus Equality
|
|
@cindex .EQV., with integer operands
|
|
@cindex comparing logical expressions
|
|
@cindex logical expressions, comparing
|
|
|
|
Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
|
|
is not supported, except via @option{-fugly-logint}, which is not
|
|
recommended except for legacy code (where the behavior expected
|
|
by the @emph{code} is assumed).
|
|
|
|
Legacy code should be changed, as resources permit, to use @code{.EQV.}
|
|
and @code{.NEQV.} instead, as these are permitted by the various
|
|
Fortran standards.
|
|
|
|
New code should never be written expecting @code{.EQ.} or @code{.NE.}
|
|
to work if either of its operands is @code{LOGICAL}.
|
|
|
|
The problem with supporting this ``feature'' is that there is
|
|
unlikely to be consensus on how it works, as illustrated by the
|
|
following sample program:
|
|
|
|
@smallexample
|
|
LOGICAL L,M,N
|
|
DATA L,M,N /3*.FALSE./
|
|
IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
|
|
END
|
|
@end smallexample
|
|
|
|
The issue raised by the above sample program is: what is the
|
|
precedence of @code{.EQ.} (and @code{.NE.}) when applied to
|
|
@code{LOGICAL} operands?
|
|
|
|
Some programmers will argue that it is the same as the precedence
|
|
for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
|
|
operands.
|
|
By this interpretation, the subexpression @samp{M.EQ.N} must be
|
|
evaluated first in the above program, resulting in a program that,
|
|
when run, does not execute the @code{PRINT} statement.
|
|
|
|
Other programmers will argue that the precedence is the same as
|
|
the precedence for @code{.EQV.}, which is restricted by the standards
|
|
to @code{LOGICAL} operands.
|
|
By this interpretation, the subexpression @samp{L.AND.M} must be
|
|
evaluated first, resulting in a program that @emph{does} execute
|
|
the @code{PRINT} statement.
|
|
|
|
Assigning arbitrary semantic interpretations to syntactic expressions
|
|
that might legitimately have more than one ``obvious'' interpretation
|
|
is generally unwise.
|
|
|
|
The creators of the various Fortran standards have done a good job
|
|
in this case, requiring a distinct set of operators (which have their
|
|
own distinct precedence) to compare @code{LOGICAL} operands.
|
|
This requirement results in expression syntax with more certain
|
|
precedence (without requiring substantial context), making it easier
|
|
for programmers to read existing code.
|
|
@command{g77} will avoid muddying up elements of the Fortran language
|
|
that were well-designed in the first place.
|
|
|
|
(Ask C programmers about the precedence of expressions such as
|
|
@samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
|
|
you, without knowing more context, whether the @samp{&} and @samp{-}
|
|
operators are infix (binary) or unary!)
|
|
|
|
Most dangerous of all is the fact that,
|
|
even assuming consensus on its meaning,
|
|
an expression like @samp{L.AND.M.EQ.N},
|
|
if it is the result of a typographical error,
|
|
doesn't @emph{look} like it has such a typo.
|
|
Even experienced Fortran programmers would not likely notice that
|
|
@samp{L.AND.M.EQV.N} was, in fact, intended.
|
|
|
|
So, this is a prime example of a circumstance in which
|
|
a quality compiler diagnoses the code,
|
|
instead of leaving it up to someone debugging it
|
|
to know to turn on special compiler options
|
|
that might diagnose it.
|
|
|
|
@node Order of Side Effects
|
|
@subsection Order of Side Effects
|
|
@cindex side effects, order of evaluation
|
|
@cindex order of evaluation, side effects
|
|
|
|
@command{g77} does not necessarily produce code that, when run, performs
|
|
side effects (such as those performed by function invocations)
|
|
in the same order as in some other compiler---or even in the same
|
|
order as another version, port, or invocation (using different
|
|
command-line options) of @command{g77}.
|
|
|
|
It is never safe to depend on the order of evaluation of side effects.
|
|
For example, an expression like this may very well behave differently
|
|
from one compiler to another:
|
|
|
|
@smallexample
|
|
J = IFUNC() - IFUNC()
|
|
@end smallexample
|
|
|
|
@noindent
|
|
There is no guarantee that @samp{IFUNC} will be evaluated in any particular
|
|
order.
|
|
Either invocation might happen first.
|
|
If @samp{IFUNC} returns 5 the first time it is invoked, and
|
|
returns 12 the second time, @samp{J} might end up with the
|
|
value @samp{7}, or it might end up with @samp{-7}.
|
|
|
|
Generally, in Fortran, procedures with side-effects intended to
|
|
be visible to the caller are best designed as @emph{subroutines},
|
|
not functions.
|
|
Examples of such side-effects include:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The generation of random numbers
|
|
that are intended to influence return values.
|
|
|
|
@item
|
|
Performing I/O
|
|
(other than internal I/O to local variables).
|
|
|
|
@item
|
|
Updating information in common blocks.
|
|
@end itemize
|
|
|
|
An example of a side-effect that is not intended to be visible
|
|
to the caller is a function that maintains a cache of recently
|
|
calculated results, intended solely to speed repeated invocations
|
|
of the function with identical arguments.
|
|
Such a function can be safely used in expressions, because
|
|
if the compiler optimizes away one or more calls to the
|
|
function, operation of the program is unaffected (aside
|
|
from being speeded up).
|
|
|
|
@node Warnings and Errors
|
|
@section Warning Messages and Error Messages
|
|
|
|
@cindex error messages
|
|
@cindex warnings vs errors
|
|
@cindex messages, warning and error
|
|
The GNU compiler can produce two kinds of diagnostics: errors and
|
|
warnings.
|
|
Each kind has a different purpose:
|
|
|
|
@itemize @w{}
|
|
@item
|
|
@emph{Errors} report problems that make it impossible to compile your
|
|
program.
|
|
GNU Fortran reports errors with the source file name, line
|
|
number, and column within the line where the problem is apparent.
|
|
|
|
@item
|
|
@emph{Warnings} report other unusual conditions in your code that
|
|
@emph{might} indicate a problem, although compilation can (and does)
|
|
proceed.
|
|
Warning messages also report the source file name, line number,
|
|
and column information,
|
|
but include the text @samp{warning:} to distinguish them
|
|
from error messages.
|
|
@end itemize
|
|
|
|
Warnings might indicate danger points where you should check to make sure
|
|
that your program really does what you intend; or the use of obsolete
|
|
features; or the use of nonstandard features of GNU Fortran.
|
|
Many warnings are issued only if you ask for them, with one of the
|
|
@option{-W} options (for instance, @option{-Wall} requests a variety of
|
|
useful warnings).
|
|
|
|
@emph{Note:} Currently, the text of the line and a pointer to the column
|
|
is printed in most @command{g77} diagnostics.
|
|
|
|
@xref{Warning Options,,Options to Request or Suppress Warnings}, for
|
|
more detail on these and related command-line options.
|
|
|
|
@node Open Questions
|
|
@chapter Open Questions
|
|
|
|
Please consider offering useful answers to these questions!
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@code{LOC()} and other intrinsics are probably somewhat misclassified.
|
|
Is the a need for more precise classification of intrinsics, and if so,
|
|
what are the appropriate groupings?
|
|
Is there a need to individually
|
|
enable/disable/delete/hide intrinsics from the command line?
|
|
@end itemize
|
|
|
|
@node Bugs
|
|
@chapter Reporting Bugs
|
|
@cindex bugs
|
|
@cindex reporting bugs
|
|
|
|
Your bug reports play an essential role in making GNU Fortran reliable.
|
|
|
|
When you encounter a problem, the first thing to do is to see if it is
|
|
already known.
|
|
@xref{Trouble}.
|
|
If it isn't known, then you should report the problem.
|
|
|
|
Reporting a bug might help you by bringing a solution to your problem, or
|
|
it might not.
|
|
(If it does not, look in the service directory; see
|
|
@ref{Service}.)
|
|
In any case, the principal function of a bug report is
|
|
to help the entire community by making the next version of GNU Fortran work
|
|
better.
|
|
Bug reports are your contribution to the maintenance of GNU Fortran.
|
|
|
|
Since the maintainers are very overloaded, we cannot respond to every
|
|
bug report.
|
|
However, if the bug has not been fixed, we are likely to
|
|
send you a patch and ask you to tell us whether it works.
|
|
|
|
In order for a bug report to serve its purpose, you must include the
|
|
information that makes for fixing the bug.
|
|
|
|
@menu
|
|
* Criteria: Bug Criteria. Have you really found a bug?
|
|
* Where: Bug Lists. Where to send your bug report.
|
|
* Reporting: Bug Reporting. How to report a bug effectively.
|
|
@end menu
|
|
|
|
@xref{Trouble,,Known Causes of Trouble with GNU Fortran},
|
|
for information on problems we already know about.
|
|
|
|
@xref{Service,,How To Get Help with GNU Fortran},
|
|
for information on where to ask for help.
|
|
|
|
@node Bug Criteria
|
|
@section Have You Found a Bug?
|
|
@cindex bug criteria
|
|
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
|
|
|
@itemize @bullet
|
|
@cindex fatal signal
|
|
@cindex core dump
|
|
@item
|
|
If the compiler gets a fatal signal, for any input whatever, that is a
|
|
compiler bug.
|
|
Reliable compilers never crash---they just remain obsolete.
|
|
|
|
@cindex invalid assembly code
|
|
@cindex assembly code, invalid
|
|
@item
|
|
If the compiler produces invalid assembly code, for any input whatever,
|
|
@c (except an @code{asm} statement),
|
|
that is a compiler bug, unless the
|
|
compiler reports errors (not just warnings) which would ordinarily
|
|
prevent the assembler from being run.
|
|
|
|
@cindex undefined behavior
|
|
@cindex undefined function value
|
|
@item
|
|
If the compiler produces valid assembly code that does not correctly
|
|
execute the input source code, that is a compiler bug.
|
|
|
|
However, you must double-check to make sure, because you might have run
|
|
into an incompatibility between GNU Fortran and traditional Fortran.
|
|
@c (@pxref{Incompatibilities}).
|
|
These incompatibilities might be considered
|
|
bugs, but they are inescapable consequences of valuable features.
|
|
|
|
Or you might have a program whose behavior is undefined, which happened
|
|
by chance to give the desired results with another Fortran compiler.
|
|
It is best to check the relevant Fortran standard thoroughly if
|
|
it is possible that the program indeed does something undefined.
|
|
|
|
After you have localized the error to a single source line, it should
|
|
be easy to check for these things.
|
|
If your program is correct and well defined, you have found
|
|
a compiler bug.
|
|
|
|
It might help if, in your submission, you identified the specific
|
|
language in the relevant Fortran standard that specifies the
|
|
desired behavior, if it isn't likely to be obvious and agreed-upon
|
|
by all Fortran users.
|
|
|
|
@item
|
|
If the compiler produces an error message for valid input, that is a
|
|
compiler bug.
|
|
|
|
@cindex invalid input
|
|
@item
|
|
If the compiler does not produce an error message for invalid input,
|
|
that is a compiler bug.
|
|
However, you should note that your idea of
|
|
``invalid input'' might be someone else's idea
|
|
of ``an extension'' or ``support for traditional practice''.
|
|
|
|
@item
|
|
If you are an experienced user of Fortran compilers, your suggestions
|
|
for improvement of GNU Fortran are welcome in any case.
|
|
@end itemize
|
|
|
|
Many, perhaps most, bug reports against @command{g77} turn out to
|
|
be bugs in the user's code.
|
|
While we find such bug reports educational, they sometimes take
|
|
a considerable amount of time to track down or at least respond
|
|
to---time we could be spending making @command{g77}, not some user's
|
|
code, better.
|
|
|
|
Some steps you can take to verify that the bug is not certainly
|
|
in the code you're compiling with @command{g77}:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Compile your code using the @command{g77} options @samp{-W -Wall -O}.
|
|
These options enable many useful warning; the @option{-O} option
|
|
enables flow analysis that enables the uninitialized-variable
|
|
warning.
|
|
|
|
If you investigate the warnings and find evidence of possible bugs
|
|
in your code, fix them first and retry @command{g77}.
|
|
|
|
@item
|
|
Compile your code using the @command{g77} options @option{-finit-local-zero},
|
|
@option{-fno-automatic}, @option{-ffloat-store}, and various
|
|
combinations thereof.
|
|
|
|
If your code works with any of these combinations, that is not
|
|
proof that the bug isn't in @command{g77}---a @command{g77} bug exposed
|
|
by your code might simply be avoided, or have a different, more subtle
|
|
effect, when different options are used---but it can be a
|
|
strong indicator that your code is making unwarranted assumptions
|
|
about the Fortran dialect and/or underlying machine it is
|
|
being compiled and run on.
|
|
|
|
@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
|
|
for information on the @option{-fno-automatic} and
|
|
@option{-finit-local-zero} options and how to convert
|
|
their use into selective changes in your own code.
|
|
|
|
@item
|
|
@pindex ftnchek
|
|
Validate your code with @command{ftnchek} or a similar code-checking
|
|
tool.
|
|
@command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
|
|
or @uref{ftp://ftp.dsm.fordham.edu}.
|
|
|
|
@pindex make
|
|
@cindex Makefile example
|
|
Here are some sample @file{Makefile} rules using @command{ftnchek}
|
|
``project'' files to do cross-file checking and @command{sfmakedepend}
|
|
(from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
|
|
to maintain dependencies automatically.
|
|
These assume the use of GNU @command{make}.
|
|
|
|
@smallexample
|
|
# Dummy suffix for ftnchek targets:
|
|
.SUFFIXES: .chek
|
|
.PHONY: chekall
|
|
|
|
# How to compile .f files (for implicit rule):
|
|
FC = g77
|
|
# Assume `include' directory:
|
|
FFLAGS = -Iinclude -g -O -Wall
|
|
|
|
# Flags for ftnchek:
|
|
CHEK1 = -array=0 -include=includes -noarray
|
|
CHEK2 = -nonovice -usage=1 -notruncation
|
|
CHEKFLAGS = $(CHEK1) $(CHEK2)
|
|
|
|
# Run ftnchek with all the .prj files except the one corresponding
|
|
# to the target's root:
|
|
%.chek : %.f ; \
|
|
ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
|
|
-noextern -library $<
|
|
|
|
# Derive a project file from a source file:
|
|
%.prj : %.f ; \
|
|
ftnchek $(CHEKFLAGS) -noextern -project -library $<
|
|
|
|
# The list of objects is assumed to be in variable OBJS.
|
|
# Sources corresponding to the objects:
|
|
SRCS = $(OBJS:%.o=%.f)
|
|
# ftnchek project files:
|
|
PRJS = $(OBJS:%.o=%.prj)
|
|
|
|
# Build the program
|
|
prog: $(OBJS) ; \
|
|
$(FC) -o $@ $(OBJS)
|
|
|
|
chekall: $(PRJS) ; \
|
|
ftnchek $(CHEKFLAGS) $(PRJS)
|
|
|
|
prjs: $(PRJS)
|
|
|
|
# For Emacs M-x find-tag:
|
|
TAGS: $(SRCS) ; \
|
|
etags $(SRCS)
|
|
|
|
# Rebuild dependencies:
|
|
depend: ; \
|
|
sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
|
|
@end smallexample
|
|
|
|
@item
|
|
Try your code out using other Fortran compilers, such as @command{f2c}.
|
|
If it does not work on at least one other compiler (assuming the
|
|
compiler supports the features the code needs), that is a strong
|
|
indicator of a bug in the code.
|
|
|
|
However, even if your code works on many compilers @emph{except}
|
|
@command{g77}, that does @emph{not} mean the bug is in @command{g77}.
|
|
It might mean the bug is in your code, and that @command{g77} simply
|
|
exposes it more readily than other compilers.
|
|
@end itemize
|
|
|
|
@node Bug Lists
|
|
@section Where to Report Bugs
|
|
@cindex bug report mailing lists
|
|
@kindex @value{email-bugs}
|
|
Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
|
|
|
|
Often people think of posting bug reports to a newsgroup instead of
|
|
mailing them.
|
|
This sometimes appears to work, but it has one problem which can be
|
|
crucial: a newsgroup posting does not contain a mail path back to the
|
|
sender.
|
|
Thus, if maintainers need more information, they might be unable
|
|
to reach you. For this reason, you should always send bug reports by
|
|
mail to the proper mailing list.
|
|
|
|
As a last resort, send bug reports on paper to:
|
|
|
|
@example
|
|
GNU Compiler Bugs
|
|
Free Software Foundation
|
|
59 Temple Place - Suite 330
|
|
Boston, MA 02111-1307, USA
|
|
@end example
|
|
|
|
@node Bug Reporting
|
|
@section How to Report Bugs
|
|
@cindex compiler bugs, reporting
|
|
|
|
The fundamental principle of reporting bugs usefully is this:
|
|
@strong{report all the facts}.
|
|
If you are not sure whether to state a
|
|
fact or leave it out, state it!
|
|
|
|
Often people omit facts because they think they know what causes the
|
|
problem and they conclude that some details don't matter.
|
|
Thus, you might
|
|
assume that the name of the variable you use in an example does not matter.
|
|
Well, probably it doesn't, but one cannot be sure.
|
|
Perhaps the bug is a
|
|
stray memory reference which happens to fetch from the location where that
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
|
of that location would fool the compiler into doing the right thing despite
|
|
the bug.
|
|
Play it safe and give a specific, complete example.
|
|
That is the
|
|
easiest thing for you to do, and the most helpful.
|
|
|
|
Keep in mind that the purpose of a bug report is to enable someone to
|
|
fix the bug if it is not known.
|
|
It isn't very important what happens if
|
|
the bug is already known.
|
|
Therefore, always write your bug reports on
|
|
the assumption that the bug is not known.
|
|
|
|
Sometimes people give a few sketchy facts and ask, ``Does this ring a
|
|
bell?''
|
|
This cannot help us fix a bug, so it is rarely helpful.
|
|
We respond by asking for enough details to enable us to investigate.
|
|
You might as well expedite matters by sending them to begin with.
|
|
(Besides, there are enough bells ringing around here as it is.)
|
|
|
|
Try to make your bug report self-contained.
|
|
If we have to ask you for
|
|
more information, it is best if you include all the previous information
|
|
in your response, as well as the information that was missing.
|
|
|
|
Please report each bug in a separate message.
|
|
This makes it easier for
|
|
us to track which bugs have been fixed and to forward your bugs reports
|
|
to the appropriate maintainer.
|
|
|
|
Do not compress and encode any part of your bug report using programs
|
|
such as @file{uuencode}.
|
|
If you do so it will slow down the processing
|
|
of your bug.
|
|
If you must submit multiple large files, use @file{shar},
|
|
which allows us to read your message without having to run any
|
|
decompression programs.
|
|
|
|
(As a special exception for GNU Fortran bug-reporting, at least
|
|
for now, if you are sending more than a few lines of code, if
|
|
your program's source file format contains ``interesting'' things
|
|
like trailing spaces or strange characters, or if you need to
|
|
include binary data files, it is acceptable to put all the
|
|
files together in a @command{tar} archive, and, whether you need to
|
|
do that, it is acceptable to then compress the single file (@command{tar}
|
|
archive or source file)
|
|
using @command{gzip} and encode it via @command{uuencode}.
|
|
Do not use any MIME stuff---the current maintainer can't decode this.
|
|
Using @command{compress} instead of @command{gzip} is acceptable, assuming
|
|
you have licensed the use of the patented algorithm in
|
|
@command{compress} from Unisys.)
|
|
|
|
To enable someone to investigate the bug, you should include all these
|
|
things:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The version of GNU Fortran.
|
|
You can get this by running @command{g77} with the @option{-v} option.
|
|
(Ignore any error messages that might be displayed
|
|
when the linker is run.)
|
|
|
|
Without this, we won't know whether there is any point in looking for
|
|
the bug in the current version of GNU Fortran.
|
|
|
|
@item
|
|
@cindex preprocessor
|
|
@cindex cpp program
|
|
@cindex programs, cpp
|
|
@pindex cpp
|
|
A complete input file that will reproduce the bug.
|
|
|
|
If your source file(s) require preprocessing
|
|
(for example, their names have suffixes like
|
|
@samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
|
|
and the bug is in the compiler proper (@file{f771})
|
|
or in a subsequent phase of processing,
|
|
run your source file through the C preprocessor
|
|
by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
|
|
Then, include the contents of @var{newfile} in the bug report.
|
|
(When you do this, use the same preprocessor options---such as
|
|
@option{-I}, @option{-D}, and @option{-U}---that you used in actual
|
|
compilation.)
|
|
|
|
A single statement is not enough of an example.
|
|
In order to compile it,
|
|
it must be embedded in a complete file of compiler input.
|
|
The bug might depend on the details of how this is done.
|
|
|
|
Without a real example one can compile,
|
|
all anyone can do about your bug report is wish you luck.
|
|
It would be futile to try to guess how to provoke the bug.
|
|
For example, bugs in register allocation and reloading
|
|
can depend on every little detail of the source and include files
|
|
that trigger them.
|
|
|
|
@item
|
|
@cindex included files
|
|
@cindex INCLUDE directive
|
|
@cindex directive, INCLUDE
|
|
@cindex #include directive
|
|
@cindex directive, #include
|
|
Note that you should include with your bug report any files
|
|
included by the source file
|
|
(via the @code{#include} or @code{INCLUDE} directive)
|
|
that you send, and any files they include, and so on.
|
|
|
|
It is not necessary to replace
|
|
the @code{#include} and @code{INCLUDE} directives
|
|
with the actual files in the version of the source file that
|
|
you send, but it might make submitting the bug report easier
|
|
in the end.
|
|
However, be sure to @emph{reproduce} the bug using the @emph{exact}
|
|
version of the source material you submit, to avoid wild-goose
|
|
chases.
|
|
|
|
@item
|
|
The command arguments you gave GNU Fortran to compile that example
|
|
and observe the bug. For example, did you use @option{-O}? To guarantee
|
|
you won't omit something important, list all the options.
|
|
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
|
and then we would not encounter the bug.
|
|
|
|
@item
|
|
The type of machine you are using, and the operating system name and
|
|
version number.
|
|
(Much of this information is printed by @samp{g77 -v}---if you
|
|
include that, send along any additional info you have that you
|
|
don't see clearly represented in that output.)
|
|
|
|
@item
|
|
The operands you gave to the @command{configure} command when you installed
|
|
the compiler.
|
|
|
|
@item
|
|
A complete list of any modifications you have made to the compiler
|
|
source. (We don't promise to investigate the bug unless it happens in
|
|
an unmodified compiler. But if you've made modifications and don't tell
|
|
us, then you are sending us on a wild-goose chase.)
|
|
|
|
Be precise about these changes. A description in English is not
|
|
enough---send a context diff for them.
|
|
|
|
Adding files of your own (such as a machine description for a machine we
|
|
don't support) is a modification of the compiler source.
|
|
|
|
@item
|
|
Details of any other deviations from the standard procedure for installing
|
|
GNU Fortran.
|
|
|
|
@item
|
|
A description of what behavior you observe that you believe is
|
|
incorrect. For example, ``The compiler gets a fatal signal,'' or,
|
|
``The assembler instruction at line 208 in the output is incorrect.''
|
|
|
|
Of course, if the bug is that the compiler gets a fatal signal, then one
|
|
can't miss it. But if the bug is incorrect output, the maintainer might
|
|
not notice unless it is glaringly wrong. None of us has time to study
|
|
all the assembler code from a 50-line Fortran program just on the chance that
|
|
one instruction might be wrong. We need @emph{you} to do this part!
|
|
|
|
Even if the problem you experience is a fatal signal, you should still
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
|
copy of the compiler is out of synch, or you have encountered a bug in
|
|
the C library on your system. (This has happened!) Your copy might
|
|
crash and the copy here would not. If you @i{said} to expect a crash,
|
|
then when the compiler here fails to crash, we would know that the bug
|
|
was not happening. If you don't say to expect a crash, then we would
|
|
not know whether the bug was happening. We would not be able to draw
|
|
any conclusion from our observations.
|
|
|
|
If the problem is a diagnostic when building GNU Fortran with some other
|
|
compiler, say whether it is a warning or an error.
|
|
|
|
Often the observed symptom is incorrect output when your program is run.
|
|
Sad to say, this is not enough information unless the program is short
|
|
and simple. None of us has time to study a large program to figure out
|
|
how it would work if compiled correctly, much less which line of it was
|
|
compiled wrong. So you will have to do that. Tell us which source line
|
|
it is, and what incorrect result happens when that line is executed. A
|
|
person who understands the program can find this as easily as finding a
|
|
bug in the program itself.
|
|
|
|
@item
|
|
If you send examples of assembler code output from GNU Fortran,
|
|
please use @option{-g} when you make them. The debugging information
|
|
includes source line numbers which are essential for correlating the
|
|
output with the input.
|
|
|
|
@item
|
|
If you wish to mention something in the GNU Fortran source, refer to it by
|
|
context, not by line number.
|
|
|
|
The line numbers in the development sources don't match those in your
|
|
sources. Your line numbers would convey no convenient information to the
|
|
maintainers.
|
|
|
|
@item
|
|
Additional information from a debugger might enable someone to find a
|
|
problem on a machine which he does not have available. However, you
|
|
need to think when you collect this information if you want it to have
|
|
any chance of being useful.
|
|
|
|
@cindex backtrace for bug reports
|
|
For example, many people send just a backtrace, but that is never
|
|
useful by itself. A simple backtrace with arguments conveys little
|
|
about GNU Fortran because the compiler is largely data-driven; the same
|
|
functions are called over and over for different RTL insns, doing
|
|
different things depending on the details of the insn.
|
|
|
|
Most of the arguments listed in the backtrace are useless because they
|
|
are pointers to RTL list structure. The numeric values of the
|
|
pointers, which the debugger prints in the backtrace, have no
|
|
significance whatever; all that matters is the contents of the objects
|
|
they point to (and most of the contents are other such pointers).
|
|
|
|
In addition, most compiler passes consist of one or more loops that
|
|
scan the RTL insn sequence. The most vital piece of information about
|
|
such a loop---which insn it has reached---is usually in a local variable,
|
|
not in an argument.
|
|
|
|
@findex debug_rtx
|
|
What you need to provide in addition to a backtrace are the values of
|
|
the local variables for several stack frames up. When a local
|
|
variable or an argument is an RTX, first print its value and then use
|
|
the GDB command @command{pr} to print the RTL expression that it points
|
|
to. (If GDB doesn't run on your machine, use your debugger to call
|
|
the function @code{debug_rtx} with the RTX as an argument.) In
|
|
general, whenever a variable is a pointer, its value is no use
|
|
without the data it points to.
|
|
@end itemize
|
|
|
|
Here are some things that are not necessary:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
A description of the envelope of the bug.
|
|
|
|
Often people who encounter a bug spend a lot of time investigating
|
|
which changes to the input file will make the bug go away and which
|
|
changes will not affect it.
|
|
|
|
This is often time consuming and not very useful, because the way we
|
|
will find the bug is by running a single example under the debugger with
|
|
breakpoints, not by pure deduction from a series of examples. You might
|
|
as well save your time for something else.
|
|
|
|
Of course, if you can find a simpler example to report @emph{instead} of
|
|
the original one, that is a convenience. Errors in the output will be
|
|
easier to spot, running under the debugger will take less time, etc.
|
|
Most GNU Fortran bugs involve just one function, so the most straightforward
|
|
way to simplify an example is to delete all the function definitions
|
|
except the one where the bug occurs. Those earlier in the file may be
|
|
replaced by external declarations if the crucial function depends on
|
|
them. (Exception: inline functions might affect compilation of functions
|
|
defined later in the file.)
|
|
|
|
However, simplification is not vital; if you don't want to do this,
|
|
report the bug anyway and send the entire test case you used.
|
|
|
|
@item
|
|
In particular, some people insert conditionals @samp{#ifdef BUG} around
|
|
a statement which, if removed, makes the bug not happen. These are just
|
|
clutter; we won't pay any attention to them anyway. Besides, you should
|
|
send us preprocessor output, and that can't have conditionals.
|
|
|
|
@item
|
|
A patch for the bug.
|
|
|
|
A patch for the bug is useful if it is a good one. But don't omit the
|
|
necessary information, such as the test case, on the assumption that a
|
|
patch is all we need. We might see problems with your patch and decide
|
|
to fix the problem another way, or we might not understand it at all.
|
|
|
|
Sometimes with a program as complicated as GNU Fortran it is very hard to
|
|
construct an example that will make the program follow a certain path
|
|
through the code. If you don't send the example, we won't be able to
|
|
construct one, so we won't be able to verify that the bug is fixed.
|
|
|
|
And if we can't understand what bug you are trying to fix, or why your
|
|
patch should be an improvement, we won't install it. A test case will
|
|
help us to understand.
|
|
|
|
See @uref{http://gcc.gnu.org/contribute.html}
|
|
for guidelines on how to make it easy for us to
|
|
understand and install your patches.
|
|
|
|
@item
|
|
A guess about what the bug is or what it depends on.
|
|
|
|
Such guesses are usually wrong. Even the maintainer can't guess right
|
|
about such things without first using the debugger to find the facts.
|
|
|
|
@item
|
|
A core dump file.
|
|
|
|
We have no way of examining a core dump for your type of machine
|
|
unless we have an identical system---and if we do have one,
|
|
we should be able to reproduce the crash ourselves.
|
|
@end itemize
|
|
|
|
@node Service
|
|
@chapter How To Get Help with GNU Fortran
|
|
|
|
If you need help installing, using or changing GNU Fortran, there are two
|
|
ways to find it:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Look in the service directory for someone who might help you for a fee.
|
|
The service directory is found in the file named @file{SERVICE} in the
|
|
GNU CC distribution.
|
|
|
|
@item
|
|
Send a message to @email{@value{email-help}}.
|
|
@end itemize
|
|
|
|
@end ifset
|
|
@ifset INTERNALS
|
|
@node Adding Options
|
|
@chapter Adding Options
|
|
@cindex options, adding
|
|
@cindex adding options
|
|
|
|
To add a new command-line option to @command{g77}, first decide
|
|
what kind of option you wish to add.
|
|
Search the @command{g77} and @command{gcc} documentation for one
|
|
or more options that is most closely like the one you want to add
|
|
(in terms of what kind of effect it has, and so on) to
|
|
help clarify its nature.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
@emph{Fortran options} are options that apply only
|
|
when compiling Fortran programs.
|
|
They are accepted by @command{g77} and @command{gcc}, but
|
|
they apply only when compiling Fortran programs.
|
|
|
|
@item
|
|
@emph{Compiler options} are options that apply
|
|
when compiling most any kind of program.
|
|
@end itemize
|
|
|
|
@emph{Fortran options} are listed in the file
|
|
@file{@value{path-g77}/lang-options.h},
|
|
which is used during the build of @command{gcc} to
|
|
build a list of all options that are accepted by
|
|
at least one language's compiler.
|
|
This list goes into the @code{documented_lang_options} array
|
|
in @file{gcc/toplev.c}, which uses this array to
|
|
determine whether a particular option should be
|
|
offered to the linked-in front end for processing
|
|
by calling @code{lang_option_decode}, which, for
|
|
@command{g77}, is in @file{@value{path-g77}/com.c} and just
|
|
calls @code{ffe_decode_option}.
|
|
|
|
If the linked-in front end ``rejects'' a
|
|
particular option passed to it, @file{toplev.c}
|
|
just ignores the option, because @emph{some}
|
|
language's compiler is willing to accept it.
|
|
|
|
This allows commands like @samp{gcc -fno-asm foo.c bar.f}
|
|
to work, even though Fortran compilation does
|
|
not currently support the @option{-fno-asm} option;
|
|
even though the @code{f771} version of @code{lang_decode_option}
|
|
rejects @option{-fno-asm}, @file{toplev.c} doesn't
|
|
produce a diagnostic because some other language (C)
|
|
does accept it.
|
|
|
|
This also means that commands like
|
|
@samp{g77 -fno-asm foo.f} yield no diagnostics,
|
|
despite the fact that no phase of the command was
|
|
able to recognize and process @option{-fno-asm}---perhaps
|
|
a warning about this would be helpful if it were
|
|
possible.
|
|
|
|
Code that processes Fortran options is found in
|
|
@file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
|
|
This code needs to check positive and negative forms
|
|
of each option.
|
|
|
|
The defaults for Fortran options are set in their
|
|
global definitions, also found in @file{@value{path-g77}/top.c}.
|
|
Many of these defaults are actually macros defined
|
|
in @file{@value{path-g77}/target.h}, since they might be
|
|
machine-specific.
|
|
However, since, in practice, GNU compilers
|
|
should behave the same way on all configurations
|
|
(especially when it comes to language constructs),
|
|
the practice of setting defaults in @file{target.h}
|
|
is likely to be deprecated and, ultimately, stopped
|
|
in future versions of @command{g77}.
|
|
|
|
Accessor macros for Fortran options, used by code
|
|
in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
|
|
|
|
@emph{Compiler options} are listed in @file{gcc/toplev.c}
|
|
in the array @code{f_options}.
|
|
An option not listed in @code{lang_options} is
|
|
looked up in @code{f_options} and handled from there.
|
|
|
|
The defaults for compiler options are set in the
|
|
global definitions for the corresponding variables,
|
|
some of which are in @file{gcc/toplev.c}.
|
|
|
|
You can set different defaults for @emph{Fortran-oriented}
|
|
or @emph{Fortran-reticent} compiler options by changing
|
|
the source code of @command{g77} and rebuilding.
|
|
How to do this depends on the version of @command{g77}:
|
|
|
|
@table @code
|
|
@item G77 0.5.24 (EGCS 1.1)
|
|
@itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
|
|
Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.
|
|
|
|
(Note that these versions of @command{g77}
|
|
perform internal consistency checking automatically
|
|
when the @option{-fversion} option is specified.)
|
|
|
|
@item G77 0.5.23
|
|
@itemx G77 0.5.24 (EGCS 1.0)
|
|
Change the way @code{f771} handles the @option{-fset-g77-defaults}
|
|
option, which is always provided as the first option when
|
|
called by @command{g77} or @command{gcc}.
|
|
|
|
This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
|
|
Have it change just the variables that you want to default
|
|
to a different setting for Fortran compiles compared to
|
|
compiles of other languages.
|
|
|
|
The @option{-fset-g77-defaults} option is passed to @code{f771}
|
|
automatically because of the specification information
|
|
kept in @file{@value{path-g77}/lang-specs.h}.
|
|
This file tells the @command{gcc} command how to recognize,
|
|
in this case, Fortran source files (those to be preprocessed,
|
|
and those that are not), and further, how to invoke the
|
|
appropriate programs (including @code{f771}) to process
|
|
those source files.
|
|
|
|
It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults},
|
|
@option{-fversion}, and other options are passed, as appropriate,
|
|
even when the user has not explicitly specified them.
|
|
Other ``internal'' options such as @option{-quiet} also
|
|
are passed via this mechanism.
|
|
@end table
|
|
|
|
@node Projects
|
|
@chapter Projects
|
|
@cindex projects
|
|
|
|
If you want to contribute to @command{g77} by doing research,
|
|
design, specification, documentation, coding, or testing,
|
|
the following information should give you some ideas.
|
|
More relevant information might be available from
|
|
@uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
|
|
|
|
@menu
|
|
* Efficiency:: Make @command{g77} itself compile code faster.
|
|
* Better Optimization:: Teach @command{g77} to generate faster code.
|
|
* Simplify Porting:: Make @command{g77} easier to configure, build,
|
|
and install.
|
|
* More Extensions:: Features many users won't know to ask for.
|
|
* Machine Model:: @command{g77} should better leverage @command{gcc}.
|
|
* Internals Documentation:: Make maintenance easier.
|
|
* Internals Improvements:: Make internals more robust.
|
|
* Better Diagnostics:: Make using @command{g77} on new code easier.
|
|
@end menu
|
|
|
|
@node Efficiency
|
|
@section Improve Efficiency
|
|
@cindex efficiency
|
|
|
|
Don't bother doing any performance analysis until most of the
|
|
following items are taken care of, because there's no question
|
|
they represent serious space/time problems, although some of
|
|
them show up only given certain kinds of (popular) input.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Improve @code{malloc} package and its uses to specify more info about
|
|
memory pools and, where feasible, use obstacks to implement them.
|
|
|
|
@item
|
|
Skip over uninitialized portions of aggregate areas (arrays,
|
|
@code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
|
|
This would reduce memory usage for large initialized aggregate
|
|
areas, even ones with only one initialized element.
|
|
|
|
As of version 0.5.18, a portion of this item has already been
|
|
accomplished.
|
|
|
|
@item
|
|
Prescan the statement (in @file{sta.c}) so that the nature of the statement
|
|
is determined as much as possible by looking entirely at its form,
|
|
and not looking at any context (previous statements, including types
|
|
of symbols).
|
|
This would allow ripping out of the statement-confirmation,
|
|
symbol retraction/confirmation, and diagnostic inhibition
|
|
mechanisms.
|
|
Plus, it would result in much-improved diagnostics.
|
|
For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
|
|
is not a subroutine intrinsic, would result actual error instead of the
|
|
unimplemented-statement catch-all.
|
|
|
|
@item
|
|
Throughout @command{g77}, don't pass line/column pairs where
|
|
a simple @code{ffewhere} type, which points to the error as much as is
|
|
desired by the configuration, will do, and don't pass @code{ffelexToken} types
|
|
where a simple @code{ffewhere} type will do.
|
|
Then, allow new default
|
|
configuration of @code{ffewhere} such that the source line text is not
|
|
preserved, and leave it to things like Emacs' next-error function
|
|
to point to them (now that @samp{next-error} supports column,
|
|
or, perhaps, character-offset, numbers).
|
|
The change in calling sequences should improve performance somewhat,
|
|
as should not having to save source lines.
|
|
(Whether this whole
|
|
item will improve performance is questionable, but it should
|
|
improve maintainability.)
|
|
|
|
@item
|
|
Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
|
|
as regards the assembly output.
|
|
Some of this might require improving
|
|
the back end, but lots of improvement in space/time required in @command{g77}
|
|
itself can be fairly easily obtained without touching the back end.
|
|
Maybe type-conversion, where necessary, can be speeded up as well in
|
|
cases like the one shown (converting the @samp{2} into @samp{2.}).
|
|
|
|
@item
|
|
If analysis shows it to be worthwhile, optimize @file{lex.c}.
|
|
|
|
@item
|
|
Consider redesigning @file{lex.c} to not need any feedback
|
|
during tokenization, by keeping track of enough parse state on its
|
|
own.
|
|
@end itemize
|
|
|
|
@node Better Optimization
|
|
@section Better Optimization
|
|
@cindex optimization, better
|
|
@cindex code generation, improving
|
|
|
|
Much of this work should be put off until after @command{g77} has
|
|
all the features necessary for its widespread acceptance as a
|
|
useful F77 compiler.
|
|
However, perhaps this work can be done in parallel during
|
|
the feature-adding work.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Do the equivalent of the trick of putting @samp{extern inline} in front
|
|
of every function definition in @code{libg2c} and #include'ing the resulting
|
|
file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions
|
|
that are at all worth inlining.
|
|
(Some of this has already been done, such as for integral exponentiation.)
|
|
|
|
@item
|
|
When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
|
|
and it's clear that types line up
|
|
and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
|
|
make @samp{CHAR_VAR}, not a
|
|
temporary, be the receiver for @samp{CHAR_FUNC}.
|
|
(This is now done for @code{COMPLEX} variables.)
|
|
|
|
@item
|
|
Design and implement Fortran-specific optimizations that don't
|
|
really belong in the back end, or where the front end needs to
|
|
give the back end more info than it currently does.
|
|
|
|
@item
|
|
Design and implement a new run-time library interface, with the
|
|
code going into @code{libgcc} so no special linking is required to
|
|
link Fortran programs using standard language features.
|
|
This library
|
|
would speed up lots of things, from I/O (using precompiled formats,
|
|
doing just one, or, at most, very few, calls for arrays or array sections,
|
|
and so on) to general computing (array/section implementations of
|
|
various intrinsics, implementation of commonly performed loops that
|
|
aren't likely to be optimally compiled otherwise, etc.).
|
|
|
|
Among the important things the library would do are:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Be a one-stop-shop-type
|
|
library, hence shareable and usable by all, in that what are now
|
|
library-build-time options in @code{libg2c} would be moved at least to the
|
|
@command{g77} compile phase, if not to finer grains (such as choosing how
|
|
list-directed I/O formatting is done by default at @code{OPEN} time, for
|
|
preconnected units via options or even statements in the main program
|
|
unit, maybe even on a per-I/O basis with appropriate pragma-like
|
|
devices).
|
|
@end itemize
|
|
|
|
@item
|
|
Probably requiring the new library design, change interface to
|
|
normally have @code{COMPLEX} functions return their values in the way
|
|
@command{gcc} would if they were declared @code{__complex__ float},
|
|
rather than using
|
|
the mechanism currently used by @code{CHARACTER} functions (whereby the
|
|
functions are compiled as returning void and their first arg is
|
|
a pointer to where to store the result).
|
|
(Don't append underscores to
|
|
external names for @code{COMPLEX} functions in some cases once @command{g77} uses
|
|
@command{gcc} rather than @command{f2c} calling conventions.)
|
|
|
|
@item
|
|
Do something useful with @code{doiter} references where possible.
|
|
For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
|
|
a @code{DO} loop that uses @samp{I} as the
|
|
iteration variable, and the back end might find that info useful
|
|
in determining whether it needs to read @samp{I} back into a register after
|
|
the call.
|
|
(It normally has to do that, unless it knows @samp{FOO} never
|
|
modifies its passed-by-reference argument, which is rarely the case
|
|
for Fortran-77 code.)
|
|
@end itemize
|
|
|
|
@node Simplify Porting
|
|
@section Simplify Porting
|
|
@cindex porting, simplify
|
|
@cindex simplify porting
|
|
|
|
Making @command{g77} easier to configure, port, build, and install, either
|
|
as a single-system compiler or as a cross-compiler, would be
|
|
very useful.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
A new library (replacing @code{libg2c}) should improve portability as well as
|
|
produce more optimal code.
|
|
Further, @command{g77} and the new library should
|
|
conspire to simplify naming of externals, such as by removing unnecessarily
|
|
added underscores, and to reduce/eliminate the possibility of naming
|
|
conflicts, while making debugger more straightforward.
|
|
|
|
Also, it should
|
|
make multi-language applications more feasible, such as by providing
|
|
Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
|
|
descriptors.
|
|
|
|
@item
|
|
Possibly related to a new library, @command{g77} should produce the equivalent
|
|
of a @command{gcc} @samp{main(argc, argv)} function when it compiles a
|
|
main program unit, instead of compiling something that must be
|
|
called by a library
|
|
implementation of @code{main()}.
|
|
|
|
This would do many useful things such as
|
|
provide more flexibility in terms of setting up exception handling,
|
|
not requiring programmers to start their debugging sessions with
|
|
@kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
|
|
|
|
@item
|
|
The GBE needs to understand the difference between alignment
|
|
requirements and desires.
|
|
For example, on Intel x86 machines, @command{g77} currently imposes
|
|
overly strict alignment requirements, due to the back end, but it
|
|
would be useful for Fortran and C programmers to be able to override
|
|
these @emph{recommendations} as long as they don't violate the actual
|
|
processor @emph{requirements}.
|
|
@end itemize
|
|
|
|
@node More Extensions
|
|
@section More Extensions
|
|
@cindex extensions, more
|
|
|
|
These extensions are not the sort of things users ask for ``by name'',
|
|
but they might improve the usability of @command{g77}, and Fortran in
|
|
general, in the long run.
|
|
Some of these items really pertain to improving @command{g77} internals
|
|
so that some popular extensions can be more easily supported.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Look through all the documentation on the GNU Fortran language,
|
|
dialects, compiler, missing features, bugs, and so on.
|
|
Many mentions of incomplete or missing features are
|
|
sprinkled throughout.
|
|
It is not worth repeating them here.
|
|
|
|
@item
|
|
Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
|
|
named and unnamed.
|
|
The idea is to provide a forward-looking, effective
|
|
replacement for things like the old-style @code{PARAMETER} statement
|
|
when people
|
|
really need typelessness in a maintainable, portable, clearly documented
|
|
way.
|
|
Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
|
|
and whatever else might come along.
|
|
(This is not really a call for polymorphism per se, just
|
|
an ability to express limited, syntactic polymorphism.)
|
|
|
|
@item
|
|
Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
|
|
|
|
@item
|
|
Support arbitrary file unit numbers, instead of limiting them
|
|
to 0 through @samp{MXUNIT-1}.
|
|
(This is a @code{libg2c} issue.)
|
|
|
|
@item
|
|
@samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
|
|
@samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
|
|
later @code{UNIT=} in the first example is invalid.
|
|
Make sure this is what users of this feature would expect.
|
|
|
|
@item
|
|
Currently @command{g77} disallows @samp{READ(1'10)} since
|
|
it is an obnoxious syntax, but
|
|
supporting it might be pretty easy if needed.
|
|
More details are needed, such
|
|
as whether general expressions separated by an apostrophe are supported,
|
|
or maybe the record number can be a general expression, and so on.
|
|
|
|
@item
|
|
Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
|
|
fully.
|
|
Currently there is no support at all
|
|
for @code{%FILL} in @code{STRUCTURE} and related syntax,
|
|
whereas the rest of the
|
|
stuff has at least some parsing support.
|
|
This requires either major
|
|
changes to @code{libg2c} or its replacement.
|
|
|
|
@item
|
|
F90 and @command{g77} probably disagree about label scoping relative to
|
|
@code{INTERFACE} and @code{END INTERFACE}, and their contained
|
|
procedure interface bodies (blocks?).
|
|
|
|
@item
|
|
@code{ENTRY} doesn't support F90 @code{RESULT()} yet,
|
|
since that was added after S8.112.
|
|
|
|
@item
|
|
Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
|
|
with the final form of the standard (it was vague at S8.112).
|
|
|
|
@item
|
|
It seems to be an ``open'' question whether a file, immediately after being
|
|
@code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
|
|
might be nice to offer an option of opening to ``undefined'' status, requiring
|
|
an explicit absolute-positioning operation to be performed before any
|
|
other (besides @code{CLOSE}) to assist in making applications port to systems
|
|
(some IBM?) that @code{OPEN} to the end of a file or some such thing.
|
|
@end itemize
|
|
|
|
@node Machine Model
|
|
@section Machine Model
|
|
|
|
This items pertain to generalizing @command{g77}'s view of
|
|
the machine model to more fully accept whatever the GBE
|
|
provides it via its configuration.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
|
|
exclusively so the target float format need not be required.
|
|
This
|
|
means changing the way @command{g77} handles initialization of aggregate areas
|
|
having more than one type, such as @code{REAL} and @code{INTEGER},
|
|
because currently
|
|
it initializes them as if they were arrays of @code{char} and uses the
|
|
bit patterns of the constants of the various types in them to determine
|
|
what to stuff in elements of the arrays.
|
|
|
|
@item
|
|
Rely more and more on back-end info and capabilities, especially in the
|
|
area of constants (where having the @command{g77} front-end's IL just store
|
|
the appropriate tree nodes containing constants might be best).
|
|
|
|
@item
|
|
Suite of C and Fortran programs that a user/administrator can run on a
|
|
machine to help determine the configuration for @command{g77} before building
|
|
and help determine if the compiler works (especially with whatever
|
|
libraries are installed) after building.
|
|
@end itemize
|
|
|
|
@node Internals Documentation
|
|
@section Internals Documentation
|
|
|
|
Better info on how @command{g77} works and how to port it is needed.
|
|
|
|
@xref{Front End}, which contains some information
|
|
on @command{g77} internals.
|
|
|
|
@node Internals Improvements
|
|
@section Internals Improvements
|
|
|
|
Some more items that would make @command{g77} more reliable
|
|
and easier to maintain:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Generally make expression handling focus
|
|
more on critical syntax stuff, leaving semantics to callers.
|
|
For example,
|
|
anything a caller can check, semantically, let it do so, rather
|
|
than having @file{expr.c} do it.
|
|
(Exceptions might include things like
|
|
diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
|
|
it seems
|
|
important to preserve the left-to-right-in-source order of production
|
|
of diagnostics.)
|
|
|
|
@item
|
|
Come up with better naming conventions for @option{-D} to establish requirements
|
|
to achieve desired implementation dialect via @file{proj.h}.
|
|
|
|
@item
|
|
Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
|
|
|
|
@item
|
|
Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
|
|
|
|
@item
|
|
Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
|
|
and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
|
|
(after determining if there is indeed no real need for it).
|
|
|
|
@item
|
|
Utility to read and check @file{bad.def} messages and their references in the
|
|
code, to make sure calls are consistent with message templates.
|
|
|
|
@item
|
|
Search and fix @samp{&ffe@dots{}} and similar so that
|
|
@samp{ffe@dots{}ptr@dots{}} macros are
|
|
available instead (a good argument for wishing this could have written all
|
|
this stuff in C++, perhaps).
|
|
On the other hand, it's questionable whether this sort of
|
|
improvement is really necessary, given the availability of
|
|
tools such as Emacs and Perl, which make finding any
|
|
address-taking of structure members easy enough?
|
|
|
|
@item
|
|
Some modules truly export the member names of their structures (and the
|
|
structures themselves), maybe fix this, and fix other modules that just
|
|
appear to as well (by appending @samp{_}, though it'd be ugly and probably
|
|
not worth the time).
|
|
|
|
@item
|
|
Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
|
|
in @file{proj.h}
|
|
and use them throughout @command{g77} source code (especially in the definitions
|
|
of access macros in @samp{.h} files) so they can be tailored
|
|
to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
|
|
|
|
@item
|
|
Decorate throughout with @code{const} and other such stuff.
|
|
|
|
@item
|
|
All F90 notational derivations in the source code are still based
|
|
on the S8.112 version of the draft standard.
|
|
Probably should update
|
|
to the official standard, or put documentation of the rules as used
|
|
in the code@dots{}uh@dots{}in the code.
|
|
|
|
@item
|
|
Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
|
|
inside but invoked via paths not involving @code{ffeexpr_lhs} or
|
|
@code{ffeexpr_rhs}) might be creating things
|
|
in improper pools, leading to such things staying around too long or
|
|
(doubtful, but possible and dangerous) not long enough.
|
|
|
|
@item
|
|
Some @code{ffebld_list_new} (or whatever) calls might not be matched by
|
|
@code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
|
|
(It definitely is not a problem just yet.)
|
|
|
|
@item
|
|
Probably not doing clean things when we fail to @code{EQUIVALENCE} something
|
|
due to alignment/mismatch or other problems---they end up without
|
|
@code{ffestorag} objects, so maybe the backend (and other parts of the front
|
|
end) can notice that and handle like an @code{opANY} (do what it wants, just
|
|
don't complain or crash).
|
|
Most of this seems to have been addressed
|
|
by now, but a code review wouldn't hurt.
|
|
@end itemize
|
|
|
|
@node Better Diagnostics
|
|
@section Better Diagnostics
|
|
|
|
These are things users might not ask about, or that need to
|
|
be looked into, before worrying about.
|
|
Also here are items that involve reducing unnecessary diagnostic
|
|
clutter.
|
|
|
|
@itemize @bullet
|
|
@item
|
|
When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
|
|
lengths, type classes, and so on),
|
|
@code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
|
|
it specifies.
|
|
|
|
@item
|
|
Speed up and improve error handling for data when repeat-count is
|
|
specified.
|
|
For example, don't output 20 unnecessary messages after the
|
|
first necessary one for:
|
|
|
|
@smallexample
|
|
INTEGER X(20)
|
|
CONTINUE
|
|
DATA (X(I), J= 1, 20) /20*5/
|
|
END
|
|
@end smallexample
|
|
|
|
@noindent
|
|
(The @code{CONTINUE} statement ensures the @code{DATA} statement
|
|
is processed in the context of executable, not specification,
|
|
statements.)
|
|
@end itemize
|
|
|
|
@include ffe.texi
|
|
|
|
@end ifset
|
|
|
|
@ifset USING
|
|
@node Diagnostics
|
|
@chapter Diagnostics
|
|
@cindex diagnostics
|
|
|
|
Some diagnostics produced by @command{g77} require sufficient explanation
|
|
that the explanations are given below, and the diagnostics themselves
|
|
identify the appropriate explanation.
|
|
|
|
Identification uses the GNU Info format---specifically, the @command{info}
|
|
command that displays the explanation is given within square
|
|
brackets in the diagnostic.
|
|
For example:
|
|
|
|
@smallexample
|
|
foo.f:5: Invalid statement [info -f g77 M FOOEY]
|
|
@end smallexample
|
|
|
|
More details about the above diagnostic is found in the @command{g77} Info
|
|
documentation, menu item @samp{M}, submenu item @samp{FOOEY},
|
|
which is displayed by typing the UNIX command
|
|
@samp{info -f g77 M FOOEY}.
|
|
|
|
Other Info readers, such as EMACS, may be just as easily used to display
|
|
the pertinent node.
|
|
In the above example, @samp{g77} is the Info document name,
|
|
@samp{M} is the top-level menu item to select,
|
|
and, in that node (named @samp{Diagnostics}, the name of
|
|
this chapter, which is the very text you're reading now),
|
|
@samp{FOOEY} is the menu item to select.
|
|
|
|
@iftex
|
|
In this printed version of the @command{g77} manual, the above example
|
|
points to a section, below, entitled @samp{FOOEY}---though, of course,
|
|
as the above is just a sample, no such section exists.
|
|
@end iftex
|
|
|
|
@menu
|
|
* CMPAMBIG:: Ambiguous use of intrinsic.
|
|
* EXPIMP:: Intrinsic used explicitly and implicitly.
|
|
* INTGLOB:: Intrinsic also used as name of global.
|
|
* LEX:: Various lexer messages
|
|
* GLOBALS:: Disagreements about globals.
|
|
* LINKFAIL:: When linking @code{f771} fails.
|
|
* Y2KBAD:: Use of non-Y2K-compliant intrinsic.
|
|
@end menu
|
|
|
|
@node CMPAMBIG
|
|
@section @code{CMPAMBIG}
|
|
|
|
@noindent
|
|
@smallexample
|
|
Ambiguous use of intrinsic @var{intrinsic} @dots{}
|
|
@end smallexample
|
|
|
|
The type of the argument to the invocation of the @var{intrinsic}
|
|
intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
|
|
Typically, it is @code{COMPLEX(KIND=2)}, also known as
|
|
@code{DOUBLE COMPLEX}.
|
|
|
|
The interpretation of this invocation depends on the particular
|
|
dialect of Fortran for which the code was written.
|
|
Some dialects convert the real part of the argument to
|
|
@code{REAL(KIND=1)}, thus losing precision; other dialects,
|
|
and Fortran 90, do no such conversion.
|
|
|
|
So, GNU Fortran rejects such invocations except under certain
|
|
circumstances, to avoid making an incorrect assumption that results
|
|
in generating the wrong code.
|
|
|
|
To determine the dialect of the program unit, perhaps even whether
|
|
that particular invocation is properly coded, determine how the
|
|
result of the intrinsic is used.
|
|
|
|
The result of @var{intrinsic} is expected (by the original programmer)
|
|
to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
It is passed as an argument to a procedure that explicitly or
|
|
implicitly declares that argument @code{REAL(KIND=1)}.
|
|
|
|
For example,
|
|
a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
|
|
statement specifying the dummy argument corresponding to an
|
|
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
|
|
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
|
|
expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
|
|
of @code{REAL(KIND=2)}.
|
|
|
|
@item
|
|
It is used in a context that would otherwise not include
|
|
any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
|
|
invocation as @code{REAL(KIND=2)} would result in unnecessary
|
|
promotions and (typically) more expensive operations on the
|
|
wider type.
|
|
|
|
For example:
|
|
|
|
@smallexample
|
|
DOUBLE COMPLEX Z
|
|
@dots{}
|
|
R(1) = T * REAL(Z)
|
|
@end smallexample
|
|
|
|
The above example suggests the programmer expected the real part
|
|
of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
|
|
multiplied by @samp{T} (presumed, along with @samp{R} above, to
|
|
be type @code{REAL(KIND=1)}).
|
|
|
|
Otherwise, the conversion would have to be delayed until after
|
|
the multiplication, requiring not only an extra conversion
|
|
(of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
|
|
expensive multiplication (a double-precision multiplication instead
|
|
of a single-precision one).
|
|
@end itemize
|
|
|
|
The result of @var{intrinsic} is expected (by the original programmer)
|
|
to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
It is passed as an argument to a procedure that explicitly or
|
|
implicitly declares that argument @code{REAL(KIND=2)}.
|
|
|
|
For example, a procedure specifying a @code{DOUBLE PRECISION}
|
|
dummy argument corresponding to an
|
|
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
|
|
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
|
|
expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
|
|
of @code{REAL(KIND=1)}.
|
|
|
|
@item
|
|
It is used in an expression context that includes
|
|
other @code{REAL(KIND=2)} operands,
|
|
or is assigned to a @code{REAL(KIND=2)} variable or array element.
|
|
|
|
For example:
|
|
|
|
@smallexample
|
|
DOUBLE COMPLEX Z
|
|
DOUBLE PRECISION R, T
|
|
@dots{}
|
|
R(1) = T * REAL(Z)
|
|
@end smallexample
|
|
|
|
The above example suggests the programmer expected the real part
|
|
of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
|
|
by the @code{REAL()} intrinsic.
|
|
|
|
Otherwise, the conversion would have to be immediately followed
|
|
by a conversion back to @code{REAL(KIND=2)}, losing
|
|
the original, full precision of the real part of @code{Z},
|
|
before being multiplied by @samp{T}.
|
|
@end itemize
|
|
|
|
Once you have determined whether a particular invocation of @var{intrinsic}
|
|
expects the Fortran 90 interpretation, you can:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
|
|
@code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
|
|
is @code{AIMAG})
|
|
if it expected the Fortran 90 interpretation.
|
|
|
|
This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
|
|
some other type, such as @code{COMPLEX*32}, you should use the
|
|
appropriate intrinsic, such as the one to convert to @code{REAL*16}
|
|
(perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
|
|
@code{QIMAG()} in place of @code{DIMAG()}).
|
|
|
|
@item
|
|
Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
|
|
otherwise.
|
|
This converts to @code{REAL(KIND=1)} in all working
|
|
Fortran compilers.
|
|
@end itemize
|
|
|
|
If you don't want to change the code, and you are certain that all
|
|
ambiguous invocations of @var{intrinsic} in the source file have
|
|
the same expectation regarding interpretation, you can:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
Compile with the @command{g77} option @option{-ff90}, to enable the
|
|
Fortran 90 interpretation.
|
|
|
|
@item
|
|
Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex},
|
|
to enable the non-Fortran-90 interpretations.
|
|
@end itemize
|
|
|
|
@xref{REAL() and AIMAG() of Complex}, for more information on this
|
|
issue.
|
|
|
|
Note: If the above suggestions don't produce enough evidence
|
|
as to whether a particular program expects the Fortran 90
|
|
interpretation of this ambiguous invocation of @var{intrinsic},
|
|
there is one more thing you can try.
|
|
|
|
If you have access to most or all the compilers used on the
|
|
program to create successfully tested and deployed executables,
|
|
read the documentation for, and @emph{also} test out, each compiler
|
|
to determine how it treats the @var{intrinsic} intrinsic in
|
|
this case.
|
|
(If all the compilers don't agree on an interpretation, there
|
|
might be lurking bugs in the deployed versions of the program.)
|
|
|
|
The following sample program might help:
|
|
|
|
@cindex JCB003 program
|
|
@smallexample
|
|
PROGRAM JCB003
|
|
C
|
|
C Written by James Craig Burley 1997-02-23.
|
|
C
|
|
C Determine how compilers handle non-standard REAL
|
|
C and AIMAG on DOUBLE COMPLEX operands.
|
|
C
|
|
DOUBLE COMPLEX Z
|
|
REAL R
|
|
Z = (3.3D0, 4.4D0)
|
|
R = Z
|
|
CALL DUMDUM(Z, R)
|
|
R = REAL(Z) - R
|
|
IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
|
|
IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
|
|
R = 4.4D0
|
|
CALL DUMDUM(Z, R)
|
|
R = AIMAG(Z) - R
|
|
IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
|
|
IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
|
|
END
|
|
C
|
|
C Just to make sure compiler doesn't use naive flow
|
|
C analysis to optimize away careful work above,
|
|
C which might invalidate results....
|
|
C
|
|
SUBROUTINE DUMDUM(Z, R)
|
|
DOUBLE COMPLEX Z
|
|
REAL R
|
|
END
|
|
@end smallexample
|
|
|
|
If the above program prints contradictory results on a
|
|
particular compiler, run away!
|
|
|
|
@node EXPIMP
|
|
@section @code{EXPIMP}
|
|
|
|
@noindent
|
|
@smallexample
|
|
Intrinsic @var{intrinsic} referenced @dots{}
|
|
@end smallexample
|
|
|
|
The @var{intrinsic} is explicitly declared in one program
|
|
unit in the source file and implicitly used as an intrinsic
|
|
in another program unit in the same source file.
|
|
|
|
This diagnostic is designed to catch cases where a program
|
|
might depend on using the name @var{intrinsic} as an intrinsic
|
|
in one program unit and as a global name (such as the name
|
|
of a subroutine or function) in another, but @command{g77} recognizes
|
|
the name as an intrinsic in both cases.
|
|
|
|
After verifying that the program unit making implicit use
|
|
of the intrinsic is indeed written expecting the intrinsic,
|
|
add an @samp{INTRINSIC @var{intrinsic}} statement to that
|
|
program unit to prevent this warning.
|
|
|
|
This and related warnings are disabled by using
|
|
the @option{-Wno-globals} option when compiling.
|
|
|
|
Note that this warning is not issued for standard intrinsics.
|
|
Standard intrinsics include those described in the FORTRAN 77
|
|
standard and, if @option{-ff90} is specified, those described
|
|
in the Fortran 90 standard.
|
|
Such intrinsics are not as likely to be confused with user
|
|
procedures as intrinsics provided as extensions to the
|
|
standard by @command{g77}.
|
|
|
|
@node INTGLOB
|
|
@section @code{INTGLOB}
|
|
|
|
@noindent
|
|
@smallexample
|
|
Same name `@var{intrinsic}' given @dots{}
|
|
@end smallexample
|
|
|
|
The name @var{intrinsic} is used for a global entity (a common
|
|
block or a program unit) in one program unit and implicitly
|
|
used as an intrinsic in another program unit.
|
|
|
|
This diagnostic is designed to catch cases where a program
|
|
intends to use a name entirely as a global name, but @command{g77}
|
|
recognizes the name as an intrinsic in the program unit that
|
|
references the name, a situation that would likely produce
|
|
incorrect code.
|
|
|
|
For example:
|
|
|
|
@smallexample
|
|
INTEGER FUNCTION TIME()
|
|
@dots{}
|
|
END
|
|
@dots{}
|
|
PROGRAM SAMP
|
|
INTEGER TIME
|
|
PRINT *, 'Time is ', TIME()
|
|
END
|
|
@end smallexample
|
|
|
|
The above example defines a program unit named @samp{TIME}, but
|
|
the reference to @samp{TIME} in the main program unit @samp{SAMP}
|
|
is normally treated by @command{g77} as a reference to the intrinsic
|
|
@code{TIME()} (unless a command-line option that prevents such
|
|
treatment has been specified).
|
|
|
|
As a result, the program @samp{SAMP} will @emph{not}
|
|
invoke the @samp{TIME} function in the same source file.
|
|
|
|
Since @command{g77} recognizes @code{libU77} procedures as
|
|
intrinsics, and since some existing code uses the same names
|
|
for its own procedures as used by some @code{libU77}
|
|
procedures, this situation is expected to arise often enough
|
|
to make this sort of warning worth issuing.
|
|
|
|
After verifying that the program unit making implicit use
|
|
of the intrinsic is indeed written expecting the intrinsic,
|
|
add an @samp{INTRINSIC @var{intrinsic}} statement to that
|
|
program unit to prevent this warning.
|
|
|
|
Or, if you believe the program unit is designed to invoke the
|
|
program-defined procedure instead of the intrinsic (as
|
|
recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}}
|
|
statement to the program unit that references the name to
|
|
prevent this warning.
|
|
|
|
This and related warnings are disabled by using
|
|
the @option{-Wno-globals} option when compiling.
|
|
|
|
Note that this warning is not issued for standard intrinsics.
|
|
Standard intrinsics include those described in the FORTRAN 77
|
|
standard and, if @option{-ff90} is specified, those described
|
|
in the Fortran 90 standard.
|
|
Such intrinsics are not as likely to be confused with user
|
|
procedures as intrinsics provided as extensions to the
|
|
standard by @command{g77}.
|
|
|
|
@node LEX
|
|
@section @code{LEX}
|
|
|
|
@noindent
|
|
@smallexample
|
|
Unrecognized character @dots{}
|
|
Invalid first character @dots{}
|
|
Line too long @dots{}
|
|
Non-numeric character @dots{}
|
|
Continuation indicator @dots{}
|
|
Label at @dots{} invalid with continuation line indicator @dots{}
|
|
Character constant @dots{}
|
|
Continuation line @dots{}
|
|
Statement at @dots{} begins with invalid token
|
|
@end smallexample
|
|
|
|
Although the diagnostics identify specific problems, they can
|
|
be produced when general problems such as the following occur:
|
|
|
|
@itemize @bullet
|
|
@item
|
|
The source file contains something other than Fortran code.
|
|
|
|
If the code in the file does not look like many of the examples
|
|
elsewhere in this document, it might not be Fortran code.
|
|
(Note that Fortran code often is written in lower case letters,
|
|
while the examples in this document use upper case letters,
|
|
for stylistic reasons.)
|
|
|
|
For example, if the file contains lots of strange-looking
|
|
characters, it might be APL source code; if it contains lots
|
|
of parentheses, it might be Lisp source code; if it
|
|
contains lots of bugs, it might be C++ source code.
|
|
|
|
@item
|
|
The source file contains free-form Fortran code, but @option{-ffree-form}
|
|
was not specified on the command line to compile it.
|
|
|
|
Free form is a newer form for Fortran code.
|
|
The older, classic form is called fixed form.
|
|
|
|
@cindex continuation character
|
|
@cindex characters, continuation
|
|
Fixed-form code is visually fairly distinctive, because
|
|
numerical labels and comments are all that appear in
|
|
the first five columns of a line, the sixth column is
|
|
reserved to denote continuation lines,
|
|
and actual statements start at or beyond column 7.
|
|
Spaces generally are not significant, so if you
|
|
see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
|
|
you are looking at fixed-form code.
|
|
@cindex *
|
|
@cindex asterisk
|
|
Comment lines are indicated by the letter @samp{C} or the symbol
|
|
@samp{*} in column 1.
|
|
@cindex trailing comment
|
|
@cindex comment
|
|
@cindex characters, comment
|
|
@cindex !
|
|
@cindex exclamation point
|
|
(Some code uses @samp{!} or @samp{/*} to begin in-line comments,
|
|
which many compilers support.)
|
|
|
|
Free-form code is distinguished from fixed-form source
|
|
primarily by the fact that statements may start anywhere.
|
|
(If lots of statements start in columns 1 through 6,
|
|
that's a strong indicator of free-form source.)
|
|
Consecutive keywords must be separated by spaces, so
|
|
@samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
|
|
There are no comment lines per se, but @samp{!} starts a
|
|
comment anywhere in a line (other than within a character or
|
|
Hollerith constant).
|
|
|
|
@xref{Source Form}, for more information.
|
|
|
|
@item
|
|
The source file is in fixed form and has been edited without
|
|
sensitivity to the column requirements.
|
|
|
|
Statements in fixed-form code must be entirely contained within
|
|
columns 7 through 72 on a given line.
|
|
Starting them ``early'' is more likely to result in diagnostics
|
|
than finishing them ``late'', though both kinds of errors are
|
|
often caught at compile time.
|
|
|
|
For example, if the following code fragment is edited by following
|
|
the commented instructions literally, the result, shown afterward,
|
|
would produce a diagnostic when compiled:
|
|
|
|
@smallexample
|
|
C On XYZZY systems, remove "C" on next line:
|
|
C CALL XYZZY_RESET
|
|
@end smallexample
|
|
|
|
The result of editing the above line might be:
|
|
|
|
@smallexample
|
|
C On XYZZY systems, remove "C" on next line:
|
|
CALL XYZZY_RESET
|
|
@end smallexample
|
|
|
|
However, that leaves the first @samp{C} in the @code{CALL}
|
|
statement in column 6, making it a comment line, which is
|
|
not really what the author intended, and which is likely
|
|
to result in one of the above-listed diagnostics.
|
|
|
|
@emph{Replacing} the @samp{C} in column 1 with a space
|
|
is the proper change to make, to ensure the @code{CALL}
|
|
keyword starts in or after column 7.
|
|
|
|
Another common mistake like this is to forget that fixed-form
|
|
source lines are significant through only column 72, and that,
|
|
normally, any text beyond column 72 is ignored or is diagnosed
|
|
at compile time.
|
|
|
|
@xref{Source Form}, for more information.
|
|
|
|
@item
|
|
The source file requires preprocessing, and the preprocessing
|
|
is not being specified at compile time.
|
|
|
|
A source file containing lines beginning with @code{#define},
|
|
@code{#include}, @code{#if}, and so on is likely one that
|
|
requires preprocessing.
|
|
|
|
If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
|
|
the file normally will be compiled @emph{without} preprocessing
|
|
by @command{g77}.
|
|
|
|
Change the file's suffix from @samp{.f} to @samp{.F}
|
|
(or, on systems with case-insensitive file names,
|
|
to @samp{.fpp} or @samp{.FPP}),
|
|
from @samp{.for} to @samp{.fpp},
|
|
or from @samp{.FOR} to @samp{.FPP}.
|
|
@command{g77} compiles files with such names @emph{with}
|
|
preprocessing.
|
|
|
|
@pindex cpp
|
|
@cindex preprocessor
|
|
@cindex cpp program
|
|
@cindex programs, cpp
|
|
@cindex @option{-x f77-cpp-input} option
|
|
@cindex options, @option{-x f77-cpp-input}
|
|
Or, learn how to use @command{gcc}'s @option{-x} option to specify
|
|
the language @samp{f77-cpp-input} for Fortran files that
|
|
require preprocessing.
|
|
@xref{Overall Options,,Options Controlling the Kind of
|
|
Output,gcc,Using the GNU Compiler Collection (GCC)}.
|
|
|
|
@item
|
|
The source file is preprocessed, and the results of preprocessing
|
|
result in syntactic errors that are not necessarily obvious to
|
|
someone examining the source file itself.
|
|
|
|
Examples of errors resulting from preprocessor macro expansion
|
|
include exceeding the line-length limit, improperly starting,
|
|
terminating, or incorporating the apostrophe or double-quote in
|
|
a character constant, improperly forming a Hollerith constant,
|
|
and so on.
|
|
|
|
@xref{Overall Options,,Options Controlling the Kind of Output},
|
|
for suggestions about how to use, and not use, preprocessing
|
|
for Fortran code.
|
|
@end itemize
|
|
|
|
@node GLOBALS
|
|
@section @code{GLOBALS}
|
|
|
|
@noindent
|
|
@smallexample
|
|
Global name @var{name} defined at @dots{} already defined@dots{}
|
|
Global name @var{name} at @dots{} has different type@dots{}
|
|
Too many arguments passed to @var{name} at @dots{}
|
|
Too few arguments passed to @var{name} at @dots{}
|
|
Argument #@var{n} of @var{name} is @dots{}
|
|
@end smallexample
|
|
|
|
These messages all identify disagreements about the
|
|
global procedure named @var{name} among different program units
|
|
(usually including @var{name} itself).
|
|
|
|
Whether a particular disagreement is reported
|
|
as a warning or an error
|
|
can depend on the relative order
|
|
of the disagreeing portions of the source file.
|
|
|
|
Disagreements between a procedure invocation
|
|
and the @emph{subsequent} procedure itself
|
|
are, usually, diagnosed as errors
|
|
when the procedure itself @emph{precedes} the invocation.
|
|
Other disagreements are diagnosed via warnings.
|
|
|
|
@cindex forward references
|
|
@cindex in-line code
|
|
@cindex compilation, in-line
|
|
This distinction, between warnings and errors,
|
|
is due primarily to the present tendency of the @command{gcc} back end
|
|
to inline only those procedure invocations that are
|
|
@emph{preceded} by the corresponding procedure definitions.
|
|
If the @command{gcc} back end is changed
|
|
to inline ``forward references'',
|
|
in which invocations precede definitions,
|
|
the @command{g77} front end will be changed
|
|
to treat both orderings as errors, accordingly.
|
|
|
|
The sorts of disagreements that are diagnosed by @command{g77} include
|
|
whether a procedure is a subroutine or function;
|
|
if it is a function, the type of the return value of the procedure;
|
|
the number of arguments the procedure accepts;
|
|
and the type of each argument.
|
|
|
|
Disagreements regarding global names among program units
|
|
in a Fortran program @emph{should} be fixed in the code itself.
|
|
However, if that is not immediately practical,
|
|
and the code has been working for some time,
|
|
it is possible it will work
|
|
when compiled with the @option{-fno-globals} option.
|
|
|
|
The @option{-fno-globals} option
|
|
causes these diagnostics to all be warnings
|
|
and disables all inlining of references to global procedures
|
|
(to avoid subsequent compiler crashes and bad-code generation).
|
|
Use of the @option{-Wno-globals} option as well as @option{-fno-globals}
|
|
suppresses all of these diagnostics.
|
|
(@option{-Wno-globals} by itself disables only the warnings,
|
|
not the errors.)
|
|
|
|
After using @option{-fno-globals} to work around these problems,
|
|
it is wise to stop using that option and address them by fixing
|
|
the Fortran code, because such problems, while they might not
|
|
actually result in bugs on some systems, indicate that the code
|
|
is not as portable as it could be.
|
|
In particular, the code might appear to work on a particular
|
|
system, but have bugs that affect the reliability of the data
|
|
without exhibiting any other outward manifestations of the bugs.
|
|
|
|
@node LINKFAIL
|
|
@section @code{LINKFAIL}
|
|
|
|
@noindent
|
|
On AIX 4.1, @command{g77} might not build with the native (non-GNU) tools
|
|
due to a linker bug in coping with the @option{-bbigtoc} option which
|
|
leads to a @samp{Relocation overflow} error. The GNU linker is not
|
|
recommended on current AIX versions, though; it was developed under a
|
|
now-unsupported version. This bug is said to be fixed by `update PTF
|
|
U455193 for APAR IX75823'.
|
|
|
|
Compiling with @option{-mminimal-toc}
|
|
might solve this problem, e.g.@: by adding
|
|
@smallexample
|
|
BOOT_CFLAGS='-mminimal-toc -O2 -g'
|
|
@end smallexample
|
|
to the @code{make bootstrap} command line.
|
|
|
|
@node Y2KBAD
|
|
@section @code{Y2KBAD}
|
|
@cindex Y2K compliance
|
|
@cindex Year 2000 compliance
|
|
|
|
@noindent
|
|
@smallexample
|
|
Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
|
|
@end smallexample
|
|
|
|
This diagnostic indicates that
|
|
the specific intrinsic invoked by the name @var{name}
|
|
is known to have an interface
|
|
that is not Year-2000 (Y2K) compliant.
|
|
|
|
@xref{Year 2000 (Y2K) Problems}.
|
|
|
|
@end ifset
|
|
|
|
@node Index
|
|
@unnumbered Index
|
|
|
|
@printindex cp
|
|
@bye
|