+++ /dev/null
-This is g77.info, produced by makeinfo version 4.5 from g77.texi.
-
-INFO-DIR-SECTION Programming
-START-INFO-DIR-ENTRY
-* g77: (g77). The GNU Fortran compiler.
-END-INFO-DIR-ENTRY
- This file documents the use and the internals of the GNU Fortran
-(`g77') compiler. It corresponds to the GCC-3.2.3 version of `g77'.
-
- Published by the Free Software Foundation 59 Temple Place - Suite 330
-Boston, MA 02111-1307 USA
-
- Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002 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.
-
- Contributed by James Craig Burley (<craig@jcb-sc.com>). Inspired by
-a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
-Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).
-
-\1f
-File: g77.info, Node: Lines, Next: Continuation Line, Prev: Character Set, Up: Characters Lines Sequence
-
-Lines
------
-
- (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:
-
- * 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 <NL> character, which has
- ASCII value 10 (decimal).
-
- * Each newline in the file serves to end the line of text that
- precedes it (and that does not contain a newline).
-
- * The end-of-file marker (`EOF') also serves to end the line of text
- that precedes it (and that does not contain a newline).
-
- * Any line of text that is shorter than 72 characters is padded to
- that length with spaces (called "blanks" in the standard).
-
- * Any line of text that is longer than 72 characters is truncated to
- that length, but the truncated remainder must consist entirely of
- spaces.
-
- * Characters other than newline and the GNU Fortran character set
- are invalid.
-
- 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.
-
-\1f
-File: g77.info, Node: Continuation Line, Next: Statements, Prev: Lines, Up: Characters Lines Sequence
-
-Continuation Line
------------------
-
- (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
-
- A continuation line is any line that both
-
- * Contains a continuation character, and
-
- * Contains only spaces in columns 1 through 5
-
- A continuation character is any character of the GNU Fortran
-character set other than space (<SPC>) or zero (`0') in column 6, or a
-digit (`0' through `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.
-
-\1f
-File: g77.info, Node: Statements, Next: Statement Labels, Prev: Continuation Line, Up: Characters Lines Sequence
-
-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 (`;'), except that
-the logical `IF' and non-construct `WHERE' statements may not be
-separated from subsequent statements using only a semicolon as
-statement separator.
-
- The `END PROGRAM', `END SUBROUTINE', `END FUNCTION', and `END BLOCK
-DATA' statements are alternatives to the `END' statement. These
-alternatives may be written as normal statements--they are not subject
-to the restrictions of the `END' statement.
-
- However, no statement other than `END' may have an initial line that
-appears to be an `END' statement--even `END PROGRAM', for example, must
-not be written as:
-
- END
- &PROGRAM
-
-\1f
-File: g77.info, Node: Statement Labels, Next: Order, Prev: Statements, Up: Characters Lines Sequence
-
-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:
-
- * The semicolon is followed by the label for the statement, which in
- turn follows the label.
-
- * The label must be no more than five digits in length.
-
- * 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.
-
- A statement may have only one label defined for it.
-
-\1f
-File: g77.info, Node: Order, Next: INCLUDE, Prev: Statement Labels, Up: Characters Lines Sequence
-
-Order of Statements and Lines
------------------------------
-
- (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
-
- Generally, `DATA' statements may precede executable statements.
-However, specification statements pertaining to any entities
-initialized by a `DATA' statement must precede that `DATA' statement.
-For example, after `DATA I/1/', `INTEGER I' is not permitted, but
-`INTEGER J' is permitted.
-
- The last line of a program unit may be an `END' statement, or may be:
-
- * An `END PROGRAM' statement, if the program unit is a main program.
-
- * An `END SUBROUTINE' statement, if the program unit is a subroutine.
-
- * An `END FUNCTION' statement, if the program unit is a function.
-
- * An `END BLOCK DATA' statement, if the program unit is a block data.
-
-\1f
-File: g77.info, Node: INCLUDE, Next: Cpp-style directives, Prev: Order, Up: Characters Lines Sequence
-
-Including Source Text
----------------------
-
- Additional source text may be included in the processing of the
-source file via the `INCLUDE' directive:
-
- INCLUDE FILENAME
-
-The source text to be included is identified by FILENAME, which is a
-literal GNU Fortran character constant. The meaning and interpretation
-of FILENAME depends on the implementation, but typically is a filename.
-
- (`g77' treats it as a filename that it searches for in the current
-directory and/or directories specified via the `-I' command-line
-option.)
-
- The effect of the `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 `INCLUDE'.
-The depth of nested `INCLUDE' references depends on the implementation,
-but typically is a positive integer.
-
- This virtual replacement treats the statements and `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 `INCLUDE'
-directive, or nothing (the end of the included text).
-
- Similarly, the including text may end the `INCLUDE' directive with a
-semicolon or the end of the line, but it cannot follow an `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 `INCLUDE' directives on the same line are
-treated as if they appeared in between the respective included texts.
-For example:
-
- INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
-
-If the text included by `INCLUDE 'A'' constitutes a `PRINT *, 'A''
-statement and the text included by `INCLUDE 'C'' constitutes a `PRINT
-*, 'C'' statement, then the output of the above sample program would be
-
- A
- B
- C
-
-(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 FILENAME used to reference the text is the
-same.
-
- Note that `INCLUDE' is _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 `INCLUDE' is subject to effectively the same restrictions
-as those on executable statements.
-
- An `INCLUDE' directive may be continued across multiple lines as if
-it were a statement. This permits long names to be used for FILENAME.
-
-\1f
-File: g77.info, Node: Cpp-style directives, Prev: INCLUDE, Up: Characters Lines Sequence
-
-Cpp-style directives
---------------------
-
- `cpp' output-style `#' directives (*note C Preprocessor Output:
-(cpp)C Preprocessor Output.) are recognized by the compiler even when
-the preprocessor isn't run on the input (as it is when compiling `.F'
-files). (Note the distinction between these `cpp' `#' _output_
-directives and `#line' _input_ directives.)
-
-\1f
-File: g77.info, Node: Data Types and Constants, Next: Expressions, Prev: Characters Lines Sequence, Up: Language
-
-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
-`INTEGER(KIND=1)' instead of the more traditional, but less portably
-concise, byte-size-based nomenclature such as `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 `INTEGER', `LOGICAL', `REAL', `COMPLEX', and
-`CHARACTER'.
-
- In some cases, the context requires specification of a particular
-type. This document uses the `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 `KIND=' makes this document more concise because `g77' is
-able to define values for `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 `CHARACTER' type; one to the `INTEGER' type;
-one to the `LOGICAL' type; and the fourth to both the `REAL' and
-`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 `KIND=' values superior to the values used in
-non-standard statements such as `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 `KIND=' is _not_ generally recommended when writing
-portable code (unless, for example, the code is going to be compiled
-only via `g77', which is a widely ported compiler). GNU Fortran does
-not yet have adequate language constructs to permit use of `KIND=' in a
-fashion that would make the code portable to Fortran 90
-implementations; and, this construct is known to _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 `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 `INTEGER' for `INTEGER(KIND=1)',
-`REAL' for `REAL(KIND=1)', and `DOUBLE COMPLEX' for
-`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 `g77'.)
-
- Further details regarding GNU Fortran data types and constants are
-provided below.
-
-* Menu:
-
-* Types::
-* Constants::
-* Integer Type::
-* Character Type::
-
-\1f
-File: g77.info, Node: Types, Next: Constants, Up: Data Types and Constants
-
-Data Types
-----------
-
- (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
-
- GNU Fortran supports these types:
-
- 1. Integer (generic type `INTEGER')
-
- 2. Real (generic type `REAL')
-
- 3. Double precision
-
- 4. Complex (generic type `COMPLEX')
-
- 5. Logical (generic type `LOGICAL')
-
- 6. Character (generic type `CHARACTER')
-
- 7. Double Complex
-
- (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
-`COMPLEX' type also is likely to accept the `DOUBLE COMPLEX' type.
-
- The GNU Fortran language supports three ways to specify a specific
-kind of a generic type.
-
-* Menu:
-
-* Double Notation:: As in `DOUBLE COMPLEX'.
-* Star Notation:: As in `INTEGER*4'.
-* Kind Notation:: As in `INTEGER(KIND=1)'.
-
-\1f
-File: g77.info, Node: Double Notation, Next: Star Notation, Up: Types
-
-Double Notation
-...............
-
- The GNU Fortran language supports two uses of the keyword `DOUBLE'
-to specify a specific kind of type:
-
- * `DOUBLE PRECISION', equivalent to `REAL(KIND=2)'
-
- * `DOUBLE COMPLEX', equivalent to `COMPLEX(KIND=2)'
-
- 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 `DOUBLE INTEGER',
-`QUADRUPLE REAL', or `QUARTER INTEGER'. Instead, `INTEGER*8',
-`REAL*16', and `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 `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.
-
-\1f
-File: g77.info, Node: Star Notation, Next: Kind Notation, Prev: Double Notation, Up: Types
-
-Star Notation
-.............
-
- The following notation specifies the storage size for a type:
-
- GENERIC-TYPE*N
-
-GENERIC-TYPE must be a generic type--one of `INTEGER', `REAL',
-`COMPLEX', `LOGICAL', or `CHARACTER'. 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 `*N' notation specifies that the amount of storage occupied by
-variables and array elements of that type is N times the storage
-occupied by a `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
-N to be supported by an implementation via the `*N' notation. `g77'
-supports `INTEGER*1' (as `INTEGER(KIND=3)') on all systems, for example,
-but not all implementations are required to do so, and `g77' is known
-to not support `REAL*1' on most (or all) systems.
-
- As a result, except for GENERIC-TYPE of `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 `*N' notation for only
-`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 N.)
-
- Specifications of types using the `*N' notation always are
-interpreted as specifications of the appropriate types described in
-this document using the `KIND=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
-`INTEGER*2' or `REAL*16'. Certainly there is known to be disagreement
-over such things among Fortran compilers on _different_ systems.
-
- Further, this notation offers no elegant way to specify sizes that
-are not even multiples of the "byte size" typically designated by
-`INTEGER*1'. Use of "absurd" values (such as `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.
-
-\1f
-File: g77.info, Node: Kind Notation, Prev: Star Notation, Up: Types
-
-Kind Notation
-.............
-
- The following notation specifies the kind-type selector of a type:
-
- GENERIC-TYPE(KIND=N)
-
-Use the above form where a type name is valid.
-
- GENERIC-TYPE must be a generic type--one of `INTEGER', `REAL',
-`COMPLEX', `LOGICAL', or `CHARACTER'. 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 `g77' _and_
-Fortran 90 implementations simpler.
-
- However, writing code that ports to existing FORTRAN 77
-implementations depends on avoiding the `KIND=' construct.
-
- The `KIND=' construct is thus useful in the context of GNU Fortran
-for two reasons:
-
- * 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).
-
- * It provides a sort of Rosetta stone for this document to use to
- concisely describe the types of various operations and operands.
-
- The values of N in the GNU Fortran language are assigned using a
-scheme that:
-
- * Attempts to maximize the ability of readers of this document to
- quickly familiarize themselves with assignments for popular types
-
- * Provides a unique value for each specific desired meaning
-
- * 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
-
- * Avoids using values that are similar to values used in the
- existing, popular `*N' notation, to prevent readers from expecting
- that these implied correspondences work on all GNU Fortran
- implementations
-
- 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 N that are
-the products of the values for those fundamental meanings.
-
- A prime value of 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 N assigned so far are:
-
-`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 `1D0 * 0.1_0' would be equivalent to `1D0 * 0.1D0'.
-
-`KIND=1'
- This corresponds to the default types for `REAL', `INTEGER',
- `LOGICAL', `COMPLEX', and `CHARACTER', as appropriate.
-
- These are the "default" types described in the Fortran 90 standard,
- though that standard does not assign any particular `KIND=' value
- to these types.
-
- (Typically, these are `REAL*4', `INTEGER*4', `LOGICAL*4', and
- `COMPLEX*8'.)
-
-`KIND=2'
- This corresponds to types that occupy twice as much storage as the
- default types. `REAL(KIND=2)' is `DOUBLE PRECISION' (typically
- `REAL*8'), `COMPLEX(KIND=2)' is `DOUBLE COMPLEX' (typically
- `COMPLEX*16'),
-
- These are the "double precision" types described in the Fortran 90
- standard, though that standard does not assign any particular
- `KIND=' value to these types.
-
- N of 4 thus corresponds to types that occupy four times as much
- storage as the default types, N of 8 to types that occupy eight
- times as much storage, and so on.
-
- The `INTEGER(KIND=2)' and `LOGICAL(KIND=2)' types are not
- necessarily supported by every GNU Fortran implementation.
-
-`KIND=3'
- This corresponds to types that occupy as much storage as the
- default `CHARACTER' type, which is the same effective type as
- `CHARACTER(KIND=1)' (making that type effectively the same as
- `CHARACTER(KIND=3)').
-
- (Typically, these are `INTEGER*1' and `LOGICAL*1'.)
-
- N of 6 thus corresponds to types that occupy twice as much storage
- as the N=3 types, 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.
-
-`KIND=5'
- This corresponds to types that occupy half the storage as the
- default (N=1) types.
-
- (Typically, these are `INTEGER*2' and `LOGICAL*2'.)
-
- 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.
-
-`KIND=7'
- This is valid only as `INTEGER(KIND=7)' and denotes the `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 `CHARACTER*1' variable, array, array element, or
- substring.
-
- (Typically this is equivalent to `INTEGER*4' or, on 64-bit
- systems, `INTEGER*8'. In a compatible C implementation, it
- typically would be the same size and semantics of the C type `void
- *'.)
-
- Note that these are _proposed_ correspondences and might change in
-future versions of `g77'--avoid writing code depending on them while
-`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:
-
- * Types that make use of only half their storage size for
- representing precision and range.
-
- For example, some compilers offer options that cause `INTEGER'
- types to occupy the amount of storage that would be needed for
- `INTEGER(KIND=2)' types, but the range remains that of
- `INTEGER(KIND=1)'.
-
- * The IEEE single floating-point type.
-
- * Types with a specific bit pattern (endianness), such as the
- little-endian form of `INTEGER(KIND=1)'. These could permit,
- conceptually, use of portable code and implementations on data
- files written by existing systems.
-
- Future _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 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.
-
-\1f
-File: g77.info, Node: Constants, Next: Integer Type, Prev: Types, Up: Data Types and Constants
-
-Constants
----------
-
- (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
-
- A "typeless constant" has one of the following forms:
-
- 'BINARY-DIGITS'B
- 'OCTAL-DIGITS'O
- 'HEXADECIMAL-DIGITS'Z
- 'HEXADECIMAL-DIGITS'X
-
-BINARY-DIGITS, OCTAL-DIGITS, and HEXADECIMAL-DIGITS are nonempty
-strings of characters in the set `01', `01234567', and
-`0123456789ABCDEFabcdef', respectively. (The value for `A' (and `a')
-is 10, for `B' and `b' is 11, and so on.)
-
- A prefix-radix constant, such as `Z'ABCD'', can optionally be
-treated as typeless. *Note Options Controlling Fortran Dialect:
-Fortran Dialect Options, for information on the `-ftypeless-boz' option.
-
- Typeless constants have values that depend on the context in which
-they are used.
-
- All other constants, called "typed constants", are
-interpreted--converted to internal form--according to their inherent
-type. Thus, context is _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, `1' is always type `INTEGER(KIND=1)' in GNU Fortran
-(called default INTEGER in Fortran 90), `9.435784839284958' is always
-type `REAL(KIND=1)' (even if the additional precision specified is
-lost, and even when used in a `REAL(KIND=2)' context), `1E0' is always
-type `REAL(KIND=2)', and `1D0' is always type `REAL(KIND=2)'.
-
-\1f
-File: g77.info, Node: Integer Type, Next: Character Type, Prev: Constants, Up: Data Types and Constants
-
-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:
-
- B'BINARY-DIGITS'
- O'OCTAL-DIGITS'
- Z'HEXADECIMAL-DIGITS'
- X'HEXADECIMAL-DIGITS'
-
-BINARY-DIGITS, OCTAL-DIGITS, and HEXADECIMAL-DIGITS are nonempty
-strings of characters in the set `01', `01234567', and
-`0123456789ABCDEFabcdef', respectively. (The value for `A' (and `a')
-is 10, for `B' and `b' is 11, and so on.)
-
-\1f
-File: g77.info, Node: Character Type, Prev: Integer Type, Up: Data Types and Constants
-
-Character Type
---------------
-
- (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
-
- A character constant may be delimited by a pair of double quotes
-(`"') 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.
-
- 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 `'hello'(3:5)' is the same as the value of `'llo''.
-
-\1f
-File: g77.info, Node: Expressions, Next: Specification Statements, Prev: Data Types and Constants, Up: Language
-
-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()::
-
-\1f
-File: g77.info, Node: %LOC(), Up: Expressions
-
-The `%LOC()' Construct
-----------------------
-
- %LOC(ARG)
-
- The `%LOC()' construct is an expression that yields the value of the
-location of its argument, ARG, in memory. The size of the type of the
-expression depends on the system--typically, it is equivalent to either
-`INTEGER(KIND=1)' or `INTEGER(KIND=2)', though it is actually type
-`INTEGER(KIND=7)'.
-
- The argument to `%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 `%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 `%LOC()' returning a pointer that can be safely
-used to _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 `g77'.
-
- Generally, `%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 `%LOC()'.
-
- _Implementation Note:_ Currently, `g77' passes arguments (those not
-passed using a construct such as `%VAL()') by reference or descriptor,
-depending on the type of the actual argument. Thus, given `INTEGER I',
-`CALL FOO(I)' would seem to mean the same thing as `CALL
-FOO(%VAL(%LOC(I)))', and in fact might compile to identical code.
-
- However, `CALL FOO(%VAL(%LOC(I)))' emphatically means "pass, by
-value, the address of `I' in memory". While `CALL FOO(I)' might use
-that same approach in a particular version of `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 `CALL
-FOO(%VAL(%LOC(I)))' using the same version or compiler.
-
- *Note Debugging and Interfacing::, for detailed information on how
-this particular version of `g77' implements various constructs.
-
-\1f
-File: g77.info, Node: Specification Statements, Next: Control Statements, Prev: Expressions, Up: Language
-
-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::
-
-\1f
-File: g77.info, Node: NAMELIST, Next: DOUBLE COMPLEX, Up: Specification Statements
-
-`NAMELIST' Statement
---------------------
-
- The `NAMELIST' statement, and related I/O constructs, are supported
-by the GNU Fortran language in essentially the same way as they are by
-`f2c'.
-
- This follows Fortran 90 with the restriction that on `NAMELIST'
-input, subscripts must have the form
- SUBSCRIPT [ `:' SUBSCRIPT [ `:' STRIDE]]
- i.e.
- &xx x(1:3,8:10:2)=1,2,3,4,5,6/
- is allowed, but not, say,
- &xx x(:3,8::2)=1,2,3,4,5,6/
-
- As an extension of the Fortran 90 form, `$' and `$END' may be used
-in place of `&' and `/' in `NAMELIST' input, so that
- $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
- could be used instead of the example above.
-
-\1f
-File: g77.info, Node: DOUBLE COMPLEX, Prev: NAMELIST, Up: Specification Statements
-
-`DOUBLE COMPLEX' Statement
---------------------------
-
- `DOUBLE COMPLEX' is a type-statement (and type) that specifies the
-type `COMPLEX(KIND=2)' in GNU Fortran.
-
-\1f
-File: g77.info, Node: Control Statements, Next: Functions and Subroutines, Prev: Specification Statements, Up: Language
-
-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::
-
-\1f
-File: g77.info, Node: DO WHILE, Next: END DO, Up: Control Statements
-
-DO WHILE
---------
-
- The `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 `DO' is also
-supported.
-
-\1f
-File: g77.info, Node: END DO, Next: Construct Names, Prev: DO WHILE, Up: Control Statements
-
-END DO
-------
-
- The `END DO' statement is provided by the GNU Fortran language.
-
- This statement is used in one of two ways:
-
- * The Fortran 90 meaning, in which it specifies the termination
- point of a single `DO' loop started with a `DO' statement that
- specifies no termination label.
-
- * The MIL-STD 1753 meaning, in which it specifies the termination
- point of one or more `DO' loops, all of which start with a `DO'
- statement that specify the label defined for the `END DO'
- statement.
-
- This kind of `END DO' statement is merely a synonym for
- `CONTINUE', except it is permitted only when the statement is
- labeled and a target of one or more labeled `DO' loops.
-
- It is expected that this use of `END DO' will be removed from the
- GNU Fortran language in the future, though it is likely that it
- will long be supported by `g77' as a dialect form.
-
-\1f
-File: g77.info, Node: Construct Names, Next: CYCLE and EXIT, Prev: END DO, Up: Control Statements
-
-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:
-
- CONSTRUCT-NAME: BLOCK-STATEMENT
-
-Here, CONSTRUCT-NAME is the construct name itself; its definition is
-connoted by the single colon (`:'); and BLOCK-STATEMENT is an `IF',
-`DO', or `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:
-
- END BLOCK CONSTRUCT-NAME
-
-Here, BLOCK must be `IF', `DO', or `SELECT', as appropriate.
-
-\1f
-File: g77.info, Node: CYCLE and EXIT, Prev: Construct Names, Up: Control Statements
-
-The `CYCLE' and `EXIT' Statements
----------------------------------
-
- The `CYCLE' and `EXIT' statements specify that the remaining
-statements in the current iteration of a particular active (enclosing)
-`DO' loop are to be skipped.
-
- `CYCLE' specifies that these statements are skipped, but the `END
-DO' statement that marks the end of the `DO' loop be executed--that is,
-the next iteration, if any, is to be started. If the statement marking
-the end of the `DO' loop is not `END DO'--in other words, if the loop
-is not a block `DO'--the `CYCLE' statement does not execute that
-statement, but does start the next iteration (if any).
-
- `EXIT' specifies that the loop specified by the `DO' construct is
-terminated.
-
- The `DO' loop affected by `CYCLE' and `EXIT' is the innermost
-enclosing `DO' loop when the following forms are used:
-
- CYCLE
- EXIT
-
- Otherwise, the following forms specify the construct name of the
-pertinent `DO' loop:
-
- CYCLE CONSTRUCT-NAME
- EXIT CONSTRUCT-NAME
-
- `CYCLE' and `EXIT' can be viewed as glorified `GO TO' statements.
-However, they cannot be easily thought of as `GO TO' statements in
-obscure cases involving FORTRAN 77 loops. For example:
-
- 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
-
-In particular, neither the `EXIT' nor `CYCLE' statements above are
-equivalent to a `GO TO' statement to either label `10' or `20'.
-
- To understand the effect of `CYCLE' and `EXIT' in the above
-fragment, it is helpful to first translate it to its equivalent using
-only block `DO' loops:
-
- 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
-
- Adding new labels allows translation of `CYCLE' and `EXIT' to `GO
-TO' so they may be more easily understood by programmers accustomed to
-FORTRAN coding:
-
- 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
-
-Thus, the `CYCLE' statement in the innermost loop skips over the
-`PRINT' statement as it begins the next iteration of the loop, while
-the `EXIT' statement in the middle loop ends that loop but _not_ the
-outermost loop.
-
-\1f
-File: g77.info, Node: Functions and Subroutines, Next: Scope and Classes of Names, Prev: Control Statements, Up: Language
-
-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::
-
-\1f
-File: g77.info, Node: %VAL(), Next: %REF(), Up: Functions and Subroutines
-
-The `%VAL()' Construct
-----------------------
-
- %VAL(ARG)
-
- The `%VAL()' construct specifies that an argument, ARG, is to be
-passed by value, instead of by reference or descriptor.
-
- `%VAL()' is restricted to actual arguments in invocations of
-external procedures.
-
- Use of `%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.
-
- _Implementation Note:_ Currently, `g77' passes all arguments either
-by reference or by descriptor.
-
- Thus, use of `%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.)
-
- *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
-information on how this particular version of `g77' passes arguments to
-procedures.
-
-\1f
-File: g77.info, Node: %REF(), Next: %DESCR(), Prev: %VAL(), Up: Functions and Subroutines
-
-The `%REF()' Construct
-----------------------
-
- %REF(ARG)
-
- The `%REF()' construct specifies that an argument, ARG, is to be
-passed by reference, instead of by value or descriptor.
-
- `%REF()' is restricted to actual arguments in invocations of
-external procedures.
-
- Use of `%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 `%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,
-ARG. (For example, a copy-in/copy-out implementation.)
-
- _Implementation Note:_ Currently, `g77' passes all arguments (other
-than variables and arrays of type `CHARACTER') by reference. Future
-versions of, or dialects supported by, `g77' might not pass `CHARACTER'
-functions by reference.
-
- Thus, use of `%REF()' tends to be restricted to cases where ARG is
-type `CHARACTER' but the called procedure accesses it via a means other
-than the method used for Fortran `CHARACTER' arguments.
-
- *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
-information on how this particular version of `g77' passes arguments to
-procedures.
-
-\1f
-File: g77.info, Node: %DESCR(), Next: Generics and Specifics, Prev: %REF(), Up: Functions and Subroutines
-
-The `%DESCR()' Construct
-------------------------
-
- %DESCR(ARG)
-
- The `%DESCR()' construct specifies that an argument, ARG, is to be
-passed by descriptor, instead of by value or reference.
-
- `%DESCR()' is restricted to actual arguments in invocations of
-external procedures.
-
- Use of `%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 `%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, ARG. (For example, a copy-in/copy-out implementation.)
-And, future versions of `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.
-
- _Implementation Note:_ Currently, `g77' passes all variables and
-arrays of type `CHARACTER' by descriptor. Future versions of, or
-dialects supported by, `g77' might pass `CHARACTER' functions by
-descriptor as well.
-
- Thus, use of `%DESCR()' tends to be restricted to cases where ARG is
-not type `CHARACTER' but the called procedure accesses it via a means
-similar to the method used for Fortran `CHARACTER' arguments.
-
- *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
-information on how this particular version of `g77' passes arguments to
-procedures.
-
projects / msp430-gcc.git / blobdiff