| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
http://www.fortran.com/fortran/F77_std/rjcnf0001.html
or as monolithic text at
http://www.fortran.com/fortran/F77_std/f77_std.html.
It offers some extensions that are popular among users
of UNIX f77 and 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.
(If you need a text on Fortran,
a few freely available electronic references have pointers from
http://www.fortran.com/fortran/Books/. There is a `cooperative
net project', User Notes on Fortran Programming at
ftp://vms.huji.ac.il/fortran/ and mirrors elsewhere; some of this
material might not apply specifically to g77.)
Part of what defines a particular implementation of a Fortran
system, such as 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 language is described below. Much of the material is organized along the same lines as the ANSI FORTRAN 77 standard itself.
See section 11. Other Dialects, for information on features g77 supports
that are not part of the GNU Fortran language.
Note: This portion of the documentation definitely needs a lot of work!
Relationship to the ANSI FORTRAN 77 standard:
10.1 Direction of Language Development Where GNU Fortran is headed. 10.2 ANSI FORTRAN 77 Standard Support Degree of support for the standard.
Extensions to the ANSI FORTRAN 77 standard:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 g77 itself is in beta test.
Some current features of the language might later
be redefined as dialects of Fortran supported by g77
when better ways to express these features are added to g77,
for example.
Such features would still be supported by
g77, but would be available only when
one or more command-line options were used.
The GNU Fortran language is distinct from the
GNU Fortran compilation system (g77).
For example, 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 g77 accepts
when compiling using the prevailing defaults and what this
document describes as being part of the language.
Future versions of 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 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 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:
f77.
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 g77 can use to resolve
conflicts between various camps of Fortran users.
If these two camps disagree about what a particular construct should
mean, 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.
See section 18.5.1 Backslash in Constants.
Other examples are likely to arise in the future, as 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 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 g77).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
In summary, the only ANSI FORTRAN 77 features 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.
10.2.1 No Passing External Assumed-length CHAR*(*) CFUNC restriction. 10.2.2 No Passing Dummy Assumed-length CHAR*(*) CFUNC restriction. 10.2.3 No Pathological Implied-DO No `((..., I=...), I=...)'. 10.2.4 No Useless Implied-DO No `(A, I=1, 1)'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
g77 disallows passing of an external procedure
as an actual argument if the procedure's
type is declared CHARACTER*(*). For example:
CHARACTER*(*) CFUNC EXTERNAL CFUNC CALL FOO(CFUNC) END |
It isn't clear whether the standard considers this conforming.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
g77 disallows passing of a dummy procedure
as an actual argument if the procedure's
type is declared CHARACTER*(*).
SUBROUTINE BAR(CFUNC) CHARACTER*(*) CFUNC EXTERNAL CFUNC CALL FOO(CFUNC) END |
It isn't clear whether the standard considers this conforming.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The DO variable for an implied-DO construct in a
DATA statement may not be used as the DO variable
for an outer implied-DO construct. For example, this
fragment is disallowed by g77:
DATA ((A(I, I), I= 1, 10), I= 1, 10) /.../ |
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 very unlikely that any production Fortran code tries to use this unsupported construct.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An array element initializer in an implied-DO construct in a
DATA statement must contain at least one reference to the DO
variables of each outer implied-DO construct. For example,
this fragment is disallowed by g77:
DATA (A, I= 1, 1) /1./ |
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities.
However, g77 doesn't necessarily diagnose all cases
where this requirement is not met.
Note that it is very unlikely that any production Fortran code tries to use this unsupported construct.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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, 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 g77
system, perform as described by the GNU Fortran language definition.
Reasons for different behavior include, among others:
g77.
Despite these "loopholes", the availability of a clear specification
of the language of programs submitted to 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 g77 system) that supports
this language, the program should behave in a largely predictable way".
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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:
``The |
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 FROBNITZ statement--does not pertain the GNU Fortran
language itself.
That content offers advice and warnings about the FROBNITZ
statement.
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 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 not a valid GNU Fortran program.
Such input is said to have 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:
COMMON, INTEGER, and
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.
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: `PRINT *, 'My name is Bob''.
"The INTEGER ivar statement specifies that
ivar is a variable or array of type INTEGER."
In the above example, any valid text may be substituted for the metasyntactic variable ivar to make the statement apply to a specific instance, as long as the same text is substituted for both occurrences of ivar.
See section 10.7.1.3 Kind Notation, for information on the relationship
between Fortran 90 nomenclature (such as INTEGER(KIND=1))
and the more traditional, less portably concise nomenclature
(such as INTEGER*4).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
10.5.1 Syntactic Items 10.5.2 Statements, Comments, and Lines 10.5.3 Scope of Symbolic Names and Statement Labels
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
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 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 (`_') are accepted in symbol names after the first character (which must be a letter).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
Use of an exclamation point (`!') to begin a trailing comment (a comment that extends to the end of the same source line) is permitted under the following conditions:
Use of a semicolon (`;') as a statement separator is permitted under the following conditions:
IF statement nor a non-construct
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:
IF (VALIDP) CALL FOO; CALL BAR |
Some readers might think the `CALL BAR' is executed
only if `VALIDP' is .TRUE., while others might
assume its execution is unconditional.
(At present, g77 does not diagnose code that
violates this restriction.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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). See section 10.10.3 Construct Names, for more information.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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:
Note that this document refers to SPC as space, while X3.9-1978 FORTRAN 77 refers to it as blank.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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:
EOF) also serves to end the line
of text that precedes it (and that does not contain a newline).
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
A continuation line is any line that both
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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:
A statement may have only one label defined for it.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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:
END PROGRAM statement, if the program unit is a main program.
END SUBROUTINE statement, if the program unit is a subroutine.
END FUNCTION statement, if the program unit is a function.
END BLOCK DATA statement, if the program unit is a block data.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
cpp output-style # directives
(see section `C Preprocessor Output' in The C Preprocessor)
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.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.
10.7.1 Data Types 10.7.2 Constants 10.7.3 Integer Type 10.7.4 Character Type
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
GNU Fortran supports these types:
INTEGER)
REAL)
COMPLEX)
LOGICAL)
CHARACTER)
(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.
10.7.1.1 Double Notation As in DOUBLE COMPLEX.10.7.1.2 Star Notation As in INTEGER*4.10.7.1.3 Kind Notation As in INTEGER(KIND=1).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
The values of n in the GNU Fortran language are assigned using a scheme that:
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
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
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
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
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
(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
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:
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).
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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. See section Options Controlling Fortran Dialect, 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).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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''.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
10.8.1 The %LOC()Construct
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
%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.
See section 16. Debugging and Interfacing, for detailed information on
how this particular version of g77 implements various
constructs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
10.9.1 NAMELISTStatement10.9.2 DOUBLE COMPLEXStatement
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 [ |
&xx x(1:3,8:10:2)=1,2,3,4,5,6/ |
&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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
DOUBLE COMPLEX Statement
DOUBLE COMPLEX is a type-statement (and type) that
specifies the type COMPLEX(KIND=2) in GNU Fortran.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
10.10.1 DO WHILE 10.10.2 END DO 10.10.3 Construct Names 10.10.4 The CYCLEandEXITStatements
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The END DO statement is provided by the GNU Fortran language.
This statement is used in one of two ways:
DO loop started with a DO statement
that specifies no termination label.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(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.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
%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.)
See section Procedures (SUBROUTINE and FUNCTION),
for detailed information on
how this particular version of g77 passes arguments
to procedures.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
%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.
See section Procedures (SUBROUTINE and FUNCTION), for detailed information on
how this particular version of g77 passes arguments
to procedures.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
%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.