WORKING DRAFT J3/06-007r1 25th September 2006 18:59 This is an internal working document of J3. 2006/09/25 WORKING DRAFT J3/06-007r1 Contents 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.5 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.1 New intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.2 New intrinsic data type and operator . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.3 Fortran 2003 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.4 Fortran 95 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.5 Fortran 90 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6.6 FORTRAN 77 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7 Notation used in this part of ISO/IEC 1539 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.1 Applicability of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.2 Informative notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.3 Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.5 Assumed syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.6 Syntax conventions and characteristics . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.7 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8 Deleted and obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.2 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.3 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Fortran terms and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Program units and scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.5 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.6 Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1 Statement classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.5 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 i J3/06-007r1 WORKING DRAFT 2006/09/25 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.6 Co-array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.7 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.8 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.10 Companion processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Lexical tokens, source form, and macro processing . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Processor character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.3 Underscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.4 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.5 Other characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5 Macro processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.1 Macro definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.2 Macro expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1 Type specifiers and type compatibility . . . . . . . . . . . . . . . . . . . . . . . 43 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.1 Classification and specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.2 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.3 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.4 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.5 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.6 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.7 Bits type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 ii 2006/09/25 WORKING DRAFT J3/06-007r1 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.1 Derived type concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.2 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.3 Derived-type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.5.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.5.5 Type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5.6 Final subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5.7 Type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.5.8 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.9 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.10 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.11 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 77 4.6 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.7 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5 Attribute declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.2 Automatic data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2.3 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.4 Examples of type declaration statements . . . . . . . . . . . . . . . . . . . . . . 85 5.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.2 Accessibility attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.3 ALLOCATABLE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.4 ASYNCHRONOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.5 BIND attribute for data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.6 CONTIGUOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.7 DIMENSION attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.8 EXTERNAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.3.9 INTENT attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.3.10 INTRINSIC attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.11 OPTIONAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.12 PARAMETER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.13 POINTER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.14 PROTECTED attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.15 SAVE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.16 TARGET attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.17 VALUE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.18 VOLATILE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.4 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4.1 Accessibility statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.5 CONTIGUOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.6 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.7 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.8 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.9 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.10 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4.11 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4.12 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 iii J3/06-007r1 WORKING DRAFT 2006/09/25 5.4.13 SAVE statement . . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 104 5.4.14 TARGET statement . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 105 5.4.15 VALUE statement . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 105 5.4.16 VOLATILE statement . . . ....... . . . . . . . . . . . . . . . . . . . . . . 105 5.5 IMPLICIT statement . . . . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 105 5.6 NAMELIST statement . . . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 107 5.7 Storage association of data objects . ....... . . . . . . . . . . . . . . . . . . . . . . 108 5.7.1 EQUIVALENCE statement ....... . . . . . . . . . . . . . . . . . . . . . . 108 5.7.2 COMMON statement . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 111 5.7.3 Restrictions on common and equivalence . . . . . . . . . . . . . . . . . . . . . . 113 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.3 Complex parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.1.4 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.3 Image selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.1 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.2 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.1.3 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.1.4 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 139 7.1.5 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 141 7.1.6 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7.1.7 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.1.8 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.2 Interpretation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2.2 Numeric intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7.2.3 Character intrinsic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7.2.4 Relational intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.2.5 Logical intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 7.2.6 Bits intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.4 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.4.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.4.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.4.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 166 7.4.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1.2 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 iv 2006/09/25 WORKING DRAFT J3/06-007r1 8.1.3 ASSOCIATE construct . . . . . . . . . . . . . . . . . ........... . . . . 176 8.1.4 BLOCK construct . . . . . . . . . . . . . . . . . . . . ........... . . . . 177 8.1.5 CASE construct . . . . . . . . . . . . . . . . . . . . . ........... . . . . 178 8.1.6 CRITICAL construct . . . . . . . . . . . . . . . . . . ........... . . . . 180 8.1.7 DO construct . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 182 8.1.8 IF construct and statement . . . . . . . . . . . . . . . ........... . . . . 188 8.1.9 SELECT TYPE construct . . . . . . . . . . . . . . . ........... . . . . 189 8.1.10 EXIT statement . . . . . . . . . . . . . . . . . . . . . ........... . . . . 192 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 192 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . ........... . . . . 192 8.2.2 Computed GO TO statement . . . . . . . . . . . . . ........... . . . . 193 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . ........... . . . . 193 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 193 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 193 8.5 Image execution control . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 195 8.5.1 Image control statements . . . . . . . . . . . . . . . . ........... . . . . 195 8.5.2 SYNC ALL statement . . . . . . . . . . . . . . . . . ........... . . . . 197 8.5.3 SYNC TEAM statement . . . . . . . . . . . . . . . . ........... . . . . 197 8.5.4 SYNC IMAGES statement . . . . . . . . . . . . . . . ........... . . . . 199 8.5.5 NOTIFY and QUERY statements . . . . . . . . . . . ........... . . . . 200 8.5.6 SYNC MEMORY statement . . . . . . . . . . . . . . ........... . . . . 202 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements . . . . 203 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.5 OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.6 CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.5.2 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 9.5.3 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.5.4 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 229 9.5.5 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 241 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.6.1 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.6.2 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.7.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.7.2 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.7.3 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 v J3/06-007r1 WORKING DRAFT 2006/09/25 9.7.4 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.9 File inquiry statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.9.1 Forms of the INQUIRE statement . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.9.2 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 252 9.10.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . 253 9.10.2 End-of-file condition and the END= specifier . . . . . . . . . . . . . . . . . . . . 253 9.10.3 End-of-record condition and the EOR= specifier . . . . . . . . . . . . . . . . . . 254 9.10.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.11 Restrictions on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.1 Format specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.2 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.2.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.2.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10.3 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 10.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 10.3.2 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 10.3.3 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.4 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . 260 10.5 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.6 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.7 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.7.2 Numeric and bits editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 10.7.3 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 10.7.4 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 10.7.5 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 10.7.6 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.8 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.8.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 10.8.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 10.8.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . 275 10.8.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 10.9 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.10 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.10.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.10.2 Values and value separators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.10.3 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 10.10.4 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 10.11 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 10.11.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 10.11.2 Name-value subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 10.11.3 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 10.11.4 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 vi 2006/09/25 WORKING DRAFT J3/06-007r1 11 Program units . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 287 11.1 Main program . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 287 11.2 Modules . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 288 11.2.1 General . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 288 11.2.2 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 289 11.2.3 Submodules . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 291 11.3 Block data program units . . ............ . . . . . . . . . . . . . . . . . . . . . . 292 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 12.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 12.2 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 12.2.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . 295 12.2.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . 295 12.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 12.3.1 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 12.3.2 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 296 12.3.3 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.4 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.4.2 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.4.3 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 298 12.5 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 12.5.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 12.5.2 Actual arguments, dummy arguments, and argument association . . . . . . . . . 310 12.5.3 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 12.5.4 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 12.5.5 Resolving named procedure references . . . . . . . . . . . . . . . . . . . . . . . . 323 12.5.6 Resolving type-bound procedure references . . . . . . . . . . . . . . . . . . . . . 325 12.6 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.6.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.6.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 326 12.6.3 Definition and invocation of procedures by means other than Fortran . . . . . . 333 12.6.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 12.7 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 12.8 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 12.8.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 336 12.8.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 336 12.8.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 337 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.2.1 General rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.2.2 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.2.3 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.2.4 Arguments to collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 344 vii J3/06-007r1 WORKING DRAFT 2006/09/25 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.15 Collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.16 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.17 Allocation transfer procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.18 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.19 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 348 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 349 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 13.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 13.8.2 The IEEE intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 13.8.3 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 435 13.8.4 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . 438 14 Exceptions and IEEE arithmetic . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 439 14.1 Derived types and constants defined in the modules . . . . . . . . . . . . . . . . . . . . . 440 14.2 The exceptions . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 441 14.3 The rounding modes . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 442 14.4 Underflow mode . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 443 14.5 Halting . . . . . . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 443 14.6 The floating point status . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 444 14.7 Exceptional values . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 444 14.8 IEEE arithmetic . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 444 14.9 Tables of the procedures . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 445 14.9.1 Inquiry functions . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 445 14.9.2 Elemental functions . . . . ......... . . . . . . . . . . . . . . . . . . . . . 446 14.9.3 Kind function . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 446 14.9.4 Elemental subroutines . . ......... . . . . . . . . . . . . . . . . . . . . . 446 14.9.5 Nonelemental subroutines ......... . . . . . . . . . . . . . . . . . . . . . 446 14.10 Specifications of the procedures . . ......... . . . . . . . . . . . . . . . . . . . . . 447 14.11 Examples . . . . . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 462 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2.1 Summary of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2.2 Named constants and derived types in the module . . . . . . . . . . . . . . . . . 467 15.2.3 Procedures in the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 15.3 Interoperability between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.2 Interoperability of intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.3 Interoperability with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . 474 15.3.4 Interoperability of derived types and C struct types . . . . . . . . . . . . . . . . 475 15.3.5 Interoperability of scalar variables . . . . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.6 Interoperability of array variables . . . . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.7 Interoperability of procedures and procedure interfaces . . . . . . . . . . . . . . 477 viii 2006/09/25 WORKING DRAFT J3/06-007r1 15.4 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 15.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 15.4.2 Binding labels for common blocks and variables . . . . . . . . . . . . . . . . . . 480 15.5 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 15.5.1 Definition and reference of interoperable procedures . . . . . . . . . . . . . . . . 480 15.5.2 Binding labels for procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 15.5.3 Exceptions and IEEE arithmetic procedures . . . . . . . . . . . . . . . . . . . . 481 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.1 Identifiers and entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.2 Scope of global identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.3 Scope of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 16.3.1 Classes of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 16.3.2 Local identifiers that are the same as common block names . . . . . . . . . . . . 485 16.3.3 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 16.3.4 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . 485 16.3.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 16.4 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 16.5 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.5.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.5.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 16.5.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 16.5.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.5.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 499 16.6.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 499 16.6.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 499 16.6.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 499 16.6.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 501 16.6.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.8 Pointer association context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 Annex A (informative)Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Annex B (informative)Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . 521 Annex C (informative)Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 C.1 Clause 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 C.1.1 Selection of the approximation methods (4.4.3) . . . . . . . . . . . . . . . . . . 523 C.1.2 Type extension and component accessibility (4.5.2.2, 4.5.4) . . . . . . . . . . . . 523 C.1.3 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 C.1.4 Pointers (4.5.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 C.1.5 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . 526 C.1.6 Generic type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 ix J3/06-007r1 WORKING DRAFT 2006/09/25 C.1.7 Final subroutines (4.5.6, 4.5.6.2, 4.5.6.3, 4.5.6.4) . . . . . . . . . . . . . . . . . . 529 C.2 Clause 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 C.2.1 The POINTER attribute (5.3.13) . . . . . . . . . . . . . . . . . . . . . . . . . . 531 C.2.2 The TARGET attribute (5.3.16) . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 C.2.3 The VOLATILE attribute (5.3.18) . . . . . . . . . . . . . . . . . . . . . . . . . . 532 C.3 Clause 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 535 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . 535 C.4 Clause 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . 537 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . 537 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . 538 C.5 Clause 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . 542 C.6 Clause 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 544 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.6.6 CLOSE statement (9.4.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7 Clause 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7.1 Number of records (10.4, 10.5, 10.8.2) . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7.2 List-directed input (10.10.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 C.8 Clause 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . 550 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 C.8.4 Modules with submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 C.9 Clause 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 C.9.1 Portability problems with external procedures (12.4.3.4) . . . . . . . . . . . . . 563 C.9.2 Procedures defined by means other than Fortran (12.6.3) . . . . . . . . . . . . . 563 C.9.3 Procedure interfaces (12.4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 C.9.4 Abstract interfaces (12.4) and procedure pointer components (4.5) . . . . . . . . 564 C.9.5 Argument association and evaluation (12.5.2) . . . . . . . . . . . . . . . . . . . 566 C.9.6 Pointers and targets as arguments (12.5.2.5, 12.5.2.7, 12.5.2.8) . . . . . . . . . . 567 C.9.7 Polymorphic Argument Association (12.5.2.10) . . . . . . . . . . . . . . . . . . . 568 C.10 Clause 13 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 C.10.1 Module for THIS IMAGE and IMAGE INDEX . . . . . . . . . . . . . . . . . . 570 C.10.2 Collective co-array subroutine variations . . . . . . . . . . . . . . . . . . . . . . 570 C.11 Clause 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 C.11.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 C.11.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . 571 C.12 Clause 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 C.12.1 Examples of host association (16.5.1.4) . . . . . . . . . . . . . . . . . . . . . . . 577 C.12.2 Rules ensuring unambiguous generics (12.4.3.3.4) . . . . . . . . . . . . . . . . . 578 C.13 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 x 2006/09/25 WORKING DRAFT J3/06-007r1 C.13.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 C.13.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 C.13.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . 588 C.13.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 C.13.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 589 C.13.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 589 C.13.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 C.13.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 C.13.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . 590 C.13.10 Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . 591 Annex D (informative)Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.1 Extract of all syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.2 Syntax rule cross-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638 Annex E (informative)Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651 xi J3/06-007r1 WORKING DRAFT 2006/09/25 xii 2006/09/25 WORKING DRAFT J3/06-007r1 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.1 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 137 7.3 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 151 7.4 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 151 7.5 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 152 7.6 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 153 7.7 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 153 7.8 Interpretation of the bits intrinsic operators . . . . . . . . . . . . . . . . . . . . . . 154 7.9 The values of bits intrinsic operations other than // . . . . . . . . . . . . . . . . . 154 7.10 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 154 7.11 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 157 7.12 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 160 7.13 Bits conversion and the assignment statement . . . . . . . . . . . . . . . . . . . . . 160 10.1 E and D exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 10.2 EN exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 10.3 ES exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 410 15.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . 468 15.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 472 xiii J3/06-007r1 WORKING DRAFT 2006/09/25 Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechni- cal Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organi- zations, governmental and nongovernmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft Interna- tional Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. ISO/IEC 1539-1 was prepared by Joint Technical Committee ISO/IEC/JTC1, Information technology, Subcommittee SC22, Programming languages, their environments and system software interfaces. This fifth edition cancels and replaces the fourth edition (ISO/IEC 1539-1:2004), which has been tech- nically revised. It also incorporates the Technical Corrigenda ISO/IEC 1539-1:2004/Cor. 1:2005 and ISO/IEC 15391:2004/Cor. 2:2006. ISO/IEC 1539 consists of the following parts, under the general title Information technology -- Pro- gramming languages -- Fortran: -- Part 1: Base language -- Part 2: Varying length character strings -- Part 3: Conditional Compilation xiv 2006/09/25 WORKING DRAFT J3/06-007r1 Introduction International Standard programming language Fortran This part of the International Standard comprises the specification of the base Fortran language, infor- mally known as Fortran 2008. With the limitations noted in 1.6.3, the syntax and semantics of Fortran 2003 are contained entirely within Fortran 2008. Therefore, any standard-conforming Fortran 2003 pro- gram not affected by such limitations is a standard-conforming Fortran 2008 program. New features of Fortran 2008 can be compatibly incorporated into such Fortran 2003 programs, with any exceptions indicated in the text of this part of the standard. Fortran 2008 contains several extensions to Fortran 2003; some of these are listed below. (1) The maximum rank of an array has been increased from seven to fifteen. (2) Performance enhancements: The DO CONCURRENT construct, which allows loop itera- tions to be executed in any order or potentially concurrently. (3) Pointers can be initialized to point to a target. (4) Performance enhancements: CONTIGUOUS attribute. (5) The ATAN intrinsic is extended so that ATAN (Y, X) is ATAN2 (Y,X). (6) Allocatable components of recursive type. (7) The MOLD= specifier has been added to the ALLOCATE statement. (8) OPEN statement enhancements that allow the processor to select a unit number when opening an external unit. Such a unit number is guaranteed not to interfere with any program-managed unit numbers. (9) The BLOCK construct (allows declarations within executable statements). (10) A disassociated or deallocated actual argument can correspond to an optional nonpointer nonallocatable dummy argument. (11) The concept of variable now includes references to pointer functions which return associated pointers. (12) The COMPILER VERSION and COMPILER OPTIONS functions provide information about the translation phase of the execution of a program. (13) The real and imaginary parts of a COMPLEX variable can be selected using a component- like syntax. (14) Scoped macros which can generate whole Fortran statements and subprograms. (15) A FINDLOC intrinsic was added and a BACK= argument was also added to MAXLOC and MINLOC. (16) Parallel programming support: SPMD parallel programming, co-arrays for data exchange between images, image control statements, and collective procedures. (17) A BITS data type for non-numeric programming and enhanced handling of BOZ constants. (18) The G0 edit descriptor. (19) Additional mathematical intrinsic functions for computing Bessel functions, the error func- tion, the Gamma function, and generalized L2 norms. J3 internal note Unresolved Technical Issue 080 The laundry list needs to be redone at a later time. RAH suggests going down the list of things in spread sheet and having a big feature and a little feature list. xv J3/06-007r1 WORKING DRAFT 2006/09/25 Organization of this part of ISO/IEC 1539 This part of ISO/IEC 1539 is organized in 16 clauses, dealing with 8 conceptual areas. These 8 areas, and the clauses in which they are treated, are: High/low level concepts Clauses 1, 2, 3 Data concepts Clauses 4, 5, 6 Computations Clauses 7, 13, 14 Execution control Clause 8 Input/output Clauses 9, 10 Program units Clauses 11, 12 Interoperability with C Clause 15 Scoping and association rules Clause 16 It also contains the following nonnormative material: Glossary A Decremental features B Extended notes C Syntax rules D Index E xvi 2006/09/25 WORKING DRAFT J3/06-007r1 Information technology -- Programming languages -- 1 Fortran -- 2 Part 1: 3 Base Language 4 1 Overview 5 1.1 Scope 6 ISO/IEC 1539 is a multipart International Standard; the parts are published separately. This publi- 7 cation, ISO/IEC 1539-1, which is the first part, specifies the form and establishes the interpretation 8 of programs expressed in the base Fortran language. The purpose of this part of ISO/IEC 1539 is to 9 promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on 10 a variety of computing systems. The second part, ISO/IEC 1539-2, defines additional facilities for the 11 manipulation of character strings of variable length; this has been largely subsumed by allocatable char- 12 acters with deferred length parameters. The third part, ISO/IEC 1539-3, defines a standard conditional 13 compilation facility for Fortran. A processor conforming to part 1 need not conform to ISO/IEC 1539-2 14 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. Throughout this 15 publication, the term "this standard" refers to ISO/IEC 1539-1. 16 1.2 Processor 17 The combination of a computing system and the mechanism by which programs are transformed for use 18 on that computing system is called a processor in this part of ISO/IEC 1539. 19 1.3 Inclusions 20 This part of ISO/IEC 1539 specifies 21 (1) the forms that a program written in the Fortran language may take, 22 (2) the rules for interpreting the meaning of a program and its data, 23 (3) the form of the input data to be processed by such a program, and 24 (4) the form of the output data resulting from the use of such a program. 25 1.4 Exclusions 26 This part of ISO/IEC 1539 does not specify 27 (1) the mechanism by which programs are transformed for use on computing systems, 28 (2) the operations required for setup and control of the use of programs on computing systems, 29 (3) the method of transcription of programs or their input or output data to or from a storage 30 medium, 31 1 J3/06-007r1 WORKING DRAFT 2006/09/25 (4) the program and processor behavior when this part of ISO/IEC 1539 fails to establish an 1 interpretation except for the processor detection and reporting requirements in items (2) to 2 (8) of 1.5, 3 (5) the size or complexity of a program and its data that will exceed the capacity of any 4 particular computing system or the capability of a particular processor, 5 (6) the physical properties of the representation of quantities and the method of rounding, 6 approximating, or computing numeric values on a particular processor, 7 (7) the physical properties of input/output records, files, and units, or 8 (8) the physical properties and implementation of storage. 9 1.5 Conformance 10 A program (2.2.2) is a standard-conforming program if it uses only those forms and relationships 11 described herein and if the program has an interpretation according to this part of ISO/IEC 1539. A 12 program unit (2.2.1) conforms to this part of ISO/IEC 1539 if it can be included in a program in a 13 manner that allows the program to be standard conforming. 14 A processor conforms to this part of ISO/IEC 1539 if: 15 (1) it executes any standard-conforming program in a manner that fulfills the interpretations 16 herein, subject to any limits that the processor may impose on the size and complexity of 17 the program; 18 (2) it contains the capability to detect and report the use within a submitted program unit of 19 a form designated herein as obsolescent, insofar as such use can be detected by reference to 20 the numbered syntax rules and constraints; 21 (3) it contains the capability to detect and report the use within a submitted program unit of 22 an additional form or relationship that is not permitted by the numbered syntax rules or 23 constraints, including the deleted features described in Annex B; 24 (4) it contains the capability to detect and report the use within a submitted program unit of 25 an intrinsic type with a kind type parameter value not supported by the processor (4.4); 26 (5) it contains the capability to detect and report the use within a submitted program unit of 27 source form or characters not permitted by Clause 3; 28 (6) it contains the capability to detect and report the use within a submitted program of name 29 usage not consistent with the scope rules for names, labels, operators, and assignment 30 symbols in Clause 16; 31 (7) it contains the capability to detect and report the use within a submitted program unit of 32 intrinsic procedures whose names are not defined in Clause 13; and 33 (8) it contains the capability to detect and report the reason for rejecting a submitted program. 34 However, in a format specification that is not part of a FORMAT statement (10.2.1), a processor need not 35 detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 36 A standard-conforming processor may allow additional forms and relationships provided that such ad- 37 ditions do not conflict with the standard forms and relationships. However, a standard-conforming 38 processor may allow additional intrinsic procedures even though this could cause a conflict with the 39 name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 40 of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 41 given the EXTERNAL attribute (5.3.8) in the scoping unit (2.2.1). A standard-conforming program 42 shall not use nonstandard intrinsic procedures or modules that have been added by the processor. 43 Because a standard-conforming program may place demands on a processor that are not within the 44 scope of this part of ISO/IEC 1539 or may include standard items that are not portable, such as 45 external procedures defined by means other than Fortran, conformance to this part of ISO/IEC 1539 46 2 2006/09/25 WORKING DRAFT J3/06-007r1 does not ensure that a program will execute consistently on all or any standard-conforming processors. 1 In some cases, this part of ISO/IEC 1539 allows the provision of facilities that are not completely specified 2 in the standard. These facilities are identified as processor dependent. They shall be provided, with 3 methods or semantics determined by the processor. 4 NOTE 1.1 The processor should be accompanied by documentation that specifies the limits it imposes on the size and complexity of a program and the means of reporting when these limits are exceeded, that defines the additional forms and relationships it allows, and that defines the means of reporting the use of additional forms and relationships and the use of deleted or obsolescent forms. In this context, the use of a deleted form is the use of an additional form. The processor should be accompanied by documentation that specifies the methods or semantics of processor-dependent facilities. 1.6 Compatibility 5 1.6.1 New intrinsic procedures 6 Each Fortran International Standard since ISO 1539:1980 (informally referred to as Fortran 77), defines 7 more intrinsic procedures than the previous one. Therefore, a Fortran program conforming to an older 8 standard may have a different interpretation under a newer standard if it invokes an external procedure 9 having the same name as one of the new standard intrinsic procedures, unless that procedure is specified 10 to have the EXTERNAL attribute. 11 1.6.2 New intrinsic data type and operator 12 This part of ISO/IEC 1539 specifies a new intrinsic type, BITS, which will conflict with a derived type 13 of the same name. 14 This part of ISO/IEC 1539 specifies a new intrinsic operator, .XOR., which might conflict with a user- 15 defined operator of the same name, has a different precedence from that of a user-defined operator, and 16 a different syntax from that of a user-defined unary operator. 17 1.6.3 Fortran 2003 compatibility 18 Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension 19 to the preceding Fortran International Standard, ISO/IEC 1539-1:2004 (Fortran 2003). Any standard- 20 conforming Fortran 2003 program that does not use a derived type called BITS, and does not use a 21 user-defined operator called .XOR., remains standard-conforming under this part of ISO/IEC 1539. 22 1.6.4 Fortran 95 compatibility 23 Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension to 24 ISO/IEC 1539-1:1997 (Fortran 95). Any standard-conforming Fortran 95 program that does not use a 25 derived type called BITS or a user-defined operator called .XOR. remains standard-conforming under 26 this part of ISO/IEC 1539. The following Fortran 95 features may have different interpretations in this 27 part of ISO/IEC 1539. 28 (1) Earlier Fortran standards had the concept of printing, meaning that column one of formatted 29 output had special meaning for a processor-dependent (possibly empty) set of external 30 files. This could be neither detected nor specified by a standard-specified means. The 31 interpretation of the first column is not specified by this part of ISO/IEC 1539. 32 3 J3/06-007r1 WORKING DRAFT 2006/09/25 (2) This part of ISO/IEC 1539 specifies a different output format for real zero values in list- 1 directed and namelist output. 2 (3) If the processor can distinguish between positive and negative real zero, this part of ISO/IEC 3 1539 requires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real 4 zero and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative 5 zero imaginary part. 6 1.6.5 Fortran 90 compatibility 7 Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 8 of ISO/IEC 1539 is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard- 9 conforming Fortran 90 program that does not use a derived type called BITS, a user-defined operator 10 called .XOR., or one of the deleted features remains standard-conforming under this part of ISO/IEC 11 1539. 12 The PAD= specifier in the INQUIRE statement in this part of ISO/IEC 1539 returns the value UNDE- 13 FINED if there is no connection or the connection is for unformatted input/output. Fortran 90 specified 14 YES. 15 Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor 16 dependent. this part of ISO/IEC 1539 specifies that the second argument shall not be zero. 17 1.6.6 FORTRAN 77 compatibility 18 Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 19 of ISO/IEC 1539 is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard- 20 conforming Fortran 77 program that does not use one of the deleted features noted in Annex B.1 and 21 that does not depend on the differences specified here remains standard-conforming under this part of 22 ISO/IEC 1539. This part of ISO/IEC 1539 restricts the behavior for some features that were processor 23 dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program that uses one of 24 these processor-dependent features may have a different interpretation under this part of ISO/IEC 1539, 25 yet remain a standard-conforming program. The following Fortran 77 features may have different 26 interpretations in this part of ISO/IEC 1539. 27 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 28 than can be represented in a real datum when the constant is used to initialize a data object 29 of type double precision real in a DATA statement. This part of ISO/IEC 1539 does not 30 permit a processor this option. 31 (2) If a named variable that was not in a common block was initialized in a DATA statement and 32 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 33 dependent. This part of ISO/IEC 1539 specifies (5.4.6) that this named variable has the 34 SAVE attribute. 35 (3) Fortran 77 specified that the number of characters required by the input list was to be 36 less than or equal to the number of characters in the record during formatted input. This 37 part of ISO/IEC 1539 specifies (9.5.4.4.2) that the input record is logically padded with 38 blanks if there are not enough characters in the record, unless the PAD= specifier with the 39 value 'NO' is specified in an appropriate OPEN or READ statement. 40 (4) A value of 0 for a list item in a formatted output statement will be formatted in a different 41 form for some G edit descriptors. In addition, this part of ISO/IEC 1539 specifies how 42 rounding of values will affect the output field form, but Fortran 77 did not address this 43 issue. Therefore, some Fortran 77 processors may produce an output form different from 44 the output form produced by Fortran 2003 processors for certain combinations of values and 45 G edit descriptors. 46 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 47 4 2006/09/25 WORKING DRAFT J3/06-007r1 SIGN intrinsic function when the second argument is negative real zero is changed by this 1 part of ISO/IEC 1539. 2 1.7 Notation used in this part of ISO/IEC 1539 3 1.7.1 Applicability of requirements 4 In this part of ISO/IEC 1539, "shall" is to be interpreted as a requirement; conversely, "shall not" is 5 to be interpreted as a prohibition. Except where stated otherwise, such requirements and prohibitions 6 apply to programs rather than processors. 7 1.7.2 Informative notes 8 Informative notes of explanation, rationale, examples, and other material are interspersed with the 9 normative body of this part of ISO/IEC 1539. The informative material is nonnormative; it is identified 10 by being in shaded, framed boxes that have numbered headings beginning with "NOTE." 11 1.7.3 Syntax rules 12 Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These 13 syntax rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions. 14 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 15 where otherwise noted. 16 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 17 eral syntactic classes for which particular syntactic entities shall be substituted in actual 18 statements. 19 Common abbreviations used in syntactic terms are: 20 arg for argument attr for attribute decl for declaration def for definition desc for descriptor expr for expression int for integer op for operator spec for specifier stmt for statement (3) The syntactic metasymbols used are: 21 is introduces a syntactic class definition or introduces a syntactic class alternative [] encloses an optional item [ ] ... encloses an optionally repeated item that may occur zero or more times continues a syntax rule (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a 22 one- or two-digit clause number and nn is a two-digit sequence number within that clause. 23 The syntax rules are distributed as appropriate throughout the text, and are referenced by 24 number as needed. Some rules in Clauses 2 and 3 are more fully described in later clauses; in 25 such cases, the clause number s is the number of the later clause where the rule is repeated. 26 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 27 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 28 restricted by corresponding constraints and text. 29 5 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 1.2 An example of the use of the syntax rules is: digit-string is digit [ digit ] ... The following are examples of forms for a digit string allowed by the above rule: digit digit digit digit digit digit digit digit digit digit digit digit digit digit digit If particular entities are substituted for digit, actual digit strings might be: 4 67 1999 10243852 1.7.4 Constraints 1 Each constraint is given a unique identifying number of the form Csn, where s is a one or two digit clause 2 number and nn is a two or three digit sequence number within that clause. 3 Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 4 annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 5 rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places 6 where the syntax term appears. 7 Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 8 to that of a restriction stated in the text, except that a processor is required to have the capability to 9 detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 10 and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 11 conforming program is required to adhere to the broad requirement, but that a standard-conforming 12 processor is required only to have the capability of diagnosing violations of the constraint. 13 1.7.5 Assumed syntax rules 14 In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 15 tion, the following rules are assumed. 16 R101 xyz-list is xyz [ , xyz ] ... 17 R102 xyz-name is name 18 R103 scalar-xyz is xyz 19 C101 (R103) scalar-xyz shall be scalar. 20 The letters "xyz " stand for any syntactic class phrase. An explicit syntax rule for a term overrides an 21 assumed rule. 22 1.7.6 Syntax conventions and characteristics 23 (1) Any syntactic class name ending in "-stmt" follows the source form statement rules: it shall 24 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 25 statement (such as an IF or WHERE statement). Conversely, everything considered to be 26 a source form statement is given a "-stmt" ending in the syntax rules. 6 2006/09/25 WORKING DRAFT J3/06-007r1 (2) The rules on statement ordering are described rigorously in the definition of program-unit 1 (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 2 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 3 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" 4 in R510), and in a few other cases. 5 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 6 suffix "-selector " is used. See, for example, "kind-selector " (R405) and "length-selector " 7 (R421). 8 (5) The term "subscript" (for example, R619, R620, and R621) is used consistently in array 9 definitions. 10 1.7.7 Text conventions 11 In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 12 Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 13 statement". Boldface words are used in the text where they are first defined with a specialized meaning. 14 The descriptions of obsolescent features appear in a smaller type size. 15 NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 1.8 Deleted and obsolescent features 16 1.8.1 General 17 This part of ISO/IEC 1539 protects the users' investment in existing software by including all but five 18 of the language elements of Fortran 90 that are not processor dependent. This part of ISO/IEC 1539 19 identifies two categories of outmoded features. There are five in the first category, deleted features, 20 which consists of features considered to have been redundant in Fortran 77 and largely unused in 21 Fortran 90. Those in the second category, obsolescent features, are considered to have been redundant 22 in Fortran 90 and Fortran 95, but are still frequently used. 23 1.8.2 Nature of deleted features 24 Better methods existed in Fortran 77 for each deleted feature. These features were not included in 25 Fortran 95 or Fortran 2003, and are not included in this revision of Fortran. 26 1.8.3 Nature of obsolescent features 27 Better methods existed in Fortran 90 and Fortran 95 for each obsolescent feature. It is recommended 28 that programmers use these better methods in new programs and convert existing code to these methods. 29 The obsolescent features are identified in the text of this part of ISO/IEC 1539 by a distinguishing type 30 font (1.7.7). 31 A future revision of this part of ISO/IEC 1539 might delete an obscolescent feature if its use has become 32 insignificant. 33 1.9 Normative references 34 The following referenced standards are indispensable for the application of this part of ISO/IEC 1539. 35 For dated references, only the edition cited applies. For undated references, the latest edition of the 36 7 J3/06-007r1 WORKING DRAFT 2006/09/25 referenced standard (including any amendments) applies. 1 ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 2 ISO 8601:1988, Data elements and interchange formats--Information interchange-- 3 Representation of dates and times. 4 ISO/IEC 9899:1999, Information technology--Programming languages--C. 5 ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 6 Part 1: Architecture and basic multilingual plane. 7 IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 8 ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 9 commonly known as ASCII. 10 This part of ISO/IEC 1539 refers to ISO/IEC 9899:1999 as the C International Standard. 11 Because IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arith- 12 metic, and is widely known by this name, this standard refers to it as the IEEE International Standard. 13 8 2006/09/25 WORKING DRAFT J3/06-007r1 2 Fortran terms and concepts 1 2.1 High level syntax 2 This clause introduces the terms associated with program units and other Fortran concepts above the 3 construct, statement, and expression levels and illustrates their relationships. The notation used in this 4 part of ISO/IEC 1539is described in 1.7. 5 NOTE 2.1 Constraints and other information related to the rules that do not begin with R2 appear in the appropriate clause. R201 program is program-unit 6 [ program-unit ] ... 7 A program shall contain exactly one main-program program-unit or a main program defined by means 8 other than Fortran, but not both. 9 R202 program-unit is main-program 10 or external-subprogram 11 or module 12 or submodule 13 or block-data 14 R1101 main-program is [ program-stmt ] 15 [ specification-part ] 16 [ execution-part ] 17 [ internal-subprogram-part ] 18 end-program-stmt 19 R203 external-subprogram is function-subprogram 20 or subroutine-subprogram 21 R1225 function-subprogram is function-stmt 22 [ specification-part ] 23 [ execution-part ] 24 [ internal-subprogram-part ] 25 end-function-stmt 26 R1233 subroutine-subprogram is subroutine-stmt 27 [ specification-part ] 28 [ execution-part ] 29 [ internal-subprogram-part ] 30 end-subroutine-stmt 31 R1104 module is module-stmt 32 [ specification-part ] 33 [ module-subprogram-part ] 34 end-module-stmt 35 R1116 submodule is submodule-stmt 36 [ specification-part ] 37 [ module-subprogram-part ] 38 end-submodule-stmt 39 R1120 block-data is block-data-stmt 40 [ specification-part ] 41 9 J3/06-007r1 WORKING DRAFT 2006/09/25 end-block-data-stmt 1 R204 specification-part is [ use-stmt ] ... 2 [ import-stmt ] ... 3 [ implicit-part ] 4 [ declaration-construct ] ... 5 R205 implicit-part is [ implicit-part-stmt ] ... 6 implicit-stmt 7 R206 implicit-part-stmt is implicit-stmt 8 or parameter-stmt 9 or format-stmt 10 or entry-stmt 11 R207 declaration-construct is derived-type-def 12 or entry-stmt 13 or enum-def 14 or format-stmt 15 or interface-block 16 or macro-definition 17 or parameter-stmt 18 or procedure-declaration-stmt 19 or specification-stmt 20 or type-declaration-stmt 21 or stmt-function-stmt 22 R208 execution-part is executable-construct 23 [ execution-part-construct ] ... 24 R209 execution-part-construct is executable-construct 25 or format-stmt 26 or entry-stmt 27 or data-stmt 28 R210 internal-subprogram-part is contains-stmt 29 [ internal-subprogram ] ... 30 R211 internal-subprogram is function-subprogram 31 or subroutine-subprogram 32 R1107 module-subprogram-part is contains-stmt 33 [ module-subprogram ] ... 34 R1108 module-subprogram is function-subprogram 35 or subroutine-subprogram 36 or separate-module-subprogram 37 R212 specification-stmt is access-stmt 38 or allocatable-stmt 39 or asynchronous-stmt 40 or bind-stmt 41 or common-stmt 42 or data-stmt 43 or dimension-stmt 44 or equivalence-stmt 45 or external-stmt 46 or intent-stmt 47 or intrinsic-stmt 48 or namelist-stmt 49 or optional-stmt 50 or pointer-stmt 51 or protected-stmt 52 or save-stmt 53 or target-stmt 54 10 2006/09/25 WORKING DRAFT J3/06-007r1 or volatile-stmt 1 or value-stmt 2 R213 executable-construct is action-stmt 3 or associate-construct 4 or block-construct 5 or case-construct 6 or critical-construct 7 or do-construct 8 or forall-construct 9 or if-construct 10 or select-type-construct 11 or where-construct 12 R214 action-stmt is allocate-stmt 13 or assignment-stmt 14 or backspace-stmt 15 or call-stmt 16 or close-stmt 17 or continue-stmt 18 or cycle-stmt 19 or deallocate-stmt 20 or endfile-stmt 21 or end-function-stmt 22 or end-program-stmt 23 or end-subroutine-stmt 24 or exit-stmt 25 or flush-stmt 26 or forall-stmt 27 or goto-stmt 28 or if-stmt 29 or inquire-stmt 30 or notify-stmt 31 or nullify-stmt 32 or open-stmt 33 or pointer-assignment-stmt 34 or print-stmt 35 or query-stmt 36 or read-stmt 37 or return-stmt 38 or rewind-stmt 39 or stop-stmt 40 or sync-all-stmt 41 or sync-images-stmt 42 or sync-memory-stmt 43 or sync-team-stmt 44 or wait-stmt 45 or where-stmt 46 or write-stmt 47 or 48 arithmetic-if-stmt or computed-goto-stmt 49 C201 (R208) An execution-part shall not contain an end-function-stmt, end-program-stmt, or end- 50 subroutine-stmt. 51 Additionally, an EXPAND statement may occur anywhere that any statement may occur other than 52 11 J3/06-007r1 WORKING DRAFT 2006/09/25 as the first statement of a program unit. The syntax rules are applied to the program after macro 1 expansion, i.e. with each EXPAND statement replaced by the statements it produces. 2 2.2 Program unit concepts 3 2.2.1 Program units and scoping units 4 Program units are the fundamental components of a Fortran program. A program unit may be 5 a main program, an external subprogram, a module, a submodule, or a block data program unit. A 6 subprogram may be a function subprogram or a subroutine subprogram. A module contains definitions 7 that are to be made accessible to other program units. A submodule is a extension of a module; it may 8 contain the definitions of procedures declared in a module or another submodule. A block data program 9 unit is used to specify initial values for data objects in named common blocks. Each type of program 10 unit is described in Clause 11 or 12. An external subprogram is a subprogram that is not in a main 11 program, a module, a submodule, or another subprogram. An internal subprogram is a subprogram 12 that is in a main program or another subprogram. A module subprogram is a subprogram that is in 13 a module or submodule but is not an internal subprogram. 14 A program unit consists of a set of nonoverlapping scoping units. A scoping unit is 15 (1) a program unit or subprogram, excluding any scoping units in it, 16 (2) a derived-type definition (4.5.2), or 17 (3) an interface body, excluding any scoping units in it. 18 A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often 19 abbreviated to host). A module or submodule is also the host scoping unit of its child submodules. 20 2.2.2 Program 21 A program consists of exactly one main program, any number (including zero) of other kinds of program 22 units, and any number (including zero) of external procedures and other entities defined by means other 23 than Fortran. 24 NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). This part of ISO/IEC 1539places no ordering requirement on the program units that constitute a program, but because the public portions of a module are required to be available by the time a module reference (11.2.2) is processed, a processor may require a particular order of processing of the program units. 2.2.3 Main program 25 The Fortran main program is described in 11.1. 26 2.2.4 Procedure 27 A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 28 execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 29 in an expression; its invocation causes a value to be computed which is then used in evaluating the 30 expression. The variable that returns the value of a function is called the result variable. A subroutine 31 is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 32 operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 33 12 2006/09/25 WORKING DRAFT J3/06-007r1 the program state by changing the values of any of the data objects accessible to the subroutine; unless 1 it is a pure procedure, a function may do this in addition to computing the function value. 2 Procedures are described further in Clause 12. 3 2.2.4.1 External procedure 4 An external procedure is a procedure that is defined by an external subprogram or by means other 5 than Fortran. An external procedure may be invoked by the main program or by any procedure of a 6 program. 7 2.2.4.2 Module procedure 8 A module procedure is a procedure that is defined by a module subprogram (R1108). The module or 9 submodule containing the subprogram is the host scoping unit of the module procedure. 10 2.2.4.3 Internal procedure 11 An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 12 main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 13 is local to its host in the sense that the internal procedure is accessible within the host scoping unit and 14 all its other internal procedures but is not accessible elsewhere. 15 2.2.4.4 Interface block 16 An interface body describes an abstract interface or the interface of a dummy procedure, external 17 procedure, procedure pointer, or type-bound procedure. 18 An interface block is a specific interface block, an abstract interface block, or a generic interface block. 19 A specific interface block is a collection of interface bodies. A generic interface block can also be used 20 to specify that a procedure can be invoked 21 (1) by using a generic name, 22 (2) by using a defined operator, 23 (3) by using a defined assignment, or 24 (4) for derived-type input/output. 25 2.2.5 Module 26 A module contains (or accesses from other modules) definitions that are to be made accessible to other 27 program units. These definitions include data object declarations, type definitions, procedure definitions, 28 and interface blocks. A scoping unit in another program unit may access the definitions in a module. 29 Modules are further described in Clause 11. 30 2.2.6 Submodule 31 A submodule is a program unit that extends a module or another submodule. It may provide definitions 32 (12.6) for procedures whose interfaces are declared (12.4.3.2) in an ancestor module or submodule. It 33 may also contain declarations and definitions of other entities, which are accessible in its descendants. 34 An entity declared in a submodule is not accessible by use association unless it is a module procedure 35 whose interface is declared in the ancestor module. Submodules are further described in Clause 11. 36 NOTE 2.3 The scoping unit of a submodule accesses the scoping unit of its parent module or submodule by host association. 13 J3/06-007r1 WORKING DRAFT 2006/09/25 2.3 Execution concepts 1 2.3.1 Statement classification 2 Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 3 There are restrictions on the order in which statements may appear in a program unit, and not all 4 executable statements may appear in all contexts. 5 2.3.2 Program execution 6 An instance of a Fortran program is an image. Execution of a program consists of the asynchronous 7 execution of a fixed number (which may be one) of its images. Each image has its own execution state, 8 floating point status (14.6), and set of data objects and procedure pointers. Whether a file is available 9 on any image or only on a specific image is processor dependent. Each image is identified by an image 10 index, which is an integer value in the range one to the number of images. 11 NOTE 2.4 The programmer controls the progress of execution in each image through explicit use of Fortran control constructs (8.1, 8.2). Image control statements (8.5.1) affect the relative progress of exe- cution between images. Co-arrays (2.4.6) provide a mechanism for accessing data on one image from another image. NOTE 2.5 A processor might allow the number of images to be chosen at compile time, link time, or run time. It might be the same as the number of CPUs but this is not required. Compiling for a single image might permit the optimizer to eliminate overhead associated with parallel execution. Portable programs should not make assumptions about the exact number of images. The maximum number of images may be limited due to architectural constraints. A team is a set of images formed by invoking the intrinsic collective subroutine FORM TEAM (13.7.69) 12 for the purposes of collaboration. A team is identified by a scalar variable of type IMAGE TEAM 13 (13.8.3.7). 14 2.3.3 Executable/nonexecutable statements 15 Image execution is a sequence, in time, of actions. An executable statement is an instruction to 16 perform or control one or more of these actions. Thus, the executable statements of a program unit 17 determine the behavior of the program unit. The executable statements are all of those that make up 18 the syntactic class executable-construct. 19 J3 internal note Unresolved Technical Issue 095 The above definition is incorrect after the addition of the BLOCK construct, since it now includes the specification statements. It needs to be rewritten more carefully. Nonexecutable statements do not specify actions; they are used to configure the program environment 20 in which actions take place. The nonexecutable statements are all those not classified as executable. 21 2.3.4 Statement order 22 The syntax rules of clause 2.1 specify the statement order within program units and subprograms. These 23 rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for statements and 24 applies to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of 25 14 2006/09/25 WORKING DRAFT J3/06-007r1 statements that may be interspersed and horizontal lines delineate varieties of statements that shall not 1 be interspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE 2 and CONTAINS statements in a subprogram, nonexecutable statements generally precede executable 3 statements, although the ENTRY statement, FORMAT statement, and DATA statement may appear 4 among the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. 5 Table 2.1: Requirements on statement ordering PROGRAM, FUNCTION, SUBROUTINE, MODULE, SUBMODULE, or BLOCK DATA statement USE statements IMPORT statements IMPLICIT NONE PARAMETER IMPLICIT statements statements Derived-type definitions, FORMAT interface blocks, and PARAMETER type declaration statements, ENTRY and DATA enumeration definitions, statements statements procedure declarations, specification statements, and statement function statements Executable DATA constructs statements CONTAINS statement Internal subprograms or module subprograms END statement Table 2.2: Statements allowed in scoping units Kind of scoping unit1 Main Module or Block External Module Internal Interface Statement type program submodule data subprog subprog subprog body USE Yes Yes Yes Yes Yes Yes Yes IMPORT No No No No No No Yes ENTRY No No No Yes Yes No No FORMAT Yes No No Yes Yes Yes No Misc. decl.s 2 Yes Yes Yes Yes Yes Yes Yes DATA Yes Yes Yes Yes Yes Yes No Derived-type Yes Yes Yes Yes Yes Yes Yes Interface Yes Yes No Yes Yes Yes Yes Executable Yes No No Yes Yes Yes No CONTAINS Yes Yes No Yes Yes No No Statement function Yes No No Yes Yes Yes No (1) The scoping unit of a module or submodule does not include any module subprograms that it contains. 15 J3/06-007r1 WORKING DRAFT 2006/09/25 Statements allowed in scoping units Kind of scoping unit1 Main Module or Block External Module Internal Interface Statement type program submodule data subprog subprog subprog body (2) Miscellaneous declarations are PARAMETER statements, IMPLICIT statements, type declaration statements, enumeration definitions, procedure declaration statements, and spec- ification statements. 2.3.5 The END statement 1 An end-program-stmt, end-function-stmt, end-subroutine-stmt, end-mp-subprogram-stmt, end-module- 2 stmt, end-submodule-stmt, or end-block-data-stmt is an END statement. Each program unit, module 3 subprogram, and internal subprogram shall have exactly one END statement. The end-program-stmt, 4 end-function-stmt, end-subroutine-stmt, and end-mp-subprogram-stmt statements are executable, and 5 may be branch target statements (8.2). Executing an end-program-stmt causes normal termination of 6 execution of the program. Executing an end-function-stmt, end-subroutine-stmt, or end-mp-subprogram- 7 stmt is equivalent to executing a return-stmt with no scalar-int-expr . 8 The end-module-stmt, end-submodule-stmt, and end-block-data-stmt statements are nonexecutable. 9 2.3.6 Execution sequence 10 If a program contains a Fortran main program, execution of the program begins by creating a fixed 11 number of instances of the program; each image begins execution with the first executable construct of 12 the main program. The execution of a main program or subprogram involves execution of the executable 13 constructs within its scoping unit. When a Fortran procedure is invoked, the specification expressions 14 within the specification-part of the invoked procedure, if any, are evaluated in a processor dependent 15 order. Thereafter, execution proceeds to the first executable construct appearing after the invoked 16 entry point. With the following exceptions, the effect of execution is as if the executable constructs are 17 executed in the order in which they appear in the main program or subprogram until a STOP, RETURN, 18 or END statement is executed. 19 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 20 explicitly specify a new starting place for the execution sequence. 21 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 22 an internal statement structure and execution of these constructs involves implicit internal 23 branching. See Clause 8 for the detailed semantics of each of these constructs. 24 (3) BLOCK constructs may contain specification expressions; see 8.1.4 for detailed semantics 25 of this construct. 26 (4) END=, ERR=, and EOR= specifiers may result in a branch. 27 (5) Alternate returns may result in a branch. 28 Internal subprograms may precede the END statement of a main program or a subprogram. The 29 execution sequence excludes all such definitions. 30 The relative ordering of the exeuction sequences of different images can be affected by image control 31 statements (8.5.1). 32 Normal termination of execution of an image occurs if a STOP statement is executed on that image. Ex- 33 ecution of an end-program-stmt results in a synchronization of all images followed by normal termination 34 of execution of all images. Normal termination of execution of an image also may occur during execution 35 of a procedure defined by a companion processor (C International Standard 5.1.2.2.3 and 7.20.4.3). If 36 16 2006/09/25 WORKING DRAFT J3/06-007r1 normal termination of execution occurs within a Fortran program unit and the program incorporates 1 procedures defined by a companion processor, the process of execution termination shall include the 2 effect of executing the C exit() function (C International Standard 7.20.4.3). 3 2.4 Data concepts 4 Nonexecutable statements are used to specify the characteristics of the data environment. This includes 5 typing variables, declaring arrays, and defining new types. 6 2.4.1 Type 7 A type is a named category of data that is characterized by a set of values, a syntax for denoting 8 these values, and a set of operations that interpret and manipulate the values. This central concept is 9 described in 4.1. 10 A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 11 the set of operations depend on the values of one or more parameters. Such a parameter is called a type 12 parameter (4.2). 13 There are two categories of types: intrinsic types and derived types. 14 2.4.1.1 Intrinsic type 15 An intrinsic type is a type that is defined by the language, along with operations, and is always 16 accessible. The intrinsic types are integer, real, complex, character, logical, and bits. The properties of 17 intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. 18 The kind type parameter indicates the representation method for the specified type. 19 2.4.1.2 Derived type 20 A derived type is a type that is defined by a type definition or by an intrinsic module. A scalar object of 21 derived type is called a structure (4.5). Derived types may be parameterized. Assignment of structures 22 is defined intrinsically (7.4.1.3), but there are no intrinsic operations for structures. For each derived 23 type, a structure constructor is available to provide values (4.5.10). In addition, data objects of derived 24 type may be used as procedure arguments and function results, and may appear in input/output lists. 25 If additional operations are needed for a derived type, they shall be supplied as procedure definitions. 26 Derived types are described further in 4.5. 27 2.4.2 Data value 28 Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 29 on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 30 that objects of a derived type may assume are determined by the type definition, type parameter values, 31 and the sets of values of its components. 32 2.4.3 Data entity 33 A data entity is a data object, the result of the evaluation of an expression, or the result of the execution 34 of a function reference (called the function result). A data entity has a type and type parameters; it 35 may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 36 either a scalar or an array. 37 17 J3/06-007r1 WORKING DRAFT 2006/09/25 2.4.3.1 Data object 1 A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a 2 constant. The type and type parameters of a named data object may be specified explicitly (5.2) or 3 implicitly (5.5). 4 Subobjects are portions of certain objects that may be referenced and defined (variables only) inde- 5 pendently of the other portions. These include portions of arrays (array elements and array sections), 6 portions of character strings (substrings), portions of complex objects (real and imaginary parts), and 7 portions of structures (components). Subobjects are themselves data objects, but subobjects are refer- 8 enced only by object designators or intrinsic functions. A subobject of a variable is a variable. Subobjects 9 are described in Clause 6. 10 Objects referenced by a name are: 11 a named scalar (a scalar object) a named array (an array object) 12 Subobjects referenced by an object designator are: 13 an array element (a scalar subobject) an array section (an array subobject) a structure component (a scalar or an array subobject) a substring (a scalar subobject) 14 2.4.3.1.1 Variable 15 A variable may have a value and may be defined and redefined during execution of a program. 16 A named local variable of the scoping unit of a module, submodule, main program, or subprogram, 17 is a named variable that is a local entity of the scoping unit, is not a dummy argument, is not in 18 COMMON, does not have the BIND attribute, and is not accessed by use or host association. A named 19 local variable of a BLOCK construct is a named variable that is declared in that construct, is not in 20 COMMON, does not have the BIND attribute, and is not accessed by use association.A subobject of a 21 named local variable is also a local variable. 22 2.4.3.1.2 Constant 23 A constant has a value and cannot become defined, redefined, or undefined during execution of a 24 program. A constant with a name is called a named constant and has the PARAMETER attribute 25 (5.3.12). A constant without a name is called a literal constant (4.4). 26 2.4.3.1.3 Subobject of a constant 27 A subobject of a constant is a portion of a constant. The portion referenced may depend on the 28 value of a variable. 29 NOTE 2.6 For example, given: CHARACTER (LEN = 10), PARAMETER :: DIGITS = '0123456789' CHARACTER (LEN = 1) :: DIGIT INTEGER :: I ... DIGIT = DIGITS (I:I) 18 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 2.6 (cont.) DIGITS is a named constant and DIGITS (I:I) designates a subobject of the constant DIGITS. 2.4.3.2 Expression 1 An expression (7.1) produces a data entity when evaluated. An expression represents either a data 2 reference or a computation; it is formed from operands, operators, and parentheses. The type, type 3 parameters, value, and rank of an expression result are determined by the rules in Clause 7. 4 2.4.3.3 Function reference 5 A function reference (12.5.3) produces a data entity when the function is executed during expression 6 evaluation. The type, type parameters, and rank of a function result are determined by the interface of 7 the function (12.3.3). The value of a function result is determined by execution of the function. 8 2.4.4 Scalar 9 A scalar is a datum that is not an array. Scalars may be of any type. 10 NOTE 2.7 A structure is scalar even if it has arrays as components. The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. 11 2.4.5 Array 12 An array is a set of scalar data, all of the same type and type parameters, whose individual elements 13 are arranged in a rectangular pattern. An array element is one of the individual elements in the array 14 and is a scalar. An array section is a subset of the elements of an array and is itself an array. 15 An array may have up to fifteen dimensions, and any extent (number of elements) in any dimension. 16 The rank of the array is the number of dimensions; its size is the total number of elements, which is 17 equal to the product of the extents. An array may have zero size. The shape of an array is determined 18 by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 19 are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 20 declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 21 vary during execution. 22 Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 23 intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations 24 are performed element-by-element to produce a resultant array conformable with the array operands. 25 Element-by-element operation means corresponding elements of the operand arrays are involved in a 26 scalar operation to produce the corresponding element in the result array. Such an operation is described 27 as elemental. 28 NOTE 2.8 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. A rank-one array may be constructed from scalars and other arrays and may be reshaped into any 29 allowable array shape (4.7). 30 Arrays may be of any type and are described further in 6.2. 31 19 J3/06-007r1 WORKING DRAFT 2006/09/25 2.4.6 Co-array 1 A co-array is a data entity that has nonzero co-rank; it can be directly referenced or defined by any 2 image. It may be a scalar or an array. 3 For each co-array on an image, there is a corresponding co-array with the same type, type parameters, 4 and bounds on every other image. If a co-array is scalar, the set of corresponding co-arrays on all the 5 images is arranged in a rectangular pattern. If a co-array is an array, the set of corresponding co-array 6 elements on all the images is arranged in a rectangular pattern. In both cases, the dimensions of the 7 pattern are called co-dimensions. 8 A co-array on another image can be accessed directly by using co-subscripts. On its own image, a 9 co-array can be accessed without use of co-subscripts. 10 The co-rank of a co-array is the number of co-dimensions. The co-size of a co-array is always equal to 11 the number of images. 12 J3 internal note Unresolved Technical Issue 007 The term "co-dimension" is not defined. It might be better to define co-array in terms of being a rectangular set of objects in co-rank "co-dimensions" etc., similarly to how we define arrays. An object whose designator includes an image-selector is a co-indexed object. For a co-indexed object, 13 its co-subscript list determines the image index in the same way that a subscript list determines the 14 subscript order value for an array element (6.2.2.2). 15 Intrinsic procedures are provided for mapping between an image index and a list of co-subscripts. 16 NOTE 2.9 The mechanism for an image to reference and define a co-array on another image might vary according to the hardware. On a shared-memory machine, a co-array could be implemented as a section of an array of higher rank. On a distributed-memory machine with separate physical memory for each image, a processor might store a co-array at the same virtual address in each physical memory. 2.4.7 Pointer 17 A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 18 entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 19 A pointer is associated with a target by pointer assignment (7.4.2). A data pointer may also be 20 associated with a target by allocation (6.3.1). A pointer is disassociated following execution of a 21 NULLIFY statement, following pointer assignment with a disassociated pointer, by default initialization, 22 or by explicit initialization. A data pointer may also be disassociated by execution of a DEALLOCATE 23 statement. A disassociated pointer is not associated with a target (16.5.2). 24 A pointer that is not associated shall not be referenced or defined. 25 If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 26 associated with a target. 27 2.4.8 Storage 28 Many of the facilities of this part of ISO/IEC 1539make no assumptions about the physical storage 29 characteristics of data objects. However, program units that include storage association dependent 30 features shall observe the storage restrictions described in 16.5.3. 31 20 2006/09/25 WORKING DRAFT J3/06-007r1 2.5 Fundamental terms 1 For the purposes of this document, the terms and definitions in this subclause apply. 2 2.5.1 Name and designator 3 A name is used to identify a program constituent, such as a program unit, named variable, named 4 constant, dummy argument, or derived type. The rules governing the construction of names are given 5 in 3.2.1. A designator is a name followed by zero or more component selectors, complex part selectors, 6 array section selectors, array element selectors, image selectors, and substring selectors. 7 An object designator is a designator for a data object. A procedure designator is a designator for 8 a procedure. 9 NOTE 2.10 An object name is a special case of an object designator. 2.5.2 Keyword 10 The term keyword is used in two ways. 11 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 12 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 13 such keywords appear literally. In descriptive text, this meaning is denoted by the term 14 "keyword" without any modifier. Examples of statement keywords are: IF, READ, UNIT, 15 KIND, and INTEGER. 16 (2) It is used to denote names that identify items in a list. In actual argument lists, type 17 parameter lists, and structure constructors, items may be identified by a preceding keyword = 18 rather than their position within the list. An argument keyword is the name of a dummy 19 argument in the interface for the procedure being referenced, a type parameter keyword 20 is the name of a type parameter in the type being specified, and a component keyword 21 is the name of a component in a structure constructor. 22 R215 keyword is name 23 NOTE 2.11 Use of keywords rather than position to identify items in a list can make such lists more readable and allows them to be reordered. This facilitates specification of a list in cases where optional items are omitted. 2.5.3 Association 24 Association is name association (16.5.1), pointer association (16.5.2), storage association (16.5.3), 25 or inheritance association (16.5.4). Name association is argument association, host association, use 26 association, linkage association, or construct association. 27 Storage association causes different entities to use the same storage. Any association permits an entity 28 to be identified by different names in the same scoping unit or by the same name or different names in 29 different scoping units. 30 2.5.4 Declaration 31 The term declaration refers to the specification of attributes for various program entities. Often this 32 involves specifying the type of a named data object or specifying the shape of a named array object. 33 21 J3/06-007r1 WORKING DRAFT 2006/09/25 2.5.5 Definition 1 The term definition is used in two ways. 2 (1) It refers to the specification of derived types, enumerations, and procedures. 3 (2) When an object is given a valid value during program execution, it becomes defined. This 4 is often accomplished by execution of an assignment or input statement. When a variable 5 does not have a predictable value, it is undefined. Similarly, when a pointer is associated 6 with a target or nullified, its pointer association status is said to become defined. When 7 the association status of a pointer is not predictable, its pointer association status is said to 8 be undefined. 9 Clause 16 describes the ways in which variables may become defined and undefined. 10 2.5.6 Reference 11 A data object reference is the appearance of the data object designator in a context requiring its 12 value at that point during execution. 13 A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 14 symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined 15 derived-type input/output (10.7.6) or derived-type finalization (4.5.6.2) is also a procedure reference. 16 The appearance of a data object designator or procedure designator in an actual argument list does not 17 constitute a reference to that data object or procedure unless such a reference is necessary to complete 18 the specification of the actual argument. 19 A module reference is the appearance of a module name in a USE statement (11.2.2). 20 2.5.7 Intrinsic 21 The qualifier intrinsic has two meanings. 22 (1) The qualifier signifies that the term to which it is applied is defined in this part of ISO/IEC 23 1539. Intrinsic applies to types, procedures, modules, assignment statements, and operators. 24 All intrinsic types, procedures, assignments, and operators may be used in any scoping 25 unit without further definition or specification. Intrinsic modules may be accessed by use 26 association. Intrinsic procedures and modules defined in this part of ISO/IEC 1539are called 27 standard intrinsic procedures and standard intrinsic modules, respectively. 28 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 29 defined in this part of ISO/IEC 1539(13, 14, 15.2). Such procedures and modules are called 30 nonstandard intrinsic procedures and nonstandard intrinsic modules, respectively. 31 2.5.8 Operator 32 An operator specifies a computation involving one (unary operator) or two (binary operator) data values 33 (operands). This part of ISO/IEC 1539specifies a number of intrinsic operators (e.g., the arithmetic 34 operators +, ­, *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with 35 logical operands). Additional operators may be defined within a program (4.5.5, 12.4.3.3). 36 2.5.9 Sequence 37 A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n. The 38 number of elements in the sequence is n. A sequence may be empty, in which case it contains no elements. 39 22 2006/09/25 WORKING DRAFT J3/06-007r1 The elements of a nonempty sequence are referred to as the first element, second element, etc. The 1 nth element, where n is the number of elements in the sequence, is called the last element. An empty 2 sequence has no first or last element. 3 2.5.10 Companion processors 4 A processor has one or more companion processors. A companion processor is a processor-dependent 5 mechanism by which global data and procedures may be referenced or defined. A companion processor 6 may be a mechanism that references and defines such entities by a means other than Fortran (12.6.3), 7 it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 8 one companion processor, the means by which the Fortran processor selects among them are processor 9 dependent. 10 If a procedure is defined by means of a companion processor that is not the Fortran processor itself, this 11 part of ISO/IEC 1539refers to the C function that defines the procedure, although the procedure need 12 not be defined by means of the C programming language. 13 NOTE 2.12 A companion processor might or might not be a mechanism that conforms to the requirements of the C International Standard. For example, a processor may allow a procedure defined by some language other than Fortran or C to be invoked if it can be described by a C prototype as defined in 6.5.5.3 of the C International Standard. 23 J3/06-007r1 WORKING DRAFT 2006/09/25 24 2006/09/25 WORKING DRAFT J3/06-007r1 3 Lexical tokens, source form, and macro processing 1 3.1 Processor character set 2 The processor character set is processor dependent. Each character in a processor character set is either 3 a control character or a graphic character. The set of graphics characters is further divided into 4 letters (3.1.1), digits (3.1.2), underscore (3.1.3), special characters (3.1.4), and other characters (3.1.5). 5 The letters, digits, underscore, and special characters make up the Fortran character set. 6 R301 character is alphanumeric-character 7 or special-character 8 R302 alphanumeric-character is letter 9 or digit 10 or underscore 11 Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 12 3.1.3, and 3.1.4. However, the style of any graphic is not specified. 13 3.1.1 Letters 14 The twenty-six letters are: 15 ABCDEFGHIJKLMNOPQRSTUVWXYZ 16 The set of letters defines the syntactic class letter . The processor character set shall include lower- 17 case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in 18 program units except in a character context (3.3). 19 NOTE 3.1 The following statements are equivalent: CALL BIG_COMPLEX_OPERATION (NDATE) call big_complex_operation (ndate) Call Big_Complex_Operation (NDate) 3.1.2 Digits 20 The ten digits are: 21 0123456789 22 The ten digits define the syntactic class digit. 23 3.1.3 Underscore 24 R303 underscore is 25 The underscore may be used as a significant character in a name. 26 3.1.4 Special characters 25 J3/06-007r1 WORKING DRAFT 2006/09/25 1 The special characters are shown in Table 3.1. 2 Table 3.1: Special characters Character Name of character Character Name of character Blank ; Semicolon = Equals ! Exclamation point + Plus Quotation mark or quote " - Minus % Percent * Asterisk & Ampersand / Slash Tilde ~ Backslash < Less than \ ( Left parenthesis > Greater than ) Right parenthesis ? Question mark [ Left square bracket Apostrophe ' ] Right square bracket ` Grave accent { Left curly bracket Circumflex accent ^ } | Right curly bracket Vertical line , Comma $ Currency symbol . Decimal point or period Number sign # : Colon @ Commercial at The special characters define the syntactic class special-character . Some of the special characters are 3 used for operator symbols, bracketing, and various forms of separating and delimiting other lexical 4 tokens. 5 3.1.5 Other characters 6 Additional characters may be representable in the processor, but may appear only in comments (3.3.1.1, 7 3.3.2.1), character constants (4.4.5), input/output records (9.1.1), and character string edit descriptors 8 (10.3.2). 9 3.2 Low-level syntax 10 The low-level syntax describes the fundamental lexical tokens of a program unit. Lexical tokens are 11 sequences of characters that constitute the building blocks of a program. They are keywords, names, 12 literal constants other than complex literal constants, operators, labels, delimiters, comma, =, =>, :, ::, 13 ;, and %. 14 3.2.1 Names 15 Names are used for various entities such as variables, program units, dummy arguments, named con- 16 stants, and derived types. 17 R304 name is letter [ alphanumeric-character ] ... 18 C301 (R304) The maximum length of a name is 63 characters. 19 NOTE 3.2 Examples of names: 26 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 3.2 (cont.) A1 NAME_LENGTH (single underscore) S_P_R_E_A_D__O_U_T (two consecutive underscores) TRAILER_ (trailing underscore) NOTE 3.3 The word "name" always denotes this particular syntactic form. The word "identifier" is used where entities may be identified by other syntactic forms or by values; its particular meaning depends on the context in which it is used. 3.2.2 Constants 1 R305 constant is literal-constant 2 or named-constant 3 R306 literal-constant is int-literal-constant 4 or real-literal-constant 5 or complex-literal-constant 6 or logical-literal-constant 7 or char-literal-constant 8 or boz-literal-constant 9 R307 named-constant is name 10 R308 int-constant is constant 11 C302 (R308) int-constant shall be of type integer. 12 R309 char-constant is constant 13 C303 (R309) char-constant shall be of type character. 14 3.2.3 Operators 15 R310 intrinsic-operator is power-op 16 or mult-op 17 or add-op 18 or concat-op 19 or rel-op 20 or not-op 21 or and-op 22 or or-op 23 or equiv-op 24 R707 power-op is ** 25 R708 mult-op is * 26 or / 27 R709 add-op is + 28 or ­ 29 R711 concat-op is // 30 R713 rel-op is .EQ. 31 or .NE. 32 or .LT. 33 or .LE. 34 or .GT. 35 or .GE. 36 27 J3/06-007r1 WORKING DRAFT 2006/09/25 or == 1 or /= 2 or < 3 or <= 4 or > 5 or >= 6 R718 not-op is .NOT. 7 R719 and-op is .AND. 8 R720 or-op is .OR. 9 R721 equiv-op is .EQV. 10 or .NEQV. 11 or .XOR. 12 R311 defined-operator is defined-unary-op 13 or defined-binary-op 14 or extended-intrinsic-op 15 R703 defined-unary-op is . letter [ letter ] ... . 16 R723 defined-binary-op is . letter [ letter ] ... . 17 R312 extended-intrinsic-op is intrinsic-operator 18 3.2.4 Statement labels 19 A statement label provides a means of referring to an individual statement. 20 R313 label is digit [ digit [ digit [ digit [ digit ] ] ] ] 21 C304 (R313) At least one digit in a label shall be nonzero. 22 If a statement is labeled, the statement shall contain a nonblank character. The same statement label 23 shall not be given to more than one statement in a scoping unit. Leading zeros are not significant in 24 distinguishing between statement labels. 25 NOTE 3.4 For example: 99999 10 010 are all statement labels. The last two are equivalent. There are 99999 unique statement labels and a processor shall accept any of them as a statement label. However, a processor may have a limit on the total number of unique statement labels in one program unit. Any statement may have a statement label, but the labels are used only in the following ways. 26 (1) The label on a branch target statement (8.2) is used to identify that statement as the 27 possible destination of a branch. 28 (2) The label on a FORMAT statement (10.2.1) is used to identify that statement as the format 29 specification for a data transfer statement (9.5). 30 (3) In some forms of the DO construct (8.1.7), the range of the DO construct is identified by 31 the label on the last statement in that range. 32 3.2.5 Delimiters 33 28 2006/09/25 WORKING DRAFT J3/06-007r1 Delimiters are used to enclose syntactic lists. The following pairs are delimiters: 1 ( ... ) 2 / ... / 3 [ ... ] 4 (/ ... /) 5 3.3 Source form 6 A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, 7 and INCLUDE lines. A line is a sequence of zero or more characters. Lines following a program unit 8 END statement are not part of that program unit. A Fortran statement is a sequence of one or more 9 complete or partial lines. 10 A character context means characters within a character literal constant (4.4.5) or within a character 11 string edit descriptor (10.3.2). 12 A comment may contain any character that may occur in any character context. 13 There are two source forms: free and fixed. 14 Free form and fixed form shall not be mixed in the same program unit. The means for specifying the source form of a program unit are processor dependent. 15 3.3.1 Free source form 16 In free source form there are no restrictions on where a statement (or portion of a statement) may 17 appear within a line. A line may contain zero characters. If a line consists entirely of characters of 18 default kind (4.4.5), it may contain at most 132 characters. If a line contains any character that is not 19 of default kind, the maximum number of characters allowed on the line is processor dependent. 20 Blank characters shall not appear within lexical tokens other than in a character context or in a format 21 specification. Blanks may be inserted freely between tokens to improve readability; for example, blanks 22 may occur between the tokens that form a complex literal constant. A sequence of blank characters 23 outside of a character context is equivalent to a single blank character. 24 A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, 25 or labels. 26 NOTE 3.5 For example, the blanks after REAL, READ, 30, and DO are required in the following: REAL X READ 10 30 DO K=1,3 One or more blanks shall be used to separate adjacent keywords except in the following cases, where 27 blanks are optional: 28 Adjacent keywords where separating blanks are optional BLOCK DATA END MODULE DOUBLE PRECISION END INTERFACE ELSE IF END PROCEDURE 29 J3/06-007r1 WORKING DRAFT 2006/09/25 Adjacent keywords where separating blanks are optional ELSE WHERE END PROGRAM END ASSOCIATE END SELECT END BLOCK END SUBMODULE END BLOCK DATA END SUBROUTINE END CRITICAL END TYPE END DO END WHERE END ENUM GO TO END FILE IN OUT END FORALL SELECT CASE END FUNCTION SELECT TYPE END IF 3.3.1.1 Free form commentary 1 The character "!" initiates a comment except where it appears within a character context. The 2 comment extends to the end of the line. If the first nonblank character on a line is an "!", the line 3 is a comment line. Lines containing only blanks or containing no characters are also comment lines. 4 Comments may appear anywhere in a program unit and may precede the first statement of a program 5 unit or may follow the last statement of a program unit. Comments have no effect on the interpretation 6 of the program unit. 7 NOTE 3.6 The standard does not restrict the number of consecutive comment lines. 3.3.1.2 Free form statement continuation 8 The character "&" is used to indicate that the current statement is continued on the next line that is not 9 a comment line. Comment lines cannot be continued; an "&" in a comment has no effect. Comments may 10 occur within a continued statement. When used for continuation, the "&" is not part of the statement. 11 No line shall contain a single "&" as the only nonblank character or as the only nonblank character 12 before an "!" that initiates a comment. 13 If a noncharacter context is to be continued, an "&" shall be the last nonblank character on the line, 14 or the last nonblank character before an "!". There shall be a later line that is not a comment; the 15 statement is continued on the next such line. If the first nonblank character on that line is an "&", the 16 statement continues at the next character position following that "&"; otherwise, it continues with the 17 first character position of that line. 18 If a lexical token is split across the end of a line, the first nonblank character on the first following 19 noncomment line shall be an "&" immediately followed by the successive characters of the split token. 20 If a character context is to be continued, an "&" shall be the last nonblank character on the line and 21 shall not be followed by commentary. There shall be a later line that is not a comment; an "&" shall be 22 the first nonblank character on the next such line and the statement continues with the next character 23 following that "&". 24 3.3.1.3 Free form statement termination 25 If a statement is not continued, a comment or the end of the line terminates the statement. 26 A statement may alternatively be terminated by a ";" character that appears other than in a character 27 context or in a comment. The ";" is not part of the statement. After a ";" terminator, another statement 28 30 2006/09/25 WORKING DRAFT J3/06-007r1 may appear on the same line, or begin on that line and be continued. A sequence consisting only of zero 1 or more blanks and one or more ";" terminators, in any order, is equivalent to a single ";" terminator. 2 3.3.1.4 Free form statements 3 A label may precede any statement not forming part of another statement. 4 NOTE 3.7 No Fortran statement begins with a digit. A statement shall not have more than 255 continuation lines. 5 3.3.2 Fixed source form 6 7 In fixed source form, there are restrictions on where a statement may appear within a line. If a source line contains only 8 default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor dependent. 9 Except in a character context, blanks are insignificant and may be used freely throughout the program. 10 3.3.2.1 Fixed form commentary 11 12 The character "!" initiates a comment except where it appears within a character context or in character position 6. The 13 comment extends to the end of the line. If the first nonblank character on a line is an "!" in any character position other 14 than character position 6, the line is a comment line. Lines beginning with a "C" or "*" in character position 1 and lines 15 containing only blanks are also comment lines. Comments may appear anywhere in a program unit and may precede the 16 first statement of the program unit or may follow the last statement of a program unit. Comments have no effect on the interpretation of the program unit. 17 NOTE 3.8 The standard does not restrict the number of consecutive comment lines. 3.3.2.2 Fixed form statement continuation 18 19 Except within commentary, character position 6 is used to indicate continuation. If character position 6 contains a blank 20 or zero, the line is the initial line of a new statement, which begins in character position 7. If character position 6 contains 21 any character other than blank or zero, character positions 7­72 of the line constitute a continuation of the preceding 22 noncomment line. NOTE 3.9 An "!" or ";" in character position 6 is interpreted as a continuation indicator unless it appears within commentary indicated by a "C" or "*" in character position 1 or by an "!" in character positions 1­5. Comment lines cannot be continued. Comment lines may occur within a continued statement. 23 3.3.2.3 Fixed form statement termination 24 If a statement is not continued, a comment or the end of the line terminates the statement. 25 26 A statement may alternatively be terminated by a ";" character that appears other than in a character context, in a 27 comment, or in character position 6. The ";" is not part of the statement. After a ";" terminator, another statement may 28 begin on the same line, or begin on that line and be continued. A ";" shall not appear as the first nonblank character 29 on an initial line. A sequence consisting only of zero or more blanks and one or more ";" terminators, in any order, is equivalent to a single ";" terminator. 30 3.3.2.4 Fixed form statements 31 31 J3/06-007r1 WORKING DRAFT 2006/09/25 1 A label, if present, shall occur in character positions 1 through 5 of the first line of a statement; otherwise, positions 1 2 through 5 shall be blank. Blanks may appear anywhere within a label. A statement following a ";" on the same line shall 3 not be labeled. Character positions 1 through 5 of any continuation lines shall be blank. A statement shall not have more 4 than 255 continuation lines. The program unit END statement shall not be continued. A statement whose initial line appears to be a program unit END statement shall not be continued. 5 3.4 Including source text 6 Additional text may be incorporated into the source text of a program unit during processing. This is 7 accomplished with the INCLUDE line, which has the form 8 INCLUDE char-literal-constant 9 The char-literal-constant shall not have a kind type parameter value that is a named-constant. 10 An INCLUDE line is not a Fortran statement. 11 An INCLUDE line shall appear on a single source line where a statement may appear; it shall be the 12 only nonblank text on this line other than an optional trailing comment. Thus, a statement label is not 13 allowed. 14 The effect of the INCLUDE line is as if the referenced source text physically replaced the INCLUDE line 15 prior to program processing. Included text may contain any source text, including additional INCLUDE 16 lines; such nested INCLUDE lines are similarly replaced with the specified source text. The maximum 17 depth of nesting of any nested INCLUDE lines is processor dependent. Inclusion of the source text 18 referenced by an INCLUDE line shall not, at any level of nesting, result in inclusion of the same source 19 text. 20 When an INCLUDE line is resolved, the first included statement line shall not be a continuation line 21 and the last included statement line shall not be continued. 22 The interpretation of char-literal-constant is processor dependent. An example of a possible valid inter- 23 pretation is that char-literal-constant is the name of a file that contains the source text to be included. 24 NOTE 3.10 In some circumstances, for example where source code is maintained in an INCLUDE file for use in programs whose source form might be either fixed or free, observing the following rules allows the code to be used with either source form: (1) Confine statement labels to character positions 1 to 5 and statements to character positions 7 to 72; (2) Treat blanks as being significant; (3) Use only the exclamation mark (!) to indicate a comment, but do not start the comment in character position 6; (4) For continued statements, place an ampersand (&) in both character position 73 of a continued line and character position 6 of a continuing line. 3.5 Macro processing 25 3.5.1 Macro definition 26 A macro definition defines a macro. A defined macro shall only be referenced by a USE statement, 27 IMPORT statement, or macro expansion statement. A defined macro shall not be redefined. 28 32 2006/09/25 WORKING DRAFT J3/06-007r1 R314 macro-definition is define-macro-stmt 1 [ macro-declaration-stmt ] ... 2 macro-body-block 3 end-macro-stmt 4 R315 define-macro-stmt is DEFINE MACRO [ , macro-attribute-list ] :: macro-name 5 [ ( [ macro-dummy-arg-name-list ] ) ] 6 C305 (R315) A macro-dummy-arg-name shall not appear more than once in a macro-dummy-arg- 7 name-list. 8 R316 macro-attribute is access-spec 9 The DEFINE MACRO statement begins the definition of the macro macro-name. Appearance of an 10 access-spec in the DEFINE MACRO statement explicitly gives the macro the specified attribute. Each 11 macro-dummy-arg-name is a macro dummy argument. A macro dummy argument is a macro local 12 variable. 13 R317 macro-declaration-stmt is macro-type-declaration-stmt 14 or macro-optional-decl-stmt 15 R318 macro-type-declaration-stmt is MACRO macro-type-spec :: macro-local-variable-name-list 16 R319 macro-optional-decl-stmt is MACRO OPTIONAL :: macro-dummy-arg-name-list 17 R320 macro-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] 18 C306 (R318) A macro-local-variable-name shall not be the same as the name of a dummy argument 19 of the macro being defined. 20 C307 (R319) A macro-dummy-arg-name shall be the name of a dummy argument of the macro being 21 defined. 22 C308 (R320) If macro-expr appears, when the macro is expanded macro-expr shall be of type integer, 23 and have a non-negative value that specifies a representation method that exists on the processor. 24 A macro type declaration statement specifies that the named entities are macro local variables of the 25 specified type. If the kind is not specified, they are of default kind. A macro local variable that is not a 26 macro dummy argument shall appear in a macro type declaration statement. 27 R321 macro-body-block is [ macro-body-construct ] ... 28 R322 macro-body-construct is macro-definition 29 or expand-stmt 30 or macro-body-stmt 31 or macro-do-construct 32 or macro-if-construct 33 C309 A statement in a macro definition that is not a macro-body-construct or macro-definition shall 34 not appear on a line with any other statement. 35 R323 macro-do-construct is macro-do-stmt 36 macro-body-block 37 macro-end-do-stmt 38 R324 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , 39 macro-do-limit [ , macro-do-limit ] 40 33 J3/06-007r1 WORKING DRAFT 2006/09/25 C310 (R324) A macro-do-variable-name shall be a local variable of the macro being defined, and shall 1 not be a macro dummy argument. 2 R325 macro-do-limit is macro-expr 3 C311 (R325) A macro-do-limit shall expand to an expression of type integer. 4 R326 macro-end-do-stmt is MACRO END DO 5 A macro DO construct iterates the expansion of its enclosed macro body block at macro expansion time. 6 The number of iterations is determined by the values of the expanded macro expressions in the MACRO 7 DO statement. 8 R327 macro-if-construct is macro-if-then-stmt 9 macro-body-block 10 [ macro-else-if-stmt 11 macro-body-block ] ... 12 [ macro-else-stmt 13 macro-body-block ] 14 macro-end-if-stmt 15 R328 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN 16 R329 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN 17 R330 macro-else-stmt is MACRO ELSE 18 R331 macro-end-if-stmt is MACRO END IF 19 R332 macro-condition is macro-expr 20 C312 (R332) A macro condition shall expand to an expression of type logical. 21 A macro IF construct provides conditional expansion of its enclosed macro body blocks at macro expan- 22 sion time. Whether the enclosed macro body blocks contribute to the macro expansion is determined by 23 the logical value of the expanded macro expressions in the MACRO IF and MACRO ELSE IF statements. 24 R333 macro-body-stmt is result-token [ result-token ] ... [ && ] 25 C313 (R333) The first result-token shall not be MACRO unless the second result-token is not a keyword 26 or name. 27 R334 result-token is token [ %% token ] ... 28 C314 (R334) The concatenated textual tokens in a result-token shall have the form of a lexical token. 29 R335 token is any lexical token including labels, keywords, and semi-colon. 30 C315 && shall not appear in the last macro-body-stmt of a macro definition. 31 C316 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. 32 R336 end-macro-stmt is END MACRO [ macro-name ] 33 C317 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name 34 in the DEFINE MACRO statement. 35 R337 macro-expr is basic-token-sequence 36 C318 (R337) A macro-expr shall expand to a scalar initialization expression. 34 2006/09/25 WORKING DRAFT J3/06-007r1 Macro expressions are used to control the behavior of the MACRO DO and MACRO IF constructs when 1 a macro is being expanded. The type, type parameters, and value of a macro expression are determined 2 when that macro expression is expanded. 3 3.5.2 Macro expansion 4 3.5.2.1 General 5 Macro expansion is the conceptual replacement of the EXPAND statement with the Fortran statements 6 that it produces. The semantics of an EXPAND statement are those of the Fortran statements that it 7 produces. It is recommended that a processor be capable of displaying the results of macro expansion. It 8 is processor-dependent whether comments in a macro definition appear in the expansion. It is processor- 9 dependent whether continuations and consecutive blanks that are not part of a token are preserved. 10 The process of macro expansion produces Fortran statements consisting of tokens. The combined length 11 of the tokens for a single statement, plus inter-token spacing, shall not be greater than 33280 characters. 12 If a statement contains any character that is not of default kind, the maximum number of characters 13 allowed is processor dependent. 14 NOTE 3.11 This length is so that the result of macro expansion can be formed into valid free form Fortran source, consisting of an initial line and 255 continuation lines, times 130 which allows for beginning and ending continuation characters (&) on each line. Also, breaking tokens across continuation lines in macro definitions and in EXPAND statements does not affect macro expansion: it is as if they were joined together before replacement. R338 expand-stmt is EXPAND macro-name [ ( macro-actual-arg-list ) ] 15 C319 (R338) macro-name shall be the name of a macro that was previously defined or accessed via 16 use or host association. 17 C320 (R338) The macro shall expand to a sequence or zero or more complete Fortran statements. 18 C321 (R338) The statements produced by a macro expansion shall conform to the syntax rules and 19 constraints as if they replaced the EXPAND statement prior to program processing. 20 C322 (R338) The statements produced by a macro expansion shall not include a statement which 21 ends the scoping unit containing the EXPAND statement. 22 C323 (R338) If a macro expansion produces a statement which begins a new scoping unit, it shall also 23 produce a statement which ends that scoping unit. 24 C324 (R338) If the EXPAND statement appears as the action-stmt of an if-stmt, it shall expand to 25 exactly one action-stmt that is not an if-stmt, end-program-stmt, end-function-stmt, or end- 26 subroutine-stmt. 27 C325 28 (R338) If the EXPAND statement appears as a do-term-action-stmt, it shall expand to exactly one action-stmt 29 that is not a continue-stmt, a goto-stmt, a return-stmt, a stop-stmt, an exit-stmt, a cycle-stmt, an end-function- stmt, an end-subroutine-stmt, an end-program-stmt, or an arithmetic-if-stmt. 30 C326 (R338) If the EXPAND statement has a label, the expansion of the macro shall produce at least 31 one statement, and the first statement produced shall not have a label. 32 C327 (R338) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- 33 gument. 34 35 J3/06-007r1 WORKING DRAFT 2006/09/25 C328 (R338) At most one macro-actual-arg shall appear corresponding to each optional macro dummy 1 argument. 2 Expansion of a macro is performed by the EXPAND statement. If the EXPAND statement has a label, 3 the label is interpreted after expansion as belonging to the first statement of the expansion. 4 R339 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value 5 C329 (R339) macro-dummy-name shall be the name of a macro dummy argument of the macro being 6 expanded. 7 C330 (R338) The macro-dummy-name= shall not be omitted unless it has been omitted from each 8 preceding macro-actual-arg in the expand-stmt. 9 R340 macro-actual-arg-value is basic-token-sequence 10 R341 basic-token-sequence is basic-token 11 or [ basic-token-sequence] nested-token-sequence 12 [ basic-token-sequence ] 13 or basic-token basic-token-sequence 14 R342 basic-token is any lexical token except comma, parentheses, array 15 constructor delimiters, and semi-colon. 16 R343 nested-token-sequence is ( [ arg-token ] ... ) 17 or (/ [ arg-token ] ... /) 18 or lbracket [ arg-token ] ... rbracket 19 R344 arg-token is basic-token 20 or , 21 Macro expansion processes any macro declarations of the macro definition, and then expands its macro 22 body block. Any macro expressions in macro-type-specs are evaluated and the kinds of the macro 23 variables thereby declared are determined for that particular expansion. 24 Macro expansion of a macro body block processes each macro body construct of the macro body block 25 in turn, starting with the first macro body construct and ending with the last macro body construct. 26 Expansion of a statement within a macro body construct consists of three steps: 27 (1) token replacement, 28 (2) token concatenation, and 29 (3) statement-dependent processing. 30 Token replacement replaces each token of a macro body statement or macro expression that is a macro 31 local variable with the value of that variable. In a macro expression, a reference to the PRESENT 32 intrinsic function with a macro dummy argument name as its actual argument is replaced by the token 33 .TRUE. if the specified macro dummy argument is present, and the token .FALSE. if the specified macro 34 dummy argument is not present. Otherwise, the value of a macro dummy argument that is present is 35 the sequence of tokens from the corresponding actual argument. The value of a macro dummy argument 36 that is not present is a zero-length token sequence. The value of an integer macro variable is its minimal- 37 length decimal representation; if negative this will produce two tokens, a minus sign and an unsigned 38 integer literal constant. 39 Token concatenation is performed with the %% operator, which is only permitted inside a macro defini- 40 tion. After expansion, each sequence of single tokens separated by %% operators is replaced by a single 41 token consisting of the concatenated text of the sequence of tokens. The result of a concatenation shall 42 be a valid Fortran token, and may be a different kind of token from one or more of the original sequence 43 36 2006/09/25 WORKING DRAFT J3/06-007r1 of tokens. 1 NOTE 3.12 For example, the sequence 3 %% .14159 %% E %% + %% 0 forms the single real literal constant 3.14159E+0. 3.5.2.2 Macro body statements 2 Processing a macro body statement produces a whole or partial Fortran statement. A macro body 3 statement that is either the first macro body statement processed by this macro expansion or the next 4 macro body statement processed after a macro body statement that did not end with the continuation 5 generation operator &&, is an initial macro body statement. The next macro body statement processed 6 after a macro body statement that ends with && is a continuation macro body statement. An initial 7 macro body statement that does not end with && produces a whole Fortran statement consisting of its 8 token sequence. All other macro body statements produce partial Fortran statements, and the sequence 9 of tokens starting with those produced by the initial macro body statement and appending the tokens 10 produced by each subsequent continuation macro body statement form a Fortran statement. The && 11 operators are not included in the token sequence. 12 3.5.2.3 The macro DO construct 13 The macro DO construct specifies the repeated expansion of a macro body block. Processing the macro 14 DO statement performs the following steps in sequence. 15 (1) The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter 16 m3 are of type integer with the same kind type parameter as the macro-do-variable-name. 17 Their values are given by the first macro-expr , the second macro-expr , and the third macro- 18 expr of the macro-do-stmt respectively, including, if necessary, conversion to the kind type 19 parameter of the macro-do-variable-name according to the rules for numeric conversion 20 (Table 7.12). If the third macro-expr does not appear, m3 has the value 1. The value of m3 21 shall not be zero. 22 (2) The macro DO variable becomes defined with the value of the initial parameter m1 . 23 The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , (3) 24 unless that value is negative, in which case the iteration count is 0. 25 After this, the following steps are performed repeatedly until processing of the macro DO construct is 26 finished. 27 (1) The iteration count is tested. If it is zero, the loop terminates and processing of the macro 28 DO construct is finished. 29 (2) If the iteration count is nonzero, the macro body block of the macro DO construct is 30 expanded. 31 (3) The iteration count is decremented by one. The macro DO variable is incremented by the 32 value of the incrementation parameter m3 . 33 3.5.2.4 The MACRO IF construct 34 The MACRO IF construct provides conditional expansion of macro body blocks. At most one of the 35 macro body blocks of the macro IF construct is expanded. The macro conditions of the construct are 36 evaluated in order until a true value is found or a MACRO ELSE or MACRO END IF statement is 37 encountered. If a true value or a MACRO ELSE statement is found, the macro body block immediately 38 following is expanded and this completes the processing of the construct. If none of the evaluated 39 37 J3/06-007r1 WORKING DRAFT 2006/09/25 conditions is true and there is no MACRO ELSE statement, the processing of the construct is completed 1 without expanding any of the macro body blocks within the construct. 2 3.5.2.5 Macro definitions 3 Processing a macro definition defines a new macro. If a macro definition is produced by a macro expan- 4 sion, all of the statements of the produced macro definition have token replacement and concatenation 5 applied to them before the new macro is defined. 6 3.5.2.6 Examples 7 NOTE 3.13 This is a macro which loops over an array of any rank and processes each array element. DEFINE MACRO loop_over(array,rank,traceinfo) MACRO INTEGER :: i BLOCK MACRO DO i=1,rank INTEGER loop_over_temp_%%i MACRO END DO MACRO DO i=1,rank DO loop_over_temp_%%i=1,size(array,i) MACRO END DO CALL impure_scalar_procedure(array(loop_over_temp_%%1 && MACRO DO i=2,rank ,loop_over_temp%i && MACRO END DO ),traceinfo) MACRO DO i=1,rank END DO MACRO END DO END BLOCK END MACRO NOTE 3.14 One can effectively pass macro names as macro arguments, since expansion of arguments occurs before analysis of each macro body statement. For example: DEFINE MACRO :: iterator(count,operation) MACRO DO i=1,count EXPAND operation(i) MACRO END DO END MACRO DEFINE MACRO :: process_element(j) READ *,a(j) result(j) = process(a(j)) IF (j>1) PRINT *,'difference =',result(j)-result(j-1) END MACRO EXPAND iterator(17,process_element) This expands into 17 sets of 3 statements: 38 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 3.14 (cont.) READ *,a(1) result(1) = process(a(1)) IF (1>1) PRINT *,'difference =',result(1)-result(1-1) READ *,a(2) result(2) = process(a(2)) IF (2>1) PRINT *,'difference =',result(2)-result(2-1) ... READ *,a(17) result(17) = process(a(17)) IF (17>1) PRINT *,'difference =',result(17)-result(17-1) NOTE 3.15 Using the ability to evaluate initialization expressions under macro control and test them, one can create interfaces and procedures for all kinds of a type, for example: DEFINE MACRO :: i_square_procs() MACRO INTEGER i MACRO DO i=1,1000 MACRO IF (SELECTED_INT_KIND(i)>=0 .AND. (i==1 .OR. SELECTED_INT_KIND(i)/=SELECTED_INT_KIND(i-1))) THEN FUNCTION i_square_range_%%i(a) RESULT(r) INTEGER(SELECTED_INT_KIND(i)) a,r r = a**2 END FUNCTION MACRO END IF MACRO END DO END MACRO 39 J3/06-007r1 WORKING DRAFT 2006/09/25 40 2006/09/25 WORKING DRAFT J3/06-007r1 4 Types 1 4.1 The concept of type 2 Fortran provides an abstract means whereby data may be categorized without relying on a particular 3 physical representation. This abstract means is the concept of type. 4 A type has a name, a set of valid values, a means to denote such values (constants), and a set of 5 operations to manipulate the values. 6 A type is either an intrinsic type or a derived type. 7 This part of ISO/IEC 1539 defines six intrinsic types: integer, real, complex, character, logical, and bits. 8 A derived type is one that is defined by a derived-type definition (4.5.2) or by an intrinsic module. It 9 shall be used only where it is accessible (4.5.2.2). An intrinsic type is always accessible. 10 4.1.1 Set of values 11 For each type, there is a set of valid values. The set of valid values may be completely determined, 12 as is the case for logical and bits, or may be determined by a processor-dependent method, as is the 13 case for integer, character, and real. For complex, the set of valid values consists of the set of all the 14 combinations of the values of the individual components. For derived types, the set of valid values is as 15 defined in 4.5.8. 16 4.1.2 Constants 17 The syntax for literal constants of each intrinsic type is specified in 4.4. 18 The syntax for denoting a value indicates the type, type parameters, and the particular value. 19 A constant value may be given a name (5.3.12, 5.4.10). 20 A structure constructor (4.5.10) may be used to construct a constant value of derived type from an 21 appropriate sequence of initialization expressions (7.1.7). Such a constant value is scalar even though it 22 may have components that are arrays. 23 4.1.3 Operations 24 For each of the intrinsic types, a set of operations and corresponding operators is defined intrinsically. 25 These are described in Clause 7. The intrinsic set may be augmented with operations and operators 26 defined by functions with the OPERATOR interface (12.4.3.2). Operator definitions are described in 27 Clauses 7 and 12. 28 For derived types, there are no intrinsic operations. Operations on derived types may be defined by the 29 program (4.5.11). 30 4.2 Type parameters 31 A type may be parameterized. In this case, the set of values, the syntax for denoting the values, and 32 the set of operations on the values of the type depend on the values of the parameters. 33 41 J3/06-007r1 WORKING DRAFT 2006/09/25 The intrinsic types are all parameterized. Derived types may be defined to be parameterized. 1 A type parameter is either a kind type parameter or a length type parameter. All type parameters are 2 of type integer. 3 A kind type parameter may be used in initialization and specification expressions within the derived-type 4 definition (4.5.2) for the type; it participates in generic resolution (12.5.5.2). Each of the intrinsic types 5 has a kind type parameter named KIND, which is used to distinguish multiple representations of the 6 intrinsic type. 7 NOTE 4.1 The value of a kind type parameter is always known at compile time. Some parameterizations that involve multiple representation forms need to be distinguished at compile time for practical implementation and performance. Examples include the multiple precisions of the intrinsic real type and the possible multiple character sets of the intrinsic character type. A type parameter of a derived type may be specified to be a kind type parameter in order to allow generic resolution based on the parameter; that is to allow a single generic to include two specific procedures that have interfaces distinguished only by the value of a kind type parameter of a dummy argument. All generic references are resolvable at compile time. A length type parameter may be used in specification expressions within the derived-type definition for 8 the type, but it shall not be used in initialization expressions. The intrinsic character type has a length 9 type parameter named LEN, which is the length of the string. 10 NOTE 4.2 The adjective "length" is used for type parameters other than kind type parameters because they often specify a length, as for intrinsic character type. However, they may be used for other purposes. The important difference from kind type parameters is that their values need not be known at compile time and might change during execution. A type parameter value may be specified with a type specification (4.4, 4.5.9). 11 R401 type-param-value is scalar-int-expr 12 or * 13 or : 14 C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. 15 C402 (R401) A colon may be used as a type-param-value only in the declaration of an entity or 16 component that has the POINTER or ALLOCATABLE attribute. 17 A deferred type parameter is a length type parameter whose value can change during execution of 18 the program. A colon as a type-param-value specifies a deferred type parameter. 19 The values of the deferred type parameters of an object are determined by successful execution of an 20 ALLOCATE statement (6.3.1), execution of an intrinsic assignment statement (7.4.1.3), execution of a 21 pointer assignment statement (7.4.2), or by argument association (12.5.2). 22 NOTE 4.3 Deferred type parameters of functions, including function procedure pointers, have no values. Instead, they indicate that those type parameters of the function result will be determined by execution of the function, if it returns an allocated allocatable result or an associated pointer result. 42 2006/09/25 WORKING DRAFT J3/06-007r1 An assumed type parameter is a length type parameter for a dummy argument that assumes the 1 type parameter value from the corresponding actual argument; it is also used for an associate name in a 2 SELECT TYPE construct that assumes the type parameter value from the corresponding selector, and 3 for a named constant of type character that assumes its length from the initialization-expr . An asterisk 4 as a type-param-value specifies an assumed type parameter. 5 4.3 Relationship of types and values to objects 6 The name of a type serves as a type specifier and may be used to declare objects of that type. A 7 declaration specifies the type of a named object. A data object may be declared explicitly or implicitly. 8 Data objects may have attributes in addition to their types. Clause 5 describes the way in which a data 9 object is declared and how its type and other attributes are specified. 10 Scalar data of any intrinsic or derived type may be shaped in a rectangular pattern to compose an array 11 of the same type and type parameters. An array object has a type and type parameters just as a scalar 12 object does. 13 A variable is a data object. The type and type parameters of a variable determine which values that 14 variable may take. Assignment provides one means of defining or redefining the value of a variable of 15 any type. Assignment is defined intrinsically for all types where the type, type parameters, and shape 16 of both the variable and the value to be assigned to it are identical. Assignment between objects of 17 certain differing intrinsic types, type parameters, and shapes is described in Clause 7. A subroutine and 18 a generic interface (4.5.2, 12.4.3.2) whose generic specifier is ASSIGNMENT (=) define an assignment 19 that is not defined intrinsically or redefine an intrinsic derived-type assignment (7.4.1.4). 20 NOTE 4.4 For example, assignment of a real value to an integer variable is defined intrinsically. The type of a variable determines the operations that may be used to manipulate the variable. 21 4.3.1 Type specifiers and type compatibility 22 4.3.1.1 General 23 A type is specified by a type specifier. In an executable statement, or in an expression within a nonex- 24 ecutable statement, a type-spec is used. In a nonexecutable statement other than within an expression, 25 a declaration-type-spec is used. 26 R402 type-spec is intrinsic-type-spec 27 or derived-type-spec 28 C403 (R402) The derived-type-spec shall not specify an abstract type (4.5.7). 29 R403 declaration-type-spec is intrinsic-type-spec 30 or TYPE ( intrinsic-type-spec ) 31 or TYPE ( derived-type-spec ) 32 or CLASS ( derived-type-spec ) 33 or CLASS ( * ) 34 C404 (R403) In a declaration-type-spec, every type-param-value that is not a colon or an asterisk shall 35 be a specification-expr . 36 C405 (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify 37 an extensible type (4.5.7). 38 43 J3/06-007r1 WORKING DRAFT 2006/09/25 C406 (R403) The TYPE(derived-type-spec) shall not specify an abstract type (4.5.7). 1 C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLO- 2 CATABLE or POINTER attribute. It shall not have the VALUE attribute. 3 An intrinsic-type-spec specifies the named intrinsic type and its type parameter values. A derived-type- 4 spec specifies the named derived type and its type parameter values. 5 NOTE 4.5 A type-spec is used in an array constructor, a SELECT TYPE construct, or an ALLOCATE statement. Elsewhere, a declaration-type-spec is used. 4.3.1.2 TYPE 6 A TYPE type specifier is used to declare entities of an intrinsic or derived type. 7 Where a data entity is declared explicitly using the TYPE type specifier to be of derived type, the 8 specified derived type shall have been defined previously in the scoping unit or be accessible there by 9 use or host association. If the data entity is a function result, the derived type may be specified in 10 the FUNCTION statement provided the derived type is defined within the body of the function or is 11 accessible there by use or host association. If the derived type is specified in the FUNCTION statement 12 and is defined within the body of the function, it is as if the function result variable was declared with 13 that derived type immediately following the derived-type-def of the specified derived type. 14 4.3.1.3 CLASS 15 A polymorphic entity is a data entity that is able to be of differing types during program execution. 16 The type of a data entity at a particular point during execution of a program is its dynamic type. The 17 declared type of a data entity is the type that it is declared to have, either explicitly or implicitly. 18 A CLASS type specifier is used to declare polymorphic entities. The declared type of a polymorphic 19 entity is the specified type if the CLASS type specifier contains a type name. 20 An entity declared with the CLASS(*) specifier is an unlimited polymorphic entity. An unlimited 21 polymorphic entity is not declared to have a type. It is not considered to have the same declared type 22 as any other entity, including another unlimited polymorphic entity. 23 A nonpolymorphic entity is type compatible only with entities of the same declared type. A poly- 24 morphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same 25 declared type or any of its extensions. Even though an unlimited polymorphic entity is not considered 26 to have a declared type, it is type compatible with all entities. An entity is type compatible with a type 27 if it is type compatible with entities of that type. 28 Two entities are type incompatible if neither is type compatible with the other. 29 NOTE 4.6 Given TYPE TROOT ... TYPE,EXTENDS(TROOT) :: TEXTENDED ... CLASS(TROOT) A CLASS(TEXTENDED) B ... 44 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.6 (cont.) A is type compatible with B but B is not type compatible with A. A polymorphic allocatable object may be allocated to be of any type with which it is type compatible. 1 A polymorphic pointer or dummy argument may, during program execution, be associated with objects 2 with which it is type compatible. 3 The dynamic type of an allocated allocatable polymorphic object is the type with which it was allocated. 4 The dynamic type of an associated polymorphic pointer is the dynamic type of its target. The dynamic 5 type of a nonallocatable nonpointer polymorphic dummy argument is the dynamic type of its associated 6 actual argument. The dynamic type of an unallocated allocatable or a disassociated pointer is the same 7 as its declared type. The dynamic type of an entity identified by an associate name (8.1.3) is the dynamic 8 type of the selector with which it is associated. The dynamic type of an object that is not polymorphic 9 is its declared type. 10 NOTE 4.7 Only components of the declared type of a polymorphic object may be designated by component selection (6.1.2). 4.4 Intrinsic types 11 4.4.1 Classification and specification 12 Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, 13 real, and complex. The nonnumeric intrinsic types are character, logical, and bits. 14 The numeric types are provided for numerical computation. The normal operations of arithmetic, 15 addition (+), subtraction (­), multiplication (*), division (/), exponentiation (**), identity (unary +), 16 and negation (unary ­), are defined intrinsically for the numeric types. 17 R404 intrinsic-type-spec is INTEGER [ kind-selector ] 18 or REAL [ kind-selector ] 19 or DOUBLE PRECISION 20 or COMPLEX [ kind-selector ] 21 or CHARACTER [ char-selector ] 22 or LOGICAL [ kind-selector ] 23 or BITS [ kind-selector ] 24 R405 kind-selector is ( [ KIND = ] scalar-int-initialization-expr ) 25 C408 (R405) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 26 resentation method that exists on the processor. 27 4.4.2 Integer type 28 The set of values for the integer type is a subset of the mathematical integers. The processor shall 29 provide one or more representation methods that define sets of values for data of type integer. Each 30 such method is characterized by a value for a type parameter called the kind type parameter; this kind 31 type parameter is of type default integer. The kind type parameter of a representation method is returned 32 by the intrinsic inquiry function KIND (13.7.96). The decimal exponent range of a representation method 33 is returned by the intrinsic function RANGE (13.7.143). The intrinsic function SELECTED INT KIND 34 (13.7.153) returns a kind value based on a specified decimal range requirement. The integer type includes 35 a zero value, which is considered to be neither negative nor positive. The value of a signed integer zero 36 is the same as the value of an unsigned integer zero. 45 J3/06-007r1 WORKING DRAFT 2006/09/25 1 The processor shall provide at least one representation method with a decimal exponent range greater 2 than or equal to 18. 3 The type specifier for the integer type uses the keyword INTEGER. 4 If the kind type parameter is not specified, the default kind value is KIND (0) and the type specified is 5 default integer. The decimal exponent range of default integer shall be at least 5. 6 Any integer value may be represented as a signed-int-literal-constant. 7 R406 signed-int-literal-constant is [ sign ] int-literal-constant 8 R407 int-literal-constant is digit-string [ kind-param ] 9 R408 kind-param is digit-string 10 or scalar-int-constant-name 11 R409 signed-digit-string is [ sign ] digit-string 12 R410 digit-string is digit [ digit ] ... 13 R411 sign is + 14 or ­ 15 C409 (R408) A scalar-int-constant-name shall be a named constant of type integer. 16 C410 (R408) The value of kind-param shall be nonnegative. 17 C411 (R407) The value of kind-param shall specify a representation method that exists on the pro- 18 cessor. 19 The optional kind type parameter following digit-string specifies the kind type parameter of the integer 20 constant; if it is not present, the constant is of type default integer. 21 An integer constant is interpreted as a decimal value. 22 NOTE 4.8 Examples of signed integer literal constants are: 473 +56 -101 21_2 21_SHORT 1976354279568241_8 where SHORT is a scalar integer named constant. 4.4.3 Real type 23 The real type has values that approximate the mathematical real numbers. The processor shall provide 24 two or more approximation methods that define sets of values for data of type real. Each such method 25 has a representation method and is characterized by a value for a type parameter called the kind 26 type parameter; this kind type parameter is of type default integer. The kind type parameter of an 27 approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 28 The decimal precision, decimal exponent range, and radix of an approximation method are returned by 29 the intrinsic functions PRECISION (13.7.137), RANGE (13.7.143), and RADIX (13.7.140). The intrinsic 30 function SELECTED REAL KIND (13.7.154) returns a kind value based on specified precision, range, 31 46 2006/09/25 WORKING DRAFT J3/06-007r1 and radix requirements. 1 NOTE 4.9 See C.1.1 for remarks concerning selection of approximation methods. The real type includes a zero value. Processors that distinguish between positive and negative zeros 2 shall treat them as mathematically equivalent 3 (1) in all relational operations, 4 (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified 5 that negative zero is distinguished, and 6 (3) as the scalar-numeric-expr in an arithmetic IF. 7 NOTE 4.10 On a processor that can distinguish between 0.0 and -0.0, ( X >= 0.0 ) evaluates to true if X = 0.0 or if X = -0.0, ( X < 0.0 ) evaluates to false for X = -0.0, and IF (X) 1,2,3 causes a transfer of control to the branch target statement with the statement label "2" for both X = 0.0 and X = -0.0. In order to distinguish between 0.0 and -0.0, a program should use the SIGN function. SIGN(1.0,X) will return -1.0 if X < 0.0 or if the processor distinguishes between 0.0 and -0.0 and X has the value -0.0. The type specifier for the real type uses the keyword REAL. The keyword DOUBLE PRECISION is an 8 alternate specifier for one kind of real type. 9 If the type keyword REAL is specified and the kind type parameter is not specified, the default kind 10 value is KIND (0.0) and the type specified is default real. If the type keyword DOUBLE PRECISION 11 is specified, the kind value is KIND (0.0D0) and the type specified is double precision real. The 12 decimal precision of the double precision real approximation method shall be greater than that of the 13 default real method. 14 The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall 15 be at least 37. It is recommended that the decimal precision of default real be at least 6, and that its 16 decimal exponent range be at least 37. 17 R412 signed-real-literal-constant is [ sign ] real-literal-constant 18 R413 real-literal-constant is significand [ exponent-letter exponent ] [ kind-param ] 19 or digit-string exponent-letter exponent [ kind-param ] 20 R414 significand is digit-string . [ digit-string ] 21 or . digit-string 22 R415 exponent-letter is E 23 or D 24 R416 exponent is signed-digit-string 25 47 J3/06-007r1 WORKING DRAFT 2006/09/25 C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. 1 C413 (R413) The value of kind-param shall specify an approximation method that exists on the 2 processor. 3 A real literal constant without a kind type parameter is a default real constant if it is without an 4 exponent part or has exponent letter E, and is a double precision real constant if it has exponent letter 5 D. A real literal constant written with a kind type parameter is a real constant with the specified kind 6 type parameter. 7 The exponent represents the power of ten scaling to be applied to the significand or digit string. The 8 meaning of these constants is as in decimal scientific notation. 9 The significand may be written with more digits than a processor will use to approximate the value of 10 the constant. 11 NOTE 4.11 Examples of signed real literal constants are: -12.78 +1.6E3 2.1 -16.E4_8 0.45D-4 10.93E7_QUAD .123 3E4 where QUAD is a scalar integer named constant. 4.4.4 Complex type 12 The complex type has values that approximate the mathematical complex numbers. The values of a 13 complex type are ordered pairs of real values. The first real value is called the real part, and the second 14 real value is called the imaginary part. 15 Each approximation method used to represent data entities of type real shall be available for both the 16 real and imaginary parts of a data entity of type complex. A kind type parameter may be specified for 17 a complex entity and selects for both parts the real approximation method characterized by this kind 18 type parameter value; this kind type parameter is of type default integer. The kind type parameter of 19 an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 20 The type specifier for the complex type uses the keyword COMPLEX. There is no keyword for double 21 precision complex. If the type keyword COMPLEX is specified and the kind type parameter is not 22 specified, the default kind value is the same as that for default real, the type of both parts is default 23 real, and the type specified is default complex. 24 R417 complex-literal-constant is ( real-part , imag-part ) 25 R418 real-part is signed-int-literal-constant 26 or signed-real-literal-constant 27 or named-constant 28 R419 imag-part is signed-int-literal-constant 29 or signed-real-literal-constant 30 or named-constant 31 48 2006/09/25 WORKING DRAFT J3/06-007r1 C414 (R417) Each named constant in a complex literal constant shall be of type integer or real. 1 If the real part and the imaginary part of a complex literal constant are both real, the kind type 2 parameter value of the complex literal constant is the kind type parameter value of the part with the 3 greater decimal precision; if the precisions are the same, it is the kind type parameter value of one of the 4 parts as determined by the processor. If a part has a kind type parameter value different from that of 5 the complex literal constant, the part is converted to the approximation method of the complex literal 6 constant. 7 If both the real and imaginary parts are integer, they are converted to the default real approximation 8 method and the constant is of type default complex. If only one of the parts is an integer, it is converted 9 to the approximation method selected for the part that is real and the kind type parameter value of the 10 complex literal constant is that of the part that is real. 11 NOTE 4.12 Examples of complex literal constants are: (1.0, -1.0) (3, 3.1E6) (4.0_4, 3.6E7_8) ( 0., PI) where PI is a previously declared named real constant. 4.4.5 Character type 12 4.4.5.1 Character sets 13 The character type has a set of values composed of character strings. A character string is a sequence 14 of characters, numbered from left to right 1, 2, 3, ... up to the number of characters in the string. The 15 number of characters in the string is called the length of the string. The length is a type parameter; its 16 kind is processor-dependent and its value is greater than or equal to zero. 17 The processor shall provide one or more representation methods that define sets of values for data 18 of type character. Each such method is characterized by a value for a type parameter called the kind 19 type parameter; this kind type parameter is of type default integer. The kind type parameter of a rep- 20 resentation method is returned by the intrinsic inquiry function KIND (13.7.96). The intrinsic function 21 SELECTED CHAR KIND (13.7.152) returns a kind value based on the name of a character type. Any 22 character of a particular representation method representable in the processor may occur in a character 23 string of that representation method. 24 The character set defined by ISO/IEC 646:1991 (International Reference Version) is referred to as the 25 ASCII character set and its corresponding representation method is the ASCII character type. 26 The character set defined by ISO/IEC 10646-1:2000 UCS-4 is referred to as the ISO 10646 character 27 set and its corresponding representation method is the ISO 10646 character type. 28 4.4.5.2 Character type specifier 29 The type specifier for the character type uses the keyword CHARACTER. 30 If the kind type parameter is not specified, the default kind value is KIND ('A') and the type specified 31 is default character. 32 The default character kind shall support a character set that includes the Fortran character set. By sup- 33 plying nondefault character kinds, the processor may support additional character sets. The characters 34 49 J3/06-007r1 WORKING DRAFT 2006/09/25 available in nondefault character kinds are not specified by this standard, except that one character in 1 each nondefault character set shall be designated as a blank character to be used as a padding character. 2 R420 char-selector is length-selector 3 or ( LEN = type-param-value , 4 KIND = scalar-int-initialization-expr ) 5 or ( type-param-value , 6 [ KIND = ] scalar-int-initialization-expr ) 7 or ( KIND = scalar-int-initialization-expr 8 [ , LEN =type-param-value ] ) 9 R421 length-selector is ( [ LEN = ] type-param-value ) 10 or * char-length [ , ] 11 R422 char-length is ( type-param-value ) 12 or scalar-int-literal-constant 13 C415 (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 14 resentation method that exists on the processor. 15 C416 (R422) The scalar-int-literal-constant shall not include a kind-param. 16 C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr . 17 C418 (R420 R421 R422) A type-param-value of * shall be used only 18 (1) to declare a dummy argument, 19 (2) to declare a named constant, 20 (3) in the type-spec of an ALLOCATE statement wherein each allocate-object is a dummy 21 argument of type CHARACTER with an assumed character length, 22 (4) in the type-spec or derived-type-spec of a type guard statement (8.1.9), or 23 (5) in an external function, to declare the character length parameter of the function result. 24 C419 A function name shall not be declared with an asterisk type-param-value 25 unless it is of type CHAR- ACTER and is the name of the result of an external function or the name of a dummy function. 26 C420 A function name declared with an asterisk type-param-value shall not be an array, a pointer, recursive, or pure. 27 C421 28 (R421) The optional comma in a length-selector is permitted only in a declaration-type-spec in a type-declaration- 29 stmt. C422 30 (R421) The optional comma in a length-selector is permitted only if no double-colon separator appears in the type-declaration-stmt. 31 C423 32 (R420) The length specified for a character statement function or for a statement function dummy argument of type character shall be an initialization expression. 33 The char-selector in a CHARACTER intrinsic-type-spec and the * char-length in an entity-decl or in 34 a component-decl of a type definition specify character length. The * char-length in an entity-decl or 35 a component-decl specifies an individual length and overrides the length specified in the char-selector , 36 if any. If a * char-length is not specified in an entity-decl or a component-decl , the length-selector or 37 type-param-value specified in the char-selector is the character length. If the length is not specified in a 38 char-selector or a * char-length, the length is 1. 39 If the character length parameter value evaluates to a negative value, the length of character entities 40 declared is zero. A character length parameter value of : indicates a deferred type parameter (4.2). A 41 char-length type parameter value of * has the following meanings. 42 (1) If used to declare a dummy argument of a procedure, the dummy argument assumes the 43 length of the associated actual argument. 50 2006/09/25 WORKING DRAFT J3/06-007r1 (2) If used to declare a named constant, the length is that of the constant value. 1 (3) If used in the type-spec of an ALLOCATE statement, each allocate-object assumes its length 2 from the associated actual argument. 3 (4) If used in the type-spec of a type guard statement, the associating entity assumes its length 4 from the selector. 5 (5) 6 If used to specify the character length parameter of a function result, any scoping unit invoking the function shall declare the function name with a character length parameter value other than * or access such a 7 8 definition by host or use association. When the function is invoked, the length of the result variable in the function is assumed from the value of this type parameter. 9 4.4.5.3 Character literal constant 10 A character literal constant is written as a sequence of characters, delimited by either apostrophes 11 or quotation marks. 12 R423 char-literal-constant is [ kind-param ] ' [ rep-char ] ... ' 13 or [ kind-param ] " [ rep-char ] ... " 14 C424 (R423) The value of kind-param shall specify a representation method that exists on the pro- 15 cessor. 16 The optional kind type parameter preceding the leading delimiter specifies the kind type parameter of 17 the character constant; if it is not present, the constant is of type default character. 18 For the type character with kind kind-param, if present, and for type default character otherwise, a 19 representable character, rep-char , is defined as follows. 20 (1) In free source form, it is any graphic character in the processor-dependent character set. 21 (2) 22 In fixed source form, it is any character in the processor-dependent character set. A processor may restrict 23 the occurrence of some or all of the control characters. NOTE 4.13 Fortran 77 allowed any character to occur in a character context. This standard allows a source program to contain characters of more than one kind. Some processors may identify characters of nondefault kinds by control characters (called "escape" or "shift" characters). It is difficult, if not impossible, to process, edit, and print files where some occurences of control characters have their intended meaning and some occurrences might not. Almost all control characters have uses or effects that effectively preclude their use in character contexts and this is why free source form allows only graphic characters as representable characters. Nevertheless, for compatibility with Fortran 77, control characters remain permitted in principle in fixed source form. The delimiting apostrophes or quotation marks are not part of the value of the character literal constant. 24 An apostrophe character within a character constant delimited by apostrophes is represented by two 25 consecutive apostrophes (without intervening blanks); in this case, the two apostrophes are counted as 26 one character. Similarly, a quotation mark character within a character constant delimited by quotation 27 marks is represented by two consecutive quotation marks (without intervening blanks) and the two 28 quotation marks are counted as one character. 29 A zero-length character literal constant is represented by two consecutive apostrophes (without inter- 30 vening blanks) or two consecutive quotation marks (without intervening blanks) outside of a character 31 context. 32 The intrinsic operation concatenation (//) is defined between two data entities of type character (7.2.3) 33 with the same kind type parameter. 34 51 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.14 Examples of character literal constants are: "DON'T" 'DON''T' both of which have the value DON'T and '' which has the zero-length character string as its value. NOTE 4.15 An example of a nondefault character literal constant, where the processor supports the corre- sponding character set, is: ¡ ¢ £ ¤ ¢ ¥ ¦ § NIHONGO ' ' where NIHONGO is a named constant whose value is the kind type parameter for Nihongo (Japanese) characters. This means "Without her, nothing is possible". 4.4.5.4 Collating sequence 1 The processor defines a collating sequence for the character set of each kind of character. A collating 2 sequence is a one-to-one mapping of the characters into the nonnegative integers such that each charac- 3 ter corresponds to a different nonnegative integer. The intrinsic functions CHAR (13.7.30) and ICHAR 4 (13.7.84) provide conversions between the characters and the integers according to this mapping. 5 NOTE 4.16 For example: ICHAR ( 'X' ) returns the integer value of the character 'X' according to the collating sequence of the processor. The collating sequence of the default character type shall satisfy the following constraints. 6 (1) ICHAR ('A') < ICHAR ('B') < ... < ICHAR ('Z') for the twenty-six upper-case letters. 7 (2) ICHAR ('0') < ICHAR ('1') < ... < ICHAR ('9') for the ten digits. 8 (3) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('A') or 9 ICHAR (' ') < ICHAR ('A') < ICHAR ('Z') < ICHAR ('0'). 10 (4) ICHAR ('a') < ICHAR ('b') < ... < ICHAR ('z') for the twenty-six lower-case letters. 11 (5) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('a') or 12 ICHAR (' ') < ICHAR ('a') < ICHAR ('z') < ICHAR ('0'). 13 Except for blank, there are no constraints on the location of the special characters and underscore in 14 the collating sequence, nor is there any specified collating sequence relationship between the upper-case 15 and lower-case letters. 16 The collating sequence for the ASCII character type is as defined by ISO/IEC 646:1991 (International 17 Reference Version); this collating sequence is called the ASCII collating sequence in this standard. 18 The collating sequence for the ISO 10646 character type is as defined by ISO/IEC 10646-1:2000. 19 52 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.17 The intrinsic functions ACHAR (13.7.2) and IACHAR (13.7.77) provide conversion between char- acters and corresponding integer values according to the ASCII collating sequence. The intrinsic functions LGT, LGE, LLE, and LLT (13.7.101-13.7.104) provide comparisons between 1 strings based on the ASCII collating sequence. International portability is guaranteed if the set of 2 characters used is limited to the letters, digits, underscore, and special characters. 3 4.4.6 Logical type 4 The logical type has two values, which represent true and false. 5 The processor shall provide one or more representation methods for data of type logical. Each such 6 method is characterized by a value for a type parameter called the kind type parameter; this kind type 7 parameter is of type default integer. The kind type parameter of a representation method is returned 8 by the intrinsic inquiry function KIND (13.7.96). 9 The type specifier for the logical type uses the keyword LOGICAL. 10 If the kind type parameter is not specified, the default kind value is KIND (.FALSE.) and the type 11 specified is default logical. 12 R424 logical-literal-constant is .TRUE. [ kind-param ] 13 or .FALSE. [ kind-param ] 14 C425 (R424) The value of kind-param shall specify a representation method that exists on the pro- 15 cessor. 16 The optional kind type parameter following the trailing delimiter specifies the kind type parameter of 17 the logical constant; if it is not present, the constant is of type default logical. 18 The intrinsic operations defined for data entities of logical type are: negation (.NOT.), conjunction 19 (.AND.), inclusive disjunction (.OR.), logical equivalence (.EQV.), and logical nonequivalence (.NEQV.) 20 as described in 7.2.5. There is also a set of intrinsically defined relational operators that compare the 21 values of data entities of other types and yield a value of type default logical. These operations are 22 described in 7.2.4. 23 4.4.7 Bits type 24 The bits type has a set of values composed of ordered sequences of bits. The number of bits in 25 the sequence is specified by the kind type parameter, which shall be greater than or equal to zero. 26 The processor shall provide representation methods with kind type parameter values equal to every 27 nonnegative integer less than or equal to a processor-determined limit. This limit shall be at least as 28 large as the storage size, expressed in bits, of every supported kind of type integer, real, complex, and 29 logical. Additional representation methods may be provided. 30 The type specifier for the bits type uses the keyword BITS. 31 If the kind type parameter is not specified for a bits variable, the default kind value is the size of a 32 numeric storage unit expressed in bits, and the type specified is default bits. 33 R425 boz-literal-constant is binary-constant [ kind-param ] 34 or octal-constant [ kind-param ] 35 or hex-constant [ kind-param ] 36 R426 binary-constant is B ' digit [ digit ] ... ' 37 53 J3/06-007r1 WORKING DRAFT 2006/09/25 or B " digit [ digit ] ... " 1 C426 (R426) digit shall have one of the values 0 or 1. 2 R427 octal-constant is O ' digit [ digit ] ... ' 3 or O " digit [ digit ] ... " 4 C427 (R427) digit shall have one of the values 0 through 7. 5 R428 hex-constant is Z ' hex-digit [ hex-digit ] ... ' 6 or Z " hex-digit [ hex-digit ] ... " 7 R429 hex-digit is digit 8 or A 9 or B 10 or C 11 or D 12 or E 13 or F 14 The hex-digits A through F represent the numbers ten through fifteen, respectively; they may be repre- 15 sented by their lower-case equivalents. 16 If the optional kind type parameter is not specified for a boz literal constant, the kind value is assumed 17 from the form of the constant. If the constant is a binary-constant the kind value is the number 18 of digit characters. If the constant is an octal-constant the kind value is three times the number of 19 digit characters. If the constant is a hex-constant the kind value is four times the number of hex-digit 20 characters. 21 NOTE 4.18 Even if a bits value is too large to fit into a single statement as a literal constant, it can be constructed by concatenation of bits named constants. Each digit of an octal constant represents three bits, and each hex digit of a hex constant represents 22 four bits, according to their numerical representations as binary integers, with leading zero bits where 23 needed. 24 If a kind-param is specified for a boz literal constant and has a value greater than the number of bits 25 specified by its digits, the constant is padded on the left (13.3) with enough zero bits to create a constant 26 of kind kind-param. If the kind-param specified has a value smaller the number of bits specified by its 27 digits, only the rightmost kind-param bits are used to determine the value of the constant. 28 NOTE 4.19 Though the processor is required to provide bit kinds only up to four times the size of a numeric storage unit, or up to the maximum intrinsic type size (whichever is larger), it is expected that the actual size limit will be much larger, based on system capacity constraints. Use of BITS objects with KIND values equal to small integer multiples of NUMERIC STORAGE SIZE should result in more efficient execution. 4.5 Derived types 29 4.5.1 Derived type concepts 30 Additional types may be derived from the intrinsic types and other derived types. A type definition is 31 required to define the name of the type and the names and attributes of its components and type-bound 32 54 2006/09/25 WORKING DRAFT J3/06-007r1 procedures. 1 A derived type may be parameterized by multiple type parameters, each of which is defined to be either 2 a kind or length type parameter and may have a default value. 3 The ultimate components of an object of derived type are the components that are of intrinsic type 4 or have the POINTER or ALLOCATABLE attribute, plus the ultimate components of the components 5 of the object that are of derived type and have neither the ALLOCATABLE nor POINTER attribute. 6 NOTE 4.20 The ultimate components of objects of the derived type kids defined below are name, age, and other_kids. type :: person character(len=20) :: name integer :: age end type person type :: kids type(person) :: oldest_child type(person), allocatable, dimension(:) :: other_kids end type kids The direct components of an object of derived type are the components of that object, plus the direct 7 components of the components of the object that are of derived type and have neither the ALLOCAT- 8 ABLE nor POINTER attribute. 9 By default, no storage sequence is implied by the order of the component definitions. However, a storage 10 order is implied for a sequence type (4.5.2.3). If the derived type has the BIND attribute, the storage 11 sequence is that required by the companion processor (2.5.10, 15.3.4). 12 A scalar entity of derived type is a structure. If a derived type has the SEQUENCE property, a scalar 13 entity of the type is a sequence structure. 14 4.5.2 Derived-type definition 15 4.5.2.1 Syntax 16 R430 derived-type-def is derived-type-stmt 17 [ type-param-def-stmt ] ... 18 [ private-or-sequence ] ... 19 [ component-part ] 20 [ type-bound-procedure-part ] 21 end-type-stmt 22 R431 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name 23 [ ( type-param-name-list ) ] 24 R432 type-attr-spec is ABSTRACT 25 or access-spec 26 or BIND (C) 27 or EXTENDS ( parent-type-name ) 28 C428 (R431) A derived type type-name shall not be DOUBLEPRECISION or the same as the name 29 of any intrinsic type defined in this part of ISO/IEC 1539. 30 C429 (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt. 31 55 J3/06-007r1 WORKING DRAFT 2006/09/25 C430 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). 1 C431 (R430) If the type definition contains or inherits (4.5.7.2) a deferred binding (4.5.5), ABSTRACT 2 shall appear. 3 C432 (R430) If ABSTRACT appears, the type shall be extensible. 4 C433 (R430) If EXTENDS appears, SEQUENCE shall not appear. 5 C434 (R430) If EXTENDS appears and the type being defined has a co-array ultimate component, 6 its parent type shall have a co-array ultimate component. 7 R433 private-or-sequence is private-components-stmt 8 or sequence-stmt 9 C435 (R430) The same private-or-sequence shall not appear more than once in a given derived-type- 10 def . 11 R434 end-type-stmt is END TYPE [ type-name ] 12 C436 (R434) If END TYPE is followed by a type-name, the type-name shall be the same as that in 13 the corresponding derived-type-stmt. 14 Derived types with the BIND attribute are subject to additional constraints as specified in 15.3.4. 15 NOTE 4.21 An example of a derived-type definition is: TYPE PERSON INTEGER AGE CHARACTER (LEN = 50) NAME END TYPE PERSON An example of declaring a variable CHAIRMAN of type PERSON is: TYPE (PERSON) :: CHAIRMAN 4.5.2.2 Accessibility 16 Types that are defined in a module or accessible in that module by use association have either the 17 PUBLIC or PRIVATE attribute. Types for which an access-spec is not explicitly specified in that 18 module have the default accessibility attribute for that module. The default accessibility attribute for a 19 module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only types that have 20 the PUBLIC attribute in that module are available to be accessed from that module by use association. 21 The accessibility of a type does not affect, and is not affected by, the accessibility of its components and 22 bindings. 23 If a type definition is private, then the type name, and thus the structure constructor (4.5.10) for the 24 type, are accessible only within the module containing the definition, and within its descendants. 25 NOTE 4.22 An example of a type with a private name is: TYPE, PRIVATE :: AUXILIARY LOGICAL :: DIAGNOSTIC 56 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.22 (cont.) CHARACTER (LEN = 20) :: MESSAGE END TYPE AUXILIARY Such a type would be accessible only within the module in which it is defined, and within its descendants. 4.5.2.3 Sequence type 1 R435 sequence-stmt is SEQUENCE 2 C437 (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type 3 or of a sequence derived type. 4 C438 (R430) If SEQUENCE appears, a type-bound-procedure-part shall not appear. 5 If the SEQUENCE statement appears, the type is a sequence type. The order of the component 6 definitions in a sequence type specifies a storage sequence for objects of that type. The type is a 7 numeric sequence type if there are no type parameters, no pointer or allocatable components, and 8 each component is of type default integer, default real, double precision real, default complex, default 9 logical, default bits, or a numeric sequence type. The type is a character sequence type if there 10 are no type parameters, no pointer or allocatable components, and each component is of type default 11 character or a character sequence type. 12 NOTE 4.23 An example of a numeric sequence type is: TYPE NUMERIC_SEQ SEQUENCE INTEGER :: INT_VAL REAL :: REAL_VAL LOGICAL :: LOG_VAL END TYPE NUMERIC_SEQ NOTE 4.24 A structure resolves into a sequence of components. Unless the structure includes a SEQUENCE statement, the use of this terminology in no way implies that these components are stored in this, or any other, order. Nor is there any requirement that contiguous storage be used. The sequence merely refers to the fact that in writing the definitions there will necessarily be an order in which the components appear, and this will define a sequence of components. This order is of limited significance because a component of an object of derived type will always be accessed by a component name except in the following contexts: the sequence of expressions in a derived-type value constructor, intrinsic assignment, the data values in namelist input data, and the inclusion of the structure in an input/output list of a formatted data transfer, where it is expanded to this sequence of components. Provided the processor adheres to the defined order in these cases, it is otherwise free to organize the storage of the components for any nonsequence structure in memory as best suited to the particular architecture. 4.5.2.4 Determination of derived types 13 Derived-type definitions with the same type name may appear in different scoping units, in which case 14 they may be independent and describe different derived types or they may describe the same type. 15 57 J3/06-007r1 WORKING DRAFT 2006/09/25 Two data entities have the same type if they are declared with reference to the same derived-type 1 definition. The definition may be accessed from a module or from a host scoping unit. Data entities in 2 different scoping units also have the same type if they are declared with reference to different derived-type 3 definitions that specify the same type name, all have the SEQUENCE property or all have the BIND 4 attribute, have no components with PRIVATE accessibility, and have type parameters and components 5 that agree in order, name, and attributes. Otherwise, they are of different derived types. A data entity 6 declared using a type with the SEQUENCE property or with the BIND attribute is not of the same type 7 as an entity of a type declared to be PRIVATE or that has any components that are PRIVATE. 8 NOTE 4.25 An example of declaring two entities with reference to the same derived-type definition is: TYPE POINT REAL X, Y END TYPE POINT TYPE (POINT) :: X1 CALL SUB (X1) ... CONTAINS SUBROUTINE SUB (A) TYPE (POINT) :: A ... END SUBROUTINE SUB The definition of derived type POINT is known in subroutine SUB by host association. Because the declarations of X1 and A both reference the same derived-type definition, X1 and A have the same type. X1 and A also would have the same type if the derived-type definition were in a module and both SUB and its containing program unit referenced the module. NOTE 4.26 An example of data entities in different scoping units having the same type is: PROGRAM PGM TYPE EMPLOYEE SEQUENCE INTEGER ID_NUMBER CHARACTER (50) NAME END TYPE EMPLOYEE TYPE (EMPLOYEE) PROGRAMMER CALL SUB (PROGRAMMER) ... END PROGRAM PGM SUBROUTINE SUB (POSITION) TYPE EMPLOYEE SEQUENCE INTEGER ID_NUMBER CHARACTER (50) NAME END TYPE EMPLOYEE TYPE (EMPLOYEE) POSITION ... END SUBROUTINE SUB The actual argument PROGRAMMER and the dummy argument POSITION have the same type 58 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.26 (cont.) because they are declared with reference to a derived-type definition with the same name, the SEQUENCE property, and components that agree in order, name, and attributes. Suppose the component name ID NUMBER was ID NUM in the subroutine. Because all the component names are not identical to the component names in derived type EMPLOYEE in the main program, the actual argument PROGRAMMER would not be of the same type as the dummy argument POSITION. Thus, the program would not be standard-conforming. NOTE 4.27 The requirement that the two types have the same name applies to the type-names of the respective derived-type-stmts, not to local names introduced via renaming in USE statements. 4.5.3 Derived-type parameters 1 4.5.3.1 Declaration 2 R436 type-param-def-stmt is INTEGER [ kind-selector ] , type-param-attr-spec :: 3 type-param-decl -list 4 R437 type-param-decl is type-param-name [ = scalar-int-initialization-expr ] 5 C439 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the 6 type-param-names in the derived-type-stmt of that derived-type-def . 7 C440 (R436) Each type-param-name in the derived-type-stmt in a derived-type-def shall appear as a 8 type-param-name in a type-param-def-stmt in that derived-type-def . 9 R438 type-param-attr-spec is KIND 10 or LEN 11 The derived type is parameterized if the derived-type-stmt has any type-param-names. 12 Each type parameter is itself of type integer. If its kind selector is omitted, the kind type parameter is 13 default integer. 14 The type-param-attr-spec explicitly specifies whether a type parameter is a kind parameter or a length 15 parameter. 16 If a type-param-decl has a scalar-int-initialization-expr , the type parameter has a default value which 17 is specified by the expression. If necessary, the value is converted according to the rules of intrinsic 18 assignment (7.4.1.3) to a value of the same kind as the type parameter. 19 A type parameter may be used as a primary in a specification expression (7.1.6) in the derived-type- 20 def . A kind type parameter may also be used as a primary in an initialization expression (7.1.7) in the 21 derived-type-def . 22 NOTE 4.28 The following example uses derived-type parameters. TYPE humongous_matrix(k, d) INTEGER, KIND :: k = kind(0.0) INTEGER(selected_int_kind(12)), LEN :: d !-- Specify a nondefault kind for d. REAL(k) :: element(d,d) 59 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.28 (cont.) END TYPE In the following example, dim is declared to be a kind parameter, allowing generic overloading of procedures distinguished only by dim. TYPE general_point(dim) INTEGER, KIND :: dim REAL :: coordinates(dim) END TYPE 4.5.3.2 Type parameter order 1 Type parameter order is an ordering of the type parameters of a derived type; it is used for derived- 2 type specifiers. 3 The type parameter order of a nonextended type is the order of the type parameter list in the derived- 4 type definition. The type parameter order of an extended type consists of the type parameter order of 5 its parent type followed by any additional type parameters in the order of the type parameter list in the 6 derived-type definition. 7 NOTE 4.29 Given TYPE :: t1(k1,k2) INTEGER,KIND :: k1,k2 REAL(k1) a(k2) END TYPE TYPE,EXTENDS(t1) :: t2(k3) INTEGER,KIND :: k3 LOGICAL(k3) flag END TYPE the type parameter order for type T1 is K1 then K2, and the type parameter order for type T2 is K1 then K2 then K3. 4.5.4 Components 8 4.5.4.1 Syntax 9 R439 component-part is [ component-def-stmt ] ... 10 R440 component-def-stmt is data-component-def-stmt 11 or proc-component-def-stmt 12 R441 data-component-def-stmt is declaration-type-spec [ [ , component-attr-spec-list ] :: ] 13 component-decl -list 14 R442 component-attr-spec is access-spec 15 or ALLOCATABLE 16 or DIMENSION ( component-array-spec ) 17 or DIMENSION [ ( deferred-shape-spec-list ) ] 18 lbracket co-array-spec rbracket 19 or CONTIGUOUS 20 or POINTER 21 R443 component-decl is component-name [ ( component-array-spec ) ] 22 60 2006/09/25 WORKING DRAFT J3/06-007r1 [ lbracket co-array-spec rbracket ] 1 [ * char-length ] [ component-initialization ] 2 R444 component-array-spec is explicit-shape-spec-list 3 or deferred-shape-spec-list 4 5 C441 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt. 6 C442 (R441) If neither the POINTER nor ALLOCATABLE attribute is specified, the declaration-type- 7 spec in the component-def-stmt shall specify an intrinsic type or a previously defined derived 8 type. 9 C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in 10 the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible 11 derived type including the type being defined. 12 C444 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec 13 shall be a deferred-shape-spec-list. 14 C445 (R441) If a co-array-spec appears, it shall be a deferred-co-shape-spec-list and the component 15 shall have the ALLOCATABLE attribute. 16 C446 (R441) If a co-array-spec appears, the component shall not be of type IMAGE TEAM (13.8.3.7), 17 C PTR, or C FUNPTR (15.3.3). 18 C447 A data component whose type has a co-array ultimate component shall be a nonpointer nonal- 19 locatable scalar and shall not be a co-array. 20 C448 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each 21 component-array-spec shall be an explicit-shape-spec-list. 22 C449 (R444) Each bound in the explicit-shape-spec shall either be an initialization expression or be a 23 specification expression that does not contain references to specification functions or any object 24 designators other than named constants or subobjects thereof. 25 J3 internal note Unresolved Technical Issue 094 This contraint is inconsistent (as is the one 3 below): it allows INTEGER c1(DIGITS(yvariable)) INTEGER c2(len_type_param) but not INTEGER c3(DIGITS(yvariable)+len_type_param) It's not quite trivial to word this correctly... C450 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. 26 C451 (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the 27 POINTER attribute. 28 C452 (R443) The * char-length option is permitted only if the component is of type character. 29 C453 (R440) Each type-param-value within a component-def-stmt shall either be a colon, be an ini- 30 tialization expression, or be a specification expression that contains neither references to speci- 31 fication functions nor any object designators other than named constants or subobjects thereof. 32 61 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.30 Because a type parameter is not an object, a type-param-value or a bound in an explicit-shape-spec may contain a type-param-name. R445 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , 1 proc-component-attr-spec-list :: proc-decl -list 2 NOTE 4.31 See 12.4.3.5 for definitions of proc-interface and proc-decl . R446 proc-component-attr-spec is POINTER 3 or PASS [ (arg-name) ] 4 or NOPASS 5 or access-spec 6 C454 (R445) The same proc-component-attr-spec shall not appear more than once in a given proc- 7 component-def-stmt. 8 C455 (R445) POINTER shall appear in each proc-component-attr-spec-list. 9 C456 (R445) If the procedure pointer component has an implicit interface or has no arguments, 10 NOPASS shall be specified. 11 C457 (R445) If PASS (arg-name) appears, the interface shall have a dummy argument named arg- 12 name. 13 C458 (R445) PASS and NOPASS shall not both appear in the same proc-component-attr-spec-list. 14 4.5.4.2 Array components 15 A data component is an array if its component-decl contains a component-array-spec or its data-compo- 16 nent-def-stmt contains the DIMENSION clause with a component-array-spec. If the component-decl 17 contains a component-array-spec, it specifies the array rank, and if the array is explicit shape (5.3.7.2), 18 the array bounds; otherwise, the component-array-spec in the DIMENSION clause specifies the array 19 rank, and if the array is explicit shape, the array bounds. 20 A data component is a co-array if its component-decl contains a co-array-spec or its data-component-def- 21 stmt contains a DIMENSION clause with a co-array-spec. If the component-decl contains a co-array-spec 22 it specifies the co-rank; otherwise, the co-array-spec in the DIMENSION clause specifies the co-rank. 23 NOTE 4.32 An example of a derived type definition with an array component is: TYPE LINE REAL, DIMENSION (2, 2) :: COORD ! ! COORD(:,1) has the value of (/X1, Y1/) ! COORD(:,2) has the value of (/X2, Y2/) REAL :: WIDTH ! Line width in centimeters INTEGER :: PATTERN ! 1 for solid, 2 for dash, 3 for dot END TYPE LINE An example of declaring a variable LINE SEGMENT to be of the type LINE is: TYPE (LINE) :: LINE_SEGMENT 62 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.32 (cont.) The scalar variable LINE SEGMENT has a component that is an array. In this case, the array is a subobject of a scalar. The double colon in the definition for COORD is required; the double colon in the definition for WIDTH and PATTERN is optional. NOTE 4.33 An example of a derived type definition with an allocatable component is: TYPE STACK INTEGER :: INDEX INTEGER, ALLOCATABLE :: CONTENTS (:) END TYPE STACK For each scalar variable of type STACK, the shape of the component CONTENTS is determined by execution of an ALLOCATE statement or assignment statement, or by argument association. NOTE 4.34 Default initialization of an explicit-shape array component may be specified by an initialization expression consisting of an array constructor (4.7), or of a single scalar that becomes the value of each array element. 4.5.4.3 Pointer components 1 A component is a pointer (2.4.7) if its component-attr-spec-list contains the POINTER attribute. A 2 pointer component may be a data pointer or a procedure pointer. 3 NOTE 4.35 An example of a derived type definition with a pointer component is: TYPE REFERENCE INTEGER :: VOLUME, YEAR, PAGE CHARACTER (LEN = 50) :: TITLE PROCEDURE (printer_interface), POINTER :: PRINT => NULL() CHARACTER, DIMENSION (:), POINTER :: SYNOPSIS END TYPE REFERENCE Any object of type REFERENCE will have the four nonpointer components VOLUME, YEAR, PAGE, and TITLE, the procedure pointer PRINT, which has an explicit interface the same as printer interface, plus a pointer to an array of characters holding SYNOPSIS. The size of this target array will be determined by the length of the abstract. The space for the target may be allocated (6.3.1) or the pointer component may be associated with a target by a pointer assignment statement (7.4.2). 4.5.4.4 The passed-object dummy argument 4 A passed-object dummy argument is a distinguished dummy argument of a procedure pointer 5 component or type-bound procedure. It affects procedure overriding (4.5.7.3) and argument association 6 (12.5.2.2). 7 If NOPASS is specified, the procedure pointer component or type-bound procedure has no passed-object 8 dummy argument. 9 63 J3/06-007r1 WORKING DRAFT 2006/09/25 If neither PASS nor NOPASS is specified or PASS is specified without arg-name, the first dummy argu- 1 ment of a procedure pointer component or type-bound procedure is its passed-object dummy argument. 2 If PASS (arg-name) is specified, the dummy argument named arg-name is the passed-object dummy 3 argument of the procedure pointer component or named type-bound procedure. 4 C459 The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy data 5 object with the same declared type as the type being defined; all of its length type parameters 6 shall be assumed; it shall be polymorphic (4.3.1.3) if and only if the type being defined is 7 extensible (4.5.7). It shall not have the VALUE attribute. 8 NOTE 4.36 If a procedure is bound to several types as a type-bound procedure, different dummy arguments might be the passed-object dummy argument in different contexts. 4.5.4.5 Default initialization for components 9 Default initialization provides a means of automatically initializing pointer components to be disassoci- 10 ated or associated with specific targets, and nonpointer nonallocatable components to have a particular 11 value. Allocatable components are always initialized to not allocated. 12 A pointer variable or component is data-pointer-initialization compatible with a target if the pointer 13 is type compatible with the target, they have the same rank, and the values of corresponding nondeferred 14 type parameters are specified by initialization expressions that have the same value. 15 R447 component-initialization is = initialization-expr 16 or => null-init 17 or => initial-data-target 18 R448 initial-data-target is designator 19 C460 (R441) If component-initialization appears, a double-colon separator shall appear before the 20 component-decl -list. 21 C461 (R441) If component-initialization appears, every type parameter and array bound of the com- 22 ponent shall be a colon or initialization expression. 23 C462 (R441) If => appears in component-initialization, POINTER shall appear in the component- 24 attr-spec-list. If = appears in component-initialization, neither POINTER nor ALLOCATABLE 25 shall appear in the component-attr-spec-list. 26 C463 (R447) If initial-data-target appears, component-name shall be data-pointer-initialization com- 27 patible with it. 28 C464 (R448) The designator shall designate a variable that is an initialization target. Every subscript, 29 section subscript, substring starting point, and substring ending point in designator shall be an 30 initialization expression. 31 If null-init appears for a pointer component, that component in any object of the type has an initial 32 association status of disassociated (16.5.2.2) or becomes disassociated as specified in 16.5.2.2.2. 33 A variable is an initialization target if it has the TARGET attribute, either has the SAVE attribute 34 or is declared in the main program, and does not have the ALLOCATABLE attribute. 35 If initial-data-target appears for a data pointer component, that component in any object of the type is 36 initially associated with the target or becomes associated with the target as specified in 16.5.2.2.1. 37 64 2006/09/25 WORKING DRAFT J3/06-007r1 If initial-proc-target (12.4.3.5) appears in proc-decl for a procedure pointer component, that component 1 in any object of the type is initially associated with the target or becomes associated with the target as 2 specified in 16.5.2.2.1. 3 If initialization-expr appears for a nonpointer component, that component in any object of the type 4 is initially defined (16.6.3) or becomes defined as specified in 16.6.5 with the value determined from 5 initialization-expr . If necessary, the value is converted according to the rules of intrinsic assignment 6 (7.4.1.3) to a value that agrees in type, type parameters, and shape with the component. If the compo- 7 nent is of a type for which default initialization is specified for a component, the default initialization 8 specified by initialization-expr overrides the default initialization specified for that component. When 9 one initialization overrides another it is as if only the overriding initialization were specified (see Note 10 4.38). Explicit initialization in a type declaration statement (5.2) overrides default initialization (see 11 Note 4.37). Unlike explicit initialization, default initialization does not imply that the object has the 12 SAVE attribute. 13 A subcomponent (6.1.2) is default-initialized if the type of the object of which it is a component 14 specifies default initialization for that component, and the subcomponent is not a subobject of an object 15 that is default-initialized or explicitly initialized. 16 NOTE 4.37 It is not required that initialization be specified for each component of a derived type. For example: TYPE DATE INTEGER DAY CHARACTER (LEN = 5) MONTH INTEGER :: YEAR = 1994 ! Partial default initialization END TYPE DATE In the following example, the default initial value for the YEAR component of TODAY is overridden by explicit initialization in the type declaration statement: TYPE (DATE), PARAMETER :: TODAY = DATE (21, "Feb.", 1995) NOTE 4.38 The default initial value of a component of derived type may be overridden by default initialization specified in the definition of the type. Continuing the example of Note 4.37: TYPE SINGLE_SCORE TYPE(DATE) :: PLAY_DAY = TODAY INTEGER SCORE TYPE(SINGLE_SCORE), POINTER :: NEXT => NULL ( ) END TYPE SINGLE_SCORE TYPE(SINGLE_SCORE) SETUP The PLAY DAY component of SETUP receives its initial value from TODAY, overriding the initialization for the YEAR component. NOTE 4.39 Arrays of structures may be declared with elements that are partially or totally initialized by default. Continuing the example of Note 4.38 : TYPE MEMBER (NAME_LEN) 65 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.39 (cont.) INTEGER, LEN :: NAME_LEN CHARACTER (LEN = NAME_LEN) NAME = '' INTEGER :: TEAM_NO, HANDICAP = 0 TYPE (SINGLE_SCORE), POINTER :: HISTORY => NULL ( ) END TYPE MEMBER TYPE (MEMBER(9)) LEAGUE (36) ! Array of partially initialized elements TYPE (MEMBER(9)) :: ORGANIZER = MEMBER ("I. Manage",1,5,NULL ( )) ORGANIZER is explicitly initialized, overriding the default initialization for an object of type MEMBER. Allocated objects may also be initialized partially or totally. For example: ALLOCATE (ORGANIZER % HISTORY) ! A partially initialized object of type ! SINGLE_SCORE is created. NOTE 4.40 A pointer component of a derived type may have as its target an object of that derived type. The type definition may specify that in objects declared to be of this type, such a pointer is default initialized to disassociated. For example: TYPE NODE INTEGER :: VALUE = 0 TYPE (NODE), POINTER :: NEXT_NODE => NULL ( ) END TYPE A type such as this may be used to construct linked lists of objects of type NODE. See C.1.4 for an example. Linked lists can also be constructed using allocatable components. NOTE 4.41 A pointer component of a derived type may be default-initialized to have an initial target. TYPE NODE INTEGER :: VALUE = 0 TYPE (NODE), POINTER :: NEXT_NODE => SENTINEL END TYPE TYPE(NODE), SAVE, TARGET :: SENTINEL 4.5.4.6 Component order 1 Component order is an ordering of the nonparent components of a derived type; it is used for intrinsic 2 formatted input/output and structure constructors (where component keywords are not used). Parent 3 components are excluded from the component order of an extended type (4.5.7). 4 The component order of a nonextended type is the order of the declarations of the components in the 5 derived-type definition. The component order of an extended type consists of the component order of 6 its parent type followed by any additional components in the order of their declarations in the extended 7 derived-type definition. 8 66 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.42 Given the same type definitions as in Note 4.29, the component order of type T1 is just A (there is only one component), and the component order of type T2 is A then FLAG. The parent component (T1) does not participate in the component order. 4.5.4.7 Component accessibility 1 R449 private-components-stmt is PRIVATE 2 C465 (R449) A private-components-stmt is permitted only if the type definition is within the specifi- 3 cation part of a module. 4 The default accessibility for the components that are declared in a type's component-part is private 5 if the type definition contains a private-components-stmt, and public otherwise. The accessibility of a 6 component may be explicitly declared by an access-spec; otherwise its accessibility is the default for the 7 type definition in which it is declared. 8 If a component is private, that component name is accessible only within the module containing the 9 definition, and within its descendants. 10 NOTE 4.43 Type parameters are not components. They are effectively always public. NOTE 4.44 The accessibility of the components of a type is independent of the accessibility of the type name. It is possible to have all four combinations: a public type name with a public component, a private type name with a private component, a public type name with a private component, and a private type name with a public component. NOTE 4.45 An example of a type with private components is: TYPE POINT PRIVATE REAL :: X, Y END TYPE POINT Such a type definition is accessible in any scoping unit accessing the module via a USE state- ment; however, the components X and Y are accessible only within the module, and within its descendants. NOTE 4.46 The following example illustrates the use of an individual component access-spec to override the default accessibility: TYPE MIXED PRIVATE INTEGER :: I INTEGER, PUBLIC :: J END TYPE MIXED TYPE (MIXED) :: M 67 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.46 (cont.) The component M%J is accessible in any scoping unit where M is accessible; M%I is accessible only within the module containing the TYPE MIXED definition, and within its descendants. 4.5.5 Type-bound procedures 1 R450 type-bound-procedure-part is contains-stmt 2 [ binding-private-stmt ] 3 [ proc-binding-stmt ] ... 4 R451 binding-private-stmt is PRIVATE 5 C466 (R450) A binding-private-stmt is permitted only if the type definition is within the specification 6 part of a module. 7 R452 proc-binding-stmt is specific-binding 8 or generic-binding 9 or final-binding 10 R453 specific-binding is PROCEDURE [ (interface-name) ] 11 [ [ , binding-attr -list ] :: ] 12 binding-name [ => procedure-name ] 13 C467 (R453) If => procedure-name appears, the double-colon separator shall appear. 14 C468 (R453) If => procedure-name appears, interface-name shall not appear. 15 C469 (R453) The procedure-name shall be the name of an accessible module procedure or an external 16 procedure that has an explicit interface. 17 If neither => procedure-name nor interface-name appears, it is as though => procedure-name had 18 appeared with a procedure name the same as the binding name. 19 R454 generic-binding is GENERIC 20 [, access-spec ] :: generic-spec => binding-name-list 21 C470 (R454) Within the specification-part of a module, each generic-binding shall specify, either 22 implicitly or explicitly, the same accessibility as every other generic-binding with that generic- 23 spec in the same derived type. 24 C471 (R454) Each binding-name in binding-name-list shall be the name of a specific binding of the 25 type. 26 C472 (R454) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object 27 dummy argument (4.5.4.4). 28 C473 (R454) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall 29 be as specified in 12.4.3.3.1. 30 C474 (R454) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified 31 in 12.4.3.3.2. 32 C475 (R454) If generic-spec is dtio-generic-spec, the interface of each binding shall be as specified in 33 9.5.4.7. The type of the dtv argument shall be type-name. 34 R455 binding-attr is PASS [ (arg-name) ] 35 or NOPASS 36 or NON OVERRIDABLE 37 68 2006/09/25 WORKING DRAFT J3/06-007r1 or DEFERRED 1 or access-spec 2 C476 (R455) The same binding-attr shall not appear more than once in a given binding-attr -list. 3 C477 (R453) If the interface of the binding has no dummy argument of the type being defined, 4 NOPASS shall appear. 5 C478 (R453) If PASS (arg-name) appears, the interface of the binding shall have a dummy argument 6 named arg-name. 7 C479 (R455) PASS and NOPASS shall not both appear in the same binding-attr -list. 8 C480 (R455) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- 9 attr -list. 10 C481 (R455) DEFERRED shall appear if and only if interface-name appears. 11 C482 (R453) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding 12 it overrides is deferred. 13 C483 (R453) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- 14 RIDABLE attribute. 15 Each binding in a proc-binding-stmt specifies a type-bound procedure. A type-bound procedure 16 may have a passed-object dummy argument (4.5.4.4). A generic-binding specifies a type-bound generic 17 interface for its specific bindings. A binding that specifies the DEFERRED attribute is a deferred 18 binding. A deferred binding shall appear only in the definition of an abstract type. 19 A type-bound procedure may be identified by a binding name in the scope of the type definition. 20 This name is the binding-name for a specific binding, and the generic-name for a generic binding whose 21 generic-spec is generic-name. A final binding, or a generic binding whose generic-spec is not generic- 22 name, has no binding name. 23 The interface of a specific binding is that of the procedure specified by procedure-name or the interface 24 specified by interface-name. 25 NOTE 4.47 An example of a type and a type-bound procedure is: TYPE POINT REAL :: X, Y CONTAINS PROCEDURE, PASS :: LENGTH => POINT_LENGTH END TYPE POINT ... and in the module-subprogram-part of the same module: REAL FUNCTION POINT_LENGTH (A, B) CLASS (POINT), INTENT (IN) :: A, B POINT_LENGTH = SQRT ( (A%X - B%X)**2 + (A%Y - B%Y)**2 ) END FUNCTION POINT_LENGTH The same generic-spec may be used in several generic-bindings within a single derived-type definition. 26 Each additional generic-binding with the same generic-spec extends the generic interface. 27 69 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.48 Unlike the situation with generic procedure names, a generic type-bound procedure name is not permitted to be the same as a specific type-bound procedure name in the same type (16.3). The default accessibility for the procedure bindings of a type is private if the type definition contains a 1 binding-private-stmt, and public otherwise. The accessibility of a procedure binding may be explicitly 2 declared by an access-spec; otherwise its accessibility is the default for the type definition in which it is 3 declared. 4 A public type-bound procedure is accessible via any accessible object of the type. A private type-bound 5 procedure is accessible only within the module containing the type definition, and within its descendants. 6 NOTE 4.49 The accessibility of a type-bound procedure is not affected by a PRIVATE statement in the component-part; the accessibility of a data component is not affected by a PRIVATE statement in the type-bound-procedure-part. 4.5.6 Final subroutines 7 4.5.6.1 Declaration 8 R456 final-binding is FINAL [ :: ] final-subroutine-name-list 9 C484 (R456) A final-subroutine-name shall be the name of a module procedure with exactly one 10 dummy argument. That argument shall be nonoptional and shall be a nonpointer, nonallocat- 11 able, nonpolymorphic variable of the derived type being defined. All length type parameters of 12 the dummy argument shall be assumed. The dummy argument shall not be INTENT(OUT). 13 C485 (R456) A final-subroutine-name shall not be one previously specified as a final subroutine for 14 that type. 15 C486 (R456) A final subroutine shall not have a dummy argument with the same kind type parameters 16 and rank as the dummy argument of another final subroutine of that type. 17 The FINAL keyword specifies a list of final subroutines. A final subroutine might be executed when 18 a data entity of that type is finalized (4.5.6.2). 19 A derived type is finalizable if it has any final subroutines or if it has any nonpointer, nonallocatable 20 component whose type is finalizable. A nonpointer data entity is finalizable if its type is finalizable. 21 NOTE 4.50 Final subroutines are effectively always "accessible". They are called for entity finalization re- gardless of the accessibility of the type, its other type-bound procedures, or the subroutine name itself. NOTE 4.51 Final subroutines are not inherited through type extension and cannot be overridden. The final subroutines of the parent type are called after any additional final subroutines of an extended type are called. 4.5.6.2 The finalization process 22 Only finalizable entities are finalized. When an entity is finalized, the following steps are carried out 23 in sequence. 70 2006/09/25 WORKING DRAFT J3/06-007r1 (1) If the dynamic type of the entity has a final subroutine whose dummy argument has the 1 same kind type parameters and rank as the entity being finalized, it is called with the entity 2 as an actual argument. Otherwise, if there is an elemental final subroutine whose dummy 3 argument has the same kind type parameters as the entity being finalized, it is called with 4 the entity as an actual argument. Otherwise, no subroutine is called at this point. 5 (2) Each finalizable component that appears in the type definition is finalized. If the entity 6 being finalized is an array, each finalizable component of each element of that entity is 7 finalized separately. 8 (3) If the entity is of extended type and the parent type is finalizable, the parent component is 9 finalized. 10 If several entities are to be finalized as a consequence of an event specified in 4.5.6.3, the order in which 11 they are finalized is processor-dependent. A final subroutine shall not reference or define an object that 12 has already been finalized. 13 If an object is not finalized, it retains its definition status and does not become undefined. 14 4.5.6.3 When finalization occurs 15 When a pointer is deallocated its target is finalized. When an allocatable entity is deallocated, it is 16 finalized. 17 A nonpointer, nonallocatable object that is not a dummy argument or function result is finalized immedi- 18 ately before it would become undefined due to execution of a RETURN or END statement (16.6.6, item 19 (3)). If the object is defined in a module or submodule, and there are no longer any active procedures 20 referencing the module or submodule, it is processor-dependent whether it is finalized. 21 A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it 22 would become undefined due to termination of the BLOCK construct (16.6.6, item (20)). 23 If an executable construct references a function, the result is finalized after execution of the innermost 24 executable construct containing the reference. 25 If an executable construct references a structure constructor or array constructor, the entity created by 26 the constructor is finalized after execution of the innermost executable construct containing the reference. 27 If a specification expression in a scoping unit references a function, the result is finalized before execution 28 of the executable constructs in the scoping unit. 29 If a specification expression in a scoping unit references a structure constructor or array constructor, the 30 entity created by the constructor is finalized before execution of the executable constructs in the scoping 31 unit. 32 When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated 33 with an INTENT(OUT) dummy argument is finalized. 34 When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr 35 and before the definition of the variable. 36 NOTE 4.52 If finalization is used for storage management, it often needs to be combined with defined assign- ment. If an object is allocated via pointer allocation and later becomes unreachable due to all pointers to that 37 object having their pointer association status changed, it is processor dependent whether it is finalized. 38 If it is finalized, it is processor dependent as to when the final subroutines are called. 39 71 J3/06-007r1 WORKING DRAFT 2006/09/25 4.5.6.4 Entities that are not finalized 1 If image execution is terminated, either by an error (e.g. an allocation failure) or by execution of a STOP 2 or END PROGRAM statement, entities existing immediately prior to termination are not finalized. 3 NOTE 4.53 A nonpointer, nonallocatable object that has the SAVE attribute or that occurs in the main pro- gram is never finalized as a direct consequence of the execution of a RETURN or END statement. A variable in a module or submodule is not finalized if it retains its definition status and value, even when there is no active procedure referencing the module or submodule. 4.5.7 Type extension 4 4.5.7.1 Concepts 5 A nonsequence derived type that does not have the BIND attribute is an extensible type. 6 An extensible type that does not have the EXTENDS attribute is a base type. A type that has the 7 EXTENDS attribute is an extended type. The parent type of an extended type is the type named 8 in the EXTENDS attribute specification. 9 NOTE 4.54 The name of the parent type might be a local name introduced via renaming in a USE statement. A base type is an extension type of itself only. An extended type is an extension of itself and of all 10 types for which its parent type is an extension. 11 An abstract type is a type that has the ABSTRACT attribute. 12 NOTE 4.55 A deferred binding (4.5.5) defers the implementation of a type-bound procedure to extensions of the type; it may appear only in an abstract type. The dynamic type of an object cannot be abstract; therefore, a deferred binding cannot be invoked. An extension of an abstract type need not be abstract if it has no deferred bindings. A short example of an abstract type is: TYPE, ABSTRACT :: FILE_HANDLE CONTAINS PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN ... END TYPE For a more elaborate example see C.1.3. 4.5.7.2 Inheritance 13 An extended type includes all of the type parameters, all of the components, and the nonoverridden 14 (4.5.7.3) nonfinal procedure bindings of its parent type. These are inherited by the extended type from 15 the parent type. They retain all of the attributes that they had in the parent type. Additional type 16 parameters, components, and procedure bindings may be declared in the derived-type definition of the 17 extended type. 18 72 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.56 Inaccessible components and bindings of the parent type are also inherited, but they remain inac- cessible in the extended type. Inaccessible entities occur if the type being extended is accessed via use association and has a private entity. NOTE 4.57 A base type is not required to have any components, bindings, or parameters; an extended type is not required to have more components, bindings, or parameters than its parent type. An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and 1 type parameters of the parent type. The name of this component is the parent type name. It has the 2 accessibility of the parent type. Components of the parent component are inheritance associated 3 (16.5.4) with the corresponding components inherited from the parent type. An ancestor component 4 of a type is the parent component of the type or an ancestor component of the parent component. 5 NOTE 4.58 A component or type parameter declared in an extended type shall not have the same name as any accessible component or type parameter of its parent type. NOTE 4.59 Examples: TYPE POINT ! A base type REAL :: X, Y END TYPE POINT TYPE, EXTENDS(POINT) :: COLOR_POINT ! An extension of TYPE(POINT) ! Components X and Y, and component name POINT, inherited from parent INTEGER :: COLOR END TYPE COLOR_POINT 4.5.7.3 Type-bound procedure overriding 6 If a nongeneric binding specified in a type definition has the same binding name as a binding from the 7 parent type then the binding specified in the type definition overrides the one from the parent type. 8 The overriding binding and the overridden binding shall satisfy the following conditions. 9 (1) Either both shall have a passed-object dummy argument or neither shall. 10 (2) If the overridden binding is pure then the overriding binding shall also be pure. 11 (3) Either both shall be elemental or neither shall. 12 (4) They shall have the same number of dummy arguments. 13 (5) Passed-object dummy arguments, if any, shall correspond by name and position. 14 (6) Dummy arguments that correspond by position shall have the same names and characteris- 15 tics, except for the type of the passed-object dummy arguments. 16 (7) Either both shall be subroutines or both shall be functions having the same result charac- 17 teristics (12.3.3). 18 (8) If the overridden binding is PUBLIC then the overriding binding shall not be PRIVATE. 19 73 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 4.60 The following is an example of procedure overriding, expanding on the example in Note 4.47. TYPE, EXTENDS (POINT) :: POINT_3D REAL :: Z CONTAINS PROCEDURE, PASS :: LENGTH => POINT_3D_LENGTH END TYPE POINT_3D ... and in the module-subprogram-part of the same module: REAL FUNCTION POINT_3D_LENGTH ( A, B ) CLASS (POINT_3D), INTENT (IN) :: A CLASS (POINT), INTENT (IN) :: B SELECT TYPE(B) CLASS IS(POINT_3D) POINT_3D_LENGTH = SQRT( (A%X-B%X)**2 + (A%Y-B%Y)**2 + (A%Z-B%Z)**2 ) RETURN END SELECT PRINT *, 'In POINT_3D_LENGTH, dynamic type of argument is incorrect.' STOP END FUNCTION POINT_3D_LENGTH If a generic binding specified in a type definition has the same generic-spec as an inherited binding, it 1 extends the generic interface and shall satisfy the requirements specified in 12.4.3.3.4. 2 If a generic binding in a type definition has the same dtio-generic-spec as one inherited from the parent, it 3 extends the type-bound generic interface for dtio-generic-spec and shall satisfy the requirements specified 4 in 12.4.3.3.4. 5 A binding of a type and a binding of an extension of that type correspond if the latter binding is the 6 same binding as the former, overrides a corresponding binding, or is an inherited corresponding binding. 7 4.5.8 Derived-type values 8 The component value of 9 (1) a pointer component is its pointer association, 10 (2) an allocatable component is its allocation status and, if it is allocated, its dynamic type and 11 type parameters, bounds and value, and 12 (3) a nonpointer nonallocatable component is its value. 13 The set of values of a particular derived type consists of all possible sequences of the component values 14 of its components. 15 4.5.9 Derived-type specifier 16 A derived-type specifier is used in several contexts to specify a particular derived type and type param- 17 eters. 18 R457 derived-type-spec is type-name [ ( type-param-spec-list ) ] 19 R458 type-param-spec is [ keyword = ] type-param-value 20 C487 (R457) type-name shall be the name of an accessible derived type. 74 2006/09/25 WORKING DRAFT J3/06-007r1 C488 (R457) type-param-spec-list shall appear only if the type is parameterized. 1 C489 (R457) There shall be at most one type-param-spec corresponding to each parameter of the type. 2 If a type parameter does not have a default value, there shall be a type-param-spec corresponding 3 to that type parameter. 4 C490 (R458) The keyword = may be omitted from a type-param-spec only if the keyword = has been 5 omitted from each preceding type-param-spec in the type-param-spec-list. 6 C491 (R458) Each keyword shall be the name of a parameter of the type. 7 C492 (R458) An asterisk may be used as a type-param-value in a type-param-spec only in the decla- 8 ration of a dummy argument or associate name or in the allocation of a dummy argument. 9 Type parameter values that do not have type parameter keywords specified correspond to type param- 10 eters in type parameter order (4.5.3.2). If a type parameter keyword is present, the value is assigned to 11 the type parameter named by the keyword. If necessary, the value is converted according to the rules of 12 intrinsic assignment (7.4.1.3) to a value of the same kind as the type parameter. 13 The value of a type parameter for which no type-param-value has been specified is its default value. 14 4.5.10 Construction of derived-type values 15 A derived-type definition implicitly defines a corresponding structure constructor that allows con- 16 struction of values of that derived type. The type and type parameters of a constructed value are 17 specified by a derived type specifier. 18 R459 structure-constructor is derived-type-spec ( [ component-spec-list ] ) 19 R460 component-spec is [ keyword = ] component-data-source 20 R461 component-data-source is expr 21 or data-target 22 or proc-target 23 C493 (R459) The derived-type-spec shall not specify an abstract type (4.5.7). 24 C494 (R459) At most one component-spec shall be provided for a component. 25 C495 (R459) If a component-spec is provided for an ancestor component, a component-spec shall not 26 be provided for any component that is inheritance associated with a subcomponent of that 27 ancestor component. 28 C496 (R459) A component-spec shall be provided for a nonallocatable component unless it has default 29 initialization or is inheritance associated with a subcomponent of another component for which 30 a component-spec is provided. 31 C497 (R460) The keyword = may be omitted from a component-spec only if the keyword = has been 32 omitted from each preceding component-spec in the constructor. 33 C498 (R460) Each keyword shall be the name of a component of the type. 34 C499 (R459) The type name and all components of the type for which a component-spec appears shall 35 be accessible in the scoping unit containing the structure constructor. 36 C4100 (R459) If derived-type-spec is a type name that is the same as a generic name, the component- 37 spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a 38 generic reference to that name (12.5.5.2). 39 C4101 (R461) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall 40 75 J3/06-007r1 WORKING DRAFT 2006/09/25 correspond to a procedure pointer component. 1 C4102 (R461) A data-target shall have the same rank as its corresponding component. 2 NOTE 4.61 The form 'name(...)' is interpreted as a generic function-reference if possible; it is interpreted as a structure-constructor only if it cannot be interpreted as a generic function-reference. In the absence of a component keyword, each component-data-source is assigned to the corresponding 3 component in component order (4.5.4.6). If a component keyword appears, the expr is assigned to the 4 component named by the keyword. For a nonpointer component, the declared type and type parameters 5 of the component and expr shall conform in the same way as for a variable and expr in an intrinsic 6 assignment statement (7.4.1.2), as specified in Table 7.11. If necessary, each value of intrinsic type is 7 converted according to the rules of intrinsic assignment (7.4.1.3) to a value that agrees in type and type 8 parameters with the corresponding component of the derived type. For a nonpointer nonallocatable 9 component, the shape of the expression shall conform with the shape of the component. 10 If a component with default initialization has no corresponding component-data-source, then the default 11 initialization is applied to that component. If an allocatable component has no corresponding component- 12 data-source, then that component has an allocation status of unallocated. 13 NOTE 4.62 Because no parent components appear in the defined component ordering, a value for a parent component can be specified only with a component keyword. Examples of equivalent values using types defined in Note 4.59: ! Create values with components x = 1.0, y = 2.0, color = 3. TYPE(POINT) :: PV = POINT(1.0, 2.0) ! Assume components of TYPE(POINT) ! are accessible here. ... COLOR_POINT( point=point(1,2), color=3) ! Value for parent component COLOR_POINT( point=PV, color=3) ! Available even if TYPE(point) ! has private components COLOR_POINT( 1, 2, 3) ! All components of TYPE(point) ! need to be accessible. A structure constructor shall not appear before the referenced type is defined. 14 NOTE 4.63 This example illustrates a derived-type constant expression using a derived type defined in Note 4.21: PERSON (21, 'JOHN SMITH') This could also be written as PERSON (NAME = 'JOHN SMITH', AGE = 21) NOTE 4.64 An example constructor using the derived type GENERAL POINT defined in Note 4.28 is general_point(dim=3) ( (/ 1., 2., 3. /) ) 76 2006/09/25 WORKING DRAFT J3/06-007r1 For a pointer component, the corresponding component-data-source shall be an allowable data-target or 1 proc-target for such a pointer in a pointer assignment statement (7.4.2). If the component data source is 2 a pointer, the association of the component is that of the pointer; otherwise, the component is pointer 3 associated with the component data source. 4 NOTE 4.65 For example, if the variable TEXT were declared (5.2) to be CHARACTER, DIMENSION (1:400), TARGET :: TEXT and BIBLIO were declared using the derived-type definition REFERENCE in Note 4.35 TYPE (REFERENCE) :: BIBLIO the statement BIBLIO = REFERENCE (1, 1987, 1, "This is the title of the referenced & &paper", TEXT) is valid and associates the pointer component SYNOPSIS of the object BIBLIO with the target object TEXT. If a component of a derived type is allocatable, the corresponding constructor expression shall either be 5 a reference to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, 6 or shall evaluate to an entity of the same rank. If the expression is a reference to the intrinsic function 7 NULL, the corresponding component of the constructor has a status of unallocated. If the expression 8 is an allocatable entity, the corresponding component of the constructor has the same allocation status 9 as that allocatable entity and, if it is allocated, the same dynamic type, bounds, and value; if a length 10 parameter of the component is deferred, its value is the same as the corresponding parameter of the 11 expression. Otherwise the corresponding component of the constructor has an allocation status of 12 allocated and has the same bounds and value as the expression. 13 NOTE 4.66 When the constructor is an actual argument, the allocation status of the allocatable component is available through the associated dummy argument. 4.5.11 Derived-type operations and assignment 14 Intrinsic assignment of derived-type entities is described in 7.4.1. This part of ISO/IEC 1539 does 15 not specify any intrinsic operations on derived-type entities. Any operation on derived-type entities 16 or defined assignment (7.4.1.4) for derived-type entities shall be defined explicitly by a function or a 17 subroutine, and a generic interface (4.5.2, 12.4.3.2). 18 4.6 Enumerations and enumerators 19 An enumeration is a set of enumerators. An enumerator is a named integer constant. An enumeration 20 definition specifies the enumeration and its set of enumerators of the corresponding integer kind. 21 R462 enum-def is enum-def-stmt 22 enumerator-def-stmt 23 [ enumerator-def-stmt ] ... 24 end-enum-stmt 25 77 J3/06-007r1 WORKING DRAFT 2006/09/25 R463 enum-def-stmt is ENUM, BIND(C) 1 R464 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator -list 2 R465 enumerator is named-constant [ = scalar-int-initialization-expr ] 3 R466 end-enum-stmt is END ENUM 4 C4103 (R464) If = appears in an enumerator , a double-colon separator shall appear before the enu- 5 merator -list. 6 For an enumeration, the kind is selected such that an integer type with that kind is interoperable (15.3.2) 7 with the corresponding C enumeration type. The corresponding C enumeration type is the type that 8 would be declared by a C enumeration specifier (6.7.2.2 of the C International Standard) that specified 9 C enumeration constants with the same values as those specified by the enum-def , in the same order as 10 specified by the enum-def . 11 The companion processor (2.5.10) shall be one that uses the same representation for the types declared 12 by all C enumeration specifiers that specify the same values in the same order. 13 NOTE 4.67 If a companion processor uses an unsigned type to represent a given enumeration type, the Fortran processor will use the signed integer type of the same width for the enumeration, even though some of the values of the enumerators cannot be represented in this signed integer type. The values of any such enumerators will be interoperable with the values declared in the C enumeration. NOTE 4.68 The C International Standard guarantees the enumeration constants fit in a C int (6.7.2.2 of the C International Standard). Therefore, the Fortran processor can evaluate all enumerator values using the integer type with kind parameter C INT, and then determine the kind parameter of the integer type that is interoperable with the corresponding C enumerated type. NOTE 4.69 The C International Standard specifies that two enumeration types are compatible only if they specify enumeration constants with the same names and same values in the same order. This part of ISO/IEC 1539 further requires that a C processor that is to be a companion processor of a Fortran processor use the same representation for two enumeration types if they both specify enumeration constants with the same values in the same order, even if the names are different. An enumerator is treated as if it were explicitly declared with the PARAMETER attribute. The enu- 14 merator is defined in accordance with the rules of intrinsic assignment (7.4) with the value determined 15 as follows. 16 (1) If scalar-int-initialization-expr is specified, the value of the enumerator is the result of 17 scalar-int-initialization-expr . 18 (2) If scalar-int-initialization-expr is not specified and the enumerator is the first enumerator 19 in enum-def , the enumerator has the value 0. 20 (3) If scalar-int-initialization-expr is not specified and the enumerator is not the first enumer- 21 ator in enum-def , its value is the result of adding 1 to the value of the enumerator that 22 immediately precedes it in the enum-def . 23 NOTE 4.70 Example of an enumeration definition: ENUM, BIND(C) ENUMERATOR :: RED = 4, BLUE = 9 78 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.70 (cont.) ENUMERATOR YELLOW END ENUM The kind type parameter for this enumeration is processor dependent, but the processor is required to select a kind sufficient to represent the values 4, 9, and 10, which are the values of its enumerators. The following declaration might be equivalent to the above enumeration definition. INTEGER(SELECTED_INT_KIND(2)), PARAMETER :: RED = 4, BLUE = 9, YELLOW = 10 An entity of the same kind type parameter value can be declared using the intrinsic function KIND with one of the enumerators as its argument, for example INTEGER(KIND(RED)) :: X NOTE 4.71 There is no difference in the effect of declaring the enumerators in multiple ENUMERATOR statements or in a single ENUMERATOR statement. The order in which the enumerators in an enumeration definition are declared is significant, but the number of ENUMERATOR statements is not. 4.7 Construction of array values 1 An array constructor is defined as a sequence of scalar values and is interpreted as a rank-one array 2 where the element values are those specified in the sequence. 3 R467 array-constructor is (/ ac-spec /) 4 or lbracket ac-spec rbracket 5 R468 ac-spec is type-spec :: 6 or [type-spec ::] ac-value-list 7 R469 lbracket is [ 8 R470 rbracket is ] 9 R471 ac-value is expr 10 or ac-implied-do 11 R472 ac-implied-do is ( ac-value-list , ac-implied-do-control ) 12 R473 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr 13 [ , scalar-int-expr ] 14 R474 ac-do-variable is do-variable 15 C4104 (R468) If type-spec is omitted, each ac-value expression in the array-constructor shall have the 16 same type and kind type parameters. 17 C4105 (R468) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor 18 shall be of an intrinsic type that is in type conformance with a variable of type type-spec as 19 specified in Table 7.11. 20 C4106 (R468) If type-spec specifies a derived type, all ac-value expressions in the array-constructor 21 shall be of that derived type and shall have the same kind type parameter values as specified by 22 type-spec. 23 C4107 (R472) The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear 24 as the ac-do-variable of the containing ac-implied-do. 25 79 J3/06-007r1 WORKING DRAFT 2006/09/25 If type-spec is omitted, each ac-value expression in the array constructor shall have the same length type 1 parameters; in this case, the type and type parameters of the array constructor are those of the ac-value 2 expressions. 3 If type-spec appears, it specifies the type and type parameters of the array constructor. Each ac-value 4 expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this 5 type and type parameters. Each value is converted to the type parameters of the array-constructor in 6 accordance with the rules of intrinsic assignment (7.4.1.3). 7 The character length of an ac-value in an ac-implied-do whose iteration count is zero shall not depend 8 on the value of the ac-do-variable and shall not depend on the value of an expression that is not an 9 initialization expression. 10 If an ac-value is a scalar expression, its value specifies an element of the array constructor. If an ac- 11 value is an array expression, the values of the elements of the expression, in array element order (6.2.2.2), 12 specify the corresponding sequence of elements of the array constructor. If an ac-value is an ac-implied- 13 do, it is expanded to form a sequence of elements under the control of the ac-do-variable, as in the DO 14 construct (8.1.7.5). 15 For an ac-implied-do, the loop initialization and execution is the same as for a DO construct. 16 An empty sequence forms a zero-sized rank-one array. 17 NOTE 4.72 A one-dimensional array may be reshaped into any allowable array shape using the RESHAPE intrinsic function (13.7.146). An example is: X = (/ 3.2, 4.01, 6.5 /) Y = RESHAPE (SOURCE = [ 2.0, [ 4.5, 4.5 ], X ], SHAPE = [ 3, 2 ]) This results in Y having the 3 × 2 array of values: 2.0 3.2 4.5 4.01 4.5 6.5 NOTE 4.73 Examples of array constructors containing an implied DO are: (/ (I, I = 1, 1075) /) and [ 3.6, (3.6 / I, I = 1, N) ] NOTE 4.74 Using the type definition for PERSON in Note 4.21, an example of the construction of a derived- type array value is: (/ PERSON (40, 'SMITH'), PERSON (20, 'JONES') /) 80 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 4.75 Using the type definition for LINE in Note 4.32, an example of the construction of a derived-type scalar value with a rank-2 array component is: LINE (RESHAPE ( (/ 0.0, 0.0, 1.0, 2.0 /), (/ 2, 2 /) ), 0.1, 1) The RESHAPE intrinsic function is used to construct a value that represents a solid line from (0, 0) to (1, 2) of width 0.1 centimeters. NOTE 4.76 Examples of zero-size array constructors are: (/ INTEGER :: /) (/ ( I, I = 1, 0) /) NOTE 4.77 An example of an array constructor that specifies a length type parameter: (/ CHARACTER(LEN=7) :: 'Takata', 'Tanaka', 'Hayashi' /) In this constructor, without the type specification, it would have been necessary to specify all of the constants with the same character length. 81 J3/06-007r1 WORKING DRAFT 2006/09/25 82 2006/09/25 WORKING DRAFT J3/06-007r1 5 Attribute declarations and specifications 1 5.1 General 2 Every data object has a type and rank and may have type parameters and other attributes that determine 3 the uses of the object. Collectively, these properties are the attribute of the object. The type of a 4 named data object is either specified explicitly in a type declaration statement or determined implicitly 5 by the first letter of its name (5.5). All of its attributes may be specified in a type declaration statement 6 or individually in separate specification statements. 7 A function has a type and rank and may have type parameters and other attributes that determine the 8 uses of the function. The type, rank, and type parameters are the same as those of its result variable. 9 A subroutine does not have a type, rank, or type parameters, but may have other attributes that 10 determine the uses of the subroutine. 11 5.2 Type declaration statements 12 5.2.1 Syntax 13 R501 type-declaration-stmt is declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl -list 14 The type declaration statement specifies the type of the entities in the entity declaration list. The type 15 and type parameters are those specified by declaration-type-spec, except that the character length type 16 parameter may be overridden for an entity by the appearance of * char-length in its entity-decl . 17 R502 attr-spec is access-spec 18 or ALLOCATABLE 19 or ASYNCHRONOUS 20 or CONTIGUOUS 21 or dimension-spec 22 or EXTERNAL 23 or INTENT ( intent-spec ) 24 or INTRINSIC 25 or language-binding-spec 26 or OPTIONAL 27 or PARAMETER 28 or POINTER 29 or PROTECTED 30 or SAVE 31 or TARGET 32 or VALUE 33 or VOLATILE 34 35 C501 (R501) The same attr-spec shall not appear more than once in a given type-declaration-stmt. 36 C502 (R501) If a language-binding-spec with a NAME= specifier appears, the entity-decl -list shall 37 consist of a single entity-decl . 38 C503 (R501) If a language-binding-spec is specified, the entity-decl -list shall not contain any procedure 39 83 J3/06-007r1 WORKING DRAFT 2006/09/25 names. 1 The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, 2 except that the DIMENSION attribute may be specified or overridden for an entity by the appearance 3 of array-spec in its entity-decl . 4 R503 entity-decl is object-name [( array-spec )] 5 [ lbracket co-array-spec rbracket ] 6 [ * char-length ] [ initialization ] 7 or function-name [ * char-length ] 8 C504 (R503) If the entity is not of type character, * char-length shall not appear. 9 C505 (R501) If initialization appears, a double-colon separator shall appear before the entity-decl -list. 10 C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, 11 an object in a named common block unless the type declaration is in a block data program unit, 12 an object in blank common, an allocatable variable, an external function, an intrinsic function, 13 or an automatic object. 14 C507 (R503) An initialization shall appear if the entity is a named constant (5.3.12). 15 C508 (R503) The function-name shall be the name of an external function, an intrinsic function, a 16 function dummy procedure, a procedure pointer, or a statement function. 17 R504 object-name is name 18 C509 (R504) The object-name shall be the name of a data object. 19 R505 initialization is = initialization-expr 20 or => null-init 21 or => initial-data-target 22 R506 null-init is function-reference 23 C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = 24 appears in initialization, the entity shall not have the POINTER attribute. 25 C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible 26 with it (4.5.4.5). 27 C512 (R506) The function-reference shall be a reference to the NULL intrinsic function with no 28 arguments. 29 A name that identifies a specific intrinsic function in a scoping unit has a type as specified in 13.6. An 30 explicit type declaration statement is not required; however, it is permitted. Specifying a type for a 31 generic intrinsic function name in a type declaration statement is not sufficient, by itself, to remove the 32 generic properties from that function. 33 5.2.2 Automatic data objects 34 An automatic data object is a nondummy data object with a type parameter or array bound that 35 depends on the value of a specification-expr that is not an initialization expression. 36 C513 An automatic object shall not be a local variable of a main program, module, or submodule. 37 84 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 5.1 An automatic object shall not have the SAVE attribute and shall not appear in a common block. If a type parameter in a declaration-type-spec or in a char-length in an entity-decl is defined by an 1 expression that is not an initialization expression, the type parameter value is established on entry to 2 the procedure and is not affected by any redefinition or undefinition of the variables in the expression 3 during execution of the procedure. 4 5.2.3 Initialization 5 The appearance of initialization in an entity-decl for an entity without the PARAMETER attribute 6 specifies that the entity is a variable with explicit initialization. Explicit initialization alternatively 7 may be specified in a DATA statement unless the variable is of a derived type for which default initial- 8 ization is specified. If initialization is =initialization-expr , the variable is initially defined with the value 9 specified by the initialization-expr ; if necessary, the value is converted according to the rules of intrinsic 10 assignment (7.4.1.3) to a value that agrees in type, type parameters, and shape with the variable. A 11 variable, or part of a variable, shall not be explicitly initialized more than once in a program. If the 12 variable is an array, it shall have its shape specified in either the type declaration statement or a previous 13 attribute specification statement in the same scoping unit. 14 If null-init appears, the initial association status of the object is disassociated. If initial-data-target 15 appears, the object is initially associated with the target. 16 Explicit initialization of a variable that is not in a common block implies the SAVE attribute, which 17 may be confirmed by explicit specification. 18 5.2.4 Examples of type declaration statements 19 NOTE 5.2 REAL A (10) LOGICAL, DIMENSION (5, 5) :: MASK1, MASK2 COMPLEX :: CUBE_ROOT = (-0.5, 0.866) INTEGER, PARAMETER :: SHORT = SELECTED_INT_KIND (4) INTEGER (SHORT) K ! Range at least -9999 to 9999. REAL (KIND (0.0D0)) A REAL (KIND = 2) B COMPLEX (KIND = KIND (0.0D0)) :: C CHARACTER (LEN = 10, KIND = 2) A CHARACTER B, C *20 TYPE (PERSON) :: CHAIRMAN TYPE(NODE), POINTER :: HEAD => NULL ( ) TYPE (humongous_matrix (k=8, d=1000)) :: mat (The last line above uses a type definition from Note 4.28.) 5.3 Attributes 20 5.3.1 Constraints 21 An attribute may be explicitly specified by an attr-spec in a type declaration statement or by an attribute 22 specification statement (5.4). The following constraints apply to attributes. 85 J3/06-007r1 WORKING DRAFT 2006/09/25 1 C514 An entity shall not be explicitly given any attribute more than once in a scoping unit. 2 C515 An array-spec for a function result that does not have the ALLOCATABLE or POINTER 3 attribute shall be an explicit-shape-spec-list. 4 C516 The ALLOCATABLE, POINTER, or OPTIONAL attribute shall not be specified for a dummy 5 argument of a procedure that has a proc-language-binding-spec. 6 5.3.2 Accessibility attribute 7 The accessibility attribute specifies the accessibility of an entity via a particular identifier. 8 R507 access-spec is PUBLIC 9 or PRIVATE 10 C517 (R507) An access-spec shall appear only in the specification-part of a module. 11 Identifiers that are specified in a module or accessible in that module by use association have either 12 the PUBLIC or PRIVATE attribute. Identifiers for which an access-spec is not explicitly specified in 13 that module have the default accessibility attribute for that module. The default accessibility attribute 14 for a module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only identifiers 15 that have the PUBLIC attribute in that module are available to be accessed from that module by use 16 association. 17 NOTE 5.3 In order for an identifier to be accessed by use association, it must have the PUBLIC attribute in the module from which it is accessed. It can nonetheless have the PRIVATE attribute in a module in which it is accessed by use association, and therefore not be available for use association from a module where it is PRIVATE. NOTE 5.4 An example of an accessibility specification is: REAL, PRIVATE :: X, Y, Z 5.3.3 ALLOCATABLE attribute 18 An entity with the ALLOCATABLE attribute is a variable for which space is allocated by an AL- 19 LOCATE statement (6.3.1) or by an intrinsic assignment statement (7.4.1.3). 20 5.3.4 ASYNCHRONOUS attribute 21 An entity with the ASYNCHRONOUS attribute is a variable that may be subject to asynchronous 22 input/output. 23 The base object of a variable shall have the ASYNCHRONOUS attribute in a scoping unit if 24 (1) the variable appears in an executable statement or specification expression in that scoping 25 unit and 26 (2) any statement of the scoping unit is executed while the variable is a pending I/O storage 27 sequence affector (9.5.2.5). 28 Use of a variable in an asynchronous input/output statement can imply the ASYNCHRONOUS attribute; 29 86 2006/09/25 WORKING DRAFT J3/06-007r1 see subclause (9.5.2.5). 1 An object may have the ASYNCHRONOUS attribute in a particular scoping unit without necessarily 2 having it in other scoping units (11.2.2, 16.5.1.4). If an object has the ASYNCHRONOUS attribute, 3 then all of its subobjects also have the ASYNCHRONOUS attribute. 4 NOTE 5.5 The ASYNCHRONOUS attribute specifies the variables that might be associated with a pending input/output storage sequence (the actual memory locations on which asynchronous input/output is being performed) while the scoping unit is in execution. This information could be used by the compiler to disable certain code motion optimizations. The ASYNCHRONOUS attribute is similar to the VOLATILE attribute. It is intended to facilitate traditional code motion optimizations in the presence of asynchronous input/output. 5.3.5 BIND attribute for data entities 5 The BIND attribute for a variable or common block specifies that it is capable of interoperating with a 6 C variable that has external linkage (15.4). 7 R508 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) 8 C518 An entity with the BIND attribute shall be a common block, variable, or procedure. 9 C519 A variable with the BIND attribute shall be declared in the specification part of a module. 10 C520 A variable with the BIND attribute shall be interoperable (15.3). 11 C521 Each variable of a common block with the BIND attribute shall be interoperable. 12 C522 (R508) The scalar-char-initialization-expr shall be of default character kind. If the value of the 13 scalar-char-initialization-expr after discarding leading and trailing blanks has nonzero length, 14 it shall be valid as an identifier on the companion processor. 15 NOTE 5.6 The C International Standard provides a facility for creating C identifiers whose characters are not restricted to the C basic character set. Such a C identifier is referred to as a universal character name (6.4.3 of the C International Standard). The name of such a C identifier might include characters that are not part of the representation method used by the processor for type default character. If so, the C entity cannot be referenced from Fortran. The BIND attribute for a variable or common block implies the SAVE attribute, which may be confirmed 16 by explicit specification. 17 5.3.6 CONTIGUOUS attribute 18 C523 An entity that has the CONTIGUOUS attribute shall be an array pointer or an assumed-shape 19 array. 20 The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated 21 with a contiguous object, or that an array pointer can only be pointer associated with a contiguous target. 22 An object is contiguous if it is 23 (1) an object with the CONTIGUOUS attribute, 24 (2) a scalar object, 25 87 J3/06-007r1 WORKING DRAFT 2006/09/25 (3) a nonpointer whole array that is not assumed-shape, 1 (4) an array allocated by an ALLOCATE statement, 2 (5) an assumed-shape array that is argument associated with an array that is contiguous, 3 (6) a pointer associated with a contiguous target, 4 (7) an array with at most one element, or 5 (8) a nonzero-sized array section (6.2.2) with the following properties: 6 (a) Its base object is contiguous. 7 (b) It does not have a vector subscript. 8 (c) The elements of the section, in array element order, are a subset of the base object 9 elements that are consecutive in array element order. 10 (d) If the array is of type character and a substring-range appears, the substring-range 11 specifies all of the characters of the parent-string (6.1.1). 12 (e) Only its final part-ref has nonzero rank. 13 (f) It is not the real or imaginary part (6.1.3) of an array of type complex. 14 J3 internal note Unresolved Technical Issue 011 The above list (CONTIGUOUS definition) does not conform to the ISO guidelines. An object is not contiguous if it is an array subobject, and 15 (1) the object has two or more elements, 16 (2) the elements of the object in array element order are not consecutive in the elements of the 17 base object, 18 (3) the object is not of type character with length zero, and 19 (4) the object is not of a derived type that has no ultimate components other than zero-sized 20 arrays and characters with length zero. 21 It is processor-dependent whether any other object is contiguous. 22 NOTE 5.7 If a derived type has only one component that is not zero-sized, it is processor-dependent whether a structure component of a contiguous array of that type is contiguous. That is, the derived type might contain padding on some processors. NOTE 5.8 The CONTIGUOUS attribute allows a processor to enable optimizations that depend on the memory layout of the object occupying a contiguous block of memory. Examples of CONTIGUOUS attribute specifications are: REAL, POINTER, CONTIGUOUS :: SPTR(:) REAL, CONTIGUOUS, DIMENSION(:,:) :: D 5.3.7 DIMENSION attribute 23 5.3.7.1 General 24 The DIMENSION attribute specifies that an entity is an array, a co-array, or both. If an array-spec 25 appears, it is an array. If a co-array-spec appears, it is a co-array. 26 For an array, its array-spec specifies its rank or rank and shape. For a co-array, its co-array-spec specifies 27 88 2006/09/25 WORKING DRAFT J3/06-007r1 its co-rank or co-rank and co-bounds. 1 NOTE 5.9 Unless it is a dummy argument, a co-array has the same bounds and co-bounds on every image. See Note 12.31 for further discussion of the bounds and co-bounds of dummy co-arrays. R509 dimension-spec is DIMENSION ( array-spec ) 2 or DIMENSION [ ( array-spec ) ] lbracket co-array-spec rbracket 3 C524 (R501) A co-array that has the ALLOCATABLE attribute shall be specified with a co-array-spec 4 that is a deferred-co-shape-spec-list. 5 C525 A co-array shall be a component or a variable that is not a function result. 6 C526 A co-array shall not be of type IMAGE TEAM (13.8.3.7), C PTR, or C FUNPTR (15.3.3). 7 C527 An entity whose type has a co-array ultimate component shall be a nonpointer nonallocatable 8 scalar, shall not be a co-array, and shall not be a function result. 9 NOTE 5.10 A co-array is permitted to be of a derived type with pointer or allocatable components. The target of such a pointer component is always on the same image. An allocatable component of a co-array need be allocated on an image only if it is referenced or defined. C528 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared 10 in the main program, or allocatable. 11 NOTE 5.11 This requirement for the SAVE attribute has the effect that automatic co-arrays are not permitted; for example, the co-array WORK in the following code fragment is not valid. SUBROUTINE SOLVE3(N,A,B) INTEGER :: N REAL :: A(N)[*], B(N) REAL :: WORK(N)[*] ! Not permitted If this were permitted, it would require an implicit synchronization on entry to the procedure. Explicit-shape co-arrays that are declared in a subprogram and are not dummy arguments are required to have the SAVE attribute because otherwise they might be implemented as if they were automatic co-arrays. R510 array-spec is explicit-shape-spec-list 12 or assumed-shape-spec-list 13 or deferred-shape-spec-list 14 or assumed-size-spec 15 or implied-shape-spec-list 16 R511 co-array-spec is deferred-co-shape-spec-list 17 or explicit-co-shape-spec 18 C529 The sum of the rank and co-rank of an entity shall not exceed fifteen. 89 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 5.12 Examples of DIMENSION attribute specifications are: SUBROUTINE EX (N, A, B) REAL, DIMENSION (N, 10) :: W ! Automatic explicit-shape array REAL A (:), B (0:) ! Assumed-shape arrays REAL, POINTER :: D (:, :) ! Array pointer REAL, DIMENSION (:), POINTER :: P ! Array pointer REAL, ALLOCATABLE, DIMENSION (:) :: E ! Allocatable array REAL, PARAMETER :: V(0:*) = [0.1, 1.1] ! Implied-shape array 5.3.7.2 Explicit-shape array 1 An explicit-shape array is a named array that is declared with an explicit-shape-spec-list. This specifies 2 explicit values for the bounds in each dimension of the array. 3 R512 explicit-shape-spec is [ lower-bound : ] upper-bound 4 R513 lower-bound is specification-expr 5 R514 upper-bound is specification-expr 6 C530 (R512) An explicit-shape-spec whose bounds are not initialization expressions shall appear only 7 in a subprogram or interface body. 8 An explicit-shape array that is a local variable of a subprogram or BLOCK construct may have bounds 9 that are not initialization expressions. The bounds, and hence shape, are determined at entry to a 10 procedure defined by the subprogram, or on execution of the BLOCK statement, by evaluating the 11 bounds expressions. The bounds of such an array are unaffected by the redefinition or undefinition of 12 any variable during execution of the procedure or BLOCK construct. 13 The values of each lower-bound and upper-bound determine the bounds of the array along a particular 14 dimension and hence the extent of the array in that dimension. The value of a lower bound or an upper 15 bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set 16 of integer values between and including the lower and upper bounds, provided the upper bound is not 17 less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the 18 extent in that dimension is zero, and the array is of zero size. If the lower-bound is omitted, the default 19 value is 1. The rank is equal to the number of explicit-shape-specs. 20 5.3.7.3 Assumed-shape array 21 An assumed-shape array is a nonallocatable nonpointer dummy argument array that takes its shape 22 from the associated actual argument array. 23 R515 assumed-shape-spec is [ lower-bound ] : 24 The rank is equal to the number of colons in the assumed-shape-spec-list. 25 The extent of a dimension of an assumed-shape array dummy argument is the extent of the corresponding 26 dimension of the associated actual argument array. If the lower bound value is d and the extent of the 27 corresponding dimension of the associated actual argument array is s, then the value of the upper bound 28 is s + d - 1. If lower-bound appears it specifies the lower bound; otherwise the lower bound is 1. 29 5.3.7.4 Deferred-shape array 30 A deferred-shape array is an allocatable array or an array pointer. 31 90 2006/09/25 WORKING DRAFT J3/06-007r1 An allocatable array is an array that has the ALLOCATABLE attribute and a specified rank, but its 1 bounds, and hence shape, are determined by allocation or argument association. 2 An array pointer is an array with the POINTER attribute and a specified rank. Its bounds, and hence 3 shape, are determined when it is associated with a target. 4 R516 deferred-shape-spec is : 5 C531 An array that has the POINTER or ALLOCATABLE attribute shall have an array-spec that is 6 a deferred-shape-spec-list. 7 The rank is equal to the number of colons in the deferred-shape-spec-list. 8 The size, bounds, and shape of an unallocated allocatable array or a disassociated array pointer are 9 undefined. No part of such an array shall be referenced or defined; however, the array may appear as an 10 argument to an intrinsic inquiry function as specified in 13.1. 11 The bounds of each dimension of an allocated allocatable array are those specified when the array is 12 allocated. 13 The bounds of each dimension of an associated array pointer may be specified in two ways: 14 (1) in an ALLOCATE statement (6.3.1) when the target is allocated; 15 (2) by pointer assignment (7.4.2). 16 The bounds of the array pointer or allocatable array are unaffected by any subsequent redefinition or 17 undefinition of variables on which the bounds' expressions depend. 18 5.3.7.5 Assumed-size array 19 An assumed-size array is a dummy argument array whose size is assumed from that of an associated 20 actual argument. The rank and extents may differ for the actual and dummy arrays; only the size of the 21 actual array is assumed by the dummy array. An assumed-size array is declared with an assumed-size- 22 spec. 23 R517 assumed-size-spec is [ explicit-shape-spec , ]... [ lower-bound : ] * 24 C532 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy 25 data argument. 26 C533 An assumed-size array with INTENT (OUT) shall not be polymorphic, of a finalizable type, of 27 a type with an ultimate allocatable component, or of a type for which default initialization is 28 specified. 29 The size of an assumed-size array is determined as follows. 30 (1) If the actual argument associated with the assumed-size dummy array is an array of any 31 type other than default character, the size is that of the actual array. 32 (2) If the actual argument associated with the assumed-size dummy array is an array element 33 of any type other than default character with a subscript order value of r (6.2.2.2) in an 34 array of size x, the size of the dummy array is x - r + 1. 35 (3) If the actual argument is a default character array, default character array element, or a 36 default character array element substring (6.1.1), and if it begins at character storage unit t 37 of an array with c character storage units, the size of the dummy array is MAX (INT ((c - 38 t + 1)/e), 0), where e is the length of an element in the dummy character array. 39 (4) If the actual argument is of type default character and is a scalar that is not an array element 40 or array element substring designator, the size of the dummy array is MAX (INT (l/e), 0), 41 91 J3/06-007r1 WORKING DRAFT 2006/09/25 where e is the length of an element in the dummy character array and l is the length of the 1 actual argument. 2 The rank is equal to one plus the number of explicit-shape-specs. 3 An assumed-size array has no upper bound in its last dimension and therefore has no extent in its last 4 dimension and no shape. An assumed-size array name shall not be written as a whole array reference 5 except as an actual argument in a procedure reference for which the shape is not required. 6 If a list of explicit-shape-specs appears, it specifies the bounds of the first rank -1 dimensions. If lower- 7 bound appears it specifies the lower bound of the last dimension; otherwise that lower bound is 1. An 8 assumed-size array may be subscripted or sectioned (6.2.2.3). The upper bound shall not be omitted 9 from a subscript triplet in the last dimension. 10 If an assumed-size array has bounds that are not initialization expressions, the bounds are determined 11 at entry to the procedure. The bounds of such an array are unaffected by the redefinition or undefinition 12 of any variable during execution of the procedure. 13 5.3.7.6 Implied-shape array 14 An implied-shape array is a named constant that takes its shape from the initialization-expr in its 15 declaration. An implied-shape array is declared with an implied-shape-spec-list. 16 R518 implied-shape-spec is [ lower-bound : ] * 17 C534 An implied-shape array shall be a named constant. 18 The rank of an implied-shape array is the number of implied-shape-specs in the implied-shape-spec-list. 19 The extent of each dimension of an implied-shape array is the same as the extent of the corresponding 20 dimension of the initialization-expr . The lower bound of each dimension is lower-bound , if it appears, 21 and 1 otherwise; the upper bound is one less than the sum of the lower bound and the extent. 22 5.3.8 EXTERNAL attribute 23 The EXTERNAL attribute specifies that an entity is an external procedure, dummy procedure, 24 procedure pointer, or block data subprogram. 25 C535 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. 26 In an external subprogram, the EXTERNAL attribute shall not be specified for a procedure defined by 27 the subprogram. 28 If an external procedure or dummy procedure is used as an actual argument or is the target of a procedure 29 pointer assignment, it shall be declared to have the EXTERNAL attribute. 30 A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer. 31 5.3.8.1 Allocatable co-array 32 A co-array that has the ALLOCATABLE attribute has a specified co-rank, but its co-bounds are 33 determined by allocation or argument association. 34 R519 deferred-co-shape-spec is : 35 C536 A co-array that has the ALLOCATABLE attribute shall have a co-array-spec that is a deferred- 36 co-shape-spec-list. 37 92 2006/09/25 WORKING DRAFT J3/06-007r1 The co-rank of an allocatable co-array is equal to the number of colons in its deferred-co-shape-spec-list. 1 The co-bounds of an unallocated allocatable co-array are undefined. No part of such a co-array shall be 2 referenced or defined; however, the co-array may appear as an argument to an intrinsic inquiry function 3 as specified in 13.1. 4 The co-bounds of an allocated allocatable co-array are those specified when the co-array is allocated. 5 The co-bounds of an allocatable co-array are unaffected by any subsequent redefinition or undefinition 6 of the variables on which the bounds' expressions depend. 7 5.3.8.2 Explicit-co-shape co-array 8 An explicit-co-shape co-array is a named co-array that has its co-rank and co-bounds declared by 9 an explicit-co-shape-spec. 10 R520 explicit-co-shape-spec is [ [ lower-co-bound : ] upper-co-bound , ]... [ lower-co-bound : ] * 11 12 C537 A co-array that does not have the ALLOCATABLE attribute shall have a co-array-spec that is 13 an explicit-co-shape-spec. 14 The co-rank is equal to one plus the number of upper-co-bound s. 15 R521 lower-co-bound is specification-expr 16 R522 upper-co-bound is specification-expr 17 C538 (R520) A lower-co-bound or upper-co-bound that is not an initialization expression shall appear 18 only in a subprogram or interface body. 19 If an explicit-co-shape co-array has co-bounds that are not initialization expressions, the co-bounds are 20 determined at entry to the procedure by evaluating the co-bounds expressions. The co-bounds of such 21 a co-array are unaffected by the redefinition or undefinition of any variable during execution of the 22 procedure. 23 The values of each lower-co-bound and upper-co-bound determine the co-bounds of the array along a 24 particular co-dimension. The subscript range of the array in that co-dimension is the set of integer values 25 between and including the lower and upper co-bounds. If the lower co-bound is omitted, the default 26 value is 1. The upper co-bound shall not be less than the lower co-bound. 27 5.3.9 INTENT attribute 28 The INTENT attribute specifies the intended use of a dummy argument. An INTENT (IN) dummy 29 argument is suitable for receiving data from the invoking scoping unit, an INTENT (OUT) dummy 30 argument is suitable for returning data to the invoking scoping unit, and an INTENT (INOUT) dummy 31 argument is suitable for use both to receive data from and to return data to the invoking scoping unit. 32 R523 intent-spec is IN 33 or OUT 34 or INOUT 35 C539 An entity with the INTENT attribute shall be a dummy data object or a dummy procedure 36 pointer. 37 C540 (R523) A nonpointer object with the INTENT (IN) attribute shall not appear in a variable 38 definition context (16.6.7). 39 93 J3/06-007r1 WORKING DRAFT 2006/09/25 C541 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context 1 (16.6.8). 2 The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be de- 3 fined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a 4 pointer dummy argument specifies that during the execution of the procedure its association shall not 5 be changed except that it may become undefined if the target is deallocated other than through the 6 pointer (16.5.2.2.3). 7 The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument 8 becomes undefined on invocation of the procedure, except for any subcomponents that are default- 9 initialized (4.5.4.5). Any actual argument that becomes associated with such a dummy argument shall 10 be definable. The INTENT (OUT) attribute for a pointer dummy argument specifies that on invocation 11 of the procedure the pointer association status of the dummy argument becomes undefined. Any actual 12 argument associated with such a pointer dummy shall be a pointer variable. 13 NOTE 5.13 If the actual argument is finalizable it will be finalized before undefinition and default initialization of the dummy argument (4.5.6). The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument 14 associated with the dummy argument shall be definable. The INTENT (INOUT) attribute for a pointer 15 dummy argument specifies that any actual argument associated with the dummy argument shall be a 16 pointer variable. 17 NOTE 5.14 The INTENT attribute for an allocatable dummy argument applies to both the allocation status and the definition status. An actual argument associated with an INTENT(OUT) allocatable dummy argument is deallocated on procedure invocation (6.3.3.1). If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the 18 argument associated entity (12.5.2). 19 NOTE 5.15 An example of INTENT specification is: SUBROUTINE MOVE (FROM, TO) USE PERSON_MODULE TYPE (PERSON), INTENT (IN) :: FROM TYPE (PERSON), INTENT (OUT) :: TO If an object has an INTENT attribute, then all of its subobjects have the same INTENT attribute. 20 NOTE 5.16 If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subobjects of the dummy object apply to the pointer in contexts where it is used as a pointer, but not in contexts where it is dereferenced to indicate its target. For example, if X is a dummy argument of derived type with an integer pointer component P, and X has INTENT(IN), then the statement X%P => NEW_TARGET 94 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 5.16 (cont.) is prohibited, but X%P = 0 is allowed (provided that X%P is associated with a definable target). Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target. NOTE 5.17 Argument intent specifications serve several purposes in addition to documenting the intended use of dummy arguments. A processor can check whether an INTENT (IN) dummy argument is used in a way that could redefine it. A slightly more sophisticated processor could check to see whether an INTENT (OUT) dummy argument could possibly be referenced before it is defined. If the procedure's interface is explicit, the processor can also verify that actual arguments corresponding to INTENT (OUT) or INTENT (INOUT) dummy arguments are definable. A more sophisticated processor could use this information to optimize the translation of the referencing scoping unit by taking advantage of the fact that actual arguments corresponding to INTENT (IN) dummy arguments will not be changed and that any prior value of an actual argument corresponding to an INTENT (OUT) dummy argument will not be referenced and could thus be discarded. INTENT (OUT) means that the value of the argument after invoking the procedure is entirely the result of executing that procedure. If an argument should retain its current value rather than being redefined, INTENT (INOUT) should be used rather than INTENT (OUT), even if there is no explicit reference to the value of the dummy argument. Because an INTENT(OUT) variable is considered undefined on entry to the procedure, any default initialization specified for its type will be applied. INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The actual argument corresponding to an INTENT (INOUT) dummy argument is always required to be definable, while an argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. 5.3.10 INTRINSIC attribute 1 The INTRINSIC attribute specifies that the entity is an intrinsic procedure. It may be a generic 2 procedure (13.5), a specific procedure (13.6), or both. 3 If the specific name of an intrinsic procedure (13.6) is used as an actual argument, the name shall be 4 explicitly specified to have the INTRINSIC attribute. An intrinsic procedure whose specific name is 5 marked with a bullet (·) in 13.6 shall not be used as an actual argument. 6 C542 If the name of a generic intrinsic procedure is explicitly declared to have the INTRINSIC at- 7 tribute, and it is also the generic name of one or more generic interfaces (12.4.3.2) accessible in 8 the same scoping unit, the procedures in the interfaces and the specific intrinsic procedures shall 9 all be functions or all be subroutines, and the characteristics of the specific intrinsic procedures 10 and the procedures in the interfaces shall differ as specified in 12.4.3.3.4. 11 5.3.11 OPTIONAL attribute 12 The OPTIONAL attribute specifies that the dummy argument need not be associated with an actual 13 argument in a reference to the procedure (12.5.2.13). The PRESENT intrinsic function can be used to 14 95 J3/06-007r1 WORKING DRAFT 2006/09/25 determine whether an optional dummy argument is associated with an actual argument. 1 C543 An entity with the OPTIONAL attribute shall be a dummy argument. 2 5.3.12 PARAMETER attribute 3 The PARAMETER attribute specifies that an entity is a named constant. The entity has the value 4 specified by its initialization-expr , converted, if necessary, to the type, type parameters and shape of the 5 entity. 6 C544 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. 7 A named constant shall not be referenced unless it has been defined previously in the same statement, 8 defined in a prior statement, or made accessible by use or host association. 9 NOTE 5.18 Examples of declarations with a PARAMETER attribute are: REAL, PARAMETER :: ONE = 1.0, Y = 4.1 / 3.0 INTEGER, DIMENSION (3), PARAMETER :: ORDER = (/ 1, 2, 3 /) TYPE(NODE), PARAMETER :: DEFAULT = NODE(0, NULL ( )) 5.3.13 POINTER attribute 10 Entities with the POINTER attribute can be associated with different data objects or procedures 11 during execution of a program. A pointer is either a data pointer or a procedure pointer. Procedure 12 pointers are described in 12.4.3.5. 13 C545 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or 14 TARGET attribute. 15 C546 A procedure with the POINTER attribute shall have the EXTERNAL attribute. 16 C547 A co-array shall not have the POINTER attribute. 17 A data pointer shall not be referenced unless it is pointer associated with a target object that is defined. 18 A data pointer shall not be defined unless it is pointer associated with a target object that is definable. 19 If a data pointer is associated, the values of its deferred type parameters are the same as the values of 20 the corresponding type parameters of its target. 21 A procedure pointer shall not be referenced unless it is pointer associated with a target procedure. 22 NOTE 5.19 Examples of POINTER attribute specifications are: TYPE (NODE), POINTER :: CURRENT, TAIL REAL, DIMENSION (:, :), POINTER :: IN, OUT, SWAP For a more elaborate example see C.2.1. 5.3.14 PROTECTED attribute 23 The PROTECTED attribute imposes limitations on the usage of module entities. 24 96 2006/09/25 WORKING DRAFT J3/06-007r1 C548 The PROTECTED attribute shall be specified only in the specification part of a module. 1 C549 An entity with the PROTECTED attribute shall be a procedure pointer or variable. 2 C550 An entity with the PROTECTED attribute shall not be in a common block. 3 C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association 4 shall not appear in a variable definition context (16.6.7) or as the data-target or proc-target in 5 a pointer-assignment-stmt. 6 C552 A pointer that has the PROTECTED attribute and is accessed by use association shall not 7 appear in a pointer association context (16.6.8). 8 Other than within the module in which an entity is given the PROTECTED attribute, or within any of 9 its descendants, 10 (1) if it is a nonpointer object, it is not definable, and 11 (2) if it is a pointer, its association status shall not be changed except that it may become 12 undefined if its target is deallocated other than through the pointer (16.5.2.2.3) or if its 13 target becomes undefined by execution of a RETURN or END statement. 14 If an object has the PROTECTED attribute, all of its subobjects have the PROTECTED attribute. 15 NOTE 5.20 An example of the PROTECTED attribute: MODULE temperature REAL, PROTECTED :: temp_c, temp_f CONTAINS SUBROUTINE set_temperature_c(c) REAL, INTENT(IN) :: c temp_c = c temp_f = temp_c*(9.0/5.0) + 32 END SUBROUTINE END MODULE The PROTECTED attribute ensures that the variables temp_c and temp_f cannot be modified other than via the set_temperature_c procedure, thus keeping them consistent with each other. 5.3.15 SAVE attribute 16 The SAVE attribute specifies that a variable retains its association status, allocation status, definition 17 status, and value after execution of a RETURN or END statement unless it is a pointer and its target 18 becomes undefined (16.5.2.2.3(4)). If it is a local variable of a subprogram it is shared by all instances 19 (12.6.2.3) of the subprogram. 20 Giving a common block the SAVE attribute confers the attribute on all variables in the common block. 21 C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. 22 C554 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic 23 data object, or an object that is in a common block. 24 A saved entity is an entity that has the SAVE attribute. An unsaved entity is an entity that does not 25 have the SAVE attribute. 26 The SAVE attribute has no effect on entities declared in a main program. If a common block has the 27 97 J3/06-007r1 WORKING DRAFT 2006/09/25 SAVE attribute in any scoping unit that is not a main program, it shall have the SAVE attribute in 1 every scoping unit that is not a main program. 2 5.3.16 TARGET attribute 3 The TARGET attribute specifies that a data object may have a pointer associated with it (7.4.2). 4 An object without the TARGET attribute shall not have an accessible pointer associated with it. 5 C555 An entity with the TARGET attribute shall be a variable. 6 C556 An entity with the TARGET attribute shall not have the POINTER attribute. 7 NOTE 5.21 In addition to variables explicitly declared to have the TARGET attribute, the objects created by allocation of pointers (6.3.1.2) have the TARGET attribute. If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET 8 attribute. 9 NOTE 5.22 Examples of TARGET attribute specifications are: TYPE (NODE), TARGET :: HEAD REAL, DIMENSION (1000, 1000), TARGET :: A, B For a more elaborate example see C.2.2. NOTE 5.23 Every object designator that starts from a target object will have either the TARGET or POINTER attribute. If pointers are involved, the designator might not necessarily be a subobject of the original target object, but because pointers may point only to targets, there is no way to end up at a nonpointer that is not a target. 5.3.17 VALUE attribute 10 The VALUE attribute specifies a type of argument association (12.5.2.5) for a dummy argument. 11 C557 An entity with the VALUE attribute shall be a scalar dummy data object. 12 C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), 13 INTENT(OUT), POINTER, or VOLATILE attributes. 14 C559 If an entity has the VALUE attribute, any length type parameter value in its declaration shall 15 be omitted or specified by an initialization expression. 16 5.3.18 VOLATILE attribute 17 The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, 18 by means not specified by the program, or by another image without synchronization. 19 C560 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy 20 argument. 21 An object may have the VOLATILE attribute in a particular scoping unit without necessarily having 22 98 2006/09/25 WORKING DRAFT J3/06-007r1 it in other scoping units (11.2.2, 16.5.1.4). If an object has the VOLATILE attribute, then all of its 1 subobjects also have the VOLATILE attribute. 2 NOTE 5.24 The Fortran processor should use the most recent definition of a volatile object when a value is required. Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility to manage any interaction with non-Fortran processes. A pointer with the VOLATILE attribute may additionally have its association status, dynamic type and 3 type parameters, and array bounds changed by means not specified by the program. 4 NOTE 5.25 If the target of a pointer is referenced, defined, or becomes undefined, by means not specified by the program, while the pointer is associated with the target, then the pointer shall have the VOLATILE attribute. Usually a pointer should have the VOLATILE attribute if its target has the VOLATILE attribute. Similarly, all members of an EQUIVALENCE group should have the VOLATILE attribute if one member has the VOLATILE attribute. An allocatable object with the VOLATILE attribute may additionally have its allocation status, dynamic 5 type and type parameters, and array bounds changed by means not specified by the program. 6 5.4 Attribute specification statements 7 5.4.1 Accessibility statement 8 R524 access-stmt is access-spec [ [ :: ] access-id -list ] 9 R525 access-id is use-name 10 or generic-spec 11 C561 (R524) An access-stmt shall appear only in the specification-part of a module. Only one ac- 12 cessibility statement with an omitted access-id -list is permitted in the specification-part of a 13 module. 14 C562 (R525) Each use-name shall be the name of a named variable, procedure, derived type, named 15 constant, namelist group, or macro. 16 An access-stmt with an access-id -list specifies the accessibility attribute (5.3.2), PUBLIC or PRIVATE, 17 of each access-id in the list. An access-stmt without an access-id list specifies the default accessibility 18 that applies to all potentially accessible identifiers in the specification-part of the module. The statement 19 PUBLIC 20 specifies a default of public accessibility. The statement 21 PRIVATE 22 specifies a default of private accessibility. If no such statement appears in a module, the default is public 23 accessibility. 24 NOTE 5.26 Examples of accessibility statements are: MODULE EX PRIVATE 99 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 5.26 (cont.) PUBLIC :: A, B, C, ASSIGNMENT (=), OPERATOR (+) 5.4.2 ALLOCATABLE statement 1 R526 allocatable-stmt is ALLOCATABLE [ :: ] allocatable-decl -list 2 R527 allocatable-decl is object-name [ ( array-spec ) ] 3 [ lbracket co-array-spec rbracket ] 4 This statement specifies the ALLOCATABLE attribute (5.3.3) for a list of objects. 5 NOTE 5.27 An example of an ALLOCATABLE statement is: REAL A, B (:), SCALAR ALLOCATABLE :: A (:, :), B, SCALAR 5.4.3 ASYNCHRONOUS statement 6 R528 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name-list 7 The ASYNCHRONOUS statement specifies the ASYNCHRONOUS attribute (5.3.4) for a list of objects. 8 5.4.4 BIND statement 9 R529 bind-stmt is language-binding-spec [ :: ] bind-entity-list 10 R530 bind-entity is entity-name 11 or / common-block-name / 12 C563 (R529) If the language-binding-spec has a NAME= specifier, the bind-entity-list shall consist of 13 a single bind-entity. 14 The BIND statement specifies the BIND attribute (5.3.5) for a list of variables and common blocks. 15 5.4.5 CONTIGUOUS statement 16 R531 contiguous-stmt is CONTIGUOUS [ :: ] object-name-list 17 The CONTIGUOUS statement specifies the CONTIGUOUS attribute (5.3.6) for a list of objects. 18 5.4.6 DATA statement 19 R532 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... 20 This statement specifies explicit initialization (5.2.3). 21 A variable, or part of a variable, shall not be explicitly initialized more than once in a program. If a 22 nonpointer object has been specified with default initialization in a type definition, it shall not appear 23 in a data-stmt-object-list. 24 A variable that appears in a DATA statement and has not been typed previously may appear in a 25 subsequent type declaration only if that declaration confirms the implicit typing. An array name, 26 array section, or array element that appears in a DATA statement shall have had its array properties 27 established by a previous specification statement. 28 100 2006/09/25 WORKING DRAFT J3/06-007r1 Except for variables in named common blocks, a named variable has the SAVE attribute if any part of 1 it is initialized in a DATA statement, and this may be confirmed by explicit specification. 2 R533 data-stmt-set is data-stmt-object-list / data-stmt-value-list / 3 R534 data-stmt-object is variable 4 or data-implied-do 5 R535 data-implied-do is ( data-i-do-object-list , data-i-do-variable = 6 scalar-int-initialization-expr , 7 scalar-int-initialization-expr 8 [ , scalar-int-initialization-expr ] ) 9 R536 data-i-do-object is array-element 10 or scalar-structure-component 11 or data-implied-do 12 R537 data-i-do-variable is do-variable 13 C564 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. 14 C565 (R534) In a variable that is a data-stmt-object, any subscript, section subscript, substring start- 15 ing point, and substring ending point shall be an initialization expression. 16 C566 (R534) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall 17 not be a dummy argument, made accessible by use association or host association, in a named 18 common block unless the DATA statement is in a block data program unit, in a blank common 19 block, a function name, a function result name, an automatic object, or an allocatable variable. 20 C567 (R534) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an object 21 designator in which a pointer appears other than as the entire rightmost part-ref . 22 C568 (R536) The array-element shall be a variable. 23 C569 (R536) The scalar-structure-component shall be a variable. 24 C570 (R536) The scalar-structure-component shall contain at least one part-ref that contains a sub- 25 script-list. 26 C571 (R536) In an array-element or scalar-structure-component that is a data-i-do-object, any sub- 27 script shall be an initialization expression, and any primary within that subscript that is a 28 data-i-do-variable shall be a DO variable of this data-implied-do or of a containing data-implied- 29 do. 30 R538 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant 31 R539 data-stmt-repeat is scalar-int-constant 32 or scalar-int-constant-subobject 33 C572 (R539) The data-stmt-repeat shall be positive or zero. If the data-stmt-repeat is a named con- 34 stant, it shall have been declared previously in the scoping unit or made accessible by use 35 association or host association. 36 R540 data-stmt-constant is scalar-constant 37 or scalar-constant-subobject 38 or signed-int-literal-constant 39 or signed-real-literal-constant 40 or null-init 41 or initial-data-target 42 or structure-constructor 43 C573 (R540) If a DATA statement constant value is a named constant or a structure constructor, the 44 101 J3/06-007r1 WORKING DRAFT 2006/09/25 named constant or derived type shall have been declared previously in the scoping unit or made 1 accessible by use or host association. 2 C574 (R540) If a data-stmt-constant is a structure-constructor , it shall be an initialization expression. 3 R541 int-constant-subobject is constant-subobject 4 C575 (R541) int-constant-subobject shall be of type integer. 5 R542 constant-subobject is designator 6 C576 (R542) constant-subobject shall be a subobject of a constant. 7 C577 (R542) Any subscript, substring starting point, or substring ending point shall be an initializa- 8 tion expression. 9 The data-stmt-object-list is expanded to form a sequence of pointers and scalar variables, referred to 10 as "sequence of variables" in subsequent text. A nonpointer array whose unqualified name appears 11 as a data-stmt-object or data-i-do-object is equivalent to a complete sequence of its array elements in 12 array element order (6.2.2.2). An array section is equivalent to the sequence of its array elements in 13 array element order. A data-implied-do is expanded to form a sequence of array elements and structure 14 components, under the control of the data-i-do-variable, as in the DO construct (8.1.7.5). 15 The data-stmt-value-list is expanded to form a sequence of data-stmt-constants. A data-stmt-repeat 16 indicates the number of times the following data-stmt-constant is to be included in the sequence; omission 17 of a data-stmt-repeat has the effect of a repeat factor of 1. 18 A zero-sized array or a data-implied-do with an iteration count of zero contributes no variables to the 19 expanded sequence of variables, but a zero-length scalar character variable does contribute a variable 20 to the expanded sequence. A data-stmt-constant with a repeat factor of zero contributes no data-stmt- 21 constants to the expanded sequence of scalar data-stmt-constants. 22 The expanded sequences of variables and data-stmt-constants are in one-to-one correspondence. Each 23 data-stmt-constant specifies the initial value, initial data target, or null-init for the corresponding vari- 24 able. The lengths of the two expanded sequences shall be the same. 25 A data-stmt-constant shall be null-init or initial-data-target if and only if the corresponding data-stmt- 26 object has the POINTER attribute. If data-stmt-constant is null-init, the initial association status of 27 the corresponding data statement object is disassociated. If data-stmt-constant is initial-data-target the 28 corresponding data statement object shall be data-pointer-initialization compatible with the initial data 29 target; the data statement object is initially associated with the target. 30 A data-stmt-constant other than null-init or initial-data-target shall be compatible with its corresponding 31 variable according to the rules of intrinsic assignment (7.4.1.2). The variable is initially defined with 32 the value specified by the data-stmt-constant; if necessary, the value is converted according to the rules 33 of intrinsic assignment (7.4.1.3) to a value that agrees in type, type parameters, and shape with the 34 variable. 35 NOTE 5.28 Examples of DATA statements are: CHARACTER (LEN = 10) NAME INTEGER, DIMENSION (0:9) :: MILES REAL, DIMENSION (100, 100) :: SKEW TYPE (NODE), POINTER :: HEAD_OF_LIST TYPE (PERSON) MYNAME, YOURNAME DATA NAME / 'JOHN DOE' /, MILES / 10 * 0 / 102 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 5.28 (cont.) DATA ((SKEW (K, J), J = 1, K), K = 1, 100) / 5050 * 0.0 / DATA ((SKEW (K, J), J = K + 1, 100), K = 1, 99) / 4950 * 1.0 / DATA HEAD_OF_LIST / NULL() / DATA MYNAME / PERSON (21, 'JOHN SMITH') / DATA YOURNAME % AGE, YOURNAME % NAME / 35, 'FRED BROWN' / The character variable NAME is initialized with the value JOHN DOE with padding on the right because the length of the constant is less than the length of the variable. All ten elements of the integer array MILES are initialized to zero. The two-dimensional array SKEW is initialized so that the lower triangle of SKEW is zero and the strict upper triangle is one. The structures MYNAME and YOURNAME are declared using the derived type PERSON from Note 4.21. The pointer HEAD OF LIST is declared using the derived type NODE from Note 4.40; it is initially disassociated. MYNAME is initialized by a structure constructor. YOURNAME is initialized by supplying a separate value for each component. 5.4.7 DIMENSION statement 1 R543 dimension-stmt is DIMENSION [ :: ] dimension-decl -list 2 R544 dimension-decl is array-name ( array-spec ) 3 or co-name [ ( array-spec ) ] lbracket co-array-spec rbracket 4 This statement specifies the DIMENSION attribute (5.3.7) for a list of objects. 5 NOTE 5.29 An example of a DIMENSION statement is: DIMENSION A (10), B (10, 70), C (:) 5.4.8 INTENT statement 6 R545 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name-list 7 This statement specifies the INTENT attribute (5.3.9) for the dummy arguments in the list. 8 NOTE 5.30 An example of an INTENT statement is: SUBROUTINE EX (A, B) INTENT (INOUT) :: A, B 5.4.9 OPTIONAL statement 9 R546 optional-stmt is OPTIONAL [ :: ] dummy-arg-name-list 10 This statement specifies the OPTIONAL attribute (5.3.11) for the dummy arguments in the list. 11 NOTE 5.31 An example of an OPTIONAL statement is: SUBROUTINE EX (A, B) OPTIONAL :: B 103 J3/06-007r1 WORKING DRAFT 2006/09/25 5.4.10 PARAMETER statement 1 The PARAMETER statement specifies the PARAMETER attribute (5.3.12) and the values for the 2 named constants in the list. 3 R547 parameter-stmt is PARAMETER ( named-constant-def -list ) 4 R548 named-constant-def is named-constant = initialization-expr 5 If a named constant is defined by a PARAMETER statement, it shall not be subsequently declared to 6 have a type or type parameter value that differs from the type and type parameters it would have if 7 declared implicitly (5.5). A named array constant defined by a PARAMETER statement shall have its 8 shape specified in a prior specification statement. 9 The value of each named constant is that specified by the corresponding initialization expression; if 10 necessary, the value is converted according to the rules of intrinsic assignment (7.4.1.3) to a value that 11 agrees in type, type parameters, and shape with the named constant. 12 NOTE 5.32 An example of a PARAMETER statement is: PARAMETER (MODULUS = MOD (28, 3), NUMBER_OF_SENATORS = 100) 5.4.11 POINTER statement 13 R549 pointer-stmt is POINTER [ :: ] pointer-decl -list 14 R550 pointer-decl is object-name [ ( deferred-shape-spec-list ) ] 15 or proc-entity-name 16 This statement specifies the POINTER attribute (5.3.13) for a list of entities. 17 NOTE 5.33 An example of a POINTER statement is: TYPE (NODE) :: CURRENT POINTER :: CURRENT, A (:, :) 5.4.12 PROTECTED statement 18 R551 protected-stmt is PROTECTED [ :: ] entity-name-list 19 The PROTECTED statement specifies the PROTECTED attribute (5.3.14) for a list of entities. 20 5.4.13 SAVE statement 21 R552 save-stmt is SAVE [ [ :: ] saved-entity-list ] 22 R553 saved-entity is object-name 23 or proc-pointer-name 24 or / common-block-name / 25 R554 proc-pointer-name is name 26 C578 (R552) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no 27 other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. 28 A SAVE statement with a saved entity list specifies the SAVE attribute (5.3.15) for a list of entities. A 29 104 2006/09/25 WORKING DRAFT J3/06-007r1 SAVE statement without a saved entity list is treated as though it contained the names of all allowed 1 items in the same scoping unit. 2 NOTE 5.34 An example of a SAVE statement is: SAVE A, B, C, / BLOCKA /, D 5.4.14 TARGET statement 3 R555 target-stmt is TARGET [ :: ] target-decl -list 4 R556 target-decl is object-name [ ( array-spec ) ] 5 [ lbracket co-array-spec rbracket ] 6 This statement specifies the TARGET attribute (5.3.16) for a list of objects. 7 NOTE 5.35 An example of a TARGET statement is: TARGET :: A (1000, 1000), B 5.4.15 VALUE statement 8 R557 value-stmt is VALUE [ :: ] dummy-arg-name-list 9 The VALUE statement specifies the VALUE attribute (5.3.17) for a list of dummy arguments. 10 5.4.16 VOLATILE statement 11 R558 volatile-stmt is VOLATILE [ :: ] object-name-list 12 The VOLATILE statement specifies the VOLATILE attribute (5.3.18) for a list of objects. 13 5.5 IMPLICIT statement 14 In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all 15 implicitly typed data entities whose names begin with one of the letters specified in the statement. 16 Alternatively, it may indicate that no implicit typing rules are to apply in a particular scoping unit. 17 R559 implicit-stmt is IMPLICIT implicit-spec-list 18 or IMPLICIT NONE 19 R560 implicit-spec is declaration-type-spec ( letter-spec-list ) 20 R561 letter-spec is letter [ ­ letter ] 21 C579 (R559) If IMPLICIT NONE is specified in a scoping unit, it shall precede any PARAMETER 22 statements that appear in the scoping unit and there shall be no other IMPLICIT statements 23 in the scoping unit. 24 C580 (R561) If the minus and second letter appear, the second letter shall follow the first letter 25 alphabetically. 26 A letter-spec consisting of two letter s separated by a minus is equivalent to writing a list containing all 27 of the letters in alphabetical order in the alphabetic sequence from the first letter through the second 28 105 J3/06-007r1 WORKING DRAFT 2006/09/25 letter. For example, A­C is equivalent to A, B, C. The same letter shall not appear as a single letter, or 1 be included in a range of letters, more than once in all of the IMPLICIT statements in a scoping unit. 2 In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z 3 and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in 4 its letter-spec-list. IMPLICIT NONE specifies the null mapping for all the letters. If a mapping is not 5 specified for a letter, the default for a program unit or an interface body is default integer if the letter 6 is I, J, ..., or N and default real otherwise, and the default for an internal or module procedure is the 7 mapping in the host scoping unit. 8 Any data entity that is not explicitly declared by a type declaration statement, is not an intrinsic 9 function, and is not made accessible by use association or host association is declared implicitly to be of 10 the type (and type parameters) mapped from the first letter of its name, provided the mapping is not 11 null. The mapping for the first letter of the data entity shall either have been established by a prior 12 IMPLICIT statement or be the default mapping for the letter. The mapping may be to a derived type 13 that is inaccessible in the local scope if the derived type is accessible in the host scoping unit. The data 14 entity is treated as if it were declared in an explicit type declaration in the outermost scoping unit in 15 which it appears. An explicit type specification in a FUNCTION statement overrides an IMPLICIT 16 statement for the name of the result variable of that function subprogram. 17 NOTE 5.36 The following are examples of the use of IMPLICIT statements: MODULE EXAMPLE_MODULE IMPLICIT NONE ... INTERFACE FUNCTION FUN (I) ! Not all data entities need to INTEGER FUN ! be declared explicitly END FUNCTION FUN END INTERFACE CONTAINS FUNCTION JFUN (J) ! All data entities need to INTEGER JFUN, J ! be declared explicitly. ... END FUNCTION JFUN END MODULE EXAMPLE_MODULE SUBROUTINE SUB IMPLICIT COMPLEX (C) C = (3.0, 2.0) ! C is implicitly declared COMPLEX ... CONTAINS SUBROUTINE SUB1 IMPLICIT INTEGER (A, C) C = (0.0, 0.0) ! C is host associated and of ! type complex Z = 1.0 ! Z is implicitly declared REAL A=2 ! A is implicitly declared INTEGER CC = 1 ! CC is implicitly declared INTEGER ... END SUBROUTINE SUB1 SUBROUTINE SUB2 Z = 2.0 ! Z is implicitly declared REAL and ! is different from the variable of 106 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 5.36 (cont.) ! the same name in SUB1 ... END SUBROUTINE SUB2 SUBROUTINE SUB3 USE EXAMPLE_MODULE ! Accesses integer function FUN ! by use association Q = FUN (K) ! Q is implicitly declared REAL and ... ! K is implicitly declared INTEGER END SUBROUTINE SUB3 END SUBROUTINE SUB NOTE 5.37 The following is an example of a mapping to a derived type that is inaccessible in the local scope: PROGRAM MAIN IMPLICIT TYPE(BLOB) (A) TYPE BLOB INTEGER :: I END TYPE BLOB TYPE(BLOB) :: B CALL STEVE CONTAINS SUBROUTINE STEVE INTEGER :: BLOB .. AA = B .. END SUBROUTINE STEVE END PROGRAM MAIN In the subroutine STEVE, it is not possible to explicitly declare a variable to be of type BLOB because BLOB has been given a different meaning, but implicit mapping for the letter A still maps to type BLOB, so AA is of type BLOB. 5.6 NAMELIST statement 1 A NAMELIST statement specifies a group of named data objects, which may be referred to by a 2 single name for the purpose of data transfer (9.5, 10.11). 3 R562 namelist-stmt is NAMELIST 4 / namelist-group-name / namelist-group-object-list 5 [ [ , ] / namelist-group-name / 6 namelist-group-object-list ] . . . 7 C581 (R562) The namelist-group-name shall not be a name accessed by use association. 8 R563 namelist-group-object is variable-name 9 C582 (R563) A namelist-group-object shall not be an assumed-size array. 10 C583 (R562) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- 11 name has the PUBLIC attribute. 12 107 J3/06-007r1 WORKING DRAFT 2006/09/25 The order in which the variables are specified in the NAMELIST statement determines the order in 1 which the values appear on output. 2 Any namelist-group-name may occur more than once in the NAMELIST statements in a scoping unit. 3 The namelist-group-object-list following each successive appearance of the same namelist-group-name in 4 a scoping unit is treated as a continuation of the list for that namelist-group-name. 5 A namelist group object may be a member of more than one namelist group. 6 A namelist group object shall either be accessed by use or host association or shall have its type, type 7 parameters, and shape specified by previous specification statements or the procedure heading in the 8 same scoping unit or by the implicit typing rules in effect for the scoping unit. If a namelist group object 9 is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall 10 confirm the implied type and type parameters. 11 NOTE 5.38 An example of a NAMELIST statement is: NAMELIST /NLIST/ A, B, C 5.7 Storage association of data objects 12 5.7.1 EQUIVALENCE statement 13 5.7.1.1 General 14 An EQUIVALENCE statement is used to specify the sharing of storage units by two or more objects 15 in a scoping unit. This causes storage association (16.5.3) of the objects that share the storage units. 16 NOTE 5.39 The co-size of a co-array is not a constant, therefore co-arrays are not allowed in COMMON or EQUIVALENCE. If the equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does 17 not cause type conversion or imply mathematical equivalence. If a scalar and an array are equivalenced, 18 the scalar does not have array properties and the array does not have the properties of a scalar. 19 R564 equivalence-stmt is EQUIVALENCE equivalence-set-list 20 R565 equivalence-set is ( equivalence-object , equivalence-object-list ) 21 R566 equivalence-object is variable-name 22 or array-element 23 or substring 24 C584 (R566) An equivalence-object shall not be a designator with a base object that is a dummy 25 argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ulti- 26 mate component, an object of a nonsequence derived type, an object of a derived type that has 27 a pointer at any level of component selection, an automatic object, a function name, an entry 28 name, a result name, a variable with the BIND attribute, a variable in a common block that 29 has the BIND attribute, or a named constant. 30 C585 (R566) An equivalence-object shall not be a designator that has more than one part-ref . 31 C586 (R566) An equivalence-object shall not be a co-array or a subobject thereof. 32 108 2006/09/25 WORKING DRAFT J3/06-007r1 C587 (R566) An equivalence-object shall not have the TARGET attribute. 1 C588 (R566) Each subscript or substring range expression in an equivalence-object shall be an integer 2 initialization expression (7.1.7). 3 C589 (R565) If an equivalence-object is of type default integer, default real, double precision real, 4 default complex, default logical, default bits, or numeric sequence type, all of the objects in the 5 equivalence set shall be of these types. 6 C590 (R565) If an equivalence-object is of type default character or character sequence type, all of the 7 objects in the equivalence set shall be of these types. 8 C591 (R565) If an equivalence-object is of a sequence derived type that is not a numeric sequence or 9 character sequence type, all of the objects in the equivalence set shall be of the same type with 10 the same type parameter values. 11 C592 (R565) If an equivalence-object is of an intrinsic type other than default integer, default real, 12 double precision real, default complex, default logical, or default character, all of the objects in 13 the equivalence set shall be of the same type with the same kind type parameter value. 14 C593 (R566) If an equivalence-object has the PROTECTED attribute, all of the objects in the equiv- 15 alence set shall have the PROTECTED attribute. 16 C594 (R566) The name of an equivalence-object shall not be a name made accessible by use association. 17 C595 (R566) A substring shall not have length zero. 18 NOTE 5.40 The EQUIVALENCE statement allows the equivalencing of sequence structures and the equiv- alencing of objects of intrinsic type with nondefault type parameters, but there are strict rules regarding the appearance of these objects in an EQUIVALENCE statement. A structure that appears in an EQUIVALENCE statement shall be a sequence structure. If a sequence structure is not of numeric sequence type or of character sequence type, it shall be equivalenced only to objects of the same type with the same type parameter values. A structure of a numeric sequence type shall be equivalenced only to another structure of a numeric sequence type, an object of default integer type, default real type, double precision real type, default complex type, default logical type, or default bits such that components of the structure ultimately become associated only with objects of these types. A structure of a character sequence type shall be equivalenced only to an object of default character type or another structure of a character sequence type. An object of intrinsic type with nondefault kind type parameters shall not be equivalenced to objects of different type or kind type parameters. Further rules on the interaction of EQUIVALENCE statements and default initialization are given in 16.5.3.4. 5.7.1.2 Equivalence association 19 An EQUIVALENCE statement specifies that the storage sequences (16.5.3.2) of the data objects specified 20 in an equivalence-set are storage associated. All of the nonzero-sized sequences in the equivalence-set, if 21 any, have the same first storage unit, and all of the zero-sized sequences in the equivalence-set, if any, 22 are storage associated with one another and with the first storage unit of any nonzero-sized sequences. 23 This causes the storage association of the data objects in the equivalence-set and may cause storage 24 109 J3/06-007r1 WORKING DRAFT 2006/09/25 association of other data objects. 1 5.7.1.3 Equivalence of default character objects 2 A data object of type default character shall not be equivalenced to an object that is not of type default 3 character and not of a character sequence type. The lengths of the equivalenced character objects need 4 not be the same. 5 An EQUIVALENCE statement specifies that the storage sequences of all the default character data 6 objects specified in an equivalence-set are storage associated. All of the nonzero-sized sequences in the 7 equivalence-set, if any, have the same first character storage unit, and all of the zero-sized sequences in 8 the equivalence-set, if any, are storage associated with one another and with the first character storage 9 unit of any nonzero-sized sequences. This causes the storage association of the data objects in the 10 equivalence-set and may cause storage association of other data objects. 11 NOTE 5.41 For example, using the declarations: CHARACTER (LEN = 4) :: A, B CHARACTER (LEN = 3) :: C (2) EQUIVALENCE (A, C (1)), (B, C (2)) the association of A, B, and C can be illustrated graphically as: 1 2 3 4 5 6 7 |--- --- A --- ---| |--- --- B --- ---| |--- C(1) ---| |--- C(2) ---| 5.7.1.4 Array names and array element designators 12 For a nonzero-sized array, the use of the array name unqualified by a subscript list as an equivalence- 13 object has the same effect as using an array element designator that identifies the first element of the 14 array. 15 5.7.1.5 Restrictions on EQUIVALENCE statements 16 An EQUIVALENCE statement shall not specify that the same storage unit is to occur more than once 17 in a storage sequence. 18 NOTE 5.42 For example: REAL, DIMENSION (2) :: A REAL :: B EQUIVALENCE (A (1), B), (A (2), B) ! Not standard-conforming is prohibited, because it would specify the same storage unit for A (1) and A (2). An EQUIVALENCE statement shall not specify that consecutive storage units are to be nonconsecutive. 19 110 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 5.43 For example, the following is prohibited: REAL A (2) DOUBLE PRECISION D (2) EQUIVALENCE (A (1), D (1)), (A (2), D (2)) ! Not standard-conforming 5.7.2 COMMON statement 1 5.7.2.1 General 2 The COMMON statement specifies blocks of physical storage, called common blocks, that can be 3 accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global 4 data facility based on storage association (16.5.3). 5 The common blocks specified by the COMMON statement may be named and are called named com- 6 mon blocks, or may be unnamed and are called blank common. 7 R567 common-stmt is COMMON 8 [ / [ common-block-name ] / ] common-block-object-list 9 [ [ , ] / [ common-block-name ] / 10 common-block-object-list ] ... 11 R568 common-block-object is variable-name [ ( array-spec ) ] 12 or proc-pointer-name 13 C596 (R568) An array-spec in a common-block-object shall be an explicit-shape-spec-list. 14 C597 (R568) Only one appearance of a given variable-name or proc-pointer-name is permitted in all 15 common-block-object-lists within a scoping unit. 16 C598 (R568) A common-block-object shall not be a dummy argument, an allocatable variable, a 17 derived-type object with an ultimate component that is allocatable, an automatic object, a 18 function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. 19 C599 (R568) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2.3) or a 20 type with the BIND attribute and it shall have no default initialization. 21 C5100 (R568) A variable-name or proc-pointer-name shall not be a name made accessible by use 22 association. 23 In each COMMON statement, the data objects whose names appear in a common block object list 24 following a common block name are declared to be in that common block. If the first common block 25 name is omitted, all data objects whose names appear in the first common block object list are specified to 26 be in blank common. Alternatively, the appearance of two slashes with no common block name between 27 them declares the data objects whose names appear in the common block object list that follows to be 28 in blank common. 29 Any common block name or an omitted common block name for blank common may occur more than 30 once in one or more COMMON statements in a scoping unit. The common block list following each 31 successive appearance of the same common block name in a scoping unit is treated as a continuation of 32 the list for that common block name. Similarly, each blank common block object list in a scoping unit 33 is treated as a continuation of blank common. 34 The form variable-name (array-spec) specifies the DIMENSION attribute for that variable. 35 If derived-type objects of numeric sequence type (4.5.2) or character sequence type (4.5.2) appear in 36 111 J3/06-007r1 WORKING DRAFT 2006/09/25 common, it is as if the individual components were enumerated directly in the common list. 1 NOTE 5.44 Examples of COMMON statements are: COMMON /BLOCKA/ A, B, D (10, 30) COMMON I, J, K 5.7.2.2 Common block storage sequence 2 For each common block in a scoping unit, a common block storage sequence is formed as follows: 3 (1) A storage sequence is formed consisting of the sequence of storage units in the storage 4 sequences (16.5.3.2) of all data objects in the common block object lists for the common 5 block. The order of the storage sequences is the same as the order of the appearance of the 6 common block object lists in the scoping unit. 7 (2) The storage sequence formed in (1) is extended to include all storage units of any storage 8 sequence associated with it by equivalence association. The sequence shall be extended only 9 by adding storage units beyond the last storage unit. Data objects associated with an entity 10 in a common block are considered to be in that common block. 11 Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute 12 to common block storage sequences formed in that scoping unit. 13 5.7.2.3 Size of a common block 14 The size of a common block is the size of its common block storage sequence, including any extensions 15 of the sequence resulting from equivalence association. 16 5.7.2.4 Common association 17 Within a program, the common block storage sequences of all nonzero-sized common blocks with the 18 same name have the same first storage unit, and the common block storage sequences of all zero-sized 19 common blocks with the same name are storage associated with one another. Within a program, the 20 common block storage sequences of all nonzero-sized blank common blocks have the same first storage 21 unit and the storage sequences of all zero-sized blank common blocks are associated with one another and 22 with the first storage unit of any nonzero-sized blank common blocks. This results in the association of 23 objects in different scoping units. Use association or host association may cause these associated objects 24 to be accessible in the same scoping unit. 25 A nonpointer object of default integer type, default real type, double precision real type, default complex 26 type, default logical type, or numeric sequence type shall be associated only with nonpointer objects of 27 these types. 28 A nonpointer object of type default character or character sequence type shall be associated only with 29 nonpointer objects of these types. 30 A nonpointer object of a derived type that is not a numeric sequence or character sequence type shall 31 be associated only with nonpointer objects of the same type with the same type parameter values. 32 A nonpointer object of intrinsic type other than default integer, default real, double precision real, 33 default complex, default logical, or default character shall be associated only with nonpointer objects of 34 the same type and type parameters. 35 A data pointer shall be storage associated only with data pointers of the same type and rank. Data 36 pointers that are storage associated shall have deferred the same type parameters; corresponding non- 37 112 2006/09/25 WORKING DRAFT J3/06-007r1 deferred type parameters shall have the same value. A procedure pointer shall be storage associated 1 only with another procedure pointer; either both interfaces shall be explicit or both interfaces shall be 2 implicit. If the interfaces are explicit, the characteristics shall be the same. If the interfaces are implicit, 3 either both shall be subroutines or both shall be functions with the same type and type parameters. 4 An object with the TARGET attribute shall be storage associated only with another object that has 5 the TARGET attribute and the same type and type parameters. 6 NOTE 5.45 A common block is permitted to contain sequences of different storage units, provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block. For example, this allows a single common block to contain both numeric and character storage units. Association in different scoping units between objects of default type, objects of double precision real type, and sequence structures is permitted according to the rules for equivalence objects (5.7.1). 5.7.2.5 Differences between named common and blank common 7 A blank common block has the same properties as a named common block, except for the following. 8 (1) Execution of a RETURN or END statement may cause data objects in a named common 9 block to become undefined unless the common block has the SAVE attribute, but never 10 causes data objects in blank common to become undefined (16.6.6). 11 (2) Named common blocks of the same name shall be of the same size in all scoping units of a 12 program in which they appear, but blank common blocks may be of different sizes. 13 (3) A data object in a named common block may be initially defined by means of a DATA 14 statement or type declaration statement in a block data program unit (11.3), but objects in 15 blank common shall not be initially defined. 16 5.7.3 Restrictions on common and equivalence 17 An EQUIVALENCE statement shall not cause the storage sequences of two different common blocks to 18 be associated. 19 Equivalence association shall not cause a derived-type object with default initialization to be associated 20 with an object in a common block. 21 Equivalence association shall not cause a common block storage sequence to be extended by adding 22 storage units preceding the first storage unit of the first object specified in a COMMON statement for 23 the common block. 24 NOTE 5.46 For example, the following is not permitted: COMMON /X/ A REAL B (2) EQUIVALENCE (A, B (2)) ! Not standard-conforming 113 J3/06-007r1 WORKING DRAFT 2006/09/25 114 2006/09/25 WORKING DRAFT J3/06-007r1 6 Use of data objects 1 The appearance of a data object designator in a context that requires its value is termed a reference. A 2 reference is permitted only if the data object is defined. A reference to a pointer is permitted only if the 3 pointer is associated with a target object that is defined. A data object becomes defined with a value 4 when events described in 16.6.5 occur. 5 R601 variable is designator 6 or expr 7 C601 (R601) designator shall not be a constant or a subobject of a constant. 8 C602 (R601) expr shall be a reference to a function that has a pointer result. 9 A variable is either the data object denoted by designator or the target of expr . 10 R602 variable-name is name 11 C603 (R602) variable-name shall be the name of a variable. 12 R603 designator is object-name 13 or array-element 14 or array-section 15 or complex-part-designator 16 or structure-component 17 or substring 18 R604 logical-variable is variable 19 C604 (R604) logical-variable shall be of type logical. 20 R605 default-logical-variable is variable 21 C605 (R605) default-logical-variable shall be of type default logical. 22 R606 char-variable is variable 23 C606 (R606) char-variable shall be of type character. 24 R607 default-char-variable is variable 25 C607 (R607) default-char-variable shall be of type default character. 26 R608 int-variable is variable 27 C608 (R608) int-variable shall be of type integer. 28 NOTE 6.1 For example, given the declarations: CHARACTER (10) A, B (10) TYPE (PERSON) P ! See Note 4.21 then A, B, B (1), B (1:5), P % AGE, and A (1:1) are all variables. 115 J3/06-007r1 WORKING DRAFT 2006/09/25 A constant (3.2.2) is a literal constant or a named constant. A literal constant is a scalar denoted by a 1 syntactic form, which indicates its type, type parameters, and value. A named constant is a constant 2 that has a name; the name has the PARAMETER attribute (5.3.12, 5.4.10). A reference to a constant 3 is always permitted; redefinition of a constant is never permitted. 4 6.1 Scalars 5 A scalar (2.4.4) is a data entity that can be represented by a single value of the type and that is not an 6 array (6.2). Its value, if defined, is a single element from the set of values that characterize its type. 7 NOTE 6.2 A scalar object of derived type has a single value that consists of the values of its components (4.5.8). A scalar has rank zero. 8 6.1.1 Substrings 9 A substring is a contiguous portion of a character string (4.4.5). The following rules define the forms 10 of a substring: 11 R609 substring is parent-string ( substring-range ) 12 R610 parent-string is scalar-variable-name 13 or array-element 14 or scalar-structure-component 15 or scalar-constant 16 R611 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] 17 C609 (R610) parent-string shall be of type character. 18 The value of the first scalar-int-expr in substring-range is called the starting point and the value of 19 the second one is called the ending point. The length of a substring is the number of characters in the 20 substring and is MAX (l - f + 1, 0), where f and l are the starting and ending points, respectively. 21 Let the characters in the parent string be numbered 1, 2, 3, ..., n, where n is the length of the parent 22 string. Then the characters in the substring are those from the parent string from the starting point and 23 proceeding in sequence up to and including the ending point. Both the starting point and the ending 24 point shall be within the range 1, 2, ..., n unless the starting point exceeds the ending point, in which 25 case the substring has length zero. If the starting point is not specified, the default value is 1. If the 26 ending point is not specified, the default value is n. 27 If the parent is a variable, the substring is also a variable. 28 NOTE 6.3 Examples of character substrings are: B(1)(1:5) array element as parent string P%NAME(1:1) structure component as parent string ID(4:9) scalar variable name as parent string '0123456789'(N:N) character constant as parent string 6.1.2 Structure components 29 116 2006/09/25 WORKING DRAFT J3/06-007r1 A structure component is part of an object of derived type; it may be referenced by an object 1 designator. A structure component may be a scalar or an array. 2 R612 data-ref is part-ref [ % part-ref ] ... 3 R613 part-ref is part-name [ ( section-subscript-list ) ] [ image-selector ] 4 C610 (R612) Each part-name except the rightmost shall be of derived type. 5 C611 (R612) Each part-name except the leftmost shall be the name of a component of the declared 6 type of the preceding part-name. 7 C612 (R612) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. 8 C613 (R612) The leftmost part-name shall be the name of a data object. 9 C614 (R613) If a section-subscript-list appears, the number of section-subscripts shall equal the rank 10 of part-name. 11 C615 (R613) If image-selector appears and part-name is an array, section-subscript-list shall appear. 12 C616 (R612) A data-ref that is a co-indexed object shall not be of a type that has a pointer ultimate 13 component. 14 C617 (R612) If image-selector appears, data-ref shall not be, or have a direct component, of type 15 IMAGE TEAM (13.8.3.7), C PTR, or C FUNPTR (15.3.3). 16 NOTE 6.4 This restriction is needed to avoid a disallowed pointer assignment for a component, such as Z[P] = Z ! Not allowed if Z has a pointer component Z = Z[P] ! Not allowed if Z has a pointer component J3 internal note Unresolved Technical Issue 020 Is "Z[P] = Z" allowed if Z has an allocatable component? This would imply remote (re)allocation, which I was told was bad when I asked why we were prohibiting "array[i]" forcing it to be "array(:)[i]". Also, constraint (C633a) in ALLOCATE prevents explicit remote allocation. If the answer is that remote reallocation is fine in this instance, we need to make that consistent (including allowing explicit remote allocation). Or if it is bad, we need to remove it consistently. Subgroup say they want to allow this, but require allocatable components in Z[P] to have the same shape as those in Z, removing the auto realloc. The editor disagrees that this is an obviously "good" technical fix; see discussion under assignment. The rank of a part-ref of the form part-name is the rank of part-name. The rank of a part-ref that has 17 a section subscript list is the number of subscript triplets and vector subscripts in the list. 18 C618 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right 19 of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. 20 The rank of a data-ref is the rank of the part-ref with nonzero rank, if any; otherwise, the rank is zero. 21 The base object of a data-ref is the data object whose name is the leftmost part name. 22 The type and type parameters, if any, of a data-ref are those of the rightmost part name. 23 A data-ref with more than one part-ref is a subobject of its base object if none of the part-names, 24 except for possibly the rightmost, are pointers. If the rightmost part-name is the only pointer, then the 25 117 J3/06-007r1 WORKING DRAFT 2006/09/25 data-ref is a subobject of its base object in contexts that pertain to its pointer association status but 1 not in any other contexts. 2 NOTE 6.5 If X is an object of derived type with a pointer component P, then the pointer X%P is a subobject of X when considered as a pointer ­ that is in contexts where it is not dereferenced. However the target of X%P is not a subobject of X. Thus, in contexts where X%P is dereferenced to refer to the target, it is not a subobject of X. R614 structure-component is data-ref 3 C619 (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form 4 part-name. 5 A structure component shall be neither referenced nor defined before the declaration of the base object. 6 A structure component is a pointer only if the rightmost part name is defined to have the POINTER 7 attribute. 8 NOTE 6.6 Examples of structure components are: SCALAR_PARENT%SCALAR_FIELD scalar component of scalar parent ARRAY_PARENT(J)%SCALAR_FIELD component of array element parent ARRAY_PARENT(1:N)%SCALAR_FIELD component of array section parent For a more elaborate example see C.3.1. NOTE 6.7 The syntax rules are structured such that a data-ref that ends in a component name without a following subscript list is a structure component, even when other component names in the data- ref are followed by a subscript list. A data-ref that ends in a component name with a following subscript list is either an array element or an array section. A data-ref of nonzero rank that ends with a substring-range is an array section. A data-ref of zero rank that ends with a substring-range is a substring. A subcomponent of an object of derived type is a component of that object or of a subobject of that 9 object. 10 A data-ref shall not be a co-indexed object that has a pointer subcomponent. A data-ref that is a 11 co-indexed object shall not be, or have a subcomponent, of type IMAGE TEAM (13.8.3.7), C PTR, or 12 C FUNPTR (15.3.3). 13 118 2006/09/25 WORKING DRAFT J3/06-007r1 J3 internal note Unresolved Technical Issue 089 I'm just so sure the sky is going to fall in if the user dares to do this, but why are we adding uncheckable requirements? (Well, ok it's theoretically checkable at runtime only.) And why is this requirement placed here? None of the other stuff which uses the term "sub- component" is here, this is just the definition. It probably belongs in a separate subclause for co-indexed objects... which might clean up some of the other mess that is being made of clause 6. We REALLY ought not to be placing type requirements on runtime values. That is UNAC- CEPTABLE. I am not kidding ­ note the careful design of the object-oriented stuff to avoid such requirements. If the co-array folk don't have the time to design the facility properly, omit it, don't go and make a complete pig's ear of the standard. It is not beyond the wit of man to design this to be compile-time checkable. Back to the original question ­ why is the sky going to fall in? I do not believe that the conse- quences of allowing this justify the complexity of these arbitrary restrictions. Furthermore, the restrictions are ineffective. There are standard-conforming ways (using TRANSFER) to "hide" the type of the value and restore it later, on another image. 6.1.3 Complex parts 1 A complex part designator is used to designate the real or imaginary part of a complex data object, 2 independently of the other part. 3 R615 complex-part-designator is designator % RE 4 or designator % IM 5 C620 (R615) The designator shall be of complex type. 6 If complex-part-designator is designator %RE it designates the real part of designator . If it is designa- 7 tor %IM it designates the imaginary part of designator . The type of a complex-part-designator is real, 8 and its kind and shape are those of the designator . 9 NOTE 6.8 The following are examples of complex part designators: impedance%re !-- Same value as REAL(impedance) fft%im !-- Same value as AIMAG(fft) x%im = 0.0 !-- Sets the imaginary part of X to zero 6.1.4 Type parameter inquiry 10 A type parameter inquiry is used to inquire about a type parameter of a data object. It applies to 11 both intrinsic and derived types. 12 R616 type-param-inquiry is designator % type-param-name 13 C621 (R616) The type-param-name shall be the name of a type parameter of the declared type of the 14 object designated by the designator . 15 A deferred type parameter of a pointer that is not associated or of an unallocated allocatable variable 16 shall not be inquired about. 17 119 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 6.9 A type-param-inquiry has a syntax like that of a structure component reference, but it does not have the same semantics. It is not a variable and thus can never be assigned to. It may be used only as a primary in an expression. It is scalar even if designator is an array. The intrinsic type parameters can also be inquired about by using the intrinsic functions KIND and LEN. NOTE 6.10 The following are examples of type parameter inquiries: a%kind !-- A is real. Same value as KIND(a). s%len !-- S is character. Same value as LEN(s). b(10)%kind !-- Inquiry about an array element. p%dim !-- P is of the derived type general_point. See Note 4.28 for the definition of the general_point type used in the last example above. 6.2 Arrays 1 An array is a set of scalar data, all of the same type and type parameters, whose individual elements 2 are arranged in a rectangular pattern. The scalar data that make up an array are the array elements. 3 No order of reference to the elements of an array is indicated by the appearance of the array designator, 4 except where array element ordering (6.2.2.2) is specified. 5 6.2.1 Whole arrays 6 A whole array is a named array, which may be either a named constant (5.3.12, 5.4.10) or a variable; 7 no subscript list is appended to the name. 8 The appearance of a whole array variable in an executable construct specifies all the elements of the 9 array (2.4.5). An assumed-size array is permitted to appear as a whole array in an executable construct 10 only as an actual argument in a procedure reference that does not require the shape. 11 The appearance of a whole array name in a nonexecutable statement specifies the entire array except 12 for the appearance of a whole array name in an equivalence set (5.7.1.4). 13 6.2.2 Array elements and array sections 14 R617 array-element is data-ref 15 C622 (R617) Every part-ref shall have rank zero and the last part-ref shall contain a subscript-list. 16 R618 array-section is data-ref [ ( substring-range ) ] 17 or complex-part-designator 18 C623 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have a 19 section-subscript-list with nonzero rank, the array-section is a complex-part-designator that is 20 an array, or another part-ref shall have nonzero rank. 21 C624 (R618) If a substring-range appears, the rightmost part-name shall be of type character. 22 R619 subscript is scalar-int-expr 23 120 2006/09/25 WORKING DRAFT J3/06-007r1 R620 section-subscript is subscript 1 or subscript-triplet 2 or vector-subscript 3 R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ] 4 R622 stride is scalar-int-expr 5 R623 vector-subscript is int-expr 6 C625 (R623) A vector-subscript shall be an integer array expression of rank one. 7 C626 (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension 8 of an assumed-size array. 9 An array element is a scalar. An array section is an array. If a substring-range is present in an array- 10 section, each element is the designated substring of the corresponding element of the array section. 11 NOTE 6.11 For example, with the declarations: REAL A (10, 10) CHARACTER (LEN = 10) B (5, 5, 5) A (1, 2) is an array element, A (1:N:2, M) is a rank-one array section, and B (:, :, :) (2:3) is an array of shape (5, 5, 5) whose elements are substrings of length 2 of the corresponding elements of B. NOTE 6.12 Unless otherwise specified, an array element or array section does not have an attribute of the whole array. In particular, an array element or an array section does not have the POINTER or ALLOCATABLE attribute. NOTE 6.13 Examples of array elements and array sections are: ARRAY_A(1:N:2)%ARRAY_B(I, J)%STRING(K)(:) array section SCALAR_PARENT%ARRAY_FIELD(J) array element SCALAR_PARENT%ARRAY_FIELD(1:N) array section SCALAR_PARENT%ARRAY_FIELD(1:N)%SCALAR_FIELD array section 6.2.2.1 Array elements 12 The value of a subscript in an array element shall be within the bounds for that dimension. 13 6.2.2.2 Array element order 14 The elements of an array form a sequence known as the array element order. The position of an array 15 element in this sequence is determined by the subscript order value of the subscript list designating the 16 element. The subscript order value is computed from the formulas in Table 6.1. 17 Table 6.1: Subscript order value Rank Subscript bounds Subscript list Subscript order value 1 + (s1 - j1 ) 1 j1 :k1 s1 1 + (s1 - j1 ) 2 j1 :k1 ,j2 :k2 s1 , s2 +(s2 - j2 ) × d1 121 J3/06-007r1 WORKING DRAFT 2006/09/25 Rank Subscript bounds Subscript list Subscript order value 1 + (s1 - j1 ) +(s2 - j2 ) × d1 3 j1 :k1 , j2 :k2 , j3 :k3 s1 , s2 , s3 +(s3 - j3 ) × d2 × d1 · · · · · · · · · · · · 1 + (s1 - j1 ) +(s2 - j2 ) × d1 +(s3 - j3 ) × d2 × d1 15 j1 :k1 , . . . , j15 :k15 s1 , . . . , s15 +... +(s15 - j15 ) × d14 ×d13 × . . . × d1 Notes for Table 6.1: 1) di = max (ki - ji + 1, 0) is the size of the ith dimension. 2) If the size of the array is nonzero, ji si ki for all i = 1, 2, ..., 15. 6.2.2.3 Array sections 1 An array section is an array subobject optionally followed by a substring range. 2 In an array-section having a section-subscript-list, each subscript-triplet and vector-subscript in the 3 section subscript list indicates a sequence of subscripts, which may be empty. Each subscript in such a 4 sequence shall be within the bounds for its dimension unless the sequence is empty. The array section is 5 the set of elements from the array determined by all possible subscript lists obtainable from the single 6 subscripts or sequences of subscripts specified by each section subscript. 7 In an array-section with no section-subscript-list, the rank and shape of the array is the rank and shape 8 of the part-ref with nonzero rank; otherwise, the rank of the array section is the number of subscript 9 triplets and vector subscripts in the section subscript list. The shape is the rank-one array whose ith 10 element is the number of integer values in the sequence indicated by the ith subscript triplet or vector 11 subscript. If any of these sequences is empty, the array section has size zero. The subscript order of the 12 elements of an array section is that of the array data object that the array section represents. 13 6.2.2.3.1 Subscript triplet 14 A subscript triplet designates a regular sequence of subscripts consisting of zero or more subscript values. 15 The third expression in the subscript triplet is the increment between the subscript values and is called 16 the stride. The subscripts and stride of a subscript triplet are optional. An omitted first subscript in a 17 subscript triplet is equivalent to a subscript whose value is the lower bound for the array and an omitted 18 second subscript is equivalent to the upper bound. An omitted stride is equivalent to a stride of 1. 19 The stride shall not be zero. 20 When the stride is positive, the subscripts specified by a triplet form a regularly spaced sequence of 21 integers beginning with the first subscript and proceeding in increments of the stride to the largest such 22 integer not greater than the second subscript; the sequence is empty if the first subscript is greater than 23 the second. 24 NOTE 6.14 For example, suppose an array is declared as A (5, 4, 3). The section A (3 : 5, 2, 1 : 2) is the array of shape (3, 2): 122 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 6.14 (cont.) A (3, 2, 1) A (3, 2, 2) A (4, 2, 1) A (4, 2, 2) A (5, 2, 1) A (5, 2, 2) When the stride is negative, the sequence begins with the first subscript and proceeds in increments of 1 the stride down to the smallest such integer equal to or greater than the second subscript; the sequence 2 is empty if the second subscript is greater than the first. 3 NOTE 6.15 For example, if an array is declared B (10), the section B (9 : 1 : ­2) is the array of shape (5) whose elements are B (9), B (7), B (5), B (3), and B (1), in that order. NOTE 6.16 A subscript in a subscript triplet need not be within the declared bounds for that dimension if all values used in selecting the array elements are within the declared bounds. For example, if an array is declared as B (10), the array section B (3 : 11 : 7) is the array of shape (2) consisting of the elements B (3) and B (10), in that order. 6.2.2.3.2 Vector subscript 4 A vector subscript designates a sequence of subscripts corresponding to the values of the elements 5 of the expression. Each element of the expression shall be defined. A many-one array section is an 6 array section with a vector subscript having two or more elements with the same value. A many-one 7 array section shall appear neither on the left of the equals in an assignment statement nor as an input 8 item in a READ statement. 9 An array section with a vector subscript shall not be argument associated with a dummy array that 10 is defined or redefined. An array section with a vector subscript shall not be the target in a pointer 11 assignment statement. An array section with a vector subscript shall not be an internal file. 12 NOTE 6.17 For example, suppose Z is a two-dimensional array of shape (5, 7) and U and V are one-dimensional arrays of shape (3) and (4), respectively. Assume the values of U and V are: U = (/ 1, 3, 2 /) V = (/ 2, 1, 1, 3 /) Then Z (3, V) consists of elements from the third row of Z in the order: Z (3, 2) Z (3, 1) Z (3, 1) Z (3, 3) and Z (U, 2) consists of the column elements: Z (1, 2) Z (3, 2) Z (2, 2) and Z (U, V) consists of the elements: Z (1, 2) Z (1, 1) Z (1, 1) Z (1, 3) Z (3, 2) Z (3, 1) Z (3, 1) Z (3, 3) Z (2, 2) Z (2, 1) Z (2, 1) Z (2, 3) 123 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 6.17 (cont.) Because Z (3, V) and Z (U, V) contain duplicate elements from Z, the sections Z (3, V) and Z (U, V) shall not be redefined as sections. 6.2.3 Image selectors 1 An image selector specifies the image index for co-array data. 2 R624 image-selector is lbracket co-subscript-list rbracket 3 R625 co-subscript is scalar-int-expr 4 The number of co-subscripts shall be equal to the co-rank of the object. The value of a co-subscript in 5 an image selector shall be within the co-bounds for its co-dimension. Taking account of the co-bounds, 6 the co-subscript list in an image selector determines the image index in the same way that a subscript 7 list in an array element determines the subscript order value (6.2.2.2), taking account of the bounds. An 8 image selector shall specify an image index value that is not greater than the number of images. 9 NOTE 6.18 For example, if there are 16 images and the co-array A is declared REAL :: A(10)[5,*] A(:)[1,4] is valid because it specifies image 16, but A(:)[2,4] is invalid because it specifies image 17. 6.3 Dynamic association 10 Dynamic control over the allocation, association, and deallocation of pointer targets is provided by 11 the ALLOCATE, NULLIFY, and DEALLOCATE statements and pointer assignment. ALLOCATE 12 (6.3.1) creates targets for pointers; pointer assignment (7.4.2) associates pointers with existing targets; 13 NULLIFY (6.3.2) disassociates pointers from targets, and DEALLOCATE (6.3.3) deallocates targets. 14 Dynamic association applies to scalars and arrays of any type. 15 The ALLOCATE and DEALLOCATE statements also are used to create and deallocate variables with 16 the ALLOCATABLE attribute. 17 NOTE 6.19 Detailed remarks regarding pointers and dynamic association are in C.3.3. 6.3.1 ALLOCATE statement 18 The ALLOCATE statement dynamically creates pointer targets and allocatable variables. 19 R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list 20 [, alloc-opt-list ] ) 21 R627 alloc-opt is ERRMSG = errmsg-variable 22 or MOLD = source-expr 23 or SOURCE = source-expr 24 or STAT = stat-variable 25 R628 stat-variable is scalar-int-variable 26 R629 errmsg-variable is scalar-default-char-variable 27 R630 source-expr is expr 28 R631 allocation is allocate-object [ ( allocate-shape-spec-list ) ] 29 124 2006/09/25 WORKING DRAFT J3/06-007r1 [ lbracket allocate-co-array-spec rbracket ] 1 R632 allocate-object is variable-name 2 or structure-component 3 R633 allocate-shape-spec is [ lower-bound-expr : ] upper-bound-expr 4 R634 lower-bound-expr is scalar-int-expr 5 R635 upper-bound-expr is scalar-int-expr 6 R636 allocate-co-array-spec is [ allocate-co-shape-spec-list , ] [ lower-bound-expr : ] * 7 R637 allocate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr 8 C627 (R632) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 9 C628 (R626) If any allocate-object in the statement has a deferred type parameter, either type-spec or 10 source-expr shall appear. 11 C629 (R626) If a type-spec appears, it shall specify a type with which each allocate-object is type 12 compatible. 13 C630 (R626) If any allocate-object is unlimited polymorphic or is of abstract type, either type-spec or 14 source-expr shall appear. 15 C631 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each allocate-object 16 is a dummy argument for which the corresponding type parameter is assumed. 17 C632 (R626) If a type-spec appears, the kind type parameter values of each allocate-object shall be 18 the same as the corresponding type parameter values of the type-spec. 19 C633 (R631) An allocate-shape-spec-list shall appear if and only if the allocate-object is an array. An 20 allocate-co-array-spec shall appear if and only if the allocate-object is a co-array. 21 C634 (R631) The number of allocate-shape-specs in an allocate-shape-spec-list shall be the same as the 22 rank of the allocate-object. The number of allocate-co-shape-specs in an allocate-co-array-spec 23 shall be one less than the co-rank of the allocate-object. 24 C635 (R627) No alloc-opt shall appear more than once in a given alloc-opt-list. 25 C636 (R626) At most one of source-expr and type-spec shall appear. 26 C637 (R626) Each allocate-object shall be type compatible (4.3.1.3) with source-expr . If SOURCE= 27 appears, source-expr shall be a scalar or have the same rank as each allocate-object. 28 C638 (R626) Corresponding kind type parameters of allocate-object and source-expr shall have the 29 same values. 30 C639 (R626) type-spec shall not specify a type that has a co-array ultimate component. 31 C640 (R630) The declared type of source-expr shall not have a co-array ultimate component. 32 C641 (R632) An allocate-object shall not be a co-indexed object. 33 NOTE 6.20 If a co-array is of a derived type that has an allocatable component, the component shall be allocated by its own image: TYPE(SOMETHING), ALLOCATABLE :: T[:] ... ALLOCATE(T[*]) ! Allowed - implies synchronization ALLOCATE(T%AAC(N)) ! Allowed - allocated by its own image 125 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 6.20 (cont.) ALLOCATE(T[Q]%AAC(N)) ! Not allowed, because it is not ! necessarily executed on image Q. An allocate-object or a bound or type parameter of an allocate-object shall not depend on the value of 1 stat-variable, the value of errmsg-variable, or on the value, bounds, length type parameters, allocation 2 status, or association status of any allocate-object in the same ALLOCATE statement. 3 Neither stat-variable, source-expr , nor errmsg-variable shall be allocated within the ALLOCATE state- 4 ment in which it appears; nor shall they depend on the value, bounds, length type parameters, allocation 5 status, or association status of any allocate-object in the same ALLOCATE statement. 6 If type-spec is specified, each allocate-object is allocated with the specified dynamic type and type pa- 7 rameter values; if source-expr is specified, each allocate-object is allocated with the dynamic type and 8 type parameter values of source-expr ; otherwise, each allocate-object is allocated with its dynamic type 9 the same as its declared type. 10 If type-spec appears and the value of a type parameter it specifies differs from the value of the corre- 11 sponding nondeferred type parameter specified in the declaration of any allocate-object, an error condition 12 occurs. If the value of a nondeferred length type parameter of an allocate-object differs from the value 13 of the corresponding type parameter of source-expr , an error condition occurs. 14 If a type-param-value in a type-spec in an ALLOCATE statement is an asterisk, it denotes the current 15 value of that assumed type parameter. If it is an expression, subsequent redefinition or undefinition of 16 any entity in the expression does not affect the type parameter value. 17 NOTE 6.21 An example of an ALLOCATE statement is: ALLOCATE (X (N), B (-3 : M, 0:9), STAT = IERR_ALLOC) When an ALLOCATE statement is executed for an array, the values of the lower bound and upper 18 bound expressions determine the bounds of the array. Subsequent redefinition or undefinition of any 19 entities in the bound expressions do not affect the array bounds. If the lower bound is omitted, the 20 default value is 1. If the upper bound is less than the lower bound, the extent in that dimension is zero 21 and the array has zero size. 22 When an ALLOCATE statement is executed for a co-array, the values of the lower co-bound and upper 23 co-bound expressions determine the co-bounds of the co-array. Subsequent redefinition or undefinition 24 of any entities in the co-bound expressions do not affect the co-bounds. If the lower co-bound is omitted, 25 the default value is 1. The upper co-bound shall not be less than the lower co-bound. 26 NOTE 6.22 An allocate-object may be of type character with zero character length. If SOURCE= appears, source-expr shall be conformable (2.4.5) with allocation. If the value of a non- 27 deferred length type parameter of allocate-object is different from the value of the corresponding type 28 parameter of source-expr , an error condition occurs. If the allocation is successful, the value of allocate- 29 object becomes that of source-expr . 30 If MOLD= appears and source-expr is a variable, its value need not be defined. 31 126 2006/09/25 WORKING DRAFT J3/06-007r1 J3 internal note Unresolved Technical Issue 081 Should we require allocatables to be allocated, or only when they have deferred type parameters? Furthermore, we should probably extend MOLD= (and SOURCE=) to be able to specify the shape, when no array-spec is provided, so the user can write ALLOCATE(A,MOLD=B) instead of ALLOCATE(A(LBOUND(B,1):UBOUND(B,1),LBOUND(B,2):UBOUND(B,2)),MOLD=B) NOTE 6.23 The source-expr can be an array or scalar independently of whether an allocate-object is an array or a scalar. For MOLD=source-expr , only the dynamic type and type parameter values of source-expr are relevant; its rank, shape, and value are not. NOTE 6.24 An example of an ALLOCATE statement in which the value and dynamic type are determined by reference to another object is: CLASS(*), ALLOCATABLE :: NEW CLASS(*), POINTER :: OLD ! ... ALLOCATE (NEW, SOURCE=OLD) ! Allocate NEW with the value and dynamic type of OLD A more extensive example is given in C.3.2. If the STAT= specifier appears, successful execution of the ALLOCATE statement causes the stat- 1 variable to become defined with a value of zero. If an error condition occurs during the execution 2 of the ALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive 3 integer value and each allocate-object will have a processor-dependent status; each allocate-object that 4 was successfully allocated shall have an allocation status of allocated or a pointer association status of 5 associated; each allocate-object that was not successfully allocated shall retain its previous allocation 6 status or pointer association status. 7 If an error condition occurs during execution of an ALLOCATE statement that does not contain the 8 STAT= specifier, execution of the program is terminated. 9 The ERRMSG= specifier is described in 6.3.1.3. 10 6.3.1.1 Allocation of allocatable variables 11 The allocation status of an allocatable entity is one of the following at any time. 12 (1) The status of an allocatable variable becomes allocated if it is allocated by an ALLOCATE 13 statement, if it is allocated during assignment, or if it is given that status by the allocation 14 transfer procedure (13.7.124). An allocatable variable with this status may be referenced, 15 defined, or deallocated; allocating it causes an error condition in the ALLOCATE statement. 16 The intrinsic function ALLOCATED (13.7.10) returns true for such a variable. 17 (2) An allocatable variable has a status of unallocated if it is not allocated. The status of 18 an allocatable variable becomes unallocated if it is deallocated (6.3.3) or if it is given that 19 status by the allocation transfer procedure. An allocatable variable with this status shall 20 127 J3/06-007r1 WORKING DRAFT 2006/09/25 not be referenced or defined. It shall not be supplied as an actual argument corresponding 1 to a nonallocatable dummy argument, except to certain intrinsic inquiry functions. It may 2 be allocated with the ALLOCATE statement. Deallocating it causes an error condition in 3 the DEALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns false 4 for such a variable. 5 At the beginning of execution of a program, allocatable variables are unallocated. 6 A saved allocatable object has an initial status of unallocated. The status may change during the 7 execution of the program. 8 When the allocation status of an allocatable variable changes, the allocation status of any associated 9 allocatable variable changes accordingly. Allocation of an allocatable variable establishes values for the 10 deferred type parameters of all associated allocatable variables. 11 An unsaved allocatable local variable of a procedure has a status of unallocated at the beginning of 12 each invocation of the procedure; the status may change during execution of the procedure. An unsaved 13 allocatable local variable of a module or submodule, or a subobject thereof, has an initial status of 14 unallocated; the status may change during execution of the program. An unsaved local variable of a 15 construct has a status of unallocated at the beginning of each execution of the construct; the status may 16 change during execution of the construct. 17 When an object of derived type is created by an ALLOCATE statement, any allocatable ultimate 18 components have an allocation status of unallocated. 19 The value of each lower-bound-expr and each upper-bound-expr in an allocate-co-array-spec shall be the 20 same on each image. 21 If an allocation specifies a co-array, its dynamic type and the values of each length type parameter shall 22 be the same on each image. 23 There is implicit synchronization of all images in association with each ALLOCATE statement that 24 involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 25 is delayed until all other images have executed the same statement the same number of times. 26 NOTE 6.25 When an image executes an ALLOCATE statement, communication is not necessarily involved apart from any required for synchronization. The image allocates its co-array and records how the corresponding co-arrays on other images are to be addressed. The processor is not required to detect violations of the rule that the bounds are the same on all images, nor is it responsible for detecting or resolving deadlock problems (such as two images waiting on different ALLOCATE statements). 6.3.1.2 Allocation of pointer targets 27 Allocation of a pointer creates an object that implicitly has the TARGET attribute. Following successful 28 execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may 29 be used to reference or define the target. Additional pointers may become associated with the pointer 30 target or a part of the pointer target by pointer assignment. It is not an error to allocate a pointer 31 that is already associated with a target. In this case, a new pointer target is created as required by the 32 attributes of the pointer and any array bounds, type, and type parameters specified by the ALLOCATE 33 statement. The pointer is then associated with this new target. Any previous association of the pointer 34 with a target is broken. If the previous target had been created by allocation, it becomes inaccessible 35 unless other pointers are associated with it. The ASSOCIATED intrinsic function (13.7.15) may be used 36 to determine whether a pointer that does not have undefined association status is associated. 37 128 2006/09/25 WORKING DRAFT J3/06-007r1 At the beginning of execution of a function whose result is a pointer, the association status of the result 1 pointer is undefined. Before such a function returns, it shall either associate a target with this pointer 2 or cause the association status of this pointer to become disassociated. 3 6.3.1.3 ERRMSG= specifier 4 If an error condition occurs during execution of an ALLOCATE or DEALLOCATE statement, the 5 processor shall assign an explanatory message to errmsg-variable. If no such condition occurs, the 6 processor shall not change the value of errmsg-variable. 7 6.3.2 NULLIFY statement 8 The NULLIFY statement causes pointers to be disassociated. 9 R638 nullify-stmt is NULLIFY ( pointer-object-list ) 10 R639 pointer-object is variable-name 11 or structure-component 12 or proc-pointer-name 13 C642 (R639) Each pointer-object shall have the POINTER attribute. 14 A pointer-object shall not depend on the value, bounds, or association status of another pointer-object 15 in the same NULLIFY statement. 16 NOTE 6.26 When a NULLIFY statement is applied to a polymorphic pointer (4.3.1.3), its dynamic type becomes the declared type. 6.3.3 DEALLOCATE statement 17 The DEALLOCATE statement causes allocatable variables to be deallocated; it causes pointer tar- 18 gets to be deallocated and the pointers to be disassociated. 19 R640 deallocate-stmt is DEALLOCATE ( allocate-object-list [ , dealloc-opt-list ] ) 20 C643 (R640) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 21 R641 dealloc-opt is STAT = stat-variable 22 or ERRMSG = errmsg-variable 23 C644 (R641) No dealloc-opt shall appear more than once in a given dealloc-opt-list. 24 An allocate-object shall not depend on the value, bounds, allocation status, or association status of 25 another allocate-object in the same DEALLOCATE statement; it also shall not depend on the value of 26 the stat-variable or errmsg-variable in the same DEALLOCATE statement. 27 Neither stat-variable nor errmsg-variable shall be deallocated within the same DEALLOCATE state- 28 ment; they also shall not depend on the value, bounds, allocation status, or association status of any 29 allocate-object in the same DEALLOCATE statement. 30 If the STAT= specifier appears, successful execution of the DEALLOCATE statement causes the stat- 31 variable to become defined with a value of zero. If an error condition occurs during the execution of 32 the DEALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive 33 integer value and each allocate-object that was successfully deallocated shall have an allocation status of 34 unallocated or a pointer association status of disassociated. Each allocate-object that was not successfully 35 deallocated shall retain its previous allocation status or pointer association status. 36 129 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 6.27 The status of objects that were not successfully deallocated can be individually checked with the ALLOCATED or ASSOCIATED intrinsic functions. If an error condition occurs during execution of a DEALLOCATE statement that does not contain the 1 STAT= specifier, execution of the program is terminated. 2 The ERRMSG= specifier is described in 6.3.1.3. 3 NOTE 6.28 An example of a DEALLOCATE statement is: DEALLOCATE (X, B) 6.3.3.1 Deallocation of allocatable variables 4 Deallocating an unallocated allocatable variable causes an error condition in the DEALLOCATE state- 5 ment. Deallocating an allocatable variable with the TARGET attribute causes the pointer association 6 status of any pointer associated with it to become undefined. 7 When the execution of a procedure is terminated by execution of a RETURN or END statement, an 8 unsaved allocatable local variable of the procedure retains its allocation and definition status if it is a 9 function result variable or a subobject thereof; otherwise, it is deallocated. 10 When a BLOCK construct terminates, an unsaved allocatable local variable of the construct is deallo- 11 cated. 12 NOTE 6.29 The ALLOCATED intrinsic function may be used to determine whether a variable is allocated or unallocated. If an unsaved allocatable local variable of a module or submodule is allocated when execution of a 13 RETURN or END statement results in no active scoping unit referencing the module or submodule, it 14 is processor-dependent whether the object retains its allocation status or is deallocated. 15 NOTE 6.30 The following example illustrates the effects of SAVE on allocation status. MODULE MOD1 TYPE INITIALIZED_TYPE INTEGER :: I = 1 ! Default initialization END TYPE INITIALIZED_TYPE SAVE :: SAVED1, SAVED2 INTEGER :: SAVED1, UNSAVED1 TYPE(INITIALIZED_TYPE) :: SAVED2, UNSAVED2 ALLOCATABLE :: SAVED1(:), SAVED2(:), UNSAVED1(:), UNSAVED2(:) END MODULE MOD1 PROGRAM MAIN CALL SUB1 ! The values returned by the ALLOCATED intrinsic calls ! in the PRINT statement are: ! .FALSE., .FALSE., .FALSE., and .FALSE. ! Module MOD1 is used, and its variables are allocated. ! After return from the subroutine, whether the variables 130 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 6.30 (cont.) ! which were not specified with the SAVE attribute ! retain their allocation status is processor dependent. CALL SUB1 ! The values returned by the first two ALLOCATED intrinsic ! calls in the PRINT statement are: ! .TRUE., .TRUE. ! The values returned by the second two ALLOCATED ! intrinsic calls in the PRINT statement are ! processor dependent and each could be either ! .TRUE. or .FALSE. CONTAINS SUBROUTINE SUB1 USE MOD1 ! Brings in saved and unsaved variables. PRINT *, ALLOCATED(SAVED1), ALLOCATED(SAVED2), & ALLOCATED(UNSAVED1), ALLOCATED(UNSAVED2) IF (.NOT. ALLOCATED(SAVED1)) ALLOCATE(SAVED1(10)) IF (.NOT. ALLOCATED(SAVED2)) ALLOCATE(SAVED2(10)) IF (.NOT. ALLOCATED(UNSAVED1)) ALLOCATE(UNSAVED1(10)) IF (.NOT. ALLOCATED(UNSAVED2)) ALLOCATE(UNSAVED2(10)) END SUBROUTINE SUB1 END PROGRAM MAIN If an executable construct references a function whose result is either allocatable or a structure with 1 a subobject that is allocatable, and the function reference is executed, an allocatable result and any 2 subobject that is an allocated allocatable entity in the result returned by the function is deallocated 3 after execution of the innermost executable construct containing the reference. 4 If a function whose result is either allocatable or a structure with an allocatable object is referenced in 5 the specification part of a scoping unit or BLOCK construct, and the function reference is executed, an 6 allocatable result and any subobject that is an allocated allocatable entity in the result returned by the 7 function is deallocated before execution of the executable constructs of the scoping unit or block. 8 When a procedure is invoked, any allocated allocatable object that is an actual argument associated with 9 an INTENT(OUT) allocatable dummy argument is deallocated; any allocated allocatable object that is 10 a subobject of an actual argument associated with an INTENT(OUT) dummy argument is deallocated. 11 When an intrinsic assignment statement (7.4.1.3) is executed, any allocated allocatable subobject of the 12 variable is deallocated before the assignment takes place. 13 When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. 14 If an allocatable component is a subobject of a finalizable object, that object is finalized before the 15 component is automatically deallocated. 16 The effect of automatic deallocation is the same as that of a DEALLOCATE statement without a 17 dealloc-opt-list. 18 NOTE 6.31 In the following example: SUBROUTINE PROCESS REAL, ALLOCATABLE :: TEMP(:) REAL, ALLOCATABLE, SAVE :: X(:) ... 131 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 6.31 (cont.) END SUBROUTINE PROCESS on return from subroutine PROCESS, the allocation status of X is preserved because X has the SAVE attribute. TEMP does not have the SAVE attribute, so it will be deallocated if it was allo- cated. On the next invocation of PROCESS, TEMP will have an allocation status of unallocated. There is implicit synchronization of all images in association with each DEALLOCATE statement that 1 involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 2 is delayed until all other images have executed the same statement the same number of times. 3 There is also an implicit synchronization of all images in association with the deallocation of a co-array 4 or co-array subcomponent caused by the execution of a RETURN or END statement or the termination 5 of a BLOCK construct. 6 6.3.3.2 Deallocation of pointer targets 7 If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating 8 a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an 9 error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, 10 the pointer shall not be deallocated. 11 If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object 12 that was created by allocation. Deallocating a pointer target causes the pointer association status of 13 any other pointer that is associated with the target or a portion of the target to become undefined. 14 132 2006/09/25 WORKING DRAFT J3/06-007r1 7 Expressions and assignment 1 This clause describes the formation, interpretation, and evaluation rules for expressions, intrinsic and 2 defined assignment, pointer assignment, masked array assignment (WHERE), and FORALL. 3 7.1 Expressions 4 An expression represents either a data reference or a computation, and its value is either a scalar or 5 an array. An expression is formed from operands, operators, and parentheses. 6 An operand is either a scalar or an array. An operation is either intrinsic or defined (7.2). More 7 complicated expressions can be formed using operands which are themselves expressions. 8 Evaluation of an expression produces a value, which has a type, type parameters (if appropriate), and a 9 shape (7.1.4). 10 7.1.1 Form of an expression 11 An expression is defined in terms of several categories: primary, level-1 expression, level-2 expression, 12 level-3 expression, level-4 expression, and level-5 expression. 13 These categories are related to the different operator precedence levels and, in general, are defined in 14 terms of other categories. The simplest form of each expression category is a primary. The rules given 15 below specify the syntax of an expression. The semantics are specified in 7.2. 16 7.1.1.1 Primary 17 R701 primary is constant 18 or designator 19 or array-constructor 20 or structure-constructor 21 or function-reference 22 or type-param-inquiry 23 or type-param-name 24 or ( expr ) 25 C701 (R701) The type-param-name shall be the name of a type parameter. 26 C702 (R701) The designator shall not be a whole assumed-size array. 27 NOTE 7.1 Examples of a primary are: Example Syntactic class constant 1.0 designator 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' (I:I) array-constructor (/ 1.0, 2.0 /) structure-constructor PERSON (12, 'Jones') function-reference F (X, Y) type-param-inquiry X%KIND 133 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.1 (cont.) type-param-name KIND (expr ) (S + T) 7.1.1.2 Level-1 expressions 1 Defined unary operators have the highest operator precedence (Table 7.10). Level-1 expressions are 2 primaries optionally operated on by defined unary operators: 3 R702 level-1-expr is [ defined-unary-op ] primary 4 R703 defined-unary-op is . letter [ letter ] ... . 5 C703 (R703) A defined-unary-op shall not contain more than 63 letters and shall not be the same as 6 any intrinsic-operator or logical-literal-constant. 7 NOTE 7.2 Simple examples of a level-1 expression are: Example Syntactic class primary (R701) A level-1-expr (R702) .INVERSE. B A more complicated example of a level-1 expression is: .INVERSE. (A + B) 7.1.1.3 Level-2 expressions 8 Level-2 expressions are level-1 expressions optionally involving the numeric operators power-op, mult-op, 9 and add-op. 10 R704 mult-operand is level-1-expr [ power-op mult-operand ] 11 R705 add-operand is [ add-operand mult-op ] mult-operand 12 R706 level-2-expr is [ [ level-2-expr ] add-op ] add-operand 13 R707 power-op is ** 14 R708 mult-op is * 15 or / 16 R709 add-op is + 17 or ­ 18 NOTE 7.3 Simple examples of a level-2 expression are: Example Syntactic class Remarks level-1-expr A is a primary. (R702) A mult-operand B is a level-1-expr , ** is a power-op, B ** C and C is a mult-operand . (R704) add-operand D is an add-operand , * is a mult-op, D*E and E is a mult-operand . (R705) level-2-expr + is an add-op +1 and 1 is an add-operand . (R706) level-2-expr F is a level-2-expr , ­ is an add-op, F-I and I is an add-operand . (R706) 134 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 7.3 (cont.) A more complicated example of a level-2 expression is: - A + D * E + B ** C 7.1.1.4 Level-3 expressions 1 Level-3 expressions are level-2 expressions optionally involving the character operator and bits concate- 2 nation operator concat-op. 3 R710 level-3-expr is [ level-3-expr concat-op ] level-2-expr 4 R711 concat-op is // 5 NOTE 7.4 Simple examples of a level-3 expression are: Example Syntactic class level-2-expr (R706) A level-3-expr (R710) B // C A more complicated example of a level-3 expression is: X // Y // 'ABCD' 7.1.1.5 Level-4 expressions 6 Level-4 expressions are level-3 expressions optionally involving the relational operators rel-op. 7 R712 level-4-expr is [ level-3-expr rel-op ] level-3-expr 8 R713 rel-op is .EQ. 9 or .NE. 10 or .LT. 11 or .LE. 12 or .GT. 13 or .GE. 14 or == 15 or /= 16 or < 17 or <= 18 or > 19 or >= 20 NOTE 7.5 Simple examples of a level-4 expression are: Example Syntactic class level-3-expr (R710) A level-4-expr (R712) B == C D, >=, <, <= C C L .NOT. L, B L, B L L L .AND., .OR., .EQV., .NEQV. B B,I B I B B Note: The symbols I, R, Z, C, L, and B stand for the types integer, real, complex, character, logical, and bits, respectively. Where more than one type for x2 is given, the type of the result of the operation is given in the same relative position in the next column. For the intrinsic operators with operands of type character, the kind type parameters of the operands shall be the same. A numeric intrinsic operation is an intrinsic operation for which the intrinsic-operator is a numeric 8 operator (+, ­, *, /, or **). A numeric intrinsic operator is the operator in a numeric intrinsic 9 operation. 10 For numeric intrinsic binary operations, the two operands may be of different numeric types or different 11 kind type parameters. Except for a value raised to an integer power, if the operands have different types 12 or kind type parameters, the effect is as if each operand that differs in type or kind type parameter from 13 those of the result is converted to the type and kind type parameter of the result before the operation 14 is performed. When a value of type real or complex is raised to an integer power, the integer operand 15 137 J3/06-007r1 WORKING DRAFT 2006/09/25 need not be converted. 1 The character intrinsic operation is the intrinsic operation for which the intrinsic-operator is (//) 2 and both operands are of type character. The operands shall have the same kind type parameter. The 3 character intrinsic operator is the operator in a character intrinsic operation. 4 A logical intrinsic operation is an intrinsic operation for which the intrinsic-operator is .AND., .OR., 5 .XOR., .NOT., .EQV., or .NEQV. and both operands are of type logical. A logical intrinsic operator 6 is the operator in a logical intrinsic operation. 7 A bits intrinsic operation is an intrinsic operation for which the intrinsic-operator is //, .AND., .OR., 8 .XOR., .NOT., .EQV., or .NEQV. and at least one operand is of type bits. A bits intrinsic operator 9 is the operator in a bits intrinsic operation. 10 For bits intrinsic operations other than concatenation (//), the two operands may be of different types 11 or different kind type parameters. The effect is as if each operand that differs in type or kind type 12 parameter from those of the result is converted to the type and kind type parameter of the result before 13 the operation is performed. 14 A relational intrinsic operator is an intrinsic-operator that is .EQ., .NE., .GT., .GE., .LT., .LE., 15 ==, /=, >, >=, <, or <=. A relational intrinsic operation is an intrinsic operation for which the 16 intrinsic-operator is a relational intrinsic operator. A numeric relational intrinsic operation is a 17 relational intrinsic operation for which both operands are of numeric type. A character relational 18 intrinsic operation is a relational intrinsic operation for which both operands are of type character. 19 The kind type parameters of the operands of a character relational intrinsic operation shall be the same. 20 A bits relational intrinsic operation is a relational intrinsic operation for which at least one of the 21 operands is of type bits. 22 If both operands of a bits relational operation do not have the same kind type parameter, the operand 23 with the smaller kind type parameter is converted to the same kind as the other operand. If one operand 24 of a bits relational operation is not of type bits, it is converted to type bits with the same kind type 25 parameter as the other operand. Any conversion takes place before the operation is evaluated. 26 7.1.3 Defined operations 27 A defined operation is either a defined unary operation or a defined binary operation. A defined 28 unary operation is an operation that has the form defined-unary-op x2 or intrinsic-operator x2 and 29 that is defined by a function and a generic interface (4.5.2, 12.4.3.3). 30 A function defines the unary operation op x2 if 31 (1) the function is specified with a FUNCTION (12.6.2.1) or ENTRY (12.6.2.5) statement that 32 specifies one dummy argument d2 , 33 (2) either 34 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- 35 TOR (op), or 36 (b) there is a generic binding (4.5.2) in the declared type of x2 with a generic-spec of 37 OPERATOR (op) and there is a corresponding binding to the function in the dynamic 38 type of x2 , 39 (3) the type of d2 is compatible with the dynamic type of x2 , 40 (4) the type parameters, if any, of d2 match the corresponding type parameters of x2 , and 41 (5) either 42 (a) the rank of x2 matches that of d2 or 43 (b) the function is elemental and there is no other function that defines the operation. 44 138 2006/09/25 WORKING DRAFT J3/06-007r1 If d2 is an array, the shape of x2 shall match the shape of d2 . 1 A defined binary operation is an operation that has the form x1 defined-binary-op x2 or x1 intrinsic- 2 operator x2 and that is defined by a function and a generic interface. 3 A function defines the binary operation x1 op x2 if 4 (1) the function is specified with a FUNCTION (12.6.2.1) or ENTRY (12.6.2.5) statement that 5 specifies two dummy arguments, d1 and d2 , 6 (2) either 7 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- 8 TOR (op), or 9 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic- 10 spec of OPERATOR (op) and there is a corresponding binding to the function in the 11 dynamic type of x1 or x2 , respectively, 12 (3) the types of d1 and d2 are compatible with the dynamic types of x1 and x2 , respectively, 13 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 14 and x2 , respectively, and 15 (5) either 16 (a) the ranks of x1 and x2 match those of d1 and d2 or 17 (b) the function is elemental, x1 and x2 are conformable, and there is no other function 18 that defines the operation. 19 If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2 , respectively. 20 NOTE 7.8 An intrinsic operator may be used as the operator in a defined operation. In such a case, the generic properties of the operator are extended. An extension operation is a defined operation in which the operator is of the form defined-unary-op 21 or defined-binary-op. Such an operator is called an extension operator. The operator used in an 22 extension operation may be such that a generic interface for the operator may specify more than one 23 function. 24 A defined elemental operation is a defined operation for which the function is elemental (12.8). 25 7.1.4 Type, type parameters, and shape of an expression 26 The type, type parameters, and shape of an expression depend on the operators and on the types, type 27 parameters, and shapes of the primaries used in the expression, and are determined recursively from 28 the syntactic form of the expression. The type of an expression is one of the intrinsic types (4.4) or a 29 derived type (4.5). 30 If an expression is a polymorphic primary or defined operation, the type parameters and the declared and 31 dynamic types of the expression are the same as those of the primary or defined operation. Otherwise 32 the type parameters and dynamic type of the expression are the same as its declared type and type 33 parameters; they are referred to simply as the type and type parameters of the expression. 34 R724 logical-expr is expr 35 C705 (R724) logical-expr shall be of type logical. 36 R725 char-expr is expr 139 J3/06-007r1 WORKING DRAFT 2006/09/25 1 C706 (R725) char-expr shall be of type character. 2 R726 default-char-expr is expr 3 C707 (R726) default-char-expr shall be of type default character. 4 R727 int-expr is expr 5 C708 (R727) int-expr shall be of type integer. 6 R728 numeric-expr is expr 7 C709 (R728) numeric-expr shall be of type integer, real, or complex. 8 7.1.4.1 Type, type parameters, and shape of a primary 9 The type, type parameters, and shape of a primary are determined according to whether the primary is a 10 constant, variable, array constructor, structure constructor, function reference, type parameter inquiry, 11 type parameter name, or parenthesized expression. If a primary is a constant, its type, type parameters, 12 and shape are those of the constant. If it is a structure constructor, it is scalar and its type and type 13 parameters are as described in 4.5.10. If it is an array constructor, its type, type parameters, and shape 14 are as described in 4.7. If it is a variable or function reference, its type, type parameters, and shape are 15 those of the variable (5.2, 5.3) or the function reference (12.5.3), respectively. If the function reference 16 is generic (12.4.3.2, 13.5) then its type, type parameters, and shape are those of the specific function 17 referenced, which is determined by the types, type parameters, and ranks of its actual arguments as 18 specified in 12.5.5.2. If it is a type parameter inquiry or type parameter name, it is a scalar integer with 19 the kind of the type parameter. 20 If a primary is a parenthesized expression, its type, type parameters, and shape are those of the expres- 21 sion. 22 The associated target object is referenced if a pointer appears as 23 (1) a primary in an intrinsic or defined operation, 24 (2) the expr of a parenthesized primary, or 25 (3) the only primary on the right-hand side of an intrinsic assignment statement. 26 The type, type parameters, and shape of the primary are those of the current target. If the pointer is 27 not associated with a target, it may appear as a primary only as an actual argument in a reference to 28 a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a 29 pointer assignment statement. 30 A disassociated array pointer or an unallocated allocatable array has no shape but does have rank. 31 The type, type parameters, and rank of the result of the NULL intrinsic function depend on context 32 (13.7.131). 33 7.1.4.2 Type, type parameters, and shape of the result of an operation 34 The type of the result of an intrinsic operation [x1 ] op x2 is specified by Table 7.1. The shape of the 35 result of an intrinsic operation is the shape of x2 if op is unary or if x1 is scalar, and is the shape of x1 36 otherwise. 37 The type, type parameters, and shape of the result of a defined operation [x1 ] op x2 are specified by the 38 function defining the operation (7.2). 39 An expression of an intrinsic type has a kind type parameter. An expression of type character also has 40 140 2006/09/25 WORKING DRAFT J3/06-007r1 a character length parameter. 1 The type parameters of the result of an intrinsic operation are as follows. 2 (1) For an expression x1 // x2 where // is the character intrinsic operator and x1 and x2 are 3 of type character, the character length parameter is the sum of the lengths of the operands 4 and the kind type parameter is the kind type parameter of x1 , which shall be the same as 5 the kind type parameter of x2 . 6 (2) For an expression op x2 where op is an intrinsic unary operator and x2 is of type integer, 7 real, complex, logical, or bits, the kind type parameter of the expression is that of the 8 operand. 9 (3) For an expression x1 op x2 where op is a numeric intrinsic binary operator with one operand 10 of type integer and the other of type real or complex, the kind type parameter of the 11 expression is that of the real or complex operand. 12 (4) For an expression x1 op x2 where op is a numeric intrinsic binary operator with both 13 operands of the same type and kind type parameters, or with one real and one complex 14 with the same kind type parameters, the kind type parameter of the expression is identical 15 to that of each operand. In the case where both operands are integer with different kind type 16 parameters, the kind type parameter of the expression is that of the operand with the greater 17 decimal exponent range if the decimal exponent ranges are different; if the decimal exponent 18 ranges are the same, the kind type parameter of the expression is processor dependent, but 19 it is the same as that of one of the operands. In the case where both operands are any 20 of type real or complex with different kind type parameters, the kind type parameter of 21 the expression is that of the operand with the greater decimal precision if the decimal 22 precisions are different; if the decimal precisions are the same, the kind type parameter of 23 the expression is processor dependent, but it is the same as that of one of the operands. 24 (5) For an expression x1 op x2 where op is a logical intrinsic binary operator with both operands 25 of the same kind type parameter, the kind type parameter of the expression is identical to 26 that of each operand. In the case where both operands are of type logical with different 27 kind type parameters, the kind type parameter of the expression is processor dependent, 28 but it is the same as that of one of the operands. 29 (6) For an expression x1 // x2 where both operands are of type bits, the kind type parameter 30 of the result is the sum of the kind type parameters of the operands. 31 (7) For an expression x1 op x2 where op is a bits intrinsic binary operator other than //, the 32 type of the expression is bits and the kind type parameter of the expression is the maximum 33 of the kind type parameters of x1 and x2 . 34 (8) For an expression x1 op x2 where op is a relational intrinsic operator, the expression has 35 the default logical kind type parameter. 36 C710 The kind type parameter for the result of a bits concatenation operation expression shall be a 37 bits kind type parameter value supported by the processor. 38 7.1.5 Conformability rules for elemental operations 39 An elemental operation is an intrinsic operation or a defined elemental operation. Two entities are 40 in shape conformance if both are arrays of the same shape, or one or both are scalars. 41 For all elemental binary operations, the two operands shall be in shape conformance. In the case where 42 one is a scalar and the other an array, the scalar is treated as if it were an array of the same shape as 43 the array operand with every element, if any, of the array equal to the value of the scalar. 44 7.1.6 Specification expression 45 141 J3/06-007r1 WORKING DRAFT 2006/09/25 A specification expression is an expression with limitations that make it suitable for use in speci- 1 fications such as length type parameters (C404) and array bounds (R513, R514). A specification-expr 2 shall be an initialization expression unless it is in an interface body (12.4.3.2), the specification part of 3 a subprogram, or the declaration-type-spec of a FUNCTION statement (12.6.2.1). 4 R729 specification-expr is scalar-int-expr 5 C711 (R729) The scalar-int-expr shall be a restricted expression. 6 A restricted expression is an expression in which each operation is intrinsic and each primary is 7 (1) a constant or subobject of a constant, 8 (2) an object designator with a base object that is a dummy argument that has neither the 9 OPTIONAL nor the INTENT (OUT) attribute, 10 (3) an object designator with a base object that is in a common block, 11 (4) an object designator with a base object that is made accessible by use association or host 12 association, 13 (5) an object designator with a base object that is a local variable of the procedure containing 14 the BLOCK construct in which the restricted expression appears, 15 (6) an object designator with a base object that is a local variable of an outer BLOCK construct 16 containing the BLOCK construct in which the restricted expression appears, 17 (7) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 18 control is a restricted expression, 19 (8) a structure constructor where each component is a restricted expression, 20 (9) a specification inquiry where each designator or function argument is 21 (a) a restricted expression or 22 (b) a variable whose properties inquired about are not 23 (i) dependent on the upper bound of the last dimension of an assumed-size array, 24 (ii) deferred, or 25 (iii) defined by an expression that is not a restricted expression, 26 (10) a reference to any other standard intrinsic function where each argument is a restricted 27 expression, 28 (11) a reference to a specification function where each argument is a restricted expression, 29 (12) a type parameter of the derived type being defined, 30 (13) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 31 ing ac-implied-do-control is a restricted expression, or 32 (14) a restricted expression enclosed in parentheses, 33 where each subscript, section subscript, substring starting point, substring ending point, and type pa- 34 rameter value is a restricted expression, and where any final subroutine that is invoked is pure. 35 A specification inquiry is a reference to 36 (1) an array inquiry function (13.5.7), 37 (2) the bit inquiry function BIT SIZE, 38 (3) the character inquiry function LEN, 39 (4) the kind inquiry function KIND, 40 (5) the bits kind inquiry function BITS KIND, 41 (6) the character inquiry function NEW LINE, 42 (7) a numeric inquiry function (13.5.6), 43 (8) a type parameter inquiry (6.1.4), 44 142 2006/09/25 WORKING DRAFT J3/06-007r1 (9) an IEEE inquiry function (14.9.1), 1 (10) the function C SIZEOF from the intrinsic module ISO C BINDING (15.2.3.6) , or 2 (11) the COMPILER VERSION or COMPILER OPTIONS inquiry functions from the intrinsic 3 module ISO FORTRAN ENV (13.8.3.3, 13.8.3.4). 4 A function is a specification function if it is a pure function, is not a standard intrinsic function, is 5 not an internal function, is not a statement function, and does not have a dummy procedure argument. 6 Evaluation of a specification expression shall not directly or indirectly cause a procedure defined by the 7 subprogram in which it appears to be invoked. 8 NOTE 7.9 Specification functions are nonintrinsic functions that may be used in specification expressions to determine the attributes of data objects. The requirement that they be pure ensures that they cannot have side effects that could affect other objects being declared in the same specification-part. The requirement that they not be internal ensures that they cannot inquire, via host association, about other objects being declared in the same specification-part. The prohibition against recursion avoids the creation of a new instance of a procedure while construction of one is in progress. A variable in a specification expression shall have its type and type parameters, if any, specified by a 9 previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, 10 or by host or use association. If a variable in a specification expression is typed by the implicit typing 11 rules, its appearance in any subsequent type declaration statement shall confirm the implied type and 12 type parameters. 13 If a specification expression includes a specification inquiry that depends on a type parameter or an 14 array bound of an entity specified in the same specification-part, the type parameter or array bound 15 shall be specified in a prior specification of the specification-part. The prior specification may be to the 16 left of the specification inquiry in the same statement, but shall not be within the same entity-decl . If a 17 specification expression includes a reference to the value of an element of an array specified in the same 18 specification-part, the array shall be completely specified in prior declarations. 19 If a specification expression in a module or submodule includes a reference to a generic entity, that 20 generic entity shall have no specific procedures defined in the module or submodule subsequent to the 21 specification expression. 22 NOTE 7.10 The following are examples of specification expressions: LBOUND (B, 1) + 5 ! B is an assumed-shape dummy array M + LEN (C) ! M and C are dummy arguments 2 * PRECISION (A) ! A is a real variable made accessible ! by a USE statement 7.1.7 Initialization expression 23 An initialization expression is an expression with limitations that make it suitable for use as a kind 24 type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, 25 and each primary is 26 (1) a constant or subobject of a constant, 27 (2) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 28 control is an initialization expression, 29 143 J3/06-007r1 WORKING DRAFT 2006/09/25 (3) a structure constructor where each component-spec corresponding to 1 (a) an allocatable component is a reference to the intrinsic function NULL, 2 (b) a pointer component is a reference to the intrinsic function NULL or an initialization 3 target, and 4 (c) any other component is an initialization expression, 5 (4) a reference to an elemental standard intrinsic function, where each argument is an initial- 6 ization expression, 7 (5) a reference to a transformational standard intrinsic function other than NULL, where each 8 argument is an initialization expression, 9 (6) A reference to the transformational intrinsic function NULL that does not have an argu- 10 ment with a type parameter that is assumed or is defined by an expression that is not an 11 initialization expression, 12 (7) a reference to the transformational function IEEE SELECTED REAL KIND from the in- 13 trinsic module IEEE ARITHMETIC (14), where each argument is an initialization expres- 14 sion. 15 (8) a specification inquiry where each designator or function argument is 16 (a) an initialization expression or 17 (b) a variable whose properties inquired about are not 18 (i) assumed, 19 (ii) deferred, or 20 (iii) defined by an expression that is not an initialization expression, 21 (9) a kind type parameter of the derived type being defined, 22 (10) a data-i-do-variable within a data-implied-do, 23 (11) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 24 ing ac-implied-do-control is an initialization expression, or 25 (12) an initialization expression enclosed in parentheses, 26 and where each subscript, section subscript, substring starting point, substring ending point, and type 27 parameter value is an initialization expression. 28 R730 initialization-expr is expr 29 C712 (R730) initialization-expr shall be an initialization expression. 30 R731 char-initialization-expr is char-expr 31 C713 (R731) char-initialization-expr shall be an initialization expression. 32 R732 int-initialization-expr is int-expr 33 C714 (R732) int-initialization-expr shall be an initialization expression. 34 R733 logical-initialization-expr is logical-expr 35 C715 (R733) logical-initialization-expr shall be an initialization expression. 36 If an initialization expression includes a specification inquiry that depends on a type parameter or an 37 array bound of an entity specified in the same specification-part, the type parameter or array bound 38 shall be specified in a prior specification of the specification-part. The prior specification may be to the 39 left of the specification inquiry in the same statement, but shall not be within the same entity-decl . 40 If an initialization expression in a module or submodule includes a reference to a generic entity, that 41 generic entity shall have no specific procedures defined in the module or submodule subsequent to the 42 144 2006/09/25 WORKING DRAFT J3/06-007r1 initialization expression. 1 NOTE 7.11 The following are examples of initialization expressions: 3 -3 + 4 'AB' 'AB' // 'CD' ('AB' // 'CD') // 'EF' SIZE (A) DIGITS (X) + 4 4.0 * atan(1.0) ceiling(number_of_decimal_digits / log10(radix(0.0))) where A is an explicit-shaped array with constant bounds and X is of type default real. 7.1.8 Evaluation 2 7.1.8.1 Evaluation of operations 3 An intrinsic operation requires the values of its operands. 4 The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other 5 entity within the statement. If a function reference causes definition or undefinition of an actual argument 6 of the function, that argument or any associated entities shall not appear elsewhere in the same statement. 7 However, execution of a function reference in the logical expression in an IF statement (8.1.8.4), the mask 8 expression in a WHERE statement (7.4.3.1), or the subscripts and strides in a FORALL statement (7.4.4) 9 is permitted to define variables in the statement that is conditionally executed. 10 NOTE 7.12 For example, the statements A (I) = F (I) Y = G (X) + X are prohibited if the reference to F defines or undefines I or the reference to G defines or undefines X. However, in the statements IF (F (X)) A = X WHERE (G (X)) B = X F or G may define X. The declared type of an expression in which a function reference appears does not affect, and is not 11 affected by, the evaluation of the actual arguments of the function. 12 Execution of an array element reference requires the evaluation of its subscripts. The type of an expres- 13 sion in which the array element reference appears does not affect, and is not affected by, the evaluation 14 of its subscripts. Execution of an array section reference requires the evaluation of its section subscripts. 15 The type of an expression in which an array section appears does not affect, and is not affected by, the 16 evaluation of the array section subscripts. Execution of a substring reference requires the evaluation of 17 145 J3/06-007r1 WORKING DRAFT 2006/09/25 its substring expressions. The type of an expression in which a substring appears does not affect, and 1 is not affected by, the evaluation of the substring expressions. It is not necessary for a processor to 2 evaluate any subscript expressions or substring expressions for an array of zero size or a character entity 3 of zero length. 4 The appearance of an array constructor requires the evaluation of each scalar-int-expr of the ac-implied- 5 do-control in any ac-implied-do it may contain. The type of an expression in which an array constructor 6 appears does not affect, and is not affected by, the evaluation of such bounds and stride expressions. 7 When an elemental binary operation is applied to a scalar and an array or to two arrays of the same 8 shape, the operation is performed element-by-element on corresponding array elements of the array 9 operands. 10 NOTE 7.13 For example, the array expression A+B produces an array of the same shape as A and B. The individual array elements of the result have the values of the first element of A added to the first element of B, the second element of A added to the second element of B, etc. When an elemental unary operator operates on an array operand, the operation is performed element- 11 by-element, and the result is the same shape as the operand. 12 NOTE 7.14 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. 7.1.8.2 Evaluation of operands 13 It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely 14 each operand, if the value of the expression can be determined otherwise. 15 NOTE 7.15 This principle is most often applicable to logical expressions, zero-sized arrays, and zero-length strings, but it applies to all expressions. For example, in evaluating the expression X > Y .OR. L (Z) where X, Y, and Z are real and L is a function of type logical, the function reference L (Z) need not be evaluated if X is greater than Y. Similarly, in the array expression W (Z) + A where A is of size zero and W is a function, the function reference W (Z) need not be evaluated. If a statement contains a function reference in a part of an expression that need not be evaluated, all 16 entities that would have become defined in the execution of that reference become undefined at the 17 completion of evaluation of the expression containing the function reference. 18 146 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 7.16 In the examples in Note 7.15, if L or W defines its argument, evaluation of the expressions under the specified conditions causes Z to become undefined, no matter whether or not L(Z) or W(Z) is evaluated. If a statement contains a function reference in a part of an expression that need not be evaluated, no 1 invocation of that function in that part of the expression shall execute an image control statement other 2 than CRITICAL or END CRITICAL. 3 NOTE 7.17 This restriction is intended to avoid inadvertant deadlock caused by optimization. 7.1.8.3 Integrity of parentheses 4 Subclauses 7.1.8.3 to 7.1.8.8 state certain conditions under which a processor may evaluate an expression 5 that is different from the one specified by applying the rules given in 7.1.1 and 7.2. However, any 6 expression in parentheses shall be treated as a data entity. 7 NOTE 7.18 For example, in evaluating the expression A + (B ­ C) where A, B, and C are of numeric types, the difference of B and C shall be evaluated before the addition operation is performed; the processor shall not evaluate the mathematically equivalent expression (A + B) ­ C. 7.1.8.4 Evaluation of numeric intrinsic operations 8 The rules given in 7.2.2 specify the interpretation of a numeric intrinsic operation. Once the interpreta- 9 tion has been established in accordance with those rules, the processor may evaluate any mathematically 10 equivalent expression, provided that the integrity of parentheses is not violated. 11 Two expressions of a numeric type are mathematically equivalent if, for all possible values of their 12 primaries, their mathematical values are equal. However, mathematically equivalent expressions of 13 numeric type may produce different computational results. 14 NOTE 7.19 Any difference between the values of the expressions (1./3.)*3. and 1. is a computational difference, not a mathematical difference. The difference between the values of the expressions 5/2 and 5./2. is a mathematical difference, not a computational difference. The mathematical definition of integer division is given in 7.2.2.1. NOTE 7.20 The following are examples of expressions with allowable alternative forms that may be used by the processor in the evaluation of those expressions. A, B, and C represent arbitrary real or complex operands; I and J represent arbitrary integer operands; and X, Y, and Z represent arbitrary operands of numeric type. Expression Allowable alternative form X+Y Y+X X*Y Y*X -X + Y Y-X X+Y+Z X + (Y + Z) X-Y+Z X - (Y - Z) 147 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.20 (cont.) X * A/Z X * (A / Z) X * Y-X*Z X * (Y - Z) A / B/C A / (B * C) A / 5.0 0.2 * A The following are examples of expressions with forbidden alternative forms that shall not be used by a processor in the evaluation of those expressions. Expression Forbidden alternative form I/2 0.5 * I X*I/J X * (I / J) I/J/A I / (J * A) (X + Y) + Z X + (Y + Z) (X * Y) - (X * Z) X * (Y - Z) X * (Y - Z) X*Y-X*Z The execution of any numeric operation whose result is not defined by the arithmetic used by the 1 processor is prohibited. Raising a negative-valued primary of type real to a real power is prohibited. 2 In addition to the parentheses required to establish the desired interpretation, parentheses may be 3 included to restrict the alternative forms that may be used by the processor in the actual evaluation 4 of the expression. This is useful for controlling the magnitude and accuracy of intermediate values 5 developed during the evaluation of an expression. 6 NOTE 7.21 For example, in the expression A + (B - C) the parenthesized expression (B ­ C) shall be evaluated and then added to A. The inclusion of parentheses may change the mathematical value of an expression. For example, the two expressions A*I/J A * (I / J) may have different mathematical values if I and J are of type integer. Each operand in a numeric intrinsic operation has a type that may depend on the order of evaluation 7 used by the processor. 8 NOTE 7.22 For example, in the evaluation of the expression Z+R+I where Z, R, and I represent data objects of complex, real, and integer type, respectively, the type of the operand that is added to I may be either complex or real, depending on which pair of operands (Z and R, R and I, or Z and I) is added first. 148 2006/09/25 WORKING DRAFT J3/06-007r1 7.1.8.5 Evaluation of the character intrinsic operation 1 The rules given in 7.2.3 specify the interpretation of the character intrinsic operation. A processor is 2 only required to evaluate as much of the character intrinsic operation as is required by the context in 3 which the expression appears. 4 NOTE 7.23 For example, the statements CHARACTER (LEN = 2) C1, C2, C3, CF C1 = C2 // CF (C3) do not require the function CF to be evaluated, because only the value of C2 is needed to determine the value of C1 because C1 and C2 both have a length of 2. 7.1.8.6 Evaluation of relational intrinsic operations 5 The rules given in 7.2.4 specify the interpretation of relational intrinsic operations. Once the interpre- 6 tation of an expression has been established in accordance with those rules, the processor may evaluate 7 any other expression that is relationally equivalent, provided that the integrity of parentheses in any 8 expression is not violated. 9 NOTE 7.24 For example, the processor may choose to evaluate the expression I>J where I and J are integer variables, as J-I<0 Two relational intrinsic operations are relationally equivalent if their logical values are equal for all 10 possible values of their primaries. 11 7.1.8.7 Evaluation of logical intrinsic operations 12 The rules given in 7.2.5 specify the interpretation of logical intrinsic operations. Once the interpretation 13 of an expression has been established in accordance with those rules, the processor may evaluate any 14 other expression that is logically equivalent, provided that the integrity of parentheses in any expression 15 is not violated. 16 NOTE 7.25 For example, for the variables L1, L2, and L3 of type logical, the processor may choose to evaluate the expression L1 .AND. L2 .AND. L3 as L1 .AND. (L2 .AND. L3) Two expressions of type logical are logically equivalent if their values are equal for all possible values of 17 their primaries. 18 149 J3/06-007r1 WORKING DRAFT 2006/09/25 7.1.8.8 Evaluation of bits intrinsic operations 1 The rules given in 7.2.6 specify the interpretation of bits intrinsic operations. Once the interpretation 2 of an expression has been established in accordance with those rules, the processor may evaluate any 3 other expression that is computationally equivalent, provided that the integrity of parentheses in any 4 expression is not violated. 5 NOTE 7.26 For example, for the variables B1, B2, and B3 of type bits, the processor may choose to evaluate the expression B1 .XOR. B2 .XOR. B3 as B1 .XOR. (B2 .XOR. B3) Two expressions of type bits are computationally equivalent if their values are equal for all possible 6 values of their primaries. 7 7.1.8.9 Evaluation of a defined operation 8 The rules given in 7.2 specify the interpretation of a defined operation. Once the interpretation of an 9 expression has been established in accordance with those rules, the processor may evaluate any other 10 expression that is equivalent, provided that the integrity of parentheses is not violated. 11 Two expressions of derived type are equivalent if their values are equal for all possible values of their 12 primaries. 13 7.2 Interpretation of operations 14 7.2.1 General 15 The intrinsic operations are those defined in 7.1.2. These operations are divided into the following 16 categories: numeric, character, relational, logical, and bits. The interpretations defined in subclause 7.2 17 apply to both scalars and arrays; the interpretation for arrays is obtained by applying the interpretation 18 for scalars element by element. 19 The interpretation of a defined operation is provided by the function that defines the operation. The type, 20 type parameters and interpretation of an expression that consists of an intrinsic or defined operation are 21 independent of the type and type parameters of the context or any larger expression in which it appears. 22 NOTE 7.27 For example, if X is of type real, J is of type integer, and INT is the real-to-integer intrinsic conversion function, the expression INT (X + J) is an integer expression and X + J is a real expression. The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 23 .LE., .GT., .GE., .EQ., and .NE., respectively. 24 7.2.2 Numeric intrinsic operations 25 150 2006/09/25 WORKING DRAFT J3/06-007r1 A numeric operation is used to express a numeric computation. Evaluation of a numeric operation 1 produces a numeric value. The permitted data types for operands of the numeric intrinsic operations 2 are specified in 7.1.2. 3 The numeric operators and their interpretation in an expression are given in Table 7.3, where x1 denotes 4 the operand to the left of the operator and x2 denotes the operand to the right of the operator. 5 Table 7.3: Interpretation of the numeric intrinsic operators Operator Representing Use of operator Interpretation ** Exponentiation x1 ** x2 Raise x1 to the power x2 / Division x1 / x2 Divide x1 by x2 * Multiplication x1 * x2 Multiply x1 by x2 - Subtraction x1 - x2 Subtract x2 from x1 - Negation - x2 Negate x2 + Addition x1 + x2 Add x1 and x2 + Identity + x2 Same as x2 The interpretation of a division operation depends on the types of the operands (7.2.2.1). 6 If x1 and x2 are of type integer and x2 has a negative value, the interpretation of x1 ** x2 is the same 7 as the interpretation of 1/(x1 ** ABS (x2 )), which is subject to the rules of integer division (7.2.2.1). 8 NOTE 7.28 For example, 2 ** (­3) has the value of 1/(2 ** 3), which is zero. 7.2.2.1 Integer division 9 One operand of type integer may be divided by another operand of type integer. Although the math- 10 ematical quotient of two integers is not necessarily an integer, Table 7.1 specifies that an expression 11 involving the division operator with two operands of type integer is interpreted as an expression of type 12 integer. The result of such an operation is the integer closest to the mathematical quotient and between 13 zero and the mathematical quotient inclusively. 14 NOTE 7.29 For example, the expression (­8) / 3 has the value (­2). 7.2.2.2 Complex exponentiation 15 In the case of a complex value raised to a complex power, the value of the operation x1 ** x2 is the 16 principal value of xx2 . 17 1 7.2.3 Character intrinsic operation 18 The character intrinsic operator // is used to concatenate two operands of type character with the same 19 kind type parameter. Evaluation of the character intrinsic operation produces a result of type character. 20 The interpretation of the character intrinsic operator // when used to form an expression is given in 21 Table 7.4, where x1 denotes the operand to the left of the operator and x2 denotes the operand to the 22 right of the operator. 23 Table 7.4: Interpretation of the character intrinsic operator // Operator Representing Use of operator Interpretation // Concatenation x1 // x2 Concatenate x1 with x2 151 J3/06-007r1 WORKING DRAFT 2006/09/25 The result of the character intrinsic operation // is a character string whose value is the value of x1 1 concatenated on the right with the value of x2 and whose length is the sum of the lengths of x1 and x2 . 2 Parentheses used to specify the order of evaluation have no effect on the value of a character expression. 3 NOTE 7.30 For example, the value of ('AB' // 'CDE') // 'F' is the string 'ABCDEF'. Also, the value of 'AB' // ('CDE' // 'F') is the string 'ABCDEF'. 7.2.4 Relational intrinsic operations 4 A relational intrinsic operation is used to compare values of two operands using the relational intrinsic 5 operators .LT., .LE., .GT., .GE., .EQ., .NE., <, <=, >, >=, ==, and /=. The permitted types for 6 operands of the relational intrinsic operators are specified in 7.1.2. 7 NOTE 7.31 As shown in Table 7.1, a relational intrinsic operator cannot be used to compare the value of an expression of a numeric type with one of type character or logical. Also, two operands of type logical cannot be compared, a complex operand may be compared with another numeric operand only when the operator is .EQ., .NE., ==, or /=, and two character operands cannot be compared unless they have the same kind type parameter value. Evaluation of a relational intrinsic operation produces a result of type default logical. 8 The interpretation of the relational intrinsic operators is given in Table 7.5, where x1 denotes the operand 9 to the left of the operator and x2 denotes the operand to the right of the operator. 10 Table 7.5: Interpretation of the relational intrinsic operators Operator Representing Use of operator Interpretation .LT. Less than x1 .LT. x2 x1 less than x2 < Less than x1 < x2 x1 less than x2 .LE. Less than or equal to x1 .LE. x2 x1 less than or equal to x2 <= Less than or equal to x1 <= x2 x1 less than or equal to x2 .GT. Greater than x1 .GT. x2 x1 greater than x2 > Greater than x1 > x2 x1 greater than x2 .GE. Greater than or equal to x1 .GE. x2 x1 greater than or equal to x2 >= Greater than or equal to x1 >= x2 x1 greater than or equal to x2 .EQ. Equal to x1 .EQ. x2 x1 equal to x2 == Equal to x1 == x2 x1 equal to x2 .NE. Not equal to x1 .NE. x2 x1 not equal to x2 /= Not equal to x1 /= x2 x1 not equal to x2 A numeric relational intrinsic operation is interpreted as having the logical value true if and only if the 11 values of the operands satisfy the relation specified by the operator. 12 In the numeric relational operation 13 x1 rel-op x2 14 if the types or kind type parameters of x1 and x2 differ, their values are converted to the type and kind 15 type parameter of the expression x1 + x2 before evaluation. 16 A character relational intrinsic operation is interpreted as having the logical value true if and only if the 17 values of the operands satisfy the relation specified by the operator. 18 152 2006/09/25 WORKING DRAFT J3/06-007r1 For a character relational intrinsic operation, the operands are compared one character at a time in 1 order, beginning with the first character of each character operand. If the operands are of unequal 2 length, the shorter operand is treated as if it were extended on the right with blanks to the length of 3 the longer operand. If both x1 and x2 are of zero length, x1 is equal to x2 ; if every character of x1 is 4 the same as the character in the corresponding position in x2 , x1 is equal to x2 . Otherwise, at the first 5 position where the character operands differ, the character operand x1 is considered to be less than x2 6 if the character value of x1 at this position precedes the value of x2 in the collating sequence (4.4.5.4); 7 x1 is greater than x2 if the character value of x1 at this position follows the value of x2 in the collating 8 sequence. 9 NOTE 7.32 The collating sequence depends partially on the processor; however, the result of the use of the operators .EQ., .NE., ==, and /= does not depend on the collating sequence. For nondefault character types, the blank padding character is processor dependent. A bits relational intrinsic operation is interpreted as having the logical value true if and only if the values 10 of the operands satisfy the relation specified by the operator. 11 For a bits relational intrinsic operation, x1 and x2 are equal if and only if each corresponding bit has 12 the same value. If x1 and x2 are not equal, and the leftmost unequal corresponding bit of x1 is 1 and 13 x2 is 0 then x1 is greater than x2 ; otherwise x1 is less than x2 . 14 7.2.5 Logical intrinsic operations 15 A logical operation is used to express a logical computation. Evaluation of a logical operation produces 16 a result of type logical. The permitted types for operands of the logical intrinsic operations are specified 17 in 7.1.2. 18 The logical operators and their interpretation when used to form an expression are given in Table 7.6, 19 where x1 denotes the operand to the left of the operator and x2 denotes the operand to the right of the 20 operator. 21 Table 7.6: Interpretation of the logical intrinsic operators Representing Use of operator Interpretation Operator Logical negation True if x2 is false .NOT. .NOT. x2 Logical conjunction True if x1 and x2 are both true .AND. x1 .AND. x2 Logical inclusive disjunction True if x1 and/or x2 is true .OR. x1 .OR. x2 True if both x1 and x2 are true or Logical equivalence .EQV. x1 .EQV. x2 both are false True if either x1 or x2 is true, but Logical nonequivalence .NEQV. x1 .NEQV. x2 not both True if either x1 or x2 is true, but Logical nonequivalence .XOR. x1 .XOR. x2 not both The values of the logical intrinsic operations are shown in Table 7.7. 22 Table 7.7: The values of operations involving logical intrinsic operators x1 x2 .NOT. x2 x1 .AND. x2 x1 .OR. x2 x1 .EQV. x2 x1 .NEQV. x2 x1 .XOR. x2 true true false true true true false false true false true false true false true true false true false false true false true true false false true false false true false false 153 J3/06-007r1 WORKING DRAFT 2006/09/25 7.2.6 Bits intrinsic operations 1 Bit operations are used to express bitwise operations on sequences of bits, or to concatenate such 2 sequences. Evaluation of a bits operation produces a result of type bits. The permitted types of 3 operands of the bits intrinsic operations are specified in 7.1.2. 4 The bits operators and their interpretation when used to form an expression are given in Table 7.8, 5 where x1 denotes the operand of type bits to the left of the operator and x2 denotes the operand of type 6 bits to the right of the operator. 7 Table 7.8: Interpretation of the bits intrinsic operators Operator Representing Use of operator Interpretation (//) Concatenation x1 // x2 Concatenation of x1 and x2 .NOT. Bitwise NOT .NOT. x2 Bitwise NOT of x2 .AND. Bitwise AND x1 .AND. x2 Bitwise AND of x1 and x2 .OR. Bitwise inclusive OR x1 .OR. x2 Bitwise OR of x1 and x2 .EQV. Bitwise equivalence x1 .EQV. x2 Bitwise equivalence of x1 and x2 .NEQV. Bitwise nonequivalence x1 .NEQV. x2 Bitwise nonequivalence of x1 and x2 .XOR. Bitwise exclusive OR x1 .XOR. x2 Bitwise exclusive OR of x1 and x2 The leftmost KIND(x1 ) bits of the result of the bits concatenation operation are the value of x1 and the 8 rightmost KIND(x2 ) bits of the result are the value of x2 . 9 For a bits intrinsic operation other than //, the result value is computed separately for each pair of bits 10 at corresponding positions in each operand. The value of each bit operation, for bits denoted b1 and b2 11 are given in Table 7.9. 12 Table 7.9: The values of bits intrinsic operations other than // x1 x2 .NOT. x2 x1 .AND. x2 x1 .OR. x2 x1 .EQV. x2 x1 .NEQV. x2 x1 .XOR. x2 1 1 0 1 1 1 0 0 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 0 1 0 0 7.3 Precedence of operators 13 There is a precedence among the intrinsic and extension operations corresponding to the form of expres- 14 sions specified in 7.1.1, which determines the order in which the operands are combined unless the order 15 is changed by the use of parentheses. This precedence order is summarized in Table 7.10. 16 Table 7.10: Categories of operations and relative precedence Category of operation Operators Precedence Extension defined-unary-op Highest Numeric ** . Numeric *, / . Numeric unary +, ­ . Numeric binary +, ­ . Character // . Relational .EQ., .NE., .LT., .LE., .GT., .GE., ==, /=, <, <=, >, >= . Logical, Bits .NOT. . Logical, Bits .AND. . 154 2006/09/25 WORKING DRAFT J3/06-007r1 Categories of operations and relative precedence (cont.) Category of operation Operators Precedence Logical, Bits .OR. . Logical, Bits .EQV., .NEQV., .XOR. . Extension defined-binary-op Lowest The precedence of a defined operation is that of its operator. 1 NOTE 7.33 For example, in the expression -A ** 2 the exponentiation operator (**) has precedence over the negation operator (­); therefore, the operands of the exponentiation operator are combined to form an expression that is used as the operand of the negation operator. The interpretation of the above expression is the same as the interpretation of the expression - (A ** 2) The general form of an expression (7.1.1) also establishes a precedence among operators in the same 2 syntactic class. This precedence determines the order in which the operands are to be combined in 3 determining the interpretation of the expression unless the order is changed by the use of parentheses. 4 NOTE 7.34 In interpreting a level-2-expr containing two or more binary operators + or ­, each operand (add- operand ) is combined from left to right. Similarly, the same left-to-right interpretation for a mult- operand in add-operand , as well as for other kinds of expressions, is a consequence of the general form. However, for interpreting a mult-operand expression when two or more exponentiation operators ** combine level-1-expr operands, each level-1-expr is combined from right to left. For example, the expressions 2.1 + 3.4 + 4.9 2.1 * 3.4 * 4.9 2.1 / 3.4 / 4.9 2 ** 3 ** 4 'AB' // 'CD' // 'EF' have the same interpretations as the expressions (2.1 + 3.4) + 4.9 (2.1 * 3.4) * 4.9 (2.1 / 3.4) / 4.9 2 ** (3 ** 4) ('AB' // 'CD') // 'EF' As a consequence of the general form (7.1.1), only the first add-operand of a level-2-expr may be preceded by the identity (+) or negation (­) operator. These formation rules do not permit expressions containing two consecutive numeric operators, such as A ** ­B or A + ­B. However, expressions such as A ** (­B) and A + (­B) are permitted. The rules do allow a binary operator or an intrinsic unary operator to be followed by a defined unary operator, such as: 155 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.34 (cont.) A * .INVERSE. B - .INVERSE. (B) As another example, in the expression A .OR. B .AND. C the general form implies a higher precedence for the .AND. operator than for the .OR. opera- tor; therefore, the interpretation of the above expression is the same as the interpretation of the expression A .OR. (B .AND. C) NOTE 7.35 An expression may contain more than one category of operator. The logical expression L .OR. A + B >= C where A, B, and C are of type real, and L is of type logical, contains a numeric operator, a relational operator, and a logical operator. This expression would be interpreted the same as the expression L .OR. ((A + B) >= C) NOTE 7.36 If (1) The operator ** is extended to type logical, (2) The operator .STARSTAR. is defined to duplicate the function of ** on type real, (3) .MINUS. is defined to duplicate the unary operator ­, and (4) L1 and L2 are type logical and X and Y are type real, then in precedence: L1 ** L2 is higher than X * Y; X * Y is higher than X .STARSTAR. Y; and .MINUS. X is higher than ­X. 7.4 Assignment 1 Execution of an assignment statement causes a variable to become defined or redefined. Execution of a 2 pointer assignment statement causes a pointer to become associated with a target or causes its pointer 3 association status to become disassociated or undefined. Execution of a WHERE statement or WHERE 4 construct masks the evaluation of expressions and assignment of values in array assignment statements 5 according to the value of a logical array expression. Execution of a FORALL statement or FORALL 6 construct controls the assignment to elements of arrays by using a set of index variables and a mask 7 expression. 8 7.4.1 Assignment statement 9 A variable may be defined or redefined by execution of an assignment statement. 10 7.4.1.1 General form 11 156 2006/09/25 WORKING DRAFT J3/06-007r1 R734 assignment-stmt is variable = expr 1 C716 (R734) The variable shall not be a whole assumed-size array. 2 NOTE 7.37 Examples of an assignment statement are: A = 3.5 + X * Y I = INT (A) An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic 3 assignment statement. 4 7.4.1.2 Intrinsic assignment statement 5 An intrinsic assignment statement is an assignment statement that is not a defined assignment 6 statement (7.4.1.4). In an intrinsic assignment statement, 7 (1) if the variable is polymorphic it shall be allocatable, 8 (2) if variable is a co-indexed object, it shall not be of a type that has an allocatable ultimate 9 component, 10 J3 internal note Unresolved Technical Issue 023 06-174r3 had no edit about this at all; when it came up in discussion with JKR et al they suggested making a runtime requirement that the types and shapes of the allocatable components must match; however, that would be very unsafe. Since the only safe way of programming such an assignment would be to avoid the intrinsic assignment altogether, we should not allow the intrinsic assignment in this case. Furthermore, giving different semantics to intrinsic assignment when a component is a co-indexed object is a bad idea - it will confuse the users ­ better to disallow the discrepant inconsistency. The fact that this inherently unsafe idea affects cross-image variables with all the fun of race conditions and other goodies to make debugging impossible simply underlines that this is a bad idea." (3) if expr is an array then the variable shall also be an array, 11 (4) the shapes of the variable and expr shall conform unless the variable is an allocatable array 12 that has the same rank as expr and is neither a co-array nor a co-indexed object, 13 (5) if the variable is an allocatable co-array or co-indexed object, it shall not be polymorphic, 14 (6) if the variable is polymorphic it shall be type compatible with expr and have the same rank; 15 otherwise the declared types of the variable and expr shall conform as specified in Table 16 7.11, 17 (7) if the variable is of derived type each kind type parameter of the variable shall have the 18 same value as the corresponding type parameter of expr , and 19 (8) if the variable is of derived type each length type parameter of the variable shall have the 20 same value as the corresponding type parameter of expr unless the variable is allocatable 21 and its corresponding type parameter is deferred. 22 23 Table 7.11: Type conformance for the intrinsic assignment statement Type of the variable Type of expr integer integer, real, complex, bits real integer, real, complex, bits complex integer, real, complex, bits 157 J3/06-007r1 WORKING DRAFT 2006/09/25 Type conformance for the intrinsic assignment statement (cont.) Type of the variable Type of expr ISO 10646, ASCII, or default character ISO 10646, ASCII, or default character other character character of the same kind type parameter as the variable logical logical, bits bits integer, real, complex, bits derived type same derived type as the variable A numeric intrinsic assignment statement is an intrinsic assignment statement for which the vari- 1 able and expr are of numeric type. A character intrinsic assignment statement is an intrinsic 2 assignment statement for which the variable and expr are of type character. A logical intrinsic as- 3 signment statement is an intrinsic assignment statement for which the variable and expr are of type 4 logical. A bits intrinsic assignment statement is an intrinsic assignment statement for which either 5 the variable or expr is of type bits. A derived-type intrinsic assignment statement is an intrinsic 6 assignment statement for which the variable and expr are of derived type. 7 An array intrinsic assignment statement is an intrinsic assignment statement for which the variable 8 is an array. The the variable shall not be a many-one array section (6.2.2.3.2). 9 If the variable is a pointer, it shall be associated with a definable target such that the type, type 10 parameters, and shape of the target and expr conform. 11 7.4.1.3 Interpretation of intrinsic assignments 12 Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expr and all 13 expressions within variable (7.1.8), the possible conversion of expr to the type and type parameters of 14 the variable (Table 7.12), and the definition of the variable with the resulting value. The execution of 15 the assignment shall have the same effect as if the evaluation of expr and the evaluation of all expressions 16 in variable occurred before any portion of the variable is defined by the assignment. The evaluation of 17 expressions within variable shall neither affect nor be affected by the evaluation of expr . No value is 18 assigned to the variable if it is of type character and zero length, or is an array of size zero. 19 If the variable is a pointer, the value of expr is assigned to the target of the variable. 20 If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, 21 any of the corresponding length type parameter values of the variable and expr differ, or the variable 22 is polymorphic and the dynamic type of the variable and expr differ. If the variable is or becomes an 23 unallocated allocatable variable, then it is allocated with each deferred type parameter equal to the 24 corresponding type parameter of expr , with the shape of expr , with each lower bound equal to the 25 corresponding element of LBOUND(expr ), and with the same dynamic type as expr . 26 NOTE 7.38 For example, given the declaration CHARACTER(:),ALLOCATABLE :: NAME then after the assignment statement NAME = 'Dr. '//FIRST_NAME//' '//SURNAME NAME will have the length LEN(FIRST NAME)+LEN(SURNAME)+5, even if it had previously been unallocated, or allocated with a different length. However, for the assignment statement NAME(:) = 'Dr. '//FIRST_NAME//' '//SURNAME 158 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 7.38 (cont.) NAME must already be allocated at the time of the assignment; the assigned value is truncated or blank padded to the previously allocated length of NAME. Both variable and expr may contain references to any portion of the variable. 1 NOTE 7.39 For example, in the character intrinsic assignment statement: STRING (2:5) = STRING (1:4) the assignment of the first character of STRING to the second character does not affect the evaluation of STRING (1:4). If the value of STRING prior to the assignment was 'ABCDEF', the value following the assignment is 'AABCDF'. If expr is a scalar and the variable is an array, the expr is treated as if it were an array of the same 2 shape as the variable with every element of the array equal to the scalar value of expr . 3 If the variable is an array, the assignment is performed element-by-element on corresponding array 4 elements of the variable and expr . 5 NOTE 7.40 For example, if A and B are arrays of the same shape, the array intrinsic assignment A=B assigns the corresponding elements of B to those of A; that is, the first element of B is assigned to the first element of A, the second element of B is assigned to the second element of A, etc. If C is an allocatable array of rank 1, then C = PACK(ARRAY,ARRAY>0) will cause C to contain all the positive elements of ARRAY in array element order; if C is not allocated or is allocated with the wrong size, it will be re-allocated to be of the correct size to hold the result of PACK. The processor may perform the element-by-element assignment in any order. 6 NOTE 7.41 For example, the following program segment results in the values of the elements of array X being reversed: REAL X (10) ... X (1:10) = X (10:1:-1) For a numeric intrinsic assignment statement, the variable and expr may have different numeric types 7 or different kind type parameters, in which case the value of expr is converted to the type and kind type 8 parameter of the variable according to the rules of Table 7.12. 9 159 J3/06-007r1 WORKING DRAFT 2006/09/25 Table 7.12: Numeric conversion and the assignment statement Type of the variable Value Assigned integer INT (expr , KIND = KIND (variable)) real REAL (expr , KIND = KIND (variable)) complex CMPLX (expr , KIND = KIND (variable)) Note: The functions INT, REAL, CMPLX, and KIND are the generic functions defined in 13.7. For a logical intrinsic assignment statement, the variable and expr may have different kind type param- 1 eters, in which case the value of expr is converted to the kind type parameter of the variable. 2 For a character intrinsic assignment statement, the variable and expr may have different character length 3 parameters in which case the conversion of expr to the length of the variable is as follows. 4 (1) If the length of the variable is less than that of expr , the value of expr is truncated from 5 the right until it is the same length as the variable. 6 (2) If the length of the variable is greater than that of expr , the value of expr is extended on 7 the right with blanks until it is the same length as the variable. 8 If the variable and expr have different kind type parameters, each character c in expr is converted to 9 the kind type parameter of the variable by ACHAR(IACHAR(c),KIND(variable)). 10 NOTE 7.42 For nondefault character types, the blank padding character is processor dependent. When assign- ing a character expression to a variable of a different kind, each character of the expression that is not representable in the kind of the variable is replaced by a processor-dependent character. For a bits intrinsic assignment statement, the variable and expr may have different types or different 11 kind type parameters, in which case the value of expr is converted to the type and kind type parameter 12 of the variable according to the rules of Table 7.13. 13 Table 7.13: Bits conversion and the assignment statement Type of the variable Value Assigned integer INT (expr , KIND = KIND (variable)) real REAL (expr , KIND = KIND (variable)) complex CMPLX (expr , KIND = KIND (variable)) logical LOGICAL (expr , KIND = KIND (variable)) bits BITS (expr , KIND = KIND (variable)) Note: The functions BITS, INT, REAL, CMPLX, and KIND are the generic functions defined in 13.7. NOTE 7.43 Bits assignment is not always the same as the result of the TRANSFER intrinsic, because: · bits assignment operates elementally, whereas TRANSFER does not preserve array element boundaries; · for scalars, if the source is larger TRANSFER uses those bits which occur first in memory whereas bits assignment always uses the "rightmost" bits (according to the model for bits values), independent of the endianness of the processor's memory addressing; · if the source is smaller, TRANSFER uses it for the part of the result which occurs first in 160 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 7.43 (cont.) memory address order and leaves the rest of the result processor-dependent, whereas bits assignment copies the source to the rightmost bits and makes the remaining bits all zero. A derived-type intrinsic assignment is performed as if each component of the variable were assigned 1 from the corresponding component of expr using pointer assignment (7.4.2) for each pointer component, 2 defined assignment for each nonpointer nonallocatable component of a type that has a type-bound defined 3 assignment consistent with the component, intrinsic assignment for each other nonpointer nonallocatable 4 component, and intrinsic assignment for each allocated co-array component. For unallocated co-array 5 components, the corresponding component of the variable shall be unallocated. For a non-co-array 6 allocatable component the following sequence of operations is applied. 7 (1) If the component of the variable is allocated, it is deallocated. 8 (2) If the component of the value of expr is allocated, the corresponding component of the 9 variable is allocated with the same dynamic type and type parameters as the component 10 of the value of expr . If it is an array, it is allocated with the same bounds. The value of 11 the component of the value of expr is then assigned to the corresponding component of the 12 variable using defined assignment if the declared type of the component has a type-bound 13 defined assignment consistent with the component, and intrinsic assignment for the dynamic 14 type of that component otherwise. 15 The processor may perform the component-by-component assignment in any order or by any means that 16 has the same effect. 17 NOTE 7.44 For an example of a derived-type intrinsic assignment statement, if C and D are of the same derived type with a pointer component P and nonpointer components S, T, U, and V of type integer, logical, character, and another derived type, respectively, the intrinsic C=D pointer assigns D%P to C%P. It assigns D%S to C%S, D%T to C%T, and D%U to C%U using intrinsic assignment. It assigns D%V to C%V using defined assignment if objects of that type have a compatible type-bound defined assignment, and intrinsic assignment otherwise. NOTE 7.45 If an allocatable component of expr is unallocated, the corresponding component of the variable has an allocation status of unallocated after execution of the assignment. 7.4.1.4 Defined assignment statement 18 A defined assignment statement is an assignment statement that is defined by a subroutine and a 19 generic interface (4.5.2, 12.4.3.3.2) that specifies ASSIGNMENT (=). A defined elemental assign- 20 ment statement is a defined assignment statement for which the subroutine is elemental (12.8). 21 A subroutine defines the defined assignment x1 = x2 if 22 (1) the subroutine is specified with a SUBROUTINE (12.6.2.2) or ENTRY (12.6.2.5) statement 23 that specifies two dummy arguments, d1 and d2 , 24 (2) either 25 (a) a generic interface (12.4.3.2) provides the subroutine with a generic-spec of ASSIGN- 26 MENT (=), or 27 161 J3/06-007r1 WORKING DRAFT 2006/09/25 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic-spec 1 of ASSIGNMENT (=) and there is a corresponding binding to the subroutine in the 2 dynamic type of x1 or x2 , respectively, 3 (3) the types of d1 and d2 are compatible with the dynamic types of x1 and x2 , respectively, 4 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 5 and x2 , respectively, and 6 (5) either 7 (a) the ranks of x1 and x2 match those of d1 and d2 or 8 (b) the subroutine is elemental, x1 and x2 are conformable, and there is no other subrou- 9 tine that defines the operation. 10 If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2 , respectively. 11 7.4.1.5 Interpretation of defined assignment statements 12 The interpretation of a defined assignment is provided by the subroutine that defines it. 13 If the defined assignment is an elemental assignment and the the variable in the assignment is an array, 14 the defined assignment is performed element-by-element, on corresponding elements of the variable and 15 expr . If expr is a scalar, it is treated as if it were an array of the same shape as the variable with every 16 element of the array equal to the scalar value of expr . 17 NOTE 7.46 The rules of defined assignment (12.4.3.3.2), procedure references (12.5), subroutine references (12.5.4), and elemental subroutine arguments (12.8.3) ensure that the defined assignment has the same effect as if the evaluation of all operations in x2 and x1 occurs before any portion of x1 is defined. If an elemental assignment is defined by a pure elemental subroutine, the element assignments may be performed simultaneously or in any order. 7.4.2 Pointer assignment 18 7.4.2.1 General 19 Pointer assignment causes a pointer to become associated with a target or causes its pointer association 20 status to become disassociated or undefined. Any previous association between the pointer and a target 21 is broken. 22 Pointer assignment for a pointer component of a structure may also take place by execution of a derived- 23 type intrinsic assignment statement (7.4.1.3). 24 A pointer may also become associated with a target by allocation of the pointer. 25 7.4.2.2 Syntax 26 R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] => data-target 27 or data-pointer-object (bounds-remapping-list ) => data-target 28 or proc-pointer-object => proc-target 29 R736 data-pointer-object is variable-name 30 or scalar-variable % data-pointer-component-name 31 C717 (R735) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible 32 (4.3.1.3) with it and the corresponding kind type parameters shall be equal. 33 162 2006/09/25 WORKING DRAFT J3/06-007r1 C718 (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- 1 phic, of a sequence derived type, or of a type with the BIND attribute. 2 C719 (R735) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data- 3 pointer-object. 4 C720 (R735) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the 5 rank of data-pointer-object. 6 C721 (R735) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target 7 shall be the same. 8 C722 (R736) A variable-name shall have the POINTER attribute. 9 C723 (R736) A scalar-variable shall be a data-ref . 10 C724 (R736) A data-pointer-component-name shall be the name of a component of scalar-variable 11 that is a data pointer. 12 C725 (R736) A data-pointer-object shall not be a co-indexed object. 13 R737 bounds-spec is lower-bound-expr : 14 R738 bounds-remapping is lower-bound-expr : upper-bound-expr 15 R739 data-target is variable 16 or expr 17 C726 (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an 18 array section with a vector subscript. 19 C727 (R739) A data-target shall not be a co-indexed object. 20 NOTE 7.47 A data pointer and its target are always on the same image. A co-array may be of a derived type with pointer or allocatable subcomponents. For example, if PTR is a pointer component, Z[P]%PTR is a reference to the target of component PTR of Z on image P. This target is on image P and its association with Z[P]%PTR must have been established by the execution of an ALLOCATE statement or a pointer assignment on image P. C728 (R739) An expr shall be a reference to a function whose result is a data pointer. 21 R740 proc-pointer-object is proc-pointer-name 22 or proc-component-ref 23 R741 proc-component-ref is scalar-variable % procedure-component-name 24 C729 (R741) The scalar-variable shall be a data-ref . 25 C730 (R741) The procedure-component-name shall be the name of a procedure pointer component of 26 the declared type of scalar-variable. 27 R742 proc-target is expr 28 or procedure-name 29 or proc-component-ref 30 C731 (R742) An expr shall be a reference to a function whose result is a procedure pointer. 31 C732 (R742) A procedure-name shall be the name of an external, internal, module, or dummy proce- 32 dure, a procedure pointer, or a specific intrinsic function listed in 13.6 and not marked with a 33 163 J3/06-007r1 WORKING DRAFT 2006/09/25 bullet (·). 1 C733 (R742) The proc-target shall not be a nonintrinsic elemental procedure. 2 7.4.2.3 Data pointer assignment 3 If data-pointer-object is not polymorphic and data-target is polymorphic with dynamic type that differs 4 from its declared type, the assignment target is the ancestor component of data-target that has the type 5 of data-pointer-object. Otherwise, the assignment target is data-target. 6 If data-target is not a pointer, data-pointer-object becomes pointer associated with the assignment target. 7 Otherwise, the pointer association status of data-pointer-object becomes that of data-target; if data-target 8 is associated with an object, data-pointer-object becomes associated with the assignment target. If data- 9 target is allocatable, it shall be allocated. 10 If data-pointer-object is polymorphic (4.3.1.3), it assumes the dynamic type of data-target. If data- 11 pointer-object is of sequence derived type or a type with the BIND attribute, the dynamic type of 12 data-target shall be that derived type. 13 If data-target is a disassociated pointer, all nondeferred type parameters of the declared type of data- 14 pointer-object that correspond to nondeferred type parameters of data-target shall have the same values 15 as the corresponding type parameters of data-target. 16 Otherwise, all nondeferred type parameters of the declared type of data-pointer-object shall have the 17 same values as the corresponding type parameters of data-target. 18 If data-pointer-object has nondeferred type parameters that correspond to deferred type parameters of 19 data-target, data-target shall not be a pointer with undefined association status. 20 If data-pointer-object has the CONTIGUOUS attribute, data-target shall be contiguous. 21 If bounds-remapping-list is specified, data-target shall be contiguous (5.3.6) or of rank one. It shall not 22 be a disassociated or undefined pointer, and the size of data-target shall not be less than the size of 23 data-pointer-object. The elements of the target of data-pointer-object, in array element order (6.2.2.2), 24 are the first SIZE(data-pointer-object) elements of data-target. 25 If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of 26 the corresponding dimension of data-target. If bounds-spec-list appears, it specifies the lower bounds; 27 otherwise, the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.97) 28 applied to the corresponding dimension of data-target. The upper bound of each dimension is one less 29 than the sum of the lower bound and the extent. 30 7.4.2.4 Procedure pointer assignment 31 If the proc-target is not a pointer, proc-pointer-object becomes pointer associated with proc-target. Other- 32 wise, the pointer association status of proc-pointer-object becomes that of proc-target; if proc-target is 33 associated with a procedure, proc-pointer-object becomes associated with the same procedure. 34 If proc-target is the name of an internal procedure the host instance of proc-pointer-object becomes 35 the innermost currently executing instance of the host procedure. Otherwise if proc-target has a host 36 instance the host instance of proc-pointer-object becomes that instance. Otherwise proc-pointer-object 37 has no host instance. 38 If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except 39 that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental 40 intrinsic procedure even if proc-pointer-object is not elemental. 41 164 2006/09/25 WORKING DRAFT J3/06-007r1 If the characteristics of proc-pointer-object or proc-target are such that an explicit interface is required, 1 both proc-pointer-object and proc-target shall have an explicit interface. 2 If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc- 3 target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, 4 proc-target shall be a subroutine. 5 If proc-target and proc-pointer-object are functions, they shall have the same type; corresponding type 6 parameters shall either both be deferred or both have the same value. 7 If procedure-name is a specific procedure name that is also a generic name, only the specific procedure 8 is associated with pointer-object. 9 7.4.2.5 Examples 10 NOTE 7.48 The following are examples of pointer assignment statements. (See Note 12.16 for declarations of P and BESSEL.) NEW_NODE % LEFT => CURRENT_NODE SIMPLE_NAME => TARGET_STRUCTURE % SUBSTRUCT % COMPONENT PTR => NULL ( ) ROW => MAT2D (N, :) WINDOW => MAT2D (I-1:I+1, J-1:J+1) POINTER_OBJECT => POINTER_FUNCTION (ARG_1, ARG_2) EVERY_OTHER => VECTOR (1:N:2) WINDOW2 (0:, 0:) => MAT2D (ML:MU, NL:NU) ! P is a procedure pointer and BESSEL is a procedure with a ! compatible interface. P => BESSEL ! Likewise for a structure component. STRUCT % COMPONENT => BESSEL NOTE 7.49 It is possible to obtain different-rank views of parts of an object by specifying upper bounds in pointer assignment statements. This requires that the object be either rank one or contiguous. Consider the following example, in which a matrix is under consideration. The matrix is stored as a rank-one object in MYDATA because its diagonal is needed for some reason ­ the diagonal cannot be gotten as a single object from a rank-two representation. The matrix is represented as a rank-two view of MYDATA. real, target :: MYDATA ( NR*NC ) ! An automatic array real, pointer :: MATRIX ( :, : ) ! A rank-two view of MYDATA real, pointer :: VIEW_DIAG ( : ) MATRIX( 1:NR, 1:NC ) => MYDATA ! The MATRIX view of the data VIEW_DIAG => MYDATA( 1::NR+1 ) ! The diagonal of MATRIX Rows, columns, or blocks of the matrix can be accessed as sections of MATRIX. 7.4.3 Masked array assignment ­ WHERE 11 165 J3/06-007r1 WORKING DRAFT 2006/09/25 The masked array assignment is used to mask the evaluation of expressions and assignment of values in 1 array assignment statements, according to the value of a logical array expression. 2 7.4.3.1 General form of the masked array assignment 3 A masked array assignment is either a WHERE statement or a WHERE construct. 4 R743 where-stmt is WHERE ( mask-expr ) where-assignment-stmt 5 R744 where-construct is where-construct-stmt 6 [ where-body-construct ] ... 7 [ masked-elsewhere-stmt 8 [ where-body-construct ] ... ] ... 9 [ elsewhere-stmt 10 [ where-body-construct ] ... ] 11 end-where-stmt 12 R745 where-construct-stmt is [where-construct-name:] WHERE ( mask-expr ) 13 R746 where-body-construct is where-assignment-stmt 14 or where-stmt 15 or where-construct 16 R747 where-assignment-stmt is assignment-stmt 17 R748 mask-expr is logical-expr 18 R749 masked-elsewhere-stmt is ELSEWHERE (mask-expr ) [where-construct-name] 19 R750 elsewhere-stmt is ELSEWHERE [where-construct-name] 20 R751 end-where-stmt is END WHERE [where-construct-name] 21 C734 (R747) A where-assignment-stmt that is a defined assignment shall be elemental. 22 C735 (R744) If the where-construct-stmt is identified by a where-construct-name, the corresponding 23 end-where-stmt shall specify the same where-construct-name. If the where-construct-stmt is 24 not identified by a where-construct-name, the corresponding end-where-stmt shall not specify 25 a where-construct-name. If an elsewhere-stmt or a masked-elsewhere-stmt is identified by a 26 where-construct-name, the corresponding where-construct-stmt shall specify the same where- 27 construct-name. 28 C736 (R746) A statement that is part of a where-body-construct shall not be a branch target statement. 29 If a where-construct contains a where-stmt, a masked-elsewhere-stmt, or another where-construct then 30 each mask-expr within the where-construct shall have the same shape. In each where-assignment-stmt, 31 the mask-expr and the variable being defined shall be arrays of the same shape. 32 NOTE 7.50 Examples of a masked array assignment are: WHERE (TEMP > 100.0) TEMP = TEMP - REDUCE_TEMP WHERE (PRESSURE <= 1.0) PRESSURE = PRESSURE + INC_PRESSURE TEMP = TEMP - 5.0 ELSEWHERE RAINING = .TRUE. END WHERE 7.4.3.2 Interpretation of masked array assignments 33 When a WHERE statement or a where-construct-stmt is executed, a control mask is established. In 34 addition, when a WHERE construct statement is executed, a pending control mask is established. If 35 166 2006/09/25 WORKING DRAFT J3/06-007r1 the statement does not appear as part of a where-body-construct, the mask-expr of the statement is 1 evaluated, and the control mask is established to be the value of mask-expr . The pending control mask 2 is established to have the value .NOT. mask-expr upon execution of a WHERE construct statement that 3 does not appear as part of a where-body-construct. The mask-expr is evaluated only once. 4 Each statement in a WHERE construct is executed in sequence. 5 Upon execution of a masked-elsewhere-stmt, the following actions take place in sequence. 6 (1) The control mask mc is established to have the value of the pending control mask. 7 (2) The pending control mask is established to have the value mc .AND. (.NOT. mask-expr ). 8 (3) The control mask mc is established to have the value mc .AND. mask-expr . 9 The mask-expr is evaluated at most once. 10 Upon execution of an ELSEWHERE statement, the control mask is established to have the value of the 11 pending control mask. No new pending control mask value is established. 12 Upon execution of an ENDWHERE statement, the control mask and pending control mask are es- 13 tablished to have the values they had prior to the execution of the corresponding WHERE construct 14 statement. Following the execution of a WHERE statement that appears as a where-body-construct, the 15 control mask is established to have the value it had prior to the execution of the WHERE statement. 16 NOTE 7.51 The establishment of control masks and the pending control mask is illustrated with the following example: WHERE(cond1) ! Statement 1 ... ELSEWHERE(cond2) ! Statement 2 ... ELSEWHERE ! Statement 3 ... END WHERE Following execution of statement 1, the control mask has the value cond1 and the pending control mask has the value .NOT. cond1. Following execution of statement 2, the control mask has the value (.NOT. cond1) .AND. cond2 and the pending control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). Following execution of statement 3, the control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). The false condition values are propagated through the execution of the masked ELSEWHERE statement. Upon execution of a WHERE construct statement that is part of a where-body-construct, the pending 17 control mask is established to have the value mc .AND. (.NOT. mask-expr ). The control mask is then 18 established to have the value mc .AND. mask-expr . The mask-expr is evaluated at most once. 19 Upon execution of a WHERE statement that is part of a where-body-construct, the control mask is 20 established to have the value mc .AND. mask-expr . The pending mask is not altered. 21 If a nonelemental function reference occurs in the expr or variable of a where-assignment-stmt or in a 22 mask-expr , the function is evaluated without any masked control; that is, all of its argument expressions 23 are fully evaluated and the function is fully evaluated. If the result is an array and the reference is not 24 within the argument list of a nonelemental function, elements corresponding to true values in the control 25 mask are selected for use in evaluating the expr , variable or mask-expr . 26 If an elemental operation or function reference occurs in the expr or variable of a where-assignment-stmt 27 167 J3/06-007r1 WORKING DRAFT 2006/09/25 or in a mask-expr , and is not within the argument list of a nonelemental function reference, the operation 1 is performed or the function is evaluated only for the elements corresponding to true values of the control 2 mask. 3 If an array constructor appears in a where-assignment-stmt or in a mask-expr , the array constructor is 4 evaluated without any masked control and then the where-assignment-stmt is executed or the mask-expr 5 is evaluated. 6 When a where-assignment-stmt is executed, the values of expr that correspond to true values of the 7 control mask are assigned to the corresponding elements of the variable. 8 The value of the control mask is established by the execution of a WHERE statement, a WHERE con- 9 struct statement, an ELSEWHERE statement, a masked ELSEWHERE statement, or an ENDWHERE 10 statement. Subsequent changes to the value of entities in a mask-expr have no effect on the value of the 11 control mask. The execution of a function reference in the mask expression of a WHERE statement is 12 permitted to affect entities in the assignment statement. 13 NOTE 7.52 Examples of function references in masked array assignments are: WHERE (A > 0.0) A = LOG (A) ! LOG is invoked only for positive elements. A = A / SUM (LOG (A)) ! LOG is invoked for all elements ! because SUM is transformational. END WHERE 7.4.4 FORALL 14 FORALL constructs and statements are used to control the execution of assignment and pointer assign- 15 ment statements with selection by sets of index values and an optional mask expression. 16 7.4.4.1 The FORALL Construct 17 The FORALL construct allows multiple assignments, masked array (WHERE) assignments, and nested 18 FORALL constructs and statements to be controlled by a single forall-triplet-spec-list and scalar-mask- 19 expr . 20 R752 forall-construct is forall-construct-stmt 21 [forall-body-construct ] ... 22 end-forall-stmt 23 R753 forall-construct-stmt is [forall-construct-name :] FORALL forall-header 24 R754 forall-header is (forall-triplet-spec-list [, scalar-mask-expr ] ) 25 R755 forall-triplet-spec is index-name = subscript : subscript [ : stride] 26 R619 subscript is scalar-int-expr 27 R622 stride is scalar-int-expr 28 R756 forall-body-construct is forall-assignment-stmt 29 or where-stmt 30 or where-construct 31 or forall-construct 32 or forall-stmt 33 R757 forall-assignment-stmt is assignment-stmt 34 or pointer-assignment-stmt 35 R758 end-forall-stmt is END FORALL [forall-construct-name ] 36 C737 (R758) If the forall-construct-stmt has a forall-construct-name, the end-forall-stmt shall have 37 168 2006/09/25 WORKING DRAFT J3/06-007r1 the same forall-construct-name. If the end-forall-stmt has a forall-construct-name, the forall- 1 construct-stmt shall have the same forall-construct-name. 2 C738 (R754) The scalar-mask-expr shall be scalar and of type logical. 3 C739 (R754) Any procedure referenced in the scalar-mask-expr , including one referenced by a defined 4 operation, shall be a pure procedure (12.7). 5 C740 (R755) The index-name shall be a named scalar variable of type integer. 6 C741 (R755) A subscript or stride in a forall-triplet-spec shall not contain a reference to any index- 7 name in the forall-triplet-spec-list in which it appears. 8 C742 (R756) A statement in a forall-body-construct shall not define an index-name of the forall- 9 construct. 10 C743 (R756) Any procedure referenced in a forall-body-construct, including one referenced by a defined 11 operation, assignment, or finalization, shall be a pure procedure. 12 C744 (R756) A forall-body-construct shall not be a branch target. 13 C745 (R757) The variable in an assignment-stmt that is a forall-assignment-stmt shall be a designator . 14 NOTE 7.53 An example of a FORALL construct is: REAL :: A(10, 10), B(10, 10) = 1.0 ... FORALL (I = 1:10, J = 1:10, B(I, J) /= 0.0) A(I, J) = REAL (I + J - 2) B(I, J) = A(I, J) + B(I, J) * REAL (I * J) END FORALL NOTE 7.54 An assignment statement that is a FORALL body construct may be a scalar or array assignment statement, or a defined assignment statement. The variable being defined will normally use each index name in the forall-triplet-spec-list. For example FORALL (I = 1:N, J = 1:N) A(:, I, :, J) = 1.0 / REAL(I + J - 1) END FORALL broadcasts scalar values to rank-two subarrays of A. NOTE 7.55 An example of a FORALL construct containing a pointer assignment statement is: TYPE ELEMENT REAL ELEMENT_WT CHARACTER (32), POINTER :: NAME END TYPE ELEMENT TYPE(ELEMENT) CHART(200) REAL WEIGHTS (1000) CHARACTER (32), TARGET :: NAMES (1000) 169 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.55 (cont.) ... FORALL (I = 1:200, WEIGHTS (I + N - 1) > .5) CHART(I) % ELEMENT_WT = WEIGHTS (I + N - 1) CHART(I) % NAME => NAMES (I + N - 1) END FORALL The results of this FORALL construct cannot be achieved with a WHERE construct because a pointer assignment statement is not permitted in a WHERE construct. An index-name in a forall-construct has a scope of the construct (16.4). It is a scalar variable that has 1 the type and type parameters that it would have if it were the name of a variable in the scoping unit 2 that includes the FORALL, and this type shall be integer type; it has no other attributes. 3 NOTE 7.56 The use of index-name variables in a FORALL construct does not affect variables of the same name, for example: INTEGER :: X = -1 REAL A(5, 4) J = 100 ... FORALL (X = 1:5, J = 1:4) A (X, J) = J END FORALL After execution of the FORALL, the variables X and J have the values -1 and 100 and A has the value 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 7.4.4.2 Execution of the FORALL construct 4 There are three stages in the execution of a FORALL construct: 5 (1) determination of the values for index-name variables, 6 (2) evaluation of the scalar-mask-expr , and 7 (3) execution of the FORALL body constructs. 8 7.4.4.2.1 Determination of the values for index variables 9 The subscript and stride expressions in the forall-triplet-spec-list are evaluated. These expressions may 10 be evaluated in any order. The set of values that a particular index-name variable assumes is determined 11 as follows. 12 (1) The lower bound m1 , the upper bound m2 , and the stride m3 are of type integer with the 13 same kind type parameter as the index-name. Their values are established by evaluating 14 the first subscript, the second subscript, and the stride expressions, respectively, including, 15 if necessary, conversion to the kind type parameter of the index-name according to the rules 16 for numeric conversion (Table 7.12). If a stride does not appear, m3 has the value 1. The 17 170 2006/09/25 WORKING DRAFT J3/06-007r1 value m3 shall not be zero. 1 Let the value of max be (m2 -m1 +m3 )/m3 . If max 0 for some index-name, the execution (2) 2 of the construct is complete. Otherwise, the set of values for the index-name is 3 m1 + (k - 1) × m3 where k = 1, 2, ..., max. 4 The set of combinations of index-name values is the Cartesian product of the sets defined by each triplet 5 specification. An index-name becomes defined when this set is evaluated. 6 NOTE 7.57 The stride may be positive or negative; the FORALL body constructs are executed as long as max > 0. For the forall-triplet-spec I = 10:1:-1 max has the value 10 7.4.4.2.2 Evaluation of the mask expression 7 The scalar-mask-expr , if any, is evaluated for each combination of index-name values. If the scalar- 8 mask-expr is not present, it is as if it were present with the value true. The index-name variables may 9 be primaries in the scalar-mask-expr . 10 The active combination of index-name values is defined to be the subset of all possible combinations 11 (7.4.4.2.1) for which the scalar-mask-expr has the value true. 12 NOTE 7.58 The index-name variables may appear in the mask, for example FORALL (I=1:10, J=1:10, A(I) > 0.0 .AND. B(J) < 1.0) ... 7.4.4.2.3 Execution of the FORALL body constructs 13 The forall-body-constructs are executed in the order in which they appear. Each construct is executed 14 for all active combinations of the index-name values with the following interpretation: 15 Execution of a forall-assignment-stmt that is an assignment-stmt causes the evaluation of expr and all 16 expressions within variable for all active combinations of index-name values. These evaluations may be 17 done in any order. After all these evaluations have been performed, each expr value is assigned to the 18 corresponding variable. The assignments may occur in any order. 19 Execution of a forall-assignment-stmt that is a pointer-assignment-stmt causes the evaluation of all 20 expressions within data-target and data-pointer-object or proc-target and proc-pointer-object, the de- 21 termination of any pointers within data-pointer-object or proc-pointer-object, and the determination of 22 the target for all active combinations of index-name values. These evaluations may be done in any 23 order. After all these evaluations have been performed, each data-pointer-object or proc-pointer-object 24 is associated with the corresponding target. These associations may occur in any order. 25 In a forall-assignment-stmt, a defined assignment subroutine shall not reference any variable that be- 26 comes defined by the statement. 27 NOTE 7.59 The following FORALL construct contains two assignment statements. The assignment to array B uses the values of array A computed in the previous statement, not the values A had prior to 171 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.59 (cont.) execution of the FORALL. FORALL (I = 2:N-1, J = 2:N-1 ) A (I, J) = A(I, J-1) + A(I, J+1) + A(I-1, J) + A(I+1, J) B (I, J) = 1.0 / A(I, J) END FORALL Computations that would otherwise cause error conditions can be avoided by using an appropriate scalar-mask-expr that limits the active combinations of the index-name values. For example: FORALL (I = 1:N, Y(I) /= 0.0) X(I) = 1.0 / Y(I) END FORALL Each statement in a where-construct (7.4.3) within a forall-construct is executed in sequence. When 1 a where-stmt, where-construct-stmt or masked-elsewhere-stmt is executed, the statement's mask-expr is 2 evaluated for all active combinations of index-name values as determined by the outer forall-constructs, 3 masked by any control mask corresponding to outer where-constructs. Any where-assignment-stmt is 4 executed for all active combinations of index-name values, masked by the control mask in effect for the 5 where-assignment-stmt. 6 NOTE 7.60 This FORALL construct contains a WHERE statement and an assignment statement. INTEGER A(5,4), B(5,4) FORALL ( I = 1:5 ) WHERE ( A(I,:) == 0 ) A(I,:) = I B (I,:) = I / A(I,:) END FORALL When executed with the input array 0 0 0 0 1 1 1 0 A = 2 2 0 2 1 0 2 3 0 0 0 0 the results will be 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 1 A = 2 2 3 2 B = 1 1 1 1 1 4 2 3 4 1 2 1 5 5 5 5 1 1 1 1 For an example of a FORALL construct containing a WHERE construct with an ELSEWHERE statement, see C.4.5. Execution of a forall-stmt or forall-construct causes the evaluation of the subscript and stride expressions 7 in the forall-triplet-spec-list for all active combinations of the index-name values of the outer FORALL 8 172 2006/09/25 WORKING DRAFT J3/06-007r1 construct. The set of combinations of index-name values for the inner FORALL is the union of the sets 1 defined by these bounds and strides for each active combination of the outer index-name values; it also 2 includes the outer index-name values. The scalar-mask-expr is then evaluated for all combinations of the 3 index-name values of the inner construct to produce a set of active combinations for the inner construct. 4 If there is no scalar-mask-expr , it is as if it were present with the value .TRUE.. Each statement in the 5 inner FORALL is then executed for each active combination of the index-name values. 6 NOTE 7.61 This FORALL construct contains a nested FORALL construct. It assigns the transpose of the strict lower triangle of array A (the section below the main diagonal) to the strict upper triangle of A. INTEGER A (3, 3) FORALL (I = 1:N-1 ) FORALL ( J=I+1:N ) A(I,J) = A(J,I) END FORALL END FORALL If prior to execution N = 3 and 0 3 6 A = 1 4 7 2 5 8 then after execution 0 1 2 A = 1 4 5 2 5 8 7.4.4.3 The FORALL statement 7 The FORALL statement allows a single assignment statement or pointer assignment to be controlled by 8 a set of index values and an optional mask expression. 9 R759 forall-stmt is FORALL forall-header forall-assignment-stmt 10 A FORALL statement is equivalent to a FORALL construct containing a single forall-body-construct 11 that is a forall-assignment-stmt. 12 The scope of an index-name in a forall-stmt is the statement itself (16.4). 13 NOTE 7.62 Examples of FORALL statements are: FORALL (I=1:N) A(I,I) = X(I) This statement assigns the elements of vector X to the elements of the main diagonal of matrix A. FORALL (I = 1:N, J = 1:N) X(I,J) = 1.0 / REAL (I+J-1) Array element X(I,J) is assigned the value (1.0 / REAL (I+J-1)) for values of I and J between 1 173 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 7.62 (cont.) and N, inclusive. FORALL (I=1:N, J=1:N, Y(I,J) /= 0 .AND. I /= J) X(I,J) = 1.0 / Y(I,J) This statement takes the reciprocal of each nonzero off-diagonal element of array Y(1:N, 1:N) and assigns it to the corresponding element of array X. Elements of Y that are zero or on the diagonal do not participate, and no assignments are made to the corresponding elements of X. The results from the execution of the example in Note 7.61 could be obtained with a single FORALL statement: FORALL ( I = 1:N-1, J=1:N, J > I ) A(I,J) = A(J,I) For more examples of FORALL statements, see C.4.6. 7.4.4.4 Restrictions on FORALL constructs and statements 1 A many-to-one assignment is more than one assignment to the same object, or association of more 2 than one target with the same pointer, whether the object is referenced directly or indirectly through a 3 pointer. A many-to-one assignment shall not occur within a single statement in a FORALL construct or 4 statement. It is possible to assign or pointer assign to the same object in different assignment statements 5 in a FORALL construct. 6 NOTE 7.63 The appearance of each index-name in the identification of the left-hand side of an assignment statement is helpful in eliminating many-to-one assignments, but it is not sufficient to guarantee there will be none. For example, the following is allowed FORALL (I = 1:10) A (INDEX (I)) = B(I) END FORALL if and only if INDEX(1:10) contains no repeated values. Within the scope of a FORALL construct, a nested FORALL statement or FORALL construct shall 7 not have the same index-name. The forall-header expressions within a nested FORALL may depend on 8 the values of outer index-name variables. 9 174 2006/09/25 WORKING DRAFT J3/06-007r1 8 Execution control 1 8.1 Executable constructs containing blocks 2 8.1.1 General 3 The following are executable constructs that contain blocks: 4 (1) ASSOCIATE construct; 5 (2) BLOCK construct; 6 (3) CASE construct; 7 (4) CRITICAL construct; 8 (5) DO construct; 9 (6) IF construct; 10 (7) SELECT TYPE construct. 11 12 There is also a nonblock form of the DO construct. A block is a sequence of executable constructs that is treated as a unit. 13 R801 block is [ execution-part-construct ] ... 14 Executable constructs may be used to control which blocks of a program are executed or how many times 15 a block is executed. Blocks are always bounded by statements that are particular to the construct in 16 which they are embedded; however, in some forms of the DO construct, a sequence of executable constructs without 17 a terminating boundary statement shall obey all other rules governing blocks (8.1.2). 18 NOTE 8.1 A block need not contain any executable constructs. Execution of such a block has no effect. NOTE 8.2 An example of a construct containing a block is: IF (A > 0.0) THEN B = SQRT (A) ! These two statements C = LOG (A) ! form a block. END IF 8.1.2 Rules governing blocks 19 8.1.2.1 Control flow in blocks 20 Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a 21 block and transfers from the interior of a block to outside the block may occur. 22 Subroutine and function references (12.5.3, 12.5.4) may appear in a block. 23 8.1.2.2 Execution of a block 24 175 J3/06-007r1 WORKING DRAFT 2006/09/25 Execution of a block begins with the execution of the first executable construct in the block. Execution 1 of the block is completed when the last executable construct in the sequence is executed, when a branch 2 (8.2) within the block that has a branch target outside the block occurs, when a RETURN statement 3 within the block is executed, or when an EXIT or CYCLE statement that belongs to a construct that 4 contains the block is executed. 5 NOTE 8.3 The action that takes place at the terminal boundary depends on the particular construct and on the block within that construct. It is usually a transfer of control. 8.1.3 ASSOCIATE construct 6 The ASSOCIATE construct associates named entities with expressions or variables during the exe- 7 cution of its block. These named construct entities (16.4) are associating entities (16.5.1.6). The names 8 are associate names. 9 8.1.3.1 Form of the ASSOCIATE construct 10 R802 associate-construct is associate-stmt 11 block 12 end-associate-stmt 13 R803 associate-stmt is [ associate-construct-name : ] ASSOCIATE 14 (association-list ) 15 R804 association is associate-name => selector 16 R805 selector is expr 17 or variable 18 C801 (R804) If selector is not a variable or is a variable that has a vector subscript, associate-name 19 shall not appear in a variable definition context (16.6.7). 20 C802 (R804) An associate-name shall not be the same as another associate-name in the same associate- 21 stmt. 22 C803 (R805) expr shall not be a reference to a function that has a pointer result. 23 R806 end-associate-stmt is END ASSOCIATE [ associate-construct-name ] 24 C804 (R806) If the associate-stmt of an associate-construct specifies an associate-construct-name, 25 the corresponding end-associate-stmt shall specify the same associate-construct-name. If the 26 associate-stmt of an associate-construct does not specify an associate-construct-name, the cor- 27 responding end-associate-stmt shall not specify an associate-construct-name. 28 8.1.3.2 Execution of the ASSOCIATE construct 29 Execution of an ASSOCIATE construct causes execution of its associate-stmt followed by execution 30 of its block. During execution of that block each associate name identifies an entity, which is associ- 31 ated (16.5.1.6) with the corresponding selector. The associating entity assumes the declared type and 32 type parameters of the selector. If and only if the selector is polymorphic, the associating entity is 33 polymorphic. 34 The other attributes of the associating entity are described in 8.1.3.3. 35 It is permissible to branch to an end-associate-stmt only from within its ASSOCIATE construct. 36 8.1.3.3 Attributes of associate names 37 176 2006/09/25 WORKING DRAFT J3/06-007r1 Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the same rank as its 1 associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND 2 (13.7.97) applied to the corresponding dimension of selector . The upper bound of each dimension is one 3 less than the sum of the lower bound and the extent. The associating entity has the ASYNCHRONOUS 4 or VOLATILE attribute if and only if the selector is a variable and has the attribute. The associating 5 entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET 6 or POINTER attribute. If the associating entity is polymorphic, it assumes the dynamic type and type 7 parameter values of the selector. If the selector has the OPTIONAL attribute, it shall be present. The 8 associating entity is contiguous if and only if the selector is contiguous. 9 If the selector (8.1.3.1) is not permitted to appear in a variable definition context (16.6.7), the associate 10 name shall not appear in a variable definition context. 11 8.1.3.4 Examples of the ASSOCIATE construct 12 NOTE 8.4 The following example illustrates an association with an expression. ASSOCIATE ( Z => EXP(-(X**2+Y**2)) * COS(THETA) ) PRINT *, A+Z, A-Z END ASSOCIATE The following example illustrates an association with a derived-type variable. ASSOCIATE ( XC => AX%B(I,J)%C ) XC%DV = XC%DV + PRODUCT(XC%EV(1:N)) END ASSOCIATE The following example illustrates association with an array section. ASSOCIATE ( ARRAY => AX%B(I,:)%C ) ARRAY(N)%EV = ARRAY(N-1)%EV END ASSOCIATE The following example illustrates multiple associations. ASSOCIATE ( W => RESULT(I,J)%W, ZX => AX%B(I,J)%D, ZY => AY%B(I,J)%D ) W = ZX*X + ZY*Y END ASSOCIATE 8.1.4 BLOCK construct 13 The BLOCK construct is an executable construct which may contain declarations. 14 R807 block-construct is block-stmt 15 [ specification-part ] 16 block 17 end-block-stmt 18 R808 block-stmt is [ block-construct-name : ] BLOCK 19 R809 end-block-stmt is END BLOCK [ block-construct-name ] 20 C805 (R807) The specification-part of a BLOCK construct shall not contain a COMMON statement, 21 IMPLICIT statement, INTENT statement, OPTIONAL statement, or USE statement. 177 J3/06-007r1 WORKING DRAFT 2006/09/25 J3 internal note Unresolved Technical Issue 084 It would be better to allow the USE statement. Some work is required to handle modules going out of scope on exiting a BLOCK construct. C806 (R807) If the block-stmt of a block-construct specifies a block-construct-name, the corresponding 1 end-block-stmt shall specify the same block-construct-name. If the block-stmt does not specify 2 a block-construct-name, the corresponding end-block-stmt shall not specify a block-construct- 3 name. 4 Except for the ASYNCHRONOUS and VOLATILE statements, specifications in a BLOCK construct 5 declare construct entities whose scope is that of the BLOCK construct (16.4). 6 Execution of a BLOCK construct causes evaluation of the specification expressions within its specifica- 7 tion-part in a processor-dependent order, followed by execution of its block. 8 8.1.5 CASE construct 9 8.1.5.1 Form of the CASE construct 10 The CASE construct selects for execution at most one of its constituent blocks. The selection is based 11 on the value of an expression. 12 R810 case-construct is select-case-stmt 13 [ case-stmt 14 block ] ... 15 end-select-stmt 16 R811 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) 17 R812 case-stmt is CASE case-selector [case-construct-name] 18 R813 end-select-stmt is END SELECT [ case-construct-name ] 19 C807 (R810) If the select-case-stmt of a case-construct specifies a case-construct-name, the corre- 20 sponding end-select-stmt shall specify the same case-construct-name. If the select-case-stmt 21 of a case-construct does not specify a case-construct-name, the corresponding end-select-stmt 22 shall not specify a case-construct-name. If a case-stmt specifies a case-construct-name, the 23 corresponding select-case-stmt shall specify the same case-construct-name. 24 R814 case-expr is scalar-int-expr 25 or scalar-char-expr 26 or scalar-logical-expr 27 R815 case-selector is ( case-value-range-list ) 28 or DEFAULT 29 C808 (R810) No more than one of the selectors of one of the CASE statements shall be DEFAULT. 30 R816 case-value-range is case-value 31 or case-value : 32 or : case-value 33 or case-value : case-value 34 R817 case-value is scalar-int-initialization-expr 35 or scalar-char-initialization-expr 36 or scalar-logical-initialization-expr 37 C809 (R810) For a given case-construct, each case-value shall be of the same type as case-expr . For 38 character type, the kind type parameters shall be the same; character length differences are 39 178 2006/09/25 WORKING DRAFT J3/06-007r1 allowed. 1 C810 (R810) A case-value-range using a colon shall not be used if case-expr is of type logical. 2 C811 (R810) For a given case-construct, the case-value-ranges shall not overlap; that is, there shall 3 be no possible value of the case-expr that matches more than one case-value-range. 4 8.1.5.2 Execution of a CASE construct 5 The execution of the SELECT CASE statement causes the case expression to be evaluated. The resulting 6 value is called the case index. For a case value range list, a match occurs if the case index matches any 7 of the case value ranges in the list. For a case index with a value of c, a match is determined as follows. 8 (1) If the case value range contains a single value v without a colon, a match occurs for type 9 logical if the expression c .EQV. v is true, and a match occurs for type integer or character 10 if the expression c == v is true. 11 (2) If the case value range is of the form low : high, a match occurs if the expression low <= c 12 .AND. c <= high is true. 13 (3) If the case value range is of the form low :, a match occurs if the expression low <= c is true. 14 (4) If the case value range is of the form : high, a match occurs if the expression c <= high is 15 true. 16 (5) If no other selector matches and a DEFAULT selector appears, it matches the case index. 17 (6) If no other selector matches and the DEFAULT selector does not appear, there is no match. 18 The block following the CASE statement containing the matching selector, if any, is executed. This 19 completes execution of the construct. 20 It is permissible to branch to an end-select-stmt only from within its CASE construct. 21 8.1.5.3 Examples of CASE constructs 22 NOTE 8.5 An integer signum function: INTEGER FUNCTION SIGNUM (N) SELECT CASE (N) CASE (:-1) SIGNUM = -1 CASE (0) SIGNUM = 0 CASE (1:) SIGNUM = 1 END SELECT END NOTE 8.6 A code fragment to check for balanced parentheses: CHARACTER (80) :: LINE ... LEVEL = 0 SCAN_LINE: DO I = 1, 80 CHECK_PARENS: SELECT CASE (LINE (I:I)) CASE ('(') 179 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.6 (cont.) LEVEL = LEVEL + 1 CASE (')') LEVEL = LEVEL - 1 IF (LEVEL < 0) THEN PRINT *, 'UNEXPECTED RIGHT PARENTHESIS' EXIT SCAN_LINE END IF CASE DEFAULT ! Ignore all other characters END SELECT CHECK_PARENS END DO SCAN_LINE IF (LEVEL > 0) THEN PRINT *, 'MISSING RIGHT PARENTHESIS' END IF NOTE 8.7 The following three fragments are equivalent: IF (SILLY == 1) THEN CALL THIS ELSE CALL THAT END IF SELECT CASE (SILLY == 1) CASE (.TRUE.) CALL THIS CASE (.FALSE.) CALL THAT END SELECT SELECT CASE (SILLY) CASE DEFAULT CALL THAT CASE (1) CALL THIS END SELECT NOTE 8.8 A code fragment showing several selections of one block: SELECT CASE (N) CASE (1, 3:5, 8) ! Selects 1, 3, 4, 5, 8 CALL SUB CASE DEFAULT CALL OTHER END SELECT 8.1.6 CRITICAL construct 1 A CRITICAL construct limits execution of a block to one image at a time. 2 180 2006/09/25 WORKING DRAFT J3/06-007r1 R818 critical-construct is critical-stmt 1 block 2 end-critical-stmt 3 R819 critical-stmt is [ critical-construct-name : ] CRITICAL 4 R820 end-critical-stmt is END CRITICAL [ critical-construct-name ] 5 C812 (R818) If the critical-stmt of a critical-construct specifies a critical-construct-name, the corre- 6 sponding end-critical-stmt shall specify the same critical-construct-name. If the critical-stmt of a 7 critical-construct does not specify a critical-construct-name, the corresponding end-critical-stmt 8 shall not specify a critical-construct-name. 9 C813 (R818) The block of a critical-construct shall not contain an image control statement. 10 Execution of the CRITICAL construct is completed when execution of its block is completed. 11 The processor shall ensure that once an image has commenced executing block , no other image shall 12 commence executing it until the image has completed executing it. If image T is the next to execute the 13 construct after image M, the segments (8.5.1) that executed before the construct on image M precede 14 the segments that execute after the construct on image T. No image control statement shall be executed 15 during the execution of a critical construct by the image executing the CRITICAL construct. 16 NOTE 8.9 If more than one image executes the block of a CRITICAL construct, its execution by one image always either precedes or succeeds its execution by another image. Typically no other statement ordering is needed. Consider the following example: CRITICAL GLOBAL_COUNTER[1] = GLOBAL_COUNTER[1] + 1 END CRITICAL The definition of GLOBAL COUNTER[1] by a particular image will always precede the reference to the same variable by the next image to execute the block. NOTE 8.10 The following example permits a large number of jobs to be shared among the images: INTEGER :: NUM_JOBS[*], JOB IF (THIS_IMAGE() == 1) READ(*,*) NUM_JOBS SYNC ALL DO CRITICAL JOB = NUM_JOBS[1] NUM_JOBS[1] = JOB - 1 END CRITICAL IF (JOB > 0) THEN ! Work on JOB ELSE EXIT END IF END DO SYNC ALL 181 J3/06-007r1 WORKING DRAFT 2006/09/25 8.1.7 DO construct 1 8.1.7.1 General 2 The DO construct specifies the repeated execution of a sequence of executable constructs. Such a 3 repeated sequence is called a loop. 4 The number of iterations of a loop may be determined at the beginning of execution of the DO construct, 5 or may be left indefinite ("DO forever" or DO WHILE). Except in the case of a DO CONCURRENT 6 construct, the loop can be terminated immediately (8.1.7.5.4). The current iteration of the loop may be 7 curtailed by executing a CYCLE statement (8.1.7.5.3). 8 There are three phases in the execution of a DO construct: initiation of the loop, execution of the loop 9 range, and termination of the loop. 10 The DO CONCURRENT construct is a DO construct whose DO statement contains the CONCURRENT 11 keyword. 12 8.1.7.2 Forms of the DO construct 13 The DO construct may be written in either a block form or a nonblock form. 14 R821 do-construct is block-do-construct 15 or nonblock-do-construct 16 8.1.7.2.1 Form of the block DO construct 17 R822 block-do-construct is do-stmt 18 do-block 19 end-do 20 R823 do-stmt is label-do-stmt 21 or nonlabel-do-stmt 22 R824 label-do-stmt is [ do-construct-name : ] DO label [ loop-control ] 23 R825 nonlabel-do-stmt is [ do-construct-name : ] DO [ loop-control ] 24 R826 loop-control is [ , ] do-variable = scalar-int-expr , scalar-int-expr 25 [ , scalar-int-expr ] 26 or [ , ] WHILE ( scalar-logical-expr ) 27 or [ , ] CONCURRENT forall-header 28 R827 do-variable is scalar-int-variable-name 29 C814 (R827) The do-variable shall be a variable of type integer. 30 R828 do-block is block 31 R829 end-do is end-do-stmt 32 or continue-stmt 33 R830 end-do-stmt is END DO [ do-construct-name ] 34 C815 (R822) If the do-stmt of a block-do-construct specifies a do-construct-name, the corresponding 35 end-do shall be an end-do-stmt specifying the same do-construct-name. If the do-stmt of a 36 block-do-construct does not specify a do-construct-name, the corresponding end-do shall not 37 specify a do-construct-name. 38 C816 (R822) If the do-stmt is a nonlabel-do-stmt, the corresponding end-do shall be an end-do-stmt. 39 C817 (R822) If the do-stmt is a label-do-stmt, the corresponding end-do shall be identified with the 40 same label . 41 182 2006/09/25 WORKING DRAFT J3/06-007r1 8.1.7.2.2 Form of the nonblock DO construct 1 2 R831 nonblock-do-construct is action-term-do-construct 3 or outer-shared-do-construct 4 R832 action-term-do-construct is label-do-stmt 5 do-body 6 do-term-action-stmt 7 R833 do-body is [ execution-part-construct ] ... 8 R834 do-term-action-stmt is action-stmt 9 C818 (R834) A do-term-action-stmt shall not be a continue-stmt, a goto-stmt, a return-stmt, a stop-stmt, an exit-stmt, a cycle-stmt, an end-function-stmt, an end-subroutine-stmt, an end-program-stmt, or an arithmetic-if-stmt. 10 11 C819 (R831) The do-term-action-stmt shall be identified with a label and the corresponding label-do-stmt shall refer 12 to the same label. 13 R835 outer-shared-do-construct is label-do-stmt 14 do-body 15 shared-term-do-construct 16 R836 shared-term-do-construct is outer-shared-do-construct 17 or inner-shared-do-construct 18 R837 inner-shared-do-construct is label-do-stmt 19 do-body 20 do-term-shared-stmt 21 R838 do-term-shared-stmt is action-stmt 22 C820 (R838) A do-term-shared-stmt shall not be a goto-stmt, a return-stmt, a stop-stmt, an exit-stmt, a cycle-stmt, an end-function-stmt, an end-subroutine-stmt, an end-program-stmt, or an arithmetic-if-stmt. 23 24 C821 (R836) The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the inner-shared- 25 do-construct and outer-shared-do-construct shall refer to the same label. 26 The do-term-action-stmt, do-term-shared-stmt, or shared-term-do-construct following the do-body of a nonblock DO con- 27 struct is called the DO termination of that construct. 28 Within a scoping unit, all DO constructs whose DO statements refer to the same label are nonblock DO constructs, and share the statement identified by that label. 29 8.1.7.3 Range of the DO construct 30 The range of a block DO construct is the do-block , which shall satisfy the rules for blocks (8.1.2). In 31 particular, transfer of control to the interior of such a block from outside the block is prohibited. It 32 is permitted to branch to the end-do of a block DO construct only from within the range of that DO 33 construct. 34 35 The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a 36 range is not bounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the 37 range satisfies the rules for blocks (8.1.2). Transfer of control into the do-body or to the DO termination from outside the 38 range is prohibited; in particular, it is permitted to branch to a do-term-shared-stmt only from within the range of the corresponding inner-shared-do-construct. 39 8.1.7.4 Active and inactive DO constructs 40 A DO construct is either active or inactive. Initially inactive, a DO construct becomes active only 41 when its DO statement is executed. 42 Once active, the DO construct becomes inactive only when it terminates (8.1.7.5.4). 43 8.1.7.5 Execution of a DO construct 44 8.1.7.5.1 Loop initiation 45 When the DO statement is executed, the DO construct becomes active. If loop-control is 183 J3/06-007r1 WORKING DRAFT 2006/09/25 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 1 the following steps are performed in sequence. 2 (1) The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter 3 m3 are of type integer with the same kind type parameter as the do-variable. Their values 4 are established by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , re- 5 spectively, including, if necessary, conversion to the kind type parameter of the do-variable 6 according to the rules for numeric conversion (Table 7.12). If scalar-int-expr 3 does not 7 appear, m3 has the value 1. The value of m3 shall not be zero. 8 (2) The DO variable becomes defined with the value of the initial parameter m1 . 9 The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , (3) 10 unless that value is negative, in which case the iteration count is 0. 11 NOTE 8.11 The iteration count is zero whenever: m1 > m2 and m3 > 0, or m1 < m2 and m3 < 0. If loop-control is omitted, no iteration count is calculated. The effect is as if a large positive iteration 12 count, impossible to decrement to zero, were established. If loop-control is [ , ] WHILE (scalar-logical- 13 expr ), the effect is as if loop-control were omitted and the following statement inserted as the first 14 statement of the do-block : 15 IF (.NOT. (scalar- logical-expr )) EXIT 16 For a DO CONCURRENT construct, the values of the index variables for the iterations of the construct 17 are determined by the rules for the index variables of the FORALL construct (7.4.4.2.1 and 7.4.4.2.2). 18 An index-name in a DO CONCURRENT construct has a scope of the construct (16.4). It is a scalar 19 variable that has the type and type parameters that it would have if it were the name of a variable in the 20 scoping unit that includes the construct, and this type shall be integer type; it has no other attributes. 21 At the completion of the execution of the DO statement, the execution cycle begins. 22 8.1.7.5.2 The execution cycle 23 The execution cycle of a DO construct that is not a DO CONCURRENT construct consists of the 24 following steps performed in sequence repeatedly until termination. 25 (1) The iteration count, if any, is tested. If it is zero, the loop terminates and the DO construct 26 becomes inactive. If loop-control is [ , ] WHILE (scalar-logical-expr ), the scalar-logical-expr 27 is evaluated; if the value of this expression is false, the loop terminates and the DO construct 28 becomes inactive. If, as a result, all of the DO constructs sharing the do-term-shared-stmt are inactive, 29 30 the execution of all of these constructs is complete. However, if some of the DO constructs sharing the 31 do-term-shared-stmt are active, execution continues with step (3) of the execution cycle of the active DO construct whose DO statement was most recently executed. 32 (2) The range of the loop is executed. 33 (3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented 34 by the value of the incrementation parameter m3 . 35 Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither 36 be redefined nor become undefined while the DO construct is active. 37 The range of a DO CONCURRENT construct is executed for all of the active combinations of the 38 index-name values. Each execution of the range is an iteration. The executions may occur in any order. 184 2006/09/25 WORKING DRAFT J3/06-007r1 8.1.7.5.3 CYCLE statement 1 Execution of the range of the loop may be curtailed by executing a CYCLE statement from within the 2 range of the loop. 3 R839 cycle-stmt is CYCLE [ do-construct-name ] 4 C822 (R839) If a do-construct-name appears, the CYCLE statement shall be within the range of that 5 do-construct; otherwise, it shall be within the range of at least one do-construct. 6 C823 (R839) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it 7 belongs to an outer construct. 8 A CYCLE statement belongs to a particular DO construct. If the CYCLE statement contains a DO 9 construct name, it belongs to that DO construct; otherwise, it belongs to the innermost DO construct 10 in which it appears. 11 Execution of a CYCLE statement that belongs to a DO construct that is not a DO CONCURRENT 12 construct causes immediate progression to step (3) of the current execution cycle of the DO construct 13 to which it belongs. If this construct is a nonblock DO construct, the do-term-action-stmt or do-term-shared-stmt is 14 15 not executed. Execution of a CYCLE statement that belongs to a DO CONCURRENT construct completes execution 16 of that iteration of the construct. 17 In a block DO construct, a transfer of control to the end-do has the same effect as execution of a CYCLE 18 statement belonging to that construct. In a nonblock DO construct, transfer of control to the do-term-action-stmt 19 20 or do-term-shared-stmt causes that statement to be executed. Unless a further transfer of control results, step (3) of the current execution cycle of the DO construct is then executed. 21 8.1.7.5.4 Loop termination 22 For a DO construct that is not a DO CONCURRENT construct, the loop terminates, and the DO 23 construct becomes inactive, when any of the following occurs. 24 (1) The iteration count is determined to be zero or the scalar-logical-expr is false, when tested 25 during step (1) of the above execution cycle. 26 (2) An EXIT statement belonging to the DO construct is executed. 27 (3) An EXIT or CYCLE statement that belongs to an outer construct and is within the range 28 of the DO construct is executed. 29 (4) Control is transferred from a statement within the range of a DO construct to a statement 30 that is neither the end-do nor within the range of the same DO construct. 31 (5) A RETURN statement within the range of the DO construct is executed. 32 For a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive when 33 all of the iterations have completed execution. 34 When a DO construct becomes inactive, the DO variable, if any, of the DO construct retains its last 35 defined value. 36 8.1.7.6 Restrictions on DO CONCURRENT constructs 37 C824 A RETURN statement shall not appear within a DO CONCURRENT construct. 38 C825 A branch (8.2) within a DO CONCURRENT construct shall not have a branch target that is 39 outside the construct. 40 185 J3/06-007r1 WORKING DRAFT 2006/09/25 C826 A reference to a nonpure procedure shall not appear within a DO CONCURRENT construct. 1 C827 A reference to the procedure IEEE GET FLAG, IEEE SET HALTING MODE, or IEEE GET - 2 HALTING MODE from the intrinsic module IEEE EXCEPTIONS, shall not be appear within 3 a DO CONCURRENT construct. 4 The following additional restrictions apply to DO CONCURRENT constructs. 5 · A variable that is referenced in an iteration shall either be previously defined during that iteration, 6 or shall be defined or become undefined during any other iteration of the current execution of 7 the construct. A variable that is defined or becomes undefined by more than one iteration of the 8 current execution of the construct becomes undefined when the current execution of the construct 9 terminates. 10 · A pointer that is referenced in an iteration either shall be previously pointer associated during that 11 iteration, or shall not have its pointer association changed during any iteration. A pointer that has 12 its pointer association changed in more than one iteration has a processor dependent association 13 status when the construct terminates. 14 · An allocatable object that is allocated in more than one iteration shall be subsequently deallocated 15 during the same iteration in which it was allocated. An object that is allocated or deallocated in 16 only one iteration shall not be deallocated, allocated, referenced, defined, or become undefined in 17 a different iteration. 18 · An input/output statement shall not write data to a file record or position in one iteration and 19 read from the same record or position in a different iteration of the same execution of the construct. 20 · Records written by output statements in the loop range to a sequential access file appear in the 21 file in an indeterminate order. 22 NOTE 8.12 The restrictions on referencing variables defined in an iteration of a DO CONCURRENT construct apply to any procedure invoked within the loop. NOTE 8.13 The restrictions on the statements in the loop range of a DO CONCURRENT construct are designed to ensure there are no data dependencies between iterations of the loop. This permits code optimizations that might otherwise be difficult or impossible because they would depend on characteristics of the program not visible to the compiler. 8.1.7.7 Examples of DO constructs 23 NOTE 8.14 The following program fragment computes a tensor product of two arrays: DO I = 1, M DO J = 1, N C (I, J) = SUM (A (I, J, :) * B (:, I, J)) END DO END DO 186 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 8.15 The following program fragment contains a DO construct that uses the WHILE form of loop- control . The loop will continue to execute until an end-of-file or input/output error is encountered, at which point the DO statement terminates the loop. When a negative value of X is read, the program skips immediately to the next READ statement, bypassing most of the range of the loop. READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X DO WHILE (IOS == 0) IF (X >= 0.) THEN CALL SUBA (X) CALL SUBB (X) ... CALL SUBZ (X) ENDIF READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X END DO NOTE 8.16 The following example behaves exactly the same as the one in Note 8.15. However, the READ statement has been moved to the interior of the range, so that only one READ statement is needed. Also, a CYCLE statement has been used to avoid an extra level of IF nesting. DO ! A "DO WHILE + 1/2" loop READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X IF (IOS /= 0) EXIT IF (X < 0.) CYCLE CALL SUBA (X) CALL SUBB (X) ... CALL SUBZ (X) END DO NOTE 8.17 The following example represents a case in which the user knows that the elements of the array IND form a permutation of the integers 1, ..., N. The DO CONCURRENT construct will allow the compiler to generate vector gather/scatter code, unroll the loop, or parallelize the code for this loop, significantly improving performance. INTEGER :: A(N,N),IND(N) DO CONCURRENT (I=1:N, J=1:N) A(IND(I),IND(J)) = A(IND(I),IND(J)) + 1 END DO NOTE 8.18 Additional examples of DO constructs are in C.5.3. 8.1.8 IF construct and statement 1 187 J3/06-007r1 WORKING DRAFT 2006/09/25 8.1.8.1 Form of the IF construct 1 The IF construct selects for execution at most one of its constituent blocks. The selection is based on 2 a sequence of logical expressions. 3 R840 if-construct is if-then-stmt 4 block 5 [ else-if-stmt 6 block ] ... 7 [ else-stmt 8 block ] 9 end-if-stmt 10 R841 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN 11 R842 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] 12 R843 else-stmt is ELSE [ if-construct-name ] 13 R844 end-if-stmt is END IF [ if-construct-name ] 14 C828 (R840) If the if-then-stmt of an if-construct specifies an if-construct-name, the corresponding 15 end-if-stmt shall specify the same if-construct-name. If the if-then-stmt of an if-construct does 16 not specify an if-construct-name, the corresponding end-if-stmt shall not specify an if-construct- 17 name. If an else-if-stmt or else-stmt specifies an if-construct-name, the corresponding if-then- 18 stmt shall specify the same if-construct-name. 19 8.1.8.2 Execution of an IF construct 20 At most one of the blocks in the IF construct is executed. If there is an ELSE statement in the construct, 21 exactly one of the blocks in the construct is executed. The scalar logical expressions are evaluated in 22 the order of their appearance in the construct until a true value is found or an ELSE statement or END 23 IF statement is encountered. If a true value or an ELSE statement is found, the block immediately 24 following is executed and this completes the execution of the construct. The scalar logical expressions 25 in any remaining ELSE IF statements of the IF construct are not evaluated. If none of the evaluated 26 expressions is true and there is no ELSE statement, the execution of the construct is completed without 27 the execution of any block within the construct. 28 It is permissible to branch to an END IF statement only from within its IF construct. Execution of an 29 END IF statement has no effect. 30 8.1.8.3 Examples of IF constructs 31 NOTE 8.19 IF (CVAR == 'RESET') THEN I = 0; J = 0; K = 0 END IF PROOF_DONE: IF (PROP) THEN WRITE (3, '(''QED'')') STOP ELSE PROP = NEXTPROP END IF PROOF_DONE IF (A > 0) THEN B = C/A IF (B > 0) THEN D = 1.0 END IF 188 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 8.19 (cont.) ELSE IF (C > 0) THEN B = A/C D = -1.0 ELSE B = ABS (MAX (A, C)) D=0 END IF 8.1.8.4 IF statement 1 The IF statement controls the execution of a single action statement based on a single logical expression. 2 R845 if-stmt is IF ( scalar-logical-expr ) action-stmt 3 C829 (R845) The action-stmt in the if-stmt shall not be an if-stmt, end-program-stmt, end-function- 4 stmt, or end-subroutine-stmt. 5 Execution of an IF statement causes evaluation of the scalar logical expression. If the value of the 6 expression is true, the action statement is executed. If the value is false, the action statement is not 7 executed and execution continues. 8 The execution of a function reference in the scalar logical expression may affect entities in the action 9 statement. 10 NOTE 8.20 An example of an IF statement is: IF (A > 0.0) A = LOG (A) 8.1.9 SELECT TYPE construct 11 8.1.9.1 Form of the SELECT TYPE construct 12 The SELECT TYPE construct selects for execution at most one of its constituent blocks. The selection 13 is based on the dynamic type of an expression. A name is associated with the expression or variable 14 (16.4, 16.5.1.6), in the same way as for the ASSOCIATE construct. 15 R846 select-type-construct is select-type-stmt 16 [ type-guard-stmt 17 block ] ... 18 end-select-type-stmt 19 R847 select-type-stmt is [ select-construct-name : ] SELECT TYPE 20 ( [ associate-name => ] selector ) 21 C830 (R847) If selector is not a named variable, associate-name => shall appear. 22 C831 (R847) If selector is not a variable or is a variable that has a vector subscript, associate-name 23 shall not appear in a variable definition context (16.6.7). 24 C832 (R847) The selector in a select-type-stmt shall be polymorphic. 25 R848 type-guard-stmt is TYPE IS ( type-spec ) [ select-construct-name ] 26 or CLASS IS ( derived-type-spec ) [ select-construct-name ] 27 or CLASS DEFAULT [ select-construct-name ] 189 J3/06-007r1 WORKING DRAFT 2006/09/25 C833 (R848) The type-spec or derived-type-spec shall specify that each length type parameter is as- 1 sumed. 2 C834 (R848) The type-spec or derived-type-spec shall not specify a sequence derived type or a type 3 with the BIND attribute. 4 C835 (R848) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify 5 an extension of the declared type of selector . 6 C836 (R848) For a given select-type-construct, the same type and kind type parameter values shall 7 not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more 8 than one CLASS IS type-guard-stmt. 9 C837 (R848) For a given select-type-construct, there shall be at most one CLASS DEFAULT type- 10 guard-stmt. 11 R849 end-select-type-stmt is END SELECT [ select-construct-name ] 12 C838 (R846) If the select-type-stmt of a select-type-construct specifies a select-construct-name, the 13 corresponding end-select-type-stmt shall specify the same select-construct-name. If the select- 14 type-stmt of a select-type-construct does not specify a select-construct-name, the corresponding 15 end-select-type-stmt shall not specify a select-construct-name. If a type-guard-stmt specifies a 16 select-construct-name, the corresponding select-type-stmt shall specify the same select-construct- 17 name. 18 The associate name of a SELECT TYPE construct is the associate-name if specified; otherwise it is the 19 name that constitutes the selector . 20 8.1.9.2 Execution of the SELECT TYPE construct 21 Execution of a SELECT TYPE construct whose selector is not a variable causes the selector expression 22 to be evaluated. 23 A SELECT TYPE construct selects at most one block to be executed. During execution of that block, 24 the associate name identifies an entity, which is associated (16.5.1.6) with the selector. 25 A TYPE IS type guard statement matches the selector if the dynamic type and kind type parameter 26 values of the selector are the same as those specified by the statement. A CLASS IS type guard 27 statement matches the selector if the dynamic type of the selector is an extension of the type specified 28 by the statement and the kind type parameter values specified by the statement are the same as the 29 corresponding type parameter values of the dynamic type of the selector. 30 The block to be executed is selected as follows. 31 (1) If a TYPE IS type guard statement matches the selector, the block following that statement 32 is executed. 33 (2) Otherwise, if exactly one CLASS IS type guard statement matches the selector, the block 34 following that statement is executed. 35 (3) Otherwise, if several CLASS IS type guard statements match the selector, one of these 36 statements must specify a type that is an extension of all the types specified in the others; 37 the block following that statement is executed. 38 (4) Otherwise, if there is a CLASS DEFAULT type guard statement, the block following that 39 statement is executed. 40 NOTE 8.21 This algorithm does not examine the type guard statements in source text order when it looks for 190 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 8.21 (cont.) a match; it selects the most particular type guard when there are several potential matches. Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not 1 polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter 2 values of the selector. 3 Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and 4 has the declared type named in the type guard statement. The type parameter values of the associating 5 entity are the corresponding type parameter values of the selector. 6 Within the block following a CLASS DEFAULT type guard statement, the associating entity is poly- 7 morphic and has the same declared type as the selector. The type parameter values of the associating 8 entity are those of the declared type of the selector. 9 NOTE 8.22 If the declared type of the selector is T, specifying CLASS DEFAULT has the same effect as specifying CLASS IS (T). The other attributes of the associating entity are described in 8.1.3.3. 10 It is permissible to branch to an end-select-type-stmt only from within its SELECT TYPE construct. 11 8.1.9.3 Examples of the SELECT TYPE construct 12 NOTE 8.23 TYPE POINT REAL :: X, Y END TYPE POINT TYPE, EXTENDS(POINT) :: POINT_3D REAL :: Z END TYPE POINT_3D TYPE, EXTENDS(POINT) :: COLOR_POINT INTEGER :: COLOR END TYPE COLOR_POINT TYPE(POINT), TARGET :: P TYPE(POINT_3D), TARGET :: P3 TYPE(COLOR_POINT), TARGET :: C CLASS(POINT), POINTER :: P_OR_C P_OR_C => C SELECT TYPE ( A => P_OR_C ) CLASS IS ( POINT ) ! "CLASS ( POINT ) :: A" implied here PRINT *, A%X, A%Y ! This block gets executed TYPE IS ( POINT_3D ) ! "TYPE ( POINT_3D ) :: A" implied here PRINT *, A%X, A%Y, A%Z END SELECT 191 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.24 The following example illustrates the omission of associate-name. It uses the declarations from Note 8.23. P_OR_C => P3 SELECT TYPE ( P_OR_C ) CLASS IS ( POINT ) ! "CLASS ( POINT ) :: P_OR_C" implied here PRINT *, P_OR_C%X, P_OR_C%Y TYPE IS ( POINT_3D ) ! "TYPE ( POINT_3D ) :: P_OR_C" implied here PRINT *, P_OR_C%X, P_OR_C%Y, P_OR_C%Z ! This block gets executed END SELECT 8.1.10 EXIT statement 1 The EXIT statement provides one way of terminating a construct. 2 R850 exit-stmt is EXIT [ construct-name ] 3 C839 If a construct-name appears, the EXIT statement shall be within that construct; otherwise, it 4 shall be within the range of at least one do-construct. 5 An EXIT statement belongs to a particular construct. If the EXIT statement contains a construct 6 name, it belongs to that construct; otherwise, it belongs to the innermost DO construct in which it 7 appears. 8 C840 An exit-stmt shall not belong to a DO CONCURRENT construct, nor shall it appear within 9 the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO 10 CONCURRENT construct. 11 When an EXIT statement that belongs to a DO construct is executed, it terminates the loop (8.1.7.5.4) 12 and any active loops contained within the terminated loop. When an EXIT statement that belongs to 13 a non-DO construct is executed, it terminates any active loops contained within that construct, and 14 completes execution of that construct. 15 8.2 Branching 16 Branching is used to alter the normal execution sequence. A branch causes a transfer of control from 17 one statement in a scoping unit to a labeled branch target statement in the same scoping unit. Branching 18 may be caused by a GOTO statement, a computed GOTO statement, an arithmetic IF statement, a 19 CALL statement that has an alt-return-spec, or an input/output statement that has an END= or ERR= 20 specifier. Although procedure references and control constructs can cause transfer of control, they are 21 not branches. A branch target statement is an action-stmt, an associate-stmt, an end-associate- 22 stmt, an if-then-stmt, an end-if-stmt, a select-case-stmt, an end-select-stmt, a select-type-stmt, an end- 23 select-type-stmt, a do-stmt, an end-do-stmt, block-stmt, end-block-stmt, critical-stmt, end-critical-stmt, 24 a forall-construct-stmt, a do-term-action-stmt, a do-term-shared-stmt, or a where-construct-stmt. 25 8.2.1 GO TO statement 26 5 27 R851 goto-stmt is GO TO label 28 192 2006/09/25 WORKING DRAFT J3/06-007r1 C841 (R851) The label shall be the statement label of a branch target statement that appears in the 1 same scoping unit as the goto-stmt. 2 Execution of a GO TO statement causes a transfer of control so that the branch target statement 3 identified by the label is executed next. 4 8.2.2 Computed GO TO statement 5 R852 computed-goto-stmt is GO TO ( label-list ) [ , ] scalar-int-expr 6 7 C842 (R852 Each label in label-list shall be the statement label of a branch target statement that appears in the same scoping unit as the computed-goto-stmt. 8 NOTE 8.25 The same statement label may appear more than once in a label list. 9 Execution of a computed GO TO statement causes evaluation of the scalar integer expression. If this value is i such that 1 i n where n is the number of labels in label-list, a transfer of control occurs so that the next statement executed is 10 11 the one identified by the ith label in the list of labels. If i is less than 1 or greater than n, the execution sequence continues as though a CONTINUE statement were executed. 12 8.2.3 Arithmetic IF statement 13 R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label 14 15 C843 (R853) Each label shall be the label of a branch target statement that appears in the same scoping unit as the arithmetic-if-stmt. 16 C844 (R853) The scalar-numeric-expr shall not be of type complex. 17 NOTE 8.26 The same label may appear more than once in one arithmetic IF statement. 18 Execution of an arithmetic IF statement causes evaluation of the numeric expression followed by a transfer of control. The 19 branch target statement identified by the first label, the second label, or the third label is executed next depending on whether the value of the numeric expression is less than zero, equal to zero, or greater than zero, respectively. 20 8.3 CONTINUE statement 21 Execution of a CONTINUE statement has no effect. 22 R854 continue-stmt is CONTINUE 23 8.4 STOP statement 24 R855 stop-stmt is STOP [ stop-code ] 25 R856 stop-code is scalar-char-initialization-expr 26 or scalar-int-initialization-expr 27 C845 (R856) The scalar-char-initialization-expr shall be of default kind. 28 C846 (R856) The scalar-int-initialization-expr shall be of default kind. 29 Execution of a STOP statement causes normal termination of execution of that image. If each image 30 of a set of images executes a STOP statement immediately following the execution of a construct that 31 performs a synchronization of the images in the set, normal termination of execution occurs for all of 32 193 J3/06-007r1 WORKING DRAFT 2006/09/25 the images in the set; the executions of all other images are terminated. If termination of execution of 1 an image occurs for some other reason, termination of execution occurs on all other images. 2 J3 internal note Unresolved Technical Issue 005 1. Context-dependent meaning (immediately after SYNC ALL) is a bad idea, especially since "immediately following" is not well-defined. 2. Mixing "normal termination" and "error termination" is also probably a bad idea. In the past, STOP has always been "normal", and various other terminations have been "error" (DEALLOCATE of an unallocated allocatable). We have never felt the need to have a special statement for causing error termination, and having "STOP,ALL::" do "normal" termination on some images and "error" termination on other images is baroque. 3. We do not need to have semantics like "what happens when the user presses Control-C"; we have never had anything in the Fortran standard that did that before either. 4. Notation (editorial): we should probably define the term "error termination" and use it in the multiple places we mean that, instead of merely omitting "normal" before "termination". J3 internal note Unresolved Technical Issue 006 There is no explanation, let alone an adequate one, of when this (termination of execution of remote images) occurs. That means that there is no reason for the processor to terminate any other image, it can just let them run. Surely we want to at least terminate a remote image at the next attempt to SYNC with the image that executes "STOP,ALL::". NOTE 8.27 If all images execute a SYNC ALL statement and immediately afterwards execute a STOP state- ment, normal termination of execution occurs on all images. If only a subset of the images have their executions terminate normally, how soon termination takes place on the other images is processor dependent. When an image is terminated by a STOP statement, its stop code, if any, is made available in a 3 processor-dependent manner. If any exception (14) is signaling on that image, the processor shall issue 4 a warning indicating which exceptions are signaling; this warning shall be on the unit identified by the 5 named constant ERROR UNIT (13.8.3.5). It is recommended that the stop code is made available by 6 formatted output to the same unit. 7 NOTE 8.28 When normal termination occurs on more than one image, it is expected that a processor-dependent summary of the stop codes and signaling exceptions will be made available. NOTE 8.29 If the stop-code is an integer, it is recommended that the value also be used as the process exit status, if the operating system supports that concept. If the integer stop-code is used as the process exit status, the operating system might be able to interpret only values within a limited range, or only a limited portion of the integer value (for example, only the least-significant 8 bits). 194 2006/09/25 WORKING DRAFT J3/06-007r1 J3 internal note Unresolved Technical Issue 033 This recommendation for the process exit status does not provide any help for STOP without a code, or for END PROGRAM. Perhaps "STOP" should be equivalent to "STOP 42" whereas "END PROGRAM" should be equivalent to "STOP 5"? Not giving an exit code recommendation for "STOP charstring" is not very good either. 8.5 Image execution control 1 8.5.1 Image control statements 2 The execution sequence on each image is as specified in 2.3.6. 3 An image control statement affects the execution ordering between images. Each of the following is 4 an image control statement: 5 · SYNC ALL statement; 6 · SYNC TEAM statement; 7 · SYNC IMAGES statement; 8 · SYNC MEMORY statement; 9 · NOTIFY statement; 10 · QUERY statement; 11 · ALLOCATE or DEALLOCATE statement involving a co-array; 12 · CRITICAL or END CRITICAL statement (8.1.6); 13 · OPEN statement with a TEAM= specifier; 14 · CLOSE statement for a file that is open with a TEAM= specifier; 15 · END, END BLOCK, or RETURN statement that involves an implicit deallocation of a co-array; 16 · END PROGRAM statement; 17 · CALL statement for a collective subroutine (13.1). 18 During an execution of a statement that contains more than one reference to a procedure, image control 19 statements other than CRITICAL or END CRITICAL shall be executed in at most one of the procedures 20 invoked. 21 On each image, the sequence of statements executed before the first image control statement, between 22 the execution of two image control statements, or after the last image control statement is known as 23 a segment. The segment executed immediately before the execution of an image control statement 24 includes the evaluation of all expressions within the statement. 25 By execution of image control statements or user-defined ordering (8.5.6), the program can ensure that 26 the execution of the ith segment on image P, Pi , either precedes or succeeds the execution of the j th 27 segment on another image Q, Qj . If the program does not ensure this, segments Pi and Qj are unordered; 28 depending on the relative execution speeds of the images, some or all of the execution of the segment Pi 29 may take place at the same time as some or all of the execution of the segment Qj . 30 195 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.30 The set of all segments on all images is partially ordered: the segment Pi precedes segment Qj if and only if there is a sequence of segments starting with Pi and ending with Qj such that each segment of the sequence precedes the next either because they are on the same image or because of the execution of image control statements. A scalar co-variable that is of type default integer, default logical, default real, or default bits, and has 1 the VOLATILE attribute (5.3.18) may be referenced during the execution of a segment that is unordered 2 relative to the execution of a segment in which the co-variable is defined. Otherwise, 3 · if a co-array variable is defined on an image in a segment, it shall not be referenced or defined in 4 a segment on another image unless the segments are ordered, 5 · if the allocation of an allocatable subobject of a co-array or the pointer association of a pointer 6 subobject of a co-array is changed on an image in a segment, that subobject shall not be referenced 7 or defined in a segment on another image unless the segments are ordered, and 8 · if a procedure invocation on image P is in execution in segments Pi , Pi+1 , ..., Pk and defines a 9 non-co-array dummy argument, the argument associated entity shall not be referenced or defined 10 on another image Q in a segment Qj unless Qj precedes Pi or succeeds Pk . 11 NOTE 8.31 Apart from the effects of volatile variables, the processor may optimize the execution of a segment as if it were the only image in execution. NOTE 8.32 The model upon which the interpretation of a program is based is that there is a permanent memory location for each co-array variable and that all images can access it. In practice, an image may make a copy of a non-volatile co-array variable (in cache or a register, for example) and, as an optimization, defer copying a changed value back to the permanent location while it is still being used. Since the variable is not volatile, it is safe to defer this transfer until the end of the current segment and thereafter to reload from permanent memory any co-array variable that was not defined within the segment. It would not be safe to defer these actions beyond the end of the current segment since another image might reference the variable then. If an image P writes a record during the execution of Pi to a file that is opened for direct access with a 12 TEAM= specifier, no other image Q shall read or write the record during execution of a segment that 13 is unordered with Pi . Furthermore, it shall not read the record in a segment that succeeds Pi unless 14 · after image P writes the record, it executes a FLUSH statement (9.8) for the file during the 15 execution of a segment Pk , where k >= i, and 16 · before image Q reads the record, it executes a FLUSH statement for the file during the execution 17 of a segment Qj that succeeds Pk . 18 NOTE 8.33 The incorrect sequencing of image control statements can halt execution indefinitely. For example, one image might be executing a SYNC ALL statement while another is executing an ALLOCATE statement for a co-array; or one image might be executing a blocking QUERY statement for which an image in its image set never executes the corresponding NOTIFY statement. 196 2006/09/25 WORKING DRAFT J3/06-007r1 8.5.2 SYNC ALL statement 1 R857 sync-all-stmt is SYNC ALL [ ( [ sync-stat-list ] ) ] 2 R858 sync-stat is STAT = stat-variable 3 or ERRMSG = errmsg-variable 4 C847 No specifier shall appear more than once in a given sync-stat-list. 5 The STAT= and ERRMSG= specifiers for image execution control statements are described in 8.5.7. 6 Execution of a SYNC ALL statement performs a synchronization of all images. Execution on an image, 7 M, of the segment following the SYNC ALL statement is delayed until each other image has executed a 8 SYNC ALL statement as many times as has image M. The segments that executed before the SYNC ALL 9 statement on an image precede the segments that execute after the SYNC ALL statement on another 10 image. 11 NOTE 8.34 If synchronization is required when the images commence statement execution, a SYNC ALL statement should be the first executable statement of the main program. This is necessary if the code relies on the initialization of a co-array variable on another image. NOTE 8.35 The processor might have special hardware or employ an optimized algorithm to make the SYNC ALL statement execute efficiently. Here is a simple example of its use. Image 1 reads data and broadcasts it to other images: REAL :: P[*] ... SYNC ALL IF (THIS_IMAGE()==1) THEN READ (*,*) P DO I = 2, NUM_IMAGES() P[I] = P END DO END IF SYNC ALL 8.5.3 SYNC TEAM statement 12 R859 sync-team-stmt is SYNC TEAM ( image-team [ , sync-stat-list ] ) 13 R860 image-team is scalar-variable 14 C848 The image-team shall be a scalar variable of type IMAGE TEAM from the intrinsic module 15 ISO FORTRAN ENV. 16 Execution of a SYNC TEAM statement performs a team synchronization, which is a synchronization 17 of the images in a team. The team is specified by the value of image-team and shall include the executing 18 image. All images of the team shall execute a SYNC TEAM statement with a value of image-team that 19 was constructed by corresponding invocations of the intrinsic function FORM TEAM for the team. They 20 do not commence executing subsequent statements until all images in the team have executed a SYNC 21 TEAM statement for the team an equal number of times since FORM TEAM was invoked for the team. 22 If images M and T are any two members of the team, the segments that execute before the statement 23 197 J3/06-007r1 WORKING DRAFT 2006/09/25 on image M precede the segments that execute after the statement on image T. 1 Execution of an OPEN statement with a TEAM= specifier, a CLOSE statement for a unit whose connect 2 team consists of more than one image, or a CALL statement for a collective subroutine is interpreted as if 3 an execution of a SYNC TEAM statement for the team occurred at the beginning and end of execution 4 of the statement. The team is the set of images identified by the TEAM= specifier for the OPEN 5 statement, the unit's connect team for the CLOSE statement, the IMAGES argument for the FORM - 6 TEAM intrinsic procedure, or the argument of type IMAGE TEAM for all other collective subroutines. 7 This is called implicit team synchronization. 8 J3 internal note Unresolved Technical Issue 086 What happens if image-team identifies a team that does not include the image executing the SYNC TEAM statement? (For example, if it is NULL IMAGE TEAM.) It would be friendly for this to raise an error in the statement rather than making the program non-conformant. What happens if image-team is undefined (that is, has never been given a value)? It would be friendly for this to raise an error in the statement rather than making the program non- conformant. Given that IMAGE TEAM is a derived type, why not specify that it has default initialization and that this initializes it to the same value as NULL IMAGE TEAM. J3 internal note Unresolved Technical Issue 088 I assume that if a team consists of one image, the only effect of SYNC TEAM is to split the segment. So why not make CLOSE (of a connected unit) always collective? The compiler is going to have to split the segment anyway, just in case the connect-team has more than one image in it. NOTE 8.36 In this example the images are divided into two teams, one for an ocean calculation and one for an atmosphere calculation. USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(IMAGE_TEAM) :: TEAM INTEGER :: N2, STEP, NSTEPS LOGICAL :: OCEAN N2 = NUM_IMAGES()/2 OCEAN = (THIS_IMAGE()<=N2) IF(OCEAN) THEN CALL FORM_TEAM(TEAM, (/ (I, I=1,N2) /) ) ELSE CALL FORM_TEAM(TEAM, (/ (I, I=N2+1,NUM_IMAGES()) /) ) END IF : ! Initial calculation SYNC ALL DO STEP = 1, NSTEPS IF (OCEAN) THEN DO : ! Ocean calculation SYNC TEAM(TEAM) IF ( ... ) EXIT ! Ready to swap data END DO ELSE 198 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 8.36 (cont.) DO : ! Atmosphere calculation SYNC TEAM(TEAM) IF ( ... ) EXIT ! Ready to swap data END DO END IF SYNC ALL : ! Swap data END DO In the inner loops, each set of images first works entirely with its own data and each image synchronizes with the rest of its team. The number of synchronizations for the ocean team might differ from the number for the atmosphere team. The SYNC ALL statement that follows is needed to ensure that both teams have done their calculations before data are swapped. 8.5.4 SYNC IMAGES statement 1 R861 sync-images-stmt is SYNC IMAGES ( image-set [ , sync-stat-list ] ) 2 R862 image-set is int-expr 3 or * 4 C849 An image-set that is an int-expr shall be scalar or of rank one. 5 If image-set is an array expression, the value of each element shall be positive and not greater than the 6 number of images, and there shall be no repeated values. 7 If image-set is a scalar expression, its value shall be positive and not greater than the number of images. 8 An image-set that is an asterisk specifies all images. 9 Execution of a SYNC IMAGES statement performs a synchronization of the image with each of the 10 other images in the image-set. Execution on an image, M, of the segment following the SYNC IMAGES 11 statement is delayed until each other image T in the image-set has executed a SYNC IMAGES statement 12 with M in its image-set as many times as image M has executed a SYNC IMAGES statement with T in 13 the image-set. The segments that executed before the SYNC IMAGES statement on image M precede 14 the segments that execute after the SYNC IMAGES statement on image T. 15 NOTE 8.37 A SYNC IMAGES statement that specifies the single image value THIS IMAGE() in its image set is allowed. This simplifies writing programs for an arbitrary number of images by allowing correct execution in the limiting case of the number of images being equal to one. NOTE 8.38 Execution of a SYNC IMAGES(*) statement is not equivalent to the execution of a SYNC ALL statement. SYNC ALL causes all images to wait for each other. SYNC IMAGES statements are not required to specify the same image set on all the images participating in the synchronization. In the following example, image 1 will wait for each of the other images to complete its use of the data. The other images wait for image 1 to set up the data, but do not wait on any of the other images. IF (THIS_IMAGE() == 1) then 199 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.38 (cont.) ! Set up co-array data needed by all other images SYNC IMAGES(*) ELSE SYNC IMAGES(1) ! Use the data set up by image 1 END IF NOTE 8.39 Execution of a SYNC TEAM statement causes all the images of the team to wait for each other. There might, however, be situations where this is not efficient. In the following example, each image synchronizes with its neighbor. INTEGER :: ME, NE, STEP, NSTEPS NE = NUM_IMAGES() ME = THIS_IMAGE() ! Initial calculation SYNC ALL DO STEP = 1, NSTEPS IF (ME > 1) SYNC IMAGES(ME-1) ! Perform calculation IF (ME < NE) SYNC IMAGES(ME+1) END DO SYNC ALL The calculation starts on image 1 since all the others will be waiting on SYNC IMAGES(ME- 1). When this is done, image 2 can start and image 1 can perform its second calculation. This continues until they are all executing different steps at the same time. Eventually, image 1 will finish and then the others will finish one by one. The SYNC IMAGES syntax involves image-set rather than image-team to allow the set of images to vary from image to image. 8.5.5 NOTIFY and QUERY statements 1 R863 notify-stmt is NOTIFY ( image-set [ , sync-stat-list ] ) 2 R864 query-stmt is QUERY ( image-set [ , query-spec-list ] ) 3 R865 query-spec is READY = scalar-logical-variable 4 or sync-stat 5 C850 (R864) No specifier shall appear more than once in a given query-spec-list. 6 Execution on image M of a NOTIFY statement with a different image T in its image-set increments by 7 1 a record of the number of times, NM T , image M executed such a NOTIFY statement. 8 A QUERY statement is blocking if and only if it has no READY= specifier. A QUERY statement 9 is satisfied on completion of its execution if and only if it is a blocking QUERY statement or it set 10 the variable specified by its READY= specifier to true. Execution on image M of a satisfied QUERY 11 statement with a different image T included in its image set increases by 1 a record of the number of 12 times, QM T , image M executed such a QUERY statement. This increase is made after its value has 13 been compared with NT M . 14 If a READY= specifier appears, execution on image M of a QUERY statement causes the scalar-logical- 15 200 2006/09/25 WORKING DRAFT J3/06-007r1 variable to become defined. The value is false if, for a different image T in the image set, NT M 1 QM T . Otherwise, the value is true. 2 If a READY= specifier does not appear, increasing QM T and completing execution of the statement 3 is delayed until, for each different T in the image set, NT M > QM T . 4 A NOTIFY statement execution on image T and a satisfied QUERY statement on image M correspond 5 if and only if 6 · the NOTIFY statement's image set includes image M, 7 · the QUERY statement's image set includes image T, and 8 · after execution of both statements has completed, NT M = QM T . 9 Segments on an image executed before the execution of a NOTIFY statement precede the segments on 10 other images that follow its corresponding QUERY statements. 11 NOTE 8.40 The NOTIFY and QUERY statements can be used to order statement executions between a producer and consumer image. INTEGER,PARAMETER :: PRODUCER = 1, CONSUMER = 2 INTEGER :: VALUE[*] LOGICAL :: READY SELECT CASE (THIS_IMAGE()) CASE (PRODUCER) VALUE[CONSUMER] = 3 NOTIFY (CONSUMER) CASE (CONSUMER) WaitLoop: DO QUERY (PRODUCER,READY=READY) IF (READY) EXIT WaitLoop ! Statements neither referencing VALUE[CONSUMER], nor causing it to ! become defined or undefined END DO WaitLoop ! references to VALUE CASE DEFAULT ! Statements neither referencing VALUE[CONSUMER], nor causing it to ! become defined or undefined END SELECT Unlike SYNC IMAGES statements, the number of notifications and corresponding queries may be unequal. A program can complete with an excess number of notifies. NOTE 8.41 NOTIFY/QUERY pairs can be used in place of SYNC ALL and SYNC IMAGES to achieve better load balancing and allow one image to proceed with calculations while another image is catching up. For example, IF (THIS_IMAGE()==1) THEN DO I=1,100 201 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.41 (cont.) ... ! Primary processing of column I NOTIFY(2) ! Done with column I END DO SYNC IMAGES(2) ELSE IF (THIS_IMAGE()==2) THEN DO I=1,100 QUERY(1) ! Wait until image 1 is done with column I ... ! Secondary processing of column I END DO SYNC IMAGES(1) END IF 8.5.6 SYNC MEMORY statement 1 The SYNC MEMORY statement provides a means of dividing a segment on an image into two segments, 2 each of which can be ordered in some user-defined way with respect to segments on other images. 3 R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat-list ] ) ] 4 NOTE 8.42 SYNC MEMORY usually suppresses compiler optimizations that might reorder memory operations across the segment boundary defined by the SYNC MEMORY statement and ensures that all memory operations initiated in the preceding segments in its image complete before any memory operations in the subsequent segment in its image are initiated. It needs to do this unless it can establish that failure to do so could not alter processing on another image. All of the other image control statements include the effect of executing a SYNC MEMORY statement. 5 In addition, the other image control statements cause some form of cooperation with other images for 6 the purpose of ordering execution between images. 7 NOTE 8.43 A common example of user-written code that can be used in conjunction with SYNC MEMORY to implement specialized schemes for segment ordering is the spin-wait loop. For example: LOGICAL,VOLATILE :: LOCKED[*] = .TRUE. INTEGER :: IAM, P, Q IAM = THIS_IMAGE() IF (IAM == P) THEN ! Preceding segment SYNC MEMORY !A ! segment Pi LOCKED[Q] = .FALSE. SYNC MEMORY !B ELSE IF (IAM == Q) THEN ! segment Qj DO WHILE (LOCKED); END DO SYNC MEMORY !C ! Subsequent segment END IF Here, image Q does not complete the segment Qj until image P executes segment Pi . This ensures that executions of segments before Pi on image P precede executions of segments on image Q after 202 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 8.43 (cont.) Qj . The first SYNC MEMORY statement (A) ensures that the compiler does not reorder the following statement (locking) with the previous statements, since the lock should be freed only after the work has been completed. The definition of LOCKED[Q] might be deferred to the end of segment Pi . The second SYNC MEMORY statement (B) ends that segment immediately after the definition, minimizing any delay in releasing the lock in segment Qj . The third SYNC MEMORY statement (C) marks the beginning of a new segment, informing the compiler that the values of co-array variables referenced in that segment might have been changed by other images in preceding segments, so need to be loaded from memory. NOTE 8.44 As a second example, the user might have access to an external procedure that performs synchro- nization between images. That library procedure will not necessarily be aware of the mechanisms used by the processor to manage remote data references and definitions, and therefore not, by itself, be able to ensure the correct memory state before and after its reference. The SYNC MEM- ORY statement provides the needed memory ordering that enables the safe use of the external synchronization routine. For example: INTEGER :: IAM REAL :: X[*] IAM = THIS_IMAGE() IF (IAM == 1) X = 1.0 SYNC MEMORY CALL EXTERNAL_SYNC() SYNC MEMORY IF (IAM == 2) WRITE(*,*) X[1] where executing the subroutine EXTERNAL SYNC has an image synchronization effect similar to executing a SYNC ALL statement. 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements 1 If the STAT= specifier appears, successful execution of the SYNC ALL, SYNC TEAM, SYNC IMAGES, 2 SYNC MEMORY, NOTIFY, or QUERY statement causes the specified variable to become defined with 3 the value zero. If an error occurs during execution of one of these statements, the variable becomes 4 defined with a processor-dependent positive integer value. If an error condition occurs during execution 5 of a SYNC ALL, SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement 6 that does not contain the STAT= specifier, execution of all images is terminated. 7 If the ERRMSG= specifier appears and an error condition occurs during execution of the SYNC ALL, 8 SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement, the processor shall 9 assign an explanatory message to the specified variable. If no such condition occurs, the processor shall 10 not change the value of the variable. 11 203 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 8.45 Which errors, if any, are diagnosed is processor dependent. The processor might check that a valid set of images has been provided, with no out-of-range or repeated values. It might test for network time-outs. While the overall program would probably not be able to recover from the failure of an image, it could perhaps provide information on what failed and be able to save some of the program state to a file. 204 2006/09/25 WORKING DRAFT J3/06-007r1 9 Input/output statements 1 Input statements provide the means of transferring data from external media to internal storage or 2 from an internal file to internal storage. This process is called reading. Output statements provide 3 the means of transferring data from internal storage to external media or from internal storage to an 4 internal file. This process is called writing. Some input/output statements specify that editing of the 5 data is to be performed. 6 In addition to the statements that transfer data, there are auxiliary input/output statements to ma- 7 nipulate the external medium, or to describe or inquire about the properties of the connection to the 8 external medium. 9 The input/output statements are the OPEN, CLOSE, READ, WRITE, PRINT, BACKSPACE, END- 10 FILE, REWIND, FLUSH, WAIT, and INQUIRE statements. 11 The READ statement is a data transfer input statement. The WRITE statement and the PRINT 12 statement are data transfer output statements. The OPEN statement and the CLOSE state- 13 ment are file connection statements. The INQUIRE statement is a file inquiry statement. The 14 BACKSPACE, ENDFILE, and REWIND statements are file positioning statements. 15 A file is composed of either a sequence of file storage units (9.2.4) or a sequence of records, which 16 provide an extra level of organization to the file. A file composed of records is called a record file. A 17 file composed of file storage units is called a stream file. A processor may allow a file to be viewed 18 both as a record file and as a stream file; in this case the relationship between the file storage units when 19 viewed as a stream file and the records when viewed as a record file is processor dependent. 20 A file is either an external file (9.2) or an internal file (9.3). 21 9.1 Records 22 A record is a sequence of values or a sequence of characters. For example, a line on a terminal is usually 23 considered to be a record. However, a record does not necessarily correspond to a physical entity. There 24 are three kinds of records: 25 (1) formatted; 26 (2) unformatted; 27 (3) endfile. 28 NOTE 9.1 What is called a "record" in Fortran is commonly called a "logical record". There is no concept in Fortran of a "physical record." 9.1.1 Formatted record 29 A formatted record consists of a sequence of characters that are capable of representation in the 30 processor; however, a processor may prohibit some control characters (3.1) from appearing in a formatted 31 record. The length of a formatted record is measured in characters and depends primarily on the number 32 of characters put into the record when it is written. However, it may depend on the processor and the 33 external medium. The length may be zero. Formatted records may be read or written only by formatted 34 input/output statements. 35 205 J3/06-007r1 WORKING DRAFT 2006/09/25 Formatted records may be prepared by means other than Fortran. 1 9.1.2 Unformatted record 2 An unformatted record consists of a sequence of values in a processor-dependent form and may contain 3 data of any type or may contain no data. The length of an unformatted record is measured in file storage 4 units (9.2.4) and depends on the output list (9.5.3) used when it is written, as well as on the processor 5 and the external medium. The length may be zero. Unformatted records may be read or written only 6 by unformatted input/output statements. 7 9.1.3 Endfile record 8 An endfile record is written explicitly by the ENDFILE statement; the file shall be connected for 9 sequential access. An endfile record is written implicitly to a file connected for sequential access when 10 the most recent data transfer statement referring to the file is a data transfer output statement, no 11 intervening file positioning statement referring to the file has been executed, and 12 (1) a REWIND or BACKSPACE statement references the unit to which the file is connected, 13 or 14 (2) the unit is closed, either explicitly by a CLOSE statement, implicitly by a program termi- 15 nation not caused by an error condition, or implicitly by another OPEN statement for the 16 same unit. 17 An endfile record may occur only as the last record of a file. An endfile record does not have a length 18 property. 19 NOTE 9.2 An endfile record does not necessarily have any physical embodiment. The processor may use a record count or other means to register the position of the file at the time an ENDFILE statement is executed, so that it can take appropriate action when that position is reached again during a read operation. The endfile record, however it is implemented, is considered to exist for the BACKSPACE statement (9.7.2). 9.2 External files 20 An external file is any file that exists in a medium external to the program. 21 At any given time, there is a processor-dependent set of allowed access methods, a processor-dependent 22 set of allowed forms, a processor-dependent set of allowed actions, and a processor-dependent set of 23 allowed record lengths for a file. 24 NOTE 9.3 For example, the processor-dependent set of allowed actions for a printer would likely include the write action, but not the read action. A file may have a name; a file that has a name is called a named file. The name of a named file is 25 represented by a character string value. The set of allowable names for a file is processor dependent. 26 NOTE 9.4 Named files that are opened with the TEAM= specifier (9.4.5.17) have the same name on each image of the team. Apart from this, whether a named file on one image is the same as a file with the same name on another image is processor dependent. For code portability, if different files are 206 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.4 (cont.) needed on each image, different file names should be used. One technique is to incorporate the image number as part of the name. An external file that is connected to a unit has a position property (9.2.3). 1 NOTE 9.5 For more explanatory information on external files, see C.6.1. 9.2.1 File existence 2 At any given time, there is a processor-dependent set of external files that exist for a program. A file 3 may be known to the processor, yet not exist for a program at a particular time. 4 NOTE 9.6 Security reasons may prevent a file from existing for a program. A newly created file may exist but contain no records. To create a file means to cause a file to exist that did not exist previously. To delete a file means to 5 terminate the existence of the file. 6 All input/output statements may refer to files that exist. An INQUIRE, OPEN, CLOSE, WRITE, 7 PRINT, REWIND, FLUSH, or ENDFILE statement also may refer to a file that does not exist. Execu- 8 tion of a WRITE, PRINT, or ENDFILE statement referring to a preconnected file that does not exist 9 creates the file. 10 9.2.2 File access 11 There are three methods of accessing the data of an external file: sequential, direct, and stream. Some 12 files may have more than one allowed access method; other files may be restricted to one access method. 13 NOTE 9.7 For example, a processor may allow only sequential access to a file on magnetic tape. Thus, the set of allowed access methods depends on the file and the processor. The method of accessing a file is determined when the file is connected to a unit (9.4.3) or when the file 14 is created if the file is preconnected (9.4.4). 15 9.2.2.1 Sequential access 16 Sequential access is a method of accessing the records of an external record file in order. 17 When connected for sequential access, an external file has the following properties. 18 (1) The order of the records is the order in which they were written if the direct access method 19 is not a member of the set of allowed access methods for the file. If the direct access method 20 is also a member of the set of allowed access methods for the file, the order of the records 21 is the same as that specified for direct access. In this case, the first record accessible by 22 sequential access is the record whose record number is 1 for direct access. The second record 23 accessible by sequential access is the record whose record number is 2 for direct access, etc. 24 A record that has not been written since the file was created shall not be read. 25 (2) The records of the file are either all formatted or all unformatted, except that the last record 26 of the file may be an endfile record. Unless the previous reference to the file was a data 27 207 J3/06-007r1 WORKING DRAFT 2006/09/25 transfer output statement, the last record, if any, of the file shall be an endfile record. 1 (3) The records of the file shall be read or written only by sequential access input/output 2 statements. 3 (4) Each record shall be read or written by a single image. The processor shall ensure that once 4 an image commences transferring the data of a record to the file, no other image transfers 5 data to the file until the whole record has been transferred. 6 9.2.2.2 Direct access 7 Direct access is a method of accessing the records of an external record file in arbitrary order. 8 When connected for direct access, an external file has the following properties. 9 (1) Each record of the file is uniquely identified by a positive integer called the record number. 10 The record number of a record is specified when the record is written. Once established, 11 the record number of a record can never be changed. The order of the records is the order 12 of their record numbers. 13 NOTE 9.8 A record cannot be deleted; however, a record may be rewritten. (2) The records of the file are either all formatted or all unformatted. If the sequential access 14 method is also a member of the set of allowed access methods for the file, its endfile record, 15 if any, is not considered to be part of the file while it is connected for direct access. If the 16 sequential access method is not a member of the set of allowed access methods for the file, 17 the file shall not contain an endfile record. 18 (3) The records of the file shall be read or written only by direct access input/output statements. 19 (4) All records of the file have the same length. 20 (5) Records need not be read or written in the order of their record numbers. Any record may 21 be written into the file while it is connected to a unit. For example, it is permissible to write 22 record 3, even though records 1 and 2 have not been written. Any record may be read from 23 the file while it is connected to a unit, provided that the record has been written since the 24 file was created, and if a READ statement for this connection is permitted. 25 (6) The records of the file shall not be read or written using list-directed formatting (10.10), 26 namelist formatting (10.11), or a nonadvancing input/output statement (9.2.3.1). 27 9.2.2.3 Stream access 28 Stream access is a method of accessing the file storage units (9.2.4) of an external stream file. 29 The properties of an external file connected for stream access depend on whether the connection is for 30 unformatted or formatted access. 31 When connected for unformatted stream access, an external file has the following properties. 32 (1) The file storage units of the file shall be read or written only by stream access input/output 33 statements. 34 (2) Each file storage unit in the file is uniquely identified by a positive integer called the position. 35 The first file storage unit in the file is at position 1. The position of each subsequent file 36 storage unit is one greater than that of its preceding file storage unit. 37 (3) If it is possible to position the file, the file storage units need not be read or written in 38 order of their position. For example, it might be permissible to write the file storage unit 39 at position 3, even though the file storage units at positions 1 and 2 have not been written. 40 Any file storage unit may be read from the file while it is connected to a unit, provided that 41 208 2006/09/25 WORKING DRAFT J3/06-007r1 the file storage unit has been written since the file was created, and if a READ statement 1 for this connection is permitted. 2 When connected for formatted stream access, an external file has the following properties. 3 (1) Some file storage units of the file may contain record markers; this imposes a record structure 4 on the file in addition to its stream structure. There might or might not be a record marker 5 at the end of the file. If there is no record marker at the end of the file, the final record is 6 incomplete. 7 (2) No maximum length (9.4.5.13) is applicable to these records. 8 (3) Writing an empty record with no record marker has no effect. 9 NOTE 9.9 Because the record structure is determined from the record markers that are stored in the file itself, an incomplete record at the end of the file is necessarily not empty. (4) The file storage units of the file shall be read or written only by formatted stream access 10 input/output statements. 11 (5) Each file storage unit in the file is uniquely identified by a positive integer called the position. 12 The first file storage unit in the file is at position 1. The relationship between positions of 13 successive file storage units is processor dependent; not all positive integers need correspond 14 to valid positions. 15 (6) If it is possible to position the file, the file position can be set to a position that was 16 previously identified by the POS= specifier in an INQUIRE statement. 17 NOTE 9.10 There may be some character positions in the file that do not correspond to characters written; this is because on some processors a record marker may be written to the file as a carriage-return/line- feed or other sequence. The means of determining the position in a file connected for stream access is via the POS= specifier in an INQUIRE statement (9.9.2.21). (7) A processor may prohibit some control characters (3.1) from appearing in a formatted stream 18 file. 19 9.2.3 File position 20 Execution of certain input/output statements affects the position of an external file. Certain circum- 21 stances can cause the position of a file to become indeterminate. 22 The initial point of a file is the position just before the first record or file storage unit. The terminal 23 point is the position just after the last record or file storage unit. If there are no records or file storage 24 units in the file, the initial point and the terminal point are the same position. 25 If a record file is positioned within a record, that record is the current record; otherwise, there is no 26 current record. 27 Let n be the number of records in the file. If 1 < i n and a file is positioned within the ith record or 28 between the (i - 1)th record and the ith record, the (i - 1)th record is the preceding record. If n 1 29 and the file is positioned at its terminal point, the preceding record is the nth and last record. If n = 0 30 or if a file is positioned at its initial point or within the first record, there is no preceding record. 31 If 1 i < n and a file is positioned within the ith record or between the ith and (i + 1)th record, the 32 (i + 1)th record is the next record. If n 1 and the file is positioned at its initial point, the first record 33 is the next record. If n = 0 or if a file is positioned at its terminal point or within the nth (last) record, 34 there is no next record. 35 209 J3/06-007r1 WORKING DRAFT 2006/09/25 For a file connected for stream access, the file position is either between two file storage units, at the 1 initial point of the file, at the terminal point of the file, or undefined. 2 9.2.3.1 Advancing and nonadvancing input/output 3 An advancing input/output statement always positions a record file after the last record read or 4 written, unless there is an error condition. 5 A nonadvancing input/output statement may position a record file at a character position within 6 the current record, or a subsequent record (10.8.2). Using nonadvancing input/output, it is possible to 7 read or write a record of the file by a sequence of input/output statements, each accessing a portion 8 of the record. It is also possible to read variable-length records and be notified of their lengths. If a 9 nonadvancing output statement leaves a file positioned within a current record and no further output 10 statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement 11 is executed for it, the effect is as if the output statement were the corresponding advancing output 12 statement. 13 9.2.3.2 File position prior to data transfer 14 The positioning of the file prior to data transfer depends on the method of access: sequential, direct, or 15 stream. 16 For sequential access on input, if there is a current record, the file position is not changed. Otherwise, 17 the file is positioned at the beginning of the next record and this record becomes the current record. 18 Input shall not occur if there is no next record or if there is a current record and the last data transfer 19 statement accessing the file performed output. 20 If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data 21 transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file. 22 For sequential access on output, if there is a current record, the file position is not changed and the 23 current record becomes the last record of the file. Otherwise, a new record is created as the next record 24 of the file; this new record becomes the last and current record of the file and the file is positioned at 25 the beginning of this record. 26 For direct access, the file is positioned at the beginning of the record specified by the REC= specifier. 27 This record becomes the current record. 28 For stream access, the file is positioned immediately before the file storage unit specified by the POS= 29 specifier; if there is no POS= specifier, the file position is not changed. 30 File positioning for child data transfer statements is described in 9.5.4.7. 31 9.2.3.3 File position after data transfer 32 If an error condition (9.10) occurred, the position of the file is indeterminate. If no error condition 33 occurred, but an end-of-file condition (9.10) occurred as a result of reading an endfile record, the file is 34 positioned after the endfile record. 35 For unformatted stream access, if no error condition occurred, the file position is not changed. For 36 unformatted stream output, if the file position exceeds the previous terminal point of the file, the 37 terminal point is set to the file position. 38 NOTE 9.11 An unformatted stream output statement with a POS= specifier and an empty output list can have the effect of extending the terminal point of a file without actually writing any data. 210 2006/09/25 WORKING DRAFT J3/06-007r1 For formatted stream input, if an end-of-file condition occurred, the file position is not changed. 1 For nonadvancing input, if no error condition or end-of-file condition occurred, but an end-of-record 2 condition (9.10) occurred, the file is positioned after the record just read. If no error condition, end-of- 3 file condition, or end-of-record condition occurred in a nonadvancing input statement, the file position 4 is not changed. If no error condition occurred in a nonadvancing output statement, the file position is 5 not changed. 6 In all other cases, the file is positioned after the record just read or written and that record becomes the 7 preceding record. 8 For a formatted stream output statement, if no error condition occurred, the terminal point of the file 9 is set to the highest-numbered position to which data was transferred by the statement. 10 NOTE 9.12 The highest-numbered position might not be the current one if the output involved T or TL edit descriptors (10.8.1.1) and the statement is a nonadvancing output statement. 9.2.4 File storage units 11 A file storage unit is the basic unit of storage in a stream file or an unformatted record file. It is the 12 unit of file position for stream access, the unit of record length for unformatted files, and the unit of file 13 size for all external files. 14 Every value in a stream file or an unformatted record file shall occupy an integer number of file storage 15 units; if the stream or record file is unformatted, this number shall be the same for all scalar values of 16 the same type and type parameters. The number of file storage units required for an item of a given type 17 and type parameters may be determined using the IOLENGTH= specifier of the INQUIRE statement 18 (9.9.3). 19 For a file connected for unformatted stream access, the processor shall not have alignment restrictions 20 that prevent a value of any type from being stored at any positive integer file position. 21 The number of bits in a file storage unit is given by the constant FILE STORAGE SIZE (13.8.3.6) 22 defined in the intrinsic module ISO FORTRAN ENV. It is recommended that the file storage unit be 23 an 8-bit octet where this choice is practical. 24 NOTE 9.13 The requirement that every data value occupy an integer number of file storage units implies that data items inherently smaller than a file storage unit will require padding. This suggests that the file storage unit be small to avoid wasted space. Ideally, the file storage unit would be chosen such that padding is never required. A file storage unit of one bit would always meet this goal, but would likely be impractical because of the alignment requirements. The prohibition on alignment restrictions prohibits the processor from requiring data alignments larger than the file storage unit. The 8-bit octet is recommended as a good compromise that is small enough to accommodate the requirements of many applications, yet not so small that the data alignment requirements are likely to cause significant performance problems. 9.3 Internal files 25 211 J3/06-007r1 WORKING DRAFT 2006/09/25 Internal files provide a means of transferring and converting data from internal storage to internal 1 storage. 2 An internal file is a record file with the following properties. 3 (1) The file is a variable of default, ASCII, or ISO 10646 character type that is not an array 4 section with a vector subscript. 5 (2) A record of an internal file is a scalar character variable. 6 (3) If the file is a scalar character variable, it consists of a single record whose length is the same 7 as the length of the scalar character variable. If the file is a character array, it is treated 8 as a sequence of character array elements. Each array element, if any, is a record of the 9 file. The ordering of the records of the file is the same as the ordering of the array elements 10 in the array (6.2.2.2) or the array section (6.2.2.3). Every record of the file has the same 11 length, which is the length of an array element in the array. 12 (4) A record of the internal file becomes defined by writing the record. If the number of 13 characters written in a record is less than the length of the record, the remaining portion 14 of the record is filled with blanks. The number of characters to be written shall not exceed 15 the length of the record. 16 (5) A record may be read only if the record is defined. 17 (6) A record of an internal file may become defined (or undefined) by means other than an 18 output statement. For example, the character variable may become defined by a character 19 assignment statement. 20 (7) An internal file is always positioned at the beginning of the first record prior to data transfer, 21 except for child data transfer statements (9.5.4.7). This record becomes the current record. 22 (8) The initial value of a connection mode (9.4.1) is the value that would be implied by an 23 initial OPEN statement without the corresponding keyword. 24 (9) Reading and writing records shall be accomplished only by sequential access formatted 25 input/output statements. 26 (10) An internal file shall not be specified as the unit in a file connection statement or a file 27 positioning statement. 28 9.4 File connection 29 A unit, specified by an io-unit, provides a means for referring to a file. 30 R901 io-unit is file-unit-number 31 or * 32 or internal-file-variable 33 R902 file-unit-number is scalar-int-expr 34 R903 internal-file-variable is char-variable 35 C901 (R903) The char-variable shall not be an array section with a vector subscript. 36 C902 (R903) The char-variable shall be of type default character, ASCII character, or ISO 10646 37 character. 38 A unit is either an external unit or an internal unit. An external unit is used to refer to an external file 39 and is specified by an asterisk or a file-unit-number . The value of file-unit-number shall be nonnegative, 40 equal to one of the named constants INPUT UNIT, OUTPUT UNIT, or ERROR UNIT of the ISO - 41 FORTRAN ENV module (13.8.3), or a NEWUNIT value (9.4.5.10). An internal unit is used to refer 42 to an internal file and is specified by an internal-file-variable or a file-unit-number whose value is equal 43 to the unit argument of an active derived-type input/output procedure (9.5.4.7). The value of a file- 44 unit-number shall identify a valid unit. 45 212 2006/09/25 WORKING DRAFT J3/06-007r1 The external unit identified by a particular value of a scalar-int-expr is the same external unit in all 1 program units of the program, and on all images. 2 NOTE 9.14 In the example: SUBROUTINE A READ (6) X ... SUBROUTINE B N=6 REWIND N the value 6 used in both program units identifies the same external unit. An asterisk identifies particular processor-dependent external units that are preconnected for format- 3 ted sequential access (9.5.4.2). These units are also identified by unit numbers defined by the named 4 constants INPUT UNIT and OUTPUT UNIT of the ISO FORTRAN ENV module (13.8.3). 5 This standard identifies a processor-dependent external unit for the purpose of error reporting. This 6 unit shall be preconnected for sequential formatted output. The processor may define this to be the 7 same as the output unit identified by an asterisk. This unit is also identified by a unit number defined 8 by the named constant ERROR UNIT of the ISO FORTRAN ENV intrinsic module. 9 9.4.1 Connection modes 10 A connection for formatted input/output has several changeable modes: the blank interpretation mode 11 (10.8.6), delimiter mode (10.10.4, 10.11.4.1), sign mode (10.8.4), decimal edit mode (10.8.8), I/O round- 12 ing mode (10.7.2.3.7), pad mode (9.5.4.4.2), and scale factor (10.8.5). A connection for unformatted 13 input/output has no changeable modes. 14 Values for the modes of a connection are established when the connection is initiated. If the connection 15 is initiated by an OPEN statement, the values are as specified, either explicitly or implicitly, by the 16 OPEN statement. If the connection is initiated other than by an OPEN statement (that is, if the file is 17 an internal file or preconnected file) the values established are those that would be implied by an initial 18 OPEN statement without the corresponding keywords. 19 The scale factor cannot be explicitly specified in an OPEN statement; it is implicitly 0. 20 The modes of a connection to an external file may be changed by a subsequent OPEN statement that 21 modifies the connection. 22 The modes of a connection may be temporarily changed by a corresponding keyword specifier in a 23 data transfer statement or by an edit descriptor. Keyword specifiers take effect at the beginning of 24 execution of the data transfer statement. Edit descriptors take effect when they are encountered in 25 format processing. When a data transfer statement terminates, the values for the modes are reset to the 26 values in effect immediately before the data transfer statement was executed. 27 9.4.2 Unit existence 28 At any given time, there is a processor-dependent set of external units that exist for a program. 29 All input/output statements may refer to units that exist. The CLOSE, INQUIRE, and WAIT state- 30 ments also may refer to units that do not exist. 31 213 J3/06-007r1 WORKING DRAFT 2006/09/25 9.4.3 Connection of a file to a unit 1 An external unit has a property of being connected or not connected. If connected, it refers to an 2 external file, and the connection is for a team of images. An external unit may become connected by 3 preconnection or by the execution of an OPEN statement. The property of connection is symmetric; the 4 unit is connected to a file if and only if the file is connected to the unit. 5 J3 internal note Unresolved Technical Issue 039 The second sentence now contains irrelevant commentary, and merely implies contradiction with the first sentence, rather than a direct contradiction. Since (i/o units now are or soon will be) not global, what relevance has the TEAM= specifier to the property of connection? No more than whether the unit is connected for formatted/unformatted, direct/sequential/stream, etc. Not doing the edit to the second sentence (i.e. deleting ", and the connection is for a team of images") would be sufficient to resolve this issue here; the discussion of TEAM= also warrants reviewing. Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement shall refer to 6 a unit that is connected to a file and thereby make use of or affect that file. 7 A file may be connected and not exist (9.2.1). 8 NOTE 9.15 An example is a preconnected external file that has not yet been written. A unit shall not be connected to more than one file at the same time, and a file shall not be connected to 9 more than one unit at the same time. However, means are provided to change the status of an external 10 unit and to connect a unit to a different file. 11 This standard defines means of portable interoperation with C. C streams are described in 7.19.2 of the C 12 International Standard. Whether a unit may be connected to a file that is also connected to a C stream 13 is processor dependent. If the processor allows a unit to be connected to a file that is also connected to 14 a C stream, the results of performing input/output operations on such a file are processor dependent. 15 It is processor dependent whether the files connected to the units INPUT UNIT, OUTPUT UNIT, 16 and ERROR UNIT correspond to the predefined C text streams standard input, standard output, and 17 standard error. If a procedure defined by means of Fortran and a procedure defined by means other than 18 Fortran perform input/output operations on the same external file, the results are processor dependent. 19 A procedure defined by means of Fortran and a procedure defined by means other than Fortran can 20 perform input/output operations on different external files without interference. 21 After an external unit has been disconnected by the execution of a CLOSE statement, it may be con- 22 nected again within the same program to the same file or to a different file. After an external file has 23 been disconnected by the execution of a CLOSE statement, it may be connected again within the same 24 program to the same unit or to a different unit. 25 NOTE 9.16 The only means of referencing a file that has been disconnected is by the appearance of its name in an OPEN or INQUIRE statement. There might be no means of reconnecting an unnamed file once it is disconnected. An internal unit is always connected to the internal file designated by the variable that identifies the 26 unit. 27 214 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.17 For more explanatory information on file connection properties, see C.6.5. 9.4.4 Preconnection 1 Preconnection means that the unit is connected to a file at the beginning of execution of the program 2 and therefore it may be specified in input/output statements without the prior execution of an OPEN 3 statement. 4 9.4.5 OPEN statement 5 An OPEN statement initiates or modifies the connection between an external file and a specified unit. 6 The OPEN statement may be used to connect an existing file to a unit, create a file that is preconnected, 7 create a file and connect it to a unit, or change certain modes of a connection between a file and a unit. 8 An external unit may be connected by an OPEN statement in any program unit of a program and, once 9 connected, a reference to it may appear in any program unit of the program. 10 If the file to be connected to the unit does not exist but is the same as the file to which the unit is 11 preconnected, the modes specified by an OPEN statement become a part of the connection. 12 If the file to be connected to the unit is not the same as the file to which the unit is connected, the effect 13 is as if a CLOSE statement without a STATUS= specifier had been executed for the unit immediately 14 prior to the execution of an OPEN statement. 15 If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. 16 If the FILE= specifier is not included in such an OPEN statement, the file to be connected to the unit 17 is the same as the file to which the unit is already connected. 18 If the file to be connected to the unit is the same as the file to which the unit is connected, only the 19 specifiers for changeable modes (9.4.1) may have values different from those currently in effect. If the 20 POSITION= specifier appears in such an OPEN statement, the value specified shall not disagree with 21 the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it shall 22 be specified with the value OLD. Execution of such an OPEN statement causes any new values of the 23 specifiers for changeable modes to be in effect, but does not cause any change in any of the unspecified 24 specifiers and the position of the file is unaffected. The ERR=, IOSTAT=, and IOMSG= specifiers from 25 any previously executed OPEN statement have no effect on any currently executed OPEN statement. 26 A STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is 27 the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH 28 before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the 29 file is still considered to have a status of SCRATCH. 30 If a file is already connected to a unit, execution of an OPEN statement on that file and a different unit 31 is not permitted. 32 R904 open-stmt is OPEN ( connect-spec-list ) 33 R905 connect-spec is [ UNIT = ] file-unit-number 34 or ACCESS = scalar-default-char-expr 35 or ACTION = scalar-default-char-expr 36 or ASYNCHRONOUS = scalar-default-char-expr 37 or BLANK = scalar-default-char-expr 38 or DECIMAL = scalar-default-char-expr 39 or DELIM = scalar-default-char-expr 40 or ENCODING = scalar-default-char-expr 41 215 J3/06-007r1 WORKING DRAFT 2006/09/25 or ERR = label 1 or FILE = file-name-expr 2 or FORM = scalar-default-char-expr 3 or IOMSG = iomsg-variable 4 or IOSTAT = scalar-int-variable 5 or NEWUNIT = scalar-int-variable 6 or PAD = scalar-default-char-expr 7 or POSITION = scalar-default-char-expr 8 or RECL = scalar-int-expr 9 or ROUND = scalar-default-char-expr 10 or SIGN = scalar-default-char-expr 11 or STATUS = scalar-default-char-expr 12 or TEAM = image-team 13 R906 file-name-expr is scalar-default-char-expr 14 R907 iomsg-variable is scalar-default-char-variable 15 C903 No specifier shall appear more than once in a given connect-spec-list. 16 C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be specified; if 17 the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the 18 connect-spec-list. 19 C905 (R904) The label used in the ERR= specifier shall be the statement label of a branch target 20 statement that appears in the same scoping unit as the OPEN statement. 21 C906 (R904) If a NEWUNIT= specifier appears, a file-unit-number shall not appear. 22 If the STATUS= specifier has the value NEW or REPLACE, the FILE= specifier shall appear. If the 23 STATUS= specifier has the value SCRATCH, the FILE= specifier shall not appear. If the STATUS= 24 specifier has the value OLD, the FILE= specifier shall appear unless the unit is connected and the file 25 connected to the unit exists. 26 If the NEWUNIT= specifier appears in an OPEN statement, either the FILE= specifier shall appear, 27 or the STATUS= specifier shall appear with a value of SCRATCH. The unit identified by a NEWUNIT 28 value shall not be preconnected. 29 A specifier that requires a scalar-default-char-expr may have a limited list of character values. These 30 values are listed for each such specifier. Any trailing blanks are ignored. The value specified is without 31 regard to case. Some specifiers have a default value if the specifier is omitted. 32 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 33 NOTE 9.18 An example of an OPEN statement is: OPEN (10, FILE = 'employee.names', ACTION = 'READ', PAD = 'YES') NOTE 9.19 For more explanatory information on the OPEN statement, see C.6.4. 9.4.5.1 ACCESS= specifier in the OPEN statement 34 The scalar-default-char-expr shall evaluate to SEQUENTIAL, DIRECT, or STREAM. The ACCESS= 35 specifier specifies the access method for the connection of the file as being sequential, direct, or stream. 36 If this specifier is omitted, the default value is SEQUENTIAL. For an existing file, the specified access 37 216 2006/09/25 WORKING DRAFT J3/06-007r1 method shall be included in the set of allowed access methods for the file. For a new file, the processor 1 creates the file with a set of allowed access methods that includes the specified method. 2 9.4.5.2 ACTION= specifier in the OPEN statement 3 The scalar-default-char-expr shall evaluate to READ, WRITE, or READWRITE. READ specifies that 4 the WRITE, PRINT, and ENDFILE statements shall not refer to this connection. WRITE specifies 5 that READ statements shall not refer to this connection. READWRITE permits any input/output 6 statements to refer to this connection. If this specifier is omitted, the default value is processor dependent. 7 If READWRITE is included in the set of allowable actions for a file, both READ and WRITE also shall 8 be included in the set of allowed actions for that file. For an existing file, the specified action shall be 9 included in the set of allowed actions for the file. For a new file, the processor creates the file with a set 10 of allowed actions that includes the specified action. 11 9.4.5.3 ASYNCHRONOUS= specifier in the OPEN statement 12 The scalar-default-char-expr shall evaluate to YES or NO. If YES is specified, asynchronous input/output 13 on the unit is allowed. If NO is specified, asynchronous input/output on the unit is not allowed. If this 14 specifier is omitted, the default value is NO. 15 9.4.5.4 BLANK= specifier in the OPEN statement 16 The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier is permitted only 17 for a connection for formatted input/output. It specifies the current value of the blank interpretation 18 mode (10.8.6, 9.5.2.6) for input for this connection. This mode has no effect on output. It is a changeable 19 mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the default 20 value is NULL. 21 9.4.5.5 DECIMAL= specifier in the OPEN statement 22 The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier is per- 23 mitted only for a connection for formatted input/output. It specifies the current value of the decimal 24 edit mode (10.6, 10.8.8, 9.5.2.7) for this connection. This is a changeable mode (9.4.1). If this specifier 25 is omitted in an OPEN statement that initiates a connection, the default value is POINT. 26 9.4.5.6 DELIM= specifier in the OPEN statement 27 The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 28 ifier is permitted only for a connection for formatted input/output. It specifies the current value of the 29 delimiter mode (9.5.2.8) for list-directed (10.10.4) and namelist (10.11.4.1) output for the connection. 30 This mode has no effect on input. It is a changeable mode (9.4.1). If this specifier is omitted in an 31 OPEN statement that initiates a connection, the default value is NONE. 32 9.4.5.7 ENCODING= specifier in the OPEN statement 33 The scalar-default-char-expr shall evaluate to UTF-8 or DEFAULT. The ENCODING= specifier is 34 permitted only for a connection for formatted input/output. The value UTF-8 specifies that the encoding 35 form of the file is UTF-8 as specified by ISO/IEC 10646-1:2000. Such a file is called a Unicode file, 36 and all characters therein are of ISO 10646 character type. The value UTF-8 shall not be specified if 37 the processor does not support the ISO 10646 character type. The value DEFAULT specifies that the 38 encoding form of the file is processor-dependent. If this specifier is omitted in an OPEN statement that 39 initiates a connection, the default value is DEFAULT. 40 217 J3/06-007r1 WORKING DRAFT 2006/09/25 9.4.5.8 FILE= specifier in the OPEN statement 1 The value of the FILE= specifier is the name of the file to be connected to the specified unit. Any trailing 2 blanks are ignored. The file-name-expr shall be a name that is allowed by the processor. If this specifier 3 is omitted and the unit is not connected to a file, the STATUS= specifier shall be specified with a value 4 of SCRATCH; in this case, the connection is made to a processor-dependent file. The interpretation of 5 case is processor dependent. 6 9.4.5.9 FORM= specifier in the OPEN statement 7 The scalar-default-char-expr shall evaluate to FORMATTED or UNFORMATTED. The FORM= spec- 8 ifier determines whether the file is being connected for formatted or unformatted input/output. If this 9 specifier is omitted, the default value is UNFORMATTED if the file is being connected for direct access 10 or stream access, and the default value is FORMATTED if the file is being connected for sequential 11 access. For an existing file, the specified form shall be included in the set of allowed forms for the file. 12 For a new file, the processor creates the file with a set of allowed forms that includes the specified form. 13 9.4.5.10 NEWUNIT= specifier in the OPEN statement 14 The variable is defined with a processor determined NEWUNIT value if no error occurs during the 15 execution of the OPEN statement. If an error occurs, the processor shall not change the value of the 16 variable. 17 A NEWUNIT value is a negative number, and shall not be equal to -1, any of the named constants 18 ERROR UNIT, INPUT UNIT, or OUTPUT UNIT from the ISO FORTRAN ENV intrinsic module 19 (13.8.3), any value used by the processor for the unit argument to a user-defined derived-type in- 20 put/output procedure, nor any previous NEWUNIT value that identifies a file that is currently con- 21 nected. 22 9.4.5.11 PAD= specifier in the OPEN statement 23 The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier is permitted only for a 24 connection for formatted input/output. It specifies the current value of the pad mode (9.5.4.4.2, 9.5.2.10) 25 for input for this connection. This mode has no effect on output. It is a changeable mode (9.4.1). If this 26 specifier is omitted in an OPEN statement that initiates a connection, the default value is YES. 27 NOTE 9.20 For nondefault character types, the blank padding character is processor dependent. 9.4.5.12 POSITION= specifier in the OPEN statement 28 The scalar-default-char-expr shall evaluate to ASIS, REWIND, or APPEND. The connection shall be 29 for sequential or stream access. A new file is positioned at its initial point. REWIND positions an 30 existing file at its initial point. APPEND positions an existing file such that the endfile record is the 31 next record, if it has one. If an existing file does not have an endfile record, APPEND positions the 32 file at its terminal point. ASIS leaves the position unchanged if the file exists and already is connected. 33 ASIS leaves the position unspecified if the file exists but is not connected. If this specifier is omitted, 34 the default value is ASIS. 35 9.4.5.13 RECL= specifier in the OPEN statement 36 The value of the RECL= specifier shall be positive. It specifies the length of each record in a file being 37 connected for direct access, or specifies the maximum length of a record in a file being connected for 38 sequential access. This specifier shall not appear when a file is being connected for stream access. This 39 specifier shall appear when a file is being connected for direct access. If this specifier is omitted when 40 218 2006/09/25 WORKING DRAFT J3/06-007r1 a file is being connected for sequential access, the default value is processor dependent. If the file is 1 being connected for formatted input/output, the length is the number of characters for all records that 2 contain only characters of type default character. When a record contains any nondefault characters, 3 the appropriate value for the RECL= specifier is processor dependent. If the file is being connected for 4 unformatted input/output, the length is measured in file storage units. For an existing file, the value of 5 the RECL= specifier shall be included in the set of allowed record lengths for the file. For a new file, 6 the processor creates the file with a set of allowed record lengths that includes the specified value. 7 9.4.5.14 ROUND= specifier in the OPEN statement 8 The scalar-default-char-expr shall evaluate to one of UP, DOWN, ZERO, NEAREST, COMPATIBLE, 9 or PROCESSOR DEFINED. The ROUND= specifier is permitted only for a connection for formatted 10 input/output. It specifies the current value of the I/O rounding mode (10.7.2.3.7, 9.5.2.13) for this 11 connection. This is a changeable mode (9.4.1). If this specifier is omitted in an OPEN statement that 12 initiates a connection, the I/O rounding mode is processor dependent; it shall be one of the above modes. 13 NOTE 9.21 A processor is free to select any I/O rounding mode for the default mode. The mode might correspond to UP, DOWN, ZERO, NEAREST, or COMPATIBLE; or it might be a completely different I/O rounding mode. 9.4.5.15 SIGN= specifier in the OPEN statement 14 The scalar-default-char-expr shall evaluate to one of PLUS, SUPPRESS, or PROCESSOR DEFINED. 15 The SIGN= specifier is permitted only for a connection for formatted input/output. It specifies the 16 current value of the sign mode (10.8.4, 9.5.2.14) for this connection. This is a changeable mode (9.4.1). 17 If this specifier is omitted in an OPEN statement that initiates a connection, the default value is PRO- 18 CESSOR DEFINED. 19 9.4.5.16 STATUS= specifier in the OPEN statement 20 The scalar-default-char-expr shall evaluate to OLD, NEW, SCRATCH, REPLACE, or UNKNOWN. If 21 OLD is specified, the file shall exist. If NEW is specified, the file shall not exist. 22 Successful execution of an OPEN statement with NEW specified creates the file and changes the status 23 to OLD. If REPLACE is specified and the file does not already exist, the file is created and the status is 24 changed to OLD. If REPLACE is specified and the file does exist, the file is deleted, a new file is created 25 with the same name, and the status is changed to OLD. If SCRATCH is specified, the file is created 26 and connected to the specified unit for use by the program but is deleted at the execution of a CLOSE 27 statement referring to the same unit or at the normal termination of the program. 28 NOTE 9.22 SCRATCH shall not be specified with a named file. If UNKNOWN is specified, the status is processor dependent. If this specifier is omitted, the default 29 value is UNKNOWN. 30 9.4.5.17 TEAM= specifier in the OPEN statement 31 The image-team specifies the connect team for the unit, which is the set of images that are permitted 32 to reference the unit. The team shall include the executing image. If there is no TEAM= specifier, the 33 connect team consists of only the executing image. 34 All images in the connect team, and no others, shall execute the same OPEN statement with identical 35 219 J3/06-007r1 WORKING DRAFT 2006/09/25 values for the connect-specs. There is an implicit team synchronization. 1 If the OPEN statement has a STATUS= specifier with the value SCRATCH, the processor shall connect 2 the same file to the unit on all images in the connect team. 3 If the connect team contains more than one image, the OPEN statement shall 4 · specify direct access or 5 · specify sequential access and have an ACTION= specifier that evaluates to WRITE. 6 NOTE 9.23 Writing to a sequential file from more than one image without using synchronization is permitted, but is only useful for situations in which the ordering of records is unimportant. An example is for diagnostic output that is labeled with the image index. Preconnected units and the units identified by the values INPUT UNIT, OUTPUT UNIT, and ERROR - 7 UNIT in the intrinsic module ISO FORTRAN ENV have a connect team consisting of all the images. If 8 an image with index greater than one executes an input/output statement on one of these units, it shall 9 be a WRITE or PRINT statement. 10 J3 internal note Unresolved Technical Issue 042 Prohibiting INQUIRE seems ... excessive and unwarranted to say the least. Subgroup agree, but there is still a question-mark over other i/o statements. (BACKSPACE, ENDFILE, WAIT, FLUSH, CLOSE, OPEN, REWIND). J3 internal note Unresolved Technical Issue 043 Since READ is prohibited except on image one, in what way does INPUT UNIT have a connect team (since no-one can do anything)? Surely it would be simpler if its connect term were image 1 only? As implied by the following note... NOTE 9.24 The input unit identified by * is therefore only available on the image with index one. 9.4.6 CLOSE statement 11 The CLOSE statement is used to terminate the connection of a specified unit to an external file. 12 Execution of a CLOSE statement for a unit may occur in any program unit of a program and need not 13 occur in the same program unit as the execution of an OPEN statement referring to that unit. 14 Execution of a CLOSE statement performs a wait operation for any pending asynchronous data transfer 15 operations for the specified unit. 16 Execution of a CLOSE statement specifying a unit that does not exist or has no file connected to it is 17 permitted and affects no file or unit. 18 After a unit has been disconnected by execution of a CLOSE statement, it may be connected again 19 within the same program, either to the same file or to a different file. After a named file has been 20 disconnected by execution of a CLOSE statement, it may be connected again within the same program, 21 either to the same unit or to a different unit, provided that the file still exists. 22 220 2006/09/25 WORKING DRAFT J3/06-007r1 At normal termination of execution of a program, all units that are connected are closed. Each unit 1 is closed with status KEEP unless the file status prior to termination of execution was SCRATCH, in 2 which case the unit is closed with status DELETE. 3 NOTE 9.25 The effect is as though a CLOSE statement without a STATUS= specifier were executed on each connected unit. R908 close-stmt is CLOSE ( close-spec-list ) 4 R909 close-spec is [ UNIT = ] file-unit-number 5 or IOSTAT = scalar-int-variable 6 or IOMSG = iomsg-variable 7 or ERR = label 8 or STATUS = scalar-default-char-expr 9 C907 No specifier shall appear more than once in a given close-spec-list. 10 C908 A file-unit-number shall be specified in a close-spec-list; if the optional characters UNIT= are 11 omitted, the file-unit-number shall be the first item in the close-spec-list. 12 C909 (R909) The label used in the ERR= specifier shall be the statement label of a branch target 13 statement that appears in the same scoping unit as the CLOSE statement. 14 The scalar-default-char-expr has a limited list of character values. Any trailing blanks are ignored. The 15 value specified is without regard to case. 16 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 17 NOTE 9.26 An example of a CLOSE statement is: CLOSE (10, STATUS = 'KEEP') NOTE 9.27 For more explanatory information on the CLOSE statement, see C.6.6. 9.4.6.1 STATUS= specifier in the CLOSE statement 18 The scalar-default-char-expr shall evaluate to KEEP or DELETE. The STATUS= specifier determines 19 the disposition of the file that is connected to the specified unit. KEEP shall not be specified for a file 20 whose status prior to execution of a CLOSE statement is SCRATCH. If KEEP is specified for a file that 21 exists, the file continues to exist after the execution of a CLOSE statement. If KEEP is specified for a 22 file that does not exist, the file will not exist after the execution of a CLOSE statement. If DELETE is 23 specified, the file will not exist after the execution of a CLOSE statement. If this specifier is omitted, the 24 default value is KEEP, unless the file status prior to execution of the CLOSE statement is SCRATCH, 25 in which case the default value is DELETE. 26 9.5 Data transfer statements 27 9.5.1 General 28 The READ statement is the data transfer input statement. The WRITE statement and the 29 PRINT statement are the data transfer output statements. 30 221 J3/06-007r1 WORKING DRAFT 2006/09/25 R910 read-stmt is READ ( io-control-spec-list ) [ input-item-list ] 1 or READ format [ , input-item-list ] 2 R911 write-stmt is WRITE ( io-control-spec-list ) [ output-item-list ] 3 R912 print-stmt is PRINT format [ , output-item-list ] 4 NOTE 9.28 Examples of data transfer statements are: READ (6, *) SIZE READ 10, A, B WRITE (6, 10) A, S, J PRINT 10, A, S, J 10 FORMAT (2E16.3, I5) 9.5.2 Control information list 5 9.5.2.1 Syntax 6 A control information list is an io-control-spec-list. It governs data transfer. 7 R913 io-control-spec is [ UNIT = ] io-unit 8 or [ FMT = ] format 9 or [ NML = ] namelist-group-name 10 or ADVANCE = scalar-default-char-expr 11 or ASYNCHRONOUS = scalar-char-initialization-expr 12 or BLANK = scalar-default-char-expr 13 or DECIMAL = scalar-default-char-expr 14 or DELIM = scalar-default-char-expr 15 or END = label 16 or EOR = label 17 or ERR = label 18 or ID = scalar-int-variable 19 or IOMSG = iomsg-variable 20 or IOSTAT = scalar-int-variable 21 or PAD = scalar-default-char-expr 22 or POS = scalar-int-expr 23 or REC = scalar-int-expr 24 or ROUND = scalar-default-char-expr 25 or SIGN = scalar-default-char-expr 26 or SIZE = scalar-int-variable 27 C910 No specifier shall appear more than once in a given io-control-spec-list. 28 C911 An io-unit shall be specified in an io-control-spec-list; if the optional characters UNIT= are 29 omitted, the io-unit shall be the first item in the io-control-spec-list. 30 C912 (R913) A DELIM= or SIGN= specifier shall not appear in a read-stmt. 31 C913 (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt. 32 C914 (R913) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 33 branch target statement that appears in the same scoping unit as the data transfer statement. 34 C915 (R913) A namelist-group-name shall be the name of a namelist group. 35 222 2006/09/25 WORKING DRAFT J3/06-007r1 C916 (R913) A namelist-group-name shall not appear if an input-item-list or an output-item-list 1 appears in the data transfer statement. 2 C917 (R913) An io-control-spec-list shall not contain both a format and a namelist-group-name. 3 C918 (R913) If format appears without a preceding FMT=, it shall be the second item in the io- 4 control-spec-list and the first item shall be io-unit. 5 C919 (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item 6 in the io-control-spec-list and the first item shall be io-unit. 7 C920 (R913) If io-unit is not a file-unit-number , the io-control-spec-list shall not contain a REC= 8 specifier or a POS= specifier. 9 C921 (R913) If the REC= specifier appears, an END= specifier shall not appear, a namelist-group- 10 name shall not appear, and the format, if any, shall not be an asterisk. 11 C922 (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- 12 put/output statement with explicit format specification (10.2) whose control information list 13 does not contain an internal-file-variable as the io-unit. 14 C923 (R913) If an EOR= specifier appears, an ADVANCE= specifier also shall appear. 15 C924 (R913) If a SIZE= specifier appears, an ADVANCE= specifier also shall appear. 16 C925 (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type 17 default character and shall have the value YES or NO. 18 C926 (R913) An ASYNCHRONOUS= specifier with a value YES shall not appear unless io-unit is a 19 file-unit-number . 20 C927 (R913) If an ID= specifier appears, an ASYNCHRONOUS= specifier with the value YES shall 21 also appear. 22 C928 (R913) If a POS= specifier appears, the io-control-spec-list shall not contain a REC= specifier. 23 C929 (R913) If a DECIMAL=, BLANK=, PAD=, SIGN=, or ROUND= specifier appears, a format 24 or namelist-group-name shall also appear. 25 C930 (R913) If a DELIM= specifier appears, either format shall be an asterisk or namelist-group-name 26 shall appear. 27 A SIZE= specifier may appear only in an input statement that contains an ADVANCE= specifier with 28 the value NO. 29 An EOR= specifier may appear only in an input statement that contains an ADVANCE= specifier with 30 the value NO. 31 If the data transfer statement contains a format or namelist-group-name, the statement is a formatted 32 input/output statement; otherwise, it is an unformatted input/output statement. 33 The ADVANCE=, ASYNCHRONOUS=, DECIMAL=, BLANK=, DELIM=, PAD=, SIGN=, and 34 ROUND= specifiers have a limited list of character values. Any trailing blanks are ignored. The 35 values specified are without regard to case. 36 The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 37 223 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 9.29 An example of a READ statement is: READ (IOSTAT = IOS, UNIT = 6, FMT = '(10F8.2)') A, B 9.5.2.2 Format specification in a data transfer statement 1 The format specifier supplies a format specification or specifies list-directed formatting for a formatted 2 input/output statement. 3 R914 format is default-char-expr 4 or label 5 or * 6 C931 (R914) The label shall be the label of a FORMAT statement that appears in the same scoping 7 unit as the statement containing the FMT= specifier. 8 The default-char-expr shall evaluate to a valid format specification (10.2.1 and 10.2.2). 9 NOTE 9.30 A default-char-expr includes a character constant. If default-char-expr is an array, it is treated as if all of the elements of the array were specified in array 10 element order and were concatenated. 11 If format is *, the statement is a list-directed input/output statement. 12 NOTE 9.31 An example in which the format is a character expression is: READ (6, FMT = "(" // CHAR_FMT // ")" ) X, Y, Z where CHAR FMT is a default character variable. 9.5.2.3 NML= specifier in a data transfer statement 13 The NML= specifier supplies the namelist-group-name (5.6). This name identifies a particular collection 14 of data objects on which transfer is to be performed. 15 If a namelist-group-name appears, the statement is a namelist input/output statement. 16 9.5.2.4 ADVANCE= specifier in a data transfer statement 17 The scalar-default-char-expr shall evaluate to YES or NO. The ADVANCE= specifier determines wheth- 18 er advancing input/output occurs for a nonchild input/output statement. If YES is specified for a 19 nonchild input/output statement, advancing input/output occurs. If NO is specified, nonadvancing in- 20 put/output occurs (9.2.3.1). If this specifier is omitted from a nonchild input/output statement that 21 allows the specifier, the default value is YES. A formatted child input/output statement is a nonadvanc- 22 ing input/output statement, and any ADVANCE= specifier is ignored. 23 9.5.2.5 ASYNCHRONOUS= specifier in a data transfer statement 24 The ASYNCHRONOUS= specifier determines whether this input/output statement is synchronous or 25 asynchronous. If YES is specified, the statement and the input/output operation are asynchronous. 26 224 2006/09/25 WORKING DRAFT J3/06-007r1 If NO is specified or if the specifier is omitted, the statement and the input/output operation are 1 synchronous. 2 Asynchronous input/output is permitted only for external files opened with an ASYNCHRONOUS= 3 specifier with the value YES in the OPEN statement. 4 NOTE 9.32 Both synchronous and asynchronous input/output are allowed for files opened with an ASYN- CHRONOUS= specifier of YES. For other files, only synchronous input/output is allowed; this includes files opened with an ASYNCHRONOUS= specifier of NO, files opened without an ASYN- CHRONOUS= specifier, preconnected files accessed without an OPEN statement, and internal files. The ASYNCHRONOUS= specifier value in a data transfer statement is an initialization expression because it effects compiler optimizations and, therefore, needs to be known at compile time. The processor may perform an asynchronous data transfer operation asynchronously, but it is not re- 5 quired to do so. For each external file, records and file storage units read or written by asynchronous 6 data transfer statements are read, written, and processed in the same order as they would have been if 7 the data transfer statements were synchronous. 8 If a variable is used in an asynchronous data transfer statement as 9 (1) an item in an input/output list, 10 (2) a group object in a namelist, or 11 (3) a SIZE= specifier 12 the base object of the data-ref is implicitly given the ASYNCHRONOUS attribute in the scoping unit 13 of the data transfer statement. This attribute may be confirmed by explicit declaration. 14 When an asynchronous input/output statement is executed, the set of storage units specified by the 15 item list or NML= specifier, plus the storage units specified by the SIZE= specifier, is defined to be the 16 pending input/output storage sequence for the data transfer operation. 17 NOTE 9.33 A pending input/output storage sequence is not necessarily a contiguous set of storage units. A pending input/output storage sequence affector is a variable of which any part is associated with a 18 storage unit in a pending input/output storage sequence. 19 9.5.2.6 BLANK= specifier in a data transfer statement 20 The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier temporarily 21 changes (9.4.1) the blank interpretation mode (10.8.6, 9.4.5.4) for the connection. If the specifier is 22 omitted, the mode is not changed. 23 9.5.2.7 DECIMAL= specifier in a data transfer statement 24 The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier temporar- 25 ily changes (9.4.1) the decimal edit mode (10.6, 10.8.8, 9.4.5.5) for the connection. If the specifier is 26 omitted, the mode is not changed. 27 9.5.2.8 DELIM= specifier in a data transfer statement 28 225 J3/06-007r1 WORKING DRAFT 2006/09/25 The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 1 ifier temporarily changes (9.4.1) the delimiter mode (10.10.4, 10.11.4.1, 9.4.5.6) for the connection. If 2 the specifier is omitted, the mode is not changed. 3 9.5.2.9 ID= specifier in a data transfer statement 4 Successful execution of an asynchronous data transfer statement containing an ID= specifier causes the 5 variable specified in the ID= specifier to become defined with a processor-dependent value. This value 6 is referred to as the identifier of the data transfer operation. It can be used in a subsequent WAIT or 7 INQUIRE statement to identify the particular data transfer operation. 8 If an error occurs during the execution of a data transfer statement containing an ID= specifier, the 9 variable specified in the ID= specifier becomes undefined. 10 A child data transfer statement shall not specify the ID= specifier. 11 9.5.2.10 PAD= specifier in a data transfer statement 12 The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier temporarily changes 13 (9.4.1) the pad mode (9.5.4.4.2, 9.4.5.11) for the connection. If the specifier is omitted, the mode is not 14 changed. 15 9.5.2.11 POS= specifier in a data transfer statement 16 The POS= specifier specifies the file position in file storage units. This specifier may appear in a data 17 transfer statement only if the statement specifies a unit connected for stream access. A child data 18 transfer statement shall not specify this specifier. 19 A processor may prohibit the use of POS= with particular files that do not have the properties necessary 20 to support random positioning. A processor may also prohibit positioning a particular file to any 21 position prior to its current file position if the file does not have the properties necessary to support such 22 positioning. 23 NOTE 9.34 A file that represents connection to a device or data stream might not be positionable. If the file is connected for formatted stream access, the file position specified by POS= shall be equal to 24 either 1 (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE 25 statement for the file. 26 9.5.2.12 REC= specifier in a data transfer statement 27 The REC= specifier specifies the number of the record that is to be read or written. This specifier 28 may appear only in an input/output statement that specifies a unit connected for direct access; it 29 shall not appear in a child data transfer statement. If the control information list contains a REC= 30 specifier, the statement is a direct access input/output statement. A child data transfer statement 31 is a direct access data transfer statement if the parent is a direct access data transfer statement. Any 32 other data transfer statement is a sequential access input/output statement or a stream access 33 input/output statement, depending on whether the file connection is for sequential access or stream 34 access. 35 9.5.2.13 ROUND= specifier in a data transfer statement 36 The scalar-default-char-expr shall evaluate to one of the values specified in 9.4.5.14. The ROUND= 37 specifier temporarily changes (9.4.1) the I/O rounding mode (10.7.2.3.7, 9.4.5.14) for the connection. If 38 226 2006/09/25 WORKING DRAFT J3/06-007r1 the specifier is omitted, the mode is not changed. 1 9.5.2.14 SIGN= specifier in a data transfer statement 2 The scalar-default-char-expr shall evaluate to PLUS, SUPPRESS, or PROCESSOR DEFINED. The 3 SIGN= specifier temporarily changes (9.4.1) the sign mode (10.8.4, 9.4.5.15) for the connection. If the 4 specifier is omitted, the mode is not changed. 5 9.5.2.15 SIZE= specifier in a data transfer statement 6 When a synchronous nonadvancing input statement terminates, the variable specified in the SIZE= 7 specifier becomes defined with the count of the characters transferred by data edit descriptors during 8 execution of the current input statement. Blanks inserted as padding (9.5.4.4.2) are not counted. 9 For asynchronous nonadvancing input, the storage units specified in the SIZE= specifier become defined 10 with the count of the characters transferred when the corresponding wait operation is executed. 11 9.5.3 Data transfer input/output list 12 An input/output list specifies the entities whose values are transferred by a data transfer input/output 13 statement. 14 R915 input-item is variable 15 or io-implied-do 16 R916 output-item is expr 17 or io-implied-do 18 R917 io-implied-do is ( io-implied-do-object-list , io-implied-do-control ) 19 R918 io-implied-do-object is input-item 20 or output-item 21 R919 io-implied-do-control is do-variable = scalar-int-expr , 22 scalar-int-expr [ , scalar-int-expr ] 23 C932 (R915) A variable that is an input-item shall not be a whole assumed-size array. 24 C933 (R915) A variable that is an input-item shall not be a procedure pointer. 25 C934 (R919) The do-variable shall be a named scalar variable of type integer. 26 C935 (R918) In an input-item-list, an io-implied-do-object shall be an input-item. In an output-item- 27 list, an io-implied-do-object shall be an output-item. 28 C936 (R916) An expression that is an output-item shall not have a value that is a procedure pointer. 29 An input-item shall not appear as, nor be associated with, the do-variable of any io-implied-do that 30 contains the input-item. 31 NOTE 9.35 A constant, an expression involving operators or function references that does not have a pointer result, or an expression enclosed in parentheses shall not appear as an input list item. If an input item is a pointer, it shall be associated with a definable target and data are transferred from 32 the file to the associated target. If an output item is a pointer, it shall be associated with a target and 33 data are transferred from the target to the file. 34 227 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 9.36 Data transfers always involve the movement of values between a file and internal storage. A pointer as such cannot be read or written. Therefore, a pointer shall not appear as an item in an input/output list unless it is associated with a target that can receive a value (input) or can deliver a value (output). If an input item or an output item is allocatable, it shall be allocated. 1 A list item shall not be polymorphic unless it is processed by a user-defined derived-type input/output 2 procedure (9.5.4.7). 3 The do-variable of an io-implied-do that is in another io-implied-do shall not appear as, nor be associated 4 with, the do-variable of the containing io-implied-do. 5 The following rules describing whether to expand an input/output list item are re-applied to each 6 expanded list item until none of the rules apply. 7 · If an array appears as an input/output list item, it is treated as if the elements, if any, were 8 specified in array element order (6.2.2.2). However, no element of that array may affect the value 9 of any expression in the input-item, nor may any element appear more than once in an input-item. 10 NOTE 9.37 For example: INTEGER A (100), J (100) ... READ *, A (A) ! Not allowed READ *, A (LBOUND (A, 1) : UBOUND (A, 1)) ! Allowed READ *, A (J) ! Allowed if no two elements ! of J have the same value A(1) = 1; A(10) = 10 READ *, A (A (1) : A (10)) ! Not allowed · If a list item of derived type in an unformatted input/output statement is not processed by a 11 user-defined derived-type input/output procedure (9.5.4.7), and if any subobject of that list item 12 would be processed by a user-defined derived-type input/output procedure, the list item is treated 13 as if all of the components of the object were specified in the list in component order (4.5.4.6); 14 those components shall be accessible in the scoping unit containing the input/output statement 15 and shall not be pointers or allocatable. 16 · An effective input/output list item of derived type in an unformatted input/output statement is 17 treated as a single value in a processor-dependent form unless the list item or a subobject thereof 18 is processed by a user-defined derived-type input/output procedure (9.5.4.7). 19 NOTE 9.38 The appearance of a derived-type object as an input/output list item in an unformatted in- put/output statement is not equivalent to the list of its components. Unformatted input/output involving derived-type list items forms the single exception to the rule that the appearance of an aggregate list item (such as an array) is equivalent to the appearance of its expanded list of component parts. This exception permits the processor greater latitude in improving efficiency or in matching the processor-dependent sequence of values for a derived-type object to similar sequences for aggregate objects used by means other than Fortran. However, 228 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.38 (cont.) formatted input/output of all list items and unformatted input/output of list items other than those of derived types adhere to the above rule. · If a list item of derived type in a formatted input/output statement is not processed by a user- 1 defined derived-type input/output procedure, that list item is treated as if all of the components 2 of the list item were specified in the list in component order; those components shall be accessible 3 in the scoping unit containing the input/output statement and shall not be pointers or allocatable. 4 · If a derived-type list item is not treated as a list of its individual components, that list item's 5 ultimate components shall not have the POINTER or ALLOCATABLE attribute unless that list 6 item is processed by a user-defined derived-type input/output procedure. 7 · The scalar objects resulting when a data transfer statement's list items are expanded according 8 to the rules in this subclause for handling array and derived-type list items are called effective 9 items. Zero-sized arrays and io-implied-dos with an iteration count of zero do not contribute to 10 the effective list items. A scalar character item of zero length is an effective list item. 11 NOTE 9.39 In a formatted input/output statement, edit descriptors are associated with effective list items, which are always scalar. The rules in 9.5.3 determine the set of effective list items corresponding to each actual list item in the statement. These rules might have to be applied repetitively until all of the effective list items are scalar items. · For an io-implied-do, the loop initialization and execution are the same as for a DO construct 12 (8.1.7.5). 13 NOTE 9.40 An example of an output list with an implied DO is: WRITE (LP, FMT = '(10F8.2)') (LOG (A (I)), I = 1, N + 9, K), G · An input/output list shall not contain an item of nondefault character type if the input/output 14 statement specifies an internal file of default character type. An input/output list shall not con- 15 tain an item of nondefault character type other than ISO 10646 or ASCII character type if the 16 input/output statement specifies an internal file of ISO 10646 character type. An input/output 17 list shall not contain a character item of any character type other than ASCII character type if 18 the input/output statement specifies an internal file of ASCII character type. 19 9.5.4 Execution of a data transfer input/output statement 20 Execution of a WRITE or PRINT statement for a file that does not exist creates the file unless an error 21 condition occurs. 22 The effect of executing a synchronous data transfer input/output statement shall be as if the following 23 operations were performed in the order specified. 24 (1) Determine the direction of data transfer. 25 (2) Identify the unit. 26 (3) Perform a wait operation for all pending input/output operations for the unit. If an error, 27 end-of-file, or end-of-record condition occurs during any of the wait operations, steps 4 28 through 8 are skipped for the current data transfer statement. 29 (4) Establish the format if one is specified. 30 229 J3/06-007r1 WORKING DRAFT 2006/09/25 (5) If the statement is not a child data transfer statement (9.5.4.7), 1 (a) position the file prior to data transfer (9.2.3.2), and 2 (b) for formatted data transfer, set the left tab limit (10.8.1.1). 3 (6) Transfer data between the file and the entities specified by the input/output list (if any) or 4 namelist. 5 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. 6 (8) Position the file after data transfer (9.2.3.3) unless the statement is a child data transfer 7 statement (9.5.4.7). 8 (9) Cause any variable specified in a SIZE= specifier to become defined. 9 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 10 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 11 The effect of executing an asynchronous data transfer input/output statement shall be as if the following 12 operations were performed in the order specified. 13 (1) Determine the direction of data transfer. 14 (2) Identify the unit. 15 (3) Establish the format if one is specified. 16 (4) Position the file prior to data transfer (9.2.3.2) and, for formatted data transfer, set the left 17 tab limit (10.8.1.1). 18 (5) Establish the set of storage units identified by the input/output list. For a READ statement, 19 this might require some or all of the data in the file to be read if an input variable is used 20 as a scalar-int-expr in an io-implied-do-control in the input/output list, as a subscript, 21 substring-range, stride, or is otherwise referenced. 22 (6) Initiate an asynchronous data transfer between the file and the entities specified by the 23 input/output list (if any) or namelist. The asynchronous data transfer may complete (and 24 an error, end-of-file, or end-of-record condition may occur) during the execution of this data 25 transfer statement or during a later wait operation. 26 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. The con- 27 ditions may occur during the execution of this data transfer statement or during the corre- 28 sponding wait operation, but not both. 29 Also, any of these conditions that would have occurred during the corresponding wait oper- 30 ation for a previously pending data transfer operation that does not have an ID= specifier 31 may occur during the execution of this data transfer statement. 32 J3 internal note Unresolved Technical Issue 091 Contradiction; two paragraphs earlier, we say it occurs during the execution of the original i/o statement or "during a later wait operation". There is no wait operation in an async i/o statement. The best fix for this is to probably add an additional action to the list: "Optionally, perform a wait operation for a pending input/output operation for this unit." Also, note the difference in specification between this item (para 1) and the text four paragraphs after the list on wait operations. These should be consistent, and preferably specified only once. (8) Position the file as if the data transfer had finished (9.2.3.3). 33 (9) Cause any variable specified in a SIZE= specifier to become undefined. 34 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 35 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 36 For an asynchronous data transfer statement, the data transfers may occur during execution of the 37 statement, during execution of the corresponding wait operation, or anywhere between. The data transfer 38 230 2006/09/25 WORKING DRAFT J3/06-007r1 operation is considered to be pending until a corresponding wait operation is performed. 1 For asynchronous output, a pending input/output storage sequence affector (9.5.2.5) shall not be rede- 2 fined, become undefined, or have its pointer association status changed. 3 For asynchronous input, a pending input/output storage sequence affector shall not be referenced, be- 4 come defined, become undefined, become associated with a dummy argument that has the VALUE 5 attribute, or have its pointer association status changed. 6 Error, end-of-file, and end-of-record conditions in an asynchronous data transfer operation may occur 7 during execution of either the data transfer statement or the corresponding wait operation. If an ID= 8 specifier does not appear in the initiating data transfer statement, the conditions may occur during the 9 execution of any subsequent data transfer or wait operation for the same unit. When a condition occurs 10 for a previously executed asynchronous data transfer statement, a wait operation is performed for all 11 pending data transfer operations on that unit. When a condition occurs during a subsequent statement, 12 any actions specified by IOSTAT=, IOMSG=, ERR=, END=, and EOR= specifiers for that statement 13 are taken. 14 NOTE 9.41 Because end-of-file and error conditions for asynchronous data transfer statements without an ID= specifier may be reported by the processor during the execution of a subsequent data transfer statement, it may be impossible for the user to determine which input/output statement caused the condition. Reliably detecting which READ statement caused an end-of-file condition requires that all asynchronous READ statements for the unit include an ID= specifier. 9.5.4.1 Direction of data transfer 15 Execution of a READ statement causes values to be transferred from a file to the entities specified by 16 the input list, if any, or specified within the file itself for namelist input. Execution of a WRITE or 17 PRINT statement causes values to be transferred to a file from the entities specified by the output list 18 and format specification, if any, or by the namelist-group-name for namelist output. 19 9.5.4.2 Identifying a unit 20 A data transfer input/output statement that contains an input/output control list includes a UNIT= 21 specifier that identifies an external or internal unit. A READ statement that does not contain an 22 input/output control list specifies a particular processor-dependent unit, which is the same as the unit 23 identified by * in a READ statement that contains an input/output control list. The PRINT statement 24 specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE 25 statement. Thus, each data transfer input/output statement identifies an external or internal unit. 26 The unit identified by an unformatted data transfer statement shall be an external unit. 27 The unit identified by a data transfer input/output statement shall be connected to a file when execution 28 of the statement begins. 29 NOTE 9.42 The unit may be preconnected. 9.5.4.3 Establishing a format 30 If the input/output control list contains * as a format, list-directed formatting is established. If namelist- 31 group-name appears, namelist formatting is established. If no format or namelist-group-name is speci- 32 fied, unformatted data transfer is established. Otherwise, the format specified by format is established. 33 231 J3/06-007r1 WORKING DRAFT 2006/09/25 For output to an internal file, a format specification that is in the file or is associated with the file shall 1 not be specified. 2 9.5.4.4 Data transfer 3 Data are transferred between the file and the entities specified by the input/output list or namelist. 4 The list items are processed in the order of the input/output list for all data transfer input/output 5 statements except namelist formatted data transfer statements. The list items for a namelist input 6 statement are processed in the order of the entities specified within the input records. The list items 7 for a namelist output statement are processed in the order in which the variables are specified in the 8 namelist-group-object-list. Effective items are derived from the input/output list items as described in 9 9.5.3. 10 All values needed to determine which entities are specified by an input/output list item are determined 11 at the beginning of the processing of that item. 12 All values are transmitted to or from the entities specified by a list item prior to the processing of any 13 succeeding list item for all data transfer input/output statements. 14 NOTE 9.43 In the example, READ (N) N, X (N) the old value of N identifies the unit, but the new value of N is the subscript of X. All values following the name= part of the namelist entity (10.11) within the input records are transmit- 15 ted to the matching entity specified in the namelist-group-object-list prior to processing any succeeding 16 entity within the input record for namelist input statements. If an entity is specified more than once 17 within the input record during a namelist formatted data transfer input statement, the last occurrence 18 of the entity specifies the value or values to be used for that entity. 19 An input list item, or an entity associated with it, shall not contain any portion of an established format 20 specification. 21 If the input/output item is a pointer, data are transferred between the file and the associated target. 22 If an internal file has been specified, an input/output list item shall not be in the file or associated with 23 the file. 24 NOTE 9.44 The file is a data object. A DO variable becomes defined and its iteration count established at the beginning of processing of the 25 items that constitute the range of an io-implied-do. 26 On output, every entity whose value is to be transferred shall be defined. 27 9.5.4.4.1 Unformatted data transfer 28 During unformatted data transfer, data are transferred without editing between the file and the entities 29 specified by the input/output list. If the file is connected for sequential or direct access, exactly one 30 record is read or written. 31 A value in the file is stored in a contiguous sequence of file storage units, beginning with the file storage 32 232 2006/09/25 WORKING DRAFT J3/06-007r1 unit immediately following the current file position. 1 After each value is transferred, the current file position is moved to a point immediately after the last 2 file storage unit of the value. 3 On input from a file connected for sequential or direct access, the number of file storage units required 4 by the input list shall be less than or equal to the number of file storage units in the record. 5 On input, if the file storage units transferred do not contain a value with the same type and type 6 parameters as the input list entity, then the resulting value of the entity is processor-dependent except 7 in the following cases. 8 (1) A complex entity may correspond to two real values with the same kind type parameter as 9 the complex entity. 10 (2) A default character list entity of length n may correspond to n default characters stored in 11 the file, regardless of the length parameters of the entities that were written to these storage 12 units of the file. If the file is connected for stream input, the characters may have been 13 written by formatted stream output. 14 On output to a file connected for unformatted direct access, the output list shall not specify more values 15 than can fit into the record. If the file is connected for direct access and the values specified by the 16 output list do not fill the record, the remainder of the record is undefined. 17 If the file is connected for unformatted sequential access, the record is created with a length sufficient 18 to hold the values from the output list. This length shall be one of the set of allowed record lengths for 19 the file and shall not exceed the value specified in the RECL= specifier, if any, of the OPEN statement 20 that established the connection. 21 If the file is not connected for unformatted input/output, unformatted data transfer is prohibited. 22 9.5.4.4.2 Formatted data transfer 23 During formatted data transfer, data are transferred with editing between the file and the entities 24 specified by the input/output list or by the namelist-group-name. Format control is initiated and editing 25 is performed as described in Clause 10. 26 The current record and possibly additional records are read or written. 27 If the file is not connected for formatted input/output, formatted data transfer is prohibited. 28 During advancing input when the pad mode has the value NO, the input list and format specification 29 shall not require more characters from the record than the record contains. 30 During advancing input when the pad mode has the value YES, blank characters are supplied by the 31 processor if the input list and format specification require more characters from the record than the 32 record contains. 33 During nonadvancing input when the pad mode has the value NO, an end-of-record condition (9.10) 34 occurs if the input list and format specification require more characters from the record than the record 35 contains, and the record is complete (9.2.2.3). If the record is incomplete, an end-of-file condition occurs 36 instead of an end-of-record condition. 37 During nonadvancing input when the pad mode has the value YES, blank characters are supplied by 38 the processor if an effective item and its corresponding data edit descriptors require more characters 39 from the record than the record contains. If the record is incomplete, an end-of-file condition occurs; 40 otherwise an end-of-record condition occurs. 41 If the file is connected for direct access, the record number is increased by one as each succeeding record 42 233 J3/06-007r1 WORKING DRAFT 2006/09/25 is read or written. 1 On output, if the file is connected for direct access or is an internal file and the characters specified by 2 the output list and format do not fill a record, blank characters are added to fill the record. 3 On output, the output list and format specification shall not specify more characters for a record than 4 have been specified by a RECL= specifier in the OPEN statement or the record length of an internal 5 file. 6 9.5.4.5 List-directed formatting 7 If list-directed formatting has been established, editing is performed as described in 10.10. 8 9.5.4.6 Namelist formatting 9 If namelist formatting has been established, editing is performed as described in 10.11. 10 Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist- 11 group-object that is a pointer shall be associated with a target. If a namelist-group-object is polymorphic 12 or has an ultimate component that is allocatable or a pointer, that object shall be processed by a user- 13 defined derived-type input/output procedure (9.5.4.7). 14 9.5.4.7 User-defined derived-type input/output 15 User-defined derived-type input/output procedures allow a program to override the default handling of 16 derived-type objects and values in data transfer input/output statements described in 9.5.3. 17 A user-defined derived-type input/output procedure is a procedure accessible by a dtio-generic-spec 18 (12.4.3.2). A particular user-defined derived-type input/output procedure is selected as described in 19 9.5.4.7.3. 20 9.5.4.7.1 Executing user-defined derived-type input/output data transfers 21 If a derived-type input/output procedure is selected as specified in 9.5.4.7.3, the processor shall call the se- 22 lected user-defined derived-type input/output procedure for any appropriate data transfer input/output 23 statements executed in that scoping unit. The user-defined derived-type input/output procedure controls 24 the actual data transfer operations for the derived-type list item. 25 A data transfer statement that includes a derived-type list item and that causes a user-defined derived- 26 type input/output procedure to be invoked is called a parent data transfer statement. A data 27 transfer statement that is executed while a parent data transfer statement is being processed and that 28 specifies the unit passed into a user-defined derived-type input/output procedure is called a child data 29 transfer statement. 30 NOTE 9.45 A user-defined derived-type input/output procedure will usually contain child data transfer state- ments that read values from or write values to the current record or at the current file position. The effect of executing the user-defined derived-type input/output procedure is similar to that of substituting the list items from any child data transfer statements into the parent data transfer statement's list items, along with similar substitutions in the format specification. NOTE 9.46 A particular execution of a READ, WRITE or PRINT statement can be both a parent and a child data transfer statement. A user-defined derived-type input/output procedure can indirectly call itself or another user-defined derived-type input/output procedure by executing a child data 234 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.46 (cont.) transfer statement containing a list item of derived type, where a matching interface is accessible for that derived type. If a user-defined derived-type input/output procedure calls itself indirectly in this manner, it shall be declared RECURSIVE. A child data transfer statement is processed differently from a nonchild data transfer statement in the 1 following ways. 2 · Executing a child data transfer statement does not position the file prior to data transfer. 3 · An unformatted child data transfer statement does not position the file after data transfer is 4 complete. 5 · Any ADVANCE= specifier in a child input/output statement is ignored. 6 9.5.4.7.2 User-defined derived-type input/output procedures 7 For a particular derived type and a particular set of kind type parameter values, there are four possible 8 sets of characteristics for user-defined derived-type input/output procedures; one each for formatted 9 input, formatted output, unformatted input, and unformatted output. The user need not supply all four 10 procedures. The procedures are specified to be used for derived-type input/output by interface blocks 11 (12.4.3.2) or by generic bindings (4.5.5), with a dtio-generic-spec (R1208). 12 In the four interfaces, which specify the characteristics of user-defined procedures for derived-type in- 13 put/output, the following syntax term is used: 14 R920 dtv-type-spec is TYPE( derived-type-spec ) 15 or CLASS( derived-type-spec ) 16 C937 (R920) If derived-type-spec specifies an extensible type, the CLASS keyword shall be used; 17 otherwise, the TYPE keyword shall be used. 18 C938 (R920) All length type parameters of derived-type-spec shall be assumed. 19 If the dtio-generic-spec is READ (FORMATTED), the characteristics shall be the same as those specified 20 by the following interface: 21 SUBROUTINE my_read_routine_formatted & 22 (dtv, & 23 unit, & 24 iotype, v_list, & 25 iostat, iomsg) 26 ! the derived-type variable 27 dtv-type-spec , INTENT(INOUT) :: dtv 28 INTEGER, INTENT(IN) :: unit ! unit number 29 ! the edit descriptor string 30 CHARACTER (LEN=*), INTENT(IN) :: iotype 31 INTEGER, INTENT(IN) :: v_list(:) 32 INTEGER, INTENT(OUT) :: iostat 33 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 34 END 35 If the dtio-generic-spec is READ (UNFORMATTED), the characteristics shall be the same as those 36 specified by the following interface: 37 235 J3/06-007r1 WORKING DRAFT 2006/09/25 SUBROUTINE my_read_routine_unformatted & 1 (dtv, & 2 unit, & 3 iostat, iomsg) 4 ! the derived-type variable 5 dtv-type-spec , INTENT(INOUT) :: dtv 6 INTEGER, INTENT(IN) :: unit 7 INTEGER, INTENT(OUT) :: iostat 8 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 9 END 10 If the dtio-generic-spec is WRITE (FORMATTED), the characteristics shall be the same as those spec- 11 ified by the following interface: 12 SUBROUTINE my_write_routine_formatted & 13 (dtv, & 14 unit, & 15 iotype, v_list, & 16 iostat, iomsg) 17 ! the derived-type value/variable 18 dtv-type-spec , INTENT(IN) :: dtv 19 INTEGER, INTENT(IN) :: unit 20 ! the edit descriptor string 21 CHARACTER (LEN=*), INTENT(IN) :: iotype 22 INTEGER, INTENT(IN) :: v_list(:) 23 INTEGER, INTENT(OUT) :: iostat 24 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 25 END 26 If the dtio-generic-spec is WRITE (UNFORMATTED), the characteristics shall be the same as those 27 specified by the following interface: 28 SUBROUTINE my_write_routine_unformatted & 29 (dtv, & 30 unit, & 31 iostat, iomsg) 32 ! the derived-type value/variable 33 dtv-type-spec , INTENT(IN) :: dtv 34 INTEGER, INTENT(IN) :: unit 35 INTEGER, INTENT(OUT) :: iostat 36 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 37 END 38 The actual specific procedure names (the my_..._routine_... procedure names above) are not signifi- 39 cant. In the discussion here and elsewhere, the dummy arguments in these interfaces are referred by the 40 names given above; the names are, however, arbitrary. 41 When a user-defined derived-type input/output procedure is invoked, the processor shall pass a unit 42 argument that has a value as follows. 43 · If the parent data transfer statement uses a file-unit-number , the value of the unit argument shall 44 be that of the file-unit-number . 45 236 2006/09/25 WORKING DRAFT J3/06-007r1 · If the parent data transfer statement is a WRITE statement with an asterisk unit or a PRINT 1 statement, the unit argument shall have the same value as the OUTPUT UNIT named constant 2 of the ISO FORTRAN ENV intrinsic module (13.8.3). 3 · If the parent data transfer statement is a READ statement with an asterisk unit or a READ 4 statement without an io-control-spec-list, the unit argument shall have the same value as the 5 INPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.3). 6 · Otherwise the parent data transfer statement must access an internal file, in which case the unit 7 argument shall have a processor-dependent negative value. 8 NOTE 9.47 The unit argument passed to a user-defined derived-type input/output procedure will be negative when the parent input/output statement specified an internal unit, or specified an external unit that is a NEWUNIT value. When an internal unit is used with the INQUIRE statement, an error condition will occur, and any variable specified in an IOSTAT= specifier will be assigned the value IOSTAT INQUIRE INTERNAL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.3). For formatted data transfer, the processor shall pass an iotype argument that has the value 9 · "LISTDIRECTED" if the parent data transfer statement specified list directed formatting, 10 · "NAMELIST" if the parent data transfer statement specified namelist formatting, or 11 · "DT" concatenated with the char-literal-constant, if any, of the edit descriptor, if the parent data 12 transfer statement contained a format specification and the list item's corresponding edit descriptor 13 was a DT edit descriptor. 14 If the parent data transfer statement is a READ statement, the dtv dummy argument is argument 15 associated with the effective list item that caused the user-defined derived-type input procedure to be 16 invoked, as if the effective list item were an actual argument in this procedure reference (2.5.6). 17 If the parent data transfer statement is a WRITE or PRINT statement, the processor shall provide the 18 value of the effective list item in the dtv dummy argument. 19 If the v -list of the edit descriptor appears in the parent data transfer statement, the processor shall 20 provide the values from it in the v_list dummy argument, with the same number of elements in the 21 same order as v -list. If there is no v -list in the edit descriptor or if the data transfer statement specifies 22 list-directed or namelist formatting, the processor shall provide v_list as a zero-sized array. 23 NOTE 9.48 The user's procedure may choose to interpret an element of the v_list argument as a field width, but this is not required. If it does, it would be appropriate to fill an output field with "*"s if the width is too small. The iostat argument is used to report whether an error, end-of-record, or end-of-file condition (9.10) 24 occurs. If an error condition occurs, the user-defined derived-type input/output procedure shall assign 25 a positive value to the iostat argument. Otherwise, if an end-of-file condition occurs, the user-defined 26 derived-type input procedure shall assign the value of the named constant IOSTAT END (13.8.3.10) 27 to the iostat argument. Otherwise, if an end-of-record condition occurs, the user-defined derived- 28 type input procedure shall assign the value of the named constant IOSTAT EOR (13.8.3.11) to iostat. 29 Otherwise, the user-defined derived-type input/output procedure shall assign the value zero to the 30 iostat argument. 31 237 J3/06-007r1 WORKING DRAFT 2006/09/25 If the user-defined derived-type input/output procedure returns a nonzero value for the iostat argument, 1 the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure 2 shall not change the value of the iomsg argument. 3 NOTE 9.49 The values of the iostat and iomsg arguments set in a user-defined derived-type input/output procedure need not be passed to all of the parent data transfer statements. If the iostat argument of the user-defined derived-type input/output procedure has a nonzero value 4 when that procedure returns, and the processor therefore terminates execution of the program as de- 5 scribed in 9.10, the processor shall make the value of the iomsg argument available in a processor- 6 dependent manner. 7 When a parent READ statement is active, an input/output statement shall not read from any external 8 unit other than the one specified by the dummy argument unit and shall not perform output to any 9 external unit. 10 When a parent WRITE or PRINT statement is active, an input/output statement shall not perform 11 output to any external unit other than the one specified by the dummy argument unit and shall not 12 read from any external unit. 13 When a parent data transfer statement is active, a data transfer statement that specifies an internal file 14 is permitted. 15 OPEN, CLOSE, BACKSPACE, ENDFILE, and REWIND statements shall not be executed while a 16 parent data transfer statement is active. 17 A user-defined derived-type input/output procedure may use a FORMAT with a DT edit descriptor for 18 handling a component of the derived type that is itself of a derived type. A child data transfer statement 19 that is a list directed or namelist input/output statement may contain a list item of derived type. 20 Because a child data transfer statement does not position the file prior to data transfer, the child data 21 transfer statement starts transferring data from where the file was positioned by the parent data transfer 22 statement's most recently processed effective list item or record positioning edit descriptor. This is not 23 necessarily at the beginning of a record. 24 A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement 25 shall not cause the record position to be positioned before the record position at the time the user-defined 26 derived-type input/output procedure was invoked. 27 NOTE 9.50 A robust user-defined derived-type input/output procedure may wish to use INQUIRE to deter- mine the settings of BLANK=, PAD=, ROUND=, DECIMAL=, and DELIM= for an external unit. The INQUIRE provides values as specified in 9.9. Neither a parent nor child data transfer statement shall be asynchronous. 28 A user-defined derived-type input/output procedure, and any procedures invoked therefrom, shall not 29 define, nor cause to become undefined, any storage location referenced by any input/output list item, 30 the corresponding format, or any specifier in any active parent data transfer statement, except through 31 the dtv argument. 32 238 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.51 A child data transfer statement shall not specify the ID=, POS=, or REC= specifiers in an input/output control list. NOTE 9.52 A simple example of derived type formatted output follows. The derived type variable chairman has two components. The type and an associated write formatted procedure are defined in a module so as to be accessible from wherever they might be needed. It would also be possible to check that iotype indeed has the value 'DT' and to set iostat and iomsg accordingly. MODULE p TYPE :: person CHARACTER (LEN=20) :: name INTEGER :: age CONTAINS PROCEDURE,PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE person CONTAINS SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! argument definitions CLASS(person), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg ! local variable CHARACTER (LEN=9) :: pfmt ! vlist(1) and (2) are to be used as the field widths of the two ! components of the derived type variable. First set up the format to ! be used for output. WRITE(pfmt,'(A,I2,A,I2,A)' ) '(A', vlist(1), ',I', vlist(2), ')' ! now the basic output statement WRITE(unit, FMT=pfmt, IOSTAT=iostat) dtv%name, dtv%age END SUBROUTINE pwf END MODULE p PROGRAM USE p INTEGER id, members TYPE (person) :: chairman ... WRITE(6, FMT="(I2, DT (15,6), I5)" ) id, chairman, members ! this writes a record with four fields, with lengths 2, 15, 6, 5 239 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 9.52 (cont.) ! respectively END PROGRAM NOTE 9.53 In the following example, the variables of the derived type node form a linked list, with a single value at each node. The subroutine pwf is used to write the values in the list, one per line. MODULE p TYPE node INTEGER :: value = 0 TYPE (NODE), POINTER :: next_node => NULL ( ) CONTAINS PROCEDURE,PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE node CONTAINS RECURSIVE SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! Write the chain of values, each on a separate line in I9 format. CLASS(node), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg WRITE(unit,'(i9 /)', IOSTAT = iostat) dtv%value IF(iostat/=0) RETURN IF(ASSOCIATED(dtv%next_node)) WRITE(unit,'(dt)', IOSTAT=iostat) dtv%next_node END SUBROUTINE pwf END MODULE p 9.5.4.7.3 Resolving derived-type input/output procedure references 1 A suitable generic interface for user-defined derived-type input/output of an effective item is one that 2 has a dtio-generic-spec that is appropriate to the direction (read or write) and form (formatted or 3 unformatted) of the data transfer as specified in 9.5.4.7, and has a specific interface whose dtv argument 4 is compatible with the effective item according to the rules for argument association in 12.5.2.5. 5 When an effective item (9.5.3) that is of derived-type is encountered during a data transfer, user-defined 6 derived-type input/output occurs if both of the following conditions are true. 7 (1) The circumstances of the input/output are such that user-defined derived-type input/output 8 is permitted; that is, either 9 (a) the transfer was initiated by a list-directed, namelist, or unformatted input/output 10 statement, or 11 (b) a format specification is supplied for the input/output statement, and the edit de- 12 240 2006/09/25 WORKING DRAFT J3/06-007r1 scriptor corresponding to the effective item is a DT edit descriptor. 1 (2) A suitable user-defined derived-type input/output procedure is available; that is, either 2 (a) the declared type of the effective item has a suitable generic type-bound procedure, 3 or 4 (b) a suitable generic interface is accessible. 5 If (2a) is true, the procedure referenced is determined as for explicit type-bound procedure references 6 (12.5); that is, the binding with the appropriate specific interface is located in the declared type of the 7 effective item, and the corresponding binding in the dynamic type of the effective item is selected. 8 If (2a) is false and (2b) is true, the reference is to the procedure identified by the appropriate specific 9 interface in the interface block. This reference shall not be to a dummy procedure that is not present, 10 or to a disassociated procedure pointer. 11 9.5.5 Termination of data transfer statements 12 Termination of an input/output data transfer statement occurs when 13 (1) format processing encounters a data edit descriptor and there are no remaining elements in 14 the input-item-list or output-item-list, 15 (2) unformatted or list-directed data transfer exhausts the input-item-list or output-item-list, 16 (3) namelist output exhausts the namelist-group-object-list, 17 (4) an error condition occurs, 18 (5) an end-of-file condition occurs, 19 (6) a slash (/) is encountered as a value separator (10.10, 10.11) in the record being read during 20 list-directed or namelist input, or 21 (7) an end-of-record condition occurs during execution of a nonadvancing input statement 22 (9.10). 23 9.6 Waiting on pending data transfer 24 9.6.1 Wait operation 25 Execution of an asynchronous data transfer statement in which neither an error, end-of-record, nor end- 26 of-file condition occurs initiates a pending data transfer operation. There may be multiple pending data 27 transfer operations for the same or multiple units simultaneously. A pending data transfer operation 28 remains pending until a corresponding wait operation is performed. A wait operation may be performed 29 by a WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning statement. 30 A wait operation completes the processing of a pending data transfer operation. Each wait operation 31 completes only a single data transfer operation, although a single statement may perform multiple wait 32 operations. 33 If the actual data transfer is not yet complete, the wait operation first waits for its completion. If the 34 data transfer operation is an input operation that completed without error, the storage units of the 35 input/output storage sequence then become defined with the values as described in 9.5.2.15 and 9.5.4.4. 36 If any error, end-of-file, or end-of-record conditions occur, the applicable actions specified by the IO- 37 STAT=, IOMSG=, ERR=, END=, and EOR= specifiers of the statement that performs the wait oper- 38 ation are taken. 39 If an error or end-of-file condition occurs during a wait operation for a unit, the processor performs a 40 wait operation for all pending data transfer operations for that unit. 41 241 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 9.54 Error, end-of-file, and end-of-record conditions may be raised either during the data transfer state- ment that initiates asynchronous input/output, a subsequent asynchronous data transfer statement for the same unit, or during the wait operation. If such conditions are raised during a data transfer statement, they trigger actions according to the IOSTAT=, ERR=, END=, and EOR= specifiers of that statement; if they are raised during the wait operation, the actions are in accordance with the specifiers of the statement that performs the wait operation. After completion of the wait operation, the data transfer operation and its input/output storage sequence 1 are no longer considered to be pending. 2 9.6.2 WAIT statement 3 A WAIT statement performs a wait operation for specified pending asynchronous data transfer opera- 4 tions. 5 NOTE 9.55 The CLOSE, INQUIRE, and file positioning statements may also perform wait operations. R921 wait-stmt is WAIT (wait-spec-list) 6 R922 wait-spec is [ UNIT = ] file-unit-number 7 or END = label 8 or EOR = label 9 or ERR = label 10 or ID = scalar-int-expr 11 or IOMSG = iomsg-variable 12 or IOSTAT = scalar-int-variable 13 C939 No specifier shall appear more than once in a given wait-spec-list. 14 C940 A file-unit-number shall be specified in a wait-spec-list; if the optional characters UNIT= are 15 omitted, the file-unit-number shall be the first item in the wait-spec-list. 16 C941 (R922) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 17 branch target statement that appears in the same scoping unit as the WAIT statement. 18 The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 19 The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 20 operation for the specified unit. If the ID= specifier appears, a wait operation for the specified data 21 transfer operation is performed. If the ID= specifier is omitted, wait operations for all pending data 22 transfers for the specified unit are performed. 23 Execution of a WAIT statement specifying a unit that does not exist, has no file connected to it, or is 24 not open for asynchronous input/output is permitted, provided that the WAIT statement has no ID= 25 specifier; such a WAIT statement does not cause an error or end-of-file condition to occur. 26 NOTE 9.56 An EOR= specifier has no effect if the pending data transfer operation is not a nonadvancing read. And END= specifier has no effect if the pending data transfer operation is not a READ. 9.7 File positioning statements 27 242 2006/09/25 WORKING DRAFT J3/06-007r1 9.7.1 Syntax 1 R923 backspace-stmt is BACKSPACE file-unit-number 2 or BACKSPACE ( position-spec-list ) 3 R924 endfile-stmt is ENDFILE file-unit-number 4 or ENDFILE ( position-spec-list ) 5 R925 rewind-stmt is REWIND file-unit-number 6 or REWIND ( position-spec-list ) 7 A unit that is connected for direct access shall not be referred to by a BACKSPACE, ENDFILE, or 8 REWIND statement. A unit that is connected for unformatted stream access shall not be referred to 9 by a BACKSPACE statement. A unit that is connected with an ACTION= specifier having the value 10 READ shall not be referred to by an ENDFILE statement. 11 R926 position-spec is [ UNIT = ] file-unit-number 12 or IOMSG = iomsg-variable 13 or IOSTAT = scalar-int-variable 14 or ERR = label 15 C942 No specifier shall appear more than once in a given position-spec-list. 16 C943 A file-unit-number shall be specified in a position-spec-list; if the optional characters UNIT= 17 are omitted, the file-unit-number shall be the first item in the position-spec-list. 18 C944 (R926) The label in the ERR= specifier shall be the statement label of a branch target statement 19 that appears in the same scoping unit as the file positioning statement. 20 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 21 Execution of a file positioning statement performs a wait operation for all pending asynchronous data 22 transfer operations for the specified unit. 23 9.7.2 BACKSPACE statement 24 Execution of a BACKSPACE statement causes the file connected to the specified unit to be positioned 25 before the current record if there is a current record, or before the preceding record if there is no current 26 record. If the file is at its initial point, the position of the file is not changed. 27 NOTE 9.57 If the preceding record is an endfile record, the file is positioned before the endfile record. If a BACKSPACE statement causes the implicit writing of an endfile record, the file is positioned before 28 the record that precedes the endfile record. 29 Backspacing a file that is connected but does not exist is prohibited. 30 Backspacing over records written using list-directed or namelist formatting is prohibited. 31 A BACKSPACE statement shall not reference a unit whose connect team has more than one image. 32 NOTE 9.58 An example of a BACKSPACE statement is: BACKSPACE (10, IOSTAT = N) 243 J3/06-007r1 WORKING DRAFT 2006/09/25 9.7.3 ENDFILE statement 1 Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record 2 as the next record of the file. The file is then positioned after the endfile record, which becomes the last 3 record of the file. If the file also may be connected for direct access, only those records before the endfile 4 record are considered to have been written. Thus, only those records may be read during subsequent 5 direct access connections to the file. 6 After execution of an ENDFILE statement for a file connected for sequential access, a BACKSPACE 7 or REWIND statement shall be used to reposition the file prior to execution of any data transfer 8 input/output statement or ENDFILE statement. 9 Execution of an ENDFILE statement for a file connected for stream access causes the terminal point of 10 the file to become equal to the current file position. Only file storage units before the current position are 11 considered to have been written; thus only those file storage units may be subsequently read. Subsequent 12 stream output statements may be used to write further data to the file. 13 Execution of an ENDFILE statement for a file that is connected but does not exist creates the file; if 14 the file is connected for sequential access, it is created prior to writing the endfile record. 15 An ENDFILE statement shall not reference a unit whose connect team has more than one image. 16 NOTE 9.59 An example of an ENDFILE statement is: ENDFILE K 9.7.4 REWIND statement 17 Execution of a REWIND statement causes the specified file to be positioned at its initial point. 18 NOTE 9.60 If the file is already positioned at its initial point, execution of this statement has no effect on the position of the file. Execution of a REWIND statement for a file that is connected but does not exist is permitted and has 19 no effect on any file. 20 A REWIND statement shall not reference a unit whose connect team has more than one image. 21 NOTE 9.61 An example of a REWIND statement is: REWIND 10 9.8 FLUSH statement 22 The form of the FLUSH statement is: 23 R927 flush-stmt is FLUSH file-unit-number 24 or FLUSH ( flush-spec-list ) 25 R928 flush-spec is [UNIT =] file-unit-number 26 or IOSTAT = scalar-int-variable 27 244 2006/09/25 WORKING DRAFT J3/06-007r1 or IOMSG = iomsg-variable 1 or ERR = label 2 C945 No specifier shall appear more than once in a given flush-spec-list. 3 C946 A file-unit-number shall be specified in a flush-spec-list; if the optional characters UNIT= are 4 omitted from the unit specifier, the file-unit-number shall be the first item in the flush-spec-list. 5 C947 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 6 that appears in the same scoping unit as the FLUSH statement. 7 The IOSTAT=, IOMSG= and ERR= specifiers are described in 9.10. The IOSTAT= variable shall 8 be set to a processor-dependent positive value if an error occurs, to zero if the processor-dependent 9 flush operation was successful, or to a processor-dependent negative value if the flush operation is not 10 supported for the unit specified. 11 Execution of a FLUSH statement causes data written to an external unit to be made available to other 12 images of the unit's connect team which execute a FLUSH statement in a subsequent segment for that 13 unit. It also causes data written to an external file to be available to other processes, or causes data 14 placed in an external file by means other than Fortran to be available to a READ statement. The action 15 is processor dependent. 16 Execution of a FLUSH statement for a file that is connected but does not exist is permitted and has no 17 effect on any file. A FLUSH statement has no effect on file position. 18 Execution of a FLUSH statement performs a wait operation for all pending asynchronous data transfer 19 operations for the specified unit. 20 NOTE 9.62 Because this standard does not specify the mechanism of file storage, the exact meaning of the flush operation is not precisely defined. The intention is that the flush operation should make all data written to a file available to other processes or devices, or make data recently added to a file by other processes or devices available to the program via a subsequent read operation. This is commonly called "flushing I/O buffers". NOTE 9.63 An example of a FLUSH statement is: FLUSH( 10, IOSTAT=N) 9.9 File inquiry statement 21 9.9.1 Forms of the INQUIRE statement 22 The INQUIRE statement may be used to inquire about properties of a particular named file or of the 23 connection to a particular unit. There are three forms of the INQUIRE statement: inquire by file, 24 which uses the FILE= specifier, inquire by unit, which uses the UNIT= specifier, and inquire by 25 output list, which uses only the IOLENGTH= specifier. All specifier value assignments are performed 26 according to the rules for assignment statements. 27 For inquiry by unit, the unit specified need not exist or be connected to a file. If it is connected to a 28 file, the inquiry is being made about the connection and about the file connected. 29 An INQUIRE statement may be executed before, while, or after a file is connected to a unit. All values 30 245 J3/06-007r1 WORKING DRAFT 2006/09/25 assigned by an INQUIRE statement are those that are current at the time the statement is executed. 1 R929 inquire-stmt is INQUIRE ( inquire-spec-list ) 2 or INQUIRE ( IOLENGTH = scalar-int-variable ) 3 output-item-list 4 NOTE 9.64 Examples of INQUIRE statements are: INQUIRE (IOLENGTH = IOL) A (1:N) INQUIRE (UNIT = JOAN, OPENED = LOG_01, NAMED = LOG_02, & FORM = CHAR_VAR, IOSTAT = IOS) 9.9.2 Inquiry specifiers 5 Unless constrained, the following inquiry specifiers may be used in either of the inquire by file or inquire 6 by unit forms of the INQUIRE statement: 7 R930 inquire-spec is [ UNIT = ] file-unit-number 8 or FILE = file-name-expr 9 or ACCESS = scalar-default-char-variable 10 or ACTION = scalar-default-char-variable 11 or ASYNCHRONOUS = scalar-default-char-variable 12 or BLANK = scalar-default-char-variable 13 or DECIMAL = scalar-default-char-variable 14 or DELIM = scalar-default-char-variable 15 or DIRECT = scalar-default-char-variable 16 or ENCODING = scalar-default-char-variable 17 or ERR = label 18 or EXIST = scalar-default-logical-variable 19 or FORM = scalar-default-char-variable 20 or FORMATTED = scalar-default-char-variable 21 or ID = scalar-int-expr 22 or IOMSG = iomsg-variable 23 or IOSTAT = scalar-int-variable 24 or NAME = scalar-default-char-variable 25 or NAMED = scalar-default-logical-variable 26 or NEXTREC = scalar-int-variable 27 or NUMBER = scalar-int-variable 28 or OPENED = scalar-default-logical-variable 29 or PAD = scalar-default-char-variable 30 or PENDING = scalar-default-logical-variable 31 or POS = scalar-int-variable 32 or POSITION = scalar-default-char-variable 33 or READ = scalar-default-char-variable 34 or READWRITE = scalar-default-char-variable 35 or RECL = scalar-int-variable 36 or ROUND = scalar-default-char-variable 37 or SEQUENTIAL = scalar-default-char-variable 38 or SIGN = scalar-default-char-variable 39 or SIZE = scalar-int-variable 40 or STREAM = scalar-default-char-variable 41 or TEAM = image-team 42 or UNFORMATTED = scalar-default-char-variable 43 246 2006/09/25 WORKING DRAFT J3/06-007r1 or WRITE = scalar-default-char-variable 1 C948 No specifier shall appear more than once in a given inquire-spec-list. 2 C949 An inquire-spec-list shall contain one FILE= specifier or one UNIT= specifier, but not both. 3 C950 In the inquire by unit form of the INQUIRE statement, if the optional characters UNIT= are 4 omitted, the file-unit-number shall be the first item in the inquire-spec-list. 5 C951 If an ID= specifier appears in an inquire-spec-list, a PENDING= specifier shall also appear. 6 C952 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 7 that appears in the same scoping unit as the INQUIRE statement. 8 If file-unit-number identifies an internal unit (9.5.4.7.2), an error condition occurs. 9 When a returned value of a specifier other than the NAME= specifier is of type character, the value 10 returned is in upper case. 11 If an error condition occurs during execution of an INQUIRE statement, all of the inquiry specifier 12 variables become undefined, except for variables in the IOSTAT= and IOMSG= specifiers (if any). 13 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 14 9.9.2.1 FILE= specifier in the INQUIRE statement 15 The value of the file-name-expr in the FILE= specifier specifies the name of the file being inquired about. 16 The named file need not exist or be connected to a unit. The value of the file-name-expr shall be of a 17 form acceptable to the processor as a file name. Any trailing blanks are ignored. The interpretation of 18 case is processor dependent. 19 9.9.2.2 ACCESS= specifier in the INQUIRE statement 20 The scalar-default-char-variable in the ACCESS= specifier is assigned the value SEQUENTIAL if the 21 connection is for sequential access, DIRECT if the connection is for direct access, or STREAM if the 22 connection is for stream access. If there is no connection, it is assigned the value UNDEFINED. 23 9.9.2.3 ACTION= specifier in the INQUIRE statement 24 The scalar-default-char-variable in the ACTION= specifier is assigned the value READ if the connection 25 is for input only, WRITE if the connection is for output only, and READWRITE if the connection is for 26 both input and output. If there is no connection, the scalar-default-char-variable is assigned the value 27 UNDEFINED. 28 9.9.2.4 ASYNCHRONOUS= specifier in the INQUIRE statement 29 The scalar-default-char-variable in the ASYNCHRONOUS= specifier is assigned the value YES if the 30 connection allows asynchronous input/output; it is assigned the value NO if the connection does not 31 allow asynchronous input/output. If there is no connection, the scalar-default-char-variable is assigned 32 the value UNDEFINED. 33 9.9.2.5 BLANK= specifier in the INQUIRE statement 34 The scalar-default-char-variable in the BLANK= specifier is assigned the value ZERO or NULL, corre- 35 sponding to the blank interpretation mode in effect for a connection for formatted input/output. If there 36 is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 37 is assigned the value UNDEFINED. 38 247 J3/06-007r1 WORKING DRAFT 2006/09/25 9.9.2.6 DECIMAL= specifier in the INQUIRE statement 1 The scalar-default-char-variable in the DECIMAL= specifier is assigned the value COMMA or POINT, 2 corresponding to the decimal edit mode in effect for a connection for formatted input/output. If there 3 is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 4 is assigned the value UNDEFINED. 5 9.9.2.7 DELIM= specifier in the INQUIRE statement 6 The scalar-default-char-variable in the DELIM= specifier is assigned the value APOSTROPHE, QUOTE, 7 or NONE, corresponding to the delimiter mode in effect for a connection for formatted input/output. 8 If there is no connection or if the connection is not for formatted input/output, the scalar-default-char- 9 variable is assigned the value UNDEFINED. 10 9.9.2.8 DIRECT= specifier in the INQUIRE statement 11 The scalar-default-char-variable in the DIRECT= specifier is assigned the value YES if DIRECT is 12 included in the set of allowed access methods for the file, NO if DIRECT is not included in the set of 13 allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 14 DIRECT is included in the set of allowed access methods for the file. 15 9.9.2.9 ENCODING= specifier in the INQUIRE statement 16 The scalar-default-char-variable in the ENCODING= specifier is assigned the value UTF-8 if the con- 17 nection is for formatted input/output with an encoding form of UTF-8, and is assigned the value UN- 18 DEFINED if the connection is for unformatted input/output. If there is no connection, it is assigned 19 the value UTF-8 if the processor is able to determine that the encoding form of the file is UTF-8; if 20 the processor is unable to determine the encoding form of the file, the variable is assigned the value 21 UNKNOWN. 22 NOTE 9.65 The value assigned may be something other than UTF-8, UNDEFINED, or UNKNOWN if the processor supports other specific encoding forms (e.g. UTF-16BE). 9.9.2.10 EXIST= specifier in the INQUIRE statement 23 Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the EXIST= 24 specifier to be assigned the value true if there exists a file with the specified name; otherwise, false is 25 assigned. Execution of an INQUIRE by unit statement causes true to be assigned if the specified unit 26 exists; otherwise, false is assigned. 27 9.9.2.11 FORM= specifier in the INQUIRE statement 28 The scalar-default-char-variable in the FORM= specifier is assigned the value FORMATTED if the 29 connection is for formatted input/output, and is assigned the value UNFORMATTED if the connection 30 is for unformatted input/output. If there is no connection, it is assigned the value UNDEFINED. 31 9.9.2.12 FORMATTED= specifier in the INQUIRE statement 32 The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FOR- 33 MATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in 34 the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 35 FORMATTED is included in the set of allowed forms for the file. 36 248 2006/09/25 WORKING DRAFT J3/06-007r1 9.9.2.13 ID= specifier in the INQUIRE statement 1 The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 2 operation for the specified unit. This specifier interacts with the PENDING= specifier (9.9.2.20). 3 9.9.2.14 NAME= specifier in the INQUIRE statement 4 The scalar-default-char-variable in the NAME= specifier is assigned the value of the name of the file if 5 the file has a name; otherwise, it becomes undefined. 6 NOTE 9.66 If this specifier appears in an INQUIRE by file statement, its value is not necessarily the same as the name given in the FILE= specifier. However, the value returned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement. The processor may return a file name qualified by a user identification, device, directory, or other relevant information. The case of the characters assigned to scalar-default-char-variable is processor dependent. 7 9.9.2.15 NAMED= specifier in the INQUIRE statement 8 The scalar-default-logical-variable in the NAMED= specifier is assigned the value true if the file has a 9 name; otherwise, it is assigned the value false. 10 9.9.2.16 NEXTREC= specifier in the INQUIRE statement 11 The scalar-int-variable in the NEXTREC= specifier is assigned the value n + 1, where n is the record 12 number of the last record read from or written to the connection for direct access. If there is a connection 13 but no records have been read or written since the connection, the scalar-int-variable is assigned the 14 value 1. If there is no connection, the connection is not for direct access, or the position is indeterminate 15 because of a previous error condition, the scalar-int-variable becomes undefined. If there are pending 16 data transfer operations for the specified unit, the value assigned is computed as if all the pending data 17 transfers had already completed. 18 J3 internal note Unresolved Technical Issue 044 NEXTREC= does not have a well-defined meaning in the context of a unit opened with the TEAM= specifier. 9.9.2.17 NUMBER= specifier in the INQUIRE statement 19 The scalar-int-variable in the NUMBER= specifier is assigned the value of the external unit number of 20 the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. 21 9.9.2.18 OPENED= specifier in the INQUIRE statement 22 Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the OPENED= 23 specifier to be assigned the value true if the file specified is connected to a unit; otherwise, false is 24 assigned. Execution of an INQUIRE by unit statement causes the scalar-default-logical-variable to be 25 assigned the value true if the specified unit is connected to a file; otherwise, false is assigned. 26 9.9.2.19 PAD= specifier in the INQUIRE statement 27 249 J3/06-007r1 WORKING DRAFT 2006/09/25 The scalar-default-char-variable in the PAD= specifier is assigned the value YES or NO, corresponding 1 to the pad mode in effect for a connection for formatted input/output. If there is no connection or if 2 the connection is not for formatted input/output, the scalar-default-char-variable is assigned the value 3 UNDEFINED. 4 9.9.2.20 PENDING= specifier in the INQUIRE statement 5 The PENDING= specifier is used to determine whether previously pending asynchronous data transfers 6 are complete. A data transfer operation is previously pending if it is pending at the beginning of 7 execution of the INQUIRE statement. 8 If an ID= specifier appears and the specified data transfer operation is complete, then the variable 9 specified in the PENDING= specifier is assigned the value false and the INQUIRE statement performs 10 the wait operation for the specified data transfer. 11 If the ID= specifier is omitted and all previously pending data transfer operations for the specified unit 12 are complete, then the variable specified in the PENDING= specifier is assigned the value false and the 13 INQUIRE statement performs wait operations for all previously pending data transfers for the specified 14 unit. 15 In all other cases, the variable specified in the PENDING= specifier is assigned the value true and no 16 wait operations are performed; in this case the previously pending data transfers remain pending after 17 the execution of the INQUIRE statement. 18 NOTE 9.67 The processor has considerable flexibility in defining when it considers a transfer to be complete. Any of the following approaches could be used: (1) The INQUIRE statement could consider an asynchronous data transfer to be incom- plete until after the corresponding wait operation. In this case PENDING= would always return true unless there were no previously pending data transfers for the unit. (2) The INQUIRE statement could wait for all specified data transfers to complete and then always return false for PENDING=. (3) The INQUIRE statement could actually test the state of the specified data transfer operations. 9.9.2.21 POS= specifier in the INQUIRE statement 19 The scalar-int-variable in the POS= specifier is assigned the number of the file storage unit immediately 20 following the current position of a file connected for stream access. If the file is positioned at its terminal 21 position, the variable is assigned a value one greater than the number of the highest-numbered file storage 22 unit in the file. If the file is not connected for stream access or if the position of the file is indeterminate 23 because of previous error conditions, the variable becomes undefined. 24 9.9.2.22 POSITION= specifier in the INQUIRE statement 25 The scalar-default-char-variable in the POSITION= specifier is assigned the value REWIND if the 26 connection was opened for positioning at its initial point, APPEND if the connection was opened for 27 positioning before its endfile record or at its terminal point, and ASIS if the connection was opened 28 without changing its position. If there is no connection or if the file is connected for direct access, the 29 scalar-default-char-variable is assigned the value UNDEFINED. If the file has been repositioned since 30 the connection, the scalar-default-char-variable is assigned a processor-dependent value, which shall not 31 be REWIND unless the file is positioned at its initial point and shall not be APPEND unless the file is 32 positioned so that its endfile record is the next record or at its terminal point if it has no endfile record. 33 250 2006/09/25 WORKING DRAFT J3/06-007r1 9.9.2.23 READ= specifier in the INQUIRE statement 1 The scalar-default-char-variable in the READ= specifier is assigned the value YES if READ is included 2 in the set of allowed actions for the file, NO if READ is not included in the set of allowed actions for 3 the file, and UNKNOWN if the processor is unable to determine whether READ is included in the set 4 of allowed actions for the file. 5 9.9.2.24 READWRITE= specifier in the INQUIRE statement 6 The scalar-default-char-variable in the READWRITE= specifier is assigned the value YES if READ- 7 WRITE is included in the set of allowed actions for the file, NO if READWRITE is not included in 8 the set of allowed actions for the file, and UNKNOWN if the processor is unable to determine whether 9 READWRITE is included in the set of allowed actions for the file. 10 9.9.2.25 RECL= specifier in the INQUIRE statement 11 The scalar-int-variable in the RECL= specifier is assigned the value of the record length of a connection 12 for direct access, or the value of the maximum record length of a connection for sequential access. If 13 the connection is for formatted input/output, the length is the number of characters for all records that 14 contain only characters of type default character. If the connection is for unformatted input/output, 15 the length is measured in file storage units. If there is no connection, or if the connection is for stream 16 access, the scalar-int-variable becomes undefined. 17 9.9.2.26 ROUND= specifier in the INQUIRE statement 18 The scalar-default-char-variable in the ROUND= specifier is assigned the value UP, DOWN, ZERO, 19 NEAREST, COMPATIBLE, or PROCESSOR DEFINED, corresponding to the I/O rounding mode in 20 effect for a connection for formatted input/output. If there is no connection or if the connection is not 21 for formatted input/output, the scalar-default-char-variable is assigned the value UNDEFINED. The 22 processor shall return the value PROCESSOR DEFINED only if the I/O rounding mode currently in 23 effect behaves differently than the UP, DOWN, ZERO, NEAREST, and COMPATIBLE modes. 24 9.9.2.27 SEQUENTIAL= specifier in the INQUIRE statement 25 The scalar-default-char-variable in the SEQUENTIAL= specifier is assigned the value YES if SEQUEN- 26 TIAL is included in the set of allowed access methods for the file, NO if SEQUENTIAL is not included 27 in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine 28 whether SEQUENTIAL is included in the set of allowed access methods for the file. 29 9.9.2.28 SIGN= specifier in the INQUIRE statement 30 The scalar-default-char-variable in the SIGN= specifier is assigned the value PLUS, SUPPRESS, or 31 PROCESSOR DEFINED, corresponding to the sign mode in effect for a connection for formatted in- 32 put/output. If there is no connection, or if the connection is not for formatted input/output, the 33 scalar-default-char-variable is assigned the value UNDEFINED. 34 9.9.2.29 SIZE= specifier in the INQUIRE statement 35 The scalar-int-variable in the SIZE= specifier is assigned the size of the file in file storage units. If the 36 file size cannot be determined, the variable is assigned the value -1. 37 For a file that may be connected for stream access, the file size is the number of the highest-numbered 38 file storage unit in the file. 39 For a file that may be connected for sequential or direct access, the file size may be different from the 40 number of storage units implied by the data in the records; the exact relationship is processor-dependent. 41 251 J3/06-007r1 WORKING DRAFT 2006/09/25 9.9.2.30 STREAM= specifier in the INQUIRE statement 1 The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is 2 included in the set of allowed access methods for the file, NO if STREAM is not included in the set of 3 allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 4 STREAM is included in the set of allowed access methods for the file. 5 9.9.2.31 TEAM= specifier in the INQUIRE statement 6 The image-team in the TEAM= specifier is assigned the value of the connect team if the file or unit is 7 connected; otherwise it is assigned the value NULL IMAGE TEAM (13.8.3.13). 8 NOTE 9.68 The indices of the images in a team may be obtained by using the intrinsic function TEAM - IMAGES (13.7.172). 9.9.2.32 UNFORMATTED= specifier in the INQUIRE statement 9 The scalar-default-char-variable in the UNFORMATTED= specifier is assigned the value YES if UN- 10 FORMATTED is included in the set of allowed forms for the file, NO if UNFORMATTED is not included 11 in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 12 UNFORMATTED is included in the set of allowed forms for the file. 13 9.9.2.33 WRITE= specifier in the INQUIRE statement 14 The scalar-default-char-variable in the WRITE= specifier is assigned the value YES if WRITE is included 15 in the set of allowed actions for the file, NO if WRITE is not included in the set of allowed actions for 16 the file, and UNKNOWN if the processor is unable to determine whether WRITE is included in the set 17 of allowed actions for the file. 18 9.9.3 Inquire by output list 19 The scalar-int-variable in the IOLENGTH= specifier is assigned the processor-dependent number of file 20 storage units that would be required to store the data of the output list in an unformatted file. The 21 value shall be suitable as a RECL= specifier in an OPEN statement that connects a file for unformatted 22 direct access when there are input/output statements with the same input/output list. 23 The output list in an INQUIRE statement shall not contain any derived-type list items that require 24 a user-defined derived-type input/output procedure as described in subclause 9.5.3. If a derived-type 25 list item appears in the output list, the value returned for the IOLENGTH= specifier assumes that no 26 user-defined derived-type input/output procedure will be invoked. 27 9.10 Error, end-of-record, and end-of-file conditions 28 The set of input/output error conditions is processor dependent. 29 An end-of-record condition occurs when a nonadvancing input statement attempts to transfer data 30 from a position beyond the end of the current record, unless the file is a stream file and the current 31 record is at the end of the file (an end-of-file condition occurs instead). 32 An end-of-file condition occurs when 33 (1) an endfile record is encountered during the reading of a file connected for sequential access, 34 (2) an attempt is made to read a record beyond the end of an internal file, or 35 252 2006/09/25 WORKING DRAFT J3/06-007r1 (3) an attempt is made to read beyond the end of a stream file. 1 An end-of-file condition may occur at the beginning of execution of an input statement. An end-of-file 2 condition also may occur during execution of a formatted input statement when more than one record 3 is required by the interaction of the input list and the format. An end-of-file condition also may occur 4 during execution of a stream input statement. 5 9.10.1 Error conditions and the ERR= specifier 6 If an error condition occurs during execution of an input/output statement, the position of the file 7 becomes indeterminate. 8 If an error condition occurs during execution of an input/output statement that contains neither an 9 ERR= nor IOSTAT= specifier, execution of the program is terminated. If an error condition occurs 10 during execution of an input/output statement that contains either an ERR= specifier or an IOSTAT= 11 specifier then 12 (1) processing of the input/output list, if any, terminates, 13 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 14 do-variables in the statement that initiated the transfer become undefined, 15 (3) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 16 defined as specified in 9.10.4, 17 (4) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 18 (5) if the statement is a READ statement and it contains a SIZE= specifier, the scalar-int- 19 variable in the SIZE= specifier becomes defined as specified in 9.5.2.15, 20 (6) if the statement is a READ statement or the error condition occurs in a wait operation for 21 a transfer initiated by a READ statement, all input items or namelist group objects in the 22 statement that initiated the transfer become undefined, and 23 (7) if an ERR= specifier appears, a branch to the statement labeled by the label in the ERR= 24 specifier occurs. 25 9.10.2 End-of-file condition and the END= specifier 26 If an end-of-file condition occurs during execution of an input/output statement that contains neither 27 an END= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of-file 28 condition occurs during execution of an input/output statement that contains either an END= specifier 29 or an IOSTAT= specifier, and an error condition does not occur then 30 (1) processing of the input list, if any, terminates, 31 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 32 do-variables in the statement that initiated the transfer become undefined, 33 (3) if the statement is a READ statement or the end-of-file condition occurs in a wait operation 34 for a transfer initiated by a READ statement, all input list items or namelist group objects 35 in the statement that initiated the transfer become undefined, 36 (4) if the file specified in the input statement is an external record file, it is positioned after the 37 endfile record, 38 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 39 defined as specified in 9.10.4, 40 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 41 and 42 (7) if an END= specifier appears, a branch to the statement labeled by the label in the END= 43 specifier occurs. 44 253 J3/06-007r1 WORKING DRAFT 2006/09/25 9.10.3 End-of-record condition and the EOR= specifier 1 If an end-of-record condition occurs during execution of an input/output statement that contains neither 2 an EOR= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of- 3 record condition occurs during execution of an input/output statement that contains either an EOR= 4 specifier or an IOSTAT= specifier, and an error condition does not occur then 5 (1) If the pad mode has the value 6 (a) YES, the record is padded with blanks to satisfy the effective list item (9.5.4.4.2) 7 and corresponding data edit descriptors that require more characters than the record 8 contains, 9 (b) NO, the input list item becomes undefined, 10 (2) processing of the input list, if any, terminates, 11 (3) if the statement is a data transfer statement or the end-of-record condition occurs dur- 12 ing a wait operation, all do-variables in the statement that initiated the transfer become 13 undefined, 14 (4) the file specified in the input statement is positioned after the current record, 15 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 16 defined as specified in 9.10.4, 17 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 18 (7) if a SIZE= specifier appears, the scalar-int-variable in the SIZE= specifier becomes defined 19 as specified in (9.5.2.15), and 20 (8) if an EOR= specifier appears, a branch to the statement labeled by the label in the EOR= 21 specifier occurs. 22 9.10.4 IOSTAT= specifier 23 Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable 24 in the IOSTAT= specifier to become defined with 25 (1) a zero value if neither an error condition, an end-of-file condition, nor an end-of-record 26 condition occurs, 27 (2) the processor-dependent positive integer value of the constant IOSTAT INQUIRE INTERN- 28 AL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.3) if a unit number in an 29 INQUIRE statement identifies an internal file, 30 (3) a processor-dependent positive integer value different from IOSTAT INQUIRE INTERNAL - 31 UNIT if any other error condition occurs, 32 (4) the processor-dependent negative integer value of the constant IOSTAT END (13.8.3.10) if 33 an end-of-file condition occurs and no error condition occurs, or 34 (5) the processor-dependent negative integer value of the constant IOSTAT EOR (13.8.3.11) if 35 an end-of-record condition occurs and no error condition or end-of-file condition occurs. 36 NOTE 9.69 An end-of-file condition may occur only for sequential or stream input and an end-of-record con- dition may occur only for nonadvancing input. Consider the example: READ (FMT = "(E8.3)", UNIT = 3, IOSTAT = IOSS) X IF (IOSS < 0) THEN ! Perform end-of-file processing on the file connected to unit 3. CALL END_PROCESSING 254 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 9.69 (cont.) ELSE IF (IOSS > 0) THEN ! Perform error processing CALL ERROR_PROCESSING END IF 9.10.5 IOMSG= specifier 1 If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, 2 the processor shall assign an explanatory message to iomsg-variable. If no such condition occurs, the 3 processor shall not change the value of iomsg-variable. 4 9.11 Restrictions on input/output statements 5 If a unit, or a file connected to a unit, does not have all of the properties required for the execution of 6 certain input/output statements, those statements shall not refer to the unit. 7 An input/output statement that is executed while another input/output statement is being executed is 8 called a recursive input/output statement. 9 A recursive input/output statement shall not identify an external unit that is identified by another 10 input/output statement being executed except that a child data transfer statement may identify its 11 parent data transfer statement external unit. 12 An input/output statement shall not cause the value of any established format specification to be 13 modified. 14 A recursive input/output statement shall not modify the value of any internal unit except that a recursive 15 WRITE statement may modify the internal unit identified by that recursive WRITE statement. 16 The value of a specifier in an input/output statement shall not depend on any input-item, io-implied- 17 do do-variable, or on the definition or evaluation of any other specifier in the io-control-spec-list or 18 inquire-spec-list in that statement. 19 The value of any subscript or substring bound of a variable that appears in a specifier in an input/output 20 statement shall not depend on any input-item, io-implied-do do-variable, or on the definition or evalua- 21 tion of any other specifier in the io-control-spec-list or inquire-spec-list in that statement. 22 In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if 23 any, shall not be associated with any entity in the data transfer input/output list (9.5.3) or namelist- 24 group-object-list, nor with a do-variable of an io-implied-do in the data transfer input/output list. 25 In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an 26 array element reference, its subscript values shall not be affected by the data transfer, the io-implied-do 27 processing, or the definition or evaluation of any other specifier in the io-control-spec-list. 28 A variable that may become defined or undefined as a result of its use in a specifier in an INQUIRE 29 statement, or any associated entity, shall not appear in another specifier in the same INQUIRE statement. 30 A STOP statement shall not be executed during execution of an input/output statement. 31 NOTE 9.70 Restrictions on the evaluation of expressions (7.1.8) prohibit certain side effects. 255 J3/06-007r1 WORKING DRAFT 2006/09/25 256 2006/09/25 WORKING DRAFT J3/06-007r1 10 Input/output editing 1 10.1 Format specifications 2 A format used in conjunction with an input/output statement provides information that directs the 3 editing between the internal representation of data and the characters of a sequence of formatted records. 4 A R914 (9.5.2.2) in an input/output statement may refer to a FORMAT statement or to a character 5 expression that contains a format specification. A format specification provides explicit editing infor- 6 mation. The R914 alternatively may be an asterisk (*), which indicates list-directed formatting (10.10). 7 Namelist formatting (10.11) may be indicated by specifying a namelist-group-name instead of a format. 8 10.2 Explicit format specification methods 9 10.2.1 FORMAT statement 10 R1001 format-stmt is FORMAT format-specification 11 R1002 format-specification is ( [ format-item-list ] ) 12 or ( [ format-item-list, ] unlimited-format-item ) 13 C1001 (R1001) The format-stmt shall be labeled. 14 C1002 (R1002) The comma used to separate format-items in a format-item-list may be omitted 15 (1) between a P edit descriptor and an immediately following F, E, EN, ES, D, or G edit 16 descriptor (10.8.5), possibly preceded by a repeat specifier, 17 (2) before a slash edit descriptor when the optional repeat specification is not present (10.8.2), 18 (3) after a slash edit descriptor, or 19 (4) before or after a colon edit descriptor (10.8.3) 20 Blank characters may precede the initial left parenthesis of the format specification. Additional blank 21 characters may appear at any point within the format specification, with no effect on the interpretation 22 of the format specification, except within a character string edit descriptor (10.9). 23 NOTE 10.1 Examples of FORMAT statements are: 5 FORMAT (1PE12.4, I10) 9 FORMAT (I12, /, ' Dates: ', 2 (2I3, I5)) 10.2.2 Character format specification 24 A character expression used as a format in a formatted input/output statement shall evaluate to a 25 character string whose leading part is a valid format specification. 26 NOTE 10.2 The format specification begins with a left parenthesis and ends with a right parenthesis. All character positions up to and including the final right parenthesis of the format specification shall be 27 257 J3/06-007r1 WORKING DRAFT 2006/09/25 defined at the time the input/output statement is executed, and shall not become redefined or undefined 1 during the execution of the statement. Character positions, if any, following the right parenthesis that 2 ends the format specification need not be defined and may contain any character data with no effect on 3 the interpretation of the format specification. 4 If the format is a character array, it is treated as if all of the elements of the array were specified in array 5 element order and were concatenated. However, if a format is a character array element, the format 6 specification shall be entirely within that array element. 7 NOTE 10.3 If a character constant is used as a format in an input/output statement, care shall be taken that the value of the character constant is a valid format specification. In particular, if a format specification delimited by apostrophes contains a character constant edit descriptor delimited with apostrophes, two apostrophes shall be written to delimit the edit descriptor and four apostrophes shall be written for each apostrophe that occurs within the edit descriptor. For example, the text: 2 ISN'T 3 may be written by various combinations of output statements and format specifications: WRITE (6, 100) 2, 3 100 FORMAT (1X, I1, 1X, 'ISN''T', 1X, I1) WRITE (6, '(1X, I1, 1X, ''ISN''''T'', 1X, I1)') 2, 3 WRITE (6, '(A)') ' 2 ISN''T 3' Doubling of internal apostrophes usually can be avoided by using quotation marks to delimit the format specification and doubling of internal quotation marks usually can be avoided by using apostrophes as delimiters. 10.3 Form of a format item list 8 10.3.1 Syntax 9 R1003 format-item is [ r ] data-edit-desc 10 or control-edit-desc 11 or char-string-edit-desc 12 or [ r ] ( format-item-list ) 13 R1004 unlimited-format-item is * ( format-item-list ) 14 R1005 r is int-literal-constant 15 C1003 (R1005) r shall be positive. 16 C1004 (R1005) r shall not have a kind parameter specified for it. 17 The integer literal constant r is called a repeat specification. 18 10.3.2 Edit descriptors 19 An edit descriptor is a data edit descriptor, a control edit descriptor, or a character string 20 edit descriptor. 21 R1006 data-edit-desc is I w [ . m ] 22 or B w [ . m ] 23 or O w [ . m ] 24 258 2006/09/25 WORKING DRAFT J3/06-007r1 or Zw [. m] 1 or Fw . d 2 or Ew . d [Ee] 3 or EN w . d [ E e ] 4 or ES w . d [ E e ] 5 or Gw [. d [Ee]] 6 or Lw 7 or A[w ] 8 or Dw . d 9 or DT [ char-literal-constant ] [ ( v -list ) ] 10 R1007 w is int-literal-constant 11 R1008 m is int-literal-constant 12 R1009 d is int-literal-constant 13 R1010 e is int-literal-constant 14 R1011 v is signed-int-literal-constant 15 C1005 (R1010) e shall be positive. 16 C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be 17 positive for all other edit descriptors. 18 C1007 (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. 19 C1008 (R1006) w , m, d , e, and v shall not have kind parameters specified for them. 20 C1009 (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter 21 specified for it. 22 I, B, O, Z, F, E, EN, ES, G, L, A, D, and DT indicate the manner of editing. 23 R1012 control-edit-desc is position-edit-desc 24 or [r ]/ 25 or : 26 or sign-edit-desc 27 or kP 28 or blank-interp-edit-desc 29 or round-edit-desc 30 or decimal-edit-desc 31 R1013 k is signed-int-literal-constant 32 C1010 (R1013) k shall not have a kind parameter specified for it. 33 In k P, k is called the scale factor. 34 R1014 position-edit-desc is Tn 35 or TL n 36 or TR n 37 or nX 38 R1015 n is int-literal-constant 39 C1011 (R1015) n shall be positive. 40 C1012 (R1015) n shall not have a kind parameter specified for it. 41 R1016 sign-edit-desc is SS 42 or SP 43 or S 44 259 J3/06-007r1 WORKING DRAFT 2006/09/25 R1017 blank-interp-edit-desc is BN 1 or BZ 2 R1018 round-edit-desc is RU 3 or RD 4 or RZ 5 or RN 6 or RC 7 or RP 8 R1019 decimal-edit-desc is DC 9 or DP 10 T, TL, TR, X, slash, colon, SS, SP, S, P, BN, BZ, RU, RD, RZ, RN, RC, RP, DC, and DP indicate the 11 manner of editing. 12 R1020 char-string-edit-desc is char-literal-constant 13 C1013 (R1020) The char-literal-constant shall not have a kind parameter specified for it. 14 Each rep-char in a character string edit descriptor shall be one of the characters capable of representation 15 by the processor. 16 The character string edit descriptors provide constant data to be output, and are not valid for input. 17 The edit descriptors are without regard to case except for the characters in the character constants. 18 10.3.3 Fields 19 A field is a part of a record that is read on input or written on output when format control encounters 20 a data edit descriptor or a character string edit descriptor. The field width is the size in characters of 21 the field. 22 10.4 Interaction between input/output list and format 23 The start of formatted data transfer using a format specification initiates format control (9.5.4.4.2). 24 Each action of format control depends on information jointly provided by the next edit descriptor in the 25 format specification and the next effective item in the input/output list, if one exists. 26 If an input/output list specifies at least one effective list item, at least one data edit descriptor shall 27 exist in the format specification. 28 NOTE 10.4 An empty format specification of the form ( ) may be used only if the input/output list has no effective list items (9.5.4.4). Zero length character items are effective list items, but zero sized arrays and implied DO lists with an iteration count of zero are not. A format specification is interpreted from left to right. The exceptions are format items preceded by a 29 repeat specification r , and format reversion (described below). 30 A format item preceded by a repeat specification is processed as a list of r items, each identical to the 31 format item but without the repeat specification and separated by commas. 32 NOTE 10.5 An omitted repeat specification is treated in the same way as a repeat specification whose value is one. 260 2006/09/25 WORKING DRAFT J3/06-007r1 To each data edit descriptor interpreted in a format specification, there corresponds one effective item 1 specified by the input/output list (9.5.3), except that an input/output list item of type complex requires 2 the interpretation of two F, E, EN, ES, D, or G edit descriptors. For each control edit descriptor or 3 character edit descriptor, there is no corresponding item specified by the input/output list, and format 4 control communicates information directly with the record. 5 Whenever format control encounters a data edit descriptor in a format specification, it determines 6 whether there is a corresponding effective item specified by the input/output list. If there is such an 7 item, it transmits appropriately edited information between the item and the record, and then format 8 control proceeds. If there is no such item, format control terminates. 9 If format control encounters a colon edit descriptor in a format specification and another effective in- 10 put/output list item is not specified, format control terminates. 11 If format control encounters the rightmost parenthesis of a complete format specification and another 12 effective input/output list item is not specified, format control terminates. However, if another effective 13 input/output list item is specified, format control then reverts to the beginning of the format item 14 terminated by the last preceding right parenthesis that is not part of a DT edit descriptor. If there 15 is no such preceding right parenthesis, format control reverts to the first left parenthesis of the format 16 specification. If any reversion occurs, the reused portion of the format specification shall contain at 17 least one data edit descriptor. If format control reverts to a parenthesis that is preceded by a repeat 18 specification, the repeat specification is reused. Reversion of format control, of itself, has no effect on 19 the changeable modes (9.4.1). If format control reverts to a parenthesis that is not the beginning of an 20 unlimited-format-item, the file is positioned in a manner identical to the way it is positioned when a 21 slash edit descriptor is processed (10.8.2). 22 NOTE 10.6 Example: The format specification: 10 FORMAT (1X, 2(F10.3, I5)) with an output list of WRITE (10,10) 10.1, 3, 4.7, 1, 12.4, 5, 5.2, 6 produces the same output as the format specification: 10 FORMAT (1X, F10.3, I5, F10.3, I5/F10.3, I5, F10.3, I5) NOTE 10.7 The effect of an unlimited-format-item is as if its enclosed list were preceded by a very large repeat count. There is no file positioning implied by unlimited-format-item reversion. This may be used to write what is commonly called a comma separated value record. For example, WRITE( 10, '( "IARRAY =", *( I0, :, ","))') IARRAY produces a single record with a header and a comma separated list of integer values. 10.5 Positioning by format control 23 261 J3/06-007r1 WORKING DRAFT 2006/09/25 After each data edit descriptor or character string edit descriptor is processed, the file is positioned after 1 the last character read or written in the current record. 2 After each T, TL, TR, or X edit descriptor is processed, the file is positioned as described in 10.8.1. 3 After each slash edit descriptor is processed, the file is positioned as described in 10.8.2. 4 During formatted stream output, processing of an A edit descriptor can cause file positioning to occur 5 (10.7.4). 6 If format control reverts as described in 10.4, the file is positioned in a manner identical to the way it is 7 positioned when a slash edit descriptor is processed (10.8.2). 8 During a read operation, any unprocessed characters of the current record are skipped whenever the 9 next record is read. 10 10.6 Decimal symbol 11 The decimal symbol is the character that separates the whole and fractional parts in the decimal 12 representation of a real number in an internal or external file. When the decimal edit mode is POINT, 13 the decimal symbol is a decimal point. When the decimal edit mode is COMMA, the decimal symbol is 14 a comma. 15 10.7 Data edit descriptors 16 10.7.1 General 17 Data edit descriptors cause the conversion of data to or from its internal representation; during formatted 18 stream output, the A data edit descriptor may also cause file positioning. On input, the specified variable 19 becomes defined unless an error condition, an end-of-file condition, or an end-of-record condition occurs. 20 On output, the specified expression is evaluated. 21 During input from a Unicode file, 22 (1) characters in the record that correspond to an ASCII character variable shall have a position 23 in the ISO 10646 character type collating sequence of 127 or less, and 24 (2) characters in the record that correspond to a default character variable shall be representable 25 in the default character type. 26 During input from a non-Unicode file, 27 (1) characters in the record that correspond to a character variable shall have the kind of the 28 character variable, and 29 (2) characters in the record that correspond to a numeric logical, or bits variable shall be of 30 default character type. 31 During output to a Unicode file, all characters transmitted to the record are of ISO 10646 character 32 type. If a character input/output list item or character string edit descriptor contains a character that 33 is not representable in the ISO 10646 character type, the result is processor-dependent. 34 During output to a non-Unicode file, characters transmitted to the record as a result of processing a 35 character string edit descriptor or as a result of evaluating a numeric, logical, bits, or default character 36 data entity, are of type default character. 37 10.7.2 Numeric and bits editing 38 262 2006/09/25 WORKING DRAFT J3/06-007r1 10.7.2.1 General rules 1 The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify the input/output of 2 integer, real, complex, and bits data. The following general rules apply. 3 (1) On input, leading blanks are not significant. When the input field is not an IEEE excep- 4 tional specification (10.7.2.3.2), the interpretation of blanks, other than leading blanks, is 5 determined by the blank interpretation mode (10.8.6). Plus signs may be omitted. A field 6 containing only blanks is considered to be zero. 7 (2) On input, with F, E, EN, ES, D, and G editing, a decimal symbol appearing in the input 8 field overrides the portion of an edit descriptor that specifies the decimal symbol location. 9 The input field may have more digits than the processor uses to approximate the value of 10 the datum. 11 (3) On output with I, F, E, EN, ES, D, and G editing, the representation of a positive or zero 12 internal value in the field may be prefixed with a plus sign, as controlled by the S, SP, and 13 SS edit descriptors or the processor. The representation of a negative internal value in the 14 field shall be prefixed with a minus sign. 15 (4) On output, the representation is right justified in the field. If the number of characters 16 produced by the editing is smaller than the field width, leading blanks are inserted in the 17 field. 18 (5) On output, if the number of characters produced exceeds the field width or if an exponent 19 exceeds its specified length using the Ew.d Ee, ENw.d Ee, ESw.d Ee, or Gw.d Ee edit 20 descriptor, the processor shall fill the entire field of width w with asterisks. However, 21 the processor shall not produce asterisks if the field width is not exceeded when optional 22 characters are omitted. 23 NOTE 10.8 When an SP edit descriptor is in effect, a plus sign is not optional. (6) On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may 24 be zero. In such cases, the processor selects the smallest positive actual field width that 25 does not result in a field filled with asterisks. The specified value of w shall not be zero on 26 input. 27 10.7.2.2 Integer editing 28 The Iw and Iw.m, edit descriptors indicate that the field to be edited occupies w positions, except when 29 w is zero. When w is zero, the processor selects the field width. On input, w shall not be zero. The 30 specified input/output list item shall be of type integer or bits. The G, B, O, and Z edit descriptor also 31 may be used to edit integer data (10.7.5.2.1, 10.7.2.4). 32 If the input list item is of type bits, the integer value specified by the input field is converted to type 33 bits according to the model in 13.3. On input, m has no effect. 34 In the input field for the I edit descriptor, the character string shall be a signed-digit-string (R409) if 35 the list item is of type integer and a digit-string (R410) if it is of type bits, except for the interpretation 36 of blanks. 37 The output field for the Iw edit descriptor consists of zero or more leading blanks followed by a minus 38 sign if the internal value is negative, or an optional plus sign otherwise, followed by the magnitude of 39 the internal value as a digit-string without leading zeros. 40 NOTE 10.9 A digit-string always consists of at least one digit. 263 J3/06-007r1 WORKING DRAFT 2006/09/25 The output field for the Iw.m edit descriptor is the same as for the Iw edit descriptor, except that the 1 digit-string consists of at least m digits. If necessary, sufficient leading zeros are included to achieve the 2 minimum of m digits. The value of m shall not exceed the value of w , except when w is zero. If m is 3 zero and the internal value is zero, the output field consists of only blank characters, regardless of the 4 sign control in effect. When m and w are both zero, and the internal value is zero, one blank character 5 is produced. 6 10.7.2.3 Real and complex editing 7 10.7.2.3.1 General 8 The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output 9 list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G, B, O, 10 and Z edit descriptors also may be used to edit real and complex data (10.7.5.2.2). 11 10.7.2.3.2 F editing 12 The Fw.d edit descriptor indicates that the field occupies w positions, the fractional part of which 13 consists of d digits. When w is zero, the processor selects the field width. On input, w shall not be zero. 14 A lower-case letter is equivalent to the corresponding upper-case letter in an IEEE exceptional specifi- 15 cation or the exponent in a numeric input field. 16 The input field is either an IEEE exceptional specification or consists of an optional sign, followed by a 17 string of one or more digits optionally containing a decimal symbol, including any blanks interpreted as 18 zeros. The d has no effect on input if the input field contains a decimal symbol. If the decimal symbol 19 is omitted, the rightmost d digits of the string, with leading zeros assumed if necessary, are interpreted 20 as the fractional part of the value represented. The string of digits may contain more digits than a 21 processor uses to approximate the value. The basic form may be followed by an exponent of one of the 22 following forms: 23 · a sign followed by a digit-string; 24 · the letter E followed by zero or more blanks, followed by a signed-digit-string; 25 · the letter D followed by zero or more blanks, followed by a signed-digit-string. 26 An exponent containing a D is processed identically to an exponent containing an E. 27 NOTE 10.10 If the input field does not contain an exponent, the effect is as if the basic form were followed by an exponent with a value of -k, where k is the established scale factor (10.8.5). An input field that is an IEEE exceptional specification consists of optional blanks, followed by either 28 · an optional sign, followed by the string 'INF' or the string 'INFINITY', or 29 · an optional sign, followed by the string 'NAN', optionally followed by zero or more alphanumeric 30 characters enclosed in parentheses, 31 optionally followed by blanks. 32 The value specified by form (1) is an IEEE infinity; this form shall not be used if the processor does 33 not support IEEE infinities for the input variable. The value specified by form (2) is an IEEE NaN; 34 264 2006/09/25 WORKING DRAFT J3/06-007r1 this form shall not be used if the processor does not support IEEE NaNs for the input variable. The 1 NaN value is a quiet NaN if the only nonblank characters in the field are 'NAN' or 'NAN()'; otherwise, 2 the NaN value is processor-dependent. The interpretation of a sign in a NaN input field is processor 3 dependent. 4 For an internal value that is an IEEE infinity, the output field consists of blanks, if necessary, followed 5 by a minus sign for negative infinity or an optional plus sign otherwise, followed by the letters 'Inf' or 6 'Infinity', right justified within the field. If w is less than 3, the field is filled with asterisks; otherwise, 7 if w is less than 8, 'Inf' is produced. 8 For an internal value that is an IEEE NaN, the output field consists of blanks, if necessary, followed by 9 the letters 'NaN' and optionally followed by one to w - 5 alphanumeric processor-dependent characters 10 enclosed in parentheses, right justified within the field. If w is less than 3, the field is filled with asterisks. 11 NOTE 10.11 The processor-dependent characters following 'NaN' may convey additional information about that particular NaN. For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if 12 necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, 13 followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal 14 value, as modified by the established scale factor and rounded (10.7.2.3.7) to d fractional digits. Leading 15 zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the 16 magnitude of the value in the output field is less than one. The optional zero shall appear if there would 17 otherwise be no digits in the output field. 18 10.7.2.3.3 E and D editing 19 The Ew.d, Dw.d, and Ew.d Ee edit descriptors indicate that the external field occupies w positions, the 20 fractional part of which consists of d digits, unless a scale factor greater than one is in effect, and the 21 exponent part consists of e digits. The e has no effect on input. 22 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 23 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 24 Fw.d. 25 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field for a scale 26 factor of zero is 27 [ ± ] [0].x1 x2 . . . xd exp 28 where: 29 · ± signifies a plus sign or a minus sign; 30 · . signifies a decimal symbol (10.6); 31 · x1 x2 . . . xd are the d most significant digits of the internal value after rounding (10.7.2.3.7); 32 · exp is a decimal exponent having one of the forms specified in table 10.1. 33 265 J3/06-007r1 WORKING DRAFT 2006/09/25 Table 10.1: E and D exponent forms Edit Absolute Value Form of Exponent1 Descriptor of Exponent |exp| 99 E±z1 z2 or ±0z1 z2 Ew.d 99 < |exp| 999 ±z1 z2 z3 e |exp| 10 - 1 Ew.d Ee E±z1 z2 . . . ze |exp| 99 Dw.d D±z1 z2 or E±z1 z2 or ±0z1 z2 99 < |exp| 999 ±z1 z2 z3 (1) where each z is a digit. The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 1 descriptor forms Ew.d and Dw.d shall not be used if |exp| > 999. 2 The scale factor k controls the decimal normalization (10.3.2, 10.8.5). If -d < k 0, the output field 3 contains exactly |k| leading zeros and d - |k| significant digits after the decimal symbol. If 0 < k < d + 2, 4 the output field contains exactly k significant digits to the left of the decimal symbol and d - k + 1 5 significant digits to the right of the decimal symbol. Other values of k are not permitted. 6 10.7.2.3.4 EN editing 7 The EN edit descriptor produces an output field in the form of a real number in engineering notation 8 such that the decimal exponent is divisible by three and the absolute value of the significand (R414) is 9 greater than or equal to 1 and less than 1000, except when the output value is zero. The scale factor 10 has no effect on output. 11 The forms of the edit descriptor are ENw.d and ENw.d Ee indicating that the external field occupies w 12 positions, the fractional part of which consists of d digits and the exponent part consists of e digits. 13 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 14 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 15 Fw.d. 16 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 17 [ ± ] yyy . x1 x2 . . . xd exp 18 where: 19 · ± signifies a plus sign or a minus sign; 20 · yyy are the 1 to 3 decimal digits representative of the most significant digits of the internal value 21 after rounding (10.7.2.3.7); 22 · yyy is an integer such that 1 yyy < 1000 or, if the output value is zero, yyy = 0; 23 · . signifies a decimal symbol (10.6); 24 · x1 x2 . . . xd are the d next most significant digits of the internal value after rounding; 25 · exp is a decimal exponent, divisible by three, having one of the forms specified in table 10.2. 26 266 2006/09/25 WORKING DRAFT J3/06-007r1 Table 10.2: EN exponent forms Edit Absolute Value Form of Exponent1 Descriptor of Exponent |exp| 99 E±z1 z2 or ±0z1 z2 ENw.d 99 < |exp| 999 ±z1 z2 z3 e |exp| 10 - 1 ENw.d Ee E±z1 z2 . . . ze (1) where each z is a digit. The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 1 descriptor form ENw.d shall not be used if |exp| > 999. 2 NOTE 10.12 Examples: Internal Value Output field Using SS, EN12.3 6.421 6.421E+00 -.5 -500.000E-03 .00217 2.170E-03 4721.3 4.721E+03 10.7.2.3.5 ES editing 3 The ES edit descriptor produces an output field in the form of a real number in scientific notation such 4 that the absolute value of the significand (R414) is greater than or equal to 1 and less than 10, except 5 when the output value is zero. The scale factor has no effect on output. 6 The forms of the edit descriptor are ESw.d and ESw.d Ee indicating that the external field occupies w 7 positions, the fractional part of which consists of d digits and the exponent part consists of e digits. 8 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 9 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 10 Fw.d. 11 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 12 [ ± ] y . x1 x2 . . . xd exp 13 where: 14 · ± signifies a plus sign or a minus sign; 15 · y is a decimal digit representative of the most significant digit of the internal value after rounding 16 (10.7.2.3.7); 17 · . signifies a decimal symbol (10.6); 18 · x1 x2 . . . xd are the d next most significant digits of the internal value after rounding; 19 · exp is a decimal exponent having one of the forms specified in table 10.3. 20 267 J3/06-007r1 WORKING DRAFT 2006/09/25 Table 10.3: ES exponent forms Edit Absolute Value Form of Exponent1 Descriptor of Exponent |exp| 99 E±z1 z2 or ±0z1 z2 ESw.d 99 < |exp| 999 ±z1 z2 z3 e |exp| 10 - 1 ESw.d Ee E±z1 z2 . . . ze (1) where each z is a digit. The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 1 descriptor form ESw.d shall not be used if |exp| > 999. 2 NOTE 10.13 Examples: Internal Value Output field Using SS, ES12.3 6.421 6.421E+00 -.5 -5.000E-01 .00217 2.170E-03 4721.3 4.721E+03 10.7.2.3.6 Complex editing 3 A complex datum consists of a pair of separate real data. The editing of a scalar datum of complex type 4 is specified by two edit descriptors each of which specifies the editing of real data. The first of the edit 5 descriptors specifies the real part; the second specifies the imaginary part. The two edit descriptors may 6 be different. Control and character string edit descriptors may be processed between the edit descriptor 7 for the real part and the edit descriptor for the imaginary part. 8 10.7.2.3.7 Rounding mode 9 The rounding mode can be specified by an OPEN statement (9.4.1), a data transfer input/output 10 statement (9.5.2.13), or an edit descriptor (10.8.7). 11 In what follows, the term "decimal value" means the exact decimal number as given by the character 12 string, while the term "internal value" means the number actually stored in the processor. For example, 13 in dealing with the decimal constant 0.1, the decimal value is the mathematical quantity 1/10, which 14 has no exact representation in binary form. Formatted output of real data involves conversion from an 15 internal value to a decimal value; formatted input involves conversion from a decimal value to an internal 16 value. 17 When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest repre- 18 sentable value that is greater than or equal to the original value. When the I/O rounding mode is 19 DOWN, the value resulting from conversion shall be the largest representable value that is less than or 20 equal to the original value. When the I/O rounding mode is ZERO, the value resulting from conversion 21 shall be the value closest to the original value and no greater in magnitude than the original value. When 22 the I/O rounding mode is NEAREST, the value resulting from conversion shall be the closer of the two 23 nearest representable values if one is closer than the other. If the two nearest representable values are 24 equidistant from the original value, it is processor dependent which one of them is chosen. When the 25 I/O rounding mode is COMPATIBLE, the value resulting from conversion shall be the closer of the 26 two nearest representable values or the value away from zero if halfway between them. When the I/O 27 rounding mode is PROCESSOR DEFINED, rounding during conversion shall be a processor dependent 28 default mode, which may correspond to one of the other modes. 29 On processors that support IEEE rounding on conversions, NEAREST shall correspond to round to 30 268 2006/09/25 WORKING DRAFT J3/06-007r1 nearest, as specified in the IEEE International Standard. 1 NOTE 10.14 On processors that support IEEE rounding on conversions, the I/O rounding modes COMPATI- BLE and NEAREST will produce the same results except when the datum is halfway between the two representable values. In that case, NEAREST will pick the even value, but COMPATIBLE will pick the value away from zero. The I/O rounding modes UP, DOWN, and ZERO have the same effect as those specified in the IEEE International Standard for round toward +, round toward -, and round toward 0, respectively. 10.7.2.4 Bits editing 2 The Bw , Bw .m, Ow , Ow .m, Zw , and Zw.m edit descriptors indicate that the field to be edited occupies 3 w positions, except when w is zero. When w is zero, the processor selects the field width. On input, 4 w shall not be zero. The input/output list item shall be of type bits, integer, real, complex, or logical. 5 The G edit descriptor (10.7.5.3) or the I edit descriptor (10.7.2.2) also can be used to edit bits data. 6 If the input list item is not of type bits, the input field is edited as if the input list item were of type 7 bits and bits compatible (12.5.2.4) with the actual list item. 8 On input, m has no effect. 9 In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, 10 or hexadecimal digits (as in R426, R427, R428) in the respective input field. The lower-case hexadecimal 11 digits a through f in a hexadecimal input field are equivalent to the corresponding upper-case hexadecimal 12 digits. 13 If the output list item, x, is not of type bits, it is interpreted as if it were of type bits with the value 14 BITS(x ). 15 The output field for the Bw , Ow , and Zw descriptors consists of zero or more leading blanks followed by 16 the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, 17 with the same value and without leading zeros. 18 NOTE 10.15 A binary, octal, or hexadecimal constant always consists of at least one digit or hexadecimal digit. R1021 hex-digit-string is hex-digit [ hex-digit ] ... 19 The output field for the Bw.m, Ow.m, and Zw.m edit descriptor is the same as for the Bw , Ow , and Zw 20 edit descriptor, except that the digit-string or hex-digit-string consists of at least m digits. If necessary, 21 sufficient leading zeros are included to achieve the minimum of m digits. The value of m shall not exceed 22 the value of w , except when w is zero. If m is zero and the internal value consists of all zero bits, the 23 output field consists of only blank characters. When m and w are both zero, and the internal value 24 consists of all zero bits, one blank character is produced. 25 10.7.3 Logical editing 26 The Lw edit descriptor indicates that the field occupies w positions. The specified input/output list 27 item shall be of type logical. The G edit descriptor also may be used to edit logical data (10.7.5.4). 28 The input field consists of optional blanks, optionally followed by a period, followed by a T for true or 29 F for false. The T or F may be followed by additional characters in the field, which are ignored. 30 A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field. 31 269 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 10.16 The logical constants .TRUE. and .FALSE. are acceptable input forms. The output field consists of w - 1 blanks followed by a T or F, depending on whether the internal value 1 is true or false, respectively. 2 10.7.4 Character editing 3 The A[w ] edit descriptor is used with an input/output list item of type character. The G edit descriptor 4 also may be used to edit character data (10.7.5.5). The kind type parameter of all characters transferred 5 and converted under control of one A or G edit descriptor is implied by the kind of the corresponding 6 list item. 7 If a field width w is specified with the A edit descriptor, the field consists of w characters. If a field 8 width w is not specified with the A edit descriptor, the number of characters in the field is the length of 9 the corresponding list item, regardless of the value of the kind type parameter. 10 Let len be the length of the input/output list item. If the specified field width w for an A edit descriptor 11 corresponding to an input item is greater than or equal to len, the rightmost len characters will be taken 12 from the input field. If the specified field width w is less than len, the w characters will appear left 13 justified with len-w trailing blanks in the internal value. 14 If the specified field width w for an A edit descriptor corresponding to an output item is greater than 15 len, the output field will consist of w - len blanks followed by the len characters from the internal value. 16 If the specified field width w is less than or equal to len, the output field will consist of the leftmost w 17 characters from the internal value. 18 NOTE 10.17 For nondefault character types, the blank padding character is processor dependent. If the file is connected for stream access, the output may be split across more than one record if it 19 contains newline characters. A newline character is a nonblank character returned by the intrinsic 20 function NEW LINE. Beginning with the first character of the output field, each character that is not 21 a newline is written to the current record in successive positions; each newline character causes file 22 positioning at that point as if by slash editing (the current record is terminated at that point, a new 23 empty record is created following the current record, this new record becomes the last and current record 24 of the file, and the file is positioned at the beginning of this new record). 25 NOTE 10.18 If the intrinsic function NEW LINE returns a blank character for a particular character kind, then the processor does not support using a character of that kind to cause record termination in a formatted stream file. 10.7.5 Generalized editing 26 10.7.5.1 Overview 27 The Gw , Gw.d and Gw.d Ee edit descriptors are used with an input/output list item of any intrinsic 28 type. When w is nonzero, these edit descriptors indicate that the external field occupies w positions; 29 for real or complex data the fractional part consists of a maximum of d digits and the exponent part 30 consists of e digits. When these edit descriptors are used to specify the input/output of integer, logical, 31 bits, or character data, d and e have no effect. When w is zero the processor selects the field width. On 32 input, w shall not be zero. 33 270 2006/09/25 WORKING DRAFT J3/06-007r1 10.7.5.2 Generalized numeric editing 1 When used to specify the input/output of integer, real, and complex data, the Gw , Gw.d and Gw.d Ee 2 edit descriptors follow the general rules for numeric editing (10.7.2). 3 NOTE 10.19 The Gw.d Ee edit descriptor follows any additional rules for the Ew.d Ee edit descriptor. 10.7.5.2.1 Generalized integer editing 4 When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow 5 the rules for the Iw edit descriptor (10.7.2.2), except that w shall not be zero. When used to specify the 6 output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor. 7 10.7.5.2.2 Generalized real and complex editing 8 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 9 When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for 10 the ESw.d Ee edit descriptor. Reasonable processor-dependent values of w , d , and e are used with each 11 output value. 12 For an internal value that is an IEEE infinity or NaN, the form of the output field for the Gw.d and 13 Gw.d Ee edit descriptors is the same as for Fw.d. 14 Otherwise, the method of representation in the output field depends on the magnitude of the internal 15 value being edited. Let N be the magnitude of the internal value and r be the rounding mode value 16 defined in the table below. If 0 < N < 0.1 - r × 10-d-1 or N 10d - r, or N is identically 0 and 17 d is 0, Gw.d output editing is the same as k PEw.d output editing and Gw.d Ee output editing is 18 the same as k PEw.d Ee output editing, where k is the scale factor (10.8.5) currently in effect. If 19 0.1 - r × 10-d-1 N < 10d - r or N is identically 0 and d is not zero, the scale factor has no effect, 20 and the value of N determines the editing as follows: 21 Magnitude of Internal Value Equivalent Conversion F(w - n).(d - 1), n('b') N =0 0.1 - r × 10-d-1 N < 1 - r × 10-d F(w - n).d, n('b') 1 - r × 10-d N < 10 - r × 10-d+1 F(w - n).(d - 1), n('b') 10 - r × 10-d+1 N < 100 - r × 10-d+2 F(w - n).(d - 2), n('b') · · · · · · 10d-2 - r × 10-2 N < 10d-1 - r × 10-1 F(w - n).1, n('b') 10d-1 - r × 10-1 N < 10d - r F(w - n).0, n('b') where b is a blank, n is 4 for Gw.d and e + 2 for Gw.d Ee, and r is defined for each rounding mode as 22 follows: 23 I/O Rounding Mode r COMPATIBLE 0.5 0.5 if the higher value is even NEAREST -0.5 if the lower value is even UP 1 DOWN 0 271 J3/06-007r1 WORKING DRAFT 2006/09/25 I/O Rounding Mode r 1 if internal value is negative ZERO 0 if internal value is positive The value of w - n shall be positive 1 NOTE 10.20 The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range that permits effective use of F editing. 10.7.5.3 Generalized bits editing 2 When used to specify the input/output of bits data, the Gw.d and Gw.d Ee edit descriptors follow the 3 rules for the Zw edit descriptor (10.7.2.4), except that w shall not be zero. When used to specify the 4 output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor. 5 10.7.5.4 Generalized logical editing 6 When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors follow 7 the rules for the Lw edit descriptor (10.7.3). When used to specify the output of logical data, the G0 8 edit descriptor follows the rules for the L1 edit descriptor. 9 10.7.5.5 Generalized character editing 10 When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors follow 11 the rules for the Aw edit descriptor (10.7.4). When used to specify the output of character data, the G0 12 edit descriptor follows the rules for the A edit descriptor with no field width. 13 10.7.6 User-defined derived-type editing 14 The DT edit descriptor allows a user-provided procedure to be used instead of the processor's default 15 input/output formatting for processing a list item of derived type. 16 The DT edit descriptor may include a character literal constant. The character value "DT" concatenated 17 with the character literal constant is passed to the user-defined derived-type input/output procedure as 18 the iotype argument (9.5.4.7). The v values of the edit descriptor are passed to the user-defined 19 derived-type input/output procedure as the v_list array argument. 20 NOTE 10.21 For the edit descriptor DT'Link List'(10, 4, 2), iotype is "DTLink List" and v_list is (/10, 4, 2/). If a derived-type variable or value corresponds to a DT edit descriptor, there shall be an accessible 21 interface to a corresponding derived-type input/output procedure for that derived type (9.5.4.7). A DT 22 edit descriptor shall not correspond with a list item that is not of a derived type. 23 10.8 Control edit descriptors 24 A control edit descriptor does not cause the transfer of data or the conversion of data to or from internal 25 representation, but may affect the conversions performed by subsequent data edit descriptors. 26 272 2006/09/25 WORKING DRAFT J3/06-007r1 10.8.1 Position editing 1 The T, TL, TR, and X edit descriptors specify the position at which the next character will be transmitted 2 to or from the record. If any character skipped by a T, TL, TR, or X edit descriptor is of type nondefault 3 character, and the unit is an internal file of type default character or an external non-Unicode file, the 4 result of that position editing is processor dependent. 5 The position specified by a T edit descriptor may be in either direction from the current position. On 6 input, this allows portions of a record to be processed more than once, possibly with different editing. 7 The position specified by an X edit descriptor is forward from the current position. On input, a position 8 beyond the last character of the record may be specified if no characters are transmitted from such 9 positions. 10 NOTE 10.22 An nX edit descriptor has the same effect as a TRn edit descriptor. On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to be transmitted and 11 therefore does not by itself affect the length of the record. If characters are transmitted to positions at 12 or after the position specified by a T, TL, TR, or X edit descriptor, positions skipped and not previously 13 filled are filled with blanks. The result is as if the entire record were initially filled with blanks. 14 On output, a character in the record may be replaced. However, a T, TL, TR, or X edit descriptor never 15 directly causes a character already placed in the record to be replaced. Such edit descriptors may result 16 in positioning such that subsequent editing causes a replacement. 17 10.8.1.1 T, TL, and TR editing 18 The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to 19 nonchild data transfer, the left tab limit becomes defined as the character position of the current record 20 or the current position of the stream file. If, during data transfer, the file is positioned to another record, 21 the left tab limit becomes defined as character position one of that record. 22 The Tn edit descriptor indicates that the transmission of the next character to or from a record is to 23 occur at the nth character position of the record, relative to the left tab limit. 24 The TLn edit descriptor indicates that the transmission of the next character to or from the record is 25 to occur at the character position n characters backward from the current position. However, if n is 26 greater than the difference between the current position and the left tab limit, the TLn edit descriptor 27 indicates that the transmission of the next character to or from the record is to occur at the left tab 28 limit. 29 The TRn edit descriptor indicates that the transmission of the next character to or from the record is 30 to occur at the character position n characters forward from the current position. 31 NOTE 10.23 The n in a Tn, TLn, or TRn edit descriptor shall be specified and shall be greater than zero. 10.8.1.2 X editing 32 The nX edit descriptor indicates that the transmission of the next character to or from a record is to 33 occur at the position n characters forward from the current position. 34 273 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 10.24 The n in an nX edit descriptor shall be specified and shall be greater than zero. 10.8.2 Slash editing 1 The slash edit descriptor indicates the end of data transfer to or from the current record. 2 On input from a file connected for sequential or stream access, the remaining portion of the current 3 record is skipped and the file is positioned at the beginning of the next record. This record becomes 4 the current record. On output to a file connected for sequential or stream access, a new empty record 5 is created following the current record; this new record then becomes the last and current record of the 6 file and the file is positioned at the beginning of this new record. 7 For a file connected for direct access, the record number is increased by one and the file is positioned 8 at the beginning of the record that has that record number, if there is such a record, and this record 9 becomes the current record. 10 NOTE 10.25 A record that contains no characters may be written on output. If the file is an internal file or a file connected for direct access, the record is filled with blank characters. An entire record may be skipped on input. The repeat specification is optional in the slash edit descriptor. If it is not specified, the default value is 11 one. 12 10.8.3 Colon editing 13 The colon edit descriptor terminates format control if there are no more effective items in the in- 14 put/output list (9.5.3). The colon edit descriptor has no effect if there are more effective items in the 15 input/output list. 16 10.8.4 SS, SP, and S editing 17 The SS, SP, and S edit descriptors temporarily change (9.4.1) the sign mode (9.4.5.15, 9.5.2.14) for the 18 connection. The edit descriptors SS, SP, and S set the sign mode corresponding to the SIGN= specifier 19 values SUPPRESS, PLUS, and PROCESSOR DEFINED, respectively. 20 The sign mode controls optional plus characters in numeric output fields. When the sign mode is PLUS, 21 the processor shall produce a plus sign in any position that normally contains an optional plus sign. 22 When the sign mode is SUPPRESS, the processor shall not produce a plus sign in such positions. When 23 the sign mode is PROCESSOR DEFINED, the processor has the option of producing a plus sign or not 24 in such positions, subject to 10.7.2(5). 25 The SS, SP, and S edit descriptors affect only I, F, E, EN, ES, D, and G editing during the execution of 26 an output statement. The SS, SP, and S edit descriptors have no effect during the execution of an input 27 statement. 28 10.8.5 P editing 29 The k P edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k . The scale 30 factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities. 31 The scale factor k affects the appropriate editing in the following manner. 32 274 2006/09/25 WORKING DRAFT J3/06-007r1 (1) On input, with F, E, EN, ES, D, and G editing (provided that no exponent exists in the 1 field) and F output editing, the scale factor effect is that the externally represented number 2 equals the internally represented number multiplied by 10k . 3 (2) On input, with F, E, EN, ES, D, and G editing, the scale factor has no effect if there is an 4 exponent in the field. 5 (3) On output, with E and D editing, the significand (R414) part of the quantity to be produced 6 is multiplied by 10k and the exponent is reduced by k. 7 (4) On output, with G editing, the effect of the scale factor is suspended unless the magnitude 8 of the datum to be edited is outside the range that permits the use of F editing. If the use 9 of E editing is required, the scale factor has the same effect as with E output editing. 10 (5) On output, with EN and ES editing, the scale factor has no effect. 11 If UP, DOWN, ZERO, or NEAREST I/O rounding mode is in effect, 12 (1) on input, the scale factor is applied to the external decimal value and then this is converted 13 using the current I/O rounding mode, and 14 (2) on output, the internal value is converted using the current I/O rounding mode and then 15 the scale factor is applied to the converted decimal value. 16 10.8.6 BN and BZ editing 17 The BN and BZ edit descriptors temporarily change (9.4.1) the blank interpretation mode (9.4.5.4, 18 9.5.2.6) for the connection. The edit descriptors BN and BZ set the blank interpretation mode corre- 19 sponding to the BLANK= specifier values NULL and ZERO, respectively. 20 The blank interpretation mode controls the interpretation of nonleading blanks in numeric and bits 21 input fields. Such blank characters are interpreted as zeros when the blank interpretation mode has the 22 value ZERO; they are ignored when the blank interpretation mode has the value NULL. The effect of 23 ignoring blanks is to treat the input field as if blanks had been removed, the remaining portion of the 24 field right justified, and the blanks replaced as leading blanks. However, a field containing only blanks 25 has the value zero. 26 The blank interpretation mode affects only numeric editing, bits editing, generalized numeric editing, 27 and generalized bits editing on input. It has no effect on output. 28 10.8.7 RU, RD, RZ, RN, RC, and RP editing 29 The round edit descriptors temporarily change (9.4.1) the connection's I/O rounding mode (9.4.5.14, 30 9.5.2.13, 10.7.2.3.7). The round edit descriptors RU, RD, RZ, RN, RC, and RP set the I/O rounding 31 mode corresponding to the ROUND= specifier values UP, DOWN, ZERO, NEAREST, COMPATIBLE, 32 and PROCESSOR DEFINED, respectively. The I/O rounding mode affects the conversion of real and 33 complex values in formatted input/output. It affects only D, E, EN, ES, F, and G editing. 34 10.8.8 DC and DP editing 35 The decimal edit descriptors temporarily change (9.4.1) the decimal edit mode (9.4.5.5, 9.5.2.7, 10.6) 36 for the connection. The edit descriptors DC and DP set the decimal edit mode corresponding to the 37 DECIMAL= specifier values COMMA and POINT, respectively. 38 The decimal edit mode controls the representation of the decimal symbol (10.6) during conversion of 39 real and complex values in formatted input/output. The decimal edit mode affects only D, E, EN, ES, 40 F, and G editing. If the mode is COMMA during list-directed input/output, the character used as a 41 value separator is a semicolon in place of a comma. 42 275 J3/06-007r1 WORKING DRAFT 2006/09/25 10.9 Character string edit descriptors 1 A character string edit descriptor shall not be used on input. 2 The character string edit descriptor causes characters to be written from the enclosed characters of the 3 edit descriptor itself, including blanks. For a character string edit descriptor, the width of the field is 4 the number of characters between the delimiting characters. Within the field, two consecutive delimiting 5 characters are counted as a single character. 6 NOTE 10.26 A delimiter for a character string edit descriptor is either an apostrophe or quote. 10.10 List-directed formatting 7 10.10.1 General 8 List-directed input/output allows data editing according to the type of the list item instead of by a 9 format specification. It also allows data to be free-field, that is, separated by commas (or semicolons) 10 or blanks. 11 10.10.2 Values and value separators 12 The characters in one or more list-directed records constitute a sequence of values and value separators. 13 The end of a record has the same effect as a blank character, unless it is within a character constant. Any 14 sequence of two or more consecutive blanks is treated as a single blank, unless it is within a character 15 constant. 16 Each value is either a null value, c, r *c, or r *, where c is a literal constant, optionally signed if integer 17 or real, or an undelimited character constant and r is an unsigned, nonzero, integer literal constant. 18 Neither c nor r shall have kind type parameters specified. The constant c is interpreted as though 19 it had the same kind type parameter as the corresponding list item. The r *c form is equivalent to r 20 successive appearances of the constant c, and the r * form is equivalent to r successive appearances of 21 the null value. Neither of these forms may contain embedded blanks, except where permitted within the 22 constant c. 23 A value separator is 24 (1) a comma optionally preceded by one or more contiguous blanks and optionally followed by 25 one or more contiguous blanks, unless the decimal edit mode is COMMA, in which case a 26 semicolon is used in place of the comma, 27 (2) a slash optionally preceded by one or more contiguous blanks and optionally followed by 28 one or more contiguous blanks, or 29 (3) one or more contiguous blanks between two nonblank values or following the last nonblank 30 value, where a nonblank value is a constant, an r *c form, or an r * form. 31 NOTE 10.27 Although a slash encountered in an input record is referred to as a separator, it actually causes termination of list-directed and namelist input statements; it does not actually separate two values. NOTE 10.28 If no list items are specified in a list-directed input/output statement, one input record is skipped or one empty output record is written. 276 2006/09/25 WORKING DRAFT J3/06-007r1 10.10.3 List-directed input 1 Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting, 2 except as noted below. The form of the input value shall be acceptable for the type of the next effective 3 item in the list. Blanks are never used as zeros, and embedded blanks are not permitted in constants, 4 except within character constants and complex constants as specified below. 5 For the r *c form of an input value, the constant c is interpreted as an undelimited character constant 6 if the first list item corresponding to this value is of type default, ASCII, or ISO 10646 character, there 7 is a nonblank character immediately after r *, and that character is not an apostrophe or a quotation 8 mark; otherwise, c is interpreted as a literal constant. 9 NOTE 10.29 The end of a record has the effect of a blank, except when it appears within a character constant. When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 10 edit descriptor with a suitable value of w were used. 11 When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 12 descriptor with a suitable value of w were used. 13 When the next effective item is of type real, the input form is that of a numeric input field. A numeric 14 input field is a field suitable for F editing (10.7.2.3.2) that is assumed to have no fractional digits unless 15 a decimal symbol appears within the field. 16 When the next effective item is of type complex, the input form consists of a left parenthesis followed by 17 an ordered pair of numeric input fields separated by a comma (if the decimal edit mode is POINT) or 18 semicolon (if the decimal edit mode is COMMA), and followed by a right parenthesis. The first numeric 19 input field is the real part of the complex constant and the second is the imaginary part. Each of the 20 numeric input fields may be preceded or followed by any number of blanks and ends of records. The end 21 of a record may occur after the real part or before the imaginary part. 22 When the next effective item is of type logical, the input form shall not include value separators among 23 the optional characters permitted for L editing. 24 When the next effective item is of type character, the input form consists of a possibly delimited sequence 25 of zero or more rep-char s whose kind type parameter is implied by the kind of the effective list item. 26 Character sequences may be continued from the end of one record to the beginning of the next record, 27 but the end of record shall not occur between a doubled apostrophe in an apostrophe-delimited character 28 sequence, nor between a doubled quote in a quote-delimited character sequence. The end of the record 29 does not cause a blank or any other character to become part of the character sequence. The character 30 sequence may be continued on as many records as needed. The characters blank, comma, semicolon, 31 and slash may appear in default, ASCII, or ISO 10646 character sequences. 32 If the next effective item is of type default, ASCII, or ISO 10646 character and 33 (1) the character sequence does not contain value separators, 34 (2) the character sequence does not cross a record boundary, 35 (3) the first nonblank character is not a quotation mark or an apostrophe, 36 (4) the leading characters are not digits followed by an asterisk, and 37 (5) the character sequence contains at least one character, 38 the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the 39 character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), 40 semicolon (if the decimal edit mode is COMMA), slash, or end of record; in this case apostrophes and 41 quotation marks within the datum are not to be doubled. 277 J3/06-007r1 WORKING DRAFT 2006/09/25 Let len be the length of the next effective item, and let w be the length of the character sequence. If 1 len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 2 effective item. If len is greater than w, the sequence is transmitted to the leftmost w characters of the 3 next effective item and the remaining len-w characters of the next effective item are filled with blanks. 4 The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment 5 statement (7.4.1.3). 6 10.10.3.1 Null values 7 A null value is specified by 8 (1) the r * form, 9 (2) no characters between consecutive value separators, or 10 (3) no characters before the first value separator in the first record read by each execution of a 11 list-directed input statement. 12 NOTE 10.30 The end of a record following any other value separator, with or without separating blanks, does not specify a null value in list-directed input. A null value has no effect on the definition status of the next effective item. A null value shall not be 13 used for either the real or imaginary part of a complex constant, but a single null value may represent 14 an entire complex constant. 15 A slash encountered as a value separator during execution of a list-directed input statement causes 16 termination of execution of that input statement after the transference of the previous value. Any 17 characters remaining in the current record are ignored. If there are additional items in the input list, the 18 effect is as if null values had been supplied for them. Any do-variable in the input list becomes defined 19 as if enough null values had been supplied for any remaining input list items. 20 NOTE 10.31 All blanks in a list-directed input record are considered to be part of some value separator except for (1) blanks embedded in a character sequence, (2) embedded blanks surrounding the real or imaginary part of a complex constant, and (3) leading blanks in the first record read by each execution of a list-directed input state- ment, unless immediately followed by a slash or comma. NOTE 10.32 List-directed input example: INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G ... READ *, I, X, P, Z, G ... The input data records are: 12345,12345,,2*1.5,4* ISN'T_BOB'S,(123,0),.TEXAS$ 278 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 10.32 (cont.) The results are: Variable Value I 12345 X (1) 12345.0 X (2) unchanged X (3) 1.5 X (4) 1.5 X (5) ­ X (8) unchanged P ISN'T BOB'S Z (123.0,0.0) G true 10.10.4 List-directed output 1 The form of the values produced is the same as that required for input, except as noted otherwise. With 2 the exception of adjacent undelimited character sequences, the values are separated by one or more 3 blanks or by a comma, or a semicolon if the decimal edit mode is comma, optionally preceded by one or 4 more blanks and optionally followed by one or more blanks. 5 The processor may begin new records as necessary, but the end of record shall not occur within a constant 6 except as specified for complex constants and character sequences. The processor shall not insert blanks 7 within character sequences or within constants, except as specified for complex constants. 8 Logical output values are T for the value true and F for the value false. 9 Integer output constants are produced with the effect of an Iw edit descriptor. 10 Bits output constants are produced with the effect of a Zw .m edit descriptor with w and m equal to 11 CEILING(k/4.0) where k is the kind type parameter value of the list item. 12 Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, 13 depending on the magnitude x of the value and a range 10d1 x < 10d2 , where d1 and d2 are processor- 14 dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 15 0PFw.d ; otherwise, 1PEw.d Ee is used. 16 For numeric output, reasonable processor-dependent values of w , d , and e are used for each of the 17 numeric constants output. 18 Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, 19 each produced as defined above for real constants. The separator is a comma if the decimal edit mode is 20 POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between 21 the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire 22 record. The only embedded blanks permitted within a complex constant are between the separator and 23 the end of a record and one blank at the beginning of the next record. 24 Character sequences produced when the delimiter mode has a value of NONE 25 (1) are not delimited by apostrophes or quotation marks, 26 (2) are not separated from each other by value separators, 27 (3) have each internal apostrophe or quotation mark represented externally by one apostrophe 28 or quotation mark, and 29 (4) have a blank character inserted by the processor at the beginning of any record that begins 30 with the continuation of a character sequence from the preceding record. 31 279 J3/06-007r1 WORKING DRAFT 2006/09/25 Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, 1 are preceded and followed by a value separator, and have each internal quote represented on the external 2 medium by two contiguous quotes. 3 Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited 4 by apostrophes, are preceded and followed by a value separator, and have each internal apostrophe 5 represented on the external medium by two contiguous apostrophes. 6 If two or more successive values in an output record have identical values, the processor has the option 7 of producing a repeated constant of the form r *c instead of the sequence of identical values. 8 Slashes, as value separators, and null values are not produced as output by list-directed formatting. 9 Except for continuation of delimited character sequences, each output record begins with a blank char- 10 acter. 11 NOTE 10.33 The length of the output records is not specified and may be processor dependent. 10.11 Namelist formatting 12 10.11.1 General 13 Namelist input/output allows data editing with NAME=value subsequences. This facilitates documen- 14 tation of input and output files and more flexibility on input. 15 10.11.2 Name-value subsequences 16 The characters in one or more namelist records constitute a sequence of name-value subsequences, 17 each of which consists of an object designator followed by an equals and followed by one or more values 18 and value separators. The equals may optionally be preceded or followed by one or more contiguous 19 blanks. The end of a record has the same effect as a blank character, unless it is within a character 20 constant. Any sequence of two or more consecutive blanks is treated as a single blank, unless it is within 21 a character constant. 22 The name may be any name in the namelist-group-object-list (5.6). 23 A value separator for namelist formatting is the same as for list-directed formatting (10.10). 24 10.11.3 Namelist input 25 Input for a namelist input statement consists of 26 (1) optional blanks and namelist comments, 27 (2) the character & followed immediately by the namelist-group-name as specified in the NAME- 28 LIST statement, 29 (3) one or more blanks, 30 (4) a sequence of zero or more name-value subsequences separated by value separators, and 31 (5) a slash to terminate the namelist input. 32 NOTE 10.34 A slash encountered in a namelist input record causes the input statement to terminate. A slash cannot be used to separate two values in a namelist input statement. 280 2006/09/25 WORKING DRAFT J3/06-007r1 In each name-value subsequence, the name shall be the name of a namelist group object list item with 1 an optional qualification and the name with the optional qualification shall not be a zero-sized array, a 2 zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not 3 contain a vector subscript. 4 A group name or object name is without regard to case. 5 10.11.3.1 Namelist group object names 6 Within the input data, each name shall correspond to a particular namelist group object name. Sub- 7 scripts, strides, and substring range expressions used to qualify group object names shall be optionally 8 signed integer literal constants with no kind type parameters specified. If a namelist group object is 9 an array, the input record corresponding to it may contain either the array name or the designator of 10 a subobject of that array, using the syntax of object designators (R603). If the namelist group object 11 name is the name of a variable of derived type, the name in the input record may be either the name of 12 the variable or the designator of one of its components, indicated by qualifying the variable name with 13 the appropriate component name. Successive qualifications may be applied as appropriate to the shape 14 and type of the variable represented. 15 The order of names in the input records need not match the order of the namelist group object items. 16 The input records need not contain all the names of the namelist group object items. The definition 17 status of any names from the namelist-group-object-list that do not occur in the input record remains 18 unchanged. In the input record, each object name or subobject designator may be preceded and followed 19 by one or more optional blanks but shall not contain embedded blanks. 20 10.11.3.2 Namelist group object list items 21 The name-value subsequences are evaluated serially, in left-to-right order. A namelist group object 22 designator may appear in more than one name-value sequence. 23 When the name in the input record represents an array variable or a variable of derived type, the effect 24 is as if the variable represented were expanded into a sequence of scalar list items, in the same way that 25 formatted input/output list items are expanded (9.5.3). Each input value following the equals shall then 26 be acceptable to format specifications for the type of the list item in the corresponding position in the 27 expanded sequence, except as noted in this subclause. The number of values following the equals shall 28 not exceed the number of list items in the expanded sequence, but may be less; in the latter case, the 29 effect is as if sufficient null values had been appended to match any remaining list items in the expanded 30 sequence. 31 NOTE 10.35 For example, if the name in the input record is the name of an integer array of size 100, at most 100 values, each of which is either a digit string or a null value, may follow the equals; these values would then be assigned to the elements of the array in array element order. A slash encountered as a value separator during the execution of a namelist input statement causes 32 termination of execution of that input statement after transference of the previous value. If there are 33 additional items in the namelist group object being transferred, the effect is as if null values had been 34 supplied for them. 35 A namelist comment may appear after any value separator except a slash. A namelist comment is also 36 permitted to start in the first nonblank position of an input record except within a character literal 37 constant. 38 Successive namelist records are read by namelist input until a slash is encountered; the remainder of the 39 record is ignored and need not follow the rules for namelist input values. 40 281 J3/06-007r1 WORKING DRAFT 2006/09/25 10.11.3.3 Namelist input values 1 Each value is either a null value (10.11.3.4), c, r *c, or r *, where c is a literal constant, optionally signed 2 if integer or real, and r is an unsigned, nonzero, integer literal constant. A kind type parameter shall not 3 be specified for c or r. The constant c is interpreted as though it had the same kind type parameter as 4 the corresponding effective item. The r *c form is equivalent to r successive appearances of the constant 5 c, and the r * form is equivalent to r successive null values. Neither of these forms may contain embedded 6 blanks, except where permitted within the constant c. 7 The datum c (10.11) is any input value acceptable to format specifications for a given type, except for 8 a restriction on the form of input values corresponding to list items of types logical, integer, bits, and 9 character as specified in this subclause. The form of a real or complex value is dependent on the decimal 10 edit mode in effect (10.6). The form of an input value shall be acceptable for the type of the namelist 11 group object list item. The number and forms of the input values that may follow the equals in a name- 12 value subsequence depend on the shape and type of the object represented by the name in the input 13 record. When the name in the input record is that of a scalar variable of an intrinsic type, the equals 14 shall not be followed by more than one value. Blanks are never used as zeros, and embedded blanks are 15 not permitted in constants except within character constants and complex constants as specified in this 16 subclause. 17 When the next effective namelist group object list item is of type real, the input form of the input value 18 is that of a numeric input field. A numeric input field is a field suitable for F editing (10.7.2.3.2) that is 19 assumed to have no fractional digits unless a decimal symbol appears within the field. 20 When the next effective item is of type complex, the input form of the input value consists of a left 21 parenthesis followed by an ordered pair of numeric input fields separated by a comma (if the decimal 22 edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA), and followed by a right 23 parenthesis. The first numeric input field is the real part of the complex constant and the second part 24 is the imaginary part. Each of the numeric input fields may be preceded or followed by any number of 25 blanks and ends of records. The end of a record may occur between the real part and the comma or 26 semicolon, or between the comma or semicolon and the imaginary part. 27 When the next effective item is of type logical, the input form of the input value shall not include equals 28 or value separators among the optional characters permitted for L editing (10.7.3). 29 When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 30 edit descriptor with a suitable value of w were used. 31 When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 32 descriptor with a suitable value of w were used. 33 When the next effective item is of type character, the input form consists of a delimited sequence of zero 34 or more rep-char s whose kind type parameter is implied by the kind of the corresponding list item. Such 35 a sequence may be continued from the end of one record to the beginning of the next record, but the 36 end of record shall not occur between a doubled apostrophe in an apostrophe-delimited sequence, nor 37 between a doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or 38 any other character to become part of the sequence. The sequence may be continued on as many records 39 as needed. The characters blank, comma, semicolon, and slash may appear in such character sequences. 40 NOTE 10.36 A character sequence corresponding to a namelist input item of character type shall be delimited either with apostrophes or with quotes. The delimiter is required to avoid ambiguity between undelimited character sequences and object names. The value of the DELIM= specifier, if any, in the OPEN statement for an external file is ignored during namelist input (9.4.5.6). 282 2006/09/25 WORKING DRAFT J3/06-007r1 Let len be the length of the next effective item, and let w be the length of the character sequence. If 1 len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 2 effective item. If len is greater than w, the constant is transmitted to the leftmost w characters of the 3 next effective item and the remaining len-w characters of the next effective item are filled with blanks. 4 The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment 5 statement (7.4.1.3). 6 10.11.3.4 Null values 7 A null value is specified by 8 (1) the r * form, 9 (2) blanks between two consecutive nonblank value separators following an equals, 10 (3) zero or more blanks preceding the first value separator and following an equals, or 11 (4) two consecutive nonblank value separators. 12 A null value has no effect on the definition status of the corresponding input list item. If the namelist 13 group object list item is defined, it retains its previous value; if it is undefined, it remains undefined. A 14 null value shall not be used as either the real or imaginary part of a complex constant, but a single null 15 value may represent an entire complex constant. 16 NOTE 10.37 The end of a record following a value separator, with or without intervening blanks, does not specify a null value in namelist input. 10.11.3.5 Blanks 17 All blanks in a namelist input record are considered to be part of some value separator except for 18 (1) blanks embedded in a character constant, 19 (2) embedded blanks surrounding the real or imaginary part of a complex constant, 20 (3) leading blanks following the equals unless followed immediately by a slash or comma, or a 21 semicolon if the decimal edit mode is comma, and 22 (4) blanks between a name and the following equals. 23 10.11.3.6 Namelist Comments 24 Except within a character literal constant, a "!" character after a value separator or in the first nonblank 25 position of a namelist input record initiates a comment. The comment extends to the end of the current 26 input record and may contain any graphic character in the processor-dependent character set. The 27 comment is ignored. A slash within the namelist comment does not terminate execution of the namelist 28 input statement. Namelist comments are not allowed in stream input because comments depend on 29 record structure. 30 NOTE 10.38 Namelist input example: INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G NAMELIST / TODAY / G, I, P, Z, X READ (*, NML = TODAY) The input data records are: 283 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 10.38 (cont.) &TODAY I = 12345, X(1) = 12345, X(3:4) = 2*1.5, I=6, ! This is a comment. P = ''ISN'T_BOB'S'', Z = (123,0)/ The results stored are: Variable Value I 6 X (1) 12345.0 X (2) unchanged X (3) 1.5 X (4) 1.5 X (5) ­ X (8) unchanged P ISN'T BOB'S Z (123.0,0.0) G unchanged 10.11.4 Namelist output 1 The form of the output produced is the same as that required for input, except for the forms of real, 2 character, and logical values. The name in the output is in upper case. With the exception of adjacent 3 undelimited character values, the values are separated by one or more blanks or by a comma, or a 4 semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and optionally 5 followed by one or more blanks. 6 Namelist output shall not include namelist comments. 7 The processor may begin new records as necessary. However, except for complex constants and character 8 values, the end of a record shall not occur within a constant, character value, or name, and blanks shall 9 not appear within a constant, character value, or name. 10 NOTE 10.39 The length of the output records is not specified exactly and may be processor dependent. 10.11.4.1 Namelist output editing 11 Values in namelist output records are edited as for list-directed output (10.10.4). 12 NOTE 10.40 Namelist output records produced with a DELIM= specifier with a value of NONE and which contain a character sequence might not be acceptable as namelist input records. 10.11.4.2 Namelist output records 13 If two or more successive values for the same namelist group item in an output record produced have 14 identical values, the processor has the option of producing a repeated constant of the form r *c instead 15 of the sequence of identical values. 16 The name of each namelist group object list item is placed in the output record followed by an equals 17 and a list of values of the namelist group object list item. 18 An ampersand character followed immediately by a namelist-group-name will be produced by namelist 19 formatting at the start of the first output record to indicate which particular group of data objects is 20 being output. A slash is produced by namelist formatting to indicate the end of the namelist formatting. 284 2006/09/25 WORKING DRAFT J3/06-007r1 A null value is not produced by namelist formatting. 1 Except for new records created by explicit formatting within a user-defined derived-type output pro- 2 cedure or by continuation of delimited character sequences, each output record begins with a blank 3 character. 4 285 J3/06-007r1 WORKING DRAFT 2006/09/25 286 2006/09/25 WORKING DRAFT J3/06-007r1 11 Program units 1 11.1 Main program 2 A Fortran main program is a program unit that does not contain a SUBROUTINE, FUNCTION, 3 MODULE, SUBMODULE, or BLOCK DATA statement as its first statement. 4 R1101 main-program is [ program-stmt ] 5 [ specification-part ] 6 [ execution-part ] 7 [ internal-subprogram-part ] 8 end-program-stmt 9 R1102 program-stmt is PROGRAM program-name 10 R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] 11 C1101 (R1101) In a main-program, the execution-part shall not contain a RETURN statement or an 12 ENTRY statement. 13 C1102 (R1101) The program-name may be included in the end-program-stmt only if the optional 14 program-stmt is used and, if included, shall be identical to the program-name specified in the 15 program-stmt. 16 NOTE 11.1 The program name is global to the program (16.2). For explanatory information about uses for the program name, see subclause C.8.1. NOTE 11.2 An example of a main program is: PROGRAM ANALYZE REAL A, B, C (10,10) ! Specification part CALL FIND ! Execution part CONTAINS SUBROUTINE FIND ! Internal subprogram ... END SUBROUTINE FIND END PROGRAM ANALYZE The main program may be defined by means other than Fortran; in that case, the program shall not 17 contain a main-program program unit. 18 A reference to a Fortran main-program shall not appear in any program unit in the program, including 19 itself. 20 11.2 Modules 21 287 J3/06-007r1 WORKING DRAFT 2006/09/25 11.2.1 General 1 A module contains specifications and definitions that are to be accessible to other program units by use 2 association. A module that is provided as an inherent part of the processor is an intrinsic module. A 3 nonintrinsic module is defined by a module program unit or a means other than Fortran. 4 Procedures and types defined in an intrinsic module are not themselves intrinsic. 5 R1104 module is module-stmt 6 [ specification-part ] 7 [ module-subprogram-part ] 8 end-module-stmt 9 R1105 module-stmt is MODULE module-name 10 R1106 end-module-stmt is END [ MODULE [ module-name ] ] 11 R1107 module-subprogram-part is contains-stmt 12 [ module-subprogram ] ... 13 R1108 module-subprogram is function-subprogram 14 or subroutine-subprogram 15 or separate-module-subprogram 16 C1103 (R1104) If the module-name is specified in the end-module-stmt, it shall be identical to the 17 module-name specified in the module-stmt. 18 C1104 (R1104) A module specification-part shall not contain an entry-stmt, or a 19 a stmt-function-stmt, format-stmt. 20 C1105 (R1104) If an object that has a default-initialized direct component is declared in the specification- 21 part of a module it shall have the ALLOCATABLE, POINTER, or SAVE attribute. 22 C1106 If an object that has a co-array ultimate component is declared in the specification-part of a 23 module it shall have the SAVE attribute. 24 J3 internal note Unresolved Technical Issue 010 This is better, but still inconsistent. After 06-238r1, top-level allocatable co-arrays are allowed in a module without being SAVEd. Allow that but requiring SAVE for things with co-array components does not make sense. 06-238r1 claims "save is required for a module variable if it has a co-array component. We wish to retain this since otherwise an unexpected implicit synchronization would be needed whenever the module ceases to be active." Why would that be unexpected? I would expect that when the module goes out of scope, the allocatable (co-array thingo) either remains (as is allowed) or is deallocated (as is allowed), with only the latter case requiring (implicit) synchronisation. NOTE 11.3 The module name is global to the program (16.2). NOTE 11.4 Although statement function definitions, ENTRY statements, and FORMAT statements shall not appear in the specification part of a module, they may appear in the specification part of a module subprogram in the module. NOTE 11.5 For a discussion of the impact of modules on dependent compilation, see subclause C.8.2. 288 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 11.6 For examples of the use of modules, see subclause C.8.3. If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the 1 EXTERNAL attribute in that scoping unit; if it is a function, its type and type parameters shall be 2 explicitly declared in a type declaration statement in that scoping unit. 3 If an intrinsic procedure is declared in the scoping unit of a module, it shall explicitly be given the 4 INTRINSIC attribute in that scoping unit or be used as an intrinsic procedure in that scoping unit. 5 11.2.2 The USE statement and use association 6 The USE statement specifies use association. A USE statement is a module reference to the module 7 it specifies. At the time a USE statement is processed, the public portions of the specified module shall 8 be available. A module shall not reference itself, either directly or indirectly. A submodule shall not 9 reference its ancestor module by use association, either directly or indirectly. 10 NOTE 11.7 It is possible for submodules with different ancestor modules to reference each others' ancestor modules by use association. The USE statement provides the means by which a scoping unit accesses named data objects, derived 11 types, interface blocks, procedures, abstract interfaces, module procedure interfaces, generic identifiers, 12 macros, and namelist groups in a module. The entities in the scoping unit are use associated with the 13 entities in the module. The accessed entities have the attributes specified in the module, except that an 14 entity may have a different accessibility attribute or it may have the ASYNCHRONOUS or VOLATILE 15 attribute in the local scoping unit even if the associated module entity does not. The entities made 16 accessible are identified by the names or generic identifiers used to identify them in the module. By 17 default, they are identified by the same identifiers in the scoping unit containing the USE statement, 18 but it is possible to specify that different local identifiers are used. 19 NOTE 11.8 The accessibility of module entities may be controlled by accessibility attributes (4.5.2.2, 5.3.2), and the ONLY option of the USE statement. Definability of module entities can be controlled by the PROTECTED attribute (5.3.14). R1109 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename-list ] 20 or USE [ [ , module-nature ] :: ] module-name , 21 ONLY : [ only-list ] 22 R1110 module-nature is INTRINSIC 23 or NON INTRINSIC 24 R1111 rename is local-name => use-name 25 or OPERATOR (local-defined-operator ) => 26 OPERATOR (use-defined-operator ) 27 R1112 only is generic-spec 28 or only-use-name 29 or rename 30 R1113 only-use-name is use-name 31 C1107 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. 32 C1108 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic 33 module. 34 289 J3/06-007r1 WORKING DRAFT 2006/09/25 C1109 (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the 1 same name. 2 C1110 (R1111) OPERATOR(use-defined-operator ) shall not identify a generic-binding. 3 C1111 (R1112) The generic-spec shall not identify a generic-binding. 4 NOTE 11.9 The above two constraints do not prevent accessing a generic-spec that is declared by an interface block, even if a generic-binding has the same generic-spec. C1112 (R1112) Each generic-spec shall be a public entity in the module. 5 C1113 (R1113) Each use-name shall be the name of a public entity in the module. 6 R1114 local-defined-operator is defined-unary-op 7 or defined-binary-op 8 R1115 use-defined-operator is defined-unary-op 9 or defined-binary-op 10 C1114 (R1115) Each use-defined-operator shall be a public entity in the module. 11 A use-stmt without a module-nature provides access either to an intrinsic or to a nonintrinsic module. 12 If the module-name is the name of both an intrinsic and a nonintrinsic module, the nonintrinsic module 13 is accessed. 14 The USE statement without the ONLY option provides access to all public entities in the specified 15 module. 16 A USE statement with the ONLY option provides access only to those entities that appear as generic- 17 specs, use-names, or use-defined-operator s in the only-list. 18 More than one USE statement for a given module may appear in a scoping unit. If one of the USE 19 statements is without an ONLY option, all public entities in the module are accessible. If all the USE 20 statements have ONLY options, only those entities in one or more of the only-lists are accessible. 21 An accessible entity in the referenced module has one or more local identifiers. These identifiers are 22 (1) the identifier of the entity in the referenced module if that identifier appears as an only-use- 23 name or as the defined-operator of a generic-spec in any only for that module, 24 (2) each of the local-names or local-defined-operator s that the entity is given in any rename for 25 that module, and 26 (3) the identifier of the entity in the referenced module if that identifier does not appear as a 27 use-name or use-defined-operator in any rename for that module. 28 Two or more accessible entities, other than generic interfaces or defined operators, may have the same 29 identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces 30 and defined operators are handled as described in 12.4.3.3 and 12.4.3.3.4. Except for these cases, the 31 local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers 32 of all other entities accessible to the scoping unit through USE statements and otherwise. 33 NOTE 11.10 There is no prohibition against a use-name or use-defined-operator appearing multiple times in one USE statement or in multiple USE statements involving the same module. As a result, it is possible for one use-associated entity to be accessible by more than one local identifier. 290 2006/09/25 WORKING DRAFT J3/06-007r1 The local identifier of an entity made accessible by a USE statement shall not appear in any other 1 nonexecutable statement that would cause any attribute (5.3) of the entity to be specified in the scoping 2 unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE statement 3 in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE attribute. 4 The appearance of such a local identifier in a PUBLIC statement in a module causes the entity accessible 5 by the USE statement to be a public entity of that module. If the identifier appears in a PRIVATE 6 statement in a module, the entity is not a public entity of that module. If the local identifier does not 7 appear in either a PUBLIC or PRIVATE statement, it assumes the default accessibility attribute (5.4.1) 8 of that scoping unit. 9 NOTE 11.11 The constraints in subclauses 5.7.1, 5.7.2, and 5.6 prohibit the local-name from appearing as a common-block-object in a COMMON statement, an equivalence-object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST statement, respectively. There is no prohi- bition against the local-name appearing as a common-block-name or a namelist-group-object. NOTE 11.12 For a discussion of the impact of the ONLY option and renaming on dependent compilation, see subclause C.8.2.1. NOTE 11.13 Examples: USE STATS_LIB provides access to all public entities in the module STATS LIB. USE MATH_LIB; USE STATS_LIB, SPROD => PROD makes all public entities in both MATH LIB and STATS LIB accessible. If MATH LIB contains an entity called PROD, it is accessible by its own name while the entity PROD of STATS LIB is accessible by the name SPROD. USE STATS_LIB, ONLY: YPROD; USE STATS_LIB, ONLY : PROD makes public entities YPROD and PROD in STATS LIB accessible. USE STATS_LIB, ONLY : YPROD; USE STATS_LIB makes all public entities in STATS LIB accessible. 11.2.3 Submodules 10 A submodule is a program unit that extends a module or another submodule. The program unit that 11 it extends is its parent, and is specified by the parent-identifier in the submodule-stmt. A submodule 12 is a child of its parent. An ancestor of a submodule is its parent or an ancestor of its parent. A 13 descendant of a module or submodule is one of its children or a descendant of one of its children. The 14 submodule identifier is the ordered pair whose first element is the ancestor module name and whose 15 second element is the submodule name. 16 291 J3/06-007r1 WORKING DRAFT 2006/09/25 NOTE 11.14 A module and its submodules stand in a tree-like relationship one to another, with the module at the root. Therefore, a submodule has exactly one ancestor module and may optionally have one or more ancestor submodules. A submodule accesses the scoping unit of its parent by host association (16.5.1.4). 1 A submodule may provide implementations for module procedures, each of which is declared by a module 2 procedure interface body (12.4.3.2) within that submodule or one of its ancestors, and declarations and 3 definitions of other entities that are accessible by host association in its descendants. 4 R1116 submodule is submodule-stmt 5 [ specification-part ] 6 [ module-subprogram-part ] 7 end-submodule-stmt 8 R1117 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name 9 R1118 parent-identifier is ancestor-module-name [ : parent-submodule-name ] 10 R1119 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ] 11 C1115 (R1116) A submodule specification-part shall not contain a format-stmt, entry-stmt, 12 or stmt- function-stmt. 13 C1116 (R1116) An object with a default-initialized direct component that is declared in the specification- 14 part of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. 15 C1117 (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- 16 submodule-name shall be the name of a descendant of that module. 17 C1118 (R1116) If a submodule-name appears in the end-submodule-stmt, it shall be identical to the one 18 in the submodule-stmt. 19 11.3 Block data program units 20 A block data program unit is used to provide initial values for data objects in named common blocks. 21 R1120 block-data is block-data-stmt 22 [ specification-part ] 23 end-block-data-stmt 24 R1121 block-data-stmt is BLOCK DATA [ block-data-name ] 25 R1122 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ] 26 C1119 (R1120) The block-data-name shall be included in the end-block-data-stmt only if it was provided 27 in the block-data-stmt and, if included, shall be identical to the block-data-name in the block- 28 data-stmt. 29 C1120 (R1120) A block-data specification-part shall contain only derived-type definitions and ASYN- 30 CHRONOUS, BIND, COMMON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRIN- 31 SIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration 32 statements. 33 C1121 (R1120) A type declaration statement in a block-data specification-part shall not contain AL- 34 LOCATABLE, EXTERNAL, or BIND attribute specifiers. 35 292 2006/09/25 WORKING DRAFT J3/06-007r1 NOTE 11.15 For explanatory information about the uses for the block-data-name, see subclause C.8.1. If an object in a named common block is initially defined, all storage units in the common block storage 1 sequence shall be specified even if they are not all initially defined. More than one named common block 2 may have objects initially defined in a single block data program unit. 3 NOTE 11.16 In the example BLOCK DATA INIT REAL A, B, C, D, E, F COMMON /BLOCK1/ A, B, C, D DATA A /1.2/, C /2.3/ COMMON /BLOCK2/ E, F DATA F /6.5/ END BLOCK DATA INIT common blocks BLOCK1 and BLOCK2 both have objects that are being initialized in a single block data program unit. B, D, and E are not initialized but they need to be specified as part of the common blocks. Only an object in a named common block may be initially defined in a block data program unit. 4 NOTE 11.17 Objects associated with an object in a common block are considered to be in that common block. The same named common block shall not be specified in more than one block data program unit in a 5 program. 6 There shall not be more than one unnamed block data program unit in a program. 7 NOTE 11.18 An example of a block data program unit is: BLOCK DATA WORK COMMON /WRKCOM/ A, B, C (10, 10) REAL :: A, B, C DATA A /1.0/, B /2.0/, C /100 * 0.0/ END BLOCK DATA WORK 293 J3/06-007r1 WORKING DRAFT 2006/09/25 294 2006/09/25 WORKING DRAFT J3/06-007r1 12 Procedures 1 12.1 Concepts 2 The concept of a procedure was introduced in 2.2.4. This clause contains a complete description of 3 procedures. The actions specified by a procedure are performed when the procedure is invoked by 4 execution of a reference to it. 5 The sequence of actions encapsulated by a procedure has access to entities in the invoking scoping 6 unit by way of argument association (12.5.2). A dummy argument is a name that appears in the 7 SUBROUTINE, FUNCTION, or ENTRY statement in the declaration of a procedure (R1235). Dummy 8 arguments are also specified for intrinsic procedures and procedures in intrinsic modules in Clauses 13, 9 14, and 15. 10 The entities in the invoking scoping unit are specified by actual arguments. An actual argument is an 11 entity that appears in a procedure reference (R1223). 12 A procedure may also have access to entities in other scoping units, not necessarily the invoking scoping 13 unit, by use association (16.5.1.3), host association (16.5.1.4), linkage association (16.5.1.5), storage 14 association (16.5.3), or by reference to external procedures (5.3.8). 15 12.2 Procedure classifications 16 12.2.1 Procedure classification by reference 17 The definition of a procedure specifies it to be a function or a subroutine. A reference to a function 18 either appears explicitly as a primary within an expression, or is implied by a defined operation (7.1.3) 19 within an expression. A reference to a subroutine is a CALL statement, a defined assignment statement 20 (7.4.1.4), the appearance of an object processed by user-defined derived-type input/output (9.5.4.7) in 21 an input/output list, or finalization (4.5.6). 22 A procedure is classified as elemental if it is a procedure that may be referenced elementally (12.8). 23 12.2.2 Procedure classification by means of definition 24 12.2.2.1 Intrinsic procedures 25 A procedure that is provided as an inherent part of the processor is an intrinsic procedure. 26 12.2.2.2 External, internal, and module procedures 27 An external procedure is a procedure that is defined by an external subprogram or by a means other 28 than Fortran. 29 An internal procedure is a procedure that is defined by an internal subprogram. Internal subprograms 30 may appear in the main program, in an external subprogram, or in a module subprogram. Internal 31 subprograms shall not appear in other internal subprograms. Internal subprograms are the same as 32 external subprograms except that the name of the internal procedure is not a global identifier, an 33 internal subprogram shall not contain an ENTRY statement, and the internal subprogram has access to 34 host entities by host association. 35 295 J3/06-007r1 WORKING DRAFT 2006/09/25 A module procedure is a procedure that is defined by a module subprogram. 1 A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement. If the subprogram 2 has one or more ENTRY statements, it also defines a procedure for each of them. 3 12.2.2.3 Dummy procedures 4 A dummy argument that is specified to be a procedure or appears in a procedure reference is a dummy 5 procedure. A dummy procedure with the POINTER attribute is a dummy procedure pointer. 6 12.2.2.4 Procedure pointers 7 A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes; it may be 8 pointer associated with an external procedure, a module procedure, an intrinsic procedure, or a dummy 9 procedure that is not a procedure pointer. 10 12.2.2.5 Statement functions 11 A function that is defined by a single statement is a statement function (12.6.4). 12 12.3 Characteristics 13 12.3.1 Characteristics of procedures 14 The characteristics of a procedure are the classification of the procedure as a function or subroutine, 15 whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its 16 dummy arguments, and the characteristics of its result value if it is a function. 17 12.3.2 Characteristics of dummy arguments 18 12.3.2.1 General 19 Each dummy argument has the characteristic that it is a dummy data object, a dummy procedure, a 20 dummy procedure pointer, or an asterisk (alternate return indicator). A dummy argument other than an asterisk 21 may be specified to have the OPTIONAL attribute. This attribute means that the dummy argument 22 need not be associated with an actual argument for any particular reference to the procedure. 23 12.3.2.2 Characteristics of dummy data objects 24 The characteristics of a dummy data object are its type, its type parameters (if any), its shape, its intent 25 (5.3.9, 5.4.8), whether it is optional (5.3.11, 5.4.9), whether it is allocatable (5.3.7.4), whether it has the 26 ASYNCHRONOUS (5.3.4), CONTIGUOUS (5.3.6), VALUE (5.3.17), or VOLATILE (5.3.18) attributes, 27 whether it is polymorphic, and whether it is a pointer (5.3.13, 5.4.11) or a target (5.3.16, 5.4.14). If 28 a type parameter of an object or a bound of an array is not an initialization expression, the exact 29 dependence on the entities in the expression is a characteristic. If a shape, size, or type parameter is 30 assumed or deferred, it is a characteristic. 31 12.3.2.3 Characteristics of dummy procedures and dummy procedure pointers 32 The characteristics of a dummy procedure are the explicitness of its interface (12.4.2), its characteristics 33 as a procedure if the interface is explicit, whether it is a pointer, and whether it is optional (5.3.11, 5.4.9). 34 12.3.2.4 Characteristics of asterisk dummy arguments 35 An asterisk as a dummy argument has no characteristics. 36 296 2006/09/25 WORKING DRAFT J3/06-007r1 12.3.3 Characteristics of function results 1 The characteristics of a function result are its type, type parameters (if any), rank, whether it is poly- 2 morphic, whether it is allocatable, whether it is a pointer, whether it has the CONTIGUOUS attribute, 3 and whether it is a procedure pointer. If a function result is an array that is not allocatable or a pointer, 4 its shape is a characteristic. If a type parameter of a function result or a bound of a function result 5 array is not an initialization expression, the exact dependence on the entities in the expression is a 6 characteristic. If type parameters of a function result are deferred, which parameters are deferred is a 7 characteristic. If the length of a character function result is assumed, this is a characteristic. 8 12.4 Procedure interface 9 12.4.1 General 10 The interface of a procedure determines the forms of reference through which it may be invoked. 11 The procedure's interface consists of its abstract interface, its name, its binding label if any, and the 12 procedure's generic identifiers, if any. The characteristics of a procedure are fixed, but the remainder 13 of the interface may differ in different scoping units, except that for a separate module procedure body 14 (12.6.2.4), the dummy argument names, binding label, and whether it is recursive shall be the same a