Go to the first, previous, next, last section, table of contents.
Fortran implementations have a fair amount of freedom given them by the
standard as far as how much storage space is used and how much precision
and range is offered by the various types such as LOGICAL(KIND=1)
,
INTEGER(KIND=1)
, REAL(KIND=1)
, REAL(KIND=2)
,
COMPLEX(KIND=1)
, and CHARACTER
.
Further, many compilers offer so-called `*n' notation, but
the interpretation of n varies across compilers and target architectures.
The standard requires that LOGICAL(KIND=1)
, INTEGER(KIND=1)
,
and REAL(KIND=1)
occupy the same amount of storage space, and that COMPLEX(KIND=1)
and REAL(KIND=2)
take twice as much storage space as REAL(KIND=1)
.
Further, it requires that COMPLEX(KIND=1)
entities be ordered such that when a COMPLEX(KIND=1)
variable is
storage-associated (such as via EQUIVALENCE
)
with a two-element REAL(KIND=1)
array named `R', `R(1)'
corresponds to the real element and `R(2)' to the imaginary
element of the COMPLEX(KIND=1)
variable.
(Few requirements as to precision or ranges of any of these are
placed on the implementation, nor is the relationship of storage sizes of
these types to the CHARACTER
type specified, by the standard.)
g77
follows the above requirements, warning when compiling
a program requires placement of items in memory that contradict the
requirements of the target architecture.
(For example, a program can require placement of a REAL(KIND=2)
on a boundary that is not an even multiple of its size, but still an
even multiple of the size of a REAL(KIND=1)
variable.
On some target architectures, using the canonical
mapping of Fortran types to underlying architectural types, such
placement is prohibited by the machine definition or
the Application Binary Interface (ABI) in force for
the configuration defined for building gcc
and g77
.
g77
warns about such
situations when it encounters them.)
g77
follows consistent rules for configuring the mapping between Fortran
types, including the `*n' notation, and the underlying architectural
types as accessed by a similarly-configured applicable version of the
gcc
compiler.
These rules offer a widely portable, consistent Fortran/C
environment, although they might well conflict with the expectations of
users of Fortran compilers designed and written for particular
architectures.
These rules are based on the configuration that is in force for the
version of gcc
built in the same release as g77
(and
which was therefore used to build both the g77
compiler
components and the libg2c
run-time library):
REAL(KIND=1)
float
type.
REAL(KIND=2)
float
---usually, this is a double
.
INTEGER(KIND=1)
float
---usually, this is either
an int
or a long int
.
LOGICAL(KIND=1)
gcc
type as INTEGER(KIND=1)
.
INTEGER(KIND=2)
INTEGER(KIND=1)
---usually, this is either
a long int
or a long long int
.
LOGICAL(KIND=2)
gcc
type as INTEGER(KIND=2)
.
INTEGER(KIND=3)
gcc
type as signed char
.
LOGICAL(KIND=3)
gcc
type as INTEGER(KIND=3)
.
INTEGER(KIND=6)
INTEGER(KIND=3)
---usually, this is
a short
.
LOGICAL(KIND=6)
gcc
type as INTEGER(KIND=6)
.
COMPLEX(KIND=1)
REAL(KIND=1)
scalars (one for the real part followed by
one for the imaginary part).
COMPLEX(KIND=2)
REAL(KIND=2)
scalars.
numeric-type*n
CHARACTER
.)
Same as whatever gcc
type occupies n times the storage
space of a gcc
char
item.
DOUBLE PRECISION
REAL(KIND=2)
.
DOUBLE COMPLEX
COMPLEX(KIND=2)
.
Note that the above are proposed correspondences and might change
in future versions of g77
---avoid writing code depending
on them.
Other types supported by g77
are derived from gcc types such as char
, short
,
int
, long int
, long long int
, long double
,
and so on.
That is, whatever types gcc
already supports, g77
supports
now or probably will support in a future version.
The rules for the `numeric-type*n' notation
apply to these types,
and new values for `numeric-type(KIND=n)' will be
assigned in a way that encourages clarity, consistency, and portability.
Go to the first, previous, next, last section, table of contents.