An INTEGER statement declares the names of entities to be of type integer. If a kind selector is present, it specifies the representation method. For more information on integer type, see “Integer Type” in Chapter 4.

The CF90 and MIPSpro 7 Fortran 90 compilers support the following formats for declaring objects of this type:

INTEGER [([ KIND = ]kind_param) ][[ , attribute_list] :: ]entity_list
INTEGER * length_value[[ , attribute_list] :: ]entity_list

For kind_param values, see “Integer Type” in Chapter 4. The length_value values correspond to the kind_param values and are as follows:

The following are examples of entity-oriented declaration statements:

INTEGER, DIMENSION(:), POINTER :: MILES, HOURS
INTEGER(SHORT), POINTER :: RATE, INDEX

The following are examples of attribute-oriented declaration statements:

INTEGER :: MILES, HOURS
INTEGER(SHORT) :: RATE, INDEX
DIMENSION :: MILES(:), HOURS(:)
POINTER :: MILES, HOURS, RATE, INDEX

---

Note: The Fortran standard does not specify the INTEGER*length_value syntax. It is recommended that this syntax not be used in any new code.

---

A REAL statement declares the names of entities to be of type real. If a kind selector is present, it specifies the representation method. For more information on real type, see “Real Type” in Chapter 4.

The CF90 and MIPSpro 7 Fortran 90 compilers support the following formats for declaring objects of this type:

REAL [ ([ KIND = ]kind_param) ][[ , attribute_list] :: ]entity_list
REAL * length_value[[ , attribute_list] :: ]entity_list

For kind_param values, see “Real Type” in Chapter 4. The length_value values correspond to the kind_param values and are as follows:

The following examples show entity-oriented declaration statements:

REAL(KIND = HIGH), OPTIONAL :: VARIANCE
REAL, SAVE :: A1(10, 10), A2(100, 10, 10)

The following examples show attribute-oriented declaration statements:

REAL(KIND = HIGH) VARIANCE
REAL A1(10, 10), A2(100, 10, 10)
OPTIONAL VARIANCE
SAVE A1, A2

---

Note: The Fortran standard does not specify the REAL*length_value syntax. It is recommended that this syntax not be used in any new code.

---

A DOUBLE PRECISION statement declares the names of entities to be of real type with a representation method that represents more precision than the default real representation. The DOUBLE PRECISION statement is outmoded because REAL with the appropriate kind parameter value is equivalent. A kind selector is not permitted in the DOUBLE PRECISION statement. For more information on the real data type, see “Real Type” in Chapter 4.

The CF90 and MIPSpro 7 Fortran 90 compilers support the following formats for declaring objects of this type:

DOUBLE PRECISION [[ , attribute_list] :: ]entity_list
DOUBLE PRECISION * 16 [[, attribute_list] :: ]entity_list

The following examples show entity-oriented declaration statements:

DOUBLE PRECISION, DIMENSION(N,N) :: MATRIX_A, MATRIX_B
DOUBLE PRECISION, POINTER :: C, D, E, F(:, :)

The following examples show attribute-oriented declaration statements:

DOUBLE PRECISION :: MATRIX_A, MATRIX_B, C, D, E, F
DIMENSION :: MATRIX_A(N, N), MATRIX_B(N, N), F(:, :)
POINTER :: C, D, E, F

If DOUBLE is a named integer constant that has the value of the kind parameter of the double-precision real type on the target platform, the preceding entity-oriented declaration statements could be written as follows:

REAL (DOUBLE), DIMENSION (N,N) :: MATRIX_A, MATRIX_B
REAL (DOUBLE), POINTER :: C, D, E, F(:,:)

---

Note: The Fortran standard does not specify the DOUBLE PRECISION*16 syntax. It is recommended that this syntax not be used in any new code.

---

A COMPLEX statement declares the names of entities to be of type complex. If a kind selector is present, it specifies the representation method. For more information on complex type, see “Complex Type” in Chapter 4.

The CF90 and MIPSpro 7 Fortran 90 compilers support the following formats for declaring objects of this type:

COMPLEX [([ KIND = ]kind_param)][[ , attribute_list] :: ]entity_list
COMPLEX * length_value[[, attribute_list] :: ]entity_list

For kind_param values, see “Complex Type” in Chapter 4. The length_value values correspond to the kind_param values in the following manner:

The following examples show entity-oriented declaration statements:

COMPLEX(KIND = LOW), POINTER :: ROOTS(:)
COMPLEX, POINTER :: DISCRIMINANT, COEFFICIENTS(:)

The following examples show attribute-oriented declaration statements:

COMPLEX(KIND = LOW) :: ROOTS(:)
COMPLEX :: DISCRIMINANT, COEFFICIENTS(:)
POINTER :: ROOTS, DISCRIMINANT, COEFFICIENTS

---

Note: The Fortran standard does not specify the COMPLEX*length_value syntax. It is recommended that this syntax not be used in any new code.

---

A LOGICAL statement declares the names of entities to be of type logical. If a kind selector is present, it specifies the representation method. For more information on logical type, see “Logical Type” in Chapter 4.

The CF90 and MIPSpro 7 Fortran 90 compilers support the following formats for declaring objects of this type:

LOGICAL [ ([ KIND = ]kind_param)][[, attribute_list] :: ]entity_list
LOGICAL * length_value[[, attribute_list] :: ]entity_list

For kind_param values, see “Logical Type” in Chapter 4. The length_value values correspond to the kind_param values in the following manner:

The following examples show entity-oriented declaration statements:

LOGICAL, ALLOCATABLE :: MASK_1(:), MASK_2(:)
LOGICAL(KIND = WORD), SAVE :: INDICATOR, STATUS

The following examples show attribute-oriented declaration statements:

LOGICAL MASK_1(:), MASK_2(:)
LOGICAL (KIND = WORD) INDICATOR, STATUS
ALLOCATABLE MASK_1, MASK_2
SAVE INDICATOR, STATUS

---

Note: The Fortran standard does not specify the LOGICAL*length_value syntax. It is recommended that this syntax not be used in any new code.

---

A CHARACTER statement declares the names of entities to be of type character. For more information on character type, see “Character Type” in Chapter 4.

The following is a format for declaring objects of this type:

CHARACTER [char_selector][[ , attribute_list] :: ]entity_list

The components of this format are defined as follows:

length_selector

(LEN = type_param_value, KIND = kind_value)

(type_param_value, [ KIND = ]kind_value)

(KIND = kind_value[, LEN = type_param_value])

([ LEN = ]type_param_value)

* char_length[ , ]

(type_param_value)

scalar_int_literal_constant

specification_expr

*

The optional comma in a length_selector is permitted only if no double colon separator appears in the type declaration statement.

A character type declaration can specify a character length that is a nonconstant expression if it appears in a procedure or a procedure interface if it is not a component declaration in a derived-type definition. The length is determined on entry into the procedure and is not affected by any changes in the values of variables in the expression during the execution of the procedure. A character object declared this way that is not a dummy argument is called an automatic data object.

The length of a named character entity or a character component in a type definition is specified by the character selector in the type specification unless there is a character length in an entity or component declaration; if so, the character length specifies an individual length and overrides the length in the character selector. If a length is not specified in either a character selector or a character length, the length is 1.

If the length parameter has a negative value, the length of the character entity is 0.

If a scalar integer literal constant is used to specify a character length, it must not include a kind parameter. (This could produce an ambiguity when fixed source form is used.)

A length parameter value of * can be used only in the following ways:

A function name must not be declared with a length of * if the function is an internal or module function; or if it is array-valued, pointer-valued, or recursive; or if it is a PURE function.

An interface body can be specified for a dummy or external function whose result is of type CHAR*(*) only if the function is not invoked. This is because the characteristics must match in both places.

The length of a character-valued statement function or statement function dummy argument of type character must be an integer constant expression.

The following examples show entity-oriented character type declaration statements:

CHARACTER(LEN = 10, KIND = ASCII), SAVE :: GREETING(2)
CHARACTER(10) :: PROMPT = "PASSWORD?"
CHARACTER(*), INTENT(IN) :: HOME_TEAM, VISITORS
CHARACTER*(3), SAVE :: NORMAL_1, LONGER(9)*20, NORMAL_2
CHARACTER :: GRADE = "A"

The following examples show attribute-oriented character type declaration statements:

CHARACTER(LEN = 10, KIND = ASCII) :: GREETING
CHARACTER(10) :: PROMPT
CHARACTER(*) :: HOME_TEAM, VISITORS
CHARACTER*(3) :: NORMAL_1, LONGER*20, NORMAL_2
CHARACTER GRADE
SAVE :: GREETING, NORMAL_1, LONGER, NORMAL_2
DIMENSION GREETING(2), LONGER(9)
INTENT(IN) :: HOME_TEAM, VISITORS
DATA PROMPT / "PASSWORD?" /, GRADE / "A" /

A TYPE declaration statement declares the names of entities to be of the specified user-defined type. The type name appears in parentheses following the keyword TYPE. For more information on derived types, see “Derived Types” in Chapter 4.

The following is a format for declaring objects of user-defined type:

TYPE (type_name) [[ , attribute_list] :: ]entity_list

The following examples show entity-oriented derived type declaration statements:

TYPE(COLOR), DIMENSION(:), ALLOCATABLE :: HUES_OF_RED
TYPE(PERSON), SAVE :: CAR_POOL(3)
TYPE(PARAGRAPH), SAVE :: OVERVIEW, SUBSTANCE, SUMMARY

The following examples show attribute-oriented derived type declaration statements:

TYPE(COLOR) :: HUES_OF_RED
TYPE(PERSON) :: CAR_POOL(3)
TYPE(PARAGRAPH) :: OVERVIEW, SUBSTANCE, SUMMARY
DIMENSION :: HUES_OF_RED(:)
ALLOCATABLE :: HUES_OF_RED
SAVE :: CAR_POOL, OVERVIEW, SUBSTANCE, SUMMARY

An object of derived type (a structure) must not have the PUBLIC attribute if its type is private.

A structure constructor must be used to initialize an object of derived type. Each component of the structure constructor must be an initialization expression. For more information on structure constructors, see “Structure Constructors” in Chapter 4.

---

Note: : Variables declared to be Cray pointers and pointees through the Cray POINTER statement cannot be declared as components of derived types.

---

The Cray POINTER statement declares one variable to be a Cray pointer (that is, to have the Cray pointer data type) and another variable to be its pointee; that is, the value of the Cray pointer is the address of the pointee. This statement has the following format:

POINTER (pointer_name, pointee_name[ (array_spec) ])
[, (pointer_name, pointee_name [ (array_spec) ])] ...

Example:

POINTER(P,B),(Q,C)

This statement declares Cray pointer P and its pointee B, and Cray pointer Q and pointee C; the pointer's current value is used as the address of the pointee whenever the pointee is referenced.

An array that is named as a pointee in a Cray POINTER statement is a pointee array. Its array declarator can appear in a separate type or DIMENSION statement or in the pointer list itself. In a subprogram, the dimension declarator can contain references to variables in a common block or to dummy arguments. As with nonconstant bound array arguments to subprograms, the size of each dimension is evaluated on entrance to the subprogram, not when the pointee is referenced. For example:

POINTER(IX, X(N,0:M))

---

Note: The Fortran standard does not specify the Cray POINTER statement or data type. Variables declared to be pointers and pointees through the Cray POINTER statement cannot be declared as components of derived types.

---

In addition, pointees must not be deferred-shape or assumed-shape arrays. An assumed-size pointee array is not allowed in a main program unit.

To define a character pointer, use the CLOC(3i) intrinsic function. (The LOC(3i) intrinsic function returns only the word address.)

The FCD(3i) function can also be used to construct a Cray character pointer. FCD(3i) has two integer arguments:

On UNICOS and UNICOS/mk systems, if the pointee does not begin on a word boundary, the character offset can be added to the FCD(3i) result.

---

Note: : Intrinsic functions CLOC(3i) and FCD(3i) are not part of the Fortran standard.

---

The size of a Fortran Character Descriptor (FCD) and of a Cray character pointer depends on your platform, so Cray character pointers should not be equivalenced or storage-associated. For more information on FCDs, see FCD(3i).

Example:

CPTR = FCD(IADRS,ILEN) + IOFFSET

On UNICOS and UNICOS/mk systems, Cray character pointers are not optimized. Statements containing them are not vectorized or Autotasked.

The following operations are the only ones allowed with Cray character pointers, where cp is a character pointer and i is an integer. Arithmetic is in bytes (characters), not words or bits:

There are four formats that an array_spec can take:

explicit_shape_spec_list

assumed_shape_spec_list

deferred_shape_spec_list

assumed_size_spec

The maximum rank of an array is 7. A scalar is considered to have rank 0.

An array with a deferred_shape_spec_list must have the POINTER or ALLOCATABLE attribute.

An array with an assumed_shape_spec_list or an assumed_size_spec must be a dummy argument.

lower_bound : upper_bound

specification_expr

specification_expr

REAL Q(-10:10, -10:10, 2)  ! in a main program

SUBROUTINE EX1(Z, I, J)             ! in a
  REAL, DIMENSION(2:I + 1, J) :: Z  ! subroutine

REAL Q
DIMENSION Q(-10:10, -10:10, 2)  ! in a main program

SUBROUTINE EX1(Z, I, J)    ! in
   REAL Z                  ! a
   DIMENSION Z(2:I + 1, J) ! subroutine

[lower_bound] :

REAL, DIMENSION(2:, :) :: X

SUBROUTINE EX2(A, B, X)
   REAL A(:), B(0:), X
   DIMENSION X(2:, :)
   INTENT(IN) A, B
      . . .  

CALL EX2(U, V, W(4:9, 2:6))

:

REAL, POINTER :: D(:, :), P(:) ! array pointers
REAL, ALLOCATABLE :: E(:)      ! allocatable array

REAL D
DIMENSION D(:, :), P(:), E(:)
POINTER D, P
ALLOCATABLE E

[explicit_shape_spec_list, ][lower_bound : ] *

SUBROUTINE EX3(N, S, Y)
   REAL, DIMENSION(N, *) :: S
   REAL Y(10, 5, *)
      . . .  

SUBROUTINE EX3(N, S, Y)
   REAL S, Y
   DIMENSION S(N, *), Y(10, 5, *)
      . . .  

The dimensions of an array can be specified by the appearance of a DIMENSION attribute or by the appearance of an array specification following the name of the array in a type declaration statement. Both a DIMENSION attribute and an array specification following the name can appear in a declaration statement. In this case, the array specification following the name overrides the array specification following the DIMENSION attribute. A format for a type declaration statement with a DIMENSION attribute is as follows:

type, DIMENSION (array_spec) [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The type declaration can also contain an initialization_expr. An array specification can also appear following a name in several different kinds of statements to declare an array. They are DIMENSION, ALLOCATABLE, POINTER, TARGET, and COMMON statements.

The DIMENSION statement is the statement form of the DIMENSION attribute and is defined as follows:

DIMENSION [ :: ]array_name (array_spec)
[, array_name (array_spec) ] ...

The DIMENSION statement also confers the DIMENSION attribute. It is subject to the same rules and restrictions as the DIMENSION attribute.

The following examples show entity-oriented declarations:

INTEGER, DIMENSION(10), TARGET, SAVE :: INDICES
INTEGER, ALLOCATABLE, TARGET :: LG(:, :, :)

The following examples show attribute-oriented declarations:

INTEGER INDICES, LG(:, :, :)
DIMENSION INDICES(10)
TARGET INDICES, LG
ALLOCATABLE LG
SAVE INDICES

The following examples show the array specification in other statements:

INTEGER INDICES, LG
TARGET INDICES(10), LG
ALLOCATABLE LG(:, :, :)
SAVE INDICES

The following example shows the array specification in a COMMON statement:

COMMON /UNIVERSAL/ TIME(80), SPACE(20, 20, 20, 20)

Arrays are the only objects that can have the ALLOCATABLE attribute. An allocatable array is one for which the bounds are determined when an ALLOCATE statement is executed for the array. These arrays must be deferred-shape arrays. The following is a format for a type declaration statement with an ALLOCATABLE attribute:

type, ALLOCATABLE [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The format of the ALLOCATABLE statement is defined as follows:

ALLOCATABLE [::]array_name[ (deferred_shape_spec_list)]
[ ,array_name[ (deferred_shape_spec_list) ]] ...

The array must not be a dummy argument or function result.

If the array is given the DIMENSION attribute elsewhere, the bounds must be specified as colons (deferred shape).

The ALLOCATABLE statement also confers the ALLOCATABLE attribute. It is subject to the same rules and restrictions as the ALLOCATABLE attribute.

The following examples show entity-oriented declarations:

REAL, ALLOCATABLE :: A(:, :)
LOGICAL, ALLOCATABLE, DIMENSION(:) :: MASK1

The following examples show attribute-oriented declarations:

REAL A(:, :)
LOGICAL MASK1
DIMENSION MASK1(:)
ALLOCATABLE A, MASK1

The following is a format for a type declaration statement with a POINTER attribute:

type, POINTER [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The POINTER statement also provides a means for declaring pointers. Its format is defined as follows:

POINTER [ :: ]object_name[ (deferred_shape_spec_list) ]
[ , object_name[ (deferred_shape_spec_list) ]] ...

The target of a pointer can be a scalar or an array.

An array pointer must be declared as a deferred-shape array.

A pointer must not be referenced or defined unless it is associated with a target that can be referenced or defined. (A pointer on the right-hand side of a pointer assignment is not considered a pointer reference.)

The POINTER statement also confers the POINTER attribute. It is subject to the same rules and restrictions as the POINTER attribute.

The following example shows an entity-oriented declaration:

TYPE(NODE), POINTER :: CURRENT
REAL, POINTER :: X(:, :), Y(:)

The following example shows an attribute-oriented declaration:

TYPE(NODE) CURRENT
REAL X(:, :), Y(:)
POINTER CURRENT, X, Y

Only an object with the TARGET attribute can become the target of a pointer during execution of a program. If an object does not have the TARGET attribute or has not been allocated, no part of it can be accessed through a pointer. The following is a format for a type declaration statement with a TARGET attribute:

type, TARGET [, attribute_list] :: entity_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The type declaration statement can also contain an initialization_expr.

The TARGET statement also provides a means for specifying pointer targets. It has the following format:

TARGET [ :: ]object_name[ (array_spec) ]
[, object_name[ (array_spec) ]] ...

The TARGET statement also confers the TARGET attribute. It is subject to the same rules and restrictions as the TARGET attribute.

The following examples show entity-oriented declarations:

TYPE(NODE), TARGET :: HEAD_OF_LIST
REAL, TARGET, DIMENSION(100, 100) :: V, W(100)

The following examples show attribute-oriented declarations:

TYPE(NODE) HEAD_OF_LIST
REAL V, W(100)
DIMENSION V(100, 100)
TARGET HEAD_OF_LIST, V, W

The AUTOMATIC attribute specifies stack-based storage for a variable or array. Such variables and arrays are undefined upon entering and exiting the procedure. The following is the format for the AUTOMATIC specification:

type, AUTOMATIC [ , attribute_list] :: entity_list

If an attribute_list item has the same name as the function in which it is declared, the attribute_list item must be scalar and of type integer, real, logical, complex, or double precision.

If the attribute_list item is a pointer, the AUTOMATIC attribute applies to the pointer itself and not to any target that may become associated with the pointer.

Subject to the rules governing combinations of attributes, attribute_list can contain the following:

The following entities cannot have the AUTOMATIC attribute:

An attribute_list item cannot have the following characteristics:

---

Note: The Fortran standard does not specify the AUTOMATIC attribute or statement, nor does it provide a means to explicitly declare automatic variables as automatic. The Fortran standard does not specify compiler directives.

---

A constant can be given a name in a type declaration statement with the PARAMETER attribute or in a PARAMETER statement. The following is a format for a type declaration statement with a PARAMETER attribute:

type, PARAMETER [, attribute_list] :: name = initialization_expression

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The initialization_expression must be present.

More than one named constant can be specified in a single type declaration statement; see the examples in this section.

The named constant becomes defined with the value determined from the initialization expression in accordance with the rules for intrinsic assignment. Any named constant that appears in the initialization expression must meet one of the following conditions:

If the named constant is an array, it must have its array properties declared in this statement or in a previous statement in the same scoping unit.

The PARAMETER statement also provides a means of defining a named constant. Its format is defined as follows:

PARAMETER (named_constant_def_list)

named_constant = initialization_expr

The PARAMETER statement also confers the PARAMETER attribute. It is subject to the same rules and restrictions as the PARAMETER attribute.

The PARAMETER attribute must not be specified for dummy arguments, functions, or objects in a common block.

A named constant that appears in a PARAMETER statement and is thereby declared and typed implicitly may appear in a subsequent type declaration statement only if that declaration confirms the implicit declaration.

A named array constant appearing in a PARAMETER statement must have had its array properties established previously.

A named constant must not appear in a format specification because of a possible ambiguity.

The following examples show entity-oriented declarations:

INTEGER, PARAMETER :: STATES = 50
INTEGER, PARAMETER :: M = MOD(28, 3),  &
       NUMBER_OF_SENATORS = 2 * STATES

The following examples show attribute-oriented declarations:

INTEGER STATES, M, NUMBER_OF_SENATORS
PARAMETER(STATES = 50)
PARAMETER(M = MOD(28, 3),  &
      NUMBER_OF_SENATORS = 2 * STATES)

The PUBLIC and PRIVATE attributes control access to type definitions, variables, functions, and named constants in a module. The PUBLIC attribute declares that entities in a module are available outside the module by use association; the PRIVATE attribute prevents access outside the module by use association. The default accessibility is PUBLIC, but it can be changed to PRIVATE.

The following formats are for type declaration statements with PUBLIC and PRIVATE attributes:

type, PUBLIC [, attribute_list] :: entity_decl_list
type, PRIVATE [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The type declaration statement can also contain an initialization_expr.

PUBLIC and PRIVATE specifications can also appear in the derived-type statement of a derived-type definition in a module to specify the accessibility of the type definition, as shown in the following:

TYPE, PUBLIC :: type_name
TYPE, PRIVATE :: type_name

If a PRIVATE statement appears inside a type definition, it specifies that, although the type may be accessible outside the module, its components are private.

For more information on derived-type definitions, see “Derived Type Definition” in Chapter 4.

PUBLIC and PRIVATE statements provide another means for controlling the accessibility of variables, functions, type definitions, and named constants. PUBLIC and PRIVATE statements can control the accessibility of some entities that do not have a type; these are subroutines, generic specifiers, and namelist groups. The formats for PUBLIC and PRIVATE statements are defined as follows:

access_spec[[ :: ]access_id_list]

PUBLIC

PRIVATE

use_name

generic_spec

Specify one of the following for generic_spec:

PUBLIC and PRIVATE statements can appear only in a module.

The PUBLIC and PRIVATE statements also confer the PUBLIC or PRIVATE attribute. They are subject to the same rules and restrictions as the PUBLIC and PRIVATE attributes.

A use_name can be the name of a variable, procedure, derived type, named constant, or namelist group.

Generic specifications are explained further in the Fortran Language Reference Manual, Volume 2. The following are examples of PUBLIC and PRIVATE statements that might be used with generic specifications:

PUBLIC HYPERBOLIC_COS, HYPERBOLIC_SIN     ! generic names
PRIVATE MY_COS_RAT, MY_SIN_RAT            ! specific names
PRIVATE MY_COS_INF_PREC, MY_SIN_INF_PREC  ! specific names
PUBLIC :: OPERATOR ( .MYOP. ), OPERATOR (+), ASSIGNMENT (=)

Only one PUBLIC or PRIVATE statement with an omitted access_id list is permitted in the scoping unit of a module. It determines the default accessibility of the module.

The default accessibility of entities defined in a module is PUBLIC. A PUBLIC statement without an access_id list can appear in the module to confirm the default accessibility. A PRIVATE statement without an access_id list can appear in the module to change the default accessibility.

A procedure that has a generic identifier that is public is accessible through the generic identifier even if its specific name is private. The converse is also true. That is, a module procedure that is public, but whose generic identifier is private, is still accessible through its specific name.

A module procedure that has an argument of a private type or a function result of a private type must be private and must not have a generic identifier that is public.

The following examples show entity-oriented declarations:

REAL, PUBLIC :: GLOBAL_X
TYPE, PRIVATE :: LOCAL_DATA
   LOGICAL :: FLAG
   REAL, DIMENSION(100) :: DENSITY
END TYPE LOCAL_DATA

The following examples show attribute-oriented declarations:

REAL GLOBAL_X
PUBLIC GLOBAL_X
TYPE LOCAL_DATA
   LOGICAL FLAG
   REAL DENSITY
   DIMENSION DENSITY(100)
END TYPE LOCAL_DATA
PRIVATE LOCAL_DATA

The following example shows a public type declaration with private components:

TYPE LIST_ELEMENT
   PRIVATE
   REAL VALUE
   TYPE(LIST_ELEMENT), POINTER :: NEXT, FORMER
END TYPE LIST_ELEMENT

The following example shows how to override the default accessibility:

MODULE M
   PRIVATE
   REAL R, K, TEMP(100)           ! R, K, and TEMP are private
   REAL, PUBLIC :: A(100), B(100) ! A and B are public
END MODULE M

The INTENT attribute specifies the intended use of a dummy argument. If specified, it can help detect errors, provide information for readers of the program, and give the compiler information that can be used to make the code more efficient. It is particularly valuable in creating software libraries.

Some dummy arguments are referenced but not redefined within the subprogram; some are defined before being referenced within the subprogram; others can be referenced before being redefined. INTENT has three forms: IN, OUT, and INOUT, which correspond respectively to the preceding three situations.

If the intent of an argument is IN, the subprogram must neither change the value of the argument nor must the argument become undefined during the course of the subprogram. If the intent is OUT, the subprogram must not use the argument before it is defined, and it must be definable. If the intent is INOUT, the argument can be used to communicate information to the subprogram and return information; it must be definable. If no intent is specified, the use of the argument is subject to the limitations of the associated actual argument. For example, the actual argument may be a constant (for example, 2) or a more complicated expression (for example, N+2), and in these cases the dummy argument can be referenced but not defined.

The following is a format for a type declaration statement with an INTENT attribute:

type, INTENT (intent_spec) [, attribute_list] :: decl_list

For intent_spec, specify one of the following arguments:

The attribute_list can contain the following attributes:

The INTENT statement also provides a means of specifying an intent for an argument. Its format is defined as follows:

INTENT (intent_spec) [ :: ]dummy_arg_name_list

IN

OUT

INOUT

The INTENT attribute can be specified only for dummy arguments.

An INTENT statement can appear only in the specification part of a subprogram or interface body.

An intent must not be specified for a dummy argument that is a dummy procedure because it is not possible to change the definition of a procedure. Intent for a dummy pointer must not be specified either.

The INTENT statement also confers the INTENT attribute. It is subject to the same rules and restrictions as the INTENT attribute.

If an argument is of a type that is default initialized when it is declared with INTENT(OUT), the components that are initialized are defined when the procedure is invoked.

An assumed-size array with INTENT(OUT) cannot be a type for which default initialization is specified.

The following examples show entity-oriented declarations:

SUBROUTINE MOVE(FROM, TO)
   USE PERSON_MODULE
   TYPE(PERSON), INTENT(IN) :: FROM
   TYPE(PERSON), INTENT(OUT) :: TO

SUBROUTINE SUB(X, Y)
   INTEGER, INTENT(INOUT) :: X, Y

The following examples show attribute-oriented declarations:

SUBROUTINE MOVE(FROM, TO)
   USE PERSON_MODULE
   TYPE(PERSON) FROM, TO
   INTENT(IN) FROM
   INTENT(OUT) TO

SUBROUTINE SUB(X, Y)
   INTEGER X, Y
   INTENT(INOUT) X, Y

The OPTIONAL attribute allows a procedure reference to omit arguments with this attribute. The PRESENT(3i) intrinsic function can be used to test the presence of an optional argument in a particular invocation and this test can be used to control the subsequent processing in the procedure. If the argument is not present, the subprogram can supply a default value or it can use an algorithm that is not based on the presence of the argument.

The following is a format for a type declaration statement with an OPTIONAL attribute:

type, OPTIONAL [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The OPTIONAL statement also provides a means for specifying an argument that can be omitted. Its format is defined as follows:

OPTIONAL [ :: ]dummy_arg_name_list

The OPTIONAL attribute can be specified only for dummy arguments.

An OPTIONAL statement can appear only in the scoping unit of a subprogram or interface body.

The OPTIONAL statement also confers the OPTIONAL attribute. It is subject to the same rules and restrictions as the OPTIONAL attribute.

The following examples show entity-oriented declarations in a program fragment:

CALL SORT_X(X = VECTOR_A)
   . . .
SUBROUTINE SORT_X(X, SIZEX, FAST)
   REAL, INTENT(INOUT) :: X (:)
   INTEGER, INTENT(IN), OPTIONAL :: SIZEX
   LOGICAL, INTENT(IN), OPTIONAL :: FAST
      . . .

   INTEGER TSIZE

      . . .
   IF (PRESENT(SIZEX)) THEN
      TSIZE = SIZEX
   ELSE
      TSIZE = SIZE(X)
   END IF

   IF (.NOT. PRESENT(FAST) .AND. TSIZE > 1000) THEN
      CALL QUICK_SORT(X)
   ELSE
      CALL BUBBLE_SORT(X)
   END IF
      . . .

The following examples show attribute-oriented declarations to be inserted in the same program fragment:

SUBROUTINE SORT_X(X, SIZEX, FAST)
   REAL X(:)
   INTENT(INOUT) X
   INTEGER SIZEX
   LOGICAL FAST
   INTENT(IN) SIZEX, FAST
   OPTIONAL SIZEX, FAST
      . . .
   INTEGER TSIZE
      . . .  

Variables with the SAVE attribute retain their value and their definition, association, and allocation status after the subprogram in which they are declared completes execution. Variables without the SAVE attribute cannot be depended on to retain their value and status, although the CF90 and MIPSpro 7 Fortran 90 compilers treat named common blocks as if they had the SAVE attribute. The SAVE attribute should always be specified for an object or the object's common named block, if it is necessary for the object to retain its value and status.

Objects declared in a module can be given the SAVE attribute, in which case they always retain their value and status when a procedure that uses the module completes execution. Objects in modules must be in continual use in order to retain their values.

Objects declared in recursive subprograms can be given the SAVE attribute. Such objects are shared by all instances of the subprogram.

Any object that is data initialized (in a DATA statement or a type declaration statement) has the SAVE attribute by default.

The following is a format for a type declaration statement with a SAVE attribute:

type, SAVE [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The type declaration statement can also contain an initialization_expr, but it cannot have the PARAMETER attribute.

The SAVE statement provides a means for specifying the SAVE attribute for objects and also for named common blocks. Its format is defined as follows:

SAVE [[ :: ]saved_entity_list]

data_object_name

/ common_block_name /

A SAVE statement without a saved entity list is treated as though it contained the names of all items that could be saved in the scoping unit. The CF90 and MIPSpro 7 Fortran 90 compilers allow you to insert multiple SAVE statements without entity lists in a scoping unit.

---

Note: The Fortran standard permits only one SAVE statement without an entity list in a scoping unit.

---

If SAVE appears in a main program as an attribute or a statement, it has no effect.

The following objects must not be saved:

A variable in a common block cannot be saved individually; the entire named common block must be saved if you want any variables in it to be saved.

A named common block saved in one scoping unit of a program is saved throughout the program.

---

Note: The Fortran standard states that if a named common block is saved in one scoping unit of a program, it must be saved in every scoping unit of the program in which it is defined (other than the main program).

---

If a named common block is specified in a main program, it is available to any scoping unit of the program that specifies the named common block; it does not need to be saved.

The SAVE statement also confers the SAVE attribute. It is subject to the same rules and restrictions as the SAVE attribute.

The following example shows an entity-oriented declaration:

CHARACTER(LEN = 12), SAVE :: NAME

The following example shows an attribute-oriented declaration:

CHARACTER*12 NAME
SAVE NAME

The following example shows saving objects and named common blocks:

SAVE A, B, /BLOCKA/, C, /BLOCKB/

The VOLATILE attribute and statement specifies that the value of an object is unpredictable. The object's value can change without visible assignment by the program, and it's value can be affected by external events. The presence of this statement prevents the compiler from optimizing references to specified variables, arrays, and common blocks of data.

The following format is for a type declaration statement with the VOLATILE attribute:

type, VOLATILE [, attribute_list] :: entity_decl_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

The entity_decl_list can include the name of a common block, enclosed in slash characters (for example, /common_block_name/).

The format for the VOLATILE statement is as follows:

VOLATILE  entity_decl_list

data_object_name

/common_block_name/

The following example shows a type declaration statement that specifies the VOLATILE attribute:

INTEGER, VOLATILE :: D, E

In the following example, the named common block, BLK1, and the variables D and E are volatile. Variables P1 and P4 become volatile because of the direct equivalence of P1 and the indirect equivalence of P4. The code that shows this is as follows:

PROGRAM TEST
LOGICAL(KIND=1) IPI(4)
INTEGER(KIND=4) A, B, C, D, E, ILOOK
INTEGER(KIND=4) P1, P2, P3, P4
COMMON /BLK1/A, B, C

VOLATILE /BLK1/, D, E
EQUIVALENCE(ILOOK, IPI)
EQUIVALENCE(A, P1)
EQUIVALENCE(P1, P4)

The presence of a VOLATILE attribute or statement can inhibit some optimizations because it asserts that the compiler must perform loads and stores from the specified objects. As an example, consider the following code fragment:

J = 1
DO I = 1,100000
  IF (J.EQ.2) PRINT 'FOO'
END DO

If the preceding code were included in a Fortran program, the compiler might remove the statement IF (J.EQ.2) PRINT 'FOO' because J is loop invariant and because J was previously assigned the value 1. If J were declared VOLATILE, the compiler would perform all loads of J because something else might affect the value of J.

---

Note: The Fortran standard does not describe the VOLATILE attribute or statement.

---

A variable or common block must be declared VOLATILE if it can be read or written to in a way that is not visible to the compiler. This would be the case in the following situations:

If an array is declared VOLATILE, each element in the array is VOLATILE. If a common block is declared VOLATILE, each variable in the common block is VOLATILE.

If an object of derived type is declared VOLATILE, its components are VOLATILE.

If a pointer is declared VOLATILE, the pointer itself is VOLATILE.

A VOLATILE statement must not specify a procedure, function result, or NAMELIST group name.

The EXTERNAL attribute in a type declaration statement indicates that a name is the name of an external function or a dummy function and permits the name to be used as an actual argument.

The following is a format for a type declaration statement with an EXTERNAL attribute:

type, EXTERNAL [, attribute_list] :: function_name_list

Subject to the rules governing combinations of these attributes, attribute_list can contain the following:

An interface block can be used to describe the interface of an external function. A function described by an interface block has the EXTERNAL attribute by default, so the function name cannot also be given the EXTERNAL attribute by any other means. Note that an interface block specifies the EXTERNAL attribute for all procedures in the interface block, with the exception of module procedures specified in MODULE PROCEDURE statements within the block. For information on interface blocks, see the Fortran Language Reference Manual, Volume 2.

The EXTERNAL statement provides a means for declaring subroutines and block data program units, as well as functions, to be external. Its format is defined as follows:

EXTERNAL external_name_list

Each external name must be the name of an external procedure, a dummy argument, or a block data program unit.

If a dummy argument is specified to be EXTERNAL, the dummy argument is a dummy procedure.

The EXTERNAL statement also confers the EXTERNAL attribute. It is subject to the same rules and restrictions as the EXTERNAL attribute.

The following examples of entity-oriented declarations:

SUBROUTINE SUB(FOCUS)
   INTEGER, EXTERNAL :: FOCUS
   LOGICAL, EXTERNAL :: SIN

The following example shows an attribute-oriented declaration:

SUBROUTINE SUB (FOCUS)
   INTEGER FOCUS
   LOGICAL SIN
   EXTERNAL FOCUS, SIN

FOCUS is declared to be a dummy procedure. SIN is declared to be an external procedure. Both are functions. To declare an external subroutine, the EXTERNAL statement or an interface block must be used because a subroutine does not have a type, and thus its attributes cannot be specified in a type declaration statement. The specific and generic name SIN of the intrinsic function SIN is no longer available to subroutine SUB.

The INTRINSIC attribute in a type declaration statement indicates that a name is the name of an intrinsic function and permits the names of some intrinsic functions to be used as actual arguments.

The following is a format for a type declaration statement with an INTRINSIC attribute:

type, INTRINSIC [, attribute_list] :: intrinsic_function_name_list

For attribute_list, specify one of the following attributes:

The INTRINSIC statement provides a means for declaring intrinsic subroutines, as well as functions. Its format is defined as follows:

INTRINSIC intrinsic_procedure_name_list

Each intrinsic_procedure_name must be the name of an intrinsic procedure.

A name must not be declared to be both EXTERNAL and INTRINSIC in a scoping unit.

A type can be specified for an intrinsic function even though it has a type as specified in the Fortran Language Reference Manual, Volume 2. If a type is specified for the generic name of an intrinsic function, it does not remove the generic properties of the function name.

The INTRINSIC statement also confers the INTRINSIC attribute. It is subject to the same rules and restrictions as the INTRINSIC attribute.

The CF90 and MIPSpro 7 Fortran 90 compilers have implemented intrinsic procedures in addition to the ones required by the standard. These procedures have the status of intrinsic procedures, but programs that use them may not be portable. It is recommended that such procedures be declared INTRINSIC to allow other processors to diagnose whether or not they are intrinsic for those processors.

The following is an example of an entity-oriented declaration:

REAL, INTRINSIC :: SIN, COS

The following is an example of an attribute-oriented declaration:

REAL SIN, COS
INTRINSIC SIN, COS

Because the interfaces of intrinsic procedures are known to the compiler, it is not necessary to specify a type for them, but it is not incorrect to do so.

Fortran includes numeric and character storage units for numeric and character data. The nondefault types (user-defined types and pointers), however, are stored in unspecified storage units. These unspecified storage units are used for pointers, objects of nondefault type, and structures that contain components that are of nondefault types or are pointers. This unit is different for each different sort of object. A pointer occupies a single unspecified storage unit that is different from that of any nonpointer object and can be different for each combination of type, type parameters, and rank.

There are two kinds of structures, sequence structures and nonsequence structures, depending on whether or not the type definition contains a SEQUENCE statement. A nonsequence structure occupies a single unspecified storage unit that is different for each type. The three kinds of sequence structures are as follows:

Table 5-1, lists objects of various types and attributes and the storage units they occupy.

A storage sequence is an ordered sequence of storage units. The storage units can be elements in an array, characters in a character variable, components in a sequence structure, or variables in a common block. A sequence of storage sequences forms a composite storage sequence. The order of the storage units in such a composite sequence is the order of the units in each constituent taken in succession, ignoring any zero-sized sequences.

Storage is associated when the storage sequences of two different objects have some storage in common. This permits two or more variables to share the same storage. Two objects are totally associated if they have the same storage sequence; two objects are partially associated if they share some storage but are not totally associated.

To indicate that two or more variables will share storage, they can be placed in an equivalence group in an EQUIVALENCE statement. If the objects in an equivalence group have different types or type parameters, no conversion or mathematical relationship is implied. If a scalar and an array are equivalenced, the scalar does not have array properties and the array does not have the properties of a scalar. The format of the EQUIVALENCE statement is defined as follows:

EQUIVALENCE equivalence_set_list

(equivalence_object, equivalence_object_list)

variable_name

array_element

substring

An equivalence object must not be one of the following items:

An equivalence group list must contain at least two items.

Subscripts and substring ranges must be integer initialization expressions. A substring cannot have a length of zero.

If an equivalence object is of type default integer, default real, double-precision real, default complex, default logical, or numeric sequence type, all objects in the set must be of these types.

If an equivalence object is of type character or character sequence type, all objects in the set must be type character. The lengths do not need to be the same.

If an equivalence object is of sequence type other than numeric or character sequence type, all objects in the set must be of the same type.

---

Note: The CF90 and MIPSpro 7 Fortran 90 compilers allow equivalencing of character data with noncharacter data. The Fortran standard does not address this. It is recommended that you do not perform equivalencing in this manner, however, because alignment and padding differs across platforms, thus rendering your code less portable.

---

If an equivalence object is of intrinsic type other than default integer, default real, double-precision real, default complex, or default logical, all objects in the set must be of the same type with the same kind type parameter value.

The use of an array name unqualified by a subscript list in an equivalence set specifies the first element of the array; that is, A means the first element of A.

An EQUIVALENCE statement must not specify that the same storage unit is to occur more than once in a storage sequence. For example, the following is illegal because it would indicate that storage for X(2) and X(3) is shared:

EQUIVALENCE (A, X(2)), (A, X(3))

An EQUIVALENCE statement must not specify the sharing of storage units between objects declared in different scoping units.

An EQUIVALENCE statement specifies that the storage sequences of the data objects in an equivalence set are storage associated. Any nonzero-sized sequences in the set have the same first storage unit, and any zero-sized sequences are storage associated with one another and with the first storage unit of any nonzero-sized sequences. This causes storage association of the objects in the group and may cause storage association of other data objects.

Example 1: The following code causes the alignment illustrated in Figure 5-2:

CHARACTER(LEN = 4) :: A, B
CHARACTER(LEN = 3) :: C(2)
EQUIVALENCE (A, C(1)), (B, C(2))

Figure 5-2. Character alignment example

As a result, the fourth character of A, the first character of B, and the first character of C(2) all share the same character storage unit.

Example 2: Figure 5-3, illustrates alignment of the following two numeric arrays:

REAL, DIMENSION(6) :: X, Y
EQUIVALENCE (X(5), Y(3))

Figure 5-3. Numeric array alignment example

The COMMON statement establishes blocks of storage called common blocks and specifies objects that are contained in the blocks. Two or more program units can share this space and thus share the values of variables stored in the space. Thus, the COMMON statement provides a global data facility based on storage association. Common blocks can be named, in which case they are called named common blocks, or they can be unnamed, in which case they are called blank common.

Common blocks can contain mixtures of storage units and can contain unspecified storage units; however, if a common block contains a mixture of storage units, every declaration of the common block in the program must contain the same sequence of storage units, thereby matching types, kind type parameters, and attributes (DIMENSION and POINTER). The format of the COMMON statement is defined as follows:

COMMON [ / [common_block_name] / ]common_block_object_list
[[ , ] / [common_block_name] / common_block_object_list] ...

variable_name[ (explicit_shape_spec_list) ]

A common_block_object must not be one of the following items:

The appearance of two slashes with no common block name between them declares that the objects that follow are in blank common.

A common block name or an indication of blank common can appear more than once in one or more COMMON statements in the same scoping unit. The object list following each successive block name or blank common indication is treated as a continuation of the previous object list.

A variable can appear in only one common block within a scoping unit.

If a variable appears with an explicit-shape specification list, it is an array, and each bound must be a constant specification expression.

Only a named common block can be saved. Individual variables in the common block cannot be saved.

For each common block, a common block storage sequence is formed. It consists of the sequence of storage units of all the variables listed for the common block in the order of their appearance in the common block list. The storage sequence may be extended (on the end) to include the storage units of any variable equivalenced to a variable in the common block. Data objects storage associated with a variable in a common block are considered to be in that common block. The size of a common block is the size of its storage sequence including any extensions of the sequence resulting from equivalence association.

Within an executable program, the common block storage sequences of all nonzero-sized common blocks with the same name have the same first storage unit. Zero-sized common blocks are permitted. All zero-sized common blocks with the same name are storage associated with one another. The same is true for all blank common blocks except that because they can be of different sizes, it is possible for a zero-sized blank common block in one scoping unit to be associated with the first storage unit of a nonzero-sized blank common block in another scoping unit. In this way, many subprograms can use the same storage. They can specify common blocks to communicate global values or to reuse and conserve storage. USE association or HOST association can cause these associated objects to be accessible in the same scoping unit.

A nonpointer object of type default integer, default real, double-precision real, default complex, default logical, or numeric sequence type must become associated with only nonpointer objects of these types.

A nonpointer object of type character or character sequence must become associated with only nonpointer objects of these types.

If an object of numeric sequence or character sequence type appears in a common block, it is as if the individual components were enumerated in order directly in the common block object list.

A nonpointer object of sequence type other than numeric or character sequence type must become associated only with nonpointer objects of the same type.

A nonpointer object of intrinsic type other than default integer, default real, double precision real, default complex, default logical, or character must become associated only with nonpointer objects of the same type with the same kind type parameter value.

A pointer must become associated only with pointers of the same type, type parameters, and rank.

---

Note: An object with the TARGET attribute can become storage associated only with another object that has the TARGET attribute and the same type and type parameters.

---

The CF90 and MIPSpro 7 Fortran 90 compilers treat named common blocks and blank common blocks identically, as follows:

Consider the code in the following example:

SUBROUTINE FIRST
   REAL B(2)
   COMPLEX C
   LOGICAL FLAG
   TYPE COORDINATES
      SEQUENCE
      REAL X, Y
      LOGICAL Z_O      ! ZERO ORIGIN?
   END TYPE COORDINATES
   TYPE(COORDINATES) P
   COMMON /REUSE/ B, C, FLAG, P

   REAL MY_VALUES(100)
   CHARACTER(LEN = 20) EXPLANATION
   COMMON /SHARE/ MY_VALUES, EXPLANATION
   SAVE /SHARE/

   REAL, POINTER :: W(:, :)
   REAL, TARGET, DIMENSION(100, 100) :: EITHER, OR
   INTEGER(SHORT) :: M(2000)
   COMMON /MIXED/ W, EITHER, OR, M
      . . .
END SUBROUTINE
SUBROUTINE SECOND
   INTEGER, PARAMETER :: SHORT = 2
   INTEGER I(8)
   COMMON /REUSE/ I

   REAL MY_VALUES(100)
   CHARACTER(LEN = 20) EXPLANATION
   COMMON /SHARE/ MY_VALUES, EXPLANATION
   SAVE /SHARE/

   REAL, POINTER :: V(:)
   REAL, TARGET, DIMENSION(100000) :: ONE, ANOTHER
   INTEGER(SHORT) :: M(2000)
   COMMON /MIXED/ V, ONE, ANOTHER, M  ! ILLEGAL
   . . .
END SUBROUTINE

Common block REUSE has a storage sequence of 8 numeric storage units. It is used to conserve storage. The storage referenced in subroutine FIRST is associated with the storage referenced in subroutine SECOND, as follows:

Figure 5-4. Storage of REUSE in FIRST and SECOND

The Fortran standard does not guarantee that the storage is actually retained and reused because, in the absence of a SAVE attribute for REUSE, some compilers can release the storage when either of the subroutines completes execution. The CF90 and MIPSpro 7 Fortran 90 compilers treat named common blocks as entities that are contained in a SAVE statement.

Common block SHARE contains both numeric and character storage units and is used to share data between subroutines FIRST and SECOND.

The declaration of common block MIXED in subroutine SECOND is illegal because it does not have the same sequence of storage units as the declaration of MIXED in subroutine FIRST. The array pointer W in FIRST has two dimensions; the array pointer V in SECOND has only one. With common blocks, it is the sequence of storage units that must match, not the names of variables.

An EQUIVALENCE statement must not cause two different common blocks to become associated and must not cause a common block to be extended by adding storage units preceding the first storage unit of the common block. For example, the following code is legal and results in the alignment illustrated in Figure 5-5:

COMMON A(5)
REAL B(5)
EQUIVALENCE (A(2), B(1))

Figure 5-5. Alignment resulting from correct code

On the other hand, the following code is not legal because it would place B(1) ahead of A(1), as is illustrated in Figure 5-6:

EQUIVALENCE (A(1), B(2))

Figure 5-6. Alignment resulting from incorrect code

COMMON and EQUIVALENCE statements can appear in a module. The name of a public data object from a module must not appear in a COMMON or EQUIVALENCE statement in any scoping unit that has access to the data object.

EQUIVALENCE association must not cause a derived-type object with default initialization to be associated with an object in a common block.