Next: , Previous: Run-time Environment Limits, Up: Compiler


10.3 Compiler Types

Fortran implementations have a fair amount of freedom given them by the standard as far as how much storage space is used and how much precision and range is offered by the various types such as 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)
Same as float type.


REAL(KIND=2)
Same as whatever floating-point type that is twice the size of a float—usually, this is a double.


INTEGER(KIND=1)
Same as an integral type that is occupies the same amount of memory storage as float—usually, this is either an int or a long int.


LOGICAL(KIND=1)
Same gcc type as INTEGER(KIND=1).


INTEGER(KIND=2)
Twice the size, and usually nearly twice the range, as INTEGER(KIND=1)—usually, this is either a long int or a long long int.


LOGICAL(KIND=2)
Same gcc type as INTEGER(KIND=2).


INTEGER(KIND=3)
Same gcc type as signed char.


LOGICAL(KIND=3)
Same gcc type as INTEGER(KIND=3).


INTEGER(KIND=6)
Twice the size, and usually nearly twice the range, as INTEGER(KIND=3)—usually, this is a short.


LOGICAL(KIND=6)
Same gcc type as INTEGER(KIND=6).


COMPLEX(KIND=1)
Two REAL(KIND=1) scalars (one for the real part followed by one for the imaginary part).


COMPLEX(KIND=2)
Two REAL(KIND=2) scalars.


numeric-type*n
(Where numeric-type is any type other than CHARACTER.) Same as whatever gcc type occupies n times the storage space of a gcc char item.


DOUBLE PRECISION
Same as REAL(KIND=2).


DOUBLE COMPLEX
Same as 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.