When a generic procedure reference is made, a specific procedure is invoked. If the following rules are used, the generic reference will be unambiguous:

• Within a scoping unit, two procedures that have the same generic name must both be subroutines (or both be functions). One of the procedures must have a nonoptional dummy argument that is one of the following:
  • Not present by position or argument keyword in the other argument list
  • Is present, but has different type and kind parameters, or rank
• Within a scoping unit, two procedures that have the same generic operator must both have the same number of arguments or both define assignment. One of the procedures must have a dummy argument that corresponds by position in the argument list to a dummy argument of the other procedure that has a different type and kind parameters, or rank.

When an interface block extends an intrinsic procedure, operator, or assignment, the rules apply as if the intrinsic consists of a collection of specific procedures, one for each allowed set of arguments.

When a generic procedure is accessed from a module, the rules apply to all the specific versions, even if some of them are inaccessible by their specific names.

For More Information:

For details on generic procedure names, see Section 8.9.3.

15.4 Resolving Procedure References

The procedure name in a procedure reference is either established to be generic or specific, or is not established. The rules for resolving a procedure reference differ depending on whether the procedure is established and how it is established.

15.4.1 References to Generic Names

Within a scoping unit, a procedure name is established to be generic if any of the following is true:

• The scoping unit contains an interface block with that procedure name.
• The procedure name matches the name of a generic intrinsic procedure, and it is specified with the INTRINSIC attribute in that scoping unit.
• The procedure name is established to be generic in a module, and the scoping unit contains a USE statement making that procedure name accessible.
• The scoping unit contains no declarations for that procedure name, but the procedure name is established to be generic in a host scoping unit.

To resolve a reference to a procedure name established to be generic, the following rules are used in the order shown:

1. If an interface block with that procedure name appears in one of the following, the reference is to the specific procedure providing that interface:
   1. The scoping unit that contains the reference
   2. A module made accessible by a USE statement in the scoping unit
   
   The reference must be consistent with one of the specific interfaces of the interface block.
2. If the procedure name is specified with the INTRINSIC attribute in one of the following, the reference is to that intrinsic procedure:
   1. The same scoping unit
   2. A module made accessible by a USE statement in the scoping unit
   
   The reference must be consistent with the interface of that intrinsic procedure.
3. If the following is true, the reference is resolved by applying rules 1 and 2 to the host scoping unit:
   1. The procedure name is established to be generic in the host scoping unit
   2. There is agreement between the scoping unit and the host scoping unit as to whether the procedure is a function or subroutine name.
4. If none of the preceding rules apply, the reference must be to the generic intrinsic procedure with that name. The reference must be consistent with the interface of that intrinsic procedure.

In a scoping unit, a procedure name is established to be specific if it is not established to be generic and any of the following is true:

• The scoping unit contains an interface body with that procedure name.
• The scoping unit contains an internal procedure, module procedure, or statement function with that procedure name.
• The procedure name is the same as the name of a generic intrinsic procedure, and it is specified with the INTRINSIC attribute in that scoping unit.
• The procedure name is specified with the EXTERNAL attribute in that scoping unit.
• The procedure name is established to be specific in a module, and the scoping unit contains a USE statement making that procedure name accessible.
• The scoping unit contains no declarations for that procedure name, but the procedure name is established to be specific in a host scoping unit.

To resolve a reference to a procedure name established to be specific, the following rules are used in the order shown:

1. If either of the following is true, the dummy argument is a dummy procedure and the reference is to that dummy procedure:
   1. The scoping unit is a subprogram, and it contains an interface body with that procedure name.
   2. The procedure name has been declared EXTERNAL, and the procedure name is a dummy argument of that subprogram.
   
   The procedure invoked by the reference is the one supplied as the corresponding actual argument.
2. If the scoping unit contains an interface body or the procedure name has been declared EXTERNAL, and Rule 1 does not apply, the reference is to an external procedure with that name.
3. If the scoping unit contains an internal procedure or statement function with that procedure name, the reference is to that entity.
4. If the procedure name has been declared INTRINSIC in the scoping unit, the reference is to the intrinsic procedure with that name.
5. If the scoping unit contains a USE statement that makes the name of a module procedure accessible, the reference is to that procedure. (The USE statement allows renaming, so the name referenced may differ from the name of the module procedure.)
6. If none of the preceding rules apply, the reference is resolved by applying these rules to the host scoping unit.

In a scoping unit, a procedure name is not established if it is not determined to be generic or specific.

To resolve a reference to a procedure name that is not established, the following rules are used in the order shown:

1. If both of the following are true, the dummy argument is a dummy procedure and the reference is to that dummy procedure:
   1. The scoping unit is a subprogram.
   2. The procedure name is a dummy argument of that subprogram.
   
   The procedure invoked by the reference is the one supplied as the corresponding actual argument.
2. If both of the following are true, the procedure is an intrinsic procedure and the reference is to that intrinsic procedure:
   1. The procedure name matches the name of an intrinsic procedure.
   2. There is agreement between the intrinsic procedure definition and the reference of the name as a function or subroutine.
3. If neither of the preceding rules apply, the reference is to an external procedure with that name.

For More Information:

• On subroutine references, see Section 7.3.
• On function references, see Section 8.5.2.2.
• On generic procedure names, see Section 8.9.3.
• On the USE statement, see Section 8.3.2.

Association allows different program units to access the same value through different names. Entities are associated when each is associated with the same storage location.

There are three kinds of association:

• Name association ( Section 15.5.1)
• Pointer association ( Section 15.5.2)
• Storage association ( Section 15.5.3)

Example 15-1 shows name, pointer, and storage association between an external program unit and an external procedure.

Example 15-1 Example of Name, Pointer, and Storage Association

! Scoping Unit 1: An external program unit REAL A, B(4) REAL, POINTER :: M(:) REAL, TARGET :: N(12) COMMON /COM/... EQUIVALENCE (A, B(1)) ! Storage association between A and B(1) M => N ! Pointer association CALL P (actual-arg,...) ... ! Scoping Unit 2: An external procedure SUBROUTINE P (dummy-arg,...) ! Name and storage association between ! these arguments and the calling ! routine's arguments in scoping unit 1 COMMON /COM/... ! Storage association with common block COM ! in scoping unit 1 REAL Y CALL Q (actual-arg,...) CONTAINS SUBROUTINE Q (dummy-arg,...) ! Name and storage association between ! these arguments and the calling ! routine's arguments in host procedure ! P (subprogram Q has host association ! with procedure P) Y = 2.0*(Y-1.0) ! Name association with Y in host procedure P ...

15.5.1 Name Association

Name association allows an entity (such as the name of a variable, constant, or procedure) to be accessed from different scoping units by the same name or by different names. There are three types of name association: argument, use, and host.

15.5.1.1 Argument Association

Arguments are the values passed to and from functions and subroutines through calling program argument lists.

Execution of a procedure reference establishes argument association between an actual argument and its corresponding dummy argument. The name of a dummy argument can be different from the name of its associated actual argument (if any).

When the procedure completes execution, the argument association is terminated.

For More Information:

For details on argument association, see Section 8.8.

15.5.1.2 Use and Host Association

Use association allows the entities in a module to be accessible to other scoping units. The mechanism for use association is the USE statement. The USE statement provides access to all public entities in the module, unless ONLY is specified. In this case, only the entities named in the ONLY list can be accessed.

Host association allows the entities in a host scoping unit to be accessible to an internal procedure, derived-type definition, or module procedure contained within the host. The accessed entities are known by the same name and have the same attributes as in the host. Entities that are local to a procedure are not accessible to its host.

Use or host association remains in effect throughout the execution of the executable program.

If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible. A name that appears in the scoping unit as an external name in an EXTERNAL statement is a global name, and any entity of the host that has this as its nongeneric name is inaccessible.

An interface body does not access named entities by host association, but it can access entities by use association.

If a procedure gains access to a pointer by host association, the association of the pointer with a target that is current at the time the procedure is invoked remains current within the procedure. This pointer association can be changed within the procedure. After execution of the procedure, the pointer association remains current, unless the execution caused the target to become undefined. If this occurs, the host associated pointer becomes undefined.

The following example shows host and use association:

MODULE SHARE_DATA REAL Y, Z END MODULE PROGRAM DEMO USE SHARE_DATA ! All entities in SHARE_DATA are available REAL B, Q ! through use association. ... CALL CONS (Y) CONTAINS SUBROUTINE CONS (Y) ! Y is a local entity (dummy argument). REAL C, Y ... Y = B + C + Q + Z ! B and Q are available through host association. ... ! C is a local entity, explicitly declared. Z END SUBROUTINE CONS ! is available through use association. END PROGRAM DEMO

For More Information:

• On the USE statement, see Section 8.3.2.
• On entities with local scope, see Section 15.2.

A pointer can be associated with a target. At different times during the execution of a program, a pointer can be undefined, associated with different targets, or be disassociated. The initial association status of a pointer is undefined. A pointer can become associated by the following:

• By pointer assignment (pointer => target)
  The target must be associated, or specified with the TARGET attribute. If the target is allocatable, it must be currently allocated.
• By allocation (successful execution of an ALLOCATE statement)
  The ALLOCATE statement must reference the pointer.

A pointer becomes disassociated if any of the following occur:

• The pointer is nullified by a NULLIFY statement.
• The pointer is deallocated by a DEALLOCATE statement.
• The pointer is assigned a disassociated pointer (or the NULL intrinsic function).

When a pointer is associated with a target, the definition status of the pointer is defined or undefined, depending on the definition status of the target. A target is undefined in the following cases:

• If it was never allocated
• If it is not deallocated through the pointer
• If a RETURN or END statement causes it to become undefined

If a pointer is associated with a definable target, the definition status of the pointer can be defined or undefined, according to the rules for a variable.

If the association status of a pointer is disassociated or undefined, the pointer must not be referenced or deallocated.

Whatever its association status, a pointer can always be nullified, allocated, or associated with a target. When a pointer is nullified, it is disassociated. When a pointer is allocated, it becomes associated, but is undefined. When a pointer is associated with a target, its association and definition status are determined by its target.

For More Information:

• On pointer assignment, see Section 4.2.3.
• On the ALLOCATE and DEALLOCATE statements, see Chapter 6.
• On the NULLIFY statement, see Chapter 6.
• On the NULL intrinsic function, see Section 9.4.111.

Storage association is the association of two or more data objects. It occurs when two or more storage sequences share (or are aligned with) one or more storage units. Storage sequences are used to describe relationships among variables, common blocks, and result variables.

15.5.3.1 Storage Units and Storage Sequence

A storage unit is a fixed unit of physical memory allocated to certain data. A storage sequence is a sequence of storage units. The size of a storage sequence is the number of storage units in the storage sequence. A storage unit can be numeric, character, or unspecified.

A nonpointer scalar of type default real, integer, or logical occupies one numeric storage unit. A nonpointer scalar of type double precision real or default complex occupies two contiguous numeric storage units. In HP Fortran, one numeric storage unit corresponds to 4 bytes of memory.

A nonpointer scalar of type default character with character length 1 occupies one character storage unit. A nonpointer scalar of type default character with character length len occupies len contiguous character storage units. In HP Fortran, one character storage unit corresponds to 1 byte of memory.

A nonpointer scalar of nondefault data type occupies a single unspecified storage unit. The number of bytes corresponding to the unspecified storage unit differs depending on the data type.

Table 15-2 lists the storage requirements (in bytes) for the intrinsic data types.

4, 8 ¹ )

Table 15-2 Data Type Storage Requirements

Data Type	Storage Requirements (in bytes)
BYTE	1
LOGICAL	2, 4, or 8 1
LOGICAL(1)	1
LOGICAL(2)	2
LOGICAL(4)	4
LOGICAL(8)	8
INTEGER	2
INTEGER(1)	1
INTEGER(2)	2
INTEGER(4)	4
INTEGER(8)	8
REAL	4, 8, or 16 2
REAL(4)	4
DOUBLE PRECISION	8
REAL(8)	8
REAL(16)	16
COMPLEX	8, 16, or 32 2
COMPLEX(4)	8
DOUBLE COMPLEX	16
COMPLEX(8)	16
COMPLEX(16)	32
CHARACTER	1
CHARACTER*len	len 3
CHARACTER*(*)	assumed-length 4

A nonpointer scalar of sequence derived type occupies a sequence of storage sequences corresponding to the components of the structure, in the order they occur in the derived-type definition. (A sequence derived type has a SEQUENCE statement.)

A pointer occupies a single unspecified storage unit that is different from that of any nonpointer object and is different for each combination of type, type parameters, and rank.

The definition status and value of a data object affects the definition status and value of any storage-associated entity.

When two objects occupy the same storage sequence, they are totally storage-associated. When two objects occupy parts of the same storage sequence, they are partially associated. An EQUIVALENCE statement, a COMMON statement, or an ENTRY statement can cause total or partial storage association of storage sequences.

For More Information:

• On the COMMON statement, see Section 5.4.
• On the ENTRY statement, see Section 8.11.
• On the EQUIVALENCE statement, see Section 5.7.
• On the hardware representations of data types, see the HP Fortran for OpenVMS User Manual.