WORKING DRAFT J3/07-007 5th January 2007 18:42 This is an internal working document of J3. 2006/01/05 WORKING DRAFT J3/07-007 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.6 Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1 Statement classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 i J3/07-007 WORKING DRAFT 2006/01/05 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5 Macro processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5.1 Macro definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5.2 Macro expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.1 Type specifiers and type compatibility . . . . . . . . . . . . . . . . . . . . . . . 45 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.1 Classification and specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.2 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.3 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.4 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.5 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.6 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.7 Bits type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 ii 2006/01/05 WORKING DRAFT J3/07-007 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.1 Derived type concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.2 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.3 Derived-type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.5.5 Type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5.6 Final subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.5.7 Type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.8 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.9 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.10 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.11 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 80 4.6 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.7 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5 Attribute declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.2 Automatic data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.3 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.4 Examples of type declaration statements . . . . . . . . . . . . . . . . . . . . . . 87 5.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.2 Accessibility attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.3 ALLOCATABLE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.4 ASYNCHRONOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.5 BIND attribute for data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3.6 CONTIGUOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3.7 DIMENSION attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.3.8 EXTERNAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.9 INTENT attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.10 INTRINSIC attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.11 OPTIONAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.12 PARAMETER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.13 POINTER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.14 PROTECTED attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.15 SAVE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.3.16 TARGET attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.3.17 VALUE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.3.18 VOLATILE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.1 Accessibility statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.5 CONTIGUOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.6 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.7 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.8 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.9 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.10 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.11 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.12 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 iii J3/07-007 WORKING DRAFT 2006/01/05 5.4.13 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.14 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.15 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.16 VOLATILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5 IMPLICIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.6 NAMELIST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7 Storage association of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7.1 EQUIVALENCE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7.2 COMMON statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7.3 Restrictions on common and equivalence . . . . . . . . . . . . . . . . . . . . . . 115 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.3 Complex parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.1.4 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.2.3 Image selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.3.4 STAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.5 ERRMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.2 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.1.4 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.1.5 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.1.6 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.1.7 Evaluation of operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7.1.8 Integrity of parentheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.1.9 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 152 7.1.10 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 154 7.1.11 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.1.12 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.2 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.2.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.2.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.2.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 166 7.2.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.2 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.3 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.1.4 BLOCK construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 iv 2006/01/05 WORKING DRAFT J3/07-007 8.1.5 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 8.1.6 CRITICAL construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 8.1.7 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.1.8 IF construct and statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 8.1.9 SELECT TYPE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 8.1.10 EXIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 8.5 Image execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.5.1 Image control statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.5.2 SYNC ALL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 8.5.3 SYNC TEAM statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 8.5.4 SYNC IMAGES statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 8.5.5 NOTIFY and QUERY statements . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.5.6 SYNC MEMORY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements . . . . 206 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.4.5 OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.4.6 CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.5.2 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.5.3 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 9.5.4 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 231 9.5.5 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 243 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.6.1 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.6.2 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7.2 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.7.3 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.7.4 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 v J3/07-007 WORKING DRAFT 2006/01/05 9.9 File inquiry statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.9.1 Forms of the INQUIRE statement . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.9.2 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . 255 9.10.2 End-of-file condition and the END= specifier . . . . . . . . . . . . . . . . . . . . 255 9.10.3 End-of-record condition and the EOR= specifier . . . . . . . . . . . . . . . . . . 255 9.10.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 9.10.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 9.11 Restrictions on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.1 Format specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.3 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.2 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.3 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.4 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . 262 10.5 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.6 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7.2 Numeric and bits editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 10.7.3 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 10.7.4 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.5 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.6 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 10.8.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 10.8.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . 277 10.8.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 10.9 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.2 Values and value separators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.3 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 10.10.4 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 10.11 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.2 Name-value subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.3 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.4 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 11 Program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 11.1 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 vi 2006/01/05 WORKING DRAFT J3/07-007 11.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 11.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 11.2.2 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 291 11.2.3 Submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 11.3 Block data program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . 297 12.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.1 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.2 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.3 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.2 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.3 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 300 12.5 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 12.5.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 12.5.2 Actual arguments, dummy arguments, and argument association . . . . . . . . . 313 12.5.3 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.5.4 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.5.5 Resolving named procedure references . . . . . . . . . . . . . . . . . . . . . . . . 326 12.5.6 Resolving type-bound procedure references . . . . . . . . . . . . . . . . . . . . . 328 12.6 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 12.6.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 12.6.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 329 12.6.3 Definition and invocation of procedures by means other than Fortran . . . . . . 336 12.6.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 12.7 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 12.8 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 12.8.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 339 12.8.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 339 12.8.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 340 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.1 General rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.2 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.2.3 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.2.4 Arguments to collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 vii J3/07-007 WORKING DRAFT 2006/01/05 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.15 Collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.16 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.17 Allocation transfer procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.18 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.19 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 350 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 351 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 13.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 13.8.2 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 435 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 14.4 Underflow mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 14.5 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.6 The floating-point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.7 Exceptional values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.8 IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 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 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 viii 2006/01/05 WORKING DRAFT J3/07-007 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 16.5.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.5.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 498 16.6.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 501 16.6.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.8 Pointer association context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 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 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 ix J3/07-007 WORKING DRAFT 2006/01/05 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.5) . . . . . . . . . . . . . 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.4.5) . . . . . . . . . . . . . . . . . 578 C.13 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 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 x 2006/01/05 WORKING DRAFT J3/07-007 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)Processor Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.1 Unspecified Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.2 Processor Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.3 Unresolved Technical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 Annex E (informative)Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 E.1 Extract of all syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 E.2 Syntax rule cross-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644 Annex F (informative)Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659 xi J3/07-007 WORKING DRAFT 2006/01/05 xii 2006/01/05 WORKING DRAFT J3/07-007 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 137 7.3 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 141 7.4 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 143 7.6 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 145 7.7 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 146 7.8 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 146 7.9 Interpretation of the bits intrinsic operators . . . . . . . . . . . . . . . . . . . . . . 147 7.10 The values of bits intrinsic operations other than // . . . . . . . . . . . . . . . . . 147 7.11 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 148 7.12 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 158 7.13 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 160 7.14 Bits conversion and the assignment statement . . . . . . . . . . . . . . . . . . . . . 161 10.1 E and D exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 10.2 EN exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 10.3 ES exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 412 15.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . 468 15.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 472 xiii J3/07-007 WORKING DRAFT 2006/01/05 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/01/05 WORKING DRAFT J3/07-007 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 ISO/IEC 1539. 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 binary, octal, and hexadecimal constants. (18) The G0 edit descriptor. (19) Additional mathematical intrinsic functions for computing Bessel functions, error functions, 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/07-007 WORKING DRAFT 2006/01/05 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/01/05 WORKING DRAFT J3/07-007 Information technology -- Programming languages -- 1 2Fortran -- 3Part 1: Base Language 4 51 Overview 1.1 Scope 6 7ISO/IEC 1539 is a multipart International Standard; the parts are published separately. This publi- 8cation, ISO/IEC 1539-1, which is the first part, specifies the form and establishes the interpretation 9of programs expressed in the base Fortran language. The purpose of this part of ISO/IEC 1539 is to 10promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on 11a variety of computing systems. The second part, ISO/IEC 1539-2, defines additional facilities for the 12manipulation of character strings of variable length; this has been largely subsumed by allocatable char- 13acters with deferred length parameters. The third part, ISO/IEC 1539-3, defines a standard conditional 14compilation facility for Fortran. A processor conforming to part 1 need not conform to ISO/IEC 1539-2 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. 15 161.2 Processor 17The combination of a computing system and the mechanism by which programs are transformed for use on that computing system is called a processor in this part of ISO/IEC 1539. 18 191.3 Inclusions This part of ISO/IEC 1539 specifies 20 (1) the forms that a program written in the Fortran language may take, 21 (2) the rules for interpreting the meaning of a program and its data, 22 (3) the form of the input data to be processed by such a program, and 23 (4) the form of the output data resulting from the use of such a program. 24 251.4 Exclusions This part of ISO/IEC 1539 does not specify 26 (1) the mechanism by which programs are transformed for use on computing systems, 27 (2) the operations required for setup and control of the use of programs on computing systems, 28 29 (3) the method of transcription of programs or their input or output data to or from a storage 30 medium, 31 (4) the program and processor behavior when this part of ISO/IEC 1539 fails to establish an 32 interpretation except for the processor detection and reporting requirements in items (2) to (8) of 1.5, 1 J3/07-007 WORKING DRAFT 2006/01/05 1 (5) the size or complexity of a program and its data that will exceed the capacity of any 2 particular computing system or the capability of a particular processor, (6) the mechanism for determining the number of images of a program, 3 4 (7) the physical properties of an image or the relationship between images and the computational 5 elements of a computing system, J3 internal note Unresolved Technical Issue 099 Image properties not specified by the standard. According to later notes, we don't specify this kind of stuff. I think it belongs in Exclusions. It definitely does not belong in a note! 6 (8) the physical properties of the representation of quantities and the method of rounding, 7 approximating, or computing numeric values on a particular processor, (9) the physical properties of input/output records, files, and units, or 8 (10) the physical properties and implementation of storage. 9 101.5 Conformance 11A program (2.2.2) is a standard-conforming program if it uses only those forms and relationships 12described herein and if the program has an interpretation according to this part of ISO/IEC 1539. A 13program unit (2.2.1) conforms to this part of ISO/IEC 1539 if it can be included in a program in a 14manner that allows the program to be standard conforming. A processor conforms to this part of ISO/IEC 1539 if: 15 16 (1) it executes any standard-conforming program in a manner that fulfills the interpretations 17 herein, subject to any limits that the processor may impose on the size and complexity of 18 the program; 19 (2) it contains the capability to detect and report the use within a submitted program unit of 20 a form designated herein as obsolescent, insofar as such use can be detected by reference to 21 the numbered syntax rules and constraints; 22 (3) it contains the capability to detect and report the use within a submitted program unit of 23 an additional form or relationship that is not permitted by the numbered syntax rules or 24 constraints, including the deleted features described in Annex B; 25 (4) it contains the capability to detect and report the use within a submitted program unit of an intrinsic type with a kind type parameter value not supported by the processor (4.4); 26 27 (5) it contains the capability to detect and report the use within a submitted program unit of 28 source form or characters not permitted by Clause 3; 29 (6) it contains the capability to detect and report the use within a submitted program of name 30 usage not consistent with the scope rules for names, labels, operators, and assignment 31 symbols in Clause 16; 32 (7) it contains the capability to detect and report the use within a submitted program unit of 33 intrinsic procedures whose names are not defined in Clause 13; and (8) it contains the capability to detect and report the reason for rejecting a submitted program. 34 35However, in a format specification that is not part of a FORMAT statement (10.2.1), a processor need not 36detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 37A standard-conforming processor may allow additional forms and relationships provided that such ad- 38ditions do not conflict with the standard forms and relationships. However, a standard-conforming 39processor may allow additional intrinsic procedures even though this could cause a conflict with the 2 2006/01/05 WORKING DRAFT J3/07-007 1name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 2of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 3given the EXTERNAL attribute (5.3.8) in the scoping unit (2.2.1). A standard-conforming program 4shall not use nonstandard intrinsic procedures or modules that have been added by the processor. 5Because a standard-conforming program may place demands on a processor that are not within the 6scope of this part of ISO/IEC 1539 or may include standard items that are not portable, such as 7external procedures defined by means other than Fortran, conformance to this part of ISO/IEC 1539 8does not ensure that a program will execute consistently on all or any standard-conforming processors. 9In some cases, the provision of facilities that are not completely specified in thisstandard is allowed. 10These facilities are identified as processor dependent. They shall be provided, with methods or 11semantics determined by the processor. 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 12 1.6.1 New intrinsic procedures 13 14Each Fortran International Standard since ISO 1539:1980 (informally referred to as Fortran 77), defines 15more intrinsic procedures than the previous one. Therefore, a Fortran program conforming to an older 16standard may have a different interpretation under a newer standard if it invokes an external procedure 17having the same name as one of the new standard intrinsic procedures, unless that procedure is specified 18to have the EXTERNAL attribute. 1.6.2 New intrinsic data type and operator 19 20This part of ISO/IEC 1539 specifies a new intrinsic type, BITS, which will conflict with a derived type 21of the same name. 22This part of ISO/IEC 1539 specifies a new intrinsic operator, .XOR., which might conflict with a user- 23defined operator of the same name, has a different precedence from that of a user-defined operator, and 24a different syntax from that of a user-defined unary operator. 1.6.3 Fortran 2003 compatibility 25 26Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension 27to the preceding Fortran International Standard, ISO/IEC 1539-1:2004 (Fortran 2003). Any standard- 28conforming Fortran 2003 program that does not use a derived type called BITS, and does not use a user-defined operator called .XOR., remains standard-conforming under this part of ISO/IEC 1539. 29 1.6.4 Fortran 95 compatibility 30 31Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension to 32ISO/IEC 1539-1:1997 (Fortran 95). Any standard-conforming Fortran 95 program that does not use a 3 J3/07-007 WORKING DRAFT 2006/01/05 1derived type called BITS or a user-defined operator called .XOR. remains standard-conforming under 2this part of ISO/IEC 1539. The following Fortran 95 features may have different interpretations in this part of ISO/IEC 1539. 3 4 (1) Earlier Fortran standards had the concept of printing, meaning that column one of formatted 5 output had special meaning for a processor-dependent (possibly empty) set of external 6 files. This could be neither detected nor specified by a standard-specified means. The interpretation of the first column is not specified by this part of ISO/IEC 1539. 7 8 (2) This part of ISO/IEC 1539 specifies a different output format for real zero values in list- 9 directed and namelist output. 10 (3) If the processor can distinguish between positive and negative real zero, this part of ISO/IEC 11 1539 requires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real 12 zero and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative 13 zero imaginary part. 1.6.5 Fortran 90 compatibility 14 15Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 16of ISO/IEC 1539 is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard- 17conforming Fortran 90 program that does not use a derived type called BITS, a user-defined operator 18called .XOR., or one of the deleted features remains standard-conforming under this part of ISO/IEC 191539. 20The PAD= specifier in the INQUIRE statement in this part of ISO/IEC 1539 returns the value UNDE- 21FINED if there is no connection or the connection is for unformatted input/output. Fortran 90 specified 22YES. 23Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor dependent. this part of ISO/IEC 1539 specifies that the second argument shall not be zero. 24 1.6.6 FORTRAN 77 compatibility 25 26Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 27of ISO/IEC 1539 is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard- 28conforming Fortran 77 program that does not use one of the deleted features noted in Annex B.1 and 29that does not depend on the differences specified here remains standard-conforming under this part of 30ISO/IEC 1539. This part of ISO/IEC 1539 restricts the behavior for some features that were processor 31dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program that uses one of 32these processor-dependent features may have a different interpretation under this part of ISO/IEC 1539, 33yet remain a standard-conforming program. The following Fortran 77 features may have different interpretations in this part of ISO/IEC 1539. 34 35 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 36 than can be represented in a real datum when the constant is used to initialize a data object 37 of type double precision real in a DATA statement. This part of ISO/IEC 1539 does not 38 permit a processor this option. 39 (2) If a named variable that was not in a common block was initialized in a DATA statement and 40 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 41 dependent. This part of ISO/IEC 1539 specifies (5.4.6) that this named variable has the 42 SAVE attribute. 43 (3) Fortran 77 specified that the number of characters required by the input list was to be 44 less than or equal to the number of characters in the record during formatted input. This 45 part of ISO/IEC 1539 specifies (9.5.4.4.2) that the input record is logically padded with 46 blanks if there are not enough characters in the record, unless the PAD= specifier with the 47 value 'NO' is specified in an appropriate OPEN or READ statement. 4 2006/01/05 WORKING DRAFT J3/07-007 1 (4) A value of 0 for a list item in a formatted output statement will be formatted in a different 2 form for some G edit descriptors. In addition, this part of ISO/IEC 1539 specifies how 3 rounding of values will affect the output field form, but Fortran 77 did not address this 4 issue. Therefore, some Fortran 77 processors may produce an output form different from 5 the output form produced by Fortran 2003 processors for certain combinations of values and 6 G edit descriptors. 7 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 8 SIGN intrinsic function when the second argument is negative real zero is changed by this part of ISO/IEC 1539. 9 1.7 Notation used in this part of ISO/IEC 1539 10 1.7.1 Applicability of requirements 11 12In this part of ISO/IEC 1539, "shall" is to be interpreted as a requirement; conversely, "shall not" is 13to be interpreted as a prohibition. Except where stated otherwise, such requirements and prohibitions 14apply to programs rather than processors. 151.7.2 Informative notes 16Informative notes of explanation, rationale, examples, and other material are interspersed with the 17normative body of this part of ISO/IEC 1539. The informative material is nonnormative; it is identified 18by being in shaded, framed boxes that have numbered headings beginning with "NOTE." 1.7.3 Syntax rules 19 20Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These syntax rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions. 21 22 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 23 where otherwise noted. 24 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 25 eral syntactic classes for which particular syntactic entities shall be substituted in actual 26 statements. 27 Common abbreviations used in syntactic terms are: 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: 28 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 29 (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a 30 one- or two-digit clause number and nn is a two-digit sequence number within that clause. 5 J3/07-007 WORKING DRAFT 2006/01/05 1 The syntax rules are distributed as appropriate throughout the text, and are referenced by 2 number as needed. Some rules in Clauses 2 and 3 are more fully described in later clauses; in 3 such cases, the clause number s is the number of the later clause where the rule is repeated. 4 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 5 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 6 restricted by corresponding constraints and text. 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 71.7.4 Constraints 8Each constraint is given a unique identifying number of the form Csn, where s is a one or two digit clause 9number and nn is a two or three digit sequence number within that clause. 10Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 11annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 12rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places 13where the syntax term appears. 14Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 15to that of a restriction stated in the text, except that a processor is required to have the capability to 16detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 17and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 18conforming program is required to adhere to the broad requirement, but that a standard-conforming 19processor is required only to have the capability of diagnosing violations of the constraint. 1.7.5 Assumed syntax rules 20 21In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 22tion, the following rules are assumed. R101 xyz-list is xyz [ , xyz ] ... 23 24R102 xyz-name is name 25R103 scalar-xyz is xyz C101 (R103) scalar-xyz shall be scalar. 26 6 2006/01/05 WORKING DRAFT J3/07-007 1The letters "xyz" stand for any syntactic class phrase. An explicit syntax rule for a term overrides an 2assumed rule. 1.7.6 Syntax conventions and characteristics 3 4 (1) Any syntactic class name ending in "-stmt" follows the source form statement rules: it shall 5 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 6 statement (such as an IF or WHERE statement). Conversely, everything considered to be 7 a source form statement is given a "-stmt" ending in the syntax rules. 8 (2) The rules on statement ordering are described rigorously in the definition of program-unit (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 9 10 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 11 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" in R510), and in a few other cases. 12 13 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 14 suffix "-selector" is used. See, for example, "kind-selector" (R405) and "length-selector" (R421). 15 16 (5) The term "subscript" (for example, R619, R620, and R621) is used consistently in array 17 definitions. 181.7.7 Text conventions 19In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 20Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 21statement". Boldface words are used in the text where they are first defined with a specialized meaning. 22The descriptions of obsolescent features appear in a smaller type size. NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 231.8 Deleted and obsolescent features 241.8.1 General 25This part of ISO/IEC 1539 protects the users' investment in existing software by including all but five 26of the language elements of Fortran 90 that are not processor dependent. This part of ISO/IEC 1539 27identifies two categories of outmoded features. There are five in the first category, deleted features, 28which consists of features considered to have been redundant in Fortran 77 and largely unused in 29Fortran 90. Those in the second category, obsolescent features, are considered to have been redundant 30in Fortran 90 and Fortran 95, but are still frequently used. 311.8.2 Nature of deleted features 32Better methods existed in Fortran 77 for each deleted feature. These features were not included in 33Fortran 95 or Fortran 2003, and are not included in this revision of Fortran. 341.8.3 Nature of obsolescent features 35Better methods existed in Fortran 90 and Fortran 95 for each obsolescent feature. It is recommended 36that programmers use these better methods in new programs and convert existing code to these methods. 37The obsolescent features are identified in the text of this part of ISO/IEC 1539 by a distinguishing type font (1.7.7). 38 7 J3/07-007 WORKING DRAFT 2006/01/05 1A future revision of this part of ISO/IEC 1539 might delete an obscolescent feature if its use has become 2insignificant. 31.9 Normative references 4The following referenced standards are indispensable for the application of this part of ISO/IEC 1539. 5For dated references, only the edition cited applies. For undated references, the latest edition of the referenced standard (including any amendments) applies. 6 ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 7 8ISO 8601:1988, Data elements and interchange formats--Information interchange-- 9Representation of dates and times. ISO/IEC 9899:1999, Information technology--Programming languages--C. 10 11ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 12Part 1: Architecture and basic multilingual plane. IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 13 14ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 15commonly known as ASCII. This part of ISO/IEC 1539 refers to ISO/IEC 9899:1999 as the C International Standard. 16 17Because IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arith- 18metic, and is widely known by this name, this part of ISO/IEC 1539 refers to it as the IEEE International 19Standard. 8 2006/01/05 WORKING DRAFT J3/07-007 2 Fortran terms and concepts 1 2.1 High level syntax 2 3This clause introduces the terms associated with program units and other Fortran concepts above the 4construct, statement, and expression levels and illustrates their relationships. The notation used in this part of ISO/IEC 1539 is 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. 6R201 program is program-unit [ program-unit ] ... 7 8A program shall contain exactly one main-program program-unit or a main program defined by means 9other than Fortran, but not both. 10R202 program-unit is main-program 11 or external-subprogram 12 or module 13 or submodule 14 or block-data 15R1101 main-program is [ program-stmt ] 16 [ specification-part ] 17 [ execution-part ] 18 [ internal-subprogram-part ] 19 end-program-stmt 20R203 external-subprogram is function-subprogram 21 or subroutine-subprogram 22R1227 function-subprogram is function-stmt 23 [ specification-part ] 24 [ execution-part ] 25 [ internal-subprogram-part ] 26 end-function-stmt 27R1233 subroutine-subprogram is subroutine-stmt 28 [ specification-part ] 29 [ execution-part ] 30 [ internal-subprogram-part ] 31 end-subroutine-stmt 32R1104 module is module-stmt 33 [ specification-part ] 34 [ module-subprogram-part ] 35 end-module-stmt 36R1116 submodule is submodule-stmt 9 J3/07-007 WORKING DRAFT 2006/01/05 1 [ specification-part ] 2 [ module-subprogram-part ] 3 end-submodule-stmt 4R1120 block-data is block-data-stmt 5 [ specification-part ] 6 end-block-data-stmt 7R204 specification-part is [ use-stmt ] ... 8 [ import-stmt ] ... 9 [ implicit-part ] [ declaration-construct ] ... 10 11R205 implicit-part is [ implicit-part-stmt ] ... 12 implicit-stmt 13R206 implicit-part-stmt is implicit-stmt 14 or parameter-stmt 15 or format-stmt 16 or entry-stmt 17R207 declaration-construct is derived-type-def 18 or entry-stmt 19 or enum-def 20 or format-stmt 21 or interface-block 22 or macro-definition 23 or parameter-stmt 24 or procedure-declaration-stmt 25 or specification-stmt 26 or type-declaration-stmt 27 or stmt-function-stmt 28R208 execution-part is executable-construct [ execution-part-construct ] ... 29 30R209 execution-part-construct is executable-construct 31 or format-stmt 32 or entry-stmt 33 or data-stmt 34R210 internal-subprogram-part is contains-stmt [ internal-subprogram ] ... 35 36R211 internal-subprogram is function-subprogram 37 or subroutine-subprogram 38R1107 module-subprogram-part is contains-stmt [ module-subprogram ] ... 39 40R1108 module-subprogram is function-subprogram 41 or subroutine-subprogram 42 or separate-module-subprogram 43R1237 separate-module-subprogram is mp-subprogram-stmt 44 [ specification-part ] 45 [ execution-part ] 10 2006/01/05 WORKING DRAFT J3/07-007 1 [ internal-subprogram-part ] 2 end-mp-subprogram-stmt 3R212 specification-stmt is access-stmt 4 or allocatable-stmt 5 or asynchronous-stmt 6 or bind-stmt 7 or common-stmt 8 or data-stmt 9 or dimension-stmt 10 or equivalence-stmt 11 or external-stmt 12 or intent-stmt 13 or intrinsic-stmt 14 or namelist-stmt 15 or optional-stmt 16 or pointer-stmt 17 or protected-stmt 18 or save-stmt 19 or target-stmt 20 or volatile-stmt 21 or value-stmt 22R213 executable-construct is action-stmt 23 or associate-construct 24 or block-construct 25 or case-construct 26 or critical-construct 27 or do-construct 28 or forall-construct 29 or if-construct 30 or select-type-construct 31 or where-construct 32R214 action-stmt is allocate-stmt 33 or assignment-stmt 34 or backspace-stmt 35 or call-stmt 36 or close-stmt 37 or continue-stmt 38 or cycle-stmt 39 or deallocate-stmt 40 or end-function-stmt 41 or end-mp-subprogram-stmt 42 or end-program-stmt 43 or end-subroutine-stmt 44 or endfile-stmt 45 or exit-stmt 46 or flush-stmt 47 or forall-stmt 48 or goto-stmt 49 or if-stmt 50 or inquire-stmt 51 or notify-stmt 52 or nullify-stmt 11 J3/07-007 WORKING DRAFT 2006/01/05 1 or open-stmt 2 or pointer-assignment-stmt 3 or print-stmt 4 or query-stmt 5 or read-stmt 6 or return-stmt 7 or rewind-stmt 8 or stop-stmt 9 or sync-all-stmt 10 or sync-images-stmt 11 or sync-memory-stmt 12 or sync-team-stmt 13 or wait-stmt 14 or where-stmt 15 or write-stmt 16 or arithmetic-if-stmt 17 or computed-goto-stmt 18C201 (R208) An execution-part shall not contain an end-function-stmt, end-mp-subprogram-stmt, end- 19 program-stmt, or end-subroutine-stmt. 20Additionally, an EXPAND statement may occur anywhere that any statement may occur other than 21as the first statement of a program unit. The syntax rules are applied to the program after macro 22expansion, i.e. with each EXPAND statement replaced by the statements it produces. 2.2 Program unit concepts 23 2.2.1 Program units and scoping units 24 25Program units are the fundamental components of a Fortran program. A program unit may be 26a main program, an external subprogram, a module, a submodule, or a block data program unit. A 27subprogram may be a function subprogram or a subroutine subprogram. A module contains definitions 28that are to be made accessible to other program units. A submodule is a extension of a module; it may 29contain the definitions of procedures declared in a module or another submodule. A block data program 30unit is used to specify initial values for data objects in named common blocks. Each type of program 31unit is described in Clause 11 or 12. An external subprogram is a subprogram that is not in a main 32program, a module, a submodule, or another subprogram. An internal subprogram is a subprogram 33that is in a main program or another subprogram. A module subprogram is a subprogram that is in 34a module or submodule but is not an internal subprogram. 35A program unit consists of a set of nonoverlapping scoping units. A scoping unit is (1) a program unit or subprogram, excluding any scoping units in it, 36 (2) a derived-type definition (4.5.2), or 37 (3) an interface body, excluding any scoping units in it. 38 39A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often abbreviated to host). A module or submodule is also the host scoping unit of its child submodules. 40 2.2.2 Program 41 42A program consists of exactly one main program, any number (including zero) of other kinds of program 43units, any number (including zero) of external procedures, and any number (including zero) of other 44entities defined by means other than Fortran. 12 2006/01/05 WORKING DRAFT J3/07-007 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 1539 places 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 1 2The Fortran main program is described in 11.1. 32.2.4 Procedure 4A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 5execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 6in an expression; its invocation causes a value to be computed which is then used in evaluating the 7expression. The variable that returns the value of a function is called the result variable. A subroutine 8is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 9operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 10the program state by changing the values of any of the data objects accessible to the subroutine; unless 11it is a pure procedure, a function may do this in addition to computing the function value. 12Procedures are described further in Clause 12. 132.2.4.1 External procedure 14An external procedure is a procedure that is defined by an external subprogram or by means other 15than Fortran. An external procedure may be invoked by the main program or by any procedure of a 16program. 172.2.4.2 Module procedure 18A module procedure is a procedure that is defined by a module subprogram (R1108). The module or 19submodule containing the subprogram is the host scoping unit of the module procedure. 202.2.4.3 Internal procedure 21An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 22main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 23is local to its host in the sense that its name is accessible within the host scoping unit and all its other 24internal procedures but is not accessible elsewhere. 252.2.4.4 Interface block 26An interface body describes an abstract interface or the interface of a dummy procedure, external 27procedure, procedure pointer, or separate module procedure. 28An interface block is a specific interface block, an abstract interface block, or a generic interface block. 29A specific interface block is a collection of interface bodies. A generic interface block can also be used 30to specify that a procedure can be invoked (1) by using a generic name, 31 (2) by using a defined operator, 32 13 J3/07-007 WORKING DRAFT 2006/01/05 (3) by using a defined assignment, or 1 (4) for derived-type input/output. 2 32.2.5 Module 4A module contains (or accesses from other modules) definitions that are to be made accessible to other 5program units. These definitions include data object declarations, type definitions, procedure definitions, 6and interface blocks. A scoping unit in another program unit may access the definitions in a module. 7Modules are further described in Clause 11. 82.2.6 Submodule 9A submodule is a program unit that extends a module or another submodule. It may provide definitions 10(12.6) for procedures whose interfaces are declared (12.4.3.2) in an ancestor module or submodule. It 11may also contain declarations and definitions of other entities, which are accessible in its descendants. 12An entity declared in a submodule is not accessible by use association unless it is a module procedure 13whose interface is declared in the ancestor module. Submodules are further described in Clause 11. NOTE 2.3 The scoping unit of a submodule accesses the scoping unit of its parent module or submodule by host association. 2.3 Execution concepts 14 152.3.1 Statement classification 16Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 17There are restrictions on the order in which statements may appear in a program unit, and not all 18executable statements may appear in all contexts. 2.3.2 Program execution 19 20An instance of a Fortran program is an image. Execution of a program consists of the asynchronous 21execution of a fixed number (which may be one) of its images. Each image has its own execution state, 22floating-point status (14.6), and set of data objects and procedure pointers. Whether a file is available 23on any image or only on a specific image is processor dependent. Each image is identified by an image 24index, which is an integer value in the range one to the number of images. 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 identified by a scalar object of type IMAGE TEAM (13.8.2.7). 25 14 2006/01/05 WORKING DRAFT J3/07-007 2.3.3 Executable/nonexecutable statements 1 2Image execution is a sequence, in time, of actions. An executable statement is an instruction to 3perform or control one or more of these actions. Thus, the executable statements of a program unit 4determine the behavior of the program unit. The executable statements are all of those that make up 5the syntactic class executable-construct, excluding those in the specification-part of a BLOCK executable 6construct. 7Nonexecutable statements do not specify actions; they are used to configure the program environment 8in which actions take place. The nonexecutable statements are all those not classified as executable. 92.3.4 Statement order 10The syntax rules of clause 2.1 specify the statement order within program units and subprograms. These 11rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for statements and 12applies to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of 13statements that may be interspersed and horizontal lines delineate varieties of statements that shall not 14be interspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE 15and CONTAINS statements in a subprogram, nonexecutable statements generally precede executable 16statements, although the ENTRY statement, FORMAT statement, and DATA statement may appear 17among the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. 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 DATA Executable statements constructs 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 15 J3/07-007 WORKING DRAFT 2006/01/05 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 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. (2) Miscellaneous declarations are PARAMETER statements, IMPLICIT statements, type declaration statements, enumeration definitions, procedure declaration statements, and spec- ification statements. 12.3.5 The END statement 2An end-program-stmt, end-function-stmt, end-subroutine-stmt, end-mp-subprogram-stmt, end-module- 3stmt, end-submodule-stmt, or end-block-data-stmt is an END statement. Each program unit, module 4subprogram, and internal subprogram shall have exactly one END statement. The end-program-stmt, 5end-function-stmt, end-subroutine-stmt, and end-mp-subprogram-stmt statements are executable, and 6may be branch target statements (8.2). Executing an end-program-stmt causes normal termination of 7execution of the program. Executing an end-function-stmt, end-subroutine-stmt, or end-mp-subprogram- 8stmt is equivalent to executing a return-stmt with no scalar-int-expr. 9The end-module-stmt, end-submodule-stmt, and end-block-data-stmt statements are nonexecutable. 2.3.6 Execution sequence 10 11If a program contains a Fortran main program, execution of the program begins by creating a fixed 12number of instances of the program; each image begins execution with the first executable construct of 13the main program. The execution of a main program or subprogram involves execution of the executable 14constructs within its scoping unit. When a Fortran procedure is invoked, the specification expressions 15within the specification-part of the invoked procedure, if any, are evaluated in a processor dependent 16order. Thereafter, execution proceeds to the first executable construct appearing within the scoping unit 17of the procedure after the invoked entry point. With the following exceptions, the effect of execution is 18as if the executable constructs are executed in the order in which they appear in the main program or 19subprogram until a STOP, RETURN, or END statement is executed. 20 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 21 explicitly specify a new starting place for the execution sequence. 22 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 23 an internal statement structure and execution of these constructs involves implicit internal 24 branching. See Clause 8 for the detailed semantics of each of these constructs. 25 (3) BLOCK constructs may contain specification expressions; see 8.1.4 for detailed semantics 26 of this construct. 16 2006/01/05 WORKING DRAFT J3/07-007 (4) END=, ERR=, and EOR= specifiers may result in a branch. 1 (5) 2 Alternate returns may result in a branch. 3Internal subprograms may precede the END statement of a main program or a subprogram. The 4execution sequence excludes all such definitions. 5The relative ordering of the exeuction sequences of different images can be affected by image control statements (8.5.1). 6 7Normal termination of execution of an image occurs if a STOP statement is executed on that image. Ex- 8ecution of an end-program-stmt results in a synchronization of all images followed by normal termination 9of execution of all images. Normal termination of execution of an image also may occur during execution 10of a procedure defined by a companion processor (C International Standard 5.1.2.2.3 and 7.20.4.3). If 11normal termination of execution occurs within a Fortran program unit and the program incorporates 12procedures defined by a companion processor, the process of execution termination shall include the effect of executing the C exit() function (C International Standard 7.20.4.3). 13 2.4 Data concepts 14 15Nonexecutable statements are used to specify the characteristics of the data environment. This includes 16typing variables, declaring arrays, and defining new types. 2.4.1 Type 17 18A type is a named category of data that is characterized by a set of values, a syntax for denoting 19these values, and a set of operations that interpret and manipulate the values. This central concept is 20described in 4.1. 21A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 22the set of operations depend on the values of one or more parameters. Such a parameter is called a type parameter (4.2). 23 24There are two categories of types: intrinsic types and derived types. 252.4.1.1 Intrinsic type 26An intrinsic type is a type that is defined by the language, along with operations, and is always 27accessible. The intrinsic types are integer, real, complex, character, logical, and bits. The properties of 28intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. 29The kind type parameter indicates the representation method for the specified type. 302.4.1.2 Derived type 31A derived type is a type that is defined by a type definition or by an intrinsic module. A scalar object of 32derived type is called a structure (4.5). Derived types may be parameterized. Assignment of structures 33is defined intrinsically (7.2.1.3), but there are no intrinsic operations for structures. For each derived 34type, a structure constructor is available to provide values (4.5.10). In addition, data objects of derived 35type may be used as procedure arguments and function results, and may appear in input/output lists. 36If additional operations are needed for a derived type, they shall be supplied as procedure definitions. 37Derived types are described further in 4.5. 382.4.2 Data value 17 J3/07-007 WORKING DRAFT 2006/01/05 1Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 2on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 3that objects of a derived type may assume are determined by the type definition, type parameter values, 4and the sets of values of its components. 2.4.3 Data entity 5 6A data entity is a data object, the result of the evaluation of an expression, or the result of the execution 7of a function reference (called the function result). A data entity has a type and type parameters; it 8may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 9either a scalar or an array. 102.4.3.1 Data object 11A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a 12constant. The type and type parameters of a named data object may be specified explicitly (5.2) or implicitly (5.5). 13 14Subobjects are portions of certain objects that may be referenced and defined (variables only) inde- 15pendently of the other portions. These include portions of arrays (array elements and array sections), 16portions of character strings (substrings), portions of complex objects (real and imaginary parts), and 17portions of structures (components). Subobjects are themselves data objects, but subobjects are refer- 18enced only by object designators or intrinsic functions. A subobject of a variable is a variable. Subobjects 19are described in Clause 6. 20Objects referenced by a name are: a named scalar (a scalar object) a named array (an array object) 21 22Subobjects referenced by an object designator are: an array element (a scalar subobject) an array section (an array subobject) a complex part designator (the real or imaginary part of a complex object) a structure component (a scalar or an array subobject) a substring (a scalar subobject) 23 242.4.3.1.1 Variable 25A variable may have a value and may be defined and redefined during execution of a program. 26A named local variable of the scoping unit of a module, submodule, main program, or subprogram, is a 27named variable that is a local entity of the scoping unit, is not a dummy argument, is not in COMMON, 28does not have the BIND attribute, and is not accessed by use or host association. A named local variable 29of a BLOCK construct is a named variable that is declared in that construct, is not in COMMON, does 30not have the BIND attribute, and is not accessed by use association. A subobject of a named local 31variable is also a local variable. 322.4.3.1.2 Constant 33A constant has a value and cannot become defined, redefined, or undefined during execution of a 34program. A constant with a name is called a named constant and has the PARAMETER attribute (5.3.12). A constant without a name is called a literal constant (4.4). 35 362.4.3.1.3 Subobject of a constant 18 2006/01/05 WORKING DRAFT J3/07-007 1A subobject of a constant is a portion of a constant. The portion referenced may depend on the 2value of a variable. NOTE 2.6 For example, given: CHARACTER (LEN = 10), PARAMETER :: DIGITS = '0123456789' CHARACTER (LEN = 1) :: DIGIT INTEGER :: I ... DIGIT = DIGITS (I:I) DIGITS is a named constant and DIGITS (I:I) designates a subobject of the constant DIGITS. 32.4.3.2 Expression 4An expression (7.1) produces a data entity when evaluated. An expression represents either a data 5reference or a computation; it is formed from operands, operators, and parentheses. The type, type 6parameters, value, and rank of an expression result are determined by the rules in Clause 7. 72.4.3.3 Function reference 8A function reference (12.5.3) produces a data entity when the function is executed during expression 9evaluation. The type, type parameters, and rank of a function result are determined by the interface of the function (12.3.3). The value of a function result is determined by execution of the function. 10 112.4.4 Scalar 12A scalar (2.4.4) is a data entity that can be represented by a single value of the type and that is not an array (6.2). Its value, if defined, is a single element from the set of values that characterize its type. 13 NOTE 2.7 A structure is scalar even if it has arrays as components. A scalar object of derived type has a single value that consists of the values of its components (4.5.8). 14The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. 2.4.5 Array 15 16An array is a set of scalar data, all of the same type and type parameters, whose individual elements 17are arranged in a rectangular pattern. An array element is one of the individual elements in the array 18and is a scalar. An array section is a subset of the elements of an array and is itself an array. 19An array may have up to fifteen dimensions, and any extent (number of elements) in any dimension. 20The rank of the array is the number of dimensions; its size is the total number of elements, which is 21equal to the product of the extents. An array may have zero size. The shape of an array is determined 22by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 23are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 24declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 25vary during execution. 26Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 19 J3/07-007 WORKING DRAFT 2006/01/05 1intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations 2are performed element-by-element to produce a resultant array conformable with the array operands. 3Element-by-element operation means corresponding elements of the operand arrays are involved in a 4scalar operation to produce the corresponding element in the result array. Such an operation is described 5as elemental. 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. 6A rank-one array may be constructed from scalars and other arrays and may be reshaped into any allowable array shape (4.7). 7 8Arrays may be of any type and are described further in 6.2. 2.4.6 Co-array 9 10A co-array is a data entity that has nonzero co-rank; it can be directly referenced or defined by any 11image. It may be a scalar or an array. 12For each co-array on an image, there is a corresponding co-array with the same type, type parameters, 13and bounds on every other image. If a co-array is scalar, the set of corresponding co-arrays on all the 14images is arranged in a rectangular pattern. If a co-array is an array, the set of corresponding co-array 15elements on all the images is arranged in a rectangular pattern. In both cases, the dimensions of the 16pattern are called co-dimensions. The bounds for each co-dimension are called co-bounds. 17A co-array on another image can be accessed directly by using co-subscripts. On its own image, a 18co-array can be accessed without use of co-subscripts. 19The co-rank of a co-array is the number of co-dimensions. The co-size of a co-array is always equal to 20the number of images. 21An object whose designator includes an image-selector is a co-indexed object. For a co-indexed object, 22its co-subscript list determines the image index in the same way that a subscript list determines the subscript order value for an array element (6.2.2.1). 23 24Intrinsic procedures are provided for mapping between an image index and a list of co-subscripts. 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. 252.4.7 Pointer 26A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 27entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 28A pointer is associated with a target by pointer assignment (7.2.2) or pointer initialization (4.5.4.5, 295.2.3). A data pointer may also be associated with a target by allocation (6.3.1) or argument association 30(12.5.2.8). A pointer is disassociated following execution of a NULLIFY statement, following pointer 31assignment with a disassociated pointer, by default initialization, or by explicit initialization. A data 32pointer may also be disassociated by execution of a DEALLOCATE statement. A disassociated pointer 20 2006/01/05 WORKING DRAFT J3/07-007 is not associated with a target (16.5.2). 1 2A pointer that is not associated shall not be referenced or defined. 3If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 4associated with a target. 2.4.8 Storage 5 6Many of the facilities of this part of ISO/IEC 1539 make no assumptions about the physical storage 7characteristics of data objects. However, program units that include storage association dependent 8features shall observe the storage restrictions described in 16.5.3. 92.5 Fundamental terms 10For the purposes of this document, the terms and definitions in this subclause apply. 2.5.1 Name and designator 11 12A name is used to identify a program constituent, such as a program unit, named variable, named 13constant, dummy argument, or derived type. The rules governing the construction of names are given 14in 3.2.1. A designator is a name followed by zero or more component selectors, complex part selectors, 15array section selectors, array element selectors, image selectors, and substring selectors. 16An object designator is a designator for a data object. A procedure designator is a designator for 17a procedure. NOTE 2.10 An object name is a special case of an object designator. 2.5.2 Keyword 18 19The term keyword is used in two ways. 20 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 21 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 22 such keywords appear literally. In descriptive text, this meaning is denoted by the term 23 "keyword" without any modifier. Examples of statement keywords are IF, READ, UNIT, 24 KIND, and INTEGER. 25 (2) It is used to denote names that identify items in a list. In actual argument lists, type 26 parameter lists, and structure constructors, items may be identified by a preceding keyword= 27 rather than their position within the list. An argument keyword is the name of a dummy 28 argument in the interface for the procedure being referenced, a type parameter keyword 29 is the name of a type parameter in the type being specified, and a component keyword 30 is the name of a component in a structure constructor. 31R215 keyword is name 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. 21 J3/07-007 WORKING DRAFT 2006/01/05 12.5.3 Association 2Association is name association (16.5.1), pointer association (16.5.2), storage association (16.5.3), 3or inheritance association (16.5.4). Name association is argument association, host association, use 4association, linkage association, or construct association. 5Storage association causes different entities to use the same storage. Any association permits an entity 6to be identified by different names in the same scoping unit or by the same name or different names in 7different scoping units. 82.5.4 Declaration 9The term declaration refers to the specification of attributes for various program entities. Often this 10involves specifying the type of a named data object or specifying the shape of a named array object. 112.5.5 Definition 12The term definition is used in two ways. (1) It refers to the specification of derived types, enumerations, and procedures. 13 14 (2) When an object is given a valid value during program execution, it becomes defined. This 15 is often accomplished by execution of an assignment or input statement. When a variable 16 does not have a predictable value, it is undefined. Similarly, when a pointer is associated 17 with a target or nullified, its pointer association status is said to become defined. When 18 the association status of a pointer is not predictable, its pointer association status is said to 19 be undefined. 20Clause 16 describes the ways in which variables become defined and undefined. 212.5.6 Reference 22A data object reference is the appearance of the data object designator in a context requiring its 23value at that point during execution. 24A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 25symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined derived-type input/output (10.7.6) or derived-type finalization (4.5.6.2) is also a procedure reference. 26 27The appearance of a data object designator or procedure designator in an actual argument list does not 28constitute a reference to that data object or procedure unless such a reference is necessary to complete 29the specification of the actual argument. A module reference is the appearance of a module name in a USE statement (11.2.2). 30 312.5.7 Intrinsic 32The qualifier intrinsic has two meanings. 33 (1) The qualifier signifies that the term to which it is applied is defined in this part of ISO/IEC 34 1539. Intrinsic applies to types, procedures, modules, assignment statements, and operators. 35 All intrinsic types, procedures, assignments, and operators may be used in any scoping 36 unit without further definition or specification. Intrinsic modules may be accessed by use 37 association. Intrinsic procedures and modules defined in this part of ISO/IEC 1539 are 38 called standard intrinsic procedures and standard intrinsic modules, respectively. 22 2006/01/05 WORKING DRAFT J3/07-007 1 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 2 defined in this part of ISO/IEC 1539 (13, 14, 15.2). Such procedures and modules are called 3 nonstandard intrinsic procedures and nonstandard intrinsic modules, respectively. 2.5.8 Operator 4 5An operator specifies a computation involving one (unary operator) or two (binary operator) data 6values (operands). This part of ISO/IEC 1539 specifies a number of intrinsic operators (e.g., the 7arithmetic operators +, ­, *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). Additional operators may be defined within a program (4.5.5, 12.4.3.4). 8 2.5.9 Sequence 9 10A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n. The 11number of elements in the sequence is n. A sequence may be empty, in which case it contains no elements. 2.5.10 Companion processors 12 13A processor has one or more companion processors. A companion processor is a processor-dependent 14mechanism by which global data and procedures may be referenced or defined. A companion processor 15may be a mechanism that references and defines such entities by a means other than Fortran (12.6.3), 16it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 17one companion processor, the means by which the Fortran processor selects among them are processor 18dependent. 19If a procedure is defined by means of a companion processor that is not the Fortran processor itself, this 20part of ISO/IEC 1539 refers to the C function that defines the procedure, although the procedure need 21not be defined by means of the C programming language. 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/07-007 WORKING DRAFT 2006/01/05 24 2006/01/05 WORKING DRAFT J3/07-007 3 Lexical tokens, source form, and macro processing 1 23.1 Processor character set 3The processor character set is processor dependent. Each character in a processor character set is either 4a control character or a graphic character. The set of graphic characters is further divided into letters (3.1.1), digits (3.1.2), underscore (3.1.3), special characters (3.1.4), and other characters (3.1.5). 5 6The letters, digits, underscore, and special characters make up the Fortran character set. 7R301 character is alphanumeric-character 8 or special-character 9R302 alphanumeric-character is letter 10 or digit 11 or underscore 12Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 133.1.3, and 3.1.4. However, the style of any graphic is not specified. 143.1.1 Letters 15The twenty-six letters are: 16 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 17The set of letters defines the syntactic class letter. The processor character set shall include lower- 18case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in 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 21The ten digits are: 22 0 1 2 3 4 5 6 7 8 9 23The ten digits define the syntactic class digit. 243.1.3 Underscore 25R303 underscore is 3.1.4 Special characters 26 25 J3/07-007 WORKING DRAFT 2006/01/05 1The special characters are shown in Table 3.1. 26 2006/01/05 WORKING DRAFT J3/07-007 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 1The special characters define the syntactic class special-character. Some of the special characters are 2used for operator symbols, bracketing, and various forms of separating and delimiting other lexical 3tokens. 43.1.5 Other characters 5Additional characters may be representable in the processor, but may appear only in comments (3.3.1.1, 63.3.2.1), character constants (4.4.5), input/output records (9.1.1), and character string edit descriptors (10.3.2). 7 3.2 Low-level syntax 8 9The low-level syntax describes the fundamental lexical tokens of a program unit. Lexical tokens are 10sequences of characters that constitute the building blocks of a program. They are keywords, names, 11literal constants other than complex literal constants, operators, labels, delimiters, comma, =, =>, :, ::, 12;, and %. 133.2.1 Names 14Names are used for various entities such as variables, program units, dummy arguments, named con- 15stants, and derived types. R304 name is letter [ alphanumeric-character ] ... 16 C301 (R304) The maximum length of a name is 63 characters. 17 NOTE 3.2 Examples of names: A1 NAME_LENGTH (single underscore) S_P_R_E_A_D__O_U_T (two consecutive underscores) TRAILER_ (trailing underscore) 27 J3/07-007 WORKING DRAFT 2006/01/05 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. 13.2.2 Constants 2R305 constant is literal-constant 3 or named-constant 4R306 literal-constant is int-literal-constant 5 or real-literal-constant 6 or complex-literal-constant 7 or logical-literal-constant 8 or char-literal-constant 9 or bits-literal-constant 10R307 named-constant is name 11R308 int-constant is constant C302 (R308) int-constant shall be of type integer. 12 13R309 char-constant is constant C303 (R309) char-constant shall be of type character. 14 3.2.3 Operators 15 16R310 intrinsic-operator is power-op 17 or mult-op 18 or add-op 19 or concat-op 20 or rel-op 21 or not-op 22 or and-op 23 or or-op 24 or equiv-op 25R707 power-op is ** 26R708 mult-op is * or / 27 28R709 add-op is + 29 or ­ R711 concat-op is // 30 31R713 rel-op is .EQ. 32 or .NE. 33 or .LT. 34 or .LE. 35 or .GT. 36 or .GE. 37 or == 28 2006/01/05 WORKING DRAFT J3/07-007 1 or /= 2 or < 3 or <= 4 or > 5 or >= 6R718 not-op is .NOT. 7R719 and-op is .AND. 8R720 or-op is .OR. 9R721 equiv-op is .EQV. 10 or .NEQV. 11 or .XOR. 12R311 defined-operator is defined-unary-op 13 or defined-binary-op 14 or extended-intrinsic-op R703 defined-unary-op is . letter [ letter ] ... . 15 R723 defined-binary-op is . letter [ letter ] ... . 16 17R312 extended-intrinsic-op is intrinsic-operator 183.2.4 Statement labels 19A statement label provides a means of referring to an individual statement. R313 label is digit [ digit [ digit [ digit [ digit ] ] ] ] 20 C304 (R313) At least one digit in a label shall be nonzero. 21 22If a statement is labeled, the statement shall contain a nonblank character. The same statement label 23shall not be given to more than one statement in a scoping unit. Leading zeros are not significant in 24distinguishing between statement labels. 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. 25Any 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 J3/07-007 WORKING DRAFT 2006/01/05 specification for a data transfer statement (9.5). 1 2 (3) In some forms of the DO construct (8.1.7), the range of the DO construct is identified by 3 the label on the last statement in that range. 43.2.5 Delimiters 5Delimiters are used to enclose syntactic lists. The following pairs are delimiters: 6( ... ) 7/ ... / 8[ ... ] 9(/ ... /) 103.3 Source form 11A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, 12and INCLUDE lines. A line is a sequence of zero or more characters. Lines following a program unit 13END statement are not part of that program unit. A Fortran statement is a sequence of one or more 14complete or partial lines. 15A character context means characters within a character literal constant (4.4.5) or within a character string edit descriptor (10.3.2). 16 17A comment may contain any character that may occur in any character context. 18There are two source forms: free and fixed. Free form and fixed form shall not be mixed in the same program unit. 19 The means for specifying the source form of a program unit are processor dependent. 203.3.1 Free source form 21In free source form there are no restrictions on where a statement (or portion of a statement) may 22appear within a line. A line may contain zero characters. If a line consists entirely of characters of 23default kind (4.4.5), it may contain at most 132 characters. If a line contains any character that is not 24of default kind, the maximum number of characters allowed on the line is processor dependent. 25Blank characters shall not appear within lexical tokens other than in a character context or in a format 26specification. Blanks may be inserted freely between tokens to improve readability; for example, blanks 27may occur between the tokens that form a complex literal constant. A sequence of blank characters 28outside of a character context is equivalent to a single blank character. 29A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, 30or labels. 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 31One or more blanks shall be used to separate adjacent keywords except in the following cases, where blanks are optional: 30 2006/01/05 WORKING DRAFT J3/07-007 1 31 J3/07-007 WORKING DRAFT 2006/01/05 Adjacent keywords where separating blanks are optional BLOCK DATA END MODULE DOUBLE PRECISION END INTERFACE ELSE IF END PROCEDURE 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 13.3.1.1 Free form commentary 2The character "!" initiates a comment except where it appears within a character context. The 3comment extends to the end of the line. If the first nonblank character on a line is an "!", the line 4is a comment line. Lines containing only blanks or containing no characters are also comment lines. 5Comments may appear anywhere in a program unit and may precede the first statement of a program 6unit or may follow the last statement of a program unit. Comments have no effect on the interpretation 7of the program unit. NOTE 3.6 This part of ISO/IEC 1539 does not restrict the number of consecutive comment lines. 83.3.1.2 Free form statement continuation 9The character "&" is used to indicate that the current statement is continued on the next line that is not 10a comment line. Comment lines cannot be continued; an "&" in a comment has no effect. Comments may 11occur within a continued statement. When used for continuation, the "&" is not part of the statement. 12No line shall contain a single "&" as the only nonblank character or as the only nonblank character 13before an "!" that initiates a comment. 14If a noncharacter context is to be continued, an "&" shall be the last nonblank character on the line, 15or the last nonblank character before an "!". There shall be a later line that is not a comment; the 16statement is continued on the next such line. If the first nonblank character on that line is an "&", the 17statement continues at the next character position following that "&"; otherwise, it continues with the 18first character position of that line. 19If a lexical token is split across the end of a line, the first nonblank character on the first following 20noncomment line shall be an "&" immediately followed by the successive characters of the split token. 21If a character context is to be continued, an "&" shall be the last nonblank character on the line and 22shall not be followed by commentary. There shall be a later line that is not a comment; an "&" shall be 23the first nonblank character on the next such line and the statement continues with the next character 24following that "&". 253.3.1.3 Free form statement termination 26If a statement is not continued, a comment or the end of the line terminates the statement. 32 2006/01/05 WORKING DRAFT J3/07-007 1 A statement may alternatively be terminated by a ";" character that appears other than in a character 2 context or in a comment. The ";" is not part of the statement. After a ";" terminator, another statement 3 may appear on the same line, or begin on that line and be continued. A sequence consisting only of zero 4 or more blanks and one or more ";" terminators, in any order, is equivalent to a single ";" terminator. 5 3.3.1.4 Free form statements 6 A label may precede any statement not forming part of another statement. NOTE 3.7 No Fortran statement begins with a digit. 7 A statement shall not have more than 255 continuation lines. 8 3.3.2 Fixed source form 9 In fixed source form, there are restrictions on where a statement may appear within a line. If a source line contains only 10 default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor 11 dependent. 12 Except in a character context, blanks are insignificant and may be used freely throughout the program. 13 3.3.2.1 Fixed form commentary 14 The character "!" initiates a comment except where it appears within a character context or in character position 6. The 15 comment extends to the end of the line. If the first nonblank character on a line is an "!" in any character position other 16 than character position 6, the line is a comment line. Lines beginning with a "C" or "*" in character position 1 and lines 17 containing only blanks are also comment lines. Comments may appear anywhere in a program unit and may precede the 18 first statement of the program unit or may follow the last statement of a program unit. Comments have no effect on the 19 interpretation of the program unit. NOTE 3.8 This part of ISO/IEC 1539 does not restrict the number of consecutive comment lines. 20 3.3.2.2 Fixed form statement continuation 21 Except within commentary, character position 6 is used to indicate continuation. If character position 6 contains a blank 22 or zero, the line is the initial line of a new statement, which begins in character position 7. If character position 6 contains 23 any character other than blank or zero, character positions 7­72 of the line constitute a continuation of the preceding 24 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. 25 Comment lines cannot be continued. Comment lines may occur within a continued statement. 263.3.2.3 Fixed form statement termination 27 If a statement is not continued, a comment or the end of the line terminates the statement. 28 A statement may alternatively be terminated by a ";" character that appears other than in a character context, in a 29 comment, or in character position 6. The ";" is not part of the statement. After a ";" terminator, another statement may 30 begin on the same line, or begin on that line and be continued. A ";" shall not appear as the first nonblank character 31 on an initial line. A sequence consisting only of zero or more blanks and one or more ";" terminators, in any order, is 32 equivalent to a single ";" terminator. 33 J3/07-007 WORKING DRAFT 2006/01/05 13.3.2.4 Fixed form statements 2 A label, if present, shall occur in character positions 1 through 5 of the first line of a statement; otherwise, positions 1 3 through 5 shall be blank. Blanks may appear anywhere within a label. A statement following a ";" on the same line shall 4 not be labeled. Character positions 1 through 5 of any continuation lines shall be blank. A statement shall not have more 5 than 255 continuation lines. The program unit END statement shall not be continued. A statement whose initial line 6 appears to be a program unit END statement shall not be continued. 3.4 Including source text 7 8Additional text may be incorporated into the source text of a program unit during processing. This is 9accomplished with the INCLUDE line, which has the form 10 INCLUDE char-literal-constant 11 The char-literal-constant shall not have a kind type parameter value that is a named-constant. 12An INCLUDE line is not a Fortran statement. 13An INCLUDE line shall appear on a single source line where a statement may appear; it shall be the 14only nonblank text on this line other than an optional trailing comment. Thus, a statement label is not 15allowed. 16The effect of the INCLUDE line is as if the referenced source text physically replaced the INCLUDE line 17prior to program processing. Included text may contain any source text, including additional INCLUDE 18lines; such nested INCLUDE lines are similarly replaced with the specified source text. The maximum 19depth of nesting of any nested INCLUDE lines is processor dependent. Inclusion of the source text 20referenced by an INCLUDE line shall not, at any level of nesting, result in inclusion of the same source 21text. 22When an INCLUDE line is resolved, the first included statement line shall not be a continuation line 23and the last included statement line shall not be continued. 24The interpretation of char-literal-constant is processor dependent. An example of a possible valid inter- 25pretation is that char-literal-constant is the name of a file that contains the source text to be included. 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 26 34 2006/01/05 WORKING DRAFT J3/07-007 13.5.1 Macro definition 2A macro definition defines a macro. A defined macro shall only be referenced by a USE statement, 3IMPORT statement, or macro expansion statement. A defined macro shall not be redefined. 4R314 macro-definition is define-macro-stmt 5 [ macro-declaration-stmt ] ... 6 macro-body-block 7 end-macro-stmt 8R315 define-macro-stmt is DEFINE MACRO [ , macro-attr-list ] :: macro-name [ ( [ macro-dummy-arg-name-list ] ) ] 9 10C305 (R315) A macro-dummy-arg-name shall not appear more than once in a macro-dummy-arg- 11 name-list. 12R316 macro-attr is access-spec 13The DEFINE MACRO statement begins the definition of the macro macro-name. Appearance of an 14access-spec in the DEFINE MACRO statement explicitly gives the macro the specified attribute. Each 15macro-dummy-arg-name is a macro dummy argument. A macro dummy argument is a macro local 16variable. 17R317 macro-declaration-stmt is macro-type-declaration-stmt 18 or macro-optional-decl-stmt 19 or macro-variable-decl-stmt 20R318 macro-type-declaration-stmt is MACRO macro-type-spec :: macro-local-variable-name-list 21R319 macro-optional-decl-stmt is MACRO OPTIONAL :: macro-dummy-arg-name-list 22R320 macro-variable-decl-stmt is MACRO VARIABLE :: macro-local-variable-name-list R321 macro-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] 23 24C306 (R318, macro-variable-decl-stmt) A macro-local-variable-name shall not be the same as the name 25 of a dummy argument of the macro being defined. 26C307 (R319) A macro-dummy-arg-name shall be the name of a dummy argument of the macro being 27 defined. 28C308 (R321) If macro-expr appears, when the macro is expanded macro-expr shall be of type integer, 29 and have a non-negative value that specifies a representation method that exists on the processor. 30A macro type declaration statement specifies that the named entities are macro local variables of the 31specified type. If the kind is not specified, they are of default kind. A macro variable declaration 32statement declares untyped macro local variables; the value of an untyped macro local variable is a 33token sequence, and its initial value is an empty sequence (no tokens). A macro local variable that is 34not a macro dummy argument shall appear in a macro type declaration statement or in a macro variable 35declaration statement. R322 macro-body-block is [ macro-body-construct ] ... 36 37R323 macro-body-construct is macro-definition 38 or expand-stmt 39 or macro-body-stmt 40 or macro-do-construct 41 or macro-if-construct 35 J3/07-007 WORKING DRAFT 2006/01/05 1 or macro-int-assignment-stmt 2 or macro-tok-assignment-stmt 3C309 A statement in a macro definition that is not a macro-body-construct or macro-definition shall 4 not appear on a line with any other statement. 5R324 macro-do-construct is macro-do-stmt 6 macro-body-block 7 macro-end-do-stmt 8R325 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , macro-do-limit [ , macro-do-limit ] 9 10C310 (R325) A macro-do-variable-name shall be a local variable of the macro being defined, and shall 11 not be a macro dummy argument. 12R326 macro-do-limit is macro-expr C311 (R326) A macro-do-limit shall expand to an expression of type integer. 13 14R327 macro-end-do-stmt is MACRO END DO 15A macro DO construct iterates the expansion of its enclosed macro body block at macro expansion time. 16The number of iterations is determined by the values of the expanded macro expressions in the MACRO 17DO statement. 18R328 macro-if-construct is macro-if-then-stmt 19 macro-body-block 20 [ macro-else-if-stmt 21 macro-body-block ] ... 22 [ macro-else-stmt 23 macro-body-block ] 24 macro-end-if-stmt R329 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN 25 R330 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN 26 27R331 macro-else-stmt is MACRO ELSE 28R332 macro-end-if-stmt is MACRO END IF 29R333 macro-condition is macro-expr C312 (R333) A macro condition shall expand to an expression of type logical. 30 31A macro IF construct provides conditional expansion of its enclosed macro body blocks at macro expan- 32sion time. Whether the enclosed macro body blocks contribute to the macro expansion is determined by 33the logical value of the expanded macro expressions in the MACRO IF and MACRO ELSE IF statements. 34R334 macro-int-assignment-stmt is MACRO macro-integer-variable-name = macro-expr C313 (R334) macro-integer-variable-name shall be the name of a macro local variable of type integer. 35 36R335 macro-tok-assignment-stmt is MACRO macro-tok-variable-name = assignment-tok-sequence 37 38C314 (R335) macro-tok-variable-name shall be the name of an untyped macro local variable that is 39 not a macro dummy argument. 36 2006/01/05 WORKING DRAFT J3/07-007 R336 assignment-tok-sequence is result-token [ result-token ] ... [ && ] 1 R337 macro-body-stmt is result-token [ result-token ] ... [ && ] 2 3C315 (R337) If the first result-token is MACRO the second result-token shall not be a keyword or 4 name. C316 (R337) If the first token is DEFINE the second token shall not be MACRO. 5 R338 result-token is token [ %% token ] ... 6 7R339 token is any lexical token including labels, keywords, and semi-colon. 8C317 && shall not appear in the last macro-body-stmt of a macro definition. 9C318 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. R340 end-macro-stmt is END MACRO [ macro-name ] 10 11C319 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name 12 in the DEFINE MACRO statement. 13R341 macro-expr is basic-token-sequence C320 (R341) A macro-expr shall expand to a scalar initialization expression. 14 15Macro expressions are used to control the behavior of the MACRO DO and MACRO IF constructs when 16a macro is being expanded. The type, type parameters, and value of a macro expression are determined 17when that macro expression is expanded. 3.5.2 Macro expansion 18 193.5.2.1 General 20Macro expansion is the conceptual replacement of the EXPAND statement with the Fortran statements 21that it produces. The semantics of an EXPAND statement are those of the Fortran statements that it 22produces. It is recommended that a processor be capable of displaying the results of macro expansion. It 23is processor-dependent whether comments in a macro definition appear in the expansion. It is processor- 24dependent whether continuations and consecutive blanks that are not part of a token are preserved. 25The process of macro expansion produces Fortran statements consisting of tokens. The combined length 26of the tokens for a single statement, plus inter-token spacing, shall not be greater than 33280 characters. 27If a statement contains any character that is not of default kind, the maximum number of characters 28allowed is processor dependent. 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. R342 expand-stmt is EXPAND macro-name [ ( macro-actual-arg-list ) ] 29 30C321 (R342) macro-name shall be the name of a macro that was previously defined or accessed via 31 use or host association. 37 J3/07-007 WORKING DRAFT 2006/01/05 C322 (R342) The macro shall expand to a sequence or zero or more complete Fortran statements. 1 2C323 (R342) The statements produced by a macro expansion shall conform to the syntax rules and 3 constraints as if they replaced the EXPAND statement prior to program processing. 4C324 (R342) The statements produced by a macro expansion shall not include a statement which 5 ends the scoping unit containing the EXPAND statement. 6C325 (R342) If a macro expansion produces a statement which begins a new scoping unit, it shall also 7 produce a statement which ends that scoping unit. 8C326 (R342) If the EXPAND statement appears as the action-stmt of an if-stmt, it shall expand 9 to exactly one action-stmt that is not an end-function-stmt, end-mp-subprogram-stmt, end- 10 program-stmt, end-subroutine-stmt, or if-stmt. 11C327 (R342) If the EXPAND statement appears as a do-term-action-stmt, it shall expand to exactly one action- 12 stmt that is not an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, end-mp-subprogram-stmt, 13 end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. 14C328 (R342) If the EXPAND statement has a label, the expansion of the macro shall produce at least 15 one statement, and the first statement produced shall not have a label. 16C329 (R342) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- 17 gument. 18C330 (R342) At most one macro-actual-arg shall appear corresponding to each optional macro dummy 19 argument. 20Expansion of a macro is performed by the EXPAND statement. If the EXPAND statement has a label, 21the label is interpreted after expansion as belonging to the first statement of the expansion. R343 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value 22 23C331 (R343) macro-dummy-name shall be the name of a macro dummy argument of the macro being 24 expanded. 25C332 (R342) The macro-dummy-name= shall not be omitted unless it has been omitted from each 26 preceding macro-actual-arg in the expand-stmt. 27R344 macro-actual-arg-value is basic-token-sequence 28R345 basic-token-sequence is basic-token 29 or [ basic-token-sequence] nested-token-sequence 30 [ basic-token-sequence ] 31 or basic-token basic-token-sequence 32R346 basic-token is any lexical token except comma, parentheses, array 33 constructor delimiters, and semi-colon. 34R347 nested-token-sequence is ( [ arg-token ] ... ) 35 or (/ [ arg-token ] ... /) or lbracket [ arg-token ] ... rbracket 36 37R348 arg-token is basic-token 38 or , 39Macro expansion processes any macro declarations of the macro definition, and then expands its macro 40body block. Any macro expressions in macro-type-specs are evaluated and the kinds of the macro 38 2006/01/05 WORKING DRAFT J3/07-007 1variables thereby declared are determined for that particular expansion. 2Macro expansion of a macro body block processes each macro body construct of the macro body block 3in turn, starting with the first macro body construct and ending with the last macro body construct. 4Expansion of a statement within a macro body construct consists of three steps: (1) token replacement, 5 (2) token concatenation, and 6 (3) statement-dependent processing. 7 83.5.2.2 Token replacement 9Token replacement replaces each token of a macro body statement, assignment token sequence, or macro 10expression that is a macro local variable with the value of that variable. 11In a macro expression, a reference to the PRESENT intrinsic function with a macro dummy argument 12name as its actual argument is replaced by the token .TRUE. if the specified macro dummy argument 13is present, and the token .FALSE. if the specified macro dummy argument is not present. Otherwise, 14the value of a macro dummy argument that is present is the sequence of tokens from the corresponding 15actual argument, and the value of a macro dummy argument that is not present is a zero-length token 16sequence. 17The value of an integer macro variable is its minimal-length decimal representation; if negative this 18produces two tokens, a minus sign and an unsigned integer literal constant. An untyped macro local 19variable expands to the sequence of tokens that was assigned to it, or to zero-length token sequence if it 20has never been assigned to. 213.5.2.3 Token concatenation 22Token concatenation is performed with the %% operator, which is only permitted inside a macro defini- 23tion. After expansion, each sequence of single tokens separated by %% operators is replaced by a single 24token consisting of the concatenated text of the sequence of tokens. The result of a concatenation shall 25be a valid Fortran token, and may be a different kind of token from one or more of the original sequence 26of tokens. C333 (R338) The result of token concatenation shall have the form of a lexical token. 27 NOTE 3.12 For example, the sequence 3 %% .14159 %% E %% + %% 0 forms the single real literal constant 3.14159E+0. 283.5.2.4 Macro body statements 29Processing a macro body statement produces a whole or partial Fortran statement. A macro body 30statement that is either the first macro body statement processed by this macro expansion or the next 31macro body statement processed after a macro body statement that did not end with the continuation 32generation operator &&, is an initial macro body statement. The next macro body statement processed 33after a macro body statement that ends with && is a continuation macro body statement. An initial 34macro body statement that does not end with && produces a whole Fortran statement consisting of its 35token sequence. All other macro body statements produce partial Fortran statements, and the sequence 36of tokens starting with those produced by the initial macro body statement and appending the tokens 39 J3/07-007 WORKING DRAFT 2006/01/05 1produced by each subsequent continuation macro body statement form a Fortran statement. The && 2operators are not included in the token sequence. 33.5.2.5 The MACRO DO construct 4The MACRO DO construct specifies the repeated expansion of a macro body block. Processing the 5MACRO DO statement performs the following steps in sequence. 6 (1) The initial parameter m1, the terminal parameter m2, and the incrementation parameter 7 m3 are of type integer with the same kind type parameter as the macro-do-variable-name. 8 Their values are given by the first macro-expr, the second macro-expr, and the third macro- 9 expr of the macro-do-stmt respectively, including, if necessary, conversion to the kind type 10 parameter of the macro-do-variable-name according to the rules for numeric conversion 11 (Table 7.13). If the third macro-expr does not appear, m3 has the value 1. The value of m3 12 shall not be zero. (2) 13 The MACRO DO variable becomes defined with the value of the initial parameter m1. 14 (3) The iteration count is established and is the value of the expression (m2 - m1 + m3)/m3, 15 unless that value is negative, in which case the iteration count is 0. 16After this, the following steps are performed repeatedly until processing of the MACRO DO construct 17is finished. 18 (1) The iteration count is tested. If it is zero, the loop terminates and processing of the MACRO 19 DO construct is finished. 20 (2) If the iteration count is nonzero, the macro body block of the MACRO DO construct is 21 expanded. 22 (3) The iteration count is decremented by one. The MACRO DO variable is incremented by 23 the value of the incrementation parameter m3. 243.5.2.6 The MACRO IF construct 25The MACRO IF construct provides conditional expansion of macro body blocks. At most one of the 26macro body blocks of the MACRO IF construct is expanded. The macro conditions of the construct 27are evaluated in order until a true value is found or a MACRO ELSE or MACRO END IF statement is 28encountered. If a true value or a MACRO ELSE statement is found, the macro body block immediately 29following is expanded and this completes the processing of the construct. If none of the evaluated 30conditions is true and there is no MACRO ELSE statement, the processing of the construct is completed 31without expanding any of the macro body blocks within the construct. 323.5.2.7 Macro assignment 33Processing a macro integer assignment statement sets the macro local variable value to that of the macro 34expression. 35Processing a macro token assignment statement sets the macro local variable value to be the sequence 36of tokens following the equals sign. If no tokens appear after the equals sign, the macro local variable is 37set to the zero-length token sequence. 383.5.2.8 Macro definitions 39Processing a macro definition defines a new macro. If a macro definition is produced by a macro expan- 40sion, all of the statements of the produced macro definition have token replacement and concatenation 41applied to them before the new macro is defined. 40 2006/01/05 WORKING DRAFT J3/07-007 13.5.2.9 Examples 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: 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) ... 41 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 3.14 (cont.) 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 NOTE 3.16 Macros can be used to define other macros on expansion. For example, ! Macro that defines a macro which assigns a value to an array element DEFINE MACRO :: assign_shortcut(rank) DEFINE MACRO assign_%%rank(array,indices,value) MACRO INTEGER :: i array(indices(1)&& MACRO DO i=2,rank ,indices(i)&& MACRO END DO )=value END MACRO assign_%%rank END MACRO assign_shortcut ! Create assignment macros for all ranks MACRO DO i=1,15 EXPAND assign_shortcut(i) MACRO END DO ! Now use the rank-3 assignment macro: REAL :: A(10,10,10) INTEGER :: indices(3)=[1,5,6] EXPAND assign_3(A,indices,5.0) ! Expands to: ! A(indices(1),indices(2),indices(3))=5.0 42 2006/01/05 WORKING DRAFT J3/07-007 4 Types 1 4.1 The concept of type 2 3Fortran provides an abstract means whereby data can be categorized without relying on a particular 4physical representation. This abstract means is the concept of type. 5A type has a name, a set of valid values, a means to denote such values (constants), and a set of 6operations to manipulate the values. 7A type is either an intrinsic type or a derived type. This part of ISO/IEC 1539 defines six intrinsic types: integer, real, complex, character, logical, and bits. 8 9A derived type is one that is defined by a derived-type definition (4.5.2) or by an intrinsic module. It shall be used only where it is accessible (4.5.2.2). An intrinsic type is always accessible. 10 114.1.1 Set of values 12For each type, there is a set of valid values. The sets of valid values for logical and bits are completely 13determined by this part of ISO/IEC 1539. The sets of valid values for integer, character, and real are 14processor dependent. The set of valid values for complex consists of the set of all the combinations of 15the values of the individual components. The set of valid values for a derived type is as defined in 4.5.8. 164.1.2 Constants 17The syntax for literal constants of each intrinsic type is specified in 4.4. 18The syntax for denoting a value indicates the type, type parameters, and the particular value. A constant value can be given a name (5.3.12, 5.4.10). 19 20A structure constructor (4.5.10) can be used to construct a constant value of derived type from an 21appropriate sequence of initialization expressions (7.1.12). Such a constant value is scalar even if it has 22components that are arrays. 4.1.3 Operations 23 24For each of the intrinsic types, a set of operations and corresponding operators is defined intrinsically. 25These are described in Clause 7. The intrinsic set can be augmented with operations and operators 26defined by functions with the OPERATOR interface (12.4.3.2). Operator definitions are described in 27Clauses 7 and 12. 28For derived types, there are no intrinsic operations. Operations on derived types can be defined by the program (4.5.11). 29 4.2 Type parameters 30 31A type might be parameterized. In this case, the set of values, the syntax for denoting the values, and 32the set of operations on the values of the type depend on the values of the parameters. 43 J3/07-007 WORKING DRAFT 2006/01/05 1The intrinsic types are all parameterized. Derived types may be defined to be parameterized. 2A type parameter is either a kind type parameter or a length type parameter. All type parameters are 3of type integer. 4A kind type parameter may be used in initialization and specification expressions within the derived-type 5definition (4.5.2) for the type; it participates in generic resolution (12.5.5.2). Each of the intrinsic types 6has a kind type parameter named KIND, which is used to distinguish multiple representations of the 7intrinsic type. 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. 8A length type parameter may be used in specification expressions within the derived-type definition for 9the type, but it shall not be used in initialization expressions. The intrinsic character type has a length 10type parameter named LEN, which is the length of the string. 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 12R401 type-param-value is scalar-int-expr 13 or * 14 or : C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. 15 16C402 (R401) A colon shall not be used as a type-param-value except in the declaration of an entity or 17 component that has the POINTER or ALLOCATABLE attribute. 18A deferred type parameter is a length type parameter whose value can change during execution of 19the program. A colon as a type-param-value specifies a deferred type parameter. 20The values of the deferred type parameters of an object are determined by successful execution of an 21ALLOCATE statement (6.3.1), execution of an intrinsic assignment statement (7.2.1.3), execution of a pointer assignment statement (7.2.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. 44 2006/01/05 WORKING DRAFT J3/07-007 1An assumed type parameter is a length type parameter for a dummy argument that assumes the 2type parameter value from the corresponding actual argument; it is also used for an associate name in a 3SELECT TYPE construct that assumes the type parameter value from the corresponding selector, and 4for a named constant of type character that assumes its length from the initialization-expr. An asterisk 5as a type-param-value specifies an assumed type parameter. 4.3 Relationship of types and values to objects 6 7The name of a type serves as a type specifier and may be used to declare objects of that type. A 8declaration specifies the type of a named object. A data object may be declared explicitly or implicitly. 9Data objects may have attributes in addition to their types. Clause 5 describes the way in which a data 10object is declared and how its type and other attributes are specified. 11Scalar data of any intrinsic or derived type may be shaped in a rectangular pattern to compose an array 12of the same type and type parameters. An array object has a type and type parameters just as a scalar 13object does. 14A variable is a data object. The type and type parameters of a variable determine which values that 15variable may take. Assignment (7.2) provides one means of defining or redefining the value of a variable 16of any type. 17The type of a variable determines the operations that may be used to manipulate the variable. 4.3.1 Type specifiers and type compatibility 18 194.3.1.1 General 20A type is specified by a type specifier. 21R402 type-spec is intrinsic-type-spec 22 or derived-type-spec C403 (R402) The derived-type-spec shall not specify an abstract type (4.5.7). 23 24R403 declaration-type-spec is intrinsic-type-spec 25 or TYPE ( intrinsic-type-spec ) 26 or TYPE ( derived-type-spec ) 27 or CLASS ( derived-type-spec ) or CLASS ( * ) 28 29C404 (R403) In a declaration-type-spec, every type-param-value that is not a colon or an asterisk shall 30 be a specification-expr. 31C405 (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify an extensible type (4.5.7). 32 C406 (R403) The TYPE(derived-type-spec) shall not specify an abstract type (4.5.7). 33 34C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLO- 35 CATABLE or POINTER attribute. It shall not have the VALUE attribute. 36An intrinsic-type-spec specifies the named intrinsic type and its type parameter values. A derived-type- 37spec specifies the named derived type and its type parameter values. 45 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.4 A type-spec is used in an array constructor, a SELECT TYPE construct, or an ALLOCATE statement. Elsewhere, a declaration-type-spec is used. 14.3.1.2 TYPE 2A TYPE type specifier is used to declare entities of an intrinsic or derived type. 3Where a data entity is declared explicitly using the TYPE type specifier to be of derived type, the 4specified derived type shall have been defined previously in the scoping unit or be accessible there by 5use or host association. If the data entity is a function result, the derived type may be specified in 6the FUNCTION statement provided the derived type is defined within the body of the function or is 7accessible there by use or host association. If the derived type is specified in the FUNCTION statement 8and is defined within the body of the function, it is as if the function result variable was declared with 9that derived type immediately following the derived-type-def of the specified derived type. 104.3.1.3 CLASS 11A polymorphic entity is a data entity that is able to be of differing types during program execution. 12The type of a data entity at a particular point during execution of a program is its dynamic type. The 13declared type of a data entity is the type that it is declared to have, either explicitly or implicitly. 14A CLASS type specifier is used to declare polymorphic entities. The declared type of a polymorphic 15entity is the specified type if the CLASS type specifier contains a type name. 16An entity declared with the CLASS(*) specifier is an unlimited polymorphic entity. An unlimited 17polymorphic entity is not declared to have a type. It is not considered to have the same declared type 18as any other entity, including another unlimited polymorphic entity. 19A nonpolymorphic entity is type compatible only with entities of the same declared type. A poly- 20morphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same 21declared type or any of its extensions. Even though an unlimited polymorphic entity is not considered 22to have a declared type, it is type compatible with all entities. An entity is type compatible with a type 23if it is type compatible with entities of that type. 24Two entities are type incompatible if neither is type compatible with the other. NOTE 4.5 Given TYPE TROOT ... TYPE,EXTENDS(TROOT) :: TEXTENDED ... CLASS(TROOT) A CLASS(TEXTENDED) B ... A is type compatible with B but B is not type compatible with A. 25A polymorphic allocatable object may be allocated to be of any type with which it is type compatible. 26A polymorphic pointer or dummy argument may, during program execution, be associated with objects 27with which it is type compatible. 28The dynamic type of an allocated allocatable polymorphic object is the type with which it was allocated. 46 2006/01/05 WORKING DRAFT J3/07-007 1The dynamic type of an associated polymorphic pointer is the dynamic type of its target. The dynamic 2type of a nonallocatable nonpointer polymorphic dummy argument is the dynamic type of its associated 3actual argument. The dynamic type of an unallocated allocatable or a disassociated pointer is the same 4as its declared type. The dynamic type of an entity identified by an associate name (8.1.3) is the dynamic 5type of the selector with which it is associated. The dynamic type of an object that is not polymorphic 6is its declared type. NOTE 4.6 Only components of the declared type of a polymorphic object may be designated by component selection (6.1.2). 4.4 Intrinsic types 7 4.4.1 Classification and specification 8 9Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, 10real, and complex. The nonnumeric intrinsic types are character, logical, and bits. 11The numeric types are provided for numerical computation. The normal operations of arithmetic, 12addition (+), subtraction (­), multiplication (*), division (/), exponentiation (**), identity (unary +), and negation (unary ­), are defined intrinsically for the numeric types. 13 14R404 intrinsic-type-spec is INTEGER [ kind-selector ] 15 or REAL [ kind-selector ] 16 or DOUBLE PRECISION 17 or COMPLEX [ kind-selector ] 18 or CHARACTER [ char-selector ] 19 or LOGICAL [ kind-selector ] or BITS [ kind-selector ] 20 R405 kind-selector is ( [ KIND = ] scalar-int-initialization-expr ) 21 22C408 (R405) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 23 resentation method that exists on the processor. 4.4.2 Integer type 24 25The set of values for the integer type is a subset of the mathematical integers. The processor shall 26provide one or more representation methods that define sets of values for data of type integer. Each 27such method is characterized by a value for a type parameter called the kind type parameter; this kind 28type parameter is of type default integer. The kind type parameter of a representation method is returned 29by the intrinsic inquiry function KIND (13.7.96). The decimal exponent range of a representation method 30is returned by the intrinsic function RANGE (13.7.143). The intrinsic function SELECTED INT KIND 31(13.7.153) returns a kind value based on a specified decimal range requirement. The integer type includes 32a zero value, which is considered to be neither negative nor positive. The value of a signed integer zero 33is the same as the value of an unsigned integer zero. 34The processor shall provide at least one representation method with a decimal exponent range greater 35than or equal to 18. 36The type specifier for the integer type uses the keyword INTEGER. 37If the kind type parameter is not specified, the default kind value is KIND (0) and the type specified is 38default integer. The decimal exponent range of default integer shall be at least 5. 47 J3/07-007 WORKING DRAFT 2006/01/05 1Any integer value may be represented as a signed-int-literal-constant. R406 signed-int-literal-constant is [ sign ] int-literal-constant 2 R407 int-literal-constant is digit-string [ kind-param ] 3 4R408 kind-param is digit-string 5 or scalar-int-constant-name R409 signed-digit-string is [ sign ] digit-string 6 R410 digit-string is digit [ digit ] ... 7 8R411 sign is + 9 or ­ C409 (R408) A scalar-int-constant-name shall be a named constant of type integer. 10 C410 (R408) The value of kind-param shall be nonnegative. 11 12C411 (R407) The value of kind-param shall specify a representation method that exists on the pro- 13 cessor. 14The optional kind type parameter following digit-string specifies the kind type parameter of the integer 15constant; if it is not present, the constant is of type default integer. 16An integer constant is interpreted as a decimal value. NOTE 4.7 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 17 18The real type has values that approximate the mathematical real numbers. The processor shall provide 19two or more approximation methods that define sets of values for data of type real. Each such method 20has a representation method and is characterized by a value for a type parameter called the kind 21type parameter; this kind type parameter is of type default integer. The kind type parameter of an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 22 23The decimal precision, decimal exponent range, and radix of an approximation method are returned by 24the intrinsic functions PRECISION (13.7.137), RANGE (13.7.143), and RADIX (13.7.140). The intrinsic 25function SELECTED REAL KIND (13.7.154) returns a kind value based on specified precision, range, 26and radix requirements. 48 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.8 See C.1.1 for remarks concerning selection of approximation methods. 1The real type includes a zero value. Processors that distinguish between positive and negative zeros 2shall treat them as mathematically equivalent (1) in all relational operations, 3 4 (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified 5 that negative zero is distinguished, and (3) 6 as the scalar-numeric-expr in an arithmetic IF. NOTE 4.9 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. 7The type specifier for the real type uses the keyword REAL. The keyword DOUBLE PRECISION is an 8alternative specifier for one kind of real type. 9If the type keyword REAL is specified and the kind type parameter is not specified, the default kind 10value is KIND (0.0) and the type specified is default real. If the type keyword DOUBLE PRECISION 11is specified, the kind value is KIND (0.0D0) and the type specified is double precision real. The 12decimal precision of the double precision real approximation method shall be greater than that of the 13default real method. 14The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall 15be at least 37. It is recommended that the decimal precision of default real be at least 6, and that its 16decimal exponent range be at least 37. R412 signed-real-literal-constant is [ sign ] real-literal-constant 17 18R413 real-literal-constant is significand [ exponent-letter exponent ] [ kind-param ] or digit-string exponent-letter exponent [ kind-param ] 19 20R414 significand is digit-string . [ digit-string ] 21 or . digit-string 22R415 exponent-letter is E 23 or D 49 J3/07-007 WORKING DRAFT 2006/01/05 1R416 exponent is signed-digit-string C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. 2 3C413 (R413) The value of kind-param shall specify an approximation method that exists on the 4 processor. 5A real literal constant without a kind type parameter is a default real constant if it is without an 6exponent part or has exponent letter E, and is a double precision real constant if it has exponent letter 7D. A real literal constant written with a kind type parameter is a real constant with the specified kind 8type parameter. 9The exponent represents the power of ten scaling to be applied to the significand or digit string. The 10meaning of these constants is as in decimal scientific notation. 11The significand may be written with more digits than a processor will use to approximate the value of 12the constant. NOTE 4.10 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 13 14The complex type has values that approximate the mathematical complex numbers. The values of a 15complex type are ordered pairs of real values. The first real value is called the real part, and the second 16real value is called the imaginary part. 17Each approximation method used to represent data entities of type real shall be available for both the 18real and imaginary parts of a data entity of type complex. A kind type parameter may be specified for 19a complex entity and selects for both parts the real approximation method characterized by this kind 20type parameter value; this kind type parameter is of type default integer. The kind type parameter of an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 21 22The type specifier for the complex type uses the keyword COMPLEX. There is no keyword for double 23precision complex. If the type keyword COMPLEX is specified and the kind type parameter is not 24specified, the default kind value is the same as that for default real, the type of both parts is default 25real, and the type specified is default complex. R417 complex-literal-constant is ( real-part , imag-part ) 26 27R418 real-part is signed-int-literal-constant 28 or signed-real-literal-constant 29 or named-constant 30R419 imag-part is signed-int-literal-constant 50 2006/01/05 WORKING DRAFT J3/07-007 1 or signed-real-literal-constant 2 or named-constant C414 (R417) Each named constant in a complex literal constant shall be of type integer or real. 3 4If the real part and the imaginary part of a complex literal constant are both real, the kind type 5parameter value of the complex literal constant is the kind type parameter value of the part with the 6greater decimal precision; if the precisions are the same, it is the kind type parameter value of one of the 7parts as determined by the processor. If a part has a kind type parameter value different from that of 8the complex literal constant, the part is converted to the approximation method of the complex literal 9constant. 10If both the real and imaginary parts are integer, they are converted to the default real approximation 11method and the constant is of type default complex. If only one of the parts is an integer, it is converted 12to the approximation method selected for the part that is real and the kind type parameter value of the 13complex literal constant is that of the part that is real. NOTE 4.11 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 14 154.4.5.1 Character sets 16The character type has a set of values composed of character strings. A character string is a sequence 17of characters, numbered from left to right 1, 2, 3, ... up to the number of characters in the string. The 18number of characters in the string is called the length of the string. The length is a type parameter; its 19kind is processor-dependent and its value is greater than or equal to zero. 20The processor shall provide one or more representation methods that define sets of values for data 21of type character. Each such method is characterized by a value for a type parameter called the kind 22type parameter; this kind type parameter is of type default integer. The kind type parameter of a rep- 23resentation method is returned by the intrinsic inquiry function KIND (13.7.96). The intrinsic function 24SELECTED CHAR KIND (13.7.152) returns a kind value based on the name of a character type. Any 25character of a particular representation method representable in the processor may occur in a character 26string of that representation method. 27The character set defined by ISO/IEC 646:1991 (International Reference Version) is referred to as the 28ASCII character set and its corresponding representation method is the ASCII character type. 29The character set defined by ISO/IEC 10646-1:2000 UCS-4 is referred to as the ISO 10646 character 30set and its corresponding representation method is the ISO 10646 character type. 314.4.5.2 Character type specifier 32The type specifier for the character type uses the keyword CHARACTER. 33If the kind type parameter is not specified, the default kind value is KIND ('A') and the type specified 34is default character. 51 J3/07-007 WORKING DRAFT 2006/01/05 1The default character kind shall support a character set that includes the Fortran character set. By 2supplying nondefault character kinds, the processor may support additional character sets. The charac- 3ters available in nondefault character kinds are not specified by this part of ISO/IEC 1539, except that 4one character in each nondefault character set shall be designated as a blank character to be used as a 5padding character. 6R420 char-selector is length-selector 7 or ( LEN = type-param-value , 8 KIND = scalar-int-initialization-expr ) 9 or ( type-param-value , 10 [ KIND = ] scalar-int-initialization-expr ) 11 or ( KIND = scalar-int-initialization-expr [ , LEN =type-param-value ] ) 12 13R421 length-selector is ( [ LEN = ] type-param-value ) 14 or * char-length [ , ] 15R422 char-length is ( type-param-value ) 16 or int-literal-constant 17C415 (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 18 resentation method that exists on the processor. C416 (R422) The int-literal-constant shall not include a kind-param. 19 C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr. 20 C418 (R420 R421 R422) A type-param-value of * shall be used only 21 (1) to declare a dummy argument, 22 (2) to declare a named constant, 23 24 (3) in the type-spec of an ALLOCATE statement wherein each allocate-object is a dummy 25 argument of type CHARACTER with an assumed character length, (4) in the type-spec or derived-type-spec of a type guard statement (8.1.9), or 26 (5) 27 in an external function, to declare the character length parameter of the function result. 28C419 A function name shall not be declared with an asterisk type-param-value unless it is of type CHAR- 29 ACTER and is the name of the result of an external function or the name of a dummy function. 30C420 A function name declared with an asterisk type-param-value shall not be an array, a pointer, elemental, recursive, 31 or pure. 32C421 (R421) The optional comma in a length-selector is permitted only in a declaration-type-spec in a type-declaration- 33 stmt. 34C422 (R421) The optional comma in a length-selector is permitted only if no double-colon separator appears in the 35 type-declaration-stmt. 36C423 (R420) The length specified for a character statement function or for a statement function dummy argument of 37 type character shall be an initialization expression. 38The char-selector in a CHARACTER intrinsic-type-spec and the * char-length in an entity-decl or in 39a component-decl of a type definition specify character length. The * char-length in an entity-decl or 40a component-decl specifies an individual length and overrides the length specified in the char-selector, 41if any. If a * char-length is not specified in an entity-decl or a component-decl, the length-selector or 42type-param-value specified in the char-selector is the character length. If the length is not specified in a 43char-selector or a * char-length, the length is 1. 52 2006/01/05 WORKING DRAFT J3/07-007 1If the character length parameter value evaluates to a negative value, the length of character entities 2declared is zero. A character length parameter value of : indicates a deferred type parameter (4.2). A 3char-length type parameter value of * has the following meanings. 4 (1) If used to declare a dummy argument of a procedure, the dummy argument assumes the 5 length of the associated actual argument. (2) If used to declare a named constant, the length is that of the constant value. 6 7 (3) If used in the type-spec of an ALLOCATE statement, each allocate-object assumes its length 8 from the associated actual argument. 9 (4) If used in the type-spec of a type guard statement, the associating entity assumes its length 10 from the selector. 11 (5) If used to specify the character length parameter of a function result, any scoping unit invoking the function 12 shall declare the function name with a character length parameter value other than * or access such a 13 definition by host or use association. When the function is invoked, the length of the result variable in the 14 function is assumed from the value of this type parameter. 154.4.5.3 Character literal constant 16A character literal constant is written as a sequence of characters, delimited by either apostrophes 17or quotation marks. 18R423 char-literal-constant is [ kind-param ] ' [ rep-char ] ... ' or [ kind-param 19 ] " [ rep-char ] ... " 20C424 (R423) The value of kind-param shall specify a representation method that exists on the pro- 21 cessor. 22The optional kind type parameter preceding the leading delimiter specifies the kind type parameter of 23the character constant; if it is not present, the constant is of type default character. 24For the type character with kind kind-param, if present, and for type default character otherwise, a 25representable character, rep-char, is defined as follows. (1) In free source form, it is any graphic character in the processor-dependent character set. 26 27 (2) In fixed source form, it is any character in the processor-dependent character set. A processor may restrict 28 the occurrence of some or all of the control characters. NOTE 4.12 Fortran 77 allowed any character to occur in a character context. This part of ISO/IEC 1539 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 char- acters 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. 29The delimiting apostrophes or quotation marks are not part of the value of the character literal constant. 30An apostrophe character within a character constant delimited by apostrophes is represented by two 31consecutive apostrophes (without intervening blanks); in this case, the two apostrophes are counted as 32one character. Similarly, a quotation mark character within a character constant delimited by quotation 33marks is represented by two consecutive quotation marks (without intervening blanks) and the two 34quotation marks are counted as one character. 35A zero-length character literal constant is represented by two consecutive apostrophes (without inter- 53 J3/07-007 WORKING DRAFT 2006/01/05 1vening blanks) or two consecutive quotation marks (without intervening blanks) outside of a character 2context. 3The intrinsic operation concatenation (//) is defined between two data entities of type character (7.1.5.3) with the same kind type parameter. 4 NOTE 4.13 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.14 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". 54.4.5.4 Collating sequence 6The processor defines a collating sequence for the character set of each kind of character. A collating 7sequence is a one-to-one mapping of the characters into the nonnegative integers such that each charac- 8ter corresponds to a different nonnegative integer. The intrinsic functions CHAR (13.7.30) and ICHAR (13.7.84) provide conversions between the characters and the integers according to this mapping. 9 NOTE 4.15 For example: ICHAR ( 'X' ) returns the integer value of the character 'X' according to the collating sequence of the processor. 10The collating sequence of the default character type shall satisfy the following constraints. (1) ICHAR ('A') < ICHAR ('B') < ... < ICHAR ('Z') for the twenty-six upper-case letters. 11 (2) ICHAR ('0') < ICHAR ('1') < ... < ICHAR ('9') for the ten digits. 12 (3) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('A') or 13 ICHAR (' ') < ICHAR ('A') < ICHAR ('Z') < ICHAR ('0'). 14 (4) ICHAR ('a') < ICHAR ('b') < ... < ICHAR ('z') for the twenty-six lower-case letters. 15 (5) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('a') or 16 ICHAR (' ') < ICHAR ('a') < ICHAR ('z') < ICHAR ('0'). 17 18Except for blank, there are no constraints on the location of the special characters and underscore in 19the collating sequence, nor is there any specified collating sequence relationship between the upper-case 54 2006/01/05 WORKING DRAFT J3/07-007 1and lower-case letters. 2The collating sequence for the ASCII character type is as defined by ISO/IEC 646:1991 (International 3Reference Version); this collating sequence is called the ASCII collating sequence in this part of 4ISO/IEC 1539. The collating sequence for the ISO 10646 character type is as defined by ISO/IEC 510646-1:2000. NOTE 4.16 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. 6The intrinsic functions LGT, LGE, LLE, and LLT (13.7.101-13.7.104) provide comparisons between 7strings based on the ASCII collating sequence. International portability is guaranteed if the set of 8characters used is limited to the letters, digits, underscore, and special characters. 4.4.6 Logical type 9 10The logical type has two values, which represent true and false. 11The processor shall provide one or more representation methods for data of type logical. Each such 12method is characterized by a value for a type parameter called the kind type parameter; this kind type 13parameter is of type default integer. The kind type parameter of a representation method is returned by the intrinsic inquiry function KIND (13.7.96). 14 15The type specifier for the logical type uses the keyword LOGICAL. 16If the kind type parameter is not specified, the default kind value is KIND (.FALSE.) and the type 17specified is default logical. 18R424 logical-literal-constant is .TRUE. [ kind-param ] or .FALSE. [ kind-param ] 19 20C425 (R424) The value of kind-param shall specify a representation method that exists on the pro- 21 cessor. 22The optional kind type parameter specifies the kind type parameter of the logical constant; if it is not 23present, the constant is of type default logical. 24The intrinsic operations defined for data entities of logical type are negation (.NOT.), conjunction 25(.AND.), inclusive disjunction (.OR.), logical equivalence (.EQV.), and logical nonequivalence (.NEQV., 26.XOR.) as described in 7.1.5.4. There is also a set of intrinsically defined relational operators that 27compare the values of data entities of other types and yield a value of type default logical. These 28operations are described in 7.1.5.6. 4.4.7 Bits type 29 30The bits type has a set of values composed of ordered sequences of bits. The number of bits in 31the sequence is specified by the kind type parameter, which shall be greater than or equal to zero. 32The processor shall provide representation methods with kind type parameter values equal to every 33nonnegative integer less than or equal to a processor-determined limit. This limit shall be at least as 34large as the storage size, expressed in bits, of every supported kind of type integer, real, complex, and 35logical. Additional representation methods may be provided. 36The type specifier for the bits type uses the keyword BITS. 37If the kind type parameter is not specified for a bits variable, the default kind value is the size of a 55 J3/07-007 WORKING DRAFT 2006/01/05 1numeric storage unit expressed in bits, and the type specified is default bits. 2R425 bits-literal-constant is binary-constant [ kind-param ] 3 or octal-constant [ kind-param ] or hex-constant [ kind-param ] 4 5R426 binary-constant is B ' digit [ digit ] ... ' 6 or B " digit [ digit ] ... " C426 (R426) digit shall have one of the values 0 or 1. 7 8R427 octal-constant is O ' digit [ digit ] ... ' 9 or O " digit [ digit ] ... " C427 (R427) digit shall have one of the values 0 through 7. 10 11R428 hex-constant is Z ' hex-digit [ hex-digit ] ... ' 12 or Z " hex-digit [ hex-digit ] ... " 13R429 hex-digit is digit 14 or A 15 or B 16 or C 17 or D 18 or E 19 or F 20The hex-digits A through F represent the numbers ten through fifteen, respectively; they may be repre- 21sented by their lower-case equivalents. 22If the optional kind type parameter is not specified for a bits literal constant, the kind value is assumed 23from the form of the constant. If the constant is a binary-constant the kind value is the number 24of digit characters. If the constant is an octal-constant the kind value is three times the number of 25digit characters. If the constant is a hex-constant the kind value is four times the number of hex-digit 26characters. NOTE 4.17 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. 27Each digit of an octal constant represents three bits, and each hex digit of a hex constant represents 28four bits, according to their numerical representations as binary integers, with leading zero bits where 29needed. 30If a kind-param is specified for a bits literal constant and has a value greater than the number of bits 31specified by its digits, the constant is padded on the left (13.3) with enough zero bits to create a constant 32of kind kind-param. If the kind-param specified has a value smaller the number of bits specified by its 33digits, only the rightmost kind-param bits are used to determine the value of the constant and the 34remaining bits shall be zero. NOTE 4.18 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. 56 2006/01/05 WORKING DRAFT J3/07-007 4.5 Derived types 1 4.5.1 Derived type concepts 2 3Additional types may be derived from the intrinsic types and other derived types. A type definition is 4required to define the name of the type and the names and attributes of its components and type-bound 5procedures. 6A derived type may be parameterized by multiple type parameters, each of which is defined to be either 7a kind or length type parameter and may have a default value. 8The ultimate components of an object of derived type are the components that are of intrinsic type 9or have the POINTER or ALLOCATABLE attribute, plus the ultimate components of the components 10of the object that are of derived type and have neither the ALLOCATABLE nor POINTER attribute. NOTE 4.19 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 11The direct components of an object of derived type are the components of that object, plus the direct 12components of the components of the object that are of derived type and have neither the ALLOCAT- 13ABLE nor POINTER attribute. 14By default, no storage sequence is implied by the order of the component definitions. However, a storage 15order is implied for a sequence type (4.5.2.3). If the derived type has the BIND attribute, the storage sequence is that required by the companion processor (2.5.10, 15.3.4). 16 17A scalar entity of derived type is a structure. If a derived type has the SEQUENCE property, a scalar 18entity of the type is a sequence structure. 4.5.2 Derived-type definition 19 204.5.2.1 Syntax 21R430 derived-type-def is derived-type-stmt 22 [ type-param-def-stmt ] ... 23 [ private-or-sequence ] ... 24 [ component-part ] 25 [ type-bound-procedure-part ] 26 end-type-stmt 27R431 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name [ ( type-param-name-list ) ] 28 29R432 type-attr-spec is ABSTRACT 57 J3/07-007 WORKING DRAFT 2006/01/05 1 or access-spec 2 or BIND (C) or EXTENDS ( parent-type-name ) 3 4C428 (R431) A derived type type-name shall not be DOUBLEPRECISION or the same as the name of any intrinsic type defined in this part of ISO/IEC 1539. 5 C429 (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt. 6 C430 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). 7 8C431 (R430) If the type definition contains or inherits (4.5.7.2) a deferred binding (4.5.5), ABSTRACT 9 shall appear. C432 (R430) If ABSTRACT appears, the type shall be extensible. 10 C433 (R430) If EXTENDS appears, SEQUENCE shall not appear. 11 12C434 (R430) If EXTENDS appears and the type being defined has a co-array ultimate component, 13 its parent type shall have a co-array ultimate component. 14R433 private-or-sequence is private-components-stmt 15 or sequence-stmt 16C435 (R430) The same private-or-sequence shall not appear more than once in a given derived-type- 17 def . R434 end-type-stmt is END TYPE [ type-name ] 18 19C436 (R434) If END TYPE is followed by a type-name, the type-name shall be the same as that in 20 the corresponding derived-type-stmt. 21Derived types with the BIND attribute are subject to additional constraints as specified in 15.3.4. NOTE 4.20 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 224.5.2.2 Accessibility 23Types that are defined in a module or accessible in that module by use association have either the 24PUBLIC or PRIVATE attribute. Types for which an access-spec is not explicitly specified in that 25module have the default accessibility attribute for that module. The default accessibility attribute for a 26module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only types that have 27the PUBLIC attribute in that module are available to be accessed from that module by use association. 28The accessibility of a type does not affect, and is not affected by, the accessibility of its components and 29bindings. 58 2006/01/05 WORKING DRAFT J3/07-007 1If a type definition is private, then the type name, and thus the structure constructor (4.5.10) for the 2type, are accessible only within the module containing the definition, and within its descendants. NOTE 4.21 An example of a type with a private name is: TYPE, PRIVATE :: AUXILIARY LOGICAL :: DIAGNOSTIC 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. 34.5.2.3 Sequence type 4R435 sequence-stmt is SEQUENCE 5C437 (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type 6 or of a sequence derived type. C438 (R430) If SEQUENCE appears, a type-bound-procedure-part shall not appear. 7 8If the SEQUENCE statement appears, the type is a sequence type. The order of the component 9definitions in a sequence type specifies a storage sequence for objects of that type. The type is a 10numeric sequence type if there are no type parameters, no pointer or allocatable components, and 11each component is of type default integer, default real, double precision real, default complex, default 12logical, default bits, or a numeric sequence type. The type is a character sequence type if there 13are no type parameters, no pointer or allocatable components, and each component is of type default 14character or a character sequence type. NOTE 4.22 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.23 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 59 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.23 (cont.) as best suited to the particular architecture. 14.5.2.4 Determination of derived types 2Derived-type definitions with the same type name may appear in different scoping units, in which case 3they may be independent and describe different derived types or they may describe the same type. 4Two data entities have the same type if they are declared with reference to the same derived-type 5definition. The definition may be accessed from a module or from a host scoping unit. Data entities in 6different scoping units also have the same type if they are declared with reference to different derived-type 7definitions that specify the same type name, all have the SEQUENCE property or all have the BIND 8attribute, have no components with PRIVATE accessibility, and have type parameters and components 9that agree in order, name, and attributes. Otherwise, they are of different derived types. A data entity 10declared using a type with the SEQUENCE property or with the BIND attribute is not of the same type 11as an entity of a type declared to be PRIVATE or that has any components that are PRIVATE. NOTE 4.24 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.25 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 60 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.25 (cont.) 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 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.26 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 24.5.3.1 Type parameter definition statement 3R436 type-param-def-stmt is INTEGER [ kind-selector ] , type-param-attr-spec :: 4 type-param-decl-list R437 type-param-decl is type-param-name [ = scalar-int-initialization-expr ] 5 6C439 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the 7 type-param-names in the derived-type-stmt of that derived-type-def . 8C440 (R436) Each type-param-name in the derived-type-stmt in a derived-type-def shall appear as a 9 type-param-name in a type-param-def-stmt in that derived-type-def . 10R438 type-param-attr-spec is KIND 11 or LEN 12The derived type is parameterized if the derived-type-stmt has any type-param-names. 13Each type parameter is itself of type integer. If its kind selector is omitted, the kind type parameter is 14default integer. 15The type-param-attr-spec explicitly specifies whether a type parameter is a kind parameter or a length 16parameter. 17If a type-param-decl has a scalar-int-initialization-expr, the type parameter has a default value which 18is specified by the expression. If necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value of the same kind as the type parameter. 19 20A type parameter may be used as a primary in a specification expression (7.1.11) in the derived-type- 21def . A kind type parameter may also be used as a primary in an initialization expression (7.1.12) in the 22derived-type-def . 61 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.27 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) 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 14.5.3.2 Type parameter order 2Type parameter order is an ordering of the type parameters of a derived type; it is used for derived- 3type specifiers. 4The type parameter order of a nonextended type is the order of the type parameter list in the derived- 5type definition. The type parameter order of an extended type (4.5.7 consists of the type parameter 6order of its parent type followed by any additional type parameters in the order of the type parameter 7list in the derived-type definition. NOTE 4.28 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 94.5.4.1 Component definition statement R439 component-part is [ component-def-stmt ] ... 10 11R440 component-def-stmt is data-component-def-stmt 12 or proc-component-def-stmt 13R441 data-component-def-stmt is declaration-type-spec [ [ , component-attr-spec-list ] :: ] 14 component-decl-list 62 2006/01/05 WORKING DRAFT J3/07-007 1R442 component-attr-spec is access-spec 2 or ALLOCATABLE 3 or DIMENSION ( component-array-spec ) 4 or DIMENSION [ ( deferred-shape-spec-list ) ] 5 lbracket co-array-spec rbracket 6 or CONTIGUOUS 7 or POINTER 8R443 component-decl is component-name [ ( component-array-spec ) ] 9 [ lbracket co-array-spec rbracket ] [ * char-length ] [ component-initialization ] 10 11R444 component-array-spec is explicit-shape-spec-list 12 or deferred-shape-spec-list 13 C441 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt. 14 15C442 (R441) If neither the POINTER nor ALLOCATABLE attribute is specified, the declaration-type- 16 spec in the component-def-stmt shall specify an intrinsic type or a previously defined derived 17 type. 18C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in 19 the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible 20 derived type including the type being defined. 21C444 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec 22 shall be a deferred-shape-spec-list. 23C445 (R441) If a co-array-spec appears, it shall be a deferred-co-shape-spec-list and the component 24 shall have the ALLOCATABLE attribute. 25C446 (R441) If a co-array-spec appears, the component shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 26 27C447 A data component whose type has a co-array ultimate component shall be a nonpointer nonal- 28 locatable scalar and shall not be a co-array. 29C448 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each 30 component-array-spec shall be an explicit-shape-spec-list. 31C449 (R444) Each bound in the explicit-shape-spec shall either be an initialization expression or be a 32 specification expression that does not contain references to specification functions or any object 33 designators other than named constants or subobjects thereof. 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... 63 J3/07-007 WORKING DRAFT 2006/01/05 C450 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. 1 2C451 (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the 3 POINTER attribute. C452 (R443) The * char-length option is permitted only if the component is of type character. 4 5C453 (R440) Each type-param-value within a component-def-stmt shall either be a colon, be an ini- 6 tialization expression, or be a specification expression that contains neither references to speci- 7 fication functions nor any object designators other than named constants or subobjects thereof. NOTE 4.29 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. 8R445 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , 9 proc-component-attr-spec-list :: proc-decl-list NOTE 4.30 See 12.4.3.6 for definitions of proc-interface and proc-decl. 10R446 proc-component-attr-spec is POINTER 11 or PASS [ (arg-name) ] 12 or NOPASS 13 or access-spec 14C454 (R445) The same proc-component-attr-spec shall not appear more than once in a given proc- 15 component-def-stmt. C455 (R445) POINTER shall appear in each proc-component-attr-spec-list. 16 17C456 (R445) If the procedure pointer component has an implicit interface or has no arguments, 18 NOPASS shall be specified. 19C457 (R445) If PASS (arg-name) appears, the interface shall have a dummy argument named arg- 20 name. C458 (R445) PASS and NOPASS shall not both appear in the same proc-component-attr-spec-list. 21 224.5.4.2 Array components 23A data component is an array if its component-decl contains a component-array-spec or its data-compo- 24nent-def-stmt contains the DIMENSION clause with a component-array-spec. If the component-decl 25contains a component-array-spec, it specifies the array rank, and if the array is explicit shape (5.3.7.2), 26the array bounds; otherwise, the component-array-spec in the DIMENSION clause specifies the array 27rank, and if the array is explicit shape, the array bounds. 28A data component is a co-array if its component-decl contains a co-array-spec or its data-component-def- 29stmt contains a DIMENSION clause with a co-array-spec. If the component-decl contains a co-array-spec 30it specifies the co-rank; otherwise, the co-array-spec in the DIMENSION clause specifies the co-rank. NOTE 4.31 An example of a derived type definition with an array component is: 64 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.31 (cont.) 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 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.32 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.33 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. 14.5.4.3 Pointer components 2A component is a pointer (2.4.7) if its component-attr-spec-list contains the POINTER attribute. A 3pointer component may be a data pointer or a procedure pointer. NOTE 4.34 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 65 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.34 (cont.) 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.2.2). 14.5.4.4 The passed-object dummy argument 2A passed-object dummy argument is a distinguished dummy argument of a procedure pointer 3component or type-bound procedure. It affects procedure overriding (4.5.7.3) and argument association (12.5.2.2). 4 5If NOPASS is specified, the procedure pointer component or type-bound procedure has no passed-object 6dummy argument. 7If neither PASS nor NOPASS is specified or PASS is specified without arg-name, the first dummy argu- 8ment of a procedure pointer component or type-bound procedure is its passed-object dummy argument. 9If PASS (arg-name) is specified, the dummy argument named arg-name is the passed-object dummy 10argument of the procedure pointer component or named type-bound procedure. 11C459 The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy data 12 object with the same declared type as the type being defined; all of its length type parameters 13 shall be assumed; it shall be polymorphic (4.3.1.3) if and only if the type being defined is extensible (4.5.7). It shall not have the VALUE attribute. 14 NOTE 4.35 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. 154.5.4.5 Default initialization for components 16Default initialization provides a means of automatically initializing pointer components to be disassoci- 17ated or associated with specific targets, and nonpointer nonallocatable components to have a particular 18value. Allocatable components are always initialized to not allocated. 19A pointer variable or component is data-pointer-initialization compatible with a target if the pointer 20is type compatible with the target, they have the same rank, and the values of corresponding nondeferred 21type parameters are specified by initialization expressions that have the same value. 22R447 component-initialization is = initialization-expr 23 or => null-init 24 or => initial-data-target 25R448 initial-data-target is designator 26C460 (R441) If component-initialization appears, a double-colon separator shall appear before the 27 component-decl-list. 28C461 (R441) If component-initialization appears, every type parameter and array bound of the com- 29 ponent shall be a colon or initialization expression. 30C462 (R441) If => appears in component-initialization, POINTER shall appear in the component- 31 attr-spec-list. If = appears in component-initialization, neither POINTER nor ALLOCATABLE 32 shall appear in the component-attr-spec-list. 66 2006/01/05 WORKING DRAFT J3/07-007 1C463 (R447) If initial-data-target appears, component-name shall be data-pointer-initialization com- 2 patible with it. 3C464 (R448) The designator shall designate a variable that is an initialization target. Every subscript, 4 section subscript, substring starting point, and substring ending point in designator shall be an 5 initialization expression. 6If null-init appears for a pointer component, that component in any object of the type has an initial association status of disassociated (16.5.2.2) or becomes disassociated as specified in 16.5.2.2.2. 7 8A variable is an initialization target if it has the TARGET attribute, either has the SAVE attribute 9or is declared in the main program, and does not have the ALLOCATABLE attribute. 10If initial-data-target appears for a data pointer component, that component in any object of the type is 11initially associated with the target or becomes associated with the target as specified in 16.5.2.2.1. 12If initial-proc-target (12.4.3.6) appears in proc-decl for a procedure pointer component, that component 13in any object of the type is initially associated with the target or becomes associated with the target as 14specified in 16.5.2.2.1. 15If initialization-expr appears for a nonpointer component, that component in any object of the type 16is initially defined (16.6.3) or becomes defined as specified in 16.6.5 with the value determined from 17initialization-expr. If necessary, the value is converted according to the rules of intrinsic assignment 18(7.2.1.3) to a value that agrees in type, type parameters, and shape with the component. If the compo- 19nent is of a type for which default initialization is specified for a component, the default initialization 20specified by initialization-expr overrides the default initialization specified for that component. When 21one initialization overrides another it is as if only the overriding initialization were specified (see Note 224.37). Explicit initialization in a type declaration statement (5.2) overrides default initialization (see 23Note 4.36). Unlike explicit initialization, default initialization does not imply that the object has the 24SAVE attribute. 25A subcomponent (6.1.2) is default-initialized if the type of the object of which it is a component 26specifies default initialization for that component, and the subcomponent is not a subobject of an object 27that is default-initialized or explicitly initialized. NOTE 4.36 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.37 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.36: TYPE SINGLE_SCORE 67 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.37 (cont.) 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.38 Arrays of structures may be declared with elements that are partially or totally initialized by default. Continuing the example of Note 4.37 : TYPE MEMBER (NAME_LEN) 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.39 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.40 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 68 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.40 (cont.) TYPE(NODE), SAVE, TARGET :: SENTINEL 14.5.4.6 Component order 2Component order is an ordering of the nonparent components of a derived type; it is used for intrinsic 3formatted input/output and structure constructors (where component keywords are not used). Parent components are excluded from the component order of an extended type (4.5.7). 4 5The component order of a nonextended type is the order of the declarations of the components in the 6derived-type definition. The component order of an extended type consists of the component order of 7its parent type followed by any additional components in the order of their declarations in the extended 8derived-type definition. NOTE 4.41 Given the same type definitions as in Note 4.28, 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. 94.5.4.7 Component accessibility 10R449 private-components-stmt is PRIVATE 11C465 (R449) A private-components-stmt is permitted only if the type definition is within the specifi- 12 cation part of a module. 13The default accessibility for the components that are declared in a type's component-part is private 14if the type definition contains a private-components-stmt, and public otherwise. The accessibility of a 15component may be explicitly declared by an access-spec; otherwise its accessibility is the default for the 16type definition in which it is declared. 17If a component is private, that component name is accessible only within the module containing the 18definition, and within its descendants. NOTE 4.42 Type parameters are not components. They are effectively always public. NOTE 4.43 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.44 An example of a type with private components is: TYPE POINT PRIVATE REAL :: X, Y END TYPE POINT 69 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.44 (cont.) 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.45 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 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 2R450 type-bound-procedure-part is contains-stmt 3 [ binding-private-stmt ] [ type-bound-proc-binding ] ... 4 5R451 binding-private-stmt is PRIVATE 6C466 (R450) A binding-private-stmt is permitted only if the type definition is within the specification 7 part of a module. 8R452 type-bound-proc-binding is type-bound-procedure-stmt 9 or type-bound-generic-stmt 10 or final-procedure-stmt 11R453 type-bound-procedure-stmt is PROCEDURE [ [ , binding-attr-list ] :: ] 12 binding-name [ => procedure-name ] 13 or PROCEDURE (interface-name) 14 , binding-attr-list :: binding-name C467 (R453) If => procedure-name appears, the double-colon separator shall appear. 15 16C468 (R453) The procedure-name shall be the name of an accessible module procedure or an external 17 procedure that has an explicit interface. 18If neither => procedure-name nor interface-name appears, it is as though => procedure-name had 19appeared with a procedure name the same as the binding name. 20R454 type-bound-generic-stmt is GENERIC [, access-spec ] :: generic-spec => binding-name-list 21 22C469 (R454) Within the specification-part of a module, each type-bound-generic-stmt shall specify, 23 either implicitly or explicitly, the same accessibility as every other type-bound-generic-stmt with 24 that generic-spec in the same derived type. 70 2006/01/05 WORKING DRAFT J3/07-007 1C470 (R454) Each binding-name in binding-name-list shall be the name of a specific binding of the 2 type. 3C471 (R454) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object dummy argument (4.5.4.4). 4 5C472 (R454) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall 6 be as specified in 12.4.3.4.2. 7C473 (R454) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified 8 in 12.4.3.4.3. 9C474 (R454) If generic-spec is dtio-generic-spec, the interface of each binding shall be as specified in 10 9.5.4.7. The type of the dtv argument shall be type-name. 11R455 binding-attr is PASS [ (arg-name) ] 12 or NOPASS 13 or NON OVERRIDABLE 14 or DEFERRED 15 or access-spec C475 (R455) The same binding-attr shall not appear more than once in a given binding-attr-list. 16 17C476 (R453) If the interface of the binding has no dummy argument of the type being defined, 18 NOPASS shall appear. 19C477 (R453) If PASS (arg-name) appears, the interface of the binding shall have a dummy argument 20 named arg-name. C478 (R455) PASS and NOPASS shall not both appear in the same binding-attr-list. 21 22C479 (R455) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- 23 attr-list. C480 (R455) DEFERRED shall appear if and only if interface-name appears. 24 25C481 (R453) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding 26 it overrides is deferred. 27C482 (R453) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- 28 RIDABLE attribute. 29A type-bound procedure statement declares a specific type-bound procedure. A specific type- 30bound procedure may have a passed-object dummy argument (4.5.4.4). A binding that specifies the 31DEFERRED attribute is a deferred binding. A deferred binding shall appear only in the definition 32of an abstract type. 33A GENERIC statement declares a type-bound generic interface for its specific type-bound procedures. 34A binding of a type is a specific type-bound procedure, a generic type-bound interface, or a final 35subroutine. These are referred to as specific bindings, generic bindings, and final bindings respectively. 36A type-bound procedure may be identified by a binding name in the scope of the type definition. 37This name is the binding-name for a specific binding, and the generic-name for a generic binding whose 38generic-spec is generic-name. A final binding, or a generic binding whose generic-spec is not generic- 39name, has no binding name. 40The interface of a specific binding is that of the procedure specified by procedure-name or the interface 71 J3/07-007 WORKING DRAFT 2006/01/05 1specified by interface-name. NOTE 4.46 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 2The same generic-spec may be used in several GENERIC statements within a single derived-type defi- 3nition. Each additional GENERIC statement with the same generic-spec extends the generic interface. NOTE 4.47 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). 4The default accessibility for the procedure bindings of a type is private if the type definition contains a 5binding-private-stmt, and public otherwise. The accessibility of a procedure binding may be explicitly 6declared by an access-spec; otherwise its accessibility is the default for the type definition in which it is 7declared. 8A public type-bound procedure is accessible via any accessible object of the type. A private type-bound 9procedure is accessible only within the module containing the type definition, and within its descendants. NOTE 4.48 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. 104.5.6 Final subroutines 114.5.6.1 Declaration R456 final-procedure-stmt is FINAL [ :: ] final-subroutine-name-list 12 13C483 (R456) A final-subroutine-name shall be the name of a module procedure with exactly one 14 dummy argument. That argument shall be nonoptional and shall be a nonpointer, nonallocat- 15 able, nonpolymorphic variable of the derived type being defined. All length type parameters of the dummy argument shall be assumed. The dummy argument shall not have INTENT(OUT). 16 17C484 (R456) A final-subroutine-name shall not be one previously specified as a final subroutine for 18 that type. 72 2006/01/05 WORKING DRAFT J3/07-007 1C485 (R456) A final subroutine shall not have a dummy argument with the same kind type parameters 2 and rank as the dummy argument of another final subroutine of that type. 3The FINAL statement specifies that each procedure it names is a final subroutine. A final subroutine might be executed when a data entity of that type is finalized (4.5.6.2). 4 5A derived type is finalizable if it has any final subroutines or if it has any nonpointer, nonallocatable 6component whose type is finalizable. A nonpointer data entity is finalizable if its type is finalizable. NOTE 4.49 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.50 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. 74.5.6.2 The finalization process 8Only finalizable entities are finalized. When an entity is finalized, the following steps are carried out 9in sequence. 10 (1) If the dynamic type of the entity has a final subroutine whose dummy argument has the 11 same kind type parameters and rank as the entity being finalized, it is called with the entity 12 as an actual argument. Otherwise, if there is an elemental final subroutine whose dummy 13 argument has the same kind type parameters as the entity being finalized, it is called with 14 the entity as an actual argument. Otherwise, no subroutine is called at this point. 15 (2) All finalizable components that appear in the type definition are finalized in a processor- 16 dependent order. If the entity being finalized is an array, each finalizable component of each 17 element of that entity is finalized separately. 18 (3) If the entity is of extended type and the parent type is finalizable, the parent component is 19 finalized. 20If several entities are to be finalized as a consequence of an event specified in 4.5.6.3, the order in which 21they are finalized is processor-dependent. A final subroutine shall not reference or define an object that 22has already been finalized. 23If an object is not finalized, it retains its definition status and does not become undefined. 244.5.6.3 When finalization occurs 25When a pointer is deallocated its target is finalized. When an allocatable entity is deallocated, it is 26finalized. 27A nonpointer, nonallocatable object that is not a dummy argument or function result is finalized im- 28mediately before it would become undefined due to execution of a RETURN or END statement (16.6.6, item (3)). 29 30A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it would become undefined due to termination of the BLOCK construct (16.6.6, item (20)). 31 32If an executable construct references a function, the result is finalized after execution of the innermost 33executable construct containing the reference. 73 J3/07-007 WORKING DRAFT 2006/01/05 1If an executable construct references a structure constructor or array constructor, the entity created by 2the constructor is finalized after execution of the innermost executable construct containing the reference. 3If a specification expression in a scoping unit references a function, the result is finalized before execution 4of the executable constructs in the scoping unit. 5If a specification expression in a scoping unit references a structure constructor or array constructor, the 6entity created by the constructor is finalized before execution of the executable constructs in the scoping 7unit. 8When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. 9 10When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr 11and before the definition of the variable. NOTE 4.51 If finalization is used for storage management, it often needs to be combined with defined assign- ment. 12If an object is allocated via pointer allocation and later becomes unreachable due to all pointers to that 13object having their pointer association status changed, it is processor dependent whether it is finalized. 14If it is finalized, it is processor dependent as to when the final subroutines are called. 154.5.6.4 Entities that are not finalized 16If image execution is terminated, either by an error (e.g. an allocation failure) or by execution of a STOP 17or END PROGRAM statement, entities existing immediately prior to termination are not finalized. NOTE 4.52 A nonpointer, nonallocatable object that has the SAVE attribute or that is declared in the main program, a module, or a submodule 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 18 194.5.7.1 Concepts 20A nonsequence derived type that does not have the BIND attribute is an extensible type. 21An extensible type that does not have the EXTENDS attribute is a base type. A type that has the 22EXTENDS attribute is an extended type. The parent type of an extended type is the type named 23in the EXTENDS attribute specification. NOTE 4.53 The name of the parent type might be a local name introduced via renaming in a USE statement. 24A base type is an extension type of itself only. An extended type is an extension of itself and of all 25types for which its parent type is an extension. 26An abstract type is a type that has the ABSTRACT attribute. 74 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.54 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. 14.5.7.2 Inheritance 2An extended type includes all of the type parameters, all of the components, and the nonoverridden 3(4.5.7.3) nonfinal procedure bindings of its parent type. These are inherited by the extended type from 4the parent type. They retain all of the attributes that they had in the parent type. Additional type 5parameters, components, and procedure bindings may be declared in the derived-type definition of the 6extended type. NOTE 4.55 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.56 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. 7An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and 8type parameters of the parent type. The name of this component is the parent type name. It has the 9accessibility of the parent type. Components of the parent component are inheritance associated 10(16.5.4) with the corresponding components inherited from the parent type. An ancestor component 11of a type is the parent component of the type or an ancestor component of the parent component. NOTE 4.57 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.58 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 75 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.58 (cont.) END TYPE COLOR_POINT 14.5.7.3 Type-bound procedure overriding 2If a nongeneric binding specified in a type definition has the same binding name as a binding from the 3parent type then the binding specified in the type definition overrides the one from the parent type. 4The overriding binding and the overridden binding shall satisfy the following conditions. (1) Either both shall have a passed-object dummy argument or neither shall. 5 (2) If the overridden binding is pure then the overriding binding shall also be pure. 6 (3) Either both shall be elemental or neither shall. 7 (4) They shall have the same number of dummy arguments. 8 (5) Passed-object dummy arguments, if any, shall correspond by name and position. 9 10 (6) Dummy arguments that correspond by position shall have the same names and characteris- 11 tics, except for the type of the passed-object dummy arguments. 12 (7) Either both shall be subroutines or both shall be functions having the same result charac- teristics (12.3.3). 13 (8) If the overridden binding is PUBLIC then the overriding binding shall not be PRIVATE. 14 NOTE 4.59 The following is an example of procedure overriding, expanding on the example in Note 4.46. 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 15If a generic binding specified in a type definition has the same generic-spec as an inherited binding, it 16extends the generic interface and shall satisfy the requirements specified in 12.4.3.4.5. 17A binding of a type and a binding of an extension of that type correspond if the latter binding is the 18same binding as the former, overrides a corresponding binding, or is an inherited corresponding binding. 4.5.8 Derived-type values 19 76 2006/01/05 WORKING DRAFT J3/07-007 1The component value of (1) a pointer component is its pointer association, 2 3 (2) an allocatable component is its allocation status and, if it is allocated, its dynamic type and 4 type parameters, bounds and value, and (3) a nonpointer nonallocatable component is its value. 5 6The set of values of a particular derived type consists of all possible sequences of the component values 7of its components. 4.5.9 Derived-type specifier 8 9A derived-type specifier is used in several contexts to specify a particular derived type and type param- 10eters. R457 derived-type-spec is type-name [ ( type-param-spec-list ) ] 11 R458 type-param-spec is [ keyword = ] type-param-value 12 C486 (R457) type-name shall be the name of an accessible derived type. 13 C487 (R457) type-param-spec-list shall appear only if the type is parameterized. 14 15C488 (R457) There shall be at most one type-param-spec corresponding to each parameter of the type. 16 If a type parameter does not have a default value, there shall be a type-param-spec corresponding 17 to that type parameter. 18C489 (R458) The keyword= may be omitted from a type-param-spec only if the keyword= has been 19 omitted from each preceding type-param-spec in the type-param-spec-list. C490 (R458) Each keyword shall be the name of a parameter of the type. 20 21C491 (R458) An asterisk may be used as a type-param-value in a type-param-spec only in the decla- 22 ration of a dummy argument or associate name or in the allocation of a dummy argument. 23Type parameter values that do not have type parameter keywords specified correspond to type param- 24eters in type parameter order (4.5.3.2). If a type parameter keyword is present, the value is assigned to 25the type parameter named by the keyword. If necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value of the same kind as the type parameter. 26 27The value of a type parameter for which no type-param-value has been specified is its default value. 4.5.10 Construction of derived-type values 28 29A derived-type definition implicitly defines a corresponding structure constructor that allows con- 30struction of values of that derived type. The type and type parameters of a constructed value are 31specified by a derived type specifier. R459 structure-constructor is derived-type-spec ( [ component-spec-list ] ) 32 R460 component-spec is [ keyword = ] component-data-source 33 34R461 component-data-source is expr 35 or data-target 36 or proc-target C492 (R459) The derived-type-spec shall not specify an abstract type (4.5.7). 37 77 J3/07-007 WORKING DRAFT 2006/01/05 C493 (R459) At most one component-spec shall be provided for a component. 1 2C494 (R459) If a component-spec is provided for an ancestor component, a component-spec shall not 3 be provided for any component that is inheritance associated with a subcomponent of that 4 ancestor component. 5C495 (R459) A component-spec shall be provided for a nonallocatable component unless it has default 6 initialization or is inheritance associated with a subcomponent of another component for which 7 a component-spec is provided. 8C496 (R460) The keyword= may be omitted from a component-spec only if the keyword= has been 9 omitted from each preceding component-spec in the constructor. C497 (R460) Each keyword shall be the name of a component of the type. 10 11C498 (R459) The type name and all components of the type for which a component-spec appears shall 12 be accessible in the scoping unit containing the structure constructor. 13C499 (R459) If derived-type-spec is a type name that is the same as a generic name, the component- 14 spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (12.5.5.2). 15 16C4100 (R461) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall 17 correspond to a procedure pointer component. C4101 (R461) A data-target shall have the same rank as its corresponding component. 18 NOTE 4.60 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. 19In the absence of a component keyword, each component-data-source is assigned to the corresponding 20component in component order (4.5.4.6). If a component keyword appears, the expr is assigned to the 21component named by the keyword. For a nonpointer component, the declared type and type parameters 22of the component and expr shall conform in the same way as for a variable and expr in an intrinsic 23assignment statement (7.2.1.2), as specified in Table 7.12. If necessary, each value of intrinsic type is 24converted according to the rules of intrinsic assignment (7.2.1.3) to a value that agrees in type and type 25parameters with the corresponding component of the derived type. For a nonpointer nonallocatable 26component, the shape of the expression shall conform with the shape of the component. 27If a component with default initialization has no corresponding component-data-source, then the default 28initialization is applied to that component. If an allocatable component has no corresponding component- 29data-source, then that component has an allocation status of unallocated. NOTE 4.61 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.58: ! 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) 78 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.61 (cont.) ! has private components COLOR_POINT( 1, 2, 3) ! All components of TYPE(point) ! need to be accessible. 1A structure constructor shall not appear before the referenced type is defined. NOTE 4.62 This example illustrates a derived-type constant expression using a derived type defined in Note 4.20: PERSON (21, 'JOHN SMITH') This could also be written as PERSON (NAME = 'JOHN SMITH', AGE = 21) NOTE 4.63 An example constructor using the derived type GENERAL POINT defined in Note 4.27 is general_point(dim=3) ( [ 1., 2., 3. ] ) 2For a pointer component, the corresponding component-data-source shall be an allowable data-target or 3proc-target for such a pointer in a pointer assignment statement (7.2.2). If the component data source is 4a pointer, the association of the component is that of the pointer; otherwise, the component is pointer 5associated with the component data source. NOTE 4.64 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.34 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. 6If a component of a derived type is allocatable, the corresponding constructor expression shall either be 7a reference to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, 8or shall evaluate to an entity of the same rank. If the expression is a reference to the intrinsic function 9NULL, the corresponding component of the constructor has a status of unallocated. If the expression 10is an allocatable entity, the corresponding component of the constructor has the same allocation status 11as that allocatable entity and, if it is allocated, the same dynamic type, bounds, and value; if a length 12parameter of the component is deferred, its value is the same as the corresponding parameter of the 79 J3/07-007 WORKING DRAFT 2006/01/05 1expression. Otherwise the corresponding component of the constructor has an allocation status of 2allocated and has the same bounds and value as the expression. NOTE 4.65 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 3 4Intrinsic assignment of derived-type entities is described in 7.2.1. This part of ISO/IEC 1539 does 5not specify any intrinsic operations on derived-type entities. Any operation on derived-type entities 6or defined assignment (7.2.1.4) for derived-type entities shall be defined explicitly by a function or a subroutine, and a generic interface (4.5.2, 12.4.3.2). 7 84.6 Enumerations and enumerators 9An enumeration is a set of enumerators. An enumerator is a named integer constant. An enumeration 10definition specifies the enumeration and its set of enumerators of the corresponding integer kind. 11R462 enum-def is enum-def-stmt 12 enumerator-def-stmt 13 [ enumerator-def-stmt ] ... 14 end-enum-stmt R463 enum-def-stmt is ENUM, BIND(C) 15 R464 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator-list 16 R465 enumerator is named-constant [ = scalar-int-initialization-expr ] 17 18R466 end-enum-stmt is END ENUM 19C4102 (R464) If = appears in an enumerator, a double-colon separator shall appear before the enu- 20 merator-list. 21For an enumeration, the kind is selected such that an integer type with that kind is interoperable (15.3.2) 22with the corresponding C enumeration type. The corresponding C enumeration type is the type that 23would be declared by a C enumeration specifier (6.7.2.2 of the C International Standard) that specified 24C enumeration constants with the same values as those specified by the enum-def , in the same order as 25specified by the enum-def . 26The companion processor (2.5.10) shall be one that uses the same representation for the types declared 27by all C enumeration specifiers that specify the same values in the same order. NOTE 4.66 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 types of any such enumerators will be interoperable with the type declared in the C enumeration. NOTE 4.67 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 80 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.67 (cont.) integer type that is interoperable with the corresponding C enumerated type. NOTE 4.68 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. 1An enumerator is treated as if it were explicitly declared with the PARAMETER attribute. The enu- 2merator is defined in accordance with the rules of intrinsic assignment (7.2) with the value determined 3as follows. 4 (1) If scalar-int-initialization-expr is specified, the value of the enumerator is the result of 5 scalar-int-initialization-expr. 6 (2) If scalar-int-initialization-expr is not specified and the enumerator is the first enumerator 7 in enum-def , the enumerator has the value 0. 8 (3) If scalar-int-initialization-expr is not specified and the enumerator is not the first enumer- 9 ator in enum-def , its value is the result of adding 1 to the value of the enumerator that 10 immediately precedes it in the enum-def . NOTE 4.69 Example of an enumeration definition: ENUM, BIND(C) ENUMERATOR :: RED = 4, BLUE = 9 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.70 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 11 12An array constructor is defined as a sequence of scalar values and is interpreted as a rank-one array where the element values are those specified in the sequence. 81 J3/07-007 WORKING DRAFT 2006/01/05 1R467 array-constructor is (/ ac-spec /) 2 or lbracket ac-spec rbracket 3R468 ac-spec is type-spec :: or [type-spec ::] ac-value-list 4 R469 lbracket is [ 5 R470 rbracket is ] 6 7R471 ac-value is expr 8 or ac-implied-do R472 ac-implied-do is ( ac-value-list , ac-implied-do-control ) 9 10R473 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] 11 12R474 ac-do-variable is do-variable 13C4103 (R468) If type-spec is omitted, each ac-value expression in the array-constructor shall have the 14 same type and kind type parameters. 15C4104 (R468) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor 16 shall be of an intrinsic type that is in type conformance with a variable of type type-spec as 17 specified in Table 7.12. 18C4105 (R468) If type-spec specifies a derived type, all ac-value expressions in the array-constructor 19 shall be of that derived type and shall have the same kind type parameter values as specified by 20 type-spec. 21C4106 (R472) The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear 22 as the ac-do-variable of the containing ac-implied-do. 23If type-spec is omitted, each ac-value expression in the array constructor shall have the same length type 24parameters; in this case, the type and type parameters of the array constructor are those of the ac-value 25expressions. 26If type-spec appears, it specifies the type and type parameters of the array constructor. Each ac-value 27expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this 28type and type parameters. Each value is converted to the type parameters of the array-constructor in accordance with the rules of intrinsic assignment (7.2.1.3). 29 30The character length of an ac-value in an ac-implied-do whose iteration count is zero shall not depend 31on the value of the ac-do-variable and shall not depend on the value of an expression that is not an 32initialization expression. 33If an ac-value is a scalar expression, its value specifies an element of the array constructor. If an ac- 34value is an array expression, the values of the elements of the expression, in array element order (6.2.2.1), 35specify the corresponding sequence of elements of the array constructor. If an ac-value is an ac-implied- 36do, it is expanded to form a sequence of elements under the control of the ac-do-variable, as in the DO construct (8.1.7.5). 37 38For an ac-implied-do, the loop initialization and execution is the same as for a DO construct. 39An empty sequence forms a zero-sized array. 82 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.71 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.72 Examples of array constructors containing an implied DO are: (/ (I, I = 1, 1075) /) and [ 3.6, (3.6 / I, I = 1, N) ] NOTE 4.73 Using the type definition for PERSON in Note 4.20, an example of the construction of a derived- type array value is: [ PERSON (40, 'SMITH'), PERSON (20, 'JONES') ] NOTE 4.74 Using the type definition for LINE in Note 4.31, 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.75 Examples of zero-size array constructors are: [ INTEGER :: ] [ ( I, I = 1, 0) ] NOTE 4.76 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 83 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.76 (cont.) the constants with the same character length. 84 2006/01/05 WORKING DRAFT J3/07-007 5 Attribute declarations and specifications 1 25.1 General 3Every data object has a type and rank and may have type parameters and other properties that determine 4the uses of the object. Collectively, these properties are the attributes of the object. The type of a 5named data object is either specified explicitly in a type declaration statement or determined implicitly 6by the first letter of its name (5.5). All of its attributes may be specified in a type declaration statement 7or individually in separate specification statements. 8A function has a type and rank and may have type parameters and other attributes that determine the 9uses of the function. The type, rank, and type parameters are the same as those of its result variable. 10A subroutine does not have a type, rank, or type parameters, but may have other attributes that 11determine the uses of the subroutine. 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 15The type declaration statement specifies the type of the entities in the entity declaration list. The type 16and type parameters are those specified by declaration-type-spec, except that the character length type 17parameter may be overridden for an entity by the appearance of * char-length in its entity-decl. 18R502 attr-spec is access-spec 19 or ALLOCATABLE 20 or ASYNCHRONOUS 21 or CONTIGUOUS 22 or dimension-spec 23 or EXTERNAL 24 or INTENT ( intent-spec ) 25 or INTRINSIC 26 or language-binding-spec 27 or OPTIONAL 28 or PARAMETER 29 or POINTER 30 or PROTECTED 31 or SAVE 32 or TARGET 33 or VALUE 34 or VOLATILE 35 C501 (R501) The same attr-spec shall not appear more than once in a given type-declaration-stmt. 36 37C502 (R501) If a language-binding-spec with a NAME= specifier appears, the entity-decl-list shall 38 consist of a single entity-decl. 39C503 (R501) If a language-binding-spec is specified, the entity-decl-list shall not contain any procedure 85 J3/07-007 WORKING DRAFT 2006/01/05 1 names. 2The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, 3except that the DIMENSION attribute may be specified or overridden for an entity by the appearance 4of array-spec in its entity-decl. 5R503 entity-decl is object-name [( array-spec )] 6 [ lbracket co-array-spec rbracket ] 7 [ * char-length ] [ initialization ] 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 11C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, 12 an object in a named common block unless the type declaration is in a block data program unit, 13 an object in blank common, an allocatable variable, an external function, an intrinsic function, 14 or an automatic object. C507 (R503) An initialization shall appear if the entity is a named constant (5.3.12). 15 16C508 (R503) The function-name shall be the name of an external function, an intrinsic function, a 17 function dummy procedure, a procedure pointer, or a statement function. 18R504 object-name is name C509 (R504) The object-name shall be the name of a data object. 19 20R505 initialization is = initialization-expr 21 or => null-init 22 or => initial-data-target 23R506 null-init is function-reference 24C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = 25 appears in initialization, the entity shall not have the POINTER attribute. 26C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it (4.5.4.5). 27 28C512 (R506) The function-reference shall be a reference to the NULL intrinsic function with no 29 arguments. 30A name that identifies a specific intrinsic function in a scoping unit has a type as specified in 13.6. An 31explicit type declaration statement is not required; however, it is permitted. Specifying a type for a 32generic intrinsic function name in a type declaration statement is not sufficient, by itself, to remove the 33generic properties from that function. 5.2.2 Automatic data objects 34 35An automatic data object is a nondummy data object with a type parameter or array bound that 36depends on the value of a specification-expr that is not an initialization expression. 37C513 An automatic object shall not be a local variable of a main program, module, or submodule. 86 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.1 An automatic object shall not have the SAVE attribute and shall not appear in a common block. 1If a type parameter in a declaration-type-spec or in a char-length in an entity-decl is defined by an 2expression that is not an initialization expression, the type parameter value is established on entry to 3the procedure or BLOCK construct and is not affected by any redefinition or undefinition of the variables 4in the expression during execution of the procedure or BLOCK construct. 55.2.3 Initialization 6The appearance of initialization in an entity-decl for an entity without the PARAMETER attribute 7specifies that the entity is a variable with explicit initialization. Explicit initialization alternatively 8may be specified in a DATA statement unless the variable is of a derived type for which default initial- 9ization is specified. If initialization is =initialization-expr, the variable is initially defined with the value 10specified by the initialization-expr; if necessary, the value is converted according to the rules of intrinsic 11assignment (7.2.1.3) to a value that agrees in type, type parameters, and shape with the variable. A 12variable, or part of a variable, shall not be explicitly initialized more than once in a program. If the 13variable is an array, it shall have its shape specified in either the type declaration statement or a previous 14attribute specification statement in the same scoping unit. 15If null-init appears, the initial association status of the object is disassociated. If initial-data-target 16appears, the object is initially associated with the target. 17Explicit initialization of a variable that is not in a common block implies the SAVE attribute, which 18may be confirmed by explicit specification. 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.27.) 205.3 Attributes 215.3.1 Constraints 22An attribute may be explicitly specified by an attr-spec in a type declaration statement or by an attribute specification statement (5.4). The following constraints apply to attributes. 87 J3/07-007 WORKING DRAFT 2006/01/05 1 2C514 An entity shall not be explicitly given any attribute more than once in a scoping unit. 3C515 An array-spec for a function result that does not have the ALLOCATABLE or POINTER 4 attribute shall be an explicit-shape-spec-list. 5C516 The ALLOCATABLE, POINTER, or OPTIONAL attribute shall not be specified for a dummy 6 argument of a procedure that has a proc-language-binding-spec. 5.3.2 Accessibility attribute 7 8The accessibility attribute specifies the accessibility of an entity via a particular identifier. 9R507 access-spec is PUBLIC 10 or PRIVATE C517 (R507) An access-spec shall appear only in the specification-part of a module. 11 12Identifiers that are specified in a module or accessible in that module by use association have either the 13PUBLIC or PRIVATE attribute. Identifiers for which an access-spec is not explicitly specified in 14that module have the default accessibility attribute for that module. The default accessibility attribute 15for a module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only identifiers 16that have the PUBLIC attribute in that module are available to be accessed from that module by use 17association. 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 that module. NOTE 5.4 An example of an accessibility specification is: REAL, PRIVATE :: X, Y, Z 185.3.3 ALLOCATABLE attribute 19An entity with the ALLOCATABLE attribute is a variable for which space is allocated by an AL- LOCATE statement (6.3.1) or by an intrinsic assignment statement (7.2.1.3). 20 215.3.4 ASYNCHRONOUS attribute 22An entity with the ASYNCHRONOUS attribute is a variable that may be subject to asynchronous input/output. 23 24The base object of a variable shall have the ASYNCHRONOUS attribute in a scoping unit if 25 (1) the variable appears in an executable statement or specification expression in that scoping 26 unit and 27 (2) any statement of the scoping unit is executed while the variable is a pending I/O storage sequence affector (9.5.2.5). 28 29Use of a variable in an asynchronous input/output statement can imply the ASYNCHRONOUS attribute; 88 2006/01/05 WORKING DRAFT J3/07-007 see subclause (9.5.2.5). 1 2An object may have the ASYNCHRONOUS attribute in a particular scoping unit without necessarily 3having it in other scoping units (11.2.2, 16.5.1.4). If an object has the ASYNCHRONOUS attribute, 4then all of its subobjects also have the ASYNCHRONOUS attribute. 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. 55.3.5 BIND attribute for data entities 6The BIND attribute for a variable or common block specifies that it is capable of interoperating with a C variable that has external linkage (15.4). 7 R508 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) 8 9C518 An entity with the BIND attribute shall be a common block, variable, or procedure. 10C519 A variable with the BIND attribute shall be declared in the specification part of a module. C520 A variable with the BIND attribute shall be interoperable (15.3). 11 12C521 Each variable of a common block with the BIND attribute shall be interoperable. 13C522 (R508) The scalar-char-initialization-expr shall be of default character kind. If the value of the 14 scalar-char-initialization-expr after discarding leading and trailing blanks has nonzero length, 15 it shall be valid as an identifier on the companion processor. 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. 16The BIND attribute for a variable or common block implies the SAVE attribute, which may be confirmed 17by explicit specification. 185.3.6 CONTIGUOUS attribute 19C523 An entity with the CONTIGUOUS attribute shall be an array pointer or an assumed-shape 20 array. 21The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated 22with a contiguous effective argument, or that an array pointer can only be pointer associated with a 23contiguous target. 24An object is contiguous if it is (1) an object with the CONTIGUOUS attribute, 25 89 J3/07-007 WORKING DRAFT 2006/01/05 (2) a nonpointer whole array that is not assumed-shape, 1 (3) an assumed-shape array that is argument associated with an array that is contiguous, 2 (4) an array allocated by an ALLOCATE statement, 3 (5) a pointer associated with a contiguous target, or 4 (6) a nonzero-sized array section (6.2.2) provided that 5 (a) its base object is contiguous, 6 (b) it does not have a vector subscript, 7 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 specifies all of the characters of the parent-string (6.1.1), 11 (e) only its final part-ref has nonzero rank, and 12 (f) it is not the real or imaginary part (6.1.3) of an array of type complex. 13 14An object is not contiguous if it is an array subobject, and (1) the object has two or more elements, 15 16 (2) the elements of the object in array element order are not consecutive in the elements of the 17 base object, (3) the object is not of type character with length zero, and 18 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. 21It is processor-dependent whether any other object is contiguous. 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 makes it easier for a processor to enable optimizations that de- pend 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 225.3.7 DIMENSION attribute 235.3.7.1 General 24The DIMENSION attribute specifies that an entity is an array, a co-array, or both. If an array-spec 25appears, it is an array. If a co-array-spec appears, it is a co-array. 26For an array, its array-spec specifies its rank or rank and shape. For a co-array, its co-array-spec specifies 27its co-rank or co-rank and co-bounds. NOTE 5.9 Unless it is a dummy argument, a co-array has the same bounds and co-bounds on every image. 90 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.9 (cont.) See Note 12.32 for further discussion of the bounds and co-bounds of dummy co-arrays. 1R509 dimension-spec is DIMENSION ( array-spec ) or DIMENSION [ ( array-spec ) ] lbracket co-array-spec rbracket 2 3C524 (R501) A co-array with the ALLOCATABLE attribute shall be specified with a co-array-spec 4 that is a deferred-co-shape-spec-list. 5C525 A co-array shall be a component or a variable that is not a function result. C526 A co-array shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 6 7C527 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. 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. 9C528 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared 10 in the main program, or allocatable. 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. 11R510 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 16R511 co-array-spec is deferred-co-shape-spec-list 17 or explicit-co-shape-spec 18C529 The sum of the rank and co-rank of an entity shall not exceed fifteen. NOTE 5.12 Examples of DIMENSION attribute specifications are: SUBROUTINE EX (N, A, B) 91 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.12 (cont.) 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 15.3.7.2 Explicit-shape array 2An explicit-shape array is a named array that is declared with an explicit-shape-spec-list. This specifies 3explicit values for the bounds in each dimension of the array. R512 explicit-shape-spec is [ lower-bound : ] upper-bound 4 5R513 lower-bound is specification-expr 6R514 upper-bound is specification-expr 7C530 (R512) An explicit-shape-spec whose bounds are not initialization expressions shall appear only 8 in a subprogram or interface body. 9An explicit-shape array that is a local variable of a subprogram or BLOCK construct may have bounds 10that are not initialization expressions. The bounds, and hence shape, are determined at entry to a 11procedure defined by the subprogram, or on execution of the BLOCK statement, by evaluating the 12bounds expressions. The bounds of such an array are unaffected by the redefinition or undefinition of 13any variable during execution of the procedure or BLOCK construct. 14The values of each lower-bound and upper-bound determine the bounds of the array along a particular 15dimension and hence the extent of the array in that dimension. The value of a lower bound or an upper 16bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set 17of integer values between and including the lower and upper bounds, provided the upper bound is not 18less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the 19extent in that dimension is zero, and the array is of zero size. If the lower-bound is omitted, the default 20value is 1. The rank is equal to the number of explicit-shape-specs. 215.3.7.3 Assumed-shape array 22An assumed-shape array is a nonallocatable nonpointer dummy argument array that takes its shape 23from the associated actual argument array. R515 assumed-shape-spec is [ lower-bound ] : 24 25The rank is equal to the number of colons in the assumed-shape-spec-list. 26The extent of a dimension of an assumed-shape array dummy argument is the extent of the corresponding 27dimension of the associated actual argument array. If the lower bound value is d and the extent of the 28corresponding dimension of the associated actual argument array is s, then the value of the upper bound 29is s + d - 1. If lower-bound appears it specifies the lower bound; otherwise the lower bound is 1. 305.3.7.4 Deferred-shape array 31A deferred-shape array is an allocatable array or an array pointer. 32An allocatable array is an array that has the ALLOCATABLE attribute and a specified rank, but its bounds, and hence shape, are determined by allocation or argument association. 92 2006/01/05 WORKING DRAFT J3/07-007 1 2An array pointer is an array with the POINTER attribute and a specified rank. Its bounds, and hence 3shape, are determined when it is associated with a target. 4R516 deferred-shape-spec is : 5C531 An array with the POINTER or ALLOCATABLE attribute shall have an array-spec that is a 6 deferred-shape-spec-list. 7The rank is equal to the number of colons in the deferred-shape-spec-list. 8The size, bounds, and shape of an unallocated allocatable array or a disassociated array pointer are 9undefined. No part of such an array shall be referenced or defined; however, the array may appear as an 10argument to an intrinsic inquiry function as specified in 13.1. 11The bounds of each dimension of an allocated allocatable array are those specified when the array 12is allocated or, if it is a dummy argument, when it is argument associated with an allocated actual 13argument. 14The bounds of each dimension of an associated array pointer, and hence its shape, may be specified (1) in an ALLOCATE statement (6.3.1) when the target is allocated, 15 (2) by pointer assignment (7.2.2), or 16 17 (3) if it is a dummy argument, by argument association with a nonpointer actual argument or 18 an associated pointer actual argument. 19The bounds of an array pointer or allocatable array are unaffected by any subsequent redefinition or 20undefinition of variables on which the bounds' expressions depend. 215.3.7.5 Assumed-size array 22An assumed-size array is a dummy argument array whose size is assumed from that of an associated 23actual argument. The rank and extents may differ for the actual and dummy arrays; only the size of the 24actual array is assumed by the dummy array. An assumed-size array is declared with an assumed-size- 25spec. R517 assumed-size-spec is [ explicit-shape-spec , ]... [ lower-bound : ] * 26 27C532 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy 28 data argument. 29C533 An assumed-size array with INTENT (OUT) shall not be polymorphic, of a finalizable type, of 30 a type with an ultimate allocatable component, or of a type for which default initialization is 31 specified. 32The size of an assumed-size array is determined as follows. 33 (1) If the actual argument associated with the assumed-size dummy array is an array of any 34 type other than default character, the size is that of the actual array. 35 (2) If the actual argument associated with the assumed-size dummy array is an array element 36 of any type other than default character with a subscript order value of r (6.2.2.1) in an 37 array of size x, the size of the dummy array is x - r + 1. 38 (3) If the actual argument is a default character array, default character array element, or a 39 default character array element substring (6.1.1), and if it begins at character storage unit t 40 of an array with c character storage units, the size of the dummy array is MAX (INT ((c - t + 1)/e), 0), where e is the length of an element in the dummy character array. 41 93 J3/07-007 WORKING DRAFT 2006/01/05 1 (4) If the actual argument is of type default character and is a scalar that is not an array element 2 or array element substring designator, the size of the dummy array is MAX (INT (l/e), 0), 3 where e is the length of an element in the dummy character array and l is the length of the 4 actual argument. 5The rank is equal to one plus the number of explicit-shape-specs. 6An assumed-size array has no upper bound in its last dimension and therefore has no extent in its last 7dimension and no shape. An assumed-size array name shall not be written as a whole array reference 8except as an actual argument in a procedure reference for which the shape is not required. 9If a list of explicit-shape-specs appears, it specifies the bounds of the first rank-1 dimensions. If lower- 10bound appears it specifies the lower bound of the last dimension; otherwise that lower bound is 1. An 11assumed-size array may be subscripted or sectioned (6.2.2.2). The upper bound shall not be omitted 12from a subscript triplet in the last dimension. 13If an assumed-size array has bounds that are not initialization expressions, the bounds are determined 14at entry to the procedure. The bounds of such an array are unaffected by the redefinition or undefinition 15of any variable during execution of the procedure. 165.3.7.6 Implied-shape array 17An implied-shape array is a named constant that takes its shape from the initialization-expr in its 18declaration. An implied-shape array is declared with an implied-shape-spec-list. R518 implied-shape-spec is [ lower-bound : ] * 19 20C534 An implied-shape array shall be a named constant. 21The rank of an implied-shape array is the number of implied-shape-specs in the implied-shape-spec-list. 22The extent of each dimension of an implied-shape array is the same as the extent of the corresponding 23dimension of the initialization-expr. The lower bound of each dimension is lower-bound, if it appears, 24and 1 otherwise; the upper bound is one less than the sum of the lower bound and the extent. 255.3.7.7 Allocatable co-array 26A co-array with the ALLOCATABLE attribute has a specified co-rank, but its co-bounds are determined 27by allocation or argument association. 28R519 deferred-co-shape-spec is : 29C535 A co-array with the ALLOCATABLE attribute shall have a co-array-spec that is a deferred-co- 30 shape-spec-list. 31The co-rank of an allocatable co-array is equal to the number of colons in its deferred-co-shape-spec-list. 32The co-bounds of an unallocated allocatable co-array are undefined. No part of such a co-array shall be 33referenced or defined; however, the co-array may appear as an argument to an intrinsic inquiry function 34as specified in 13.1. 35The co-bounds of an allocated allocatable co-array are those specified when the co-array is allocated. 36The co-bounds of an allocatable co-array are unaffected by any subsequent redefinition or undefinition 37of the variables on which the bounds' expressions depend. 385.3.7.8 Explicit-co-shape co-array 94 2006/01/05 WORKING DRAFT J3/07-007 1An explicit-co-shape co-array is a named co-array that has its co-rank and co-bounds declared by 2an explicit-co-shape-spec. 3R520 explicit-co-shape-spec is [ [ lower-co-bound : ] upper-co-bound, ]... [ lower-co-bound : ] * 4 5C536 A co-array that does not have the ALLOCATABLE attribute shall have a co-array-spec that is 6 an explicit-co-shape-spec. 7The co-rank is equal to one plus the number of upper-co-bounds. 8R521 lower-co-bound is specification-expr 9R522 upper-co-bound is specification-expr 10C537 (R520) A lower-co-bound or upper-co-bound that is not an initialization expression shall appear 11 only in a subprogram or interface body. 12If an explicit-co-shape co-array has co-bounds that are not initialization expressions, the co-bounds are 13determined at entry to the procedure by evaluating the co-bounds expressions. The co-bounds of such 14a co-array are unaffected by the redefinition or undefinition of any variable during execution of the 15procedure. 16The values of each lower-co-bound and upper-co-bound determine the co-bounds of the array along a 17particular co-dimension. The subscript range of the array in that co-dimension is the set of integer values 18between and including the lower and upper co-bounds. If the lower co-bound is omitted, the default 19value is 1. The upper co-bound shall not be less than the lower co-bound. 205.3.8 EXTERNAL attribute 21The EXTERNAL attribute specifies that an entity is an external procedure, dummy procedure, 22procedure pointer, or block data subprogram. 23C538 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. 24C539 In an external subprogram, the EXTERNAL attribute shall not be specified for a procedure 25 defined by the subprogram. 26If an external procedure or dummy procedure is used as an actual argument or is the target of a procedure 27pointer assignment, it shall be declared to have the EXTERNAL attribute. 28A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer. 295.3.9 INTENT attribute 30The INTENT attribute specifies the intended use of a dummy argument. An INTENT (IN) dummy 31argument is suitable for receiving data from the invoking scoping unit, an INTENT (OUT) dummy 32argument is suitable for returning data to the invoking scoping unit, and an INTENT (INOUT) dummy 33argument is suitable for use both to receive data from and to return data to the invoking scoping unit. 34R523 intent-spec is IN 35 or OUT 36 or INOUT 37C540 An entity with the INTENT attribute shall be a dummy data object or a dummy procedure 38 pointer. 39C541 (R523) A nonpointer object with the INTENT (IN) attribute shall not appear in a variable 95 J3/07-007 WORKING DRAFT 2006/01/05 definition context (16.6.7). 1 2C542 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context (16.6.8). 3 4The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be de- 5fined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a 6pointer dummy argument specifies that during the execution of the procedure its association shall not 7be changed except that it may become undefined if the target is deallocated other than through the pointer (16.5.2.2.3). 8 9The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument 10becomes undefined on invocation of the procedure, except for any subcomponents that are default- 11initialized (4.5.4.5). Any actual argument that becomes associated with such a dummy argument shall 12be definable. The INTENT (OUT) attribute for a pointer dummy argument specifies that on invocation 13of the procedure the pointer association status of the dummy argument becomes undefined. Any actual 14argument associated with such a pointer dummy shall be a pointer variable. 15The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument 16associated with the dummy argument shall be definable. The INTENT (INOUT) attribute for a pointer 17dummy argument specifies that any actual argument associated with the dummy argument shall be a 18pointer variable. NOTE 5.13 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). 19If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the argument associated entity (12.5.2). 20 NOTE 5.14 An example of INTENT specification is: SUBROUTINE MOVE (FROM, TO) USE PERSON_MODULE TYPE (PERSON), INTENT (IN) :: FROM TYPE (PERSON), INTENT (OUT) :: TO 21If an object has an INTENT attribute, then all of its subobjects have the same INTENT attribute. NOTE 5.15 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 is prohibited, but 96 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.15 (cont.) 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.16 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. 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. 15.3.10 INTRINSIC attribute 2The INTRINSIC attribute specifies that the entity is an intrinsic procedure. It may be a generic procedure (13.5), a specific procedure (13.6), or both. 3 4If the specific name of an intrinsic procedure (13.6) is used as an actual argument, the name shall be 5explicitly specified to have the INTRINSIC attribute. An intrinsic procedure whose specific name is marked with a bullet (·) in 13.6 shall not be used as an actual argument. 6 7C543 If the name of a generic intrinsic procedure is explicitly declared to have the INTRINSIC at- 8 tribute, and it is also the generic name of one or more generic interfaces (12.4.3.2) accessible in 9 the same scoping unit, the procedures in the interfaces and the specific intrinsic procedures shall 10 all be functions or all be subroutines, and the characteristics of the specific intrinsic procedures 11 and the procedures in the interfaces shall differ as specified in 12.4.3.4.5. 125.3.11 OPTIONAL attribute 13The OPTIONAL attribute specifies that the dummy argument need not be associated with an actual argument in a reference to the procedure (12.5.2.13). 14 15C544 An entity with the OPTIONAL attribute shall be a dummy argument. 97 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.17 The PRESENT intrinsic function (13.7.138) can be used to determine whether an optional dummy argument is associated with an actual argument. 15.3.12 PARAMETER attribute 2The PARAMETER attribute specifies that an entity is a named constant. The entity has the value 3specified by its initialization-expr, converted, if necessary, to the type, type parameters and shape of the 4entity. 5C545 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. 6A named constant shall not be referenced unless it has been defined previously in the same statement, 7defined in a prior statement, or made accessible by use or host association. 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 ( )) 85.3.13 POINTER attribute 9Entities with the POINTER attribute can be associated with different data objects or procedures 10during execution of a program. A pointer is either a data pointer or a procedure pointer. Procedure 11pointers are described in 12.4.3.6. 12C546 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or 13 TARGET attribute, and shall not be a co-array. 14C547 A procedure with the POINTER attribute shall have the EXTERNAL attribute. 15A data pointer shall not be referenced unless it is pointer associated with a target object that is defined. 16A data pointer shall not be defined unless it is pointer associated with a target object that is definable. 17If a data pointer is associated, the values of its deferred type parameters are the same as the values of 18the corresponding type parameters of its target. 19A procedure pointer shall not be referenced unless it is pointer associated with a target procedure. 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. 205.3.14 PROTECTED attribute 21The PROTECTED attribute imposes limitations on the usage of module entities. 22C548 The PROTECTED attribute shall be specified only in the specification part of a module. 98 2006/01/05 WORKING DRAFT J3/07-007 1C549 An entity with the PROTECTED attribute shall be a procedure pointer or variable. 2C550 An entity with the PROTECTED attribute shall not be in a common block. 3C551 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. 6C552 A pointer that has the PROTECTED attribute and is accessed by use association shall not appear in a pointer association context (16.6.8). 7 8Other than within the module in which an entity is given the PROTECTED attribute, or within any of 9its descendants, (1) if it is a nonpointer object, it is not definable, and 10 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. 14If an object has the PROTECTED attribute, all of its subobjects have the PROTECTED attribute. 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. 155.3.15 SAVE attribute 16The SAVE attribute specifies that a local variable of a program unit or subprogram retains its association 17status, allocation status, definition status, and value after execution of a RETURN or END statement 18unless it is a pointer and its target becomes undefined (16.5.2.2.3(4)). If it is a local variable of a subprogram it is shared by all instances (12.6.2.4) of the subprogram. 19 20The SAVE attribute specifies that a local variable of a BLOCK construct retains its association status, 21allocation status, definition status, and value after termination of the construct unless it is a pointer 22and its target becomes undefined (16.5.2.2.3(5)). If the BLOCK construct is within a subprogram the variable is shared by all instances (12.6.2.4) of the subprogram. 23 24Giving a common block the SAVE attribute confers the attribute on all variables in the common block. 25C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. 26C554 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic 27 data object, or an object that is in a common block. 99 J3/07-007 WORKING DRAFT 2006/01/05 1A saved entity is an entity that has the SAVE attribute. An unsaved entity is an entity that does not 2have the SAVE attribute. 3The SAVE attribute has no effect on entities declared in a main program, module, or submodule. If 4a common block has the SAVE attribute in any other kind of scoping unit, it shall have the SAVE 5attribute in every scoping unit that is not a main program, module, or submodule. 65.3.16 TARGET attribute 7The TARGET attribute specifies that a data object may have a pointer associated with it (7.2.2). 8An object without the TARGET attribute shall not have an accessible pointer associated with it. 9C555 An entity with the TARGET attribute shall be a variable. 10C556 An entity with the TARGET attribute shall not have the POINTER attribute. 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. 11If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET 12attribute. 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. 135.3.17 VALUE attribute The VALUE attribute specifies a type of argument association (12.5.2.5) for a dummy argument. 14 15C557 An entity with the VALUE attribute shall be a scalar dummy data object. 16C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. 17 18C559 If an entity has the VALUE attribute, any length type parameter value in its declaration shall 19 be omitted or specified by an initialization expression. 205.3.18 VOLATILE attribute 21The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, 22by means not specified by the program, or by another image without synchronization. 100 2006/01/05 WORKING DRAFT J3/07-007 1C560 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy 2 argument. 3An object may have the VOLATILE attribute in a particular scoping unit without necessarily having 4it in other scoping units (11.2.2, 16.5.1.4). If an object has the VOLATILE attribute, then all of its 5subobjects also have the VOLATILE attribute. 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. 6A pointer with the VOLATILE attribute may additionally have its association status, dynamic type and 7type parameters, and array bounds changed by means not specified by the program. 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. 8An allocatable object with the VOLATILE attribute may additionally have its allocation status, dynamic 9type and type parameters, and array bounds changed by means not specified by the program. 5.4 Attribute specification statements 10 5.4.1 Accessibility statement 11 R524 access-stmt is access-spec [ [ :: ] access-id-list ] 12 13R525 access-id is use-name 14 or generic-spec 15C561 (R524) An access-stmt shall appear only in the specification-part of a module. Only one ac- 16 cessibility statement with an omitted access-id-list is permitted in the specification-part of a 17 module. 18C562 (R525) Each use-name shall be the name of a named variable, procedure, derived type, named 19 constant, namelist group, or macro. 20An access-stmt with an access-id-list specifies the accessibility attribute (5.3.2), PUBLIC or PRIVATE, 21of each access-id in the list. An access-stmt without an access-id list specifies the default accessibility 22that applies to all potentially accessible identifiers in the specification-part of the module. The statement 23PUBLIC 24specifies a default of public accessibility. The statement 25PRIVATE 26specifies a default of private accessibility. If no such statement appears in a module, the default is public 27accessibility. 101 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.26 Examples of accessibility statements are: MODULE EX PRIVATE PUBLIC :: A, B, C, ASSIGNMENT (=), OPERATOR (+) 15.4.2 ALLOCATABLE statement R526 allocatable-stmt is ALLOCATABLE [ :: ] allocatable-decl-list 2 3R527 allocatable-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] 4 The ALLOCATABLE 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 65.4.3 ASYNCHRONOUS statement R528 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name-list 7 8The ASYNCHRONOUS statement specifies the ASYNCHRONOUS attribute (5.3.4) for a list of 9objects. 105.4.4 BIND statement R529 bind-stmt is language-binding-spec [ :: ] bind-entity-list 11 12R530 bind-entity is entity-name or / common-block-name / 13 14C563 (R529) If the language-binding-spec has a NAME= specifier, the bind-entity-list shall consist of 15 a single bind-entity. The BIND statement specifies the BIND attribute (5.3.5) for a list of variables and common blocks. 16 175.4.5 CONTIGUOUS statement R531 contiguous-stmt is CONTIGUOUS [ :: ] object-name-list 18 The CONTIGUOUS statement specifies the CONTIGUOUS attribute (5.3.6) for a list of objects. 19 205.4.6 DATA statement R532 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... 21 The DATA statement specifies explicit initialization (5.2.3). 22 23A variable, or part of a variable, shall not be explicitly initialized more than once in a program. If a 24nonpointer object has been specified with default initialization in a type definition, it shall not appear 102 2006/01/05 WORKING DRAFT J3/07-007 1in a data-stmt-object-list. 2A variable that appears in a DATA statement and has not been typed previously may appear in a 3subsequent type declaration only if that declaration confirms the implicit typing. An array name, 4array section, or array element that appears in a DATA statement shall have had its array properties 5established by a previous specification statement. 6Except for variables in named common blocks, a named variable has the SAVE attribute if any part of 7it is initialized in a DATA statement, and this may be confirmed by explicit specification. R533 data-stmt-set is data-stmt-object-list / data-stmt-value-list / 8 9R534 data-stmt-object is variable 10 or data-implied-do 11R535 data-implied-do is ( data-i-do-object-list , data-i-do-variable = 12 scalar-int-initialization-expr , 13 scalar-int-initialization-expr [ , scalar-int-initialization-expr ] ) 14 15R536 data-i-do-object is array-element 16 or scalar-structure-component 17 or data-implied-do 18R537 data-i-do-variable is do-variable 19C564 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. 20C565 (R534) In a variable that is a data-stmt-object, any subscript, section subscript, substring start- 21 ing point, and substring ending point shall be an initialization expression. 22C566 (R534) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall 23 not be a dummy argument, made accessible by use association or host association, in a named 24 common block unless the DATA statement is in a block data program unit, in a blank common 25 block, a function name, a function result name, an automatic object, or an allocatable variable. 26C567 (R534) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an object 27 designator in which a pointer appears other than as the entire rightmost part-ref . C568 (R536) The array-element shall be a variable. 28 C569 (R536) The scalar-structure-component shall be a variable. 29 30C570 (R536) The scalar-structure-component shall contain at least one part-ref that contains a sub- 31 script-list. 32C571 (R536) In an array-element or scalar-structure-component that is a data-i-do-object, any sub- 33 script shall be an initialization expression, and any primary within that subscript that is a 34 data-i-do-variable shall be a DO variable of this data-implied-do or of a containing data-implied- 35 do. R538 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant 36 37R539 data-stmt-repeat is scalar-int-constant 38 or scalar-int-constant-subobject 39C572 (R539) The data-stmt-repeat shall be positive or zero. If the data-stmt-repeat is a named con- 40 stant, it shall have been declared previously in the scoping unit or made accessible by use 103 J3/07-007 WORKING DRAFT 2006/01/05 1 association or host association. 2R540 data-stmt-constant is scalar-constant 3 or scalar-constant-subobject 4 or signed-int-literal-constant 5 or signed-real-literal-constant 6 or null-init 7 or initial-data-target 8 or structure-constructor 9C573 (R540) If a DATA statement constant value is a named constant or a structure constructor, the 10 named constant or derived type shall have been declared previously in the scoping unit or made 11 accessible by use or host association. C574 (R540) If a data-stmt-constant is a structure-constructor, it shall be an initialization expression. 12 13R541 int-constant-subobject is constant-subobject C575 (R541) int-constant-subobject shall be of type integer. 14 15R542 constant-subobject is designator C576 (R542) constant-subobject shall be a subobject of a constant. 16 17C577 (R542) Any subscript, substring starting point, or substring ending point shall be an initializa- 18 tion expression. 19The data-stmt-object-list is expanded to form a sequence of pointers and scalar variables, referred to 20as "sequence of variables" in subsequent text. A nonpointer array whose unqualified name appears 21as a data-stmt-object or data-i-do-object is equivalent to a complete sequence of its array elements in 22array element order (6.2.2.1). An array section is equivalent to the sequence of its array elements in 23array element order. A data-implied-do is expanded to form a sequence of array elements and structure components, under the control of the data-i-do-variable, as in the DO construct (8.1.7.5). 24 25The data-stmt-value-list is expanded to form a sequence of data-stmt-constants. A data-stmt-repeat 26indicates the number of times the following data-stmt-constant is to be included in the sequence; omission 27of a data-stmt-repeat has the effect of a repeat factor of 1. 28A zero-sized array or a data-implied-do with an iteration count of zero contributes no variables to the 29expanded sequence of variables, but a zero-length scalar character variable does contribute a variable 30to the expanded sequence. A data-stmt-constant with a repeat factor of zero contributes no data-stmt- 31constants to the expanded sequence of scalar data-stmt-constants. 32The expanded sequences of variables and data-stmt-constants are in one-to-one correspondence. Each 33data-stmt-constant specifies the initial value, initial data target, or null-init for the corresponding vari- 34able. The lengths of the two expanded sequences shall be the same. 35A data-stmt-constant shall be null-init or initial-data-target if and only if the corresponding data-stmt- 36object has the POINTER attribute. If data-stmt-constant is null-init, the initial association status of 37the corresponding data statement object is disassociated. If data-stmt-constant is initial-data-target the 38corresponding data statement object shall be data-pointer-initialization compatible with the initial data 39target; the data statement object is initially associated with the target. 40A data-stmt-constant other than null-init or initial-data-target shall be compatible with its corresponding 41variable according to the rules of intrinsic assignment (7.2.1.2). The variable is initially defined with 42the value specified by the data-stmt-constant; if necessary, the value is converted according to the rules 43of intrinsic assignment (7.2.1.3) to a value that agrees in type, type parameters, and shape with the 104 2006/01/05 WORKING DRAFT J3/07-007 1variable. 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 / 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.20. The pointer HEAD OF LIST is declared using the derived type NODE from Note 4.39; it is initially disassociated. MYNAME is initialized by a structure constructor. YOURNAME is initialized by supplying a separate value for each component. 25.4.7 DIMENSION statement R543 dimension-stmt is DIMENSION [ :: ] dimension-decl-list 3 4R544 dimension-decl is array-name ( array-spec ) or co-name [ ( array-spec ) ] lbracket co-array-spec rbracket 5 The DIMENSION statement specifies the DIMENSION attribute (5.3.7) for a list of objects. 6 NOTE 5.29 An example of a DIMENSION statement is: DIMENSION A (10), B (10, 70), C (:) 75.4.8 INTENT statement R545 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name-list 8 The INTENT statement specifies the INTENT attribute (5.3.9) for the dummy arguments in the list. 9 NOTE 5.30 An example of an INTENT statement is: SUBROUTINE EX (A, B) INTENT (INOUT) :: A, B 105.4.9 OPTIONAL statement 105 J3/07-007 WORKING DRAFT 2006/01/05 R546 optional-stmt is OPTIONAL [ :: ] dummy-arg-name-list 1 2The OPTIONAL statement specifies the OPTIONAL attribute (5.3.11) for the dummy arguments 3in the list. NOTE 5.31 An example of an OPTIONAL statement is: SUBROUTINE EX (A, B) OPTIONAL :: B 45.4.10 PARAMETER statement 5The PARAMETER statement specifies the PARAMETER attribute (5.3.12) and the values for the 6 named constants in the list. R547 parameter-stmt is PARAMETER ( named-constant-def -list ) 7 8R548 named-constant-def is named-constant = initialization-expr 9If a named constant is defined by a PARAMETER statement, it shall not be subsequently declared to 10have a type or type parameter value that differs from the type and type parameters it would have if 11declared implicitly (5.5). A named array constant defined by a PARAMETER statement shall have its 12shape specified in a prior specification statement. 13The value of each named constant is that specified by the corresponding initialization expression; if 14necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value that 15agrees in type, type parameters, and shape with the named constant. NOTE 5.32 An example of a PARAMETER statement is: PARAMETER (MODULUS = MOD (28, 3), NUMBER_OF_SENATORS = 100) 165.4.11 POINTER statement R549 pointer-stmt is POINTER [ :: ] pointer-decl-list 17 18R550 pointer-decl is object-name [ ( deferred-shape-spec-list ) ] 19 or proc-entity-name The POINTER statement specifies the POINTER attribute (5.3.13) for a list of entities. 20 NOTE 5.33 An example of a POINTER statement is: TYPE (NODE) :: CURRENT POINTER :: CURRENT, A (:, :) 215.4.12 PROTECTED statement R551 protected-stmt is PROTECTED [ :: ] entity-name-list 22 The PROTECTED statement specifies the PROTECTED attribute (5.3.14) for a list of entities. 23 106 2006/01/05 WORKING DRAFT J3/07-007 15.4.13 SAVE statement R552 save-stmt is SAVE [ [ :: ] saved-entity-list ] 2 3R553 saved-entity is object-name 4 or proc-pointer-name or / common-block-name / 5 6R554 proc-pointer-name is name 7C578 (R552) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no 8 other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. 9A SAVE statement with a saved entity list specifies the SAVE attribute (5.3.15) for a list of entities. 10A SAVE statement without a saved entity list is treated as though it contained the names of all allowed 11items in the same scoping unit. NOTE 5.34 An example of a SAVE statement is: SAVE A, B, C, / BLOCKA /, D 125.4.14 TARGET statement 13R555 target-stmt is TARGET [ :: ] target-decl-list R556 target-decl is object-name [ ( array-spec ) ] 14 [ lbracket co-array-spec rbracket ] 15 The TARGET statement specifies the TARGET attribute (5.3.16) for a list of objects. 16 NOTE 5.35 An example of a TARGET statement is: TARGET :: A (1000, 1000), B 175.4.15 VALUE statement R557 value-stmt is VALUE [ :: ] dummy-arg-name-list 18 The VALUE statement specifies the VALUE attribute (5.3.17) for a list of dummy arguments. 19 205.4.16 VOLATILE statement R558 volatile-stmt is VOLATILE [ :: ] object-name-list 21 The VOLATILE statement specifies the VOLATILE attribute (5.3.18) for a list of objects. 22 235.5 IMPLICIT statement 24In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all 25implicitly typed data entities whose names begin with one of the letters specified in the statement. 26Alternatively, it may indicate that no implicit typing rules are to apply in a particular scoping unit. 107 J3/07-007 WORKING DRAFT 2006/01/05 1R559 implicit-stmt is IMPLICIT implicit-spec-list 2 or IMPLICIT NONE R560 implicit-spec is declaration-type-spec ( letter-spec-list ) 3 R561 letter-spec is letter [ ­ letter ] 4 5C579 (R559) If IMPLICIT NONE is specified in a scoping unit, it shall precede any PARAMETER 6 statements that appear in the scoping unit and there shall be no other IMPLICIT statements 7 in the scoping unit. 8C580 (R561) If the minus and second letter appear, the second letter shall follow the first letter 9 alphabetically. 10A letter-spec consisting of two letters separated by a minus is equivalent to writing a list containing all 11of the letters in alphabetical order in the alphabetic sequence from the first letter through the second 12letter. For example, A­C is equivalent to A, B, C. The same letter shall not appear as a single letter, or 13be included in a range of letters, more than once in all of the IMPLICIT statements in a scoping unit. 14In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z 15and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in 16its letter-spec-list. IMPLICIT NONE specifies the null mapping for all the letters. If a mapping is not 17specified for a letter, the default for a program unit or an interface body is default integer if the letter 18is I, J, ..., or N and default real otherwise, and the default for an internal or module procedure is the 19mapping in the host scoping unit. 20Any data entity that is not explicitly declared by a type declaration statement, is not an intrinsic 21function, and is not made accessible by use association or host association is declared implicitly to be of 22the type (and type parameters) mapped from the first letter of its name, provided the mapping is not 23null. The mapping for the first letter of the data entity shall either have been established by a prior 24IMPLICIT statement or be the default mapping for the letter. The mapping may be to a derived type 25that is inaccessible in the local scope if the derived type is accessible in the host scoping unit. The data 26entity is treated as if it were declared in an explicit type declaration in the outermost scoping unit in 27which it appears. An explicit type specification in a FUNCTION statement overrides an IMPLICIT 28statement for the name of the result variable of that function subprogram. 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) 108 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.36 (cont.) 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 ! 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. 15.6 NAMELIST statement 109 J3/07-007 WORKING DRAFT 2006/01/05 1A NAMELIST statement specifies a group of named data objects, which may be referred to by a single name for the purpose of data transfer (9.5, 10.11). 2 3R562 namelist-stmt is NAMELIST 4 / namelist-group-name / namelist-group-object-list 5 [ [ , ] / namelist-group-name / namelist-group-object-list ] ... 6 C581 (R562) The namelist-group-name shall not be a name accessed by use association. 7 8R563 namelist-group-object is variable-name C582 (R563) A namelist-group-object shall not be an assumed-size array. 9 10C583 (R562) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- 11 name has the PUBLIC attribute. 12The order in which the variables are specified in the NAMELIST statement determines the order in 13which the values appear on output. 14Any namelist-group-name may occur more than once in the NAMELIST statements in a scoping unit. 15The namelist-group-object-list following each successive appearance of the same namelist-group-name in 16a scoping unit is treated as a continuation of the list for that namelist-group-name. 17A namelist group object may be a member of more than one namelist group. 18A namelist group object shall either be accessed by use or host association or shall have its type, type 19parameters, and shape specified by previous specification statements or the procedure heading in the 20same scoping unit or by the implicit typing rules in effect for the scoping unit. If a namelist group object 21is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall 22confirm the implied type and type parameters. NOTE 5.38 An example of a NAMELIST statement is: NAMELIST /NLIST/ A, B, C 5.7 Storage association of data objects 23 245.7.1 EQUIVALENCE statement 255.7.1.1 General 26An EQUIVALENCE statement is used to specify the sharing of storage units by two or more objects in a scoping unit. This causes storage association (16.5.3) of the objects that share the storage units. 27 NOTE 5.39 The co-size of a co-array is not a constant, therefore co-arrays are not allowed in COMMON or EQUIVALENCE. 28If the equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does 29not cause type conversion or imply mathematical equivalence. If a scalar and an array are equivalenced, 30the scalar does not have array properties and the array does not have the properties of a scalar. R564 equivalence-stmt is EQUIVALENCE equivalence-set-list 110 2006/01/05 WORKING DRAFT J3/07-007 1 R565 equivalence-set is ( equivalence-object , equivalence-object-list ) 2 3R566 equivalence-object is variable-name 4 or array-element 5 or substring 6C584 (R566) An equivalence-object shall not be a designator with a base object that is a dummy 7 argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ulti- 8 mate component, an object of a nonsequence derived type, an object of a derived type that has 9 a pointer at any level of component selection, an automatic object, a function name, an entry 10 name, a result name, a variable with the BIND attribute, a variable in a common block that 11 has the BIND attribute, or a named constant. C585 (R566) An equivalence-object shall not be a designator that has more than one part-ref . 12 C586 (R566) An equivalence-object shall not be a co-array or a subobject thereof. 13 C587 (R566) An equivalence-object shall not have the TARGET attribute. 14 15C588 (R566) Each subscript or substring range expression in an equivalence-object shall be an integer initialization expression (7.1.12). 16 17C589 (R565) If an equivalence-object is of type default integer, default real, double precision real, 18 default complex, default logical, default bits, or numeric sequence type, all of the objects in the 19 equivalence set shall be of these types. 20C590 (R565) If an equivalence-object is of type default character or character sequence type, all of the 21 objects in the equivalence set shall be of these types. 22C591 (R565) If an equivalence-object is of a sequence derived type that is not a numeric sequence or 23 character sequence type, all of the objects in the equivalence set shall be of the same type with 24 the same type parameter values. 25C592 (R565) If an equivalence-object is of an intrinsic type other than default integer, default real, 26 double precision real, default complex, default logical, or default character, all of the objects in 27 the equivalence set shall be of the same type with the same kind type parameter value. 28C593 (R566) If an equivalence-object has the PROTECTED attribute, all of the objects in the equiv- 29 alence set shall have the PROTECTED attribute. C594 (R566) The name of an equivalence-object shall not be a name made accessible by use association. 30 C595 (R566) A substring shall not have length zero. 31 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 111 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.40 (cont.) 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. 15.7.1.2 Equivalence association 2An EQUIVALENCE statement specifies that the storage sequences (16.5.3.2) of the data objects specified 3in an equivalence-set are storage associated. All of the nonzero-sized sequences in the equivalence-set, if 4any, have the same first storage unit, and all of the zero-sized sequences in the equivalence-set, if any, 5are storage associated with one another and with the first storage unit of any nonzero-sized sequences. 6This causes the storage association of the data objects in the equivalence-set and may cause storage 7association of other data objects. 85.7.1.3 Equivalence of default character objects 9A data object of type default character shall not be equivalenced to an object that is not of type default 10character and not of a character sequence type. The lengths of equivalenced default character objects 11need not be the same. 12An EQUIVALENCE statement specifies that the storage sequences of all the default character data 13objects specified in an equivalence-set are storage associated. All of the nonzero-sized sequences in the 14equivalence-set, if any, have the same first character storage unit, and all of the zero-sized sequences in 15the equivalence-set, if any, are storage associated with one another and with the first character storage 16unit of any nonzero-sized sequences. This causes the storage association of the data objects in the 17equivalence-set and may cause storage association of other data objects. 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) ---| 185.7.1.4 Array names and array element designators 19For a nonzero-sized array, the use of the array name unqualified by a subscript list as an equivalence- 20object has the same effect as using an array element designator that identifies the first element of the 21array. 112 2006/01/05 WORKING DRAFT J3/07-007 15.7.1.5 Restrictions on EQUIVALENCE statements 2An EQUIVALENCE statement shall not specify that the same storage unit is to occur more than once 3in a storage sequence. 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). 4An EQUIVALENCE statement shall not specify that consecutive storage units are to be nonconsecutive. 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 55.7.2 COMMON statement 65.7.2.1 General 7The COMMON statement specifies blocks of physical storage, called common blocks, that can be 8accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global data facility based on storage association (16.5.3). 9 10The common blocks specified by the COMMON statement may be named and are called named com- 11mon blocks, or may be unnamed and are called blank common. 12R567 common-stmt is COMMON 13 [ / [ common-block-name ] / ] common-block-object-list 14 [ [ , ] / [ common-block-name ] / common-block-object-list ] ... 15 16R568 common-block-object is variable-name [ ( array-spec ) ] 17 or proc-pointer-name C596 (R568) An array-spec in a common-block-object shall be an explicit-shape-spec-list. 18 19C597 (R568) Only one appearance of a given variable-name or proc-pointer-name is permitted in all 20 common-block-object-lists within a scoping unit. 21C598 (R568) A common-block-object shall not be a dummy argument, an allocatable variable, a 22 derived-type object with an ultimate component that is allocatable, an automatic object, a 23 function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. 24C599 (R568) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2.3) or a 25 type with the BIND attribute and it shall have no default initialization. 26C5100 (R568) A variable-name or proc-pointer-name shall not be a name made accessible by use 113 J3/07-007 WORKING DRAFT 2006/01/05 1 association. 2In each COMMON statement, the data objects whose names appear in a common block object list 3following a common block name are declared to be in that common block. If the first common block 4name is omitted, all data objects whose names appear in the first common block object list are specified to 5be in blank common. Alternatively, the appearance of two slashes with no common block name between 6them declares the data objects whose names appear in the common block object list that follows to be 7in blank common. 8Any common block name or an omitted common block name for blank common may occur more than 9once in one or more COMMON statements in a scoping unit. The common block list following each 10successive appearance of the same common block name in a scoping unit is treated as a continuation of 11the list for that common block name. Similarly, each blank common block object list in a scoping unit 12is treated as a continuation of blank common. The form variable-name (array-spec) specifies the DIMENSION attribute for that variable. 13 14If derived-type objects of numeric sequence type (4.5.2) or character sequence type (4.5.2) appear in 15common, it is as if the individual components were enumerated directly in the common list. NOTE 5.44 Examples of COMMON statements are: COMMON /BLOCKA/ A, B, D (10, 30) COMMON I, J, K 165.7.2.2 Common block storage sequence 17For each common block in a scoping unit, a common block storage sequence is formed as follows: 18 (1) A storage sequence is formed consisting of the sequence of storage units in the storage 19 sequences (16.5.3.2) of all data objects in the common block object lists for the common 20 block. The order of the storage sequences is the same as the order of the appearance of the 21 common block object lists in the scoping unit. 22 (2) The storage sequence formed in (1) is extended to include all storage units of any storage 23 sequence associated with it by equivalence association. The sequence shall be extended only 24 by adding storage units beyond the last storage unit. Data objects associated with an entity 25 in a common block are considered to be in that common block. 26Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute 27to common block storage sequences formed in that scoping unit. 285.7.2.3 Size of a common block 29The size of a common block is the size of its common block storage sequence, including any extensions 30of the sequence resulting from equivalence association. 315.7.2.4 Common association 32Within a program, the common block storage sequences of all nonzero-sized common blocks with the 33same name have the same first storage unit, and the common block storage sequences of all zero-sized 34common blocks with the same name are storage associated with one another. Within a program, the 35common block storage sequences of all nonzero-sized blank common blocks have the same first storage 36unit and the storage sequences of all zero-sized blank common blocks are associated with one another and 37with the first storage unit of any nonzero-sized blank common blocks. This results in the association of 114 2006/01/05 WORKING DRAFT J3/07-007 1objects in different scoping units. Use association or host association may cause these associated objects 2to be accessible in the same scoping unit. 3A nonpointer object of default integer type, default real type, double precision real type, default complex 4type, default logical type, or numeric sequence type shall be associated only with nonpointer objects of 5these types. 6A nonpointer object of type default character or character sequence type shall be associated only with 7nonpointer objects of these types. 8A nonpointer object of a derived type that is not a numeric sequence or character sequence type shall 9be associated only with nonpointer objects of the same type with the same type parameter values. 10A nonpointer object of intrinsic type other than default integer, default real, double precision real, 11default complex, default logical, or default character shall be associated only with nonpointer objects of 12the same type and type parameters. 13A data pointer shall be storage associated only with data pointers of the same type and rank. Data 14pointers that are storage associated shall have deferred the same type parameters; corresponding non- 15deferred type parameters shall have the same value. A procedure pointer shall be storage associated 16only with another procedure pointer; either both interfaces shall be explicit or both interfaces shall be 17implicit. If the interfaces are explicit, the characteristics shall be the same. If the interfaces are implicit, 18either both shall be subroutines or both shall be functions with the same type and type parameters. 19An object with the TARGET attribute shall be storage associated only with another object that has 20the TARGET attribute and the same type and type parameters. 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). 215.7.2.5 Differences between named common and blank common 22A blank common block has the same properties as a named common block, except for the following. 23 (1) Execution of a RETURN or END statement might cause data objects in a named common 24 block to become undefined unless the common block has the SAVE attribute or is declared 25 in a module or submodule, but never causes data objects in blank common to become undefined (16.6.6). 26 27 (2) Named common blocks of the same name shall be of the same size in all scoping units of a 28 program in which they appear, but blank common blocks may be of different sizes. 29 (3) A data object in a named common block may be initially defined by means of a DATA 30 statement or type declaration statement in a block data program unit (11.3), but objects in 31 blank common shall not be initially defined. 5.7.3 Restrictions on common and equivalence 32 33An EQUIVALENCE statement shall not cause the storage sequences of two different common blocks to 34be associated. 115 J3/07-007 WORKING DRAFT 2006/01/05 1Equivalence association shall not cause a derived-type object with default initialization to be associated 2with an object in a common block. 3Equivalence association shall not cause a common block storage sequence to be extended by adding 4storage units preceding the first storage unit of the first object specified in a COMMON statement for 5the common block. NOTE 5.46 For example, the following is not permitted: COMMON /X/ A REAL B (2) EQUIVALENCE (A, B (2)) ! Not standard-conforming 116 2006/01/05 WORKING DRAFT J3/07-007 6 Use of data objects 1 2The appearance of a data object designator in a context that requires its value is termed a reference. A 3reference is permitted only if the data object is defined. A reference to a pointer is permitted only if the 4pointer is associated with a target object that is defined. A data object becomes defined with a value 5when events described in 16.6.5 occur. 6R601 variable is designator 7 or expr 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 10A variable is either the data object denoted by designator or the target of expr. 11R602 variable-name is name C603 (R602) variable-name shall be the name of a variable. 12 13R603 designator is object-name 14 or array-element 15 or array-section 16 or complex-part-designator 17 or structure-component 18 or substring 19R604 logical-variable is variable C604 (R604) logical-variable shall be of type logical. 20 21R605 default-logical-variable is variable C605 (R605) default-logical-variable shall be of type default logical. 22 23R606 char-variable is variable C606 (R606) char-variable shall be of type character. 24 25R607 default-char-variable is variable C607 (R607) default-char-variable shall be of type default character. 26 27R608 int-variable is variable 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.20 then A, B, B (1), B (1:5), P % AGE, and A (1:1) are all variables. 117 J3/07-007 WORKING DRAFT 2006/01/05 1A constant (3.2.2) is a literal constant or a named constant. A literal constant is a scalar denoted by a 2syntactic form, which indicates its type, type parameters, and value. A named constant is a constant 3that has a name; the name has the PARAMETER attribute (5.3.12, 5.4.10). A reference to a constant 4is always permitted; redefinition of a constant is never permitted. 56.1 Scalars 6.1.1 Substrings 6 A substring is a contiguous portion of a character string (4.4.5). 7 R609 substring is parent-string ( substring-range ) 8 9R610 parent-string is scalar-variable-name 10 or array-element 11 or scalar-structure-component 12 or scalar-constant R611 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] 13 C609 (R610) parent-string shall be of type character. 14 15The value of the first scalar-int-expr in substring-range is called the starting point and the value of 16the second one is called the ending point. The length of a substring is the number of characters in the substring and is MAX (l - f + 1, 0), where f and l are the starting and ending points, respectively. 17 18Let the characters in the parent string be numbered 1, 2, 3, ..., n, where n is the length of the parent 19string. Then the characters in the substring are those from the parent string from the starting point and 20proceeding in sequence up to and including the ending point. Both the starting point and the ending 21point shall be within the range 1, 2, ..., n unless the starting point exceeds the ending point, in which 22case the substring has length zero. If the starting point is not specified, the default value is 1. If the 23ending point is not specified, the default value is n. 24If the parent is a variable, the substring is also a variable. NOTE 6.2 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 25 26A structure component is part of an object of derived type; it may be referenced by an object 27designator. A structure component may be a scalar or an array. R612 data-ref is part-ref [ % part-ref ] ... 28 R613 part-ref is part-name [ ( section-subscript-list ) ] [ image-selector ] 29 C610 (R612) Each part-name except the rightmost shall be of derived type. 30 31C611 (R612) Each part-name except the leftmost shall be the name of a component of the declared 118 2006/01/05 WORKING DRAFT J3/07-007 1 type of the preceding part-name. C612 (R612) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. 2 C613 (R612) The leftmost part-name shall be the name of a data object. 3 4C614 (R613) If a section-subscript-list appears, the number of section-subscripts shall equal the rank 5 of part-name. 6C615 (R613) If image-selector appears, the number of co-subscripts shall be equal to the co-rank of 7 part-name. C616 (R613) If image-selector appears and part-name is an array, section-subscript-list shall appear. 8 9C617 (R612) If image-selector appears, data-ref shall not be, or have a direct component, of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 10 C618 (R612) A data-ref that is a co-indexed object shall not have a pointer ultimate component. 11 NOTE 6.3 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 12The rank of a part-ref of the form part-name is the rank of part-name. The rank of a part-ref that has 13a section subscript list is the number of subscript triplets and vector subscripts in the list. 14C619 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right 15 of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. 16The rank of a data-ref is the rank of the part-ref with nonzero rank, if any; otherwise, the rank is zero. 17The base object of a data-ref is the data object whose name is the leftmost part name. 18The type and type parameters, if any, of a data-ref are those of the rightmost part name. 19A data-ref with more than one part-ref is a subobject of its base object if none of the part-names, 20except for possibly the rightmost, are pointers. If the rightmost part-name is the only pointer, then the 21data-ref is a subobject of its base object in contexts that pertain to its pointer association status but 22not in any other contexts. NOTE 6.4 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. 23R614 structure-component is data-ref 24C620 (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form 25 part-name. 26A structure component shall be neither referenced nor defined before the declaration of the base object. 27A structure component is a pointer only if the rightmost part name is defined to have the POINTER 28attribute. 119 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 6.5 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.6 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. 1A subcomponent of an object of derived type is a component of that object or of a subobject of that 2object. 3A data-ref shall not be a co-indexed object that has a pointer subcomponent. A data-ref that is a 4co-indexed object shall not be, or have a subcomponent, of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 5 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 6 7A complex part designator is used to designate the real or imaginary part of a complex data object, 8independently of the other part. 9R615 complex-part-designator is designator % RE 10 or designator % IM C621 (R615) The designator shall be of complex type. 11 12If complex-part-designator is designator%RE it designates the real part of designator. If it is designa- 13tor%IM it designates the imaginary part of designator. The type of a complex-part-designator is real, 120 2006/01/05 WORKING DRAFT J3/07-007 1and its kind and shape are those of the designator. NOTE 6.7 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 2 3A type parameter inquiry is used to inquire about a type parameter of a data object. It applies to 4both intrinsic and derived types. 5R616 type-param-inquiry is designator % type-param-name 6C622 (R616) The type-param-name shall be the name of a type parameter of the declared type of the 7 object designated by the designator. 8A deferred type parameter of a pointer that is not associated or of an unallocated allocatable variable 9shall not be inquired about. NOTE 6.8 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.9 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.27 for the definition of the general_point type used in the last example above. 6.2 Arrays 10 11An array is a set of scalar data, all of the same type and type parameters, whose individual elements 12are arranged in a rectangular pattern. The scalar data that make up an array are the array elements. 13No order of reference to the elements of an array is indicated by the appearance of the array designator, except where array element ordering (6.2.2.1) is specified. 14 6.2.1 Whole arrays 15 16A whole array is a named array, which may be either a named constant (5.3.12, 5.4.10) or a variable; 17no subscript list is appended to the name. 121 J3/07-007 WORKING DRAFT 2006/01/05 1The appearance of a whole array variable in an executable construct specifies all the elements of the 2array (2.4.5). An assumed-size array is permitted to appear as a whole array in an executable construct 3only as an actual argument in a procedure reference that does not require the shape. 4The appearance of a whole array name in a nonexecutable statement specifies the entire array except for the appearance of a whole array name in an equivalence set (5.7.1.4). 5 6.2.2 Array elements and array sections 6 7R617 array-element is data-ref C623 (R617) Every part-ref shall have rank zero and the last part-ref shall contain a subscript-list. 8 9R618 array-section is data-ref [ ( substring-range ) ] 10 or complex-part-designator 11C624 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have 12 a section-subscript-list with nonzero rank, another part-ref shall have nonzero rank, or the 13 complex-part-designator shall be an array. C625 (R618) If a substring-range appears, the rightmost part-name shall be of type character. 14 15R619 subscript is scalar-int-expr 16R620 section-subscript is subscript 17 or subscript-triplet 18 or vector-subscript R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ] 19 20R622 stride is scalar-int-expr 21R623 vector-subscript is int-expr C626 (R623) A vector-subscript shall be an integer array expression of rank one. 22 23C627 (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension 24 of an assumed-size array. 25An array element is a scalar. An array section is an array. If a substring-range is present in an array- 26section, each element is the designated substring of the corresponding element of the array section. 27The value of a subscript in an array element shall be within the bounds for that dimension. NOTE 6.10 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.11 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 122 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.11 (cont.) ALLOCATABLE attribute. NOTE 6.12 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 16.2.2.1 Array element order 2The elements of an array form a sequence known as the array element order. The position of an array 3element in this sequence is determined by the subscript order value of the subscript list designating the 4element. The subscript order value is computed from the formulas in Table 6.1. Table 6.1: Subscript order value Rank Subscript bounds Subscript list Subscript order value 1 j1:k1 s1 1 + (s1 - j1) 1 + (s1 - j1) 2 j1:k1,j2:k2 s1,s2 +(s2 - j2) × d1 1 + (s1 - j1) 3 j1:k1,j2:k2,j3:k3 s1,s2,s3 +(s2 - j2) × d1 +(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. 56.2.2.2 Array sections 6An array section is an array subobject optionally followed by a substring range. 7In an array-section having a section-subscript-list, each subscript-triplet and vector-subscript in the 8section subscript list indicates a sequence of subscripts, which may be empty. Each subscript in such a 9sequence shall be within the bounds for its dimension unless the sequence is empty. The array section is 10the set of elements from the array determined by all possible subscript lists obtainable from the single 11subscripts or sequences of subscripts specified by each section subscript. 12In an array-section with no section-subscript-list, the rank and shape of the array is the rank and shape 13of the part-ref with nonzero rank; otherwise, the rank of the array section is the number of subscript 14triplets and vector subscripts in the section subscript list. The shape is the rank-one array whose ith 123 J3/07-007 WORKING DRAFT 2006/01/05 1element is the number of integer values in the sequence indicated by the ith subscript triplet or vector 2subscript. If any of these sequences is empty, the array section has size zero. The subscript order of the 3elements of an array section is that of the array data object that the array section represents. 46.2.2.2.1 Subscript triplet 5A subscript triplet designates a regular sequence of subscripts consisting of zero or more subscript values. 6The third expression in the subscript triplet is the increment between the subscript values and is called 7the stride. The subscripts and stride of a subscript triplet are optional. An omitted first subscript in a 8subscript triplet is equivalent to a subscript whose value is the lower bound for the array and an omitted 9second subscript is equivalent to the upper bound. An omitted stride is equivalent to a stride of 1. 10The stride shall not be zero. 11When the stride is positive, the subscripts specified by a triplet form a regularly spaced sequence of 12integers beginning with the first subscript and proceeding in increments of the stride to the largest such 13integer not greater than the second subscript; the sequence is empty if the first subscript is greater than 14the second. NOTE 6.13 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): A (3, 2, 1) A (3, 2, 2) A (4, 2, 1) A (4, 2, 2) A (5, 2, 1) A (5, 2, 2) 15When the stride is negative, the sequence begins with the first subscript and proceeds in increments of 16the stride down to the smallest such integer equal to or greater than the second subscript; the sequence 17is empty if the second subscript is greater than the first. NOTE 6.14 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.15 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. 186.2.2.2.2 Vector subscript 19A vector subscript designates a sequence of subscripts corresponding to the values of the elements 20of the expression. Each element of the expression shall be defined. A many-one array section is an 21array section with a vector subscript having two or more elements with the same value. A many-one 22array section shall appear neither on the left of the equals in an assignment statement nor as an input 23item in a READ statement. 24An array section with a vector subscript shall not be argument associated with a dummy array that 25is defined or redefined. An array section with a vector subscript shall not be the target in a pointer 26assignment statement. An array section with a vector subscript shall not be an internal file. 124 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.16 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) 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 2An image selector specifies the image index for co-array data. 3R624 image-selector is lbracket co-subscript-list rbracket 4R625 co-subscript is scalar-int-expr 5The number of co-subscripts shall be equal to the co-rank of the object. The value of a co-subscript in 6an image selector shall be within the co-bounds for its co-dimension. Taking account of the co-bounds, 7the co-subscript list in an image selector determines the image index in the same way that a subscript 8list in an array element determines the subscript order value (6.2.2.1), taking account of the bounds. An 9image selector shall specify an image index value that is not greater than the number of images. NOTE 6.17 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 116.3.1 ALLOCATE statement 12The ALLOCATE statement dynamically creates pointer targets and allocatable variables. 13R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list [, alloc-opt-list ] ) 125 J3/07-007 WORKING DRAFT 2006/01/05 1R627 alloc-opt is ERRMSG = errmsg-variable 2 or MOLD = source-expr 3 or SOURCE = source-expr 4 or STAT = stat-variable 5R628 stat-variable is scalar-int-variable 6R629 errmsg-variable is scalar-default-char-variable 7R630 source-expr is expr 8R631 allocation is allocate-object [ ( allocate-shape-spec-list ) ] [ lbracket allocate-co-array-spec rbracket ] 9 10R632 allocate-object is variable-name 11 or structure-component R633 allocate-shape-spec is [ lower-bound-expr : ] upper-bound-expr 12 13R634 lower-bound-expr is scalar-int-expr 14R635 upper-bound-expr is scalar-int-expr R636 allocate-co-array-spec is [ allocate-co-shape-spec-list , ] [ lower-bound-expr : ] * 15 R637 allocate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr 16 C628 (R632) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 17 18C629 (R626) If any allocate-object has a deferred type parameter, is unlimited polymorphic, or is of 19 abstract type, either type-spec or source-expr shall appear. 20C630 (R626) If a type-spec appears, it shall specify a type with which each allocate-object is type 21 compatible. 22C631 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each allocate-object 23 is a dummy argument for which the corresponding type parameter is assumed. 24C632 (R626) If a type-spec appears, the kind type parameter values of each allocate-object shall be 25 the same as the corresponding type parameter values of the type-spec. 26C633 (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr 27 shall appear and have the same rank as allocate-object. If allocate-object is scalar, allocate- 28 shape-spec-list shall not appear. C634 (R631) An allocate-co-array-spec shall appear if and only if the allocate-object is a co-array. 29 30C635 (R631) The number of allocate-shape-specs in an allocate-shape-spec-list shall be the same as the 31 rank of the allocate-object. The number of allocate-co-shape-specs in an allocate-co-array-spec 32 shall be one less than the co-rank of the allocate-object. C636 (R627) No alloc-opt shall appear more than once in a given alloc-opt-list. 33 C637 (R626) At most one of source-expr and type-spec shall appear. 34 35C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with source-expr. If SOURCE= 36 appears, source-expr shall be a scalar or have the same rank as each allocate-object. 37C639 (R626) Corresponding kind type parameters of allocate-object and source-expr shall have the 126 2006/01/05 WORKING DRAFT J3/07-007 1 same values. C640 (R626) type-spec shall not specify a type that has a co-array ultimate component. 2 C641 (R630) The declared type of source-expr shall not have a co-array ultimate component. 3 C642 (R632) An allocate-object shall not be a co-indexed object. 4 NOTE 6.18 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 ALLOCATE(T[Q]%AAC(N)) ! Not allowed, because it is not ! necessarily executed on image Q. 5An allocate-object or a bound or type parameter of an allocate-object shall not depend on the value of 6stat-variable, the value of errmsg-variable, or on the value, bounds, length type parameters, allocation 7status, or association status of any allocate-object in the same ALLOCATE statement. 8source-expr shall not be allocated within the ALLOCATE statement in which it appears; nor shall it 9depend on the value, bounds, deferred type parameters, allocation status, or association status of any 10allocate-object in that statement. 11If type-spec is specified, each allocate-object is allocated with the specified dynamic type and type pa- 12rameter values; if source-expr is specified, each allocate-object is allocated with the dynamic type and 13type parameter values of source-expr; otherwise, each allocate-object is allocated with its dynamic type 14the same as its declared type. 15If type-spec appears and the value of a type parameter it specifies differs from the value of the corre- 16sponding nondeferred type parameter specified in the declaration of any allocate-object, an error condition 17occurs. If the value of a nondeferred length type parameter of an allocate-object differs from the value 18of the corresponding type parameter of source-expr, an error condition occurs. 19If a type-param-value in a type-spec in an ALLOCATE statement is an asterisk, it denotes the current 20value of that assumed type parameter. If it is an expression, subsequent redefinition or undefinition of 21any entity in the expression does not affect the type parameter value. NOTE 6.19 An example of an ALLOCATE statement is: ALLOCATE (X (N), B (-3 : M, 0:9), STAT = IERR_ALLOC) 22When an ALLOCATE statement is executed for an array for which allocate-shape-spec-list is specified, 23the values of the lower bound and upper bound expressions determine the bounds of the array. Subse- 24quent redefinition or undefinition of any entities in the bound expressions do not affect the array bounds. 25If the lower bound is omitted, the default value is 1. If the upper bound is less than the lower bound, 26the extent in that dimension is zero and the array has zero size. 27When an ALLOCATE statement is executed for a co-array, the values of the lower co-bound and upper 28co-bound expressions determine the co-bounds of the co-array. Subsequent redefinition or undefinition 127 J3/07-007 WORKING DRAFT 2006/01/05 1of any entities in the co-bound expressions do not affect the co-bounds. If the lower co-bound is omitted, 2the default value is 1. The upper co-bound shall not be less than the lower co-bound. 3The value of each lower-bound-expr and each upper-bound-expr in an allocate-co-array-spec shall be the 4same on each image. 5If an allocation specifies a co-array, its dynamic type and the values of each length type parameter shall 6be the same on each image. 7There is implicit synchronization of all images in association with each ALLOCATE statement that 8involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 9is delayed until all other images have executed the same statement the same number of times. NOTE 6.20 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). 10If source-expr is a pointer, it shall be associated with a target. If source-expr is allocatable, it shall be 11allocated. 12When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds 13of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do 14not affect the array bounds. 15If SOURCE= appears, source-expr shall be conformable (2.4.5) with allocation. If the value of a non- 16deferred length type parameter of allocate-object is different from the value of the corresponding type 17parameter of source-expr, an error condition occurs. On successful allocation, if allocate-object and 18source-expr have the same rank the value of allocate-object becomes that of source-expr, otherwise the 19value of each element of allocate-object becomes that of source-expr. 20If MOLD= appears and source-expr is a variable, its value need not be defined. 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.21 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 ! ... 128 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.21 (cont.) ALLOCATE (NEW, SOURCE=OLD) ! Allocate NEW with the value and dynamic type of OLD A more extensive example is given in C.3.2. 1The STAT= specifier is described in 6.3.4. 2If an error condition occurs during execution of an ALLOCATE statement that does not contain the 3STAT= specifier, execution of the program is terminated. 4The ERRMSG= specifier is described in 6.3.5. 56.3.1.1 Allocation of allocatable variables 6The allocation status of an allocatable entity is one of the following at any time. 7 (1) The status of an allocatable variable becomes allocated if it is allocated by an ALLOCATE 8 statement, if it is allocated during assignment, or if it is given that status by the allocation 9 transfer procedure (13.7.124). An allocatable variable with this status may be referenced, 10 defined, or deallocated; allocating it causes an error condition in the ALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns true for such a variable. 11 12 (2) An allocatable variable has a status of unallocated if it is not allocated. The status of 13 an allocatable variable becomes unallocated if it is deallocated (6.3.3) or if it is given that 14 status by the allocation transfer procedure. An allocatable variable with this status shall 15 not be referenced or defined. It shall not be supplied as an actual argument corresponding 16 to a nonallocatable dummy argument, except to certain intrinsic inquiry functions. It may 17 be allocated with the ALLOCATE statement. Deallocating it causes an error condition in 18 the DEALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns false 19 for such a variable. 20At the beginning of execution of a program, allocatable variables are unallocated. 21When the allocation status of an allocatable variable changes, the allocation status of any associated 22allocatable variable changes accordingly. Allocation of an allocatable variable establishes values for the 23deferred type parameters of all associated allocatable variables. 24An unsaved allocatable local variable of a procedure has a status of unallocated at the beginning of 25each invocation of the procedure. An unsaved allocatable local variable of a module or submodule, or 26a subobject thereof, has an initial status of unallocated. An unsaved local variable of a construct has a 27status of unallocated at the beginning of each execution of the construct. 28When an object of derived type is created by an ALLOCATE statement, any allocatable ultimate 29components have an allocation status of unallocated. 306.3.1.2 Allocation of pointer targets 31Allocation of a pointer creates an object that implicitly has the TARGET attribute. Following successful 32execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may 33be used to reference or define the target. Additional pointers may become associated with the pointer 34target or a part of the pointer target by pointer assignment. It is not an error to allocate a pointer 35that is already associated with a target. In this case, a new pointer target is created as required by the 36attributes of the pointer and any array bounds, type, and type parameters specified by the ALLOCATE 37statement. The pointer is then associated with this new target. Any previous association of the pointer 38with a target is broken. If the previous target had been created by allocation, it becomes inaccessible 39unless other pointers are associated with it. The ASSOCIATED intrinsic function (13.7.15) may be used 129 J3/07-007 WORKING DRAFT 2006/01/05 1to determine whether a pointer that does not have undefined association status is associated. 2At the beginning of execution of a function whose result is a pointer, the association status of the result 3pointer is undefined. Before such a function returns, it shall either associate a target with this pointer 4or cause the association status of this pointer to become disassociated. 56.3.2 NULLIFY statement 6The NULLIFY statement causes pointers to be disassociated. R638 nullify-stmt is NULLIFY ( pointer-object-list ) 7 8R639 pointer-object is variable-name 9 or structure-component 10 or proc-pointer-name C643 (R639) Each pointer-object shall have the POINTER attribute. 11 12A pointer-object shall not depend on the value, bounds, or association status of another pointer-object 13in the same NULLIFY statement. NOTE 6.22 When a NULLIFY statement is applied to a polymorphic pointer (4.3.1.3), its dynamic type becomes the declared type. 146.3.3 DEALLOCATE statement 15The DEALLOCATE statement causes allocatable variables to be deallocated; it causes pointer tar- 16gets to be deallocated and the pointers to be disassociated. R640 deallocate-stmt is DEALLOCATE ( allocate-object-list [ , dealloc-opt-list ] ) 17 C644 (R640) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 18 19R641 dealloc-opt is STAT = stat-variable 20 or ERRMSG = errmsg-variable C645 (R641) No dealloc-opt shall appear more than once in a given dealloc-opt-list. 21 22An allocate-object shall not depend on the value, bounds, allocation status, or association status of 23another allocate-object in the same DEALLOCATE statement; it also shall not depend on the value of 24the stat-variable or errmsg-variable in the same DEALLOCATE statement. 25The STAT= specifier is described in 6.3.4. 26If an error condition occurs during execution of a DEALLOCATE statement that does not contain the 27STAT= specifier, execution of the program is terminated. 28The ERRMSG= specifier is described in 6.3.5. NOTE 6.23 An example of a DEALLOCATE statement is: DEALLOCATE (X, B) 296.3.3.1 Deallocation of allocatable variables 130 2006/01/05 WORKING DRAFT J3/07-007 1Deallocating an unallocated allocatable variable causes an error condition in the DEALLOCATE state- 2ment. Deallocating an allocatable variable with the TARGET attribute causes the pointer association 3status of any pointer associated with it to become undefined. 4When the execution of a procedure is terminated by execution of a RETURN or END statement, an 5unsaved allocatable local variable of the procedure retains its allocation and definition status if it is a 6function result variable or a subobject thereof; otherwise, it is deallocated. 7When a BLOCK construct terminates, an unsaved allocatable local variable of the construct is deallo- 8cated. NOTE 6.24 The ALLOCATED intrinsic function may be used to determine whether a variable is allocated or unallocated. 9If an executable construct references a function whose result is either allocatable or a structure with 10a subobject that is allocatable, and the function reference is executed, an allocatable result and any 11subobject that is an allocated allocatable entity in the result returned by the function is deallocated 12after execution of the innermost executable construct containing the reference. 13If a function whose result is either allocatable or a structure with an allocatable subobject is referenced 14in the specification part of a scoping unit or BLOCK construct, and the function reference is executed, 15an allocatable result and any subobject that is an allocated allocatable entity in the result returned by 16the function is deallocated before execution of the executable constructs of the scoping unit or block. 17When a procedure is invoked, any allocated allocatable object that is an actual argument associated with 18an INTENT(OUT) allocatable dummy argument is deallocated; any allocated allocatable object that is a subobject of an actual argument associated with an INTENT(OUT) dummy argument is deallocated. 19 20When an intrinsic assignment statement (7.2.1.3) is executed, any non-co-array allocated allocatable 21subobject of the variable is deallocated before the assignment takes place. 22When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. 23If an allocatable component is a subobject of a finalizable object, that object is finalized before the 24component is automatically deallocated. 25The effect of automatic deallocation is the same as that of a DEALLOCATE statement without a 26dealloc-opt-list. NOTE 6.25 In the following example: SUBROUTINE PROCESS REAL, ALLOCATABLE :: TEMP(:) REAL, ALLOCATABLE, SAVE :: X(:) ... 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. 27There is implicit synchronization of all images in association with each DEALLOCATE statement that 28involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 131 J3/07-007 WORKING DRAFT 2006/01/05 1is delayed until all other images have executed the same statement the same number of times. 2There is also an implicit synchronization of all images in association with the deallocation of a co-array 3or co-array subcomponent caused by the execution of a RETURN or END statement or the termination 4of a BLOCK construct. 56.3.3.2 Deallocation of pointer targets 6If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating 7a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an 8error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, 9the pointer shall not be deallocated. 10If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object 11that was created by allocation. Deallocating a pointer target causes the pointer association status of 12any other pointer that is associated with the target or a portion of the target to become undefined. 6.3.4 STAT= specifier 13 14stat-variable shall not be allocated or deallocated within the ALLOCATE or DEALLOCATE statement 15in which it appears; nor shall it depend on the value, bounds, deferred type parameters, allocation status, 16or association status of any allocate-object in that statement. 17If the STAT= specifier appears, successful execution of the ALLOCATE or DEALLOCATE statement 18causes the stat-variable to become defined with a value of zero. 19If an error condition occurs during the execution of the ALLOCATE or DEALLOCATE statement, the 20stat-variable becomes defined with a processor-dependent positive integer value and each allocate-object 21will have a processor-dependent status: 22 · each allocate-object that was successfully allocated shall have an allocation status of allocated or 23 a pointer association status of associated; 24 · each allocate-object that was successfully deallocated shall have an allocation status of unallocated 25 or a pointer association status of disassociated; 26 · each allocate-object that was not successfully allocated or deallocated shall retain its previous 27 allocation status or pointer association status. NOTE 6.26 The status of objects that were not successfully allocated or deallocated can be individually checked with the ALLOCATED or ASSOCIATED intrinsic functions. 6.3.5 ERRMSG= specifier 28 29errmsg-variable shall not be allocated or deallocated within the ALLOCATE or DEALLOCATE state- 30ment in which it appears; nor shall it depend on the value, bounds, deferred type parameters, allocation 31status, or association status of any allocate-object in that statement. 32If an error condition occurs during execution of an ALLOCATE or DEALLOCATE statement, the 33processor shall assign an explanatory message to errmsg-variable. If no such condition occurs, the 34processor shall not change the value of errmsg-variable. 132 2006/01/05 WORKING DRAFT J3/07-007 7 Expressions and assignment 1 7.1 Expressions 2 37.1.1 General 4An expression represents either a data reference or a computation, and its value is either a scalar or 5an array. An expression is formed from operands, operators, and parentheses. 6An operand is either a scalar or an array. An operation is either intrinsic (7.1.5) or defined (7.1.6). More 7complicated expressions can be formed using operands which are themselves expressions. 8Evaluation of an expression produces a value, which has a type, type parameters (if appropriate), and a shape (7.1.9). The co-rank of an expression that is not a variable is zero. 9 7.1.2 Form of an expression 10 117.1.2.1 Expression categories 12An expression is defined in terms of several categories: primary, level-1 expression, level-2 expression, 13level-3 expression, level-4 expression, and level-5 expression. 14These categories are related to the different operator precedence levels and, in general, are defined in 15terms of other categories. The simplest form of each expression category is a primary. 167.1.2.2 Primary 17R701 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 or ( expr ) 24 C701 (R701) The type-param-name shall be the name of a type parameter. 25 C702 (R701) The designator shall not be a whole assumed-size array. 26 NOTE 7.1 Examples of a primary are: Example Syntactic class 1.0 constant 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' (I:I) designator [ 1.0, 2.0 ] array-constructor PERSON (12, 'Jones') structure-constructor F (X, Y) function-reference X%KIND type-param-inquiry 133 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.1 (cont.) KIND type-param-name (S + T) (expr) 17.1.2.3 Level-1 expressions 2Defined unary operators have the highest operator precedence (Table 7.2). Level-1 expressions are 3primaries optionally operated on by defined unary operators: R702 level-1-expr is [ defined-unary-op ] primary 4 R703 defined-unary-op is . letter [ letter ] ... . 5 6C703 (R703) A defined-unary-op shall not contain more than 63 letters and shall not be the same as 7 any intrinsic-operator or logical-literal-constant. NOTE 7.2 Simple examples of a level-1 expression are: Example Syntactic class A primary (R701) .INVERSE. B level-1-expr (R702) A more complicated example of a level-1 expression is: .INVERSE. (A + B) 87.1.2.4 Level-2 expressions 9Level-2 expressions are level-1 expressions optionally involving the numeric operators power-op, mult-op, 10and add-op. 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 14R707 power-op is ** 15R708 mult-op is * or / 16 17R709 add-op is + 18 or ­ NOTE 7.3 Simple examples of a level-2 expression are: Example Syntactic class Remarks A level-1-expr A is a primary. (R702) B ** C mult-operand B is a level-1-expr, ** is a power-op, and C is a mult-operand. (R704) D * E add-operand D is an add-operand, * is a mult-op, and E is a mult-operand. (R705) 134 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.3 (cont.) +1 level-2-expr + is an add-op and 1 is an add-operand. (R706) F - I level-2-expr F is a level-2-expr, ­ is an add-op, and I is an add-operand. (R706) A more complicated example of a level-2 expression is: - A + D * E + B ** C 17.1.2.5 Level-3 expressions 2Level-3 expressions are level-2 expressions optionally involving the character operator and bits concate- 3nation operator concat-op. 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 A level-2-expr (R706) B // C level-3-expr (R710) A more complicated example of a level-3 expression is: X // Y // 'ABCD' 67.1.2.6 Level-4 expressions 7Level-4 expressions are level-3 expressions optionally involving the relational operators rel-op. R712 level-4-expr is [ level-3-expr rel-op ] level-3-expr 8 9R713 rel-op is .EQ. 10 or .NE. 11 or .LT. 12 or .LE. 13 or .GT. 14 or .GE. 15 or == 16 or /= 17 or < 18 or <= 19 or > 20 or >= NOTE 7.5 Simple examples of a level-4 expression are: 135 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.5 (cont.) Example Syntactic class A level-3-expr (R710) B == C level-4-expr (R712) D < E level-4-expr (R712) A more complicated example of a level-4 expression is: (A + B) /= C 17.1.2.7 Level-5 expressions 2Level-5 expressions are level-4 expressions optionally involving the logical and bits operators not-op, 3and-op, or-op, and equiv-op. R714 and-operand is [ not-op ] level-4-expr 4 R715 or-operand is [ or-operand and-op ] and-operand 5 R716 equiv-operand is [ equiv-operand or-op ] or-operand 6 R717 level-5-expr is [ level-5-expr equiv-op ] equiv-operand 7 8R718 not-op is .NOT. 9R719 and-op is .AND. 10R720 or-op is .OR. 11R721 equiv-op is .EQV. 12 or .NEQV. 13 or .XOR. NOTE 7.6 Simple examples of a level-5 expression are: Example Syntactic class A level-4-expr (R712) .NOT. B and-operand (R714) C .AND. D or-operand (R715) E .OR. F equiv-operand (R716) G .EQV. H level-5-expr (R717) S .NEQV. T level-5-expr (R717) A more complicated example of a level-5 expression is: A .AND. B .EQV. .NOT. C 147.1.2.8 General form of an expression 15Expressions are level-5 expressions optionally involving defined binary operators. Defined binary oper- ators have the lowest operator precedence (Table 7.2). 16 R722 expr is [ expr defined-binary-op ] level-5-expr 17 R723 defined-binary-op is . letter [ letter ] ... . 18 136 2006/01/05 WORKING DRAFT J3/07-007 1C704 (R723) A defined-binary-op shall not contain more than 63 letters and shall not be the same as 2 any intrinsic-operator or logical-literal-constant. NOTE 7.7 Simple examples of an expression are: Example Syntactic class A level-5-expr (R717) B.UNION.C expr (R722) More complicated examples of an expression are: (B .INTERSECT. C) .UNION. (X - Y) A + B == C * D .INVERSE. (A + B) A + B .AND. C * D E // G == H (1:10) 7.1.3 Precedence of operators 3 4There is a precedence among the intrinsic and extension operations corresponding to the form of expres- 5sions specified in 7.1.2, which determines the order in which the operands are combined unless the order 6is changed by the use of parentheses. This precedence order is summarized in Table 7.2. Table 7.2: 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. . Logical, Bits .OR. . Logical, Bits .EQV., .NEQV., .XOR. . Extension defined-binary-op Lowest 7The precedence of a defined operation is that of its operator. NOTE 7.8 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) 137 J3/07-007 WORKING DRAFT 2006/01/05 1The general form of an expression (7.1.2) also establishes a precedence among operators in the same 2syntactic class. This precedence determines the order in which the operands are to be combined in 3determining the interpretation of the expression unless the order is changed by the use of parentheses. NOTE 7.9 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.2), 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: 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.10 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 138 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.10 (cont.) L .OR. ((A + B) >= C) NOTE 7.11 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.1.4 Evaluation of operations 1 2An intrinsic operation requires the values of its operands. 3The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other 4entity within the statement. If a function reference causes definition or undefinition of an actual argument 5of the function, that argument or any associated entities shall not appear elsewhere in the same statement. 6However, execution of a function reference in the logical expression in an IF statement (8.1.8.4), the mask 7expression in a WHERE statement (7.2.3.1), or the subscripts and strides in a FORALL statement (7.2.4) 8is permitted to define variables in the statement that is conditionally executed. 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. 9The appearance of an array constructor requires the evaluation of each scalar-int-expr of the ac-implied- 10do-control in any ac-implied-do it may contain. 11When an elemental binary operation is applied to a scalar and an array or to two arrays of the same 12shape, the operation is performed element-by-element on corresponding array elements of the array 13operands. NOTE 7.13 For example, the array expression A + B 139 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.13 (cont.) 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. 1When an elemental unary operator operates on an array operand, the operation is performed element- 2by-element, and the result is the same shape as the operand. 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.5 Intrinsic operations 3 47.1.5.1 Definitions 5An intrinsic operation is either an intrinsic unary operation or an intrinsic binary operation. An 6intrinsic unary operation is an operation of the form intrinsic-operator x2 where x2 is of an intrinsic type (4.4) listed in Table 7.3 for the unary intrinsic operator. 7 8An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and 9x2 are of the intrinsic types (4.4) listed in Table 7.3 for the binary intrinsic operator and are in shape conformance (7.1.10). 10 11A numeric intrinsic operation is an intrinsic operation for which the intrinsic-operator is a numeric 12operator (+, ­, *, /, or **). A numeric intrinsic operator is the operator in a numeric intrinsic 13operation. 14The character intrinsic operation is the intrinsic operation for which the intrinsic-operator is (//) 15and both operands are of type character. The operands shall have the same kind type parameter. The 16character intrinsic operator is the operator in a character intrinsic operation. 17A logical intrinsic operation is an intrinsic operation for which the intrinsic-operator is .AND., .OR., 18.XOR., .NOT., .EQV., or .NEQV. and both operands are of type logical. A logical intrinsic operator 19is the operator in a logical intrinsic operation. 20A bits intrinsic operation is an intrinsic operation for which the intrinsic-operator is //, .AND., .OR., 21.XOR., .NOT., .EQV., or .NEQV. and at least one operand is of type bits. A bits intrinsic operator 22is the operator in a bits intrinsic operation. 23A relational intrinsic operator is an intrinsic-operator that is .EQ., .NE., .GT., .GE., .LT., .LE., 24==, /=, >, >=, <, or <=. A relational intrinsic operation is an intrinsic operation for which the 25intrinsic-operator is a relational intrinsic operator. A numeric relational intrinsic operation is a 26relational intrinsic operation for which both operands are of numeric type. A character relational 27intrinsic operation is a relational intrinsic operation for which both operands are of type character. 28The kind type parameters of the operands of a character relational intrinsic operation shall be the same. 29A bits relational intrinsic operation is a relational intrinsic operation for which at least one of the 30operands is of type bits. 31The interpretations defined in subclause 7.1.5 apply to both scalars and arrays; the interpretation for 32arrays is obtained by applying the interpretation for scalars element by element. 140 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.15 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. Table 7.3: Type of operands and results for intrinsic operators Intrinsic operator Type of Type of Type of op x1 x2 [x1] op x2 Unary +, ­ I, R, Z I, R, Z I I, R, Z I, R, Z Binary +, ­, *, /, ** R I, R, Z R, R, Z Z I, R, Z Z, Z, Z // C C C B B B I I, R, Z, B L, L, L, L .EQ., .NE., R I, R, Z, B L, L, L, L ==, /= Z I, R, Z, B L, L, L, L B I, R, Z, B L, L, L, L C C L I I, R, B L, L, L .GT., .GE., .LT., .LE. R I, R, B L, L, L >, >=, <, <= B I, R, B L, L, L C C L .NOT. L, B L, B L L L .AND., .OR., .EQV., .NEQV., .XOR. 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. 141 J3/07-007 WORKING DRAFT 2006/01/05 J3 internal note Unresolved Technical Issue 104 Real-bits mixed-mode comparisons considered harmful. The feature of intrinsic mixed-mode comparisions between BITS and REAL is, in my opinion, a serious misfeature. I am speaking particularly about .LT., .LE., .GT., and .GE.. I understand perfectly well that BITS work like unsigned integers for comparisons between them- selves. I understand perfectly well that it is very convenient to do mixed-mode comparisons with BITS and INTEGER, and that when doing so, converting to "unsigned" is a reasonable thing to do... though see next paragraph. There are two schools of thought on this (what to convert mixed-mode operations between un- signed and signed integer to), "value-preserving" and "unsigned-preserving". Interestingly enough the BITS proposal picked "unsigned-preserving" which is what most (not all) K&R C compilers did, and some K&R C compilers and the C standard picked "value-preserving". This decision might profitably bear further consideration, but in any case is not the topic of this UTI! What BITS has also added is mixed-mode REAL and BITS comparison. Here, bits don't act like unsigned integers at all! In fact it is fair to say this operation doesn't have any coherent mathematical theory behind it, being totally processor-dependent on the internal representation of said REALs. Having "IF (X<1)" doing a totally different operation from "IF (X<1.)" is IMO an extraordinarily poor design, and likely to be error-prone to use in practice. It is also unnecessary; the three people in the world who actually want to sort a mixture of REALs and BITSs can do "IF (X, >=, ==, and /=. The permitted types for 7operands of the relational intrinsic operators are specified in 7.1.5.1. 8The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 9.LE., .GT., .GE., .EQ., and .NE., respectively. 10If both operands of a bits relational operation do not have the same kind type parameter, the operand 11with the smaller kind type parameter is converted to the same kind as the other operand. If one operand 12of a bits relational operation is not of type bits, it is converted to type bits with the same kind type 13parameter as the other operand. Any conversion takes place before the operation is evaluated. NOTE 7.26 As shown in Table 7.3, 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. 14Evaluation of a relational intrinsic operation produces a result of type default logical. 15The interpretation of the relational intrinsic operators is given in Table 7.11, where x1 denotes the 16operand to the left of the operator and x2 denotes the operand to the right of the operator. Table 7.11: 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 17A numeric relational intrinsic operation is interpreted as having the logical value true if and only if the 18values of the operands satisfy the relation specified by the operator. In the numeric relational operation 148 2006/01/05 WORKING DRAFT J3/07-007 1 x1 rel-op x2 2 3if the types or kind type parameters of x1 and x2 differ, their values are converted to the type and kind 4type parameter of the expression x1 + x2 before evaluation. 5A character relational intrinsic operation is interpreted as having the logical value true if and only if the 6values of the operands satisfy the relation specified by the operator. 7For a character relational intrinsic operation, the operands are compared one character at a time in 8order, beginning with the first character of each character operand. If the operands are of unequal 9length, the shorter operand is treated as if it were extended on the right with blanks to the length of 10the longer operand. If both x1 and x2 are of zero length, x1 is equal to x2; if every character of x1 is 11the same as the character in the corresponding position in x2, x1 is equal to x2. Otherwise, at the first 12position where the character operands differ, the character operand x1 is considered to be less than x2 13if the character value of x1 at this position precedes the value of x2 in the collating sequence (4.4.5.4); 14x1 is greater than x2 if the character value of x1 at this position follows the value of x2 in the collating 15sequence. NOTE 7.27 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. 16A bits relational intrinsic operation is interpreted as having the logical value true if and only if the values 17of the operands satisfy the relation specified by the operator. 18For a bits relational intrinsic operation, x1 and x2 are equal if and only if each corresponding bit has 19the same value. If x1 and x2 are not equal, and the leftmost unequal corresponding bit of x1 is 1 and 20x2 is 0 then x1 is greater than x2; otherwise x1 is less than x2. 217.1.5.6.2 Evaluation of relational intrinsic operations 22Once the interpretation of a relational intrinsic operation is established, the processor may evaluate 23any other expression that is relationally equivalent, provided that the integrity of parentheses in any 24expression is not violated. NOTE 7.28 For example, the processor may choose to evaluate the expression I > J where I and J are integer variables, as J - I < 0 25Two relational intrinsic operations are relationally equivalent if their logical values are equal for all 26possible values of their primaries. 7.1.6 Defined operations 27 149 J3/07-007 WORKING DRAFT 2006/01/05 17.1.6.1 Definitions 2A defined operation is either a defined unary operation or a defined binary operation. A defined 3unary operation is an operation that has the form defined-unary-op x2 or intrinsic-operator x2 and that is defined by a function and a generic interface (4.5.2, 12.4.3.4). 4 5A function defines the unary operation op x2 if 6 (1) the function is specified with a FUNCTION (12.6.2.2) or ENTRY (12.6.2.6) statement that 7 specifies one dummy argument d2, (2) either 8 9 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- TOR (op), or 10 11 (b) there is a generic binding (4.5.2) in the declared type of x2 with a generic-spec of 12 OPERATOR (op) and there is a corresponding binding to the function in the dynamic 13 type of x2, (3) 14 the type of d2 is compatible with the dynamic type of x2, (4) 15 the type parameters, if any, of d2 match the corresponding type parameters of x2, and (5) either 16 (a) 17 the rank of x2 matches that of d2 or (b) the function is elemental and there is no other function that defines the operation. 18 19If d2 is an array, the shape of x2 shall match the shape of d2. 20A defined binary operation is an operation that has the form x1 defined-binary-op x2 or x1 intrinsic- 21operator x2 and that is defined by a function and a generic interface. 22A function defines the binary operation x1 op x2 if 23 (1) the function is specified with a FUNCTION (12.6.2.2) or ENTRY (12.6.2.6) statement that 24 specifies two dummy arguments, d1 and d2, (2) either 25 26 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- TOR (op), or 27 28 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic- 29 spec of OPERATOR (op) and there is a corresponding binding to the function in the 30 dynamic type of x1 or x2, respectively, (3) 31 the types of d1 and d2 are compatible with the dynamic types of x1 and x2, respectively, 32 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 33 and x2, respectively, and (5) either 34 (a) 35 the ranks of x1 and x2 match those of d1 and d2 or 36 (b) the function is elemental, x1 and x2 are conformable, and there is no other function 37 that defines the operation. 38If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2, respectively. NOTE 7.29 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. 150 2006/01/05 WORKING DRAFT J3/07-007 1An extension operation is a defined operation in which the operator is of the form defined-unary-op 2or defined-binary-op. Such an operator is called an extension operator. The operator used in an 3extension operation may be such that a generic interface for the operator may specify more than one 4function. A defined elemental operation is a defined operation for which the function is elemental (12.8). 5 67.1.6.2 Interpretation of a defined operation 7The interpretation of a defined operation is provided by the function that defines the operation. 8The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 9.LE., .GT., .GE., .EQ., and .NE., respectively. 107.1.6.3 Evaluation of a defined operation 11Once the interpretation of a defined operation is established, the processor may evaluate any other 12expression that is equivalent, provided that the integrity of parentheses is not violated. 13Two expressions of derived type are equivalent if their values are equal for all possible values of their 14primaries. 7.1.7 Evaluation of operands 15 16It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely 17each operand, if the value of the expression can be determined otherwise. NOTE 7.30 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. 18If a statement contains a function reference in a part of an expression that need not be evaluated, all 19entities that would have become defined in the execution of that reference become undefined at the 20completion of evaluation of the expression containing the function reference. NOTE 7.31 In the examples in Note 7.30, 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. 21If a statement contains a function reference in a part of an expression that need not be evaluated, no 22invocation of that function in that part of the expression shall execute an image control statement other 23than CRITICAL or END CRITICAL. 151 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.32 This restriction is intended to avoid inadvertant deadlock caused by optimization. 7.1.8 Integrity of parentheses 1 2The rules for evaluation specified in subclause 7.1.5 state certain conditions under which a processor 3may evaluate an expression that is different from the one specified by applying the rules given in 7.1.2 4and rules for interpretation specified in subclause 7.1.5. However, any expression in parentheses shall be 5treated as a data entity. NOTE 7.33 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.9 Type, type parameters, and shape of an expression 6 7The type, type parameters, and shape of an expression depend on the operators and on the types, type 8parameters, and shapes of the primaries used in the expression, and are determined recursively from 9the syntactic form of the expression. The type of an expression is one of the intrinsic types (4.4) or a derived type (4.5). 10 11If an expression is a polymorphic primary or defined operation, the type parameters and the declared and 12dynamic types of the expression are the same as those of the primary or defined operation. Otherwise 13the type parameters and dynamic type of the expression are the same as its declared type and type 14parameters; they are referred to simply as the type and type parameters of the expression. 15R724 logical-expr is expr C705 (R724) logical-expr shall be of type logical. 16 17R725 char-expr is expr C706 (R725) char-expr shall be of type character. 18 19R726 default-char-expr is expr C707 (R726) default-char-expr shall be of type default character. 20 21R727 int-expr is expr C708 (R727) int-expr shall be of type integer. 22 23R728 numeric-expr is expr C709 (R728) numeric-expr shall be of type integer, real, or complex. 24 257.1.9.1 Type, type parameters, and shape of a primary 26The type, type parameters, and shape of a primary are determined according to whether the primary is a 27constant, variable, array constructor, structure constructor, function reference, type parameter inquiry, 28type parameter name, or parenthesized expression. If a primary is a constant, its type, type parameters, 29and shape are those of the constant. If it is a structure constructor, it is scalar and its type and type 30parameters are as described in 4.5.10. If it is an array constructor, its type, type parameters, and shape 31are as described in 4.7. If it is a variable or function reference, its type, type parameters, and shape are 32those of the variable (5.2, 5.3) or the function reference (12.5.3), respectively. If the function reference 152 2006/01/05 WORKING DRAFT J3/07-007 1is generic (12.4.3.2, 13.5) then its type, type parameters, and shape are those of the specific function 2referenced, which is determined by the types, type parameters, and ranks of its actual arguments as 3specified in 12.5.5.2. If it is a type parameter inquiry or type parameter name, it is a scalar integer with 4the kind of the type parameter. 5If a primary is a parenthesized expression, its type, type parameters, and shape are those of the expres- 6sion. 7The associated target object is referenced if a pointer appears as (1) a primary in an intrinsic or defined operation, 8 (2) the expr of a parenthesized primary, or 9 (3) the only primary on the right-hand side of an intrinsic assignment statement. 10 11The type, type parameters, and shape of the primary are those of the current target. If the pointer is 12not associated with a target, it may appear as a primary only as an actual argument in a reference to 13a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a 14pointer assignment statement. 15A disassociated array pointer or an unallocated allocatable array has no shape but does have rank. 16The type, type parameters, and rank of the result of the NULL intrinsic function depend on context (13.7.131). 17 187.1.9.2 Type, type parameters, and shape of the result of an operation 19The type of the result of an intrinsic operation [x1] op x2 is specified by Table 7.3. The shape of the 20result of an intrinsic operation is the shape of x2 if op is unary or if x1 is scalar, and is the shape of x1 21otherwise. 22The type, type parameters, and shape of the result of a defined operation [x1] op x2 are specified by the function defining the operation (7.1.6). 23 24An expression of an intrinsic type has a kind type parameter. An expression of type character also has 25a character length parameter. 26The type parameters of the result of an intrinsic operation are as follows. 27 (1) For an expression x1 // x2 where // is the character intrinsic operator and x1 and x2 are 28 of type character, the character length parameter is the sum of the lengths of the operands 29 and the kind type parameter is the kind type parameter of x1, which shall be the same as 30 the kind type parameter of x2. 31 (2) For an expression op x2 where op is an intrinsic unary operator and x2 is of type integer, 32 real, complex, logical, or bits, the kind type parameter of the expression is that of the 33 operand. 34 (3) For an expression x1 op x2 where op is a numeric intrinsic binary operator with one operand 35 of type integer and the other of type real or complex, the kind type parameter of the 36 expression is that of the real or complex operand. 37 (4) For an expression x1 op x2 where op is a numeric intrinsic binary operator with both 38 operands of the same type and kind type parameters, or with one real and one complex 39 with the same kind type parameters, the kind type parameter of the expression is identical 40 to that of each operand. In the case where both operands are integer with different kind type 41 parameters, the kind type parameter of the expression is that of the operand with the greater 42 decimal exponent range if the decimal exponent ranges are different; if the decimal exponent 43 ranges are the same, the kind type parameter of the expression is processor dependent, but 44 it is the same as that of one of the operands. In the case where both operands are any 45 of type real or complex with different kind type parameters, the kind type parameter of 153 J3/07-007 WORKING DRAFT 2006/01/05 1 the expression is that of the operand with the greater decimal precision if the decimal 2 precisions are different; if the decimal precisions are the same, the kind type parameter of 3 the expression is processor dependent, but it is the same as that of one of the operands. 4 (5) For an expression x1 op x2 where op is a logical intrinsic binary operator with both operands 5 of the same kind type parameter, the kind type parameter of the expression is identical to 6 that of each operand. In the case where both operands are of type logical with different 7 kind type parameters, the kind type parameter of the expression is processor dependent, 8 but it is the same as that of one of the operands. 9 (6) For an expression x1 // x2 where both operands are of type bits, the kind type parameter 10 of the expression is the sum of the kind type parameters of the operands. 11 (7) For an expression x1 op x2 where op is a bits intrinsic binary operator other than //, the 12 kind type parameter of the expression is the maximum of the kind type parameters of x1 13 and x2. 14 (8) For an expression x1 op x2 where op is a relational intrinsic operator, the expression has 15 the default logical kind type parameter. 16C710 The kind type parameter of the result of a bits concatenation operation expression shall be a 17 bits kind type parameter value supported by the processor. 7.1.10 Conformability rules for elemental operations 18 19An elemental operation is an intrinsic operation or a defined elemental operation. Two entities are 20in shape conformance if both are arrays of the same shape, or one or both are scalars. 21For all elemental binary operations, the two operands shall be in shape conformance. In the case where 22one is a scalar and the other an array, the scalar is treated as if it were an array of the same shape as 23the array operand with every element, if any, of the array equal to the value of the scalar. 7.1.11 Specification expression 24 25A specification expression is an expression with limitations that make it suitable for use in speci- 26fications such as length type parameters (C404) and array bounds (R513, R514). A specification-expr 27shall be an initialization expression unless it is in an interface body (12.4.3.2), the specification part of a subprogram or BLOCK construct, or the declaration-type-spec of a FUNCTION statement (12.6.2.2). 28 29R729 specification-expr is scalar-int-expr C711 (R729) The scalar-int-expr shall be a restricted expression. 30 31A restricted expression is an expression in which each operation is intrinsic and each primary is (1) a constant or subobject of a constant, 32 33 (2) an object designator with a base object that is a dummy argument that has neither the OPTIONAL nor the INTENT (OUT) attribute, 34 (3) an object designator with a base object that is in a common block, 35 36 (4) an object designator with a base object that is made accessible by use association or host 37 association, 38 (5) an object designator with a base object that is a local variable of the procedure containing 39 the BLOCK construct in which the restricted expression appears, 40 (6) an object designator with a base object that is a local variable of an outer BLOCK construct 41 containing the BLOCK construct in which the restricted expression appears, 42 (7) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 43 control is a restricted expression, (8) a structure constructor where each component is a restricted expression, 44 154 2006/01/05 WORKING DRAFT J3/07-007 (9) a specification inquiry where each designator or function argument is 1 (a) a restricted expression or 2 (b) a variable whose properties inquired about are not 3 (i) dependent on the upper bound of the last dimension of an assumed-size array, 4 (ii) deferred, or 5 (iii) defined by an expression that is not a restricted expression, 6 7 (10) a reference to any other standard intrinsic function where each argument is a restricted 8 expression, (11) a reference to a specification function where each argument is a restricted expression, 9 (12) a type parameter of the derived type being defined, 10 11 (13) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 12 ing ac-implied-do-control is a restricted expression, or (14) a restricted expression enclosed in parentheses, 13 14where each subscript, section subscript, substring starting point, substring ending point, and type pa- 15rameter value is a restricted expression, and where any final subroutine that is invoked is pure. 16A specification inquiry is a reference to (1) an array inquiry function (13.5.7), 17 (2) the bit inquiry function BIT SIZE, 18 (3) the character inquiry function LEN, 19 (4) the kind inquiry function KIND, 20 (5) the bits kind inquiry function BITS KIND, 21 (6) the character inquiry function NEW LINE, 22 (7) a numeric inquiry function (13.5.6), 23 (8) a type parameter inquiry (6.1.4), 24 (9) an IEEE inquiry function (14.9.1), 25 (10) the function C SIZEOF from the intrinsic module ISO C BINDING (15.2.3.6) , or 26 27 (11) the COMPILER VERSION or COMPILER OPTIONS inquiry functions from the intrinsic module ISO FORTRAN ENV (13.8.2.3, 13.8.2.4). 28 29A function is a specification function if it is a pure function, is not a standard intrinsic function, is 30not an internal function, is not a statement function, and does not have a dummy procedure argument. 31Evaluation of a specification expression shall not directly or indirectly cause a procedure defined by the 32subprogram in which it appears to be invoked. NOTE 7.34 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. 33A variable in a specification expression shall have its type and type parameters, if any, specified by a 34previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, 35or by host or use association. If a variable in a specification expression is typed by the implicit typing 36rules, its appearance in any subsequent type declaration statement shall confirm the implied type and 37type parameters. 155 J3/07-007 WORKING DRAFT 2006/01/05 1If a specification expression includes a specification inquiry that depends on a type parameter or an 2array bound of an entity specified in the same specification-part, the type parameter or array bound 3shall be specified in a prior specification of the specification-part. The prior specification may be to the 4left of the specification inquiry in the same statement, but shall not be within the same entity-decl. If a 5specification expression includes a reference to the value of an element of an array specified in the same 6specification-part, the array shall be completely specified in prior declarations. 7If a specification expression in a module or submodule includes a reference to a generic entity, that 8generic entity shall have no specific procedures defined in the module or submodule subsequent to the 9specification expression. NOTE 7.35 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.12 Initialization expression 10 11An initialization expression is an expression with limitations that make it suitable for use as a kind 12type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, 13and each primary is (1) a constant or subobject of a constant, 14 15 (2) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 16 control is an initialization expression, (3) a structure constructor where each component-spec corresponding to 17 (a) an allocatable component is a reference to the intrinsic function NULL, 18 19 (b) a pointer component is a reference to the intrinsic function NULL or an initialization 20 target, and (c) any other component is an initialization expression, 21 22 (4) a reference to an elemental standard intrinsic function, where each argument is an initial- 23 ization expression, 24 (5) a reference to a transformational standard intrinsic function other than NULL, where each 25 argument is an initialization expression, 26 (6) A reference to the transformational intrinsic function NULL that does not have an argu- 27 ment with a type parameter that is assumed or is defined by an expression that is not an 28 initialization expression, 29 (7) a reference to the transformational function IEEE SELECTED REAL KIND from the in- 30 trinsic module IEEE ARITHMETIC (14), where each argument is an initialization expres- 31 sion, (8) a specification inquiry where each designator or function argument is 32 (a) an initialization expression or 33 (b) a variable whose properties inquired about are not 34 (i) assumed, 35 (ii) deferred, or 36 (iii) defined by an expression that is not an initialization expression, 37 (9) a kind type parameter of the derived type being defined, 38 156 2006/01/05 WORKING DRAFT J3/07-007 (10) a data-i-do-variable within a data-implied-do, 1 2 (11) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 3 ing ac-implied-do-control is an initialization expression, or (12) an initialization expression enclosed in parentheses, 4 5and where each subscript, section subscript, substring starting point, substring ending point, and type 6parameter value is an initialization expression. 7R730 initialization-expr is expr C712 (R730) initialization-expr shall be an initialization expression. 8 9R731 char-initialization-expr is char-expr C713 (R731) char-initialization-expr shall be an initialization expression. 10 11R732 int-initialization-expr is int-expr C714 (R732) int-initialization-expr shall be an initialization expression. 12 13R733 logical-initialization-expr is logical-expr C715 (R733) logical-initialization-expr shall be an initialization expression. 14 15If an initialization expression includes a specification inquiry that depends on a type parameter or an 16array bound of an entity specified in the same specification-part, the type parameter or array bound 17shall be specified in a prior specification of the specification-part. The prior specification may be to the 18left of the specification inquiry in the same statement, but shall not be within the same entity-decl. 19If an initialization expression in a module or submodule includes a reference to a generic entity, that 20generic entity shall have no specific procedures defined in the module or submodule subsequent to the 21initialization expression. NOTE 7.36 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.2 Assignment 22 7.2.1 Assignment statement 23 24A variable may be defined or redefined by execution of an assignment statement. 257.2.1.1 General form 157 J3/07-007 WORKING DRAFT 2006/01/05 1R734 assignment-stmt is variable = expr 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) 3An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic 4assignment statement. 57.2.1.2 Intrinsic assignment statement 6An intrinsic assignment statement is an assignment statement that is not a defined assignment statement (7.2.1.4). In an intrinsic assignment statement, 7 (1) if the variable is polymorphic it shall be allocatable, 8 9 (2) if variable is a co-indexed object, it shall not be of a type that has an allocatable ultimate 10 component, (3) if expr is an array then the variable shall also be an array, 11 12 (4) the shapes of the variable and expr shall conform unless the variable is an allocatable array 13 that has the same rank as expr and is neither a co-array nor a co-indexed object, (5) if the variable is an allocatable co-array or co-indexed object, it shall not be polymorphic, 14 15 (6) if the variable is polymorphic it shall be type compatible with expr and have the same rank; 16 otherwise the declared types of the variable and expr shall conform as specified in Table 17 7.12, 18 (7) if the variable is of derived type each kind type parameter of the variable shall have the 19 same value as the corresponding type parameter of expr, and 20 (8) if the variable is of derived type each length type parameter of the variable shall have the 21 same value as the corresponding type parameter of expr unless the variable is allocatable, 22 is not a co-array or co-indexed object, and its corresponding type parameter is deferred. 23 Table 7.12: 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 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 24A numeric intrinsic assignment statement is an intrinsic assignment statement for which the vari- 25able and expr are of numeric type. A character intrinsic assignment statement is an intrinsic 26assignment statement for which the variable and expr are of type character. A logical intrinsic as- 27signment statement is an intrinsic assignment statement for which the variable and expr are of type 28logical. A bits intrinsic assignment statement is an intrinsic assignment statement for which either 29the variable or expr is of type bits. A derived-type intrinsic assignment statement is an intrinsic assignment statement for which the variable and expr are of derived type. 158 2006/01/05 WORKING DRAFT J3/07-007 1 2An array intrinsic assignment statement is an intrinsic assignment statement for which the variable is an array. The variable shall not be a many-one array section (6.2.2.2.2). 3 4If the variable is a pointer, it shall be associated with a definable target such that the type, type 5parameters, and shape of the target and expr conform. 67.2.1.3 Interpretation of intrinsic assignments 7Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expr and all 8expressions within variable (7.1), the possible conversion of expr to the type and type parameters of the 9variable (Table 7.13), and the definition of the variable with the resulting value. The execution of the 10assignment shall have the same effect as if the evaluation of expr and the evaluation of all expressions 11in variable occurred before any portion of the variable is defined by the assignment. The evaluation of 12expressions within variable shall neither affect nor be affected by the evaluation of expr. No value is 13assigned to the variable if it is of type character and zero length, or is an array of size zero. 14If the variable is a pointer, the value of expr is assigned to the target of the variable. 15If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, 16any of the corresponding length type parameter values of the variable and expr differ, or the variable 17is polymorphic and the dynamic type of the variable and expr differ. If the variable is or becomes an 18unallocated allocatable variable, then it is allocated with each deferred type parameter equal to the 19corresponding type parameter of expr, with the shape of expr, with each lower bound equal to the 20corresponding element of LBOUND(expr), and if the variable is polymorphic, with the same dynamic 21type as expr. 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 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. 22Both variable and expr may contain references to any portion of the variable. 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 159 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.39 (cont.) value following the assignment is 'AABCDF'. 1If expr is a scalar and the variable is an array, the expr is treated as if it were an array of the same 2shape as the variable with every element of the array equal to the scalar value of expr. 3If the variable is an array, the assignment is performed element-by-element on corresponding array 4elements of the variable and expr. 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. 5The processor may perform the element-by-element assignment in any order. 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) 6For a numeric intrinsic assignment statement, the variable and expr may have different numeric types 7or different kind type parameters, in which case the value of expr is converted to the type and kind type 8parameter of the variable according to the rules of Table 7.13. Table 7.13: 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. 9For a logical intrinsic assignment statement, the variable and expr may have different kind type param- 10eters, in which case the value of expr is converted to the kind type parameter of the variable. 11For a character intrinsic assignment statement, the variable and expr may have different character length 12parameters in which case the conversion of expr to the length of the variable is as follows. 160 2006/01/05 WORKING DRAFT J3/07-007 1 (1) If the length of the variable is less than that of expr, the value of expr is truncated from 2 the right until it is the same length as the variable. 3 (2) If the length of the variable is greater than that of expr, the value of expr is extended on 4 the right with blanks until it is the same length as the variable. 5If the variable and expr have different kind type parameters, each character c in expr is converted to the kind type parameter of the variable by ACHAR(IACHAR(c),KIND(variable)). 6 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. 7For a bits intrinsic assignment statement, the variable and expr may have different types or different 8kind type parameters, in which case the value of expr is converted to the type and kind type parameter 9of the variable according to the rules of Table 7.14. Table 7.14: 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, LOGICAL, 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 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. 10A derived-type intrinsic assignment is performed as if each component of the variable were assigned 11from the corresponding component of expr using pointer assignment (7.2.2) for each pointer component, 12defined assignment for each nonpointer nonallocatable component of a type that has a type-bound defined 13assignment consistent with the component, intrinsic assignment for each other nonpointer nonallocatable 14component, and intrinsic assignment for each allocated co-array component. For unallocated co-array 15components, the corresponding component of the variable shall be unallocated. For a non-co-array 16allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated. 17 18 (2) If the component of the value of expr is allocated, the corresponding component of the 19 variable is allocated with the same dynamic type and type parameters as the component 161 J3/07-007 WORKING DRAFT 2006/01/05 1 of the value of expr. If it is an array, it is allocated with the same bounds. The value of 2 the component of the value of expr is then assigned to the corresponding component of the 3 variable using defined assignment if the declared type of the component has a type-bound 4 defined assignment consistent with the component, and intrinsic assignment for the dynamic 5 type of that component otherwise. 6The processor may perform the component-by-component assignment in any order or by any means that 7has the same effect. 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. 87.2.1.4 Defined assignment statement 9A defined assignment statement is an assignment statement that is defined by a subroutine and a 10generic interface (4.5.2, 12.4.3.4.3) that specifies ASSIGNMENT (=). A defined elemental assign- ment statement is a defined assignment statement for which the subroutine is elemental (12.8). 11 12A subroutine defines the defined assignment x1 = x2 if 13 (1) the subroutine is specified with a SUBROUTINE (12.6.2.3) or ENTRY (12.6.2.6) statement 14 that specifies two dummy arguments, d1 and d2, (2) either 15 16 (a) a generic interface (12.4.3.2) provides the subroutine with a generic-spec of ASSIGN- MENT (=), or 17 18 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic-spec 19 of ASSIGNMENT (=) and there is a corresponding binding to the subroutine in the 20 dynamic type of x1 or x2, respectively, (3) 21 the types of d1 and d2 are compatible with the dynamic types of x1 and x2, respectively, 22 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 23 and x2, respectively, and (5) either 24 (a) 25 the ranks of x1 and x2 match those of d1 and d2 or 26 (b) the subroutine is elemental, x1 and x2 are conformable, and there is no other subrou- 27 tine that defines the operation. 28If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2, respectively. 297.2.1.5 Interpretation of defined assignment statements 162 2006/01/05 WORKING DRAFT J3/07-007 1The interpretation of a defined assignment is provided by the subroutine that defines it. 2If the defined assignment is an elemental assignment and the the variable in the assignment is an array, 3the defined assignment is performed element-by-element, on corresponding elements of the variable and 4expr. If expr is a scalar, it is treated as if it were an array of the same shape as the variable with every 5element of the array equal to the scalar value of expr. NOTE 7.46 The rules of defined assignment (12.4.3.4.3), 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.2.2 Pointer assignment 6 77.2.2.1 General 8Pointer assignment causes a pointer to become associated with a target or causes its pointer association 9status to become disassociated or undefined. Any previous association between the pointer and a target 10is broken. 11Pointer assignment for a pointer component of a structure may also take place by execution of a derived- type intrinsic assignment statement (7.2.1.3). 12 137.2.2.2 Syntax 14R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] => data-target 15 or data-pointer-object (bounds-remapping-list ) => data-target 16 or proc-pointer-object => proc-target 17R736 data-pointer-object is variable-name 18 or scalar-variable % data-pointer-component-name 19C717 (R735) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal. 20 21C718 (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- 22 phic, of a sequence derived type, or of a type with the BIND attribute. 23C719 (R735) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data- 24 pointer-object. 25C720 (R735) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the 26 rank of data-pointer-object. 27C721 (R735) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target 28 shall be the same. C722 (R736) A variable-name shall have the POINTER attribute. 29 C723 (R736) A scalar-variable shall be a data-ref . 30 31C724 (R736) A data-pointer-component-name shall be the name of a component of scalar-variable 32 that is a data pointer. C725 (R736) A data-pointer-object shall not be a co-indexed object. 163 J3/07-007 WORKING DRAFT 2006/01/05 1 2R737 bounds-spec is lower-bound-expr : 3R738 bounds-remapping is lower-bound-expr : upper-bound-expr 4R739 data-target is variable 5 or expr 6C726 (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an 7 array section with a vector subscript. C727 (R739) A data-target shall not be a co-indexed object. 8 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. 9 10R740 proc-pointer-object is proc-pointer-name 11 or proc-component-ref 12R741 proc-component-ref is scalar-variable % procedure-component-name C729 (R741) The scalar-variable shall be a data-ref . 13 14C730 (R741) The procedure-component-name shall be the name of a procedure pointer component of 15 the declared type of scalar-variable. 16R742 proc-target is expr 17 or procedure-name 18 or proc-component-ref C731 (R742) An expr shall be a reference to a function whose result is a procedure pointer. 19 20C732 (R742) A procedure-name shall be the name of an external, internal, module, or dummy proce- 21 dure, a procedure pointer, or a specific intrinsic function listed in 13.6 and not marked with a bullet (·). 22 C733 (R742) The proc-target shall not be a nonintrinsic elemental procedure. 23 247.2.2.3 Data pointer assignment 25If data-pointer-object is not polymorphic (4.3.1.3) and data-target is polymorphic with dynamic type 26that differs from its declared type, the assignment target is the ancestor component of data-target that 27has the type of data-pointer-object. Otherwise, the assignment target is data-target. 28If data-target is not a pointer, data-pointer-object becomes pointer associated with the assignment target. 29Otherwise, the pointer association status of data-pointer-object becomes that of data-target; if data-target 30is associated with an object, data-pointer-object becomes associated with the assignment target. If data- 31target is allocatable, it shall be allocated. 32If data-pointer-object is polymorphic, it assumes the dynamic type of data-target. If data-pointer-object 33is of sequence derived type or a type with the BIND attribute, the dynamic type of data-target shall be 164 2006/01/05 WORKING DRAFT J3/07-007 1that derived type. 2If data-target is a disassociated pointer, all nondeferred type parameters of the declared type of data- 3pointer-object that correspond to nondeferred type parameters of data-target shall have the same values 4as the corresponding type parameters of data-target. 5Otherwise, all nondeferred type parameters of the declared type of data-pointer-object shall have the 6same values as the corresponding type parameters of data-target. 7If data-pointer-object has nondeferred type parameters that correspond to deferred type parameters of 8data-target, data-target shall not be a pointer with undefined association status. 9If data-pointer-object has the CONTIGUOUS attribute, data-target shall be contiguous. 10If bounds-remapping-list is specified, data-target shall be contiguous (5.3.6) or of rank one. It shall not 11be a disassociated or undefined pointer, and the size of data-target shall not be less than the size of 12data-pointer-object. The elements of the target of data-pointer-object, in array element order (6.2.2.1), are the first SIZE(data-pointer-object) elements of data-target. 13 14If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of 15the corresponding dimension of data-target. If bounds-spec-list appears, it specifies the lower bounds; 16otherwise, the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.97) 17applied to the corresponding dimension of data-target. The upper bound of each dimension is one less 18than the sum of the lower bound and the extent. 197.2.2.4 Procedure pointer assignment 20If the proc-target is not a pointer, proc-pointer-object becomes pointer associated with proc-target. Other- 21wise, the pointer association status of proc-pointer-object becomes that of proc-target; if proc-target is 22associated with a procedure, proc-pointer-object becomes associated with the same procedure. 23If proc-target is the name of an internal procedure the host instance of proc-pointer-object becomes 24the innermost currently executing instance of the host procedure. Otherwise if proc-target has a host 25instance the host instance of proc-pointer-object becomes that instance. Otherwise proc-pointer-object 26has no host instance. 27If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except 28that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental 29intrinsic procedure even if proc-pointer-object is not elemental. 30If the characteristics of proc-pointer-object or proc-target are such that an explicit interface is required, 31both proc-pointer-object and proc-target shall have an explicit interface. 32If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc- 33target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, 34proc-target shall be a subroutine. 35If proc-target and proc-pointer-object are functions, they shall have the same type; corresponding type 36parameters shall either both be deferred or both have the same value. 37If procedure-name is a specific procedure name that is also a generic name, only the specific procedure 38is associated with pointer-object. 397.2.2.5 Examples 165 J3/07-007 WORKING DRAFT 2006/01/05 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. Rank remapping can be applied to CONTIGUOUS arrays, for example: REAL, CONTIGUOUS, POINTER :: A(:) REAL, CONTIGUOUS, TARGET :: B(:,:) ! Dummy argument A(1:SIZE(B)) => B ! Linear view of a rank-2 array 7.2.3 Masked array assignment ­ WHERE 1 27.2.3.1 General form of the masked array assignment 3A masked array assignment is either a WHERE statement or a WHERE construct. It is used to 4mask the evaluation of expressions and assignment of values in array assignment statements, according 5to the value of a logical array expression. R743 where-stmt is WHERE ( mask-expr ) where-assignment-stmt 6 7R744 where-construct is where-construct-stmt 8 [ where-body-construct ] ... 166 2006/01/05 WORKING DRAFT J3/07-007 1 [ masked-elsewhere-stmt 2 [ where-body-construct ] ... ] ... 3 [ elsewhere-stmt 4 [ where-body-construct ] ... ] 5 end-where-stmt R745 where-construct-stmt is [where-construct-name:] WHERE ( mask-expr ) 6 7R746 where-body-construct is where-assignment-stmt 8 or where-stmt 9 or where-construct 10R747 where-assignment-stmt is assignment-stmt 11R748 mask-expr is logical-expr R749 masked-elsewhere-stmt is ELSEWHERE (mask-expr) [where-construct-name] 12 R750 elsewhere-stmt is ELSEWHERE [where-construct-name] 13 R751 end-where-stmt is END WHERE [where-construct-name] 14 C734 (R747) A where-assignment-stmt that is a defined assignment shall be elemental. 15 16C735 (R744) If the where-construct-stmt is identified by a where-construct-name, the corresponding 17 end-where-stmt shall specify the same where-construct-name. If the where-construct-stmt is 18 not identified by a where-construct-name, the corresponding end-where-stmt shall not specify 19 a where-construct-name. If an elsewhere-stmt or a masked-elsewhere-stmt is identified by a 20 where-construct-name, the corresponding where-construct-stmt shall specify the same where- 21 construct-name. C736 (R746) A statement that is part of a where-body-construct shall not be a branch target statement. 22 23If a where-construct contains a where-stmt, a masked-elsewhere-stmt, or another where-construct then 24each mask-expr within the where-construct shall have the same shape. In each where-assignment-stmt, 25the mask-expr and the variable being defined shall be arrays of the same shape. 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 267.2.3.2 Interpretation of masked array assignments 27When a WHERE statement or a where-construct-stmt is executed, a control mask is established. In 28addition, when a WHERE construct statement is executed, a pending control mask is established. If 29the statement does not appear as part of a where-body-construct, the mask-expr of the statement is 30evaluated, and the control mask is established to be the value of mask-expr. The pending control mask 31is established to have the value .NOT. mask-expr upon execution of a WHERE construct statement that 32does not appear as part of a where-body-construct. The mask-expr is evaluated only once. 167 J3/07-007 WORKING DRAFT 2006/01/05 1Each statement in a WHERE construct is executed in sequence. 2Upon execution of a masked-elsewhere-stmt, the following actions take place in sequence. (1) 3 The control mask mc is established to have the value of the pending control mask. (2) 4 The pending control mask is established to have the value mc .AND. (.NOT. mask-expr). (3) 5 The control mask mc is established to have the value mc .AND. mask-expr. 6The mask-expr is evaluated at most once. 7Upon execution of an ELSEWHERE statement, the control mask is established to have the value of the 8pending control mask. No new pending control mask value is established. 9Upon execution of an ENDWHERE statement, the control mask and pending control mask are es- 10tablished to have the values they had prior to the execution of the corresponding WHERE construct 11statement. Following the execution of a WHERE statement that appears as a where-body-construct, the 12control mask is established to have the value it had prior to the execution of the WHERE statement. 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. 13Upon execution of a WHERE construct statement that is part of a where-body-construct, the pending 14control mask is established to have the value mc .AND. (.NOT. mask-expr). The control mask is then 15established to have the value mc .AND. mask-expr. The mask-expr is evaluated at most once. 16Upon execution of a WHERE statement that is part of a where-body-construct, the control mask is 17established to have the value mc .AND. mask-expr. The pending mask is not altered. 18If a nonelemental function reference occurs in the expr or variable of a where-assignment-stmt or in a 19mask-expr, the function is evaluated without any masked control; that is, all of its argument expressions 20are fully evaluated and the function is fully evaluated. If the result is an array and the reference is not 21within the argument list of a nonelemental function, elements corresponding to true values in the control 22mask are selected for use in evaluating the expr, variable or mask-expr. 23If an elemental operation or function reference occurs in the expr or variable of a where-assignment-stmt 24or in a mask-expr, and is not within the argument list of a nonelemental function reference, the operation 25is performed or the function is evaluated only for the elements corresponding to true values of the control 26mask. 27If an array constructor appears in a where-assignment-stmt or in a mask-expr, the array constructor is 168 2006/01/05 WORKING DRAFT J3/07-007 1evaluated without any masked control and then the where-assignment-stmt is executed or the mask-expr 2is evaluated. 3When a where-assignment-stmt is executed, the values of expr that correspond to true values of the 4control mask are assigned to the corresponding elements of the variable. 5The value of the control mask is established by the execution of a WHERE statement, a WHERE con- 6struct statement, an ELSEWHERE statement, a masked ELSEWHERE statement, or an ENDWHERE 7statement. Subsequent changes to the value of entities in a mask-expr have no effect on the value of the 8control mask. The execution of a function reference in the mask expression of a WHERE statement is 9permitted to affect entities in the assignment statement. 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 107.2.4 FORALL 117.2.4.1 Form of the FORALL Construct 12The FORALL construct allows multiple assignments, masked array (WHERE) assignments, and nested 13FORALL constructs and statements to be controlled by a single forall-triplet-spec-list and scalar-mask- 14expr. 15R752 forall-construct is forall-construct-stmt 16 [forall-body-construct ] ... 17 end-forall-stmt R753 forall-construct-stmt is [forall-construct-name :] FORALL forall-header 18 R754 forall-header is ( [ type-spec :: ] forall-triplet-spec-list [, scalar-mask-expr] ) 19 R755 forall-triplet-spec is index-name = subscript : subscript [ : stride] 20 21R619 subscript is scalar-int-expr 22R622 stride is scalar-int-expr 23R756 forall-body-construct is forall-assignment-stmt 24 or where-stmt 25 or where-construct 26 or forall-construct 27 or forall-stmt 28R757 forall-assignment-stmt is assignment-stmt 29 or pointer-assignment-stmt R758 end-forall-stmt is END FORALL [forall-construct-name ] 30 31C737 (R758) If the forall-construct-stmt has a forall-construct-name, the end-forall-stmt shall have 32 the same forall-construct-name. If the end-forall-stmt has a forall-construct-name, the forall- 169 J3/07-007 WORKING DRAFT 2006/01/05 1 construct-stmt shall have the same forall-construct-name. C738 (R754) type-spec shall specify type integer. 2 C739 (R754) The scalar-mask-expr shall be scalar and of type logical. 3 4C740 (R754) Any procedure referenced in the scalar-mask-expr, including one referenced by a defined operation, shall be a pure procedure (12.7). 5 C741 (R755) The index-name shall be a named scalar variable of type integer. 6 7C742 (R755) A subscript or stride in a forall-triplet-spec shall not contain a reference to any index- 8 name in the forall-triplet-spec-list in which it appears. 9C743 (R756) A statement in a forall-body-construct shall not define an index-name of the forall- 10 construct. 11C744 (R756) Any procedure referenced in a forall-body-construct, including one referenced by a defined 12 operation, assignment, or finalization, shall be a pure procedure. C745 (R756) A forall-body-construct shall not be a branch target. 13 C746 (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) 170 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.55 (cont.) CHARACTER (32), TARGET :: NAMES (1000) . . . 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. 1An index-name in a forall-construct has a scope of the construct (16.4). It is a scalar variable that has 2the type and type parameters that it would have if it were the name of a variable in the scoping unit 3that includes the FORALL, and this type shall be integer type; it has no other attributes. 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 47.2.4.2 Execution of the FORALL construct 57.2.4.2.1 Execution stages 6There are three stages in the execution of a FORALL construct: (1) determination of the values for index-name variables, 7 (2) evaluation of the scalar-mask-expr, and 8 (3) execution of the FORALL body constructs. 9 107.2.4.2.2 Determination of the values for index variables 11The subscript and stride expressions in the forall-triplet-spec-list are evaluated. These expressions may 12be evaluated in any order. The set of values that a particular index-name variable assumes is determined 13as follows. 14 (1) The lower bound m1, the upper bound m2, and the stride m3 are of type integer with the 15 same kind type parameter as the index-name. Their values are established by evaluating 171 J3/07-007 WORKING DRAFT 2006/01/05 1 the first subscript, the second subscript, and the stride expressions, respectively, including, 2 if necessary, conversion to the kind type parameter of the index-name according to the rules 3 for numeric conversion (Table 7.13). If a stride does not appear, m3 has the value 1. The 4 value m3 shall not be zero. 5 (2) Let the value of max be (m2-m1+m3)/m3. If max 0 for some index-name, the execution 6 of the construct is complete. Otherwise, the set of values for the index-name is where k = 1, 2, ..., max. 7 m1 + (k - 1) × m3 8The set of combinations of index-name values is the Cartesian product of the sets defined by each triplet 9specification. An index-name becomes defined when this set is evaluated. 107.2.4.2.3 Evaluation of the mask expression 11The scalar-mask-expr, if any, is evaluated for each combination of index-name values. If there is no 12scalar-mask-expr, it is as if it appeared with the value true. The index-name variables may be primaries 13in the scalar-mask-expr. 14The active combination of index-name values is defined to be the subset of all possible combinations (7.2.4.2.2) for which the scalar-mask-expr has the value true. 15 NOTE 7.57 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) . . . 167.2.4.2.4 Execution of the FORALL body constructs 17The forall-body-constructs are executed in the order in which they appear. Each construct is executed 18for all active combinations of the index-name values with the following interpretation: 19Execution of a forall-assignment-stmt that is an assignment-stmt causes the evaluation of expr and all 20expressions within variable for all active combinations of index-name values. These evaluations may be 21done in any order. After all these evaluations have been performed, each expr value is assigned to the 22corresponding variable. The assignments may occur in any order. 23Execution of a forall-assignment-stmt that is a pointer-assignment-stmt causes the evaluation of all 24expressions within data-target and data-pointer-object or proc-target and proc-pointer-object, the de- 25termination of any pointers within data-pointer-object or proc-pointer-object, and the determination of 26the target for all active combinations of index-name values. These evaluations may be done in any 27order. After all these evaluations have been performed, each data-pointer-object or proc-pointer-object 28is associated with the corresponding target. These associations may occur in any order. 29In a forall-assignment-stmt, a defined assignment subroutine shall not reference any variable that be- 30comes defined by the statement. NOTE 7.58 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 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) 172 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.58 (cont.) 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 1Each statement in a where-construct (7.2.3) within a forall-construct is executed in sequence. When 2a where-stmt, where-construct-stmt or masked-elsewhere-stmt is executed, the statement's mask-expr is 3evaluated for all active combinations of index-name values as determined by the outer forall-constructs, 4masked by any control mask corresponding to outer where-constructs. Any where-assignment-stmt is 5executed for all active combinations of index-name values, masked by the control mask in effect for the 6where-assignment-stmt. NOTE 7.59 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. 7Execution of a forall-stmt or forall-construct causes the evaluation of the subscript and stride expressions 8in the forall-triplet-spec-list for all active combinations of the index-name values of the outer FORALL 9construct. The set of combinations of index-name values for the inner FORALL is the union of the 10sets defined by these bounds and strides for each active combination of the outer index-name values; it 11also includes the outer index-name values. The scalar-mask-expr is then evaluated for all combinations 12of the index-name values of the inner construct to produce a set of active combinations for the inner 13construct. If there is no scalar-mask-expr, it is as if it appeared with the value true. Each statement in 173 J3/07-007 WORKING DRAFT 2006/01/05 1the inner FORALL is then executed for each active combination of the index-name values. NOTE 7.60 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 27.2.4.3 The FORALL statement 3The FORALL statement allows a single assignment statement or pointer assignment to be controlled by 4a set of index values and an optional mask expression. 5R759 forall-stmt is FORALL forall-header forall-assignment-stmt 6A FORALL statement is equivalent to a FORALL construct containing a single forall-body-construct 7that is a forall-assignment-stmt. The scope of an index-name in a forall-stmt is the statement itself (16.4). 8 NOTE 7.61 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 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) 174 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.61 (cont.) 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.60 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. 17.2.4.4 Restrictions on FORALL constructs and statements 2A many-to-one assignment is more than one assignment to the same object, or association of more 3than one target with the same pointer, whether the object is referenced directly or indirectly through a 4pointer. A many-to-one assignment shall not occur within a single statement in a FORALL construct or 5statement. It is possible to assign or pointer assign to the same object in different assignment statements 6in a FORALL construct. NOTE 7.62 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. 7Within the scope of a FORALL construct, a nested FORALL statement or FORALL construct shall 8not have the same index-name. The forall-header expressions within a nested FORALL may depend on 9the values of outer index-name variables. 175 J3/07-007 WORKING DRAFT 2006/01/05 176 2006/01/05 WORKING DRAFT J3/07-007 18 Execution control 8.1 Executable constructs containing blocks 2 38.1.1 General 4The following are executable constructs that contain blocks: (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. 13A block is a sequence of executable constructs that is treated as a unit. R801 block is [ execution-part-construct ] ... 14 15Executable constructs may be used to control which blocks of a program are executed or how many times 16a block is executed. Blocks are always bounded by statements that are particular to the construct in 17which they are embedded; however, in some forms of the DO construct, a sequence of executable constructs without 18 a terminating boundary statement shall obey all other rules governing blocks (8.1.2). 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 208.1.2.1 Control flow in blocks 21Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a 22block and transfers from the interior of a block to outside the block may occur. Subroutine and function references (12.5.3, 12.5.4) may appear in a block. 23 248.1.2.2 Execution of a block 177 J3/07-007 WORKING DRAFT 2006/01/05 1Execution of a block begins with the execution of the first executable construct in the block. Execution 2of the block is completed when the last executable construct in the sequence is executed, when a branch 3(8.2) within the block that has a branch target outside the block occurs, when a RETURN statement 4within the block is executed, or when an EXIT or CYCLE statement that belongs to a construct that 5contains the block is executed. 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. 68.1.3 ASSOCIATE construct 7The ASSOCIATE construct associates named entities with expressions or variables during the exe- 8cution of its block. These named construct entities (16.4) are associating entities (16.5.1.6). The names 9are associate names. 108.1.3.1 Form of the ASSOCIATE construct 11R802 associate-construct is associate-stmt 12 block 13 end-associate-stmt 14R803 associate-stmt is [ associate-construct-name : ] ASSOCIATE (association-list ) 15 16R804 association is associate-name => selector 17R805 selector is expr 18 or variable 19C801 (R804) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). 20 21C802 (R804) An associate-name shall not be the same as another associate-name in the same associate- 22 stmt. 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 25C804 (R806) If the associate-stmt of an associate-construct specifies an associate-construct-name, 26 the corresponding end-associate-stmt shall specify the same associate-construct-name. If the 27 associate-stmt of an associate-construct does not specify an associate-construct-name, the cor- 28 responding end-associate-stmt shall not specify an associate-construct-name. 298.1.3.2 Execution of the ASSOCIATE construct 30Execution of an ASSOCIATE construct causes execution of its associate-stmt followed by execution 31of its block. During execution of that block each associate name identifies an entity, which is associ- 32ated (16.5.1.6) with the corresponding selector. The associating entity assumes the declared type and 33type parameters of the selector. If and only if the selector is polymorphic, the associating entity is 34polymorphic. 35The other attributes of the associating entity are described in 8.1.3.3. 36It is permissible to branch to an end-associate-stmt only from within its ASSOCIATE construct. 178 2006/01/05 WORKING DRAFT J3/07-007 18.1.3.3 Attributes of associate names 2Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the same rank as its 3associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND 4(13.7.97) applied to the corresponding dimension of selector. The upper bound of each dimension is one 5less than the sum of the lower bound and the extent. The associating entity has the ASYNCHRONOUS 6or VOLATILE attribute if and only if the selector is a variable and has the attribute. The associating 7entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET 8or POINTER attribute. If the associating entity is polymorphic, it assumes the dynamic type and type 9parameter values of the selector. If the selector has the OPTIONAL attribute, it shall be present. The 10associating entity is contiguous if and only if the selector is contiguous. 11If the selector (8.1.3.1) is not permitted to appear in a variable definition context (16.6.7), the associate 12name shall not appear in a variable definition context. 138.1.3.4 Examples of the ASSOCIATE construct 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 148.1.4 BLOCK construct 15The BLOCK construct is an executable construct which may contain declarations. 16R807 block-construct is block-stmt 17 [ specification-part ] 18 block 19 end-block-stmt R808 block-stmt is [ block-construct-name : ] BLOCK 20 R809 end-block-stmt is END BLOCK [ block-construct-name ] 21 179 J3/07-007 WORKING DRAFT 2006/01/05 1C805 (R807) The specification-part of a BLOCK construct shall not contain a COMMON, EQUIVA- 2 LENCE, IMPLICIT, INTENT, NAMELIST, OPTIONAL, or USE statement. 3C806 (R807) A SAVE statement in a BLOCK construct shall contain a saved-entity-list that does not 4 specify a common-block-name. 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. 5C807 (R807) If the block-stmt of a block-construct specifies a block-construct-name, the corresponding 6 end-block-stmt shall specify the same block-construct-name. If the block-stmt does not specify 7 a block-construct-name, the corresponding end-block-stmt shall not specify a block-construct- 8 name. 9Except for the ASYNCHRONOUS and VOLATILE statements, specifications in a BLOCK construct declare construct entities whose scope is that of the BLOCK construct (16.4). 10 11Execution of a BLOCK construct causes evaluation of the specification expressions within its specification 12part in a processor-dependent order, followed by execution of its block. 138.1.5 CASE construct 148.1.5.1 Form of the CASE construct 15The CASE construct selects for execution at most one of its constituent blocks. The selection is based 16on the value of an expression. 17R810 case-construct is select-case-stmt 18 [ case-stmt 19 block ] ... 20 end-select-stmt R811 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) 21 R812 case-stmt is CASE case-selector [case-construct-name] 22 R813 end-select-stmt is END SELECT [ case-construct-name ] 23 24C808 (R810) If the select-case-stmt of a case-construct specifies a case-construct-name, the corre- 25 sponding end-select-stmt shall specify the same case-construct-name. If the select-case-stmt 26 of a case-construct does not specify a case-construct-name, the corresponding end-select-stmt 27 shall not specify a case-construct-name. If a case-stmt specifies a case-construct-name, the 28 corresponding select-case-stmt shall specify the same case-construct-name. 29R814 case-expr is scalar-int-expr 30 or scalar-char-expr 31 or scalar-logical-expr 32R815 case-selector is ( case-value-range-list ) 33 or DEFAULT C809 (R810) No more than one of the selectors of one of the CASE statements shall be DEFAULT. 34 35R816 case-value-range is case-value 36 or case-value : 180 2006/01/05 WORKING DRAFT J3/07-007 1 or : case-value 2 or case-value : case-value 3R817 case-value is scalar-int-initialization-expr 4 or scalar-char-initialization-expr 5 or scalar-logical-initialization-expr 6C810 (R810) For a given case-construct, each case-value shall be of the same type as case-expr. For 7 character type, the kind type parameters shall be the same; character length differences are 8 allowed. C811 (R810) A case-value-range using a colon shall not be used if case-expr is of type logical. 9 10C812 (R810) For a given case-construct, the case-value-ranges shall not overlap; that is, there shall 11 be no possible value of the case-expr that matches more than one case-value-range. 128.1.5.2 Execution of a CASE construct 13The execution of the SELECT CASE statement causes the case expression to be evaluated. The resulting 14value is called the case index. For a case value range list, a match occurs if the case index matches any 15of the case value ranges in the list. For a case index with a value of c, a match is determined as follows. 16 (1) If the case value range contains a single value v without a colon, a match occurs for type 17 logical if the expression c .EQV. v is true, and a match occurs for type integer or character 18 if the expression c == v is true. 19 (2) If the case value range is of the form low : high, a match occurs if the expression low <= c 20 .AND. c <= high is true. (3) 21 If the case value range is of the form low :, a match occurs if the expression low <= c is true. 22 (4) If the case value range is of the form : high, a match occurs if the expression c <= high is 23 true. (5) If no other selector matches and a DEFAULT selector appears, it matches the case index. 24 (6) If no other selector matches and the DEFAULT selector does not appear, there is no match. 25 26The block following the CASE statement containing the matching selector, if any, is executed. This 27completes execution of the construct. 28It is permissible to branch to an end-select-stmt only from within its CASE construct. 298.1.5.3 Examples of CASE constructs 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 181 J3/07-007 WORKING DRAFT 2006/01/05 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 ('(') 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 182 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.8 (cont.) CALL OTHER END SELECT 18.1.6 CRITICAL construct 2A CRITICAL construct limits execution of a block to one image at a time. 3R818 critical-construct is critical-stmt 4 block 5 end-critical-stmt R819 critical-stmt is [ critical-construct-name : ] CRITICAL 6 R820 end-critical-stmt is END CRITICAL [ critical-construct-name ] 7 8C813 (R818) If the critical-stmt of a critical-construct specifies a critical-construct-name, the corre- 9 sponding end-critical-stmt shall specify the same critical-construct-name. If the critical-stmt of a 10 critical-construct does not specify a critical-construct-name, the corresponding end-critical-stmt 11 shall not specify a critical-construct-name. C814 (R818) The block of a critical-construct shall not contain an image control statement. 12 13Execution of the CRITICAL construct is completed when execution of its block is completed. 14The processor shall ensure that once an image has commenced executing block, no other image shall 15commence executing it until the image has completed executing it. If image T is the next to execute the 16construct after image M, the segments (8.5.1) that executed before the construct on image M precede 17the segments that execute after the construct on image T. No image control statement shall be executed 18during the execution of a critical construct by the image executing the CRITICAL construct. 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] 183 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.10 (cont.) NUM_JOBS[1] = JOB - 1 END CRITICAL IF (JOB > 0) THEN ! Work on JOB ELSE EXIT END IF END DO SYNC ALL 18.1.7 DO construct 28.1.7.1 General 3The DO construct specifies the repeated execution of a sequence of executable constructs. Such a 4repeated sequence is called a loop. 5The number of iterations of a loop may be determined at the beginning of execution of the DO construct, 6or may be left indefinite ("DO forever" or DO WHILE). Except in the case of a DO CONCURRENT 7construct, the loop can be terminated immediately (8.1.7.5.4). The current iteration of the loop may be curtailed by executing a CYCLE statement (8.1.7.5.3). 8 9There are three phases in the execution of a DO construct: initiation of the loop, execution of the loop 10range, and termination of the loop. 11The DO CONCURRENT construct is a DO construct whose DO statement contains the CON- 12CURRENT keyword. 138.1.7.2 Forms of the DO construct 14The DO construct may be written in either a block form or a nonblock form. 15R821 do-construct is block-do-construct 16 or nonblock-do-construct 178.1.7.2.1 Form of the block DO construct 18R822 block-do-construct is do-stmt 19 do-block 20 end-do 21R823 do-stmt is label-do-stmt 22 or nonlabel-do-stmt 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 25R826 loop-control is [ , ] do-variable = scalar-int-expr, scalar-int-expr 26 [ , scalar-int-expr ] 27 or [ , ] WHILE ( scalar-logical-expr ) or [ , ] CONCURRENT forall-header 28 29R827 do-variable is scalar-int-variable-name 184 2006/01/05 WORKING DRAFT J3/07-007 C815 (R827) The do-variable shall be a variable of type integer. 1 2 R828 do-block is block 3R829 end-do is end-do-stmt 4 or continue-stmt R830 end-do-stmt is END DO [ do-construct-name ] 5 6C816 (R822) If the do-stmt of a block-do-construct specifies a do-construct-name, the corresponding 7 end-do shall be an end-do-stmt specifying the same do-construct-name. If the do-stmt of a 8 block-do-construct does not specify a do-construct-name, the corresponding end-do shall not 9 specify a do-construct-name. C817 (R822) If the do-stmt is a nonlabel-do-stmt, the corresponding end-do shall be an end-do-stmt. 10 11 C818 (R822) If the do-stmt is a label-do-stmt, the corresponding end-do shall be identified with the 12 same label. 13 8.1.7.2.2 Form of the nonblock DO construct 14 R831 nonblock-do-construct is action-term-do-construct 15 or outer-shared-do-construct 16 R832 action-term-do-construct is label-do-stmt 17 do-body 18 do-term-action-stmt 19 R833 do-body is [ execution-part-construct ] ... 20 R834 do-term-action-stmt is action-stmt 21 C819 (R834) A do-term-action-stmt shall not be an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, 22 end-mp-subprogram-stmt, end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop- 23 stmt. 24 C820 (R831) The do-term-action-stmt shall be identified with a label and the corresponding label-do-stmt shall refer 25 to the same label. 26 R835 outer-shared-do-construct is label-do-stmt 27 do-body 28 shared-term-do-construct 29 R836 shared-term-do-construct is outer-shared-do-construct 30 or inner-shared-do-construct 31 R837 inner-shared-do-construct is label-do-stmt 32 do-body 33 do-term-shared-stmt 34 R838 do-term-shared-stmt is action-stmt 35 C821 (R838) A do-term-shared-stmt shall not be an arithmetic-if-stmt, cycle-stmt, end-function-stmt, end-program- 36 stmt, end-mp-subprogram-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. 37 C822 (R836) The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the inner-shared- 38 do-construct and outer-shared-do-construct shall refer to the same label. 39 The do-term-action-stmt, do-term-shared-stmt, or shared-term-do-construct following the do-body of a nonblock DO con- 40 struct is called the DO termination of that construct. 41 Within a scoping unit, all DO constructs whose DO statements refer to the same label are nonblock DO constructs, and 42 share the statement identified by that label. 185 J3/07-007 WORKING DRAFT 2006/01/05 18.1.7.3 Range of the DO construct 2The range of a block DO construct is the do-block, which shall satisfy the rules for blocks (8.1.2). In 3particular, transfer of control to the interior of such a block from outside the block is prohibited. It 4is permitted to branch to the end-do of a block DO construct only from within the range of that DO 5construct. 6 The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a 7 range is not bounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the 8 range satisfies the rules for blocks (8.1.2). Transfer of control into the do-body or to the DO termination from outside the 9 range is prohibited; in particular, it is permitted to branch to a do-term-shared-stmt only from within the range of the 10 corresponding inner-shared-do-construct. 118.1.7.4 Active and inactive DO constructs 12A DO construct is either active or inactive. Initially inactive, a DO construct becomes active only 13when its DO statement is executed. Once active, the DO construct becomes inactive only when it terminates (8.1.7.5.4). 14 158.1.7.5 Execution of a DO construct 168.1.7.5.1 Loop initiation 17When the DO statement is executed, the DO construct becomes active. If loop-control is 18 [ , ] do-variable = scalar-int-expr1 , scalar-int-expr2 [ , scalar-int-expr3 ] 19the following steps are performed in sequence. 20 (1) The initial parameter m1, the terminal parameter m2, and the incrementation parameter 21 m3 are of type integer with the same kind type parameter as the do-variable. Their values 22 are established by evaluating scalar-int-expr1, scalar-int-expr2, and scalar-int-expr3, re- 23 spectively, including, if necessary, conversion to the kind type parameter of the do-variable 24 according to the rules for numeric conversion (Table 7.13). If scalar-int-expr3 does not 25 appear, m3 has the value 1. The value of m3 shall not be zero. (2) 26 The DO variable becomes defined with the value of the initial parameter m1. 27 (3) The iteration count is established and is the value of the expression (m2 - m1 + m3)/m3, 28 unless that value is negative, in which case the iteration count is 0. NOTE 8.11 The iteration count is zero whenever: m1 > m2 and m3 > 0, or m1 < m2 and m3 < 0. 29If loop-control is omitted, no iteration count is calculated. The effect is as if a large positive iteration 30count, impossible to decrement to zero, were established. If loop-control is [ , ] WHILE (scalar-logical- 31expr), the effect is as if loop-control were omitted and the following statement inserted as the first 32statement of the do-block: 33IF (.NOT. (scalar- logical-expr )) EXIT 34For a DO CONCURRENT construct, the values of the index variables for the iterations of the construct are determined by the rules for the index variables of the FORALL construct (7.2.4.2.2 and 7.2.4.2.3). 35 36An index-name in a DO CONCURRENT construct has a scope of the construct (16.4). It is a scalar 186 2006/01/05 WORKING DRAFT J3/07-007 1variable that has the type and type parameters that it would have if it were the name of a variable in the 2scoping unit that includes the construct, and this type shall be integer type; it has no other attributes. 3At the completion of the execution of the DO statement, the execution cycle begins. 48.1.7.5.2 The execution cycle 5The execution cycle of a DO construct that is not a DO CONCURRENT construct consists of the 6following steps performed in sequence repeatedly until termination. 7 (1) The iteration count, if any, is tested. If it is zero, the loop terminates and the DO construct 8 becomes inactive. If loop-control is [ , ] WHILE (scalar-logical-expr), the scalar-logical-expr 9 is evaluated; if the value of this expression is false, the loop terminates and the DO construct 10 becomes inactive. If, as a result, all of the DO constructs sharing the do-term-shared-stmt are inactive, 11 the execution of all of these constructs is complete. However, if some of the DO constructs sharing the 12 do-term-shared-stmt are active, execution continues with step (3) of the execution cycle of the active DO 13 construct whose DO statement was most recently executed. (2) The range of the loop is executed. 14 15 (3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented 16 by the value of the incrementation parameter m3. 17 Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither 18 be redefined nor become undefined while the DO construct is active. 19 The range of a DO CONCURRENT construct is executed for all of the active combinations of the 20 index-name values. Each execution of the range is an iteration. The executions may occur in any order. 21 8.1.7.5.3 CYCLE statement 22 Execution of the range of the loop may be curtailed by executing a CYCLE statement from within the 23 range of the loop. R839 cycle-stmt is CYCLE [ do-construct-name ] 24 25 C823 (R839) If a do-construct-name appears, the CYCLE statement shall be within the range of that 26 do-construct; otherwise, it shall be within the range of at least one do-construct. 27 C824 (R839) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it 28 belongs to an outer construct. 29 A CYCLE statement belongs to a particular DO construct. If the CYCLE statement contains a DO 30 construct name, it belongs to that DO construct; otherwise, it belongs to the innermost DO construct 31 in which it appears. 32 Execution of a CYCLE statement that belongs to a DO construct that is not a DO CONCURRENT 33 construct causes immediate progression to step (3) of the current execution cycle of the DO construct 34 to which it belongs. If this construct is a nonblock DO construct, the do-term-action-stmt or do-term-shared-stmt is 35 not executed. 36Execution of a CYCLE statement that belongs to a DO CONCURRENT construct completes execution 37of that iteration of the construct. 38In a block DO construct, a transfer of control to the end-do has the same effect as execution of a CYCLE 39statement belonging to that construct. In a nonblock DO construct, transfer of control to the do-term-action-stmt 40 or do-term-shared-stmt causes that statement to be executed. Unless a further transfer of control results, step (3) of the 41 current execution cycle of the DO construct is then executed. 187 J3/07-007 WORKING DRAFT 2006/01/05 18.1.7.5.4 Loop termination 2For a DO construct that is not a DO CONCURRENT construct, the loop terminates, and the DO 3construct becomes inactive, when any of the following occurs. 4 (1) The iteration count is determined to be zero or the scalar-logical-expr is false, when tested during step (1) of the above execution cycle. 5 (2) An EXIT statement belonging to the DO construct is executed. 6 7 (3) An EXIT or CYCLE statement that belongs to an outer construct and is within the range 8 of the DO construct is executed. 9 (4) Control is transferred from a statement within the range of a DO construct to a statement 10 that is neither the end-do nor within the range of the same DO construct. (5) A RETURN statement within the range of the DO construct is executed. 11 12For a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive when 13all of the iterations have completed execution. 14When a DO construct becomes inactive, the DO variable, if any, of the DO construct retains its last 15defined value. 168.1.7.6 Restrictions on DO CONCURRENT constructs 17C825 A RETURN statement shall not appear within a DO CONCURRENT construct. 18C826 A branch (8.2) within a DO CONCURRENT construct shall not have a branch target that is 19 outside the construct. 20C827 A reference to a nonpure procedure shall not appear within a DO CONCURRENT construct. 21C828 A reference to the procedure IEEE GET FLAG, IEEE SET HALTING MODE, or IEEE GET - 22 HALTING MODE from the intrinsic module IEEE EXCEPTIONS, shall not appear within a 23 DO CONCURRENT construct. 24The following additional restrictions apply to DO CONCURRENT constructs. 25 · A variable that is referenced in an iteration shall either be previously defined during that iteration, 26 or shall not be defined or become undefined during any other iteration of the current execution of 27 the construct. A variable that is defined or becomes undefined by more than one iteration of the 28 current execution of the construct becomes undefined when the current execution of the construct 29 terminates. 30 · A pointer that is referenced in an iteration either shall be previously pointer associated during that 31 iteration, or shall not have its pointer association changed during any iteration. A pointer that has 32 its pointer association changed in more than one iteration has a processor dependent association 33 status when the construct terminates. 34 · An allocatable object that is allocated in more than one iteration shall be subsequently deallocated 35 during the same iteration in which it was allocated. An object that is allocated or deallocated in 36 only one iteration shall not be deallocated, allocated, referenced, defined, or become undefined in 37 a different iteration. 38 · An input/output statement shall not write data to a file record or position in one iteration and 39 read from the same record or position in a different iteration of the same execution of the construct. 40 · Records written by output statements in the loop range to a sequential access file appear in the 41 file in an indeterminate order. 188 2006/01/05 WORKING DRAFT J3/07-007 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. 18.1.7.7 Examples of DO constructs 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 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) 189 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.16 (cont.) . . . 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 makes it easier for the processor to generate vector gather/scatter code, unroll the loop, or parallelize the code for this loop, potentially 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. 18.1.8 IF construct and statement 28.1.8.1 Form of the IF construct 3The IF construct selects for execution at most one of its constituent blocks. The selection is based on 4a sequence of logical expressions. 5R840 if-construct is if-then-stmt 6 block 7 [ else-if-stmt 8 block ] ... 9 [ else-stmt 10 block ] 11 end-if-stmt R841 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN 12 R842 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] 13 R843 else-stmt is ELSE [ if-construct-name ] 14 R844 end-if-stmt is END IF [ if-construct-name ] 15 16C829 (R840) If the if-then-stmt of an if-construct specifies an if-construct-name, the corresponding 17 end-if-stmt shall specify the same if-construct-name. If the if-then-stmt of an if-construct does 18 not specify an if-construct-name, the corresponding end-if-stmt shall not specify an if-construct- 19 name. If an else-if-stmt or else-stmt specifies an if-construct-name, the corresponding if-then- 20 stmt shall specify the same if-construct-name. 218.1.8.2 Execution of an IF construct 22At most one of the blocks in the IF construct is executed. If there is an ELSE statement in the construct, 23exactly one of the blocks in the construct is executed. The scalar logical expressions are evaluated in 190 2006/01/05 WORKING DRAFT J3/07-007 1the order of their appearance in the construct until a true value is found or an ELSE statement or END 2IF statement is encountered. If a true value or an ELSE statement is found, the block immediately 3following is executed and this completes the execution of the construct. The scalar logical expressions 4in any remaining ELSE IF statements of the IF construct are not evaluated. If none of the evaluated 5expressions is true and there is no ELSE statement, the execution of the construct is completed without 6the execution of any block within the construct. 7It is permissible to branch to an END IF statement only from within its IF construct. Execution of an 8END IF statement has no effect. 98.1.8.3 Examples of IF constructs 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 ELSE IF (C > 0) THEN B = A/C D = -1.0 ELSE B = ABS (MAX (A, C)) D = 0 END IF 108.1.8.4 IF statement 11The IF statement controls the execution of a single action statement based on a single logical expression. R845 if-stmt is IF ( scalar-logical-expr ) action-stmt 12 13C830 (R845) The action-stmt in the if-stmt shall not be an end-function-stmt, end-mp-subprogram- 14 stmt, end-program-stmt, end-subroutine-stmt, or if-stmt. 15Execution of an IF statement causes evaluation of the scalar logical expression. If the value of the 16expression is true, the action statement is executed. If the value is false, the action statement is not 17executed and execution continues. 18The execution of a function reference in the scalar logical expression may affect entities in the action 19statement. 191 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.20 An example of an IF statement is: IF (A > 0.0) A = LOG (A) 18.1.9 SELECT TYPE construct 28.1.9.1 Form of the SELECT TYPE construct 3The SELECT TYPE construct selects for execution at most one of its constituent blocks. The 4selection is based on the dynamic type of an expression. A name is associated with the expression or variable (16.4, 16.5.1.6), in the same way as for the ASSOCIATE construct. 5 6R846 select-type-construct is select-type-stmt 7 [ type-guard-stmt 8 block ] ... 9 end-select-type-stmt 10R847 select-type-stmt is [ select-construct-name : ] SELECT TYPE ( [ associate-name => ] selector ) 11 C831 (R847) If selector is not a named variable, associate-name => shall appear. 12 13C832 (R847) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). 14 C833 (R847) The selector in a select-type-stmt shall be polymorphic. 15 16R848 type-guard-stmt is TYPE IS ( type-spec ) [ select-construct-name ] 17 or CLASS IS ( derived-type-spec ) [ select-construct-name ] or CLASS DEFAULT [ select-construct-name ] 18 19C834 (R848) The type-spec or derived-type-spec shall specify that each length type parameter is as- 20 sumed. 21C835 (R848) The type-spec or derived-type-spec shall not specify a sequence derived type or a type 22 with the BIND attribute. 23C836 (R848) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify 24 an extension of the declared type of selector. 25C837 (R848) For a given select-type-construct, the same type and kind type parameter values shall 26 not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more 27 than one CLASS IS type-guard-stmt. 28C838 (R848) For a given select-type-construct, there shall be at most one CLASS DEFAULT type- 29 guard-stmt. R849 end-select-type-stmt is END SELECT [ select-construct-name ] 30 31C839 (R846) If the select-type-stmt of a select-type-construct specifies a select-construct-name, the 32 corresponding end-select-type-stmt shall specify the same select-construct-name. If the select- 33 type-stmt of a select-type-construct does not specify a select-construct-name, the corresponding 34 end-select-type-stmt shall not specify a select-construct-name. If a type-guard-stmt specifies a 35 select-construct-name, the corresponding select-type-stmt shall specify the same select-construct- 36 name. 192 2006/01/05 WORKING DRAFT J3/07-007 1The associate name of a SELECT TYPE construct is the associate-name if specified; otherwise it is the 2name that constitutes the selector. 38.1.9.2 Execution of the SELECT TYPE construct 4Execution of a SELECT TYPE construct whose selector is not a variable causes the selector expression 5to be evaluated. 6A SELECT TYPE construct selects at most one block to be executed. During execution of that block, the associate name identifies an entity, which is associated (16.5.1.6) with the selector. 7 8A TYPE IS type guard statement matches the selector if the dynamic type and kind type parameter 9values of the selector are the same as those specified by the statement. A CLASS IS type guard 10statement matches the selector if the dynamic type of the selector is an extension of the type specified 11by the statement and the kind type parameter values specified by the statement are the same as the 12corresponding type parameter values of the dynamic type of the selector. 13The block to be executed is selected as follows. 14 (1) If a TYPE IS type guard statement matches the selector, the block following that statement 15 is executed. 16 (2) Otherwise, if exactly one CLASS IS type guard statement matches the selector, the block 17 following that statement is executed. 18 (3) Otherwise, if several CLASS IS type guard statements match the selector, one of these 19 statements must specify a type that is an extension of all the types specified in the others; 20 the block following that statement is executed. 21 (4) Otherwise, if there is a CLASS DEFAULT type guard statement, the block following that 22 statement is executed. NOTE 8.21 This algorithm does not examine the type guard statements in source text order when it looks for a match; it selects the most particular type guard when there are several potential matches. 23Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not 24polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter 25values of the selector. 26Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and 27has the declared type named in the type guard statement. The type parameter values of the associating 28entity are the corresponding type parameter values of the selector. 29Within the block following a CLASS DEFAULT type guard statement, the associating entity is poly- 30morphic and has the same declared type as the selector. The type parameter values of the associating 31entity are those of the declared type of the selector. NOTE 8.22 If the declared type of the selector is T, specifying CLASS DEFAULT has the same effect as specifying CLASS IS (T). 32The other attributes of the associating entity are described in 8.1.3.3. 33It is permissible to branch to an end-select-type-stmt only from within its SELECT TYPE construct. 348.1.9.3 Examples of the SELECT TYPE construct 193 J3/07-007 WORKING DRAFT 2006/01/05 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 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 18.1.10 EXIT statement 2The EXIT statement provides one way of terminating a construct. R850 exit-stmt is EXIT [ construct-name ] 3 4C840 If a construct-name appears, the EXIT statement shall be within that construct; otherwise, it 5 shall be within the range of at least one do-construct. 6An EXIT statement belongs to a particular construct. If the EXIT statement contains a construct 7name, it belongs to that construct; otherwise, it belongs to the innermost DO construct in which it 8appears. 194 2006/01/05 WORKING DRAFT J3/07-007 1 C841 An exit-stmt shall not belong to a DO CONCURRENT construct, nor shall it appear within 2 the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO 3 CONCURRENT construct. 4 When an EXIT statement that belongs to a DO construct is executed, it terminates the loop (8.1.7.5.4) 5 and any active loops contained within the terminated loop. When an EXIT statement that belongs to 6 a non-DO construct is executed, it terminates any active loops contained within that construct, and 7 completes execution of that construct. 8.2 Branching 8 9 Branching is used to alter the normal execution sequence. A branch causes a transfer of control from 10 one statement in a scoping unit to a labeled branch target statement in the same scoping unit. Branching 11 may be caused by a GOTO statement, a computed GOTO statement, an arithmetic IF statement, a 12 CALL statement that has an alt-return-spec, or an input/output statement that has an END= or ERR= 13 specifier. Although procedure references and control constructs can cause transfer of control, they are 14 not branches. A branch target statement is an action-stmt, an associate-stmt, an end-associate- 15 stmt, an if-then-stmt, an end-if-stmt, a select-case-stmt, an end-select-stmt, a select-type-stmt, an end- 16 select-type-stmt, a do-stmt, an end-do-stmt, block-stmt, end-block-stmt, critical-stmt, end-critical-stmt, 17 a forall-construct-stmt, a do-term-action-stmt, a do-term-shared-stmt, or a where-construct-stmt. 18 8.2.1 GO TO statement 19 5 20 R851 goto-stmt is GO TO label 21 C842 (R851) The label shall be the statement label of a branch target statement that appears in the 22 same scoping unit as the goto-stmt. 23 Execution of a GO TO statement causes a transfer of control so that the branch target statement 24 identified by the label is executed next. 8.2.2 Computed GO TO statement 25 26 R852 computed-goto-stmt is GO TO ( label-list ) [ , ] scalar-int-expr 27 C843 (R852 Each label in label-list shall be the statement label of a branch target statement that appears in the same 28 scoping unit as the computed-goto-stmt. NOTE 8.25 The same statement label may appear more than once in a label list. 29 Execution of a computed GO TO statement causes evaluation of the scalar integer expression. If this value is i such 30 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 31 is 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 32 continues as though a CONTINUE statement were executed. 338.2.3 Arithmetic IF statement 34 R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label 35 C844 (R853) Each label shall be the label of a branch target statement that appears in the same scoping unit as the 36 arithmetic-if-stmt. 37 C845 (R853) The scalar-numeric-expr shall not be of type complex. 195 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.26 The same label may appear more than once in one arithmetic IF statement. 1 Execution of an arithmetic IF statement causes evaluation of the numeric expression followed by a transfer of control. 2 The branch target statement identified by the first label, the second label, or the third label is executed next depending 3 on whether the value of the numeric expression is less than zero, equal to zero, or greater than zero, respectively. 48.3 CONTINUE statement 5Execution of a CONTINUE statement has no effect. 6R854 continue-stmt is CONTINUE 78.4 STOP statement R855 stop-stmt is STOP [ stop-code ] 8 9R856 stop-code is scalar-char-initialization-expr 10 or scalar-int-initialization-expr C846 (R856) The scalar-char-initialization-expr shall be of default kind. 11 C847 (R856) The scalar-int-initialization-expr shall be of default kind. 12 13Execution of a STOP statement causes normal termination of execution of that image. If each image 14of a set of images executes a STOP statement immediately following the execution of a construct that 15performs a synchronization of the images in the set, normal termination of execution occurs for all of 16the images in the set; the executions of all other images are terminated. If termination of execution of 17an image occurs for some other reason, termination of execution occurs on all other images. 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". 196 2006/01/05 WORKING DRAFT J3/07-007 J3 internal note (cont.) 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. 1When an image is terminated by a STOP statement, its stop code, if any, is made available in a 2processor-dependent manner. If any exception (14) is signaling on that image, the processor shall issue 3a warning indicating which exceptions are signaling; this warning shall be on the unit identified by the 4named constant ERROR UNIT (13.8.2.5). It is recommended that the stop code is made available by 5formatted output to the same unit. 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 processor supports that concept. If the integer stop-code is used as the process exit status, the processor 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). If the stop-code is of type character or does not appear, or if an END PROGRAM statement is executed, it is recommended that the value zero be supplied as the process exit status, if the processor supports that concept. 8.5 Image execution control 6 8.5.1 Image control statements 7 8The execution sequence on each image is as specified in 2.3.6. 9An image control statement affects the execution ordering between images. Each of the following is 10an image control statement: 11 · SYNC ALL statement; 12 · SYNC TEAM statement; 13 · SYNC IMAGES statement; 14 · SYNC MEMORY statement; 197 J3/07-007 WORKING DRAFT 2006/01/05 1 · NOTIFY statement; 2 · QUERY statement; 3 · ALLOCATE or DEALLOCATE statement involving a co-array; · CRITICAL or END CRITICAL statement (8.1.6); 4 5 · OPEN statement with a TEAM= specifier; 6 · CLOSE statement; 7 · END, END BLOCK, or RETURN statement that involves an implicit deallocation of a co-array; 8 · END PROGRAM statement; 9 · CALL statement for a collective subroutine (13.1) or the FORM TEAM intrinsic subroutine (13.7.69). 10 11During an execution of a statement that contains more than one reference to a procedure, at most one 12reference shall cause execution of an image control statement other than CRITICAL, END CRITICAL, 13or CLOSE for a file with a connect term of only one image. 14On each image, the sequence of statements executed before the first image control statement, between 15the execution of two image control statements, or after the last image control statement is known as 16a segment. The segment executed immediately before the execution of an image control statement 17includes the evaluation of all expressions within the statement. 18By execution of image control statements or user-defined ordering (8.5.6), the program can ensure that 19the execution of the ith segment on image P, Pi, either precedes or succeeds the execution of the jth 20segment on another image Q, Qj. If the program does not ensure this, segments Pi and Qj are unordered; 21depending on the relative execution speeds of the images, some or all of the execution of the segment Pi 22may take place at the same time as some or all of the execution of the segment Qj. 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. 23A scalar co-variable that is of type default integer, default logical, default real, or default bits, and has 24the VOLATILE attribute (5.3.18) may be referenced during the execution of a segment that is unordered 25relative to the execution of a segment in which the co-variable is defined. Otherwise, 26 · if a co-array variable is defined on an image in a segment, it shall not be referenced, defined, or 27 become undefined in a segment on another image unless the segments are ordered, 28 · if the allocation of an allocatable subobject of a co-array or the pointer association of a pointer 29 subobject of a co-array is changed on an image in a segment, that subobject shall not be referenced 30 or defined in a segment on another image unless the segments are ordered, and 31 · if a procedure invocation on image P is in execution in segments Pi, Pi , ..., Pk and defines a +1 32 non-co-array dummy argument, the argument associated entity shall not be referenced, defined, or 33 become undefined on another image Q in a segment Qj unless Qj precedes Pi or succeeds Pk. 198 2006/01/05 WORKING DRAFT J3/07-007 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. 1If an image P writes a record during the execution of Pi to a file that is opened for direct access with a 2TEAM= specifier, no other image Q shall read or write the record during execution of a segment that 3is unordered with Pi. Furthermore, it shall not read the record in a segment that succeeds Pi unless 4 · after image P writes the record, it executes a FLUSH statement (9.8) for the file during the 5 execution of a segment Pk, where k >= i, and 6 · before image Q reads the record, it executes a FLUSH statement for the file during the execution 7 of a segment Qj that succeeds Pk. 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. 88.5.2 SYNC ALL statement R857 sync-all-stmt is SYNC ALL [ ( [ sync-stat-list ] ) ] 9 10R858 sync-stat is STAT = stat-variable 11 or ERRMSG = errmsg-variable 12C848 No specifier shall appear more than once in a given sync-stat-list. 13The STAT= and ERRMSG= specifiers for image execution control statements are described in 8.5.7. 14Execution of a SYNC ALL statement performs a synchronization of all images. Execution on an image, 15M, of the segment following the SYNC ALL statement is delayed until each other image has executed a 16SYNC ALL statement as many times as has image M. The segments that executed before the SYNC ALL 17statement on an image precede the segments that execute after the SYNC ALL statement on another 18image. 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. 199 J3/07-007 WORKING DRAFT 2006/01/05 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 18.5.3 SYNC TEAM statement R859 sync-team-stmt is SYNC TEAM ( image-team [ , sync-stat-list ] ) 2 3R860 image-team is scalar-variable 4C849 The image-team shall be a scalar variable of type IMAGE TEAM from the intrinsic module 5 ISO FORTRAN ENV. 6Execution of a SYNC TEAM statement performs a team synchronization, which is a synchronization 7of the images in a team. The team is specified by the value of image-team and shall include the executing 8image. All images of the team shall execute a SYNC TEAM statement with a value of image-team that 9was constructed by corresponding invocations of the intrinsic function FORM TEAM for the team. They 10do not commence executing subsequent statements until all images in the team have executed a SYNC 11TEAM statement for the team an equal number of times since FORM TEAM was invoked for the team. 12If images M and T are any two members of the team, the segments that execute before the statement 13on image M precede the segments that execute after the statement on image T. 14Execution of an OPEN statement with a TEAM= specifier, a CLOSE statement for a unit whose connect 15team consists of more than one image, or a CALL statement for a collective subroutine is interpreted 16as if an execution of a SYNC TEAM statement for the team occurred at the beginning and end of 17execution of the statement. The team is identified by the value of image-team in the statement, is the 18set of all images for a collective subroutine with no TEAM argument, or is the connect team for the 19CLOSE statement. NOTE 8.36 Execution of the FORM TEAM intrinsic subroutine also performs a team synchronization. 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, it could be an empty image set.) It would be friendly for this to raise an error in the statement rather than making the program non-conformant. 200 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.37 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 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. 18.5.4 SYNC IMAGES statement R861 sync-images-stmt is SYNC IMAGES ( image-set [ , sync-stat-list ] ) 2 3R862 image-set is int-expr 4 or * 5C850 An image-set that is an int-expr shall be scalar or of rank one. 6If image-set is an array expression, the value of each element shall be positive and not greater than the 7number of images, and there shall be no repeated values. 8If image-set is a scalar expression, its value shall be positive and not greater than the number of images. 201 J3/07-007 WORKING DRAFT 2006/01/05 1An image-set that is an asterisk specifies all images. 2Execution of a SYNC IMAGES statement performs a synchronization of the image with each of the 3other images in the image-set. Execution on an image, M, of the segment following the SYNC IMAGES 4statement is delayed until each other image T in the image-set has executed a SYNC IMAGES statement 5with M in its image-set as many times as image M has executed a SYNC IMAGES statement with T in 6the image-set. The segments that executed before the SYNC IMAGES statement on image M precede 7the segments that execute after the SYNC IMAGES statement on image T. NOTE 8.38 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.39 Execution of SYNC IMAGES (*) on all images has the same effect as execution of SYNC ALL on all images, but SYNC ALL might have better performance. SYNC IMAGES statements are not required to specify the entire image set, or even the same image set, on all 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 ! 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.40 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 202 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.40 (cont.) 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. 18.5.5 NOTIFY and QUERY statements R863 notify-stmt is NOTIFY ( image-set [ , sync-stat-list ] ) 2 R864 query-stmt is QUERY ( image-set [ , query-spec-list ] ) 3 4R865 query-spec is READY = scalar-logical-variable 5 or sync-stat C851 (R864) No specifier shall appear more than once in a given query-spec-list. 6 7Execution on image M of a NOTIFY statement with a different image T in its image-set increments by 81 a record of the number of times, NM T , image M executed such a NOTIFY statement. 9A QUERY statement is blocking if and only if it has no READY= specifier. A QUERY statement is 10satisfied on completion of its execution if and only if it is a blocking QUERY statement or it set the 11variable specified by its READY= specifier to true. 12Let QM T denote the number of times image M has completed the execution of a satisfied QUERY 13statement with a different image T in its image set. Completion of execution on image M of a blocking 14QUERY statement is delayed until, for each different T in its image set, NTM > QM T . 15Execution of a non-blocking QUERY statement on image M causes the scalar-logical-variable of its 16READY= specifier to be assigned the value false if, for a different image T in the image set, NTM 17QM T ; otherwise, true is assigned. 18A NOTIFY statement execution on image T and a satisfied QUERY statement on image M correspond 19if and only if 20 · the NOTIFY statement's image set includes image M, 21 · the QUERY statement's image set includes image T, and 22 · after execution of both statements has completed, NT M = QM T . 23Segments on an image executed before the execution of a NOTIFY statement precede the segments on 24other images that follow its corresponding QUERY statements. NOTE 8.41 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 203 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.41 (cont.) 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.42 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 ... ! 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 18.5.6 SYNC MEMORY statement 2The SYNC MEMORY statement provides a means of dividing a segment on an image into two segments, 3each of which can be ordered in some user-defined way with respect to segments on other images. R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat-list ] ) ] 4 NOTE 8.43 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. 204 2006/01/05 WORKING DRAFT J3/07-007 1All of the other image control statements include the effect of executing a SYNC MEMORY statement. 2In addition, the other image control statements cause some form of cooperation with other images for 3the purpose of ordering execution between images. NOTE 8.44 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 LOCKED[Q] = .FALSE. ! segment Pi SYNC MEMORY ! B ELSE IF (IAM == Q) THEN DO WHILE (LOCKED); END DO ! segment Qj 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 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.45 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 205 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.45 (cont.) 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 2If the STAT= specifier appears, successful execution of the SYNC ALL, SYNC TEAM, SYNC IMAGES, 3SYNC MEMORY, NOTIFY, or QUERY statement causes the specified variable to become defined with 4the value zero. If an error occurs during execution of one of these statements, the variable becomes 5defined with a processor-dependent positive integer value. If an error condition occurs during execution 6of a SYNC ALL, SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement 7that does not contain the STAT= specifier, execution of all images is terminated. 8If the ERRMSG= specifier appears and an error condition occurs during execution of the SYNC ALL, 9SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement, the processor shall 10assign an explanatory message to the specified variable. If no such condition occurs, the processor shall 11not change the value of the variable. NOTE 8.46 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. 206 2006/01/05 WORKING DRAFT J3/07-007 9 Input/output statements 1 2Input statements provide the means of transferring data from external media to internal storage or 3from an internal file to internal storage. This process is called reading. Output statements provide 4the means of transferring data from internal storage to external media or from internal storage to an 5internal file. This process is called writing. Some input/output statements specify that editing of the 6data is to be performed. 7In addition to the statements that transfer data, there are auxiliary input/output statements to ma- 8nipulate the external medium, or to describe or inquire about the properties of the connection to the 9external medium. 10The input/output statements are the OPEN, CLOSE, READ, WRITE, PRINT, BACKSPACE, END- 11FILE, REWIND, FLUSH, WAIT, and INQUIRE statements. 12The READ statement is a data transfer input statement. The WRITE statement and the PRINT 13statement are data transfer output statements. The OPEN statement and the CLOSE state- 14ment are file connection statements. The INQUIRE statement is a file inquiry statement. The 15BACKSPACE, ENDFILE, and REWIND statements are file positioning statements. 16A file is composed of either a sequence of file storage units (9.2.4) or a sequence of records, which 17provide an extra level of organization to the file. A file composed of records is called a record file. A 18file composed of file storage units is called a stream file. A processor may allow a file to be viewed 19both as a record file and as a stream file; in this case the relationship between the file storage units when 20viewed as a stream file and the records when viewed as a record file is processor dependent. A file is either an external file (9.2) or an internal file (9.3). 21 229.1 Records 23A record is a sequence of values or a sequence of characters. For example, a line on a terminal is usually 24considered to be a record. However, a record does not necessarily correspond to a physical entity. There 25are three kinds of records: (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." 299.1.1 Formatted record 30A formatted record consists of a sequence of characters that are representable in the processor; 31however, a processor may prohibit some control characters (3.1) from appearing in a formatted record. 32The length of a formatted record is measured in characters and depends primarily on the number of 33characters put into the record when it is written. However, it may depend on the processor and the 34external medium. The length may be zero. Formatted records may be read or written only by formatted input/output statements. 35 207 J3/07-007 WORKING DRAFT 2006/01/05 1Formatted records may be prepared by means other than Fortran. 29.1.2 Unformatted record 3An unformatted record consists of a sequence of values in a processor-dependent form and may contain 4data of any type or may contain no data. The length of an unformatted record is measured in file storage 5units (9.2.4) and depends on the output list (9.5.3) used when it is written, as well as on the processor 6and the external medium. The length may be zero. Unformatted records may be read or written only by unformatted input/output statements. 7 89.1.3 Endfile record 9An endfile record is written explicitly by the ENDFILE statement; the file shall be connected for 10sequential access. An endfile record is written implicitly to a file connected for sequential access when 11the most recent data transfer statement referring to the file is a data transfer output statement, no 12intervening file positioning statement referring to the file has been executed, and 13 (1) a REWIND or BACKSPACE statement references the unit to which the file is connected, 14 or 15 (2) the unit is closed, either explicitly by a CLOSE statement, implicitly by a program termi- 16 nation not caused by an error condition, or implicitly by another OPEN statement for the 17 same unit. 18An endfile record may occur only as the last record of a file. An endfile record does not have a length 19property. 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). 209.2 External files 21An external file is any file that exists in a medium external to the program. 22At any given time, there is a processor-dependent set of allowed access methods, a processor-dependent 23set of allowed forms, a processor-dependent set of allowed actions, and a processor-dependent set of 24allowed record lengths for a file. 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. 25A file may have a name; a file that has a name is called a named file. The name of a named file is 26represented by a character string value. The set of allowable names for a file is processor dependent. 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 208 2006/01/05 WORKING DRAFT J3/07-007 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. 29.2.1 File existence 3At any given time, there is a processor-dependent set of external files that exist for a program. A file 4may be known to the processor, yet not exist for a program at a particular time. NOTE 9.6 Security reasons may prevent a file from existing for a program. A newly created file may exist but contain no records. 5To create a file means to cause a file to exist that did not exist previously. To delete a file means to 6terminate the existence of the file. 7All input/output statements may refer to files that exist. An INQUIRE, OPEN, CLOSE, WRITE, 8PRINT, REWIND, FLUSH, or ENDFILE statement also may refer to a file that does not exist. Execu- 9tion of a WRITE, PRINT, or ENDFILE statement referring to a preconnected file that does not exist 10creates the file. 119.2.2 File access 12There are three methods of accessing the data of an external file: sequential, direct, and stream. Some 13files may have more than one allowed access method; other files may be restricted to one access method. 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. 14The method of accessing a file is determined when the file is connected to a unit (9.4.3) or when the file is created if the file is preconnected (9.4.4). 15 169.2.2.1 Sequential access 17Sequential access is a method of accessing the records of an external record file in order. 18When connected for sequential access, an external file has the following properties. 19 (1) The order of the records is the order in which they were written if the direct access method 20 is not a member of the set of allowed access methods for the file. If the direct access method 21 is also a member of the set of allowed access methods for the file, the order of the records 22 is the same as that specified for direct access. In this case, the first record accessible by 23 sequential access is the record whose record number is 1 for direct access. The second record 24 accessible by sequential access is the record whose record number is 2 for direct access, etc. 25 A record that has not been written since the file was created shall not be read. 26 (2) The records of the file are either all formatted or all unformatted, except that the last record 27 of the file may be an endfile record. Unless the previous reference to the file was a data 209 J3/07-007 WORKING DRAFT 2006/01/05 1 transfer output statement, the last record, if any, of the file shall be an endfile record. 2 (3) The records of the file shall be read or written only by sequential access input/output 3 statements. 4 (4) Each record shall be read or written by a single image. The processor shall ensure that once 5 an image commences transferring the data of a record to the file, no other image transfers 6 data to the file until the whole record has been transferred. 79.2.2.2 Direct access 8Direct access is a method of accessing the records of an external record file in arbitrary order. 9When connected for direct access, an external file has the following properties. 10 (1) Each record of the file is uniquely identified by a positive integer called the record number. 11 The record number of a record is specified when the record is written. Once established, 12 the record number of a record can never be changed. The order of the records is the order 13 of their record numbers. NOTE 9.8 A record cannot be deleted; however, a record may be rewritten. 14 (2) The records of the file are either all formatted or all unformatted. If the sequential access 15 method is also a member of the set of allowed access methods for the file, its endfile record, 16 if any, is not considered to be part of the file while it is connected for direct access. If the 17 sequential access method is not a member of the set of allowed access methods for the file, 18 the file shall not contain an endfile record. (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 21 (5) Records need not be read or written in the order of their record numbers. Any record may 22 be written into the file while it is connected to a unit. For example, it is permissible to write 23 record 3, even though records 1 and 2 have not been written. Any record may be read from 24 the file while it is connected to a unit, provided that the record has been written since the 25 file was created, and if a READ statement for this connection is permitted. 26 (6) The records of the file shall not be read or written using list-directed formatting (10.10), namelist formatting (10.11), or a nonadvancing input/output statement (9.2.3.1). 27 289.2.2.3 Stream access Stream access is a method of accessing the file storage units (9.2.4) of an external stream file. 29 30The properties of an external file connected for stream access depend on whether the connection is for 31unformatted or formatted access. 32When connected for unformatted stream access, an external file has the following properties. 33 (1) The file storage units of the file shall be read or written only by stream access input/output 34 statements. 35 (2) Each file storage unit in the file is uniquely identified by a positive integer called the position. 36 The first file storage unit in the file is at position 1. The position of each subsequent file 37 storage unit is one greater than that of its preceding file storage unit. 38 (3) If it is possible to position the file, the file storage units need not be read or written in 39 order of their position. For example, it might be permissible to write the file storage unit 40 at position 3, even though the file storage units at positions 1 and 2 have not been written. 41 Any file storage unit may be read from the file while it is connected to a unit, provided that 210 2006/01/05 WORKING DRAFT J3/07-007 1 the file storage unit has been written since the file was created, and if a READ statement 2 for this connection is permitted. 3When connected for formatted stream access, an external file has the following properties. 4 (1) Some file storage units of the file may contain record markers; this imposes a record structure 5 on the file in addition to its stream structure. There might or might not be a record marker 6 at the end of the file. If there is no record marker at the end of the file, the final record is 7 incomplete. (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. 10 (4) The file storage units of the file shall be read or written only by formatted stream access input/output statements. 11 12 (5) Each file storage unit in the file is uniquely identified by a positive integer called the position. 13 The first file storage unit in the file is at position 1. The relationship between positions of 14 successive file storage units is processor dependent; not all positive integers need correspond 15 to valid positions. 16 (6) If it is possible to position the file, the file position can be set to a position that was 17 previously identified by the POS= specifier in an INQUIRE statement. 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). 18 (7) A processor may prohibit some control characters (3.1) from appearing in a formatted stream 19 file. 9.2.3 File position 20 21Execution of certain input/output statements affects the position of an external file. Certain circum- 22stances can cause the position of a file to become indeterminate. 23The initial point of a file is the position just before the first record or file storage unit. The terminal 24point is the position just after the last record or file storage unit. If there are no records or file storage 25units in the file, the initial point and the terminal point are the same position. 26If a record file is positioned within a record, that record is the current record; otherwise, there is no 27current record. 28Let n be the number of records in the file. If 1 < i n and a file is positioned within the ith record or 29between the (i - 1)th record and the ith record, the (i - 1)th record is the preceding record. If n 1 30and the file is positioned at its terminal point, the preceding record is the nth and last record. If n = 0 31or if a file is positioned at its initial point or within the first record, there is no preceding record. 32If 1 i < n and a file is positioned within the ith record or between the ith and (i + 1)th record, the 33(i+1)th record is the next record. If n 1 and the file is positioned at its initial point, the first record 34is the next record. If n = 0 or if a file is positioned at its terminal point or within the nth (last) record, 35there is no next record. 211 J3/07-007 WORKING DRAFT 2006/01/05 1For a file connected for stream access, the file position is either between two file storage units, at the 2initial point of the file, at the terminal point of the file, or undefined. 9.2.3.1 Advancing and nonadvancing input/output 3 4An advancing input/output statement always positions a record file after the last record read or 5written, unless there is an error condition. 6A nonadvancing input/output statement may position a record file at a character position within 7the current record, or a subsequent record (10.8.2). Using nonadvancing input/output, it is possible to 8read or write a record of the file by a sequence of input/output statements, each accessing a portion 9of the record. It is also possible to read variable-length records and be notified of their lengths. If a 10nonadvancing output statement leaves a file positioned within a current record and no further output 11statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement 12is executed for it, the effect is as if the output statement were the corresponding advancing output 13statement. 149.2.3.2 File position prior to data transfer 15The positioning of the file prior to data transfer depends on the method of access: sequential, direct, or 16stream. 17For sequential access on input, if there is a current record, the file position is not changed. Otherwise, 18the file is positioned at the beginning of the next record and this record becomes the current record. 19Input shall not occur if there is no next record or if there is a current record and the last data transfer 20statement accessing the file performed output. 21If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data 22transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file. 23For sequential access on output, if there is a current record, the file position is not changed and the 24current record becomes the last record of the file. Otherwise, a new record is created as the next record 25of the file; this new record becomes the last and current record of the file and the file is positioned at 26the beginning of this record. 27For direct access, the file is positioned at the beginning of the record specified by the REC= specifier. 28This record becomes the current record. 29For stream access, the file is positioned immediately before the file storage unit specified by the POS= 30specifier; if there is no POS= specifier, the file position is not changed. 31File positioning for child data transfer statements is described in 9.5.4.7. 329.2.3.3 File position after data transfer 33If an error condition (9.10) occurred, the position of the file is indeterminate. If no error condition 34occurred, but an end-of-file condition (9.10) occurred as a result of reading an endfile record, the file is 35positioned after the endfile record. 36For unformatted stream access, if no error condition occurred, the file position is not changed. For 37unformatted stream output, if the file position exceeds the previous terminal point of the file, the 38terminal point is set to the file position. 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. 212 2006/01/05 WORKING DRAFT J3/07-007 1For formatted stream input, if an end-of-file condition occurred, the file position is not changed. 2For nonadvancing input, if no error condition or end-of-file condition occurred, but an end-of-record 3condition (9.10) occurred, the file is positioned after the record just read. If no error condition, end-of- 4file condition, or end-of-record condition occurred in a nonadvancing input statement, the file position 5is not changed. If no error condition occurred in a nonadvancing output statement, the file position is 6not changed. 7In all other cases, the file is positioned after the record just read or written and that record becomes the 8preceding record. 9For a formatted stream output statement, if no error condition occurred, the terminal point of the file 10is set to the highest-numbered position to which data was transferred by the statement. 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 12A file storage unit is the basic unit of storage in a stream file or an unformatted record file. It is the 13unit of file position for stream access, the unit of record length for unformatted files, and the unit of file 14size for all external files. 15Every value in a stream file or an unformatted record file shall occupy an integer number of file storage 16units; if the stream or record file is unformatted, this number shall be the same for all scalar values of 17the same type and type parameters. The number of file storage units required for an item of a given type 18and type parameters may be determined using the IOLENGTH= specifier of the INQUIRE statement (9.9.3). 19 20For a file connected for unformatted stream access, the processor shall not have alignment restrictions 21that prevent a value of any type from being stored at any positive integer file position. 22The number of bits in a file storage unit is given by the constant FILE STORAGE SIZE (13.8.2.6) 23defined in the intrinsic module ISO FORTRAN ENV. It is recommended that the file storage unit be 24an 8-bit octet where this choice is practical. 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. 259.3 Internal files 213 J3/07-007 WORKING DRAFT 2006/01/05 1Internal files provide a means of transferring and converting data from internal storage to internal 2storage. 3An internal file is a record file with the following properties. 4 (1) The file is a variable of default, ASCII, or ISO 10646 character type that is not an array 5 section with a vector subscript. (2) A record of an internal file is a scalar character variable. 6 7 (3) If the file is a scalar character variable, it consists of a single record whose length is the same 8 as the length of the scalar character variable. If the file is a character array, it is treated 9 as a sequence of character array elements. Each array element, if any, is a record of the 10 file. The ordering of the records of the file is the same as the ordering of the array elements 11 in the array (6.2.2.1) or the array section (6.2.2.2). Every record of the file has the same 12 length, which is the length of an array element in the array. 13 (4) A record of the internal file becomes defined by writing the record. If the number of 14 characters written in a record is less than the length of the record, the remaining portion 15 of the record is filled with blanks. The number of characters to be written shall not exceed 16 the length of the record. (5) A record may be read only if the record is defined. 17 18 (6) A record of an internal file may become defined (or undefined) by means other than an 19 output statement. For example, the character variable may become defined by a character 20 assignment statement. 21 (7) An internal file is always positioned at the beginning of the first record prior to data transfer, except for child data transfer statements (9.5.4.7). This record becomes the current record. 22 23 (8) The initial value of a connection mode (9.4.1) is the value that would be implied by an 24 initial OPEN statement without the corresponding keyword. 25 (9) Reading and writing records shall be accomplished only by sequential access formatted input/output statements. 26 27 (10) An internal file shall not be specified as the unit in a file connection statement or a file 28 positioning statement. 299.4 File connection 30A unit, specified by an io-unit, provides a means for referring to a file. 31R901 io-unit is file-unit-number 32 or * 33 or internal-file-variable 34R902 file-unit-number is scalar-int-expr 35R903 internal-file-variable is char-variable C901 (R903) The char-variable shall not be an array section with a vector subscript. 36 37C902 (R903) The char-variable shall be of type default character, ASCII character, or ISO 10646 38 character. 39A unit is either an external unit or an internal unit. An external unit is used to refer to an external file 40and is specified by an asterisk or a file-unit-number. The value of file-unit-number shall be nonnegative, 41equal to one of the named constants INPUT UNIT, OUTPUT UNIT, or ERROR UNIT of the ISO - 42FORTRAN ENV module (13.8.2), or a NEWUNIT value (9.4.5.10). An internal unit is used to refer 43to an internal file and is specified by an internal-file-variable or a file-unit-number whose value is equal 44to the unit argument of an active derived-type input/output procedure (9.5.4.7). The value of a file- 214 2006/01/05 WORKING DRAFT J3/07-007 1unit-number shall identify a valid unit. 2The external unit identified by a particular value of a scalar-int-expr is the same external unit in all 3program units of the program, and on all images. 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. 4An asterisk identifies particular processor-dependent external units that are preconnected for format- 5ted sequential access (9.5.4.2). These units are also identified by unit numbers defined by the named constants INPUT UNIT and OUTPUT UNIT of the ISO FORTRAN ENV module (13.8.2). 6 7This part of ISO/IEC 1539 identifies a processor-dependent external unit for the purpose of error re- 8porting. This unit shall be preconnected for sequential formatted output. The processor may define this 9to be the same as the output unit identified by an asterisk. This unit is also identified by a unit number 10defined by the named constant ERROR UNIT of the ISO FORTRAN ENV intrinsic module. 119.4.1 Connection modes 12A connection for formatted input/output has several changeable modes: the blank interpretation mode 13(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- 14ing mode (10.7.2.3.7), pad mode (9.5.4.4.2), and scale factor (10.8.5). A connection for unformatted input/output has no changeable modes. 15 16Values for the modes of a connection are established when the connection is initiated. If the connection 17is initiated by an OPEN statement, the values are as specified, either explicitly or implicitly, by the 18OPEN statement. If the connection is initiated other than by an OPEN statement (that is, if the file is 19an internal file or preconnected file) the values established are those that would be implied by an initial 20OPEN statement without the corresponding keywords. 21The scale factor cannot be explicitly specified in an OPEN statement; it is implicitly 0. 22The modes of a connection to an external file may be changed by a subsequent OPEN statement that 23modifies the connection. 24The modes of a connection may be temporarily changed by a corresponding keyword specifier in a 25data transfer statement or by an edit descriptor. Keyword specifiers take effect at the beginning of 26execution of the data transfer statement. Edit descriptors take effect when they are encountered in 27format processing. When a data transfer statement terminates, the values for the modes are reset to the 28values in effect immediately before the data transfer statement was executed. 299.4.2 Unit existence 30At any given time, there is a processor-dependent set of external units that exist for a program. 31All input/output statements may refer to units that exist. The CLOSE, INQUIRE, and WAIT state- 215 J3/07-007 WORKING DRAFT 2006/01/05 1ments also may refer to units that do not exist. 29.4.3 Connection of a file to a unit 3An external unit has a property of being connected or not connected. If connected, it refers to an 4external file. An external unit may become connected by preconnection or by the execution of an OPEN 5statement. The property of connection is symmetric; the unit is connected to a file if and only if the file 6is connected to the unit. 7Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement shall refer to 8a unit that is connected to a file and thereby make use of or affect that file. A file may be connected and not exist (9.2.1). 9 NOTE 9.15 An example is a preconnected external file that has not yet been written. 10A unit shall not be connected to more than one file at the same time, and a file shall not be connected to 11more than one unit at the same time. However, means are provided to change the status of an external 12unit and to connect a unit to a different file. 13This part of ISO/IEC 1539 defines means of portable interoperation with C. C streams are described 14in 7.19.2 of the C International Standard. Whether a unit can be connected to a file that is also 15connected to a C stream is processor dependent. If a unit is connected to a file that is also connected to 16a C stream, the results of performing input/output operations on such a file are processor dependent. 17It is processor dependent whether the files connected to the units INPUT UNIT, OUTPUT UNIT, 18and ERROR UNIT correspond to the predefined C text streams standard input, standard output, and 19standard error. If a procedure defined by means of Fortran and a procedure defined by means other than 20Fortran perform input/output operations on the same external file, the results are processor dependent. 21A procedure defined by means of Fortran and a procedure defined by means other than Fortran can perform input/output operations on different external files without interference. 22 23After an external unit has been disconnected by the execution of a CLOSE statement, it may be con- 24nected again within the same program to the same file or to a different file. After an external file has 25been disconnected by the execution of a CLOSE statement, it may be connected again within the same 26program to the same unit or to a different unit. 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. 27An internal unit is always connected to the internal file designated by the variable that identifies the 28unit. NOTE 9.17 For more explanatory information on file connection properties, see C.6.5. 299.4.4 Preconnection 30Preconnection means that the unit is connected to a file at the beginning of execution of the program 31and therefore it may be specified in input/output statements without the prior execution of an OPEN 32statement. 216 2006/01/05 WORKING DRAFT J3/07-007 19.4.5 OPEN statement 2An OPEN statement initiates or modifies the connection between an external file and a specified unit. 3The OPEN statement may be used to connect an existing file to a unit, create a file that is preconnected, 4create a file and connect it to a unit, or change certain modes of a connection between a file and a unit. 5An external unit may be connected by an OPEN statement in any program unit of a program and, once 6connected, a reference to it may appear in any program unit of the program. 7If the file to be connected to the unit does not exist but is the same as the file to which the unit is 8preconnected, the modes specified by an OPEN statement become a part of the connection. 9If the file to be connected to the unit is not the same as the file to which the unit is connected, the effect 10is as if a CLOSE statement without a STATUS= specifier had been executed for the unit immediately 11prior to the execution of an OPEN statement. 12If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. 13If the FILE= specifier is not included in such an OPEN statement, the file to be connected to the unit 14is the same as the file to which the unit is already connected. 15If the file to be connected to the unit is the same as the file to which the unit is connected, only the 16specifiers for changeable modes (9.4.1) may have values different from those currently in effect. If the 17POSITION= specifier appears in such an OPEN statement, the value specified shall not disagree with 18the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it shall 19be specified with the value OLD. Execution of such an OPEN statement causes any new values of the 20specifiers for changeable modes to be in effect, but does not cause any change in any of the unspecified 21specifiers and the position of the file is unaffected. The ERR=, IOSTAT=, and IOMSG= specifiers from 22any previously executed OPEN statement have no effect on any currently executed OPEN statement. 23A STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is 24the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH 25before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the 26file is still considered to have a status of SCRATCH. 27If a file is already connected to a unit, an OPEN statement on that file with a different unit shall not 28be executed. R904 open-stmt is OPEN ( connect-spec-list ) 29 30R905 connect-spec is [ UNIT = ] file-unit-number 31 or ACCESS = scalar-default-char-expr 32 or ACTION = scalar-default-char-expr 33 or ASYNCHRONOUS = scalar-default-char-expr 34 or BLANK = scalar-default-char-expr 35 or DECIMAL = scalar-default-char-expr 36 or DELIM = scalar-default-char-expr 37 or ENCODING = scalar-default-char-expr 38 or ERR = label 39 or FILE = file-name-expr 40 or FORM = scalar-default-char-expr 41 or IOMSG = iomsg-variable 42 or IOSTAT = scalar-int-variable 43 or NEWUNIT = scalar-int-variable 44 or PAD = scalar-default-char-expr 45 or POSITION = scalar-default-char-expr 46 or RECL = scalar-int-expr 217 J3/07-007 WORKING DRAFT 2006/01/05 1 or ROUND = scalar-default-char-expr 2 or SIGN = scalar-default-char-expr 3 or STATUS = scalar-default-char-expr 4 or TEAM = image-team 5R906 file-name-expr is scalar-default-char-expr 6R907 iomsg-variable is scalar-default-char-variable 7C903 No specifier shall appear more than once in a given connect-spec-list. 8C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be specified; if 9 the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the 10 connect-spec-list. 11C905 (R904) The label used in the ERR= specifier shall be the statement label of a branch target 12 statement that appears in the same scoping unit as the OPEN statement. C906 (R904) If a NEWUNIT= specifier appears, a file-unit-number shall not appear. 13 14If the STATUS= specifier has the value NEW or REPLACE, the FILE= specifier shall appear. If the 15STATUS= specifier has the value SCRATCH, the FILE= specifier shall not appear. If the STATUS= 16specifier has the value OLD, the FILE= specifier shall appear unless the unit is connected and the file 17connected to the unit exists. 18If the NEWUNIT= specifier appears in an OPEN statement, either the FILE= specifier shall appear, 19or the STATUS= specifier shall appear with a value of SCRATCH. The unit identified by a NEWUNIT 20value shall not be preconnected. 21A specifier that requires a scalar-default-char-expr may have a limited list of character values. These 22values are listed for each such specifier. Any trailing blanks are ignored. The value specified is without 23regard to case. Some specifiers have a default value if the specifier is omitted. 24The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 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. 259.4.5.1 ACCESS= specifier in the OPEN statement 26The scalar-default-char-expr shall evaluate to SEQUENTIAL, DIRECT, or STREAM. The ACCESS= 27specifier specifies the access method for the connection of the file as being sequential, direct, or stream. 28If this specifier is omitted, the default value is SEQUENTIAL. For an existing file, the specified access 29method shall be included in the set of allowed access methods for the file. For a new file, the processor 30creates the file with a set of allowed access methods that includes the specified method. 319.4.5.2 ACTION= specifier in the OPEN statement 32The scalar-default-char-expr shall evaluate to READ, WRITE, or READWRITE. READ specifies that 33the WRITE, PRINT, and ENDFILE statements shall not refer to this connection. WRITE specifies 218 2006/01/05 WORKING DRAFT J3/07-007 1that READ statements shall not refer to this connection. READWRITE permits any input/output 2statements to refer to this connection. If this specifier is omitted, the default value is processor dependent. 3If READWRITE is included in the set of allowable actions for a file, both READ and WRITE also shall 4be included in the set of allowed actions for that file. For an existing file, the specified action shall be 5included in the set of allowed actions for the file. For a new file, the processor creates the file with a set 6of allowed actions that includes the specified action. 79.4.5.3 ASYNCHRONOUS= specifier in the OPEN statement 8The scalar-default-char-expr shall evaluate to YES or NO. If YES is specified, asynchronous input/output 9on the unit is allowed. If NO is specified, asynchronous input/output on the unit is not allowed. If this 10specifier is omitted, the default value is NO. 119.4.5.4 BLANK= specifier in the OPEN statement 12The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier is permitted only 13for a connection for formatted input/output. It specifies the current value of the blank interpretation 14mode (10.8.6, 9.5.2.6) for input for this connection. This mode has no effect on output. It is a changeable 15mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the default 16value is NULL. 179.4.5.5 DECIMAL= specifier in the OPEN statement 18The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier is per- 19mitted only for a connection for formatted input/output. It specifies the current value of the decimal 20edit mode (10.6, 10.8.8, 9.5.2.7) for this connection. This is a changeable mode (9.4.1). If this specifier 21is omitted in an OPEN statement that initiates a connection, the default value is POINT. 229.4.5.6 DELIM= specifier in the OPEN statement 23The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 24ifier is permitted only for a connection for formatted input/output. It specifies the current value of the 25delimiter mode (9.5.2.8) for list-directed (10.10.4) and namelist (10.11.4.1) output for the connection. 26This mode has no effect on input. It is a changeable mode (9.4.1). If this specifier is omitted in an 27OPEN statement that initiates a connection, the default value is NONE. 289.4.5.7 ENCODING= specifier in the OPEN statement 29The scalar-default-char-expr shall evaluate to UTF-8 or DEFAULT. The ENCODING= specifier is 30permitted only for a connection for formatted input/output. The value UTF-8 specifies that the encoding 31form of the file is UTF-8 as specified by ISO/IEC 10646-1:2000. Such a file is called a Unicode file, 32and all characters therein are of ISO 10646 character type. The value UTF-8 shall not be specified if 33the processor does not support the ISO 10646 character type. The value DEFAULT specifies that the 34encoding form of the file is processor-dependent. If this specifier is omitted in an OPEN statement that 35initiates a connection, the default value is DEFAULT. 369.4.5.8 FILE= specifier in the OPEN statement 37The value of the FILE= specifier is the name of the file to be connected to the specified unit. Any trailing 38blanks are ignored. The file-name-expr shall be a name that is allowed by the processor. If this specifier 39is omitted and the unit is not connected to a file, the STATUS= specifier shall be specified with a value 40of SCRATCH; in this case, the connection is made to a processor-dependent file. The interpretation of 41case is processor dependent. 219 J3/07-007 WORKING DRAFT 2006/01/05 19.4.5.9 FORM= specifier in the OPEN statement 2The scalar-default-char-expr shall evaluate to FORMATTED or UNFORMATTED. The FORM= spec- 3ifier determines whether the file is being connected for formatted or unformatted input/output. If this 4specifier is omitted, the default value is UNFORMATTED if the file is being connected for direct access 5or stream access, and the default value is FORMATTED if the file is being connected for sequential 6access. For an existing file, the specified form shall be included in the set of allowed forms for the file. 7For a new file, the processor creates the file with a set of allowed forms that includes the specified form. 89.4.5.10 NEWUNIT= specifier in the OPEN statement 9The variable is defined with a processor determined NEWUNIT value if no error occurs during the 10execution of the OPEN statement. If an error occurs, the processor shall not change the value of the 11variable. 12A NEWUNIT value is a negative number, and shall not be equal to -1, any of the named constants 13ERROR UNIT, INPUT UNIT, or OUTPUT UNIT from the ISO FORTRAN ENV intrinsic module 14(13.8.2), any value used by the processor for the unit argument to a user-defined derived-type in- 15put/output procedure, nor any previous NEWUNIT value that identifies a file that is currently con- 16nected. 179.4.5.11 PAD= specifier in the OPEN statement 18The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier is permitted only for a 19connection for formatted input/output. It specifies the current value of the pad mode (9.5.4.4.2, 9.5.2.10) 20for input for this connection. This mode has no effect on output. It is a changeable mode (9.4.1). If this 21specifier is omitted in an OPEN statement that initiates a connection, the default value is YES. 229.4.5.12 POSITION= specifier in the OPEN statement 23The scalar-default-char-expr shall evaluate to ASIS, REWIND, or APPEND. The connection shall be 24for sequential or stream access. A new file is positioned at its initial point. REWIND positions an 25existing file at its initial point. APPEND positions an existing file such that the endfile record is the 26next record, if it has one. If an existing file does not have an endfile record, APPEND positions the 27file at its terminal point. ASIS leaves the position unchanged if the file exists and already is connected. 28ASIS leaves the position unspecified if the file exists but is not connected. If this specifier is omitted, 29the default value is ASIS. 309.4.5.13 RECL= specifier in the OPEN statement 31The value of the RECL= specifier shall be positive. It specifies the length of each record in a file being 32connected for direct access, or specifies the maximum length of a record in a file being connected for 33sequential access. This specifier shall not appear when a file is being connected for stream access. This 34specifier shall appear when a file is being connected for direct access. If this specifier is omitted when 35a file is being connected for sequential access, the default value is processor dependent. If the file is 36being connected for formatted input/output, the length is the number of characters for all records that 37contain only characters of type default character. When a record contains any nondefault characters, 38the effect of the RECL= specifier is processor dependent. If the file is being connected for unformatted 39input/output, the length is measured in file storage units. For an existing file, the value of the RECL= 40specifier shall be included in the set of allowed record lengths for the file. For a new file, the processor 41creates the file with a set of allowed record lengths that includes the specified value. 429.4.5.14 ROUND= specifier in the OPEN statement 220 2006/01/05 WORKING DRAFT J3/07-007 1The scalar-default-char-expr shall evaluate to one of UP, DOWN, ZERO, NEAREST, COMPATIBLE, 2or PROCESSOR DEFINED. The ROUND= specifier is permitted only for a connection for formatted 3input/output. It specifies the current value of the I/O rounding mode (10.7.2.3.7, 9.5.2.13) for this 4connection. This is a changeable mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the I/O rounding mode is processor dependent; it shall be one of the above modes. 5 NOTE 9.20 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. 69.4.5.15 SIGN= specifier in the OPEN statement 7The scalar-default-char-expr shall evaluate to one of PLUS, SUPPRESS, or PROCESSOR DEFINED. 8The SIGN= specifier is permitted only for a connection for formatted input/output. It specifies the 9current value of the sign mode (10.8.4, 9.5.2.14) for this connection. This is a changeable mode (9.4.1). 10If this specifier is omitted in an OPEN statement that initiates a connection, the default value is PRO- 11CESSOR DEFINED. 129.4.5.16 STATUS= specifier in the OPEN statement 13The scalar-default-char-expr shall evaluate to OLD, NEW, SCRATCH, REPLACE, or UNKNOWN. If 14OLD is specified, the file shall exist. If NEW is specified, the file shall not exist. 15Successful execution of an OPEN statement with NEW specified creates the file and changes the status 16to OLD. If REPLACE is specified and the file does not already exist, the file is created and the status is 17changed to OLD. If REPLACE is specified and the file does exist, the file is deleted, a new file is created 18with the same name, and the status is changed to OLD. If SCRATCH is specified, the file is created 19and connected to the specified unit for use by the program but is deleted at the execution of a CLOSE 20statement referring to the same unit or at the normal termination of the program. NOTE 9.21 SCRATCH shall not be specified with a named file. 21If UNKNOWN is specified, the status is processor dependent. If this specifier is omitted, the default 22value is UNKNOWN. 239.4.5.17 TEAM= specifier in the OPEN statement 24The image-team specifies the connect team for the unit, which is the set of images that are permitted 25to reference the unit. The team shall include the executing image. If there is no TEAM= specifier, the 26connect team consists of only the executing image. 27All images in the connect team, and no others, shall execute the same OPEN statement with identical 28values for the connect-specs. There is an implicit team synchronization. 29If the OPEN statement has a STATUS= specifier with the value SCRATCH, the processor shall connect 30the same file to the unit on all images in the connect team. 31If the connect team contains more than one image, the OPEN statement shall 32 · specify direct access or 33 · specify sequential access and have an ACTION= specifier that evaluates to WRITE. 221 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.22 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. 1Units connected to a preconnected file, other than the unit identified by the value INPUT UNIT in 2the intrinsic module ISO FORTRAN ENV have a connect team consisting of all the images. The unit 3identified by the value INPUT UNIT in the intrinsic module ISO FORTRAN ENV is preconnected with 4a connect team consisting of image 1 on image 1 and is not preconnected on other images. NOTE 9.23 The input unit identified by * is therefore only available on the image with index one. File position- ing statements and READ are not allowed for preconnected units, including units preconnected to OUTPUT UNIT and ERROR UNIT, if the number of images is greater than one. The FLUSH and INQUIRE statements are always allowed for preconnected units. 59.4.6 CLOSE statement 6The CLOSE statement is used to terminate the connection of a specified unit to an external file. 7Execution of a CLOSE statement for a unit may occur in any program unit of a program and need not 8occur in the same program unit as the execution of an OPEN statement referring to that unit. 9Execution of a CLOSE statement performs a wait operation for any pending asynchronous data transfer 10operations for the specified unit. 11Execution of a CLOSE statement specifying a unit that does not exist or has no file connected to it is 12permitted and affects no file or unit. 13After a unit has been disconnected by execution of a CLOSE statement, it may be connected again 14within the same program, either to the same file or to a different file. After a named file has been 15disconnected by execution of a CLOSE statement, it may be connected again within the same program, 16either to the same unit or to a different unit, provided that the file still exists. 17At normal termination of execution of a program, all units that are connected are closed. Each unit 18is closed with status KEEP unless the file status prior to termination of execution was SCRATCH, in 19which case the unit is closed with status DELETE. NOTE 9.24 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 ) 20 21R909 close-spec is [ UNIT = ] file-unit-number 22 or IOSTAT = scalar-int-variable 23 or IOMSG = iomsg-variable 24 or ERR = label 25 or STATUS = scalar-default-char-expr 26C907 No specifier shall appear more than once in a given close-spec-list. 27C908 A file-unit-number shall be specified in a close-spec-list; if the optional characters UNIT= are 28 omitted, the file-unit-number shall be the first item in the close-spec-list. 222 2006/01/05 WORKING DRAFT J3/07-007 1C909 (R909) The label used in the ERR= specifier shall be the statement label of a branch target 2 statement that appears in the same scoping unit as the CLOSE statement. 3The scalar-default-char-expr has a limited list of character values. Any trailing blanks are ignored. The 4value specified is without regard to case. 5The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 6If an image executes a CLOSE statement, all images in the connect team of the unit specified shall execute 7a CLOSE statement for the unit with the same disposition. There is an implicit team synchronization 8associated with the execution of a CLOSE statement for a unit with a connect team that has more than one image (8.5.3). 9 NOTE 9.25 An example of a CLOSE statement is: CLOSE (10, STATUS = 'KEEP') NOTE 9.26 For more explanatory information on the CLOSE statement, see C.6.6. 109.4.6.1 STATUS= specifier in the CLOSE statement 11The scalar-default-char-expr shall evaluate to KEEP or DELETE. The STATUS= specifier determines 12the disposition of the file that is connected to the specified unit. KEEP shall not be specified for a file 13whose status prior to execution of a CLOSE statement is SCRATCH. If KEEP is specified for a file that 14exists, the file continues to exist after the execution of a CLOSE statement. If KEEP is specified for a 15file that does not exist, the file will not exist after the execution of a CLOSE statement. If DELETE is 16specified, the file will not exist after the execution of a CLOSE statement. If this specifier is omitted, the 17default value is KEEP, unless the file status prior to execution of the CLOSE statement is SCRATCH, 18in which case the default value is DELETE. 199.5 Data transfer statements 209.5.1 General 21The READ statement is the data transfer input statement. The WRITE statement and the 22PRINT statement are the data transfer output statements. 23R910 read-stmt is READ ( io-control-spec-list ) [ input-item-list ] or READ format [ , input-item-list ] 24 R911 write-stmt is WRITE ( io-control-spec-list ) [ output-item-list ] 25 R912 print-stmt is PRINT format [ , output-item-list ] 26 NOTE 9.27 Examples of data transfer statements are: READ (6, *) SIZE READ 10, A, B WRITE (6, 10) A, S, J PRINT 10, A, S, J 223 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.27 (cont.) 10 FORMAT (2E16.3, I5) 19.5.2 Control information list 29.5.2.1 Syntax 3A control information list is an io-control-spec-list. It governs data transfer. 4R913 io-control-spec is [ UNIT = ] io-unit 5 or [ FMT = ] format 6 or [ NML = ] namelist-group-name 7 or ADVANCE = scalar-default-char-expr 8 or ASYNCHRONOUS = scalar-char-initialization-expr 9 or BLANK = scalar-default-char-expr 10 or DECIMAL = scalar-default-char-expr 11 or DELIM = scalar-default-char-expr 12 or END = label 13 or EOR = label 14 or ERR = label 15 or ID = scalar-int-variable 16 or IOMSG = iomsg-variable 17 or IOSTAT = scalar-int-variable 18 or PAD = scalar-default-char-expr 19 or POS = scalar-int-expr 20 or REC = scalar-int-expr 21 or ROUND = scalar-default-char-expr 22 or SIGN = scalar-default-char-expr 23 or SIZE = scalar-int-variable 24C910 No specifier shall appear more than once in a given io-control-spec-list. 25C911 An io-unit shall be specified in an io-control-spec-list; if the optional characters UNIT= are 26 omitted, the io-unit shall be the first item in the io-control-spec-list. C912 (R913) A DELIM= or SIGN= specifier shall not appear in a read-stmt. 27 C913 (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt. 28 29C914 (R913) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 30 branch target statement that appears in the same scoping unit as the data transfer statement. C915 (R913) A namelist-group-name shall be the name of a namelist group. 31 32C916 (R913) A namelist-group-name shall not appear if an input-item-list or an output-item-list 33 appears in the data transfer statement. C917 (R913) An io-control-spec-list shall not contain both a format and a namelist-group-name. 34 35C918 (R913) If format appears without a preceding FMT=, it shall be the second item in the io- 36 control-spec-list and the first item shall be io-unit. 37C919 (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item 38 in the io-control-spec-list and the first item shall be io-unit. 39C920 (R913) If io-unit is not a file-unit-number, the io-control-spec-list shall not contain a REC= 224 2006/01/05 WORKING DRAFT J3/07-007 1 specifier or a POS= specifier. 2C921 (R913) If the REC= specifier appears, an END= specifier shall not appear, a namelist-group- 3 name shall not appear, and the format, if any, shall not be an asterisk. 4C922 (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- 5 put/output statement with explicit format specification (10.2) whose control information list 6 does not contain an internal-file-variable as the io-unit. C923 (R913) If an EOR= specifier appears, an ADVANCE= specifier also shall appear. 7 C924 (R913) If a SIZE= specifier appears, an ADVANCE= specifier also shall appear. 8 9C925 (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type 10 default character and shall have the value YES or NO. 11C926 (R913) An ASYNCHRONOUS= specifier with a value YES shall not appear unless io-unit is a 12 file-unit-number. 13C927 (R913) If an ID= specifier appears, an ASYNCHRONOUS= specifier with the value YES shall 14 also appear. C928 (R913) If a POS= specifier appears, the io-control-spec-list shall not contain a REC= specifier. 15 16C929 (R913) If a DECIMAL=, BLANK=, PAD=, SIGN=, or ROUND= specifier appears, a format 17 or namelist-group-name shall also appear. 18C930 (R913) If a DELIM= specifier appears, either format shall be an asterisk or namelist-group-name 19 shall appear. 20A SIZE= specifier may appear only in an input statement that contains an ADVANCE= specifier with 21the value NO. 22An EOR= specifier may appear only in an input statement that contains an ADVANCE= specifier with 23the value NO. 24If the data transfer statement contains a format or namelist-group-name, the statement is a formatted input/output statement; otherwise, it is an unformatted input/output statement. 25 26The ADVANCE=, ASYNCHRONOUS=, DECIMAL=, BLANK=, DELIM=, PAD=, SIGN=, and 27ROUND= specifiers have a limited list of character values. Any trailing blanks are ignored. The 28values specified are without regard to case. 29The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. NOTE 9.28 An example of a READ statement is: READ (IOSTAT = IOS, UNIT = 6, FMT = '(10F8.2)') A, B 309.5.2.2 Format specification in a data transfer statement 31The format specifier supplies a format specification or specifies list-directed formatting for a formatted input/output statement. 32 33R914 format is default-char-expr 34 or label 225 J3/07-007 WORKING DRAFT 2006/01/05 1 or * 2C931 (R914) The label shall be the label of a FORMAT statement that appears in the same scoping 3 unit as the statement containing the FMT= specifier. The default-char-expr shall evaluate to a valid format specification (10.2.1 and 10.2.2). 4 NOTE 9.29 A default-char-expr includes a character constant. 5If default-char-expr is an array, it is treated as if all of the elements of the array were specified in array 6element order and were concatenated. If format is *, the statement is a list-directed input/output statement. 7 NOTE 9.30 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. 89.5.2.3 NML= specifier in a data transfer statement 9The NML= specifier supplies the namelist-group-name (5.6). This name identifies a particular collection 10of data objects on which transfer is to be performed. If a namelist-group-name appears, the statement is a namelist input/output statement. 11 129.5.2.4 ADVANCE= specifier in a data transfer statement 13The scalar-default-char-expr shall evaluate to YES or NO. The ADVANCE= specifier determines wheth- 14er advancing input/output occurs for a nonchild input/output statement. If YES is specified for a 15nonchild input/output statement, advancing input/output occurs. If NO is specified, nonadvancing in- 16put/output occurs (9.2.3.1). If this specifier is omitted from a nonchild input/output statement that 17allows the specifier, the default value is YES. A formatted child input/output statement is a nonadvanc- ing input/output statement, and any ADVANCE= specifier is ignored. 18 199.5.2.5 ASYNCHRONOUS= specifier in a data transfer statement 20The ASYNCHRONOUS= specifier determines whether this input/output statement is synchronous or 21asynchronous. If YES is specified, the statement and the input/output operation are asynchronous. 22If NO is specified or if the specifier is omitted, the statement and the input/output operation are 23synchronous. 24Asynchronous input/output is permitted only for external files opened with an ASYNCHRONOUS= 25specifier with the value YES in the OPEN statement. NOTE 9.31 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. 226 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.31 (cont.) 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. 1The processor may perform an asynchronous data transfer operation asynchronously, but it is not re- 2quired to do so. For each external file, records and file storage units read or written by asynchronous 3data transfer statements are read, written, and processed in the same order as they would have been if 4the data transfer statements were synchronous. 5If a variable is used in an asynchronous data transfer statement as (1) an item in an input/output list, 6 (2) a group object in a namelist, or 7 (3) a SIZE= specifier 8 9the base object of the data-ref is implicitly given the ASYNCHRONOUS attribute in the scoping unit 10of the data transfer statement. This attribute may be confirmed by explicit declaration. 11When an asynchronous input/output statement is executed, the set of storage units specified by the 12item list or NML= specifier, plus the storage units specified by the SIZE= specifier, is defined to be the pending input/output storage sequence for the data transfer operation. 13 NOTE 9.32 A pending input/output storage sequence is not necessarily a contiguous set of storage units. 14A pending input/output storage sequence affector is a variable of which any part is associated with a storage unit in a pending input/output storage sequence. 15 169.5.2.6 BLANK= specifier in a data transfer statement 17The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier temporarily 18changes (9.4.1) the blank interpretation mode (10.8.6, 9.4.5.4) for the connection. If the specifier is 19omitted, the mode is not changed. 209.5.2.7 DECIMAL= specifier in a data transfer statement 21The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier temporar- 22ily changes (9.4.1) the decimal edit mode (10.6, 10.8.8, 9.4.5.5) for the connection. If the specifier is 23omitted, the mode is not changed. 249.5.2.8 DELIM= specifier in a data transfer statement 25The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 26ifier temporarily changes (9.4.1) the delimiter mode (10.10.4, 10.11.4.1, 9.4.5.6) for the connection. If 27the specifier is omitted, the mode is not changed. 289.5.2.9 ID= specifier in a data transfer statement 29Successful execution of an asynchronous data transfer statement containing an ID= specifier causes the 30variable specified in the ID= specifier to become defined with a processor determined value. This value 31is referred to as the identifier of the data transfer operation. It can be used in a subsequent WAIT or 32INQUIRE statement to identify the particular data transfer operation. 33If an error occurs during the execution of a data transfer statement containing an ID= specifier, the variable specified in the ID= specifier becomes undefined. 227 J3/07-007 WORKING DRAFT 2006/01/05 1A child data transfer statement shall not specify the ID= specifier. 29.5.2.10 PAD= specifier in a data transfer statement 3The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier temporarily changes 4(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 5changed. 69.5.2.11 POS= specifier in a data transfer statement 7The POS= specifier specifies the file position in file storage units. This specifier may appear in a data 8transfer statement only if the statement specifies a unit connected for stream access. A child data 9transfer statement shall not specify this specifier. 10A processor may prohibit the use of POS= with particular files that do not have the properties necessary 11to support random positioning. A processor may also prohibit positioning a particular file to any 12position prior to its current file position if the file does not have the properties necessary to support such 13positioning. NOTE 9.33 A unit that is connected to a device or data stream might not be positionable. 14If the file is connected for formatted stream access, the file position specified by POS= shall be equal to 15either 1 (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE 16statement for the file. 179.5.2.12 REC= specifier in a data transfer statement 18The REC= specifier specifies the number of the record that is to be read or written. This specifier 19may appear only in an input/output statement that specifies a unit connected for direct access; it 20shall not appear in a child data transfer statement. If the control information list contains a REC= 21specifier, the statement is a direct access input/output statement. A child data transfer statement 22is a direct access data transfer statement if the parent is a direct access data transfer statement. Any 23other data transfer statement is a sequential access input/output statement or a stream access 24input/output statement, depending on whether the file connection is for sequential access or stream 25access. 269.5.2.13 ROUND= specifier in a data transfer statement 27The scalar-default-char-expr shall evaluate to one of the values specified in 9.4.5.14. The ROUND= 28specifier temporarily changes (9.4.1) the I/O rounding mode (10.7.2.3.7, 9.4.5.14) for the connection. If 29the specifier is omitted, the mode is not changed. 309.5.2.14 SIGN= specifier in a data transfer statement 31The scalar-default-char-expr shall evaluate to PLUS, SUPPRESS, or PROCESSOR DEFINED. The 32SIGN= specifier temporarily changes (9.4.1) the sign mode (10.8.4, 9.4.5.15) for the connection. If the 33specifier is omitted, the mode is not changed. 349.5.2.15 SIZE= specifier in a data transfer statement 35When a synchronous nonadvancing input statement terminates, the variable specified in the SIZE= 36specifier becomes defined with the count of the characters transferred by data edit descriptors during execution of the current input statement. Blanks inserted as padding (9.5.4.4.2) are not counted. 37 228 2006/01/05 WORKING DRAFT J3/07-007 1For asynchronous nonadvancing input, the storage units specified in the SIZE= specifier become defined 2with the count of the characters transferred when the corresponding wait operation is executed. 9.5.3 Data transfer input/output list 3 4An input/output list specifies the entities whose values are transferred by a data transfer input/output 5statement. 6R915 input-item is variable 7 or io-implied-do 8R916 output-item is expr 9 or io-implied-do R917 io-implied-do is ( io-implied-do-object-list , io-implied-do-control ) 10 11R918 io-implied-do-object is input-item 12 or output-item 13R919 io-implied-do-control is do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] 14 C932 (R915) A variable that is an input-item shall not be a whole assumed-size array. 15 C933 (R915) A variable that is an input-item shall not be a procedure pointer. 16 C934 (R919) The do-variable shall be a named scalar variable of type integer. 17 18C935 (R918) In an input-item-list, an io-implied-do-object shall be an input-item. In an output-item- 19 list, an io-implied-do-object shall be an output-item. C936 (R916) An expression that is an output-item shall not have a value that is a procedure pointer. 20 21An input-item shall not appear as, nor be associated with, the do-variable of any io-implied-do that 22contains the input-item. NOTE 9.34 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. 23If an input item is a pointer, it shall be associated with a definable target and data are transferred from 24the file to the associated target. If an output item is a pointer, it shall be associated with a target and 25data are transferred from the target to the file. NOTE 9.35 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). 26If an input item or an output item is allocatable, it shall be allocated. 27A list item shall not be polymorphic unless it is processed by a user-defined derived-type input/output procedure (9.5.4.7). 28 29The do-variable of an io-implied-do that is in another io-implied-do shall not appear as, nor be associated 229 J3/07-007 WORKING DRAFT 2006/01/05 1with, the do-variable of the containing io-implied-do. 2The following rules describing whether to expand an input/output list item are re-applied to each 3expanded list item until none of the rules apply. 4 · If an array appears as an input/output list item, it is treated as if the elements, if any, were 5 specified in array element order (6.2.2.1). However, no element of that array may affect the value 6 of any expression in the input-item, nor may any element appear more than once in an input-item. NOTE 9.36 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 7 · If a list item of derived type in an unformatted input/output statement is not processed by a 8 user-defined derived-type input/output procedure (9.5.4.7), and if any subobject of that list item 9 would be processed by a user-defined derived-type input/output procedure, the list item is treated 10 as if all of the components of the object were specified in the list in component order (4.5.4.6); 11 those components shall be accessible in the scoping unit containing the input/output statement 12 and shall not be pointers or allocatable. 13 · An effective input/output list item of derived type in an unformatted input/output statement is 14 treated as a single value in a processor-dependent form unless the list item or a subobject thereof is processed by a user-defined derived-type input/output procedure (9.5.4.7). 15 NOTE 9.37 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, 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. 16 · If a list item of derived type in a formatted input/output statement is not processed by a user- 17 defined derived-type input/output procedure, that list item is treated as if all of the components 18 of the list item were specified in the list in component order; those components shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable. 19 20 · If a derived-type list item is not treated as a list of its individual components, that list item's 21 ultimate components shall not have the POINTER or ALLOCATABLE attribute unless that list item is processed by a user-defined derived-type input/output procedure. 22 23 · The scalar objects resulting when a data transfer statement's list items are expanded according 24 to the rules in this subclause for handling array and derived-type list items are called effective 230 2006/01/05 WORKING DRAFT J3/07-007 1 items. Zero-sized arrays and io-implied-dos with an iteration count of zero do not contribute to 2 the effective list items. A scalar character item of zero length is an effective list item. NOTE 9.38 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. 3 · For an io-implied-do, the loop initialization and execution are the same as for a DO construct (8.1.7.5). 4 NOTE 9.39 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 5 · An input/output list shall not contain an item of nondefault character type if the input/output 6 statement specifies an internal file of default character type. An input/output list shall not con- 7 tain an item of nondefault character type other than ISO 10646 or ASCII character type if the 8 input/output statement specifies an internal file of ISO 10646 character type. An input/output 9 list shall not contain a character item of any character type other than ASCII character type if the input/output statement specifies an internal file of ASCII character type. 10 9.5.4 Execution of a data transfer input/output statement 11 12Execution of a WRITE or PRINT statement for a file that does not exist creates the file unless an error 13condition occurs. 14The effect of executing a synchronous data transfer input/output statement shall be as if the following 15operations were performed in the order specified. (1) Determine the direction of data transfer. 16 (2) Identify the unit. 17 18 (3) Perform a wait operation for all pending input/output operations for the unit. If an error, 19 end-of-file, or end-of-record condition occurs during any of the wait operations, steps 4 20 through 8 are skipped for the current data transfer statement. (4) Establish the format if one is specified. 21 (5) If the statement is not a child data transfer statement (9.5.4.7), 22 (a) position the file prior to data transfer (9.2.3.2), and 23 (b) for formatted data transfer, set the left tab limit (10.8.1.1). 24 25 (6) Transfer data between the file and the entities specified by the input/output list (if any) or 26 namelist. (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. 27 28 (8) Position the file after data transfer (9.2.3.3) unless the statement is a child data transfer statement (9.5.4.7). 29 (9) Cause any variable specified in a SIZE= specifier to become defined. 30 31 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 32 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 33The effect of executing an asynchronous data transfer input/output statement shall be as if the following 34operations were performed in the order specified. 231 J3/07-007 WORKING DRAFT 2006/01/05 (1) Determine the direction of data transfer. 1 (2) Identify the unit. 2 (3) Establish the format if one is specified. 3 4 (4) Position the file prior to data transfer (9.2.3.2) and, for formatted data transfer, set the left tab limit (10.8.1.1). 5 6 (5) Establish the set of storage units identified by the input/output list. For a READ statement, 7 this might require some or all of the data in the file to be read if an input variable is used 8 as a scalar-int-expr in an io-implied-do-control in the input/output list, as a subscript, 9 substring-range, stride, or is otherwise referenced. 10 (6) Initiate an asynchronous data transfer between the file and the entities specified by the 11 input/output list (if any) or namelist. The asynchronous data transfer may complete (and 12 an error, end-of-file, or end-of-record condition may occur) during the execution of this data 13 transfer statement or during a later wait operation. 14 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. The con- 15 ditions may occur during the execution of this data transfer statement or during the corre- 16 sponding wait operation, but not both. 17 Also, any of these conditions that would have occurred during the corresponding wait oper- 18 ation for a previously pending data transfer operation that does not have an ID= specifier 19 may occur during the execution of this data transfer statement. 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). 20 (9) Cause any variable specified in a SIZE= specifier to become undefined. 21 22 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 23 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 24For an asynchronous data transfer statement, the data transfers may occur during execution of the 25statement, during execution of the corresponding wait operation, or anywhere between. The data transfer 26operation is considered to be pending until a corresponding wait operation is performed. 27For asynchronous output, a pending input/output storage sequence affector (9.5.2.5) shall not be rede- 28fined, become undefined, or have its pointer association status changed. 29For asynchronous input, a pending input/output storage sequence affector shall not be referenced, be- 30come defined, become undefined, become associated with a dummy argument that has the VALUE 31attribute, or have its pointer association status changed. 32Error, end-of-file, and end-of-record conditions in an asynchronous data transfer operation may occur 33during execution of either the data transfer statement or the corresponding wait operation. If an ID= 34specifier does not appear in the initiating data transfer statement, the conditions may occur during the 35execution of any subsequent data transfer or wait operation for the same unit. When a condition occurs 36for a previously executed asynchronous data transfer statement, a wait operation is performed for all 37pending data transfer operations on that unit. When a condition occurs during a subsequent statement, 38any actions specified by IOSTAT=, IOMSG=, ERR=, END=, and EOR= specifiers for that statement 39are taken. 232 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.40 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. 19.5.4.1 Direction of data transfer 2Execution of a READ statement causes values to be transferred from a file to the entities specified by 3the input list, if any, or specified within the file itself for namelist input. Execution of a WRITE or 4PRINT statement causes values to be transferred to a file from the entities specified by the output list 5and format specification, if any, or by the namelist-group-name for namelist output. 69.5.4.2 Identifying a unit 7A data transfer input/output statement that contains an input/output control list includes a UNIT= 8specifier that identifies an external or internal unit. A READ statement that does not contain an 9input/output control list specifies a particular processor-dependent unit, which is the same as the unit 10identified by * in a READ statement that contains an input/output control list. The PRINT statement 11specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE statement. Thus, each data transfer input/output statement identifies an external or internal unit. 12 13The unit identified by an unformatted data transfer statement shall be an external unit. 14The unit identified by a data transfer input/output statement shall be connected to a file when execution 15of the statement begins. NOTE 9.41 The unit may be preconnected. 169.5.4.3 Establishing a format 17If the input/output control list contains * as a format, list-directed formatting is established. If namelist- 18group-name appears, namelist formatting is established. If no format or namelist-group-name is speci- 19fied, unformatted data transfer is established. Otherwise, the format specified by format is established. 20For output to an internal file, a format specification that is in the file or is associated with the file shall 21not be specified. 229.5.4.4 Data transfer 23Data are transferred between the file and the entities specified by the input/output list or namelist. 24The list items are processed in the order of the input/output list for all data transfer input/output 25statements except namelist formatted data transfer statements. The list items for a namelist input 26statement are processed in the order of the entities specified within the input records. The list items 27for a namelist output statement are processed in the order in which the variables are specified in the 28namelist-group-object-list. Effective items are derived from the input/output list items as described in 299.5.3. 30All values needed to determine which entities are specified by an input/output list item are determined 31at the beginning of the processing of that item. 32All values are transmitted to or from the entities specified by a list item prior to the processing of any succeeding list item for all data transfer input/output statements. 233 J3/07-007 WORKING DRAFT 2006/01/05 1 NOTE 9.42 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. 2All values following the name= part of the namelist entity (10.11) within the input records are transmit- 3ted to the matching entity specified in the namelist-group-object-list prior to processing any succeeding 4entity within the input record for namelist input statements. If an entity is specified more than once 5within the input record during a namelist formatted data transfer input statement, the last occurrence 6of the entity specifies the value or values to be used for that entity. 7An input list item, or an entity associated with it, shall not contain any portion of an established format 8specification. If the input/output item is a pointer, data are transferred between the file and the associated target. 9 10If an internal file has been specified, an input/output list item shall not be in the file or associated with 11the file. NOTE 9.43 The file is a data object. 12A DO variable becomes defined and its iteration count established at the beginning of processing of the 13items that constitute the range of an io-implied-do. 14On output, every entity whose value is to be transferred shall be defined. 159.5.4.4.1 Unformatted data transfer 16During unformatted data transfer, data are transferred without editing between the file and the entities 17specified by the input/output list. If the file is connected for sequential or direct access, exactly one 18record is read or written. 19A value in the file is stored in a contiguous sequence of file storage units, beginning with the file storage 20unit immediately following the current file position. 21After each value is transferred, the current file position is moved to a point immediately after the last 22file storage unit of the value. 23On input from a file connected for sequential or direct access, the number of file storage units required 24by the input list shall be less than or equal to the number of file storage units in the record. 25On input, if the file storage units transferred do not contain a value with the same type and type 26parameters as the input list entity, then the resulting value of the entity is processor-dependent except 27in the following cases. 28 (1) A complex entity may correspond to two real values with the same kind type parameter as 29 the complex entity. 30 (2) A default character list entity of length n may correspond to n default characters stored in 31 the file, regardless of the length parameters of the entities that were written to these storage 32 units of the file. If the file is connected for stream input, the characters may have been 33 written by formatted stream output. 234 2006/01/05 WORKING DRAFT J3/07-007 1On output to a file connected for unformatted direct access, the output list shall not specify more values 2than can fit into the record. If the file is connected for direct access and the values specified by the 3output list do not fill the record, the remainder of the record is undefined. 4If the file is connected for unformatted sequential access, the record is created with a length sufficient 5to hold the values from the output list. This length shall be one of the set of allowed record lengths for 6the file and shall not exceed the value specified in the RECL= specifier, if any, of the OPEN statement 7that established the connection. If the file is not connected for unformatted input/output, unformatted data transfer is prohibited. 8 99.5.4.4.2 Formatted data transfer 10During formatted data transfer, data are transferred with editing between the file and the entities 11specified by the input/output list or by the namelist-group-name. Format control is initiated and editing 12is performed as described in Clause 10. 13The current record and possibly additional records are read or written. If the file is not connected for formatted input/output, formatted data transfer is prohibited. 14 15During advancing input when the pad mode has the value NO, the input list and format specification 16shall not require more characters from the record than the record contains. 17During advancing input when the pad mode has the value YES, blank characters are supplied by the 18processor if the input list and format specification require more characters from the record than the 19record contains. 20During nonadvancing input when the pad mode has the value NO, an end-of-record condition (9.10) 21occurs if the input list and format specification require more characters from the record than the record 22contains, and the record is complete (9.2.2.3). If the record is incomplete, an end-of-file condition occurs 23instead of an end-of-record condition. 24During nonadvancing input when the pad mode has the value YES, blank characters are supplied by 25the processor if an effective item and its corresponding data edit descriptors require more characters 26from the record than the record contains. If the record is incomplete, an end-of-file condition occurs; 27otherwise an end-of-record condition occurs. 28If the file is connected for direct access, the record number is increased by one as each succeeding record 29is read or written. 30On output, if the file is connected for direct access or is an internal file and the characters specified by 31the output list and format do not fill a record, blank characters are added to fill the record. 32On output, the output list and format specification shall not specify more characters for a record than 33have been specified by a RECL= specifier in the OPEN statement or the record length of an internal 34file. 359.5.4.5 List-directed formatting 36If list-directed formatting has been established, editing is performed as described in 10.10. 379.5.4.6 Namelist formatting 38If namelist formatting has been established, editing is performed as described in 10.11. 235 J3/07-007 WORKING DRAFT 2006/01/05 1Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist- 2group-object that is a pointer shall be associated with a target. If a namelist-group-object is polymorphic 3or has an ultimate component that is allocatable or a pointer, that object shall be processed by a user- defined derived-type input/output procedure (9.5.4.7). 4 9.5.4.7 User-defined derived-type input/output 5 6User-defined derived-type input/output procedures allow a program to override the default handling of derived-type objects and values in data transfer input/output statements described in 9.5.3. 7 8A user-defined derived-type input/output procedure is a procedure accessible by a dtio-generic-spec 9(12.4.3.2). A particular user-defined derived-type input/output procedure is selected as described in 109.5.4.7.3. 9.5.4.7.1 Executing user-defined derived-type input/output data transfers 11 12If a derived-type input/output procedure is selected as specified in 9.5.4.7.3, the processor shall call the se- 13lected user-defined derived-type input/output procedure for any appropriate data transfer input/output 14statements executed in that scoping unit. The user-defined derived-type input/output procedure controls 15the actual data transfer operations for the derived-type list item. 16A data transfer statement that includes a derived-type list item and that causes a user-defined derived- 17type input/output procedure to be invoked is called a parent data transfer statement. A data 18transfer statement that is executed while a parent data transfer statement is being processed and that 19specifies the unit passed into a user-defined derived-type input/output procedure is called a child data 20transfer statement. NOTE 9.44 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.45 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 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. 21A child data transfer statement is processed differently from a nonchild data transfer statement in the 22following ways. 23 · Executing a child data transfer statement does not position the file prior to data transfer. 24 · An unformatted child data transfer statement does not position the file after data transfer is 25 complete. · Any ADVANCE= specifier in a child input/output statement is ignored. 26 9.5.4.7.2 User-defined derived-type input/output procedures 27 236 2006/01/05 WORKING DRAFT J3/07-007 1For a particular derived type and a particular set of kind type parameter values, there are four possible 2sets of characteristics for user-defined derived-type input/output procedures; one each for formatted 3input, formatted output, unformatted input, and unformatted output. The user need not supply all four 4procedures. The procedures are specified to be used for derived-type input/output by interface blocks (12.4.3.2) or by generic bindings (4.5.5), with a dtio-generic-spec (R1208). 5 6In the four interfaces, which specify the characteristics of user-defined procedures for derived-type in- put/output, the following syntax term is used: 7 8R920 dtv-type-spec is TYPE( derived-type-spec ) or CLASS( derived-type-spec ) 9 10C937 (R920) If derived-type-spec specifies an extensible type, the CLASS keyword shall be used; 11 otherwise, the TYPE keyword shall be used. C938 (R920) All length type parameters of derived-type-spec shall be assumed. 12 13If the dtio-generic-spec is READ (FORMATTED), the characteristics shall be the same as those specified 14by the following interface: 15 SUBROUTINE my_read_routine_formatted & 16 (dtv, & 17 unit, & 18 iotype, v_list, & 19 iostat, iomsg) 20 ! the derived-type variable 21 dtv-type-spec , INTENT(INOUT) :: dtv 22 INTEGER, INTENT(IN) :: unit ! unit number 23 ! the edit descriptor string 24 CHARACTER (LEN=*), INTENT(IN) :: iotype 25 INTEGER, INTENT(IN) :: v_list(:) 26 INTEGER, INTENT(OUT) :: iostat 27 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 28 END 29If the dtio-generic-spec is READ (UNFORMATTED), the characteristics shall be the same as those 30specified by the following interface: 31 SUBROUTINE my_read_routine_unformatted & 32 (dtv, & 33 unit, & 34 iostat, iomsg) 35 ! the derived-type variable 36 dtv-type-spec , INTENT(INOUT) :: dtv 37 INTEGER, INTENT(IN) :: unit 38 INTEGER, INTENT(OUT) :: iostat 39 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 40 END 41If the dtio-generic-spec is WRITE (FORMATTED), the characteristics shall be the same as those spec- 42ified by the following interface: SUBROUTINE my_write_routine_formatted & 237 J3/07-007 WORKING DRAFT 2006/01/05 1 2 (dtv, & 3 unit, & 4 iotype, v_list, & 5 iostat, iomsg) 6 ! the derived-type value/variable 7 dtv-type-spec , INTENT(IN) :: dtv 8 INTEGER, INTENT(IN) :: unit 9 ! the edit descriptor string 10 CHARACTER (LEN=*), INTENT(IN) :: iotype 11 INTEGER, INTENT(IN) :: v_list(:) 12 INTEGER, INTENT(OUT) :: iostat 13 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 14 END 15If the dtio-generic-spec is WRITE (UNFORMATTED), the characteristics shall be the same as those 16specified by the following interface: 17 SUBROUTINE my_write_routine_unformatted & 18 (dtv, & 19 unit, & 20 iostat, iomsg) 21 ! the derived-type value/variable 22 dtv-type-spec , INTENT(IN) :: dtv 23 INTEGER, INTENT(IN) :: unit 24 INTEGER, INTENT(OUT) :: iostat 25 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 26 END 27The actual specific procedure names (the my_..._routine_... procedure names above) are not signifi- 28cant. In the discussion here and elsewhere, the dummy arguments in these interfaces are referred by the 29names given above; the names are, however, arbitrary. 30When a user-defined derived-type input/output procedure is invoked, the processor shall pass a unit 31argument that has a value as follows. 32 · If the parent data transfer statement uses a file-unit-number, the value of the unit argument shall 33 be that of the file-unit-number. 34 · If the parent data transfer statement is a WRITE statement with an asterisk unit or a PRINT 35 statement, the unit argument shall have the same value as the OUTPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.2). 36 37 · If the parent data transfer statement is a READ statement with an asterisk unit or a READ 38 statement without an io-control-spec-list, the unit argument shall have the same value as the INPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.2). 39 40 · Otherwise the parent data transfer statement must access an internal file, in which case the unit 41 argument shall have a processor-dependent negative value. 238 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.46 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.2). 1For formatted data transfer, the processor shall pass an iotype argument that has the value 2 · "LISTDIRECTED" if the parent data transfer statement specified list directed formatting, 3 · "NAMELIST" if the parent data transfer statement specified namelist formatting, or 4 · "DT" concatenated with the char-literal-constant, if any, of the edit descriptor, if the parent data 5 transfer statement contained a format specification and the list item's corresponding edit descriptor 6 was a DT edit descriptor. 7If the parent data transfer statement is a READ statement, the dtv dummy argument is argument 8associated with the effective list item that caused the user-defined derived-type input procedure to be invoked, as if the effective list item were an actual argument in this procedure reference (2.5.6). 9 10If the parent data transfer statement is a WRITE or PRINT statement, the processor shall provide the 11value of the effective list item in the dtv dummy argument. 12If the v-list of the edit descriptor appears in the parent data transfer statement, the processor shall 13provide the values from it in the v_list dummy argument, with the same number of elements in the 14same order as v-list. If there is no v-list in the edit descriptor or if the data transfer statement specifies 15list-directed or namelist formatting, the processor shall provide v_list as a zero-sized array. NOTE 9.47 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. 16The iostat argument is used to report whether an error, end-of-record, or end-of-file condition (9.10) 17occurs. If an error condition occurs, the user-defined derived-type input/output procedure shall assign 18a positive value to the iostat argument. Otherwise, if an end-of-file condition occurs, the user-defined 19derived-type input procedure shall assign the value of the named constant IOSTAT END (13.8.2.10) 20to the iostat argument. Otherwise, if an end-of-record condition occurs, the user-defined derived- 21type input procedure shall assign the value of the named constant IOSTAT EOR (13.8.2.11) to iostat. 22Otherwise, the user-defined derived-type input/output procedure shall assign the value zero to the 23iostat argument. 24If the user-defined derived-type input/output procedure returns a nonzero value for the iostat argument, 25the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure 26shall not change the value of the iomsg argument. NOTE 9.48 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. 27If the iostat argument of the user-defined derived-type input/output procedure has a nonzero value 28when that procedure returns, and the processor therefore terminates execution of the program as de- 239 J3/07-007 WORKING DRAFT 2006/01/05 1scribed in 9.10, the processor shall make the value of the iomsg argument available in a processor- 2dependent manner. 3When a parent READ statement is active, an input/output statement shall not read from any external 4unit other than the one specified by the dummy argument unit and shall not perform output to any 5external unit. 6When a parent WRITE or PRINT statement is active, an input/output statement shall not perform 7output to any external unit other than the one specified by the dummy argument unit and shall not 8read from any external unit. 9When a parent data transfer statement is active, a data transfer statement that specifies an internal file 10is permitted. 11OPEN, CLOSE, BACKSPACE, ENDFILE, and REWIND statements shall not be executed while a 12parent data transfer statement is active. 13A user-defined derived-type input/output procedure may use a FORMAT with a DT edit descriptor for 14handling a component of the derived type that is itself of a derived type. A child data transfer statement that is a list directed or namelist input/output statement may contain a list item of derived type. 15 16Because a child data transfer statement does not position the file prior to data transfer, the child data 17transfer statement starts transferring data from where the file was positioned by the parent data transfer 18statement's most recently processed effective list item or record positioning edit descriptor. This is not 19necessarily at the beginning of a record. 20A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement 21shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. 22 NOTE 9.49 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. 23Neither a parent nor child data transfer statement shall be asynchronous. 24A user-defined derived-type input/output procedure, and any procedures invoked therefrom, shall not 25define, nor cause to become undefined, any storage location referenced by any input/output list item, 26the corresponding format, or any specifier in any active parent data transfer statement, except through 27the dtv argument. NOTE 9.50 A child data transfer statement shall not specify the ID=, POS=, or REC= specifiers in an input/output control list. NOTE 9.51 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 240 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.51 (cont.) 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 ! respectively END PROGRAM NOTE 9.52 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 241 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.52 (cont.) 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 2A suitable generic interface for user-defined derived-type input/output of an effective item is one that 3has a dtio-generic-spec that is appropriate to the direction (read or write) and form (formatted or 4unformatted) of the data transfer as specified in 9.5.4.7, and has a specific interface whose dtv argument 5is compatible with the effective item according to the rules for argument association in 12.5.2.5. 6When an effective item (9.5.3) that is of derived-type is encountered during a data transfer, user-defined derived-type input/output occurs if both of the following conditions are true. 7 8 (1) The circumstances of the input/output are such that user-defined derived-type input/output 9 is permitted; that is, either 10 (a) the transfer was initiated by a list-directed, namelist, or unformatted input/output 11 statement, or 12 (b) a format specification is supplied for the input/output statement, and the edit de- 13 scriptor corresponding to the effective item is a DT edit descriptor. (2) A suitable user-defined derived-type input/output procedure is available; that is, either 14 15 (a) the declared type of the effective item has a suitable generic type-bound procedure, 16 or (b) a suitable generic interface is accessible. 17 18If (2a) is true, the procedure referenced is determined as for explicit type-bound procedure references 19(12.5); that is, the binding with the appropriate specific interface is located in the declared type of the 20effective item, and the corresponding binding in the dynamic type of the effective item is selected. 21If (2a) is false and (2b) is true, the reference is to the procedure identified by the appropriate specific 242 2006/01/05 WORKING DRAFT J3/07-007 1interface in the interface block. This reference shall not be to a dummy procedure that is not present, 2or to a disassociated procedure pointer. 39.5.5 Termination of data transfer statements Termination of an input/output data transfer statement occurs when 4 5 (1) format processing encounters a data edit descriptor and there are no remaining elements in 6 the input-item-list or output-item-list, (2) unformatted or list-directed data transfer exhausts the input-item-list or output-item-list, 7 (3) namelist output exhausts the namelist-group-object-list, 8 (4) an error condition occurs, 9 (5) an end-of-file condition occurs, 10 11 (6) a slash (/) is encountered as a value separator (10.10, 10.11) in the record being read during 12 list-directed or namelist input, or 13 (7) an end-of-record condition occurs during execution of a nonadvancing input statement (9.10). 14 9.6 Waiting on pending data transfer 15 9.6.1 Wait operation 16 17Execution of an asynchronous data transfer statement in which neither an error, end-of-record, nor end- 18of-file condition occurs initiates a pending data transfer operation. There may be multiple pending data 19transfer operations for the same or multiple units simultaneously. A pending data transfer operation 20remains pending until a corresponding wait operation is performed. A wait operation may be performed 21by a WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning statement. 22A wait operation completes the processing of a pending data transfer operation. Each wait operation 23completes only a single data transfer operation, although a single statement may perform multiple wait 24operations. 25If the actual data transfer is not yet complete, the wait operation first waits for its completion. If the 26data transfer operation is an input operation that completed without error, the storage units of the input/output storage sequence then become defined with the values as described in 9.5.2.15 and 9.5.4.4. 27 28If any error, end-of-file, or end-of-record conditions occur, the applicable actions specified by the IO- 29STAT=, IOMSG=, ERR=, END=, and EOR= specifiers of the statement that performs the wait oper- 30ation are taken. 31If an error or end-of-file condition occurs during a wait operation for a unit, the processor performs a 32wait operation for all pending data transfer operations for that unit. NOTE 9.53 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. 33After completion of the wait operation, the data transfer operation and its input/output storage sequence 34are no longer considered to be pending. 243 J3/07-007 WORKING DRAFT 2006/01/05 19.6.2 WAIT statement 2A WAIT statement performs a wait operation for specified pending asynchronous data transfer oper- 3ations. NOTE 9.54 The CLOSE, INQUIRE, and file positioning statements may also perform wait operations. R921 wait-stmt is WAIT (wait-spec-list) 4 5R922 wait-spec is [ UNIT = ] file-unit-number 6 or END = label 7 or EOR = label 8 or ERR = label 9 or ID = scalar-int-expr 10 or IOMSG = iomsg-variable 11 or IOSTAT = scalar-int-variable 12C939 No specifier shall appear more than once in a given wait-spec-list. 13C940 A file-unit-number shall be specified in a wait-spec-list; if the optional characters UNIT= are 14 omitted, the file-unit-number shall be the first item in the wait-spec-list. 15C941 (R922) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 16 branch target statement that appears in the same scoping unit as the WAIT statement. 17The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 18The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 19operation for the specified unit. If the ID= specifier appears, a wait operation for the specified data 20transfer operation is performed. If the ID= specifier is omitted, wait operations for all pending data 21transfers for the specified unit are performed. 22Execution of a WAIT statement specifying a unit that does not exist, has no file connected to it, or is 23not open for asynchronous input/output is permitted, provided that the WAIT statement has no ID= 24specifier; such a WAIT statement does not cause an error or end-of-file condition to occur. NOTE 9.55 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 25 9.7.1 Syntax 26 27R923 backspace-stmt is BACKSPACE file-unit-number or BACKSPACE ( position-spec-list ) 28 29R924 endfile-stmt is ENDFILE file-unit-number or ENDFILE ( position-spec-list ) 30 31R925 rewind-stmt is REWIND file-unit-number or REWIND ( position-spec-list ) 32 33A unit that is connected for direct access shall not be referred to by a BACKSPACE, ENDFILE, or 244 2006/01/05 WORKING DRAFT J3/07-007 1REWIND statement. A unit that is connected for unformatted stream access shall not be referred to 2by a BACKSPACE statement. A unit that is connected with an ACTION= specifier having the value 3READ shall not be referred to by an ENDFILE statement. A unit whose connect team has more than 4one image shall not be referred to by a BACKSPACE, ENDFILE, or REWIND statement. 5R926 position-spec is [ UNIT = ] file-unit-number 6 or IOMSG = iomsg-variable 7 or IOSTAT = scalar-int-variable 8 or ERR = label 9C942 No specifier shall appear more than once in a given position-spec-list. 10C943 A file-unit-number shall be specified in a position-spec-list; if the optional characters UNIT= 11 are omitted, the file-unit-number shall be the first item in the position-spec-list. 12C944 (R926) The label in the ERR= specifier shall be the statement label of a branch target statement 13 that appears in the same scoping unit as the file positioning statement. 14The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 15Execution of a file positioning statement performs a wait operation for all pending asynchronous data 16transfer operations for the specified unit. 179.7.2 BACKSPACE statement 18Execution of a BACKSPACE statement causes the file connected to the specified unit to be positioned 19before the current record if there is a current record, or before the preceding record if there is no current 20record. If the file is at its initial point, the position of the file is not changed. NOTE 9.56 If the preceding record is an endfile record, the file is positioned before the endfile record. 21If a BACKSPACE statement causes the implicit writing of an endfile record, the file is positioned before 22the record that precedes the endfile record. 23Backspacing a file that is connected but does not exist is prohibited. 24Backspacing over records written using list-directed or namelist formatting is prohibited. NOTE 9.57 An example of a BACKSPACE statement is: BACKSPACE (10, IOSTAT = N) 259.7.3 ENDFILE statement 26Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record 27as the next record of the file. The file is then positioned after the endfile record, which becomes the last 28record of the file. If the file also may be connected for direct access, only those records before the endfile 29record are considered to have been written. Thus, only those records may be read during subsequent 30direct access connections to the file. 31After execution of an ENDFILE statement for a file connected for sequential access, a BACKSPACE 32or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. 33 245 J3/07-007 WORKING DRAFT 2006/01/05 1Execution of an ENDFILE statement for a file connected for stream access causes the terminal point of 2the file to become equal to the current file position. Only file storage units before the current position are 3considered to have been written; thus only those file storage units may be subsequently read. Subsequent 4stream output statements may be used to write further data to the file. 5Execution of an ENDFILE statement for a file that is connected but does not exist creates the file; if 6the file is connected for sequential access, it is created prior to writing the endfile record. NOTE 9.58 An example of an ENDFILE statement is: ENDFILE K 79.7.4 REWIND statement 8Execution of a REWIND statement causes the specified file to be positioned at its initial point. NOTE 9.59 If the file is already positioned at its initial point, execution of this statement has no effect on the position of the file. 9Execution of a REWIND statement for a file that is connected but does not exist is permitted and has 10no effect on any file. NOTE 9.60 An example of a REWIND statement is: REWIND 10 119.8 FLUSH statement 12R927 flush-stmt is FLUSH file-unit-number or FLUSH ( flush-spec-list ) 13 14R928 flush-spec is [UNIT =] file-unit-number 15 or IOSTAT = scalar-int-variable 16 or IOMSG = iomsg-variable 17 or ERR = label 18C945 No specifier shall appear more than once in a given flush-spec-list. 19C946 A file-unit-number shall be specified in a flush-spec-list; if the optional characters UNIT= are 20 omitted from the unit specifier, the file-unit-number shall be the first item in the flush-spec-list. 21C947 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 22 that appears in the same scoping unit as the FLUSH statement. 23The IOSTAT=, IOMSG= and ERR= specifiers are described in 9.10. The IOSTAT= variable shall 24be set to a processor-dependent positive value if an error occurs, to zero if the processor-dependent 25flush operation was successful, or to a processor-dependent negative value if the flush operation is not 26supported for the unit specified. 27Execution of a FLUSH statement causes data written to an external unit to be made available to 246 2006/01/05 WORKING DRAFT J3/07-007 1other images of the unit's connect team which execute a FLUSH statement in a subsequent segment for 2that unit. It also causes data written to an external file to be available to other processes, or causes 3data placed in an external file by means other than Fortran to be available to a READ statement. The 4action is processor dependent. J3 internal note Unresolved Technical Issue 106 FLUSH action contradiction. The last sentence contradicts the entire rest of the paragraph it's in. Well, what is it ­ is the action processor-defined, or does it cause data written to an external file to be available to other processors and cause data placed in an external file by means other than Fortran to be available to a READ statement? Hmm, the first half sounds like something outside the scope of the standard anyway, so it could probably be more cautiously worded. 5Execution of a FLUSH statement for a file that is connected but does not exist is permitted and has no 6effect on any file. A FLUSH statement has no effect on file position. 7Execution of a FLUSH statement performs a wait operation for all pending asynchronous data transfer 8operations for the specified unit. NOTE 9.61 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.62 An example of a FLUSH statement is: FLUSH( 10, IOSTAT=N) 9.9 File inquiry statement 9 109.9.1 Forms of the INQUIRE statement 11The INQUIRE statement may be used to inquire about properties of a particular named file or of 12the connection to a particular unit. There are three forms of the INQUIRE statement: inquire by file, 13which uses the FILE= specifier, inquire by unit, which uses the UNIT= specifier, and inquire by 14output list, which uses only the IOLENGTH= specifier. All specifier value assignments are performed 15according to the rules for assignment statements. 16For inquiry by unit, the unit specified need not exist or be connected to a file. If it is connected to a 17file, the inquiry is being made about the connection and about the file connected. 18An INQUIRE statement may be executed before, while, or after a file is connected to a unit. All values 19assigned by an INQUIRE statement are those that are current at the time the statement is executed. 20R929 inquire-stmt is INQUIRE ( inquire-spec-list ) 21 or INQUIRE ( IOLENGTH = scalar-int-variable ) 22 output-item-list 247 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.63 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 1 2Unless constrained, the following inquiry specifiers may be used in either of the inquire by file or inquire 3by unit forms of the INQUIRE statement: 4R930 inquire-spec is [ UNIT = ] file-unit-number 5 or FILE = file-name-expr 6 or ACCESS = scalar-default-char-variable 7 or ACTION = scalar-default-char-variable 8 or ASYNCHRONOUS = scalar-default-char-variable 9 or BLANK = scalar-default-char-variable 10 or DECIMAL = scalar-default-char-variable 11 or DELIM = scalar-default-char-variable 12 or DIRECT = scalar-default-char-variable 13 or ENCODING = scalar-default-char-variable 14 or ERR = label 15 or EXIST = scalar-default-logical-variable 16 or FORM = scalar-default-char-variable 17 or FORMATTED = scalar-default-char-variable 18 or ID = scalar-int-expr 19 or IOMSG = iomsg-variable 20 or IOSTAT = scalar-int-variable 21 or NAME = scalar-default-char-variable 22 or NAMED = scalar-default-logical-variable 23 or NEXTREC = scalar-int-variable 24 or NUMBER = scalar-int-variable 25 or OPENED = scalar-default-logical-variable 26 or PAD = scalar-default-char-variable 27 or PENDING = scalar-default-logical-variable 28 or POS = scalar-int-variable 29 or POSITION = scalar-default-char-variable 30 or READ = scalar-default-char-variable 31 or READWRITE = scalar-default-char-variable 32 or RECL = scalar-int-variable 33 or ROUND = scalar-default-char-variable 34 or SEQUENTIAL = scalar-default-char-variable 35 or SIGN = scalar-default-char-variable 36 or SIZE = scalar-int-variable 37 or STREAM = scalar-default-char-variable 38 or TEAM = image-team 39 or UNFORMATTED = scalar-default-char-variable 40 or WRITE = scalar-default-char-variable 41C948 No specifier shall appear more than once in a given inquire-spec-list. 42C949 An inquire-spec-list shall contain one FILE= specifier or one UNIT= specifier, but not both. 248 2006/01/05 WORKING DRAFT J3/07-007 1C950 In the inquire by unit form of the INQUIRE statement, if the optional characters UNIT= are 2 omitted, the file-unit-number shall be the first item in the inquire-spec-list. 3C951 If an ID= specifier appears in an inquire-spec-list, a PENDING= specifier shall also appear. 4C952 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 5 that appears in the same scoping unit as the INQUIRE statement. If file-unit-number identifies an internal unit (9.5.4.7.2), an error condition occurs. 6 7When a returned value of a specifier other than the NAME= specifier is of type character, the value 8returned is in upper case. 9If an error condition occurs during execution of an INQUIRE statement, all of the inquiry specifier variables become undefined, except for variables in the IOSTAT= and IOMSG= specifiers (if any). 10 11The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 129.9.2.1 FILE= specifier in the INQUIRE statement 13The value of the file-name-expr in the FILE= specifier specifies the name of the file being inquired about. 14The named file need not exist or be connected to a unit. The value of the file-name-expr shall be of a 15form acceptable to the processor as a file name. Any trailing blanks are ignored. The interpretation of 16case is processor dependent. 179.9.2.2 ACCESS= specifier in the INQUIRE statement 18The scalar-default-char-variable in the ACCESS= specifier is assigned the value SEQUENTIAL if the 19connection is for sequential access, DIRECT if the connection is for direct access, or STREAM if the 20connection is for stream access. If there is no connection, it is assigned the value UNDEFINED. 219.9.2.3 ACTION= specifier in the INQUIRE statement 22The scalar-default-char-variable in the ACTION= specifier is assigned the value READ if the connection 23is for input only, WRITE if the connection is for output only, and READWRITE if the connection is for 24both input and output. If there is no connection, the scalar-default-char-variable is assigned the value 25UNDEFINED. 269.9.2.4 ASYNCHRONOUS= specifier in the INQUIRE statement 27The scalar-default-char-variable in the ASYNCHRONOUS= specifier is assigned the value YES if the 28connection allows asynchronous input/output; it is assigned the value NO if the connection does not 29allow asynchronous input/output. If there is no connection, the scalar-default-char-variable is assigned 30the value UNDEFINED. 319.9.2.5 BLANK= specifier in the INQUIRE statement 32The scalar-default-char-variable in the BLANK= specifier is assigned the value ZERO or NULL, corre- 33sponding to the blank interpretation mode in effect for a connection for formatted input/output. If there 34is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 35is assigned the value UNDEFINED. 369.9.2.6 DECIMAL= specifier in the INQUIRE statement 37The scalar-default-char-variable in the DECIMAL= specifier is assigned the value COMMA or POINT, 38corresponding to the decimal edit mode in effect for a connection for formatted input/output. If there 249 J3/07-007 WORKING DRAFT 2006/01/05 1is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 2is assigned the value UNDEFINED. 39.9.2.7 DELIM= specifier in the INQUIRE statement 4The scalar-default-char-variable in the DELIM= specifier is assigned the value APOSTROPHE, QUOTE, 5or NONE, corresponding to the delimiter mode in effect for a connection for formatted input/output. 6If there is no connection or if the connection is not for formatted input/output, the scalar-default-char- 7variable is assigned the value UNDEFINED. 89.9.2.8 DIRECT= specifier in the INQUIRE statement 9The scalar-default-char-variable in the DIRECT= specifier is assigned the value YES if DIRECT is 10included in the set of allowed access methods for the file, NO if DIRECT is not included in the set of 11allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 12DIRECT is included in the set of allowed access methods for the file. 139.9.2.9 ENCODING= specifier in the INQUIRE statement 14The scalar-default-char-variable in the ENCODING= specifier is assigned the value UTF-8 if the con- 15nection is for formatted input/output with an encoding form of UTF-8, and is assigned the value UN- 16DEFINED if the connection is for unformatted input/output. If there is no connection, it is assigned 17the value UTF-8 if the processor is able to determine that the encoding form of the file is UTF-8; if 18the processor is unable to determine the encoding form of the file, the variable is assigned the value 19UNKNOWN. NOTE 9.64 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). 209.9.2.10 EXIST= specifier in the INQUIRE statement 21Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the EXIST= 22specifier to be assigned the value true if there exists a file with the specified name; otherwise, false is 23assigned. Execution of an INQUIRE by unit statement causes true to be assigned if the specified unit 24exists; otherwise, false is assigned. 259.9.2.11 FORM= specifier in the INQUIRE statement 26The scalar-default-char-variable in the FORM= specifier is assigned the value FORMATTED if the 27connection is for formatted input/output, and is assigned the value UNFORMATTED if the connection is for unformatted input/output. If there is no connection, it is assigned the value UNDEFINED. 28 299.9.2.12 FORMATTED= specifier in the INQUIRE statement 30The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FOR- 31MATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in 32the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 33FORMATTED is included in the set of allowed forms for the file. 349.9.2.13 ID= specifier in the INQUIRE statement 35The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer operation for the specified unit. This specifier interacts with the PENDING= specifier (9.9.2.20). 36 250 2006/01/05 WORKING DRAFT J3/07-007 19.9.2.14 NAME= specifier in the INQUIRE statement 2The scalar-default-char-variable in the NAME= specifier is assigned the value of the name of the file if 3the file has a name; otherwise, it becomes undefined. NOTE 9.65 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. 4The case of the characters assigned to scalar-default-char-variable is processor dependent. 59.9.2.15 NAMED= specifier in the INQUIRE statement 6The scalar-default-logical-variable in the NAMED= specifier is assigned the value true if the file has a 7name; otherwise, it is assigned the value false. 89.9.2.16 NEXTREC= specifier in the INQUIRE statement 9The scalar-int-variable in the NEXTREC= specifier is assigned the value n + 1, where n is the record 10number of the last record read from or written to the connection for direct access by the executing 11image. If there is a connection but no records have been read or written since the connection, the scalar- 12int-variable is assigned the value 1. If there is no connection, the connection is not for direct access, 13or the position is indeterminate because of a previous error condition, the scalar-int-variable becomes 14undefined. If there are pending data transfer operations for the specified unit, the value assigned is 15computed as if all the pending data transfers had already completed. 169.9.2.17 NUMBER= specifier in the INQUIRE statement 17The scalar-int-variable in the NUMBER= specifier is assigned the value of the external unit number of 18the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. 199.9.2.18 OPENED= specifier in the INQUIRE statement 20Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the OPENED= 21specifier to be assigned the value true if the file specified is connected to a unit; otherwise, false is 22assigned. Execution of an INQUIRE by unit statement causes the scalar-default-logical-variable to be 23assigned the value true if the specified unit is connected to a file; otherwise, false is assigned. 249.9.2.19 PAD= specifier in the INQUIRE statement 25The scalar-default-char-variable in the PAD= specifier is assigned the value YES or NO, corresponding 26to the pad mode in effect for a connection for formatted input/output. If there is no connection or if 27the connection is not for formatted input/output, the scalar-default-char-variable is assigned the value 28UNDEFINED. 299.9.2.20 PENDING= specifier in the INQUIRE statement 30The PENDING= specifier is used to determine whether previously pending asynchronous data transfers 31are complete. A data transfer operation is previously pending if it is pending at the beginning of 32execution of the INQUIRE statement. 251 J3/07-007 WORKING DRAFT 2006/01/05 1If an ID= specifier appears and the specified data transfer operation is complete, then the variable 2specified in the PENDING= specifier is assigned the value false and the INQUIRE statement performs 3the wait operation for the specified data transfer. 4If the ID= specifier is omitted and all previously pending data transfer operations for the specified unit 5are complete, then the variable specified in the PENDING= specifier is assigned the value false and the 6INQUIRE statement performs wait operations for all previously pending data transfers for the specified 7unit. 8In all other cases, the variable specified in the PENDING= specifier is assigned the value true and no 9wait operations are performed; in this case the previously pending data transfers remain pending after 10the execution of the INQUIRE statement. NOTE 9.66 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. 119.9.2.21 POS= specifier in the INQUIRE statement 12The scalar-int-variable in the POS= specifier is assigned the number of the file storage unit immediately 13following the current position of a file connected for stream access. If the file is positioned at its terminal 14position, the variable is assigned a value one greater than the number of the highest-numbered file storage 15unit in the file. If the file is not connected for stream access or if the position of the file is indeterminate 16because of previous error conditions, the variable becomes undefined. 179.9.2.22 POSITION= specifier in the INQUIRE statement 18The scalar-default-char-variable in the POSITION= specifier is assigned the value REWIND if the 19connection was opened for positioning at its initial point, APPEND if the connection was opened for 20positioning before its endfile record or at its terminal point, and ASIS if the connection was opened 21without changing its position. If there is no connection or if the file is connected for direct access, the 22scalar-default-char-variable is assigned the value UNDEFINED. If the file has been repositioned since 23the connection, the scalar-default-char-variable is assigned a processor-dependent value, which shall not 24be REWIND unless the file is positioned at its initial point and shall not be APPEND unless the file is 25positioned so that its endfile record is the next record or at its terminal point if it has no endfile record. 269.9.2.23 READ= specifier in the INQUIRE statement 27The scalar-default-char-variable in the READ= specifier is assigned the value YES if READ is included 28in the set of allowed actions for the file, NO if READ is not included in the set of allowed actions for 29the file, and UNKNOWN if the processor is unable to determine whether READ is included in the set 30of allowed actions for the file. 319.9.2.24 READWRITE= specifier in the INQUIRE statement 252 2006/01/05 WORKING DRAFT J3/07-007 1The scalar-default-char-variable in the READWRITE= specifier is assigned the value YES if READ- 2WRITE is included in the set of allowed actions for the file, NO if READWRITE is not included in 3the set of allowed actions for the file, and UNKNOWN if the processor is unable to determine whether 4READWRITE is included in the set of allowed actions for the file. 59.9.2.25 RECL= specifier in the INQUIRE statement 6The scalar-int-variable in the RECL= specifier is assigned the value of the record length of a connection 7for direct access, or the value of the maximum record length of a connection for sequential access. If 8the connection is for formatted input/output, the length is the number of characters for all records that 9contain only characters of type default character. If the connection is for unformatted input/output, 10the length is measured in file storage units. If there is no connection, or if the connection is for stream 11access, the scalar-int-variable becomes undefined. 129.9.2.26 ROUND= specifier in the INQUIRE statement 13The scalar-default-char-variable in the ROUND= specifier is assigned the value UP, DOWN, ZERO, 14NEAREST, COMPATIBLE, or PROCESSOR DEFINED, corresponding to the I/O rounding mode in 15effect for a connection for formatted input/output. If there is no connection or if the connection is not 16for formatted input/output, the scalar-default-char-variable is assigned the value UNDEFINED. The 17processor shall return the value PROCESSOR DEFINED only if the I/O rounding mode currently in 18effect behaves differently than the UP, DOWN, ZERO, NEAREST, and COMPATIBLE modes. 199.9.2.27 SEQUENTIAL= specifier in the INQUIRE statement 20The scalar-default-char-variable in the SEQUENTIAL= specifier is assigned the value YES if SEQUEN- 21TIAL is included in the set of allowed access methods for the file, NO if SEQUENTIAL is not included 22in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine 23whether SEQUENTIAL is included in the set of allowed access methods for the file. 249.9.2.28 SIGN= specifier in the INQUIRE statement 25The scalar-default-char-variable in the SIGN= specifier is assigned the value PLUS, SUPPRESS, or 26PROCESSOR DEFINED, corresponding to the sign mode in effect for a connection for formatted in- 27put/output. If there is no connection, or if the connection is not for formatted input/output, the 28scalar-default-char-variable is assigned the value UNDEFINED. 299.9.2.29 SIZE= specifier in the INQUIRE statement 30The scalar-int-variable in the SIZE= specifier is assigned the size of the file in file storage units. If the 31file size cannot be determined, the variable is assigned the value -1. 32For a file that may be connected for stream access, the file size is the number of the highest-numbered 33file storage unit in the file. 34For a file that may be connected for sequential or direct access, the file size may be different from the 35number of storage units implied by the data in the records; the exact relationship is processor-dependent. 369.9.2.30 STREAM= specifier in the INQUIRE statement 37The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is 38included in the set of allowed access methods for the file, NO if STREAM is not included in the set of 39allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 40STREAM is included in the set of allowed access methods for the file. 253 J3/07-007 WORKING DRAFT 2006/01/05 19.9.2.31 TEAM= specifier in the INQUIRE statement 2The image-team in the TEAM= specifier is assigned the value of the connect team if the file or unit is 3connected; otherwise it is assigned a value that identifies an empty image set. NOTE 9.67 The indices of the images in a team may be obtained by using the intrinsic function TEAM - IMAGES (13.7.172). 49.9.2.32 UNFORMATTED= specifier in the INQUIRE statement 5The scalar-default-char-variable in the UNFORMATTED= specifier is assigned the value YES if UN- 6FORMATTED is included in the set of allowed forms for the file, NO if UNFORMATTED is not included 7in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 8UNFORMATTED is included in the set of allowed forms for the file. 99.9.2.33 WRITE= specifier in the INQUIRE statement 10The scalar-default-char-variable in the WRITE= specifier is assigned the value YES if WRITE is included 11in the set of allowed actions for the file, NO if WRITE is not included in the set of allowed actions for 12the file, and UNKNOWN if the processor is unable to determine whether WRITE is included in the set 13of allowed actions for the file. 9.9.3 Inquire by output list 14 15The scalar-int-variable in the IOLENGTH= specifier is assigned the processor-dependent number of file 16storage units that would be required to store the data of the output list in an unformatted file. The 17value shall be suitable as a RECL= specifier in an OPEN statement that connects a file for unformatted direct access when there are input/output statements with the same input/output list. 18 19The output list in an INQUIRE statement shall not contain any derived-type list items that require 20a user-defined derived-type input/output procedure as described in subclause 9.5.3. If a derived-type 21list item appears in the output list, the value returned for the IOLENGTH= specifier assumes that no user-defined derived-type input/output procedure will be invoked. 22 9.10 Error, end-of-record, and end-of-file conditions 23 The set of input/output error conditions is processor dependent. 24 25An end-of-record condition occurs when a nonadvancing input statement attempts to transfer data 26from a position beyond the end of the current record, unless the file is a stream file and the current record is at the end of the file (an end-of-file condition occurs instead). 27 28An end-of-file condition occurs when (1) an endfile record is encountered during the reading of a file connected for sequential access, 29 (2) an attempt is made to read a record beyond the end of an internal file, or 30 (3) an attempt is made to read beyond the end of a stream file. 31 32An end-of-file condition may occur at the beginning of execution of an input statement. An end-of-file 33condition also may occur during execution of a formatted input statement when more than one record 34is required by the interaction of the input list and the format. An end-of-file condition also may occur 35during execution of a stream input statement. 254 2006/01/05 WORKING DRAFT J3/07-007 9.10.1 Error conditions and the ERR= specifier 1 2If an error condition occurs during execution of an input/output statement, the position of the file 3becomes indeterminate. 4If an error condition occurs during execution of an input/output statement that contains neither an 5ERR= nor IOSTAT= specifier, execution of the program is terminated. If an error condition occurs 6during execution of an input/output statement that contains either an ERR= specifier or an IOSTAT= 7specifier then (1) processing of the input/output list, if any, terminates, 8 9 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 10 do-variables in the statement that initiated the transfer become undefined, 11 (3) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 12 defined as specified in 9.10.4, (4) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 13 14 (5) if the statement is a READ statement and it contains a SIZE= specifier, the scalar-int- 15 variable in the SIZE= specifier becomes defined as specified in 9.5.2.15, 16 (6) if the statement is a READ statement or the error condition occurs in a wait operation for 17 a transfer initiated by a READ statement, all input items or namelist group objects in the 18 statement that initiated the transfer become undefined, and 19 (7) if an ERR= specifier appears, a branch to the statement labeled by the label in the ERR= 20 specifier occurs. 9.10.2 End-of-file condition and the END= specifier 21 22If an end-of-file condition occurs during execution of an input/output statement that contains neither 23an END= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of-file 24condition occurs during execution of an input/output statement that contains either an END= specifier 25or an IOSTAT= specifier, and an error condition does not occur then (1) processing of the input list, if any, terminates, 26 27 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 28 do-variables in the statement that initiated the transfer become undefined, 29 (3) if the statement is a READ statement or the end-of-file condition occurs in a wait operation 30 for a transfer initiated by a READ statement, all input list items or namelist group objects 31 in the statement that initiated the transfer become undefined, 32 (4) if the file specified in the input statement is an external record file, it is positioned after the 33 endfile record, 34 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 35 defined as specified in 9.10.4, 36 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 37 and 38 (7) if an END= specifier appears, a branch to the statement labeled by the label in the END= 39 specifier occurs. 9.10.3 End-of-record condition and the EOR= specifier 40 41If an end-of-record condition occurs during execution of an input/output statement that contains neither 42an EOR= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of- 43record condition occurs during execution of an input/output statement that contains either an EOR= 44specifier or an IOSTAT= specifier, and an error condition does not occur then (1) If the pad mode has the value 45 255 J3/07-007 WORKING DRAFT 2006/01/05 1 (a) YES, the record is padded with blanks to satisfy the effective list item (9.5.4.4.2) 2 and corresponding data edit descriptors that require more characters than the record 3 contains, (b) NO, the input list item becomes undefined, 4 (2) processing of the input list, if any, terminates, 5 6 (3) if the statement is a data transfer statement or the end-of-record condition occurs dur- 7 ing a wait operation, all do-variables in the statement that initiated the transfer become 8 undefined, (4) the file specified in the input statement is positioned after the current record, 9 10 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 11 defined as specified in 9.10.4, (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 12 13 (7) if a SIZE= specifier appears, the scalar-int-variable in the SIZE= specifier becomes defined as specified in (9.5.2.15), and 14 15 (8) if an EOR= specifier appears, a branch to the statement labeled by the label in the EOR= 16 specifier occurs. 9.10.4 IOSTAT= specifier 17 18Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable 19in the IOSTAT= specifier to become defined with 20 (1) a zero value if neither an error condition, an end-of-file condition, nor an end-of-record 21 condition occurs, 22 (2) the processor-dependent positive integer value of the constant IOSTAT INQUIRE INTERN- 23 AL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.2) if a unit number in an 24 INQUIRE statement identifies an internal file, 25 (3) a processor-dependent positive integer value different from IOSTAT INQUIRE INTERNAL- 26 UNIT if any other error condition occurs, 27 (4) the processor-dependent negative integer value of the constant IOSTAT END (13.8.2.10) if 28 an end-of-file condition occurs and no error condition occurs, or 29 (5) the processor-dependent negative integer value of the constant IOSTAT EOR (13.8.2.11) if 30 an end-of-record condition occurs and no error condition or end-of-file condition occurs. NOTE 9.68 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 ELSE IF (IOSS > 0) THEN ! Perform error processing CALL ERROR_PROCESSING END IF 9.10.5 IOMSG= specifier 31 256 2006/01/05 WORKING DRAFT J3/07-007 1If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, 2the processor shall assign an explanatory message to iomsg-variable. If no such condition occurs, the 3processor shall not change the value of iomsg-variable. 9.11 Restrictions on input/output statements 4 5If a unit, or a file connected to a unit, does not have all of the properties required for the execution of certain input/output statements, those statements shall not refer to the unit. 6 7An input/output statement that is executed while another input/output statement is being executed is called a recursive input/output statement. 8 9A recursive input/output statement shall not identify an external unit that is identified by another 10input/output statement being executed except that a child data transfer statement may identify its 11parent data transfer statement external unit. 12An input/output statement shall not cause the value of any established format specification to be 13modified. 14A recursive input/output statement shall not modify the value of any internal unit except that a recursive 15WRITE statement may modify the internal unit identified by that recursive WRITE statement. 16The value of a specifier in an input/output statement shall not depend on any input-item, io-implied- 17do do-variable, or on the definition or evaluation of any other specifier in the io-control-spec-list or 18inquire-spec-list in that statement. 19The value of any subscript or substring bound of a variable that appears in a specifier in an input/output 20statement shall not depend on any input-item, io-implied-do do-variable, or on the definition or evalua- 21tion of any other specifier in the io-control-spec-list or inquire-spec-list in that statement. 22In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if 23any, shall not be associated with any entity in the data transfer input/output list (9.5.3) or namelist- group-object-list, nor with a do-variable of an io-implied-do in the data transfer input/output list. 24 25In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an 26array element reference, its subscript values shall not be affected by the data transfer, the io-implied-do 27processing, or the definition or evaluation of any other specifier in the io-control-spec-list. 28A variable that may become defined or undefined as a result of its use in a specifier in an INQUIRE 29statement, or any associated entity, shall not appear in another specifier in the same INQUIRE statement. A STOP statement shall not be executed during execution of an input/output statement. 30 NOTE 9.69 Restrictions on the evaluation of expressions (7.1.4) prohibit certain side effects. 257 J3/07-007 WORKING DRAFT 2006/01/05 258 2006/01/05 WORKING DRAFT J3/07-007 10 Input/output editing 1 10.1 Format specifications 2 3A format used in conjunction with an input/output statement provides information that directs the 4editing between the internal representation of data and the characters of a sequence of formatted records. 5A R914 (9.5.2.2) in an input/output statement may refer to a FORMAT statement or to a character 6expression that contains a format specification. A format specification provides explicit editing infor- 7mation. The R914 alternatively may be an asterisk (*), which indicates list-directed formatting (10.10). 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 1010.2.1 FORMAT statement 11R1001 format-stmt is FORMAT format-specification 12R1002 format-specification is ( [ format-item-list ] ) 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 16 (1) between a P edit descriptor and an immediately following F, E, EN, ES, D, or G edit 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 21Blank characters may precede the initial left parenthesis of the format specification. Additional blank 22characters may appear at any point within the format specification, with no effect on the interpretation 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 25A character expression used as a format in a formatted input/output statement shall evaluate to a 26character string whose leading part is a valid format specification. NOTE 10.2 The format specification begins with a left parenthesis and ends with a right parenthesis. 259 J3/07-007 WORKING DRAFT 2006/01/05 1All character positions up to and including the final right parenthesis of the format specification shall be 2defined at the time the input/output statement is executed, and shall not become redefined or undefined 3during the execution of the statement. Character positions, if any, following the right parenthesis that 4ends the format specification need not be defined and may contain any character data with no effect on 5the interpretation of the format specification. 6If the format is a character array, it is treated as if all of the elements of the array were specified in array 7element order and were concatenated. However, if a format is a character array element, the format 8specification shall be entirely within that array element. 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. 910.3 Form of a format item list 10.3.1 Syntax 10 11R1003 format-item is [ r ] data-edit-desc 12 or control-edit-desc 13 or char-string-edit-desc or [ r ] ( format-item-list ) 14 R1004 unlimited-format-item is * ( format-item-list ) 15 16R1005 r is int-literal-constant C1003 (R1005) r shall be positive. 17 C1004 (R1005) r shall not have a kind parameter specified for it. 18 19The integer literal constant r is called a repeat specification. 10.3.2 Edit descriptors 20 21An edit descriptor is a data edit descriptor, a control edit descriptor, or a character string 22edit descriptor. 260 2006/01/05 WORKING DRAFT J3/07-007 1R1006 data-edit-desc is I w [ . m ] 2 or B w [ . m ] 3 or O w [ . m ] 4 or Z w [ . m ] 5 or F w . d 6 or E w . d [ E e ] 7 or EN w . d [ E e ] 8 or ES w . d [ E e ] 9 or G w [ . d [ E e ] ] 10 or L w 11 or A [ w ] 12 or D w . d or DT [ char-literal-constant ] [ ( v-list ) ] 13 14R1007 w is int-literal-constant 15R1008 m is int-literal-constant 16R1009 d is int-literal-constant 17R1010 e is int-literal-constant 18R1011 v is signed-int-literal-constant C1005 (R1010) e shall be positive. 19 20C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be 21 positive for all other edit descriptors. C1007 (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. 22 C1008 (R1006) w, m, d, e, and v shall not have kind parameters specified for them. 23 24C1009 (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter 25 specified for it. 26I, B, O, Z, F, E, EN, ES, G, L, A, D, and DT indicate the manner of editing. 27R1012 control-edit-desc is position-edit-desc 28 or [ r ] / 29 or : 30 or sign-edit-desc 31 or k P 32 or blank-interp-edit-desc 33 or round-edit-desc 34 or decimal-edit-desc 35R1013 k is signed-int-literal-constant C1010 (R1013) k shall not have a kind parameter specified for it. 36 37In k P, k is called the scale factor. 38R1014 position-edit-desc is T n 39 or TL n 40 or TR n 41 or n X 261 J3/07-007 WORKING DRAFT 2006/01/05 1R1015 n is int-literal-constant C1011 (R1015) n shall be positive. 2 C1012 (R1015) n shall not have a kind parameter specified for it. 3 4R1016 sign-edit-desc is SS 5 or SP 6 or S 7R1017 blank-interp-edit-desc is BN 8 or BZ 9R1018 round-edit-desc is RU 10 or RD 11 or RZ 12 or RN 13 or RC 14 or RP 15R1019 decimal-edit-desc is DC 16 or DP 17T, TL, TR, X, slash, colon, SS, SP, S, P, BN, BZ, RU, RD, RZ, RN, RC, RP, DC, and DP indicate the 18manner of editing. 19R1020 char-string-edit-desc is char-literal-constant C1013 (R1020) The char-literal-constant shall not have a kind parameter specified for it. 20 21Each rep-char in a character string edit descriptor shall be one of the characters capable of representation 22by the processor. 23The character string edit descriptors provide constant data to be output, and are not valid for input. 24The edit descriptors are without regard to case except for the characters in the character constants. 2510.3.3 Fields 26A field is a part of a record that is read on input or written on output when format control encounters 27a data edit descriptor or a character string edit descriptor. The field width is the size in characters of 28the field. 10.4 Interaction between input/output list and format 29 30The start of formatted data transfer using a format specification initiates format control (9.5.4.4.2). 31Each action of format control depends on information jointly provided by the next edit descriptor in the format specification and the next effective item in the input/output list, if one exists. 32 33If an input/output list specifies at least one effective list item, at least one data edit descriptor shall 34exist in the format specification. 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. 262 2006/01/05 WORKING DRAFT J3/07-007 1A format specification is interpreted from left to right. The exceptions are format items preceded by a repeat specification r, and format reversion (described below). 2 3A format item preceded by a repeat specification is processed as a list of r items, each identical to the 4format item but without the repeat specification and separated by commas. NOTE 10.5 An omitted repeat specification is treated in the same way as a repeat specification whose value is one. 5To each data edit descriptor interpreted in a format specification, there corresponds one effective item 6specified by the input/output list (9.5.3), except that an input/output list item of type complex requires 7the interpretation of two F, E, EN, ES, D, or G edit descriptors. For each control edit descriptor or 8character edit descriptor, there is no corresponding item specified by the input/output list, and format 9control communicates information directly with the record. 10Whenever format control encounters a data edit descriptor in a format specification, it determines 11whether there is a corresponding effective item specified by the input/output list. If there is such an 12item, it transmits appropriately edited information between the item and the record, and then format 13control proceeds. If there is no such item, format control terminates. 14If format control encounters a colon edit descriptor in a format specification and another effective in- put/output list item is not specified, format control terminates. 15 16If format control encounters the rightmost parenthesis of a complete format specification and another 17effective input/output list item is not specified, format control terminates. However, if another effective 18input/output list item is specified, format control then reverts to the beginning of the format item 19terminated by the last preceding right parenthesis that is not part of a DT edit descriptor. If there 20is no such preceding right parenthesis, format control reverts to the first left parenthesis of the format 21specification. If any reversion occurs, the reused portion of the format specification shall contain at 22least one data edit descriptor. If format control reverts to a parenthesis that is preceded by a repeat 23specification, the repeat specification is reused. Reversion of format control, of itself, has no effect on 24the changeable modes (9.4.1). If format control reverts to a parenthesis that is not the beginning of an 25unlimited-format-item, the file is positioned in a manner identical to the way it is positioned when a slash edit descriptor is processed (10.8.2). 26 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. 263 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.7 (cont.) 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 1 2After each data edit descriptor or character string edit descriptor is processed, the file is positioned after 3the last character read or written in the current record. 4After each T, TL, TR, or X edit descriptor is processed, the file is positioned as described in 10.8.1. 5After each slash edit descriptor is processed, the file is positioned as described in 10.8.2. 6During formatted stream output, processing of an A edit descriptor can cause file positioning to occur (10.7.4). 7 8If format control reverts as described in 10.4, the file is positioned in a manner identical to the way it is positioned when a slash edit descriptor is processed (10.8.2). 9 10During a read operation, any unprocessed characters of the current record are skipped whenever the 11next record is read. 10.6 Decimal symbol 12 13The decimal symbol is the character that separates the whole and fractional parts in the decimal 14representation of a real number in an internal or external file. When the decimal edit mode is POINT, 15the decimal symbol is a decimal point. When the decimal edit mode is COMMA, the decimal symbol is 16a comma. 10.7 Data edit descriptors 17 1810.7.1 General 19Data edit descriptors cause the conversion of data to or from its internal representation; during formatted 20stream output, the A data edit descriptor may also cause file positioning. On input, the specified variable 21becomes defined unless an error condition, an end-of-file condition, or an end-of-record condition occurs. 22On output, the specified expression is evaluated. 23During input from a Unicode file, 24 (1) characters in the record that correspond to an ASCII character variable shall have a position 25 in the ISO 10646 character type collating sequence of 127 or less, and 26 (2) characters in the record that correspond to a default character variable shall be representable 27 in the default character type. 28During input from a non-Unicode file, 29 (1) characters in the record that correspond to a character variable shall have the kind of the 30 character variable, and 31 (2) characters in the record that correspond to a numeric logical, or bits variable shall be of 32 default character type. 264 2006/01/05 WORKING DRAFT J3/07-007 1During output to a Unicode file, all characters transmitted to the record are of ISO 10646 character 2type. If a character input/output list item or character string edit descriptor contains a character that 3is not representable in the ISO 10646 character type, the result is processor-dependent. 4During output to a non-Unicode file, characters transmitted to the record as a result of processing a 5character string edit descriptor or as a result of evaluating a numeric, logical, bits, or default character 6data entity, are of type default character. 10.7.2 Numeric and bits editing 7 810.7.2.1 General rules 9The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify the input/output of 10integer, real, complex, and bits data. The following general rules apply. 11 (1) On input, leading blanks are not significant. When the input field is not an IEEE excep- 12 tional specification (10.7.2.3.2), the interpretation of blanks, other than leading blanks, is 13 determined by the blank interpretation mode (10.8.6). Plus signs may be omitted. A field 14 containing only blanks is considered to be zero. 15 (2) On input, with F, E, EN, ES, D, and G editing, a decimal symbol appearing in the input 16 field overrides the portion of an edit descriptor that specifies the decimal symbol location. 17 The input field may have more digits than the processor uses to approximate the value of 18 the datum. 19 (3) On output with I, F, E, EN, ES, D, and G editing, the representation of a positive or zero 20 internal value in the field may be prefixed with a plus sign, as controlled by the S, SP, and 21 SS edit descriptors or the processor. The representation of a negative internal value in the 22 field shall be prefixed with a minus sign. 23 (4) On output, the representation is right justified in the field. If the number of characters 24 produced by the editing is smaller than the field width, leading blanks are inserted in the 25 field. 26 (5) On output, if the number of characters produced exceeds the field width or if an exponent 27 exceeds its specified length using the Ew.d Ee, ENw.d Ee, ESw.d Ee, or Gw.d Ee edit 28 descriptor, the processor shall fill the entire field of width w with asterisks. However, 29 the processor shall not produce asterisks if the field width is not exceeded when optional 30 characters are omitted. NOTE 10.8 When an SP edit descriptor is in effect, a plus sign is not optional. 31 (6) On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may 32 be zero. In such cases, the processor selects the smallest positive actual field width that 33 does not result in a field filled with asterisks. The specified value of w shall not be zero on 34 input. 3510.7.2.2 Integer editing 36The Iw and Iw.m, edit descriptors indicate that the field to be edited occupies w positions, except when 37w is zero. When w is zero, the processor selects the field width. On input, w shall not be zero. The 38specified input/output list item shall be of type integer or bits. The G, B, O, and Z edit descriptor also may be used to edit integer data (10.7.5.2.1, 10.7.2.4). 39 40If the input list item is of type bits, the integer value specified by the input field is converted to type 41bits according to the model in 13.3. On input, m has no effect. 265 J3/07-007 WORKING DRAFT 2006/01/05 1In the input field for the I edit descriptor, the character string shall be a signed-digit-string (R409) if 2the list item is of type integer and a digit-string (R410) if it is of type bits, except for the interpretation 3of blanks. 4The output field for the Iw edit descriptor consists of zero or more leading blanks followed by a minus 5sign if the internal value is negative, or an optional plus sign otherwise, followed by the magnitude of 6the internal value as a digit-string without leading zeros. NOTE 10.9 A digit-string always consists of at least one digit. 7The output field for the Iw.m edit descriptor is the same as for the Iw edit descriptor, except that the 8digit-string consists of at least m digits. If necessary, sufficient leading zeros are included to achieve the 9minimum of m digits. The value of m shall not exceed the value of w, except when w is zero. If m is 10zero and the internal value is zero, the output field consists of only blank characters, regardless of the 11sign control in effect. When m and w are both zero, and the internal value is zero, one blank character 12is produced. 1310.7.2.3 Real and complex editing 1410.7.2.3.1 General 15The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output 16list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G, B, O, and Z edit descriptors also may be used to edit real and complex data (10.7.5.2.2). 17 1810.7.2.3.2 F editing 19The Fw.d edit descriptor indicates that the field occupies w positions, the fractional part of which 20consists of d digits. When w is zero, the processor selects the field width. On input, w shall not be zero. 21A lower-case letter is equivalent to the corresponding upper-case letter in an IEEE exceptional specifi- 22cation or the exponent in a numeric input field. 23The input field is either an IEEE exceptional specification or consists of an optional sign, followed by a 24string of one or more digits optionally containing a decimal symbol, including any blanks interpreted as 25zeros. The d has no effect on input if the input field contains a decimal symbol. If the decimal symbol 26is omitted, the rightmost d digits of the string, with leading zeros assumed if necessary, are interpreted 27as the fractional part of the value represented. The string of digits may contain more digits than a 28processor uses to approximate the value. The basic form may be followed by an exponent of one of the 29following forms: 30 · a sign followed by a digit-string; 31 · the letter E followed by zero or more blanks, followed by a signed-digit-string; 32 · the letter D followed by zero or more blanks, followed by a signed-digit-string. 33An exponent containing a D is processed identically to an exponent containing an E. 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). 266 2006/01/05 WORKING DRAFT J3/07-007 1An input field that is an IEEE exceptional specification consists of optional blanks, followed by either 2 · an optional sign, followed by the string 'INF' or the string 'INFINITY', or 3 · an optional sign, followed by the string 'NAN', optionally followed by zero or more alphanumeric 4 characters enclosed in parentheses, 5optionally followed by blanks. 6The value specified by form (1) is an IEEE infinity; this form shall not be used if the processor does 7not support IEEE infinities for the input variable. The value specified by form (2) is an IEEE NaN; 8this form shall not be used if the processor does not support IEEE NaNs for the input variable. The 9NaN value is a quiet NaN if the only nonblank characters in the field are 'NAN' or 'NAN()'; otherwise, 10the NaN value is processor-dependent. The interpretation of a sign in a NaN input field is processor 11dependent. 12For an internal value that is an IEEE infinity, the output field consists of blanks, if necessary, followed 13by a minus sign for negative infinity or an optional plus sign otherwise, followed by the letters 'Inf' or 14'Infinity', right justified within the field. If w is less than 3, the field is filled with asterisks; otherwise, 15if w is less than 8, 'Inf' is produced. 16For an internal value that is an IEEE NaN, the output field consists of blanks, if necessary, followed by 17the letters 'NaN' and optionally followed by one to w - 5 alphanumeric processor-dependent characters 18enclosed in parentheses, right justified within the field. If w is less than 3, the field is filled with asterisks. NOTE 10.11 The processor-dependent characters following 'NaN' may convey additional information about that particular NaN. 19For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if 20necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, 21followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal 22value, as modified by the established scale factor and rounded (10.7.2.3.7) to d fractional digits. Leading 23zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the 24magnitude of the value in the output field is less than one. The optional zero shall appear if there would 25otherwise be no digits in the output field. 2610.7.2.3.3 E and D editing 27The Ew.d, Dw.d, and Ew.d Ee edit descriptors indicate that the external field occupies w positions, the 28fractional part of which consists of d digits, unless a scale factor greater than one is in effect, and the 29exponent part consists of e digits. The e has no effect on input. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 30 31For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 32Fw.d. 33For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field for a scale 34factor of zero is 35 [ ± ] [0].x1x2 ...xdexp 36where: 37 · ± signifies a plus sign or a minus sign; 267 J3/07-007 WORKING DRAFT 2006/01/05 · . signifies a decimal symbol (10.6); 1 2 · x1x2 ...xd are the d most significant digits of the internal value after rounding (10.7.2.3.7); 3 · exp is a decimal exponent having one of the forms specified in table 10.1. Table 10.1: E and D exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 Ew.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 Ew.d Ee |exp| 10e - 1 E±z1z2 ...ze Dw.d |exp| 99 D±z1z2 or E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 (1) where each z is a digit. 4The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit descriptor forms Ew.d and Dw.d shall not be used if |exp| > 999. 5 6The scale factor k controls the decimal normalization (10.3.2, 10.8.5). If -d < k 0, the output field 7contains exactly |k| leading zeros and d-|k| significant digits after the decimal symbol. If 0 < k < d+2, 8the output field contains exactly k significant digits to the left of the decimal symbol and d - k + 1 9significant digits to the right of the decimal symbol. Other values of k are not permitted. 1010.7.2.3.4 EN editing 11The EN edit descriptor produces an output field in the form of a real number in engineering notation 12such that the decimal exponent is divisible by three and the absolute value of the significand (R414) is 13greater than or equal to 1 and less than 1000, except when the output value is zero. The scale factor 14has no effect on output. 15The forms of the edit descriptor are ENw.d and ENw.d Ee indicating that the external field occupies w 16positions, the fractional part of which consists of d digits and the exponent part consists of e digits. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 17 18For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 19Fw.d. 20For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 21 [ ± ] yyy . x1x2 ...xdexp 22where: 23 · ± signifies a plus sign or a minus sign; 24 · yyy are the 1 to 3 decimal digits representative of the most significant digits of the internal value after rounding (10.7.2.3.7); 25 26 · yyy is an integer such that 1 yyy < 1000 or, if the output value is zero, yyy = 0; · . signifies a decimal symbol (10.6); 27 28 · x1x2 ...xd are the d next most significant digits of the internal value after rounding; 268 2006/01/05 WORKING DRAFT J3/07-007 1 · exp is a decimal exponent, divisible by three, having one of the forms specified in table 10.2. Table 10.2: EN exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 ENw.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 ENw.d Ee |exp| 10e - 1 E±z1z2 ...ze (1) where each z is a digit. 2The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit descriptor form ENw.d shall not be used if |exp| > 999. 3 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 410.7.2.3.5 ES editing 5The ES edit descriptor produces an output field in the form of a real number in scientific notation such 6that the absolute value of the significand (R414) is greater than or equal to 1 and less than 10, except 7when the output value is zero. The scale factor has no effect on output. 8The forms of the edit descriptor are ESw.d and ESw.d Ee indicating that the external field occupies w 9positions, the fractional part of which consists of d digits and the exponent part consists of e digits. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 10 11For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 12Fw.d. 13For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 14 [ ± ] y . x1x2 ...xdexp 15where: 16 · ± signifies a plus sign or a minus sign; 17 · y is a decimal digit representative of the most significant digit of the internal value after rounding (10.7.2.3.7); 18 · . signifies a decimal symbol (10.6); 19 20 · x1x2 ...xd are the d next most significant digits of the internal value after rounding; 21 · exp is a decimal exponent having one of the forms specified in table 10.3. 269 J3/07-007 WORKING DRAFT 2006/01/05 Table 10.3: ES exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 ESw.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 ESw.d Ee |exp| 10e - 1 E±z1z2 ...ze (1) where each z is a digit. 1The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 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 310.7.2.3.6 Complex editing 4A complex datum consists of a pair of separate real data. The editing of a scalar datum of complex type 5is specified by two edit descriptors each of which specifies the editing of real data. The first of the edit 6descriptors specifies the real part; the second specifies the imaginary part. The two edit descriptors may 7be different. Control and character string edit descriptors may be processed between the edit descriptor 8for the real part and the edit descriptor for the imaginary part. 910.7.2.3.7 Rounding mode 10The rounding mode can be specified by an OPEN statement (9.4.1), a data transfer input/output statement (9.5.2.13), or an edit descriptor (10.8.7). 11 12In what follows, the term "decimal value" means the exact decimal number as given by the character 13string, while the term "internal value" means the number actually stored in the processor. For example, 14in dealing with the decimal constant 0.1, the decimal value is the mathematical quantity 1/10, which 15has no exact representation in binary form. Formatted output of real data involves conversion from an 16internal value to a decimal value; formatted input involves conversion from a decimal value to an internal 17value. 18When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest repre- 19sentable value that is greater than or equal to the original value. When the I/O rounding mode is 20DOWN, the value resulting from conversion shall be the largest representable value that is less than or 21equal to the original value. When the I/O rounding mode is ZERO, the value resulting from conversion 22shall be the value closest to the original value and no greater in magnitude than the original value. When 23the I/O rounding mode is NEAREST, the value resulting from conversion shall be the closer of the two 24nearest representable values if one is closer than the other. If the two nearest representable values are 25equidistant from the original value, it is processor dependent which one of them is chosen. When the 26I/O rounding mode is COMPATIBLE, the value resulting from conversion shall be the closer of the 27two nearest representable values or the value away from zero if halfway between them. When the I/O 28rounding mode is PROCESSOR DEFINED, rounding during conversion shall be a processor-dependent 29default mode, which may correspond to one of the other modes. 30On processors that support IEEE rounding on conversions, NEAREST shall correspond to round to 270 2006/01/05 WORKING DRAFT J3/07-007 1nearest, as specified in the IEEE International Standard. 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. 210.7.2.4 Bits editing 3The Bw, Bw.m, Ow, Ow.m, Zw, and Zw.m edit descriptors indicate that the field to be edited occupies 4w positions, except when w is zero. When w is zero, the processor selects the field width. On input, 5w shall not be zero. The input/output list item shall be of type bits, integer, real, complex, or logical. 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 7If the input list item is not of type bits, the input field is edited as if the input list item were of type bits and bits compatible (12.5.2.4) with the actual list item. 8 9On input, m has no effect. 10In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, 11or hexadecimal digits (as in R426, R427, R428) in the respective input field. The lower-case hexadecimal 12digits a through f in a hexadecimal input field are equivalent to the corresponding upper-case hexadecimal 13digits. 14If the output list item, x, is not of type bits, it is interpreted as if it were of type bits with the value BITS(x). 15 16The output field for the Bw, Ow, and Zw descriptors consists of zero or more leading blanks followed by 17the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, 18with the same value and without leading zeros. 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 20The output field for the Bw.m, Ow.m, and Zw.m edit descriptor is the same as for the Bw, Ow, and Zw 21edit descriptor, except that the digit-string or hex-digit-string consists of at least m digits. If necessary, 22sufficient leading zeros are included to achieve the minimum of m digits. The value of m shall not exceed 23the value of w, except when w is zero. If m is zero and the internal value consists of all zero bits, the 24output field consists of only blank characters. When m and w are both zero, and the internal value 25consists of all zero bits, one blank character is produced. 10.7.3 Logical editing 26 27The Lw edit descriptor indicates that the field occupies w positions. The specified input/output list item shall be of type logical. The G edit descriptor also may be used to edit logical data (10.7.5.4). 28 29The input field consists of optional blanks, optionally followed by a period, followed by a T for true or 30F for false. The T or F may be followed by additional characters in the field, which are ignored. 31A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field. 271 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.16 The logical constants .TRUE. and .FALSE. are acceptable input forms. 1The output field consists of w - 1 blanks followed by a T or F, depending on whether the internal value 2is true or false, respectively. 10.7.4 Character editing 3 4The A[w] edit descriptor is used with an input/output list item of type character. The G edit descriptor 5also may be used to edit character data (10.7.5.5). The kind type parameter of all characters transferred 6and converted under control of one A or G edit descriptor is implied by the kind of the corresponding 7list item. 8If a field width w is specified with the A edit descriptor, the field consists of w characters. If a field 9width w is not specified with the A edit descriptor, the number of characters in the field is the length of 10the corresponding list item, regardless of the value of the kind type parameter. 11Let len be the length of the input/output list item. If the specified field width w for an A edit descriptor 12corresponding to an input item is greater than or equal to len, the rightmost len characters will be taken 13from the input field. If the specified field width w is less than len, the w characters will appear left 14justified with len-w trailing blanks in the internal value. 15If the specified field width w for an A edit descriptor corresponding to an output item is greater than 16len, the output field will consist of w -len blanks followed by the len characters from the internal value. 17If the specified field width w is less than or equal to len, the output field will consist of the leftmost w 18characters from the internal value. NOTE 10.17 For nondefault character types, the blank padding character is processor dependent. 19If the file is connected for stream access, the output may be split across more than one record if it 20contains newline characters. A newline character is a nonblank character returned by the intrinsic 21function NEW LINE. Beginning with the first character of the output field, each character that is not 22a newline is written to the current record in successive positions; each newline character causes file 23positioning at that point as if by slash editing (the current record is terminated at that point, a new 24empty record is created following the current record, this new record becomes the last and current record 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 2710.7.5.1 Overview 28The Gw, Gw.d and Gw.d Ee edit descriptors are used with an input/output list item of any intrinsic 29type. When w is nonzero, these edit descriptors indicate that the external field occupies w positions; 30for real or complex data the fractional part consists of a maximum of d digits and the exponent part 31consists of e digits. When these edit descriptors are used to specify the input/output of integer, logical, 32bits, or character data, d and e have no effect. When w is zero the processor selects the field width. On 33input, w shall not be zero. 272 2006/01/05 WORKING DRAFT J3/07-007 110.7.5.2 Generalized numeric editing 2When used to specify the input/output of integer, real, and complex data, the Gw, Gw.d and Gw.d Ee 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. 410.7.5.2.1 Generalized integer editing 5When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow 6the rules for the Iw edit descriptor (10.7.2.2), except that w shall not be zero. When used to specify the 7output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor. 810.7.5.2.2 Generalized real and complex editing The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 9 10When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for 11the ESw.d Ee edit descriptor. Reasonable processor-dependent values of w, d, and e are used with each 12output value. 13For an internal value that is an IEEE infinity or NaN, the form of the output field for the Gw.d and 14Gw.d Ee edit descriptors is the same as for Fw.d. 15Otherwise, the method of representation in the output field depends on the magnitude of the internal 16value being edited. Let N be the magnitude of the internal value and r be the rounding mode value -1 17defined in the table below. If 0 < N < 0.1 - r × 10-d or N 10d - r, or N is identically 0 and 18d is 0, Gw.d output editing is the same as k PEw.d output editing and Gw.d Ee output editing is 19the same as k PEw.d Ee output editing, where k is the scale factor (10.8.5) currently in effect. If -1 200.1 - r × 10-d N < 10d - r or N is identically 0 and d is not zero, the scale factor has no effect, 21and the value of N determines the editing as follows: Magnitude of Internal Value Equivalent Conversion N = 0 F(w - n).(d - 1), n('b') 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') 22where 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 23follows: 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 273 J3/07-007 WORKING DRAFT 2006/01/05 I/O Rounding Mode r 1 if internal value is negative ZERO 0 if internal value is positive 1The value of w - n shall be positive 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. 210.7.5.3 Generalized bits editing 3When used to specify the input/output of bits data, the Gw.d and Gw.d Ee edit descriptors follow the 4rules for the Zw edit descriptor (10.7.2.4), except that w shall not be zero. When used to specify the 5output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor. 610.7.5.4 Generalized logical editing 7When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors follow 8the rules for the Lw edit descriptor (10.7.3). When used to specify the output of logical data, the G0 9edit descriptor follows the rules for the L1 edit descriptor. 1010.7.5.5 Generalized character editing 11When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors follow 12the rules for the Aw edit descriptor (10.7.4). When used to specify the output of character data, the G0 13edit descriptor follows the rules for the A edit descriptor with no field width. 10.7.6 User-defined derived-type editing 14 15The DT edit descriptor allows a user-provided procedure to be used instead of the processor's default input/output formatting for processing a list item of derived type. 16 17The DT edit descriptor may include a character literal constant. The character value "DT" concatenated 18with the character literal constant is passed to the user-defined derived-type input/output procedure as 19the iotype argument (9.5.4.7). The v values of the edit descriptor are passed to the user-defined 20derived-type input/output procedure as the v_list array argument. NOTE 10.21 For the edit descriptor DT'Link List'(10, 4, 2), iotype is "DTLink List" and v_list is [10, 4, 2]. 21If a derived-type variable or value corresponds to a DT edit descriptor, there shall be an accessible 22interface to a corresponding derived-type input/output procedure for that derived type (9.5.4.7). A DT 23edit descriptor shall not correspond with a list item that is not of a derived type. 10.8 Control edit descriptors 24 25A control edit descriptor does not cause the transfer of data or the conversion of data to or from internal 26representation, but may affect the conversions performed by subsequent data edit descriptors. 274 2006/01/05 WORKING DRAFT J3/07-007 10.8.1 Position editing 1 2The T, TL, TR, and X edit descriptors specify the position at which the next character will be transmitted 3to or from the record. If any character skipped by a T, TL, TR, or X edit descriptor is of type nondefault 4character, and the unit is an internal file of type default character or an external non-Unicode file, the 5result of that position editing is processor dependent. 6The position specified by a T edit descriptor may be in either direction from the current position. On 7input, this allows portions of a record to be processed more than once, possibly with different editing. 8The position specified by an X edit descriptor is forward from the current position. On input, a position 9beyond the last character of the record may be specified if no characters are transmitted from such 10positions. NOTE 10.22 An nX edit descriptor has the same effect as a TRn edit descriptor. 11On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to be transmitted and 12therefore does not by itself affect the length of the record. If characters are transmitted to positions at 13or after the position specified by a T, TL, TR, or X edit descriptor, positions skipped and not previously 14filled are filled with blanks. The result is as if the entire record were initially filled with blanks. 15On output, a character in the record may be replaced. However, a T, TL, TR, or X edit descriptor never 16directly causes a character already placed in the record to be replaced. Such edit descriptors may result 17in positioning such that subsequent editing causes a replacement. 1810.8.1.1 T, TL, and TR editing 19The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to 20nonchild data transfer, the left tab limit becomes defined as the character position of the current record 21or the current position of the stream file. If, during data transfer, the file is positioned to another record, 22the left tab limit becomes defined as character position one of that record. 23The Tn edit descriptor indicates that the transmission of the next character to or from a record is to 24occur at the nth character position of the record, relative to the left tab limit. 25The TLn edit descriptor indicates that the transmission of the next character to or from the record is 26to occur at the character position n characters backward from the current position. However, if n is 27greater than the difference between the current position and the left tab limit, the TLn edit descriptor 28indicates that the transmission of the next character to or from the record is to occur at the left tab 29limit. 30The TRn edit descriptor indicates that the transmission of the next character to or from the record is 31to occur at the character position n characters forward from the current position. NOTE 10.23 The n in a Tn, TLn, or TRn edit descriptor shall be specified and shall be greater than zero. 3210.8.1.2 X editing 33The nX edit descriptor indicates that the transmission of the next character to or from a record is to 34occur at the position n characters forward from the current position. 275 J3/07-007 WORKING DRAFT 2006/01/05 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 2The slash edit descriptor indicates the end of data transfer to or from the current record. 3On input from a file connected for sequential or stream access, the remaining portion of the current 4record is skipped and the file is positioned at the beginning of the next record. This record becomes 5the current record. On output to a file connected for sequential or stream access, a new empty record 6is created following the current record; this new record then becomes the last and current record of the 7file and the file is positioned at the beginning of this new record. 8For a file connected for direct access, the record number is increased by one and the file is positioned 9at the beginning of the record that has that record number, if there is such a record, and this record 10becomes the current record. 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. 11The repeat specification is optional in the slash edit descriptor. If it is not specified, the default value is 12one. 10.8.3 Colon editing 13 14The colon edit descriptor terminates format control if there are no more effective items in the in- 15put/output list (9.5.3). The colon edit descriptor has no effect if there are more effective items in the input/output list. 16 10.8.4 SS, SP, and S editing 17 18The SS, SP, and S edit descriptors temporarily change (9.4.1) the sign mode (9.4.5.15, 9.5.2.14) for the 19connection. The edit descriptors SS, SP, and S set the sign mode corresponding to the SIGN= specifier 20values SUPPRESS, PLUS, and PROCESSOR DEFINED, respectively. 21The sign mode controls optional plus characters in numeric output fields. When the sign mode is PLUS, 22the processor shall produce a plus sign in any position that normally contains an optional plus sign. 23When the sign mode is SUPPRESS, the processor shall not produce a plus sign in such positions. When 24the sign mode is PROCESSOR DEFINED, the processor has the option of producing a plus sign or not in such positions, subject to 10.7.2(5). 25 26The SS, SP, and S edit descriptors affect only I, F, E, EN, ES, D, and G editing during the execution of 27an output statement. The SS, SP, and S edit descriptors have no effect during the execution of an input 28statement. 10.8.5 P editing 29 30The kP edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k. The scale 31factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities. 32The scale factor k affects the appropriate editing in the following manner. 276 2006/01/05 WORKING DRAFT J3/07-007 1 (1) On input, with F, E, EN, ES, D, and G editing (provided that no exponent exists in the 2 field) and F output editing, the scale factor effect is that the externally represented number 3 equals the internally represented number multiplied by 10k. 4 (2) On input, with F, E, EN, ES, D, and G editing, the scale factor has no effect if there is an 5 exponent in the field. 6 (3) On output, with E and D editing, the significand (R414) part of the quantity to be produced 7 is multiplied by 10k and the exponent is reduced by k. 8 (4) On output, with G editing, the effect of the scale factor is suspended unless the magnitude 9 of the datum to be edited is outside the range that permits the use of F editing. If the use 10 of E editing is required, the scale factor has the same effect as with E output editing. (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 13 (1) on input, the scale factor is applied to the external decimal value and then this is converted using the current I/O rounding mode, and 14 15 (2) on output, the internal value is converted using the current I/O rounding mode and then 16 the scale factor is applied to the converted decimal value. 10.8.6 BN and BZ editing 17 18The BN and BZ edit descriptors temporarily change (9.4.1) the blank interpretation mode (9.4.5.4, 199.5.2.6) for the connection. The edit descriptors BN and BZ set the blank interpretation mode corre- 20sponding to the BLANK= specifier values NULL and ZERO, respectively. 21The blank interpretation mode controls the interpretation of nonleading blanks in numeric and bits 22input fields. Such blank characters are interpreted as zeros when the blank interpretation mode has the 23value ZERO; they are ignored when the blank interpretation mode has the value NULL. The effect of 24ignoring blanks is to treat the input field as if blanks had been removed, the remaining portion of the 25field right justified, and the blanks replaced as leading blanks. However, a field containing only blanks 26has the value zero. 27The blank interpretation mode affects only numeric editing, bits editing, generalized numeric editing, 28and generalized bits editing on input. It has no effect on output. 10.8.7 RU, RD, RZ, RN, RC, and RP editing 29 30The round edit descriptors temporarily change (9.4.1) the connection's I/O rounding mode (9.4.5.14, 319.5.2.13, 10.7.2.3.7). The round edit descriptors RU, RD, RZ, RN, RC, and RP set the I/O rounding 32mode corresponding to the ROUND= specifier values UP, DOWN, ZERO, NEAREST, COMPATIBLE, 33and PROCESSOR DEFINED, respectively. The I/O rounding mode affects the conversion of real and 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 36The decimal edit descriptors temporarily change (9.4.1) the decimal edit mode (9.4.5.5, 9.5.2.7, 10.6) 37for the connection. The edit descriptors DC and DP set the decimal edit mode corresponding to the 38DECIMAL= specifier values COMMA and POINT, respectively. 39The decimal edit mode controls the representation of the decimal symbol (10.6) during conversion of 40real and complex values in formatted input/output. The decimal edit mode affects only D, E, EN, ES, 41F, and G editing. If the mode is COMMA during list-directed input/output, the character used as a 42value separator is a semicolon in place of a comma. 277 J3/07-007 WORKING DRAFT 2006/01/05 10.9 Character string edit descriptors 1 2A character string edit descriptor shall not be used on input. 3The character string edit descriptor causes characters to be written from the enclosed characters of the 4edit descriptor itself, including blanks. For a character string edit descriptor, the width of the field is 5the number of characters between the delimiting characters. Within the field, two consecutive delimiting 6characters are counted as a single character. NOTE 10.26 A delimiter for a character string edit descriptor is either an apostrophe or quote. 10.10 List-directed formatting 7 810.10.1 General 9List-directed input/output allows data editing according to the type of the list item instead of by a 10format specification. It also allows data to be free-field, that is, separated by commas (or semicolons) 11or blanks. 10.10.2 Values and value separators 12 13The characters in one or more list-directed records constitute a sequence of values and value separators. 14The end of a record has the same effect as a blank character, unless it is within a character constant. Any 15sequence of two or more consecutive blanks is treated as a single blank, unless it is within a character 16constant. 17Each value is either a null value, c, r*c, or r*, where c is a literal constant, optionally signed if integer 18or real, or an undelimited character constant and r is an unsigned, nonzero, integer literal constant. 19Neither c nor r shall have kind type parameters specified. The constant c is interpreted as though 20it had the same kind type parameter as the corresponding list item. The r*c form is equivalent to r 21successive appearances of the constant c, and the r* form is equivalent to r successive appearances of 22the null value. Neither of these forms may contain embedded blanks, except where permitted within the 23constant c. 24A value separator is 25 (1) a comma optionally preceded by one or more contiguous blanks and optionally followed by 26 one or more contiguous blanks, unless the decimal edit mode is COMMA, in which case a 27 semicolon is used in place of the comma, 28 (2) a slash optionally preceded by one or more contiguous blanks and optionally followed by 29 one or more contiguous blanks, or 30 (3) one or more contiguous blanks between two nonblank values or following the last nonblank 31 value, where a nonblank value is a constant, an r*c form, or an r* form. 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. 278 2006/01/05 WORKING DRAFT J3/07-007 10.10.3 List-directed input 1 2Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting, 3except as noted below. The form of the input value shall be acceptable for the type of the next effective 4item in the list. Blanks are never used as zeros, and embedded blanks are not permitted in constants, 5except within character constants and complex constants as specified below. 6For the r*c form of an input value, the constant c is interpreted as an undelimited character constant 7if the first list item corresponding to this value is of type default, ASCII, or ISO 10646 character, there 8is a nonblank character immediately after r*, and that character is not an apostrophe or a quotation 9mark; otherwise, c is interpreted as a literal constant. NOTE 10.29 The end of a record has the effect of a blank, except when it appears within a character constant. 10When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 11edit descriptor with a suitable value of w were used. 12When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 13descriptor with a suitable value of w were used. 14When the next effective item is of type real, the input form is that of a numeric input field. A numeric 15input field is a field suitable for F editing (10.7.2.3.2) that is assumed to have no fractional digits unless 16a decimal symbol appears within the field. 17When the next effective item is of type complex, the input form consists of a left parenthesis followed by 18an ordered pair of numeric input fields separated by a comma (if the decimal edit mode is POINT) or 19semicolon (if the decimal edit mode is COMMA), and followed by a right parenthesis. The first numeric 20input field is the real part of the complex constant and the second is the imaginary part. Each of the 21numeric input fields may be preceded or followed by any number of blanks and ends of records. The end 22of a record may occur after the real part or before the imaginary part. 23When the next effective item is of type logical, the input form shall not include value separators among 24the optional characters permitted for L editing. 25When the next effective item is of type character, the input form consists of a possibly delimited sequence 26of zero or more rep-chars whose kind type parameter is implied by the kind of the effective list item. 27Character sequences may be continued from the end of one record to the beginning of the next record, 28but the end of record shall not occur between a doubled apostrophe in an apostrophe-delimited character 29sequence, nor between a doubled quote in a quote-delimited character sequence. The end of the record 30does not cause a blank or any other character to become part of the character sequence. The character 31sequence may be continued on as many records as needed. The characters blank, comma, semicolon, 32and slash may appear in default, ASCII, or ISO 10646 character sequences. 33If the next effective item is of type default, ASCII, or ISO 10646 character and (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 39the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the 40character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), 41semicolon (if the decimal edit mode is COMMA), slash, or end of record; in this case apostrophes and quotation marks within the datum are not to be doubled. 279 J3/07-007 WORKING DRAFT 2006/01/05 1Let len be the length of the next effective item, and let w be the length of the character sequence. If 2len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 3effective item. If len is greater than w, the sequence is transmitted to the leftmost w characters of the 4next effective item and the remaining len-w characters of the next effective item are filled with blanks. 5The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment statement (7.2.1.3). 6 710.10.3.1 Null values 8A null value is specified by (1) the r* form, 9 (2) no characters between consecutive value separators, or 10 11 (3) no characters before the first value separator in the first record read by each execution of a 12 list-directed input statement. 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. 13A null value has no effect on the definition status of the next effective item. A null value shall not be 14used for either the real or imaginary part of a complex constant, but a single null value may represent 15an entire complex constant. 16A slash encountered as a value separator during execution of a list-directed input statement causes 17termination of execution of that input statement after the transference of the previous value. Any 18characters remaining in the current record are ignored. If there are additional items in the input list, the 19effect is as if null values had been supplied for them. Any do-variable in the input list becomes defined 20as if enough null values had been supplied for any remaining input list items. 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$ 280 2006/01/05 WORKING DRAFT J3/07-007 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 2The form of the values produced is the same as that required for input, except as noted otherwise. With 3the exception of adjacent undelimited character sequences, the values are separated by one or more 4blanks or by a comma, or a semicolon if the decimal edit mode is comma, optionally preceded by one or 5more blanks and optionally followed by one or more blanks. 6The processor may begin new records as necessary, but the end of record shall not occur within a constant 7except as specified for complex constants and character sequences. The processor shall not insert blanks 8within character sequences or within constants, except as specified for complex constants. 9Logical output values are T for the value true and F for the value false. 10Integer output constants are produced with the effect of an Iw edit descriptor. 11Bits output constants are produced with the effect of a Zw.m edit descriptor with w and m equal to CEILING(k/4.0) where k is the kind type parameter value of the list item. 12 13Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, 14depending on the magnitude x of the value and a range 10d1 x < 10d2, where d1 and d2 are processor- 15dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 160PFw.d; otherwise, 1PEw.d Ee is used. 17For numeric output, reasonable processor-dependent values of w, d, and e are used for each of the 18numeric constants output. 19Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, 20each produced as defined above for real constants. The separator is a comma if the decimal edit mode is 21POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between 22the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire 23record. The only embedded blanks permitted within a complex constant are between the separator and 24the end of a record and one blank at the beginning of the next record. 25Character sequences produced when the delimiter mode has a value of NONE (1) are not delimited by apostrophes or quotation marks, 26 (2) are not separated from each other by value separators, 27 28 (3) have each internal apostrophe or quotation mark represented externally by one apostrophe 29 or quotation mark, and 30 (4) have a blank character inserted by the processor at the beginning of any record that begins 31 with the continuation of a character sequence from the preceding record. 281 J3/07-007 WORKING DRAFT 2006/01/05 1Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, 2are preceded and followed by a value separator, and have each internal quote represented on the external 3medium by two contiguous quotes. 4Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited 5by apostrophes, are preceded and followed by a value separator, and have each internal apostrophe 6represented on the external medium by two contiguous apostrophes. 7If two or more successive values in an output record have identical values, the processor has the option 8of producing a repeated constant of the form r*c instead of the sequence of identical values. 9Slashes, as value separators, and null values are not produced as output by list-directed formatting. 10Except for continuation of delimited character sequences, each output record begins with a blank char- 11acter. NOTE 10.33 The length of the output records is not specified and may be processor dependent. 10.11 Namelist formatting 12 1310.11.1 General 14Namelist input/output allows data editing with NAME=value subsequences. This facilitates documen- 15tation of input and output files and more flexibility on input. 10.11.2 Name-value subsequences 16 17The characters in one or more namelist records constitute a sequence of name-value subsequences, 18each of which consists of an object designator followed by an equals and followed by one or more values 19and value separators. The equals may optionally be preceded or followed by one or more contiguous 20blanks. The end of a record has the same effect as a blank character, unless it is within a character 21constant. Any sequence of two or more consecutive blanks is treated as a single blank, unless it is within 22a character constant. 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 26Input for a namelist input statement consists of (1) optional blanks and namelist comments, 27 28 (2) the character & followed immediately by the namelist-group-name as specified in the NAME- 29 LIST statement, (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. 282 2006/01/05 WORKING DRAFT J3/07-007 1In each name-value subsequence, the name shall be the name of a namelist group object list item with 2an optional qualification and the name with the optional qualification shall not be a zero-sized array, a 3zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not 4contain a vector subscript. 5A group name or object name is without regard to case. 610.11.3.1 Namelist group object names 7Within the input data, each name shall correspond to a particular namelist group object name. Sub- 8scripts, strides, and substring range expressions used to qualify group object names shall be optionally 9signed integer literal constants with no kind type parameters specified. If a namelist group object is 10an array, the input record corresponding to it may contain either the array name or the designator of 11a subobject of that array, using the syntax of object designators (R603). If the namelist group object 12name is the name of a variable of derived type, the name in the input record may be either the name of 13the variable or the designator of one of its components, indicated by qualifying the variable name with 14the appropriate component name. Successive qualifications may be applied as appropriate to the shape 15and type of the variable represented. 16The order of names in the input records need not match the order of the namelist group object items. 17The input records need not contain all the names of the namelist group object items. The definition 18status of any names from the namelist-group-object-list that do not occur in the input record remains 19unchanged. In the input record, each object name or subobject designator may be preceded and followed 20by one or more optional blanks but shall not contain embedded blanks. 2110.11.3.2 Namelist group object list items 22The name-value subsequences are evaluated serially, in left-to-right order. A namelist group object 23designator may appear in more than one name-value sequence. 24When the name in the input record represents an array variable or a variable of derived type, the effect 25is as if the variable represented were expanded into a sequence of scalar list items, in the same way that 26formatted input/output list items are expanded (9.5.3). Each input value following the equals shall then 27be acceptable to format specifications for the type of the list item in the corresponding position in the 28expanded sequence, except as noted in this subclause. The number of values following the equals shall 29not exceed the number of list items in the expanded sequence, but may be less; in the latter case, the 30effect is as if sufficient null values had been appended to match any remaining list items in the expanded 31sequence. 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. 32A slash encountered as a value separator during the execution of a namelist input statement causes 33termination of execution of that input statement after transference of the previous value. If there are 34additional items in the namelist group object being transferred, the effect is as if null values had been 35supplied for them. 36A namelist comment may appear after any value separator except a slash. A namelist comment is also 37permitted to start in the first nonblank position of an input record except within a character literal 38constant. 39Successive namelist records are read by namelist input until a slash is encountered; the remainder of the 40record is ignored and need not follow the rules for namelist input values. 283 J3/07-007 WORKING DRAFT 2006/01/05 110.11.3.3 Namelist input values 2Each value is either a null value (10.11.3.4), c, r*c, or r*, where c is a literal constant, optionally signed 3if integer or real, and r is an unsigned, nonzero, integer literal constant. A kind type parameter shall not 4be specified for c or r. The constant c is interpreted as though it had the same kind type parameter as 5the corresponding effective item. The r*c form is equivalent to r successive appearances of the constant 6c, and the r* form is equivalent to r successive null values. Neither of these forms may contain embedded 7blanks, except where permitted within the constant c. 8The datum c (10.11) is any input value acceptable to format specifications for a given type, except for 9a restriction on the form of input values corresponding to list items of types logical, integer, bits, and 10character as specified in this subclause. The form of a real or complex value is dependent on the decimal 11edit mode in effect (10.6). The form of an input value shall be acceptable for the type of the namelist 12group object list item. The number and forms of the input values that may follow the equals in a name- 13value subsequence depend on the shape and type of the object represented by the name in the input 14record. When the name in the input record is that of a scalar variable of an intrinsic type, the equals 15shall not be followed by more than one value. Blanks are never used as zeros, and embedded blanks are 16not permitted in constants except within character constants and complex constants as specified in this 17subclause. 18When the next effective namelist group object list item is of type real, the input form of the input value 19is that of a numeric input field. A numeric input field is a field suitable for F editing (10.7.2.3.2) that is 20assumed to have no fractional digits unless a decimal symbol appears within the field. 21When the next effective item is of type complex, the input form of the input value consists of a left 22parenthesis followed by an ordered pair of numeric input fields separated by a comma (if the decimal 23edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA), and followed by a right 24parenthesis. The first numeric input field is the real part of the complex constant and the second part 25is the imaginary part. Each of the numeric input fields may be preceded or followed by any number of 26blanks and ends of records. The end of a record may occur between the real part and the comma or 27semicolon, or between the comma or semicolon and the imaginary part. 28When the next effective item is of type logical, the input form of the input value shall not include equals or value separators among the optional characters permitted for L editing (10.7.3). 29 30When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 31edit descriptor with a suitable value of w were used. 32When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 33descriptor with a suitable value of w were used. 34When the next effective item is of type character, the input form consists of a delimited sequence of zero 35or more rep-chars whose kind type parameter is implied by the kind of the corresponding list item. Such 36a sequence may be continued from the end of one record to the beginning of the next record, but the 37end of record shall not occur between a doubled apostrophe in an apostrophe-delimited sequence, nor 38between a doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or 39any other character to become part of the sequence. The sequence may be continued on as many records 40as needed. The characters blank, comma, semicolon, and slash may appear in such character sequences. 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). 284 2006/01/05 WORKING DRAFT J3/07-007 1Let len be the length of the next effective item, and let w be the length of the character sequence. If 2len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 3effective item. If len is greater than w, the constant is transmitted to the leftmost w characters of the 4next effective item and the remaining len-w characters of the next effective item are filled with blanks. 5The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment statement (7.2.1.3). 6 710.11.3.4 Null values 8A null value is specified by (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 13A null value has no effect on the definition status of the corresponding input list item. If the namelist 14group object list item is defined, it retains its previous value; if it is undefined, it remains undefined. A 15null value shall not be used as either the real or imaginary part of a complex constant, but a single null 16value may represent an entire complex constant. 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. 1710.11.3.5 Blanks 18All blanks in a namelist input record are considered to be part of some value separator except for (1) blanks embedded in a character constant, 19 (2) embedded blanks surrounding the real or imaginary part of a complex constant, 20 21 (3) leading blanks following the equals unless followed immediately by a slash or comma, or a 22 semicolon if the decimal edit mode is comma, and (4) blanks between a name and the following equals. 23 2410.11.3.6 Namelist Comments 25Except within a character literal constant, a "!" character after a value separator or in the first nonblank 26position of a namelist input record initiates a comment. The comment extends to the end of the current 27input record and may contain any graphic character in the processor-dependent character set. The 28comment is ignored. A slash within the namelist comment does not terminate execution of the namelist 29input statement. Namelist comments are not allowed in stream input because comments depend on 30record structure. 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: 285 J3/07-007 WORKING DRAFT 2006/01/05 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 2The form of the output produced is the same as that required for input, except for the forms of real, 3character, and logical values. The name in the output is in upper case. With the exception of adjacent 4undelimited character values, the values are separated by one or more blanks or by a comma, or a 5semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and optionally 6followed by one or more blanks. 7Namelist output shall not include namelist comments. 8The processor may begin new records as necessary. However, except for complex constants and character 9values, the end of a record shall not occur within a constant, character value, or name, and blanks shall 10not appear within a constant, character value, or name. NOTE 10.39 The length of the output records is not specified exactly and may be processor dependent. 1110.11.4.1 Namelist output editing 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. 1310.11.4.2 Namelist output records 14If two or more successive values for the same namelist group item in an output record produced have 15identical values, the processor has the option of producing a repeated constant of the form r*c instead 16of the sequence of identical values. 17The name of each namelist group object list item is placed in the output record followed by an equals 18and a list of values of the namelist group object list item. 19An ampersand character followed immediately by a namelist-group-name will be produced by namelist 20formatting at the start of the first output record to indicate which particular group of data objects is being output. A slash is produced by namelist formatting to indicate the end of the namelist formatting. 286 2006/01/05 WORKING DRAFT J3/07-007 1A null value is not produced by namelist formatting. 2Except for new records created by explicit formatting within a user-defined derived-type output pro- 3cedure or by continuation of delimited character sequences, each output record begins with a blank 4character. 287 J3/07-007 WORKING DRAFT 2006/01/05 288 2006/01/05 WORKING DRAFT J3/07-007 11 Program units 1 11.1 Main program 2 3A Fortran main program is a program unit that does not contain a SUBROUTINE, FUNCTION, 4MODULE, SUBMODULE, or BLOCK DATA statement as its first statement. 5R1101 main-program is [ program-stmt ] 6 [ specification-part ] 7 [ execution-part ] 8 [ internal-subprogram-part ] 9 end-program-stmt 10R1102 program-stmt is PROGRAM program-name R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] 11 12C1101 (R1101) In a main-program, the execution-part shall not contain a RETURN statement or an 13 ENTRY statement. 14C1102 (R1101) The program-name may be included in the end-program-stmt only if the optional 15 program-stmt is used and, if included, shall be identical to the program-name specified in the 16 program-stmt. 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 17The main program may be defined by means other than Fortran; in that case, the program shall not 18contain a main-program program unit. 19A reference to a Fortran main-program shall not appear in any program unit in the program, including 20itself. 2111.2 Modules 289 J3/07-007 WORKING DRAFT 2006/01/05 111.2.1 General 2A module contains specifications and definitions that are to be accessible to other program units by use 3association. A module that is provided as an inherent part of the processor is an intrinsic module. A 4nonintrinsic module is defined by a module program unit or a means other than Fortran. 5Procedures and types defined in an intrinsic module are not themselves intrinsic. 6R1104 module is module-stmt 7 [ specification-part ] 8 [ module-subprogram-part ] 9 end-module-stmt 10R1105 module-stmt is MODULE module-name R1106 end-module-stmt is END [ MODULE [ module-name ] ] 11 12R1107 module-subprogram-part is contains-stmt [ module-subprogram ] ... 13 14R1108 module-subprogram is function-subprogram 15 or subroutine-subprogram 16 or separate-module-subprogram 17C1103 (R1104) If the module-name is specified in the end-module-stmt, it shall be identical to the 18 module-name specified in the module-stmt. 19C1104 (R1104) A module specification-part shall not contain a stmt-function-stmt, an entry-stmt, or a 20 format-stmt. 21C1105 (R1104) If an object that has a default-initialized direct component is declared in the specifica- 22 tion part of a module it shall have the ALLOCATABLE, POINTER, or SAVE attribute. 23C1106 If an object that has a co-array ultimate component is declared in the specification-part of a 24 module it shall have the SAVE attribute. 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. 290 2006/01/05 WORKING DRAFT J3/07-007 NOTE 11.5 For a discussion of the impact of modules on dependent compilation, see subclause C.8.2. NOTE 11.6 For examples of the use of modules, see subclause C.8.3. 1If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the 2EXTERNAL attribute in that scoping unit; if it is a function, its type and type parameters shall be 3explicitly declared in a type declaration statement in that scoping unit. 4If an intrinsic procedure is declared in the scoping unit of a module, it shall explicitly be given the 5INTRINSIC attribute in that scoping unit or be used as an intrinsic procedure in that scoping unit. 611.2.2 The USE statement and use association 7The USE statement specifies use association. A USE statement is a reference to the module it 8specifies. At the time a USE statement is processed, the public portions of the specified module shall 9be available. A module shall not reference itself, either directly or indirectly. A submodule shall not 10reference its ancestor module by use association, either directly or indirectly. NOTE 11.7 It is possible for submodules with different ancestor modules to reference each others' ancestor modules by use association. 11The USE statement provides the means by which a scoping unit accesses named data objects, derived 12types, interface blocks, procedures, abstract interfaces, module procedure interfaces, generic identifiers, 13macros, and namelist groups in a module. The entities in the scoping unit are use associated with the 14entities in the module. The accessed entities have the attributes specified in the module, except that an 15entity may have a different accessibility attribute or it may have the ASYNCHRONOUS or VOLATILE 16attribute in the local scoping unit even if the associated module entity does not. The entities made 17accessible are identified by the names or generic identifiers used to identify them in the module. By 18default, they are identified by the same identifiers in the scoping unit containing the USE statement, 19but it is possible to specify that different local identifiers are used. 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). 20R1109 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename-list ] 21 or USE [ [ , module-nature ] :: ] module-name , ONLY : [ only-list ] 22 23R1110 module-nature is INTRINSIC 24 or NON INTRINSIC 25R1111 rename is local-name => use-name 26 or OPERATOR (local-defined-operator) => OPERATOR (use-defined-operator) 27 28R1112 only is generic-spec 29 or only-use-name 291 J3/07-007 WORKING DRAFT 2006/01/05 1 or rename 2R1113 only-use-name is use-name C1107 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. 3 4C1108 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic 5 module. 6C1109 (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the 7 same name. C1110 (R1111) OPERATOR(use-defined-operator) shall not identify a type-bound generic interface. 8 C1111 (R1112) The generic-spec shall not identify a type-bound generic interface. 9 NOTE 11.9 The above two constraints do not prevent accessing a generic-spec that is declared by an interface block, even if a type-bound generic interface has the same generic-spec. C1112 (R1112) Each generic-spec shall be a public entity in the module. 10 C1113 (R1113) Each use-name shall be the name of a public entity in the module. 11 12R1114 local-defined-operator is defined-unary-op 13 or defined-binary-op 14R1115 use-defined-operator is defined-unary-op 15 or defined-binary-op C1114 (R1115) Each use-defined-operator shall be a public entity in the module. 16 17A use-stmt without a module-nature provides access either to an intrinsic or to a nonintrinsic module. 18If the module-name is the name of both an intrinsic and a nonintrinsic module, the nonintrinsic module 19is accessed. 20The USE statement without the ONLY option provides access to all public entities in the specified 21module. 22A USE statement with the ONLY option provides access only to those entities that appear as generic- 23specs, use-names, or use-defined-operators in the only-list. 24More than one USE statement for a given module may appear in a scoping unit. If one of the USE 25statements is without an ONLY option, all public entities in the module are accessible. If all the USE 26statements have ONLY options, only those entities in one or more of the only-lists are accessible. 27An accessible entity in the referenced module has one or more local identifiers. These identifiers are 28 (1) the identifier of the entity in the referenced module if that identifier appears as an only-use- 29 name or as the defined-operator of a generic-spec in any only for that module, 30 (2) each of the local-names or local-defined-operators that the entity is given in any rename for 31 that module, and 32 (3) the identifier of the entity in the referenced module if that identifier does not appear as a 33 use-name or use-defined-operator in any rename for that module. 34Two or more accessible entities, other than generic interfaces or defined operators, may have the same 35identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces 36and defined operators are handled as described in 12.4.3.4 and 12.4.3.4.5. Except for these cases, the 292 2006/01/05 WORKING DRAFT J3/07-007 1local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers 2of all other entities accessible to the scoping unit through USE statements and otherwise. 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. 3The local identifier of an entity made accessible by a USE statement shall not appear in any other 4nonexecutable statement that would cause any attribute (5.3) of the entity to be specified in the scoping 5unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE statement 6in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE attribute. 7The appearance of such a local identifier in a PUBLIC statement in a module causes the entity accessible 8by the USE statement to be a public entity of that module. If the identifier appears in a PRIVATE 9statement in a module, the entity is not a public entity of that module. If the local identifier does not 10appear in either a PUBLIC or PRIVATE statement, it assumes the default accessibility attribute (5.4.1) 11of that scoping unit. 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. 1211.2.3 Submodules 293 J3/07-007 WORKING DRAFT 2006/01/05 1A submodule is a program unit that extends a module or another submodule. The program unit that 2it extends is its parent, and is specified by the parent-identifier in the submodule-stmt. A submodule 3is a child of its parent. An ancestor of a submodule is its parent or an ancestor of its parent. A 4descendant of a module or submodule is one of its children or a descendant of one of its children. The 5submodule identifier is the ordered pair whose first element is the ancestor module name and whose 6second element is the submodule name. 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). 7 8A submodule may provide implementations for module procedures, each of which is declared by a module 9procedure interface body (12.4.3.2) within that submodule or one of its ancestors, and declarations and 10definitions of other entities that are accessible by host association in its descendants. 11R1116 submodule is submodule-stmt 12 [ specification-part ] 13 [ module-subprogram-part ] 14 end-submodule-stmt R1117 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name 15 R1118 parent-identifier is ancestor-module-name [ : parent-submodule-name ] 16 R1119 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ] 17 18C1115 (R1116) A submodule specification-part shall not contain a format-stmt, entry-stmt, or stmt- 19 function-stmt. 20C1116 (R1116) An object with a default-initialized direct component that is declared in the specification 21 part of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. 22C1117 (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- 23 submodule-name shall be the name of a descendant of that module. 24C1118 (R1116) If a submodule-name appears in the end-submodule-stmt, it shall be identical to the one 25 in the submodule-stmt. 11.3 Block data program units 26 27A block data program unit is used to provide initial values for data objects in named common blocks. 28R1120 block-data is block-data-stmt 29 [ specification-part ] 30 end-block-data-stmt R1121 block-data-stmt is BLOCK DATA [ block-data-name ] 31 R1122 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ] 32 33C1119 (R1120) The block-data-name shall be included in the end-block-data-stmt only if it was provided 34 in the block-data-stmt and, if included, shall be identical to the block-data-name in the block- 35 data-stmt. 294 2006/01/05 WORKING DRAFT J3/07-007 1C1120 (R1120) A block-data specification-part shall contain only derived-type definitions and ASYN- 2 CHRONOUS, BIND, COMMON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRIN- 3 SIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration 4 statements. 5C1121 (R1120) A type declaration statement in a block-data specification-part shall not contain AL- 6 LOCATABLE, EXTERNAL, or BIND attribute specifiers. NOTE 11.15 For explanatory information about the uses for the block-data-name, see subclause C.8.1. 7If an object in a named common block is initially defined, all storage units in the common block storage 8sequence shall be specified even if they are not all initially defined. More than one named common block 9may have objects initially defined in a single block data program unit. 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. 10Only an object in a named common block may be initially defined in a block data program unit. NOTE 11.17 Objects associated with an object in a common block are considered to be in that common block. 11The same named common block shall not be specified in more than one block data program unit in a 12program. 13There shall not be more than one unnamed block data program unit in a program. 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 295 J3/07-007 WORKING DRAFT 2006/01/05 296 2006/01/05 WORKING DRAFT J3/07-007 112 Procedures 12.1 Concepts 2 3The concept of a procedure was introduced in 2.2.4. This clause contains a complete description of 4procedures. The actions specified by a procedure are performed when the procedure is invoked by 5execution of a reference to it. 6The sequence of actions encapsulated by a procedure has access to entities in the invoking scoping 7unit by way of argument association (12.5.2). A dummy argument is a name that appears in the 8SUBROUTINE, FUNCTION, or ENTRY statement in the declaration of a procedure (R1235). Dummy 9arguments are also specified for intrinsic procedures and procedures in intrinsic modules in Clauses 13, 1014, and 15. 11The entities in the invoking scoping unit are specified by actual arguments. An actual argument is an entity that appears in a procedure reference (R1223). 12 13A procedure may also have access to entities in other scoping units, not necessarily the invoking scoping 14unit, by use association (16.5.1.3), host association (16.5.1.4), linkage association (16.5.1.5), storage association (16.5.3), or by reference to external procedures (5.3.8). 15 1612.2 Procedure classifications 12.2.1 Procedure classification by reference 17 18The definition of a procedure specifies it to be a function or a subroutine. A reference to a function 19either appears explicitly as a primary within an expression, or is implied by a defined operation (7.1.6) 20within an expression. A reference to a subroutine is a CALL statement, a defined assignment statement 21(7.2.1.4), the appearance of an object processed by user-defined derived-type input/output (9.5.4.7) in 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 2512.2.2.1 Intrinsic procedures 26A procedure that is provided as an inherent part of the processor is an intrinsic procedure. 2712.2.2.2 External, internal, and module procedures 28An external procedure is a procedure that is defined by an external subprogram or by a means other 29than Fortran. 30An internal procedure is a procedure that is defined by an internal subprogram. Internal subprograms 31may appear in the main program, in an external subprogram, or in a module subprogram. Internal 32subprograms shall not appear in other internal subprograms. Internal subprograms are the same as 33external subprograms except that the name of the internal procedure is not a global identifier, an 34internal subprogram shall not contain an ENTRY statement, and the internal subprogram has access to 35host entities by host association. 297 J3/07-007 WORKING DRAFT 2006/01/05 1A module procedure is a procedure that is defined by a module subprogram. 2A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement. If the subprogram 3has one or more ENTRY statements, it also defines a procedure for each of them. 412.2.2.3 Dummy procedures 5A dummy argument that is specified to be a procedure or appears in a procedure reference is a dummy 6procedure. A dummy procedure with the POINTER attribute is a dummy procedure pointer. 712.2.2.4 Procedure pointers 8A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes; it may be 9pointer associated with an external procedure, an internal procedure, an intrinsic procedure, a module 10procedure, or a dummy procedure that is not a procedure pointer. 1112.2.2.5 Statement functions 12 A function that is defined by a single statement is a statement function (12.6.4). 1312.3 Characteristics 12.3.1 Characteristics of procedures 14 15The characteristics of a procedure are the classification of the procedure as a function or subroutine, 16whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its 17dummy arguments, and the characteristics of its result value if it is a function. 12.3.2 Characteristics of dummy arguments 18 1912.3.2.1 General 20Each dummy argument has the characteristic that it is a dummy data object, a dummy procedure, a 21dummy procedure pointer, or an asterisk (alternate return indicator). A dummy argument other than an asterisk 22may be specified to have the OPTIONAL attribute. This attribute means that the dummy argument 23need not be associated with an actual argument for any particular reference to the procedure. 2412.3.2.2 Characteristics of dummy data objects 25The characteristics of a dummy data object are its type, its type parameters (if any), its shape, its 26co-rank, its co-dimensions, its intent (5.3.9, 5.4.8), whether it is optional (5.3.11, 5.4.9), whether it is 27allocatable (5.3.7.4), whether it has the ASYNCHRONOUS (5.3.4), CONTIGUOUS (5.3.6), VALUE 28(5.3.17), or VOLATILE (5.3.18) attributes, whether it is polymorphic, and whether it is a pointer 29(5.3.13, 5.4.11) or a target (5.3.16, 5.4.14). If a type parameter of an object or a bound of an array is not 30an initialization expression, the exact dependence on the entities in the expression is a characteristic. If 31a shape, size, or type parameter is assumed or deferred, it is a characteristic. 3212.3.2.3 Characteristics of dummy procedures and dummy procedure pointers 33The characteristics of a dummy procedure are the explicitness of its interface (12.4.2), its characteristics 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 3512.3.2.4 Characteristics of asterisk dummy arguments 36 An asterisk as a dummy argument has no characteristics. 298 2006/01/05 WORKING DRAFT J3/07-007 112.3.3 Characteristics of function results 2The characteristics of a function result are its type, type parameters (if any), rank, whether it is poly- 3morphic, whether it is allocatable, whether it is a pointer, whether it has the CONTIGUOUS attribute, 4and whether it is a procedure pointer. If a function result is an array that is not allocatable or a pointer, 5its shape is a characteristic. If a type parameter of a function result or a bound of a function result 6array is not an initialization expression, the exact dependence on the entities in the expression is a 7characteristic. If type parameters of a function result are deferred, which parameters are deferred is a 8characteristic. If the length of a character function result is assumed, this is a characteristic. 912.4 Procedure interface 1012.4.1 General 11The interface of a procedure determines the forms of reference through which it may be invoked. 12The procedure's interface consists of its abstract interface, its name, its binding label if any, and the 13procedure's generic identifiers, if any. The characteristics of a procedure are fixed, but the remainder 14of the interface may differ in different scoping units, except that for a separate module procedure body 15(12.6.2.5), the dummy argument names, binding label, and whether it is recursive shall be the same as in its corresponding module procedure interface body (12.4.3.2). 16 17An abstract interface consists of procedure characteristics and the names of dummy arguments. NOTE 12.1 For more explanatory information on procedure interfaces, see C.9.3. 12.4.2 Implicit and explicit interfaces 18 19If a procedure is accessible in a scoping unit, its interface is either explicit or implicit in that scoping 20unit. The interface of an internal procedure, module procedure, or intrinsic procedure is always explicit 21in such a scoping unit. The interface of a subroutine or a function with a separate result name is explicit 22within the subprogram that defines it. The interface of a statement function is always implicit. The interface of 23an external procedure or dummy procedure is explicit in a scoping unit other than its own if an interface body (12.4.3.2) for the procedure is supplied or accessible, and implicit otherwise. 24 NOTE 12.2 For example, the subroutine LLS of C.8.3.5 has an explicit interface. 2512.4.2.1 Explicit interface 26A procedure other than a statement function shall have an explicit interface if it is referenced and (1) a reference to the procedure appears 27 (a) with an argument keyword (12.5.2), 28 (b) in a context that requires it to be pure, or 29 30 (c) with an argument that it not of type bits corresponding to a dummy argument of 31 type bits, (2) the procedure has a dummy argument that 32 33 (a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, 34 VALUE, or VOLATILE attribute, (b) is an assumed-shape array, 35 299 J3/07-007 WORKING DRAFT 2006/01/05 (c) is a co-array, 1 (d) is of a parameterized derived type, or 2 (e) is polymorphic, 3 (3) the procedure has a result that 4 (a) is an array, 5 (b) is a pointer or is allocatable, or 6 (c) has a nonassumed type parameter value that is not an initialization expression, 7 (4) the procedure is elemental, or 8 (5) the procedure has the BIND attribute. 9 12.4.3 Specification of the procedure interface 10 1112.4.3.1 General 12The interface for an internal, external, module, or dummy procedure is specified by a FUNCTION, 13SUBROUTINE, or ENTRY statement and by specification statements for the dummy arguments and 14the result of a function. These statements may appear in the procedure definition, in an interface body, 15or both, except that the ENTRY statement shall not appear in an interface body. NOTE 12.3 An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit. However, the name of a procedure may appear in a PROCEDURE statement in an interface block (12.4.3.2). 1612.4.3.2 Interface block 17R1201 interface-block is interface-stmt 18 [ interface-specification ] ... 19 end-interface-stmt 20R1202 interface-specification is interface-body 21 or procedure-stmt 22R1203 interface-stmt is INTERFACE [ generic-spec ] 23 or ABSTRACT INTERFACE R1204 end-interface-stmt is END INTERFACE [ generic-spec ] 24 25R1205 interface-body is function-stmt 26 [ specification-part ] 27 end-function-stmt 28 or subroutine-stmt 29 [ specification-part ] 30 end-subroutine-stmt R1206 procedure-stmt is [ MODULE ] PROCEDURE [ :: ] procedure-name-list 31 32R1207 generic-spec is generic-name 33 or OPERATOR ( defined-operator ) 34 or ASSIGNMENT ( = ) 35 or dtio-generic-spec 300 2006/01/05 WORKING DRAFT J3/07-007 1R1208 dtio-generic-spec is READ (FORMATTED) 2 or READ (UNFORMATTED) 3 or WRITE (FORMATTED) or WRITE (UNFORMATTED) 4 5C1201 (R1201) An interface-block in a subprogram shall not contain an interface-body for a procedure 6 defined by that subprogram. 7C1202 (R1201) The generic-spec shall be included in the end-interface-stmt only if it is provided in the 8 interface-stmt. If the end-interface-stmt includes generic-name, the interface-stmt shall specify 9 the same generic-name. If the end-interface-stmt includes ASSIGNMENT(=), the interface- 10 stmt shall specify ASSIGNMENT(=). If the end-interface-stmt includes dtio-generic-spec, the 11 interface-stmt shall specify the same dtio-generic-spec. If the end-interface-stmt includes OP- 12 ERATOR(defined-operator), the interface-stmt shall specify the same defined-operator. If one 13 defined-operator is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the corre- sponding operator <, <=, >, >=, ==, or /=. 14 15C1203 (R1203) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the 16 function-stmt or the subroutine-name in the subroutine-stmt shall not be the same as a keyword 17 that specifies an intrinsic type. C1204 (R1202) A procedure-stmt is allowed only in an interface block that has a generic-spec. 18 19C1205 (R1205) An interface-body of a pure procedure shall specify the intents of all dummy arguments 20 except pointer, alternate return, and procedure arguments. 21C1206 (R1205) An interface-body shall not contain an entry-stmt, data-stmt, format-stmt, or stmt- 22 function-stmt. 23C1207 (R1206) A procedure-name shall have an explicit interface and shall refer to an accessible pro- 24 cedure pointer, external procedure, dummy procedure, or module procedure. 25C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in that statement shall 26 be accessible in the current scope as a module procedure. 27C1209 (R1206) A procedure-name shall not specify a procedure that is specified previously in any 28 procedure-stmt in any accessible interface with the same generic identifier. 29An external or module subprogram specifies a specific interface for the procedures defined in that 30subprogram. Such a specific interface is explicit for module procedures and implicit for external proce- 31dures. 32An interface block introduced by ABSTRACT INTERFACE is an abstract interface block. An 33interface body in an abstract interface block specifies an abstract interface. An interface block with a 34generic specification is a generic interface block. An interface block with neither ABSTRACT nor a 35generic specification is a specific interface block. 36The name of the entity declared by an interface body is the function-name in the function-stmt or the 37subroutine-name in the subroutine-stmt that begins the interface body. 38A module procedure interface body is an interface body whose initial statement contains the 39keyword MODULE. It defines the module procedure interface for a separate module procedure 40(12.6.2.5). A separate module procedure is accessible by use association if and only if its interface body 41is declared in the specification part of a module and is public. If a corresponding (12.6.2.5) separate 42module procedure is not defined, the interface may be used to specify an explicit specific interface but 43the procedure shall not be used in any other way. 301 J3/07-007 WORKING DRAFT 2006/01/05 C1210 (R1205) A module procedure interface body shall not appear in an abstract interface block. 1 2An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an 3explicit specific interface for an external procedure or a dummy procedure. If the name of the declared 4procedure is that of a dummy argument in the subprogram containing the interface body, the procedure 5is a dummy procedure; otherwise, it is an external procedure. 6An interface body specifies all of the characteristics of the explicit specific interface or abstract interface. 7The specification part of an interface body may specify attributes or define values for data entities that 8do not determine characteristics of the procedure. Such specifications have no effect. 9If an explicit specific interface is specified by an interface body or a procedure declaration statement 10(12.4.3.6) for an external procedure, the characteristics shall be consistent with those specified in the 11procedure definition, except that the interface may specify a procedure that is not pure if the procedure 12is defined to be pure. An interface for a procedure named by an ENTRY statement may be specified by 13using the entry name as the procedure name in the interface body. If an external procedure does not 14exist in the program, an interface body for it may be used to specify an explicit specific interface but 15the procedure shall not be used in any other way. An explicit specific interface may be specified by an 16interface body for an external procedure that does not exist in the program if the procedure is never 17used in any way. A procedure shall not have more than one explicit specific interface in a given scoping 18unit. NOTE 12.4 The dummy argument names in an interface body may be different from the corresponding dummy argument names in the procedure definition because the name of a dummy argument is not a characteristic. NOTE 12.5 An example of a specific interface block is: INTERFACE SUBROUTINE EXT1 (X, Y, Z) REAL, DIMENSION (100, 100) :: X, Y, Z END SUBROUTINE EXT1 SUBROUTINE EXT2 (X, Z) REAL X COMPLEX (KIND = 4) Z (2000) END SUBROUTINE EXT2 FUNCTION EXT3 (P, Q) LOGICAL EXT3 INTEGER P (1000) LOGICAL Q (1000) END FUNCTION EXT3 END INTERFACE This interface block specifies explicit interfaces for the three external procedures EXT1, EXT2, and EXT3. Invocations of these procedures may use argument keywords (12.5.2); for example: PRINT *, EXT3 (Q = P_MASK (N+1 : N+1000), P = ACTUAL_P) 1912.4.3.3 IMPORT statement R1209 import-stmt is IMPORT [[ :: ] import-name-list ] 20 302 2006/01/05 WORKING DRAFT J3/07-007 1C1211 (R1209) The IMPORT statement is allowed only in an interface-body that is not a module 2 procedure interface body. C1212 (R1209) Each import-name shall be the name of an entity in the host scoping unit. 3 4The IMPORT statement specifies that the named entities from the host scoping unit are accessible in 5the interface body by host association. An entity that is imported in this manner and is defined in the 6host scoping unit shall be explicitly declared prior to the interface body. The name of an entity made 7accessible by an IMPORT statement shall not appear in any of the contexts described in 16.5.1.4 that 8cause the host entity of that name to be inaccessible. 9Within an interface body, if an IMPORT statement with no import-name-list appears, each host entity 10not named in an IMPORT statement also is made accessible by host association if its name does not 11appear in any of the contexts described in 16.5.1.4 that cause the host entity of that name to be 12inaccessible. If an entity that is made accessible by this means is accessed by host association and is 13defined in the host scoping unit, it shall be explicitly declared prior to the interface body. NOTE 12.6 The IMPORT statement can be used to allow module procedures to have dummy arguments that are procedures with assumed-shape arguments of an opaque type. For example: MODULE M TYPE T PRIVATE ! T is an opaque type ... END TYPE CONTAINS SUBROUTINE PROCESS(X,Y,RESULT,MONITOR) TYPE(T),INTENT(IN) :: X(:,:),Y(:,:) TYPE(T),INTENT(OUT) :: RESULT(:,:) INTERFACE SUBROUTINE MONITOR(ITERATION_NUMBER,CURRENT_ESTIMATE) IMPORT T INTEGER,INTENT(IN) :: ITERATION_NUMBER TYPE(T),INTENT(IN) :: CURRENT_ESTIMATE(:,:) END SUBROUTINE END INTERFACE ... END SUBROUTINE END MODULE The MONITOR dummy procedure requires an explicit interface because it has an assumed-shape array argument, but TYPE(T) would not be available inside the interface body without the IM- PORT statement. 1412.4.3.4 Generic interfaces 1512.4.3.4.1 Generic identifiers 16A generic interface block specifies a generic interface for each of the procedures in the interface block. 17The PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, or 18module procedures that have this generic interface. A generic interface is always explicit. 19The generic-spec in an interface-stmt is a generic identifier for all the procedures in the interface 20block. The rules specifying how any two procedures with the same generic identifier shall differ are given 303 J3/07-007 WORKING DRAFT 2006/01/05 1 in 12.4.3.4.5. They ensure that any generic invocation applies to at most one specific procedure. 2 A generic name specifies a single name to reference all of the procedure names in the interface block. 3 A generic name may be the same as any one of the procedure names in the interface block, or the same 4 as any accessible generic name. 5 A generic name may be the same as a derived-type name, in which case all of the procedures in the 6 interface block shall be functions. 7 An interface-stmt having a dtio-generic-spec is an interface for a user-defined derived-type input/output procedure (9.5.4.7). 8 NOTE 12.7 An example of a generic procedure interface is: INTERFACE SWITCH SUBROUTINE INT_SWITCH (X, Y) INTEGER, INTENT (INOUT) :: X, Y END SUBROUTINE INT_SWITCH SUBROUTINE REAL_SWITCH (X, Y) REAL, INTENT (INOUT) :: X, Y END SUBROUTINE REAL_SWITCH SUBROUTINE COMPLEX_SWITCH (X, Y) COMPLEX, INTENT (INOUT) :: X, Y END SUBROUTINE COMPLEX_SWITCH END INTERFACE SWITCH Any of these three subroutines (INT SWITCH, REAL SWITCH, COMPLEX SWITCH) may be referenced with the generic name SWITCH, as well as by its specific name. For example, a reference to INT SWITCH could take the form: CALL SWITCH (MAX_VAL, LOC_VAL) ! MAX_VAL and LOC_VAL are of type INTEGER 912.4.3.4.2 Defined operations 10If OPERATOR is specified in a generic specification, all of the procedures specified in the generic 11interface shall be functions that may be referenced as defined operations (7.1.6, 12.5). In the case of 12functions of two arguments, infix binary operator notation is implied. In the case of functions of one 13argument, prefix operator notation is implied. OPERATOR shall not be specified for functions with no 14arguments or for functions with more than two arguments. The dummy arguments shall be nonoptional 15dummy data objects and shall be specified with INTENT (IN). The function result shall not have assumed 16 character length. If the operator is an intrinsic-operator (R310), the number of function arguments shall 17be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic operation (7.1.5). 18 19A defined operation is treated as a reference to the function. For a unary defined operation, the operand 20corresponds to the function's dummy argument; for a binary operation, the left-hand operand corre- 21sponds to the first dummy argument of the function and the right-hand operand corresponds to the 22second dummy argument. NOTE 12.8 An example of the use of the OPERATOR generic specification is: INTERFACE OPERATOR ( * ) 304 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.8 (cont.) FUNCTION BOOLEAN_AND (B1, B2) LOGICAL, INTENT (IN) :: B1 (:), B2 (SIZE (B1)) LOGICAL :: BOOLEAN_AND (SIZE (B1)) END FUNCTION BOOLEAN_AND END INTERFACE OPERATOR ( * ) This allows, for example SENSOR (1:N) * ACTION (1:N) as an alternative to the function call BOOLEAN_AND (SENSOR (1:N), ACTION (1:N)) ! SENSOR and ACTION are ! of type LOGICAL 1A given defined operator may, as with generic names, apply to more than one function, in which case 2it is generic in exact analogy to generic procedure names. For intrinsic operator symbols, the generic 3properties include the intrinsic operations they represent. Because both forms of each relational operator 4have the same interpretation (7.1.6.2), extending one form (such as <=) has the effect of defining both forms (<= and .LE.). 5 NOTE 12.9 In Fortran 90 and Fortran 95, it was not possible to define operations on pointers because pointer dummy arguments were disallowed from having an INTENT attribute. The restriction against INTENT for pointer dummy arguments is now lifted, so defined operations on pointers are now possible. However, the POINTER attribute cannot be used to resolve generic procedures (12.4.3.4.5), so it is not possible to define a generic operator that has one procedure for pointers and another procedure for nonpointers. 612.4.3.4.3 Defined assignments 7If ASSIGNMENT ( = ) is specified in a generic specification, all the procedures in the generic interface 8shall be subroutines that may be referenced as defined assignments (7.2.1.4). Defined assignment may, 9as with generic names, apply to more than one subroutine, in which case it is generic in exact analogy 10to generic procedure names. 11Each of these subroutines shall have exactly two dummy arguments. The dummy arguments shall be 12nonoptional dummy data objects. The first argument shall have INTENT (OUT) or INTENT (INOUT) 13and the second argument shall have INTENT (IN). Either the second argument shall be an array whose 14rank differs from that of the first argument, the declared types and kind type parameters of the arguments 15shall not conform as specified in Table 7.12, or the first argument shall be of derived type. A defined 16assignment is treated as a reference to the subroutine, with the left-hand side as the first argument 17and the right-hand side enclosed in parentheses as the second argument. The ASSIGNMENT generic 18specification specifies that assignment is extended or redefined. NOTE 12.10 An example of the use of the ASSIGNMENT generic specification is: INTERFACE ASSIGNMENT ( = ) 305 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.10 (cont.) SUBROUTINE LOGICAL_TO_NUMERIC (N, B) INTEGER, INTENT (OUT) :: N LOGICAL, INTENT (IN) :: B END SUBROUTINE LOGICAL_TO_NUMERIC SUBROUTINE CHAR_TO_STRING (S, C) USE STRING_MODULE ! Contains definition of type STRING TYPE (STRING), INTENT (OUT) :: S ! A variable-length string CHARACTER (*), INTENT (IN) :: C END SUBROUTINE CHAR_TO_STRING END INTERFACE ASSIGNMENT ( = ) Example assignments are: KOUNT = SENSOR (J) ! CALL LOGICAL_TO_NUMERIC (KOUNT, (SENSOR (J))) NOTE = '89AB' ! CALL CHAR_TO_STRING (NOTE, ('89AB')) 12.4.3.4.4 User-defined derived-type input/output procedure interfaces 1 2All of the procedures specified in an interface block for a user-defined derived-type input/output proce- 3dure shall be subroutines that have interfaces as described in 9.5.4.7.2. 412.4.3.4.5 Restrictions on generic declarations 5This subclause contains the rules that shall be satisfied by every pair of specific procedures that have 6the same generic identifier within a scoping unit. If a generic procedure is accessed from a module, the 7rules apply to all the specific versions even if some of them are inaccessible by their specific names. NOTE 12.11 In most scoping units, the possible sources of procedures with a particular generic identifier are the accessible interface blocks and the generic bindings other than names for the accessible objects in that scoping unit. In a type definition, they are the generic bindings, including those from a parent type. 8A dummy argument is type, kind, and rank compatible, or TKR compatible, with another dummy 9argument if both have the same rank, and either the first is type compatible with the second and the 10kind type parameters of the first have the same values as the corresponding kind type parameters of the 11second, or the two are bits compatible. 12Two dummy arguments are distinguishable if 13 · one is a procedure and the other is a data object, 14 · they are both data objects or known to be functions, and neither is TKR compatible with the 15 other, 16 · one has the ALLOCATABLE attribute and the other has the POINTER attribute, or 17 · one is a function with nonzero rank and the other is not known to be a function. 18Within a scoping unit, if two procedures have the same generic operator and the same number of 19arguments or both define assignment, one shall have a dummy argument that corresponds by position 20in the argument list to a dummy argument of the other that is distinguishable with it. 306 2006/01/05 WORKING DRAFT J3/07-007 1Within a scoping unit, if two procedures have the same dtio-generic-spec (12.4.3.2), their dtv arguments 2shall be type incompatible or have different kind type parameters. 3Within a scoping unit, two procedures that have the same generic name shall both be subroutines or 4both be functions, and (1) there is a non-passed-object dummy data object in one or the other of them such that 5 6 (a) the number of dummy data objects in one that are nonoptional, are not passed-object, 7 and with which that dummy data object is TKR compatible, possibly including that 8 dummy data object itself, 9 exceeds 10 (b) the number of non-passed-object dummy data objects, both optional and nonoptional, 11 in the other that are not distinguishable with that dummy data object, 12 (2) both have passed-object dummy arguments and the passed-object dummy arguments are 13 distinguishable, or (3) at least one of them shall have both 14 15 (a) a nonoptional non-passed-object dummy argument at an effective position such that 16 either the other procedure has no dummy argument at that effective position or the 17 dummy argument at that position is distinguishable with it, and 18 (b) a nonoptional non-passed-object dummy argument whose name is such that either the 19 other procedure has no dummy argument with that name or the dummy argument 20 with that name is distinguishable with it. 21 and the dummy argument that disambiguates by position shall either be the same as or 22 occur earlier in the argument list than the one that disambiguates by name. 23The effective position of a dummy argument is its position in the argument list after any passed-object 24dummy argument has been removed. 25Within a scoping unit, if a generic name is the same as the name of a generic intrinsic procedure, the 26generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure 27are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure 28from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the 29interface that is referenced. NOTE 12.12 An extensive explanation of the application of these rules is in C.12.2. 3012.4.3.5 EXTERNAL statement An EXTERNAL statement specifies the EXTERNAL attribute (5.3.8) for a list of names. 31 R1210 external-stmt is EXTERNAL [ :: ] external-name-list 32 33The appearance of the name of a block data program unit in an EXTERNAL statement confirms that 34the block data program unit is a part of the program. NOTE 12.13 For explanatory information on potential portability problems with external procedures, see sub- clause C.9.1. NOTE 12.14 An example of an EXTERNAL statement is: 307 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.14 (cont.) EXTERNAL FOCUS 112.4.3.6 Procedure declaration statement 2A procedure declaration statement declares procedure pointers, dummy procedures, and external procedures. It specifies the EXTERNAL attribute (5.3.8) for all entities in the proc-decl-list. 3 4R1211 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] ) [ [ , proc-attr-spec ] ... :: ] proc-decl-list 5 6R1212 proc-interface is interface-name 7 or declaration-type-spec 8R1213 proc-attr-spec is access-spec 9 or proc-language-binding-spec 10 or INTENT ( intent-spec ) 11 or OPTIONAL 12 or POINTER 13 or SAVE R1214 proc-decl is procedure-entity-name [ => proc-pointer-init ] 14 15R1215 interface-name is name 16R1216 proc-pointer-init is null-init 17 or initial-proc-target 18R1217 initial-proc-target is procedure-name 19 20C1213 (R1215) The name shall be the name of an abstract interface or of a procedure that has an 21 explicit interface. If name is declared by a procedure-declaration-stmt it shall be previously 22 declared. If name denotes an intrinsic procedure it shall be one that is listed in 13.6 and not marked with a bullet (·). 23 C1214 (R1215) The name shall not be the same as a keyword that specifies an intrinsic type. 24 25C1215 If a procedure entity has the INTENT attribute or SAVE attribute, it shall also have the 26 POINTER attribute. 27C1216 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall 28 specify an external procedure. C1217 (R1214) If => appears in proc-decl, the procedure entity shall have the POINTER attribute. 29 C1218 (R1217) The procedure-name shall be the name of an initialization target. 30 31C1219 (R1211) If proc-language-binding-spec with a NAME= is specified, then proc-decl-list shall con- 32 tain exactly one proc-decl, which shall neither have the POINTER attribute nor be a dummy 33 procedure. 34C1220 (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an 35 interface-name, and interface-name shall be declared with a proc-language-binding-spec. 36If proc-interface appears and consists of interface-name, it specifies an explicit specific interface (12.4.3.2) 37for the declared procedures or procedure pointers. The abstract interface (12.4) is that specified by the 308 2006/01/05 WORKING DRAFT J3/07-007 1interface named by interface-name. 2If proc-interface appears and consists of declaration-type-spec, it specifies that the declared procedures 3or procedure pointers are functions having implicit interfaces and the specified result type. If a type is 4specified for an external function, its function definition (12.6.2.2) shall specify the same result type and 5type parameters. 6If proc-interface does not appear, the procedure declaration statement does not specify whether the 7declared procedures or procedure pointers are subroutines or functions. 8If a proc-attr-spec other than a proc-language-binding-spec appears, it specifies that the declared proce- 9dures or procedure pointers have that attribute. These attributes are described in 5.3. If a proc-language- 10binding-spec with NAME= appears, it specifies a binding label or its absence, as described in 15.5.2. 11A proc-language-binding-spec without a NAME= is allowed, but is redundant with the proc-interface 12required by C1220. 13A procedure is an initialization target if it is a nonelemental external or module procedure, or a specific intrinsic function listed in 13.6 and not marked with a bullet (·). 14 15If => appears in a proc-decl in a procedure-declaration-stmt it specifies the initial association status 16of the corresponding procedure entity, and implies the SAVE attribute, which may be confirmed by 17explicit specification. If => null-init appears, the procedure entity is initially disassociated. If => 18initial-proc-target appears, the procedure entity is initially associated with the target. 19If proc-entity-name has an explicit interface, its characteristics shall be the same as initial-proc-target 20except that initial-proc-target may be pure even if proc-entity-name is not pure and initial-proc-target 21may be an elemental intrinsic procedure. 22If the characteristics of proc-entity-name or initial-proc-target are such that an explicit interface is 23required, both proc-entity-name and initial-proc-target shall have an explicit interface. 24If proc-entity-name has an implicit interface and is explicitly typed or referenced as a function, initial- 25proc-target shall be a function. If proc-entity-name has an implicit interface and is referenced as a 26subroutine, initial-proc-target shall be a subroutine. 27If initial-proc-target and proc-entity-name are functions, they shall have the same type; corresponding 28type parameters shall either both be deferred or both have the same value. NOTE 12.15 In contrast to the EXTERNAL statement, it is not possible to use the PROCEDURE statement to identify a BLOCK DATA subprogram. NOTE 12.16 The following code illustrates PROCEDURE statements. Note 7.48 illustrates the use of the P and BESSEL defined by this code. ABSTRACT INTERFACE FUNCTION REAL_FUNC (X) REAL, INTENT (IN) :: X REAL :: REAL_FUNC END FUNCTION REAL_FUNC END INTERFACE INTERFACE SUBROUTINE SUB (X) 309 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.16 (cont.) REAL, INTENT (IN) :: X END SUBROUTINE SUB END INTERFACE !-- Some external or dummy procedures with explicit interface. PROCEDURE (REAL_FUNC) :: BESSEL, GFUN PROCEDURE (SUB) :: PRINT_REAL !-- Some procedure pointers with explicit interface, !-- one initialized to NULL(). PROCEDURE (REAL_FUNC), POINTER :: P, R => NULL() PROCEDURE (REAL_FUNC), POINTER :: PTR_TO_GFUN !-- A derived type with a procedure pointer component ... TYPE STRUCT_TYPE PROCEDURE (REAL_FUNC), POINTER :: COMPONENT END TYPE STRUCT_TYPE !-- ... and a variable of that type. TYPE(STRUCT_TYPE) :: STRUCT !-- An external or dummy function with implicit interface PROCEDURE (REAL) :: PSI 112.4.3.7 INTRINSIC statement An INTRINSIC statement specifies the INTRINSIC attribute (5.3.10) for a list of names. 2 R1218 intrinsic-stmt is INTRINSIC [ :: ] intrinsic-procedure-name-list 3 C1221 (R1218) Each intrinsic-procedure-name shall be the name of an intrinsic procedure. 4 NOTE 12.17 A name shall not be explicitly specified to have both the EXTERNAL and INTRINSIC attributes in the same scoping unit. 512.4.3.8 Implicit interface specification 6In a scoping unit where the interface of a function is implicit, the type and type parameters of the 7function result are specified by an implicit or explicit type specification of the function name. The type, 8type parameters, and shape of dummy arguments of a procedure invoked from a scoping unit where the 9interface of the procedure is implicit shall be such that the actual arguments are consistent with the 10characteristics of the dummy arguments. 1112.5 Procedure reference 12.5.1 Syntax 12 13The form of a procedure reference is dependent on the interface of the procedure or procedure pointer, 14but is independent of the means by which the procedure is defined. The forms of procedure references 15are as follows. R1219 function-reference is procedure-designator ( [ actual-arg-spec-list ] ) 16 C1222 (R1219) The procedure-designator shall designate a function. 17 310 2006/01/05 WORKING DRAFT J3/07-007 1 C1223 (R1219) The actual-arg-spec-list shall not contain an alt-return-spec. R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ] 2 C1224 (R1220) The procedure-designator shall designate a subroutine. 3 4 R1221 procedure-designator is procedure-name 5 or proc-component-ref 6 or data-ref % binding-name C1225 (R1221) A procedure-name shall be the name of a procedure or procedure pointer. 7 C1226 (R1221) A binding-name shall be a binding name (4.5.5) of the declared type of data-ref . 8 9 C1227 (R1221) If data-ref is an array, the referenced type-bound procedure shall have the PASS at- 10 tribute. 11 Resolving references to type-bound procedures is described in 12.5.6. 12 A function may also be referenced as a defined operation (12.4.3.4.2). A subroutine may also be ref- 13 erenced as a defined assignment (12.4.3.4.3), by user-defined derived-type input/output (9.5.4.7), or by finalization (4.5.6). 14 NOTE 12.18 If image I executes a procedure reference in which the variable of a proc-component-ref specifies a procedure pointer on image J, the procedure pointer association is fetched from image J but the invocation of the associated procedure occurs on image I. R1222 actual-arg-spec is [ keyword = ] actual-arg 15 16 R1223 actual-arg is expr 17 or variable 18 or procedure-name 19 or proc-component-ref 20 or alt-return-spec 21 R1224 alt-return-spec is * label 22C1228 (R1222) The keyword = shall not appear if the interface of the procedure is implicit in the 23 scoping unit. 24C1229 (R1222) The keyword = shall not be omitted from an actual-arg-spec unless it has been omitted 25 from each preceding actual-arg-spec in the argument list. 26C1230 (R1222) Each keyword shall be the name of a dummy argument in the explicit interface of the 27 procedure. C1231 (R1223) A nonintrinsic elemental procedure shall not be used as an actual argument. 28 29C1232 (R1223) A procedure-name shall be the name of an external, internal, module, or dummy proce- 30 dure, a specific intrinsic function listed in 13.6 and not marked with a bullet (·), or a procedure 31 pointer. 32C1233 (R1224) The label shall be the statement label of a branch target statement that appears in the same scoping 33 unit as the call-stmt. 311 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.19 Successive commas shall not be used to omit optional arguments. NOTE 12.20 Examples of procedure reference using procedure pointers: P => BESSEL WRITE (*, *) P(2.5) !-- BESSEL(2.5) S => PRINT_REAL CALL S(3.14) NOTE 12.21 An internal procedure cannot be invoked using a procedure pointer from either Fortran or C after the host instance completes execution, because the pointer is then undefined. While the host instance is active, however, the internal procedure may be invoked from outside of the host procedure scoping unit if that internal procedure was passed as an actual argument or is the target of a procedure pointer. b Let us assume there is a procedure with the following interface that calculates f(x)dx. a INTERFACE FUNCTION INTEGRATE(F, A, B) RESULT(INTEGRAL) BIND(C) USE ISO_C_BINDING INTERFACE FUNCTION F(X) BIND(C) ! Integrand USE ISO_C_BINDING REAL(C_FLOAT), VALUE :: X REAL(C_FLOAT) :: F END FUNCTION END INTERFACE REAL(C_FLOAT), VALUE :: A, B ! Bounds REAL(C_FLOAT) :: INTEGRAL END FUNCTION INTEGRATE END INTERFACE This procedure can be called from Fortran or C, and could be written in either Fortran or C. The argument F representing the mathematical function f(x) can be written as an internal procedure; this internal procedure will have access to any host instance local variables necessary to actually calculate f(x). For example: REAL FUNCTION MY_INTEGRATION(N, A, B) RESULT(INTEGRAL) ! Integrate f(x)=x^n over [a,b] USE ISO_C_BINDING INTEGER, INTENT(IN) :: N REAL, INTENT(IN) :: A, B INTEGRAL = INTEGRATE(MY_F, REAL(A, C_FLOAT), REAL(B, C_FLOAT)) ! This will call the internal function MY_F to calculate f(x). ! The above interface of INTEGRATE must be explicit and available. CONTAINS 312 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.21 (cont.) REAL(C_FLOAT) FUNCTION MY_F(X) BIND(C) ! Integrand REAL(C_FLOAT), VALUE :: X MY_F = X**N ! N is taken from the host instance of MY_INTEGRATION. END FUNCTION END FUNCTION MY_INTEGRATION The function INTEGRATE shall not save a function pointer to MY F and use it after INTEGRATE has finished execution, because the host instance of MY F might no longer exist, making the pointer undefined. If such a pointer is saved, then it can only be used to invoke MY F during the execution of the host instance of MY INTEGRATION called from INTEGRATE. 12.5.2 Actual arguments, dummy arguments, and argument association 1 212.5.2.1 Argument correspondence 3In either a subroutine reference or a function reference, the actual argument list identifies the corre- 4spondence between the actual arguments supplied and the dummy arguments of the procedure. This 5correspondence may be established either by keyword or by position. If an argument keyword appears, 6the actual argument corresponds to the dummy argument whose name is the same as the argument 7keyword (using the dummy argument names from the interface accessible in the scoping unit containing 8the procedure reference). In the absence of an argument keyword, an actual argument corresponds to the 9dummy argument occupying the corresponding position in the reduced dummy argument list; that is, 10the first actual argument corresponds to the first dummy argument in the reduced list, the second actual 11argument corresponds to the second dummy argument in the reduced list, etc. The reduced dummy 12argument list is either the full dummy argument list or, if there is a passed-object dummy argument 13(4.5.4.4), the dummy argument list with the passed object dummy argument omitted. Exactly one 14actual argument shall correspond to each nonoptional dummy argument. At most one actual argument 15shall correspond to each optional dummy argument. Each actual argument shall correspond to a dummy 16argument. NOTE 12.22 For example, the procedure defined by SUBROUTINE SOLVE (FUNCT, SOLUTION, METHOD, STRATEGY, PRINT) INTERFACE FUNCTION FUNCT (X) REAL FUNCT, X END FUNCTION FUNCT END INTERFACE REAL SOLUTION INTEGER, OPTIONAL :: METHOD, STRATEGY, PRINT ... may be invoked with CALL SOLVE (FUN, SOL, PRINT = 6) provided its interface is explicit; if the interface is specified by an interface block, the name of the last argument shall be PRINT. 313 J3/07-007 WORKING DRAFT 2006/01/05 112.5.2.2 The passed-object dummy argument and argument correspondence 2In a reference to a type-bound procedure, or a procedure pointer component, that has a (4.5.4.4), the 3data-ref of the function-reference or call-stmt corresponds, as an actual argument, with the passed-object 4dummy argument. 512.5.2.3 Argument association 6Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a 7nonoptional nonpointer dummy argument shall be pointer associated with a target. 8If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument 9that is pointer associated with a target, the dummy argument becomes argument associated with that 10target. 11If a present nonpointer dummy argument without the VALUE attribute corresponds to a nonpointer 12actual argument it becomes argument associated with that actual argument. 13A present dummy argument with the VALUE attribute becomes argument associated with a definable 14anonymous data object whose initial value is the value of the actual argument. 15A present pointer dummy argument that corresponds to a pointer actual argument becomes argument 16associated with that actual argument. A present pointer dummy argument that does not correspond to 17a pointer actual argument is not argument associated. 18The entity that is argument-associated with a dummy argument is called its effective argument. 1912.5.2.4 Compatibility with bits objects 20An entity is bits compatible with another entity if and only if one is of type bits, the other is of type 21bits, integer, real, complex, or logical, and scalar entities of these types have the same size expressed in 22bits. J3 internal note Unresolved Technical Issue 016 Can "bits compatible" be folded into a new concept of "type and kind compatible"? 2312.5.2.5 Ordinary dummy variables 24The requirements in this subclause apply to actual arguments that correspond to nonallocatable non- 25pointer dummy data objects. 26The dummy argument shall be type compatible with the actual argument or it shall be of type bits and 27bits compatible with the actual argument. 28Unless the actual argument and the corresponding dummy argument are bits compatible, the type 29parameter values of the actual argument shall agree with the corresponding ones of the dummy argument 30that are not assumed, except for the case of the character length parameter of an actual argument of 31type default character associated with a dummy argument that is not assumed shape. 32If a scalar dummy argument is of type default character, the length len of the dummy argument shall 33be less than or equal to the length of the actual argument. The dummy argument becomes associated 34with the leftmost len characters of the actual argument. If an array dummy argument is of type default 35character and is not assumed shape, it becomes associated with the leftmost characters of the actual argument element sequence (12.5.2.12). 36 37The values of assumed type parameters of a dummy argument are assumed from the corresponding type 314 2006/01/05 WORKING DRAFT J3/07-007 1parameters of the actual argument. 2If the actual argument is a co-indexed object with an allocatable ultimate component, the dummy argument shall have the INTENT(IN) or the VALUE attribute. 3 J3 internal note Unresolved Technical Issue 050 Note that this does not match the edit in 06-319r3, but I believe it correctly reflects the technical discussion therein. Remove this UTI if that is correct, and if the requirement is good. NOTE 12.23 If the actual argument is a co-indexed object, a processor that uses distributed memory might create a copy on the executing image of the actual argument, including copies of any allocated allocatable subcomponents, and associate the dummy argument with that copy. If necessary, on return from the procedure, the value of the copy would be copied back to the actual argument. 4Except in references to intrinsic inquiry functions, if the dummy argument is nonoptional and the actual 5argument is allocatable, the corresponding actual argument shall be allocated. NOTE 12.24 Fortran argument association is usually similar to call by reference and call by value-result. If the VALUE attribute is specified, the effect is as if the actual argument is assigned to a temporary, and the temporary is then argument associated with the dummy argument. Subsequent changes to the value or definition status of the dummy argument do not affect the actual argument. The actual mechanism by which this happens is determined by the processor. 6If the dummy argument does not have the TARGET attribute, or is not type-compatible with the 7actual argument, any pointers associated with the effective argument do not become associated with the 8corresponding dummy argument on invocation of the procedure. If such a dummy argument is used as 9an actual argument that corresponds to a dummy argument with the TARGET attribute, whether any 10pointers associated with the original effective argument become associated with the dummy argument 11with the TARGET attribute is processor dependent. 12If the dummy argument has the TARGET attribute, is type-compatible with the actual argument, does 13not have the VALUE attribute, and is either a scalar or an assumed-shape array that does not have the 14CONTIGUOUS attribute, and the effective argument has the TARGET attribute but is not a co-indexed 15object or an array section with a vector subscript then 16 (1) any pointers associated with the effective argument become associated with the correspond- 17 ing dummy argument on invocation of the procedure, and 18 (2) when execution of the procedure completes, any pointers that do not become undefined 19 (16.5.2.2.3) and are associated with the dummy argument remain associated with the effec- 20 tive argument. 21If the dummy argument has the TARGET attribute and is an explicit-shape array, an assumed-shape 22array with the CONTIGUOUS attribute, or an assumed-size array, and the effective argument has the 23TARGET attribute but is not an array section with a vector subscript then 24 (1) on invocation of the procedure, whether any pointers associated with the effective argument 25 become associated with the corresponding dummy argument is processor dependent, and 26 (2) when execution of the procedure completes, the pointer association status of any pointer 27 that is pointer associated with the dummy argument is processor dependent. 28If the dummy argument has the TARGET attribute and the effective argument does not have the 315 J3/07-007 WORKING DRAFT 2006/01/05 1TARGET attribute or is an array section with a vector subscript, or the dummy argument is not 2type-compatible with the actual argument, any pointers associated with the dummy argument become 3undefined when execution of the procedure completes. 4If the dummy argument has the TARGET attribute and the VALUE attribute, any pointers associated 5with the dummy argument become undefined when execution of the procedure completes. 6If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual 7argument is of type default character, of type character with the C character kind (15.2), or is an element 8or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array. If 9the procedure is nonelemental and is referenced by a generic name or as a defined operator or defined 10assignment, the ranks of the actual arguments and corresponding dummy arguments shall agree. 11If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as 12the rank of the dummy argument; the actual argument shall not be an assumed-size array (including an array element designator or an array element substring designator). 13 14Except when a procedure reference is elemental (12.8), each element of an array actual argument or of 15a sequence in a sequence association (12.5.2.12) is associated with the element of the dummy array that has the same position in array element order (6.2.2.1). 16 NOTE 12.25 For type default character sequence associations, the interpretation of element is provided in 12.5.2.12. 17A scalar dummy argument of a nonelemental procedure shall be associated only with a scalar actual 18argument. 19If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. 20If a dummy argument has INTENT (OUT), the actual argument becomes undefined at the time the 21association is established, except for direct components of an object of derived type for which default 22initialization has been specified. If the dummy argument is not polymorphic and the type of the effective 23argument is an extension type of the type of the dummy argument, only the part of the effective argument 24that is of the same type as the dummy argument becomes undefined. 25If the actual argument is an array section having a vector subscript, the dummy argument is not defin- 26able and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE 27attributes. NOTE 12.26 Argument intent specifications serve several purposes. See Note 5.16. NOTE 12.27 For more explanatory information on argument association and evaluation, see subclause C.9.5. For more explanatory information on targets as dummy arguments, see subclause C.9.6. 28C1234 An actual argument that is a co-indexed object shall not correspond to a dummy argument that 29 has either the ASYNCHRONOUS or VOLATILE attribute. 30C1235 (R1223) If an actual argument is an array section or an assumed-shape array, and the corre- 31 sponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that 32 dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS 33 attribute. 316 2006/01/05 WORKING DRAFT J3/07-007 1C1236 (R1223) If an actual argument is a pointer array, and the corresponding dummy argument 2 has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an 3 assumed-shape array that does not have the CONTIGUOUS attribute or a pointer array. J3 internal note Unresolved Technical Issue 097 So, consider this example. INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:),q(:) ... CALL s(p,q) ! Constraint violation associating P with A p = q ! No constraint violation because ! syntax is not being used. Hmm, maybe this should be an interp? Is there any doubt as to our intention? Is there any doubt the standard does not reflect that intention? NOTE 12.28 The constraints on actual arguments that correspond to a dummy argument with either the ASYN- CHRONOUS or VOLATILE attribute are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism. Making a copy of actual arguments whose values are likely to change due to an asynchronous I/O operation completing or in some unpredictable manner will cause those new values to be lost when a called procedure returns and the copy-out overwrites the actual argument. 412.5.2.6 Allocatable and pointer dummy variables 5The requirements in this subclause apply to actual arguments that correspond to either allocatable or 6pointer dummy data objects. 7The actual argument shall be polymorphic if and only if the associated dummy argument is polymorphic, 8and either both the actual and dummy arguments shall be unlimited polymorphic, or the declared type 9of the actual argument shall be the same as the declared type of the dummy argument. NOTE 12.29 The dynamic type of a polymorphic allocatable or pointer dummy argument may change as a result of execution of an allocate statement or pointer assignment in the subprogram. Because of this the corresponding actual argument needs to be polymorphic and have a declared type that is the same as the declared type of the dummy argument or an extension of that type. However, type compatibility requires that the declared type of the dummy argument be the same as, or an extension of, the type of the actual argument. Therefore, the dummy and actual arguments need to have the same declared type. Dynamic type information is not maintained for a nonpolymorphic allocatable or pointer dummy argument. However, allocating or pointer assigning such a dummy argument would require main- tenance of this information if the corresponding actual argument is polymorphic. Therefore, the corresponding actual argument needs to be nonpolymorphic. 317 J3/07-007 WORKING DRAFT 2006/01/05 1The rank of the actual argument shall be the same as that of the dummy argument. The type parameter 2values of the actual argument shall agree with the corresponding ones of the dummy argument that are 3not assumed or deferred. 4The values of assumed type parameters of a dummy argument are assumed from the corresponding type 5parameters of the associated actual argument. 6The actual argument shall have deferred the same type parameters as the dummy argument. 7If the actual argument is a co-indexed object, the dummy argument shall have the INTENT(IN) at- 8tribute. J3 internal note Unresolved Technical Issue 096 Co-indexed actual to pointer/allocatable dummy. In the interests of preventing remote allocation/deallocation or remote pointer assignment, in accordance with the reasoning in 06-319r3, it would seem necessary to have the above requirement specified somewhere. This seems like the obvious place to have it: this subclause contains those requirements which apply both to allocatable dummies and to pointer dummies. It's possible that the requirement already exists somewhere else, in which case it's superfluous here ... but the authors of 06-319r3 clearly didn't think so, at least in the allocatable case. If this requirement is too onerous for the pointer case, just move the above sentence to the next subclause, which applies only to the allocatable case. Note that this might have some "consistency" interaction with what is left of UTI 050. 912.5.2.7 Allocatable dummy variables 10The requirements in this subclause apply to actual arguments that correspond to allocatable dummy 11data objects. 12The actual argument shall be allocatable. It is permissible for the actual argument to have an allocation 13status of unallocated. 14If the dummy argument does not have the TARGET attribute, any pointers associated with the ac- 15tual argument do not become associated with the corresponding dummy argument on invocation of the 16procedure. If such a dummy argument is used as an actual argument that is associated with a dummy ar- 17gument with the TARGET attribute, whether any pointers associated with the original actual argument 18become associated with the dummy argument with the TARGET attribute is processor dependent. 19If the dummy argument has the TARGET attribute, does not have the INTENT(OUT) or VALUE 20attribute, and the corresponding actual argument has the TARGET attribute then 21 (1) any pointers associated with the actual argument become associated with the corresponding 22 dummy argument on invocation of the procedure, and 23 (2) when execution of the procedure completes, any pointers that do not become undefined 24 (16.5.2.2.3) and are associated with the dummy argument remain associated with the actual 25 argument. 26If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. 27If a dummy argument has INTENT (OUT), an allocated actual argument is deallocated on procedure invocation (6.3.3.1). 28 2912.5.2.8 Pointer dummy variables 30The requirements in this subclause apply to actual arguments that correspond to dummy data pointers. 31If the dummy argument does not have the INTENT(IN) attribute, the actual argument shall be a 318 2006/01/05 WORKING DRAFT J3/07-007 1pointer. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in 2a pointer assignment statement. If the actual argument is not a pointer, the dummy pointer becomes 3pointer-associated with the actual argument. 4The nondeferred type parameters and ranks shall agree. 5If the dummy pointer has the CONTIGUOUS attribute and the actual argument does not have the 6CONTIGUOUS attribute, the actual argument shall satisfy the following conditions. 7 · Its base object shall either have the CONTIGUOUS attribute or shall not be a pointer or assumed- 8 shape array. 9 · It shall not be the real or imaginary part of an array of type complex. 10 · Its designator shall not contain a substring-range. 11 · It shall not have a vector subscript. 12 · Only its final part-ref shall have nonzero rank. 13 · If that part-ref has a section-subscript-list, the section-subscript-list shall satisfy these conditions: 14 ­ no stride shall appear; 15 ­ if any section-subscript is a subscript, it shall not be followed by a subscript-triplet; 16 ­ all but the last subscript-triplet shall consist of a single colon with no subscript. NOTE 12.30 This requires that the actual argument be obviously contiguous at compile time. Columns, planes, cubes and hypercubes of contiguous base objects can be passed, for example: ARRAY1 (10:20, 3) ! passes part of the third column of ARRAY1. X3D (:, i:j, 2) ! passes part of the second plane of X3D (or the whole ! plane if i==LBOUND(X3D,2) and j==UBOUND(X3D,2). Y5D (:, :, :, :, 7) ! passes the seventh hypercube of Y5D. 17If the dummy argument has INTENT(OUT), the pointer association status of the actual argument 18becomes undefined on invocation of the procedure. 19If the dummy argument is nonoptional and the actual argument is allocatable, the actual argument shall 20be allocated. NOTE 12.31 For more explanatory information on pointers as dummy arguments, see subclause C.9.6. 2112.5.2.9 Co-array arguments 22If the dummy argument is an allocatable co-array, the actual argument shall be an allocatable co-array 23with the same rank and co-rank. 24If a dummy argument is a nonallocatable co-array, the co-rank and co-bounds are specified by the local 25declaration and are independent of those of the actual argument. The actual argument shall be a co-array 26or a subobject of a co-array without any co-subscripts, vector-valued subscripts, non-co-array allocatable 27component selection, or pointer component selection. 319 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.32 The co-array on the executing image is specified as the actual argument and this is associated with the dummy co-array argument on the same image. There are corresponding co-arrays on the other images. For example: INTERFACE SUBROUTINE SUB(X, Y) REAL :: X(:)[*], Y(:)[*] END SUBROUTINE SUB END INTERFACE ... REAL, ALLOCATABLE :: A(:)[:], B(:,:)[:] ... CALL SUB(A(:), B(1,:)) NOTE 12.33 The bounds and co-bounds of a dummy co-array may differ on each image executing a reference to the procedure. A co-indexed data-ref always uses the bounds and co-bounds on the executing image. 1If the dummy argument is a co-array that has the CONTIGUOUS attribute or is not of assumed shape, 2the actual argument shall be compile-time contiguous. J3 internal note Unresolved Technical Issue 101 Use of undefined term "compile-time contiguous". This term has not been defined. According to a straw vote taken at meeting 178, it ought to be. NOTE 12.34 The requirements on an actual argument that corresponds to a dummy co-array that is not of assumed-shape or has the CONTIGUOUS attribute are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism. 312.5.2.10 Actual arguments associated with dummy procedure entities 4If the actual argument is the name of an internal subprogram, the host instance of the dummy argument 5is the innermost currently executing instance of the host of that internal subprogram. If the actual 6argument has a host instance the host instance of the dummy argument is that instance. Otherwise the 7dummy argument has no host instance. 8If a dummy argument is a procedure pointer, the associated actual argument shall be a procedure pointer, 9a reference to a function that returns a procedure pointer, a reference to the NULL intrinsic function, or 10a valid target for the dummy pointer in a pointer assignment statement. If the actual argument is not 11a pointer, the dummy argument shall have the INTENT(IN) attribute and becomes pointer associated 12with the actual argument. 13If a dummy argument is a dummy procedure without the POINTER attribute, the associated actual 14argument shall be an external, internal, module, or dummy procedure, or a specific intrinsic procedure 15listed in 13.6 and not marked with a bullet (·). If the specific name is also a generic name, only the 16specific procedure is associated with the dummy argument. 17If an external procedure name or a dummy procedure name is used as an actual argument, its interface 320 2006/01/05 WORKING DRAFT J3/07-007 1shall be explicit or it shall be explicitly declared to have the EXTERNAL attribute. 2If the interface of a dummy procedure is explicit, the characteristics listed in 12.3.1 shall be the same 3for the associated actual argument and the corresponding dummy argument, except that a pure actual 4argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which is prohibited from being elemental). 5 6If the interface of a dummy procedure is implicit and either the dummy argument is explicitly typed 7or referenced as a function, it shall not be referenced as a subroutine and any corresponding actual 8argument shall be a function, function procedure pointer, or dummy procedure. 9If the interface of a dummy procedure is implicit and a reference to it appears as a subroutine reference, 10any corresponding actual argument shall be a subroutine, subroutine procedure pointer, or dummy 11procedure. 1212.5.2.11 Actual arguments associated with alternate return indicators 13 If a dummy argument is an asterisk (12.6.2.3), the associated actual argument shall be an alternate return specifier (12.5). 1412.5.2.12 Sequence association 15An actual argument represents an element sequence if it is an array expression, an array element 16designator, a scalar of type default character, or a scalar of type character with the C character kind 17(15.2.2). If the actual argument is an array expression, the element sequence consists of the elements 18in array element order. If the actual argument is an array element designator, the element sequence 19consists of that array element and each element that follows it in array element order. 20If the actual argument is of type default character or of type character with the C character kind, and is 21an array expression, array element, or array element substring designator, the element sequence consists 22of the storage units beginning with the first storage unit of the actual argument and continuing to the 23end of the array. The storage units of an array element substring designator are viewed as array elements 24consisting of consecutive groups of storage units having the character length of the dummy array. 25If the actual argument is of type default character or of type character with the C character kind, and 26is a scalar that is not an array element or array element substring designator, the element sequence 27consists of the storage units of the actual argument. NOTE 12.35 Some of the elements in the element sequence may consist of storage units from different elements of the original array. 28An actual argument that represents an element sequence and corresponds to a dummy argument that is 29an array is sequence associated with the dummy argument if the dummy argument is an explicit-shape 30or assumed-size array. The rank and shape of the actual argument need not agree with the rank and 31shape of the dummy argument, but the number of elements in the dummy argument shall not exceed 32the number of elements in the element sequence of the actual argument. If the dummy argument is 33assumed-size, the number of elements in the dummy argument is exactly the number of elements in the 34element sequence. 3512.5.2.13 Argument presence and restrictions on arguments not present 36A dummy argument or an entity that is host associated with a dummy argument is not present if the 37dummy argument (1) does not correspond to an actual argument, 38 321 J3/07-007 WORKING DRAFT 2006/01/05 (2) corresponds to an actual argument that is not present, or 1 2 (3) does not have the ALLOCATABLE or POINTER attribute, and corresponds to an actual 3 argument that (a) has the ALLOCATABLE attribute and is not allocated, or 4 (b) has the POINTER attribute and is disassociated. 5 6Otherwise, it is present. A nonoptional dummy argument shall be present. If an optional nonpointer 7dummy argument corresponds to a pointer actual argument, the pointer association status of the actual 8argument shall not be undefined. 9An optional dummy argument that is not present is subject to the following restrictions. 10 (1) If it is a data object, it shall not be referenced or be defined. If it is of a type for which 11 default initialization is specified for a direct component, the initialization has no effect. (2) It shall not be used as the data-target or proc-target of a pointer assignment. 12 (3) If it is a procedure or procedure pointer, it shall not be invoked. 13 14 (4) It shall not be supplied as an actual argument corresponding to a nonoptional dummy 15 argument other than as the argument of the PRESENT intrinsic function or as an argument of a function reference that meets the requirements of (6) or (8) in 7.1.12. 16 17 (5) A designator with it as the base object and with at least one subobject selector shall not 18 be supplied as an actual argument. 19 (6) If it is an array, it shall not be supplied as an actual argument to an elemental procedure 20 unless an array of the same rank is supplied as an actual argument corresponding to a 21 nonoptional dummy argument of that elemental procedure. 22 (7) If it is a pointer, it shall not be allocated, deallocated, nullified, pointer-assigned, or supplied 23 as an actual argument corresponding to an optional nonpointer dummy argument. 24 (8) If it is allocatable, it shall not be allocated, deallocated, or supplied as an actual argument 25 corresponding to an optional nonallocatable dummy argument. (9) If it has length type parameters, they shall not be the subject of an inquiry. 26 (10) It shall not be used as the selector in a SELECT TYPE or ASSOCIATE construct. 27 28Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional 29dummy argument, which is then also considered not to be present. 3012.5.2.14 Restrictions on entities associated with dummy arguments 31While an entity is associated with a dummy argument, the following restrictions hold. 32 (1) Action that affects the allocation status of the entity or a subobject thereof shall be taken 33 through the dummy argument. Action that affects the value of the entity or any subobject 34 of it shall be taken only through the dummy argument unless (a) the dummy argument has the POINTER attribute or 35 36 (b) the dummy argument has the TARGET attribute, the dummy argument does not 37 have INTENT (IN), the dummy argument is a scalar object or an assumed-shape 38 array without the CONTIGUOUS attribute, and the actual argument is a target 39 other than an array section with a vector subscript. NOTE 12.36 In SUBROUTINE OUTER REAL, POINTER :: A (:) ... 322 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.36 (cont.) ALLOCATE (A (1:N)) ... CALL INNER (A) ... CONTAINS SUBROUTINE INNER (B) REAL :: B (:) ... END SUBROUTINE INNER SUBROUTINE SET (C, D) REAL, INTENT (OUT) :: C REAL, INTENT (IN) :: D C = D END SUBROUTINE SET END SUBROUTINE OUTER an assignment statement such as A (1) = 1.0 would not be permitted during the execution of INNER because this would be changing A without using B, but statements such as B (1) = 1.0 or CALL SET (B (1), 1.0) would be allowed. Similarly, DEALLOCATE (A) would not be allowed because this affects the allocation of B without using B. In this case, DEALLOCATE (B) also would not be permitted. If B were declared with the POINTER attribute, either of the statements DEALLOCATE (A) and DEALLOCATE (B) would be permitted, but not both. NOTE 12.37 If there is a partial or complete overlap between the actual arguments associated with two different dummy arguments of the same procedure and the dummy arguments have neither the POINTER 323 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.37 (cont.) nor TARGET attribute, the overlapped portions shall not be defined, redefined, or become unde- fined during the execution of the procedure. For example, in CALL SUB (A (1:5), A (3:9)) A (3:5) shall not be defined, redefined, or become undefined through the first dummy argument because it is part of the argument associated with the second dummy argument and shall not be defined, redefined, or become undefined through the second dummy argument because it is part of the argument associated with the first dummy argument. A (1:2) remains definable through the first dummy argument and A (6:9) remains definable through the second dummy argument. NOTE 12.38 This restriction applies equally to pointer targets. In REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) ! The dummy arguments of SUB are neither pointers nor targets. B (3:5) cannot be defined because it is part of the argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument. NOTE 12.39 Because a nonpointer dummy argument declared with INTENT(IN) shall not be used to change the associated actual argument, the associated actual argument remains constant throughout the execution of the procedure. 1 (2) If the allocation status of the entity or a subobject thereof is affected through the dummy 2 argument, then at any time during the execution of the procedure, either before or after the 3 allocation or deallocation, it may be referenced only through the dummy argument. If the 4 value of the entity or any subobject of it is affected through the dummy argument, then at 5 any time during the execution of the procedure, either before or after the definition, it may 6 be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute or 7 8 (b) the dummy argument has the TARGET attribute, the dummy argument does not 9 have INTENT (IN), the dummy argument is a scalar object or an assumed-shape 10 array without the CONTIGUOUS attribute, and the actual argument is a target 11 other than an array section with a vector subscript. NOTE 12.40 In MODULE DATA REAL :: W, X, Y, Z END MODULE DATA PROGRAM MAIN 324 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.40 (cont.) USE DATA ... CALL INIT (X) ... END PROGRAM MAIN SUBROUTINE INIT (V) USE DATA ... READ (*, *) V ... END SUBROUTINE INIT variable X shall not be directly referenced at any time during the execution of INIT because it is being defined through the dummy argument V. X may be (indirectly) referenced through V. W, Y, and Z may be directly referenced. X may, of course, be directly referenced once execution of INIT is complete. NOTE 12.41 The restrictions on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the subprogram, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage. 112.5.3 Function reference 2A function is invoked during expression evaluation by a function-reference or by a defined operation 3(7.1.6). When it is invoked, all actual argument expressions are evaluated, then the arguments are 4associated, and then the function is executed. When execution of the function is complete, the value 5of the function result is available for use in the expression that caused the function to be invoked. The 6characteristics of the function result (12.3.3) are determined by the interface of the function. A reference 7to an elemental function (12.8) is an elemental reference if one or more actual arguments are arrays and 8all array arguments have the same shape. 912.5.4 Subroutine reference 10A subroutine is invoked by execution of a CALL statement, execution of a defined assignment statement 11(7.2.1.4), user-defined derived-type input/output(9.5.4.7.1), or finalization(4.5.6). When a subroutine is 12invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the 13subroutine is executed. When the actions specified by the subroutine are completed, the execution of the 14CALL statement, the execution of the defined assignment statement, the processing of an input or output 15list item, or finalization of an object is also completed. If a CALL statement includes one or more alternate 16 return specifiers among its arguments, control may be transferred to one of the statements indicated, depending on the 17 action specified by the subroutine. A reference to an elemental subroutine (12.8) is an elemental reference if 18there is at least one actual argument corresponding to an INTENT(OUT) or INTENT(INOUT) dummy 19argument, all such actual arguments are arrays, and all actual arguments are conformable. 12.5.5 Resolving named procedure references 20 325 J3/07-007 WORKING DRAFT 2006/01/05 112.5.5.1 Establishment of procedure names 2The rules for interpreting a procedure reference depend on whether the procedure name in the reference 3is established by the available declarations and specifications to be generic in the scoping unit containing 4the reference, is established to be only specific in the scoping unit containing the reference, or is not 5established. 6A procedure name is established to be generic in a scoping unit (1) if that scoping unit contains an interface block with that name; 7 8 (2) if that scoping unit contains an INTRINSIC attribute specification for that name and it is 9 the name of a generic intrinsic procedure; 10 (3) if that scoping unit contains a USE statement that makes that procedure name accessible 11 and the corresponding name in the module is established to be generic; or 12 (4) if that scoping unit contains no declarations of that name, that scoping unit has a host 13 scoping unit, and that name is established to be generic in the host scoping unit. 14A procedure name is established to be only specific in a scoping unit if it is established to be specific 15and not established to be generic. It is established to be specific 16 (1) if that scoping unit contains a module subprogram, internal subprogram, or statement function 17 that defines a procedure with that name; 18 (2) if that scoping unit contains an INTRINSIC attribute specification for that name and it is 19 the name of a specific intrinsic procedure; 20 (3) if that scoping unit contains an explicit EXTERNAL attribute specification (5.3.8) for that 21 name; 22 (4) if that scoping unit contains a USE statement that makes that procedure name accessible 23 and the corresponding name in the module is established to be specific; or 24 (5) if that scoping unit contains no declarations of that name, that scoping unit has a host 25 scoping unit, and that name is established to be specific in the host scoping unit. 26A procedure name is not established in a scoping unit if it is neither established to be generic nor 27established to be specific. 2812.5.5.2 Resolving procedure references to names established to be generic 29If the reference is consistent with a nonelemental reference to one of the specific interfaces of a generic 30interface that has that name and either is in the scoping unit in which the reference appears or is made 31accessible by a USE statement in the scoping unit, the reference is to the specific procedure in the 32interface block that provides that interface. The rules in 12.4.3.4.5 ensure that there can be at most one 33such specific procedure. 34Otherwise, if the reference is consistent with an elemental reference to one of the specific interfaces of 35a generic interface that has that name and either is in the scoping unit in which the reference appears 36or is made accessible by a USE statement in the scoping unit, the reference is to the specific elemental 37procedure in the interface block that provides that interface. The rules in 12.4.3.4.5 ensure that there 38can be at most one such specific elemental procedure. 39Otherwise, if the scoping unit contains either an INTRINSIC attribute specification for that name or 40a USE statement that makes that name accessible from a module in which the corresponding name is 41specified to have the INTRINSIC attribute, and if the reference is consistent with the interface of that 42intrinsic procedure, the reference is to that intrinsic procedure. 43Otherwise, if the scoping unit has a host scoping unit, the name is established to be generic in that host 44scoping unit, and there is agreement between the scoping unit and the host scoping unit as to whether 326 2006/01/05 WORKING DRAFT J3/07-007 1the name is a function name or a subroutine name, the name is resolved by applying the rules in this 2subclause to the host scoping unit. 3Otherwise, if the name is that of an intrinsic procedure and the reference is consistent with that intrinsic 4procedure, the reference is to that intrinsic procedure. NOTE 12.42 These rules allow particular specific procedures of a generic procedure to be used for particular array ranks and a general elemental version to be used for other ranks. For example, given an interface block such as: INTERFACE RANF ELEMENTAL FUNCTION SCALAR_RANF(X) REAL, INTENT(IN) :: X END FUNCTION SCALAR_RANF FUNCTION VECTOR_RANDOM(X) REAL X(:) REAL VECTOR_RANDOM(SIZE(X)) END FUNCTION VECTOR_RANDOM END INTERFACE RANF and a declaration such as: REAL A(10,10), AA(10,10) then the statement A = RANF(AA) is an elemental reference to SCALAR RANF. The statement A(6:10,2) = RANF(AA(6:10,2)) is a nonelemental reference to VECTOR RANDOM. NOTE 12.43 In the USE statement case, it is possible, because of the renaming facility, for the name in the reference to be different from the name of the intrinsic procedure. 512.5.5.3 Resolving procedure references to names established to be only specific 6If the scoping unit contains an interface body or EXTERNAL attribute specification for the name and 7the name is the name of a dummy argument of the scoping unit, the dummy argument is a dummy 8procedure and the reference is to that dummy procedure. That is, the procedure invoked by executing 9that reference is the procedure supplied as the actual argument corresponding to that dummy procedure. 10If the scoping unit contains an interface body or EXTERNAL attribute specification for the name and 11the name is not the name of a dummy argument of the scoping unit, the reference is to an external 12procedure with that name. 13If the scoping unit contains a module subprogram, internal subprogram, or statement function that defines 14a procedure with the name, the reference is to the procedure so defined. 15If the scoping unit contains an INTRINSIC attribute specification for the name, the reference is to the 327 J3/07-007 WORKING DRAFT 2006/01/05 1intrinsic with that name. 2If the scoping unit contains a USE statement that makes a procedure accessible by the name, the 3reference is to that procedure. NOTE 12.44 Because of the renaming facility of the USE statement, the name in the reference may be different from the original name of the procedure. 4If none of the above apply, the scoping unit shall have a host scoping unit, and the reference is resolved 5by applying the rules in this subclause to the host scoping unit. 612.5.5.4 Resolving procedure references to names not established 7If the name is the name of a dummy argument of the scoping unit, the dummy argument is a dummy 8procedure and the reference is to that dummy procedure. That is, the procedure invoked by executing 9that reference is the procedure supplied as the actual argument corresponding to that dummy procedure. 10Otherwise, if the name is the name of an intrinsic procedure, and if there is agreement between the 11reference and the status of the intrinsic procedure as being a function or subroutine, the reference is to 12that intrinsic procedure. 13Otherwise, the reference is to an external procedure with that name. 12.5.6 Resolving type-bound procedure references 14 15If the binding-name in a procedure-designator (R1221) is that of a specific type-bound procedure, the 16procedure referenced is the one bound to that name in the dynamic type of the data-ref . 17If the binding-name in a procedure-designator is that of a generic type bound procedure, the generic 18binding with that name in the declared type of the data-ref is used to select a specific binding using the 19following criteria. 20 (1) If the reference is consistent with one of the specific bindings of that generic binding, that 21 specific binding is selected. 22 (2) Otherwise, the reference shall be consistent with an elemental reference to one of the specific 23 bindings of that generic binding; that specific binding is selected. 24The reference is to the procedure bound to the same name as the selected specific binding in the dynamic 25type of the data-ref . 2612.6 Procedure definition 12.6.1 Intrinsic procedure definition 27 28Intrinsic procedures are defined as an inherent part of the processor. A standard-conforming processor 29shall include the intrinsic procedures described in Clause 13, but may include others. However, a 30standard-conforming program shall not make use of intrinsic procedures other than those described in 31Clause 13. 12.6.2 Procedures defined by subprograms 32 328 2006/01/05 WORKING DRAFT J3/07-007 112.6.2.1 General 2A subprogram defines one or more procedures. A procedure is defined by the initial SUBROUTINE or FUNCTION statement, and each ENTRY statement defines an additional procedure (12.6.2.6). 3 4A subprogram is specified to be elemental (12.8), pure (12.7), recursive, or a separate module subprogram (12.6.2.5) by a prefix-spec in its initial SUBROUTINE or FUNCTION statement. 5 R1225 prefix is prefix-spec [ prefix-spec ] ... 6 7R1226 prefix-spec is declaration-type-spec 8 or ELEMENTAL 9 or IMPURE 10 or MODULE 11 or PURE 12 or RECURSIVE C1237 (R1225) A prefix shall contain at most one of each prefix-spec. 13 C1238 (R1225) A prefix shall not specify both PURE and IMPURE. 14 C1239 (R1225) A prefix shall not specify both ELEMENTAL and RECURSIVE. 15 16C1240 (R1225) A prefix shall not specify ELEMENTAL if proc-language-binding-spec appears in the 17 function-stmt or subroutine-stmt. 18C1241 (R1225) MODULE shall appear only within the function-stmt or subroutine-stmt of a module 19 subprogram or of an interface body that is declared in the scoping unit of a module or submodule. 20C1242 (R1225) If MODULE appears within the prefix in a module subprogram, an accessible module 21 procedure interface having the same name as the subprogram shall be declared in the module 22 or submodule in which the subprogram is defined, or shall be declared in an ancestor of that 23 program unit. 24C1243 (R1225) If MODULE appears within the prefix in a module subprogram, the subprogram shall 25 specify the same characteristics and dummy argument names as its corresponding (12.6.2.5) 26 module procedure interface body. 27C1244 (R1225) If MODULE appears within the prefix in a module subprogram and a binding label 28 is specified, it shall be the same as the binding label specified in the corresponding module 29 procedure interface body. 30C1245 (R1225) If MODULE appears within the prefix in a module subprogram, RECURSIVE shall 31 appear if and only if RECURSIVE appears in the prefix in the corresponding module procedure 32 interface body. 33The RECURSIVE prefix-spec shall appear if any procedure defined by the subprogram directly or indi- 34rectly invokes itself or any other procedure defined by the subprogram. 35If the prefix-spec PURE appears, or the prefix-spec ELEMENTAL appears and IMPURE does not appear, 36the subprogram is a pure subprogram and shall meet the additional constraints of 12.7. 37If the prefix-spec ELEMENTAL appears, the subprogram is an elemental subprogram and shall meet 38the additional constraints of 12.8.1. 3912.6.2.2 Function subprogram 40A function subprogram is a subprogram that has a FUNCTION statement as its first statement. 329 J3/07-007 WORKING DRAFT 2006/01/05 1R1227 function-subprogram is function-stmt 2 [ specification-part ] 3 [ execution-part ] 4 [ internal-subprogram-part ] 5 end-function-stmt 6R1228 function-stmt is [ prefix ] FUNCTION function-name ( [ dummy-arg-name-list ] ) [ suffix ] 7 8C1246 (R1228) If RESULT appears, result-name shall not be the same as function-name and shall not 9 be the same as the entry-name in any ENTRY statement in the subprogram. 10C1247 (R1228) If RESULT appears, the function-name shall not appear in any specification statement 11 in the scoping unit of the function subprogram. 12R1229 proc-language-binding-spec is language-binding-spec 13C1248 (R1229) A proc-language-binding-spec with a NAME= specifier shall not be specified in the 14 function-stmt or subroutine-stmt of an internal procedure, or of an interface body for an abstract 15 interface or a dummy procedure. J3 internal note Unresolved Technical Issue 103 Should a redundant NAME=" be (unnecessarily) required? Paper 06-352r3 takes what we in the U.K. call a "belt and braces" approach. It adds a constraint to force the user to specify NAME=" (no binding label), and just in case it adds a specification that if NAME= is missing entirely, there is no binding label. That is not a good way of proceeding. It is inconsistent with existing practice (dummy procedures). With dummy procedures, the user not only has an "automatic lack of binding label", he is not allowed to specify NAME=. This is certainly the most friendly way to go. There are two possibilities: 1. automatic lack of binding name, as done for dummy procedures (and procedure pointers); 2. manual prohibition of binding name, forcing NAME=". Item (1) is certainly friendlier, and consistent with what we've already done. The only point I can see in favour of (2) is the documentary value of making the user say NAME=" when it is the only option. I think that is pretty marginal value, but others might disagree. To resolve this issue, pick the approach (1) or (2), and do 1. automatic lack of binding name: nothing, just remove the UTI; 2. manual prohibition of binding name: · remove the 15.5.2 text inserted by 06-352r3, · reinstate C1240 from 06-352r3, and · undo my change to C1239. 16C1249 (R1229) If proc-language-binding-spec is specified for a procedure, each of the procedure's dummy 17 arguments shall be a nonoptional interoperable variable (15.3.5, 15.3.6) or a nonoptional interop- 18 erable procedure (15.3.7). If proc-language-binding-spec is specified for a function, the function 19 result shall be an interoperable scalar variable. 20R1230 dummy-arg-name is name 330 2006/01/05 WORKING DRAFT J3/07-007 C1250 (R1230) A dummy-arg-name shall be the name of a dummy argument. 1 2R1231 suffix is proc-language-binding-spec [ RESULT ( result-name ) ] or RESULT ( result-name ) [ proc-language-binding-spec ] 3 R1232 end-function-stmt is END [ FUNCTION [ function-name ] ] 4 C1251 (R1227) An internal function subprogram shall not contain an ENTRY statement. 5 C1252 (R1227) An internal function subprogram shall not contain an internal-subprogram-part. 6 7C1253 (R1232) If a function-name appears in the end-function-stmt, it shall be identical to the function- 8 name specified in the function-stmt. 9The name of the function is function-name. 10The type and type parameters (if any) of the result of the function defined by a function subprogram 11may be specified by a type specification in the FUNCTION statement or by the name of the result 12variable appearing in a type declaration statement in the declaration part of the function subprogram. 13They shall not be specified both ways. If they are not specified either way, they are determined by 14the implicit typing rules in force within the function subprogram. If the function result is an array, 15allocatable, or a pointer, this shall be specified by specifications of the name of the result variable within 16the function body. The specifications of the function result attributes, the specification of dummy 17argument attributes, and the information in the procedure heading collectively define the characteristics of the function (12.3.1). 18 19If RESULT appears, the name of the result variable of the function is result-name and all occurrences 20of the function name in execution-part statements in the scoping unit refer to the function itself. If 21RESULT does not appear, the result variable is function-name and all occurrences of the function name 22in execution-part statements in the scoping unit are references to the result variable. The characteristics 23(12.3.3) of the function result are those of the result variable. On completion of execution of the function, 24the value returned is that of its result variable. If the function result is a pointer, the shape of the value 25returned by the function is determined by the shape of the result variable when the execution of the 26function is completed. If the result variable is not a pointer, its value shall be defined by the function. 27If the function result is a pointer, on return the pointer association status of the result variable shall not 28be undefined. NOTE 12.45 The result variable is similar to any other variable local to a function subprogram. Its existence begins when execution of the function is initiated and ends when execution of the function is terminated. However, because the final value of this variable is used subsequently in the evaluation of the expression that invoked the function, an implementation may wish to defer releasing the storage occupied by that variable until after its value has been used in expression evaluation. NOTE 12.46 An example of a recursive function is: RECURSIVE FUNCTION CUMM_SUM (ARRAY) RESULT (C_SUM) REAL, INTENT (IN), DIMENSION (:) :: ARRAY REAL, DIMENSION (SIZE (ARRAY)) ::C_SUM INTEGER N N = SIZE (ARRAY) IF (N <= 1) THEN C_SUM = ARRAY ELSE 331 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.46 (cont.) N = N / 2 C_SUM (:N) = CUMM_SUM (ARRAY (:N)) C_SUM (N+1:) = C_SUM (N) + CUMM_SUM (ARRAY (N+1:)) END IF END FUNCTION CUMM_SUM NOTE 12.47 The following is an example of the declaration of an interface body with the BIND attribute, and a reference to the procedure declared. USE, INTRINSIC :: ISO_C_BINDING INTERFACE FUNCTION JOE (I, J, R) BIND(C,NAME="FrEd") USE, INTRINSIC :: ISO_C_BINDING INTEGER(C_INT) :: JOE INTEGER(C_INT), VALUE :: I, J REAL(C_FLOAT), VALUE :: R END FUNCTION JOE END INTERFACE INT = JOE(1_C_INT, 3_C_INT, 4.0_C_FLOAT) END PROGRAM The invocation of the function JOE results in a reference to a function with a binding label "FrEd". FrEd may be a C function described by the C prototype int FrEd(int n, int m, float x); 112.6.2.3 Subroutine subprogram 2A subroutine subprogram is a subprogram that has a SUBROUTINE statement as its first 3statement. 4R1233 subroutine-subprogram is subroutine-stmt 5 [ specification-part ] 6 [ execution-part ] 7 [ internal-subprogram-part ] 8 end-subroutine-stmt 9R1234 subroutine-stmt is [ prefix ] SUBROUTINE subroutine-name [ ( [ dummy-arg-list ] ) [ proc-language-binding-spec ] ] 10 C1254 (R1234) The prefix of a subroutine-stmt shall not contain a declaration-type-spec. 11 12R1235 dummy-arg is dummy-arg-name 13 or * R1236 end-subroutine-stmt is END [ SUBROUTINE [ subroutine-name ] ] 14 C1255 (R1233) An internal subroutine subprogram shall not contain an ENTRY statement. 15 332 2006/01/05 WORKING DRAFT J3/07-007 C1256 (R1233) An internal subroutine subprogram shall not contain an internal-subprogram-part. 1 2C1257 (R1236) If a subroutine-name appears in the end-subroutine-stmt, it shall be identical to the 3 subroutine-name specified in the subroutine-stmt. 4The name of the subroutine is subroutine-name. 512.6.2.4 Instances of a subprogram 6When a procedure defined by a subprogram is invoked, an instance of that subprogram is created. 7Execution begins with the first executable construct following the FUNCTION, SUBROUTINE, or 8ENTRY statement specifying the name of the procedure invoked. 9 When a statement function is invoked, an instance of that statement function is created. 10When execution of an instance completes it ceases to exist. 11Each instance has an independent sequence of execution and an independent set of dummy arguments 12and local unsaved data objects. If an internal procedure or statement function in the subprogram is invoked 13by name from an instance of the subprogram or from an internal subprogram or statement function that 14has access to the entities of that instance, the created instance of the internal subprogram or statement 15 function also has access to the entities of that instance of the host subprogram. If an internal procedure 16is invoked via a dummy procedure or procedure pointer, the internal procedure has access to the entities 17of the host instance of that dummy procedure or procedure pointer. 18All other entities are shared by all instances of the subprogram. NOTE 12.48 The value of a saved data object appearing in one instance may have been defined in a previous instance or by initialization in a DATA statement or type declaration statement. 1912.6.2.5 Separate module procedures 20A separate module procedure is a module procedure defined by a separate-module-subprogram, 21by a function-subprogram whose initial statement contains the keyword MODULE, or by a subroutine- 22subprogram whose initial statement contains the keyword MODULE. Its interface is declared by a module 23procedure interface body (12.4.3.2) in the specification-part of the module or submodule in which the 24procedure is defined, or in an ancestor module or submodule. 25R1237 separate-module-subprogram is mp-subprogram-stmt 26 [ specification-part ] 27 [ execution-part ] 28 [ internal-subprogram-part ] 29 end-mp-subprogram-stmt 30R1238 mp-subprogram-stmt is MODULE PROCEDURE procedure-name 31 R1239 end-mp-subprogram-stmt is END [PROCEDURE [procedure-name]] 32 33C1258 (R1237) The procedure-name shall be the same as the name of an accessible module procedure 34 interface that is declared in the module or submodule in which the separate-module-subprogram 35 is defined, or is declared in an ancestor of that program unit. 36 C1259 (R1239) If a procedure-name appears in the end-mp-subprogram-stmt, it shall be identical to the 37 procedure-name in the MODULE PROCEDURE statement. 333 J3/07-007 WORKING DRAFT 2006/01/05 1A module procedure interface body and a subprogram that defines a separate module procedure corre- 2spond if they have the same name, and the module procedure interface is declared in the same program 3unit as the subprogram or is declared in an ancestor of the program unit in which the procedure is 4defined and is accessible by host association from that ancestor. A module procedure interface body 5shall not correspond to more than one subprogram that defines a separate module procedure. NOTE 12.49 A separate module procedure can be accessed by use association only if its interface body is declared in the specification part of a module and is public. 6If a procedure is defined by a separate-module-subprogram, its characteristics are specified by the corre- 7sponding module procedure interface body. 8If a separate module procedure is a function defined by a separate-module-subprogram, the result variable 9name is determined by the FUNCTION statement in the module procedure interface body. Otherwise, 10the result variable name is determined by the FUNCTION statement in the module subprogram. 1112.6.2.6 ENTRY statement 12An ENTRY statement permits a procedure reference to begin with a particular executable statement 13within the function or subroutine subprogram in which the ENTRY statement appears. R1240 entry-stmt is ENTRY entry-name [ ( [ dummy-arg-list ] ) [ suffix ] ] 14 15C1260 (R1240) If RESULT appears, the entry-name shall not appear in any specification or type- 16 declaration statement in the scoping unit of the function program. 17C1261 (R1240) An entry-stmt shall appear only in an external-subprogram or a module-subprogram 18 that does not define a separate module procedure. An entry-stmt shall not appear within an 19 executable-construct. C1262 (R1240) RESULT shall appear only if the entry-stmt is in a function subprogram. 20 21C1263 (R1240) A dummy-arg shall not be an alternate return indicator if the ENTRY statement is in a function 22 subprogram. 23C1264 (R1240) If RESULT appears, result-name shall not be the same as the function-name in the 24 FUNCTION statement and shall not be the same as the entry-name in any ENTRY statement 25 in the subprogram. 26Optionally, a subprogram may have one or more ENTRY statements. 27If the ENTRY statement is in a function subprogram, an additional function is defined by that subpro- 28gram. The name of the function is entry-name and the name of its result variable is result-name or 29is entry-name if no result-name is provided. The characteristics of the function result are specified by 30specifications of the result variable. The dummy arguments of the function are those specified in the 31ENTRY statement. If the characteristics of the result of the function named in the ENTRY statement 32are the same as the characteristics of the result of the function named in the FUNCTION statement, 33their result variables identify the same variable, although their names need not be the same. Otherwise, 34they are storage associated and shall all be nonpointer, nonallocatable scalars of type default integer, 35default real, double precision real, default complex, or default logical. 36If the ENTRY statement is in a subroutine subprogram, an additional subroutine is defined by that 37subprogram. The name of the subroutine is entry-name. The dummy arguments of the subroutine are 38those specified in the ENTRY statement. 334 2006/01/05 WORKING DRAFT J3/07-007 1The order, number, types, kind type parameters, and names of the dummy arguments in an ENTRY 2statement may differ from the order, number, types, kind type parameters, and names of the dummy 3arguments in the FUNCTION or SUBROUTINE statement in the containing subprogram. 4Because an ENTRY statement defines an additional function or an additional subroutine, it is referenced in the same manner as any other function or subroutine (12.5). 5 6In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear 7in an executable statement preceding that ENTRY statement, unless it also appears in a FUNCTION, 8SUBROUTINE, or ENTRY statement that precedes the executable statement. 9In a subprogram, a dummy argument specified in an ENTRY statement shall not appear in an executable 10statement preceding that ENTRY statement, unless it also appears in a FUNCTION, SUBROUTINE, 11or ENTRY statement that precedes the executable statement. 12 In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in the expression 13 of a statement function unless the name is also a dummy argument of the statement function, appears in a FUNCTION 14 or SUBROUTINE statement, or appears in an ENTRY statement that precedes the statement function statement. 15If a dummy argument appears in an executable statement, the execution of the executable statement is 16permitted during the execution of a reference to the function or subroutine only if the dummy argument 17appears in the dummy argument list of the procedure name referenced. 18If a dummy argument is used in a specification expression to specify an array bound or character length 19of an object, the appearance of the object in a statement that is executed during a procedure reference 20is permitted only if the dummy argument appears in the dummy argument list of the procedure name referenced and it is present (12.5.2.13). 21 22A scoping unit containing a reference to a procedure defined by an ENTRY statement may have access to 23an interface body for the procedure. The procedure header for the interface body shall be a FUNCTION 24statement for an entry in a function subprogram and shall be a SUBROUTINE statement for an entry 25in a subroutine subprogram. 26The keyword RECURSIVE is not used in an ENTRY statement. Instead, the presence or absence of 27RECURSIVE in the initial SUBROUTINE or FUNCTION statement controls whether the procedure 28defined by an ENTRY statement is permitted to reference itself or another procedure defined by the 29subprogram. 30The keywords PURE and IMPURE are not used in an ENTRY statement. Instead, the procedure 31defined by an ENTRY statement is pure if and only if the subprogram is a pure subprogram. 32The keyword ELEMENTAL is not used in an ENTRY statement. Instead, the procedure defined by 33an ENTRY statement is elemental if and only if ELEMENTAL is specified in the SUBROUTINE or 34FUNCTION statement. 3512.6.2.7 RETURN statement 36R1241 return-stmt is RETURN [ scalar-int-expr ] C1265 (R1241) The return-stmt shall be in the scoping unit of a function or subroutine subprogram. 37 38C1266 (R1241) The scalar-int-expr is allowed only in the scoping unit of a subroutine subprogram. 39Execution of the RETURN statement completes execution of the instance of the subprogram in which 40it appears. If the expression appears and has a value n between 1 and the number of asterisks in the dummy argument 41 list, the CALL statement that invoked the subroutine transfers control to the statement identified by the nth alternate 42 return specifier in the actual argument list of the referenced procedure. If the expression is omitted or has a value outside 335 J3/07-007 WORKING DRAFT 2006/01/05 1 the required range, there is no transfer of control to an alternate return. 2 Execution of an end-function-stmt, end-mp-subprogram-stmt, or end-subroutine-stmt is equivalent to 3 executing a RETURN statement with no expression. 4 12.6.2.8 CONTAINS statement 5 R1242 contains-stmt is CONTAINS 6 The CONTAINS statement separates the body of a main program, module, submodule, or subpro- 7 gram from any internal or module subprograms it may contain, or it introduces the type-bound procedure part of a derived-type definition (4.5.2). The CONTAINS statement is not executable. 8 12.6.3 Definition and invocation of procedures by means other than Fortran 9 10 A procedure may be defined by means other than Fortran. The interface of a procedure defined by 11 means other than Fortran may be specified by an interface body or procedure declaration statement. If 12 the interface of such a procedure does not have a proc-language-binding-spec, the means by which the 13 procedure is defined are processor dependent. A reference to such a procedure is made as though it were 14 defined by an external subprogram. If the interface of a procedure has a proc-language-binding-spec, the procedure is interoperable (15.5). 15 16 Interoperation with C functions is described in 15.5. NOTE 12.50 For explanatory information on definition of procedures by means other than Fortran, see subclause C.9.2. 1712.6.4 Statement function 18 A statement function is a function defined by a single statement. 19 R1243 stmt-function-stmt is function-name ( [ dummy-arg-name-list ] ) = scalar-expr 20C1267 (R1243) The primaries of the scalar-expr shall be constants (literal and named), references to variables, references 21 to functions and function dummy procedures, and intrinsic operations. If scalar-expr contains a reference to a 22 function or a function dummy procedure, the reference shall not require an explicit interface, the function shall 23 not require an explicit interface unless it is an intrinsic function, the function shall not be a transformational 24 intrinsic, and the result shall be scalar. If an argument to a function or a function dummy procedure is an array, 25 it shall be an array name. If a reference to a statement function appears in scalar-expr, its definition shall have 26 been provided earlier in the scoping unit and shall not be the name of the statement function being defined. 27C1268 (R1243) Named constants in scalar-expr shall have been declared earlier in the scoping unit or made accessible 28 by use or host association. If array elements appear in scalar-expr, the array shall have been declared as an array 29 earlier in the scoping unit or made accessible by use or host association. 30C1269 (R1243) If a dummy-arg-name, variable, function reference, or dummy function reference is typed by the implicit 31 typing rules, its appearance in any subsequent type declaration statement shall confirm this implied type and 32 the values of any implied type parameters. 33C1270 (R1243) The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar. 34C1271 (R1243) A given dummy-arg-name shall not appear more than once in any dummy-arg-name-list. 35C1272 (R1243) Each variable reference in scalar-expr may be either a reference to a dummy argument of the statement function or a reference to a variable accessible in the same scoping unit as the statement function statement. 336 2006/01/05 WORKING DRAFT J3/07-007 1 The definition of a statement function with the same name as an accessible entity from the host shall be preceded by the 2 declaration of its type in a type declaration statement. 3 The dummy arguments have a scope of the statement function statement. Each dummy argument has the same type and 4 type parameters as the entity of the same name in the scoping unit containing the statement function. 5 A statement function shall not be supplied as a procedure argument. 6 The value of a statement function reference is obtained by evaluating the expression using the values of the actual arguments 7 for the values of the corresponding dummy arguments and, if necessary, converting the result to the declared type and 8 type parameters of the function. 9 A function reference in the scalar expression shall not cause a dummy argument of the statement function to become 10 redefined or undefined. 12.7 Pure procedures 11 12A pure procedure is (1) a pure intrinsic procedure (13.1), 13 (2) defined by a pure subprogram, 14 (3) a dummy procedure that has been specified to be PURE, or 15 (4) 16 a statement function that references only pure functions. 17A pure subprogram is a subprogram that has the prefix-spec PURE or that has the prefix-spec ELE- 18MENTAL and does not have the prefix-spec IMPURE. The following additional constraints apply to 19pure subprograms. 20C1273 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data objects have INTENT(IN). 21 22C1274 The specification-part of a pure subroutine subprogram shall specify the intents of all its non- 23 pointer dummy data objects. 24C1275 A local variable of a pure subprogram, or of a BLOCK construct within a pure subprogram, 25 shall not have the SAVE attribute. NOTE 12.51 Variable initialization in a type-declaration-stmt or a data-stmt implies the SAVE attribute; there- fore, such initialization is also disallowed. 26C1276 The specification-part of a pure subprogram shall specify that all its dummy procedures are 27 pure. 28C1277 If a procedure that is neither an intrinsic procedure nor a statement function is used in a context 29 that requires it to be pure, then its interface shall be explicit in the scope of that use. The 30 interface shall specify that the procedure is pure. 31C1278 All internal subprograms in a pure subprogram shall be pure. 32C1279 In a pure subprogram any designator with a base object that is in common or accessed by 33 host or use association, is a dummy argument of a pure function, is a dummy argument with 34 INTENT (IN) of a pure subroutine, or an object that is storage associated with any such variable, 35 shall not be used (1) in a variable definition context (16.6.7), 36 337 J3/07-007 WORKING DRAFT 2006/01/05 (2) as the data-target in a pointer-assignment-stmt, 1 2 (3) as the expr corresponding to a component with the POINTER attribute in a structure- 3 constructor, 4 (4) as the expr of an intrinsic assignment statement in which the variable is of a derived type 5 if the derived type has a pointer component at any level of component selection, or 6 (5) as an actual argument associated with a dummy argument with INTENT (OUT) or IN- TENT (INOUT) or with the POINTER attribute. 7 NOTE 12.52 Item 3 requires that processors be able to determine if entities with the PRIVATE attribute or with private components have a pointer component. 8C1280 Any procedure referenced in a pure subprogram, including one referenced via a defined operation, defined assignment, user-defined derived-type input/output, or finalization, shall be pure. 9 10C1281 A pure subprogram shall not contain a print-stmt, open-stmt, close-stmt, backspace-stmt, endfile- 11 stmt, rewind-stmt, flush-stmt, wait-stmt, or inquire-stmt. 12C1282 A pure subprogram shall not contain a read-stmt or write-stmt whose io-unit is a file-unit- 13 number or *. 14C1283 A pure subprogram shall not contain a stop-stmt. 15C1284 A co-indexed object shall not appear in a variable definition context in a pure subprogram. C1285 A pure subprogram shall not contain an image control statement (8.5.1). 16 NOTE 12.53 The above constraints are designed to guarantee that a pure procedure is free from side effects (modifications of data visible outside the procedure), which means that it is safe to reference it in constructs such as a FORALL assignment-stmt or a DO CONCURRENT construct, where there is no explicit order of evaluation. The constraints on pure subprograms may appear complicated, but it is not necessary for a pro- grammer to be intimately familiar with them. From the programmer's point of view, these con- straints can be summarized as follows: a pure subprogram shall not contain any operation that could conceivably result in an assignment or pointer assignment to a common variable, a variable accessed by use or host association, or an INTENT (IN) dummy argument; nor shall a pure sub- program contain any operation that could conceivably perform any external file input/output or STOP operation. Note the use of the word conceivably; it is not sufficient for a pure subprogram merely to be side-effect free in practice. For example, a function that contains an assignment to a global variable but in a block that is not executed in any invocation of the function is nevertheless not a pure function. The exclusion of functions of this nature is required if strict compile-time checking is to be used. It is expected that most library procedures will conform to the constraints required of pure pro- cedures, and so can be declared pure and referenced in FORALL statements and constructs, DO CONCURRENT constructs, and within user-defined pure procedures. NOTE 12.54 Pure subroutines are included to allow subroutine calls from pure procedures in a safe way, and to allow forall-assignment-stmts to be defined assignments. The constraints for pure subroutines are based on the same principles as for pure functions, except that side effects to INTENT (OUT), 338 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.54 (cont.) INTENT (INOUT), and pointer dummy arguments are permitted. 12.8 Elemental procedures 1 12.8.1 Elemental procedure declaration and interface 2 3An elemental procedure is an elemental intrinsic procedure or a procedure that is defined by an 4elemental subprogram. 5An elemental subprogram has the prefix-spec ELEMENTAL. An elemental subprogram is a pure sub- 6program unless it has the prefix-spec IMPURE. The following additional constraints apply to elemental 7subprograms. 8C1286 All dummy arguments of an elemental procedure shall be scalar non-co-array dummy data 9 objects and shall not have the POINTER or ALLOCATABLE attribute. 10C1287 The result variable of an elemental function shall be scalar and shall not have the POINTER or 11 ALLOCATABLE attribute. 12C1288 In the scoping unit of an elemental subprogram, an object designator with a dummy argument 13 as the base object shall not appear in a specification-expr except as the designator in a type 14 parameter inquiry (6.1.4) or as the argument to one of the intrinsic functions BIT SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6). 15 NOTE 12.55 The restriction on dummy arguments in specification expressions is imposed primarily to facilitate optimization. An example of usage that is not permitted is ELEMENTAL REAL FUNCTION F (A, N) REAL, INTENT (IN) :: A INTEGER, INTENT (IN) :: N REAL :: WORK_ARRAY(N) ! Invalid ... END FUNCTION F An example of usage that is permitted is ELEMENTAL REAL FUNCTION F (A) REAL, INTENT (IN) :: A REAL (SELECTED_REAL_KIND (PRECISION (A)*2)) :: WORK ... END FUNCTION F 12.8.2 Elemental function actual arguments and results 16 17If a generic name or a specific name is used to reference an elemental function, the shape of the result is 18the same as the shape of the actual argument with the greatest rank. If there are no actual arguments 19or the actual arguments are all scalar, the result is scalar. For those elemental functions that have more 20than one argument, all actual arguments shall be conformable. In the array case, the values of the 21elements, if any, of the result are the same as would have been obtained if the scalar function had been 22applied separately, in array element order, to corresponding elements of each array actual argument. 339 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.56 An example of an elemental reference to the intrinsic function MAX: if X and Y are arrays of shape (M, N), MAX (X, 0.0, Y) is an array expression of shape (M, N) whose elements have values MAX (X(I, J), 0.0, Y(I, J)), I = 1, 2, ..., M, J = 1,2, ..., N 12.8.3 Elemental subroutine actual arguments 1 2An elemental subroutine is one that has only scalar dummy arguments, but may have array actual 3arguments. In a reference to an elemental subroutine, either all actual arguments shall be scalar, or 4all actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments shall 5be arrays of the same shape and the remaining actual arguments shall be conformable with them. In 6the case that the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy 7arguments are arrays, the values of the elements, if any, of the results are the same as would be obtained 8if the subroutine had been applied separately, in array element order, to corresponding elements of each 9array actual argument. 10In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and 11FROM dummy arguments may be the same variable and may be associated scalar variables or associated 12array variables all of whose corresponding elements are associated. Apart from this, the actual arguments 13in a reference to an elemental subroutine must satisfy the restrictions of 12.5.2.14. 340 2006/01/05 WORKING DRAFT J3/07-007 13 Intrinsic procedures and modules 1 13.1 Classes of intrinsic procedures 2 3There are four classes of intrinsic procedures: inquiry functions, elemental functions, transformational 4functions, and subroutines. Some intrinsic subroutines are elemental. Some intrinsic subroutines are 5collective. 6An inquiry function is one whose result depends on the properties of one or more of its arguments 7instead of their values; in fact, these argument values may be undefined. Unless the description of 8an inquiry function states otherwise, these arguments are permitted to be unallocated allocatables or 9pointers that are not associated. An elemental intrinsic function is one that is specified for scalar 10arguments, but may be applied to array arguments as described in 12.8. All other intrinsic functions 11are transformational functions; they almost all have one or more array arguments or an array result. 12All standard intrinsic functions are pure. 13The subroutine MOVE ALLOC and the elemental subroutine MVBITS are pure. No other standard 14intrinsic subroutine is pure. 15A collective subroutine is one of the intrinsic subroutines named in 13.5.15. These subroutines accept 16an optional argument TEAM that identifies a team. If the TEAM argument is not present, the team 17consists of all images. The specified team shall include the invoking image. If it is invoked by one image 18of a team, it shall be invoked by the same statement on all images of the team. There is an implicit 19team synchronization at the beginning and end of the execution of a collective subroutine. 20Generic names of standard intrinsic procedures are listed in 13.5. In most cases, generic functions 21accept arguments of more than one type and the type of the result is the same as the type of the 22arguments. Specific names of standard intrinsic functions with corresponding generic names are listed 23in 13.6. 24If an intrinsic procedure is used as an actual argument to a procedure, its specific name shall be used 25and it may be referenced in the called procedure only with scalar arguments. If an intrinsic procedure does not have a specific name, it shall not be used as an actual argument (12.5.2.10). 26 27Elemental intrinsic procedures behave as described in 12.8. 13.2 Arguments to intrinsic procedures 28 2913.2.1 General rules 30All intrinsic procedures may be invoked with either positional arguments or argument keywords (12.5). 31The descriptions in 13.5 through 13.7 give the argument keyword names and positional sequence for 32standard intrinsic procedures. 33Many of the intrinsic procedures have optional arguments. These arguments are identified by the notation 34"optional" in the argument descriptions. In addition, the names of the optional arguments are enclosed 35in square brackets in description headings and in lists of procedures. The valid forms of reference for 36procedures with optional arguments are described in 12.5.2. 341 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 13.1 The text CMPLX (X [, Y, KIND]) indicates that Y and KIND are both optional arguments. Valid reference forms include CMPLX(x), CMPLX(x, y), CMPLX(x, KIND=kind), CMPLX(x, y, kind), and CMPLX(KIND=kind, X=x, Y=y). NOTE 13.2 Some intrinsic procedures impose additional requirements on their optional arguments. For exam- ple, SELECTED REAL KIND requires that at least one of its optional arguments be present, and RANDOM SEED requires that at most one of its optional arguments be present. 1The dummy arguments of the specific intrinsic procedures in 13.6 have INTENT(IN). The dummy 2arguments of the generic intrinsic procedures in 13.7 have INTENT(IN) if the intent is not stated 3explicitly. 4The actual argument associated with an intrinsic function dummy argument named KIND shall be a 5scalar integer initialization expression and its value shall specify a representation method for the function 6result that exists on the processor. 7Intrinsic subroutines that assign values to arguments of type character do so in accordance with the rules of intrinsic assignment (7.2.1.3). 8 13.2.2 The shape of array arguments 9 10Unless otherwise specified, the inquiry intrinsic functions accept array arguments for which the shape 11need not be defined. The shape of array arguments to transformational and elemental intrinsic functions 12shall be defined. 13.2.3 Mask arguments 13 14Some array intrinsic functions have an optional MASK argument of type logical that is used by the 15function to select the elements of one or more arguments to be operated on by the function. Any 16element not selected by the mask need not be defined at the time the function is invoked. 17The MASK affects only the value of the function, and does not affect the evaluation, prior to invoking 18the function, of arguments that are array expressions. 13.2.4 Arguments to collective subroutines 19 20Each argument to a collective subroutine shall have the same shape on all images of the team. A co-array 21argument shall have the same bounds on all images of the team. An INTENT(IN) argument of type 22IMAGE TEAM shall have a value that was constructed by corresponding invocations of FORM TEAM 23for the team. 2413.3 Bit model 25The bit manipulation procedures and inquiry functions are described in terms of a model for the repre- 26sentation and behaviour of bits on a processor. 27For an integer, a bit is defined to be a binary digit w located at position k of a nonnegative integer scalar 28object based on a model nonnegative integer defined by 342 2006/01/05 WORKING DRAFT J3/07-007 z-1 j = wk × 2k k=0 1and for which wk may have the value 0 or 1. An example of a model number compatible with the 2examples used in 13.4 would have z = 32, thereby defining a 32-bit integer. 3Using the notation of the formula above, the value of an object of type bits and kind z is represented as 4the ordered sequence of bits with wk the bit at position k. The rightmost bit is w0 and the leftmost bit 5is wz . Such a bits object can be interpreted as a nonnegative integer with the value j. -1 6An inquiry function BIT SIZE is available to determine the parameter z of the model. 7Effectively, this model defines an integer object to consist of z bits in sequence numbered from right 8to left from 0 to z - 1. This model is valid only in the context of the use of such an object as the 9argument or result of one of the bit manipulation procedures or the reduction functions IANY, IALL, or 10IPARITY. In all other contexts, the model defined for an integer in 13.4 applies. In particular, whereas 11the models are identical for r = 2 and wz -1 = 0, they do not correspond for r = 2 or wz-1 = 1 and the 12interpretation of bits in such objects is processor dependent. 1313.4 Numeric models 14The numeric manipulation and inquiry functions are described in terms of a model for the representation 15and behavior of numbers on a processor. The model has parameters that are determined so as to make 16the model best fit the machine on which the program is executed. 17The model set for integer i is defined by q-1 i = s × wk × rk k=0 18where r is an integer exceeding one, q is a positive integer, each wk is a nonnegative integer less than r, 19and s is +1 or -1. 20The model set for real x is defined by 0 or p x = s × be × fk × b-k , k=1 21where b and p are integers exceeding one; each fk is a nonnegative integer less than b, with f1 nonzero; s 22is +1 or -1; and e is an integer that lies between some integer maximum emax and some integer minimum 23emin inclusively. For x = 0, its exponent e and digits fk are defined to be zero. The integer parameters 24r and q determine the set of model integers and the integer parameters b, p, emin, and emax determine 25the set of model floating-point numbers. The parameters of the integer and real models are available 26for each representation method of the integer and real types. The parameters characterize the set of 27available numbers in the definition of the model. The floating-point manipulation functions (13.5.10) 28and numeric inquiry functions (13.5.6) provide values of some parameters and other values related to 29the models. 343 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 13.3 Examples of these functions in 13.7 use the models 30 i = s × wk × 2k k=0 and 24 1 x = 0 or s × 2e × + fk × 2-k , -126 e 127 2 k=2 13.5 Standard generic intrinsic procedures 1 2For all of the standard intrinsic procedures, the arguments shown are the names that shall be used for 3argument keywords if the keyword form is used for actual arguments. NOTE 13.4 For example, a reference to CMPLX may be written in the form CMPLX (A, B, M) or in the form CMPLX (Y = B, KIND = M, X = A). NOTE 13.5 Many of the argument keywords have names that are indicative of their usage. For example: KIND Describes the kind type parameter of the result STRING, STRING A An arbitrary character string BACK Controls the direction of string scan (forward or backward) MASK A mask that may be applied to the arguments DIM A selected dimension of an array argument 413.5.1 Numeric functions ABS (A) Absolute value 5 AIMAG (Z) Imaginary part of a complex number 6 AINT (A [, KIND]) Truncation to whole number 7 ANINT (A [, KIND]) Nearest whole number 8 CEILING (A [, KIND]) Least integer greater than or equal to number 9 CMPLX (X [, Y, KIND]) Conversion to complex type 10 CONJG (Z) Conjugate of a complex number 11 DBLE (A) Conversion to double precision real type 12 DIM (X, Y) Positive difference 13 DPROD (X, Y) Double precision real product 14 FLOOR (A [, KIND]) Greatest integer less than or equal to number 15 INT (A [, KIND]) Conversion to integer type 16 MAX (A1, A2 [, A3,...]) Maximum value 17 MIN (A1, A2 [, A3,...]) Minimum value 18 MOD (A, P) Remainder function 19 MODULO (A, P) Modulo function 20 344 2006/01/05 WORKING DRAFT J3/07-007 NINT (A [, KIND]) Nearest integer 1 REAL (A [, KIND]) Conversion to real type 2 SIGN (A, B) Transfer of sign 3 413.5.2 Mathematical functions ACOS (X) Arccosine 5 ACOSH (X) Hyperbolic arccosine 6 ASIN (X) Arcsine 7 ASINH (X) Hyperbolic arcsine 8 ATAN (X) or ATAN (Y, X) Arctangent 9 ATAN2 (Y, X) Arctangent 10 ATANH (X) Hyperbolic arctangent 11 BESSEL J0 (X) Bessel function of the first kind of order zero 12 BESSEL J1 (X) Bessel function of the first kind of order one 13 BESSEL JN (N,X) Bessel function of the first kind of order N 14 BESSEL Y0 (X) Bessel function of the second kind of order zero 15 BESSEL Y1 (X) Bessel function of the second kind of order one 16 BESSEL YN (N, X) Bessel function of the second kind of order N 17 COS (X) Cosine 18 COSH (X) Hyperbolic cosine 19 ERF (X) Error function 20 ERFC (X) Complementary error function 21 22 ERFC SCALED (X) Exponentially-scaled complementary error 23 function EXP (X) Exponential 24 GAMMA (X) Gamma function 25 HYPOT (X, Y) Euclidean distance function 26 LOG (X) Natural logarithm 27 LOG GAMMA (X) Logarithm of absolute value of gamma function 28 LOG10 (X) Common logarithm (base 10) 29 SIN (X) Sine 30 SINH (X) Hyperbolic sine 31 SQRT (X) Square root 32 TAN (X) Tangent 33 TANH (X) Hyperbolic tangent 34 3513.5.3 Character functions 36 ACHAR (I [, KIND]) Character in given position in ASCII collating 37 sequence ADJUSTL (STRING) Adjust left 38 ADJUSTR (STRING) Adjust right 39 40 CHAR (I [, KIND]) Character in given position in processor collating 41 sequence 42 IACHAR (C [, KIND]) Position of a character in ASCII collating 43 sequence 44 ICHAR (C [, KIND]) Position of a character in processor collating 45 sequence INDEX (STRING, SUBSTRING [, BACK, Starting position of a substring KIND]) 46 LEN TRIM (STRING [, KIND]) Length without trailing blank characters 47 LGE (STRING A, STRING B) Lexically greater than or equal 48 LGT (STRING A, STRING B) Lexically greater than 49 345 J3/07-007 WORKING DRAFT 2006/01/05 LLE (STRING A, STRING B) Lexically less than or equal 1 LLT (STRING A, STRING B) Lexically less than 2 MAX (A1, A2 [, A3,...]) Maximum value 3 MIN (A1, A2 [, A3,...]) Minimum value 4 REPEAT (STRING, NCOPIES) Repeated concatenation 5 SCAN (STRING, SET [, BACK, KIND]) Scan a string for a character in a set 6 TRIM (STRING) Remove trailing blank characters 7 VERIFY (STRING, SET [, BACK, KIND]) Verify the set of characters in a string 8 913.5.4 Kind functions 10 BITS KIND (X) Bits kind type parameter value, compatible with 11 the argument KIND (X) Kind type parameter value 12 13 SELECTED BITS KIND (N) Bits kind type parameter value, given number of 14 bits 15 SELECTED CHAR KIND (NAME) Character kind type parameter value, given 16 character set name SELECTED INT KIND (R) Integer kind type parameter value, given range 17 18 SELECTED REAL KIND ([P, R, RADIX]) Real kind type parameter value, given precision, 19 range, and radix 13.5.5 Miscellaneous type conversion functions 20 BITS (A [, KIND]) Convert to bits type 21 22 LOGICAL (L [, KIND]) Convert between objects of type logical with 23 different kind type parameters 24 TRANSFER (SOURCE, MOLD [, SIZE]) Treat first argument as if of type of second 25 argument 13.5.6 Numeric inquiry functions 26 DIGITS (X) Number of significant digits of the model 27 28 EPSILON (X) Number that is almost negligible compared to 29 one HUGE (X) Largest number of the model 30 MAXEXPONENT (X) Maximum exponent of the model 31 MINEXPONENT (X) Minimum exponent of the model 32 PRECISION (X) Decimal precision 33 RADIX (X) Base of the model 34 RANGE (X) Decimal exponent range 35 TINY (X) Smallest positive number of the model 36 13.5.7 Array inquiry functions 37 CO LBOUND (CO ARRAY [, DIM, KIND]) Lower co-bounds of a co-array 38 CO UBOUND (CO ARRAY [, DIM, KIND]) Upper co-bounds of a co-array 39 LBOUND (ARRAY [, DIM, KIND]) Lower dimension bounds of an array 40 SHAPE (SOURCE [, KIND]) Shape of an array or scalar 41 SIZE (ARRAY [, DIM, KIND]) Total number of elements in an array 42 UBOUND (ARRAY [, DIM, KIND]) Upper dimension bounds of an array 43 346 2006/01/05 WORKING DRAFT J3/07-007 13.5.8 Other inquiry functions 1 ALLOCATED (ARRAY) or Allocation status ALLOCATED (SCALAR) 2 ASSOCIATED (POINTER [, TARGET]) Association status inquiry or comparison 3 BIT SIZE (I) Number of bits of the model 4 EXTENDS TYPE OF (A, MOLD) Same dynamic type or an extension 5 6 IS CONTIGUOUS Contiguity inquiry LEN (STRING [, KIND]) Length of a character entity 7 NEW LINE (A) Newline character 8 PRESENT (A) Argument presence 9 SAME TYPE AS (A, B) Same dynamic type 10 STORAGE SIZE (A [, KIND]) Size in bits of an array element 11 13.5.9 Bit manipulation procedures 12 BTEST (I, POS) Bit testing 13 DSHIFTL (I, J, SHIFT) Combined left shift 14 DSHIFTR (I, J, SHIFT) Combined right shift 15 IAND (I, J) Bitwise AND 16 IBCLR (I, POS) Clear bit 17 IBITS (I, POS, LEN) Bit extraction 18 IBSET (I, POS) Set bit 19 IEOR (I, J) Exclusive OR 20 IOR (I, J) Inclusive OR 21 ISHFT (I, SHIFT) Logical shift 22 ISHFTC (I, SHIFT [, SIZE]) Circular shift 23 LEADZ (I) Number of leading zero bits 24 MASKL (I [, KIND]) Left justified bit mask 25 MASKR (I [, KIND]) Right justified bit mask 26 MERGE BITS (I, J, MASK) Merge bits under mask 27 MVBITS (FROM, FROMPOS, LEN, TO, Copies bits from one integer to another TOPOS) 28 NOT (I) Bitwise complement 29 POPCNT (I) Number of one bits 30 POPPAR (I) Parity of one bits 31 SHIFTA (I, SHIFT) Right shift with fill 32 SHIFTL (I, SHIFT) Left shift 33 SHIFTR (I, SHIFT) Right shift 34 TRAILZ (I) Number of trailing zero bits 35 13.5.10 Floating-point manipulation functions 36 EXPONENT (X) Exponent part of a model number 37 FRACTION (X) Fractional part of a number 38 39 NEAREST (X, S) Nearest different processor number in given 40 direction 41 RRSPACING (X) Reciprocal of the relative spacing of model 42 numbers near given number SCALE (X, I) Multiply a real by its base to an integer power 43 SET EXPONENT (X, I) Set exponent part of a number 44 45 SPACING (X) Absolute spacing of model numbers near given 46 number 347 J3/07-007 WORKING DRAFT 2006/01/05 13.5.11 Vector and matrix multiply functions 1 DOT PRODUCT (VECTOR A, Dot product of two rank-one arrays VECTOR B) 2 MATMUL (MATRIX A, MATRIX B) Matrix multiplication 3 13.5.12 Array reduction functions 4 ALL (MASK [, DIM]) True if all values are true 5 ANY (MASK [, DIM]) True if any value is true 6 COUNT (MASK [, DIM, KIND]) Number of true elements in an array 7 IALL (ARRAY, DIM [, MASK]) or Bitwise AND of array elements IALL (ARRAY [, MASK]) 8 IANY (ARRAY, DIM [, MASK]) or Bitwise OR of array elements IANY (ARRAY [, MASK]) 9 IPARITY (ARRAY, DIM [, MASK]) or Bitwise exclusive OR of array elements IPARITY (ARRAY [, MASK]) 10 MAXVAL (ARRAY, DIM [, MASK]) or Maximum value in an array MAXVAL (ARRAY [, MASK]) 11 MINVAL (ARRAY, DIM [, MASK]) or Minimum value in an array MINVAL (ARRAY [, MASK]) 12 NORM2 (X) 13 L2 norm of an array PARITY (MASK [, DIM]) True if an odd number of values is true 14 PRODUCT (ARRAY, DIM [, MASK]) or Product of array elements PRODUCT (ARRAY [, MASK]) 15 SUM (ARRAY, DIM [, MASK]) or Sum of array elements SUM (ARRAY [, MASK]) 16 13.5.13 Array construction functions 17 CSHIFT (ARRAY, SHIFT [, DIM]) Circular shift 18 EOSHIFT (ARRAY, SHIFT [, BOUNDARY, End-off shift DIM]) 19 MERGE (TSOURCE, FSOURCE, MASK) Merge under mask 20 21 PACK (ARRAY, MASK [, VECTOR]) Pack an array into an array of rank one under a 22 mask RESHAPE (SOURCE, SHAPE[, PAD, Reshape an array ORDER]) 23 SPREAD (SOURCE, DIM, NCOPIES) Replicates array by adding a dimension 24 TRANSPOSE (MATRIX) Transpose of an array of rank two 25 26 UNPACK (VECTOR, MASK, FIELD) Unpack an array of rank one into an array under 27 a mask 13.5.14 Array location functions 28 FINDLOC (ARRAY, VALUE, DIM, [, Location of value in an array MASK, KIND, BACK]) or FINDLOC (ARRAY, VALUE, [, MASK, KIND, BACK]) 29 MAXLOC (ARRAY, DIM [, MASK, KIND, Location of a maximum value in an array BACK]) or MAXLOC (ARRAY [, MASK, KIND, BACK]) 30 MINLOC (ARRAY, DIM [, MASK, KIND, Location of a minimum value in an array BACK]) or MINLOC (ARRAY [, MASK, KIND, BACK]) 31 348 2006/01/05 WORKING DRAFT J3/07-007 113.5.15 Collective subroutines CO ALL (MASK, RESULT [, TEAM]) Whether all values are true 2 CO ANY (MASK, RESULT [, TEAM]) Whether any value is true 3 CO COUNT (MASK, RESULT [, TEAM]) Number of true elements in a co-array 4 CO MAXLOC (CO ARRAY, RESULT [, Image indices of maximum values TEAM]) 5 CO MAXVAL (CO ARRAY, RESULT [, Maximum values TEAM]) 6 CO MINLOC (CO ARRAY, RESULT [, Image indices of minimum values TEAM]) 7 CO MINVAL (CO ARRAY, RESULT [, Minimum values TEAM]) 8 CO PRODUCT (CO ARRAY, RESULT [, Products of elements TEAM]) 9 CO SUM (CO ARRAY, RESULT [, TEAM]) Sums of elements 10 1113.5.16 Null function NULL ([MOLD]) Returns disassociated or unallocated result 12 13.5.17 Allocation transfer procedure 13 14 MOVE ALLOC (FROM, TO) Moves an allocation from one allocatable object 15 to another 1613.5.18 Random number subroutines RANDOM NUMBER (HARVEST) Returns pseudorandom number 17 18 RANDOM SEED ([SIZE, PUT, GET]) Initializes or restarts the pseudorandom number 19 generator 13.5.19 System environment procedures 20 COMMAND ARGUMENT COUNT () Number of command arguments 21 CPU TIME (TIME) Obtain processor time 22 DATE AND TIME ([DATE, TIME, ZONE, Obtain date and time VALUES]) 23 EXECUTE COMMAND - Execute a command line LINE (COMMAND, [WAIT, EXITSTAT, CMDSTAT, CMDMSG]) 24 FORM TEAM (TEAM, IMAGES) Forms a team of images 25 GET COMMAND ([COMMAND, Returns entire command LENGTH, STATUS]) 26 GET COMMAND ARGUMENT (NUMBER Returns a command argument [, VALUE, LENGTH, STATUS]) 27 GET ENVIRONMENT VARIABLE (NAME Obtain the value of an environment variable [, VALUE, LENGTH, STATUS, TRIM NAME]) 28 IMAGE INDEX (CO ARRAY, SUB) Index of an image 29 IS IOSTAT END (I) Test for end-of-file value 30 IS IOSTAT EOR (I) Test for end-of-record value 31 NUM IMAGES () Number of images 32 SYSTEM CLOCK ([COUNT, Obtain data from the system clock COUNT RATE, COUNT MAX]) 33 349 J3/07-007 WORKING DRAFT 2006/01/05 TEAM IMAGES (TEAM) Indices of the images in a team 1 THIS IMAGE () Index of the invoking image 2 THIS IMAGE (CO ARRAY [, DIM]) Co-subscript list 3 13.6 Specific names for standard intrinsic functions 4 5Except for AMAX0, AMIN0, MAX1, and MIN1, the result type of the specific function is the same as the 6result type of the corresponding generic function would be if it were invoked with the same arguments 7as the specific function. Specific Name Generic Name Argument Type ABS ABS default real ACOS ACOS default real AIMAG AIMAG default complex AINT AINT default real ALOG LOG default real ALOG10 LOG10 default real · AMAX0 (...) REAL (MAX (...)) default integer · AMAX1 MAX default real · AMIN0 (...) REAL (MIN (...)) default integer · AMIN1 MIN default real AMOD MOD default real ANINT ANINT default real ASIN ASIN default real ATAN (X) ATAN default real ATAN2 ATAN2 default real CABS ABS default complex CCOS COS default complex CEXP EXP default complex · CHAR CHAR default integer CLOG LOG default complex CONJG CONJG default complex COS COS default real COSH COSH default real CSIN SIN default complex CSQRT SQRT default complex DABS ABS double precision real DACOS ACOS double precision real DASIN ASIN double precision real DATAN ATAN double precision real DATAN2 ATAN2 double precision real DCOS COS double precision real DCOSH COSH double precision real DDIM DIM double precision real DEXP EXP double precision real DIM DIM default real DINT AINT double precision real DLOG LOG double precision real DLOG10 LOG10 double precision real · DMAX1 MAX double precision real · DMIN1 MIN double precision real DMOD MOD double precision real DNINT ANINT double precision real 350 2006/01/05 WORKING DRAFT J3/07-007 Specific Name Generic Name Argument Type DPROD DPROD default real DSIGN SIGN double precision real DSIN SIN double precision real DSINH SINH double precision real DSQRT SQRT double precision real DTAN TAN double precision real DTANH TANH double precision real EXP EXP default real · FLOAT REAL default integer IABS ABS default integer · ICHAR ICHAR default character IDIM DIM default integer · IDINT INT double precision real IDNINT NINT double precision real · IFIX INT default real INDEX INDEX default character · INT INT default real ISIGN SIGN default integer LEN LEN default character · LGE LGE default character · LGT LGT default character · LLE LLE default character · LLT LLT default character · MAX0 MAX default integer · MAX1 (...) INT (MAX (...)) default real · MIN0 MIN default integer · MIN1 (...) INT (MIN (...)) default real MOD MOD default integer NINT NINT default real · REAL REAL default integer SIGN SIGN default real SIN SIN default real SINH SINH default real · SNGL REAL double precision real SQRT SQRT default real TAN TAN default real TANH TANH default real 1A specific intrinsic function marked with a bullet (·) shall not be used as an actual argument or as a 2target in a procedure pointer assignment statement. 13.7 Specifications of the standard intrinsic procedures 3 4Detailed specifications of the standard generic intrinsic procedures are provided here in alphabetical 5order. 6The types and type parameters of standard intrinsic procedure arguments and function results are de- 7termined by these specifications. The "Argument(s)" paragraphs specify requirements on the actual 8arguments of the procedures. The result characteristics are sometimes specified in terms of the char- 9acteristics of dummy arguments. A program is prohibited from invoking an intrinsic procedure under 10circumstances where a value to be returned in a subroutine argument or function result is outside the 351 J3/07-007 WORKING DRAFT 2006/01/05 1range of values representable by objects of the specified type and type parameters, unless the intrinsic 2module IEEE ARITHMETIC (clause 14) is accessible and there is support for an infinite or a NaN 3result, as appropriate. If an infinite result is returned, the flag IEEE OVERFLOW or IEEE DIVIDE - 4BY ZERO shall signal; if a NaN result is returned, the flag IEEE INVALID shall signal. If all results 5are normal, these flags shall have the same status as when the intrinsic procedure was invoked. 13.7.1 ABS (A) 6 7Description. Absolute value. 8Class. Elemental function. 9Argument. A shall be of type integer, real, or complex. 10Result Characteristics. The same as A except that if A is complex, the result is real. 11Result Value. If A is of type integer or real, the value of the result is |A|; if A is complex with value 12(x,y), the result is equal to a processor-dependent approximation to x2 + y2 computed without undue 13overflow or underflow. Example. ABS ((3.0, 4.0)) has the value 5.0 (approximately). 14 13.7.2 ACHAR (I [, KIND]) 15 16Description. Returns the character in a specified position of the ASCII collating sequence. It is the 17inverse of the IACHAR function. 18Class. Elemental function. 19Arguments. I shall be of type integer or bits. If it is of type bits, it is interpreted as a nonnegative 20 integer as described in 13.3. KIND (optional) shall be a scalar integer initialization expression. 21 22Result Characteristics. Character of length one. If KIND is present, the kind type parameter is that 23specified by the value of KIND; otherwise, the kind type parameter is that of default character type. 24Result Value. If I has a value in the range 0 I 127, the result is the character in position I of 25the ASCII collating sequence, provided the processor is capable of representing that character in the 26character type of the result; otherwise, the result is processor dependent. ACHAR (IACHAR (C)) shall 27have the value C for any character C capable of representation in the default character type. Examples. ACHAR (88) has the value 'X'. ACHAR (Z'41') has the value 'A'. 28 13.7.3 ACOS (X) 29 Description. Arccosine (inverse cosine) function. 30 31Class. Elemental function. Argument. X shall be of type real with a value that satisfies the inequality |X| 1, or of type complex. 32 33Result Characteristics. Same as X. 34Result Value. The result has a value equal to a processor-dependent approximation to arccos(X). If it 35is real it is expressed in radians and lies in the range 0 ACOS(X) . If it is complex the real part is expressed in radians and lies in the range 0 REAL(ACOS(X)) . 352 2006/01/05 WORKING DRAFT J3/07-007 Example. ACOS (0.54030231) has the value 1.0 (approximately). 1 13.7.4 ACOSH (X) 2 3Description. Inverse hyperbolic cosine function. 4Class. Elemental function. 5Argument. X shall be of type real or complex. 6Result Characteristics. Same as X. 7Result Value. The result has a value equal to a processor-dependent approximation to the inverse 8hyperbolic cosine function of X. If the result is complex the imaginary part is expressed in radians and lies in the range 0 AIMAG(ACOSH(X)) 9 Example. ACOSH(1.5430806) has the value 1.0 (approximately). 10 13.7.5 ADJUSTL (STRING) 11 12Description. Adjust to the left, removing leading blanks and inserting trailing blanks. 13Class. Elemental function. 14Argument. STRING shall be of type character. 15Result Characteristics. Character of the same length and kind type parameter as STRING. 16Result Value. The value of the result is the same as STRING except that any leading blanks have 17been deleted and the same number of trailing blanks have been inserted. Example. ADJUSTL (' WORD') has the value 'WORD '. 18 13.7.6 ADJUSTR (STRING) 19 20Description. Adjust to the right, removing trailing blanks and inserting leading blanks. 21Class. Elemental function. 22Argument. STRING shall be of type character. 23Result Characteristics. Character of the same length and kind type parameter as STRING. 24Result Value. The value of the result is the same as STRING except that any trailing blanks have 25been deleted and the same number of leading blanks have been inserted. Example. ADJUSTR ('WORD ') has the value ' WORD'. 26 13.7.7 AIMAG (Z) 27 28Description. Imaginary part of a complex number. 29Class. Elemental function. 30Argument. Z shall be of type complex. 31Result Characteristics. Real with the same kind type parameter as Z. Result Value. If Z has the value (x,y), the result has the value y. 32 353 J3/07-007 WORKING DRAFT 2006/01/05 Example. AIMAG ((2.0, 3.0)) has the value 3.0. 1 13.7.8 AINT (A [, KIND]) 2 3Description. Truncation to a whole number. 4Class. Elemental function. 5Arguments. 6A shall be of type real. KIND (optional) shall be a scalar integer initialization expression. 7 8Result Characteristics. The result is of type real. If KIND is present, the kind type parameter is 9that specified by the value of KIND; otherwise, the kind type parameter is that of A. 10Result Value. If |A| < 1, AINT (A) has the value 0; if |A| 1, AINT (A) has a value equal to the 11integer whose magnitude is the largest integer that does not exceed the magnitude of A and whose sign 12is the same as the sign of A. Examples. AINT (2.783) has the value 2.0. AINT (­2.783) has the value ­2.0. 13 13.7.9 ALL (MASK [, DIM]) 14 15Description. Determine whether all values are true in MASK along dimension DIM. 16Class. Transformational function. 17Arguments. 18MASK shall be of type logical. It shall be an array. DIM (optional) shall be scalar and of type integer with value in the range 1 DIM n, where n is the rank of MASK. The corresponding actual argument shall not be an optional 19 dummy argument. 20Result Characteristics. The result is of type logical with the same kind type parameter as MASK. It 21is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 22..., dn) where (d1, d2, ..., dn) is the shape of MASK. 23Result Value. 24Case (i): The result of ALL (MASK) has the value true if all elements of MASK are true or if 25 MASK has size zero, and the result has value false if any element of MASK is false. 26Case (ii): If MASK has rank one, ALL(MASK,DIM) is equal to ALL(MASK). Otherwise, the value 27 of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of ALL (MASK, DIM) is equal to -1 28 ALL (MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn)). -1 29Examples. Case (i): The value of ALL ([.TRUE., .FALSE., .TRUE.]) is false. 30 1 3 5 0 3 5 31Case (ii): If B is the array and C is the array then ALL (B /= C, DIM = 2 4 6 7 4 8 1) is [true, false, false] and ALL (B /= C, DIM = 2) is [false, false]. 32 13.7.10 ALLOCATED (ARRAY) or ALLOCATED (SCALAR) 33 Description. Indicate whether an allocatable variable is allocated. 354 2006/01/05 WORKING DRAFT J3/07-007 1 2Class. Inquiry function. 3Arguments. 4ARRAY shall be an allocatable array. 5SCALAR shall be an allocatable scalar. 6Result Characteristics. Default logical scalar. 7Result Value. The result has the value true if the argument (ARRAY or SCALAR) is allocated and 8has the value false if the argument is unallocated. 13.7.11 ANINT (A [, KIND]) 9 10Description. Nearest whole number. 11Class. Elemental function. 12Arguments. 13A shall be of type real. KIND (optional) shall be a scalar integer initialization expression. 14 15Result Characteristics. The result is of type real. If KIND is present, the kind type parameter is 16that specified by the value of KIND; otherwise, the kind type parameter is that of A. 17Result Value. The result is the integer nearest A, or if there are two integers equally near A, the result 18is whichever such integer has the greater magnitude. Examples. ANINT (2.783) has the value 3.0. ANINT (­2.783) has the value ­3.0. 19 13.7.12 ANY (MASK [, DIM]) 20 21Description. Determine whether any value is true in MASK along dimension DIM. 22Class. Transformational function. 23Arguments. 24MASK shall be of type logical. It shall be an array. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of MASK. The corresponding actual argument shall not be an optional 25 dummy argument. 26Result Characteristics. The result is of type logical with the same kind type parameter as MASK. It 27is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 28..., dn) where (d1, d2, ..., dn) is the shape of MASK. 29Result Value. 30Case (i): The result of ANY (MASK) has the value true if any element of MASK is true and has 31 the value false if no elements are true or if MASK has size zero. 32Case (ii): If MASK has rank one, ANY(MASK,DIM) is equal to ANY(MASK). Otherwise, the 33 value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of ANY(MASK, DIM) is equal to -1 34 ANY(MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn)). -1 355 J3/07-007 WORKING DRAFT 2006/01/05 1Examples. Case (i): The value of ANY ([.TRUE., .FALSE., .TRUE.]) is true. 2 1 3 5 0 3 5 3Case (ii): If B is the array and C is the array then ANY(B /= C, DIM = 2 4 6 7 4 8 1) is [true, false, true] and ANY(B /= C, DIM = 2) is [true, true]. 4 13.7.13 ASIN (X) 5 Description. Arcsine (inverse sine) function. 6 7Class. Elemental function. Argument. X shall be of type real with a value that satisfies the inequality |X| 1, or of type complex. 8 9Result Characteristics. Same as X. 10Result Value. The result has a value equal to a processor-dependent approximation to arcsin(X). If it 11is real it is expressed in radians and and lies in the range -/2 ASIN(X) /2. If it is complex the real part is expressed in radians and lies in the range -/2 REAL(ASIN(X)) /2. 12 Example. ASIN (0.84147098) has the value 1.0 (approximately). 13 13.7.14 ASINH (X) 14 15Description. Inverse hyperbolic sine function. 16Class. Elemental function. 17Argument. X shall be of type real or complex. 18Result Characteristics. Same as X. 19Result Value. The result has a value equal to a processor-dependent approximation to the inverse 20hyperbolic sine function of X. If the result is complex the imaginary part is expressed in radians and lies in the range -/2 AIMAG(ASINH(X)) /2. 21 Example. ASINH(1.1752012) has the value 1.0 (approximately). 22 13.7.15 ASSOCIATED (POINTER [, TARGET]) 23 24Description. Returns the association status of its pointer argument or indicates whether the pointer 25is associated with the target. 26Class. Inquiry function. 27Arguments. POINTER shall be a pointer. It may be of any type or may be a procedure pointer. Its pointer 28 association status shall not be undefined. TARGET shall be allowable as the data-target or proc-target in a pointer assignment statement (optional) (7.2.2) in which POINTER is data-pointer-object or proc-pointer-object. If TARGET 29 is a pointer then its pointer association status shall not be undefined. 30Result Characteristics. Default logical scalar. 31Result Value. 356 2006/01/05 WORKING DRAFT J3/07-007 1Case (i): If TARGET is absent, the result is true if and only if POINTER is associated with a 2 target. 3Case (ii): If TARGET is present and is a procedure, the result is true if and only if POINTER is 4 associated with TARGET. 5Case (iii): If TARGET is present and is a procedure pointer, the result is true if and only if POINTER 6 and TARGET are associated with the same procedure. 7Case (iv): If TARGET is present and is a scalar target, the result is true if and only if TARGET is 8 not a zero-sized storage sequence and POINTER is associated with a target that occupies 9 the same storage units as TARGET. 10Case (v): If TARGET is present and is an array target, the result is true if and only if POINTER is 11 associated with a target that has the same shape as TARGET, is neither of size zero nor 12 an array whose elements are zero-sized storage sequences, and occupies the same storage 13 units as TARGET in array element order. 14Case (vi): If TARGET is present and is a scalar pointer, the result is true if and only if POINTER 15 and TARGET are associated, the tragets are not zero-sized storage sequences, and they 16 occupy the same storage units. 17Case (vii): If TARGET is present and is an array pointer, the result is true if and only if POINTER 18 and TARGET are both associated, have the same shape, are neither of size zero nor arrays 19 whose elements are zero-sized storage sequences, and occupy the same storage units in 20 array element order. 21Examples. ASSOCIATED (CURRENT, HEAD) is true if CURRENT is associated with the target 22HEAD. After the execution of 23 A_PART => A (:N) ASSOCIATED (A PART, A) is true if N is equal to UBOUND (A, DIM = 1). After the execution of 24 25 NULLIFY (CUR); NULLIFY (TOP) ASSOCIATED (CUR, TOP) is false. 26 13.7.16 ATAN (X) or ATAN (Y, X) 27 Description. Arctangent (inverse tangent) function. 28 29Class. Elemental function. 30Arguments. 31Y shall be of type real. X If Y is present, X shall be of type real with the same kind type parameter as Y. If Y has the value zero, X shall not have the value zero. If Y is absent, X shall be of type 32 real or complex. 33Result Characteristics. Same as X. 34Result Value. If Y is present, the result is the same as the result of ATAN2(Y,X). If Y is absent, 35the result has a value equal to a processor-dependent approximation to arctan(X) whose real part is expressed in radians and lies in the range -/2 ATAN(X) /2. 36 Example. ATAN (1.5574077) has the value 1.0 (approximately). 37 13.7.17 ATAN2 (Y, X) 38 357 J3/07-007 WORKING DRAFT 2006/01/05 1Description. Arctangent (inverse tangent) function. The result is the principal value of the argument of the nonzero complex number (X, Y). 2 3Class. Elemental function. 4Arguments. 5Y shall be of type real. X shall be of the same type and kind type parameter as Y. If Y has the value zero, X 6 shall not have the value zero. 7Result Characteristics. Same as X. 8Result Value. The result has a value equal to a processor-dependent approximation to the principal 9value of the argument of the complex number (X, Y), expressed in radians. It lies in the range - 10ATAN2(Y,X) and is equal to a processor-dependent approximation to a value of arctan(Y/X) if 11X = 0. If Y > 0, the result is positive. If Y = 0 and X > 0, the result is Y. If Y = 0 and X < 0, then the 12result is approximately if Y is positive real zero or the processor cannot distinguish between positive 13and negative real zero, and approximately - if Y is negative real zero. If Y < 0, the result is negative. If X = 0, the absolute value of the result is approximately /2. 14 1 1 15Examples. ATAN2 (1.5574077, 1.0) has the value 1.0 (approximately). If Y has the value -1 -1 -1 1 3 and X has the value , the value of ATAN2 (Y, X) is approximately 4 4 . -1 1 -3 16 4 -4 13.7.18 ATANH (X) 17 18Description. Inverse hyperbolic tangent function. 19Class. Elemental function. 20Argument. X shall be of type real or complex. 21Result Characteristics. Same as X. 22Result Value. The result has a value equal to a processor-dependent approximation to the inverse 23hyperbolic tangent function of X. If the result is complex the imaginary part is expressed in radians and lies in the range -/2 AIMAG(ATANH(X)) /2. 24 Example. ATANH(0.76159416) has the value 1.0 (approximately). 25 13.7.19 BESSEL J0 (X) 26 27Description. Bessel function of the first kind of order zero. 28Class. Elemental function. 29Argument. X shall be of type real. 30Result Characteristics. Same as X. 31Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 32function of the first kind of order zero of X. Example. BESSEL J0 (1.0) has the value 0.765 (approximately). 33 13.7.20 BESSEL J1 (X) 358 2006/01/05 WORKING DRAFT J3/07-007 1Description. Bessel function of the first kind of order one. 2Class. Elemental function. 3Argument. X shall be of type real. 4Result Characteristics. Same as X. 5Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 6function of the first kind of order one of X. Example. BESSEL J1 (1.0) has the value 0.440 (approximately). 7 13.7.21 BESSEL JN (N, X) 8 9Description. Bessel function of the first kind of order N. 10Class. Elemental function. 11Arguments. 12N shall be of type integer and nonnegative. 13X shall be of type real. 14Result Characteristics. Same as X. 15Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 16function of the first kind of order N of X. Example. BESSEL JN (2, 1.0) has the value 0.115 (approximately). 17 13.7.22 BESSEL Y0 (X) 18 19Description. Bessel function of the second kind of order zero. 20Class. Elemental function. 21Argument. X shall be of type real. Its value shall be greater than zero. 22Result Characteristics. Same as X. 23Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 24function of the second kind of order zero of X. Example. BESSEL Y0(1.0) has the value 0.088 (approximately). 25 13.7.23 BESSEL Y1 (X) 26 27Description. Bessel function of the second kind of order one. 28Class. Elemental function. 29Argument. X shall be of type real. Its value shall be greater than zero. 30Result Characteristics. Same as X. 31Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 32function of the second kind of order one of X. 359 J3/07-007 WORKING DRAFT 2006/01/05 Example. BESSEL Y1 (1.0) has the value -0.781 (approximately). 1 13.7.24 BESSEL YN (N, X) 2 3Description. Bessel function of the second kind of order N. 4Class. Elemental function. 5Arguments. 6N shall be of type integer and nonnegative. 7X shall be of type real. Its value shall be greater than zero. 8Result Characteristics. Same as X. 9Result Value. The result has a value equal to a processor-dependent approximation to the Bessel 10function of the second kind of order N of X. Example. BESSEL YN (2, 1.0) has the value -1.651 (approximately). 11 13.7.25 BIT SIZE (I) 12 13Description. Returns the number of bits z defined by the model of 13.3. 14Class. Inquiry function. 15Argument. I shall be of type integer or bits. It may be a scalar or an array. 16Result Characteristics. Scalar integer. If I is of type integer the kind type parameter is that of I, 17otherwise it is that of default integer type. 18Result Value. If I is of type integer, the result has the value of the number of bits z of the model integer defined for bit manipulation contexts in 13.3. If I is of type bits, the result has the value KIND(I). 19 20Examples. BIT SIZE (1) has the value 32 if z of the model is 32. BIT SIZE(Z'00FF') has the value 2116. 13.7.26 BITS (A [, KIND]) 22 23Description. Convert to bits type. 24Class. Elemental function. 25Arguments. 26A shall be of type integer, real, complex, logical, or bits. KIND (optional) shall be a scalar integer initialization expression. 27 28Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is BITS KIND(A). 29 30Result Value. If A is of type bits and the kind type parameter of A is the same as that of the result, 31the result value is the value of A. 32If A is of type bits with a smaller kind type parameter value than that of the result, the rightmost KIND(A) bits of the result value are the same as those of A and the remaining bits of the result are 0. 33 360 2006/01/05 WORKING DRAFT J3/07-007 1If A is of type bits with a larger kind type parameter value than that of the result, the result value consists of the rightmost KIND(result) bits of A. 2 3If A is not of type bits and BITS KIND(A) is greater than or equal to the kind type parameter of the result, the result value consists of the rightmost KIND(result) bits of the physical representation of A. 4 5If A is not of type bits and BITS KIND(A) is less than or equal to the kind type parameter of the result, 6the rightmost bits of the result are those of the physical representation of A and the remaining bits of 7the result are 0. 8Examples. BITS (Z'AB', 16) has the value Z'00AB'. BITS (-1) has the value Z'FFFFFFFF' for a 9processor whose default integer representation is 32-bit two's-complement. BITS (.TRUE., 5) has the 10value B'00001' for a processor that represents the logical value true by setting the low order bit of the 11internal value and clearing the other bits. BITS (X) has the value Z'7F800000' if the value of X is an 12IEEE single precision positive infinity. 13.7.27 BITS KIND (X) 13 14Description. Return bits kind compatible with the argument. 15Class. Inquiry function. 16Arguments. 17X shall be of type bits, integer, real, complex, or logical. 18Result Characteristics. Default integer scalar. 19Result Value. If X is of type bits, the result has the value KIND (X). If X is of type default integer, 20default real, or default logical, the result has the value NUMERIC STORAGE SIZE (13.8.2.13). If X is 21of type double precision or default complex, the result has the value 2 × NUMERIC STORAGE SIZE. 22Otherwise, the result value is the number of bits of storage used by the processor to represent scalar 23objects of that type and kind. Example. The value of BITS KIND (0) is 32 if the size of a numeric storage unit is 32 bits. 24 13.7.28 BTEST (I, POS) 25 26Description. Tests a bit of an integer or bits value. 27Class. Elemental function. 28Arguments. 29I shall be of type integer or bits. POS shall be of type integer. It shall be nonnegative and be less than BIT SIZE (I). 30 31Result Characteristics. Default logical. 32Result Value. The result has the value true if bit POS of I has the value 1 and has the value false if 33bit POS of I has the value 0. The model for the interpretation of an integer value as a sequence of bits 34is in 13.3. 1 2 35Examples. BTEST (8, 3) has the value true. If A has the value , the value of BTEST (A, 2) 3 4 false false true false 36is and the value of BTEST (2, A) is . false true false false 361 J3/07-007 WORKING DRAFT 2006/01/05 BTEST (B'01000', 3) has the value true. 1 13.7.29 CEILING (A [, KIND]) 2 3Description. Returns the least integer greater than or equal to its argument. 4Class. Elemental function. 5Arguments. 6A shall be of type real. KIND (optional) shall be a scalar integer initialization expression. 7 8Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 9value of KIND; otherwise, the kind type parameter is that of default integer type. 10Result Value. The result has a value equal to the least integer greater than or equal to A. Examples. CEILING (3.7) has the value 4. CEILING (­3.7) has the value ­3. 11 13.7.30 CHAR (I [, KIND]) 12 13Description. Returns the character in a given position of the processor collating sequence associated 14with the specified kind type parameter. It is the inverse of the ICHAR function. 15Class. Elemental function. 16Arguments. I shall be of type integer or bits. If I is of type bits, it is interpreted as a non-negative integer as described in 13.3. The value of I shall be in the range 0 I n - 1, where n is the number of characters in the collating sequence associated with the specified 17 kind type parameter. KIND (optional) shall be a scalar integer initialization expression. 18 19Result Characteristics. Character of length one. If KIND is present, the kind type parameter is that 20specified by the value of KIND; otherwise, the kind type parameter is that of default character type. 21Result Value. The result is the character in position I of the collating sequence associated with the 22specified kind type parameter. ICHAR (CHAR (I, KIND (C))) shall have the value I for 0 I n - 1 23and CHAR (ICHAR (C), KIND (C)) shall have the value C for any character C capable of representation 24in the processor. 25Examples. CHAR (88) has the value 'X' on a processor using the ASCII collating sequence for the 26default character type. CHAR (Z'41') has the value 'A' on a processor using the ASCII collating 27sequence. 13.7.31 CMPLX (X [, Y, KIND]) 28 29Description. Convert to complex type. 30Class. Elemental function. 31Arguments. 32X shall be of type integer, real, or complex, or bits. 362 2006/01/05 WORKING DRAFT J3/07-007 Y (optional) shall be of type integer or real, or bits. If X is of type complex, Y shall not be present, 1 nor shall Y be associated with an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 2 3Result Characteristics. The result is of type complex. If KIND is present, the kind type parameter 4is that specified by the value of KIND; otherwise, the kind type parameter is that of default real type. 5Result Value. If Y is absent and X is not complex, it is as if Y were present with the value zero. If X 6is complex, it is as if X were real with the value REAL (X, KIND) and Y were present with the value 7AIMAG (X, KIND). CMPLX (X, Y, KIND) has the complex value whose real part is REAL (X, KIND) and whose imaginary part is REAL (Y, KIND). 8 Example. CMPLX (­3) has the value (­3.0, 0.0). 9 13.7.32 CO ALL (MASK, RESULT [, TEAM]) 10 11Description. Determine whether all values are true on a team of images. 12Class. Collective subroutine. 13Arguments. MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) 14 argument. RESULT shall be of type logical and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar, it is assigned the value true if the value of MASK is true on all the images of the team, and the value false otherwise. If it is an array, each element is assigned the value true if all corresponding elements of MASK are true on 15 all the images of the team, and the value false otherwise. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO ALL is performed. If TEAM is not present, the 16 team consists of all images. 17Example. If the number of images is two and MASK is the array [true, false, true] on one image and 18[true, true, true] on the other image, the value of RESULT after executing the statement CALL CO - ALL (MASK, RESULT) is [true, false, true]. 19 13.7.33 CO ANY (MASK, RESULT [, TEAM]) 20 21Description. Determine whether any value is true on a team of images. 22Class. Collective subroutine. 23Arguments. MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) 24 argument. RESULT shall be of type logical and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar it is assigned the value true if any value of MASK is true on any image of the team, and false otherwise. If it is an array, each element is assigned the value true if any of the corresponding elements of MASK are true on any image 25 of the team, and false otherwise. 363 J3/07-007 WORKING DRAFT 2006/01/05 TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO ANY is performed. If TEAM is not present, the 1 team consists of all images. 2Example. If the number of images is two and MASK is the array [true, false, false] on one image and 3[true, true, false] on the other image, the value of RESULT after executing the statement CALL CO - ANY (MASK, RESULT) is [true, true, false]. 4 13.7.34 CO COUNT (MASK, RESULT [, TEAM]) 5 6Description. Count the numbers of true elements on a team of images. 7Class. Collective subroutine. 8Arguments. MASK shall be a co-array of type logical. It may be a scalar or an array. It is an INTENT(IN) 9 argument. RESULT shall be of type integer and have the same shape as MASK. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the number of images of the team for which MASK has the value true. If it is an array, each element is assigned a value equal to the number of corresponding elements of MASK on the images of the 10 team that have the value true. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO COUNT is performed. If TEAM is not present, 11 the team consists of all images. 12Example. If the number of images is two and MASK is the array [true, false, false] on one image and 13[true, true, false] on the other image, the value of result after executing the statement CALL CO COUNT (MASK, RESULT) is [2, 1, 0]. 14 13.7.35 CO LBOUND (CO ARRAY [, DIM, KIND]) 15 16Description. Returns all the lower co-bounds or a specified lower co-bound of a co-array. 17Class. Inquiry function. 18Arguments. CO ARRAY shall be a co-array and may be of any type. It may be a scalar or an array. If it is 19 allocatable it shall be allocated. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the co-rank of CO ARRAY. The corresponding actual argument shall not be an 20 optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 21 22Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 23value of KIND; otherwise, the kind type parameter is that of default integer type. The result is scalar 24if DIM is present; otherwise, the result is an array of rank one and size n, where n is the co-rank of 25CO ARRAY. 26Result Value. 27Case (i): CO LBOUND (CO ARRAY, DIM) has a value equal to the lower co-bound for co- 28 subscript DIM of CO ARRAY. 364 2006/01/05 WORKING DRAFT J3/07-007 1Case (ii): CO LBOUND (CO ARRAY) has a value whose ith element is equal to CO LBOUND (CO ARRAY, i), for i = 1, 2,..., n, where n is the co-rank of CO ARRAY. 2 3Examples. If A is allocated by the statement ALLOCATE (A [2:3, 7:*]) then CO LBOUND (A) is [2, 7] and CO LBOUND (A, DIM=2) is 7. 4 13.7.36 CO MAXLOC (CO ARRAY, RESULT [, TEAM]) 5 6Description. Image indices of the maximum values of the elements on a team of images. 7Class. Collective subroutine. 8Arguments. CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar or an array. It is an INTENT(IN) argument. 9 RESULT shall be of type integer and have the same shape as CO ARRAY. It is an IN- TENT(OUT) argument. If it is scalar, it is assigned a value equal to the image index of the maximum value of CO ARRAY on the images of the team; if more than one image has the maximum value, the smallest such image index is assigned. If RESULT is an array, each element of RESULT is assigned a value equal to the image index of the maximum value of all the corresponding elements of CO ARRAY on the images of the team; if more than one image has the maximum value, the smallest such image index is assigned. If CO ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for 10 characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO MAXLOC is performed. If TEAM is not present, 11 the team consists of all images. 12Example. If the number of images is two and CO ARRAY is the array [1, 5, 6] on one image and 13[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO MAXLOC (CO ARRAY, RESULT) is [2, 1, 1]. 14 13.7.37 CO MAXVAL (CO ARRAY, RESULT [, TEAM]) 15 16Description. Maximum values of the elements on a team of images. 17Class. Collective subroutine. 18Arguments. CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar or an array. It is an INTENT(IN) argument. 19 RESULT shall be of the same type and type parameters as CO ARRAY, and shall have the same shape as CO ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to the maximum value of CO ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to the maximum value of all the corresponding elements of CO ARRAY on all the images of the team. If CO ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for 20 characters with the kind type parameter of the argument is applied. 365 J3/07-007 WORKING DRAFT 2006/01/05 TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO MAXVAL is performed. If TEAM is not present, 1 the team consists of all images. 2Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image and 3[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO MAXVAL (CO ARRAY, RESULT) is [4, 5, 6]. 4 13.7.38 CO MINLOC (CO ARRAY, RESULT [, TEAM]) 5 6Description. Image indices of the minimum values of the elements on a team of images. 7Class. Collective subroutine. 8Arguments. CO ARRAY shall a co-array of type integer, real, bits, or character. It may be a scalar or an array. It is an INTENT(IN) argument. 9 RESULT shall be of type integer and have the same shape as CO ARRAY. It is an IN- TENT(OUT) argument. If it is scalar, it is assigned a value equal to the image index of the minimum value of CO ARRAY on all the images of the team; if more than one image has the minimum value, the smallest such image index is assigned. If it is an array, each element is assigned a value equal to the image index of the minimum value of all the corresponding elements of CO ARRAY on the images of the team; if more than one image has the minimum value, the smallest such image index is assigned. If CO ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for 10 characters with the kind type parameter of the argument is applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO MINLOC is performed. If TEAM is not present, 11 the team consists of all images. 12Example. If the number of images is two and CO ARRAY is the array [1, 5, 6] on one image and 13[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO MINLOC (ARRAY, RESULT) is [1, 2, 1]. 14 13.7.39 CO MINVAL (CO ARRAY, RESULT [, TEAM]) 15 16Description. Minimum values of the elements on a team of images. 17Class. Collective subroutine. 18Arguments. CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar or an array. It is an INTENT(IN) argument. 19 RESULT shall be of the same type and type parameters as CO ARRAY, and shall have the same shape as CO ARRAY. It is an INTENT(OUT) argument. If it is scalar it is assigned a value equal to the minimum value of CO ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to the minimum value of all the corresponding elements of CO ARRAY on all the images of the team. If CO ARRAY is of type character, the result is the value that would be selected by application of intrinsic relational operators; that is, the collating sequence for characters with the kind type parameter of the argument is applied. 366 2006/01/05 WORKING DRAFT J3/07-007 1 TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO MINVAL is performed. If TEAM is not present, 2 the team consists of all images. 3Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image and 4[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO MINVAL (CO ARRAY, RESULT) is [1, 1, 3]. 5 13.7.40 CO PRODUCT (CO ARRAY, RESULT [, TEAM]) 6 7Description. Products of elements on a team of images. 8Class. Collective subroutine. 9Arguments. CO ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an array. It is an INTENT(IN) argument. 10 RESULT shall be of the same type and type parameters as CO ARRAY, and shall have the same shape as CO ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to a processor-dependent and image-dependent approximation to the product of the values of CO ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to a processor-dependent and image-dependent approximation to the product of all the corresponding elements of CO ARRAY on 11 the images of the team. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO PRODUCT is performed. If TEAM is not 12 present, the team consists of all images. 13Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image and 14[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO PRODUCT (CO ARRAY, RESULT) is [4, 5, 18]. 15 13.7.41 CO SUM (CO ARRAY, RESULT [, TEAM]) 16 17Description. Sums of elements on a team of images. 18Class. Collective subroutine. 19Arguments. CO ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an array. It is an INTENT(IN) argument. 20 RESULT shall be of the same type and type parameters as CO ARRAY, and shall have the same shape as CO ARRAY. It is an INTENT(OUT) argument. If it is scalar, it is assigned a value equal to a processor-dependent and image-dependent approximation to the sum of the values of CO ARRAY on all the images of the team. If it is an array, each element is assigned a value equal to a processor-dependent and image-dependent approximation to the sum of all the corresponding elements of CO ARRAY on the 21 images of the team. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(IN) argument that specifies the team for which CO SUM is performed. If TEAM is not present, the team consists of all images. 367 J3/07-007 WORKING DRAFT 2006/01/05 1Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image and 2[4, 1, 6] on the other image, the value of RESULT after executing the statement CALL CO SUM (CO ARRAY, RESULT) is [5, 6, 9]. 3 13.7.42 CO UBOUND (CO ARRAY [, DIM, KIND]) 4 5Description. Returns all the upper co-bounds or a specified upper co-bound of a co-array of co-rank 6greater than one. 7Class. Inquiry function. 8Arguments. CO ARRAY shall be a co-array of any type and of co-rank greater than one. It may be a scalar or 9 an array. If it is allocatable it shall be allocated. DIM (optional) d shall be scalar and of type integer with a value in the range 1 DIM n-1, where n is the co-rank of CO ARRAY. The corresponding actual argument shall not be an 10 optional dummy argument. J3 internal note Unresolved Technical Issue 105 CO UBOUND is inconvenient and inconsistent. This is a very peculiar intrinsic. The processor knows jolly well how many array elements there are; in this it is not, in fact, analogous to the assumed-size array case. (Yes, some processors do know how big assumed-size arrays are, but not all and its not required by the standard ­ again, not analogous.) The only way in which this is analogous to an assumed-size array is 1. The last co-dimension might, I repeat might, be a few images short of a whole column. 2. The use of an asterisk in the syntax. This is an irrelevance ­ asterisk is also used for assumed length type parameters (and one is permitted to ask about those). The result shape of CO UBOUND is also inconsistent with UBOUND. In fact the vector form of UBOUND is simply not permitted with an assumed-size array! There is no doubt what the value of the co-bound of the last co-dimension is; for example, for the dummy argument REAL, ALLOCATABLE :: X(:,:,:,:*) it is CO_LBOUND(X,4) + CEILING(REAL(NUM_IMAGES())/ ((CO_UBOUND(X,1)-CO_LBOUND(X,1)+1)* CO_UBOUND(X,2)-CO_LBOUND(X,2)+1)* CO_UBOUND(X,3)-CO_LBOUND(X,3)+1))) - 1 Why are we even thinking of making the user write out this abomination? 368 2006/01/05 WORKING DRAFT J3/07-007 J3 internal note (cont.) Just tell him the answer! P.S. Yes, in my mind there is no doubt that the co-bound for the last co-dimension is the ceiling and not the floor, because we say the technical term co-bound(s) means the bounds of the co- dimensions ­ that's what bounds are (limits one cannot go beyond). The fact that a few images might be missing off the end doesn't affect that. P.P.S. The fact that the number of images, and thus the final upper co-bounds of all co-arrays, is determined by magic instead of by a Fortran statement that declares it, is neither here nor there; there's no expression in an assumed-shape array declaration either. P.P.P.S. Here we have the situation where providing the right answer would be a significant convenience to the user, and would make CO UBOUND consistent with UBOUND to boot. P.P.P.P.S. Paper 06-379 attempted to fix this, but there was a claim that this conflicted with [93:15], which says The co-rank is equal to one plus the number of upper-co-bounds. Well, it does not conflict. The technical term co-bound is defined in chapter two; the syntax term upper-co-bound is (a) spelled differently, and (b) even if the syntax term were simply co-bound, would not override that definition. (Allocatable coarrays don't even have the syntax thingy, so it cannot be the definition of co-bound anyway. I'll note that the original definition of co-bounds (in 06-007) was completely faulty (like, didn't work at all) and that has probably influenced this confusion. (Of course paper 06-379 didn't do the full and proper fix here, but that's another story.) KIND (optional) shall be a scalar integer initialization expression. 1 2Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 3value of KIND; otherwise, the kind type parameter is that of default integer type. The result is scalar 4if DIM is present; otherwise, the result is an array of rank one and size n - 1, where n is the co-rank of 5CO ARRAY. 6Result Value. 7Case (i): CO UBOUND (CO ARRAY, DIM) has a value equal to the upper co-bound for co- 8 subscript DIM of CO ARRAY. 9Case (ii): CO UBOUND (CO ARRAY) has a value whose ith element is equal to 10 CO UBOUND (CO ARRAY, i), for i = 1, 2,..., n - 1, where n is the co-rank of CO - 11 ARRAY. 12Examples. If A is allocated by the statement ALLOCATE (A [2:3, 0:7, *]) then CO UBOUND (A) is [3, 7] and CO UBOUND (A, DIM=2) is 7. 13 13.7.43 COMMAND ARGUMENT COUNT () 14 15Description. Returns the number of command arguments. 16Class. Inquiry function. 17Argument. None. 18Result Characteristics. Scalar default integer. 19Result Value. The result value is equal to the number of command arguments available. If there are 20no command arguments available or if the processor does not support command arguments, then the 21result has the value zero. If the processor has a concept of a command name, the command name does 22not count as one of the command arguments. 23Example. See 13.7.73. 369 J3/07-007 WORKING DRAFT 2006/01/05 13.7.44 CONJG (Z) 1 2Description. Conjugate of a complex number. 3Class. Elemental function. 4Argument. Z shall be of type complex. 5Result Characteristics. Same as Z. Result Value. If Z has the value (x,y), the result has the value (x,-y). 6 Example. CONJG ((2.0, 3.0)) has the value (2.0, ­3.0). 7 13.7.45 COS (X) 8 9Description. Cosine function. 10Class. Elemental function. 11Argument. X shall be of type real or complex. 12Result Characteristics. Same as X. 13Result Value. The result has a value equal to a processor-dependent approximation to cos(X). If X is 14of type real, it is regarded as a value in radians. If X is of type complex, its real part is regarded as a 15value in radians. Example. COS (1.0) has the value 0.54030231 (approximately). 16 13.7.46 COSH (X) 17 18Description. Hyperbolic cosine function. 19Class. Elemental function. 20Argument. X shall be of type real or complex. 21Result Characteristics. Same as X. 22Result Value. The result has a value equal to a processor-dependent approximation to cosh(X). If X 23is of type complex its imaginary part is regarded as a value in radians. Example. COSH (1.0) has the value 1.5430806 (approximately). 24 13.7.47 COUNT (MASK [, DIM, KIND]) 25 26Description. Count the number of true elements of MASK along dimension DIM. 27Class. Transformational function. 28Arguments. 29MASK shall be of type logical. It shall be an array. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of MASK. The corresponding actual argument shall not be an optional 30 dummy argument. KIND (optional) shall be a scalar integer initialization expression. 370 2006/01/05 WORKING DRAFT J3/07-007 1 2Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 3value of KIND; otherwise the kind type parameter is that of default integer type. The result is scalar 4if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) -1 5where (d1, d2, ..., dn) is the shape of MASK. 6Result Value. 7Case (i): The result of COUNT (MASK) has a value equal to the number of true elements of MASK 8 or has the value zero if MASK has size zero. 9Case (ii): If MASK has rank one, COUNT (MASK, DIM) has a value equal to that of COUNT 10 (MASK). Otherwise, the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of -1 11 COUNT (MASK, DIM) is equal to COUNT (MASK (s1, s2, ..., sDIM , :, sDIM+1, -1 12 ..., sn)). 13Examples. Case (i): The value of COUNT ([.TRUE., .FALSE., .TRUE.]) is 2. 14 1 3 5 0 3 5 15Case (ii): If B is the array and C is the array , COUNT (B /= C, DIM = 2 4 6 7 4 8 1) is [2, 0, 1] and COUNT (B /= C, DIM = 2) is [1, 2]. 16 13.7.48 CPU TIME (TIME) 17 18Description. Returns the processor time. 19Class. Subroutine. 20Argument. TIME shall be scalar and of type real. It is an INTENT(OUT) argument that is assigned 21a processor-dependent approximation to the processor time in seconds. If the processor cannot return a 22meaningful time, a processor-dependent negative value is returned. 23Example. 24 REAL T1, T2 25 ... 26 CALL CPU_TIME(T1) 27 ... ! Code to be timed. 28 CALL CPU_TIME(T2) 29 WRITE (*,*) 'Time taken by code was ', T2-T1, ' seconds' 30writes the processor time taken by a piece of code. NOTE 13.6 A processor for which a single result is inadequate (for example, a parallel processor) might choose to provide an additional version for which time is an array. The exact definition of time is left imprecise because of the variability in what different processors are able to provide. The primary purpose is to compare different algorithms on the same processor or discover which parts of a calculation are the most expensive. The start time is left imprecise because the purpose is to time sections of code, as in the example. 371 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 13.6 (cont.) Most computer systems have multiple concepts of time. One common concept is that of time expended by the processor for a given program. This might or might not include system overhead, and has no obvious connection to elapsed "wall clock" time. 13.7.49 CSHIFT (ARRAY, SHIFT [, DIM]) 1 2Description. Perform a circular shift on an array expression of rank one or perform circular shifts on 3all the complete rank one sections along a given dimension of an array expression of rank two or greater. 4Elements shifted out at one end of a section are shifted in at the other end. Different sections may be 5shifted by different amounts and in different directions. 6Class. Transformational function. 7Arguments. 8ARRAY may be of any type. It shall be an array. SHIFT shall be of type integer and shall be scalar if ARRAY has rank one; otherwise, it shall be scalar or of rank n - 1 and of shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) where -1 9 (d1, d2, ..., dn) is the shape of ARRAY. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is 10 the rank of ARRAY. If DIM is omitted, it is as if it were present with the value 1. 11Result Characteristics. The result is of the type and type parameters of ARRAY, and has the shape 12of ARRAY. 13Result Value. 14Case (i): If ARRAY has rank one, element i of the result is ARRAY (1 + MODULO (i + SHIFT ­ 1, SIZE (ARRAY))). 15 16Case (ii): If ARRAY has rank greater than one, section (s1, s2, ..., sDIM , :, sDIM+1, ...., sn) of -1 17 the result has a value equal to CSHIFT (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ...., -1 18 sn), sh, 1), where sh is SHIFT or SHIFT (s1, s2, ..., sDIM , sDIM+1, ..., sn). -1 19Examples. 20Case (i): If V is the array [1, 2, 3, 4, 5, 6], the effect of shifting V circularly to the left by two 21 positions is achieved by CSHIFT (V, SHIFT = 2) which has the value [3, 4, 5, 6, 1, 2]; 22 CSHIFT (V, SHIFT = ­2) achieves a circular shift to the right by two positions and has the value [5, 6, 1, 2, 3, 4]. 23 24Case (ii): The rows of an array of rank two may all be shifted by the same amount or by different 1 2 3 25 amounts. If M is the array 4 5 6 the value of , 7 8 9 3 1 2 26 CSHIFT (M, SHIFT = ­1, DIM = 2) is 6 4 5 and the value of , 9 7 8 3 1 2 CSHIFT (M, SHIFT = [­1, 1, 0], DIM = 2) is 5 6 4 . 7 8 9 27 13.7.50 DATE AND TIME ([DATE, TIME, ZONE, VALUES]) 28 372 2006/01/05 WORKING DRAFT J3/07-007 1Description. Returns data about the real-time clock and date in a form compatible with the represen- 2tations defined in ISO 8601:1988. 3Class. Subroutine. 4Arguments. DATE (optional) shall be scalar and of type default character. It is an INTENT (OUT) argument. It is assigned a value of the form CCYYMMDD, where CC is the century, YY is the year within the century, MM is the month within the year, and DD is the day within 5 the month. If there is no date available, DATE is assigned all blanks. TIME (optional) shall be scalar and of type default character. It is an INTENT (OUT) argument. It is assigned a value of the form hhmmss.sss, where hh is the hour of the day, mm is the minutes of the hour, and ss.sss is the seconds and milliseconds of the minute. If 6 there is no clock available, TIME is assigned all blanks. ZONE (optional) shall be scalar and of type default character. It is an INTENT (OUT) argument. It is assigned a value of the form +hhmm or -hhmm, where hh and mm are the time difference with respect to Coordinated Universal Time (UTC) in hours and minutes, 7 respectively. If this information is not available, ZONE is assigned all blanks. VALUES shall be of type default integer and of rank one. It is an INTENT (OUT) argument. (optional) Its size shall be at least 8. The values returned in VALUES are as follows: 8 VALUES (1) the year, including the century (for example, 1990), or ­HUGE (0) if there is no date 9 available; VALUES (2) the month of the year, or ­HUGE (0) if there is no date available; 10 VALUES (3) the day of the month, or ­HUGE (0) if there is no date available; 11 VALUES (4) the time difference with respect to Coordinated Universal Time (UTC) in minutes, or ­HUGE (0) if this information is not available; 12 VALUES (5) the hour of the day, in the range of 0 to 23, or ­HUGE (0) if there is no clock; 13 VALUES (6) the minutes of the hour, in the range 0 to 59, or ­HUGE (0) if there is no clock; 14 VALUES (7) the seconds of the minute, in the range 0 to 60, or ­HUGE (0) if there is no clock; 15 VALUES (8) the milliseconds of the second, in the range 0 to 999, or ­HUGE (0) if there is no 16 clock. 17Example. 18 INTEGER DATE_TIME (8) 19 CHARACTER (LEN = 10) BIG_BEN (3) 20 CALL DATE_AND_TIME (BIG_BEN (1), BIG_BEN (2), & 21 BIG_BEN (3), DATE_TIME) 22If run in Geneva, Switzerland on April 12, 1985 at 15:27:35.5 with a system configured for the local 23time zone, this sample would have assigned the value 19850412 to BIG BEN (1), the value 152735.500 24to BIG BEN (2), the value +0100 to BIG BEN (3), and the value [1985, 4, 12, 60, 15, 27, 35, 500] to 25DATE TIME. 373 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 13.7 UTC is defined by ISO 8601:1988. 13.7.51 DBLE (A) 1 2Description. Convert to double precision real type. 3Class. Elemental function. 4Argument. A shall be of type integer, real, complex, or bits. 5Result Characteristics. Double precision real. Result Value. The result has the value REAL (A, KIND (0.0D0)). 6 Example. DBLE (­3) has the value ­3.0D0. 7 13.7.52 DIGITS (X) 8 9Description. Returns the number of significant digits of the model representing numbers of the same 10type and kind type parameter as the argument. 11Class. Inquiry function. 12Argument. X shall be of type integer or real. It may be a scalar or an array. 13Result Characteristics. Default integer scalar. 14Result Value. The result has the value q if X is of type integer and p if X is of type real, where q and 15p are as defined in 13.4 for the model representing numbers of the same type and kind type parameter 16as X. Example. DIGITS (X) has the value 24 for real X whose model is as in Note 13.3. 17 13.7.53 DIM (X, Y) 18 19Description. The difference X­Y if it is positive; otherwise zero. 20Class. Elemental function. 21Arguments. 22X shall be of type integer or real. 23Y shall be of the same type and kind type parameter as X. 24Result Characteristics. Same as X. 25Result Value. The value of the result is X­Y if X>Y and zero otherwise. Example. DIM (­3.0, 2.0) has the value 0.0. 26 13.7.54 DOT PRODUCT (VECTOR A, VECTOR B) 27 28Description. Performs dot-product multiplication of numeric or logical vectors. 29Class. Transformational function. 374 2006/01/05 WORKING DRAFT J3/07-007 1Arguments. VECTOR A shall be of numeric type (integer, real, or complex) or of logical type. It shall be a 2 rank-one array. VECTOR B shall be of numeric type if VECTOR A is of numeric type or of type logical if VEC- TOR A is of type logical. It shall be a rank-one array. It shall be of the same size as 3 VECTOR A. 4Result Characteristics. If the arguments are of numeric type, the type and kind type parameter 5of the result are those of the expression VECTOR A * VECTOR B determined by the types of the 6arguments according to 7.1.9.2. If the arguments are of type logical, the result is of type logical with 7the kind type parameter of the expression VECTOR A .AND. VECTOR B according to 7.1.9.2. The 8result is scalar. 9Result Value. 10Case (i): If VECTOR A is of type integer or real, the result has the value SUM (VECTOR - A*VECTOR B). If the vectors have size zero, the result has the value zero. 11 12Case (ii): If VECTOR A is of type complex, the result has the value SUM (CONJG (VECTOR - A)*VECTOR B). If the vectors have size zero, the result has the value zero. 13 14Case (iii): If VECTOR A is of type logical, the result has the value ANY (VECTOR A .AND. VECTOR B). If the vectors have size zero, the result has the value false. 15 Example. DOT PRODUCT ([1, 2, 3], [2, 3, 4]) has the value 20. 16 13.7.55 DPROD (X, Y) 17 18Description. Double precision real product. 19Class. Elemental function. 20Arguments. 21X shall be of type default real. 22Y shall be of type default real. 23Result Characteristics. Double precision real. 24Result Value. The result has a value equal to a processor-dependent approximation to the product of 25X and Y. Example. DPROD (­3.0, 2.0) has the value ­6.0D0. 26 13.7.56 DSHIFTL (I, J, SHIFT) 27 28Description. Performs a combined left shift. 29Class. Elemental function. 30Arguments. 31I shall be of type integer or bits. 32J shall be of the same type and kind as I. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I). 33 34Result Characteristics. Same as I. 375 J3/07-007 WORKING DRAFT 2006/01/05 1Result Value. The rightmost SHIFT bits of the result value are the same as the leftmost bits of J, 2and the remaining bits of the result value are the same as the rightmost bits of I. This is equal to IOR (SHIFTL (I, SHIFT), SHIFTR (J, BIT SIZE (J)-SHIFT)). 3 4Examples. DSHIFTL (Z'01234567', Z'89ABCDEF', 8) has the value Z'23456789'. DSHIFTL (I, I, SHIFT) has the same result value as ISHFTC (I, SHIFT). 5 13.7.57 DSHIFTR (I, J, SHIFT) 6 7Description. Performs a combined right shift. 8Class. Elemental function. 9Arguments. 10I shall be of type integer or bits. 11J shall be of the same type and kind as I. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I). 12 13Result Characteristics. Same as I. 14Result Value. The leftmost SHIFT bits of the result value are the same as the rightmost bits of 15I, and the remaining bits of the result value are the same as the leftmost bits of J. This is equal to IOR (SHIFTL (I, BIT SIZE (I)-SHIFT), SHIFTR (J, SHIFT)). 16 17Examples. DSHIFTR(Z'01234567', Z'89ABCDEF', 8) has the value Z'6789ABCD'. 18DSHIFTR (B'111', B'000', 2) has the value B'110'. DSHIFTR (I, I, SHIFT) has the same result value as ISHFTC (I,-SHIFT). 19 13.7.58 EOSHIFT (ARRAY, SHIFT [, BOUNDARY, DIM]) 20 21Description. Perform an end-off shift on an array expression of rank one or perform end-off shifts on 22all the complete rank-one sections along a given dimension of an array expression of rank two or greater. 23Elements are shifted off at one end of a section and copies of a boundary value are shifted in at the other 24end. Different sections may have different boundary values and may be shifted by different amounts and 25in different directions. 26Class. Transformational function. 27Arguments. 28ARRAY may be of any type. It shall be an array. SHIFT shall be of type integer and shall be scalar if ARRAY has rank one; otherwise, it shall be scalar or of rank n - 1 and of shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) where -1 29 (d1, d2, ..., dn) is the shape of ARRAY. 376 2006/01/05 WORKING DRAFT J3/07-007 BOUNDARY shall be of the same type and type parameters as ARRAY and shall be scalar if (optional) ARRAY has rank one; otherwise, it shall be either scalar or of rank n - 1 and of shape (d1, d2, ..., dDIM , dDIM+1, ..., dn). BOUNDARY may be omitted for the -1 types in the following table and, in this case, it is as if it were present with the scalar value shown converted, if necessary, to the kind type parameter value of ARRAY. Type of ARRAY Value of BOUNDARY Integer 0 Real 0.0 Complex (0.0, 0.0) Logical false Character (len) len blanks Bits B'0' 1 DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is 2 the rank of ARRAY. If DIM is omitted, it is as if it were present with the value 1. 3Result Characteristics. The result has the type, type parameters, and shape of ARRAY. 4Result Value. Element (s1, s2, ..., sn) of the result has the value ARRAY (s1, s2, ..., sDIM , -1 5sDIM +sh, sDIM+1, ..., sn) where sh is SHIFT or SHIFT (s1, s2, ..., sDIM , sDIM+1, ..., sn) provided -1 6the inequality LBOUND (ARRAY, DIM) sDIM + sh UBOUND (ARRAY, DIM) holds and is 7otherwise BOUNDARY or BOUNDARY (s1, s2, ..., sDIM , sDIM+1, ..., sn). -1 8Examples. 9Case (i): If V is the array [1, 2, 3, 4, 5, 6], the effect of shifting V end-off to the left by 3 positions is 10 achieved by EOSHIFT (V, SHIFT = 3), which has the value [4, 5, 6, 0, 0, 0]; EOSHIFT (V, 11 SHIFT = ­2, BOUNDARY = 99) achieves an end-off shift to the right by 2 positions with the boundary value of 99 and has the value [99, 99, 1, 2, 3, 4]. 12 13Case (ii): The rows of an array of rank two may all be shifted by the same amount or by different 14 amounts and the boundary elements can be the same or different. If M is the array A B C 15 D E F then the value of EOSHIFT (M, SHIFT = ­1, BOUNDARY = '*', DIM = , G H I * A B 16 2) is * D E and the value of EOSHIFT (M, SHIFT = [­1, 1, 0], BOUNDARY = , G H * A B ['*', '/', '?'], DIM = 2) is E F / . G H I 17 13.7.59 EPSILON (X) 18 19Description. Returns a positive model number that is almost negligible compared to unity of the model 20representing numbers of the same type and kind type parameter as the argument. 21Class. Inquiry function. 22Argument. X shall be of type real. It may be a scalar or an array. 23Result Characteristics. Scalar of the same type and kind type parameter as X. -p 24Result Value. The result has the value b1 where b and p are as defined in 13.4 for the model 25representing numbers of the same type and kind type parameter as X. 377 J3/07-007 WORKING DRAFT 2006/01/05 Example. EPSILON (X) has the value 2-23 for real X whose model is as in Note 13.3. 1 13.7.60 ERF (X) 2 3Description. Error function. 4Class. Elemental function. 5Argument. X shall be of type real. 6Result Characteristics. Same as X. 7Result Value. The result has a value equal to a processor-dependent approximation to the error function of X, 2 X exp(-t2)dt. 8 0 Example. ERF (1.0) has the value 0.843 (approximately). 9 13.7.61 ERFC (X) 10 11Description. Complementary error function. 12Class. Elemental function. 13Argument. X shall be of type real. 14Result Characteristics. Same as X. 15Result Value. The result has a value equal to a processor-dependent approximation to the comple- mentary error function of X, that is, 1 - ERF (X). 16 Example. ERFC (1.0) has the value 0.157 (approximately). 17 13.7.62 ERFC SCALED (X) 18 19Description. Exponentially-scaled complementary error function. 20Class. Elemental function. 21Argument. X shall be of type real. 22Result Characteristics. Same as X. 23Result Value. The result has a value equal to a processor-dependent approximation to the exponentially- scaled complementary error function of X, exp(X2)2 exp(-t2)dt. 24 X Example. ERFC SCALED (20.0) has the value 0.02817434874 (approximately). 25 NOTE 13.8 The complementary error function is asymptotic to exp(-X2)/(X ). As such it underflows for X > 9 when using IEEE single precision arithmetic. The exponentially-scaled complementary error function is asymptotic to 1/(X ). As such it does not underflow until X > HUGE (X)/ . 13.7.63 EXECUTE COMMAND LINE (COMMAND [, WAIT, EXITSTAT, CMDSTAT, CMDMSG ]) 26 27Description. Execute the command line specified by the string COMMAND. If the processor supports 28command line execution, it shall support synchronous and may support asynchronous execution of the 378 2006/01/05 WORKING DRAFT J3/07-007 1command line. 2Class. Subroutine. 3Arguments. COMMAND shall be of type default character and shall be scalar. It is an INTENT(IN) argu- ment. Its value is the command line to be executed. The interpretation is processor- 4 dependent. WAIT (optional) shall be of type default logical and shall be scalar. It is an INTENT(IN) argument. If WAIT is present with the value false, and the processor supports asynchronous execution of the command, the command is executed asynchronously; otherwise it is 5 executed synchronously. EXITSTAT shall be of type default integer and shall be a scalar. It is an INTENT(INOUT) (optional) argument. If the command is executed synchronously, it is assigned the value of the 6 processor-dependent exit status. Otherwise, the value of EXITSTAT is unchanged. CMDSTAT shall be of type default integer and shall be a scalar. It is an INTENT(OUT) argu- (optional) ment. It is assigned the value -1 if the processor does not support command line execution, a processor-dependent positive value if an error condition occurs, or the value -2 if no error condition occurs but WAIT is present with the value false and the processor does not support asynchronous execution. Otherwise it is assigned the 7 value 0. CMDMSG shall be of type default character and shall be a scalar. It is an INTENT(INOUT) ar- (optional) gument. If an error condition occurs, it is assigned a processor-dependent explanatory 8 message. Otherwise, it is unchanged. 9When the command is executed synchronously, EXECUTE COMMAND LINE returns after the com- 10mand line has completed execution. Otherwise, EXECUTE COMMAND LINE returns without waiting. 11If an error condition occurs and CMDSTAT is not present, execution of the program is terminated. 13.7.64 EXP (X) 12 13Description. Exponential. 14Class. Elemental function. 15Argument. X shall be of type real or complex. 16Result Characteristics. Same as X. 17Result Value. The result has a value equal to a processor-dependent approximation to eX. If X is of 18type complex, its imaginary part is regarded as a value in radians. Example. EXP (1.0) has the value 2.7182818 (approximately). 19 13.7.65 EXPONENT (X) 20 21Description. Returns the exponent part of the argument when represented as a model number. 22Class. Elemental function. 23Argument. X shall be of type real. 24Result Characteristics. Default integer. 379 J3/07-007 WORKING DRAFT 2006/01/05 1Result Value. The result has a value equal to the exponent e of the representation for the value of X 2in the model (13.4) that has the radix of X but no limits on exponent values, provided X is nonzero and 3e is within the range for default integers. If X has the value zero, the result has the value zero. If X is an IEEE infinity or NaN, the result has the value HUGE(0). 4 5Examples. EXPONENT (1.0) has the value 1 and EXPONENT (4.1) has the value 3 for reals whose 6model is as in Note 13.3. 13.7.66 EXTENDS TYPE OF (A, MOLD) 7 8Description. Inquires whether the dynamic type of A is an extension type (4.5.7) of the dynamic type 9of MOLD. 10Class. Inquiry function. 11Arguments. A shall be an object of extensible type. If it is a pointer, it shall not have an undefined 12 association status. MOLD shall be an object of extensible type. If it is a pointer, it shall not have an undefined 13 association status. 14Result Characteristics. Default logical scalar. 15Result Value. If MOLD is unlimited polymorphic and is either a disassociated pointer or unallocated 16allocatable, the result is true; otherwise if A is unlimited polymorphic and is either a disassociated pointer 17or unallocated allocatable, the result is false; otherwise the result is true if and only if the dynamic type 18of A is an extension type of the dynamic type of MOLD. NOTE 13.9 The dynamic type of a disassociated pointer or unallocated allocatable is its declared type. 13.7.67 FINDLOC (ARRAY, VALUE, DIM, [,MASK, KIND, BACK]) or FINDLOC (ARRAY, VALUE, [, MASK, KIND, BACK]) 19 20Description. Determine the location of the first element of ARRAY identified by MASK along dimen- 21sion DIM having a value equal to VALUE. 22Class. Transformational function. 23Arguments. 24ARRAY shall be of intrinsic type. It shall be an array. 25VALUE shall be scalar and in type conformance with ARRAY, as specified in Table 7.12. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 26 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 27 KIND (optional) shall be a scalar integer initialization expression. 28 BACK (optional) shall be scalar and of type logical. 29 30Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 380 2006/01/05 WORKING DRAFT J3/07-007 1value of KIND; otherwise the kind type parameter is that of default integer type. If DIM is absent, the 2result is an array of rank one and of size equal to the rank of ARRAY; otherwise, the result is of rank 3n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn), where (d1, d2, ..., dn) is the shape of ARRAY. -1 4Result Value. 5Case (i): The result of FINDLOC (ARRAY, VALUE) is a rank-one array whose element values are 6 the values of the subscripts of an element of ARRAY whose value matches VALUE. The 7 ith subscript returned lies in the range 1 to ei, where ei is the extent of the ith dimension 8 of ARRAY. If no elements match VALUE or ARRAY has size zero, all elements of the 9 result are zero. 10Case (ii): The result of FINDLOC (ARRAY, VALUE, MASK = MASK) is a rank-one array whose 11 element values are the values of the subscripts of an element of ARRAY, corresponding 12 to a true element of MASK, whose value matches VALUE. The ith subscript returned lies 13 in the range 1 to ei, where ei is the extent of the ith dimension of ARRAY. If no elements 14 match VALUE, ARRAY has size zero, or every element of MASK has the value false, all 15 elements of the result are zero. 16Case (iii): If ARRAY has rank one, the result of 17 FINDLOC (ARRAY, VALUE, DIM=DIM [, MASK = MASK]) is a scalar whose value is 18 equal to that of the first element of FINDLOC (ARRAY, VALUE [, MASK = MASK]). 19 Otherwise, the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn ) of the result is -1 20 equal to FINDLOC (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn), VALUE, DIM=1, -1 21 [, MASK = MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn)]). -1 22If both ARRAY and VALUE are of type logical, the comparison is performed with the .EQV. operator; 23otherwise, the comparison is performed with the == operator. If the value of the comparison is true, 24that element of ARRAY matches VALUE. 25If only one element matches VALUE, that element's subscripts are returned. Otherwise, if more than 26one element matches VALUE and BACK is absent or present with the value false, the element whose 27subscripts are returned is the first such element, taken in array element order. If BACK is present with 28the value true, the element whose subscripts are returned is the last such element, taken in array element 29order. 30Examples. 31Case (i): The value of FINDLOC ([2, 6, 4, 6,], VALUE=6) is [2], and the value of FINDLOC ([2, 6, 4, 6], VALUE=6, BACK=.TRUE.) is [4]. 32 0 -5 7 7 T T F T 33Case (ii): If A has the value 3 4 -1 2 and M has the value T T F T FIND- , , 1 5 6 7 T T F T 34 LOC (A, 7, MASK = M) has the value [1, 4] and FINDLOC (A, 7, MASK = M, BACK = 35 .TRUE.) has the value [3, 4]. Note that this is independent of the declared lower bounds 36 for A. 37Case (iii): The value of FINDLOC ([2, 6, 4], VALUE=6, DIM=1) is 2. If B has the value 1 2 -9 38 , FINDLOC (B, VALUE=2, DIM=1) has the value [2, 1, 0] and FIND- 2 2 6 39 LOC (B, VALUE=2, DIM=2) has the value [2, 1]. Note that this is true even if B has 40 a declared lower bound other than 1. 13.7.68 FLOOR (A [, KIND]) 41 42Description. Returns the greatest integer less than or equal to its argument. 43Class. Elemental function. 381 J3/07-007 WORKING DRAFT 2006/01/05 1Arguments. 2A shall be of type real. KIND (optional) shall be a scalar integer initialization expression. 3 4Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 5value of KIND; otherwise, the kind type parameter is that of default integer type. 6Result Value. The result has a value equal to the greatest integer less than or equal to A. Examples. FLOOR (3.7) has the value 3. FLOOR (­3.7) has the value ­4. 7 13.7.69 FORM TEAM (TEAM, IMAGES [, STAT, ERRMSG]) 8 9Description. Form a team of images. 10Class. Subroutine. 11Arguments. TEAM shall be a scalar of type IMAGE TEAM (13.8.2.7). It is an INTENT(OUT) argument. 12 IMAGES shall be of rank one and type integer. It is an INTENT(IN) argument that specifies the image indices of the team members, and shall specify the same set of images on all images of the team. All the elements shall have values in the range 1, ..., NUM - IMAGES () and there shall be no repeated values. One of the elements shall have the value THIS IMAGE(). 13 STAT (optional) shall be a scalar of type default integer. It is an INTENT(OUT) argument. It is assigned a processor-dependent positive value if an error condition occurs, -1 if any of the images of the team has initiated image termination but no error condition has 14 occurred, and zero otherwise. ERRMSG shall be a scalar of type default character. It is an INTENT(INOUT) argument. If (optional) an error condition occurs, it is assigned a processor-dependent explanatory message; 15 otherwise, it is unchanged. 16If FORM TEAM is invoked by an image, it shall be invoked by the same statement on all images specified 17by the IMAGES argument. There is an implicit team synchronization after the team is formed. 18If an error condition occurs and STAT is not present, error termination occurs. 19Example. 20 The following code fragment splits images into two groups and implicitly synchronizes each of the 21 teams if there are two or more images. If there is only one image, that image becomes the only 22 team member. The members of the team may be specified in a different order on different images. 23 USE, INTRINSIC :: ISO_FORTRAN_ENV 24 INTEGER :: I 25 TYPE(IMAGE_TEAM) :: TEAM 26 IF (THIS_IMAGE()<=NUM_IMAGES()/2) THEN 27 CALL FORM_TEAM(TEAM, [(I,I=1,NUM_IMAGES()/2)]) 28 ELSE 29 CALL FORM_TEAM(TEAM, [(I,I=NUM_IMAGES()/2+1,NUM_IMAGES())]) 30 END IF 382 2006/01/05 WORKING DRAFT J3/07-007 13.7.70 FRACTION (X) 1 2Description. Returns the fractional part of the model representation of the argument value. 3Class. Elemental function. 4Argument. X shall be of type real. 5Result Characteristics. Same as X. 6Result Value. The result has the value X × b-e, where b and e are as defined in 13.4 for the represen- 7tation of X in the model that has the radix of X but no limits on exponent values. If X has the value 8zero, or is an IEEE infinity or NaN, the result has the same value as X. Example. FRACTION (3.0) has the value 0.75 for reals whose model is as in Note 13.3. 9 13.7.71 GAMMA (X) 10 11Description. Gamma function. 12Class. Elemental function. 13Argument. X shall be of type real. Its value shall not be a negative integer or zero. 14Result Characteristics. Same as X. 15Result Value. The result has a value equal to a processor-dependent approximation to the gamma function of X, (X) = tX -1exp(-t)dt. 16 0 Example. GAMMA (1.0) has the value 1.000 (approximately). 17 13.7.72 GET COMMAND ([COMMAND, LENGTH, STATUS]) 18 19Description. Returns the entire command by which the program was invoked. 20Class. Subroutine. 21Arguments. COMMAND shall be scalar and of type default character. It is an INTENT(OUT) argument. It (optional) is assigned the entire command by which the program was invoked. If the command 22 cannot be determined, COMMAND is assigned all blanks. LENGTH shall be scalar and of type default integer. It is an INTENT(OUT) argument. It is (optional) assigned the significant length of the command by which the program was invoked. The significant length may include trailing blanks if the processor allows commands with significant trailing blanks. This length does not consider any possible trunca- tion or padding in assigning the command to the COMMAND argument; in fact the COMMAND argument need not even be present. If the command length cannot be 23 determined, a length of 0 is assigned. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. It (optional) is assigned the value -1 if the COMMAND argument is present and has a length less than the significant length of the command. It is assigned a processor-dependent 24 positive value if the command retrieval fails. Otherwise it is assigned the value 0. 13.7.73 GET COMMAND ARGUMENT (NUMBER [, VALUE, LENGTH, STATUS]) 25 383 J3/07-007 WORKING DRAFT 2006/01/05 1Description. Returns a command argument. 2Class. Subroutine. 3Arguments. NUMBER shall be scalar and of type default integer. It is an INTENT(IN) argument. 4 It specifies the number of the command argument that the other arguments give information about. Useful values of NUMBER are those between 0 and the argument count returned by the COMMAND ARGUMENT COUNT intrinsic. Other values are allowed, but will result in error status return (see below). 5 Command argument 0 is defined to be the command name by which the program was invoked if the processor has such a concept. It is allowed to call the GET - COMMAND ARGUMENT procedure for command argument number 0, even if the 6 processor does not define command names or other command arguments. The remaining command arguments are numbered consecutively from 1 to the argu- 7 ment count in an order determined by the processor. VALUE shall be scalar and of type default character. It is an INTENT(OUT) argument. It is (optional) assigned the value of the command argument specified by NUMBER. If the command 8 argument value cannot be determined, VALUE is assigned all blanks. LENGTH shall be scalar and of type default integer. It is an INTENT(OUT) argument. It (optional) is assigned the significant length of the command argument specified by NUMBER. The significant length may include trailing blanks if the processor allows command arguments with significant trailing blanks. This length does not consider any possi- ble truncation or padding in assigning the command argument value to the VALUE argument; in fact the VALUE argument need not even be present. If the command 9 argument length cannot be determined, a length of 0 is assigned. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. It is (optional) assigned the value -1 if the VALUE argument is present and has a length less than the significant length of the command argument specified by NUMBER. It is assigned a processor-dependent positive value if the argument retrieval fails. Otherwise it is 10 assigned the value 0. NOTE 13.10 One possible reason for failure is that NUMBER is negative or greater than COMMAND ARGU- MENT COUNT(). 11Example. 12 Program echo 13 integer :: i 14 character :: command*32, arg*128 15 call get_command_argument(0, command) 16 write (*,*) "Command name is: ", command 17 do i = 1 , command_argument_count() 18 call get_command_argument(i, arg) 19 write (*,*) "Argument ", i, " is ", arg 20 end do 384 2006/01/05 WORKING DRAFT J3/07-007 1 end program echo 13.7.74 GET ENVIRONMENT VARIABLE (NAME [, VALUE, LENGTH, STATUS, TRIM NAME]) 2 3Description. Gets the value of an environment variable. 4Class. Subroutine. 5Arguments. NAME shall be scalar and of type default character. It is an INTENT(IN) argument. The 6 interpretation of case is processor dependent VALUE shall be a scalar of type default character. It is an INTENT(OUT) argument. It is (optional) assigned the value of the environment variable specified by NAME. VALUE is assigned all blanks if the environment variable does not exist or does not have a value or if the 7 processor does not support environment variables. LENGTH shall be a scalar of type default integer. It is an INTENT(OUT) argument. If the (optional) specified environment variable exists and has a value, LENGTH is set to the length 8 of that value. Otherwise LENGTH is set to 0. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. If the (optional) environment variable exists and either has no value or its value is successfully assigned to VALUE, STATUS is set to zero. STATUS is set to -1 if the VALUE argument is present and has a length less than the significant length of the environment variable. It is assigned the value 1 if the specified environment variable does not exist, or 2 if the processor does not support environment variables. Processor-dependent values 9 greater than 2 may be returned for other error conditions. TRIM NAME shall be a scalar of type logical. It is an INTENT(IN) argument. If TRIM NAME is (optional) present with the value false then trailing blanks in NAME are considered significant if the processor supports trailing blanks in environment variable names. Otherwise 10 trailing blanks in NAME are not considered part of the environment variable's name. 13.7.75 HUGE (X) 11 12Description. Returns the largest number of the model representing numbers of the same type and kind 13type parameter as the argument. 14Class. Inquiry function. 15Argument. X shall be of type integer, real, or bits. It may be a scalar or an array. 16Result Characteristics. Scalar of the same type and kind type parameter as X. 17Result Value. The result has the value rq - 1 if X is of type integer and (1 - b-p)bemax if X is of type 18real, where r, q, b, p, and emax are as defined in 13.4 for the model representing numbers of the same 19type and kind type parameter as X. If X is of type bits, the result value has all of its bits set to 1. Example. HUGE (X) has the value (1 - 2-24) × 2127 for real X whose model is as in Note 13.3. 20 13.7.76 HYPOT (X, Y) 21 22Description. Euclidean distance function. 23Class. Elemental function. 385 J3/07-007 WORKING DRAFT 2006/01/05 1Arguments. 2X shall be of type real. 3Y shall be of type real with the same kind type parameter as X. 4Result Characteristics. Same as X. 5Result Value. The result has a value equal to a processor-dependent approximation to the Euclidean 6distance, X2 + Y2, without undue overflow or underflow. Example. HYPOT (2.0, 1.0) has the value 2.236 (approximately). 7 13.7.77 IACHAR (C [, KIND]) 8 9Description. Returns the position of a character in the ASCII collating sequence. This is the inverse 10of the ACHAR function. 11Class. Elemental function. 12Arguments. 13C shall be of type character and of length one. KIND (optional) shall be a scalar integer initialization expression. 14 15Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 16value of KIND; otherwise, the kind type parameter is that of default integer type. 17Result Value. If C is in the collating sequence defined by the codes specified in ISO/IEC 646:1991 18(International Reference Version), the result is the position of C in that sequence and satisfies the 19inequality (0 IACHAR(C) 127). A processor-dependent value is returned if C is not in the ASCII 20collating sequence. The results are consistent with the LGE, LGT, LLE, and LLT lexical comparison 21functions. For example, if LLE (C, D) is true, IACHAR (C) <= IACHAR (D) is true where C and D are 22any two characters representable by the processor. Example. IACHAR ('X') has the value 88. 23 13.7.78 IALL (ARRAY, DIM [, MASK]) or IALL (ARRAY, [MASK]) 24 25Description. Bitwise AND of all the elements of ARRAY along dimension DIM corresponding to the 26true elements of MASK. 27Class. Transformational function. 28Arguments. 29ARRAY shall be of type integer or bits. It shall be an array. DIM shall be a scalar of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 30 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 31 32Result Characteristics. The result is of the same type and kind type parameter as ARRAY. It is 33scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank n - 1 and 34shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) where (d1, d2, ..., dn) is the shape of ARRAY. -1 386 2006/01/05 WORKING DRAFT J3/07-007 1Result Value. 2Case (i): If ARRAY has size zero the result value is equal to NOT (INT (0, KIND (ARRAY))) if 3 ARRAY is of type integer, and NOT (BITS (B'0', KIND (ARRAY))) if array is of type 4 bits. Otherwise, the result of IALL (ARRAY) has a value equal to the bitwise AND of 5 all the elements of ARRAY. 6Case (ii): The result of IALL (ARRAY, MASK=MASK) has a value equal to IALL (PACK (ARRAY, MASK)). 7 8Case (iii): The result of IALL (ARRAY, DIM=DIM [ , MASK=MASK]) has a value equal to that 9 of IALL (ARRAY [ , MASK=MASK]) if ARRAY has rank one. Otherwise, the value of 10 element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal to IALL (ARRAY (s1, -1 11 s2, ..., sDIM , :, sDIM+1, ..., sn) [, MASK = MASK (s1, s2, ..., sDIM , :, sDIM+1, -1 -1 12 ..., sn)]). 13Examples. IALL ([B'1110', B'1101', B'1011']) has the value B'1000'. IALL ([B'1110', B'1101', B'1011'], 14MASK=[.true., .false., .true]) has the value B'1010'. IALL([14, 13, 11]) has the value 8. IALL([14, 13, 11], MASK=[.true., .false., .true]) has the value 10. 15 13.7.79 IAND (I, J) 16 17Description. Performs a bitwise AND. 18Class. Elemental function. 19Arguments. 20I shall be of type integer or bits. J shall be of type integer or bits. If both I and J are of type integer, they shall have the same kind type parameter; otherwise BITS KIND (I) shall be equal to BITS - KIND (J). 21 22Result Characteristics. If I and J have the same type, the result characteristics are the same as I. 23Otherwise, the result characteristics are the same as those of the argument with integer type. 24Result Value. The result has the value obtained by combining I and J bit-by-bit according to the 25following truth table: I J IAND (I, J) 1 1 1 1 0 0 0 1 0 0 0 0 26The model for the interpretation of an integer value as a sequence of bits is in 13.3. Examples. IAND (1, 3) has the value 1. IAND (Z'12345678', Z'0000FFFF') has the value Z'00005678'. 27 13.7.80 IANY (ARRAY, DIM [, MASK]) or IANY (ARRAY, [MASK]) 28 29Description. Bitwise OR of all the elements of ARRAY along dimension DIM corresponding to the 30true elements of MASK. 31Class. Transformational function. Arguments. 387 J3/07-007 WORKING DRAFT 2006/01/05 1 2ARRAY shall be of type integer or bits. It shall be an array. DIM (optional) shall be a scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 3 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 4 5Result Characteristics. The result is of the same type and kind type parameter as ARRAY. It is 6scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank n - 1 and 7shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) where (d1, d2, ..., dn) is the shape of ARRAY. -1 8Result Value. 9Case (i): The result of IANY (ARRAY) is the bitwise OR of all the elements of ARRAY. If AR- 10 RAY has size zero the result value is equal to zero if ARRAY is of type integer, and BITS (B'0', KIND(ARRAY)) otherwise. 11 12Case (ii): The result of IANY (ARRAY, MASK=MASK) has a value equal to IANY (PACK (ARRAY, MASK)). 13 14Case (iii): The result of IANY (ARRAY, DIM=DIM [, MASK=MASK]) has a value equal to that 15 of IANY (ARRAY [, MASK=MASK]) if ARRAY has rank one. Otherwise, the value of 16 element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal to IANY (ARRAY (s1, -1 17 s2, ..., sDIM , :, sDIM+1, ..., sn) [, MASK = MASK(s1, s2, ..., sDIM , :, sDIM+1, ..., -1 -1 18 sn)]). 19Examples. IANY ([B'1110', B'1101', B'1000']) has the value B'1111'. IANY ([B'1110', B'1101', 20B'1000'], MASK=[.true., .false., .true]) has the value B'1110'. IANY ([14, 13, 8]) has the value 15. IANY ([14, 13, 8], MASK=[.true., .false., .true]) has the value 14. 21 13.7.81 IBCLR (I, POS) 22 23Description. Clears one bit to zero. 24Class. Elemental function. 25Arguments. 26I shall be of type integer or bits. POS shall be of type integer. It shall be nonnegative and less than BIT SIZE (I). 27 28Result Characteristics. Same as I. 29Result Value. The result has the value of the sequence of bits of I, except that bit POS is zero. The 30model for the interpretation of an integer value as a sequence of bits is in 13.3. 31Examples. IBCLR (14, 1) has the value 12. If V has the value [1, 2, 3, 4], the value of IB- CLR (POS = V, I = 31) is [29, 27, 23, 15].IBCLR (B'11111', 3) has the value B'10111'. 32 13.7.82 IBITS (I, POS, LEN) 33 34Description. Extracts a sequence of bits. 35Class. Elemental function. 36Arguments. 388 2006/01/05 WORKING DRAFT J3/07-007 1I shall be of type integer or bits. POS shall be of type integer. It shall be nonnegative and POS + LEN shall be less than or equal to BIT SIZE (I). 2 3LEN shall be of type integer and nonnegative. 4Result Characteristics. Same as I. 5Result Value. The result has the value of the sequence of LEN bits in I beginning at bit POS, right- 6adjusted and with all other bits zero. The model for the interpretation of an integer value as a sequence 7of bits is in 13.3. Examples. IBITS (14, 1, 3) has the value 7. IBITS (Z'ABCD', 4, 8) has the value Z'00BC'. 8 13.7.83 IBSET (I, POS) 9 10Description. Sets one bit to one. 11Class. Elemental function. 12Arguments. 13I shall be of type integer or bits. POS shall be of type integer. It shall be nonnegative and less than BIT SIZE (I). 14 15Result Characteristics. Same as I. 16Result Value. The result has the value of the sequence of bits of I, except that bit POS is one. The 17model for the interpretation of an integer value as a sequence of bits is in 13.3. 18Examples. IBSET (12, 1) has the value 14. If V has the value [1, 2, 3, 4], the value of IBSET (POS=V, I=0) is [2, 4, 8, 16]. IBSET (B'00000', 3) has the value B'01000'. 19 13.7.84 ICHAR (C [, KIND]) 20 21Description. Returns the position of a character in the processor collating sequence associated with 22the kind type parameter of the character. This is the inverse of the CHAR function. 23Class. Elemental function. 24Arguments. C shall be of type character and of length one. Its value shall be that of a character 25 capable of representation in the processor. KIND (optional) shall be a scalar integer initialization expression. 26 27Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 28value of KIND; otherwise, the kind type parameter is that of default integer type. 29Result Value. The result is the position of C in the processor collating sequence associated with 30the kind type parameter of C and is in the range 0 ICHAR(C) n - 1, where n is the number 31of characters in the collating sequence. For any characters C and D capable of representation in the 32processor, C <= D is true if and only if ICHAR (C) <= ICHAR (D) is true and C == D is true if and only if ICHAR (C) == ICHAR (D) is true. 33 34Example. ICHAR ('X') has the value 88 on a processor using the ASCII collating sequence for the 389 J3/07-007 WORKING DRAFT 2006/01/05 1default character type. 13.7.85 IEOR (I, J) 2 3Description. Performs a bitwise exclusive OR. 4Class. Elemental function. 5Arguments. 6I shall be of type integer or bits. J shall be of type integer or bits. If both I and J are of type integer, they shall have the same kind type parameter; otherwise BITS KIND (I) shall be equal to BITS - KIND (J). 7 8Result Characteristics. If I and J have the same type, the result characteristics are the same as I. 9Otherwise, the result characteristics are the same as those of the argument with integer type. 10Result Value. The result has the value obtained by combining I and J bit-by-bit according to the 11following truth table: I J IEOR (I, J) 1 1 0 1 0 1 0 1 1 0 0 0 12The model for the interpretation of an integer value as a sequence of bits is in 13.3. Examples. IEOR (1, 3) has the value 2. IEOR (O'5', B'110') has the value O'3'. 13 13.7.86 IMAGE INDEX (CO ARRAY, SUB) 14 15Description. Returns the index of the image corresponding to the co-subscripts SUB for CO ARRAY. 16Class. Inquiry function. 17Arguments. 18CO ARRAY shall be a co-array of any type. SUB shall be a rank-one array of size equal to the co-rank of CO ARRAY and shall be of 19 type integer. 20Result Characteristics. Default integer scalar. 21Result Value. If the value of SUB is a valid sequence of co-subscripts for CO ARRAY, the result is 22the index of the corresponding image. Otherwise, the result is zero. 23Examples. If A is declared A [0:*], IMAGE INDEX (A, [0]) has the value 1. If B is declared REAL B (10, 20) [10, 0:9, 0:*], IMAGE INDEX (B, [3, 1, 2]) has the value 213 (on any image). 24 NOTE 13.11 For an example of a module that implements a function similar to the intrinsic IMAGE INDEX, see subclause C.10.1. 390 2006/01/05 WORKING DRAFT J3/07-007 13.7.87 INDEX (STRING, SUBSTRING [, BACK, KIND]) 1 2Description. Returns the starting position of a substring within a string. 3Class. Elemental function. 4Arguments. 5STRING shall be of type character. 6SUBSTRING shall be of type character with the same kind type parameter as STRING. BACK (optional) shall be of type logical. 7 KIND (optional) shall be a scalar integer initialization expression. 8 9Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 10value of KIND; otherwise the kind type parameter is that of default integer type. 11Result Value. 12Case (i): If BACK is absent or has the value false, the result is the minimum positive value of I 13 such that STRING (I : I + LEN (SUBSTRING) ­ 1) = SUBSTRING or zero if there 14 is no such value. Zero is returned if LEN (STRING) < LEN (SUBSTRING) and one is returned if LEN (SUBSTRING) = 0. 15 16Case (ii): If BACK is present with the value true, the result is the maximum value of I less than or 17 equal to LEN (STRING) ­ LEN (SUBSTRING) + 1 such that STRING (I : I + LEN (SUB- 18 STRING) ­ 1) = SUBSTRING or zero if there is no such value. Zero is returned if 19 LEN (STRING) < LEN (SUBSTRING) and LEN (STRING) + 1 is returned if LEN (SUB- STRING) = 0. 20 21Examples. INDEX ('FORTRAN', 'R') has the value 3. INDEX ('FORTRAN', 'R', BACK = .TRUE.) has the value 5. 22 13.7.88 INT (A [, KIND]) 23 24Description. Convert to integer type. 25Class. Elemental function. 26Arguments. 27A shall be of type integer, real, complex, or bits. KIND (optional) shall be a scalar integer initialization expression. 28 29Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 30value of KIND; otherwise, the kind type parameter is that of default integer type. 31Result Value. Case (i): If A is of type integer, INT (A) = A. 32 33Case (ii): If A is of type real, there are two cases: if |A| < 1, INT (A) has the value 0; if |A| 1, 34 INT (A) is the integer whose magnitude is the largest integer that does not exceed the 35 magnitude of A and whose sign is the same as the sign of A. Case (iii): If A is of type complex, INT(A) = INT(REAL(A, KIND(A))). 36 37Case (iv): If A is of type bits, the result has the integer value such that 38 BITS (INT (A, kind)) = BITS (A, BITS KIND (INT (0, kind))), where kind is the kind of 391 J3/07-007 WORKING DRAFT 2006/01/05 1 the result. If the value specified by the model in 13.3 for interpreting the bits as an integer 2 is a valid value for the result, it has that value; otherwise, it is processor dependent. Example. INT (­3.7) has the value ­3. 3 13.7.89 IOR (I, J) 4 5Description. Performs a bitwise inclusive OR. 6Class. Elemental function. 7Arguments. 8I shall be of type integer or bits. J shall be of type integer or bits. If both I and J are of type integer, they shall have the same kind type parameter; otherwise BITS KIND (I) shall be equal to BITS - KIND (J). 9 10Result Characteristics. If I and J have the same type, the result characteristics are the same as I. 11Otherwise, the result characteristics are the same as those of the argument with integer type. 12Result Value. The result has the value obtained by combining I and J bit-by-bit according to the 13following truth table: I J IOR (I, J) 1 1 1 1 0 1 0 1 1 0 0 0 14The model for the interpretation of an integer value as a sequence of bits is in 13.3. Examples. IOR (5, 3) has the value 7. IOR (Z'1234, Z'00FF') has the value Z'12FF'. 15 13.7.90 IPARITY (ARRAY, DIM [, MASK]) or IPARITY (ARRAY, [MASK]) 16 17Description. Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corresponding 18to the true elements of MASK. 19Class. Transformational function. 20Arguments. 21ARRAY shall be of type integer or bits. It shall be an array. DIM shall be a scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 22 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 23 24Result Characteristics. The result is of the same type and kind type parameter as ARRAY. It is 25scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 26..., dn) where (d1, d2, ..., dn) is the shape of ARRAY. 27Result Value. 392 2006/01/05 WORKING DRAFT J3/07-007 1Case (i): The result of IPARITY (ARRAY) has a value equal to the bitwise exclusive OR of all the 2 elements of ARRAY. If ARRAY has size zero the result has the value zero if ARRAY is of type integer, and BITS (B'0', KIND (ARRAY)) otherwise. 3 4Case (ii): The result of IPARITY (ARRAY, MASK=MASK) has a value equal to that of IPAR- ITY (PACK (ARRAY, MASK)). 5 6Case (iii): The result of IPARITY (ARRAY, DIM=DIM [, MASK=MASK]) has a value equal to 7 that of IPARITY (ARRAY [, MASK=MASK]) if ARRAY has rank one. Otherwise, 8 the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal to -1 9 IPARITY (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) [, MASK = MASK(s1, s2, -1 10 ..., sDIM , :, sDIM+1, ..., sn)]). -1 11Examples. IPARITY ([B'1110', B'1101', B'1000']) has the value B'1011'. 12IPARITY ([B'1110', B'1101', B'1000'], MASK=[.true., .false., .true]) has the value B'0110'. 13IPARITY ([14, 13, 8]) has the value 11. IPARITY ([14, 13, 8], MASK=[.true., .false., .true]) has the 14value 6. 13.7.91 ISHFT (I, SHIFT) 15 16Description. Performs a logical shift. 17Class. Elemental function. 18Arguments. 19I shall be of type integer or bits. SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or equal to BIT SIZE (I). 20 21Result Characteristics. Same as I. 22Result Value. The result has the value obtained by shifting the bits of I by SHIFT positions. If SHIFT 23is positive, the shift is to the left; if SHIFT is negative, the shift is to the right; and if SHIFT is zero, no 24shift is performed. Bits shifted out from the left or from the right, as appropriate, are lost. Zeros are 25shifted in from the opposite end. The model for the interpretation of an integer value as a sequence of 26bits is in 13.3. Examples. ISHFT (3, 1) has the value 6. ISHFT (B'00000011', 1) has the value B'00000110'. 27 13.7.92 ISHFTC (I, SHIFT [, SIZE]) 28 29Description. Performs a circular shift of the rightmost bits. 30Class. Elemental function. 31Arguments. 32I shall be of type integer or bits. SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or equal to 33 SIZE. SIZE (optional) shall be of type integer. The value of SIZE shall be positive and shall not exceed BIT SIZE (I). If SIZE is absent, it is as if it were present with the value of BIT - SIZE (I). 34 35Result Characteristics. Same as I. 393 J3/07-007 WORKING DRAFT 2006/01/05 1Result Value. The result has the value obtained by shifting the SIZE rightmost bits of I circularly by 2SHIFT positions. If SHIFT is positive, the shift is to the left; if SHIFT is negative, the shift is to the 3right; and if SHIFT is zero, no shift is performed. No bits are lost. The unshifted bits are unaltered. 4The model for the interpretation of an integer value as a sequence of bits is in 13.3. Examples. ISHFTC (3, 2, 3) has the value 5. ISHFTC (Z'ABCD', 4, 8) has the value Z'ABDC'. 5 13.7.93 IS CONTIGUOUS (A) 6 Description. Determine whether an object is contiguous (5.3.6). 7 8Class. Inquiry function. 9Argument. A may be of any type. It shall be an array. If it is a pointer it shall be associated. 10Result Characteristics. Default logical scalar. 11Result Value. The result has the value true if A is contiguous, and false otherwise. 12Example. After the pointer assignment AP => TARGET (1:10:2), IS CONTIGUOUS (AP) will have 13the value false. 13.7.94 IS IOSTAT END (I) 14 15Description. Determine whether a value indicates an end-of-file condition. 16Class. Elemental function. 17Argument. I shall be of type integer. 18Result Characteristics. Default logical. 19Result Value. The result has the value true if and only if I is a value for the scalar-int-variable in an IOSTAT= specifier (9.10.4) that would indicate an end-of-file condition. 20 13.7.95 IS IOSTAT EOR (I) 21 22Description. Determine whether a value indicates an end-of-record condition. 23Class. Elemental function. 24Argument. I shall be of type integer. 25Result Characteristics. Default logical. 26Result Value. The result has the value true if and only if I is a value for the scalar-int-variable in an IOSTAT= specifier (9.10.4) that would indicate an end-of-record condition. 27 13.7.96 KIND (X) 28 29Description. Returns the value of the kind type parameter of X. 30Class. Inquiry function. 31Argument. X may be of any intrinsic type. It may be a scalar or an array. 32Result Characteristics. Default integer scalar. 33Result Value. The result has a value equal to the kind type parameter value of X. 394 2006/01/05 WORKING DRAFT J3/07-007 Example. KIND (0.0) has the kind type parameter value of default real. 1 13.7.97 LBOUND (ARRAY [, DIM, KIND]) 2 3Description. Returns all the lower bounds or a specified lower bound of an array. 4Class. Inquiry function. 5Arguments. ARRAY may be of any type. It shall be an array. It shall not be an unallocated allocatable 6 or a pointer that is not associated. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 7 dummy argument. KIND (optional) shall be a scalar integer initialization expression. 8 9Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 10value of KIND; otherwise the kind type parameter is that of default integer type. The result is scalar if 11DIM is present; otherwise, the result is an array of rank one and size n, where n is the rank of ARRAY. 12Result Value. 13Case (i): If ARRAY is a whole array or array structure component and either ARRAY is an 14 assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, 15 LBOUND (ARRAY, DIM) has a value equal to the lower bound for subscript DIM of 16 ARRAY. Otherwise the result value is 1. 17Case (ii): LBOUND (ARRAY) has a value whose ith element is equal to LBOUND (ARRAY, i), 18 for i = 1, 2,..., n, where n is the rank of ARRAY. 19Examples. If A is declared by the statement 20 REAL A (2:3, 7:10) then LBOUND (A) is [2, 7] and LBOUND (A, DIM=2) is 7. 21 13.7.98 LEADZ (I) 22 23Description. Count the number of leading zero bits. 24Class. Elemental function. 25Argument. I shall be of type integer or bits. 26Result Characteristics. Default integer. 27Result Value. If all of the bits of I are zero, the result has the value BIT SIZE (I). Otherwise, the 28result has the value BIT SIZE (I) - 1 - k, where k is the position of the leftmost 1 bit in I. The model 29for the interpretation of an integer value as a sequence of bits is in 13.3. 30Examples. LEADZ (B'001101000') has the value 2. LEADZ (1) has the value 31 if BIT SIZE (1) has 31the value 32. 13.7.99 LEN (STRING [, KIND]) 32 33Description. Returns the length of a character entity. 395 J3/07-007 WORKING DRAFT 2006/01/05 1Class. Inquiry function. 2Arguments. STRING shall be of type character. It may be a scalar or an array. If it is an unallocated allocatable or a pointer that is not associated, its length type parameter shall not be 3 deferred. KIND (optional) shall be a scalar integer initialization expression. 4 5Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified 6by the value of KIND; otherwise the kind type parameter is that of default integer type. 7Result Value. The result has a value equal to the number of characters in STRING if it is scalar or in 8an element of STRING if it is an array. 9Example. If C is declared by the statement 10 CHARACTER (11) C (100) LEN (C) has the value 11. 11 13.7.100 LEN TRIM (STRING [, KIND]) 12 13Description. Returns the length of the character argument without counting trailing blank characters. 14Class. Elemental function. 15Arguments. 16STRING shall be of type character. KIND (optional) shall be a scalar integer initialization expression. 17 18Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 19value of KIND; otherwise the kind type parameter is that of default integer type. 20Result Value. The result has a value equal to the number of characters remaining after any trailing 21blanks in STRING are removed. If the argument contains no nonblank characters, the result is zero. Examples. LEN TRIM (' A B ') has the value 4 and LEN TRIM (' ') has the value 0. 22 13.7.101 LGE (STRING A, STRING B) 23 24Description. Test whether a string is lexically greater than or equal to another string, based on the 25ASCII collating sequence. 26Class. Elemental function. 27Arguments. 28STRING A shall be of type default character of type ASCII character. 29STRING B shall be of type character with the same kind type parameter as STRING A. 30Result Characteristics. Default logical. 31Result Value. If the strings are of unequal length, the comparison is made as if the shorter string were 32extended on the right with blanks to the length of the longer string. If either string contains a character 33not in the ASCII character set, the result is processor dependent. The result is true if the strings are 396 2006/01/05 WORKING DRAFT J3/07-007 1equal or if STRING A follows STRING B in the ASCII collating sequence; otherwise, the result is false. NOTE 13.12 The result is true if both STRING A and STRING B are of zero length. Example. LGE ('ONE', 'TWO') has the value false. 2 13.7.102 LGT (STRING A, STRING B) 3 4Description. Test whether a string is lexically greater than another string, based on the ASCII collating 5sequence. 6Class. Elemental function. 7Arguments. 8STRING A shall be of type default character of type ASCII character. 9STRING B shall be of type character with the same kind type parameter as STRING A. 10Result Characteristics. Default logical. 11Result Value. If the strings are of unequal length, the comparison is made as if the shorter string were 12extended on the right with blanks to the length of the longer string. If either string contains a character 13not in the ASCII character set, the result is processor dependent. The result is true if STRING A follows 14STRING B in the ASCII collating sequence; otherwise, the result is false. NOTE 13.13 The result is false if both STRING A and STRING B are of zero length. Example. LGT ('ONE', 'TWO') has the value false. 15 13.7.103 LLE (STRING A, STRING B) 16 17Description. Test whether a string is lexically less than or equal to another string, based on the ASCII 18collating sequence. 19Class. Elemental function. 20Arguments. 21STRING A shall be of type default character of type ASCII character. 22STRING B shall be of type character with the same kind type parameter as STRING A. 23Result Characteristics. Default logical. 24Result Value. If the strings are of unequal length, the comparison is made as if the shorter string were 25extended on the right with blanks to the length of the longer string. If either string contains a character 26not in the ASCII character set, the result is processor dependent. The result is true if the strings are 27equal or if STRING A precedes STRING B in the ASCII collating sequence; otherwise, the result is 28false. NOTE 13.14 The result is true if both STRING A and STRING B are of zero length. 397 J3/07-007 WORKING DRAFT 2006/01/05 Example. LLE ('ONE', 'TWO') has the value true. 1 13.7.104 LLT (STRING A, STRING B) 2 3Description. Test whether a string is lexically less than another string, based on the . 4Class. Elemental function. 5Arguments. 6STRING A shall be of type default character of type ASCII character. 7STRING B shall be of type character with the same kind type parameter as STRING A. 8Result Characteristics. Default logical. 9Result Value. If the strings are of unequal length, the comparison is made as if the shorter string were 10extended on the right with blanks to the length of the longer string. If either string contains a character 11not in the ASCII character set, the result is processor dependent. The result is true if STRING A 12precedes STRING B in the ASCII collating sequence; otherwise, the result is false. NOTE 13.15 The result is false if both STRING A and STRING B are of zero length. Example. LLT ('ONE', 'TWO') has the value true. 13 13.7.105 LOG (X) 14 15Description. Natural logarithm. 16Class. Elemental function. 17Argument. X shall be of type real or complex. If X is real, its value shall be greater than zero. If X is 18complex, its value shall not be zero. 19Result Characteristics. Same as X. 20Result Value. The result has a value equal to a processor-dependent approximation to logeX. A result 21of type complex is the principal value with imaginary part in the range - . If the real 22part of X is less than zero and the imaginary part of X is zero, then the imaginary part of the result 23is approximately if the imaginary part of X is positive real zero or the processor cannot distinguish 24between positive and negative real zero, and approximately - if the imaginary part of X is negative 25real zero. Example. LOG (10.0) has the value 2.3025851 (approximately). 26 13.7.106 LOG GAMMA (X) 27 28Description. Logarithm of the absolute value of the gamma function. 29Class. Elemental function. 30Argument. X shall be of type real. Its value shall not be a negative integer or zero. 31Result Characteristics. Same as X. 32Result Value. The result has a value equal to a processor-dependent approximation to the natural logarithm of the absolute value of the gamma function of X. 398 2006/01/05 WORKING DRAFT J3/07-007 1 Example. LOG GAMMA (3.0) has the value 0.693 (approximately). 2 13.7.107 LOG10 (X) 3 4Description. Common logarithm. 5Class. Elemental function. 6Argument. X shall be of type real. The value of X shall be greater than zero. 7Result Characteristics. Same as X. 8Result Value. The result has a value equal to a processor-dependent approximation to log10X. Example. LOG10 (10.0) has the value 1.0 (approximately). 9 13.7.108 LOGICAL (L [, KIND]) 10 11Description. Converts between kinds of logical or from bits to logical. 12Class. Elemental function. 13Arguments. 14L shall be of type logical or bits. KIND (optional) shall be a scalar integer initialization expression. 15 16Result Characteristics. Logical. If KIND is present, the kind type parameter is that specified by the 17value of KIND; otherwise, the kind type parameter is that of default logical. 18Result Value. Case (i): If L is of type logical, the value is that of L. 19 20Case (ii): If L is of type bits and KIND (L) is greater than or equal to BITS KIND (result), the 21 physical representation of the result is the same as that of the rightmost bits of L. 22Case (iii): If L is of type bits and KIND (L) is less than BITS KIND (result), the rightmost KIND(L) 23 bits of the physical representation of the result are the same as those of L, and the 24 remaining bits of the physical representation of the result are zero. NOTE 13.16 The result of a bits to logical conversion may be used in a context requiring a logical value only if the physical representation of the result is valid as a logical value. 25Examples. LOGICAL (L .OR. .NOT. L) has the value true and is of type default logical, regardless of the kind type parameter of the logical variable L. LOGICAL (BITS (.TRUE.)) has the value true. 26 13.7.109 MASKL (I [, KIND]) 27 28Description. Generate a left justified mask. 29Class. Elemental function. 30Arguments. 399 J3/07-007 WORKING DRAFT 2006/01/05 I shall be of type integer. It shall be nonnegative and less than or equal to the kind 1 type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. 2 3Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified by the 4value of KIND; otherwise, the kind type parameter is that of default bits type. 5Result Value. The result value has its leftmost I bits set to 1 and the remaining bits set to 0. Example. MASKL (12) has the value Z'FFF00000' if the default bits kind type parameter value is 32. 6 13.7.110 MASKR (I [, KIND]) 7 8Description. Generate a right justified mask. 9Class. Elemental function. 10Arguments. I shall be of type integer. It shall be nonnegative and less than or equal to the kind 11 type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. 12 13Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified by the 14value of KIND; otherwise, the kind type parameter is that of default bits type. 15Result Value. The result value has its rightmost I bits set to 1 and the remaining bits set to 0. Example. MASKR (12) has the value Z'00000FFF' if the default bits kind type parameter value is 32. 16 13.7.111 MATMUL (MATRIX A, MATRIX B) 17 18Description. Performs matrix multiplication of numeric or logical matrices. 19Class. Transformational function. 20Arguments. MATRIX A shall be of numeric type (integer, real, or complex) or of logical type. It shall be an 21 array of rank one or two. MATRIX B shall be of numeric type if MATRIX A is of numeric type and of logical type if MA- TRIX A is of logical type. It shall be an array of rank one or two. If MATRIX A has rank one, MATRIX B shall have rank two. If MATRIX B has rank one, MATRIX A shall have rank two. The size of the first (or only) dimension of MATRIX B shall equal the size of the last (or only) dimension of MATRIX A. 22 23Result Characteristics. If the arguments are of numeric type, the type and kind type parameter of 24the result are determined by the types of the arguments as specified in 7.1.9.2 for the * operator. If the 25arguments are of type logical, the result is of type logical with the kind type parameter of the arguments 26as specified in 7.1.9.2 for the .AND. operator. The shape of the result depends on the shapes of the 27arguments as follows: 28Case (i): If MATRIX A has shape (n,m) and MATRIX B has shape (m,k), the result has shape (n,k). 29 Case (ii): If MATRIX A has shape (m) and MATRIX B has shape (m,k), the result has shape (k). 30 Case (iii): If MATRIX A has shape (n,m) and MATRIX B has shape (m), the result has shape (n). 31 400 2006/01/05 WORKING DRAFT J3/07-007 1Result Value. 2Case (i): Element (i,j) of the result has the value SUM (MATRIX A (i, :) * MATRIX B (:, j)) 3 if the arguments are of numeric type and has the value ANY (MATRIX A (i, :) .AND. MATRIX B (:, j)) if the arguments are of logical type. 4 5Case (ii): Element (j) of the result has the value SUM (MATRIX A (:) * MATRIX B (:, j)) if the 6 arguments are of numeric type and has the value ANY (MATRIX A (:) .AND. MATRIX - B (:, j)) if the arguments are of logical type. 7 8Case (iii): Element (i) of the result has the value SUM (MATRIX A (i, :) * MATRIX B (:)) if 9 the arguments are of numeric type and has the value ANY (MATRIX A (i, :) .AND. MATRIX B (:)) if the arguments are of logical type. 10 1 2 1 2 3 11Examples. Let A and B be the matrices and 2 3 let X and Y be the vectors [1, 2] ; 2 3 4 3 4 and [1, 2, 3]. 12 14 20 Case (i): The result of MATMUL (A, B) is the matrix-matrix product AB with the value . 20 29 13 Case (ii): The result of MATMUL (X, A) is the vector-matrix product XA with the value [5, 8, 11]. 14 Case (iii): The result of MATMUL (A, Y) is the matrix-vector product AY with the value [14, 20]. 15 13.7.112 MAX (A1, A2 [, A3, ...]) 16 17Description. Maximum value. 18Class. Elemental function. 19Arguments. The arguments shall all have the same type which shall be integer, real, bits, or character 20and they shall all have the same kind type parameter. 21Result Characteristics. The type and kind type parameter of the result are the same as those of 22the arguments. For arguments of character type, the length of the result is the length of the longest 23argument. 24Result Value. The value of the result is that of the largest argument. For arguments of character 25type, the result is the value that would be selected by application of intrinsic relational operators; that 26is, the collating sequence for characters with the kind type parameter of the arguments is applied. If the 27selected argument is shorter than the longest argument, the result is extended with blanks on the right 28to the length of the longest argument. 29Examples. MAX (­9.0, 7.0, 2.0) has the value 7.0, MAX ('Z', 'BB') has the value 'Z ', and MAX (['A', 'Z'], ['BB', 'Y ']) has the value ['BB', 'Z ']. MAX (B'10000', B'01111') has the value B'10000'. 30 13.7.113 MAXEXPONENT (X) 31 32Description. Returns the maximum exponent of the model representing numbers of the same type and 33kind type parameter as the argument. 34Class. Inquiry function. 35Argument. X shall be of type real. It may be a scalar or an array. 36Result Characteristics. Default integer scalar. 37Result Value. The result has the value emax, as defined in 13.4 for the model representing numbers of the same type and kind type parameter as X. 401 J3/07-007 WORKING DRAFT 2006/01/05 1 Example. MAXEXPONENT (X) has the value 127 for real X whose model is as in Note 13.3. 2 13.7.114 MAXLOC (ARRAY, DIM [, MASK, KIND, BACK]) or MAXLOC (ARRAY [, MASK, KIND, BACK]) 3 4Description. Determine the location of the first element of ARRAY along dimension DIM having the 5maximum value of the elements identified by MASK. 6Class. Transformational function. 7Arguments. 8ARRAY shall be of type integer, real, bits, or character. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 9 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 10 KIND (optional) shall be a scalar integer initialization expression. 11 BACK (optional) shall be scalar and of type logical. 12 13Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 14value of KIND; otherwise the kind type parameter is that of default integer type. If DIM is absent, the 15result is an array of rank one and of size equal to the rank of ARRAY; otherwise, the result is of rank 16n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn), where (d1, d2, ..., dn) is the shape of ARRAY. -1 17Result Value. 18Case (i): The result of MAXLOC (ARRAY) is a rank-one array whose element values are the values 19 of the subscripts of an element of ARRAY whose value equals the maximum value of all 20 of the elements of ARRAY. The ith subscript returned lies in the range 1 to ei, where ei 21 is the extent of the ith dimension of ARRAY. If ARRAY has size zero, all elements of the 22 result are zero. 23Case (ii): The result of MAXLOC (ARRAY, MASK = MASK) is a rank-one array whose element 24 values are the values of the subscripts of an element of ARRAY, corresponding to a 25 true element of MASK, whose value equals the maximum value of all such elements of 26 ARRAY. The ith subscript returned lies in the range 1 to ei, where ei is the extent of 27 the ith dimension of ARRAY. If ARRAY has size zero or every element of MASK has the 28 value false, all elements of the result are zero. 29Case (iii): If ARRAY has rank one, MAXLOC (ARRAY, DIM = DIM [, MASK = MASK]) is a 30 scalar whose value is equal to that of the first element of MAXLOC (ARRAY [, MASK = 31 MASK]). Otherwise, the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn ) of the -1 32 result is equal to 33 MAXLOC (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn), DIM=1 -1 34 [, MASK = MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 35If only one element has the maximum value, that element's subscripts are returned. Otherwise, if more 36than one element has the maximum value and BACK is absent or present with the value false, the 37element whose subscripts are returned is the first such element, taken in array element order. If BACK 38is present with the value true, the element whose subscripts are returned is the last such element, taken 39in array element order. 402 2006/01/05 WORKING DRAFT J3/07-007 1If ARRAY has type character, the result is the value that would be selected by application of intrinsic 2relational operators; that is, the collating sequence for characters with the kind type parameter of the 3arguments is applied. 4Examples. 5Case (i): The value of MAXLOC ([2, 6, 4, 6]) is [2] and the value of MAXLOC ([2, 6, 4, 6], BACK=.TRUE.) is [4]. 6 0 -5 8 -3 7Case (ii): If A has the value 3 4 -1 2 MAXLOC (A, MASK = A < 6) has the value , 1 5 6 -4 [3, 2]. Note that this is independent of the declared lower bounds for A. 8 1 3 -9 9Case (iii): The value of MAXLOC ([5, -9, 3], DIM = 1) is 1. If B has the value , 2 2 6 10 MAXLOC (B, DIM = 1) is [2, 1, 2] and MAXLOC (B, DIM = 2) is [2, 3]. Note that this 11 is independent of the declared lower bounds for B. 13.7.115 MAXVAL (ARRAY, DIM [, MASK]) or MAXVAL (ARRAY [, MASK]) 12 13Description. Maximum value of the elements of ARRAY along dimension DIM corresponding to the 14true elements of MASK. 15Class. Transformational function. 16Arguments. 17ARRAY shall be of type integer, real, bits, or character. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 18 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 19 20Result Characteristics. The result is of the same type and type parameters as ARRAY. It is scalar 21if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) -1 22where (d1, d2, ..., dn) is the shape of ARRAY. 23Result Value. 24Case (i): The result of MAXVAL (ARRAY) has a value equal to the maximum value of all the 25 elements of ARRAY if the size of ARRAY is not zero. If ARRAY has size zero and type 26 integer or real, the result has the value of the negative number of the largest magnitude 27 supported by the processor for numbers of the type and kind type parameter of ARRAY. If 28 ARRAY has size zero and type character, the result has the value of a string of characters 29 of length LEN (ARRAY), with each character equal to CHAR (0, KIND (ARRAY)). If ARRAY has size zero and type bits, the result has the value BITS (B'0', KIND(ARRAY)). 30 31Case (ii): The result of MAXVAL (ARRAY, MASK = MASK) has a value equal to that of MAX- VAL (PACK (ARRAY, MASK)). 32 33Case (iii): The result of MAXVAL (ARRAY, DIM = DIM [,MASK = MASK]) has a value equal to 34 that of MAXVAL (ARRAY [,MASK = MASK]) if ARRAY has rank one. Otherwise, the 35 value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal to -1 36 MAXVAL (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) -1 37 [, MASK = MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 38If ARRAY has type character, the result is the value that would be selected by application of intrinsic 403 J3/07-007 WORKING DRAFT 2006/01/05 1relational operators; that is, the collating sequence for characters with the kind type parameter of the 2arguments is applied. 3Examples. Case (i): The value of MAXVAL ([1, 2, 3]) is 3. 4 Case (ii): 5 MAXVAL (C, MASK = C<0.0) is the maximum of the negative elements of C. 1 3 5 6Case (iii): If B is the array , MAXVAL (B, DIM=1) is [2, 7, 6] and MAXVAL (B, 2 7 6 DIM=2) is [5, 7]. 7 13.7.116 MERGE (TSOURCE, FSOURCE, MASK) 8 9Description. Choose alternative value according to the value of a mask. 10Class. Elemental function. 11Arguments. 12TSOURCE may be of any type. 13FSOURCE shall be of the same type and type parameters as TSOURCE. 14MASK shall be of type logical. 15Result Characteristics. Same as TSOURCE. 16Result Value. The result is TSOURCE if MASK is true and FSOURCE otherwise. 1 6 5 0 3 2 17Examples. If TSOURCE is the array , FSOURCE is the array and MASK is 2 4 6 7 4 8 T . T 18the array , where "T" represents true and "." represents false, then MERGE (TSOURCE, . . T 1 3 5 19FSOURCE, MASK) is . The value of MERGE (1.0, 0.0, K > 0) is 1.0 for K = 5 and 0.0 7 4 6 20for K = ­2. 13.7.117 MERGE BITS (I, J, MASK) 21 22Description. Merge bits under mask. 23Class. Elemental function. 24Arguments. 25I shall be of type bits or integer. J shall be of type integer or bits. BITS KIND (I) shall be equal to BITS KIND (J). 26 MASK shall be of type integer or bits. BITS KIND (I) shall be equal to BITS KIND (MASK). 27 28All integer arguments shall have the same kind type parameter. 29Result Characteristics. If I, J and MASK all have the same type, the result characteristics are the 30same as I. Otherwise, the result characteristics are the same as those of the argument(s) with integer 31type. Result Value. The result has the value of IOR (IAND (I, MASK), IAND (J, NOT (MASK))). 32 404 2006/01/05 WORKING DRAFT J3/07-007 Example. MERGE BITS(Z'0123', Z'89AB', Z'FF00') has the value Z'01AB'. 1 13.7.118 MIN (A1, A2 [, A3, ...]) 2 3Description. Minimum value. 4Class. Elemental function. 5Arguments. The arguments shall all be of the same type which shall be integer, real, bits, or character 6and they shall all have the same kind type parameter. 7Result Characteristics. The type and kind type parameter of the result are the same as those of 8the arguments. For arguments of character type, the length of the result is the length of the longest 9argument. 10Result Value. The value of the result is that of the smallest argument. For arguments of character 11type, the result is the value that would be selected by application of intrinsic relational operators; that 12is, the collating sequence for characters with the kind type parameter of the arguments is applied. If the 13selected argument is shorter than the longest argument, the result is extended with blanks on the right 14to the length of the longest argument. 15Examples. MIN (­9.0, 7.0, 2.0) has the value ­9.0, MIN ('A', 'YY') has the value 'A ', and MIN (['Z', 'A'], ['YY', 'B ']) has the value ['YY', 'A ']. MIN (B'10000', B'01111') has the value B'01111'. 16 13.7.119 MINEXPONENT (X) 17 18Description. Returns the minimum (most negative) exponent of the model representing numbers of 19the same type and kind type parameter as the argument. 20Class. Inquiry function. 21Argument. X shall be of type real. It may be a scalar or an array. 22Result Characteristics. Default integer scalar. 23Result Value. The result has the value emin, as defined in 13.4 for the model representing numbers of 24the same type and kind type parameter as X. Example. MINEXPONENT (X) has the value ­126 for real X whose model is as in Note 13.3. 25 13.7.120 MINLOC (ARRAY, DIM [, MASK, KIND, BACK]) or MINLOC (ARRAY [, MASK, KIND, BACK]) 26 27Description. Determine the location of the first element of ARRAY along dimension DIM having the 28minimum value of the elements identified by MASK. 29Class. Transformational function. 30Arguments. 31ARRAY shall be of type integer, real, bits, or character. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 32 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 33 405 J3/07-007 WORKING DRAFT 2006/01/05 KIND (optional) shall be a scalar integer initialization expression. 1 BACK (optional) shall be scalar and of type logical. 2 3Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 4value of KIND; otherwise the kind type parameter is that of default integer type. If DIM is absent, the 5result is an array of rank one and of size equal to the rank of ARRAY; otherwise, the result is of rank 6n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn), where (d1, d2, ..., dn) is the shape of ARRAY. -1 7Result Value. 8Case (i): The result of MINLOC (ARRAY) is a rank-one array whose element values are the values 9 of the subscripts of an element of ARRAY whose value equals the minimum value of all 10 the elements of ARRAY. The ith subscript returned lies in the range 1 to ei, where ei is 11 the extent of the ith dimension of ARRAY. If ARRAY has size zero, all elements of the 12 result are zero. 13Case (ii): The result of MINLOC (ARRAY, MASK = MASK) is a rank-one array whose element 14 values are the values of the subscripts of an element of ARRAY, corresponding to a 15 true element of MASK, whose value equals the minimum value of all such elements of 16 ARRAY. The ith subscript returned lies in the range 1 to ei, where ei is the extent of 17 the ith dimension of ARRAY. If ARRAY has size zero or every element of MASK has the 18 value false, all elements of the result are zero. 19Case (iii): If ARRAY has rank one, MINLOC (ARRAY, DIM = DIM [, MASK = MASK]) is a scalar 20 whose value is equal to that of the first element of MINLOC (ARRAY [, MASK = MASK]). 21 Otherwise, the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal -1 22 to 23 MINLOC (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn), DIM=1 -1 24 [, MASK = MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 25If only one element has the minimum value, that elements subscripts are returned. Otherwise, if more 26than one element has the minimum value and BACK is absent or present with the value false, the 27element whose subscripts are returned is the first such element, taken in array element order. If BACK 28is present with the value true, the element whose subscripts are returned is the last such element, taken 29in array element order. 30If ARRAY has type character, the result is the value that would be selected by application of intrinsic 31relational operators; that is, the collating sequence for characters with the kind type parameter of the 32arguments is applied. 33Examples. 34Case (i): The value of MINLOC ([4, 3, 6, 3]) is [2] and the value of MINLOC ([4, 3, 6, 3], BACK = .TRUE.) is [4]. 35 0 -5 8 -3 36Case (ii): If A has the value 3 4 -1 2 MINLOC (A, MASK = A > -4) has the value , 1 5 6 -4 [1, 4]. Note that this is independent of the declared lower bounds for A. 37 1 3 -9 38Case (iii): The value of MINLOC ([5, -9, 3], DIM = 1) is 2. If B has the value , 2 2 6 39 MINLOC (B, DIM = 1) is [1, 2, 1] and MINLOC (B, DIM = 2) is [3, 1]. Note that this 40 is independent of the declared lower bounds for B. 13.7.121 MINVAL (ARRAY, DIM [, MASK]) or MINVAL (ARRAY [, MASK]) 41 406 2006/01/05 WORKING DRAFT J3/07-007 1Description. Minimum value of all the elements of ARRAY along dimension DIM corresponding to 2true elements of MASK. 3Class. Transformational function. 4Arguments. 5ARRAY shall be of type integer, real, bits, or character. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 6 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 7 8Result Characteristics. The result is of the same type and type parameters as ARRAY. It is scalar 9if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, ..., dn) -1 10where (d1, d2, ..., dn) is the shape of ARRAY. 11Result Value. 12Case (i): The result of MINVAL (ARRAY) has a value equal to the minimum value of all the 13 elements of ARRAY if the size of ARRAY is not zero. If ARRAY has size zero and type 14 integer or real, the result has the value of the positive number of the largest magnitude 15 supported by the processor for numbers of the type and kind type parameter of ARRAY. If 16 ARRAY has size zero and type character, the result has the value of a string of characters 17 of length LEN (ARRAY), with each character equal to CHAR (n - 1, KIND (ARRAY)), 18 where n is the number of characters in the collating sequence for characters with the kind 19 type parameter of ARRAY. If ARRAY has size zero and type bits, the result has the value NOT (BITS (B'0', KIND(ARRAY))). 20 21Case (ii): The result of MINVAL (ARRAY, MASK = MASK) has a value equal to that of MIN- VAL (PACK (ARRAY, MASK)). 22 23Case (iii): The result of MINVAL (ARRAY, DIM = DIM [, MASK = MASK]) has a value equal to 24 that of MINVAL (ARRAY [, MASK = MASK]) if ARRAY has rank one. Otherwise, the 25 value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of the result is equal to -1 26 MINVAL (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) -1 27 [, MASK= MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 28If ARRAY has type character, the result is the value that would be selected by application of intrinsic 29relational operators; that is, the collating sequence for characters with the kind type parameter of the 30arguments is applied. 31Examples. Case (i): The value of MINVAL ([1, 2, 3]) is 1. 32 Case (ii): 33 MINVAL (C, MASK = C>0.0) is the minimum of the positive elements of C. 1 3 5 34Case (iii): If B is the array , MINVAL (B, DIM = 1) is [1, 3, 5] and MINVAL (B, DIM = 2 4 6 2) is [1, 2]. 35 13.7.122 MOD (A, P) 36 37Description. Remainder function. 38Class. Elemental function. Arguments. 407 J3/07-007 WORKING DRAFT 2006/01/05 1 2A shall be of type integer or real. 3P shall be of the same type and kind type parameter as A. P shall not be zero. 4Result Characteristics. Same as A. Result Value. The value of the result is A - INT (A/P) * P. 5 6Examples. MOD (3.0, 2.0) has the value 1.0 (approximately). MOD (8, 5) has the value 3. MOD (-8, 5) has the value -3. MOD (8, -5) has the value 3. MOD (-8, -5) has the value -3. 7 13.7.123 MODULO (A, P) 8 9Description. Modulo function. 10Class. Elemental function. 11Arguments. 12A shall be of type integer or real. 13P shall be of the same type and kind type parameter as A. P shall not be zero. 14Result Characteristics. Same as A. 15Result Value. 16Case (i): A is of type integer. MODULO (A, P) has the value R such that A = Q × P + R, where 17 Q is an integer, the inequalities 0 R < P hold if P > 0, and P < R 0 hold if P < 0. Case (ii): A is of type real. The value of the result is A - FLOOR (A / P) * P. 18 19Examples. MODULO (8, 5) has the value 3. MODULO (-8, 5) has the value 2. MODULO (8, -5) has the value -2. MODULO (-8, -5) has the value -3. 20 13.7.124 MOVE ALLOC (FROM, TO) 21 22Description. Moves an allocation from one allocatable object to another. 23Class. Pure subroutine. 24Arguments. FROM may be of any type and rank. It shall be allocatable. It is an INTENT(INOUT) 25 argument. TO shall be type compatible (4.3.1.3) with FROM and have the same rank. It shall be allocatable. It shall be polymorphic if FROM is polymorphic. It is an INTENT(OUT) argument. Each nondeferred parameter of the declared type of TO shall have the same 26 value as the corresponding parameter of the declared type of FROM. 27The allocation status of TO becomes unallocated if FROM is unallocated on entry to MOVE ALLOC. 28Otherwise, TO becomes allocated with dynamic type, type parameters, array bounds, and value identical 29to those that FROM had on entry to MOVE ALLOC. 30If TO has the TARGET attribute, any pointer associated with FROM on entry to MOVE ALLOC 31becomes correspondingly associated with TO. If TO does not have the TARGET attribute, the pointer 32association status of any pointer associated with FROM on entry becomes undefined. 408 2006/01/05 WORKING DRAFT J3/07-007 1The allocation status of FROM becomes unallocated. 2Example. 3 REAL,ALLOCATABLE :: GRID(:),TEMPGRID(:) 4 ... 5 ALLOCATE(GRID(-N:N)) ! initial allocation of GRID 6 ... 7 ! "reallocation" of GRID to allow intermediate points 8 ALLOCATE(TEMPGRID(-2*N:2*N)) ! allocate bigger grid 9 TEMPGRID(::2)=GRID ! distribute values to new locations 10 CALL MOVE_ALLOC(TO=GRID,FROM=TEMPGRID) 11 ! old grid is deallocated because TO is 12 ! INTENT(OUT), and GRID then "takes over" 13 ! new grid allocation NOTE 13.17 It is expected that the implementation of allocatable objects will typically involve descriptors to locate the allocated storage; MOVE ALLOC could then be implemented by transferring the contents of the descriptor for FROM to the descriptor for TO and clearing the descriptor for FROM. 13.7.125 MVBITS (FROM, FROMPOS, LEN, TO, TOPOS) 14 15Description. Copies a sequence of bits from one data object to another. 16Class. Elemental subroutine. 17Arguments. FROM shall be of type integer or bits. It is an INTENT (IN) argument. 18 FROMPOS shall be of type integer and nonnegative. It is an INTENT (IN) argument. FROMPOS + LEN shall be less than or equal to BIT SIZE (FROM). The model 19 for the interpretation of an integer value as a sequence of bits is in 13.3. LEN shall be of type integer and nonnegative. It is an INTENT (IN) argument. 20 TO shall be a variable of the same type and kind type parameter value as FROM and may be associated with FROM (12.8.3). It is an INTENT (INOUT) argument. TO is defined by copying the sequence of bits of length LEN, starting at position FROMPOS of FROM to position TOPOS of TO. No other bits of TO are altered. On return, the LEN bits of TO starting at TOPOS are equal to the value that the LEN bits of FROM starting at FROMPOS had on entry. The model for the interpretation of an 21 integer value as a sequence of bits is in 13.3. TOPOS shall be of type integer and nonnegative. It is an INTENT (IN) argument. TOPOS + LEN shall be less than or equal to BIT SIZE (TO). 22 23Examples. If TO has the initial value 6, the value of TO after the statement 24CALL MVBITS (7, 2, 2, TO, 0) is 5. If TO has the initial value B'000000111111', the value of TO after the statement CALL MVBITS (B'000000000011', 0, 2, TO, 8) is B'001100111111'. 25 409 J3/07-007 WORKING DRAFT 2006/01/05 13.7.126 NEAREST (X, S) 1 2Description. Returns the nearest different machine-representable number in a given direction. 3Class. Elemental function. 4Arguments. 5X shall be of type real. 6S shall be of type real and not equal to zero. 7Result Characteristics. Same as X. 8Result Value. The result has a value equal to the machine-representable number distinct from X and 9nearest to it in the direction of the infinity with the same sign as S. 10Example. NEAREST (3.0, 2.0) has the value 3 + 2-22 on a machine whose representation is that of 11the model in Note 13.3. NOTE 13.18 Unlike other floating-point manipulation functions, NEAREST operates on machine-representable numbers rather than model numbers. On many systems there are machine-representable numbers that lie between adjacent model numbers. 13.7.127 NEW LINE (A) 12 13Description. Returns a newline character. 14Class. Inquiry function. 15Argument. A shall be of type character. It may be a scalar or an array. 16Result Characteristics. Character scalar of length one with the same kind type parameter as A. 17Result Value. 18Case (i): If A is of the default character type and the character in position 10 of the ASCII collating sequence is representable in the default character set, then the result is ACHAR(10). 19 20Case (ii): If A is of the ASCII character type or the ISO 10646 character type, then the result is CHAR(10,KIND(A)). 21 22Case (iii): Otherwise, the result is a processor-dependent character that represents a newline in 23 output to files connected for formatted stream output if there is such a character. Case (iv): Otherwise, the result is the blank character. 24 13.7.128 NINT (A [, KIND]) 25 26Description. Nearest integer. 27Class. Elemental function. 28Arguments. 29A shall be of type real. KIND (optional) shall be a scalar integer initialization expression. 30 410 2006/01/05 WORKING DRAFT J3/07-007 1Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 2value of KIND; otherwise, the kind type parameter is that of default integer type. 3Result Value. The result is the integer nearest A, or if there are two integers equally near A, the result 4is whichever such integer has the greater magnitude. Example. NINT (2.783) has the value 3. 5 13.7.129 NOT (I) 6 7Description. Performs a bitwise complement. 8Class. Elemental function. 9Argument. I shall be of type integer or bits. 10Result Characteristics. Same as I. 11Result Value. The result has the value obtained by complementing I bit-by-bit according to the 12following truth table: I NOT (I) 1 0 0 1 13The model for the interpretation of an integer value as a sequence of bits is in 13.3. 14Examples. If I is represented by the string of bits 01010101, NOT (I) has the binary value 10101010. NOT (Z'FFFF0000') has the value Z'0000FFFF'. 15 13.7.130 NORM2 (X) 16 17Description. L2 norm of an array. 18Class. Transformational function. 19Argument. X shall be of type real. It shall be an array. 20Result Characteristics. Scalar of the same type and kind type parameter value as X. 21Result Value. The result has a value equal to a processor-dependent approximation to the generalized 22L2 norm of X, which is the square root of the sum of the squares of the elements of X. It is recommended 23that the processor compute the result without undue overflow or underflow. Example. The value of NORM2 ([3.0, 4.0]) is 5.0 (approximately). 24 13.7.131 NULL ([MOLD]) 25 26Description. Returns a disassociated pointer or designates an unallocated allocatable component of a 27structure constructor. 28Class. Transformational function. 29Argument. MOLD shall be a pointer or allocatable. It may be of any type or may be a procedure 30pointer. If MOLD is a pointer its pointer association status may be undefined, disassociated, or asso- 31ciated. If MOLD is allocatable its allocation status may be allocated or unallocated. It need not be 32defined with a value. 411 J3/07-007 WORKING DRAFT 2006/01/05 1Result Characteristics. If MOLD is present, the characteristics are the same as MOLD. If MOLD 2has deferred type parameters, those type parameters of the result are deferred. 3If MOLD is absent, the characteristics of the result are determined by the entity with which the reference 4is associated. See Table 13.1. MOLD shall not be absent in any other context. If any type parameters 5of the contextual entity are deferred, those type parameters of the result are deferred. If any type 6parameters of the contextual entity are assumed, MOLD shall be present. 7If the context of the reference to NULL is an actual argument to a generic procedure, MOLD shall be 8present if the type, type parameters, or rank are required to resolve the generic reference. MOLD shall 9also be present if the reference appears as an actual argument corresponding to a dummy argument with 10assumed character length. Table 13.1: Characteristics of the result of NULL ( ) Appearance of NULL ( ) Type, type parameters, and rank of result: right side of a pointer assignment pointer on the left side initialization for an object in a declaration the object default initialization for a component the component in a structure constructor the corresponding component as an actual argument the corresponding dummy argument in a DATA statement the corresponding pointer object 11Result. The result is a disassociated pointer or an unallocated allocatable entity. 12Examples. 13Case (i): REAL, POINTER, DIMENSION(:) :: VEC => NULL ( ) defines the initial association 14 status of VEC to be disassociated. Case (ii): The MOLD argument is required in the following: 15 16 INTERFACE GEN 17 SUBROUTINE S1 (J, PI) 18 INTEGER J 19 INTEGER, POINTER :: PI 20 END SUBROUTINE S1 21 SUBROUTINE S2 (K, PR) 22 INTEGER K 23 REAL, POINTER :: PR 24 END SUBROUTINE S2 25 END INTERFACE 26 REAL, POINTER :: REAL_PTR 27 CALL GEN (7, NULL (REAL_PTR) ) ! Invokes S2 13.7.132 NUM IMAGES () 28 29Description. Returns the number of images. 30Class. Inquiry function. 31Argument. None. Result Characteristics. Default integer scalar. 412 2006/01/05 WORKING DRAFT J3/07-007 1 2Result Value. The number of images. 3Example. The following code uses image 1 to read data and broadcast it to other images. 4 REAL :: P[*] 5 IF (THIS_IMAGE()==1) THEN 6 READ (6,*) P 7 DO I = 2, NUM_IMAGES() 8 P[I] = P 9 END DO 10 END IF 11 SYNC ALL 13.7.133 PACK (ARRAY, MASK [, VECTOR]) 12 13Description. Pack an array into an array of rank one under the control of a mask. 14Class. Transformational function. 15Arguments. 16ARRAY may be of any type. It shall be an array. 17MASK shall be of type logical and shall be conformable with ARRAY. VECTOR shall be of the same type and type parameters as ARRAY and shall have rank one. (optional) VECTOR shall have at least as many elements as there are true elements in MASK. If MASK is scalar with the value true, VECTOR shall have at least as many elements 18 as there are in ARRAY. 19Result Characteristics. The result is an array of rank one with the same type and type parameters 20as ARRAY. If VECTOR is present, the result size is that of VECTOR; otherwise, the result size is the 21number t of true elements in MASK unless MASK is scalar with the value true, in which case the result 22size is the size of ARRAY. 23Result Value. Element i of the result is the element of ARRAY that corresponds to the ith true 24element of MASK, taking elements in array element order, for i = 1, 2, ..., t. If VECTOR is present and has size n > t, element i of the result has the value VECTOR (i), for i = t + 1, ..., n. 25 0 0 0 26Examples. The nonzero elements of an array M with the value 9 0 0 may be "gathered" by the 0 0 7 27function PACK. The result of PACK (M, MASK = M/=0) is [9, 7] and the result of PACK (M, M /= 0, VECTOR = [2, 4, 6, 8, 10, 12]) is [9, 7, 6, 8, 10, 12]. 28 13.7.134 PARITY (MASK [, DIM]) 29 30Description. Determine whether an odd number of values are true in MASK along dimension DIM. 31Class. Transformational function. 32Arguments. MASK shall be of type logical. It shall be an array. 413 J3/07-007 WORKING DRAFT 2006/01/05 1 DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of MASK. The corresponding actual argument shall not be an optional 2 dummy argument. 3Result Characteristics. The result is of type logical with the same kind type parameter as MASK. It 4is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 5..., dn) where (d1, d2, ..., dn) is the shape of MASK. 6Result Value. 7Case (i): The result of PARITY (MASK) has the value true if an odd number of the elements of 8 MASK are true, and false otherwise. 9Case (ii): If MASK has rank one, PARITY (MASK, DIM) is equal to PARITY (MASK). Otherwise, 10 the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of PARITY (MASK, DIM) is -1 11 equal to PARITY (MASK (s1, s2, ..., sDIM , :, sDIM+1, ..., sn)). -1 12Examples. 13Case (i): The value of PARITY ([T, T, T, F]) is true if T has the value true and F has the value 14 false. T T F 15Case (ii): If B is the array , where T has the value true and F has the value false, T T T 16 then PARITY (B, DIM=1) has the value [F, F, T] and PARITY (B, DIM=2) has the value [F, T]. 17 13.7.135 POPCNT (I) 18 19Description. Return the number of one bits. 20Class. Elemental function. 21Argument. I shall be of type integer or bits. 22Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 23value of KIND; otherwise, the kind type parameter is that of the default integer type. 24Result Value. If I is of type integer, the result value is equal to the number of one bits in the sequence 25of bits of I. The model for the interpretation of an integer value as a sequence of bits is in 13.3. If I is 26of type bits, the result value is the number of one bits in I. 27Examples. POPCNT ([1, 2, 3, 4, 5, 6]) has the value [1, 1, 2, 1, 2, 2]. POPCNT (Z'FFFF0000') has the value 16. If B is of type bits, POPCNT (HUGE (B)) has the same value as KIND (B). 28 13.7.136 POPPAR (I) 29 30Description. Return the bitwise parity. 31Class. Elemental function. 32Argument. I shall be of type integer or bits. 33Result Characteristics. Default integer. Result Value. POPPAR (I) has the value 1 if POPCNT (I) is odd, and 0 if POPCNT (I) is even. 34 35Examples. POPPAR ([1, 2, 3, 4, 5, 6]) has the value [1, 1, 0, 1, 0, 0]. POPPAR (Z'FFFF0000') has 36the value 0. 414 2006/01/05 WORKING DRAFT J3/07-007 13.7.137 PRECISION (X) 1 2Description. Returns the decimal precision of the model representing real numbers with the same kind 3type parameter as the argument. 4Class. Inquiry function. 5Argument. X shall be of type real or complex. It may be a scalar or an array. 6Result Characteristics. Default integer scalar. 7Result Value. The result has the value INT ((p - 1) * LOG10 (b)) + k, where b and p are as defined 8in 13.4 for the model representing real numbers with the same value for the kind type parameter as X, 9and where k is 1 if b is an integral power of 10 and 0 otherwise. 10Example. PRECISION (X) has the value INT (23 * LOG10 (2.)) = INT (6.92...) = 6 for real X whose 11model is as in Note 13.3. 13.7.138 PRESENT (A) 12 13Description. Determine whether an optional argument is present. 14Class. Inquiry function. 15Argument. A shall be the name of an optional dummy argument that is accessible in the subprogram 16in which the PRESENT function reference appears. It may be of any type and it may be a pointer. It 17may be a scalar or an array. It may be a dummy procedure. The dummy argument A has no INTENT 18attribute. 19Result Characteristics. Default logical scalar. 20Result Value. The result has the value true if A is present (12.5.2.13) and otherwise has the value 21false. NOTE 13.19 The PRESENT intrinsic function is also used during macro expansion (3.5.2.2). 13.7.139 PRODUCT (ARRAY, DIM [, MASK]) or PRODUCT (ARRAY [, MASK]) 22 23Description. Product of all the elements of ARRAY along dimension DIM corresponding to the true 24elements of MASK. 25Class. Transformational function. 26Arguments. 27ARRAY shall be of type integer, real, or complex. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 28 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 29 30Result Characteristics. The result is of the same type and kind type parameter as ARRAY. It is 31scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 32..., dn) where (d1, d2, ..., dn) is the shape of ARRAY. 415 J3/07-007 WORKING DRAFT 2006/01/05 1Result Value. 2Case (i): The result of PRODUCT (ARRAY) has a value equal to a processor-dependent approxi- 3 mation to the product of all the elements of ARRAY or has the value one if ARRAY has 4 size zero. 5Case (ii): The result of PRODUCT (ARRAY, MASK = MASK) has a value equal to a processor- 6 dependent approximation to the product of the elements of ARRAY corresponding to the 7 true elements of MASK or has the value one if there are no true elements. 8Case (iii): If ARRAY has rank one, PRODUCT (ARRAY, DIM = DIM [, MASK = MASK]) 9 has a value equal to that of PRODUCT (ARRAY [, MASK = MASK ]). Otherwise, 10 the value of element (s1, s2, ..., sDIM , sDIM+1, ..., sn) of PRODUCT (ARRAY, -1 DIM = DIM [ ,MASK = MASK]) is equal to 11 12 PRODUCT (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) [, MASK = MASK -1 13 (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 14Examples. Case (i): The value of PRODUCT ([1, 2, 3]) is 6. 15 Case (ii): 16 PRODUCT (C, MASK = C > 0.0) forms the product of the positive elements of C. 1 3 5 17Case (iii): If B is the array , PRODUCT (B, DIM = 1) is [2, 12, 30] and PRODUCT (B, 2 4 6 DIM = 2) is [15, 48]. 18 13.7.140 RADIX (X) 19 20Description. Returns the base of the model representing numbers of the same type and kind type 21parameter as the argument. 22Class. Inquiry function. 23Argument. X shall be of type integer or real. It may be a scalar or an array. 24Result Characteristics. Default integer scalar. 25Result Value. The result has the value r if X is of type integer and the value b if X is of type real, 26where r and b are as defined in 13.4 for the model representing numbers of the same type and kind type 27parameter as X. Example. RADIX (X) has the value 2 for real X whose model is as in Note 13.3. 28 13.7.141 RANDOM NUMBER (HARVEST) 29 30Description. Returns one pseudorandom number or an array of pseudorandom numbers. 31Class. Subroutine. 32Argument. HARVEST shall be of type real or bits. It is an INTENT (OUT) argument. It may 33be a scalar or an array variable. If it is real, it is assigned pseudorandom numbers from the uniform 34distribution in the interval 0 x < 1. If it is of type bits, it is assigned pseudorandom values with each of the KIND (HARVEST) bits of each value having a probability of approximately 0.5 of being 1. 35 36Examples. 37 REAL X, Y (10, 10) 38 BITS B 416 2006/01/05 WORKING DRAFT J3/07-007 1 ! Initialize X with a pseudorandom number 2 CALL RANDOM_NUMBER (HARVEST = X) 3 CALL RANDOM_NUMBER (Y) 4 ! X and Y contain uniformly distributed random numbers 5 CALL RANDOM_NUMBER(B) 6 ! B contains a uniformly random collection of 0 and 1 bits. 13.7.142 RANDOM SEED ([SIZE, PUT, GET]) 7 8Description. Restarts or queries the pseudorandom number generator used by RANDOM NUMBER. 9Class. Subroutine. 10Arguments. There shall either be exactly one or no arguments present. SIZE (optional) shall be scalar and of type default integer. It is an INTENT (OUT) argument. It is assigned the number N of integers that the processor uses to hold the value of the 11 seed. PUT (optional) shall be a default integer array of rank one and size N. It is an INTENT (IN) argument. It is used in a processor-dependent manner to compute the seed value 12 accessed by the pseudorandom number generator. GET (optional) shall be a default integer array of rank one and size N It is an INTENT (OUT) 13 argument. It is assigned the current value of the seed. 14If no argument is present, the processor assigns a processor-dependent value to the seed. 15The pseudorandom number generator used by RANDOM NUMBER maintains a seed that is updated 16during the execution of RANDOM NUMBER and that may be specified or returned by RANDOM - 17SEED. Computation of the seed from the argument PUT is performed in a processor-dependent manner. 18The value returned by GET need not be the same as the value specified by PUT in an immediately 19preceding reference to RANDOM SEED. For example, following execution of the statements 20 CALL RANDOM_SEED (PUT=SEED1) 21 CALL RANDOM_SEED (GET=SEED2) 22SEED2 need not equal SEED1. When the values differ, the use of either value as the PUT argument 23in a subsequent call to RANDOM SEED shall result in the same sequence of pseudorandom numbers 24being generated. For example, after execution of the statements 25 CALL RANDOM_SEED (PUT=SEED1) 26 CALL RANDOM_SEED (GET=SEED2) 27 CALL RANDOM_NUMBER (X1) 28 CALL RANDOM_SEED (PUT=SEED2) 29 CALL RANDOM_NUMBER (X2) 30X2 equals X1. 31Examples. 417 J3/07-007 WORKING DRAFT 2006/01/05 1 CALL RANDOM_SEED ! Processor initialization 2 CALL RANDOM_SEED (SIZE = K) ! Puts size of seed in K 3 CALL RANDOM_SEED (PUT = SEED (1 : K)) ! Define seed 4 CALL RANDOM_SEED (GET = OLD (1 : K)) ! Read current seed 13.7.143 RANGE (X) 5 6Description. Returns the decimal exponent range of the model representing integer or real numbers 7with the same kind type parameter as the argument. 8Class. Inquiry function. 9Argument. X shall be of type integer, real, or complex. It may be a scalar or an array. 10Result Characteristics. Default integer scalar. 11Result Value. Case (i): For an integer argument, the result has the value INT (LOG10 (HUGE(X))). 12 13Case (ii): For a real argument, the result has the value INT (MIN (LOG10 (HUGE(X)), ­LOG10 (TINY(X)))). 14 Case (iii): For a complex argument, the result has the value RANGE(REAL(X)). 15 16Examples. RANGE (X) has the value 38 for real X whose model is as in Note 13.3, because in this case HUGE(X) = (1 - 2-24) × 2127 and TINY(X) = 2-127. 17 13.7.144 REAL (A [, KIND]) 18 19Description. Convert to real type. 20Class. Elemental function. 21Arguments. 22A shall be of type integer, real, complex, or bits. KIND (optional) shall be a scalar integer initialization expression. 23 24Result Characteristics. Real. 25Case (i): If A is of type integer, real, or bits, and KIND is present, the kind type parameter is that 26 specified by the value of KIND. If A is of type integer, real, or bits, and KIND is not 27 present, the kind type parameter is that of default real type. 28Case (ii): If A is of type complex and KIND is present, the kind type parameter is that specified 29 by the value of KIND. If A is of type complex and KIND is not present, the kind type 30 parameter is the kind type parameter of A. 31Result Value. 32Case (i): If A is of type integer or real, the result is equal to a processor-dependent approximation 33 to A. 34Case (ii): If A is of type complex, the result is equal to a processor-dependent approximation to the 35 real part of A. 36Case (iii): If A is of type bits and KIND (A) is greater than or equal to BITS KIND (result), the 37 result has the value whose physical representation is the same as the rightmost bits of A. 418 2006/01/05 WORKING DRAFT J3/07-007 1Case (iv): If A is of type bits and KIND (A) is less than BITS KIND (result), the rightmost 2 KIND (A) bits of the physical representation of the result value are the same as those of 3 A, and the remaining bits of the physical represention of the result value are zero. 4Examples. REAL (­3) has the value ­3.0. REAL (Z) has the same kind type parameter and the same 5value as the real part of the complex variable Z. REAL (Z'7F800000') has the value positive infinity if 6the default real kind is IEEE single precision. 13.7.145 REPEAT (STRING, NCOPIES) 7 8Description. Concatenate several copies of a string. 9Class. Transformational function. 10Arguments. 11STRING shall be scalar and of type character. 12NCOPIES shall be scalar and of type integer. Its value shall not be negative. 13Result Characteristics. Character scalar of length NCOPIES times that of STRING, with the same 14kind type parameter as STRING. 15Result Value. The value of the result is the concatenation of NCOPIES copies of STRING. 16Examples. REPEAT ('H', 2) has the value HH. REPEAT ('XYZ', 0) has the value of a zero-length 17string. 13.7.146 RESHAPE (SOURCE, SHAPE [, PAD, ORDER]) 18 19Description. Constructs an array of a specified shape from the elements of a given array. 20Class. Transformational function. 21Arguments. SOURCE may be of any type. It shall be an array. If PAD is absent or of size zero, the size of SOURCE shall be greater than or equal to PRODUCT (SHAPE). The size of the 22 result is the product of the values of the elements of SHAPE. SHAPE shall be of type integer, rank one, and constant size. Its size shall be positive and less 23 than 8. It shall not have an element whose value is negative. PAD (optional) shall be of the same type and type parameters as SOURCE. It shall be an array. 24 ORDER shall be of type integer, shall have the same shape as SHAPE, and its value shall be (optional) a permutation of (1, 2, ..., n), where n is the size of SHAPE. If absent, it is as if it were present with value (1, 2, ..., n). 25 26Result Characteristics. The result is an array of shape SHAPE (that is, SHAPE (RESHAPE (SOUR- CE, SHAPE, PAD, ORDER)) is equal to SHAPE) with the same type and type parameters as SOURCE. 27 28Result Value. The elements of the result, taken in permuted subscript order ORDER (1), ..., OR- 29DER (n), are those of SOURCE in normal array element order followed if necessary by those of PAD in 30array element order, followed if necessary by additional copies of PAD in array element order. 1 3 5 31Examples. RESHAPE ([1, 2, 3, 4, 5, 6], [2, 3]) has the value . 2 4 6 419 J3/07-007 WORKING DRAFT 2006/01/05 1 2 3 4 RESHAPE ([1, 2, 3, 4, 5, 6], [2, 4], [0, 0], [2, 1]) has the value . 5 6 0 0 1 13.7.147 RRSPACING (X) 2 3Description. Returns the reciprocal of the relative spacing of model numbers near the argument value. 4Class. Elemental function. 5Argument. X shall be of type real. 6Result Characteristics. Same as X. 7Result Value. The result has the value |X × b-e| × bp, where b, e, and p are as defined in 13.4 for the 8value nearest to X in the model for real values whose kind type parameter is that of X; if there are two 9such values, the value of greater absolute value is taken. If X is an IEEE infinity, the result is zero. If 10X is an IEEE NaN, the result is that NaN. J3 internal note Unresolved Technical Issue 092 This is contradictory for IEEE infinity: the specific sentence contradicts the formula, which would imply that RRSPACING(±)=NaN. Moreover, it appears to me that there is no limit as X- > for RRSPACING, and so the value implied by the formula (NaN) is indeed the correct value for RRSPACING(±). Example. RRSPACING (­3.0) has the value 0.75 × 224 for reals whose model is as in Note 13.3. 11 13.7.148 SAME TYPE AS (A, B) 12 13Description. Inquires whether the dynamic type of A is the same as the dynamic type of B. 14Class. Inquiry function. 15Arguments. A shall be an object of extensible type. If it is a pointer, it shall not have an undefined 16 association status. B shall be an object of extensible type. If it is a pointer, it shall not have an undefined 17 association status. 18Result Characteristics. Default logical scalar. 19Result Value. The result is true if and only if the dynamic type of A is the same as the dynamic type 20of B. NOTE 13.20 The dynamic type of a disassociated pointer or unallocated allocatable is its declared type. 13.7.149 SCALE (X, I) 21 22Description. Returns X × bI where b is the base of the model representation of X. 23Class. Elemental function. 24Arguments. 25X shall be of type real. 420 2006/01/05 WORKING DRAFT J3/07-007 1I shall be of type integer. 2Result Characteristics. Same as X. 3Result Value. The result has the value X×bI, where b is defined in 13.4 for model numbers representing 4values of X, provided this result is within range; if not, the result is processor dependent. Example. SCALE (3.0, 2) has the value 12.0 for reals whose model is as in Note 13.3. 5 13.7.150 SCAN (STRING, SET [, BACK, KIND]) 6 7Description. Scan a string for any one of the characters in a set of characters. 8Class. Elemental function. 9Arguments. 10STRING shall be of type character. 11SET shall be of type character with the same kind type parameter as STRING. BACK (optional) shall be of type logical. 12 KIND (optional) shall be a scalar integer initialization expression. 13 14Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 15value of KIND; otherwise the kind type parameter is that of default integer type. 16Result Value. 17Case (i): If BACK is absent or is present with the value false and if STRING contains at least one 18 character that is in SET, the value of the result is the position of the leftmost character 19 of STRING that is in SET. 20Case (ii): If BACK is present with the value true and if STRING contains at least one character that 21 is in SET, the value of the result is the position of the rightmost character of STRING 22 that is in SET. 23Case (iii): The value of the result is zero if no character of STRING is in SET or if the length of 24 STRING or SET is zero. 25Examples. Case (i): SCAN ('FORTRAN', 'TR') has the value 3. 26 Case (ii): SCAN ('FORTRAN', 'TR', BACK = .TRUE.) has the value 5. 27 Case (iii): SCAN ('FORTRAN', 'BCD') has the value 0. 28 13.7.151 SELECTED BITS KIND (N) 29 30Description. Returns a value of the kind type parameter of a bits type with N bits. 31Class. Transformational function. 32Argument. N shall be scalar and of type integer. 33Result Characteristics. Default integer scalar. 34Result Value. The result value is N if the processor supports a bits type with a kind type parameter 35equal to N; otherwise the result value is -1. 421 J3/07-007 WORKING DRAFT 2006/01/05 1Example. If the value of NUMERIC STORAGE SIZE is 32, SELECTED BITS KIND (43) has the 2value 43. 13.7.152 SELECTED CHAR KIND (NAME) 3 4Description. Returns the value of the kind type parameter of the character set named by the argument. 5Class. Transformational function. 6Argument. NAME shall be scalar and of type default character. 7Result Characteristics. Default integer scalar. 8Result Value. If NAME has the value DEFAULT, then the result has a value equal to that of the kind 9type parameter of the default character type. If NAME has the value ASCII, then the result has a value 10equal to that of the kind type parameter of the ASCII character type if the processor supports such a 11type; otherwise the result has the value -1. If NAME has the value ISO 10646, then the result has a 12value equal to that of the kind type parameter of the ISO/IEC 10646-1:2000 UCS-4 character type if the 13processor supports such a type; otherwise the result has the value -1. If NAME is a processor-defined 14name of some other character type supported by the processor, then the result has a value equal to that 15of the kind type parameter of that character type. If NAME is not the name of a supported character 16type, then the result has the value -1. The NAME is interpreted without respect to case or trailing 17blanks. 18Examples. SELECTED CHAR KIND ('ASCII') has the value 1 on a processor that uses 1 as the kind 19type parameter for the ASCII character set. The following subroutine produces a Japanese date stamp. 20 SUBROUTINE create_date_string(string) 21 INTRINSIC date_and_time,selected_char_kind 22 INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646") 23 CHARACTER(1,UCS4),PARAMETER :: nen=CHAR(INT(Z'5e74'),UCS4), & !year 24 gatsu=CHAR(INT(Z'6708'),UCS4), & !month 25 nichi=CHAR(INT(Z'65e5'),UCS4) !day 26 CHARACTER(len= *, kind= ucs4) string 27 INTEGER values(8) 28 CALL date_and_time(values=values) 29 WRITE(string,1) values(1),nen,values(2),gatsu,values(3),nichi 30 1 FORMAT(I0,A,I0,A,I0,A) 31 END SUBROUTINE" 13.7.153 SELECTED INT KIND (R) 32 33Description. Returns a value of the kind type parameter of an integer type that represents all integer 34values n with -10R < n < 10R. 35Class. Transformational function. 36Argument. R shall be scalar and of type integer. 37Result Characteristics. Default integer scalar. 38Result Value. The result has a value equal to the value of the kind type parameter of an integer type 39that represents all values n in the range -10R < n < 10R, or if no such kind type parameter is available 422 2006/01/05 WORKING DRAFT J3/07-007 1on the processor, the result is ­1. If more than one kind type parameter meets the criterion, the value 2returned is the one with the smallest decimal exponent range, unless there are several such values, in 3which case the smallest of these kind values is returned. 4Example. Assume a processor supports two integer kinds, 32 with representation method r = 2 and 5q = 31, and 64 with representation method r = 2 and q = 63. On this processor SELECTED INT - KIND(9) has the value 32 and SELECTED INT KIND(10) has the value 64. 6 13.7.154 SELECTED REAL KIND ([P, R, RADIX]) 7 8Description. Returns a value of the kind type parameter of a real type with decimal precision of at 9least P digits, a decimal exponent range of at least R, and a radix of RADIX. 10Class. Transformational function. 11Arguments. At least one argument shall be present. P (optional) shall be scalar and of type integer. 12 R (optional) shall be scalar and of type integer. 13 RADIX (optional)shall be scalar and of type integer. 14 15Result Characteristics. Default integer scalar. 16Result Value. If P or R is absent, the result value is the same as if it were present with the value zero. 17If RADIX is absent, there is no requirement on the radix of the selected kind. 18The result has a value equal to a value of the kind type parameter of a real type with decimal precision, 19as returned by the function PRECISION, of at least P digits, a decimal exponent range, as returned by 20the function RANGE, of at least R, and a radix, as returned by the function RADIX, of RADIX, if such 21a kind type parameter is available on the processor. 22Otherwise, the result is -1 if the processor supports a real type with radix RADIX and exponent range 23of at least R but not with precision of at least P, -2 if the processor supports a real type with radix 24RADIX and precision of at least P but not with exponent range of at least R, -3 if the processor 25supports a real type with radix RADIX but with neither precision of at least P nor exponent range of 26at least R, -4 if the processor supports a real type with radix RADIX and either precision of at least 27P or exponent range of at least R but not both together, and -5 if the processor supports no real type 28with radix RADIX. 29If more than one kind type parameter value meets the criteria, the value returned is the one with the 30smallest decimal precision, unless there are several such values, in which case the smallest of these kind 31values is returned. 32Example. SELECTED REAL KIND (6, 70) has the value KIND (0.0) on a machine that supports a 33default real approximation method with b = 16, p = 6, emin = -64, and emax = 63 and does not have 34a less precise approximation method. 13.7.155 SET EXPONENT (X, I) 35 36Description. Returns the model number whose fractional part is the fractional part of the model 37representation of X and whose exponent part is I. 38Class. Elemental function. 39Arguments. 423 J3/07-007 WORKING DRAFT 2006/01/05 1X shall be of type real. 2I shall be of type integer. 3Result Characteristics. Same as X. -e 4Result Value. The result has the value X × bI , where b and e are as defined in 13.4 for the repre- 5sentation for the value of X in the model that has the radix of X but no limits on exponent values. If X 6has the value zero, the result has the same value as X. J3 internal note Unresolved Technical Issue 093 The above is broken for Inf and NaN. I suggest SET EXPONENT(Inf or NaN,any) = NaN. Example. SET EXPONENT (3.0, 1) has the value 1.5 for reals whose model is as in Note 13.3. 7 13.7.156 SHAPE (SOURCE [, KIND]) 8 9Description. Returns the shape of an array or a scalar. 10Class. Inquiry function. 11Arguments. SOURCE may be of any type. It may be a scalar or an array. It shall not be an unallocated 12 allocatable or a pointer that is not associated. It shall not be an assumed-size array. KIND (optional) shall be a scalar integer initialization expression. 13 14Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 15value of KIND; otherwise the kind type parameter is that of default integer type. The result is an array 16of rank one whose size is equal to the rank of SOURCE. 17Result Value. The value of the result is the shape of SOURCE. 18Examples. The value of SHAPE (A (2:5, ­1:1) ) is [4, 3]. The value of SHAPE (3) is the rank-one 19array of size zero. 13.7.157 SHIFTA (I, SHIFT) 20 21Description. Performs a right shift with fill. 22Class. Elemental function. 23Arguments. 24I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I). 25 26Result Characteristics. Same as I. 27Result Value. The result has the value obtained by shifting the bits of I to the right SHIFT bits and 28replicating the leftmost bit of I in the left SHIFT bits. 29If SHIFT is zero the result is I. Bits shifted out from the right are lost. The model for the interpretation 30of an integer value as a sequence of bits is in 13.3. Example. SHIFTA (B'10000', 2) has the value B'11100'. 31 424 2006/01/05 WORKING DRAFT J3/07-007 13.7.158 SHIFTL (I, SHIFT) 1 2Description. Performs a left shift. 3Class. Elemental function. 4Arguments. 5I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I). 6 7Result Characteristics. Same as I. Result Value. The result has a value equal to ISHFT (I, SHIFT). 8 Examples. SHIFTL (3, 1) has the value 6. SHIFTL (B'00001', 2) has the value B'00100'. 9 13.7.159 SHIFTR (I, SHIFT) 10 11Description. Performs a right shift. 12Class. Elemental function. 13Arguments. 14I shall be of type integer or bits. SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I). 15 16Result Characteristics. Same as I. Result Value. The value of the result is ISHFT (I, -SHIFT). 17 Examples. SHIFTR (3, 1) has the value 1. SHIFTR (B'10000', 2) has the value B'00100'. 18 13.7.160 SIGN (A, B) 19 20Description. Magnitude of A with the sign of B. 21Class. Elemental function. 22Arguments. 23A shall be of type integer or real. 24B shall be of the same type and kind type parameter as A. 25Result Characteristics. Same as A. 26Result Value. Case (i): If B > 0, the value of the result is |A|. 27 Case (ii): If B < 0, the value of the result is -|A|. 28 Case (iii): If B is of type integer and B=0, the value of the result is |A|. 29 Case (iv): If B is of type real and is zero, then 30 31 (1) If the processor cannot distinguish between positive and negative real zero, the value of the result is |A|. 32 (2) If B is positive real zero, the value of the result is |A|. 33 425 J3/07-007 WORKING DRAFT 2006/01/05 (3) If B is negative real zero, the value of the result is -|A|. 1 Example. SIGN (­3.0, 2.0) has the value 3.0. 2 13.7.161 SIN (X) 3 4Description. Sine function. 5Class. Elemental function. 6Argument. X shall be of type real or complex. 7Result Characteristics. Same as X. 8Result Value. The result has a value equal to a processor-dependent approximation to sin(X). If X is 9of type real, it is regarded as a value in radians. If X is of type complex, its real part is regarded as a 10value in radians. Example. SIN (1.0) has the value 0.84147098 (approximately). 11 13.7.162 SINH (X) 12 13Description. Hyperbolic sine function. 14Class. Elemental function. 15Argument. X shall be of type real or complex. 16Result Characteristics. Same as X. 17Result Value. The result has a value equal to a processor-dependent approximation to sinh(X). If X 18is of type complex its imaginary part is regarded as a value in radians. Example. SINH (1.0) has the value 1.1752012 (approximately). 19 13.7.163 SIZE (ARRAY [, DIM, KIND]) 20 21Description. Returns the extent of an array along a specified dimension or the total number of elements 22in the array. 23Class. Inquiry function. 24Arguments. ARRAY may be of any type. It shall be an array. It shall not be an unallocated allocatable or a pointer that is not associated. If ARRAY is an assumed-size array, DIM shall be 25 present with a value less than the rank of ARRAY. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is 26 the rank of ARRAY. KIND (optional) shall be a scalar integer initialization expression. 27 28Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified 29by the value of KIND; otherwise the kind type parameter is that of default integer type. 30Result Value. The result has a value equal to the extent of dimension DIM of ARRAY or, if DIM is 31absent, the total number of elements of ARRAY. 426 2006/01/05 WORKING DRAFT J3/07-007 Examples. The value of SIZE (A (2:5, ­1:1), DIM=2) is 3. The value of SIZE (A (2:5, ­1:1)) is 12. 1 13.7.164 SPACING (X) 2 3Description. Returns the absolute spacing of model numbers near the argument value. 4Class. Elemental function. 5Argument. X shall be of type real. 6Result Characteristics. Same as X. 7Result Value. If X does not have the value zero and is not an IEEE infinity or NaN, the result has the 8value bmax( e-p,eMIN-1), where b, e, and p are as defined in 13.4 for the value nearest to X in the model 9for real values whose kind type parameter is that of X; if there are two such values the value of greater 10absolute value is taken. If X has the value zero, the result is the same as that of TINY (X). If X is an 11IEEE infinity, the result is positive infinity. If X is an IEEE NaN, the result is that NaN. Example. SPACING (3.0) has the value 2-22 for reals whose model is as in Note 13.3. 12 13.7.165 SPREAD (SOURCE, DIM, NCOPIES) 13 14Description. Replicates an array by adding a dimension. Broadcasts several copies of SOURCE along 15a specified dimension (as in forming a book from copies of a single page) and thus forms an array of 16rank one greater. 17Class. Transformational function. 18Arguments. SOURCE may be of any type. It may be a scalar or an array. The rank of SOURCE shall be 19 less than 15. DIM shall be scalar and of type integer with value in the range 1 DIM n + 1, where n 20 is the rank of SOURCE. 21NCOPIES shall be scalar and of type integer. 22Result Characteristics. The result is an array of the same type and type parameters as SOURCE 23and of rank n + 1, where n is the rank of SOURCE. Case (i): If SOURCE is scalar, the shape of the result is (MAX (NCOPIES, 0)). 24 25Case (ii): If SOURCE is an array with shape (d1, d2, ..., dn), the shape of the result is (d1, d2, 26 ..., dDIM , MAX (NCOPIES, 0), dDIM, ..., dn). -1 27Result Value. Case (i): If SOURCE is scalar, each element of the result has a value equal to SOURCE. 28 29Case (ii): If SOURCE is an array, the element of the result with subscripts (r1, r2, ..., rn ) has +1 30 the value SOURCE (r1, r2, ..., rDIM , rDIM+1, ..., rn ). -1 +1 2 3 4 31Examples. If A is the array [2, 3, 4], SPREAD (A, DIM=1, NCOPIES=NC) is the array 2 3 4 2 3 4 32if NC has the value 3 and is a zero-sized array if NC has the value 0. 13.7.166 SQRT (X) 33 34Description. Square root. 427 J3/07-007 WORKING DRAFT 2006/01/05 1Class. Elemental function. 2Argument. X shall be of type real or complex. Unless X is complex, its value shall be greater than or 3equal to zero. 4Result Characteristics. Same as X. 5Result Value. The result has a value equal to a processor-dependent approximation to the square root 6of X. A result of type complex is the principal value with the real part greater than or equal to zero. 7When the real part of the result is zero, the imaginary part has the same sign as the imaginary part of 8X. Example. SQRT (4.0) has the value 2.0 (approximately). 9 13.7.167 STORAGE SIZE (A [, KIND]) 10 11Description. Returns the storage size in bits that an array element of the same dynamic type and type 12parameters of A would have. 13Class. Inquiry function. 14Arguments. A may be of any type. It may be a scalar or an array. If it is polymorphic it shall not be an undefined pointer. If it has any deferred type parameters it shall not be an 15 unallocated allocatable or a disassociated or undefined pointer. KIND (optional) shall be a scalar integer initialization expression. 16 17Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified 18by the value of KIND; otherwise, the kind type parameter is that of default integer type. 19Result Value. The result value is the size expressed in bits for an element of an array that has 20the dynamic type and type parameters of A. If the type and type parameters are such that storage 21association (16.5.3) applies, the result is consistent with the named constants defined in the intrinsic 22module ISO FORTRAN ENV. NOTE 13.21 An array element might take more bits to store than an isolated scalar, since any hardware-imposed alignment requirements for array elements might not apply to a simple scalar variable. NOTE 13.22 This is intended to be the size in memory that an object takes when it is stored; this might differ from the size it takes during expression handling (which might be the native register size) or when stored in a file. If an object is never stored in memory but only in a register, this function nonetheless returns the size it would take if it were stored in memory. 23Example. STORAGE SIZE(1.0) has the same value as the named constant NUMERIC STORAGE - 24SIZE in the intrinsic module ISO FORTRAN ENV. 13.7.168 SUM (ARRAY, DIM [, MASK]) or SUM (ARRAY [, MASK]) 25 26Description. Sum all the elements of ARRAY along dimension DIM corresponding to the true elements 27of MASK. 28Class. Transformational function. 428 2006/01/05 WORKING DRAFT J3/07-007 1Arguments. 2ARRAY shall be of type integer, real, or complex. It shall be an array. DIM shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 3 dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 4 5Result Characteristics. The result is of the same type and kind type parameter as ARRAY. It is 6scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1, d2, ..., dDIM , dDIM+1, -1 7..., dn) where (d1, d2, ..., dn) is the shape of ARRAY. 8Result Value. 9Case (i): The result of SUM (ARRAY) has a value equal to a processor-dependent approximation 10 to the sum of all the elements of ARRAY or has the value zero if ARRAY has size zero. 11Case (ii): The result of SUM (ARRAY, MASK = MASK) has a value equal to a processor-dependent 12 approximation to the sum of the elements of ARRAY corresponding to the true elements 13 of MASK or has the value zero if there are no true elements. 14Case (iii): If ARRAY has rank one, SUM (ARRAY, DIM = DIM [, MASK = MASK]) has a value 15 equal to that of SUM (ARRAY [,MASK = MASK ]). Otherwise, the value of element 16 (s1, s2, ..., sDIM , sDIM+1, ..., sn) SUM (ARRAY, DIM = DIM [ , MASK = MASK]) -1 17 is equal to 18 SUM (ARRAY (s1, s2, ..., sDIM , :, sDIM+1, ..., sn) [, MASK= MASK (s1, s2, -1 19 ..., sDIM , :, sDIM+1, ..., sn) ] ). -1 20Examples. Case (i): The value of SUM ([1, 2, 3]) is 6. 21 Case (ii): 22 SUM (C, MASK= C > 0.0) forms the sum of the positive elements of C. 1 3 5 23Case (iii): If B is the array , SUM (B, DIM = 1) is [3,7,11] and SUM (B, DIM = 2) is 2 4 6 [9, 12]. 24 13.7.169 SYSTEM CLOCK ([COUNT, COUNT RATE, COUNT MAX]) 25 26Description. Returns numeric data from a real-time clock. 27Class. Subroutine. 28Arguments. COUNT shall be scalar and of type integer. It is an INTENT (OUT) argument. It is assigned (optional) a processor-dependent value based on the current value of the processor clock, or ­ HUGE (COUNT) if there is no clock. The processor-dependent value is incremented by one for each clock count until the value COUNT MAX is reached and is reset to 29 zero at the next count. It lies in the range 0 to COUNT MAX if there is a clock. COUNT RATE shall be scalar and of type integer or real. It is an INTENT (OUT) argument. It (optional) is assigned a processor-dependent approximation to the number of processor clock 30 counts per second, or zero if there is no clock. COUNT MAX shall be scalar and of type integer. It is an INTENT(OUT) argument. It is assigned (optional) the maximum value that COUNT can have, or zero if there is no clock. 31 429 J3/07-007 WORKING DRAFT 2006/01/05 1Example. If the processor clock is a 24-hour clock that registers time at approximately 18.20648193 2ticks per second, at 11:30 A.M. the reference 3 CALL SYSTEM_CLOCK (COUNT = C, COUNT_RATE = R, COUNT_MAX = M) 4defines C = (11 × 3600 + 30 × 60) × 18.20648193 = 753748, R = 18.20648193, and M = 24 × 3600 × 518.20648193 - 1 = 1573039. 13.7.170 TAN (X) 6 7Description. Tangent function. 8Class. Elemental function. 9Argument. X shall be of type real or complex. 10Result Characteristics. Same as X. 11Result Value. The result has a value equal to a processor-dependent approximation to tan(X). If X is 12of type real, it is regarded as a value in radians. If X is of type complex, its real part is regarded as a 13value in radians. Example. TAN (1.0) has the value 1.5574077 (approximately). 14 13.7.171 TANH (X) 15 16Description. Hyperbolic tangent function. 17Class. Elemental function. 18Argument. X shall be of type real or complex. 19Result Characteristics. Same as X. 20Result Value. The result has a value equal to a processor-dependent approximation to tanh(X). If X 21is of type complex its imaginary part is regarded as a value in radians. Example. TANH (1.0) has the value 0.76159416 (approximately). 22 13.7.172 TEAM IMAGES (TEAM) 23 24Description. Returns a list of the images in a team. 25Class. Transformational function. Argument. TEAM shall be a scalar of type IMAGE TEAM (13.8.2.7). 26 27Result Characteristics. The result is a default integer array of rank one and of size equal to the 28number of images in the team identified by TEAM. 29Result Value. The result is a rank-one array whose element values are the indices, in increasing order, 30of the images in the team identified by TEAM. 31Examples. If the value of TEAM was defined by the statement CALL FORM TEAM (TEAM, [4, 2, 1]) 32then TEAM IMAGES (TEAM) has the value [1, 2, 4]. For a value of TEAM that identifies an empty 33image set, the result is an array of size zero. 13.7.173 THIS IMAGE () or THIS IMAGE (CO ARRAY [, DIM]) 34 430 2006/01/05 WORKING DRAFT J3/07-007 1Description. Returns the index of the invoking image, a single co-subscript, or a list of co-subscripts. 2Class. Inquiry function. 3Arguments. 4CO ARRAY shall be a co-array and may be of any type. If it is allocatable it shall be allocated. DIM (optional) shall be scalar and of type default integer. Its value shall be in the range 1 DIM n, where n is the co-rank of CO ARRAY. It shall not be an absent optional dummy 5 argument. 6Result Characteristics. Type default integer. It is scalar if CO ARRAY is absent or DIM is present; 7otherwise, the result has rank one and its size is equal to the co-rank of CO ARRAY. 8Result Value. 9Case (i): The result of THIS IMAGE () is a scalar with a value equal to the index of the invoking 10 image. 11Case (ii): The result of THIS IMAGE (CO ARRAY) is the sequence of co-subscript values for CO - 12 ARRAY that would specify the invoking image. 13Case (iii): The result of THIS IMAGE (CO ARRAY, DIM) is the value of co-subscript DIM in the 14 sequence of co-subscript values for CO ARRAY that would specify the invoking image. 15Examples. If A is declared by the statement 16 REAL A (10, 20) [10, 0:9, 0:*] 17then on image 5, THIS IMAGE () has the value 5 and THIS IMAGE (A) has the value [5, 0, 0]. For the same co-array on image 213, THIS IMAGE (A) has the value [3, 1, 2]. 18 19The following code uses image 1 to read data. The other images then copy the data. 20 IF (THIS_IMAGE()==1) READ (*,*) P 21 SYNC ALL 22 P = P[1] NOTE 13.23 For an example of a module that implements a function similar to the intrinsic THIS IMAGE, see subclause C.10.1. 13.7.174 TINY (X) 23 24Description. Returns the smallest positive number of the model representing numbers of the same 25type and kind type parameter as the argument. 26Class. Inquiry function. 27Argument. X shall be of type real. It may be a scalar or an array. 28Result Characteristics. Scalar with the same type and kind type parameter as X. 29Result Value. The result has the value bemin-1 where b and emin are as defined in 13.4 for the model 30representing numbers of the same type and kind type parameter as X. Example. TINY (X) has the value 2-127 for real X whose model is as in Note 13.3. 431 J3/07-007 WORKING DRAFT 2006/01/05 1 13.7.175 TRAILZ (I) 2 3Description. Count the number of trailing zero bits. 4Class. Elemental function. 5Argument. I shall be of type integer or bits. 6Result Characteristics. Default integer. 7Result Value. If all of the bits of I are zero, the result value is BIT SIZE (I). Otherwise, the result 8value is the position of the rightmost 1 bit in I. The model for the interpretation of an integer value as 9a sequence of bits is in 13.3. Examples. TRAILZ (8) has the value 3. TRAILZ (B'101101000') has the value 3. 10 13.7.176 TRANSFER (SOURCE, MOLD [, SIZE]) 11 12Description. Returns a result with a physical representation identical to that of SOURCE but inter- 13preted with the type and type parameters of MOLD. 14Class. Transformational function. 15Arguments. 16SOURCE may be of any type. It may be a scalar or an array. MOLD may be of any type. It may be a scalar or an array. If it is a variable, it need not be 17 defined. SIZE (optional) shall be scalar and of type integer. The corresponding actual argument shall not be 18 an optional dummy argument. 19Result Characteristics. The result is of the same type and type parameters as MOLD. Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar. 20 21Case (ii): If MOLD is an array and SIZE is absent, the result is an array and of rank one. Its size 22 is as small as possible such that its physical representation is not shorter than that of 23 SOURCE. Case (iii): If SIZE is present, the result is an array of rank one and size SIZE. 24 25Result Value. If the physical representation of the result has the same length as that of SOURCE, 26the physical representation of the result is that of SOURCE. If the physical representation of the result 27is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and 28the remainder is processor dependent. If the physical representation of the result is shorter than that of 29SOURCE, the physical representation of the result is the leading part of SOURCE. If D and E are scalar 30variables such that the physical representation of D is as long as or longer than that of E, the value of 31TRANSFER (TRANSFER (E, D), E) shall be the value of E. IF D is an array and E is an array of rank one, the value of TRANSFER (TRANSFER (E, D), E, SIZE (E)) shall be the value of E. 32 33Examples. 34Case (i): TRANSFER (1082130432, 0.0) has the value 4.0 on a processor that represents the values 35 4.0 and 1082130432 as the string of binary digits 0100 0000 1000 0000 0000 0000 0000 36 0000. 37Case (ii): TRANSFER ([1.1, 2.2, 3.3], [(0.0, 0.0)])) is a complex rank-one array of length two whose 38 first element has the value (1.1, 2.2) and whose second element has a real part with the 432 2006/01/05 WORKING DRAFT J3/07-007 1 value 3.3. The imaginary part of the second element is processor dependent. 2Case (iii): TRANSFER ([1.1, 2.2, 3.3], [(0.0, 0.0)], 1) is a complex rank-one array of length one whose only element has the value (1.1, 2.2). 3 13.7.177 TRANSPOSE (MATRIX) 4 5Description. Transpose an array of rank two. 6Class. Transformational function. 7Argument. MATRIX may be of any type and shall have rank two. 8Result Characteristics. The result is an array of the same type and type parameters as MATRIX and with rank two and shape (n,m) where (m,n) is the shape of MATRIX. 9 10Result Value. Element (i,j) of the result has the value MATRIX (j + LBOUND (MATRIX, 1) - 1, i + LBOUND (MATRIX, 2) - 1). 11 1 2 3 1 4 7 Example. If A is the array 4 5 6 then TRANSPOSE (A) has the value 2 5 8 , . 7 8 9 3 6 9 12 13.7.178 TRIM (STRING) 13 14Description. Returns the argument with trailing blank characters removed. 15Class. Transformational function. 16Argument. STRING shall be of type character and shall be scalar. 17Result Characteristics. Character with the same kind type parameter value as STRING and with a 18length that is the length of STRING less the number of trailing blanks in STRING. 19Result Value. The value of the result is the same as STRING except any trailing blanks are removed. 20If STRING contains no nonblank characters, the result has zero length. Example. TRIM (' A B ') has the value ' A B'. 21 13.7.179 UBOUND (ARRAY [, DIM, KIND]) 22 23Description. Returns all the upper bounds of an array or a specified upper bound. 24Class. Inquiry function. 25Arguments. ARRAY may be of any type. It shall be an array. It shall not be an unallocated allocatable or a pointer that is not associated. If ARRAY is an assumed-size array, DIM shall be 26 present with a value less than the rank of ARRAY. DIM (optional) shall be scalar and of type integer with a value in the range 1 DIM n, where n is the rank of ARRAY. The corresponding actual argument shall not be an optional 27 dummy argument. KIND (optional) shall be a scalar integer initialization expression. 28 29Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 30value of KIND; otherwise the kind type parameter is that of default integer type. The result is scalar if 433 J3/07-007 WORKING DRAFT 2006/01/05 1DIM is present; otherwise, the result is an array of rank one and size n, where n is the rank of ARRAY. 2Result Value. 3Case (i): For an array section or for an array expression, other than a whole array or array structure 4 component, UBOUND (ARRAY, DIM) has a value equal to the number of elements in 5 the given dimension; otherwise, it has a value equal to the upper bound for subscript DIM 6 of ARRAY if dimension DIM of ARRAY does not have size zero and has the value zero 7 if dimension DIM has size zero. 8Case (ii): UBOUND (ARRAY) has a value whose ith element is equal to UBOUND (ARRAY, i), 9 for i = 1, 2,..., n, where n is the rank of ARRAY. 10Examples. If A is declared by the statement 11REAL A (2:3, 7:10) then UBOUND (A) is [3, 10] and UBOUND (A, DIM = 2) is 10. 12 13.7.180 UNPACK (VECTOR, MASK, FIELD) 13 14Description. Unpack an array of rank one into an array under the control of a mask. 15Class. Transformational function. 16Arguments. VECTOR may be of any type. It shall have rank one. Its size shall be at least t where t is the 17 number of true elements in MASK. 18MASK shall be an array of type logical. FIELD shall be of the same type and type parameters as VECTOR and shall be conformable 19 with MASK. 20Result Characteristics. The result is an array of the same type and type parameters as VECTOR 21and the same shape as MASK. 22Result Value. The element of the result that corresponds to the ith true element of MASK, in array 23element order, has the value VECTOR (i) for i = 1, 2, ..., t, where t is the number of true values 24in MASK. Each other element has a value equal to FIELD if FIELD is scalar or to the corresponding 25element of FIELD if it is an array. 26Examples. Particular values may be "scattered" to particular positions in an array by using UNPACK. 1 0 0 . T . 27If M is the array 0 1 0 V is the array [1, 2, 3], and Q is the logical mask T . . where , , 0 0 1 . . T 28"T" represents true and "." represents false, then the result of UNPACK (V, MASK = Q, FIELD = M) 1 2 0 29has the value 1 1 0 and the result of UNPACK (V, MASK = Q, FIELD = 0) has the value 0 0 3 0 2 0 1 0 0 . 0 0 3 30 13.7.181 VERIFY (STRING, SET [, BACK, KIND]) 31 32Description. Verify that a set of characters contains all the characters in a string by identifying the 33position of the first character in a string of characters that does not appear in a given set of characters. 434 2006/01/05 WORKING DRAFT J3/07-007 1Class. Elemental function. 2Arguments. 3STRING shall be of type character. 4SET shall be of type character with the same kind type parameter as STRING. BACK (optional) shall be of type logical. 5 KIND (optional) shall be a scalar integer initialization expression. 6 7Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the 8value of KIND; otherwise the kind type parameter is that of default integer type. 9Result Value. 10Case (i): If BACK is absent or has the value false and if STRING contains at least one character 11 that is not in SET, the value of the result is the position of the leftmost character of 12 STRING that is not in SET. 13Case (ii): If BACK is present with the value true and if STRING contains at least one character 14 that is not in SET, the value of the result is the position of the rightmost character of 15 STRING that is not in SET. 16Case (iii): The value of the result is zero if each character in STRING is in SET or if STRING has 17 zero length. 18Examples. Case (i): VERIFY ('ABBA', 'A') has the value 2. 19 Case (ii): VERIFY ('ABBA', 'A', BACK = .TRUE.) has the value 3. 20 Case (iii): VERIFY ('ABBA', 'AB') has the value 0. 21 2213.8 Standard intrinsic modules 2313.8.1 General 24This part of ISO/IEC 1539 defines five standard intrinsic modules: a Fortran environment module, a 25set of three modules to support exception handling and IEEE arithmetic, and a module to support 26interoperability with the C programming language. 27The IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES intrinsic modules are describ- 28ed in Clause 14. The ISO C BINDING intrinsic module is described in Clause 15. 29A processor may extend the standard intrinsic modules to provide public entities in them in addition to those specified in this part of ISO/IEC 1539. 30 NOTE 13.24 To avoid potential name conflicts with program entities, it is recommended that a program use the ONLY option in any USE statement that references a standard intrinsic module. 3113.8.2 The ISO FORTRAN ENV intrinsic module 3213.8.2.1 General The intrinsic module ISO FORTRAN ENV provides public entities relating to the Fortran environment. 435 J3/07-007 WORKING DRAFT 2006/01/05 1The processor shall provide the named constants, derived type, and procedures described in subclause 213.8.2. 313.8.2.2 CHARACTER STORAGE SIZE 4The value of the default integer scalar constant CHARACTER STORAGE SIZE is the size expressed in bits of the character storage unit (16.5.3.2). 5 13.8.2.3 COMPILER OPTIONS () 6 7Description. Returns a processor-dependent string describing the options that controlled the program 8translation phase. 9Class. Inquiry function. 10Argument. None. 11Result Characteristics. Default character scalar with processor-dependent length. 12Result Value. A processor-dependent value which describes the options that controlled the translation 13phase of program execution. Example. COMPILER OPTIONS () might have the value '/OPTIMIZE /FLOAT=IEEE'. 14 13.8.2.4 COMPILER VERSION () 15 16Description. Returns a processor-dependent string identifying the program translation phase. 17Class. Inquiry function. 18Argument. None. 19Result Characteristics. Default character scalar with processor-dependent length. 20Result Value. A processor-dependent value that identifies the name and version of the program 21translation phase of the processor. Example. COMPILER VERSION () might have the value 'Fast KL-10 Compiler Version 7'. 22 NOTE 13.25 For both COMPILER OPTIONS and COMPILER VERSION the processor should include rele- vant information that could be useful in solving problems found long after the translation phase. For example, compiler release and patch level, default compiler arguments, environment variable values, and run time library requirements might be included. A processor might include this infor- mation in an object file automatically, without the user needing to save the result of this function in a variable. 2313.8.2.5 ERROR UNIT 24The value of the default integer scalar constant ERROR UNIT identifies the processor-dependent pre- 25connected external unit used for the purpose of error reporting (9.4). This unit may be the same as 26OUTPUT UNIT. The value shall not be -1. 2713.8.2.6 FILE STORAGE SIZE 436 2006/01/05 WORKING DRAFT J3/07-007 1The value of the default integer scalar constant FILE STORAGE SIZE is the size expressed in bits of the file storage unit (9.2.4). 2 313.8.2.7 IMAGE TEAM 4A scalar object of type IMAGE TEAM identifies a team of images. This type is extensible, has only 5private components, has no co-array components, and has default initialization to a value that identifies 6an empty image set. J3 internal note Unresolved Technical Issue 090 Since the author of 06-322r4 claimed he intended IMAGE TEAM to be extensible, I added an edit to that effect. I wonder if that is what he meant? Does it have pointer components? Does it have allocatable components? Even should we ignore or fudge the image accessibility issue, the answer re allocatable components affects what can be done with it on a single image. (Consider INTENT(OUT) assumed-size arrays.) See also UTI 073. NOTE 13.26 When values of type IMAGE TEAM are constructed by calling the intrinsic subroutine FORM - TEAM on the images of a team, the processor may choose to store information in such values to speed later processing of team synchronizations and collective subroutine calls. Since this information is likely to vary between images, it is inappropriate to copy values of type IMAGE - TEAM between images. J3 internal note Unresolved Technical Issue 073 IMAGE TEAM is still not adequately explained. Better, but not there yet. Nor are its restrictions. I said: "Yes, there are certainly valid cross-image uses. Some of these are even obvious (diagnostic information for example)." Paper 06-322r4 claimed that this did not restrict "the programmer in any significant way". Well, views might differ on that. But the explanation is still not satisfactory, and on further reflection, I believe there is no need for such coyness and special molly-coddling of this type. In other words, I suggest that the special restrictions on IMAGE TEAM be simply deleted. Going by the rationale given by 06-322r4, we can simply say that it has pointer components. Then the "pointer ultimate component" restrictions automatically kick in. NOTE: This of course does not tie the hands of any implementation in any way whatsoever, since the user cannot validly do anything to a private pointer component. The author of 06-322r4 said he wants to allow pointer components without realising that just saying it has them does everything he wants! So, I suggest: 1. say that IMAGE TEAM has pointer components; 2. delete the special restrictions; 3. delete the note(s?) explaining the special restrictions. 713.8.2.8 INPUT UNIT 437 J3/07-007 WORKING DRAFT 2006/01/05 1The value of the default integer scalar constant INPUT UNIT identifies the same processor-dependent 2preconnected external unit as the one identified by an asterisk in a READ statement (9.4). The value 3shall not be -1. 413.8.2.9 INT8, INT16, INT32, and INT64 5The values of these default integer scalar named constants shall be those of the kind type parameters that 6specify an INTEGER type whose storage size expressed in bits is 8, 16, 32, and 64 respectively. If, for 7any of these constants, the processor supports more than one kind of that size, it is processor-dependent 8which kind value is provided. If the processor supports no kind of a particular size, that constant shall 9be equal to -2 if the processor supports kinds of a larger size and -1 otherwise. 1013.8.2.10 IOSTAT END 11The value of the default integer scalar constant IOSTAT END is assigned to the variable specified in 12an IOSTAT= specifier (9.10.4) if an end-of-file condition occurs during execution of an input/output 13statement and no error condition occurs. This value shall be negative. 1413.8.2.11 IOSTAT EOR 15The value of the default integer scalar constant IOSTAT EOR is assigned to the variable specified in 16an IOSTAT= specifier (9.10.4) if an end-of-record condition occurs during execution of an input/output 17statement and no end-of-file or error condition occurs. This value shall be negative and different from 18the value of IOSTAT END. 1913.8.2.12 IOSTAT INQUIRE INTERNAL UNIT 20The value of the default integer scalar constant IOSTAT INQUIRE INTERNAL UNIT is assigned to 21the variable specified in an IOSTAT= specifier in an INQUIRE statement (9.9) if a file-unit-number 22identifies an internal unit in that statement. NOTE 13.27 This can only occur when a user defined derived type input/output procedure is called by the processor as the result of executing a parent data transfer statement for an internal unit. 2313.8.2.13 NUMERIC STORAGE SIZE 24The value of the default integer scalar constant NUMERIC STORAGE SIZE is the size expressed in bits of the numeric storage unit (16.5.3.2). 25 2613.8.2.14 OUTPUT UNIT 27The value of the default integer scalar constant OUTPUT UNIT identifies the same processor-dependent 28preconnected external unit as the one identified by an asterisk in a WRITE statement (9.4). The value 29shall not be -1. 3013.8.2.15 REAL32, REAL64, and REAL128 31The values of these default integer scalar named constants shall be those of the kind type parameters 32that specify a REAL type whose storage size expressed in bits is 32, 64, and 128 respectively. If, for 33any of these constants, the processor supports more than one kind of that size, it is processor-dependent 34which kind value is provided. If the processor supports no kind of a particular size, that constant shall 35be equal to -2 if the processor supports kinds of a larger size and -1 otherwise. 438 2006/01/05 WORKING DRAFT J3/07-007 14 Exceptions and IEEE arithmetic 1 2The intrinsic modules IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES provide sup- 3port for exceptions and IEEE arithmetic. Whether the modules are provided is processor dependent. If 4the module IEEE FEATURES is provided, which of the named constants defined in this part of ISO/IEC 51539 are included is processor dependent. The module IEEE ARITHMETIC behaves as if it contained 6a USE statement for IEEE EXCEPTIONS; everything that is public in IEEE EXCEPTIONS is public 7in IEEE ARITHMETIC. NOTE 14.1 The types and procedures defined in these modules are not themselves intrinsic. 8If IEEE EXCEPTIONS or IEEE ARITHMETIC is accessible in a scoping unit, IEEE OVERFLOW and 9IEEE DIVIDE BY ZERO are supported in the scoping unit for all kinds of real and complex data. Which 10other exceptions are supported can be determined by the function IEEE SUPPORT FLAG (14.10.26); 11whether control of halting is supported can be determined by the function IEEE SUPPORT HALTING. 12The extent of support of the other exceptions may be influenced by the accessibility of the named con- 13stants IEEE INEXACT FLAG, IEEE INVALID FLAG, and IEEE UNDERFLOW FLAG of the module 14IEEE FEATURES. If a scoping unit has access to IEEE UNDERFLOW FLAG of IEEE FEATURES, 15within the scoping unit the processor shall support underflow and return true from IEEE SUPPORT - 16FLAG( IEEE UNDERFLOW, X) for at least one kind of real. Similarly, if IEEE INEXACT FLAG or 17IEEE INVALID FLAG is accessible, within the scoping unit the processor shall support the exception 18and return true from the corresponding inquiry for at least one kind of real. Also, if IEEE HALTING 19is accessible, within the scoping unit the processor shall support control of halting and return true from IEEE SUPPORT HALTING(FLAG) for the flag. 20 NOTE 14.2 IEEE INVALID is not required to be supported whenever IEEE EXCEPTIONS is accessed. This is to allow a non-IEEE processor to provide support for overflow and divide by zero. On an IEEE machine, invalid is an equally serious condition. NOTE 14.3 The IEEE FEATURES module is provided to allow a reasonable amount of cooperation between the programmer and the processor in controlling the extent of IEEE arithmetic support. On some processors some IEEE features are natural for the processor to support, others may be inefficient at run time, and others are essentially impossible to support. If IEEE FEATURES is not used, the processor will support only the natural operations. Within IEEE FEATURES the processor will define the named constants (14.1) corresponding to the time-consuming features (as well as the natural ones for completeness) but will not define named constants corresponding to the impossible features. If the programmer accesses IEEE FEATURES, the processor shall provide support for all of the IEEE FEATURES that are reasonably possible. If the programmer uses an ONLY option on a USE statement to access a particular feature name, the processor shall provide support for the corresponding feature, or issue an error message saying the name is not defined in the module. When used this way, the named constants in the IEEE FEATURES are similar to what are fre- quently called command line switches for the compiler. They can specify compilation options in a reasonably portable manner. 439 J3/07-007 WORKING DRAFT 2006/01/05 1If a scoping unit does not access IEEE FEATURES, IEEE EXCEPTIONS, or IEEE ARITHMETIC, 2the level of support is processor dependent, and need not include support for any exceptions. If a flag is 3signaling on entry to such a scoping unit, the processor ensures that it is signaling on exit. If a flag is 4quiet on entry to such a scoping unit, whether it is signaling on exit is processor dependent. 5Further IEEE support is available through the module IEEE ARITHMETIC. The extent of support may 6be influenced by the accessibility of the named constants of the module IEEE FEATURES. If a scoping 7unit has access to IEEE DATATYPE of IEEE FEATURES, within the scoping unit the processor shall 8support IEEE arithmetic and return true from IEEE SUPPORT DATATYPE(X) (14.10.23) for at least 9one kind of real. Similarly, if IEEE DENORMAL, IEEE DIVIDE, IEEE INF, IEEE NAN, IEEE - 10ROUNDING, or IEEE SQRT is accessible, within the scoping unit the processor shall support the feature 11and return true from the corresponding inquiry function for at least one kind of real. In the case of 12IEEE ROUNDING, it shall return true for all the rounding modes IEEE NEAREST, IEEE TO ZERO, 13IEEE UP, and IEEE DOWN. 14Execution might be slowed on some processors by the support of some features. If IEEE EXCEPTIONS 15or IEEE ARITHMETIC is accessed but IEEE FEATURES is not accessed, the supported subset of fea- 16tures is processor dependent. The processor's fullest support is provided when all of IEEE FEATURES 17is accessed as in 18 USE, INTRINSIC :: IEEE_ARITHMETIC; USE, INTRINSIC :: IEEE_FEATURES 19but execution might then be slowed by the presence of a feature that is not needed. In all cases, the 20extent of support can be determined by the inquiry functions. 14.1 Derived types and constants defined in the modules 21 22The modules IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES define five derived 23types, whose components are all private. No direct component of any of these types is allocatable or a 24pointer. J3 internal note Unresolved Technical Issue 098 Do they have allocatable components? I would guess NO. Do they have pointer components? I would guess NO. These have impact in F2008, because they affect cross-image accessibility. The text above reflects the editor's attempt to resolve the problem. If it is found to be correct on review, all that is needed is to delete this UTI (but see below). Note: The first one has some impact in F2003 as well, because it affects INTENT(OUT) assumed- size arrays. That is a defect in F2003. But it gets bigger in F2008. An interp is probably warranted. This also affects TYPE(C PTR) and TYPE(C FUNPTR); the text the editor added to these (see 15.3.3) also needs to be reviewed and accepted before deleting this UTI. 25The module IEEE EXCEPTIONS defines the following types. 26 · IEEE FLAG TYPE is for identifying a particular exception flag. Its only possible values are those 27 of named constants defined in the module: IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE - 28 BY ZERO, IEEE UNDERFLOW, and IEEE INEXACT. The module also defines the array named 29 constants IEEE USUAL = [ IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE INVALID ] and IEEE ALL = [ IEEE USUAL, IEEE UNDERFLOW, IEEE INEXACT ]. 30 · IEEE STATUS TYPE is for containing the floating-point status. 440 2006/01/05 WORKING DRAFT J3/07-007 1The module IEEE ARITHMETIC defines the following. 2 · The type IEEE CLASS TYPE, for identifying a class of floating-point values. Its only possible 3 values are those of named constants defined in the module: IEEE SIGNALING NAN, IEEE QUI- 4 ET NAN, IEEE NEGATIVE INF, IEEE NEGATIVE NORMAL, IEEE NEGATIVE DENORM- 5 AL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO, IEEE POSITIVE DENORMAL, IEEE - 6 POSITIVE NORMAL, IEEE POSITIVE INF, and IEEE OTHER VALUE. 7 · The type IEEE ROUND TYPE, for identifying a particular rounding mode. Its only possible 8 values are those of named constants defined in the module: IEEE NEAREST, IEEE TO ZERO, 9 IEEE UP, and IEEE DOWN for the IEEE modes; and IEEE OTHER for any other mode. 10 · The elemental operator == for two values of one of these types to return true if the values are the 11 same and false otherwise. 12 · The elemental operator /= for two values of one of these types to return true if the values differ 13 and false otherwise. 14The module IEEE FEATURES defines the type IEEE FEATURES TYPE, for expressing the need 15for particular IEEE features. Its only possible values are those of named constants defined in the 16module: IEEE DATATYPE, IEEE DENORMAL, IEEE DIVIDE, IEEE HALTING, IEEE INEXACT - 17FLAG, IEEE INF, IEEE INVALID FLAG, IEEE NAN, IEEE ROUNDING, IEEE SQRT, and IEEE - 18UNDERFLOW FLAG. 14.2 The exceptions 19 20The exceptions are the following. 21 · IEEE OVERFLOW occurs when the result for an intrinsic real operation or assignment has an 22 absolute value greater than a processor-dependent limit, or the real or imaginary part of the result 23 for an intrinsic complex operation or assignment has an absolute value greater than a processor- 24 dependent limit. 25 · IEEE DIVIDE BY ZERO occurs when a real or complex division has a nonzero numerator and a 26 zero denominator. 27 · IEEE INVALID occurs when a real or complex operation or assignment is invalid; possible examples 28 are SQRT(X) when X is real and has a nonzero negative value, and conversion to an integer (by 29 assignment, an intrinsic procedure, or a procedure defined in an intrinsic module) when the result 30 is too large to be representable. 31 · IEEE UNDERFLOW occurs when the result for an intrinsic real operation or assignment has an 32 absolute value less than a processor-dependent limit and loss of accuracy is detected, or the real 33 or imaginary part of the result for an intrinsic complex operation or assignment has an absolute 34 value less than a processor-dependent limit and loss of accuracy is detected. 35 · IEEE INEXACT occurs when the result of a real or complex operation or assignment is not exact. 36Each exception has a flag whose value is either quiet or signaling. The value can be determined by 37the function IEEE GET FLAG. Its initial value is quiet and it signals when the associated exception 38occurs. Its status can also be changed by the subroutine IEEE SET FLAG or the subroutine IEEE - 39SET STATUS. Once signaling within a procedure, it remains signaling unless set quiet by an invocation 40of the subroutine IEEE SET FLAG or the subroutine IEEE SET STATUS. 441 J3/07-007 WORKING DRAFT 2006/01/05 1If a flag is signaling on entry to a procedure other than IEEE GET FLAG or IEEE GET STATUS, the 2processor will set it to quiet on entry and restore it to signaling on return. NOTE 14.4 If a flag signals during execution of a procedure, the processor shall not set it to quiet on return. 3Evaluation of a specification expression might cause an exception to signal. 4In a scoping unit that has access to IEEE EXCEPTIONS or IEEE ARITHMETIC, if an intrinsic pro- 5cedure or a procedure defined in an intrinsic module executes normally, the values of the flags IEEE - 6OVERFLOW, IEEE DIVIDE BY ZERO, and IEEE INVALID shall be as on entry to the procedure, 7even if one or more signals during the calculation. If a real or complex result is too large for the pro- 8cedure to handle, IEEE OVERFLOW may signal. If a real or complex result is a NaN because of an 9invalid operation (for example, LOG(-1.0)), IEEE INVALID may signal. Similar rules apply to format 10processing and to intrinsic operations: no signaling flag shall be set quiet and no quiet flag shall be set 11signaling because of an intermediate calculation that does not affect the result. 12In a sequence of statements that has no invocations of IEEE GET FLAG, IEEE SET FLAG, IEEE - 13GET STATUS, IEEE SET HALTING MODE, or IEEE SET STATUS, if the execution of an operation 14would cause an exception to signal but after execution of the sequence no value of a variable depends 15on the operation, whether the exception is signaling is processor dependent. For example, when Y has 16the value zero, whether the code 17 X = 1.0/Y 18 X = 3.0 19signals IEEE DIVIDE BY ZERO is processor dependent. Another example is the following: 20 REAL, PARAMETER :: X=0.0, Y=6.0 21 IF (1.0/X == Y) PRINT *,'Hello world' 22where the processor is permitted to discard the IF statement because the logical expression can never 23be true and no value of a variable depends on it. 24An exception shall not signal if this could arise only during execution of an operation beyond those 25required or permitted by the standard. For example, the statement 26 IF (F(X)>0.0) Y = 1.0/Z shall not signal IEEE DIVIDE BY ZERO when both F(X) and Z are zero and the statement 27 28 WHERE(A>0.0) A = 1.0/A 29shall not signal IEEE DIVIDE BY ZERO. On the other hand, when X has the value 1.0 and Y has the 30value 0.0, the expression 31 X>0.00001 .OR. X/Y>0.00001 442 2006/01/05 WORKING DRAFT J3/07-007 1is permitted to cause the signaling of IEEE DIVIDE BY ZERO. 2The processor need not support IEEE INVALID, IEEE UNDERFLOW, and IEEE INEXACT. If an 3exception is not supported, its flag is always quiet. The function IEEE SUPPORT FLAG can be used 4to inquire whether a particular flag is supported. 14.3 The rounding modes 5 6The IEEE International Standard specifies four rounding modes. 7 · IEEE NEAREST rounds the exact result to the nearest representable value. 8 · IEEE TO ZERO rounds the exact result towards zero to the next representable value. 9 · IEEE UP rounds the exact result towards +infinity to the next representable value. 10 · IEEE DOWN rounds the exact result towards -infinity to the next representable value. 11The function IEEE GET ROUNDING MODE can be used to inquire which rounding mode is in opera- 12tion. Its value is one of the above four or IEEE OTHER if the rounding mode does not conform to the 13IEEE International Standard. 14If the processor supports the alteration of the rounding mode during execution, the subroutine IEEE - 15SET ROUNDING MODE can be used to alter it. The function IEEE SUPPORT ROUNDING can be 16used to inquire whether this facility is available for a particular mode. The function IEEE SUPPORT - 17IO can be used to inquire whether rounding for base conversion in formatted input/output (9.4.5.14, 9.5.2.13, 10.7.2.3.7) is as specified in the IEEE International Standard. 18 19In a procedure other than IEEE SET ROUNDING MODE or IEEE SET STATUS, the processor shall 20not change the rounding mode on entry, and on return shall ensure that the rounding mode is the same 21as it was on entry. NOTE 14.5 Within a program, all literal constants that have the same form have the same value (4.1.2). Therefore, the value of a literal constant is not affected by the rounding mode. 2214.4 Underflow mode 23Some processors allow control during program execution of whether underflow produces a denormalized 24number in conformance with the IEEE International Standard (gradual underflow) or produces zero 25instead (abrupt underflow). On some processors, floating-point performance is typically better in abrupt 26underflow mode than in gradual underflow mode. 27Control over the underflow mode is exercised by invocation of IEEE SET UNDERFLOW MODE. The 28function IEEE GET UNDERFLOW MODE can be used to inquire which underflow mode is in opera- 29tion. The function IEEE SUPPORT UNDERFLOW MODE can be used to inquire whether this facility 30is available. The initial underflow mode is processor dependent. In a procedure other than IEEE SET - 31UNDERFLOW MODE or IEEE SET STATUS, the processor shall not change the underflow mode on 32entry, and on return shall ensure that the underflow mode is the same as it was on entry. 33The underflow mode affects only floating-point calculations whose type is that of an X for which IEEE - 34SUPPORT UNDERFLOW CONTROL returns true. 443 J3/07-007 WORKING DRAFT 2006/01/05 14.5 Halting 1 2Some processors allow control during program execution of whether to abort or continue execution after 3an exception. Such control is exercised by invocation of the subroutine IEEE SET HALTING MODE. 4Halting is not precise and may occur any time after the exception has occurred. The function IEEE SUP- 5PORT HALTING can be used to inquire whether this facility is available. The initial halting mode is 6processor dependent. In a procedure other than IEEE SET HALTING MODE or IEEE SET STATUS, 7the processor shall not change the halting mode on entry, and on return shall ensure that the halting 8mode is the same as it was on entry. 14.6 The floating-point status 9 10The values of all the supported flags for exceptions, rounding mode, underflow mode, and halting are 11called the floating-point status. The floating-point status can be saved in a scalar variable of type 12TYPE(IEEE STATUS TYPE) with the subroutine IEEE GET STATUS and restored with the subrou- 13tine IEEE SET STATUS. There are no facilities for finding the values of particular flags held within 14such a variable. Portions of the floating-point status can be saved with the subroutines IEEE GET - 15FLAG, IEEE GET HALTING MODE, and IEEE GET ROUNDING MODE, and set with the subrou- 16tines IEEE SET FLAG, IEEE SET HALTING MODE, and IEEE SET ROUNDING MODE. NOTE 14.6 Some processors hold all these flags in a floating-point status register that can be saved and restored as a whole much faster than all individual flags can be saved and restored. These procedures are provided to exploit this feature. NOTE 14.7 The processor is required to ensure that a call to a Fortran procedure does not change the floating- point status other than by setting exception flags to signaling. 14.7 Exceptional values 17 18The IEEE International Standard specifies the following exceptional floating-point values. 19 · Denormalized values have very small absolute values and lowered precision. · Infinite values (+infinity and -infinity) are created by overflow or division by zero. 20 · Not-a-Number ( NaN) values are undefined values or values created by an invalid operation. 21 22In this part of ISO/IEC 1539, the term normal is used for values that are not in one of these exceptional 23classes. 24The functions IEEE IS FINITE, IEEE IS NAN, IEEE IS NEGATIVE, and IEEE IS NORMAL are pro- 25vided to test whether a value is finite, NaN, negative, or normal. The function IEEE VALUE is pro- 26vided to generate an IEEE number of any class, including an infinity or a NaN. The functions IEEE - 27SUPPORT DENORMAL, IEEE SUPPORT INF, and IEEE SUPPORT NAN are provided to determine 28whether these facilities are available for a particular kind of real. 2914.8 IEEE arithmetic 444 2006/01/05 WORKING DRAFT J3/07-007 1The function IEEE SUPPORT DATATYPE can be used to inquire whether IEEE arithmetic is sup- 2ported for a particular kind of real. Complete conformance with the IEEE International Standard is not 3required, but the normalized numbers shall be exactly those of an IEEE floating-point format; the oper- 4ations of addition, subtraction, and multiplication shall conform with at least one of the IEEE rounding 5modes; the IEEE operation rem shall be provided by the function IEEE REM; and the IEEE functions 6copysign, scalb, logb, nextafter, and unordered shall be provided by the functions IEEE COPY SIGN, 7IEEE SCALB, IEEE LOGB, IEEE NEXT AFTER, and IEEE UNORDERED, respectively. The in- 8quiry function IEEE SUPPORT DIVIDE is provided to inquire whether the processor supports divide 9with the accuracy specified by the IEEE International Standard. For each of the operations of addi- 10tion, subtraction, and multiplication, the result shall be as specified in the IEEE International Standard 11whenever the IEEE result is normalized and the operands are normalized (if floating-point) or are valid and within range (if another type). 12 13The inquiry function IEEE SUPPORT NAN is provided to inquire whether the processor supports 14IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including 15those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the 16specifications in the IEEE International Standard. 17The inquiry function IEEE SUPPORT INF is provided to inquire whether the processor supports IEEE 18infinities. Where these are supported, their behavior for unary and binary operations, including those 19defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifi- 20cations in the IEEE International Standard. 21The inquiry function IEEE SUPPORT DENORMAL is provided to inquire whether the processor sup- 22ports IEEE denormals. Where these are supported, their behavior for unary and binary operations, 23including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent 24with the specifications in the IEEE International Standard. 25The IEEE International Standard specifies a square root function that returns -0.0 for the square root 26of -0.0 and has certain accuracy requirements. The function IEEE SUPPORT SQRT can be used to 27inquire whether SQRT conforms to the IEEE International Standard for a particular kind of real. 28The inquiry function IEEE SUPPORT STANDARD is provided to inquire whether the processor sup- ports all the IEEE facilities defined in this part of ISO/IEC 1539 for a particular kind of real. 29 14.9 Tables of the procedures 30 31For all of the procedures defined in the modules, the arguments shown are the names that shall be used 32for argument keywords if the keyword form is used for the actual arguments. 33The procedure classification terms "inquiry function" and "transformational function" are used here 34with the same meanings as in 13.1. 14.9.1 Inquiry functions 35 36The module IEEE EXCEPTIONS contains the following inquiry functions. IEEE SUPPORT FLAG (FLAG [, X]) Are IEEE exceptions supported? 37 IEEE SUPPORT HALTING (FLAG) Is IEEE halting control supported? 38 39The module IEEE ARITHMETIC contains the following inquiry functions. IEEE SUPPORT DATATYPE ([X]) Is IEEE arithmetic supported? 40 IEEE SUPPORT DENORMAL ([X]) Are IEEE denormalized numbers supported? 41 IEEE SUPPORT DIVIDE ([X]) Is IEEE divide supported? 42 445 J3/07-007 WORKING DRAFT 2006/01/05 IEEE SUPPORT INF ([X]) Is IEEE infinity supported? 1 IEEE SUPPORT IO ([X]) Is IEEE formatting supported? 2 IEEE SUPPORT NAN ([X]) Are IEEE NaNs supported? 3 IEEE SUPPORT ROUNDING Is IEEE rounding supported? (ROUND VALUE [, X]) 4 IEEE SUPPORT SQRT ([X]) Is IEEE square root supported? 5 IEEE SUPPORT STANDARD ([X]) Are all IEEE facilities supported? 6 IEEE SUPPORT UNDERFLOW - Is IEEE underflow control supported? CONTROL ([X]) 7 814.9.2 Elemental functions 9The module IEEE ARITHMETIC contains the following elemental functions for reals X and Y for which IEEE SUPPORT DATATYPE(X) and IEEE SUPPORT DATATYPE(Y) are true. 10 IEEE CLASS (X) IEEE class. 11 IEEE COPY SIGN (X,Y) IEEE copysign function. 12 IEEE IS FINITE (X) Determine if value is finite. 13 IEEE IS NAN (X) Determine if value is IEEE Not-a-Number. 14 15 IEEE IS NORMAL (X) Determine if a value is normal, that is, neither an 16 infinity, a NaN, nor denormalized. IEEE IS NEGATIVE (X) Determine if value is negative. 17 18 IEEE LOGB (X) Unbiased exponent in the IEEE floating-point 19 format. 20 IEEE NEXT AFTER (X,Y) Returns the next representable neighbor of X in 21 the direction toward Y. 22 IEEE REM (X,Y) The IEEE REM function, that is X - Y*N, where 23 N is the integer nearest to the exact value X/Y. 24 25 IEEE RINT (X) Round to an integer value according to the 26 current rounding mode. IEEE SCALB (X,I) Returns X × 2I. 27 28 IEEE UNORDERED (X,Y) IEEE unordered function. True if X or Y is a 29 NaN and false otherwise. IEEE VALUE (X,CLASS) Generate an IEEE value. 30 3114.9.3 Kind function 32The module IEEE ARITHMETIC contains the following transformational function. 33 IEEE SELECTED REAL KIND ([P, R, Kind type parameter value for an IEEE real with RADIX]) 34 given precision, range, and radix. 3514.9.4 Elemental subroutines 36The module IEEE EXCEPTIONS contains the following elemental subroutines. IEEE GET FLAG (FLAG,FLAG VALUE) Get an exception flag. 37 IEEE GET HALTING MODE (FLAG, Get halting mode for an exception. HALTING) 38 3914.9.5 Nonelemental subroutines 446 2006/01/05 WORKING DRAFT J3/07-007 1The module IEEE EXCEPTIONS contains the following nonelemental subroutines. 2 IEEE GET STATUS (STATUS VALUE) Get the current state of the floating-point 3 environment. IEEE SET FLAG (FLAG,FLAG VALUE) Set an exception flag. 4 IEEE SET HALTING MODE (FLAG, Controls continuation or halting on exceptions. HALTING) 5 6 IEEE SET STATUS (STATUS VALUE) Restore the state of the floating-point 7 environment. 8The nonelemental subroutines IEEE SET FLAG and IEEE SET HALTING MODE are pure. No other 9nonelemental subroutine contained in IEEE EXCEPTIONS is pure. 10The module IEEE ARITHMETIC contains the following nonelemental subroutines. IEEE GET ROUNDING MODE Get the current IEEE rounding mode. (ROUND VALUE) 11 IEEE GET UNDERFLOW MODE Get the current underflow mode. (GRADUAL) 12 IEEE SET ROUNDING MODE Set the current IEEE rounding mode. (ROUND VALUE) 13 IEEE SET UNDERFLOW MODE Set the current underflow mode. (GRADUAL) 14 15No nonelemental subroutine contained in IEEE ARITHMETIC is pure. 14.10 Specifications of the procedures 16 17In the detailed descriptions below, procedure names are generic and are not specific. All the functions 18are pure. The dummy arguments of the intrinsic module procedures in 14.9.1, 14.9.2, and 14.9.3 have 19INTENT(IN). The dummy arguments of the intrinsic module procedures in 14.9.4 and 14.9.5 have 20INTENT(IN) if the intent is not stated explicitly. In the examples, it is assumed that the processor 21supports IEEE arithmetic for default real. NOTE 14.8 It is intended that a processor should not check a condition given in a paragraph labeled "Restriction" at compile time, but rather should rely on the programmer writing code such as IF (IEEE_SUPPORT_DATATYPE(X)) THEN C = IEEE_CLASS(X) ELSE . . ENDIF to avoid a call being made on a processor for which the condition is violated. 22For the elemental functions of IEEE ARITHMETIC, as tabulated in 14.9.2, if X or Y has a value that 23is an infinity or a NaN, the result shall be consistent with the general rules in 6.1 and 6.2 of the IEEE 24International Standard. For example, the result for an infinity shall be constructed as the limiting case 25of the result with a value of arbitrarily large magnitude, if such a limit exists. 447 J3/07-007 WORKING DRAFT 2006/01/05 14.10.1 IEEE CLASS (X) 1 2Description. IEEE class function. 3Class. Elemental function. 4Argument. X shall be of type real. 5Restriction. IEEE CLASS(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the value 6false. Result Characteristics. TYPE(IEEE CLASS TYPE). 7 8Result Value. The result value shall be IEEE SIGNALING NAN or IEEE QUIET NAN if IEEE - 9SUPPORT NAN(X) has the value true and the value of X is a signaling or quiet NaN, respectively. The 10result value shall be IEEE NEGATIVE INF or IEEE POSITIVE INF if IEEE SUPPORT INF(X) has 11the value true and the value of X is negative or positive infinity, respectively. The result value shall 12be IEEE NEGATIVE DENORMAL or IEEE POSITIVE DENORMAL if IEEE SUPPORT DENOR- 13MAL(X) has the value true and the value of X is a negative or positive denormalized value, respectively. 14The result value shall be IEEE NEGATIVE NORMAL, IEEE NEGATIVE ZERO, IEEE POSITIVE - 15ZERO, or IEEE POSITIVE NORMAL if value of X is negative normal, negative zero, positive zero, or 16positive normal, respectively. Otherwise, the result value shall be IEEE OTHER VALUE. Example. IEEE CLASS(-1.0) has the value IEEE NEGATIVE NORMAL. 17 NOTE 14.9 The result value IEEE OTHER VALUE is needed for implementing the module on systems which are basically IEEE, but do not implement all of it. It might be needed, for example, if an unfor- matted file were written in a program executing with gradual underflow enabled and read with it disabled. 14.10.2 IEEE COPY SIGN (X, Y) 18 19Description. IEEE copysign function. 20Class. Elemental function. 21Arguments. The arguments shall be of type real. 22Restriction. IEEE COPY SIGN(X,Y) shall not be invoked if IEEE SUPPORT DATATYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 23 24Result Characteristics. Same as X. 25Result Value. The result has the value of X with the sign of Y. This is true even for IEEE special values, such as a NaN or an infinity (on processors supporting such values). 26 Example. The value of IEEE COPY SIGN(X,1.0) is ABS(X) even when X is NaN. 27 14.10.3 IEEE GET FLAG (FLAG, FLAG VALUE) 28 29Description. Get an exception flag. 30Class. Elemental subroutine. 31Arguments. FLAG shall be of type TYPE(IEEE FLAG TYPE). It specifies the IEEE flag to be obtained. 448 2006/01/05 WORKING DRAFT J3/07-007 FLAG VALUE shall be of type default logical. It is an INTENT(OUT) argument. If the value of FLAG is IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE - UNDERFLOW, or IEEE INEXACT, the result value is true if the corresponding 1 exception flag is signaling and is false otherwise. 2Example. Following CALL IEEE GET FLAG(IEEE OVERFLOW,FLAG VALUE), FLAG VALUE is 3true if the IEEE OVERFLOW flag is signaling and is false if it is quiet. 14.10.4 IEEE GET HALTING MODE (FLAG, HALTING) 4 5Description. Get halting mode for an exception. 6Class. Elemental subroutine. 7Arguments. FLAG shall be of type TYPE(IEEE FLAG TYPE). It specifies the IEEE flag. It shall have one of the values IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, 8 IEEE UNDERFLOW, or IEEE INEXACT. HALTING shall be of type default logical. It is of INTENT(OUT). The value is true if the 9 exception specified by FLAG will cause halting. Otherwise, the value is false. 10Example. To store the halting mode for IEEE OVERFLOW, do a calculation without halting, and 11restore the halting mode later: 12 USE, INTRINSIC :: IEEE_ARITHMETIC 13 LOGICAL HALTING 14 ... 15 CALL IEEE_GET_HALTING_MODE(IEEE_OVERFLOW,HALTING) ! Store halting mode 16 CALL IEEE_SET_HALTING_MODE(IEEE_OVERFLOW,.FALSE.) ! No halting 17 ...! calculation without halting 18 CALL IEEE_SET_HALTING_MODE(IEEE_OVERFLOW,HALTING) ! Restore halting mode 14.10.5 IEEE GET ROUNDING MODE (ROUND VALUE) 19 20Description. Get the current IEEE rounding mode. 21Class. Subroutine. 22Argument. ROUND VALUE shall be scalar of type TYPE(IEEE ROUND TYPE). It is an IN- 23TENT(OUT) argument and returns the floating-point rounding mode, with value IEEE NEAREST, 24IEEE TO ZERO, IEEE UP, or IEEE DOWN if one of the IEEE modes is in operation and IEEE - 25OTHER otherwise. 26Example. To store the rounding mode, do a calculation with round to nearest, and restore the rounding 27mode later: 28 USE, INTRINSIC :: IEEE_ARITHMETIC 29 TYPE(IEEE_ROUND_TYPE) ROUND_VALUE 30 ... 31 CALL IEEE_GET_ROUNDING_MODE(ROUND_VALUE) ! Store the rounding mode 32 CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) 449 J3/07-007 WORKING DRAFT 2006/01/05 1 ... ! calculation with round to nearest 2 CALL IEEE_SET_ROUNDING_MODE(ROUND_VALUE) ! Restore the rounding mode 14.10.6 IEEE GET STATUS (STATUS VALUE) 3 Description. Get the current value of the floating-point status (14.6). 4 5Class. Subroutine. 6Argument. STATUS VALUE shall be scalar of type TYPE(IEEE STATUS TYPE). It is an IN- TENT(OUT) argument and returns the floating-point status. 7 8Example. To store all the exception flags, do a calculation involving exception handling, and restore 9them later: 10 USE, INTRINSIC :: IEEE_ARITHMETIC 11 TYPE(IEEE_STATUS_TYPE) STATUS_VALUE 12 ... 13 CALL IEEE_GET_STATUS(STATUS_VALUE) ! Get the flags 14 CALL IEEE_SET_FLAG(IEEE_ALL,.FALSE.) ! Set the flags quiet. 15 ... ! calculation involving exception handling 16 CALL IEEE_SET_STATUS(STATUS_VALUE) ! Restore the flags 14.10.7 IEEE GET UNDERFLOW MODE (GRADUAL) 17 Description. Get the current underflow mode (14.4). 18 19Class. Subroutine. 20Argument. GRADUAL shall be scalar and of type default logical. It is an INTENT(OUT) argument. 21The value is true if the current underflow mode is gradual underflow, and false if the current underflow 22mode is abrupt underflow. 23Restriction. IEEE GET UNDERFLOW MODE shall not be invoked unless IEEE SUPPORT UN- DERFLOW CONTROL(X) is true for some X. 24 25Example. After CALL IEEE SET UNDERFLOW MODE(.FALSE.), a subsequent CALL IEEE - GET UNDERFLOW MODE(GRADUAL) will set GRADUAL to false. 26 14.10.8 IEEE IS FINITE (X) 27 28Description. Determine if a value is finite. 29Class. Elemental function. 30Argument. X shall be of type real. 31Restriction. IEEE IS FINITE(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the 32value false. 33Result Characteristics. Default logical. 34Result Value. The result has the value true if the value of X is finite, that is, IEEE CLASS(X) has one of 35the values IEEE NEGATIVE NORMAL, IEEE NEGATIVE DENORMAL, IEEE NEGATIVE ZERO, 450 2006/01/05 WORKING DRAFT J3/07-007 1IEEE POSITIVE ZERO, IEEE POSITIVE DENORMAL, or IEEE POSITIVE NORMAL; otherwise, 2the result has the value false. Example. IEEE IS FINITE(1.0) has the value true. 3 14.10.9 IEEE IS NAN (X) 4 5Description. Determine if a value is IEEE Not-a-Number. 6Class. Elemental function. 7Argument. X shall be of type real. Restriction. IEEE IS NAN(X) shall not be invoked if IEEE SUPPORT NAN(X) has the value false. 8 9Result Characteristics. Default logical. 10Result Value. The result has the value true if the value of X is an IEEE NaN; otherwise, it has the 11value false. 12Example. IEEE IS NAN(SQRT(-1.0)) has the value true if IEEE SUPPORT SQRT(1.0) has the value 13true. 14.10.10 IEEE IS NEGATIVE (X) 14 15Description. Determine if a value is negative. 16Class. Elemental function. 17Argument. X shall be of type real. 18Restriction. IEEE IS NEGATIVE(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has 19the value false. 20Result Characteristics. Default logical. 21Result Value. The result has the value true if IEEE CLASS(X) has one of the values IEEE NEGA- 22TIVE NORMAL, IEEE NEGATIVE DENORMAL, IEEE NEGATIVE ZERO or IEEE NEGATIVE - 23INF; otherwise, the result has the value false. Example. IEEE IS NEGATIVE(0.0)) has the value false. 24 14.10.11 IEEE IS NORMAL (X) 25 26Description. Determine if a value is normal, that is, neither an infinity, a NaN, nor denormalized. 27Class. Elemental function. 28Argument. X shall be of type real. 29Restriction. IEEE IS NORMAL(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the 30value false. 31Result Characteristics. Default logical. 32Result Value. The result has the value true if IEEE CLASS(X) has one of the values IEEE NEGA- 33TIVE NORMAL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO or IEEE POSITIVE NORMAL; 34otherwise, the result has the value false. 451 J3/07-007 WORKING DRAFT 2006/01/05 1Example. IEEE IS NORMAL(SQRT(-1.0)) has the value false if IEEE SUPPORT SQRT(1.0) has the 2value true. 14.10.12 IEEE LOGB (X) 3 4Description. Unbiased exponent in the IEEE floating-point format. 5Class. Elemental function. 6Argument. X shall be of type real. 7Restriction. IEEE LOGB(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the value 8false. 9Result Characteristics. Same as X. 10Result Value. 11Case (i): If the value of X is neither zero, infinity, nor NaN, the result has the value of the unbiased exponent of X. Note: this value is equal to EXPONENT(X)-1. 12 13Case (ii): If X==0, the result is -infinity if IEEE SUPPORT INF(X) is true and -HUGE(X) other- 14 wise; IEEE DIVIDE BY ZERO signals. Example. IEEE LOGB(-1.1) has the value 0.0. 15 14.10.13 IEEE NEXT AFTER (X, Y) 16 17Description. Returns the next representable neighbor of X in the direction toward Y. 18Class. Elemental function. 19Arguments. The arguments shall be of type real. 20Restriction. IEEE NEXT AFTER(X,Y) shall not be invoked if IEEE SUPPORT DATATYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 21 22Result Characteristics. Same as X. 23Result Value. Case (i): If X == Y, the result is X and no exception is signaled. 24 25Case (ii): If X /= Y, the result has the value of the next representable neighbor of X in the direction 26 of Y. The neighbors of zero (of either sign) are both nonzero. IEEE OVERFLOW is sig- 27 naled when X is finite but IEEE NEXT AFTER(X,Y) is infinite; IEEE UNDERFLOW 28 is signaled when IEEE NEXT AFTER(X,Y) is denormalized; in both cases, IEEE INEX- 29 ACT signals. Example. The value of IEEE NEXT AFTER(1.0,2.0) is 1.0+EPSILON(X). 30 14.10.14 IEEE REM (X, Y) 31 32Description. IEEE REM function. 33Class. Elemental function. 34Arguments. The arguments shall be of type real. 35Restriction. IEEE REM(X,Y) shall not be invoked if IEEE SUPPORT DATATYPE(X) or IEEE - SUPPORT DATATYPE(Y) has the value false. 452 2006/01/05 WORKING DRAFT J3/07-007 1 2Result Characteristics. Real with the kind type parameter of whichever argument has the greater 3precision. 4Result Value. The result value, regardless of the rounding mode, shall be exactly X - Y*N, where N 5is the integer nearest to the exact value X/Y; whenever |N - X/Y| = 1/2, N shall be even. If the result 6value is zero, the sign shall be that of X. 7Examples. The value of IEEE REM(4.0,3.0) is 1.0, the value of IEEE REM(3.0,2.0) is -1.0, and the value of IEEE REM(5.0,2.0) is 1.0. 8 14.10.15 IEEE RINT (X) 9 10Description. Round to an integer value according to the current rounding mode. 11Class. Elemental function. 12Argument. X shall be of type real. 13Restriction. IEEE RINT(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the value 14false. 15Result Characteristics. Same as X. 16Result Value. The value of the result is the value of X rounded to an integer according to the current 17rounding mode. If the result has the value zero, the sign is that of X. 18Examples. If the current rounding mode is round to nearest, the value of IEEE RINT(1.1) is 1.0. If the current rounding mode is round up, the value of IEEE RINT(1.1) is 2.0. 19 14.10.16 IEEE SCALB (X, I) 20 21Description. Returns X × 2I. 22Class. Elemental function. 23Arguments. 24X shall be of type real. 25I shall be of type integer. 26Restriction. IEEE SCALB(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the value 27false. 28Result Characteristics. Same as X. 29Result Value. Case (i): If X × 2I is representable as a normal number, the result has this value. 30 31Case (ii): If X is finite and X × 2I is too large, the IEEE OVERFLOW exception shall occur. If 32 IEEE SUPPORT INF(X) is true, the result value is infinity with the sign of X; otherwise, the result value is SIGN(HUGE(X),X). 33 34Case (iii): If X × 2I is too small and there is loss of accuracy, the IEEE UNDERFLOW exception 35 shall occur. The result is the representable number having a magnitude nearest to |2I| 36 and the same sign as X. Case (iv): If X is infinite, the result is the same as X; no exception signals. 37 453 J3/07-007 WORKING DRAFT 2006/01/05 Example. The value of IEEE SCALB(1.0,2) is 4.0. 1 14.10.17 IEEE SELECTED REAL KIND ([P, R, RADIX]) 2 3Description. Returns a value of the kind type parameter of an IEEE real data type with decimal 4precision of at least P digits, a decimal exponent range of at least R, and a radix of RADIX. For data objects of such a type, IEEE SUPPORT DATATYPE(X) has the value true. 5 6Class. Transformational function. 7Arguments. At least one argument shall be present. P (optional) shall be scalar and of type integer. 8 R (optional) shall be scalar and of type integer. 9 RADIX (optional)shall be scalar and of type integer. 10 11Result Characteristics. Default integer scalar. 12Result Value. If P or R is absent, the result value is the same as if it were present with the value zero. 13If RADIX is absent, there is no requirement on the radix of the selected kind. The result has a value 14equal to a value of the kind type parameter of an IEEE real type with decimal precision, as returned by 15the function PRECISION, of at least P digits, a decimal exponent range, as returned by the function 16RANGE, of at least R, and a radix, as returned by the function RADIX, of RADIX, if such a kind type 17parameter is available on the processor. 18Otherwise, the result is -1 if the processor supports an IEEE real type with radix RADIX and exponent 19range of at least R but not with precision of at least P, -2 if the processor supports an IEEE real 20type with radix RADIX and precision of at least P but not with exponent range of at least R, -3 if 21the processor supports an IEEE real type with radix RADIX but with neither precision of at least P 22nor exponent range of at least R, -4 if the processor supports an IEEE real type with radix RADIX 23and either precision of at least P or exponent range of at least R but not both together, and -5 if the 24processor supports no IEEE real type with radix RADIX. 25If more than one kind type parameter value meets the criteria, the value returned is the one with the 26smallest decimal precision, unless there are several such values, in which case the smallest of these kind 27values is returned. 28Example. IEEE SELECTED REAL KIND(6,30) has the value KIND(0.0) on a machine that supports 29IEEE single precision arithmetic for its default real approximation method. 14.10.18 IEEE SET FLAG (FLAG, FLAG VALUE) 30 31Description. Assign a value to an exception flag. 32Class. Pure subroutine. 33Arguments. FLAG shall be a scalar or array of type TYPE(IEEE FLAG TYPE). If a value of FLAG is IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE UNDER- FLOW, or IEEE INEXACT, the corresponding exception flag is assigned a value. No 34 two elements of FLAG shall have the same value. FLAG VALUE shall be a scalar or array of type default logical. It shall be conformable with FLAG. If an element has the value true, the corresponding flag is set to be signaling; otherwise, 35 the flag is set to be quiet. 454 2006/01/05 WORKING DRAFT J3/07-007 1Example. CALL IEEE SET FLAG(IEEE OVERFLOW,.TRUE.) sets the IEEE OVERFLOW flag to 2be signaling. 14.10.19 IEEE SET HALTING MODE (FLAG, HALTING) 3 4Description. Controls continuation or halting after an exception. 5Class. Pure subroutine. 6Arguments. FLAG shall be a scalar or array of type TYPE(IEEE FLAG TYPE). It shall have only the values IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE - UNDERFLOW, or IEEE INEXACT. No two elements of FLAG shall have the same 7 value. HALTING shall be a scalar or array of type default logical. It shall be conformable with FLAG. If an element has the value true, the corresponding exception specified by FLAG will 8 cause halting. Otherwise, execution will continue after this exception. 9Restriction. IEEE SET HALTING MODE(FLAG,HALTING) shall not be invoked if IEEE - SUPPORT HALTING(FLAG) has the value false. 10 11Example. CALL IEEE SET HALTING MODE(IEEE DIVIDE BY ZERO,.TRUE.) causes halting af- 12ter a divide by zero exception. NOTE 14.10 The initial halting mode is processor dependent. Halting is not precise and may occur some time after the exception has occurred. 14.10.20 IEEE SET ROUNDING MODE (ROUND VALUE) 13 14Description. Set the current IEEE rounding mode. 15Class. Subroutine. 16Argument. ROUND VALUE shall be scalar and of type TYPE(IEEE ROUND TYPE). It specifies 17the mode to be set. 18Restriction. IEEE SET ROUNDING MODE(ROUND VALUE) shall not be invoked unless IEEE - 19SUPPORT ROUNDING(ROUND VALUE,X) is true for some X such that IEEE SUPPORT DATA- TYPE(X) is true. 20 21Example. To store the rounding mode, do a calculation with round to nearest, and restore the rounding 22mode later: 23 USE, INTRINSIC :: IEEE_ARITHMETIC 24 TYPE(IEEE_ROUND_TYPE) ROUND_VALUE 25 ... 26 CALL IEEE_GET_ROUNDING_MODE(ROUND_VALUE) ! Store the rounding mode 27 CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) 28 : ! calculation with round to nearest 29 CALL IEEE_SET_ROUNDING_MODE(ROUND_VALUE) ! Restore the rounding mode 14.10.21 IEEE SET STATUS (STATUS VALUE) 455 J3/07-007 WORKING DRAFT 2006/01/05 Description. Restore the value of the floating-point status (14.6). 1 2Class. Subroutine. 3Argument. STATUS VALUE shall be scalar and of type TYPE(IEEE STATUS TYPE). Its value shall 4have been set in a previous invocation of IEEE GET STATUS. 5Example. To store all the exceptions flags, do a calculation involving exception handling, and restore 6them later: 7 USE, INTRINSIC :: IEEE_EXCEPTIONS 8 TYPE(IEEE_STATUS_TYPE) STATUS_VALUE 9 ... 10 CALL IEEE_GET_STATUS(STATUS_VALUE) ! Store the flags 11 CALL IEEE_SET_FLAGS(IEEE_ALL,.FALSE.) ! Set them quiet 12 ... ! calculation involving exception handling 13 CALL IEEE_SET_STATUS(STATUS_VALUE) ! Restore the flags NOTE 14.11 On some processors this may be a very time consuming process. 14.10.22 IEEE SET UNDERFLOW MODE (GRADUAL) 14 15Description. Set the current underflow mode. 16Class. Subroutine. 17Argument. GRADUAL shall be scalar and of type default logical. If it is true, the current underflow 18mode is set to gradual underflow. If it is false, the current underflow mode is set to abrupt underflow. 19Restriction. IEEE SET UNDERFLOW MODE shall not be invoked unless IEEE SUPPORT UN- DERFLOW CONTROL(X) is true for some X. 20 21Example. To perform some calculations with abrupt underflow and then restore the previous mode: 22 USE,INTRINSIC :: IEEE_ARITHMETIC 23 LOGICAL SAVE_UNDERFLOW_MODE 24 ... 25 CALL IEEE_GET_UNDERFLOW_MODE(SAVE_UNDERFLOW_MODE) 26 CALL IEEE_SET_UNDERFLOW_MODE(GRADUAL=.FALSE.) 27 ... ! Perform some calculations with abrupt underflow 28 CALL IEEE_SET_UNDERFLOW_MODE(SAVE_UNDERFLOW_MODE) 14.10.23 IEEE SUPPORT DATATYPE () or IEEE SUPPORT DATATYPE (X) 29 30Description. Inquire whether the processor supports IEEE arithmetic. 31Class. Inquiry function. 32Argument. X shall be of type real. It may be a scalar or an array. 456 2006/01/05 WORKING DRAFT J3/07-007 1Result Characteristics. Default logical scalar. 2Result Value. The result has the value true if the processor supports IEEE arithmetic for all reals 3(X absent) or for real variables of the same kind type parameter as X; otherwise, it has the value false. 4Here, support is as defined in the first paragraph of 14.8. 5Example. If default real type conforms to the IEEE International Standard except that underflow values flush to zero instead of being denormal, IEEE SUPPORT DATATYPE(1.0) has the value true. 6 14.10.24 IEEE SUPPORT DENORMAL () or IEEE SUPPORT DENORMAL (X) 7 8Description. Inquire whether the processor supports IEEE denormalized numbers. 9Class. Inquiry function. 10Argument. X shall be of type real. It may be a scalar or an array. 11Result Characteristics. Default logical scalar. 12Result Value. 13Case (i): IEEE SUPPORT DENORMAL(X) has the value true if IEEE SUPPORT - 14 DATATYPE(X) has the value true and the processor supports arithmetic operations and 15 assignments with denormalized numbers (biased exponent e = 0 and fraction f = 0, see 16 subclause 3.2 of the IEEE International Standard) for real variables of the same kind 17 type parameter as X; otherwise, it has the value false. 18Case (ii): IEEE SUPPORT DENORMAL() has the value true if and only if IEEE SUPPORT - DENORMAL(X) has the value true for all real X. 19 20Example. IEEE SUPPORT DENORMAL(X) has the value true if the processor supports denormalized 21numbers for X. NOTE 14.12 The denormalized numbers are not included in the 13.4 model for real numbers; they satisfy the inequality ABS(X) < TINY(X). They usually occur as a result of an arithmetic operation whose exact result is less than TINY(X). Such an operation causes IEEE UNDERFLOW to signal unless the result is exact. IEEE SUPPORT DENORMAL(X) is false if the processor never returns a denormalized number as the result of an arithmetic operation. 14.10.25 IEEE SUPPORT DIVIDE () or IEEE SUPPORT DIVIDE (X) 22 23Description. Inquire whether the processor supports divide with the accuracy specified by the IEEE 24International Standard. 25Class. Inquiry function. 26Argument. X shall be of type real. It may be a scalar or an array. 27Result Characteristics. Default logical scalar. 28Result Value. 29Case (i): IEEE SUPPORT DIVIDE(X) has the value true if the processor supports divide with the 30 accuracy specified by the IEEE International Standard for real variables of the same kind 31 type parameter as X; otherwise, it has the value false. 32Case (ii): IEEE SUPPORT DIVIDE() has the value true if and only if IEEE SUPPORT - DIVIDE(X) has the value true for all real X. 33 457 J3/07-007 WORKING DRAFT 2006/01/05 1Example. IEEE SUPPORT DIVIDE(X) has the value true if the processor supports IEEE divide for 2X. 14.10.26 IEEE SUPPORT FLAG (FLAG) or IEEE SUPPORT FLAG (FLAG, X) 3 4Description. Inquire whether the processor supports an exception. 5Class. Inquiry function. 6Arguments. FLAG shall be scalar and of type TYPE(IEEE FLAG TYPE). Its value shall be one of IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE UNDER- 7 FLOW, or IEEE INEXACT. 8X shall be of type real. It may be a scalar or an array. 9Result Characteristics. Default logical scalar. 10Result Value. 11Case (i): IEEE SUPPORT FLAG(FLAG, X) has the value true if the processor supports detec- 12 tion of the specified exception for real variables of the same kind type parameter as X; 13 otherwise, it has the value false. 14Case (ii): IEEE SUPPORT FLAG(FLAG) has the value true if and only if IEEE SUPPORT - FLAG(FLAG, X) has the value true for all real X. 15 16Example. IEEE SUPPORT FLAG(IEEE INEXACT) has the value true if the processor supports the 17inexact exception. 14.10.27 IEEE SUPPORT HALTING (FLAG) 18 19Description. Inquire whether the processor supports the ability to control during program execution 20whether to abort or continue execution after an exception. 21Class. Inquiry function. 22Argument. FLAG shall be scalar and of type TYPE(IEEE FLAG TYPE). Its value shall be one 23of IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE UNDERFLOW, or IEEE - 24INEXACT. 25Result Characteristics. Default logical scalar. 26Result Value. The result has the value true if the processor supports the ability to control during pro- 27gram execution whether to abort or continue execution after the exception specified by FLAG; otherwise, 28it has the value false. Support includes the ability to change the mode by CALL IEEE SET HALT- ING(FLAG). 29 30Example. IEEE SUPPORT HALTING(IEEE OVERFLOW) has the value true if the processor sup- 31ports control of halting after an overflow. 14.10.28 IEEE SUPPORT INF () or IEEE SUPPORT INF (X) 32 33Description. Inquire whether the processor supports the IEEE infinity facility. 34Class. Inquiry function. 35Argument. X shall be of type real. It may be a scalar or an array. 458 2006/01/05 WORKING DRAFT J3/07-007 1Result Characteristics. Default logical scalar. 2Result Value. 3Case (i): IEEE SUPPORT INF(X) has the value true if the processor supports IEEE infinities 4 (positive and negative) for real variables of the same kind type parameter as X; otherwise, 5 it has the value false. 6Case (ii): IEEE SUPPORT INF() has the value true if and only if IEEE SUPPORT INF(X) has 7 the value true for all real X. Example. IEEE SUPPORT INF(X) has the value true if the processor supports IEEE infinities for X. 8 14.10.29 IEEE SUPPORT IO () or IEEE SUPPORT IO (X) 9 10Description. Inquire whether the processor supports IEEE base conversion rounding during formatted input/output (9.4.5.14, 9.5.2.13, 10.7.2.3.7). 11 12Class. Inquiry function. 13Argument. X shall be of type real. It may be a scalar or an array. 14Result Characteristics. Default logical scalar. 15Result Value. 16Case (i): IEEE SUPPORT IO(X) has the value true if the processor supports IEEE base conversion 17 during formatted input/output (9.4.5.14, 9.5.2.13, 10.7.2.3.7) as described in the IEEE In- 18 ternational Standard for the modes UP, DOWN, ZERO, and NEAREST for real variables 19 of the same kind type parameter as X; otherwise, it has the value false. 20Case (ii): IEEE SUPPORT IO() has the value true if and only if IEEE SUPPORT IO(X) has the 21 value true for all real X. 22Example. IEEE SUPPORT IO(X) has the value true if the processor supports IEEE base conversion 23for X. 14.10.30 IEEE SUPPORT NAN () or IEEE SUPPORT NAN (X) 24 25Description. Inquire whether the processor supports the IEEE Not-a-Number facility. 26Class. Inquiry function. 27Argument. X shall be of type real. It may be a scalar or an array. 28Result Characteristics. Default logical scalar. 29Result Value. 30Case (i): IEEE SUPPORT NAN(X) has the value true if the processor supports IEEE NaNs for 31 real variables of the same kind type parameter as X; otherwise, it has the value false. 32Case (ii): IEEE SUPPORT NAN() has the value true if and only if IEEE SUPPORT NAN(X) has 33 the value true for all real X. Example. IEEE SUPPORT NAN(X) has the value true if the processor supports IEEE NaNs for X. 34 14.10.31 IEEE SUPPORT ROUNDING (ROUND VALUE) or IEEE SUPPORT ROUNDING (ROUND VALUE, X) 35 Description. Inquire whether the processor supports a particular IEEE rounding mode. 459 J3/07-007 WORKING DRAFT 2006/01/05 1 2Class. Inquiry function. 3Arguments. ROUND VALUE shall be of type TYPE(IEEE ROUND TYPE). 4 5X shall be of type real. It may be a scalar or an array. 6Result Characteristics. Default logical scalar. 7Result Value. 8Case (i): IEEE SUPPORT ROUNDING(ROUND VALUE, X) has the value true if the processor 9 supports the rounding mode defined by ROUND VALUE for real variables of the same 10 kind type parameter as X; otherwise, it has the value false. Support includes the ability to change the mode by CALL IEEE SET ROUNDING MODE(ROUND VALUE). 11 12Case (ii): IEEE SUPPORT ROUNDING(ROUND VALUE) has the value true if and only if IEEE- SUPPORT ROUNDING(ROUND VALUE, X) has the value true for all real X. 13 14Example. IEEE SUPPORT ROUNDING(IEEE TO ZERO) has the value true if the processor sup- 15ports rounding to zero for all reals. 14.10.32 IEEE SUPPORT SQRT () or IEEE SUPPORT SQRT (X) 16 17Description. Inquire whether the intrinsic function SQRT conforms to the IEEE International Stan- 18dard. 19Class. Inquiry function. 20Argument. X shall be of type real. It may be a scalar or an array. 21Result Characteristics. Default logical scalar. 22Result Value. 23Case (i): IEEE SUPPORT SQRT(X) has the value true if the intrinsic function SQRT conforms 24 to the IEEE International Standard for real variables of the same kind type parameter as 25 X; otherwise, it has the value false. 26Case (ii): IEEE SUPPORT SQRT() has the value true if and only if IEEE SUPPORT SQRT(X) 27 has the value true for all real X. Example. If IEEE SUPPORT SQRT(1.0) has the value true, SQRT(-0.0) will have the value -0.0. 28 14.10.33 IEEE SUPPORT STANDARD () or IEEE SUPPORT STANDARD (X) 29 30Description. Inquire whether the processor supports all the IEEE facilities defined in this part of ISO/IEC 1539. 31 32Class. Inquiry function. 33Argument. X shall be of type real. It may be a scalar or an array. 34Result Characteristics. Default logical scalar. 35Result Value. 36Case (i): IEEE SUPPORT STANDARD(X) has the value true if the results of all the func- 37 tions IEEE SUPPORT DATATYPE(X), IEEE SUPPORT DENORMAL(X), IEEE - 460 2006/01/05 WORKING DRAFT J3/07-007 1 SUPPORT DIVIDE(X), IEEE SUPPORT FLAG(FLAG,X) for valid FLAG, IEEE- 2 SUPPORT HALTING(FLAG) for valid FLAG, IEEE SUPPORT INF(X), IEEE - 3 SUPPORT NAN(X), IEEE SUPPORT ROUNDING (ROUND VALUE,X) for valid 4 ROUND VALUE, and IEEE SUPPORT SQRT (X) are all true; otherwise, the result 5 has the value false. 6Case (ii): IEEE SUPPORT STANDARD() has the value true if and only if IEEE SUPPORT - STANDARD(X) has the value true for all real X. 7 8Example. IEEE SUPPORT STANDARD() has the value false if the processor supports both IEEE 9and non-IEEE kinds of reals. 1014.10.34 IEEE SUPPORT UNDERFLOW CONTROL() or IEEE SUPPORT UNDERFLOW CONTROL(X) 11 12Description. Inquire whether the procedure supports the ability to control the underflow mode during 13program execution. 14Class. Inquiry function. 15Argument. X shall be of type real. It may be a scalar or an array. 16Result Characteristics. Default logical scalar. 17Result Value. 18Case (i): IEEE SUPPORT UNDERFLOW CONTROL(X) has the value true if the processor sup- 19 ports control of the underflow mode for floating-point calculations with the same type as 20 X, and false otherwise. 21Case (ii): IEEE SUPPORT UNDERFLOW CONTROL() has the value true if the processor sup- 22 ports control of the underflow mode for all floating-point calculations, and false otherwise. 23Example. IEEE SUPPORT UNDERFLOW CONTROL(2.5) has the value true if the processor sup- 24ports underflow mode control for calculations of type default real. 14.10.35 IEEE UNORDERED (X, Y) 25 26Description. IEEE unordered function. True if X or Y is a NaN, and false otherwise. 27Class. Elemental function. 28Arguments. The arguments shall be of type real. 29Restriction. IEEE UNORDERED(X,Y) shall not be invoked if IEEE SUPPORT DATATYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 30 31Result Characteristics. Default logical. 32Result Value. The result has the value true if X or Y is a NaN or both are NaNs; otherwise, it has 33the value false. 34Example. IEEE UNORDERED(0.0,SQRT(-1.0)) has the value true if IEEE SUPPORT SQRT(1.0) 35has the value true. 14.10.36 IEEE VALUE (X, CLASS) 36 37Description. Generate an IEEE value. 461 J3/07-007 WORKING DRAFT 2006/01/05 1Class. Elemental function. 2Arguments. 3X shall be of type real. CLASS shall be of type TYPE(IEEE CLASS TYPE). The value is permitted to be: IEEE - SIGNALING NAN or IEEE QUIET NAN if IEEE SUPPORT NAN(X) has the value true, IEEE NEGATIVE INF or IEEE POSITIVE INF if IEEE SUPPORT - INF(X) has the value true, IEEE NEGATIVE DENORMAL or IEEE POSITIVE - DENORMAL if IEEE SUPPORT DENORMAL(X) has the value true, IEEE NEGA- TIVE NORMAL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO or IEEE - 4 POSITIVE NORMAL. 5Restriction. IEEE VALUE(X,CLASS) shall not be invoked if IEEE SUPPORT DATATYPE(X) has 6the value false. 7Result Characteristics. Same as X. 8Result Value. The result value is an IEEE value as specified by CLASS. Although in most cases the 9value is processor dependent, the value shall not vary between invocations for any particular X kind 10type parameter and CLASS value. Example. IEEE VALUE(1.0,IEEE NEGATIVE INF) has the value -infinity. 11 12Whenever IEEE VALUE returns a signaling NaN, it is processor dependent whether or not invalid is 13raised and processor dependent whether or not the signaling NaN is converted into a quiet NaN. NOTE 14.13 If the expr in an assignment statement is a reference to the IEEE VALUE function that returns a signaling NaN and the variable is of the same type and kind as the function result, it is recom- mended that the signaling NaN be preserved. 14.11 Examples 14 NOTE 14.14 MODULE DOT ! Module for dot product of two real arrays of rank 1. ! The caller needs to ensure that exceptions do not cause halting. USE, INTRINSIC :: IEEE_EXCEPTIONS LOGICAL :: MATRIX_ERROR = .FALSE. INTERFACE OPERATOR(.dot.) MODULE PROCEDURE MULT END INTERFACE CONTAINS REAL FUNCTION MULT(A,B) REAL, INTENT(IN) :: A(:),B(:) INTEGER I LOGICAL OVERFLOW IF (SIZE(A)/=SIZE(B)) THEN 462 2006/01/05 WORKING DRAFT J3/07-007 NOTE 14.14 (cont.) MATRIX_ERROR = .TRUE. RETURN END IF ! The processor ensures that IEEE_OVERFLOW is quiet MULT = 0.0 DO I = 1, SIZE(A) MULT = MULT + A(I)*B(I) END DO CALL IEEE_GET_FLAG(IEEE_OVERFLOW,OVERFLOW) IF (OVERFLOW) MATRIX_ERROR = .TRUE. END FUNCTION MULT END MODULE DOT This module provides the dot product of two real arrays of rank 1. If the sizes of the arrays are different, an immediate return occurs with MATRIX ERROR true. If overflow occurs during the actual calculation, the IEEE OVERFLOW flag will signal and MATRIX ERROR will be true. NOTE 14.15 USE, INTRINSIC :: IEEE_EXCEPTIONS USE, INTRINSIC :: IEEE_FEATURES, ONLY: IEEE_INVALID_FLAG ! The other exceptions of IEEE_USUAL (IEEE_OVERFLOW and ! IEEE_DIVIDE_BY_ZERO) are always available with IEEE_EXCEPTIONS TYPE(IEEE_STATUS_TYPE) STATUS_VALUE LOGICAL, DIMENSION(3) :: FLAG_VALUE ... CALL IEEE_GET_STATUS(STATUS_VALUE) CALL IEEE_SET_HALTING_MODE(IEEE_USUAL,.FALSE.) ! Needed in case the ! default on the processor is to halt on exceptions CALL IEEE_SET_FLAG(IEEE_USUAL,.FALSE.) ! First try the "fast" algorithm for inverting a matrix: MATRIX1 = FAST_INV(MATRIX) ! This shall not alter MATRIX. CALL IEEE_GET_FLAG(IEEE_USUAL,FLAG_VALUE) IF (ANY(FLAG_VALUE)) THEN ! "Fast" algorithm failed; try "slow" one: CALL IEEE_SET_FLAG(IEEE_USUAL,.FALSE.) MATRIX1 = SLOW_INV(MATRIX) CALL IEEE_GET_FLAG(IEEE_USUAL,FLAG_VALUE) IF (ANY(FLAG_VALUE)) THEN WRITE (*, *) 'Cannot invert matrix' STOP END IF END IF CALL IEEE_SET_STATUS(STATUS_VALUE) 463 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 14.15 (cont.) In this example, the function FAST INV might cause a condition to signal. If it does, another try is made with SLOW INV. If this still fails, a message is printed and the program stops. Note, also, that it is important to set the flags quiet before the second try. The state of all the flags is stored and restored. NOTE 14.16 USE, INTRINSIC :: IEEE_EXCEPTIONS LOGICAL FLAG_VALUE ... CALL IEEE_SET_HALTING_MODE(IEEE_OVERFLOW,.FALSE.) ! First try a fast algorithm for inverting a matrix. CALL IEEE_SET_FLAG(IEEE_OVERFLOW,.FALSE.) DO K = 1, N ... CALL IEEE_GET_FLAG(IEEE_OVERFLOW,FLAG_VALUE) IF (FLAG_VALUE) EXIT END DO IF (FLAG_VALUE) THEN ! Alternative code which knows that K-1 steps have executed normally. ... END IF Here the code for matrix inversion is in line and the transfer is made more precise by adding extra tests of the flag. NOTE 14.17 REAL FUNCTION HYPOT(X, Y) ! In rare circumstances this may lead to the signaling of IEEE_OVERFLOW ! The caller needs to ensure that exceptions do not cause halting. USE, INTRINSIC :: IEEE_ARITHMETIC USE, INTRINSIC :: IEEE_FEATURES, ONLY: IEEE_UNDERFLOW_FLAG ! IEEE_OVERFLOW is always available with IEEE_ARITHMETIC REAL X, Y REAL SCALED_X, SCALED_Y, SCALED_RESULT LOGICAL, DIMENSION(2) :: FLAGS TYPE(IEEE_FLAG_TYPE), PARAMETER, DIMENSION(2) :: & OUT_OF_RANGE = (/ IEEE_OVERFLOW, IEEE_UNDERFLOW /) INTRINSIC SQRT, ABS, EXPONENT, MAX, DIGITS, SCALE ! The processor clears the flags on entry ! Try a fast algorithm first HYPOT = SQRT( X**2 + Y**2 ) CALL IEEE_GET_FLAG(OUT_OF_RANGE,FLAGS) 464 2006/01/05 WORKING DRAFT J3/07-007 NOTE 14.17 (cont.) IF ( ANY(FLAGS) ) THEN CALL IEEE_SET_FLAG(OUT_OF_RANGE,.FALSE.) IF ( X==0.0 .OR. Y==0.0 ) THEN HYPOT = ABS(X) + ABS(Y) ELSE IF ( 2*ABS(EXPONENT(X)-EXPONENT(Y)) > DIGITS(X)+1 ) THEN HYPOT = MAX( ABS(X), ABS(Y) )! one of X and Y can be ignored ELSE ! scale so that ABS(X) is near 1 SCALED_X = SCALE( X, -EXPONENT(X) ) SCALED_Y = SCALE( Y, -EXPONENT(X) ) SCALED_RESULT = SQRT( SCALED_X**2 + SCALED_Y**2 ) HYPOT = SCALE( SCALED_RESULT, EXPONENT(X) ) ! might cause overflow END IF END IF ! The processor resets any flag that was signaling on entry END FUNCTION HYPOT An attempt is made to evaluate this function directly in the fastest possible way. This will work almost every time, but if an exception occurs during this fast computation, a safe but slower way evaluates the function. This slower evaluation might involve scaling and unscaling, and in (very rare) extreme cases this unscaling can cause overflow (after all, the true result might overflow if X and Y are both near the overflow limit). If the IEEE OVERFLOW or IEEE UNDERFLOW flag is signaling on entry, it is reset on return by the processor, so that earlier exceptions are not lost. 465 J3/07-007 WORKING DRAFT 2006/01/05 466 2006/01/05 WORKING DRAFT J3/07-007 15 Interoperability with C 1 215.1 General 3Fortran provides a means of referencing procedures that are defined by means of the C programming 4language or procedures that can be described by C prototypes as defined in 6.7.5.3 of the C International 5Standard, even if they are not actually defined by means of C. Conversely, there is a means of specifying 6that a procedure defined by a Fortran subprogram can be referenced from a function defined by means 7of C. In addition, there is a means of declaring global variables that are associated with C variables that 8have external linkage as defined in 6.2.2 of the C International Standard. 9The ISO C BINDING module provides access to named constants that represent kind type parameters 10of data representations compatible with C types. Fortran also provides facilities for defining derived types (4.5) and enumerations (4.6) that correspond to C types. 11 1215.2 The ISO C BINDING intrinsic module 15.2.1 Summary of contents 13 14The processor shall provide the intrinsic module ISO C BINDING. This module shall make accessible 15the following entities: named constants with the names listed in the second column of Table 15.2 and 16the first column of Table 15.1, the procedures specified in 15.2.3, C PTR, C FUNPTR, C NULL PTR, 17and C NULL FUNPTR. A processor may provide other public entities in the ISO C BINDING intrinsic 18module in addition to those listed here. NOTE 15.1 To avoid potential name conflicts with program entities, it is recommended that a program use the ONLY option in any USE statement that references the ISO C BINDING intrinsic module. 15.2.2 Named constants and derived types in the module 19 20The entities listed in the second column of Table 15.2, shall be named constants of type default integer. 21The value of C INT shall be a valid value for an integer kind parameter on the processor. The values of C - 22SHORT, C LONG, C LONG LONG, C SIGNED CHAR, C SIZE T, C INT8 T, C INT16 T, C INT32 - 23T, C INT64 T, C INT LEAST8 T, C INT LEAST16 T, C INT LEAST32 T, C INT LEAST64 T, C - 24INT FAST8 T, C INT FAST16 T, C INT FAST32 T, C INT FAST64 T, C INTMAX T, and C INT- 25PTR T shall each be a valid value for an integer kind type parameter on the processor or shall be -1 26if the companion C processor defines the corresponding C type and there is no interoperating Fortran 27processor kind or -2 if the C processor does not define the corresponding C type. 28The values of C FLOAT, C DOUBLE, and C LONG DOUBLE shall each be a valid value for a real 29kind type parameter on the processor or shall be -1 if the C processor's type does not have a precision 30equal to the precision of any of the Fortran processor's real kinds, -2 if the C processor's type does not 31have a range equal to the range of any of the Fortran processor's real kinds, -3 if the C processor's type 32has neither the precision nor range of any of the Fortran processor's real kinds, and equal to -4 if there 33is no interoperating Fortran processor kind for other reasons. The values of C FLOAT COMPLEX, 34C DOUBLE COMPLEX, and C LONG DOUBLE COMPLEX shall be the same as those of C FLOAT, 467 J3/07-007 WORKING DRAFT 2006/01/05 1C DOUBLE, and C LONG DOUBLE, respectively. NOTE 15.2 If the C processor supports more than one variety of float, double or long double, the Fortran processor might find it helpful to select from among more than one ISO C BINDING module by a processor dependent means. 2The value of C BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1. 3The value of C INT BITS shall be a valid value for a bits kind type parameter of the processor. 4The values of C SHORT BITS, C LONG BITS, C LONG LONG BITS, C SIGNED CHAR BITS, C - 5INT8 T BITS, C INT16 T BITS, C INT32 T BITS, C INT64 T BITS, C INT LEAST8 T BITS, C - 6INT LEAST16 T BITS, C INT LEAST32 T BITS, C INT LEAST64 T BITS, C INT FAST8 T BITS, 7C INT FAST16 T BITS, C INT FAST32 T BITS, C INT FAST64 T BITS, C INTMAX T BITS, C - 8INTPTR T BITS, and C BOOL BITS shall each be a valid value for a bits kind type parameter on the 9processor, -1 if the companion C processor defines the corresponding C type and there is no interoper- 10ating Fortran processor kind, or -2 if the C processor does not define the corresponding C type. 11The value of C CHAR shall be a valid value for a character kind type parameter on the processor or 12shall be -1. The value of C CHAR is known as the C character kind. 13The following entities shall be named constants of type character with a length parameter of one. The 14kind parameter value shall be equal to the value of C CHAR unless C CHAR = -1, in which case the 15kind parameter value shall be the same as for default kind. The values of these constants are specified 16in Table 15.1. In the case that C CHAR = -1 the value is specified using C syntax. The semantics of 17these values are explained in 5.2.1 and 5.2.2 of the C International Standard. Table 15.1: Names of C characters with special semantics Value Name C definition C CHAR = -1 C CHAR = -1 C NULL CHAR null character CHAR(0) '\0' C ALERT alert ACHAR(7) '\a' C BACKSPACE backspace ACHAR(8) '\b' C FORM FEED form feed ACHAR(12) '\f' C NEW LINE new line ACHAR(10) '\n' C CARRIAGE RETURN carriage return ACHAR(13) '\r' C HORIZONTAL TAB horizontal tab ACHAR(9) '\t' C VERTICAL TAB vertical tab ACHAR(11) '\v' NOTE 15.3 The value of NEW LINE(C NEW LINE) is C NEW LINE (13.7.127). 18The entities C PTR and C FUNPTR are described in 15.3.3. 19The entity C NULL PTR shall be a named constant of type C PTR. The value of C NULL PTR shall 20be the same as the value NULL in C. The entity C NULL FUNPTR shall be a named constant of type 21C FUNPTR. The value of C NULL FUNPTR shall be that of a null pointer to a function in C. 2215.2.3 Procedures in the module 23In the detailed descriptions below, procedure names are generic and not specific. 24A C procedure argument is often defined in terms of a C address. The C LOC and C FUNLOC 468 2006/01/05 WORKING DRAFT J3/07-007 1functions are provided so that Fortran applications can determine the appropriate value to use with C 2facilities. The C ASSOCIATED function is provided so that Fortran programs can compare C addresses. 3The C F POINTER and C F PROCPOINTER subroutines provide a means of associating a Fortran 4pointer with the target of a C pointer. 15.2.3.1 C ASSOCIATED (C PTR 1 [, C PTR 2]) 5 6Description. Indicates the association status of C PTR 1 or indicates whether C PTR 1 and C PTR 2 7are associated with the same entity. 8Class. Inquiry function. 9Arguments. 10C PTR 1 shall be a scalar of type C PTR or C FUNPTR. C PTR 2 shall be a scalar of the same type as C PTR 1. (optional) 11 12Result Characteristics. Default logical scalar. 13Result Value. Case (i): If C PTR 2 is absent, the result is false if C PTR 1 is a C null pointer and true otherwise. 14 15Case (ii): If C PTR 2 is present, the result is false if C PTR 1 is a C null pointer. Otherwise, the 16 result is true if C PTR 1 compares equal to C PTR 2 in the sense of 6.3.2.3 and 6.5.9 of 17 the C International Standard, and false otherwise. NOTE 15.4 The following example illustrates the use of C LOC and C ASSOCIATED. USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_FLOAT, C_ASSOCIATED, C_LOC INTERFACE SUBROUTINE FOO(GAMMA) BIND(C) IMPORT C_PTR TYPE(C_PTR), VALUE :: GAMMA END SUBROUTINE FOO END INTERFACE REAL(C_FLOAT), TARGET, DIMENSION(100) :: ALPHA TYPE(C_PTR) :: BETA ... IF (.NOT. C_ASSOCIATED(BETA)) THEN BETA = C_LOC(ALPHA) ENDIF CALL FOO(BETA) 15.2.3.2 C F POINTER (CPTR, FPTR [, SHAPE]) 18 19Description. Associates a data pointer with the target of a C pointer and specifies its shape. 20Class. Subroutine. 21Arguments. 469 J3/07-007 WORKING DRAFT 2006/01/05 CPTR shall be a scalar of type C PTR. It is an INTENT(IN) argument. Its value shall be (1) the C address of an interoperable data entity, or (2) the result of a reference to C LOC with a noninteroperable argument. 1 The value of CPTR shall not be the C address of a Fortran variable that does not 2 have the TARGET attribute. FPTR shall be a pointer, and shall not be a co-indexed object. It is an INTENT(OUT) argument. If the value of CPTR is the C address of an interoperable data entity, FPTR shall be a data pointer with type and type parameters interoperable with the type of the entity. In this case, FPTR becomes pointer associated with the target of CPTR. If FPTR is an array, its shape is specified by SHAPE and each lower bound is 1. If the value of CPTR is the result of a reference to C LOC with a noninteroperable argument X, FPTR shall be a nonpolymorphic scalar pointer with the same type and type parameters as X. In this case, X or its target if it is a pointer shall not have been deallocated or have become undefined due to execution of a RETURN or END 3 statement since the reference. FPTR becomes pointer associated with X or its target. SHAPE shall be of type integer and rank one. It is an INTENT(IN) argument. SHAPE shall (optional) be present if and only if FPTR is an array; its size shall be equal to the rank of FPTR. 4 15.2.3.3 C F PROCPOINTER (CPTR, FPTR) 5 6Description. Associates a procedure pointer with the target of a C function pointer. 7Class. Subroutine. 8Arguments. CPTR shall be a scalar of type C FUNPTR. It is an INTENT(IN) argument. Its value shall 9 be the C address of a procedure that is interoperable. FPTR shall be a procedure pointer, and shall not be a co-indexed object. It is an IN- TENT(OUT) argument. The interface for FPTR shall be interoperable with the prototype that describes the target of CPTR. FPTR becomes pointer associated with 10 the target of CPTR. NOTE 15.5 The term "target" in the descriptions of C F POINTER and C F PROCPOINTER denotes the entity referenced by a C pointer, as described in 6.2.5 of the C International Standard. 15.2.3.4 C FUNLOC (X) 11 12Description. Returns the C address of the argument. 13Class. Inquiry function. 14Argument. X shall either be a procedure that is interoperable, or a procedure pointer associated with 15an interoperable procedure. It shall not be a co-indexed object. 16Result Characteristics. Scalar of type C FUNPTR. 17Result Value. 18 The result value is described using the result name CPTR. The result is determined as if C - 19 FUNPTR were a derived type containing an implicit-interface procedure pointer component PX 470 2006/01/05 WORKING DRAFT J3/07-007 1 and the pointer assignment CPTR%PX => X were executed. 2 The result is a value that can be used as an actual CPTR argument in a call to C F PROC- 3 POINTER where FPTR has attributes that would allow the pointer assignment FPTR => X. 4 Such a call to C F PROCPOINTER shall have the effect of the pointer assignment FPTR => 5 X. 15.2.3.5 C LOC (X) 6 7Description. Returns the C address of the argument. 8Class. Inquiry function. 9Argument. X shall have either the POINTER or TARGET attribute. It shall not be a co-indexed 10object. It shall either be a contiguous variable with interoperable type and type parameters, or be a 11scalar, nonpolymorphic variable with no length type parameters. If it is allocatable, it shall be allocated. 12If it is a pointer, it shall be associated. If it is an array, it shall have nonzero size. 13Result Characteristics. Scalar of type C PTR. 14Result Value. 15 The result value is described using the result name CPTR. 16If X is a scalar data entity, the result is determined as if C PTR were a derived type containing a scalar 17pointer component PX of the type and type parameters of X and the pointer assignment CPTR%PX 18=> X were executed. 19If X is an array data entity, the result is determined as if C PTR were a derived type containing a scalar 20pointer component PX of the type and type parameters of X and the pointer assignment of CPTR%PX 21to the first element of X were executed. 22 If X is a data entity that is interoperable or has interoperable type and type parameters, the 23 result is the value that the C processor returns as the result of applying the unary "&" operator (as defined in the C International Standard, 6.5.3.2) to the target of CPTR%PX. 24 25 The result is a value that can be used as an actual CPTR argument in a call to C F POINTER 26 where FPTR has attributes that would allow the pointer assignment FPTR => X. Such a call 27 to C F POINTER shall have the effect of the pointer assignment FPTR => X. NOTE 15.6 Where the actual argument is of noninteroperable type or type parameters, the result of C LOC provides an opaque "handle" for it. In an actual implementation, this handle might be the C address of the argument; however, portable C functions should treat it as a void (generic) C pointer that cannot be dereferenced (6.5.3.2 in the C International Standard). 15.2.3.6 C SIZEOF (X) 28 29Description. Returns the size of X in bytes. 30Class. Inquiry function. 31Argument. X shall be an interoperable data entity that is not an assumed-size array. Result Characteristics. Scalar integer of kind C SIZE T (15.3.2). 32 33Result Value. 471 J3/07-007 WORKING DRAFT 2006/01/05 1 If X is scalar, the result value is the value that the C processor returns as the result of applying 2 the sizeof operator (C International Standard, subclause 6.5.3.4) to an object of a type that 3 interoperates with the type and type parameters of X. 4If X is an array, the result value is the value that the C processor returns as the result of applying 5the sizeof operator to an object of a type that interoperates with the type and type parameters of X, 6multiplied by the number of elements in X. 15.3 Interoperability between Fortran and C entities 7 815.3.1 General 9Subclause 15.3 defines the conditions under which a Fortran entity is interoperable. If a Fortran entity is 10interoperable, an equivalent entity may be defined by means of C and the Fortran entity interoperates 11with the C entity. There does not have to be such an interoperating C entity. NOTE 15.7 A Fortran entity can be interoperable with more than one C entity. 15.3.2 Interoperability of intrinsic types 12 13Table 15.2 shows the interoperability between Fortran intrinsic types and C types. A Fortran intrinsic 14type with particular type parameter values is interoperable with a C type if the type and kind type 15parameter value are listed in the table on the same row as that C type; if the type is character, inter- 16operability also requires that the length type parameter be omitted or be specified by an initialization 17expression whose value is one. A combination of Fortran type and type parameters that is interoperable 18with a C type listed in the table is also interoperable with any unqualified C type that is compatible 19with the listed C type. 20The second column of the table refers to the named constants made accessible by the ISO C BINDING 21intrinsic module. If the value of any of these named constants is negative, there is no combination of 22Fortran type and type parameters interoperable with the C type shown in that row. 23A combination of intrinsic type and type parameters is interoperable if it is interoperable with a C 24type. Table 15.2: Interoperability between Fortran and C types Named constant from the ISO C BINDING module Fortran type C type (kind type parameter if value is positive) C INT int C SHORT short int C LONG long int C LONG LONG long long int signed char C SIGNED CHAR unsigned char C SIZE T size t C INT8 T int8 t C INT16 T int16 t C INT32 T int32 t C INT64 T int64 t 472 2006/01/05 WORKING DRAFT J3/07-007 Interoperability between Fortran and C types (cont.) Named constant from the ISO C BINDING module Fortran type C type (kind type parameter if value is positive) C INT LEAST8 T int least8 t C INT LEAST16 T int least16 t C INT LEAST32 T int least32 t INTEGER C INT LEAST64 T int least64 t C INT FAST8 T int fast8 t C INT FAST16 T int fast16 t C INT FAST32 T int fast32 t C INT FAST64 T int fast64 t C INTMAX T intmax t C INTPTR T intptr t C FLOAT float REAL C DOUBLE double C LONG DOUBLE long double C FLOAT COMPLEX float Complex COMPLEX C DOUBLE COMPLEX double Complex C LONG DOUBLE COMPLEX long double Complex LOGICAL C BOOL Bool C INT BITS unsigned int or int C SHORT BITS unsigned short or short C LONG BITS unsigned long or long unsigned long long C LONG LONG BITS long long unsigned char C SIGNED CHAR BITS signed char C INT8 T BITS uint8 t or int8 t C INT16 T BITS uint16 t or int16 t C INT32 T BITS uint32 t or int32 t C INT64 T BITS uint64 t or int64 t C INT LEAST8 T BITS uint least8 t int least8 t C INT LEAST16 T BITS uint least16 t int least16 t C INT LEAST32 T BITS uint least32 t int least32 t BITS C INT LEAST64 T BITS uint least64 t int least64 t C INT FAST8 T BITS uint fast8 t or int fast8 t C INT FAST16 T BITS uint fast16 t int fast16 t C INT FAST32 T BITS uint fast32 t int fast32 t 473 J3/07-007 WORKING DRAFT 2006/01/05 Interoperability between Fortran and C types (cont.) Named constant from the ISO C BINDING module Fortran type C type (kind type parameter if value is positive) C INT FAST64 T BITS uint fast64 t int fast64 t C INTMAX T BITS uintmax t or intmax t C INTPTR T BITS uintptr t or intptr t C BOOL BITS Bool CHARACTER C CHAR char The above mentioned C types are defined in the C International Standard, subclauses 6.2.5, 7.17, and 7.18.1. NOTE 15.8 For example, the type integer with a kind type parameter of C SHORT is interoperable with the C type short or any C type derived (via typedef) from short. NOTE 15.9 The C International Standard specifies that the representations for nonnegative signed integers are the same as the corresponding values of unsigned integers. A user can use the signed kinds of integers to interoperate with the unsigned types and all their qualified versions as well. This has the potentially surprising side effect that the C type unsigned char is interoperable with the type integer with a kind type parameter of C SIGNED CHAR. NOTE 15.10 If a variable of type bits is the actual argument corresponding to an unsigned integer parameter of a C function and is interoperable with that parameter, or the unsigned integer result of a C function is assigned to a variable of type bits that is interoperable with the function result, the I format can be used to output the correct form of the unsigned integer value. 15.3.3 Interoperability with C pointer types 1 2C PTR and C FUNPTR shall be derived types with only private components. No direct component of 3either of these types is allocatable or a pointer. C PTR is interoperable with any C object pointer type. 4C FUNPTR is interoperable with any C function pointer type. NOTE 15.11 This implies that a C processor is required to have the same representation method for all C object pointer types and the same representation method for all C function pointer types if the C processor is to be the target of interoperability of a Fortran processor. The C International Standard does not impose this requirement. NOTE 15.12 The function C LOC can be used to return a value of type C PTR that is the C address of an allocated allocatable variable. The function C FUNLOC can be used to return a value of type C FUNPTR that is the C address of a procedure. For C LOC and C FUNLOC the returned value is of an interoperable type and thus may be used in contexts where the procedure or allocatable variable is not directly allowed. For example, it could be passed as an actual argument to a C function. 474 2006/01/05 WORKING DRAFT J3/07-007 NOTE 15.12 (cont.) Similarly, type C FUNPTR or C PTR can be used in a dummy argument or structure component and can have a value that is the C address of a procedure or allocatable variable, even in contexts where a procedure or allocatable variable is not directly allowed. 15.3.4 Interoperability of derived types and C struct types 1 2A Fortran derived type is interoperable if it has the BIND attribute. C1501 (R430) A derived type with the BIND attribute shall not be a SEQUENCE type. 3 C1502 (R430) A derived type with the BIND attribute shall not have type parameters. 4 C1503 (R430) A derived type with the BIND attribute shall not have the EXTENDS attribute. 5 C1504 (R430) A derived type with the BIND attribute shall not have a type-bound-procedure-part. 6 7C1505 (R430) Each component of a derived type with the BIND attribute shall be a nonpointer, 8 nonallocatable data component with interoperable type and type parameters. NOTE 15.13 The syntax rules and their constraints require that a derived type that is interoperable have components that are all data objects that are interoperable. No component is permitted to be a procedure or allocatable, but a component of type C FUNPTR or C PTR may hold the C address of such an entity. 9A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran 10type specifies BIND(C) (4.5.2), the Fortran derived type and the C struct type have the same number 11of components, and the components of the Fortran derived type have types and type parameters that 12are interoperable with the types of the corresponding components of the struct type. A component of 13a Fortran derived type and a component of a C struct type correspond if they are declared in the same 14relative position in their respective type definitions. NOTE 15.14 The names of the corresponding components of the derived type and the C struct type need not be the same. 15There is no Fortran type that is interoperable with a C struct type that contains a bit field or that 16contains a flexible array member. There is no Fortran type that is interoperable with a C union type. NOTE 15.15 For example, the C type myctype, declared below, is interoperable with the Fortran type myftype, declared below. typedef struct { int m, n; float r; } myctype USE, INTRINSIC :: ISO_C_BINDING TYPE, BIND(C) :: MYFTYPE 475 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 15.15 (cont.) INTEGER(C_INT) :: I, J REAL(C_FLOAT) :: S END TYPE MYFTYPE The names of the types and the names of the components are not significant for the purposes of determining whether a Fortran derived type is interoperable with a C struct type. NOTE 15.16 The C International Standard requires the names and component names to be the same in order for the types to be compatible (C International Standard, subclause 6.2.7). This is similar to Fortran's rule describing when different derived type definitions describe the same sequence type. This rule was not extended to determine whether a Fortran derived type is interoperable with a C struct type because the case of identifiers is significant in C but not in Fortran. 15.3.5 Interoperability of scalar variables 1 2A scalar Fortran variable is interoperable if its type and type parameters are interoperable and it has 3neither the pointer nor the allocatable attribute. 4An interoperable scalar Fortran variable is interoperable with a scalar C entity if their types and type 5parameters are interoperable. 15.3.6 Interoperability of array variables 6 7An array Fortran variable is interoperable if its type and type parameters are interoperable and it is 8of explicit shape or assumed size. 9An explicit-shape or assumed-size array of rank r, with a shape of e1 ... er is interoperable with 10a C array if its size is nonzero and (1) either 11 (a) the array is assumed size, and the C array does not specify a size, or 12 13 (b) the array is an explicit shape array, and the extent of the last dimension (er) is the 14 same as the size of the C array, and (2) either 15 16 (a) r is equal to one, and an element of the array is interoperable with an element of the 17 C array, or 18 (b) r is greater than one, and an explicit-shape array with shape of e1 ... er -1 , 19 with the same type and type parameters as the original array, is interoperable with a 20 C array of a type equal to the element type of the original C array. NOTE 15.17 An element of a multi-dimensional C array is an array type, so a Fortran array of rank one is not interoperable with a multidimensional C array. NOTE 15.18 An allocatable or pointer array is never interoperable. Such an array does not meet the requirement of being explicit shape or assumed size. 476 2006/01/05 WORKING DRAFT J3/07-007 NOTE 15.19 For example, a Fortran array declared as INTEGER :: A(18, 3:7, *) is interoperable with a C array declared as int b[][5][18] NOTE 15.20 The C programming language defines null-terminated strings, which are actually arrays of the C type char that have a C null character in them to indicate the last valid element. A Fortran array of type character with a kind type parameter equal to C CHAR is interoperable with a C string. Fortran's rules of sequence association (12.5.2.12) permit a character scalar actual argument to be associated with a dummy argument array. This makes it possible to argument associate a Fortran character string with a C string. Note 15.24 has an example of interoperation between Fortran and C strings. 15.3.7 Interoperability of procedures and procedure interfaces 1 2A Fortran procedure is interoperable if it has the BIND attribute, that is, if its interface is specified 3with a proc-language-binding-spec. 4A Fortran procedure interface is interoperable with a C function prototype if (1) the interface has the BIND attribute, 5 (2) either 6 7 (a) the interface describes a function whose result variable is a scalar that is interoperable 8 with the result of the prototype or (b) the interface describes a subroutine and the prototype has a result type of void, 9 10 (3) the number of dummy arguments of the interface is equal to the number of formal parameters 11 of the prototype, 12 (4) any dummy argument with the VALUE attribute is interoperable with the corresponding 13 formal parameter of the prototype, 14 (5) any dummy argument without the VALUE attribute corresponds to a formal parameter 15 of the prototype that is of a pointer type, and the dummy argument is interoperable with 16 an entity of the referenced type (C International Standard, 6.2.5, 7.17, and 7.18.1) of the 17 formal parameter, and (6) the prototype does not have variable arguments as denoted by the ellipsis (...). 18 NOTE 15.21 The referenced type of a C pointer type is the C type of the object that the C pointer type points to. For example, the referenced type of the pointer type int * is int. NOTE 15.22 The C language allows specification of a C function that can take a variable number of arguments (C International Standard, 7.15). This part of ISO/IEC 1539does not provide a mechanism for Fortran procedures to interoperate with such C functions. 477 J3/07-007 WORKING DRAFT 2006/01/05 1A formal parameter of a C function prototype corresponds to a dummy argument of a Fortran interface if 2they are in the same relative positions in the C parameter list and the dummy argument list, respectively. NOTE 15.23 For example, a Fortran procedure interface described by INTERFACE FUNCTION FUNC(I, J, K, L, M) BIND(C) USE, INTRINSIC :: ISO_C_BINDING INTEGER(C_SHORT) :: FUNC INTEGER(C_INT), VALUE :: I REAL(C_DOUBLE) :: J INTEGER(C_INT) :: K, L(10) TYPE(C_PTR), VALUE :: M END FUNCTION FUNC END INTERFACE is interoperable with the C function prototype short func(int i, double *j, int *k, int l[10], void *m) A C pointer may correspond to a Fortran dummy argument of type C PTR with the VALUE attribute or to a Fortran scalar that does not have the VALUE attribute. In the above example, the C pointers j and k correspond to the Fortran scalars J and K, respectively, and the C pointer m corresponds to the Fortran dummy argument M of type C PTR. NOTE 15.24 The interoperability of Fortran procedure interfaces with C function prototypes is only one part of invocation of a C function from Fortran. There are four pieces to consider in such an invocation: the procedure reference, the Fortran procedure interface, the C function prototype, and the C function. Conversely, the invocation of a Fortran procedure from C involves the function reference, the C function prototype, the Fortran procedure interface, and the Fortran procedure. In order to determine whether a reference is allowed, it is necessary to consider all four pieces. For example, consider a C function that can be described by the C function prototype void copy(char in[], char out[]); Such a function may be invoked from Fortran as follows: USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_CHAR, C_NULL_CHAR INTERFACE SUBROUTINE COPY(IN, OUT) BIND(C) IMPORT C_CHAR CHARACTER(KIND=C_CHAR), DIMENSION(*) :: IN, OUT END SUBROUTINE COPY END INTERFACE CHARACTER(LEN=10, KIND=C_CHAR) :: & 478 2006/01/05 WORKING DRAFT J3/07-007 NOTE 15.24 (cont.) & DIGIT_STRING = C_CHAR_'123456789' // C_NULL_CHAR CHARACTER(KIND=C_CHAR) :: DIGIT_ARR(10) CALL COPY(DIGIT_STRING, DIGIT_ARR) PRINT '(1X, A1)', DIGIT_ARR(1:9) END The procedure reference has character string actual arguments. These correspond to character array dummy arguments in the procedure interface body as allowed by Fortran's rules of sequence association (12.5.2.12). Those array dummy arguments in the procedure interface are interoperable with the formal parameters of the C function prototype. The C function is not shown here, but is assumed to be compatible with the C function prototype. 15.4 Interoperation with C global variables 1 215.4.1 General 3A C variable with external linkage may interoperate with a common block or with a variable declared 4in the scope of a module. The common block or variable shall be specified to have the BIND attribute. 5At most one variable that is associated with a particular C variable with external linkage is permitted 6to be declared within a program. A variable shall not be initially defined by more than one processor. 7If a common block is specified in a BIND statement, it shall be specified in a BIND statement with 8the same binding label in each scoping unit in which it is declared. A C variable with external linkage 9interoperates with a common block that has been specified in a BIND statement 10 (1) if the C variable is of a struct type and the variables that are members of the common block 11 are interoperable with corresponding components of the struct type, or 12 (2) if the common block contains a single variable, and the variable is interoperable with the C 13 variable. 14There does not have to be an associated C entity for a Fortran entity with the BIND attribute. NOTE 15.25 The following are examples of the usage of the BIND attribute for variables and for a common block. The Fortran variables, C EXTERN and C2, interoperate with the C variables, c extern and myVariable, respectively. The Fortran common blocks, COM and SINGLE, interoperate with the C variables, com and single, respectively. MODULE LINK_TO_C_VARS USE, INTRINSIC :: ISO_C_BINDING INTEGER(C_INT), BIND(C) :: C_EXTERN INTEGER(C_LONG) :: C2 BIND(C, NAME='myVariable') :: C2 COMMON /COM/ R, S REAL(C_FLOAT) :: R, S, T BIND(C) :: /COM/, /SINGLE/ 479 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 15.25 (cont.) COMMON /SINGLE/ T END MODULE LINK_TO_C_VARS int c_extern; long myVariable; struct {float r, s;} com; float single; 15.4.2 Binding labels for common blocks and variables 1 2The binding label of a variable or common block is a value of type default character that specifies the 3name by which the variable or common block is known to the companion processor. 4If a variable or common block has the BIND attribute with the NAME= specifier and the value of its 5expression, after discarding leading and trailing blanks, has nonzero length, the variable or common 6block has this as its binding label. The case of letters in the binding label is significant. If a variable 7or common block has the BIND attribute specified without a NAME= specifier, the binding label is the 8same as the name of the entity using lower case letters. Otherwise, the variable or common block has 9no binding label. 10The binding label of a C variable with external linkage is the same as the name of the C variable. A 11Fortran variable or common block with the BIND attribute that has the same binding label as a C variable with external linkage is linkage associated (16.5.1.5) with that variable. 12 15.5 Interoperation with C functions 13 15.5.1 Definition and reference of interoperable procedures 14 15A procedure that is interoperable may be defined either by means other than Fortran or by means of a 16Fortran subprogram, but not both. 17If the procedure is defined by means other than Fortran, it shall (1) be describable by a C prototype that is interoperable with the interface, 18 (2) have external linkage as defined by 6.2.2 of the C International Standard, and 19 (3) have the same binding label as the interface. 20 21A reference to such a procedure causes the function described by the C prototype to be called as specified 22in the C International Standard. 23A reference in C to a procedure that has the BIND attribute, has the same binding label, and is defined 24by means of Fortran, causes the Fortran procedure to be invoked. 25A procedure defined by means of Fortran shall not invoke setjmp or longjmp (C International Standard, 267.13). If a procedure defined by means other than Fortran invokes setjmp or longjmp, that procedure 27shall not cause any procedure defined by means of Fortran to be invoked. A procedure defined by means of Fortran shall not be invoked as a signal handler (C International Standard, 7.14.1). 28 29If a procedure defined by means of Fortran and a procedure defined by means other than Fortran perform input/output operations on the same external file, the results are processor dependent (9.4.3). 30 15.5.2 Binding labels for procedures 480 2006/01/05 WORKING DRAFT J3/07-007 1 2The binding label of a procedure is a value of type default character that specifies the name by which 3a procedure with the BIND attribute is known to the companion processor. 4If a procedure has the BIND attribute with the NAME= specifier and the value of its expression, after 5discarding leading and trailing blanks, has nonzero length, the procedure has this as its binding label. 6The case of letters in the binding label is significant. If a procedure has the BIND attribute with 7no NAME= specifier, and the procedure is not a dummy procedure, internal procedure, or procedure 8pointer, then the binding label of the procedure is the same as the name of the procedure using lower 9case letters. Otherwise, the procedure has no binding label. 10C1506 A procedure defined in a submodule shall not have a binding label unless its interface is declared 11 in the ancestor module. 12The binding label for a C function with external linkage is the same as the C function name. NOTE 15.26 In the following sample, the binding label of C SUB is "c_sub", and the binding label of C FUNC is "C_funC". SUBROUTINE C_SUB() BIND(C) ... END SUBROUTINE C_SUB INTEGER(C_INT) FUNCTION C_FUNC() BIND(C, NAME="C_funC") USE, INTRINSIC :: ISO_C_BINDING ... END FUNCTION C_FUNC The C International Standard permits functions to have names that are not permitted as Fortran names; it also distinguishes between names that would be considered as the same name in Fortran. For example, a C name may begin with an underscore, and C names that differ in case are distinct names. The specification of a binding label allows a program to use a Fortran name to refer to a procedure defined by a companion processor. 15.5.3 Exceptions and IEEE arithmetic procedures 13 14A procedure defined by means other than Fortran shall not use signal (C International Standard, 7.14.1) 15to change the handling of any exception that is being handled by the Fortran processor. 16A procedure defined by means other than Fortran shall not alter the floating-point status (14.6) other 17than by setting an exception flag to signaling. 18The values of the floating-point exception flags on entry to a procedure defined by means other than 19Fortran are processor-dependent. 481 J3/07-007 WORKING DRAFT 2006/01/05 482 2006/01/05 WORKING DRAFT J3/07-007 16 Scope, association, and definition 1 216.1 Identifiers and entities 3Entities are identified by identifiers within a scope that is a program, a scoping unit, a construct, a 4single statement, or part of a statement. · A global identifier has a scope of a program (2.2.2); 5 · A local identifier has a scope of a scoping unit (2.2); 6 · An identifier of a construct entity has a scope of a construct (7.2.3, 7.2.4, 8.1); 7 · An identifier of a statement entity has a scope of a statement or part of a statement (3.3). 8 9An entity may be identified by (1) an image index (2.3.2), 10 (2) a name (3.2.1), 11 (3) a statement label (3.2.4), 12 (4) an external input/output unit number (9.4), 13 (5) an identifier of a pending data transfer operation (9.5.2.9, 9.6), 14 (6) a submodule identifier (11.2.3), 15 (7) a generic identifier (12.4.3.2), or 16 (8) a binding label (15.5.2, 15.4.2). 17 18By means of association, an entity may be referred to by the same identifier or a different identifier in 19a different scoping unit, or by a different identifier in the same scoping unit. 16.2 Scope of global identifiers 20 21Program units, common blocks, external procedures, entities with binding labels, and images are global 22entities of a program. The name of a non-submodule program unit, common block, or external pro- 23cedure is a global identifier and shall not be the same as the name of any other such global entity in 24the same program, except that an intrinsic module may have the same name as another program unit, 25common block, or external procedure in the same program. The submodule identifier of a submodule 26is a global identifier and shall not be the same as the submodule identifier of any other submodule. A 27binding label of an entity of the program is a global identifier and shall not be the same as the binding 28label of any other entity of the program; nor shall it be the same as the name of any other global entity 29of the program that is not an intrinsic module, ignoring differences in case. An entity of the program 30shall not be identified by more than one binding label. NOTE 16.1 The name of a global entity may be the same as a binding label that identifies the same global entity. 483 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 16.2 Of the various types of procedures, only external procedures have global names. An implemen- tation may wish to assign global names to other entities in the Fortran program such as internal procedures, intrinsic procedures, procedures implementing intrinsic operators, procedures imple- menting input/output operations, etc. If this is done, it is the responsibility of the processor to ensure that none of these names conflicts with any of the names of the external procedures, with other globally named entities in a standard-conforming program, or with each other. For example, this might be done by including in each such added name a character that is not allowed in a standard-conforming name or by using such a character to combine a local designation with the global name of the program unit in which it appears. NOTE 16.3 Submodule identifiers are global identifiers, but because they consist of a module name and a descendant submodule name, the name of a submodule can be the same as the name of another submodule so long as they do not have the same ancestor module. External input/output units and pending data transfer operations are global entities. 1 16.3 Scope of local identifiers 2 316.3.1 Classes of local identifiers 4Within a scoping unit, identifiers of entities in the classes 5 (1) named variables that are not statement or construct entities (16.4), named constants, named 6 constructs, statement functions, internal procedures, module procedures, dummy procedures, 7 intrinsic procedures, abstract interfaces, module procedure interfaces, generic interfaces, de- 8 rived types, namelist groups, external procedures accessed via USE, macros, and statement 9 labels, 10 (2) type parameters, components, and type-bound procedure bindings, in a separate class for 11 each type, and (3) argument keywords, in a separate class for each procedure with an explicit interface 12 13are local identifiers in that scoping unit. 14Within a scoping unit, a local identifier of an entity of class (1) shall not be the same as a global identifier 15used in that scoping unit unless the global identifier (1) is used only as the use-name of a rename in a USE statement, 16 (2) is a common block name (16.3.2), 17 (3) is an external procedure name that is also a generic name, or 18 (4) is an external function name and the scoping unit is its defining subprogram (16.3.3). 19 20Within a scoping unit, a local identifier of one class shall not be the same as another local identifier of 21the same class, except that a generic name may be the same as the name of a procedure as explained 22in 12.4.3.2 or the same as the name of a derived type (4.5.10), and a separate module procedure shall 23have the same name as its corresponding module procedure interface body (12.6.2.5). A local identifier 24of one class may be the same as a local identifier of another class. NOTE 16.4 An intrinsic procedure is inaccessible by its own name in a scoping unit that uses the same name as a local identifier of class (1) for a different entity. For example, in the program fragment 484 2006/01/05 WORKING DRAFT J3/07-007 NOTE 16.4 (cont.) SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN (X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name. 1A local identifier identifies an entity in a scoping unit and may be used to identify an entity in another 2scoping unit except in the following cases. 3 (1) The name that appears as a subroutine-name in a subroutine-stmt has limited use within 4 the scope established by the subroutine-stmt. It can be used to identify recursive references 5 of the subroutine or to identify a common block (the latter is possible only for internal and module subroutines). 6 7 (2) The name that appears as a function-name in a function-stmt has limited use within the 8 scope established by that function-stmt. It can be used to identify the result variable, to 9 identify recursive references of the function, or to identify a common block (the latter is possible only for internal and module functions). 10 11 (3) The name that appears as an entry-name in an entry-stmt has limited use within the scope 12 of the subprogram in which the entry-stmt appears. It can be used to identify the result 13 variable if the subprogram is a function, to identify recursive references, or to identify a common block (the latter is possible only if the entry-stmt is in a module subprogram). 14 1516.3.2 Local identifiers that are the same as common block names 16A name that identifies a common block in a scoping unit shall not be used to identify a constant or an 17intrinsic procedure in that scoping unit. If a local identifier is also the name of a common block, the 18appearance of that name in any context other than as a common block name in a COMMON or SAVE 19statement is an appearance of the local identifier. NOTE 16.5 An intrinsic procedure name may be a common block name in a scoping unit that does not reference the intrinsic procedure. 2016.3.3 Function results 21For each FUNCTION statement or ENTRY statement in a function subprogram, there is a result 22variable. If there is no RESULT clause, the result variable has the same name as the function being 23defined; otherwise, the result variable has the name specified in the RESULT clause. 16.3.4 Components, type parameters, and bindings 24 25A component name has the scope of its derived-type definition. Outside the type definition, it may 26appear only within a designator of a component of a structure of that type or as a component keyword 485 J3/07-007 WORKING DRAFT 2006/01/05 1in a structure constructor for that type. 2A type parameter name has the scope of its derived-type definition. Outside the derived-type definition, 3it may appear only as a type parameter keyword in a derived-type-spec for the type or as the type-param- 4name of a type-param-inquiry. 5The binding name (4.5.5) of a type-bound procedure has the scope of its derived-type definition. Outside 6of the derived-type definition, it may appear only as the binding-name in a procedure reference. 7A generic binding for which the generic-spec is not a generic-name has a scope that consists of all scoping 8units in which an entity of the type is accessible. 9A component name or binding name may appear only in scoping units in which it is accessible. 10The accessibility of components and bindings is specified in 4.5.4.7 and 4.5.5. 16.3.5 Argument keywords 11 12As an argument keyword, a dummy argument name in an internal procedure, module procedure, or 13an interface body has a scope of the scoping unit of the host of the procedure or interface body. It 14may appear only in a procedure reference for the procedure of which it is a dummy argument. If the 15procedure or interface body is accessible in another scoping unit by use association or host association 16(16.5.1.3, 16.5.1.4), the argument keyword is accessible for procedure references for that procedure in 17that scoping unit. 18A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping 19unit in which the reference to the procedure occurs. As an argument keyword, it may appear only in a 20procedure reference for the procedure of which it is a dummy argument. 2116.4 Statement and construct entities 22A variable that appears as a data-i-do-variable in a DATA statement or an ac-do-variable in an array 23constructor, as a dummy argument in a statement function statement, or as an index-name in a FORALL 24statement is a statement entity. A variable that appears as an index-name in a FORALL or DO 25CONCURRENT construct or as an associate-name in a SELECT TYPE or ASSOCIATE construct is 26a construct entity. A macro local variable is a construct entity. An entity that is declared in a BLOCK 27construct and is not accessed by use association is a construct entity. 28If a global or local identifier is the same as that of a construct entity, the identifier is interpreted within 29the construct as that of the construct entity. Elsewhere in the scoping unit, the identifier is interpreted 30as the global or local identifier. 31If a global or local identifier accessible in the scoping unit containing a statement is the same as the 32name of a statement entity in that statement, the name is interpreted within the scope of the statement 33entity as that of the statement entity. Elsewhere in the scoping unit, including parts of the statement 34outside the scope of the statement entity, the name is interpreted as the global or local identifier. 35If the name of a statement entity is the same as the name of a construct entity and the statement is 36within the scope of the construct entity, the name is interpreted within the scope of the statement entity 37as that of the statement entity. Elsewhere in the construct, including parts of the statement outside the 38scope of the statement entity, the name is interpreted as that of the construct entity. 39Except for a common block name or a scalar variable name, a global identifier or a local identifier of 40class (1) (16.3) in the scoping unit that contains a statement shall not be the name of a statement entity 41of that statement. Within the scope of a statement entity, another statement entity shall not have the 486 2006/01/05 WORKING DRAFT J3/07-007 1same name. 2The name of a data-i-do-variable in a DATA statement or an ac-do-variable in an array constructor 3has a scope of its data-implied-do or ac-implied-do. It is a scalar variable that has the type and type 4parameters that it would have if it were the name of a variable in the scoping unit that includes the 5DATA statement or array constructor, and this type shall be integer type; it has no other attributes. 6The appearance of a name as a data-i-do-variable of an implied DO in a DATA statement or an ac-do- 7variable in an array constructor is not an implicit declaration of a variable whose scope is the scoping 8unit that contains the statement. 9The name of a variable that appears as an index-name in a FORALL statement or FORALL or DO 10CONCURRENT construct has a scope of the statement or construct. It is a scalar variable. If type-spec 11appears in forall-header it has the specified type and type parameters; otherwise it that has the type and 12type parameters that it would have if it were the name of a variable in the scoping unit that includes the 13FORALL, and this type shall be integer type. It has no other attributes. The appearance of a name as 14an index-name in a FORALL statement or FORALL or DO CONCURRENT construct is not an implicit 15declaration of a variable whose scope is the scoping unit that contains the statement or construct. 16 The name of a variable that appears as a dummy argument in a statement function statement has a scope of the statement 17 in which it appears. It is a scalar that has the type and type parameters that it would have if it were the name of a variable 18 in the scoping unit that includes the statement function; it has no other attributes. 19Except for a common block name or a scalar variable name, a global identifier or a local identifier 20of class (1) (16.3) in the scoping unit containing a FORALL statement, FORALL construct, or DO 21CONCURRENT construct shall not be the same as any of its index-names. An index-name of a 22contained FORALL statement, FORALL construct, or DO CONCURRENT construct shall not be the 23same as an index-name of any of its containing FORALL or DO CONCURRENT constructs. 24The associate name of a SELECT TYPE construct has a separate scope for each block of the construct. 25Within each block, it has the declared type, dynamic type, type parameters, rank, and bounds specified 26in 8.1.9.2. 27The associate names of an ASSOCIATE construct have the scope of the block. They have the declared 28type, dynamic type, type parameters, rank, and bounds specified in 8.1.3.2. 29The macro local variables of a macro definition have the scope of the macro definition. 3016.5 Association 3116.5.1 Name association 3216.5.1.1 Forms of name association 33There are five forms of name association: argument association, use association, host association, 34linkage association, and construct association. Argument, use, and host association provide mechanisms 35by which entities known in one scoping unit may be accessed in another scoping unit. 3616.5.1.2 Argument association 37The rules governing argument association are given in Clause 12. As explained in 12.5, execution of a 38procedure reference establishes an association between an actual argument and its corresponding dummy argument. Argument association may be sequence association (12.5.2.12). 39 40The name of the dummy argument may be different from the name, if any, of its associated actual 41argument. The dummy argument name is the name by which the associated actual argument is known, 487 J3/07-007 WORKING DRAFT 2006/01/05 1and by which it may be accessed, in the referenced procedure. NOTE 16.6 An actual argument may be a nameless data entity, such as an expression that is not simply a variable or constant. 2Upon termination of execution of a procedure reference, all argument associations established by that 3reference are terminated. A dummy argument of that procedure may be associated with an entirely 4different actual argument in a subsequent invocation of the procedure. 516.5.1.3 Use association 6Use association is the association of names in different scoping units specified by a USE statement. The 7rules governing use association are given in 11.2.2. They allow for renaming of entities being accessed. 8Use association allows access in one scoping unit to entities defined in another scoping unit; it remains 9in effect throughout the execution of the program. 1016.5.1.4 Host association 11An internal subprogram, a module subprogram, a submodule subprogram, a module procedure interface 12body, or a derived-type definition has access to entities from its host via host association. An interface 13body that is not a module procedure interface body has access via host association to the named entities 14from its host that are made accessible by IMPORT statements in the interface body. The accessed 15entities are identified by the same identifier and have the same attributes as in the host, except that an 16accessed entity may have the VOLATILE or ASYNCHRONOUS attribute even if the host entity does 17not. The accessed entities are named data objects, derived types, abstract interfaces, module procedure 18interfaces, procedures, generic identifiers, macros, and namelist groups. 19If an entity that is accessed by use association has the same nongeneric name as a host entity, the host 20entity is inaccessible by that name. Within the scoping unit, a name that is declared to be an external 21procedure name by an external-stmt, procedure-declaration-stmt, or interface-body, or that appears as a 22module-name in a use-stmt is a global identifier; any entity of the host that has this as its nongeneric 23name is inaccessible by that name. A name that appears in the scoping unit as (1) a function-name in a stmt-function-stmt or in an entity-decl in a type-declaration-stmt, 24 25 (2) an object-name in an entity-decl in a type-declaration-stmt, in a pointer-stmt, in a save-stmt, 26 in an allocatable-stmt, or in a target-stmt, (3) a type-param-name in a derived-type-stmt, 27 (4) a named-constant in a named-constant-def in a parameter-stmt, 28 (5) an array-name in a dimension-stmt, 29 (6) a variable-name in a common-block-object in a common-stmt, 30 (7) a proc-pointer-name in a common-block-object in a common-stmt, 31 (8) the name of a variable that is wholly or partially initialized in a data-stmt, 32 (9) the name of an object that is wholly or partially equivalenced in an equivalence-stmt, 33 34 (10) a dummy-arg-name in a function-stmt, in a subroutine-stmt, in an entry-stmt, or in a stmt- 35 function-stmt, (11) a result-name in a function-stmt or in an entry-stmt, 36 (12) the name of an entity declared by an interface body, 37 (13) an intrinsic-procedure-name in an intrinsic-stmt, 38 (14) a namelist-group-name in a namelist-stmt, 39 (15) the name of a macro in a define-macro-stmt, 40 (16) a generic-name in a generic-spec in an interface-stmt, or 41 488 2006/01/05 WORKING DRAFT J3/07-007 (17) the name of a named construct 1 2is a local identifier in the scoping unit and any entity of the host that has this as its nongeneric name is 3inaccessible by that name by host association. If a scoping unit is the host of a derived-type definition 4or a subprogram that does not define a separate module procedure, the name of the derived type or of 5any procedure defined by the subprogram is a local identifier in the scoping unit; any entity of the host 6that has this as its nongeneric name is inaccessible by that name. Local identifiers of a subprogram are 7not accessible to its host. NOTE 16.7 A name that appears in an ASYNCHRONOUS or VOLATILE statement is not necessarily the name of a local variable. In an internal or module procedure, if a variable that is accessible via host association is specified in an ASYNCHRONOUS or VOLATILE statement, that host variable is given the ASYNCHRONOUS or VOLATILE attribute in the local scope. 8If a host entity is inaccessible only because a local variable with the same name is wholly or partially 9initialized in a DATA statement, the local variable shall not be referenced or defined prior to the DATA 10statement. 11If a derived-type name of a host is inaccessible, data entities of that type or subobjects of such data 12entities still can be accessible. NOTE 16.8 An interface body that is not a module procedure interface body accesses by host association only those entities made accessible by IMPORT statements. 13If an external or dummy procedure with an implicit interface is accessed via host association, then it 14shall have the EXTERNAL attribute in the host scoping unit; if it is invoked as a function in the inner 15scoping unit, its type and type parameters shall be established in the host scoping unit. The type and 16type parameters of a function with the EXTERNAL attribute are established in a scoping unit if that 17scoping unit explicitly declares them, invokes the function, accesses the function from a module, or 18accesses the function from its host where its type and type parameters are established. 19If an intrinsic procedure is accessed via host association, then it shall be established to be intrinsic in the 20host scoping unit. An intrinsic procedure is established to be intrinsic in a scoping unit if that scoping 21unit explicitly gives it the INTRINSIC attribute, invokes it as an intrinsic procedure, accesses it from a 22module, or accesses it from its host where it is established to be intrinsic. NOTE 16.9 A host subprogram and an internal subprogram may contain the same and differing use-associated entities, as illustrated in the following example. MODULE B; REAL BX, Q; INTEGER IX, JX; END MODULE B MODULE C; REAL CX; END MODULE C MODULE D; REAL DX, DY, DZ; END MODULE D MODULE E; REAL EX, EY, EZ; END MODULE E MODULE F; REAL FX; END MODULE F MODULE G; USE F; REAL GX; END MODULE G PROGRAM A USE B; USE C; USE D ... 489 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 16.9 (cont.) CONTAINS SUBROUTINE INNER_PROC (Q) USE C ! Not needed USE B, ONLY: BX ! Entities accessible are BX, IX, and JX ! if no other IX or JX ! is accessible to INNER_PROC ! Q is local to INNER_PROC, ! because Q is a dummy argument USE D, X => DX ! Entities accessible are DX, DY, and DZ ! X is local name for DX in INNER_PROC ! X and DX denote same entity if no other ! entity DX is local to INNER_PROC USE E, ONLY: EX ! EX is accessible in INNER_PROC, not in program A ! EY and EZ are not accessible in INNER_PROC ! or in program A USE G ! FX and GX are accessible in INNER_PROC ... END SUBROUTINE INNER_PROC END PROGRAM A Because program A contains the statement USE B all of the entities in module B, except for Q, are accessible in INNER PROC, even though INNER - PROC contains the statement USE B, ONLY: BX The USE statement with the ONLY option means that this particular statement brings in only the entity named, not that this is the only variable from the module accessible in this scoping unit. NOTE 16.10 For more examples of host association, see subclause C.12.1. 116.5.1.5 Linkage association 2Linkage association occurs between a module variable that has the BIND attribute and the C variable 3with which it interoperates, or between a Fortran common block and the C variable with which it interoperates (15.4). Such association remains in effect throughout the execution of the program. 4 516.5.1.6 Construct association 6Execution of a SELECT TYPE statement establishes an association between the selector and the asso- 7ciate name of the construct. Execution of an ASSOCIATE statement establishes an association between 8each selector and the corresponding associate name of the construct. 490 2006/01/05 WORKING DRAFT J3/07-007 1If the selector is allocatable, it shall be allocated; the associate name is associated with the data object 2and does not have the ALLOCATABLE attribute. 3If the selector has the POINTER attribute, it shall be associated; the associate name is associated with 4the target of the pointer and does not have the POINTER attribute. 5If the selector is a variable other than an array section having a vector subscript, the association is 6with the data object specified by the selector; otherwise, the association is with the value of the selector 7expression, which is evaluated prior to execution of the block. 8Each associate name remains associated with the corresponding selector throughout the execution of the 9executed block. Within the block, each selector is known by and may be accessed by the corresponding 10associate name. Upon termination of the construct, the association is terminated. NOTE 16.11 The association between the associate name and a data object is established prior to execution of the block and is not affected by subsequent changes to variables that were used in subscripts or substring ranges in the selector. 1116.5.2 Pointer association 1216.5.2.1 General 13Pointer association between a pointer and a target allows the target to be referenced by a reference to the 14pointer. At different times during the execution of a program, a pointer may be undefined, associated 15with different targets, or be disassociated. If a pointer is associated with a target, the definition status 16of the pointer is either defined or undefined, depending on the definition status of the target. If the 17pointer has deferred type parameters or shape, their values are assumed from the target. If the pointer 18is polymorphic, its dynamic type is the dynamic type of the target. 1916.5.2.2 Pointer association status 20A pointer may have a pointer association status of associated, disassociated, or undefined. Its 21association status may change during execution of a program. Unless a pointer is initialized (explicitly 22or by default), it has an initial association status of undefined. A pointer may be initialized to have an 23association status of disassociated or associated. NOTE 16.12 A pointer from a module program unit may be accessible in a subprogram via use association. Such pointers have a lifetime that is greater than targets that are declared in the subprogram, unless such targets are saved. Therefore, if such a pointer is associated with a local target, there is the possibility that when a procedure defined by the subprogram completes execution, the target will cease to exist, leaving the pointer "dangling". This part of ISO/IEC 1539 considers such pointers to have an undefined association status. They are neither associated nor disassociated. They shall not be used again in the program until their status has been reestablished. There is no requirement on a processor to be able to detect when a pointer target ceases to exist. 2416.5.2.2.1 Events that cause pointers to become associated 25A pointer becomes associated when any of the following events occur. 26 · The pointer is allocated (6.3.1) as the result of the successful execution of an ALLOCATE statement 27 referencing the pointer. 491 J3/07-007 WORKING DRAFT 2006/01/05 1 · The pointer is pointer-assigned to a target (7.2.2) that is associated or is specified with the TAR- 2 GET attribute and, if allocatable, is allocated. 3 · The pointer is a dummy argument and its corresponding actual argument is not a pointer. 4 · The pointer is an ultimate component of an object of a type for which default initialization is 5 specified for the component, and the corresponding initializer is an initialization target, and 6 ­ a procedure is invoked with this object as an actual argument corresponding to a nonpointer nonallocatable dummy argument with INTENT (OUT), 7 8 ­ a procedure with this object as an unsaved nonpointer nonallocatable local object that is not 9 accessed by use or host association is invoked, or 10 ­ this object is allocated. 1116.5.2.2.2 Events that cause pointers to become disassociated 12A pointer becomes disassociated when (1) the pointer is nullified (6.3.2), 13 (2) the pointer is deallocated (6.3.3), 14 (3) the pointer is pointer-assigned (7.2.2) to a disassociated pointer, or 15 16 (4) the pointer is an ultimate component of an object of a type for which default initialization 17 is specified for the component, the corresponding initializer is a reference to the intrinsic 18 function NULL, and 19 ·a procedure is invoked with this object as an actual argument corresponding to a nonpointer nonallocatable dummy argument with INTENT (OUT), 20 21 ·a procedure with this object as an unsaved nonpointer nonallocatable local object 22 that is not accessed by use or host association is invoked, or 23 ·this object is allocated. 2416.5.2.2.3 Events that cause the association status of pointers to become undefined 25The association status of a pointer becomes undefined when (1) the pointer is pointer-assigned to a target that has an undefined association status, 26 (2) the target of the pointer is deallocated other than through the pointer, 27 28 (3) the allocation transfer procedure (13.7.124) is executed, the pointer is associated with the 29 argument FROM, and an object without the target attribute associated with the argument 30 TO, 31 (4) execution of a RETURN or END statement causes the pointer's target to become undefined (item (3) of 16.6.6), 32 33 (5) termination of a BLOCK construct causes the pointer's target to become undefined (item (20) of 16.6.6), 34 35 (6) execution of the host instance of a procedure pointer is completed by execution of a RE- 36 TURN or END statement, 37 (7) a procedure is terminated by execution of a RETURN or END statement and the pointer 38 is declared or accessed in the subprogram that defines the procedure unless the pointer (a) has the SAVE attribute, 39 (b) is in blank common, 40 41 (c) is in a named common block that is declared in at least one other scoping unit that 42 is in execution, 492 2006/01/05 WORKING DRAFT J3/07-007 (d) is in the scoping unit of a module or submodule, 1 (e) is accessed by host association, or 2 (f) is the return value of a function declared to have the POINTER attribute, 3 4 (8) a BLOCK construct is terminated and the pointer is an unsaved local entity that is explicitly 5 declared in the BLOCK, 6 (9) the pointer is an ultimate component of an object, default initialization is not specified 7 for the component, and a procedure is invoked with this object as an actual argument corresponding to a dummy argument with INTENT(OUT), or 8 9 (10) a procedure is invoked with the pointer as an actual argument corresponding to a pointer dummy argument with INTENT(OUT). 10 1116.5.2.2.4 Other events that change the association status of pointers 12When a pointer becomes associated with another pointer by argument association, construct association, 13or host association, the effects on its association status are specified in 16.5.5. 14While two pointers are name associated, storage associated, or inheritance associated, if the association 15status of one pointer changes, the association status of the other changes accordingly. 1616.5.2.3 Pointer definition status 17The definition status of a pointer is that of its target. If a pointer is associated with a definable target, 18the definition status of the pointer may be defined or undefined according to the rules for a variable (16.6). 19 2016.5.2.4 Relationship between association status and definition status 21If the association status of a pointer is disassociated or undefined, the pointer shall not be referenced 22or deallocated. Whatever its association status, a pointer always may be nullified, allocated, or pointer 23assigned. A nullified pointer is disassociated. When a pointer is allocated, it becomes associated but 24undefined. When a pointer is pointer assigned, its association and definition status become those of the 25specified data-target or proc-target. 16.5.3 Storage association 26 2716.5.3.1 General 28Storage sequences are used to describe relationships that exist among variables, common blocks, and 29result variables. Storage association is the association of two or more data objects that occurs when 30two or more storage sequences share or are aligned with one or more storage units. 3116.5.3.2 Storage sequence 32A storage sequence is a sequence of storage units. The size of a storage sequence is the number 33of storage units in the storage sequence. A storage unit is a character storage unit, a numeric storage 34unit, a file storage unit(9.2.4), or an unspecified storage unit. The sizes of the numeric storage unit, the 35character storage unit and the file storage unit are the values of constants in the ISO FORTRAN ENV intrinsic module (13.8.2). 36 37In a storage association context 38 (1) a nonpointer scalar object of type default integer, default real, default logical, or default 39 bits occupies a single numeric storage unit, 493 J3/07-007 WORKING DRAFT 2006/01/05 1 (2) a nonpointer scalar object of type double precision real or default complex occupies two 2 contiguous numeric storage units, 3 (3) A nonpointer scalar object of type bits with a kind type parameter that is an integer 4 multiple, N, of the size of a numeric storage unit occupies N contiguous numeric storage 5 units. A nonpointer scalar object of type bits with a kind type parameter that is not an 6 integer multiple of the size of a numeric storage unit occupies an unspecified storage unit 7 that is different for each such kind value. 8 (4) a nonpointer scalar object of type default character and character length len occupies len 9 contiguous character storage units, 10 (5) a nonpointer scalar object of type character with the C character kind (15.2.2) and character 11 length len occupies len contiguous unspecified storage units, 12 (6) a nonpointer scalar object of sequence type with no type parameters occupies a sequence of 13 storage sequences corresponding to the sequence of its ultimate components, 14 (7) a nonpointer scalar object of any type not specified in items (1)-(6) occupies a single un- 15 specified storage unit that is different for each case and each set of type parameter values, and that is different from the unspecified storage units of item (5), 16 17 (8) a nonpointer array occupies a sequence of contiguous storage sequences, one for each array element, in array element order (6.2.2.1), and 18 19 (9) a pointer occupies a single unspecified storage unit that is different from that of any non- 20 pointer object and is different for each combination of type, type parameters, and rank. A 21 pointer that has the CONTIGUOUS attribute occupies a storage unit that is different from 22 that of a pointer that does not have the CONTIGUOUS attribute. 23A sequence of storage sequences forms a storage sequence. The order of the storage units in such a 24composite storage sequence is that of the individual storage units in each of the constituent storage 25sequences taken in succession, ignoring any zero-sized constituent sequences. Each common block has a storage sequence (5.7.2.2). 26 NOTE 16.13 For a BITS value, the order of its storage units is processor dependent. For example, BITS X(2) BITS(KIND(X)*2) Y, ZLE, ZBE ... X = TRANSFER (Y, X) ZBE = X(1)//X(2) ZLE = X(2)//X(1) ! ! On some processors Y==ZLE is true and on other processors Y==ZBE is true. NOTE 16.14 A nonpointer nonallocatable scalar BITS object with a KIND value that is not an integer multiple of the size of a numeric storage unit in bits might be stored in a memory region larger than the minimum required to represent the value. For example, if BITS KIND(x) has the value 13, the storage size for x might be 16 bits. Each element of a BITS array occupies the same size memory region as a scalar BITS object of the same kind. 2716.5.3.3 Association of storage sequences 494 2006/01/05 WORKING DRAFT J3/07-007 1Two nonzero-sized storage sequences s1 and s2 are storage associated if the ith storage unit of s1 is 2the same as the jth storage unit of s2. This causes the (i + k)th storage unit of s1 to be the same as 3the (j + k)th storage unit of s2, for each integer k such that 1 i + k size of s1 and 1 j + k 4size of s2. 5Storage association also is defined between two zero-sized storage sequences, and between a zero-sized 6storage sequence and a storage unit. A zero-sized storage sequence in a sequence of storage sequences is 7storage associated with its successor, if any. If the successor is another zero-sized storage sequence, the 8two sequences are storage associated. If the successor is a nonzero-sized storage sequence, the zero-sized 9sequence is storage associated with the first storage unit of the successor. Two storage units that are 10each storage associated with the same zero-sized storage sequence are the same storage unit. NOTE 16.15 Zero-sized objects may occur in a storage association context as the result of changing a parameter. For example, a program might contain the following declarations: INTEGER, PARAMETER :: PROBSIZE = 10 INTEGER, PARAMETER :: ARRAYSIZE = PROBSIZE * 100 REAL, DIMENSION (ARRAYSIZE) :: X INTEGER, DIMENSION (ARRAYSIZE) :: IX ... COMMON / EXAMPLE / A, B, C, X, Y, Z EQUIVALENCE (X, IX) ... If the first statement is subsequently changed to assign zero to PROBSIZE, the program still will conform to the standard. 1116.5.3.4 Association of scalar data objects 12Two scalar data objects are storage associated if their storage sequences are storage associated. Two 13scalar entities are totally associated if they have the same storage sequence. Two scalar entities are 14partially associated if they are associated without being totally associated. 15The definition status and value of a data object affects the definition status and value of any storage 16associated entity. An EQUIVALENCE statement, a COMMON statement, or an ENTRY statement 17can cause storage association of storage sequences. 18An EQUIVALENCE statement causes storage association of data objects only within one scoping unit, unless one of the equivalenced entities is also in a common block (5.7.1.2 and 5.7.2.2). 19 20COMMON statements cause data objects in one scoping unit to become storage associated with data 21objects in another scoping unit. 22A common block is permitted to contain a sequence of differing storage units. All scoping units that 23access named common blocks with the same name shall specify an identical sequence of storage units. 24Blank common blocks may be declared with differing sizes in different scoping units. For any two blank 25common blocks, the initial sequence of storage units of the longer blank common block shall be identical 26to the sequence of storage units of the shorter common block. If two blank common blocks are the same 27length, they shall have the same sequence of storage units. 28An ENTRY statement in a function subprogram causes storage association of the result variables. Partial association shall exist only between 495 J3/07-007 WORKING DRAFT 2006/01/05 1 (1) an object of default character or character sequence type and an object of default character 2 or character sequence type, or 3 (2) an object of default complex, double precision real, or numeric sequence type and an object 4 of default integer, default real, default logical, double precision real, default complex, or 5 numeric sequence type. 6For noncharacter entities, partial association may occur only through the use of COMMON, EQUIV- 7ALENCE, or ENTRY statements. For character entities, partial association may occur only through 8argument association or the use of COMMON or EQUIVALENCE statements. NOTE 16.16 In the example: REAL A (4), B COMPLEX C (2) DOUBLE PRECISION D EQUIVALENCE (C (2), A (2), B), (A, D) the third storage unit of C, the second storage unit of A, the storage unit of B, and the second storage unit of D are specified as the same. The storage sequences may be illustrated as: Storage unit 1 2 3 4 5 ----C(1)----|---C(2)---- A(1) A(2) A(3) A(4) --B-- ------D------ A (2) and B are totally associated. The following are partially associated: A (1) and C (1), A (2) and C (2), A (3) and C (2), B and C (2), A (1) and D, A (2) and D, B and D, C (1) and D, and C (2) and D. Although C (1) and C (2) are each storage associated with D, C (1) and C (2) are not storage associated with each other. 9Partial association of character entities occurs when some, but not all, of the storage units of the entities 10are the same. NOTE 16.17 In the example: CHARACTER A*4, B*4, C*3 EQUIVALENCE (A (2:3), B, C) A, B, and C are partially associated. 11A storage unit shall not be explicitly initialized more than once in a program. Explicit initialization 12overrides default initialization, and default initialization for an object of derived type overrides default 13initialization for a component of the object (4.5.2). Default initialization may be specified for a storage 14unit that is storage associated provided the objects supplying the default initialization are of the same 15type and type parameters, and supply the same value for the storage unit. 1616.5.4 Inheritance association 496 2006/01/05 WORKING DRAFT J3/07-007 1Inheritance association occurs between components of the parent component and components inherited 2by type extension into an extended type (4.5.7.2). This association is persistent; it is not affected by the 3accessibility of the inherited components. 16.5.5 Establishing associations 4 5When an association is established between two entities by argument association, host association, 6or construct association, certain characteristics of the associating entity become those of the pre- 7existing entity. 8For argument association, if the dummy argument is not a pointer and the corresponding actual argument 9is a pointer, the pre-existing entity is the target of that pointer. Otherwise the pre-existing entity is the 10corresponding actual argument. In either case, the associating entity is the dummy argument. 11For host association, the associating entity is the entity in the host scoping unit and the pre-existing 12entity is the entity in the contained scoping unit. If an internal procedure is invoked via a dummy 13procedure or procedure pointer, the pre-existing entity that participates in the association is the one 14from the host instance. Otherwise, if the host scoping unit is a recursive procedure, the pre-existing entity 15that participates in the association is the one from the innermost subprogram instance that invoked, 16directly or indirectly, the contained procedure. 17For construct association, the associating entity is identified by the associate name and the pre-existing 18entity is the selector. 19When an association is established by argument association, host association, or construct association, 20the following applies. 21 · If the associating entity has the POINTER attribute, its pointer association status becomes the 22 same as that of the pre-existing entity. If the pre-existing entity has a pointer association status of 23 associated, the associating entity becomes pointer associated with the same target and, if they are 24 arrays, the bounds of the associating entity become the same as those of the pre-existing entity. 25 · If the associating entity has the ALLOCATABLE attribute, its allocation status becomes the same 26 as that of the pre-existing entity. If the pre-existing entity is allocated, the bounds (if it is an array), 27 values of deferred type parameters, definition status, and value (if it is defined) become the same 28 as those of the pre-existing entity. If the associating entity is polymorphic and the pre-existing 29 entity is allocated, the dynamic type of the associating entity becomes the same as that of the 30 pre-existing entity. 31 · If the associating entity is neither a pointer nor allocatable, its definition status, value (if it is 32 defined), and dynamic type (if it is polymorphic) become the same as those of the pre-existing 33 entity. If the entities are arrays and the association is not argument association, the bounds of the 34 associating entity become the same as those of the pre-existing entity. 3516.6 Definition and undefinition of variables 16.6.1 Definition of objects and subobjects 36 37A variable may be defined or may be undefined and its definition status may change during execution of 38a program. An action that causes a variable to become undefined does not imply that the variable was 39previously defined. An action that causes a variable to become defined does not imply that the variable 40was previously undefined. 497 J3/07-007 WORKING DRAFT 2006/01/05 1Arrays, including sections, and variables of derived, character, or complex type are objects that consist of 2zero or more subobjects. Associations may be established between variables and subobjects and between 3subobjects of different variables. These subobjects may become defined or undefined. 4An array is defined if and only if all of its elements are defined. 5A derived-type scalar object is defined if and only if all of its nonpointer components are defined. 6A complex or character scalar object is defined if and only if all of its subobjects are defined. If an object is undefined, at least one (but not necessarily all) of its subobjects are undefined. 7 16.6.2 Variables that are always defined 8 9Zero-sized arrays and zero-length strings are always defined. 16.6.3 Variables that are initially defined 10 11The following variables are initially defined: (1) variables specified to have initial values by DATA statements; 12 (2) variables specified to have initial values by type declaration statements; 13 14 (3) nonpointer default-initialized subcomponents of variables that do not have the ALLOCAT- 15 ABLE or POINTER attribute, and are saved, local variables of a main program, or declared 16 in a MODULE or BLOCK DATA scoping unit; (4) pointers specified to be initially associated with a variable that is initially defined; 17 (5) variables that are always defined; 18 (6) variables with the BIND attribute that are initialized by means other than Fortran. 19 NOTE 16.18 Fortran code: module mod integer, bind(c,name="blivet") :: foo end module mod C code: int blivet = 123; In the above example, the Fortran variable foo is initially defined to have the value 123 by means other than Fortran. 16.6.4 Variables that are initially undefined 20 21All other variables are initially undefined. 2216.6.5 Events that cause variables to become defined 23Variables become defined by the following events. 24 (1) Execution of an intrinsic assignment statement other than a masked array assignment or 25 FORALL assignment statement causes the variable that precedes the equals to become 26 defined. 498 2006/01/05 WORKING DRAFT J3/07-007 1 (2) Execution of a masked array assignment or FORALL assignment statement might cause some or all of the array elements in the assignment statement to become defined (7.2.3). 2 3 (3) As execution of an input statement proceeds, each variable that is assigned a value from 4 the input file becomes defined at the time that data is transferred to it. (See (4) in 16.6.6.) 5 Execution of a WRITE statement whose unit specifier identifies an internal file causes each 6 record that is written to become defined. (4) Execution of a DO statement causes the DO variable, if any, to become defined. 7 8 (5) Beginning of execution of the action specified by an io-implied-do in a synchronous in- put/output statement causes the do-variable to become defined. 9 10 (6) A reference to a procedure causes the entire dummy argument data object to become defined 11 if the dummy argument does not have INTENT(OUT) and the entire corresponding actual 12 argument is defined. 13 A reference to a procedure causes a subobject of a dummy argument to become defined if 14 the dummy argument does not have INTENT(OUT) and the corresponding subobject of 15 the corresponding actual argument is defined. 16 (7) Execution of an input/output statement containing an IOSTAT= specifier causes the spec- 17 ified integer variable to become defined. 18 (8) Execution of a synchronous READ statement containing a SIZE= specifier causes the spec- 19 ified integer variable to become defined. 20 (9) Execution of a wait operation corresponding to an asynchronous input statement containing 21 a SIZE= specifier causes the specified integer variable to become defined. 22 (10) Execution of an INQUIRE statement causes any variable that is assigned a value during the 23 execution of the statement to become defined if no error condition exists. 24 (11) If an error, end-of-file, or end-of-record condition occurs during execution of an input/output 25 statement that has an IOMSG= specifier, the iomsg-variable becomes defined. 26 (12) When a character storage unit becomes defined, all associated character storage units be- 27 come defined. 28 When a numeric storage unit becomes defined, all associated numeric storage units of the 29 same type become defined. When an entity of double precision real type becomes defined, 30 all totally associated entities of double precision real type become defined. 31 When an unspecified storage unit becomes defined, all associated unspecified storage units 32 become defined. 33 (13) When a default complex entity becomes defined, all partially associated default real entities 34 become defined. 35 (14) When both parts of a default complex entity become defined as a result of partially associ- 36 ated default real or default complex entities becoming defined, the default complex entity 37 becomes defined. 38 (15) When all components of a structure of a numeric sequence type or character sequence type 39 become defined as a result of partially associated objects becoming defined, the structure 40 becomes defined. 41 (16) When a dummy argument of type bits that is associated with an effective argument of a 42 different type becomes defined, the effective argument becomes defined. 499 J3/07-007 WORKING DRAFT 2006/01/05 J3 internal note Unresolved Technical Issue 076 We still have a "bits define too much" situation. I will draw people's attention to one of the primary goals of the Fortran standard, which is to promote portability. This runs directly counter to that goal. Since bits used in this manner are inherently nonportable, we need to limit them, not throw out the portability baby. Furthermore, "invalid values", i.e. values that don't act consistently, or indeed crash the program, are not limited to LOGICALs. We really ought not to go further than C here. C explicitly acknowledges that there may be "trap representations"; trap in this context means don't fall into it! We ought not to attempt to require implementations not to have trap representations!!!!! Many processors in the past have had trap representations for REALs; even it the recent past it has been common, e.g. on processors without full IEEE, representations of unsupported IEEE values would just trap (that's why we put IEEE OTHER VALUE into IEEE CLASS). There have also been processors (in the not-too-distant past) which have had trap representations for INTEGERs. And even now, many processors have LOGICAL representations that don't act like values. Bit-twiddling the guts of a Fortran data type is inherently processor-dependent. We should have the guts to say that. Furthermore, it provides maximum traction to the feature, with the smallest effort in standards- writing. I.e. replace the above with (16)When a dummy argument of type bits that is associated with an effective argument of a different type becomes defined, whether the effective argument becomes defined is processor dependent. 1 (17) Execution of a statement with a STAT= specifier causes the variable specified by the STAT= 2 specifier to become defined. 3 (18) If an error condition occurs during execution of a statement that has an ERRMSG= specifier, 4 the variable specified by the ERRMSG= specifier becomes defined. (19) Allocation of a zero-sized array causes the array to become defined. 5 6 (20) Allocation of an object that has a nonpointer default-initialized subcomponent causes that 7 subcomponent to become defined. 8 (21) Invocation of a procedure causes any automatic object of zero size in that procedure to 9 become defined. 10 (22) Execution of a pointer assignment statement that associates a pointer with a target that is 11 defined causes the pointer to become defined. 12 (23) Invocation of a procedure that contains an unsaved nonpointer nonallocatable local variable 13 causes all nonpointer default-initialized subcomponents of the object to become defined. 14 (24) Invocation of a procedure that has a nonpointer nonallocatable INTENT (OUT) dummy 15 argument causes all nonpointer default-initialized subcomponents of the dummy argument 16 to become defined. 17 (25) Invocation of a nonpointer function of a derived type causes all nonpointer default-initialized 18 subcomponents of the function result to become defined. 19 (26) In a FORALL or DO CONCURRENT construct, the index-name becomes defined when 20 the index-name value set is evaluated. 21 (27) An object with the VOLATILE attribute that is changed by a means not specified by the program becomes defined (see 5.3.18). 22 23 (28) Execution of the BLOCK statement of a BLOCK construct that has an unsaved nonpointer 24 nonallocatable local variable causes all nonpointer default-initialized subcomponents of the 500 2006/01/05 WORKING DRAFT J3/07-007 1 variable to become defined. 2 (29) Execution of an OPEN statement containing a NEWUNIT= specifier causes the specified 3 integer variable to become defined. 416.6.6 Events that cause variables to become undefined 5Variables become undefined by the following events. 6 (1) When a variable of a given type becomes defined, all associated variables of different type 7 become undefined. However, when a variable of type default real is partially associated with 8 a variable of type default complex, the complex variable does not become undefined when 9 the real variable becomes defined and the real variable does not become undefined when 10 the complex variable becomes defined. When a variable of type default complex is partially 11 associated with another variable of type default complex, definition of one does not cause 12 the other to become undefined. When a dummy argument of type bits is associated with 13 an actual argument of a different type, definition of the dummy argument does not cause 14 the actual argument to become undefined. 15 (2) If the evaluation of a function would cause a variable to become defined and if a reference 16 to the function appears in an expression in which the value of the function is not needed to 17 determine the value of the expression, the variable becomes undefined when the expression 18 is evaluated. (3) When execution of an instance of a subprogram completes, 19 (a) its unsaved local variables become undefined, and 20 21 (b) unsaved variables in a named common block that appears in the subprogram become 22 undefined if they have been defined or redefined, unless another active scoping unit 23 is referencing the common block or the common block is declared in a module or 24 submodule. 25 (4) When an error condition or end-of-file condition occurs during execution of an input state- 26 ment, all of the variables specified by the input list or namelist group of the statement 27 become undefined. 28 (5) When an error condition, end-of-file condition, or end-of-record condition occurs during 29 execution of an input/output statement and the statement contains any io-implied-dos, all of the do-variables in the statement become undefined (9.10). 30 31 (6) Execution of a direct access input statement that specifies a record that has not been written 32 previously causes all of the variables specified by the input list of the statement to become 33 undefined. 34 (7) Execution of an INQUIRE statement might cause the NAME=, RECL=, and NEXTREC= variables to become undefined (9.9). 35 36 (8) When a character storage unit becomes undefined, all associated character storage units 37 become undefined. 38 When a numeric storage unit becomes undefined, all associated numeric storage units be- 39 come undefined unless the undefinition is a result of defining an associated numeric storage unit of different type (see (1) above). 40 41 When an entity of double precision real type becomes undefined, all totally associated 42 entities of double precision real type become undefined. 43 When an unspecified storage unit becomes undefined, all associated unspecified storage units 44 become undefined. (9) When an allocatable entity is deallocated, it becomes undefined. 45 46 (10) When the allocation transfer procedure (13.5.17) causes the allocation status of an allocat- 47 able entity to become unallocated, the entity becomes undefined. 501 J3/07-007 WORKING DRAFT 2006/01/05 1 (11) Successful execution of an ALLOCATE statement for a nonzero-sized object that has a sub- 2 component for which default initialization has not been specified causes the subcomponent 3 to become undefined. 4 (12) Execution of an INQUIRE statement causes all inquiry specifier variables to become un- 5 defined if an error condition exists, except for any variable in an IOSTAT= or IOMSG= 6 specifier. (13) When a procedure is invoked 7 8 (a) an optional dummy argument that is not associated with an actual argument becomes 9 undefined, 10 (b) a dummy argument with INTENT (OUT) becomes undefined except for any non- 11 pointer default-initialized subcomponents of the argument, 12 (c) an actual argument associated with a dummy argument with INTENT (OUT) be- 13 comes undefined except for any nonpointer default-initialized subcomponents of the 14 argument, 15 (d) a subobject of a dummy argument that does not have INTENT (OUT) becomes 16 undefined if the corresponding subobject of the actual argument is undefined, and 17 (e) the result variable of a function becomes undefined except for any of its nonpointer 18 default-initialized subcomponents. 19 (14) When the association status of a pointer becomes undefined or disassociated (16.5.2.2.2- 16.5.2.2.3), the pointer becomes undefined. 20 21 (15) When the execution of a FORALL or DO CONCURRENT construct completes, the index- 22 names become undefined. 23 (16) When a DO CONCURRENT construct terminates, a variable that is defined or becomes 24 undefined during more than one iteration of the construct becomes undefined. 25 (17) Execution of an asynchronous READ statement causes all of the variables specified by the 26 input list or SIZE= specifier to become undefined. Execution of an asynchronous namelist 27 READ statement causes any variable in the namelist group to become undefined if that 28 variable will subsequently be defined during the execution of the READ statement or the 29 corresponding WAIT operation. 30 (18) When execution of a RETURN or END statement causes a variable to become undefined, 31 any variable of type C PTR becomes undefined if its value is the C address of any part of 32 the variable that becomes undefined. 33 (19) When a variable with the TARGET attribute is deallocated, any variable of type C PTR 34 becomes undefined if its value is the C address of any part of the variable that is deallocated. J3 internal note Unresolved Technical Issue 192 C PTR and C FUNPTR undefined events defective. The above events are defective, in that they omit events which cause pointers to go undefined (16.5.2.2.3). Some of these events are new to F2008 (hello BLOCK), at least one existed in F2003 (hello MOVE ALLOC). BTW, the wording above ("any part of") is unnecessary and ought to be deleted. It would be nice to reword this in a future-proof way, e.g. replace both the existing items (and the new item about C FUNPTR) with (18)When an event occurs that would cause the association status of a pointer associated with the target of a C PTR or C FUNPTR variable to become undefined (16.5.2.2.3), the variable of type C PTR or C FUNPTR becomes undefined. The above suggestion has some potential ambiguities so might need a bit more care in wording. If that's too hard, just re-list all the relevant events from 16.5.2.2.3 here. 502 2006/01/05 WORKING DRAFT J3/07-007 (20) When a BLOCK construct terminates, its unsaved local variables become undefined. 1 2 (21) When execution of the host instance of the target of a variable of type C FUNPTR is 3 completed by execution of a RETURN or END statement, the variable becomes undefined. NOTE 16.19 Execution of a defined assignment statement may leave all or part of the variable undefined. 416.6.7 Variable definition context 5Some variables are prohibited from appearing in a syntactic context that would imply definition or 6undefinition of the variable (5.3.9, 5.3.14, 12.7). The following are the contexts in which the appearance 7of a variable implies such definition or undefinition of the variable: 8 · the variable of an assignment-stmt; 9 · a pointer-object in a nullify-stmt; 10 · a data-pointer-object or proc-pointer-object in a pointer-assignment-stmt; 11 · a do-variable in a do-stmt or io-implied-do; 12 · an input-item in a read-stmt; 13 · a variable-name in a namelist-stmt if the namelist-group-name appears in a NML= specifier in a 14 read-stmt; 15 · an internal-file-variable in a write-stmt; · an IOSTAT=, SIZE=, or IOMSG= specifier in an input/output statement; 16 17 · a specifier in an INQUIRE statement other than FILE=, ID=, and UNIT=; 18 · a NEWUNIT= specifier in an OPEN statement; 19 · a READY= specifier in a QUERY statement; 20 · a stat-variable, allocate-object, or errmsg-variable; 21 · an actual argument in a reference to a procedure with an explicit interface if the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute; 22 23 · a variable that is the selector in a SELECT TYPE or ASSOCIATE construct if the associate name 24 of that construct appears in a variable definition context. 2516.6.8 Pointer association context 26Some pointers are prohibited from appearing in a syntactic context that would imply alteration of the 27pointer association status (16.5.2.2,5.3.9, 5.3.14). The following are the contexts in which the appearance 28of a pointer implies such alteration of its pointer association status: 29 · a pointer-object in a nullify-stmt; 30 · a data-pointer-object or proc-pointer-object in a pointer-assignment-stmt; 31 · an allocate-object in an allocate-stmt or deallocate-stmt; 503 J3/07-007 WORKING DRAFT 2006/01/05 1 · an actual argument in a reference to a procedure if the associated dummy argument is a pointer with the INTENT (OUT) or INTENT (INOUT) attribute. 2 3If a reference to a function appears in a variable definition context the result of the function reference 4shall be a pointer that is associated with a definable target. That target is the variable that becomes 5defined or undefined. 504 2006/01/05 WORKING DRAFT J3/07-007 1 Annex A (Informative) 2 Glossary of technical terms 3 4The following is a list of the principal technical terms used in this part of ISO/IEC 1539 and their 5definitions. A reference in parentheses immediately after a term is to the clause or subclause where the 6term is defined or explained. The wording of a definition here is not necessarily the same as its normative 7definition. 8abstract type (4.5.7) : A type that has the ABSTRACT attribute. A nonpolymorphic object shall not 9be declared to be of abstract type. A polymorphic object shall not be constructed or allocated to have 10a dynamic abstract type. 11actual argument (12, 12.5.2) : An expression, a variable, a procedure, or an alternate return specifier that 12is specified in a procedure reference. 13allocatable variable (5.3.3) : A variable having the ALLOCATABLE attribute. It may be referenced 14or defined only when it is allocated. If it is an array, it has a shape only when it is allocated. It may be 15a named variable or a structure component. argument (12) : An actual argument or a dummy argument. 16 17argument association (16.5.1.2) : The relationship between an actual argument and a dummy argu- 18ment during the execution of a procedure reference. 19array (2.4.5) : A set of scalar data, all of the same type and type parameters, whose individual elements 20are arranged in a rectangular pattern. It may be a named array, an array section, a structure component, 21a function value, or an expression. Its rank is at least one. Note that in Fortran 77, arrays were always 22named and never constants. 23array element (2.4.5, 6.2.2) : One of the scalar data that make up an array that is either named or is 24a structure component. array pointer (5.3.7.4) : A pointer to an array. 25 array section (2.4.5, 6.2.2.2) : A subobject that is an array and is not a structure component. 26 27assignment statement (7.2.1.1) : A statement that evaluates an expression and assigns its value to a 28variable. 29associate name (8.1.3.1) : The name of the construct entity with which a selector of a SELECT TYPE 30or ASSOCIATE construct is associated within the construct. 31association (16.5) : Name association, pointer association, storage association, or inheritance associa- 32tion. 33assumed-shape array (5.3.7.3) : A nonpointer dummy array that takes its shape from the associated 34actual argument. 35assumed-size array (5.3.7.5) : A dummy array whose size is assumed from the associated actual 36argument. Its last upper bound is specified by an asterisk. attribute (5) : A property of an entity that determines its uses. 37 505 J3/07-007 WORKING DRAFT 2006/01/05 1automatic data object (5.2) : A data object that is a local entity of a subprogram, that is not a dummy 2argument, and that has a length type parameter or array bound that is specified by an expression that 3is not an initialization expression. base type (4.5.7) : An extensible type that is not an extension of another type. 4 5belong (8.1.7.5.3, 8.1.7.5.4) : If an EXIT or a CYCLE statement contains a construct name, the 6statement belongs to the construct using that name. Otherwise, it belongs to the innermost DO 7construct in which it appears. 8binding label (15.5.2, 15.4.2) : A value of type default character that uniquely identifies how a variable, 9common block, subroutine, or function is known to a companion processor. 10bits compatible (12.5.2.4) : An entity is bits compatible with another entity if and only if one is of 11type bits, the other is of type bits, integer, real, complex, or logical, and scalar entities of these types 12have the same size expressed in bits. 13block (8.1) : A sequence of executable constructs embedded in another executable construct, bounded 14by statements that are particular to the construct, and treated as an integral unit. 15block data program unit (11.3) : A program unit that provides initial values for data objects in 16named common blocks. 17bounds (5.3.7.2) : For a named array, the limits within which the values of the subscripts of its array 18elements shall lie. 19character length parameter (2.4.1.1) : The type parameter that specifies the number of characters 20for an entity of type character. 21character storage unit (16.5.3.2) : The unit of storage for holding a scalar that is not a pointer and 22is of type default character and character length one. character string (4.4.5) : A sequence of characters numbered from left to right 1, 2, 3, ... 23 characteristics (12.3) : 24 25Of a procedure, its classification as a function or subroutine, whether it is pure, whether it is elemental, 26whether it has the BIND attribute, the value of its binding label, the characteristics of its dummy 27arguments, and the characteristics of its function result if it is a function. 28Of a dummy argument, whether it is a data object, is a procedure, is a procedure pointer, is an asterisk 29 (alternate return indicator), or has the OPTIONAL attribute. 30Of a dummy data object, its type, type parameters, shape, the exact dependence of an array bound 31or type parameter on other entities, intent, whether it is optional, whether it is a pointer or a target, 32whether it is allocatable, whether it has the VALUE, ASYNCHRONOUS, or VOLATILE attributes, 33whether it is polymorphic, and whether the shape, size, or a type parameter is assumed. 34Of a dummy procedure or procedure pointer, whether the interface is explicit, the characteristics of the 35procedure if the interface is explicit, and whether it is optional. 36Of a function result, its type, type parameters, which type parameters are deferred, whether it is poly- 37morphic, whether it is a pointer or allocatable, whether it is a procedure pointer, rank if it is a pointer 38or allocatable, shape if it is not a pointer or allocatable, the exact dependence of an array bound or type 39parameter on other entities, and whether the character length is assumed. class (4.3.1.3) : A class named N is the set of types extended from the type named N. 40 506 2006/01/05 WORKING DRAFT J3/07-007 1co-array (2.4.6) A data entity that has nonzero co-rank. A non-dummy co-array has the same shape 2on every image and its values may be referenced or defined by any image. 3co-bounds (5.3.7) : For a co-array, the limits within which the values of the co-subscripts of its co- 4indexed objects shall lie. co-indexed object (2.4.6) : An object whose designator includes an image-selector. 5 co-rank (2.4.6) : The number of co-dimensions of a co-array. 6 co-subscript (6.2.3) : One of the list of scalar integer expressions in an image-selector. 7 8collating sequence (4.4.5.4) : An ordering of all the different characters of a particular kind type 9parameter. collective subroutine (13.1) : An intrinsic subroutine that has an argument of type IMAGE TEAM. 10 11common block (5.7.2) : A block of physical storage that may be accessed by any of the scoping units 12in a program. 13companion processor (2.5.10): A mechanism by which global data and procedures may be referenced 14or defined. It may be a mechanism that references and defines such entities by means other than Fortran. 15The procedures can be described by a C function prototype. component (4.5) : A constituent of a derived type. 16 17component order (4.5.4.6) : The ordering of the components of a derived type that is used for intrinsic formatted input/output and for structure constructors. 18 19conformable (2.4.5) : Two arrays are conformable if they have the same shape. A scalar is con- 20formable with any array. 21conformance (1.5) : A program conforms to this part of ISO/IEC 1539 if it uses only those forms 22and relationships described therein and if the program has an interpretation according to this part of 23ISO/IEC 1539. A program unit conforms to this part of ISO/IEC 1539if it can be included in a program 24in a manner that allows the program to be standard-conforming. A processor conforms to this part of 25ISO/IEC 1539if it executes standard-conforming programs in a manner that fulfills the interpretations 26prescribed in this part of ISO/IEC 1539and contains the capability of detection and reporting as listed 27in 1.5. 28connect team (9.4.5.17) : The set of images that are permitted to reference a particular external input/output unit. 29 connected (9.4.3) : 30 31For an external unit, the property of referring to an external file. 32For an external file, the property of being referred to by an external unit. 33constant (2.4.3.1.2) : A data object whose value shall not change during execution of a program. It 34may be a named constant or a literal constant. 35construct (7.2.3, 7.2.4, 8.1) : A sequence of statements starting with an ASSOCIATE, BLOCK, DO, 36FORALL, IF, SELECT CASE, SELECT TYPE, or WHERE statement and ending with the correspond- 37ing terminal statement. 38construct association (16.5.1.6) : The association between the selector of an ASSOCIATE or SELECT 39TYPE construct and the associate name. 507 J3/07-007 WORKING DRAFT 2006/01/05 construct entity (16) : An entity defined by a lexical token whose scope is a construct. 1 2control mask (7.2.3) : In a WHERE statement or construct, an array of type logical whose value 3determines which elements of an array, in a where-assignment-stmt, will be defined. 4data : Plural of datum. 5data entity (2.4.3) : A data object, the result of the evaluation of an expression, or the result of the 6execution of a function reference (called the function result). A data entity has a type (either intrinsic 7or derived) and has, or may have, a data value (the exception is an undefined variable). Every data 8entity has a rank and is thus either a scalar or an array. data object (2.4.3.1) : A data entity that is a constant, a variable, or a subobject of a constant. 9 data type (4) : See type. 10 11datum : A single quantity that may have any of the set of values specified for its type. 12decimal symbol (9.9.2.6, 10.6, 10.8.8) : The character that separates the whole and fractional parts in 13the decimal representation of a real number in a file. By default the decimal symbol is a decimal point (also known as a period). The current decimal symbol is determined by the current decimal edit mode. 14 15declared type (4.3.1.3, 7.1.9) : The type that a data entity is declared to have. May differ from the type during execution (the dynamic type) for polymorphic data entities. 16 17default initialization (4.5) : If initialization is specified in a type definition, an object of the type will 18be automatically initialized. Nonpointer components may be initialized with values by default; pointer 19components may be initially disassociated by default. Default initialization is not provided for objects 20of intrinsic type. 21default-initialized (4.5.4.5) : A subcomponent is said to be default-initialized if it will be initialized 22by default initialization. 23deferred binding (4.5.5) : A binding with the DEFERRED attribute. A deferred binding shall appear only in an abstract type definition (4.5.7). 24 25deferred type parameter (4.3) : A length type parameter whose value is not specified in the decla- 26ration of an object, but instead is specified when the object is allocated or pointer-assigned. 27definable (2.5.5) : A variable is definable if its value may be changed by the appearance of its 28designator on the left of an assignment statement. An allocatable variable that has not been allocated 29is an example of a data object that is not definable. An example of a subobject that is not definable is C (I) when C is an array that is a constant and I is an integer variable. 30 defined (2.5.5) : For a data object, the property of having or being given a valid value. 31 32defined assignment statement (7.2.1.4, 12.4.3.4.3) : An assignment statement that is not an intrinsic 33assignment statement; it is defined by a subroutine and a generic interface that specifies ASSIGNMENT (=). 34 35defined operation (7.1.6, 12.4.3.4.2) : An operation that is not an intrinsic operation and is defined 36by a function that is associated with a generic identifier. 37deleted feature (1.8) : A feature in a previous Fortran standard that is considered to have been 38redundant and largely unused. See B.1 for a list of features that are in a previous Fortran standard, but 39are not in this part of ISO/IEC 1539. A feature designated as an obsolescent feature in this edition of this part of ISO/IEC 1539 may become a deleted feature in the next revision. 40 508 2006/01/05 WORKING DRAFT J3/07-007 1derived type (2.4.1.2, 4.5) : A type whose data have components, each of which is either of intrinsic 2type or of another derived type. designator (2.5.1) : A name, followed by zero or more subobject selectors. 3 4disassociated (2.4.7) : A disassociated pointer is not associated with a target. A pointer is disassociated 5following execution of a NULLIFY statement, following pointer assignment with a disassociated pointer, 6by default initialization, or by explicit initialization. A data pointer may also be disassociated by 7execution of a DEALLOCATE statement. 8dummy argument (12, 12.6.2.2, 12.6.2.3, 12.6.2.6, 12.6.4) : An entity by which an associated actual 9argument is accessed during execution of a procedure. 10dummy array : A dummy argument that is an array. dummy data object (12.3.2.2, 12.5.2.5-12.5.2.8) : A dummy argument that is a data object. 11 dummy procedure (12.2.2.3) : A dummy argument that is specified or referenced as a procedure. 12 13dynamic type (4.3.1.3, 7.1.9) : The type of a data entity during execution of a program. The dynamic 14type of a data entity that is not polymorphic is the same as its declared type. 15effective item (9.5.3) : A scalar object resulting from expanding an input/output list according to the 16rules in 9.5.3. 17elemental (2.4.5, 7.2.1.4, 12.8) : An adjective applied to an operation, procedure, or assignment state- 18ment that is applied independently to elements of an array or corresponding elements of a set of con- 19formable arrays and scalars. 20entity : The term used for any of the following: an abstract interface, common block, construct, data 21entity, external unit, generic interface, image, macro, namelist group, operator, procedure, program unit, 22 statement function, statement label, or type. 23executable construct (2.1) : An action statement (R214) or an ASSOCIATE, CASE, DO, FORALL, 24IF, SELECT TYPE, or WHERE construct. 25executable statement (2.3.3) : An instruction to perform or control one or more computational 26actions. 27explicit initialization (5.2) : Explicit initialization may be specified for objects of intrinsic or derived 28type in type declaration statements or DATA statements. An object of a derived type that specifies 29default initialization shall not appear in a DATA statement. 30explicit interface (12.4.2) : If a procedure has an explicit interface at the point of a reference to it, the 31processor is able to verify that the characteristics of the reference and declaration are related as required 32by this part of ISO/IEC 1539. A procedure has an explicit interface if it is an internal procedure, a 33module procedure, an intrinsic procedure, an external procedure that has an interface body, a procedure 34reference in its own scoping unit, or a dummy procedure that has an interface body. explicit-shape array (5.3.7.2) : A named array that is declared with explicit bounds. 35 36expression (2.4.3.2, 7.1) : A sequence of operands, operators, and parentheses (R722). It may be a 37variable, a constant, a function reference, or may represent a computation. 38extended type (4.5.7) : An extensible type that is an extension of another type. A type that is declared 39with the EXTENDS attribute. 40extensible type (4.5.7) : A type from which new types may be derived using the EXTENDS attribute. 509 J3/07-007 WORKING DRAFT 2006/01/05 1A nonsequence type that does not have the BIND attribute. 2extension type (4.5.7) : A base type is an extension type of itself only. An extended type is an 3extension type of itself and of all types for which its parent type is an extension. extent (2.4.5) : The size of one dimension of an array. 4 external file (9.2) : A sequence of records that exists in a medium external to the program. 5 6external linkage : The characteristic describing that a C entity is global to the program; defined in 7subclause 6.2.2 of the C International Standard. 8external procedure (2.2.4.1) : A procedure that is defined by an external subprogram or by a means 9other than Fortran. 10external subprogram (2.2) : A subprogram that is not in a main program, module, or another 11subprogram. Note that a module is not called a subprogram. Note that in Fortran 77, a block data 12program unit is called a subprogram. 13external unit (9.4) : A mechanism that is used to refer to an external file. It is identified by a 14nonnegative integer. file (9) : An internal file or an external file. 15 file storage unit (9.2.4) : The unit of storage for an unformatted or stream file. 16 final subroutine (4.5.6) : A subroutine that is called automatically by the processor during finalization. 17 18finalizable (4.5.6) : A type that has final subroutines, or that has a finalizable component. An object 19of finalizable type. 20finalization (4.5.6.2) : The process of calling user-defined final subroutines immediately before destroy- 21ing an object. 22function (2.2.4) : A procedure that is invoked in an expression and computes a value which is then 23used in evaluating the expression. function result (12.6.2.2) : The data object that returns the value of a function. 24 25function subprogram (12.6.2.2) : A sequence of statements beginning with a FUNCTION statement 26that is not in an interface block and ending with the corresponding END statement. 27generic identifier (12.4.3.2) : A lexical token that appears in an INTERFACE statement and is 28associated with all the procedures in the interface block or that appears in a GENERIC statement and 29is associated with the specific type-bound procedures. 30generic interface (4.5.2, 12.4.3.2) : An interface specified by a generic procedure binding or a generic 31interface block. generic interface block (12.4.3.2) : An interface block with a generic specification. 32 global entity (16.2) : An entity with an identifier whose scope is a program. 33 host (2.2.1) : Host scoping unit. 34 35host association (16.5.1.4) : The process by which a contained scoping unit accesses entities of its 36host. host scoping unit (2.2.1) : A scoping unit that immediately surrounds another scoping unit. 37 510 2006/01/05 WORKING DRAFT J3/07-007 1image (2.3.2) : A Fortran program executes as if it were replicated a number of times, the number of 2replications remaining fixed during execution of the program. Each copy is called an image and each 3image executes asynchronously. image index (2.3.2) : An integer value that identifies an image. 4 5implicit interface (12.4.2) : For a procedure referenced in a scoping unit, the property of not having 6an explicit interface. A statement function always has an implicit interface 7inherit (4.5.7) : To acquire from a parent. Type parameters, components, or procedure bindings of an 8extended type that are automatically acquired from its parent type without explicit declaration in the 9extended type are said to be inherited. 10inheritance association (4.5.7.2, 16.5.4) : The relationship between the inherited components and the 11parent component in an extended type. 12inquiry function (13.1) : A function that is either intrinsic or is defined in an intrinsic module and 13whose result depends on properties of one or more of its arguments instead of their values. 14instance of a subprogram (12.6.2.4) : The copy of a subprogram that is created when a procedure 15defined by the subprogram is invoked. 16intent (5.3.9) : An attribute of a dummy data object that indicates whether it is used to transfer data 17into the procedure, out of the procedure, or both. 18interface block (12.4.3.2) : A sequence of statements from an INTERFACE statement to the corre- 19sponding END INTERFACE statement. 20interface body (12.4.3.2) : A sequence of statements in an interface block from a FUNCTION or 21SUBROUTINE statement to the corresponding END statement. 22internal file (9.3) : A character variable that is used to transfer and convert data from internal storage 23to internal storage. internal procedure (2.2.4.3) : A procedure that is defined by an internal subprogram. 24 internal subprogram (2.2) : A subprogram in a main program or another subprogram. 25 26interoperable (15.3) : The property of a Fortran entity that ensures that an equivalent entity may be 27defined by means of C. 28intrinsic (2.5.7) : An adjective that may be applied to types, operators, assignment statements, pro- 29cedures, and modules. Intrinsic types, operators, and assignment statements are defined in this part of 30ISO/IEC 1539 and may be used in any scoping unit without further definition or specification. Intrinsic 31procedures are defined in this part of ISO/IEC 1539 or provided by a processor, and may be used in 32a scoping unit without further definition or specification. Intrinsic modules are defined in this part of 33ISO/IEC 1539 or provided by a processor, and may be accessed by use association; procedures and types 34defined in an intrinsic module are not themselves intrinsic. 35Intrinsic procedures and modules that are not defined in this part of ISO/IEC 1539 are called nonstandard 36intrinsic procedures and modules. invoke (2.2.4) : 37 38To call a subroutine by a CALL statement or by a defined assignment statement. 39To call a function by a reference to it by name or operator during the evaluation of an expression. To call a final subroutine by finalization. 511 J3/07-007 WORKING DRAFT 2006/01/05 1keyword (2.5.2) : A word that is part of the syntax of a statement or a name that is used to identify 2an item in a list. 3kind type parameter (2.4.1.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5, 4.4.6, 4.5.3) : A parameter whose values label 4the available kinds of an intrinsic type, or a derived-type parameter that is declared to have the KIND 5attribute. 6label : See binding label or statement label. length of a character string (4.4.5) : The number of characters in the character string. 7 lexical token (3.2) : A sequence of one or more characters with a specified interpretation. 8 9line (3.3) : A sequence of 0 to 132 characters, which may contain Fortran statements, a comment, or 10an INCLUDE line. 11linkage association (16.5.1.5) : The association between interoperable Fortran entities and their C 12counterparts. 13literal constant (2.4.3.1.2, 4.4) : A constant without a name. Note that in Fortran 77, this was 14called simply a constant. local entity (16.3) : An entity identified by a lexical token whose scope is a scoping unit. 15 16local variable (2.4.3.1.1) : A variable local to a particular scoping unit; not imported through use or 17host association, not a dummy argument, and not a variable in common. 18main program (2.3.6, 11.1) : A Fortran main program or a replacement defined by means other than 19Fortran. 20many-one array section (6.2.2.2.2) : An array section with a vector subscript having two or more 21elements with the same value. 22module (2.2.5, 11.2) : A program unit that contains or accesses definitions to be accessed by other 23program units. module procedure (2.2.4.2) : A procedure that is defined by a module subprogram. 24 J3 internal note Unresolved Technical Issue 5003 The following glossary entry is just plain wrong. A Module Procedure Interface Block declares a Module Procedure Interface, but not a Separate Module Procedure's Interface unless the Separate Module Procedure is defined by an Separate Module Subprogram (sic). This raises the question of whether the whole definition/declaration stuff in C12 is consistent and correct. It looks like it is probably inconsistent, since one cannot know when translating the module whether the MPIB should be treated as declaring the SMP's interface or not. When C12 has been fixed, the glossary entry can be reconsidered ­ and deleted if it is not useful. module procedure interface (12.4.3.2) : The interface for a separate module procedure. 25 module subprogram (2.2) : A subprogram that is in a module but is not an internal subprogram. 26 27name (3.2.1) : A lexical token consisting of a letter followed by up to 62 alphanumeric characters 28(letters, digits, and underscores). Note that in Fortran 77, this was called a symbolic name. 29name association (16.5.1) : Argument association, use association, host association, linkage associa- 30tion, or construct association. 512 2006/01/05 WORKING DRAFT J3/07-007 1named : Having a name. That is, in a phrase such as "named variable," the word "named" signifies that 2the variable name is not qualified by a subscript list, substring specification, and so on. For example, 3if X is an array variable, the reference "X" is a named variable while the reference "X(1)" is an object 4designator. 5named constant (2.4.3.1.2) : A constant that has a name. Note that in Fortran 77, this was called 6a symbolic constant. 7NaN (14.7) : A Not-a-Number value of IEEE arithmetic. It represents an undefined value or a value 8created by an invalid operation. 9nonexecutable statement (2.3.3) : A statement used to configure the program environment in which 10computational actions take place. 11numeric storage unit (16.5.3.2) : The unit of storage for holding a scalar that is not a pointer and is 12of type default real, default integer, or default logical. numeric type (4.4) : Integer, real or complex type. 13 object (2.4.3.1) : Data object. 14 object designator (2.5.1) : A designator for a data object. 15 16obsolescent feature (1.8) : A feature that is considered to have been redundant but that is still in 17frequent use. operand (2.5.8) : An expression that precedes or succeeds an operator. 18 operation (7.1.5) : A computation involving one or two operands. 19 operator (2.5.8) : A lexical token that specifies an operation. 20 21override (4.5.2, 4.5.7) : When explicit initialization or default initialization overrides default initializa- 22tion, it is as if only the overriding initialization were specified. If a procedure is bound to an extensible 23type, it overrides the one that would have been inherited from the parent type. 24parent component (4.5.7.2) : The component of an entity of extended type that corresponds to its 25inherited portion. parent type (4.5.7) : The extensible type from which an extended type is derived. 26 27passed-object dummy argument (4.5.4.4) : The dummy argument of a type-bound procedure or 28procedure pointer component that becomes associated with the object through which the procedure was 29invoked. pointer (2.4.7) : An entity that has the POINTER attribute. 30 31pointer assignment (7.2.2) : The pointer association of a pointer with a target by the execution of a 32pointer assignment statement or the execution of an assignment statement for a data object of derived 33type having the pointer as a subobject. pointer assignment statement (7.2.2) : A statement of the form "pointer-object => target". 34 35pointer associated (6.3, 7.2.2) : The relationship between a pointer and a target following a pointer 36assignment or a valid execution of an ALLOCATE statement. pointer association (16.5.2) : The process by which a pointer becomes pointer associated with a target. 37 38polymorphic (4.3.1.3) : Able to be of differing types during program execution. An object declared 513 J3/07-007 WORKING DRAFT 2006/01/05 1with the CLASS keyword is polymorphic. 2preconnected (9.4.4) : A property describing a unit that is connected to an external file at the beginning 3of execution of a program. Such a unit may be specified in input/output statements without an OPEN 4statement being executed for that unit. 5procedure (2.2.4, 12.2) : A computation that may be invoked during program execution. It may be a 6function or a subroutine. It may be an intrinsic procedure, an external procedure, a module procedure, 7an internal procedure, a dummy procedure, or a statement function. A subprogram may define more than 8one procedure if it contains ENTRY statements. procedure designator (2.5.1) : A designator for a procedure. 9 10procedure interface (12.4) : The characteristics of a procedure, the name of the procedure, the name of each dummy argument, and the generic identifiers (if any) by which it may be referenced. 11 12processor (1.2) : The combination of a computing system and the mechanism by which programs are 13transformed for use on that computing system. 14processor dependent (1.5) : The designation given to a facility that is not completely specified by 15this part of ISO/IEC 1539. Such a facility shall be provided by a processor, with methods or semantics 16determined by the processor. program (2.2.2) : A set of program units that includes exactly one main program. 17 18program unit (2.2.1) : The fundamental component of a program. A sequence of statements, comments, 19and INCLUDE lines. It may be a main program, a module, an external subprogram, or a block data 20program unit. 21prototype : The C analog of a function interface body; defined in 6.7.5.3 of the C International 22Standard. 23pure procedure (12.7) : A procedure that is a pure intrinsic procedure (13.1), is defined by a pure 24subprogram, or is a statement function that references only pure functions. rank (2.4.4, 2.4.5) : The number of dimensions of an array. Zero for a scalar. 25 record (9.1) : A sequence of values or characters that is treated as a whole within a file. 26 27reference (2.5.6) : The appearance of an object designator in a context requiring the value at that 28point during execution, the appearance of a procedure designator, its operator symbol, or a defined 29assignment statement in a context requiring execution of the procedure at that point, or the appearance 30of a module name in a USE statement. Neither the act of defining a variable nor the appearance of the 31name of a procedure as an actual argument is regarded as a reference. result variable (2.2.4, 12.6.2.2) : The variable that returns the value of a function. 32 33rounding mode (14.3, 10.7.2.3.7) : The method used to choose the result of an operation that cannot 34be represented exactly. In IEEE arithmetic, there are four modes; nearest, towards zero, up (towards 35), and down (towards -). In addition, for input/output the two additional modes COMPATIBLE 36and PROCESSOR DEFINED are provided. scalar (2.4.4) : 37 38Not being an array. 39scope (16) : That part of a program within which a lexical token has a single interpretation. It may be 40a program, a scoping unit, a construct, a single statement, or a part of a statement. 514 2006/01/05 WORKING DRAFT J3/07-007 scoping unit (2.2.1) : One of the following: 1 (1) A program unit or subprogram, excluding any scoping units in it, 2 (2) A derived-type definition, or 3 (3) An interface body, excluding any scoping units in it. 4 section subscript (6.2.2) : A subscript, vector subscript, or subscript triplet in an array section selector. 5 selector (6.1.1, 6.1.2, 6.1.4, 8.1.5, 8.1.3) : A syntactic mechanism for designating 6 (1) a subobject, 7 (2) the set of values for which a CASE block is executed, 8 9 (3) the object whose type determines which branch of a SELECT TYPE construct is executed, 10 or (4) the object that is associated with the associate-name in an ASSOCIATE construct. 11 12shape (2.4.5) : The rank and extents of an array. The shape may be represented by the rank-one array 13whose elements are the extents in each dimension. size (2.4.5) : The total number of elements of an array. 14 15specification expression (7.1.11) : An expression with limitations that make it suitable for use in 16specifications such as length type parameters or array bounds. specification function (7.1.11) : A nonintrinsic function that may be used in a specification expression. 17 18standard-conforming program (1.5) : A program that uses only those forms and relationships de- 19scribed in this part of ISO/IEC 1539, and that has an interpretation according to this part of ISO/IEC 201539. 21statement (3.3) : A sequence of lexical tokens. It usually consists of a single line, but a statement may 22be continued from one line to another and the semicolon symbol may be used to separate statements 23within a line. 24statement entity (16) : An entity identified by a lexical token whose scope is a single statement or 25part of a statement. 26statement function (12.6.4) : A procedure specified by a single statement that is similar in form to an assignment 27 statement. 28statement label (3.2.4) : A lexical token consisting of up to five digits that precedes a statement and 29may be used to refer to the statement. 30storage association (16.5.3) : The relationship between two storage sequences if a storage unit of one 31is the same as a storage unit of the other. storage sequence (16.5.3.2) : A sequence of contiguous storage units. 32 33storage unit (16.5.3.2) : A character storage unit, a numeric storage unit, a file storage unit, or an 34unspecified storage unit. stride (6.2.2.2.1) : The increment specified in a subscript triplet. 35 36struct : The C analog of a sequence derived type; defined in 6.2.5 of the C International Standard. structure (2.4.1.2) : A scalar data object of derived type. 37 38structure component (6.1.2) : A part of an object of derived type. It may be referenced by an object designator. 515 J3/07-007 WORKING DRAFT 2006/01/05 1 structure constructor (4.5.10) : A syntactic mechanism for constructing a value of derived type. 2 3subcomponent (6.1.2) : A subcomponent of an object of derived type is a component of that object 4or of a subobject of that object. submodule (2.2.6, 11.2.3) : A program unit that extends a module or another submodule. 5 6subobject (2.4.3.1) : A portion of a data object that may be referenced or defined independently of 7other portions. It may be an array element, an array section, a structure component, a substring, or the 8real or imaginary part of a complex object. 9subprogram (2.2.1) : A function subprogram or a subroutine subprogram. Note that in Fortran 77, 10a block data program unit was called a subprogram. 11subroutine (2.2.4) : A procedure that is invoked by a CALL statement or by a defined assignment 12statement. 13subroutine subprogram (12.6.2.3) : A sequence of statements beginning with a SUBROUTINE state- 14ment that is not in an interface block and ending with the corresponding END statement. 15subscript (6.2.2) : One of the list of scalar integer expressions in an array element selector. Note that 16in Fortran 77, the whole list was called the subscript. 17subscript triplet (6.2.2) : An item in the list of an array section selector that contains a colon and 18specifies a regular sequence of integer values. 19substring (6.1.1) : A contiguous portion of a scalar character string. Note that an array section can 20include a substring selector; the result is called an array section and not a substring. 21target (2.4.7, 5.3.16, 6.3.1.2) : A data entity that has the TARGET attribute, or an entity that is 22associated with a pointer. 23team (2.3.2) : A set of images formed by invoking the intrinsic collective subroutine FORM TEAM (13.7.69). 24 team synchronization (8.5.3) : Synchronization of the images in a team. 25 26transformational function (13.1) : A function that is either intrinsic or is defined in an intrinsic 27module and that is neither an elemental function nor an inquiry function. 28type (2.4.1) : A named category of data that is characterized by a set of values, together with a way to 29denote these values and a collection of operations that interpret and manipulate the values. The set of 30data values depends on the values of the type parameters. 31type-bound procedure (4.5.5) : A procedure binding in a type definition. The procedure may be 32referenced by the binding-name via any object of that dynamic type, as a defined operator, by defined 33assignment, or as part of the finalization process. 34type compatible (4.3.1.3) : All entities are type compatible with other entities of the same type. 35Unlimited polymorphic entities are type compatible with all entities; other polymorphic entities are type 36compatible with entities whose dynamic type is an extension type of the polymorphic entity's declared 37type. 38type declaration statement (5.2) : An INTEGER, REAL, DOUBLE PRECISION, COMPLEX, CHARACTER, LOGICAL, TYPE (type-name), or CLASS (type-name) statement. 39 40type parameter (2.4.1.1) : A parameter of a data type. KIND and LEN are the type parameters of 516 2006/01/05 WORKING DRAFT J3/07-007 1intrinsic types. The type parameters of a derived type are defined in the derived-type definition. 2type parameter order (4.5.3.2) : The ordering of the type parameters of a derived type that is used 3for derived-type specifiers. 4ultimate component (4.5) : For a structure, a component that is of intrinsic type, has the ALLOCAT- 5ABLE attribute, or has the POINTER attribute, or an ultimate component of a derived-type component 6that does not have the POINTER attribute or the ALLOCATABLE attribute. undefined (2.5.5) : For a data object, the property of not having a determinate value. 7 8unsigned : A qualifier of a C numeric type indicating that it is comprised only of nonnegative values; 9defined in 6.2.5 of the C International Standard. There is nothing analogous in Fortran. 10unspecified storage unit (16.5.3.2) : A unit of storage for holding a pointer or a scalar that is not a 11pointer and is of type other than default integer, default character, default real, double precision real, 12default logical, or default complex. 13use association (16.5.1.3) : The association of names in different scoping units specified by a USE 14statement. 15variable (2.4.3.1.1) : A data object whose value can be defined and redefined during the execution of 16a program. It may be a named data object, an array element, an array section, a structure component, 17or a substring. Note that in Fortran 77, a variable was always scalar and named. vector subscript (6.2.2.2.2) : A section subscript that is an integer expression of rank one. 18 19void : A C type comprising an empty set of values; defined in 6.2.5 of the C International Standard. 20There is nothing analogous in Fortran. whole array (6.2.1) : A named array. 21 517 J3/07-007 WORKING DRAFT 2006/01/05 518 2006/01/05 WORKING DRAFT J3/07-007 1 Annex B (Informative) 2 3 Decremental features 4B.1 Deleted features 5The deleted features are those features of Fortran 90 that were redundant and considered largely unused. 6The following Fortran 90 features are not required by Fortran 95, Fortran 2003, or this part of ISO/IEC 71539. (1) Real and double precision DO variables. 8 9 The ability present in Fortran 77, and for consistency also in Fortran 90, for a DO variable 10 to be of type real or double precision in addition to type integer, has been deleted. A similar 11 result can be achieved by using a DO construct with no loop control and the appropriate 12 exit test. (2) Branching to an END IF statement from outside its block. 13 14 In Fortran 77, and for consistency also in Fortran 90, it was possible to branch to an END 15 IF statement from outside the IF construct; this has been deleted. A similar result can be 16 achieved by branching to a CONTINUE statement that is immediately after the END IF 17 statement. (3) PAUSE statement. 18 19 The PAUSE statement, present in Fortran 66, Fortran 77 and for consistency also in 20 Fortran 90, has been deleted. A similar result can be achieved by writing a message to the 21 appropriate unit, followed by reading from the appropriate unit. (4) ASSIGN and assigned GO TO statements and assigned format specifiers. 22 23 The ASSIGN statement and the related assigned GO TO statement, present in Fortran 66, 24 Fortran 77 and for consistency also in Fortran 90, have been deleted. Further, the ability to 25 use an assigned integer as a format, present in Fortran 77 and Fortran 90, has been deleted. 26 A similar result can be achieved by using other control constructs instead of the assigned 27 GOTO statement and by using a default character variable to hold a format specification 28 instead of using an assigned integer. (5) H edit descriptor. 29 30 In Fortran 77, and for consistency also in Fortran 90, there was an alternative form of 31 character string edit descriptor, which had been the only such form in Fortran 66; this has 32 been deleted. A similar result can be achieved by using a character string edit descriptor. 33The following is a list of the previous editions of the Fortran International Standard, along with their 34informal names. 35 · ISO R 1539-1972, Fortran 66; 36 · ISO 1539-1980, Fortran 77; · ISO/IEC 1539:1991, Fortran 90; 37 · ISO/IEC 1539-1:1997, Fortran 95. 38 See ISO/IEC 1539:1991 for detailed rules of how these deleted features work. 39 519 J3/07-007 WORKING DRAFT 2006/01/05 1B.2 Obsolescent features 2The obsolescent features are those features of Fortran 90 that were redundant and for which better 3methods were available in Fortran 90. Subclause 1.8.3 describes the nature of the obsolescent features. The obsolescent features in this part of ISO/IEC 1539 are the following. 4 (1) Arithmetic IF -- use the IF statement or IF construct (8.1.8). 5 6 (2) Shared DO termination and termination on a statement other than END DO or CON- 7 TINUE -- use an END DO or a CONTINUE statement for each DO statement. (3) Alternate return -- see B.2.1. 8 (4) Computed GO TO statement -- see B.2.2. 9 (5) Statement functions -- see B.2.3. 10 (6) DATA statements amongst executable statements -- see B.2.4. 11 (7) Assumed length character functions -- see B.2.5. 12 (8) Fixed form source -- see B.2.6. 13 (9) CHARACTER* form of CHARACTER declaration -- see B.2.7. 14 15B.2.1 Alternate return 16An alternate return introduces labels into an argument list to allow the called procedure to direct the 17execution of the caller upon return. The same effect can be achieved with a return code that is used 18in a CASE construct on return. This avoids an irregularity in the syntax and semantics of argument 19association. For example, 20CALL SUBR_NAME (X, Y, Z, *100, *200, *300) 21may be replaced by 22CALL SUBR_NAME (X, Y, Z, RETURN_CODE) 23SELECT CASE (RETURN_CODE) 24CASE (1) 25... 26CASE (2) 27... 28CASE (3) 29... 30CASE DEFAULT 31... 32END SELECT B.2.2 Computed GO TO statement 33 34The computed GO TO has been superseded by the CASE construct, which is a generalized, easier to 35use and more efficient means of expressing the same computation. 36B.2.3 Statement functions 37Statement functions are subject to a number of nonintuitive restrictions and are a potential source of 38error because their syntax is easily confused with that of an assignment statement. 39The internal function is a more generalized form of the statement function and completely supersedes 40it. 520 2006/01/05 WORKING DRAFT J3/07-007 B.2.4 DATA statements among executables 1 2The statement ordering rules of Fortran 66, and hence of Fortran 77 and Fortran 90 for compatibility, 3allowed DATA statements to appear anywhere in a program unit after the specification statements. The 4ability to position DATA statements amongst executable statements is very rarely used, is unnecessary 5and is a potential source of error. B.2.5 Assumed character length functions 6 7Assumed character length for functions is an irregularity in the language in that elsewhere in Fortran 8the philosophy is that the attributes of a function result depend only on the actual arguments of the 9invocation and on any data accessible by the function through host or use association. Some uses of this 10facility can be replaced with an automatic character length function, where the length of the function 11result is declared in a specification expression. Other uses can be replaced by the use of a subroutine 12whose arguments correspond to the function result and the function arguments. 13Note that dummy arguments of a function may be assumed character length. 14B.2.6 Fixed form source 15Fixed form source was designed when the principal machine-readable input medium for new programs 16was punched cards. Now that new and amended programs are generally entered via keyboards with 17screen displays, it is an unnecessary overhead, and is potentially error-prone, to have to locate positions 186, 7, or 72 on a line. Free form source was designed expressly for this more modern technology. 19It is a simple matter for a software tool to convert from fixed to free form source. 20B.2.7 CHARACTER* form of CHARACTER declaration 21Fortran 90 had two different forms of specifying the length selector in CHARACTER declarations. The older form (CHARACTER*char-length) is redundant. 22 521 J3/07-007 WORKING DRAFT 2006/01/05 522 2006/01/05 WORKING DRAFT J3/07-007 1 Annex C (Informative) 2 3 Extended notes 4C.1 Clause 4 notes C.1.1 Selection of the approximation methods (4.4.3) 5 6One can select the real approximation method for an entire program through the use of a module and 7the parameterized real type. This is accomplished by defining a named integer constant to have a 8particular kind type parameter value and using that named constant in all real, complex, and derived- 9type declarations. For example, the specification statements 10INTEGER, PARAMETER :: LONG_FLOAT = 8 11REAL (LONG_FLOAT) X, Y 12COMPLEX (LONG_FLOAT) Z 13specify that the approximation method corresponding to a kind type parameter value of 8 is supplied for 14the data objects X, Y, and Z in the program unit. The kind type parameter value LONG FLOAT can 15be made available to an entire program by placing the INTEGER specification statement in a module 16and accessing the named constant LONG FLOAT with a USE statement. Note that by changing 8 to 4 17once in the module, a different approximation method is selected. 18To avoid the use of the processor-dependent values 4 or 8, replace 8 by KIND (0.0) or KIND (0.0D0). 19Another way to avoid these processor-dependent values is to select the kind value using the intrinsic 20inquiry function SELECTED REAL KIND. This function, given integer arguments P and R specifying 21minimum requirements for decimal precision and decimal exponent range, respectively, returns the kind 22type parameter value of the approximation method that has at least P decimal digits of precision and 23at least a range for positive numbers of 10-R to 10R. In the above specification statement, the 8 may be 24replaced by, for instance, SELECTED REAL KIND (10, 50), which requires an approximation method 25to be selected with at least 10 decimal digits of precision and a range from 10-50 to 1050. There are no 26magnitude or ordering constraints placed on kind values, in order that implementers may have flexibility 27in assigning such values and may add new kinds without changing previously assigned kind values. 28As kind values have no portable meaning, a good practice is to use them in programs only through 29named constants as described above (for example, SINGLE, IEEE SINGLE, DOUBLE, and QUAD), 30rather than using the kind values directly. C.1.2 Type extension and component accessibility (4.5.2.2, 4.5.4) 31 32The default accessibility of an extended type may be specified in the type definition. The accessibility 33of its components may be specified individually. 34 module types 35 type base_type 36 private !-- Sets default accessibility 523 J3/07-007 WORKING DRAFT 2006/01/05 1 integer :: i !-- a private component 2 integer, private :: j !-- another private component 3 integer, public :: k !-- a public component 4 end type base_type 5 6 type, extends(base_type) :: my_type 7 private !-- Sets default for components declared in my_type 8 integer :: l !-- A private component. 9 integer, public :: m !-- A public component. 10 end type my_type 11 12 end module types 13 14 subroutine sub 15 use types 16 type (my_type) :: x 17 18 .... 19 20 call another_sub( & 21 x%base_type, & !-- ok because base_type is a public subobject of x 22 x%base_type%k, & !-- ok because x%base_type is ok and has k as a 23 !-- public component. 24 x%k, & !-- ok because it is shorthand for x%base_type%k 25 x%base_type%i, & !-- Invalid because i is private. 26 x%i) !-- Invalid because it is shorthand for x%base_type%i 27 end subroutine sub C.1.3 Abstract types 28 29The following defines an object that can be displayed in an X window: 30 TYPE, ABSTRACT :: DRAWABLE_OBJECT 31 REAL, DIMENSION(3) :: RGB_COLOR = (/1.0,1.0,1.0/) ! White 32 REAL, DIMENSION(2) :: POSITION = (/0.0,0.0/) ! Centroid 33 CONTAINS 34 PROCEDURE(RENDER_X), PASS(OBJECT), DEFERRED :: RENDER 35 END TYPE DRAWABLE_OBJECT 36 37 ABSTRACT INTERFACE 38 SUBROUTINE RENDER_X(OBJECT, WINDOW) 39 CLASS(DRAWABLE_OBJECT), INTENT(IN) :: OBJECT 40 CLASS(X_WINDOW), INTENT(INOUT) :: WINDOW 41 END SUBROUTINE RENDER_X 42 END INTERFACE 524 2006/01/05 WORKING DRAFT J3/07-007 1We can declare a nonabstract type by extending the abstract type: 2 TYPE, EXTENDS(DRAWABLE_OBJECT) :: DRAWABLE_TRIANGLE ! Not ABSTRACT 3 REAL, DIMENSION(2,3) :: VERTICES ! In relation to centroid 4 CONTAINS 5 PROCEDURE, PASS(OBJECT) :: RENDER=>RENDER_TRIANGLE_X 6 END TYPE DRAWABLE_TRIANGLE 7The actual drawing procedure will draw a triangle in WINDOW with vertices at x coordinates 8OBJECT%POSITION(1)+OBJECT%VERTICES(1,:) and y coordinates 9OBJECT%POSITION(2)+OBJECT%VERTICES(2,:): 10 SUBROUTINE RENDER_TRIANGLE_X(OBJECT, WINDOW) 11 CLASS(DRAWABLE_TRIANGLE), INTENT(IN) :: OBJECT 12 CLASS(X_WINDOW), INTENT(INOUT) :: WINDOW 13 ... 14 END SUBROUTINE RENDER_TRIANGLE_X C.1.4 Pointers (4.5.2) 15 16Pointers are names that can change dynamically their association with a target object. In a sense, a 17normal variable is a name with a fixed association with a particular object. A normal variable name 18refers to the same storage space throughout the lifetime of the variable. A pointer name may refer 19to different storage space, or even no storage space, at different times. A variable may be considered 20to be a descriptor for space to hold values of the appropriate type, type parameters, and array rank 21such that the values stored in the descriptor are fixed when the variable is created. A pointer also may 22be considered to be a descriptor, but one whose values may be changed dynamically so as to describe 23different pieces of storage. When a pointer is declared, space to hold the descriptor is created, but the 24space for the target object is not created. 25A derived type may have one or more components that are defined to be pointers. It may have a 26component that is a pointer to an object of the same derived type. This "recursive" data definition 27allows dynamic data structures such as linked lists, trees, and graphs to be constructed. For example: 28TYPE NODE ! Define a ''recursive'' type 29 INTEGER :: VALUE = 0 30 TYPE (NODE), POINTER :: NEXT_NODE => NULL ( ) 31END TYPE NODE 32 33TYPE (NODE), TARGET :: HEAD ! Automatically initialized 34TYPE (NODE), POINTER :: CURRENT, TEMP ! Declare pointers 35INTEGER :: IOEM, K 36 37CURRENT => HEAD ! CURRENT points to head of list 38 39DO 40 READ (*, *, IOSTAT = IOEM) K ! Read next value, if any 525 J3/07-007 WORKING DRAFT 2006/01/05 1 IF (IOEM /= 0) EXIT 2 ALLOCATE (TEMP) ! Create new cell each iteration 3 TEMP % VALUE = K ! Assign value to cell 4 CURRENT % NEXT_NODE => TEMP ! Attach new cell to list 5 CURRENT => TEMP ! CURRENT points to new end of list 6END DO 7A list is now constructed and the last linked cell contains a disassociated pointer. A loop can be used 8to "walk through" the list. 9CURRENT => HEAD 10DO 11 IF (.NOT. ASSOCIATED (CURRENT % NEXT_NODE)) EXIT 12 CURRENT => CURRENT % NEXT_NODE 13 WRITE (*, *) CURRENT % VALUE 14END DO C.1.5 Structure constructors and generic names 15 16A generic name may be the same as a type name. This can be used to emulate user-defined structure 17constructors for that type, even if the type has private components. For example: 18MODULE mytype_module 19 TYPE mytype 20 PRIVATE 21 COMPLEX value 22 LOGICAL exact 23 END TYPE 24 INTERFACE mytype 25 MODULE PROCEDURE int_to_mytype 26 END INTERFACE 27 ! Operator definitions etc. 28 ... 29CONTAINS 30 TYPE(mytype) FUNCTION int_to_mytype(i) 31 INTEGER,INTENT(IN) :: i 32 int_to_mytype%value = i 33 int_to_mytype%exact = .TRUE. 34 END FUNCTION 35 ! Procedures to support operators etc. 36 ... 37END 38 39PROGRAM example 40 USE mytype_module 526 2006/01/05 WORKING DRAFT J3/07-007 1 TYPE(mytype) x 2 x = mytype(17) 3END 4The type name may still be used as a generic name if the type has type parameters. For example: 5MODULE m 6 TYPE t(kind) 7 INTEGER, KIND :: kind 8 COMPLEX(kind) value 9 END TYPE 10 INTEGER,PARAMETER :: single = KIND(0.0), double = KIND(0d0) 11 INTERFACE t 12 MODULE PROCEDURE real_to_t1, dble_to_t2, int_to_t1, int_to_t2 13 END INTERFACE 14 ... 15CONTAINS 16 TYPE(t(single)) FUNCTION real_to_t1(x) 17 REAL(single) x 18 real_to_t1%value = x 19 END FUNCTION 20 TYPE(t(double)) FUNCTION dble_to_t2(x) 21 REAL(double) x 22 dble_to_t2%value = x 23 END FUNCTION 24 TYPE(t(single)) FUNCTION int_to_t1(x,mold) 25 INTEGER x 26 TYPE(t(single)) mold 27 int_to_t1%value = x 28 END FUNCTION 29 TYPE(t(double)) FUNCTION int_to_t2(x,mold) 30 INTEGER x 31 TYPE(t(double)) mold 32 int_to_t2%value = x 33 END FUNCTION 34 ... 35END 36 37PROGRAM example 38 USE m 39 TYPE(t(single)) x 40 TYPE(t(double)) y 41 x = t(1.5) ! References real_to_t1 42 x = t(17,mold=x) ! References int_to_t1 y = t(1.5d0) ! References dble_to_t2 527 J3/07-007 WORKING DRAFT 2006/01/05 1 2 y = t(42,mold=y) ! References int_to_t2 3 y = t(kind(0d0)) ((0,1)) ! Uses the structure constructor for type t 4END C.1.6 Generic type-bound procedures 5 6Example of a derived type with generic type-bound procedures: 7The only difference between this example and the same thing rewritten to use generic interface blocks 8is that with type-bound procedures, 9 USE(rational_numbers),ONLY :: rational 10does not block the type-bound procedures; the user still gets access to the defined assignment and 11extended operations. 12MODULE rational_numbers 13 IMPLICIT NONE 14 PRIVATE 15 TYPE,PUBLIC :: rational 16 PRIVATE 17 INTEGER n,d 18 CONTAINS 19 ! ordinary type-bound procedure 20 PROCEDURE :: real => rat_to_real 21 ! specific type-bound procedures for generic support 22 PROCEDURE,PRIVATE :: rat_asgn_i 23 PROCEDURE,PRIVATE :: rat_plus_rat 24 PROCEDURE,PRIVATE :: rat_plus_i 25 PROCEDURE,PRIVATE,PASS(b) :: i_plus_rat 26 ! generic type-bound procedures 27 GENERIC :: ASSIGNMENT(=) => rat_asgn_i 28 GENERIC :: OPERATOR(+) => rat_plus_rat, rat_plus_i, i_plus_rat 29 END TYPE 30CONTAINS 31 ELEMENTAL REAL FUNCTION rat_to_real(this) RESULT(r) 32 CLASS(rational),INTENT(IN) :: this 33 r = REAL(this%n)/this%d 34 END FUNCTION 35 ELEMENTAL SUBROUTINE rat_asgn_i(a,b) 36 CLASS(rational),INTENT(OUT) :: a 37 INTEGER,INTENT(IN) :: b 38 a%n = b 39 a%d = 1 40 END SUBROUTINE 528 2006/01/05 WORKING DRAFT J3/07-007 1 ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r) 2 CLASS(rational),INTENT(IN) :: a 3 INTEGER,INTENT(IN) :: b 4 r%n = a%n + b*a%d 5 r%d = a%d 6 END FUNCTION 7 ELEMENTAL TYPE(rational) FUNCTION i_plus_rat(a,b) RESULT(r) 8 INTEGER,INTENT(IN) :: a 9 CLASS(rational),INTENT(IN) :: b 10 r%n = b%n + a*b%d 11 r%d = b%d 12 END FUNCTION 13 ELEMENTAL TYPE(rational) FUNCTION rat_plus_rat(a,b) RESULT(r) 14 CLASS(rational),INTENT(IN) :: a,b 15 r%n = a%n*b%d + b%n*a%d 16 r%d = a%d*b%d 17 END FUNCTION 18END C.1.7 Final subroutines (4.5.6, 4.5.6.2, 4.5.6.3, 4.5.6.4) 19 20Example of a parameterized derived type with final subroutines: 21MODULE m 22 TYPE t(k) 23 INTEGER, KIND :: k 24 REAL(k),POINTER :: vector(:) => NULL() 25 CONTAINS 26 FINAL :: finalize_t1s, finalize_t1v, finalize_t2e 27 END TYPE 28CONTAINS 29 SUBROUTINE finalize_t1s(x) 30 TYPE(t(KIND(0.0))) x 31 IF (ASSOCIATED(x%vector)) DEALLOCATE(x%vector) 32 END SUBROUTINE 33 SUBROUTINE finalize_t1v(x) 34 TYPE(t(KIND(0.0))) x(:) 35 DO i=LBOUND(x,1),UBOUND(x,1) 36 IF (ASSOCIATED(x(i)%vector)) DEALLOCATE(x(i)%vector) 37 END DO 38 END SUBROUTINE 39 ELEMENTAL SUBROUTINE finalize_t2e(x) 40 TYPE(t(KIND(0.0d0))),INTENT(INOUT) :: x 41 IF (ASSOCIATED(x%vector)) DEALLOCATE(x%vector) 42 END SUBROUTINE 529 J3/07-007 WORKING DRAFT 2006/01/05 1END MODULE 2 3SUBROUTINE example(n) 4 USE m 5 TYPE(t(KIND(0.0))) a,b(10),c(n,2) 6 TYPE(t(KIND(0.0d0))) d(n,n) 7 ... 8 ! Returning from this subroutine will effectively do 9 ! CALL finalize_t1s(a) 10 ! CALL finalize_t1v(b) 11 ! CALL finalize_t2e(d) 12 ! No final subroutine will be called for variable C because the user 13 ! omitted to define a suitable specific procedure for it. 14END SUBROUTINE 15Example of extended types with final subroutines: 16MODULE m 17 TYPE t1 18 REAL a,b 19 END TYPE 20 TYPE,EXTENDS(t1) :: t2 21 REAL,POINTER :: c(:),d(:) 22 CONTAINS 23 FINAL :: t2f 24 END TYPE 25 TYPE,EXTENDS(t2) :: t3 26 REAL,POINTER :: e 27 CONTAINS 28 FINAL :: t3f 29 END TYPE 30 ... 31CONTAINS 32 SUBROUTINE t2f(x) ! Finalizer for TYPE(t2)'s extra components 33 TYPE(t2) :: x 34 IF (ASSOCIATED(x%c)) DEALLOCATE(x%c) 35 IF (ASSOCIATED(x%d)) DEALLOCATE(x%d) 36 END SUBROUTINE 37 SUBROUTINE t3f(y) ! Finalizer for TYPE(t3)'s extra components 38 TYPE(t3) :: y 39 IF (ASSOCIATED(y%e)) DEALLOCATE(y%e) 40 END SUBROUTINE 41END MODULE 42 SUBROUTINE example 530 2006/01/05 WORKING DRAFT J3/07-007 1 2 USE m 3 TYPE(t1) x1 4 TYPE(t2) x2 5 TYPE(t3) x3 6 ... 7 ! Returning from this subroutine will effectively do 8 ! ! Nothing to x1; it is not finalizable 9 ! CALL t2f(x2) 10 ! CALL t3f(x3) 11 ! CALL t2f(x3%t2) 12END SUBROUTINE 13C.2 Clause 5 notes C.2.1 The POINTER attribute (5.3.13) 14 15The POINTER attribute shall be specified to declare a pointer. The type, type parameters, and rank, 16which may be specified in the same statement or with one or more attribute specification statements, 17determine the characteristics of the target objects that may be associated with the pointers declared 18in the statement. An obvious model for interpreting declarations of pointers is that such declarations 19create for each name a descriptor. Such a descriptor includes all the data necessary to describe fully 20and locate in memory an object and all subobjects of the type, type parameters, and rank specified. 21The descriptor is created empty; it does not contain values describing how to access an actual memory 22space. These descriptor values will be filled in when the pointer is associated with actual target space. 23The following example illustrates the use of pointers in an iterative algorithm: 24PROGRAM DYNAM_ITER 25 REAL, DIMENSION (:, :), POINTER :: A, B, SWAP ! Declare pointers 26 ... 27 READ (*, *) N, M 28 ALLOCATE (A (N, M), B (N, M)) ! Allocate target arrays 29 ! Read values into A 30 ... 31 ITER: DO 32 ... 33 ! Apply transformation of values in A to produce values in B 34 ... 35 IF (CONVERGED) EXIT ITER 36 ! Swap A and B 37 SWAP => A; A => B; B => SWAP 38 END DO ITER 39 ... 40END PROGRAM DYNAM_ITER C.2.2 The TARGET attribute (5.3.16) 531 J3/07-007 WORKING DRAFT 2006/01/05 1 2The TARGET attribute shall be specified for any nonpointer object that may, during the execution of the 3program, become associated with a pointer. This attribute is defined primarily for optimization purposes. 4It allows the processor to assume that any nonpointer object not explicitly declared as a target may 5be referred to only by way of its original declared name. It also means that implicitly-declared objects 6shall not be used as pointer targets. This will allow a processor to perform optimizations that otherwise 7would not be possible in the presence of certain pointers. 8The following example illustrates the use of the TARGET attribute in an iterative algorithm: 9PROGRAM ITER 10 REAL, DIMENSION (1000, 1000), TARGET :: A, B 11 REAL, DIMENSION (:, :), POINTER :: IN, OUT, SWAP 12 ... 13 ! Read values into A 14 ... 15 IN => A ! Associate IN with target A 16 OUT => B ! Associate OUT with target B 17 ... 18 ITER:DO 19 ... 20 ! Apply transformation of IN values to produce OUT 21 ... 22 IF (CONVERGED) EXIT ITER 23 ! Swap IN and OUT 24 SWAP => IN; IN => OUT; OUT => SWAP 25 END DO ITER 26 ... 27END PROGRAM ITER C.2.3 The VOLATILE attribute (5.3.18) 28 29The following example shows the use of a variable with the VOLATILE attribute to communicate with 30an asynchronous process, in this case the operating system. The program detects a user keystroke on 31the terminal and reacts at a convenient point in its processing. 32The VOLATILE attribute is necessary to prevent an optimizing compiler from storing the communication 33variable in a register or from doing flow analysis and deciding that the EXIT statement can never be 34executed. 35SUBROUTINE TERMINATE_ITERATIONS 36 37 LOGICAL, VOLATILE :: USER_HIT_ANY_KEY 38 39! Have the OS start to look for a user keystroke and set the variable 40! "USER_HIT_ANY_KEY" to TRUE as soon as it detects a keystroke. 41! This pseudo call is operating system dependent. 532 2006/01/05 WORKING DRAFT J3/07-007 1 2 CALL OS_BEGIN_DETECT_USER_KEYSTROKE( USER_HIT_ANY_KEY ) 3 4 USER_HIT_ANY_KEY = .FALSE. ! This will ignore any recent keystrokes 5 6 PRINT *, " Hit any key to terminate iterations!" 7 8 DO I = 1,100 9 ... ! Compute a value for R 10 PRINT *, I, R 11 IF (USER_HIT_ANY_KEY) EXIT 12 ENDDO 13 14! Have the OS stop looking for user keystrokes 15 CALL OS_STOP_DETECT_USER_KEYSTROKE 16 17END SUBROUTINE TERMINATE_ITERATIONS 18C.3 Clause 6 notes C.3.1 Structure components (6.1.2) 19 20Components of a structure are referenced by writing the components of successive levels of the structure 21hierarchy until the desired component is described. For example, 22TYPE ID_NUMBERS 23 INTEGER SSN 24 INTEGER EMPLOYEE_NUMBER 25END TYPE ID_NUMBERS 26 27TYPE PERSON_ID 28 CHARACTER (LEN=30) LAST_NAME 29 CHARACTER (LEN=1) MIDDLE_INITIAL 30 CHARACTER (LEN=30) FIRST_NAME 31 TYPE (ID_NUMBERS) NUMBER 32END TYPE PERSON_ID 33 34TYPE PERSON 35 INTEGER AGE 36 TYPE (PERSON_ID) ID 37END TYPE PERSON 38 39TYPE (PERSON) GEORGE, MARY 40 PRINT *, GEORGE % AGE ! Print the AGE component 533 J3/07-007 WORKING DRAFT 2006/01/05 1 2PRINT *, MARY % ID % LAST_NAME ! Print LAST_NAME of MARY 3PRINT *, MARY % ID % NUMBER % SSN ! Print SSN of MARY 4PRINT *, GEORGE % ID % NUMBER ! Print SSN and EMPLOYEE_NUMBER of GEORGE 5A structure component may be a data object of intrinsic type as in the case of GEORGE % AGE or it 6may be of derived type as in the case of GEORGE % ID % NUMBER. The resultant component may 7be a scalar or an array of intrinsic or derived type. 8TYPE LARGE 9 INTEGER ELT (10) 10 INTEGER VAL 11END TYPE LARGE 12 13TYPE (LARGE) A (5) ! 5 element array, each of whose elements 14 ! includes a 10 element array ELT and 15 ! a scalar VAL. 16PRINT *, A (1) ! Prints 10 element array ELT and scalar VAL. 17PRINT *, A (1) % ELT (3) ! Prints scalar element 3 18 ! of array element 1 of A. 19PRINT *, A (2:4) % VAL ! Prints scalar VAL for array elements 20 ! 2 to 4 of A. 21Components of an object of extensible type that are inherited from the parent type may be accessed as 22a whole by using the parent component name, or individually, either with or without qualifying them 23by the parent component name. 24For example: 25 TYPE POINT ! A base type 26 REAL :: X, Y 27 END TYPE POINT 28 TYPE, EXTENDS(POINT) :: COLOR_POINT ! An extension of TYPE(POINT) 29 ! Components X and Y, and component name POINT, inherited from parent 30 INTEGER :: COLOR 31 END TYPE COLOR_POINT 32 33 TYPE(POINT) :: PV = POINT(1.0, 2.0) 34 TYPE(COLOR_POINT) :: CPV = COLOR_POINT(POINT=PV, COLOR=3) 35 36 PRINT *, CPV%POINT ! Prints 1.0 and 2.0 37 PRINT *, CPV%POINT%X, CPV%POINT%Y ! And this does, too 38 PRINT *, CPV%X, CPV%Y ! And this does, too C.3.2 Allocation with dynamic type (6.3.1) 39 534 2006/01/05 WORKING DRAFT J3/07-007 1The following example illustrates the use of allocation with the value and dynamic type of the allocated 2object given by another object. The example copies a list of objects of any type. It copies the list 3starting at IN LIST. After copying, each element of the list starting at LIST COPY has a polymorphic 4component, ITEM, for which both the value and type are taken from the ITEM component of the 5corresponding element of the list starting at IN LIST. 6TYPE :: LIST ! A list of anything 7 TYPE(LIST), POINTER :: NEXT => NULL() 8 CLASS(*), ALLOCATABLE :: ITEM 9END TYPE LIST 10... 11TYPE(LIST), POINTER :: IN_LIST, LIST_COPY => NULL() 12TYPE(LIST), POINTER :: IN_WALK, NEW_TAIL 13! Copy IN_LIST to LIST_COPY 14IF (ASSOCIATED(IN_LIST)) THEN 15 IN_WALK => IN_LIST 16 ALLOCATE(LIST_COPY) 17 NEW_TAIL => LIST_COPY 18 DO 19 ALLOCATE(NEW_TAIL%ITEM, SOURCE=IN_WALK%ITEM) 20 IN_WALK => IN_WALK%NEXT 21 IF (.NOT. ASSOCIATED(IN_WALK)) EXIT 22 ALLOCATE(NEW_TAIL%NEXT) 23 NEW_TAIL => NEW_TAIL%NEXT 24 END DO 25END IF 26C.3.3 Pointer allocation and association 27The effect of ALLOCATE, DEALLOCATE, NULLIFY, and pointer assignment is that they are inter- 28preted as changing the values in the descriptor that is the pointer. An ALLOCATE is assumed to create 29space for a suitable object and to "assign" to the pointer the values necessary to describe that space. 30A NULLIFY breaks the association of the pointer with the space. A DEALLOCATE breaks the asso- 31ciation and releases the space. Depending on the implementation, it could be seen as setting a flag in 32the pointer that indicates whether the values in the descriptor are valid, or it could clear the descriptor 33values to some (say zero) value indicative of the pointer not pointing to anything. A pointer assignment 34copies the values necessary to describe the space occupied by the target into the descriptor that is the 35pointer. Descriptors are copied, values of objects are not. 36If PA and PB are both pointers and PB is associated with a target, then 37PA => PB 38results in PA being associated with the same target as PB. If PB was disassociated, then PA becomes 39disassociated. 40This part of ISO/IEC 1539 is specified so that such associations are direct and independent. A subsequent 41statement 42PB => D 535 J3/07-007 WORKING DRAFT 2006/01/05 1or 2ALLOCATE (PB) 3has no effect on the association of PA with its target. A statement 4DEALLOCATE (PB) 5deallocates the space that is associated with both PA and PB. PB becomes disassociated, but there is 6no requirement that the processor make it explicitly recognizable that PA no longer has a target. This 7leaves PA as a "dangling pointer" to space that has been released. The program shall not use PA again 8until it becomes associated via pointer assignment or an ALLOCATE statement. 9DEALLOCATE may only be used to release space that was created by a previous ALLOCATE. Thus 10the following is invalid: 11REAL, TARGET :: T 12REAL, POINTER :: P 13 ... 14P = > T 15DEALLOCATE (P) ! Not allowed: P's target was not allocated 16The basic principle is that ALLOCATE, NULLIFY, and pointer assignment primarily affect the pointer 17rather than the target. ALLOCATE creates a new target but, other than breaking its connection with 18the specified pointer, it has no effect on the old target. Neither NULLIFY nor pointer assignment has 19any effect on targets. A piece of memory that was allocated and associated with a pointer will become 20inaccessible to a program if the pointer is nullified or associated with a different target and no other 21pointer was associated with this piece of memory. Such pieces of memory may be reused by the processor 22if this is expedient. However, whether such inaccessible memory is in fact reused is entirely processor 23dependent. 24C.4 Clause 7 notes C.4.1 Character assignment 25 26The Fortran 77 restriction that none of the character positions being defined in the character assign- ment statement may be referenced in the expression has been removed (7.2.1.3). 27 28C.4.2 Evaluation of function references 29If more than one function reference appears in a statement, they may be executed in any order (subject to 30a function result being evaluated after the evaluation of its arguments) and their values shall not depend 31on the order of execution. This lack of dependence on order of evaluation permits parallel execution of the function references (7.1.7). 32 C.4.3 Pointers in expressions 33 34A pointer is basically considered to be like any other variable when it is used as a primary in an expression. 35If a pointer is used as an operand to an operator that expects a value, the pointer will automatically 36deliver the value stored in the space described by the pointer, that is, the value of the target object 37associated with the pointer. 536 2006/01/05 WORKING DRAFT J3/07-007 C.4.4 Pointers on the left side of an assignment 1 2A pointer that appears on the left of an intrinsic assignment statement also is dereferenced and is taken 3to be referring to the space that is its current target. Therefore, the assignment statement specifies the 4normal copying of the value of the right-hand expression into this target space. All the normal rules of 5intrinsic assignment hold; the type and type parameters of the expression and the pointer target shall 6agree and the shapes shall be conformable. 7For intrinsic assignment of derived types, nonpointer components are assigned and pointer components 8are pointer assigned. Dereferencing is applied only to entire scalar objects, not selectively to pointer 9subobjects. 10For example, suppose a type such as 11TYPE CELL 12 INTEGER :: VAL 13 TYPE (CELL), POINTER :: NEXT_CELL 14END TYPE CELL 15is defined and objects such as HEAD and CURRENT are declared using 16TYPE (CELL), TARGET :: HEAD 17TYPE (CELL), POINTER :: CURRENT 18If a linked list has been created and attached to HEAD and the pointer CURRENT has been allocated 19space, statements such as 20CURRENT = HEAD 21CURRENT = CURRENT % NEXT_CELL 22cause the contents of the cells referenced on the right to be copied to the cell referred to by CURRENT. 23In particular, the right-hand side of the second statement causes the pointer component in the cell, 24CURRENT, to be selected. This pointer is dereferenced because it is in an expression context to produce 25the target's integer value and a pointer to a cell that is in the target's NEXT CELL component. The 26left-hand side causes the pointer CURRENT to be dereferenced to produce its present target, namely 27space to hold a cell (an integer and a cell pointer). The integer value on the right is copied to the integer 28space on the left and the pointer component is pointer assigned (the descriptor on the right is copied into the space for a descriptor on the left). When a statement such as 29 30CURRENT => CURRENT % NEXT_CELL 31is executed, the descriptor value in CURRENT % NEXT CELL is copied to the descriptor named 32CURRENT. In this case, CURRENT is made to point at a different target. 33In the intrinsic assignment statement, the space associated with the current pointer does not change but 34the values stored in that space do. In the pointer assignment, the current pointer is made to associate 35with different space. Using the intrinsic assignment causes a linked list of cells to be moved up through 36the current "window"; the pointer assignment causes the current pointer to be moved down through the 37list of cells. C.4.5 An example of a FORALL construct containing a WHERE construct 38 INTEGER :: A(5,5) 537 J3/07-007 WORKING DRAFT 2006/01/05 1 2... 3FORALL (I = 1:5) 4 WHERE (A(I,:) == 0) 5 A(:,I) = I 6 ELSEWHERE (A(I,:) > 2) 7 A(I,:) = 6 8 END WHERE 9END FORALL 10If prior to execution of the FORALL, A has the value 11A = 1 0 0 0 0 12 2 1 1 1 0 13 1 2 2 0 2 14 2 1 0 2 3 15 1 0 0 0 0 16After execution of the assignment statements following the WHERE statement A has the value A'. The 17mask created from row one is used to mask the assignments to column one; the mask from row two is 18used to mask assignments to column two; etc. 19A' = 1 0 0 0 0 20 1 1 1 1 5 21 1 2 2 4 5 22 1 1 3 2 5 23 1 2 0 0 5 24The masks created for assignments following the ELSEWHERE statement are 25.NOT. (A(I,:) == 0) .AND. (A'(I,:) > 2) 26Thus the only elements affected by the assignments following the ELSEWHERE statement are A(3, 5) and A(4, 5). After execution of the FORALL construct, A has the value 27 28A = 1 0 0 0 0 29 1 1 1 1 5 30 1 2 2 4 6 31 1 1 3 2 6 32 1 2 0 0 5 C.4.6 Examples of FORALL statements 33 34Example 1: 35FORALL (J=1:M, K=1:N) X(K, J) = Y(J, K) FORALL (K=1:N) X(K, 1:M) = Y(1:M, K) 538 2006/01/05 WORKING DRAFT J3/07-007 1 2These statements both copy columns 1 through N of array Y into rows 1 through N of array X. They 3are equivalent to 4X(1:N, 1:M) = TRANSPOSE (Y(1:M, 1:N) ) 5Example 2: 6The following FORALL statement computes five partial sums of subarrays of J. 7J = (/ 1, 2, 3, 4, 5 /) 8FORALL (K = 1:5) J(K) = SUM (J(1:K) ) 9SUM is allowed in a FORALL because intrinsic functions are pure (12.7). After execution of the FORALL statement, J is equal to [1, 3, 6, 10, 15]. 10 11Example 3: 12FORALL (I = 2:N-1) X(I) = (X(I-1) + 2*X(I) + X(I+1) ) / 4 13has the same effect as 14X(2:N-1) = (X(1:N-2) + 2*X(2:N-1) + X(3:N) ) / 4 15C.5 Clause 8 notes C.5.1 Loop control 16 17Fortran provides several forms of loop control: (1) With an iteration count and a DO variable. This is the classic Fortran DO loop. 18 (2) Test a logical condition before each execution of the loop (DO WHILE). 19 (3) DO "forever". 20 21C.5.2 The CASE construct 22At most one case block is selected for execution within a CASE construct, and there is no fall-through 23from one block into another block within a CASE construct. Thus there is no requirement for the user 24to exit explicitly from a block. C.5.3 Examples of DO constructs 25 26The following are all valid examples of block DO constructs. 27Example 1: 28 SUM = 0.0 29 READ (IUN) N 30 OUTER: DO L = 1, N ! A DO with a construct name 31 READ (IUN) IQUAL, M, ARRAY (1:M) 32 IF (IQUAL < IQUAL_MIN) CYCLE OUTER ! Skip inner loop 33 INNER: DO 40 I = 1, M ! A DO with a label and a name 539 J3/07-007 WORKING DRAFT 2006/01/05 1 CALL CALCULATE (ARRAY (I), RESULT) 2 IF (RESULT < 0.0) CYCLE 3 SUM = SUM + RESULT 4 IF (SUM > SUM_MAX) EXIT OUTER 5 40 END DO INNER 6 END DO OUTER 7The outer loop has an iteration count of MAX (N, 0), and will execute that number of times or until 8SUM exceeds SUM MAX, in which case the EXIT OUTER statement terminates both loops. The inner 9loop is skipped by the first CYCLE statement if the quality flag, IQUAL, is too low. If CALCULATE 10returns a negative RESULT, the second CYCLE statement prevents it from being summed. Both loops 11have construct names and the inner loop also has a label. A construct name is required in the EXIT 12statement in order to terminate both loops, but is optional in the CYCLE statements because each 13belongs to its innermost loop. 14Example 2: 15 N = 0 16 DO 50, I = 1, 10 17 J = I 18 DO K = 1, 5 19 L = K 20 N = N + 1 ! This statement executes 50 times 21 END DO ! Nonlabeled DO inside a labeled DO 22 50 CONTINUE 23After execution of the above program fragment, I = 11, J = 10, K = 6, L = 5, and N = 50. 24Example 3: 25 N = 0 26 DO I = 1, 10 27 J = I 28 DO 60, K = 5, 1 ! This inner loop is never executed 29 L = K 30 N = N + 1 31 60 CONTINUE ! Labeled DO inside a nonlabeled DO 32 END DO 33After execution of the above program fragment, I = 11, J = 10, K = 5, N = 0, and L is not defined by 34these statements. 35 The following are all valid examples of nonblock DO constructs: 36 Example 4: 37 DO 70 38 READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X 540 2006/01/05 WORKING DRAFT J3/07-007 1 IF (IOS /= 0) EXIT 2 IF (X < 0.) GOTO 70 3 CALL SUBA (X) 4 CALL SUBB (X) 5 ... 6 CALL SUBY (X) 7 CYCLE 8 70 CALL SUBNEG (X) ! SUBNEG called only when X < 0. 9 This is not a block DO construct because it ends with a statement other than END DO or CONTINUE. The loop will 10 continue to execute until an end-of-file condition or input/output error occurs. 11 Example 5: 12 SUM = 0.0 13 READ (IUN) N 14 DO 80, L = 1, N 15 READ (IUN) IQUAL, M, ARRAY (1:M) 16 IF (IQUAL < IQUAL_MIN) M = 0 ! Skip inner loop 17 DO 80 I = 1, M 18 CALL CALCULATE (ARRAY (I), RESULT) 19 IF (RESULT < 0.) CYCLE 20 SUM = SUM + RESULT 21 IF (SUM > SUM_MAX) GOTO 81 22 80 CONTINUE ! This CONTINUE is shared by both loops 23 81 CONTINUE 24 This example is similar to Example 1 above, except that the two loops are not block DO constructs because they share 25 the CONTINUE statement with the label 80. The terminal construct of the outer DO is the entire inner DO construct. 26 The inner loop is skipped by forcing M to zero. If SUM grows too large, both loops are terminated by branching to the 27 CONTINUE statement labeled 81. The CYCLE statement in the inner loop is used to skip negative values of RESULT. 28 Example 6: 29 N = 0 30 DO 100 I = 1, 10 31 J = I 32 DO 100 K = 1, 5 33 L = K 34 100 N = N + 1 ! This statement executes 50 times 35 In this example, the two loops share an assignment statement. After execution of this program fragment, I = 11, J = 10, 36 K = 6, L = 5, and N = 50. 37 Example 7: 38 N = 0 39 DO 200 I = 1, 10 40 J = I 41 DO 200 K = 5, 1 ! This inner loop is never executed 42 L = K 43 200 N = N + 1 44 This example is very similar to the previous one, except that the inner loop is never executed. After execution of this 45 program fragment, I = 11, J = 10, K = 5, N = 0, and L is not defined by these statements. 541 J3/07-007 WORKING DRAFT 2006/01/05 C.5.4 Examples of invalid DO constructs 1 2The following are all examples of invalid skeleton DO constructs: 3Example 1: 4DO I = 1, 10 5 ... 6END DO LOOP ! No matching construct name 7Example 2: 8LOOP: DO 1000 I = 1, 10 ! No matching construct name 9 ... 101000 CONTINUE 11Example 3: 12LOOP1: DO 13 ... 14END DO LOOP2 ! Construct names don't match 15Example 4: 16DO I = 1, 10 ! Label required or ... 17 ... 181010 CONTINUE ! ... END DO required 19Example 5: 20DO 1020 I = 1, 10 21 ... 221021 END DO ! Labels don't match 23Example 6: 24FIRST: DO I = 1, 10 25 SECOND: DO J = 1, 5 26 ... 27 END DO FIRST ! Improperly nested DOs 28END DO SECOND 542 2006/01/05 WORKING DRAFT J3/07-007 1C.6 Clause 9 notes C.6.1 External files (9.2) 2 3This part of ISO/IEC 1539 accommodates, but does not require, file cataloging. To do this, several 4concepts are introduced. C.6.1.1 File connection (9.4) 5 6Before any input/output may be performed on a file, it shall be connected to a unit. The unit then serves 7as a designator for that file as long as it is connected. To be connected does not imply that "buffers" 8have or have not been allocated, that "file-control tables" have or have not been filled, or that any other 9method of implementation has been used. Connection means that (barring some other fault) a READ 10or WRITE statement may be executed on the unit, hence on the file. Without a connection, a READ 11or WRITE statement shall not be executed. C.6.1.2 File existence (9.2.1) 12 13Totally independent of the connection state is the property of existence, this being a file property. The 14processor "knows" of a set of files that exist at a given time for a given program. This set would include 15tapes ready to read, files in a catalog, a keyboard, a printer, etc. The set may exclude files inaccessible 16to the program because of security, because they are already in use by another program, etc. This part 17of ISO/IEC 1539 does not specify which files exist, hence wide latitude is available to a processor to 18implement security, locks, privilege techniques, etc. Existence is a convenient concept to designate all of 19the files that a program can potentially process. 20All four combinations of connection and existence may occur: Connect Exist Examples Yes Yes A card reader loaded and ready to be read Yes No A printer before the first line is written No Yes A file named 'JOAN' in the catalog No No A file on a reel of tape, not known to the processor 21Means are provided to create, delete, connect, and disconnect files. C.6.1.3 File names (9.4.5.8) 22 23A file may have a name. The form of a file name is not specified. If a system does not have some form of 24cataloging or tape labeling for at least some of its files, all file names will disappear at the termination 25of execution. This is a valid implementation. Nowhere does this part of ISO/IEC 1539 require names to 26survive for any period of time longer than the execution time span of a program. Therefore, this part 27of ISO/IEC 1539 does not impose cataloging as a prerequisite. The naming feature is intended to allow 28use of a cataloging system where one exists. C.6.1.4 File access (9.2.2) 29 30This part of ISO/IEC 1539 does not address problems of security, protection, locking, and many other 31concepts that may be part of the concept of "right of access". Such concepts are considered to be in the 32province of an operating system. 33The OPEN and INQUIRE statements can be extended naturally to consider these things. 543 J3/07-007 WORKING DRAFT 2006/01/05 1Possible access methods for a file are: sequential and direct. The processor may implement two different 2types of files, each with its own access method. It might also implement one type of file with two different 3access methods. 4Direct access to files is of a simple and commonly available type, that is, fixed-length records. The key 5is a positive integer. C.6.2 Nonadvancing input/output (9.2.3.1) 6 7Data transfer statements affect the positioning of an external file. In Fortran 77, if no error or end-of- 8file condition exists, the file is positioned after the record just read or written and that record becomes 9the preceding record. This part of ISO/IEC 1539 contains the record positioning ADVANCE= specifier 10in a data transfer statement that provides the capability of maintaining a position within the current 11record from one formatted data transfer statement to the next data transfer statement. The value NO 12provides this capability. The value YES positions the file after the record just read or written. The 13default is YES. 14The tab edit descriptor and the slash are still appropriate for use with this type of record access but the 15tab will not reposition before the left tab limit. 16A BACKSPACE of a file that is positioned within a record causes the specified unit to be positioned 17before the current record. 18If the last data transfer statement was WRITE and the file is positioned within a record, the file will be 19positioned implicitly after the current record before an ENDFILE record is written to the file, that is, a 20REWIND, BACKSPACE, or ENDFILE statement following a nonadvancing WRITE statement causes 21the file to be positioned at the end of the current output record before the endfile record is written to 22the file. 23This part of ISO/IEC 1539 provides a SIZE= specifier to be used with nonadvancing data transfer 24statements. The variable in the SIZE= specifier will contain the count of the number of characters that 25make up the sequence of values read by the data edit descriptors in this input statement. 26The count is especially helpful if there is only one list item in the input list because it will contain the 27number of characters that were present for the item. 28The EOR= specifier is provided to indicate when an end-of-record condition has been encountered 29during a nonadvancing data transfer statement. The end-of-record condition is not an error condition. 30If this specifier is present, the current input list item that required more characters than the record 31contained will be padded with blanks if PAD= 'YES' is in effect. This means that the input list item 32was successfully completed. The file will then be positioned after the current record. The IOSTAT= 33specifier, if present, will be defined with the value of the named constant IOSTAT EOR from the ISO - 34FORTRAN ENV module and the data transfer statement will be terminated. Program execution will 35continue with the statement specified in the EOR= specifier. The EOR= specifier gives the capability 36of taking control of execution when the end-of-record has been found. The do-variables in io-implied- 37dos retain their last defined value and any remaining items in the input-item-list retain their definition 38status when an end-of-record condition occurs. The SIZE= specifier, if present, will contain the number 39of characters read with the data edit descriptors during this READ statement. 40For nonadvancing input, the processor is not required to read partial records. The processor may read 41the entire record into an internal buffer and make successive portions of the record available to successive 42input statements. 43In an implementation of nonadvancing input/output in which a nonadvancing write to a terminal device 44causes immediate display of the output, such a write can be used as a mechanism to output a prompt. 45In this case, the statement 544 2006/01/05 WORKING DRAFT J3/07-007 1WRITE (*, FMT='(A)', ADVANCE='NO') 'CONTINUE?(Y/N): ' 2would result in the prompt 3CONTINUE?(Y/N): 4being displayed with no subsequent line feed. 5The response, which might be read by a statement of the form 6READ (*, FMT='(A)') ANSWER 7can then be entered on the same line as the prompt as in 8CONTINUE?(Y/N): Y 9This part of ISO/IEC 1539 does not require that an implementation of nonadvancing input/output 10operate in this manner. For example, an implementation of nonadvancing output in which the display 11of the output is deferred until the current record is complete is also standard-conforming. Such an 12implementation will not, however, allow a prompting mechanism of this kind to operate. C.6.3 Asynchronous input/output 13 14Rather than limit support for asynchronous input/output to what has been traditionally provided by 15facilities such as BUFFERIN/BUFFEROUT, this part of ISO/IEC 1539 builds upon existing Fortran 16syntax. This permits alternative approaches for implementing asynchronous input/output, and simplifies the task of adapting existing standard-conforming programs to use asynchronous input/output. 17 18Not all processors will actually perform input/output asynchronously, nor will every processor that does 19be able to handle data transfer statements with complicated input/output item lists in an asynchronous 20manner. Such processors can still be standard-conforming. Hopefully, the documentation for each Fortran processor will describe when, if ever, input/output will be performed asynchronously. 21 22This part of ISO/IEC 1539 allows for at least two different conceptual models for asynchronous in- put/output. 23 24Model 1: the processor will perform asynchronous input/output when the item list is simple (perhaps 25one contiguous named array) and the input/output is unformatted. The implementation cost is reduced, 26and this is the scenario most likely to be beneficial on traditional "big-iron" machines. 27Model 2: The processor is free to do any of the following: 28 (1) on output, create a buffer inside the input/output library, completely formatted, and then 29 start an asynchronous write of the buffer, and immediately return to the next statement in 30 the program. The processor is free to wait for previously issued WRITEs, or not, or 31 (2) pass the input/output list addresses to another processor/process, which will process the 32 list items independently of the processor that executes the user's code. The addresses of the 33 list items must be computed before the asynchronous READ/WRITE statement completes. 34 There is still an ordering requirement on list item processing to handle things like READ (...) N,(a(i),i=1,N). 35 36This part of ISO/IEC 1539 allows a user to issue a large number of asynchronous input/output requests, 37without waiting for any of them to complete, and then wait for any or all of them. It may be impossible, and undesirable to keep track of each of these input/output requests individually. 38 39It is not necessary for all requests to be tracked by the runtime library. If an ID= specifier does not 40appear in on a READ or WRITE statement, the runtime is free to forget about this particular request 41once it has successfully completed. If it gets an ERR or END condition, the processor is free to report 545 J3/07-007 WORKING DRAFT 2006/01/05 1this during any input/output operation to that unit. When an ID= specifier is present, the processor's 2runtime input/output library is required to keep track of any END or ERR conditions for that particular 3input/output request. However, if the input/output request succeeds without any exceptional conditions 4occurring, then the runtime can forget that ID= value if it wishes. Typically, a runtime might only keep 5track of the last request made, or perhaps a very few. Then, when a user WAITs for a particular request, 6either the library knows about it (and does the right thing with respect to error handling, etc.), or will 7assume it is one of those requests that successfully completed and was forgotten about (and will just 8return without signaling any end or error conditions). It is incumbent on the user to pass valid ID= 9values. There is no requirement on the processor to detect invalid ID= values. There is of course, 10a processor dependent limit on how many outstanding input/output requests that generate an end or 11error condition can be handled before the processor runs out of memory to keep track of such conditions. 12The restrictions on the SIZE= variables are designed to allow the processor to update such variables at 13any time (after the request has been processed, but before the WAIT operation), and then forget about 14them. That's why there is no SIZE= specifier allowed in the various WAIT operations. Only exceptional 15conditions (errors or ends of files) are expected to be tracked by individual request by the runtime, and 16then only if an ID= specifier was present. The END= and EOR= specifiers have not been added to all 17statements that can be WAIT operations. Instead, the IOSTAT variable will have to be queried after a 18WAIT operation to handle this situation. This choice was made because we expect the WAIT statement 19to be the usual method of waiting for input/output to complete (and WAIT does support the END= 20and EOR= specifiers). This particular choice is philosophical, and was not based on significant technical 21difficulties. 22Note that the requirement to set the IOSTAT variable correctly requires an implementation to remember 23which input/output requests got an EOR condition, so that a subsequent wait operation will return the 24correct IOSTAT value. This means there is a processor defined limit on the number of outstanding 25nonadvancing input/output requests that got an EOR condition (constrained by available memory to keep track of this information, similar to END/ERR conditions). 26 C.6.4 OPEN statement (9.4.5) 27 28A file may become connected to a unit either by preconnection or by execution of an OPEN statement. 29Preconnection is performed prior to the beginning of execution of a program by means external to For- 30tran. For example, it may be done by job control action or by processor-established defaults. Execution of an OPEN statement is not required to access preconnected files (9.4.4). 31 32The OPEN statement provides a means to access existing files that are not preconnected. An OPEN 33statement may be used in either of two ways: with a file name (open-by-name) and without a file name 34(open-by-unit). A unit is given in either case. Open-by-name connects the specified file to the specified 35unit. Open-by-unit connects a processor-dependent default file to the specified unit. (The default file might or might not have a name.) 36 37Therefore, there are three ways a file may become connected and hence processed: preconnection, open- 38by-name, and open-by-unit. Once a file is connected, there is no means in standard Fortran to determine 39how it became connected. 40An OPEN statement may also be used to create a new file. In fact, any of the foregoing three connection 41methods may be performed on a file that does not exist. When a unit is preconnected, writing the first 42record creates the file. With the other two methods, execution of the OPEN statement creates the file. 43When an OPEN statement is executed, the unit specified in the OPEN might or might not already be 44connected to a file. If it is already connected to a file (either through preconnection or by a prior OPEN), 45then omitting the FILE= specifier in the OPEN statement implies that the file is to remain connected 46to the unit. Such an OPEN statement may be used to change the values of the blank interpretation mode, decimal edit mode, pad mode, input/output rounding mode, delimiter mode, and sign mode. 47 546 2006/01/05 WORKING DRAFT J3/07-007 1If the value of the ACTION= specifier is WRITE, then READ statements shall not refer to this connec- 2tion. ACTION = 'WRITE' does not restrict positioning by a BACKSPACE statement or positioning 3specified by the POSITION= specifier with the value APPEND. However, a BACKSPACE statement 4or an OPEN statement containing POSITION = 'APPEND' may fail if the processor requires reading 5of the file to achieve the positioning. 6The following examples illustrate these rules. In the first example, unit 10 is preconnected to a SCRATCH 7file; the OPEN statement changes the value of PAD= to YES. 8CHARACTER (LEN = 20) CH1 9WRITE (10, '(A)') 'THIS IS RECORD 1' 10OPEN (UNIT = 10, STATUS = 'OLD', PAD = 'YES') 11REWIND 10 12READ (10, '(A20)') CH1 ! CH1 now has the value 13 ! 'THIS IS RECORD 1 ' 14In the next example, unit 12 is first connected to a file named FRED, with a status of OLD. The second 15OPEN statement then opens unit 12 again, retaining the connection to the file FRED, but changing the 16value of the DELIM= specifier to QUOTE. 17CHARACTER (LEN = 25) CH2, CH3 18OPEN (12, FILE = 'FRED', STATUS = 'OLD', DELIM = 'NONE') 19CH2 = '''THIS STRING HAS QUOTES.''' 20 ! Quotes in string CH2 21WRITE (12, *) CH2 ! Written with no delimiters 22OPEN (12, DELIM = 'QUOTE') ! Now quote is the delimiter 23REWIND 12 24READ (12, *) CH3 ! CH3 now has the value 25 ! 'THIS STRING HAS QUOTES. ' 26The next example is invalid because it attempts to change the value of the STATUS= specifier. 27OPEN (10, FILE = 'FRED', STATUS = 'OLD') 28WRITE (10, *) A, B, C 29OPEN (10, STATUS = 'SCRATCH') ! Attempts to make FRED 30 ! a SCRATCH file 31The previous example could be made valid by closing the unit first, as in the next example. 32OPEN (10, FILE = 'FRED', STATUS = 'OLD') 33WRITE (10, *) A, B, C 34CLOSE (10) 35OPEN (10, STATUS = 'SCRATCH') ! Opens a different 36 ! SCRATCH file 547 J3/07-007 WORKING DRAFT 2006/01/05 C.6.5 Connection properties (9.4.3) 1 2When a unit becomes connected to a file, either by execution of an OPEN statement or by preconnection, 3the following connection properties, among others, may be established. 4 (1) An access method, which is sequential, direct, or stream, is established for the connection (9.4.5.1). 5 6 (2) A form, which is formatted or unformatted, is established for a connection to a file that 7 exists or is created by the connection. For a connection that results from execution of an 8 OPEN statement, a default form (which depends on the access method, as described in 9 9.2.2) is established if no form is specified. For a preconnected file that exists, a form is 10 established by preconnection. For a preconnected file that does not exist, a form may be 11 established, or the establishment of a form may be delayed until the file is created (for example, by execution of a formatted or unformatted WRITE statement) (9.4.5.9). 12 13 (3) A record length may be established. If the access method is direct, the connection establishes 14 a record length that specifies the length of each record of the file. An existing file with records 15 that are not all of equal length shall not be connected for direct access. 16 If the access method is sequential, records of varying lengths are permitted. In this case, the record length established specifies the maximum length of a record in the file (9.4.5.13). 17 18A processor has wide latitude in adapting these concepts and actions to its own cataloging and job 19control conventions. Some processors may require job control action to specify the set of files that 20exist or that will be created by a program. Some processors may require no job control action prior to 21execution. This part of ISO/IEC 1539 enables processors to perform dynamic open, close, or file creation 22operations, but it does not require such capabilities of the processor. 23The meaning of "open" in contexts other than Fortran may include such things as mounting a tape, 24console messages, spooling, label checking, security checking, etc. These actions may occur upon job 25control action external to Fortran, upon execution of an OPEN statement, or upon execution of the first 26read or write of the file. The OPEN statement describes properties of the connection to the file and 27might or might not cause physical activities to take place. It is a place for an implementation to define 28properties of a file beyond those required in standard Fortran. C.6.6 CLOSE statement (9.4.6) 29 30Similarly, the actions of dismounting a tape, protection, etc. of a "close" may be implicit at the end of 31a run. The CLOSE statement might or might not cause such actions to occur. This is another place to 32extend file properties beyond those of standard Fortran. Note, however, that the execution of a CLOSE 33statement on a unit followed by an OPEN statement on the same unit to the same file or to a different 34file is a permissible sequence of events. The processor shall not deny this sequence solely because the 35implementation chooses to do the physical act of closing the file at the termination of execution of the 36program. 37C.7 Clause 10 notes C.7.1 Number of records (10.4, 10.5, 10.8.2) 38 39The number of records read by an explicitly formatted advancing input statement can be determined 40from the following rule: a record is read at the beginning of the format scan (even if the input list is 41empty), at each slash edit descriptor encountered in the format, and when a format rescan occurs at the 42end of the format. 43The number of records written by an explicitly formatted advancing output statement can be determined 44from the following rule: a record is written when a slash edit descriptor is encountered in the format, 548 2006/01/05 WORKING DRAFT J3/07-007 1when a format rescan occurs at the end of the format, and at completion of execution of the output 2statement (even if the output list is empty). Thus, the occurrence of n successive slashes between two 3other edit descriptors causes n - 1 blank lines if the records are printed. The occurrence of n slashes at 4the beginning or end of a complete format specification causes n blank lines if the records are printed. 5However, a complete format specification containing n slashes (n > 0) and no other edit descriptors 6causes n + 1 blank lines if the records are printed. For example, the statements 7 PRINT 3 83 FORMAT (/) 9will write two records that cause two blank lines if the records are printed. C.7.2 List-directed input (10.10.3) 10 11The following examples illustrate list-directed input. A blank character is represented by b. 12Example 1: 13Program: 14J = 3 15READ *, I 16READ *, J 17Sequential input file: 18record 1: b1b,4bbbbb 19record 2: ,2bbbbbbbb 20Result: I = 1, J = 3. 21Explanation: The second READ statement reads the second record. The initial comma in the record 22designates a null value; therefore, J is not redefined. 23Example 2: 24Program: 25CHARACTER A *8, B *1 26READ *, A, B 27Sequential input file: 28record 1: 'bbbbbbbb' 29record 2: 'QXY'b'Z' 30Result: A = 'bbbbbbbb', B = 'Q' 31Explanation: In the first record, the rightmost apostrophe is interpreted as delimiting the constant (it 32cannot be the first of a pair of embedded apostrophes representing a single apostrophe because this 549 J3/07-007 WORKING DRAFT 2006/01/05 1would involve the prohibited "splitting" of the pair by the end of a record); therefore, A is assigned 2the character constant 'bbbbbbbb'. The end of a record acts as a blank, which in this case is a value 3separator because it occurs between two constants. 4C.8 Clause 11 notes C.8.1 Main program and block data program unit (11.1, 11.3) 5 6The name of the main program or of a block data program unit has no explicit use within the Fortran 7language. It is available for documentation and for possible use by a processor. 8A processor may implement an unnamed main program or unnamed block data program unit by assigning 9it a default name. However, this name shall not conflict with any other global name in a standard- 10conforming program. This might be done by making the default name one that is not permitted in a 11standard-conforming program (for example, by including a character not normally allowed in names) 12or by providing some external mechanism such that for any given program the default name can be 13changed to one that is otherwise unused. C.8.2 Dependent compilation (11.2) 14 15This part of ISO/IEC 1539, like its predecessors, is intended to permit the implementation of conform- 16ing processors in which a program can be broken into multiple units, each of which can be separately 17translated in preparation for execution. Such processors are commonly described as supporting separate 18compilation. There is an important difference between the way separate compilation can be imple- 19mented under this part of ISO/IEC 1539 and the way it could be implemented under the Fortran 2077 International Standard. Under the Fortran 77 standard, any information required to translate a 21program unit was specified in that program unit. Each translation was thus totally independent of all 22others. Under this part of ISO/IEC 1539, a program unit can use information that was specified in a 23separate module and thus may be dependent on that module. The implementation of this dependency 24in a processor may be that the translation of a program unit may depend on the results of translating 25one or more modules. Processors implementing the dependency this way are commonly described as 26supporting dependent compilation. 27The dependencies involved here are new only in the sense that the Fortran processor is now aware of 28them. The same information dependencies existed under the Fortran 77 International Standard, but 29it was the programmer's responsibility to transport the information necessary to resolve them by making 30redundant specifications of the information in multiple program units. The availability of separate but 31dependent compilation offers several potential advantages over the redundant textual specification of 32information. 33 (1) Specifying information at a single place in the program ensures that different program units 34 using that information will be translated consistently. Redundant specification leaves the 35 possibility that different information will erroneously be specified. Even if an INCLUDE line 36 is used to ensure that the text of the specifications is identical in all involved program units, 37 the presence of other specifications (for example, an IMPLICIT statement) may change the 38 interpretation of that text. 39 (2) During the revision of a program, it is possible for a processor to assist in determining 40 whether different program units have been translated using different (incompatible) versions 41 of a module, although there is no requirement that a processor provide such assistance. 42 Inconsistencies in redundant textual specification of information, on the other hand, tend 43 to be much more difficult to detect. 44 (3) Putting information in a module provides a way of packaging it. Without modules, redun- 45 dant specifications frequently shall be interleaved with other specifications in a program 550 2006/01/05 WORKING DRAFT J3/07-007 1 unit, making convenient packaging of such information difficult. 2 (4) Because a processor may be implemented such that the specifications in a module are 3 translated once and then repeatedly referenced, there is the potential for greater efficiency 4 than when the processor shall translate redundant specifications of information in multiple 5 program units. 6The exact meaning of the requirement that the public portions of a module be available at the time of 7reference is processor dependent. For example, a processor could consider a module to be available only 8after it has been compiled and require that if the module has been compiled separately, the result of 9that compilation shall be identified to the compiler when compiling program units that use it. C.8.2.1 USE statement and dependent compilation (11.2.2) 10 11Another benefit of the USE statement is its enhanced facilities for name management. If one needs to 12use only selected entities in a module, one can do so without having to worry about the names of all 13the other entities in that module. If one needs to use two different modules that happen to contain 14entities with the same name, there are several ways to deal with the conflict. If none of the entities with 15the same name are to be used, they can simply be ignored. If the name happens to refer to the same 16entity in both modules (for example, if both modules obtained it from a third module), then there is no 17confusion about what the name denotes and the name can be freely used. If the entities are different 18and one or both is to be used, the local renaming facility in the USE statement makes it possible to give 19those entities different names in the program unit containing the USE statements. 20A benefit of using the ONLY option consistently, as compared to USE without it, is that the module 21from which each accessed entity is accessed is explicitly specified in each program unit. This means that 22one need not search other program units to find where each one is defined. This reduces maintenance 23costs. 24A typical implementation of dependent but separate compilation may involve storing the result of trans- 25lating a module in a file (or file element) whose name is derived from the name of the module. Note, 26however, that the name of a module is limited only by the Fortran rules and not by the names allowed 27in the file system. Thus the processor may have to provide a mapping between Fortran names and file 28system names. 29The result of translating a module could reasonably either contain only the information textually specified 30in the module (with "pointers" to information originally textually specified in other modules) or contain 31all information specified in the module (including copies of information originally specified in other 32modules). Although the former approach would appear to save on storage space, the latter approach 33can greatly simplify the logic necessary to process a USE statement and can avoid the necessity of 34imposing a limit on the logical "nesting" of modules via the USE statement. 35Variables declared in a module retain their definition status on much the same basis as variables in 36a common block. That is, saved variables retain their definition status throughout the execution of a 37program, while variables that are not saved retain their definition status only during the execution of 38scoping units that reference the module. In some cases, it may be appropriate to put a USE statement 39such as 40USE MY_MODULE, ONLY: 41in a scoping unit in order to assure that other procedures that it references can communicate through 42the module. In such a case, the scoping unit would not access any entities from the module, but the 43variables not saved in the module would retain their definition status throughout the execution of the 44scoping unit. 45There is an increased potential for undetected errors in a scoping unit that uses both implicit typing 46and the USE statement. For example, in the program fragment 551 J3/07-007 WORKING DRAFT 2006/01/05 1SUBROUTINE SUB 2 USE MY_MODULE 3 IMPLICIT INTEGER (I-N), REAL (A-H, O-Z) 4 X = F (B) 5 A = G (X) + H (X + 1) 6END SUBROUTINE SUB 7X could be either an implicitly typed real variable or a variable obtained from the module MY MODULE 8and might change from one to the other because of changes in MY MODULE unrelated to the action 9performed by SUB. Logic errors resulting from this kind of situation can be extremely difficult to locate. 10Thus, the use of these features together is discouraged. 11C.8.2.2 Accessibility attributes 12The PUBLIC and PRIVATE attributes, which can be declared only in modules, divide the entities in a 13module into those that are actually relevant to a scoping unit referencing the module and those that are 14not. This information may be used to improve the performance of a Fortran processor. For example, 15it may be possible to discard much of the information about the private entities once a module has 16been translated, thus saving on both storage and the time to search it. Similarly, it may be possible 17to recognize that two versions of a module differ only in the private entities they contain and avoid 18retranslating program units that use that module when switching from one version of the module to the 19other. C.8.3 Examples of the use of modules 20 21C.8.3.1 Identical common blocks 22A common block and all its associated specification statements may be placed in a module named, for 23example, MY COMMON and accessed by a USE statement of the form 24USE MY_COMMON 25that accesses the whole module without any renaming. This ensures that all instances of the common 26block are identical. Module MY COMMON could contain more than one common block. 27C.8.3.2 Global data 28A module may contain only data objects, for example: 29MODULE DATA_MODULE 30 SAVE 31 REAL A (10), B, C (20,20) 32 INTEGER :: I=0 33 INTEGER, PARAMETER :: J=10 34 COMPLEX D (J,J) 35END MODULE DATA_MODULE 36Data objects made global in this manner may have any combination of data types. 37Access to some of these may be made by a USE statement with the ONLY option, such as: 552 2006/01/05 WORKING DRAFT J3/07-007 1USE DATA_MODULE, ONLY: A, B, D 2and access to all of them may be made by the following USE statement: 3USE DATA_MODULE 4Access to all of them with some renaming to avoid name conflicts may be made by: 5USE DATA_MODULE, AMODULE => A, DMODULE => D 6C.8.3.3 Derived types 7A derived type may be defined in a module and accessed in a number of program units. For example: 8MODULE SPARSE 9 TYPE NONZERO 10 REAL A 11 INTEGER I, J 12 END TYPE NONZERO 13END MODULE SPARSE 14defines a type consisting of a real component and two integer components for holding the numerical 15value of a nonzero matrix element and its row and column indices. 16C.8.3.4 Global allocatable arrays 17Many programs need large global allocatable arrays whose sizes are not known before program execution. 18A simple form for such a program is: 19PROGRAM GLOBAL_WORK 20 CALL CONFIGURE_ARRAYS ! Perform the appropriate allocations 21 CALL COMPUTE ! Use the arrays in computations 22END PROGRAM GLOBAL_WORK 23MODULE WORK_ARRAYS ! An example set of work arrays 24 INTEGER N 25 REAL, ALLOCATABLE, SAVE :: A (:), B (:, :), C (:, :, :) 26END MODULE WORK_ARRAYS 27SUBROUTINE CONFIGURE_ARRAYS ! Process to set up work arrays 28 USE WORK_ARRAYS 29 READ (*, *) N 30 ALLOCATE (A (N), B (N, N), C (N, N, 2 * N)) 31END SUBROUTINE CONFIGURE_ARRAYS 32SUBROUTINE COMPUTE 33 USE WORK_ARRAYS 34 ... ! Computations involving arrays A, B, and C 35END SUBROUTINE COMPUTE 36Typically, many subprograms need access to the work arrays, and all such subprograms would contain 37the statement 553 J3/07-007 WORKING DRAFT 2006/01/05 1USE WORK_ARRAYS 2C.8.3.5 Procedure libraries 3Interface bodies for external procedures in a library may be gathered into a module. This permits the 4use of argument keywords and optional arguments, and allows static checking of the references. Different 5versions may be constructed for different applications, using argument keywords in common use in each 6application. 7An example is the following library module: 8MODULE LIBRARY_LLS 9 INTERFACE 10 SUBROUTINE LLS (X, A, F, FLAG) 11 REAL X (:, :) 12 ! The SIZE in the next statement is an intrinsic function 13 REAL, DIMENSION (SIZE (X, 2)) :: A, F 14 INTEGER FLAG 15 END SUBROUTINE LLS 16 ... 17 END INTERFACE 18 ... 19END MODULE LIBRARY_LLS 20This module allows the subroutine LLS to be invoked: 21USE LIBRARY_LLS 22 ... 23CALL LLS (X = ABC, A = D, F = XX, FLAG = IFLAG) 24 ... 25C.8.3.6 Operator extensions 26In order to extend an intrinsic operator symbol to have an additional meaning, an interface block 27specifying that operator symbol in the OPERATOR option of the INTERFACE statement may be 28placed in a module. 29For example, // may be extended to perform concatenation of two derived-type objects serving as varying 30length character strings and + may be extended to specify matrix addition for type MATRIX or interval 31arithmetic addition for type INTERVAL. 32A module might contain several such interface blocks. An operator may be defined by an external function (either in Fortran or some other language) and its procedure interface placed in the module. 33 34C.8.3.7 Data abstraction 35In addition to providing a portable means of avoiding the redundant specification of information in 36multiple program units, a module provides a convenient means of "packaging" related entities, such as 37the definitions of the representation and operations of an abstract data type. The following example 554 2006/01/05 WORKING DRAFT J3/07-007 1of a module defines a data abstraction for a SET type where the elements of each set are of type 2integer. The usual set operations of UNION, INTERSECTION, and DIFFERENCE are provided. 3The CARDINALITY function returns the cardinality of (number of elements in) its set argument. 4Two functions returning logical values are included, ELEMENT and SUBSET. ELEMENT defines the 5operator .IN. and SUBSET extends the operator <=. ELEMENT determines if a given scalar integer 6value is an element of a given set, and SUBSET determines if a given set is a subset of another given 7set. (Two sets may be checked for equality by comparing cardinality and checking that one is a subset of the other, or checking to see if each is a subset of the other.) 8 9The transfer function SETF converts a vector of integer values to the corresponding set, with duplicate 10values removed. Thus, a vector of constant values can be used as set constants. An inverse transfer 11function VECTOR returns the elements of a set as a vector of values in ascending order. In this SET 12implementation, set data objects have a maximum cardinality of 200. 13MODULE INTEGER_SETS 14! This module is intended to illustrate use of the module facility 15! to define a new type, along with suitable operators. 16 17INTEGER, PARAMETER :: MAX_SET_CARD = 200 18 19TYPE SET ! Define SET type 20 PRIVATE 21 INTEGER CARD 22 INTEGER ELEMENT (MAX_SET_CARD) 23END TYPE SET 24 25INTERFACE OPERATOR (.IN.) 26 MODULE PROCEDURE ELEMENT 27END INTERFACE OPERATOR (.IN.) 28 29INTERFACE OPERATOR (<=) 30 MODULE PROCEDURE SUBSET 31END INTERFACE OPERATOR (<=) 32 33INTERFACE OPERATOR (+) 34 MODULE PROCEDURE UNION 35END INTERFACE OPERATOR (+) 36 37INTERFACE OPERATOR (-) 38 MODULE PROCEDURE DIFFERENCE 39END INTERFACE OPERATOR (-) 40 41INTERFACE OPERATOR (*) 42 MODULE PROCEDURE INTERSECTION 43END INTERFACE OPERATOR (*) 44 45CONTAINS 555 J3/07-007 WORKING DRAFT 2006/01/05 1 2INTEGER FUNCTION CARDINALITY (A) ! Returns cardinality of set A 3 TYPE (SET), INTENT (IN) :: A 4 CARDINALITY = A % CARD 5END FUNCTION CARDINALITY 6 7LOGICAL FUNCTION ELEMENT (X, A) ! Determines if 8 INTEGER, INTENT(IN) :: X ! element X is in set A 9 TYPE (SET), INTENT(IN) :: A 10 ELEMENT = ANY (A % ELEMENT (1 : A % CARD) == X) 11END FUNCTION ELEMENT 12 13FUNCTION UNION (A, B) ! Union of sets A and B 14 TYPE (SET) UNION 15 TYPE (SET), INTENT(IN) :: A, B 16 INTEGER J 17 UNION = A 18 DO J = 1, B % CARD 19 IF (.NOT. (B % ELEMENT (J) .IN. A)) THEN 20 IF (UNION % CARD < MAX_SET_CARD) THEN 21 UNION % CARD = UNION % CARD + 1 22 UNION % ELEMENT (UNION % CARD) = & 23 B % ELEMENT (J) 24 ELSE 25 ! Maximum set size exceeded . . . 26 END IF 27 END IF 28 END DO 29END FUNCTION UNION 30 31FUNCTION DIFFERENCE (A, B) ! Difference of sets A and B 32 TYPE (SET) DIFFERENCE 33 TYPE (SET), INTENT(IN) :: A, B 34 INTEGER J, X 35 DIFFERENCE % CARD = 0 ! The empty set 36 DO J = 1, A % CARD 37 X = A % ELEMENT (J) 38 IF (.NOT. (X .IN. B)) DIFFERENCE = DIFFERENCE + SET (1, X) 39 END DO 40END FUNCTION DIFFERENCE 41 42FUNCTION INTERSECTION (A, B) ! Intersection of sets A and B 43 TYPE (SET) INTERSECTION 44 TYPE (SET), INTENT(IN) :: A, B 45 INTERSECTION = A - (A - B) 556 2006/01/05 WORKING DRAFT J3/07-007 1END FUNCTION INTERSECTION 2 3LOGICAL FUNCTION SUBSET (A, B) ! Determines if set A is 4 TYPE (SET), INTENT(IN) :: A, B ! a subset of set B 5 INTEGER I 6 SUBSET = A % CARD <= B % CARD 7 IF (.NOT. SUBSET) RETURN ! For efficiency 8 DO I = 1, A % CARD 9 SUBSET = SUBSET .AND. (A % ELEMENT (I) .IN. B) 10 END DO 11END FUNCTION SUBSET 12 13TYPE (SET) FUNCTION SETF (V) ! Transfer function between a vector 14 INTEGER V (:) ! of elements and a set of elements 15 INTEGER J ! removing duplicate elements 16 SETF % CARD = 0 17 DO J = 1, SIZE (V) 18 IF (.NOT. (V (J) .IN. SETF)) THEN 19 IF (SETF % CARD < MAX_SET_CARD) THEN 20 SETF % CARD = SETF % CARD + 1 21 SETF % ELEMENT (SETF % CARD) = V (J) 22 ELSE 23 ! Maximum set size exceeded . . . 24 END IF 25 END IF 26 END DO 27END FUNCTION SETF 28 29FUNCTION VECTOR (A) ! Transfer the values of set A 30 TYPE (SET), INTENT (IN) :: A ! into a vector in ascending order 31 INTEGER, POINTER :: VECTOR (:) 32 INTEGER I, J, K 33 ALLOCATE (VECTOR (A % CARD)) 34 VECTOR = A % ELEMENT (1 : A % CARD) 35 DO I = 1, A % CARD - 1 ! Use a better sort if 36 DO J = I + 1, A % CARD ! A % CARD is large 37 IF (VECTOR (I) > VECTOR (J)) THEN 38 K = VECTOR (J); VECTOR (J) = VECTOR (I); VECTOR (I) = K 39 END IF 40 END DO 41 END DO 42END FUNCTION VECTOR 43 44END MODULE INTEGER_SETS 557 J3/07-007 WORKING DRAFT 2006/01/05 1Examples of using INTEGER_SETS (A, B, and C are variables of type SET; X 2is an integer variable): 3! Check to see if A has more than 10 elements 4IF (CARDINALITY (A) > 10) ... 5 6! Check for X an element of A but not of B 7IF (X .IN. (A - B)) ... 8 9! C is the union of A and the result of B intersected 10! with the integers 1 to 100 11C = A + B * SETF ([(I, I = 1, 100)]) 12 13! Does A have any even numbers in the range 1:100? 14IF (CARDINALITY (A * SETF ([(I, I = 2, 100, 2)])) > 0) ... 15 16PRINT *, VECTOR (B) ! Print out the elements of set B, in ascending order 17C.8.3.8 Public entities renamed 18At times it may be necessary to rename entities that are accessed with USE statements. Care should be 19taken if the referenced modules also contain USE statements. 20The following example illustrates renaming features of the USE statement. 21MODULE J; REAL JX, JY, JZ; END MODULE J 22MODULE K 23 USE J, ONLY : KX => JX, KY => JY 24 ! KX and KY are local names to module K 25 REAL KZ ! KZ is local name to module K 26 REAL JZ ! JZ is local name to module K 27END MODULE K 28PROGRAM RENAME 29 USE J; USE K 30 ! Module J's entity JX is accessible under names JX and KX 31 ! Module J's entity JY is accessible under names JY and KY 32 ! Module K's entity KZ is accessible under name KZ 33 ! Module J's entity JZ and K's entity JZ are different entities 34 ! and shall not be referenced 35 ... 36END PROGRAM RENAME 37C.8.4 Modules with submodules 38Each submodule specifies that it is the child of exactly one parent module or submodule. Therefore, a 39module and all of its descendant submodules stand in a tree-like relationship one to another. 40If a module procedure interface body that is specified in a module has public accessibility, and its 558 2006/01/05 WORKING DRAFT J3/07-007 1corresponding separate module procedure is defined in a descendant of that module, the procedure can 2be accessed by use association. No other entity in a submodule can be accessed by use association. Each 3program unit that references a module by use association depends on it, and each submodule depends 4on its ancestor module. Therefore, if one changes a separate module procedure body in a submodule but 5does not change its corresponding module procedure interface, a tool for automatic program translation 6would not need to reprocess program units that reference the module by use association. This is so 7even if the tool exploits the relative modification times of files as opposed to comparing the result of 8translating the module to the result of a previous translation. 9By constructing taller trees, one can put entities at intermediate levels that are shared by submodules 10at lower levels; changing these entities cannot change the interpretation of anything that is accessible 11from the module by use association. Developers of modules that embody large complicated concepts 12can exploit this possibility to organize components of the concept into submodules, while preserving the 13privacy of entities that are shared by the submodules and that ought not to be exposed to users of the 14module. Putting these shared entities at an intermediate level also prevents cascades of reprocessing 15and testing if some of them are changed. 16The following example illustrates a module, color_points, with a submodule, color_points_a, that in 17turn has a submodule, color_points_b. Public entities declared within color_points can be accessed 18by use association. The submodules color_points_a and color_points_b can be changed without 19causing retranslation of program units that reference the module color_points. 20The module color_points does not have a module-subprogram-part, but a module-subprogram-part is 21not prohibited. The module could be published as definitive specification of the interface, without 22revealing trade secrets contained within color_points_a or color_points_b. Of course, a similar 23module without the module prefix in the interface bodies would serve equally well as documentation ­ 24but the procedures would be external procedures. It would make little difference to the consumer, but 25the developer would forfeit all of the advantages of modules. 26 module color_points 27 28 type color_point 29 private 30 real :: x, y 31 integer :: color 32 end type color_point 33 34 interface ! Interfaces for procedures with separate 35 ! bodies in the submodule color_points_a 36 module subroutine color_point_del ( p ) ! Destroy a color_point object 37 type(color_point), allocatable :: p 38 end subroutine color_point_del 39 ! Distance between two color_point objects 40 real module function color_point_dist ( a, b ) 41 type(color_point), intent(in) :: a, b 42 end function color_point_dist 43 module subroutine color_point_draw ( p ) ! Draw a color_point object 44 type(color_point), intent(in) :: p 45 end subroutine color_point_draw 46 module subroutine color_point_new ( p ) ! Create a color_point object 559 J3/07-007 WORKING DRAFT 2006/01/05 1 type(color_point), allocatable :: p 2 end subroutine color_point_new 3 end interface 4 5 end module color_points 6The only entities within color_points_a that can be accessed by use association are separate module 7procedures for which corresponding module procedure interface bodies are provided in color_points. 8If the procedures are changed but their interfaces are not, the interface from program units that access 9them by use association is unchanged. If the module and submodule are in separate files, utilities that 10examine the time of modification of a file would notice that changes in the module could affect the 11translation of its submodules or of program units that reference the module by use association, but 12that changes in submodules could not affect the translation of the parent module or program units that 13reference it by use association. 14The variable instance_count is not accessible by use association of color_points, but is accessible 15within color_points_a, and its submodules. 16 submodule ( color_points ) color_points_a ! Submodule of color_points 17 18 integer, save :: instance_count = 0 19 20 interface ! Interface for a procedure with a separate 21 ! body in submodule color_points_b 22 module subroutine inquire_palette ( pt, pal ) 23 use palette_stuff ! palette_stuff, especially submodules 24 ! thereof, can reference color_points by use 25 ! association without causing a circular 26 ! dependence during translation because this 27 ! use is not in the module. Furthermore, 28 ! changes in the module palette_stuff do not 29 ! affect the translation of color_points. 30 type(color_point), intent(in) :: pt 31 type(palette), intent(out) :: pal 32 end subroutine inquire_palette 33 34 end interface 35 36 contains ! Invisible bodies for public module procedure interfaces 37 ! declared in the module 38 39 module subroutine color_point_del ( p ) 40 type(color_point), allocatable :: p 41 instance_count = instance_count - 1 42 deallocate ( p ) 43 end subroutine color_point_del real module function color_point_dist ( a, b ) result ( dist ) 560 2006/01/05 WORKING DRAFT J3/07-007 1 2 type(color_point), intent(in) :: a, b 3 dist = sqrt( (b%x - a%x)**2 + (b%y - a%y)**2 ) 4 end function color_point_dist 5 module subroutine color_point_new ( p ) 6 type(color_point), allocatable :: p 7 instance_count = instance_count + 1 8 allocate ( p ) 9 end subroutine color_point_new 10 11 end submodule color_points_a 12The subroutine inquire_palette is accessible within color_points_a because its interface is declared 13therein. It is not, however, accessible by use association, because its interface is not declared in the 14module, color_points. Since the interface is not declared in the module, changes in the interface 15cannot affect the translation of program units that reference the module by use association. 16 submodule ( color_points:color_points_a ) color_points_b ! Subsidiary**2 submodule 17 18 contains 19 ! Invisible body for interface declared in the ancestor module 20 module subroutine color_point_draw ( p ) 21 use palette_stuff, only: palette 22 type(color_point), intent(in) :: p 23 type(palette) :: MyPalette 24 ...; call inquire_palette ( p, MyPalette ); ... 25 end subroutine color_point_draw 26 27 ! Invisible body for interface declared in the parent submodule 28 module procedure inquire_palette 29 ... implementation of inquire_palette 30 end procedure inquire_palette 31 32 subroutine private_stuff ! not accessible from color_points_a 33 ... 34 end subroutine private_stuff 35 36 end submodule color_points_b 37 38 module palette_stuff 39 type :: palette ; ... ; end type palette 40 contains 41 subroutine test_palette ( p ) 42 ! Draw a color wheel using procedures from the color_points module 43 type(palette), intent(in) :: p use color_points ! This does not cause a circular dependency because 561 J3/07-007 WORKING DRAFT 2006/01/05 1 2 ! the "use palette_stuff" that is logically within 3 ! color_points is in the color_points_a submodule. 4 ... 5 end subroutine test_palette 6 end module palette_stuff 7There is a use palette_stuff in color_points_a, and a use color_points in palette_stuff. The 8use palette_stuff would cause a circular reference if it appeared in color_points. In this case, it 9does not cause a circular dependence because it is in a submodule. Submodules cannot be referenced 10by use association, and therefore what would be a circular appearance of use palette_stuff is not 11accessed. 12 program main 13 use color_points 14 ! "instance_count" and "inquire_palette" are not accessible here 15 ! because they are not declared in the "color_points" module. 16 ! "color_points_a" and "color_points_b" cannot be referenced by 17 ! use association. 18 interface draw ! just to demonstrate it's possible 19 module procedure color_point_draw 20 end interface 21 type(color_point) :: C_1, C_2 22 real :: RC 23 ... 24 call color_point_new (c_1) ! body in color_points_a, interface in color_points 25 ... 26 call draw (c_1) ! body in color_points_b, specific interface 27 ! in color_points, generic interface here. 28 ... 29 rc = color_point_dist (c_1, c_2) ! body in color_points_a, interface in color_points 30 ... 31 call color_point_del (c_1) ! body in color_points_a, interface in color_points 32 ... 33 end program main 34A multilevel submodule system can be used to package and organize a large and interconnected concept 35without exposing entities of one subsystem to other subsystems. 36Consider a Plasma module from a Tokomak simulator. A plasma simulation requires attention at least to 37fluid flow, thermodynamics, and electromagnetism. Fluid flow simulation requires simulation of subsonic, 38supersonic, and hypersonic flow. This problem decomposition can be reflected in the submodule structure 39of the Plasma module: 40 Plasma module 41 | 42 |---------------------|---------------------| 43 | | | 562 2006/01/05 WORKING DRAFT J3/07-007 1 Flow submodule Thermal submodule Electromagnetics 2 | Submodule 3 |-------------------|-------------------| 4 | | | 5 Subsonic Supersonic Hypersonic 6Entities can be shared among the Subsonic, Supersonic, and Hypersonic submodules by putting 7them within the Flow submodule. One then need not worry about accidental use of these entities by 8use association or by the Thermal or Electromagnetics modules, or the development of a dependency 9of correct operation of those subsystems upon the representation of entities of the Flow subsystem as a 10consequence of maintenance. Since these these entities are not accessible by use association, if any of 11them are changed, the new values cannot be accessed in program units that reference the Plasma module 12by use association; the answer to the question "where are these entities used" is therefore confined to 13the set of descendant submodules of the Flow submodule. 14C.9 Clause 12 notes C.9.1 Portability problems with external procedures (12.4.3.5) 15 16There is a potential portability problem in a scoping unit that references an external procedure without 17explicitly declaring it to have the EXTERNAL attribute (5.3.8). On a different processor, the name 18of that procedure may be the name of a nonstandard intrinsic procedure and the processor would be 19permitted to interpret those procedure references as references to that intrinsic procedure. (On that 20processor, the program would also be viewed as not conforming to this part of ISO/IEC 1539 because of 21the references to the nonstandard intrinsic procedure.) Declaration of the EXTERNAL attribute causes 22the references to be to the external procedure regardless of the availability of an intrinsic procedure with 23the same name. Note that declaration of the type of a procedure is not enough to make it external, even 24if the type is inconsistent with the type of the result of an intrinsic of the same name. C.9.2 Procedures defined by means other than Fortran (12.6.3) 25 26A processor is not required to provide any means other than Fortran for defining external procedures. 27Among the means that might be supported are the machine assembly language, other high level lan- 28guages, the Fortran language extended with nonstandard features, and the Fortran language as supported 29by another Fortran processor (for example, a previously existing Fortran 77 processor). 30Procedures defined by means other than Fortran are considered external procedures because their def- 31initions are not in a Fortran program unit and because they are referenced using global names. The 32use of the term external should not be construed as any kind of restriction on the way in which these 33procedures may be defined. For example, if the means other than Fortran has its own facilities for 34internal and external procedures, it is permissible to use them. If the means other than Fortran can 35create an "internal" procedure with a global name, it is permissible for such an "internal" procedure 36to be considered by Fortran to be an external procedure. The means other than Fortran for defining 37external procedures, including any restrictions on the structure for organization of those procedures, are 38entirely processor dependent. 39A Fortran processor may limit its support of procedures defined by means other than Fortran such that 40these procedures may affect entities in the Fortran environment only on the same basis as procedures 41written in Fortran. For example, it might prohibit the value of a local variable from being changed by 42a procedure reference unless that variable were one of the arguments to the procedure. C.9.3 Procedure interfaces (12.4) 563 J3/07-007 WORKING DRAFT 2006/01/05 1In Fortran 77, the interface to an external procedure was always deduced from the form of references 2to that procedure and any declarations of the procedure name in the referencing program unit. In this 3part of ISO/IEC 1539, features such as argument keywords and optional arguments make it impossible 4to deduce sufficient information about the dummy arguments from the nature of the actual arguments 5to be associated with them, and features such as array function results and pointer function results 6make necessary extensions to the declaration of a procedure that cannot be done in a way that would 7be analogous with the handling of such declarations in Fortran 77. Hence, mechanisms are provided 8through which all the information about a procedure's interface may be made available in a scoping 9unit that references it. A procedure whose interface shall be deduced as in Fortran 77 is described 10as having an implicit interface. A procedure whose interface is fully known is described as having an 11explicit interface. 12A scoping unit is allowed to contain an interface body for a procedure that does not exist in the program, 13provided the procedure described is never referenced or used in any other way. The purpose of this rule is 14to allow implementations in which the use of a module providing interface bodies describing the interface 15of every routine in a library would not automatically cause each of those library routines to be a part of 16the program referencing the module. Instead, only those library procedures actually referenced would 17be a part of the program. (In implementation terms, the mere presence of an interface body would not generate an external reference in such an implementation.) 18 C.9.4 Abstract interfaces (12.4) and procedure pointer components (4.5) 19 20This is an example of a library module providing lists of callbacks that the user may register and invoke. 21MODULE callback_list_module 22 ! 23 ! Type for users to extend with their own data, if they so desire 24 ! 25 TYPE callback_data 26 END TYPE 27 ! 28 ! Abstract interface for the callback procedures 29 ! 30 ABSTRACT INTERFACE 31 SUBROUTINE callback_procedure(data) 32 IMPORT callback_data 33 CLASS(callback_data),OPTIONAL :: data 34 END SUBROUTINE 35 END INTERFACE 36 ! 37 ! The callback list type. 38 ! 39 TYPE callback_list 40 PRIVATE 41 CLASS(callback_record),POINTER :: first => NULL() 42 END TYPE 43 ! 44 ! Internal: each callback registration creates one of these 45 ! 564 2006/01/05 WORKING DRAFT J3/07-007 1 TYPE,PRIVATE :: callback_record 2 PROCEDURE(callback_procedure),POINTER,NOPASS :: proc 3 CLASS(callback_record),POINTER :: next 4 CLASS(callback_data),POINTER :: data => NULL(); 5 END TYPE 6 PRIVATE invoke,forward_invoke 7CONTAINS 8 ! 9 ! Register a callback procedure with optional data 10 ! 11 SUBROUTINE register_callback(list, entry, data) 12 TYPE(callback_list),INTENT(INOUT) :: list 13 PROCEDURE(callback_procedure) :: entry 14 CLASS(callback_data),OPTIONAL :: data 15 TYPE(callback_record),POINTER :: new,last 16 ALLOCATE(new) 17 new%proc => entry 18 IF (PRESENT(data)) ALLOCATE(new%data,SOURCE=data) 19 new%next => list%first 20 list%first => new 21 END SUBROUTINE 22 ! 23 ! Internal: Invoke a single callback and destroy its record 24 ! 25 SUBROUTINE invoke(callback) 26 TYPE(callback_record),POINTER :: callback 27 IF (ASSOCIATED(callback%data) THEN 28 CALL callback%proc(list%first%data) 29 DEALLOCATE(callback%data) 30 ELSE 31 CALL callback%proc 32 END IF 33 DEALLOCATE(callback) 34 END SUBROUTINE 35 ! 36 ! Call the procedures in reverse order of registration 37 ! 38 SUBROUTINE invoke_callback_reverse(list) 39 TYPE(callback_list),INTENT(INOUT) :: list 40 TYPE(callback_record),POINTER :: next,current 41 current => list%first 42 NULLIFY(list%first) 43 DO WHILE (ASSOCIATED(current)) 44 next => current%next 45 CALL invoke(current) 565 J3/07-007 WORKING DRAFT 2006/01/05 1 current => next 2 END DO 3 END SUBROUTINE 4 ! 5 ! Internal: Forward mode invocation 6 ! 7 RECURSIVE SUBROUTINE forward_invoke(callback) 8 IF (ASSOCIATED(callback%next)) CALL forward_invoke(callback%next) 9 CALL invoke(callback) 10 END SUBROUTINE 11 ! 12 ! Call the procedures in forward order of registration 13 ! 14 SUBROUTINE invoke_callback_forward(list) 15 TYPE(callback_list),INTENT(INOUT) :: list 16 IF (ASSOCIATED(list%first)) CALL forward_invoke(list%first) 17 END SUBROUTINE 18END C.9.5 Argument association and evaluation (12.5.2) 19 20There is a significant difference between the argument association allowed in this part of ISO/IEC 1539 21and that supported by Fortran 77 and Fortran 66. In Fortran 77 and 66, actual arguments 22were limited to consecutive storage units. With the exception of assumed length character dummy 23arguments, the structure imposed on that sequence of storage units was always determined in the invoked 24procedure and not taken from the actual argument. Thus it was possible to implement Fortran 66 25and Fortran 77 argument association by supplying only the location of the first storage unit (except 26for character arguments, where the length would also have to be supplied). However, this part of 27ISO/IEC 1539 allows arguments that do not reside in consecutive storage locations (for example, an 28array section), and dummy arguments that assume additional structural information from the actual 29argument (for example, assumed-shape dummy arguments). Thus, the mechanism to implement the argument association allowed in this part of ISO/IEC 1539 needs to be more general. 30 31Because there are practical advantages to a processor that can support references to and from procedures 32defined by a Fortran 77 processor, requirements for explicit interfaces make it possible to determine 33whether a simple (Fortran 66/Fortran 77) argument association implementation mechanism is suffi- 34cient or whether the more general mechanism is necessary (12.4.2). Thus a processor can be implemented 35whose procedures expect the simple mechanism to be used whenever the procedure's interface is one that 36uses only Fortran 77 features and that expects the more general mechanism otherwise (for example, if 37there are assumed-shape or optional arguments). At the point of reference, the appropriate mechanism 38can be determined from the interface if it is explicit and can be assumed to be the simple mechanism 39if it is not. Note that if the simple mechanism is determined to be what the procedure expects, it may 40be necessary for the processor to allocate consecutive temporary storage for the actual argument, copy 41the actual argument to the temporary storage, reference the procedure using the temporary storage in 42place of the actual argument, copy the contents of temporary storage back to the actual argument, and 43deallocate the temporary storage. 44While this is the particular implementation method these rules were designed to support, it is not 45the only one possible. For example, on some processors, it may be possible to implement the general 46argument association in such a way that the information involved in Fortran 77 argument association 47may be found in the same places and the "extra" information is placed so it does not disturb a procedure 566 2006/01/05 WORKING DRAFT J3/07-007 1expecting only Fortran 77 argument association. With such an implementation, argument association 2could be translated without regard to whether the interface is explicit or implicit. 3The provisions for expression evaluation give the processor considerable flexibility for obtaining expres- 4sion values in the most efficient way possible. This includes not evaluating or only partially evaluating an 5operand, for example, if the value of the expression can be determined otherwise (7.1.7). This flexibility 6applies to function argument evaluation, including the order of argument evaluation, delaying argument 7evaluation, and omitting argument evaluation. A processor may delay the evaluation of an argument 8in a procedure reference until the execution of the procedure refers to the value of that argument, pro- 9vided delaying the evaluation of the argument does not otherwise affect the results of the program. The 10processor may, with similar restrictions, entirely omit the evaluation of an argument not referenced in 11the execution of the procedure. This gives processors latitude for optimization (for example, for parallel processing). 12 C.9.6 Pointers and targets as arguments (12.5.2.5, 12.5.2.7, 12.5.2.8) 13 J3 internal note Unresolved Technical Issue 082 The following paragraph takes no account of auto-targetting. Rewrite or delete. 14If a dummy argument is declared to be a pointer, it may be matched only by an actual argument that 15also is a pointer, and the characteristics of both arguments shall agree. A model for such an association is 16that descriptor values of the actual pointer are copied to the dummy pointer. If the actual pointer has an 17associated target, this target becomes accessible via the dummy pointer. If the dummy pointer becomes 18associated with a different target during execution of the procedure, this target will be accessible via the 19actual pointer after the procedure completes execution. If the dummy pointer becomes associated with 20a local target that ceases to exist when the procedure completes, the actual pointer will be left dangling 21in an undefined state. Such dangling pointers shall not be used. 22When execution of a procedure completes, any pointer that remains defined and that is associated with 23a dummy argument that has the TARGET attribute and is either a scalar or an assumed-shape array, 24remains associated with the corresponding actual argument if the actual argument has the TARGET 25attribute and is not an array section with a vector subscript. 26REAL, POINTER :: PBEST 27REAL, TARGET :: B (10000) 28CALL BEST (PBEST, B) ! Upon return PBEST is associated 29 ... ! with the ``best'' element of B 30CONTAINS 31 SUBROUTINE BEST (P, A) 32 REAL, POINTER, INTENT (OUT) :: P 33 REAL, TARGET, INTENT (IN) :: A (:) 34 ... ! Find the ``best'' element A(I) 35 P => A (I) 36 RETURN 37 END SUBROUTINE BEST 38END 39When procedure BEST completes, the pointer PBEST is associated with an element of B. 40An actual argument without the TARGET attribute can become associated with a dummy argument 567 J3/07-007 WORKING DRAFT 2006/01/05 1with the TARGET attribute. This permits pointers to become associated with the dummy argument 2during execution of the procedure that contains the dummy argument. For example: 3INTEGER LARGE(100,100) 4CALL SUB (LARGE) 5 ... 6CALL SUB () 7CONTAINS 8 SUBROUTINE SUB(ARG) 9 INTEGER, TARGET, OPTIONAL :: ARG(100,100) 10 INTEGER, POINTER, DIMENSION(:,:) :: PARG 11 IF (PRESENT(ARG)) THEN 12 PARG => ARG 13 ELSE 14 ALLOCATE (PARG(100,100)) 15 PARG = 0 16 ENDIF 17 ... ! Code with lots of references to PARG 18 IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) 19 END SUBROUTINE SUB 20END 21Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is 22associated with an allocated target. The bulk of the code can reference PARG without further calls to 23the PRESENT intrinsic. C.9.7 Polymorphic Argument Association (12.5.2.10) 24 25The following example illustrates polymorphic argument association rules using the derived types defined 26in Note 4.58. 27 TYPE(POINT) :: T2 28 TYPE(COLOR_POINT) :: T3 29 CLASS(POINT) :: P2 30 CLASS(COLOR_POINT) :: P3 31 ! Dummy argument is polymorphic and actual argument is of fixed type 32 SUBROUTINE SUB2 ( X2 ); CLASS(POINT) :: X2; ... 33 SUBROUTINE SUB3 ( X3 ); CLASS(COLOR_POINT) :: X3; ... 34 35 CALL SUB2 ( T2 ) ! Valid -- The declared type of T2 is the same as the 36 ! declared type of X2. 37 CALL SUB2 ( T3 ) ! Valid -- The declared type of T3 is extended from 38 ! the declared type of X2. 39 CALL SUB3 ( T2 ) ! Invalid -- The declared type of T2 is neither the 40 ! same as nor extended from the declared type ! type of X3. 568 2006/01/05 WORKING DRAFT J3/07-007 1 2 CALL SUB3 ( T3 ) ! Valid -- The declared type of T3 is the same as the 3 ! declared type of X3. 4 ! Actual argument is polymorphic and dummy argument is of fixed type 5 SUBROUTINE TUB2 ( D2 ); TYPE(POINT) :: D2; ... 6 SUBROUTINE TUB3 ( D3 ); TYPE(COLOR_POINT) :: D3; ... 7 8 CALL TUB2 ( P2 ) ! Valid -- The declared type of P2 is the same as the 9 ! declared type of D2. 10 CALL TUB2 ( P3 ) ! Invalid -- The declared type of P3 differs from the 11 ! declared type of D2. 12 CALL TUB2 ( P3%POINT ) ! Valid alternative to the above 13 CALL TUB3 ( P2 ) ! Invalid -- The declared type of P2 differs from the 14 ! declared type of D3. 15 SELECT TYPE ( P2 ) ! Valid conditional alternative to the above 16 CLASS IS ( COLOR_POINT ) ! Works if the dynamic type of P2 is the same 17 CALL TUB3 ( P2 ) ! as the declared type of D3, or a type 18 ! extended therefrom. 19 CLASS DEFAULT 20 ! Cannot work if not. 21 END SELECT 22 CALL TUB3 ( P3 ) ! Valid -- The declared type of P3 is the same as the 23 ! declared type of D3. 24 ! Both the actual and dummy arguments are of polymorphic type. 25 CALL SUB2 ( P2 ) ! Valid -- The declared type of P2 is the same as the 26 ! declared type of X2. 27 CALL SUB2 ( P3 ) ! Valid -- The declared type of P3 is extended from 28 ! the declared type of X2. 29 CALL SUB3 ( P2 ) ! Invalid -- The declared type of P2 is neither the 30 ! same as nor extended from the declared 31 ! type of X3. 32 SELECT TYPE ( P2 ) ! Valid conditional alternative to the above 33 CLASS IS ( COLOR_POINT ) ! Works if the dynamic type of P2 is the 34 CALL SUB3 ( P2 ) ! same as the declared type of X3, or a 35 ! type extended therefrom. 36 CLASS DEFAULT 37 ! Cannot work if not. 38 END SELECT 39 CALL SUB3 ( P3 ) ! Valid -- The declared type of P3 is the same as the 40 ! declared type of X3. 41C.10 Clause 13 notes 569 J3/07-007 WORKING DRAFT 2006/01/05 1C.10.1 Module for THIS IMAGE and IMAGE INDEX 2The intrinsics THIS IMAGE (CO ARRAY) and IMAGE INDEX (CO ARRAY, SUB) cannot be written 3in Fortran since CO ARRAY may be of any type and THIS IMAGE (CO ARRAY) needs to know the 4index of the image on which the code is running. 5As an example, here are simple versions that require the co-bounds to be specified as integer arrays and require the image index for THIS IMAGE (CO ARRAY). 6 7MODULE index 8CONTAINS 9 INTEGER FUNCTION image_index(lbound, ubound, sub) 10 INTEGER, INTENT(IN) :: lbound(:), ubound(:), sub(:) 11 INTEGER :: i, n 12 n = SIZE(sub) 13 image_index = sub(n) - lbound(n) 14 DO i = n-1, 1, -1 15 image_index = image_index*(ubound(i)-lbound(i)+1) + sub(i) - lbound(i) 16 END DO 17 image_index = image_index + 1 18 END FUNCTION image_index 19 20 INTEGER FUNCTION this_image(lbound, ubound, me) RESULT(sub) 21 INTEGER, INTENT(IN) :: lbound(:), ubound(:), me 22 INTEGER :: sub(SIZE(lbound)) 23 INTEGER :: extent, i, m, ml, n 24 n = SIZE(sub) 25 m = me - 1 26 DO i = 1, n-1 27 extent = ubound(i) - lbound(i) + 1 28 ml = m 29 m = m/extent 30 sub(i) = ml - m*extent + lbound(i) 31 END DO 32 sub(n) = m + lbound(n) 33 END FUNCTION this_IMAGE 34END MODULE index C.10.2 Collective co-array subroutine variations 35 36The subroutines of 13.5.15 return an array of the same shape as the given co-array after having applied 37an operation on the images involved. Simple routines can be written to also apply the operation to the 38elements of the co-array on an image. Various versions of a global sum can be programmed, for example: 39MODULE global_sum_module 40 INTRINSIC, PRIVATE :: CO_SUM, SIZE, SUM 41CONTAINS 570 2006/01/05 WORKING DRAFT J3/07-007 1 REAL FUNCTION global_sum(array) 2 REAL,INTENT(IN) :: array(:,:)[*] 3 REAL,SAVE :: temp[*] 4 temp = SUM(array) ! Sum on the executing image 5 CALL CO_SUM(temp, global_sum) 6 END FUNCTION global_sum 7 8 REAL FUNCTION global_sum_mask(array, mask) 9 REAL,INTENT(IN) :: array(:,:)[*] 10 LOGICAL,INTENT(IN) :: mask(:,:) 11 REAL,SAVE :: temp[*] 12 temp = SUM(array, MASK=mask) ! Sum on the executing image 13 CALL CO_SUM(temp, global_sum_mask) 14 END FUNCTION global_sum_mask 15 16 FUNCTION global_sum_dim(array, dim) 17 REAL, INTENT(IN) :: array(:,:)[*] 18 INTEGER, INTENT(IN) :: dim 19 REAL, ALLOCATABLE :: global_sum_dim(:) 20 REAL, ALLOCATABLE :: temp(:)[:] 21 ALLOCATE (global_sum_dim(SIZE(array, 3-dim))) 22 ALLOCATE ( temp(SIZE(array, 3-dim))[*]) 23 temp = SUM(array, dim) ! Sum of the local part of the co-array. 24 CALL CO_SUM(temp, global_sum_dim) 25 END FUNCTION global_sum_dim 26END MODULE global_sum_module 27C.11 Clause 15 notes 28C.11.1 Runtime environments 29This part of ISO/IEC 1539 allows programs to contain procedures defined by means other than Fortran. 30That raises the issues of initialization of and interaction between the runtime environments involved. 31Implementations are free to solve these issues as they see fit, provided that 32 (1) heap allocation/deallocation (e.g., (DE)ALLOCATE in a Fortran subprogram and mal- loc/free in a C function) can be performed without interference, 33 34 (2) input/output to and from external files can be performed without interference, as long as procedures defined by different means do not do input/output with the same external file, 35 (3) input/output preconnections exist as required by the respective standards, and 36 (4) initialized data is initialized according to the respective standards. 37 C.11.2 Examples of Interoperation between Fortran and C Functions 38 39The following examples illustrate the interoperation of Fortran and C functions. Two examples are 40shown: one of Fortran calling C, and one of C calling Fortran. In each of the examples, the correspon- 41dences of Fortran actual arguments, Fortran dummy arguments, and C formal parameters are described. 571 J3/07-007 WORKING DRAFT 2006/01/05 1C.11.2.1 Example of Fortran calling C 2C Function Prototype: 3 int C_Library_Function(void* sendbuf, int sendcount, 4 int *recvcounts); 5Fortran Modules: 6 MODULE FTN_C_1 7 USE, INTRINSIC :: ISO_C_BINDING 8 END MODULE FTN_C_1 9 10 MODULE FTN_C_2 11 INTERFACE 12 INTEGER (C_INT) FUNCTION C_LIBRARY_FUNCTION & 13 (SENDBUF, SENDCOUNT, RECVCOUNTS) & 14 BIND(C, NAME='C_Library_Function') 15 USE FTN_C_1 16 IMPLICIT NONE 17 TYPE (C_PTR), VALUE :: SENDBUF 18 INTEGER (C_INT), VALUE :: SENDCOUNT 19 TYPE (C_PTR), VALUE :: RECVCOUNTS 20 END FUNCTION C_LIBRARY_FUNCTION 21 END INTERFACE 22 END MODULE FTN_C_2 23The module FTN C 2 contains the declaration of the Fortran dummy arguments, which correspond to 24the C formal parameters. The intrinsic module ISO C BINDING is referenced in the module FTN C 1. 25The NAME specifier is used in the BIND attribute in order to handle the case-sensitive name change 26between Fortran and C from 'C LIBRARY FUNCTION' to 'C Library Function'. See also Note 12.47. 27The first C formal parameter is the pointer to void sendbuf, which corresponds to the Fortran dummy 28argument SENDBUF, which has the type C PTR and the VALUE attribute. 29The second C formal parameter is the int sendcount, which corresponds to the Fortran dummy argument SENDCOUNT, which has the type INTEGER(C INT) and the VALUE attribute. 30 31The third C formal parameter is the pointer to int recvcounts, which corresponds to the Fortran dummy 32argument RECVCOUNTS, which has the type C PTR and the VALUE attribute. 33Fortran Calling Sequence: 34 USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT, C_FLOAT, C_LOC 35 USE FTN_C_2 36 ... REAL (C_FLOAT), TARGET :: SEND(100) 572 2006/01/05 WORKING DRAFT J3/07-007 1 2 INTEGER (C_INT) :: SENDCOUNT 3 INTEGER (C_INT), ALLOCATABLE, TARGET :: RECVCOUNTS(100) 4 ... 5 ALLOCATE( RECVCOUNTS(100) ) 6 ... 7 CALL C_LIBRARY_FUNCTION(C_LOC(SEND), SENDCOUNT, & 8 C_LOC(RECVCOUNTS)) 9 ... 10The preceding code contains the declaration of the Fortran actual arguments associated with the above- 11listed Fortran dummy arguments. 12The first Fortran actual argument is the address of the first element of the array SEND, which has the 13type REAL(C FLOAT) and the TARGET attribute. This address is returned by the intrinsic function 14C LOC. This actual argument is associated with the Fortran dummy argument SENDBUF, which has 15the type C PTR and the VALUE attribute. 16The second Fortran actual argument is SENDCOUNT of type INTEGER(C INT), which is associated 17with the Fortran dummy argument SENDCOUNT, which has the type INTEGER(C INT) and the 18VALUE attribute. 19The third Fortran actual argument is the address of the first element of the allocatable array RECV- 20COUNTS, with has the type REAL(C FLOAT) and the TARGET attribute. This address is returned 21by the intrinsic function C LOC. This actual argument is associated with the Fortran dummy argument 22RECVCOUNTS, which has the type C PTR and the VALUE attribute. 23C.11.2.2 Example of C calling Fortran 24Fortran Code: 25SUBROUTINE SIMULATION(ALPHA, BETA, GAMMA, DELTA, ARRAYS) BIND(C) 26 USE, INTRINSIC :: ISO_C_BINDING 27 IMPLICIT NONE 28 INTEGER (C_LONG), VALUE :: ALPHA 29 REAL (C_DOUBLE), INTENT(INOUT) :: BETA 30 INTEGER (C_LONG), INTENT(OUT) :: GAMMA 31 REAL (C_DOUBLE),DIMENSION(*),INTENT(IN) :: DELTA 32 TYPE, BIND(C) :: PASS 33 INTEGER (C_INT) :: LENC, LENF 34 TYPE (C_PTR) :: C, F 35 END TYPE PASS 36 TYPE (PASS), INTENT(INOUT) :: ARRAYS 37 REAL (C_FLOAT), ALLOCATABLE, TARGET, SAVE :: ETA(:) 38 REAL (C_FLOAT), POINTER :: C_ARRAY(:) 39 ... 40 ! Associate C_ARRAY with an array allocated in C 41 CALL C_F_POINTER (ARRAYS%C, C_ARRAY, [ARRAYS%LENC]) 42 ... 573 J3/07-007 WORKING DRAFT 2006/01/05 1 ! Allocate an array and make it available in C 2 ARRAYS%LENF = 100 3 ALLOCATE (ETA(ARRAYS%LENF)) 4 ARRAYS%F = C_LOC(ETA) 5 ... 6END SUBROUTINE SIMULATION 7C Struct Declaration 8 struct pass {int lenc, lenf; float *c, *f;}; 9C Function Prototype: 10 void simulation(long alpha, double *beta, long *gamma, 11 double delta[], struct pass *arrays); 12C Calling Sequence: 13 simulation(alpha, &beta, &gamma, delta, &arrays); 14The above-listed Fortran code specifies a subroutine SIMULATION. This subroutine corresponds to the 15C void function simulation. 16The Fortran subroutine references the intrinsic module ISO C BINDING. 17The first Fortran dummy argument of the subroutine is ALPHA, which has the type INTEGER(C - 18LONG) and the attribute VALUE. This dummy argument corresponds to the C formal parameter 19alpha, which is a long. The actual C parameter is also a long. 20The second Fortran dummy argument of the subroutine is BETA, which has the type REAL(C - 21DOUBLE) and the INTENT(INOUT) attribute. This dummy argument corresponds to the C formal 22parameter beta, which is a pointer to double. An address is passed as the actual parameter in the C 23calling sequence. 24The third Fortran dummy argument of the subroutine is GAMMA, which has the type INTEGER(C - 25LONG) and the INTENT(OUT) attribute. This dummy argument corresponds to the C formal param- 26eter gamma, which is a pointer to long. An address is passed as the actual parameter in the C calling 27sequence. 28The fourth Fortran dummy argument is the assumed-size array DELTA, which has the type REAL 29(C DOUBLE) and the attribute INTENT(IN). This dummy argument corresponds to the C formal 30parameter delta, which is a double array. The actual C parameter is also a double array. 31The fifth Fortran dummy argument is ARRAYS, which is a structure for accessing an array allocated 32in C and an array allocated in Fortran. The lengths of these arrays are held in the components LENC 33and LENF; their C addresses are held in components C and F. 34C.11.2.3 Example of calling C functions with noninteroperable data 35Many Fortran processors support 16-byte real numbers, which might not be supported by the C processor. 36Assume a Fortran programmer wants to use a C procedure from a message passing library for an array 37of these reals. The C prototype of this procedure is 574 2006/01/05 WORKING DRAFT J3/07-007 1void ProcessBuffer(void *buffer, int n_bytes); 2with the corresponding Fortran interface 3USE, INTRINSIC :: ISO_C_BINDING 4 5INTERFACE 6 SUBROUTINE PROCESS_BUFFER(BUFFER,N_BYTES) BIND(C,NAME="ProcessBuffer") 7 IMPORT :: C_PTR, C_INT 8 TYPE(C_PTR), VALUE :: BUFFER ! The ``C address'' of the array buffer 9 INTEGER(C_INT), VALUE :: N_BYTES ! Number of bytes in buffer 10 END SUBROUTINE PROCESS_BUFFER 11END INTERFACE 12This may be done using C LOC if the particular Fortran processor specifies that C LOC returns an 13appropriate address: 14REAL(R_QUAD), DIMENSION(:), ALLOCATABLE, TARGET :: QUAD_ARRAY 15... 16CALL PROCESS_BUFFER(C_LOC(QUAD_ARRAY), INT(16*SIZE(QUAD_ARRAY),C_INT)) 17 ! One quad real takes 16 bytes on this processor 18C.11.2.4 Example of opaque communication between C and Fortran 19The following example demonstrates how a Fortran processor can make a modern OO random number 20generator written in Fortran available to a C program: 21USE, INTRINSIC :: ISO_C_BINDING 22 ! Assume this code is inside a module 23 24TYPE RANDOM_STREAM 25 ! A (uniform) random number generator (URNG) 26CONTAINS 27 PROCEDURE(RANDOM_UNIFORM), DEFERRED, PASS(STREAM) :: NEXT 28 ! Generates the next number from the stream 29END TYPE RANDOM_STREAM 30 31ABSTRACT INTERFACE 32 ! Abstract interface of Fortran URNG 33 SUBROUTINE RANDOM_UNIFORM(STREAM, NUMBER) 34 IMPORT :: RANDOM_STREAM, C_DOUBLE 35 CLASS(RANDOM_STREAM), INTENT(INOUT) :: STREAM 36 REAL(C_DOUBLE), INTENT(OUT) :: NUMBER 37 END SUBROUTINE RANDOM_UNIFORM 38END INTERFACE 575 J3/07-007 WORKING DRAFT 2006/01/05 1A polymorphic object of base type RANDOM STREAM is not interoperable with C. However, we can 2make such a random number generator available to C by packaging it inside another nonpolymorphic, 3nonparameterized derived type: 4TYPE :: URNG_STATE ! No BIND(C), as this type is not interoperable 5 CLASS(RANDOM_STREAM), ALLOCATABLE :: STREAM 6END TYPE URNG_STATE 7The following two procedures will enable a C program to use our Fortran uniform random number 8generator: 9! Initialize a uniform random number generator: 10SUBROUTINE INITIALIZE_URNG(STATE_HANDLE, METHOD) & 11 BIND(C, NAME="InitializeURNG") 12 TYPE(C_PTR), INTENT(OUT) :: STATE_HANDLE 13 ! An opaque handle for the URNG 14 CHARACTER(C_CHAR), DIMENSION(*), INTENT(IN) :: METHOD 15 ! The algorithm to be used 16 17 TYPE(URNG_STATE), POINTER :: STATE 18 ! An actual URNG object 19 20 ALLOCATE(STATE) 21 ! There needs to be a corresponding finalization 22 ! procedure to avoid memory leaks, not shown in this example 23 ! Allocate STATE%STREAM with a dynamic type depending on METHOD 24 ... 25 STATE_HANDLE=C_LOC(STATE) 26 ! Obtain an opaque handle to return to C 27END SUBROUTINE INITIALIZE_URNG 28 29! Generate a random number: 30SUBROUTINE GENERATE_UNIFORM(STATE_HANDLE, NUMBER) & 31 BIND(C, NAME="GenerateUniform") 32 TYPE(C_PTR), INTENT(IN), VALUE :: STATE_HANDLE 33 ! An opaque handle: Obtained via a call to INITIALIZE_URNG 34 REAL(C_DOUBLE), INTENT(OUT) :: NUMBER 35 36 TYPE(URNG_STATE), POINTER :: STATE 37 ! A pointer to the actual URNG 38 39 CALL C_F_POINTER(CPTR=STATE_HANDLE, FPTR=STATE) 40 ! Convert the opaque handle into a usable pointer 41 CALL STATE%STREAM%NEXT(NUMBER) 42 ! Use the type-bound procedure NEXT to generate NUMBER 43END SUBROUTINE GENERATE_UNIFORM 576 2006/01/05 WORKING DRAFT J3/07-007 1C.12 Clause 16 notes C.12.1 Examples of host association (16.5.1.4) 2 3The first two examples are examples of valid host association. The third example is an example of invalid 4host association. 5Example 1: 6PROGRAM A 7 INTEGER I, J 8 ... 9CONTAINS 10 SUBROUTINE B 11 INTEGER I ! Declaration of I hides 12 ! program A's declaration of I 13 ... 14 I = J ! Use of variable J from program A 15 ! through host association 16 END SUBROUTINE B 17END PROGRAM A 18Example 2: 19PROGRAM A 20 TYPE T 21 ... 22 END TYPE T 23 ... 24CONTAINS 25 SUBROUTINE B 26 IMPLICIT TYPE (T) (C) ! Refers to type T declared below 27 ! in subroutine B, not type T 28 ! declared above in program A 29 ... 30 TYPE T 31 ... 32 END TYPE T 33 ... 34 END SUBROUTINE B 35END PROGRAM A 36Example 3: 37PROGRAM Q 38 REAL (KIND = 1) :: C 577 J3/07-007 WORKING DRAFT 2006/01/05 1 ... 2CONTAINS 3 SUBROUTINE R 4 REAL (KIND = KIND (C)) :: D ! Invalid declaration 5 ! See below 6 REAL (KIND = 2) :: C 7 ... 8 END SUBROUTINE R 9END PROGRAM Q 10In the declaration of D in subroutine R, the use of C would refer to the declaration of C in subroutine 11R, not program Q. However, it is invalid because the declaration of C is required to occur before it is used in the declaration of D (7.1.12). 12 C.12.2 Rules ensuring unambiguous generics (12.4.3.4.5) 13 14The rules in 12.4.3.4.5 are intended to ensure 15 · that it is possible to reference each specific procedure in the generic collection, 16 · that for any valid reference to the generic procedure, the determination of the specific procedure 17 referenced is unambiguous, and 18 · that the determination of the specific procedure referenced can be made before execution of the program begins (during compilation). 19 20Specific procedures are distinguished by fixed properties of their arguments, specifically type, kind type 21parameters, and rank. A valid reference to one procedure in a generic collection will differ from another 22because it has an argument that the other cannot accept, because it is missing an argument that the 23other requires, or because one of these fixed properties is different. 24Although the declared type of a data entity is a fixed property, polymorphic variables allow for a 25limited degree of type mismatch between dummy arguments and actual arguments, so the requirement 26for distinguishing two dummy arguments is type incompatibility, not merely different types. (This is 27illustrated in the BAD6 example later in this note.) 28That same limited type mismatch means that two dummy arguments that are not type incompatible 29can be distinguished on the basis of the values of the kind type parameters they have in common; if one 30of them has a kind type parameter that the other does not, that is irrelevant in distinguishing them. 31Rank is a fixed property, but some forms of array dummy arguments allow rank mismatches when a 32procedure is referenced by its specific name. In order to allow rank to always be usable in distinguishing 33generics, such rank mismatches are disallowed for those arguments when the procedure is referenced as 34part of a generic. Additionally, the fact that elemental procedures can accept array arguments is not 35taken into account when applying these rules, so apparent ambiguity between elemental and nonelemental 36procedures is possible; in such cases, the reference is interpreted as being to the nonelemental procedure. 37For procedures referenced as operators or defined-assignment, syntactically distinguished arguments are 38mapped to specific positions in the argument list, so the rule for distinguishing such procedures is that 39it be possible to distinguish the arguments at one of the argument positions. 40For user-defined derived-type input/output procedures, only the dtv argument corresponds to something 41explicitly written in the program, so it is the dtv that is required to be distinguished. Because dtv 578 2006/01/05 WORKING DRAFT J3/07-007 1arguments are required to be scalar, they cannot differ in rank. Thus this rule effectively involves only 2type and kind type parameters. 3For generic procedures identified by names, the rules are more complicated because optional arguments 4may be omitted and because arguments may be specified either positionally or by name. 5In the special case of type-bound procedures with passed-object dummy arguments, the passed-object 6argument is syntactically distinguished in the reference, so rule (2) can be applied. The type of passed- 7object arguments is constrained in ways that prevent passed-object arguments in the same scoping unit 8from being type incompatible. Thus this rule effectively involves only kind type parameters and rank. 9The primary means of distinguishing named generics is rule (3). The most common application of that rule is a single argument satisfying both (3a) and (3b): 10 11 INTERFACE GOOD1 12 FUNCTION F1A(X) 13 REAL :: F1A,X 14 END FUNCTION F1A 15 FUNCTION F1B(X) 16 INTEGER :: F1B,X 17 END FUNCTION F1B 18 END INTERFACE GOOD1 19Whether one writes GOOD1(1.0) or GOOD1(X=1.0), the reference is to F1A because F1B would require an 20integer argument whereas these references provide the real constant 1.0. 21This example and those that follow are expressed using interface bodies, with type as the distinguishing 22property. This was done to make it easier to write and describe the examples. The principles being 23illustrated are equally applicable when the procedures get their explicit interfaces in some other way or 24when kind type parameters or rank are the distinguishing property. 25Another common variant is the argument that satisfies (3a) and (3b) by being required in one specific 26and completely missing in the other: 27 INTERFACE GOOD2 28 FUNCTION F2A(X) 29 REAL :: F2A,X 30 END FUNCTION F2A 31 FUNCTION F2B(X,Y) 32 COMPLEX :: F2B 33 REAL :: X,Y 34 END FUNCTION F2B 35 END INTERFACE GOOD2 36Whether one writes GOOD2(0.0,1.0), GOOD2(0.0,Y=1.0), or GOOD2(Y=1.0,X=0.0), the reference is to 37F2B, because F2A has no argument in the second position or with the name Y. This approach is used as 38an alternative to optional arguments when one wants a function to have different result type, kind type 39parameters, or rank, depending on whether the argument is present. In many of the intrinsic functions, 40the DIM argument works this way. 41It is possible to construct cases where different arguments are used to distinguish positionally and by 42name: 579 J3/07-007 WORKING DRAFT 2006/01/05 1 INTERFACE GOOD3 2 SUBROUTINE S3A(W,X,Y,Z) 3 REAL :: W,Y 4 INTEGER :: X,Z 5 END SUBROUTINE S3A 6 SUBROUTINE S3B(X,W,Z,Y) 7 REAL :: W,Z 8 INTEGER :: X,Y 9 END SUBROUTINE S3B 10 END INTERFACE GOOD3 11If one writes GOOD3(1.0,2,3.0,4) to reference S3A, then the third and fourth arguments are consistent 12with a reference to S3B, but the first and second are not. If one switches to writing the first two 13arguments as keyword arguments in order for them to be consistent with a reference to S3B, the latter 14two arguments must also be written as keyword arguments, GOOD3(X=2,W= 1.0,Z=4,Y=3.0), and the 15named arguments Y and Z are distinguished. The ordering requirement in rule (3) is critical: 16 17 INTERFACE BAD4 ! this interface is invalid ! 18 SUBROUTINE S4A(W,X,Y,Z) 19 REAL :: W,Y 20 INTEGER :: X,Z 21 END SUBROUTINE S4A 22 SUBROUTINE S4B(X,W,Z,Y) 23 REAL :: X,Y 24 INTEGER :: W,Z 25 END SUBROUTINE S4B 26 END INTERFACE BAD4 27In this example, the positionally distinguished arguments are Y and Z, and it is W and X that are 28distinguished by name. In this order it is possible to write BAD4(1.0,2,Y=3.0,Z=4), which is a valid 29reference for both S4A and S4B. Rule (1) can be used to distinguish some cases that are not covered by rule (3): 30 31 INTERFACE GOOD5 32 SUBROUTINE S5A(X) 33 REAL :: X 34 END SUBROUTINE S5A 35 SUBROUTINE S5B(Y,X) 36 REAL :: Y,X 37 END SUBROUTINE S5B 38 END INTERFACE GOOD5 39In attempting to apply rule (3), position 2 and name Y are distinguished, but they are in the wrong 40order, just like the BAD4 example. However, when we try to construct a similarly ambiguous reference, 41we get GOOD5(1.0,X=2.0), which can't be a reference to S5A because it would be attempting to associate 580 2006/01/05 WORKING DRAFT J3/07-007 1two different actual arguments with the dummy argument X. Rule (3) catches this case by recognizing 2that S5B requires two real arguments, and S5A cannot possibly accept more than one. 3The application of rule (1) becomes more complicated when extensible types are involved. If FRUIT is 4an extensible type, PEAR and APPLE are extensions of FRUIT, and BOSC is an extension of PEAR, then 5 INTERFACE BAD6 ! this interface is invalid ! 6 SUBROUTINE S6A(X,Y) 7 CLASS(PEAR) :: X,Y 8 END SUBROUTINE S6A 9 SUBROUTINE S6B(X,Y) 10 CLASS(FRUIT) :: X 11 CLASS(BOSC) :: Y 12 END SUBROUTINE S6B 13 END INTERFACE BAD6 14might, at first glance, seem distinguishable this way, but because of the limited type mismatching allowed, 15BAD6(A_PEAR,A_BOSC) is a valid reference to both S6A and S6B. It is important to try rule (1) for each type present: 16 17 INTERFACE GOOD7 18 SUBROUTINE S7A(X,Y,Z) 19 CLASS(PEAR) :: X,Y,Z 20 END SUBROUTINE S7A 21 SUBROUTINE S7B(X,Z,W) 22 CLASS(FRUIT) :: X 23 CLASS(BOSC) :: Z 24 CLASS(APPLE),OPTIONAL :: W 25 END SUBROUTINE S7B 26 END INTERFACE GOOD7 27Looking at the most general type, S7A has a minimum and maximum of 3 FRUIT arguments, while S7B 28has a minimum of 2 and a maximum of three. Looking at the most specific, S7A has a minimum of 0 29and a maximum of 3 BOSC arguments, while S7B has a minimum of 1 and a maximum of 2. However, 30when we look at the intermediate, S7A has a minimum and maximum of 3 PEAR arguments, while S7B 31has a minimum of 1 and a maximum of 2. Because S7A's minimum exceeds S7B's maximum, they can 32be distinguished. 33In identifying the minimum number of arguments with a particular set of properties, we exclude optional 34arguments and test TKR compatibility, so the corresponding actual arguments are required to have 35those properties. In identifying the maximum number of arguments with those properties, we include 36the optional arguments and test not distinguishable, so we include actual arguments which could have 37those properties but are not required to have them. 38These rules are sufficient to ensure that references to procedures that meet them are unambiguous, but 39there remain examples that fail to meet these rules but which can be shown to be unambiguous: 40 INTERFACE BAD8 ! this interface is invalid ! 581 J3/07-007 WORKING DRAFT 2006/01/05 1 ! despite the fact that it is unambiguous ! 2 SUBROUTINE S8A(X,Y,Z) 3 REAL,OPTIONAL :: X 4 INTEGER :: Y 5 REAL :: Z 6 END SUBROUTINE S8A 7 SUBROUTINE S8B(X,Z,Y) 8 INTEGER,OPTIONAL :: X 9 INTEGER :: Z 10 REAL :: Y 11 END SUBROUTINE S8B 12 END INTERFACE BAD8 13This interface fails rule (3) because there are no required arguments that can be distinguished from the 14positionally corresponding argument, but in order for the mismatch of the optional arguments not to 15be relevant, the later arguments must be specified as keyword arguments, so distinguishing by name 16does the trick. This interface is nevertheless invalid so a standard- conforming Fortran processor is not 17required to do such reasoning. The rules to cover all cases are too complicated to be useful. 18The real data objects that would be valid arguments for S9A are entirely disjoint from procedures that 19are valid arguments to S9B and S9C, and the procedures that valid arguments for S9B are disjoint from 20the procedures that are valid arguments to S9C because the former are required to accept real arguments 21and the latter integer arguments. Again, this interface is invalid, so a standard-conforming Fortran 22processor need not examine such properties when deciding whether a generic collection is valid. Again, 23the rules to cover all cases are too complicated to be useful. C.13 Array feature notes 24 C.13.1 Summary of features 25 26This subclause is a summary of the principal array features. C.13.1.1 Whole array expressions and assignments (7.2.1.2, 7.2.1.3) 27 28An important feature is that whole array expressions and assignments are permitted. For example, the 29statement 30A = B + C * SIN (D) 31where A, B, C, and D are arrays of the same shape, is permitted. It is interpreted element-by-element; 32that is, the sine function is taken on each element of D, each result is multiplied by the corresponding 33element of C, added to the corresponding element of B, and assigned to the corresponding element of 34A. Functions, including user-written functions, may be arrays and may be generic with scalar versions. 35All arrays in an expression or across an assignment shall conform; that is, have exactly the same shape 36(number of dimensions and extents in each dimension), but scalars may be included freely and these are 37interpreted as being broadcast to a conforming array. Expressions are evaluated before any assignment 38takes place. C.13.1.2 Array sections (2.4.5, 6.2.2.2) 39 40Whenever whole arrays may be used, it is also possible to use subarrays called "sections". For example: 582 2006/01/05 WORKING DRAFT J3/07-007 1A (:, 1:N, 2, 3:1:-1) 2consists of a subarray containing the whole of the first dimension, positions 1 to N of the second dimen- 3sion, position 2 of the third dimension and positions 1 to 3 in reverse order of the fourth dimension. 4This is an artificial example chosen to illustrate the different forms. Of course, a common use may be 5to select a row or column of an array, for example: 6A (:, J) C.13.1.3 WHERE statement (7.2.3) 7 8The WHERE statement applies a conforming logical array as a mask on the individual operations in the 9expression and in the assignment. For example: 10WHERE (A > 0) B = LOG (A) 11takes the logarithm only for positive components of A and makes assignments only in these positions. The WHERE statement also has a block form (WHERE construct). 12 C.13.1.4 Automatic arrays and allocatable variables (5.2, 5.3.7.4) 13 14Two features useful for writing modular software are automatic arrays, created on entry to a subprogram 15and destroyed on return, and allocatable variables, including arrays whose rank is fixed but whose actual 16size and lifetime is fully under the programmer's control through explicit ALLOCATE and DEALLO- 17CATE statements. The declarations 18SUBROUTINE X (N, A, B) 19REAL WORK (N, N); REAL, ALLOCATABLE :: HEAP (:, :) 20specify an automatic array WORK and an allocatable array HEAP. Note that a stack is an adequate 21storage mechanism for the implementation of automatic arrays, but a heap will be needed for some 22allocatable variables. C.13.1.5 Array constructors (4.7) 23 24Arrays, and in particular array constants, may be constructed with array constructors exemplified by: 25[1.0, 3.0, 7.2] 26which is a rank-one array of size 3, 27[(1.3, 2.7, L = 1, 10), 7.1] 28which is a rank-one array of size 21 and contains the pair of real constants 1.3 and 2.7 repeated 10 times 29followed by 7.1, and 30[(I, I = 1, N)] 31which contains the integers 1, 2, ..., N. Only rank-one arrays may be constructed in this way, but higher 32dimensional arrays may be made from them by means of the intrinsic function RESHAPE. C.13.2 Examples 33 34The array features have the potential to simplify the way that almost any array-using program is con- 35ceived and written. Many algorithms involving arrays can now be written conveniently as a series of 36computations with whole arrays. 583 J3/07-007 WORKING DRAFT 2006/01/05 1C.13.2.1 Unconditional array computations 2At the simplest level, statements such as 3A = B + C 4or 5S = SUM (A) 6can take the place of entire DO loops. The loops were required to perform array addition or to sum all 7the elements of an array. 8Further examples of unconditional operations on arrays that are simple to write are: matrix multiply P = MATMUL (Q, R) largest array element L = MAXVAL (P) factorial N F = PRODUCT ([(K, K = 2, N)]) N 9The Fourier sum F = ai × cosxi may also be computed without writing a DO loop if one makes i=1 10use of the element-by-element definition of array expressions as described in Clause 7. Thus, we can 11write 12F = SUM (A * COS (X)) 13The successive stages of calculation of F would then involve the arrays: A = [ A (1), ..., A (N) ] X = [ X (1), ..., X (N) ] COS (X) = [ COS (X (1)), ..., COS (X (N)) ] A * COS (X) = [ A (1) * COS (X (1)), ..., A (N) * COS (X (N)) ] 14The final scalar result is obtained simply by summing the elements of the last of these arrays. Thus, the 15processor is dealing with arrays at every step of the calculation. 16C.13.2.2 Conditional array computations 17Suppose we wish to compute the Fourier sum in the above example, but to include only those terms 18a(i) cos x(i) that satisfy the condition that the coefficient a(i) is less than 0.01 in absolute value. More 19precisely, we are now interested in evaluating the conditional Fourier sum CF = ai × cosxi |ai|<0.01 20where the index runs from 1 to N as before. 21This can be done by using the MASK parameter of the SUM function, which restricts the summation 22of the elements of the array A * COS (X) to those elements that correspond to true elements of MASK. 23Clearly, the mask required is the logical array expression ABS (A) < 0.01. Note that the stages of 24evaluation of this expression are: A = [ A (1), ..., A (N) ] ABS (A) = [ ABS (A (1)), ..., ABS (A (N)) ] ABS (A) < 0.01 = [ ABS (A (1)) < 0.01, ..., ABS (A (N)) < 0.01 ] 584 2006/01/05 WORKING DRAFT J3/07-007 1The conditional Fourier sum we arrive at is: 2CF = SUM (A * COS (X), MASK = ABS (A) < 0.01) 3If the mask is all false, the value of CF is zero. 4The use of a mask to define a subset of an array is crucial to the action of the WHERE statement. Thus 5for example, to zero an entire array, we may write simply A = 0; but to set only the negative elements 6to zero, we need to write the conditional assignment 7WHERE (A .LT. 0) A = 0 8The WHERE statement complements ordinary array assignment by providing array assignment to any 9subset of an array that can be restricted by a logical expression. 10In the Ising model described below, the WHERE statement predominates in use over the ordinary array 11assignment statement. 12C.13.2.3 A simple program: the Ising model 13The Ising model is a well-known Monte Carlo simulation in 3-dimensional Euclidean space which is 14useful in certain physical studies. We will consider in some detail how this might be programmed. The 15model may be described in terms of a logical array of shape N by N by N. Each gridpoint is a single logical variable which is to be interpreted as either an up-spin (true) or a down-spin (false). 16 17The Ising model operates by passing through many successive states. The transition to the next state is 18governed by a local probabilistic process. At each transition, all gridpoints change state simultaneously. 19Every spin either flips to its opposite state or not according to a rule that depends only on the states 20of its 6 nearest neighbors in the surrounding grid. The neighbors of gridpoints on the boundary faces of 21the model cube are defined by assuming cubic periodicity. In effect, this extends the grid periodically 22by replicating it in all directions throughout space. 23The rule states that a spin is flipped to its opposite parity for certain gridpoints where a mere 3 or 24fewer of the 6 nearest neighbors have the same parity as it does. Also, the flip is executed only with 25probability P (4), P (5), or P (6) if as many as 4, 5, or 6 of them have the same parity as it does. (The 26rule seems to promote neighborhood alignments that may presumably lead to equilibrium in the long run.) 27 28C.13.2.3.1 Problems to be solved 29Some of the programming problems that we will need to solve in order to translate the Ising model into 30Fortran statements using entire arrays are (1) counting nearest neighbors that have the same spin, 31 (2) providing an array function to return an array of random numbers, and 32 (3) determining which gridpoints are to be flipped. 33 34C.13.2.3.2 Solutions in Fortran 35The arrays needed are: 36LOGICAL ISING (N, N, N), FLIPS (N, N, N) 37INTEGER ONES (N, N, N), COUNT (N, N, N) 38REAL THRESHOLD (N, N, N) The array function needed is: 585 J3/07-007 WORKING DRAFT 2006/01/05 1 2FUNCTION RAND (N) 3REAL RAND (N, N, N) 4The transition probabilities are specified in the array 5REAL P (6) 6The first task is to count the number of nearest neighbors of each gridpoint g that have the same spin 7as g. 8Assuming that ISING is given to us, the statements 9ONES = 0 10WHERE (ISING) ONES = 1 11make the array ONES into an exact analog of ISING in which 1 stands for an up-spin and 0 for a 12down-spin. 13The next array we construct, COUNT, will record for every gridpoint of ISING the number of spins to 14be found among the 6 nearest neighbors of that gridpoint. COUNT will be computed by adding together 156 arrays, one for each of the 6 relative positions in which a nearest neighbor is found. Each of the 6 16arrays is obtained from the ONES array by shifting the ONES array one place circularly along one of 17its dimensions. This use of circular shifting imparts the cubic periodicity. 18COUNT = CSHIFT (ONES, SHIFT = -1, DIM = 1) & 19 + CSHIFT (ONES, SHIFT = 1, DIM = 1) & 20 + CSHIFT (ONES, SHIFT = -1, DIM = 2) & 21 + CSHIFT (ONES, SHIFT = 1, DIM = 2) & 22 + CSHIFT (ONES, SHIFT = -1, DIM = 3) & 23 + CSHIFT (ONES, SHIFT = 1, DIM = 3) 24At this point, COUNT contains the count of nearest neighbor up-spins even at the gridpoints where 25the Ising model has a down-spin. But we want a count of down-spins at those gridpoints, so we correct COUNT at the down (false) points of ISING by writing: 26 27WHERE (.NOT. ISING) COUNT = 6 - COUNT 28Our object now is to use these counts of what may be called the "like-minded nearest neighbors" to 29decide which gridpoints are to be flipped. This decision will be recorded as the true elements of an array 30FLIPS. The decision to flip will be based on the use of uniformly distributed random numbers from the 31interval 0 p < 1. These will be provided at each gridpoint by the array function RAND. The flip will 32occur at a given point if and only if the random number at that point is less than a certain threshold 33value. In particular, by making the threshold value equal to 1 at the points where there are 3 or fewer 34like-minded nearest neighbors, we guarantee that a flip occurs at those points (because p is always less 35than 1). Similarly, the threshold values corresponding to counts of 4, 5, and 6 are assigned P (4), P (5), 36and P (6) in order to achieve the desired probabilities of a flip at those points (P (4), P (5), and P (6) are input parameters in the range 0 to 1). 37 38The thresholds are established by the statements: 39THRESHOLD = 1.0 WHERE (COUNT == 4) THRESHOLD = P (4) 586 2006/01/05 WORKING DRAFT J3/07-007 1 2WHERE (COUNT == 5) THRESHOLD = P (5) 3WHERE (COUNT == 6) THRESHOLD = P (6) 4and the spins that are to be flipped are located by the statement: 5FLIPS = RAND (N) <= THRESHOLD 6All that remains to complete one transition to the next state of the ISING model is to reverse the spins 7in ISING wherever FLIPS is true: 8WHERE (FLIPS) ISING = .NOT. ISING 9C.13.2.3.3 The complete Fortran subroutine 10The complete code, enclosed in a subroutine that performs a sequence of transitions, is as follows: 11SUBROUTINE TRANSITION (N, ISING, ITERATIONS, P) 12 13 LOGICAL ISING (N, N, N), FLIPS (N, N, N) 14 INTEGER ONES (N, N, N), COUNT (N, N, N) 15 REAL THRESHOLD (N, N, N), P (6) 16 17 DO I = 1, ITERATIONS 18 ONES = 0 19 WHERE (ISING) ONES = 1 20 COUNT = CSHIFT (ONES, -1, 1) + CSHIFT (ONES, 1, 1) & 21 + CSHIFT (ONES, -1, 2) + CSHIFT (ONES, 1, 2) & 22 + CSHIFT (ONES, -1, 3) + CSHIFT (ONES, 1, 3) 23 WHERE (.NOT. ISING) COUNT = 6 - COUNT 24 THRESHOLD = 1.0 25 WHERE (COUNT == 4) THRESHOLD = P (4) 26 WHERE (COUNT == 5) THRESHOLD = P (5) 27 WHERE (COUNT == 6) THRESHOLD = P (6) 28 FLIPS = RAND (N) <= THRESHOLD 29 WHERE (FLIPS) ISING = .NOT. ISING 30 END DO 31 32CONTAINS 33 FUNCTION RAND (N) 34 REAL RAND (N, N, N) 35 CALL RANDOM_NUMBER (HARVEST = RAND) 36 RETURN 37 END FUNCTION RAND 38END 39C.13.2.3.4 Reduction of storage 587 J3/07-007 WORKING DRAFT 2006/01/05 1The array ISING could be removed (at some loss of clarity) by representing the model in ONES all the 2time. The array FLIPS can be avoided by combining the two statements that use it as: 3WHERE (RAND (N) <= THRESHOLD) ISING = .NOT. ISING 4but an extra temporary array would probably be needed. Thus, the scope for saving storage while 5performing whole array operations is limited. If N is small, this will not matter and the use of whole 6array operations is likely to lead to good execution speed. If N is large, storage may be very important 7and adequate efficiency will probably be available by performing the operations plane by plane. The 8resulting code is not as elegant, but all the arrays except ISING will have size of order N2 instead of N3. C.13.3 FORmula TRANslation and array processing 9 10Many mathematical formulas can be translated directly into Fortran by use of the array processing 11features. 12We assume the following array declarations: 13REAL X (N), A (M, N) 14Some examples of mathematical formulas and corresponding Fortran expressions follow. 15C.13.3.1 A sum of products The expression N M aij j=1 i=1 16can be formed using the Fortran expression 17SUM (PRODUCT (A, DIM=1)) 18The argument DIM=1 means that the product is to be computed down each column of A. If A had the B C D value the result of this expression is BE + CF + DG. E F G 19 20C.13.3.2 A product of sums The expression M N aij i=1 j=1 21can be formed using the Fortran expression 22PRODUCT (SUM (A, DIM = 2)) 23The argument DIM = 2 means that the sum is to be computed along each row of A. If A had the B C D value the result of this expression is (B+C+D)(E+F+G). E F G 24 25C.13.3.3 Addition of selected elements The expression xi xi>0.0 588 2006/01/05 WORKING DRAFT J3/07-007 1can be formed using the Fortran expression 2SUM (X, MASK = X > 0.0) 3The mask locates the positive elements of the array of rank one. If X has the vector value (0.0, -0.1, 0.2, 0.3, 0.2, -0.1, 0.0), the result of this expression is 0.7. 4 C.13.4 Sum of squared residuals 5 The expression N (xi - xmean)2 i=1 6can be formed using the Fortran statements 7XMEAN = SUM (X) / SIZE (X) 8SS = SUM ((X - XMEAN) ** 2) 9Thus, SS is the sum of the squared residuals. C.13.5 Vector norms: infinity-norm and one-norm 10 11The infinity-norm of vector X = (X (1), ..., X(N)) is defined as the largest of the numbers ABS (X(1)), ..., ABS(X(N)) and therefore has the value MAXVAL (ABS(X)). 12 13The one-norm of vector X is defined as the sum of the numbers ABS (X (1)), ..., ABS (X (N)) and therefore has the value SUM ( ABS (X)). 14 C.13.6 Matrix norms: infinity-norm and one-norm 15 16The infinity-norm of the matrix A = (A (I, J)) is the largest row-sum of the matrix ABS (A (I, J)) and therefore has the value MAXVAL (SUM (ABS (A), DIM = 2)). 17 18The one-norm of the matrix A = (A (I, J)) is the largest column-sum of the matrix ABS (A (I, J)) and therefore has the value MAXVAL (SUM (ABS (A), DIM = 1)). 19 C.13.7 Logical queries 20 21The intrinsic functions allow quite complicated questions about tabular data to be answered without 22use of loops or conditional constructs. Consider, for example, the questions asked below about a simple 23tabulation of students' test scores. 24Suppose the rectangular table T (M, N) contains the test scores of M students who have taken N different 25tests. T is an integer matrix with entries in the range 0 to 100. 26Example: The scores on 4 tests made by 3 students are held as the table T = 85 76 90 60 71 45 50 80 66 45 21 55 27Question: What is each student's top score? Answer: MAXVAL (T, DIM = 2); in the example: [90, 80, 66]. 28 589 J3/07-007 WORKING DRAFT 2006/01/05 1Question: What is the average of all the scores? Answer: SUM (T) / SIZE (T); in the example: 62. 2 3Question: How many of the scores in the table are above average? 4Answer: ABOVE = T > SUM (T) / SIZE (T); N = COUNT (ABOVE); in the example: ABOVE is the t t t . logical array (t = true, . = false): t . . t and COUNT (ABOVE) is 6. t . . . 5 6Question: What was the lowest score in the above-average group of scores? Answer: MINVAL (T, MASK = ABOVE), where ABOVE is as defined previously; in the example: 66. 7 8Question: Was there a student whose scores were all above average? 9Answer: With ABOVE as previously defined, the answer is yes or no according as the value of the expression ANY (ALL (ABOVE, DIM = 2)) is true or false; in the example, the answer is no. 10 C.13.8 Parallel computations 11 12The most straightforward kind of parallel processing is to do the same thing at the same time to many 13operands. Matrix addition is a good example of this very simple form of parallel processing. Thus, the 14array assignment A = B + C specifies that corresponding elements of the identically-shaped arrays B 15and C be added together in parallel and that the resulting sums be assigned in parallel to the array A. 16The process being done in parallel in the example of matrix addition is of course the process of addi- 17tion; the array feature that implements matrix addition as a parallel process is the element-by-element 18evaluation of array expressions. 19These observations lead us to look to element-by-element computation as a means of implementing other 20simple parallel processing algorithms. C.13.9 Example of element-by-element computation 21 22Several polynomials of the same degree may be evaluated at the same point by arranging their coefficients 23as the rows of a matrix and applying Horner's method for polynomial evaluation to the columns of the 24matrix so formed. 25The procedure is illustrated by the code to evaluate the three cubic polynomials P(t) = 1 + 2t - 3t2 + 4t3 Q(t) = 2 - 3t + 4t2 - 5t3 R(t) = 3 + 4t - 5t2 + 6t3 26in parallel at the point t = X and to place the resulting vector of numbers [P (X), Q (X), R (X)] in the real array RESULT (3). 27 28The code to compute RESULT is just the one statement 29RESULT = M (:, 1) + X * (M (:, 2) + X * (M (:, 3) + X * M (:, 4))) 1 2 -3 4 where M represents the matrix M (3, 4) with value 2 -3 4 -5 . 3 4 -5 6 590 2006/01/05 WORKING DRAFT J3/07-007 C.13.10 Bit manipulation and inquiry procedures 1 2The procedures IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, IBITS, MVBITS, BTEST, IBSET, and 3IBCLR are defined by MIL-STD 1753 for scalar arguments and are extended in this part of ISO/IEC 41539 to accept array arguments and to return array results. 591 J3/07-007 WORKING DRAFT 2006/01/05 592 2006/01/05 WORKING DRAFT J3/07-007 Annex D (Informative) Processor Dependencies D.1 Unspecified Items This part of ISO/IEC 1539 does not specify the following properties: · the properties listed in 1.4; · a processor's error detection capabilities beyond those listed in 1.5; · which additional intrinsic procedures or modules a processor provides (1.5); · the number and kind of companion processors (2.5.10). D.2 Processor Dependencies According to this part of ISO/IEC 1539, the following properties are processor dependent: · whether an external file is available to all images or only to particular images (2.3.2); · the order of evaluation of the specification expressions within the specification part of an invoked Fortran procedure (2.3.6); · the mechanism of a companion processor, and the means of selecting between multiple companion processors (2.5.10); · the processor character set (3.1); · the means for specifying the source form of a program unit (3.3); · the maximum number of characters allowed on a source line containing characters not of default kind (3.3.1, 3.3.2); · the maximum depth of nesting of include files (3.4); · the interpretation of the char-literal-constant in the include line (3.4); · whether comments in a macro definition appear in the expansion, whether continuations and consecutive blanks that are not part of a token are preserved by macro expansion, and the maximum number of characters produced by a macro expansion in a statement containing any character that is not of default kind (3.5.2.1); · the set of values supported by an intrinsic type, other than logical and bits (4.1.1); · the kind of a character length type parameter (4.4.5.1); · whether particular control characters may appear within a character literal constant in fixed source form (4.4.5.3); · the collating sequence for each character set (4.4.5.4); 593 J3/07-007 WORKING DRAFT 2006/01/05 · the upper limit of the size supported by the BITS type (4.4.7); · the order of finalization when several objects are finalized as the consequence of a single event (4.5.6.2); · whether an array is contiguous, except as specified in 5.3.6; · the positive integer values assigned to the stat-variable in a STAT= specifier as the result of an error condition (6.3.4, 8.5.7); · the value assigned to the errmsg-variable in an ERRMSG= specifier as the result of an error condition (6.3.5, 8.5.7); · the kind of a numeric intrinsic binary operation where (1) both operands are integer but with different kind type parameters, and the decimal exponent ranges are the same, (2) both operands are any of type real or complex but with different kind type parameters, and the decimal precisions are the same, and for a logical intrinsic binary operation where the operands have different kind type parameters (7.1.9.2); · the order of evaluation of the specification expressions within the specification part of a BLOCK construct when the construct is executed (8.1.4); · the pointer association status of a pointer that has its pointer association changed in more than one iteration of a DO construct, on termination of the construct (8.1.7); · the manner in which the stop code of a STOP statement is made available (8.4); · the relationship between the file storage units when viewing a file as a stream file, and the records when viewing that file as a record file (9); · whether particular control characters may appear in a formatted record or a formatted stream file (9.1.1); · at any time, the set of allowed access methods, set of allowed forms, set of allowed actions, and set of allowed record lengths for a file (9.2); · the set of allowable names for a file (9.2); · the relationship between positions of successive file storage units in an external file that is connected for formatted stream access (9.2.2.3); · the external unit preconnected for sequential formatted input and identified by an asterisk or the named constant INPUT UNIT of the ISO FORTRAN ENV intrinsic module (9.4); · the external unit preconnected for sequential formatted output and identified by an asterisk or the named constant OUTPUT UNIT of the ISO FORTRAN ENV intrinsic module (9.4); · the external unit preconnected for sequential formatted output and identified by the named con- stant ERROR UNIT of the ISO FORTRAN ENV intrinsic module, and whether this unit is the same as OUTPUT UNIT (9.4); · at any time, the set of external units that exist for a program (9.4.2); · whether a unit can be connected to a file that is also connected to a C stream (9.4.3); · whether the files connected to the units INPUT UNIT, OUTPUT UNIT, and ERROR UNIT cor- respond to the predefined C text streams standard input, standard output, and standard error, respectively (9.4.3); 594 2006/01/05 WORKING DRAFT J3/07-007 · the results of performing input/output operations on a file that is also connected to a C stream (9.4.3); · the results of performing input/output operations on an external file both from Fortran and from a procedure defined by means other than Fortran (9.4.3); · the default value for the ACTION= specifier on the OPEN statement (9.4.5.2); · the encoding of a file opened with ENCODING='DEFAULT' (9.4.5.7); · the file connected to by an OPEN statement with STATUS='SCRATCH' (9.4.5.8); · the interpretation of case in a file name (9.4.5.8, 9.9.2.1); · the default value for the RECL= specified in an OPEN statement (9.4.5.13); · the effect of RECL= on a record containing any nondefault characters (9.4.5.13); · the default I/O rounding mode (9.4.5.14); · the default sign mode (9.4.5.15); · the file status when STATUS='UNKNOWN' is specified in an OPEN statement (9.4.5.16); · whether POS= is permitted with particular files, and whether POS= can position a particular file to a position prior to its current position (9.5.2.11); · the result of unformatted input when the value stored in the file has a different type or type parameters from the input list item, as described in 9.5.4.4.1; · the positive integer values assigned to the variable in an IOSTAT= specifier as the result of an error condition (9.10.4); · the value assigned to the variable in an IOMSG= specifier as the result of an error condition (9.10.5); · the variable in a POSITION= specifier in an INQUIRE statement as described in 9.9.2.22; · the relationship between file size and the data stored in records in a sequential or direct access file (9.9.2.29); · the number of file storage units needed to store data in an unformatted file (9.9.3); · the set of error conditions that can occur in input/output statements (9.10); · the result of output of non-representable characters to a Unicode file (10.7.1); · the interpretation of the optional non-blank characters within the parentheses of a real NaN input field (10.7.2.3.2); · the interpretation of a sign in a NaN input field (10.7.2.3.2); · for output of an IEEE NaN, whether after the letters 'NaN', the processor produces additional alphanumeric characters enclosed in parentheses (10.7.2.3.2); · the effect of the I/O rounding mode PROCESSOR DEFINED (10.7.2.3.7); · with an I/O rounding mode of NEAREST, for converting a value that is exactly halfway between the two nearest representable values in the result format, which value is chosen (10.7.2.3.7); · the field width used for the B0, O0, and Z0 edit descriptors (10.7.2.4); · the field width used for the G0 edit descriptor (10.7.5); 595 J3/07-007 WORKING DRAFT 2006/01/05 · the file position when position editing skips a character of type nondefault character in an external unit that is not connected to a Unicode file (10.8.1); · when the sign mode is PROCESSOR DEFINED, whether a plus sign appears in a numeric output field for a nonnegative value (10.8.4); · the results of list-directed output, as described in 10.10.4; · the results of namelist output, as described in 10.11.4; · the interaction between argument association and pointer association, as described in 12.5.2.5; · the values returned by some intrinsic functions, as described in 13; · the extent to which a processor supports IEEE arithmetic (14); · the values of the floating-point exception flags on entry to a procedure defined by means other than Fortran (15.5.3). D.3 Unresolved Technical Issues J3 internal note Unresolved Technical Issue 100 Ungrammatical gobbledygook with nonsensical references. That's the following paragraph. The representation methods (4.1.1 Set of values) and the kind type parameter values specifying a representation method supported by a processor is not specified by this part of ISO/IEC 1539. (4.2 Type parameters). It is also false to fact; the standard does specify the kind values for BITS. When rewording, · pay attention to singular and plural, · only make true statements, · find the normative text supporting the statements, and · get the references to said text right. J3 internal note Unresolved Technical Issue 107 Not defined by Fortran means exactly that. The text said: "The interface of a procedure defined by means other than Fortran may be specified by an interface body or procedure declaration statement. The means by which such a procedure is defined are processor dependent (12.6.3)." This is nonsense. If it is defined by means other than Fortran, it is not covered by the standard at all ... any more than your cup of coffee is. The means are not processor dependent, they are completely outwith the scope of the standard. The standard is about the Fortran programming language. If you call a procedure not defined by Fortran it is not defined by Fortran. It is not "defined by Fortran to be processor-dependent", it is just "not defined by Fortran". End of story. Fix the text in c12 to avoid saying this nonsense. 596 2006/01/05 WORKING DRAFT J3/07-007 J3 internal note Unresolved Technical Issue 108 Ordering requirement text not normative. The quoted text here is not normative, and not supported by any normative text. In particular, you cannot "give permission to do something" in a note. If this is covered by the first exclusion, the note should be rewritten to reference that exclusion, and the paragraph above should be struck. 597 J3/07-007 WORKING DRAFT 2006/01/05 598 2006/01/05 WORKING DRAFT J3/07-007 Annex E (Informative) Syntax rules E.1 Extract of all syntax rules Clause 1: R101 xyz-list is xyz [ , xyz ] ... R102 xyz-name is name R103 scalar-xyz is xyz C101 (R103) scalar-xyz shall be scalar. Clause 2: R201 program is program-unit [ program-unit ] ... R202 program-unit is main-program or external-subprogram or module or submodule or block-data R203 external-subprogram is function-subprogram or subroutine-subprogram R204 specification-part is [ use-stmt ] ... [ import-stmt ] ... [ implicit-part ] [ declaration-construct ] ... R205 implicit-part is [ implicit-part-stmt ] ... implicit-stmt R206 implicit-part-stmt is implicit-stmt or parameter-stmt or format-stmt or entry-stmt R207 declaration-construct is derived-type-def or entry-stmt or enum-def or format-stmt or interface-block or macro-definition or parameter-stmt or procedure-declaration-stmt or specification-stmt or type-declaration-stmt or stmt-function-stmt 599 J3/07-007 WORKING DRAFT 2006/01/05 R208 execution-part is executable-construct [ execution-part-construct ] ... R209 execution-part-construct is executable-construct or format-stmt or entry-stmt or data-stmt R210 internal-subprogram-part is contains-stmt [ internal-subprogram ] ... R211 internal-subprogram is function-subprogram or subroutine-subprogram R212 specification-stmt is access-stmt or allocatable-stmt or asynchronous-stmt or bind-stmt or common-stmt or data-stmt or dimension-stmt or equivalence-stmt or external-stmt or intent-stmt or intrinsic-stmt or namelist-stmt or optional-stmt or pointer-stmt or protected-stmt or save-stmt or target-stmt or volatile-stmt or value-stmt R213 executable-construct is action-stmt or associate-construct or block-construct or case-construct or critical-construct or do-construct or forall-construct or if-construct or select-type-construct or where-construct R214 action-stmt is allocate-stmt or assignment-stmt or backspace-stmt or call-stmt or close-stmt or continue-stmt or cycle-stmt 600 2006/01/05 WORKING DRAFT J3/07-007 or deallocate-stmt or end-function-stmt or end-mp-subprogram-stmt or end-program-stmt or end-subroutine-stmt or endfile-stmt or exit-stmt or flush-stmt or forall-stmt or goto-stmt or if-stmt or inquire-stmt or notify-stmt or nullify-stmt or open-stmt or pointer-assignment-stmt or print-stmt or query-stmt or read-stmt or return-stmt or rewind-stmt or stop-stmt or sync-all-stmt or sync-images-stmt or sync-memory-stmt or sync-team-stmt or wait-stmt or where-stmt or write-stmt or arithmetic-if-stmt or computed-goto-stmt C201 (R208) An execution-part shall not contain an end-function-stmt, end-mp-subprogram-stmt, end- program-stmt, or end-subroutine-stmt. R215 keyword is name Clause 3: R301 character is alphanumeric-character or special-character R302 alphanumeric-character is letter or digit or underscore R303 underscore is R304 name is letter [ alphanumeric-character ] ... C301 (R304) The maximum length of a name is 63 characters. R305 constant is literal-constant or named-constant R306 literal-constant is int-literal-constant 601 J3/07-007 WORKING DRAFT 2006/01/05 or real-literal-constant or complex-literal-constant or logical-literal-constant or char-literal-constant or bits-literal-constant R307 named-constant is name R308 int-constant is constant C302 (R308) int-constant shall be of type integer. R309 char-constant is constant C303 (R309) char-constant shall be of type character. R310 intrinsic-operator is power-op or mult-op or add-op or concat-op or rel-op or not-op or and-op or or-op or equiv-op R311 defined-operator is defined-unary-op or defined-binary-op or extended-intrinsic-op R312 extended-intrinsic-op is intrinsic-operator R313 label is digit [ digit [ digit [ digit [ digit ] ] ] ] C304 (R313) At least one digit in a label shall be nonzero. R314 macro-definition is define-macro-stmt [ macro-declaration-stmt ] ... macro-body-block end-macro-stmt R315 define-macro-stmt is DEFINE MACRO [ , macro-attr-list ] :: macro-name [ ( [ macro-dummy-arg-name-list ] ) ] C305 (R315) A macro-dummy-arg-name shall not appear more than once in a macro-dummy-arg- name-list. R316 macro-attr is access-spec R317 macro-declaration-stmt is macro-type-declaration-stmt or macro-optional-decl-stmt or macro-variable-decl-stmt R318 macro-type-declaration-stmt is MACRO macro-type-spec :: macro-local-variable-name-list R319 macro-optional-decl-stmt is MACRO OPTIONAL :: macro-dummy-arg-name-list R320 macro-variable-decl-stmt is MACRO VARIABLE :: macro-local-variable-name-list R321 macro-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] C306 (R318, macro-variable-decl-stmt) A macro-local-variable-name shall not be the same as the name of a dummy argument of the macro being defined. C307 (R319) A macro-dummy-arg-name shall be the name of a dummy argument of the macro being defined. C308 (R321) If macro-expr appears, when the macro is expanded macro-expr shall be of type integer, and have a non-negative value that specifies a representation method that exists on the processor. 602 2006/01/05 WORKING DRAFT J3/07-007 R322 macro-body-block is [ macro-body-construct ] ... R323 macro-body-construct is macro-definition or expand-stmt or macro-body-stmt or macro-do-construct or macro-if-construct or macro-int-assignment-stmt or macro-tok-assignment-stmt C309 A statement in a macro definition that is not a macro-body-construct or macro-definition shall not appear on a line with any other statement. R324 macro-do-construct is macro-do-stmt macro-body-block macro-end-do-stmt R325 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , macro-do-limit [ , macro-do-limit ] C310 (R325) A macro-do-variable-name shall be a local variable of the macro being defined, and shall not be a macro dummy argument. R326 macro-do-limit is macro-expr C311 (R326) A macro-do-limit shall expand to an expression of type integer. R327 macro-end-do-stmt is MACRO END DO R328 macro-if-construct is macro-if-then-stmt macro-body-block [ macro-else-if-stmt macro-body-block ] ... [ macro-else-stmt macro-body-block ] macro-end-if-stmt R329 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN R330 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN R331 macro-else-stmt is MACRO ELSE R332 macro-end-if-stmt is MACRO END IF R333 macro-condition is macro-expr C312 (R333) A macro condition shall expand to an expression of type logical. R334 macro-int-assignment-stmt is MACRO macro-integer-variable-name = macro-expr C313 (R334) macro-integer-variable-name shall be the name of a macro local variable of type integer. R335 macro-tok-assignment-stmt is MACRO macro-tok-variable-name = assignment-tok-sequence C314 (R335) macro-tok-variable-name shall be the name of an untyped macro local variable that is not a macro dummy argument. R336 assignment-tok-sequence is result-token [ result-token ] ... [ && ] R337 macro-body-stmt is result-token [ result-token ] ... [ && ] C315 (R337) If the first result-token is MACRO the second result-token shall not be a keyword or name. C316 (R337) If the first token is DEFINE the second token shall not be MACRO. R338 result-token is token [ %% token ] ... R339 token is any lexical token including labels, keywords, and semi-colon. C317 && shall not appear in the last macro-body-stmt of a macro definition. C318 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. 603 J3/07-007 WORKING DRAFT 2006/01/05 R340 end-macro-stmt is END MACRO [ macro-name ] C319 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name in the DEFINE MACRO statement. R341 macro-expr is basic-token-sequence C320 (R341) A macro-expr shall expand to a scalar initialization expression. R342 expand-stmt is EXPAND macro-name [ ( macro-actual-arg-list ) ] C321 (R342) macro-name shall be the name of a macro that was previously defined or accessed via use or host association. C322 (R342) The macro shall expand to a sequence or zero or more complete Fortran statements. C323 (R342) The statements produced by a macro expansion shall conform to the syntax rules and constraints as if they replaced the EXPAND statement prior to program processing. C324 (R342) The statements produced by a macro expansion shall not include a statement which ends the scoping unit containing the EXPAND statement. C325 (R342) If a macro expansion produces a statement which begins a new scoping unit, it shall also produce a statement which ends that scoping unit. C326 (R342) If the EXPAND statement appears as the action-stmt of an if-stmt, it shall expand to exactly one action-stmt that is not an end-function-stmt, end-mp-subprogram-stmt, end- program-stmt, end-subroutine-stmt, or if-stmt. C327 (R342) If the EXPAND statement appears as a do-term-action-stmt, it shall expand to exactly one action- stmt that is not an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, end-mp-subprogram-stmt, end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. C328 (R342) If the EXPAND statement has a label, the expansion of the macro shall produce at least one statement, and the first statement produced shall not have a label. C329 (R342) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- gument. C330 (R342) At most one macro-actual-arg shall appear corresponding to each optional macro dummy argument. R343 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value C331 (R343) macro-dummy-name shall be the name of a macro dummy argument of the macro being expanded. C332 (R342) The macro-dummy-name= shall not be omitted unless it has been omitted from each preceding macro-actual-arg in the expand-stmt. R344 macro-actual-arg-value is basic-token-sequence R345 basic-token-sequence is basic-token or [ basic-token-sequence] nested-token-sequence [ basic-token-sequence ] or basic-token basic-token-sequence R346 basic-token is any lexical token except comma, parentheses, array constructor delimiters, and semi-colon. R347 nested-token-sequence is ( [ arg-token ] ... ) or (/ [ arg-token ] ... /) or lbracket [ arg-token ] ... rbracket R348 arg-token is basic-token or , C333 (R338) The result of token concatenation shall have the form of a lexical token. Clause 4: R401 type-param-value is scalar-int-expr or * 604 2006/01/05 WORKING DRAFT J3/07-007 or : C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. C402 (R401) A colon shall not be used as a type-param-value except in the declaration of an entity or component that has the POINTER or ALLOCATABLE attribute. R402 type-spec is intrinsic-type-spec or derived-type-spec C403 (R402) The derived-type-spec shall not specify an abstract type (4.5.7). R403 declaration-type-spec is intrinsic-type-spec or TYPE ( intrinsic-type-spec ) or TYPE ( derived-type-spec ) or CLASS ( derived-type-spec ) or CLASS ( * ) C404 (R403) In a declaration-type-spec, every type-param-value that is not a colon or an asterisk shall be a specification-expr. C405 (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify an extensible type (4.5.7). C406 (R403) The TYPE(derived-type-spec) shall not specify an abstract type (4.5.7). C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLO- CATABLE or POINTER attribute. It shall not have the VALUE attribute. R404 intrinsic-type-spec is INTEGER [ kind-selector ] or REAL [ kind-selector ] or DOUBLE PRECISION or COMPLEX [ kind-selector ] or CHARACTER [ char-selector ] or LOGICAL [ kind-selector ] or BITS [ kind-selector ] R405 kind-selector is ( [ KIND = ] scalar-int-initialization-expr ) C408 (R405) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- resentation method that exists on the processor. R406 signed-int-literal-constant is [ sign ] int-literal-constant R407 int-literal-constant is digit-string [ kind-param ] R408 kind-param is digit-string or scalar-int-constant-name R409 signed-digit-string is [ sign ] digit-string R410 digit-string is digit [ digit ] ... R411 sign is + or ­ C409 (R408) A scalar-int-constant-name shall be a named constant of type integer. C410 (R408) The value of kind-param shall be nonnegative. C411 (R407) The value of kind-param shall specify a representation method that exists on the pro- cessor. R412 signed-real-literal-constant is [ sign ] real-literal-constant R413 real-literal-constant is significand [ exponent-letter exponent ] [ kind-param ] or digit-string exponent-letter exponent [ kind-param ] R414 significand is digit-string . [ digit-string ] or . digit-string R415 exponent-letter is E 605 J3/07-007 WORKING DRAFT 2006/01/05 or D R416 exponent is signed-digit-string C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. C413 (R413) The value of kind-param shall specify an approximation method that exists on the processor. R417 complex-literal-constant is ( real-part , imag-part ) R418 real-part is signed-int-literal-constant or signed-real-literal-constant or named-constant R419 imag-part is signed-int-literal-constant or signed-real-literal-constant or named-constant C414 (R417) Each named constant in a complex literal constant shall be of type integer or real. R420 char-selector is length-selector or ( LEN = type-param-value , KIND = scalar-int-initialization-expr ) or ( type-param-value , [ KIND = ] scalar-int-initialization-expr ) or ( KIND = scalar-int-initialization-expr [ , LEN =type-param-value ] ) R421 length-selector is ( [ LEN = ] type-param-value ) or * char-length [ , ] R422 char-length is ( type-param-value ) or int-literal-constant C415 (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- resentation method that exists on the processor. C416 (R422) The int-literal-constant shall not include a kind-param. C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr. C418 (R420 R421 R422) A type-param-value of * shall be used only C419 A function name shall not be declared with an asterisk type-param-value 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. C420 A function name declared with an asterisk type-param-value shall not be an array, a pointer, elemental, recursive, or pure. C421 (R421) The optional comma in a length-selector is permitted only in a declaration-type-spec in a type-declaration- stmt. C422 (R421) The optional comma in a length-selector is permitted only if no double-colon separator appears in the type-declaration-stmt. C423 (R420) The length specified for a character statement function or for a statement function dummy argument of type character shall be an initialization expression. R423 char-literal-constant is [ kind-param ] ' [ rep-char ] ... ' or [ kind-param ] " [ rep-char ] ... " C424 (R423) The value of kind-param shall specify a representation method that exists on the pro- cessor. R424 logical-literal-constant is .TRUE. [ kind-param ] or .FALSE. [ kind-param ] C425 (R424) The value of kind-param shall specify a representation method that exists on the pro- cessor. R425 bits-literal-constant is binary-constant [ kind-param ] 606 2006/01/05 WORKING DRAFT J3/07-007 or octal-constant [ kind-param ] or hex-constant [ kind-param ] R426 binary-constant is B ' digit [ digit ] ... ' or B " digit [ digit ] ... " C426 (R426) digit shall have one of the values 0 or 1. R427 octal-constant is O ' digit [ digit ] ... ' or O " digit [ digit ] ... " C427 (R427) digit shall have one of the values 0 through 7. R428 hex-constant is Z ' hex-digit [ hex-digit ] ... ' or Z " hex-digit [ hex-digit ] ... " R429 hex-digit is digit or A or B or C or D or E or F R430 derived-type-def is derived-type-stmt [ type-param-def-stmt ] ... [ private-or-sequence ] ... [ component-part ] [ type-bound-procedure-part ] end-type-stmt R431 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name [ ( type-param-name-list ) ] R432 type-attr-spec is ABSTRACT or access-spec or BIND (C) or EXTENDS ( parent-type-name ) C428 (R431) A derived type type-name shall not be DOUBLEPRECISION or the same as the name of any intrinsic type defined in this part of ISO/IEC 1539. C429 (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt. C430 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). C431 (R430) If the type definition contains or inherits (4.5.7.2) a deferred binding (4.5.5), ABSTRACT shall appear. C432 (R430) If ABSTRACT appears, the type shall be extensible. C433 (R430) If EXTENDS appears, SEQUENCE shall not appear. C434 (R430) If EXTENDS appears and the type being defined has a co-array ultimate component, its parent type shall have a co-array ultimate component. R433 private-or-sequence is private-components-stmt or sequence-stmt C435 (R430) The same private-or-sequence shall not appear more than once in a given derived-type- def . R434 end-type-stmt is END TYPE [ type-name ] C436 (R434) If END TYPE is followed by a type-name, the type-name shall be the same as that in the corresponding derived-type-stmt. 607 J3/07-007 WORKING DRAFT 2006/01/05 R435 sequence-stmt is SEQUENCE C437 (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type or of a sequence derived type. C438 (R430) If SEQUENCE appears, a type-bound-procedure-part shall not appear. R436 type-param-def-stmt is INTEGER [ kind-selector ] , type-param-attr-spec :: type-param-decl-list R437 type-param-decl is type-param-name [ = scalar-int-initialization-expr ] C439 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the type-param-names in the derived-type-stmt of that derived-type-def . C440 (R436) Each type-param-name in the derived-type-stmt in a derived-type-def shall appear as a type-param-name in a type-param-def-stmt in that derived-type-def . R438 type-param-attr-spec is KIND or LEN R439 component-part is [ component-def-stmt ] ... R440 component-def-stmt is data-component-def-stmt or proc-component-def-stmt R441 data-component-def-stmt is declaration-type-spec [ [ , component-attr-spec-list ] :: ] component-decl-list R442 component-attr-spec is access-spec or ALLOCATABLE or DIMENSION ( component-array-spec ) or DIMENSION [ ( deferred-shape-spec-list ) ] lbracket co-array-spec rbracket or CONTIGUOUS or POINTER R443 component-decl is component-name [ ( component-array-spec ) ] [ lbracket co-array-spec rbracket ] [ * char-length ] [ component-initialization ] R444 component-array-spec is explicit-shape-spec-list or deferred-shape-spec-list C441 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt. C442 (R441) If neither the POINTER nor ALLOCATABLE attribute is specified, the declaration-type- spec in the component-def-stmt shall specify an intrinsic type or a previously defined derived type. C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible derived type including the type being defined. C444 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec shall be a deferred-shape-spec-list. C445 (R441) If a co-array-spec appears, it shall be a deferred-co-shape-spec-list and the component shall have the ALLOCATABLE attribute. C446 (R441) If a co-array-spec appears, the component shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). C447 A data component whose type has a co-array ultimate component shall be a nonpointer nonal- locatable scalar and shall not be a co-array. C448 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each component-array-spec shall be an explicit-shape-spec-list. C449 (R444) Each bound in the explicit-shape-spec shall either be an initialization expression or be a 608 2006/01/05 WORKING DRAFT J3/07-007 specification expression that does not contain references to specification functions or any object designators other than named constants or subobjects thereof. C450 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. C451 (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the POINTER attribute. C452 (R443) The * char-length option is permitted only if the component is of type character. C453 (R440) Each type-param-value within a component-def-stmt shall either be a colon, be an ini- tialization expression, or be a specification expression that contains neither references to speci- fication functions nor any object designators other than named constants or subobjects thereof. R445 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , proc-component-attr-spec-list :: proc-decl-list R446 proc-component-attr-spec is POINTER or PASS [ (arg-name) ] or NOPASS or access-spec C454 (R445) The same proc-component-attr-spec shall not appear more than once in a given proc- component-def-stmt. C455 (R445) POINTER shall appear in each proc-component-attr-spec-list. C456 (R445) If the procedure pointer component has an implicit interface or has no arguments, NOPASS shall be specified. C457 (R445) If PASS (arg-name) appears, the interface shall have a dummy argument named arg- name. C458 (R445) PASS and NOPASS shall not both appear in the same proc-component-attr-spec-list. C459 The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy data object with the same declared type as the type being defined; all of its length type parameters shall be assumed; it shall be polymorphic (4.3.1.3) if and only if the type being defined is extensible (4.5.7). It shall not have the VALUE attribute. R447 component-initialization is = initialization-expr or => null-init or => initial-data-target R448 initial-data-target is designator C460 (R441) If component-initialization appears, a double-colon separator shall appear before the component-decl-list. C461 (R441) If component-initialization appears, every type parameter and array bound of the com- ponent shall be a colon or initialization expression. C462 (R441) If => appears in component-initialization, POINTER shall appear in the component- attr-spec-list. If = appears in component-initialization, neither POINTER nor ALLOCATABLE shall appear in the component-attr-spec-list. C463 (R447) If initial-data-target appears, component-name shall be data-pointer-initialization com- patible with it. C464 (R448) The designator shall designate a variable that is an initialization target. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be an initialization expression. R449 private-components-stmt is PRIVATE C465 (R449) A private-components-stmt is permitted only if the type definition is within the specifi- cation part of a module. R450 type-bound-procedure-part is contains-stmt [ binding-private-stmt ] [ type-bound-proc-binding ] ... 609 J3/07-007 WORKING DRAFT 2006/01/05 R451 binding-private-stmt is PRIVATE C466 (R450) A binding-private-stmt is permitted only if the type definition is within the specification part of a module. R452 type-bound-proc-binding is type-bound-procedure-stmt or type-bound-generic-stmt or final-procedure-stmt R453 type-bound-procedure-stmt is PROCEDURE [ [ , binding-attr-list ] :: ] binding-name [ => procedure-name ] or PROCEDURE (interface-name) , binding-attr-list :: binding-name C467 (R453) If => procedure-name appears, the double-colon separator shall appear. C468 (R453) The procedure-name shall be the name of an accessible module procedure or an external procedure that has an explicit interface. R454 type-bound-generic-stmt is GENERIC [, access-spec ] :: generic-spec => binding-name-list C469 (R454) Within the specification-part of a module, each type-bound-generic-stmt shall specify, either implicitly or explicitly, the same accessibility as every other type-bound-generic-stmt with that generic-spec in the same derived type. C470 (R454) Each binding-name in binding-name-list shall be the name of a specific binding of the type. C471 (R454) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object dummy argument (4.5.4.4). C472 (R454) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall be as specified in 12.4.3.4.2. C473 (R454) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified in 12.4.3.4.3. C474 (R454) If generic-spec is dtio-generic-spec, the interface of each binding shall be as specified in 9.5.4.7. The type of the dtv argument shall be type-name. R455 binding-attr is PASS [ (arg-name) ] or NOPASS or NON OVERRIDABLE or DEFERRED or access-spec C475 (R455) The same binding-attr shall not appear more than once in a given binding-attr-list. C476 (R453) If the interface of the binding has no dummy argument of the type being defined, NOPASS shall appear. C477 (R453) If PASS (arg-name) appears, the interface of the binding shall have a dummy argument named arg-name. C478 (R455) PASS and NOPASS shall not both appear in the same binding-attr-list. C479 (R455) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- attr-list. C480 (R455) DEFERRED shall appear if and only if interface-name appears. C481 (R453) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding it overrides is deferred. C482 (R453) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- RIDABLE attribute. R456 final-procedure-stmt is FINAL [ :: ] final-subroutine-name-list C483 (R456) A final-subroutine-name shall be the name of a module procedure with exactly one 610 2006/01/05 WORKING DRAFT J3/07-007 dummy argument. That argument shall be nonoptional and shall be a nonpointer, nonallocat- able, nonpolymorphic variable of the derived type being defined. All length type parameters of the dummy argument shall be assumed. The dummy argument shall not have INTENT(OUT). C484 (R456) A final-subroutine-name shall not be one previously specified as a final subroutine for that type. C485 (R456) A final subroutine shall not have a dummy argument with the same kind type parameters and rank as the dummy argument of another final subroutine of that type. R457 derived-type-spec is type-name [ ( type-param-spec-list ) ] R458 type-param-spec is [ keyword = ] type-param-value C486 (R457) type-name shall be the name of an accessible derived type. C487 (R457) type-param-spec-list shall appear only if the type is parameterized. C488 (R457) There shall be at most one type-param-spec corresponding to each parameter of the type. If a type parameter does not have a default value, there shall be a type-param-spec corresponding to that type parameter. C489 (R458) The keyword= may be omitted from a type-param-spec only if the keyword= has been omitted from each preceding type-param-spec in the type-param-spec-list. C490 (R458) Each keyword shall be the name of a parameter of the type. C491 (R458) An asterisk may be used as a type-param-value in a type-param-spec only in the decla- ration of a dummy argument or associate name or in the allocation of a dummy argument. R459 structure-constructor is derived-type-spec ( [ component-spec-list ] ) R460 component-spec is [ keyword = ] component-data-source R461 component-data-source is expr or data-target or proc-target C492 (R459) The derived-type-spec shall not specify an abstract type (4.5.7). C493 (R459) At most one component-spec shall be provided for a component. C494 (R459) If a component-spec is provided for an ancestor component, a component-spec shall not be provided for any component that is inheritance associated with a subcomponent of that ancestor component. C495 (R459) A component-spec shall be provided for a nonallocatable component unless it has default initialization or is inheritance associated with a subcomponent of another component for which a component-spec is provided. C496 (R460) The keyword= may be omitted from a component-spec only if the keyword= has been omitted from each preceding component-spec in the constructor. C497 (R460) Each keyword shall be the name of a component of the type. C498 (R459) The type name and all components of the type for which a component-spec appears shall be accessible in the scoping unit containing the structure constructor. C499 (R459) If derived-type-spec is a type name that is the same as a generic name, the component- spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (12.5.5.2). C4100 (R461) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall correspond to a procedure pointer component. C4101 (R461) A data-target shall have the same rank as its corresponding component. R462 enum-def is enum-def-stmt enumerator-def-stmt [ enumerator-def-stmt ] ... end-enum-stmt R463 enum-def-stmt is ENUM, BIND(C) R464 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator-list 611 J3/07-007 WORKING DRAFT 2006/01/05 R465 enumerator is named-constant [ = scalar-int-initialization-expr ] R466 end-enum-stmt is END ENUM C4102 (R464) If = appears in an enumerator, a double-colon separator shall appear before the enu- merator-list. R467 array-constructor is (/ ac-spec /) or lbracket ac-spec rbracket R468 ac-spec is type-spec :: or [type-spec ::] ac-value-list R469 lbracket is [ R470 rbracket is ] R471 ac-value is expr or ac-implied-do R472 ac-implied-do is ( ac-value-list , ac-implied-do-control ) R473 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] R474 ac-do-variable is do-variable C4103 (R468) If type-spec is omitted, each ac-value expression in the array-constructor shall have the same type and kind type parameters. C4104 (R468) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor shall be of an intrinsic type that is in type conformance with a variable of type type-spec as specified in Table 7.12. C4105 (R468) If type-spec specifies a derived type, all ac-value expressions in the array-constructor shall be of that derived type and shall have the same kind type parameter values as specified by type-spec. C4106 (R472) The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do. Clause 5: R501 type-declaration-stmt is declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl-list R502 attr-spec is access-spec or ALLOCATABLE or ASYNCHRONOUS or CONTIGUOUS or dimension-spec or EXTERNAL or INTENT ( intent-spec ) or INTRINSIC or language-binding-spec or OPTIONAL or PARAMETER or POINTER or PROTECTED or SAVE or TARGET or VALUE or VOLATILE C501 (R501) The same attr-spec shall not appear more than once in a given type-declaration-stmt. C502 (R501) If a language-binding-spec with a NAME= specifier appears, the entity-decl-list shall 612 2006/01/05 WORKING DRAFT J3/07-007 consist of a single entity-decl. C503 (R501) If a language-binding-spec is specified, the entity-decl-list shall not contain any procedure names. R503 entity-decl is object-name [( array-spec )] [ lbracket co-array-spec rbracket ] [ * char-length ] [ initialization ] or function-name [ * char-length ] C504 (R503) If the entity is not of type character, * char-length shall not appear. C505 (R501) If initialization appears, a double-colon separator shall appear before the entity-decl-list. C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable variable, an external function, an intrinsic function, or an automatic object. C507 (R503) An initialization shall appear if the entity is a named constant (5.3.12). C508 (R503) The function-name shall be the name of an external function, an intrinsic function, a function dummy procedure, a procedure pointer, or a statement function. R504 object-name is name C509 (R504) The object-name shall be the name of a data object. R505 initialization is = initialization-expr or => null-init or => initial-data-target R506 null-init is function-reference C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = appears in initialization, the entity shall not have the POINTER attribute. C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it (4.5.4.5). C512 (R506) The function-reference shall be a reference to the NULL intrinsic function with no arguments. C513 An automatic object shall not be a local variable of a main program, module, or submodule. C514 An entity shall not be explicitly given any attribute more than once in a scoping unit. C515 An array-spec for a function result that does not have the ALLOCATABLE or POINTER attribute shall be an explicit-shape-spec-list. C516 The ALLOCATABLE, POINTER, or OPTIONAL attribute shall not be specified for a dummy argument of a procedure that has a proc-language-binding-spec. R507 access-spec is PUBLIC or PRIVATE C517 (R507) An access-spec shall appear only in the specification-part of a module. R508 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) C518 An entity with the BIND attribute shall be a common block, variable, or procedure. C519 A variable with the BIND attribute shall be declared in the specification part of a module. C520 A variable with the BIND attribute shall be interoperable (15.3). C521 Each variable of a common block with the BIND attribute shall be interoperable. C522 (R508) The scalar-char-initialization-expr shall be of default character kind. C523 An entity with the CONTIGUOUS attribute shall be an array pointer or an assumed-shape array. R509 dimension-spec is DIMENSION ( array-spec ) or DIMENSION [ ( array-spec ) ] lbracket co-array-spec rbracket C524 (R501) A co-array with the ALLOCATABLE attribute shall be specified with a co-array-spec 613 J3/07-007 WORKING DRAFT 2006/01/05 that is a deferred-co-shape-spec-list. C525 A co-array shall be a component or a variable that is not a function result. C526 A co-array shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). C527 An entity whose type has a co-array ultimate component shall be a nonpointer nonallocatable scalar, shall not be a co-array, and shall not be a function result. C528 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared in the main program, or allocatable. R510 array-spec is explicit-shape-spec-list or assumed-shape-spec-list or deferred-shape-spec-list or assumed-size-spec or implied-shape-spec-list R511 co-array-spec is deferred-co-shape-spec-list or explicit-co-shape-spec C529 The sum of the rank and co-rank of an entity shall not exceed fifteen. R512 explicit-shape-spec is [ lower-bound : ] upper-bound R513 lower-bound is specification-expr R514 upper-bound is specification-expr C530 (R512) An explicit-shape-spec whose bounds are not initialization expressions shall appear only in a subprogram or interface body. R515 assumed-shape-spec is [ lower-bound ] : R516 deferred-shape-spec is : C531 An array with the POINTER or ALLOCATABLE attribute shall have an array-spec that is a deferred-shape-spec-list. R517 assumed-size-spec is [ explicit-shape-spec , ]... [ lower-bound : ] * C532 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy data argument. C533 An assumed-size array with INTENT (OUT) shall not be polymorphic, of a finalizable type, of a type with an ultimate allocatable component, or of a type for which default initialization is specified. R518 implied-shape-spec is [ lower-bound : ] * C534 An implied-shape array shall be a named constant. R519 deferred-co-shape-spec is : C535 A co-array with the ALLOCATABLE attribute shall have a co-array-spec that is a deferred-co- shape-spec-list. R520 explicit-co-shape-spec is [ [ lower-co-bound : ] upper-co-bound, ]... [ lower-co-bound : ] * C536 A co-array that does not have the ALLOCATABLE attribute shall have a co-array-spec that is an explicit-co-shape-spec. R521 lower-co-bound is specification-expr R522 upper-co-bound is specification-expr C537 (R520) A lower-co-bound or upper-co-bound that is not an initialization expression shall appear only in a subprogram or interface body. C538 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. C539 In an external subprogram, the EXTERNAL attribute shall not be specified for a procedure defined by the subprogram. R523 intent-spec is IN or OUT 614 2006/01/05 WORKING DRAFT J3/07-007 or INOUT C540 An entity with the INTENT attribute shall be a dummy data object or a dummy procedure pointer. C541 (R523) A nonpointer object with the INTENT (IN) attribute shall not appear in a variable definition context (16.6.7). C542 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context (16.6.8). C543 If the name of a generic intrinsic procedure is explicitly declared to have the INTRINSIC at- tribute, and it is also the generic name of one or more generic interfaces (12.4.3.2) accessible in the same scoping unit, the procedures in the interfaces and the specific intrinsic procedures shall all be functions or all be subroutines, and the characteristics of the specific intrinsic procedures and the procedures in the interfaces shall differ as specified in 12.4.3.4.5. C544 An entity with the OPTIONAL attribute shall be a dummy argument. C545 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. C546 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or TARGET attribute, and shall not be a co-array. C547 A procedure with the POINTER attribute shall have the EXTERNAL attribute. C548 The PROTECTED attribute shall be specified only in the specification part of a module. C549 An entity with the PROTECTED attribute shall be a procedure pointer or variable. C550 An entity with the PROTECTED attribute shall not be in a common block. C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition context (16.6.7) or as the data-target or proc-target in a pointer-assignment-stmt. C552 A pointer that has the PROTECTED attribute and is accessed by use association shall not appear in a pointer association context (16.6.8). (1) A pointer-object in a pointer-assignment-stmt or nullify-stmt, (2) An allocate-object in an allocate-stmt or deallocate-stmt, or (3) An actual argument in a reference to a procedure if the associated dummy argument is a pointer with the INTENT(OUT) or INTENT(INOUT) attribute. C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. C554 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic data object, or an object that is in a common block. C555 An entity with the TARGET attribute shall be a variable. C556 An entity with the TARGET attribute shall not have the POINTER attribute. C557 An entity with the VALUE attribute shall be a scalar dummy data object. C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. C559 If an entity has the VALUE attribute, any length type parameter value in its declaration shall be omitted or specified by an initialization expression. C560 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy argument. R524 access-stmt is access-spec [ [ :: ] access-id-list ] R525 access-id is use-name or generic-spec C561 (R524) An access-stmt shall appear only in the specification-part of a module. Only one ac- cessibility statement with an omitted access-id-list is permitted in the specification-part of a module. C562 (R525) Each use-name shall be the name of a named variable, procedure, derived type, named constant, namelist group, or macro. 615 J3/07-007 WORKING DRAFT 2006/01/05 R526 allocatable-stmt is ALLOCATABLE [ :: ] allocatable-decl-list R527 allocatable-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] R528 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name-list R529 bind-stmt is language-binding-spec [ :: ] bind-entity-list R530 bind-entity is entity-name or / common-block-name / C563 (R529) If the language-binding-spec has a NAME= specifier, the bind-entity-list shall consist of a single bind-entity. R531 contiguous-stmt is CONTIGUOUS [ :: ] object-name-list R532 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... R533 data-stmt-set is data-stmt-object-list / data-stmt-value-list / R534 data-stmt-object is variable or data-implied-do R535 data-implied-do is ( data-i-do-object-list , data-i-do-variable = scalar-int-initialization-expr , scalar-int-initialization-expr [ , scalar-int-initialization-expr ] ) R536 data-i-do-object is array-element or scalar-structure-component or data-implied-do R537 data-i-do-variable is do-variable C564 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. C565 (R534) In a variable that is a data-stmt-object, any subscript, section subscript, substring start- ing point, and substring ending point shall be an initialization expression. C566 (R534) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall not be a dummy argument, made accessible by use association or host association, in a named common block unless the DATA statement is in a block data program unit, in a blank common block, a function name, a function result name, an automatic object, or an allocatable variable. C567 (R534) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an object designator in which a pointer appears other than as the entire rightmost part-ref . C568 (R536) The array-element shall be a variable. C569 (R536) The scalar-structure-component shall be a variable. C570 (R536) The scalar-structure-component shall contain at least one part-ref that contains a sub- script-list. C571 (R536) In an array-element or scalar-structure-component that is a data-i-do-object, any sub- script shall be an initialization expression, and any primary within that subscript that is a data-i-do-variable shall be a DO variable of this data-implied-do or of a containing data-implied- do. R538 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant R539 data-stmt-repeat is scalar-int-constant or scalar-int-constant-subobject C572 (R539) The data-stmt-repeat shall be positive or zero. If the data-stmt-repeat is a named con- stant, it shall have been declared previously in the scoping unit or made accessible by use association or host association. R540 data-stmt-constant is scalar-constant or scalar-constant-subobject or signed-int-literal-constant 616 2006/01/05 WORKING DRAFT J3/07-007 or signed-real-literal-constant or null-init or initial-data-target or structure-constructor C573 (R540) If a DATA statement constant value is a named constant or a structure constructor, the named constant or derived type shall have been declared previously in the scoping unit or made accessible by use or host association. C574 (R540) If a data-stmt-constant is a structure-constructor, it shall be an initialization expression. R541 int-constant-subobject is constant-subobject C575 (R541) int-constant-subobject shall be of type integer. R542 constant-subobject is designator C576 (R542) constant-subobject shall be a subobject of a constant. C577 (R542) Any subscript, substring starting point, or substring ending point shall be an initializa- tion expression. R543 dimension-stmt is DIMENSION [ :: ] dimension-decl-list R544 dimension-decl is array-name ( array-spec ) or co-name [ ( array-spec ) ] lbracket co-array-spec rbracket R545 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name-list R546 optional-stmt is OPTIONAL [ :: ] dummy-arg-name-list R547 parameter-stmt is PARAMETER ( named-constant-def -list ) R548 named-constant-def is named-constant = initialization-expr R549 pointer-stmt is POINTER [ :: ] pointer-decl-list R550 pointer-decl is object-name [ ( deferred-shape-spec-list ) ] or proc-entity-name R551 protected-stmt is PROTECTED [ :: ] entity-name-list R552 save-stmt is SAVE [ [ :: ] saved-entity-list ] R553 saved-entity is object-name or proc-pointer-name or / common-block-name / R554 proc-pointer-name is name C578 (R552) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. R555 target-stmt is TARGET [ :: ] target-decl-list R556 target-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] R557 value-stmt is VALUE [ :: ] dummy-arg-name-list R558 volatile-stmt is VOLATILE [ :: ] object-name-list R559 implicit-stmt is IMPLICIT implicit-spec-list or IMPLICIT NONE R560 implicit-spec is declaration-type-spec ( letter-spec-list ) R561 letter-spec is letter [ ­ letter ] C579 (R559) If IMPLICIT NONE is specified in a scoping unit, it shall precede any PARAMETER statements that appear in the scoping unit and there shall be no other IMPLICIT statements in the scoping unit. C580 (R561) If the minus and second letter appear, the second letter shall follow the first letter alphabetically. R562 namelist-stmt is NAMELIST 617 J3/07-007 WORKING DRAFT 2006/01/05 / namelist-group-name / namelist-group-object-list [ [ , ] / namelist-group-name / namelist-group-object-list ] ... C581 (R562) The namelist-group-name shall not be a name accessed by use association. R563 namelist-group-object is variable-name C582 (R563) A namelist-group-object shall not be an assumed-size array. C583 (R562) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- name has the PUBLIC attribute. R564 equivalence-stmt is EQUIVALENCE equivalence-set-list R565 equivalence-set is ( equivalence-object , equivalence-object-list ) R566 equivalence-object is variable-name or array-element or substring C584 (R566) An equivalence-object shall not be a designator with a base object that is a dummy argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ulti- mate component, an object of a nonsequence derived type, an object of a derived type that has a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a variable with the BIND attribute, a variable in a common block that has the BIND attribute, or a named constant. C585 (R566) An equivalence-object shall not be a designator that has more than one part-ref . C586 (R566) An equivalence-object shall not be a co-array or a subobject thereof. C587 (R566) An equivalence-object shall not have the TARGET attribute. C588 (R566) Each subscript or substring range expression in an equivalence-object shall be an integer initialization expression (7.1.12). C589 (R565) If an equivalence-object is of type default integer, default real, double precision real, default complex, default logical, default bits, or numeric sequence type, all of the objects in the equivalence set shall be of these types. C590 (R565) If an equivalence-object is of type default character or character sequence type, all of the objects in the equivalence set shall be of these types. C591 (R565) If an equivalence-object is of a sequence derived type that is not a numeric sequence or character sequence type, all of the objects in the equivalence set shall be of the same type with the same type parameter values. C592 (R565) If an equivalence-object is of an intrinsic type other than default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set shall be of the same type with the same kind type parameter value. C593 (R566) If an equivalence-object has the PROTECTED attribute, all of the objects in the equiv- alence set shall have the PROTECTED attribute. C594 (R566) The name of an equivalence-object shall not be a name made accessible by use association. C595 (R566) A substring shall not have length zero. R567 common-stmt is COMMON [ / [ common-block-name ] / ] common-block-object-list [ [ , ] / [ common-block-name ] / common-block-object-list ] ... R568 common-block-object is variable-name [ ( array-spec ) ] or proc-pointer-name C596 (R568) An array-spec in a common-block-object shall be an explicit-shape-spec-list. C597 (R568) Only one appearance of a given variable-name or proc-pointer-name is permitted in all common-block-object-lists within a scoping unit. C598 (R568) A common-block-object shall not be a dummy argument, an allocatable variable, a 618 2006/01/05 WORKING DRAFT J3/07-007 derived-type object with an ultimate component that is allocatable, an automatic object, a function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. C599 (R568) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2.3) or a type with the BIND attribute and it shall have no default initialization. C5100 (R568) A variable-name or proc-pointer-name shall not be a name made accessible by use association. Clause 6: R601 variable is designator or expr C601 (R601) designator shall not be a constant or a subobject of a constant. C602 (R601) expr shall be a reference to a function that has a pointer result. R602 variable-name is name C603 (R602) variable-name shall be the name of a variable. R603 designator is object-name or array-element or array-section or complex-part-designator or structure-component or substring R604 logical-variable is variable C604 (R604) logical-variable shall be of type logical. R605 default-logical-variable is variable C605 (R605) default-logical-variable shall be of type default logical. R606 char-variable is variable C606 (R606) char-variable shall be of type character. R607 default-char-variable is variable C607 (R607) default-char-variable shall be of type default character. R608 int-variable is variable C608 (R608) int-variable shall be of type integer. R609 substring is parent-string ( substring-range ) R610 parent-string is scalar-variable-name or array-element or scalar-structure-component or scalar-constant R611 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] C609 (R610) parent-string shall be of type character. R612 data-ref is part-ref [ % part-ref ] ... R613 part-ref is part-name [ ( section-subscript-list ) ] [ image-selector ] C610 (R612) Each part-name except the rightmost shall be of derived type. C611 (R612) Each part-name except the leftmost shall be the name of a component of the declared type of the preceding part-name. C612 (R612) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. C613 (R612) The leftmost part-name shall be the name of a data object. C614 (R613) If a section-subscript-list appears, the number of section-subscripts shall equal the rank of part-name. C615 (R613) If image-selector appears, the number of co-subscripts shall be equal to the co-rank of 619 J3/07-007 WORKING DRAFT 2006/01/05 part-name. C616 (R613) If image-selector appears and part-name is an array, section-subscript-list shall appear. C617 (R612) If image-selector appears, data-ref shall not be, or have a direct component, of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). C618 (R612) A data-ref that is a co-indexed object shall not have a pointer ultimate component. C619 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. R614 structure-component is data-ref C620 (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form part-name. R615 complex-part-designator is designator % RE or designator % IM C621 (R615) The designator shall be of complex type. R616 type-param-inquiry is designator % type-param-name C622 (R616) The type-param-name shall be the name of a type parameter of the declared type of the object designated by the designator. R617 array-element is data-ref C623 (R617) Every part-ref shall have rank zero and the last part-ref shall contain a subscript-list. R618 array-section is data-ref [ ( substring-range ) ] or complex-part-designator C624 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have a section-subscript-list with nonzero rank, another part-ref shall have nonzero rank, or the complex-part-designator shall be an array. C625 (R618) If a substring-range appears, the rightmost part-name shall be of type character. R619 subscript is scalar-int-expr R620 section-subscript is subscript or subscript-triplet or vector-subscript R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ] R622 stride is scalar-int-expr R623 vector-subscript is int-expr C626 (R623) A vector-subscript shall be an integer array expression of rank one. C627 (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension of an assumed-size array. R624 image-selector is lbracket co-subscript-list rbracket R625 co-subscript is scalar-int-expr R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list [, alloc-opt-list ] ) R627 alloc-opt is ERRMSG = errmsg-variable or MOLD = source-expr or SOURCE = source-expr or STAT = stat-variable R628 stat-variable is scalar-int-variable R629 errmsg-variable is scalar-default-char-variable R630 source-expr is expr R631 allocation is allocate-object [ ( allocate-shape-spec-list ) ] [ lbracket allocate-co-array-spec rbracket ] 620 2006/01/05 WORKING DRAFT J3/07-007 R632 allocate-object is variable-name or structure-component R633 allocate-shape-spec is [ lower-bound-expr : ] upper-bound-expr R634 lower-bound-expr is scalar-int-expr R635 upper-bound-expr is scalar-int-expr R636 allocate-co-array-spec is [ allocate-co-shape-spec-list , ] [ lower-bound-expr : ] * R637 allocate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr C628 (R632) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. C629 (R626) If any allocate-object has a deferred type parameter, is unlimited polymorphic, or is of abstract type, either type-spec or source-expr shall appear. C630 (R626) If a type-spec appears, it shall specify a type with which each allocate-object is type compatible. C631 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each allocate-object is a dummy argument for which the corresponding type parameter is assumed. C632 (R626) If a type-spec appears, the kind type parameter values of each allocate-object shall be the same as the corresponding type parameter values of the type-spec. C633 (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr shall appear and have the same rank as allocate-object. If allocate-object is scalar, allocate- shape-spec-list shall not appear. C634 (R631) An allocate-co-array-spec shall appear if and only if the allocate-object is a co-array. C635 (R631) The number of allocate-shape-specs in an allocate-shape-spec-list shall be the same as the rank of the allocate-object. The number of allocate-co-shape-specs in an allocate-co-array-spec shall be one less than the co-rank of the allocate-object. C636 (R627) No alloc-opt shall appear more than once in a given alloc-opt-list. C637 (R626) At most one of source-expr and type-spec shall appear. C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with source-expr. If SOURCE= appears, source-expr shall be a scalar or have the same rank as each allocate-object. C639 (R626) Corresponding kind type parameters of allocate-object and source-expr shall have the same values. C640 (R626) type-spec shall not specify a type that has a co-array ultimate component. C641 (R630) The declared type of source-expr shall not have a co-array ultimate component. C642 (R632) An allocate-object shall not be a co-indexed object. R638 nullify-stmt is NULLIFY ( pointer-object-list ) R639 pointer-object is variable-name or structure-component or proc-pointer-name C643 (R639) Each pointer-object shall have the POINTER attribute. R640 deallocate-stmt is DEALLOCATE ( allocate-object-list [ , dealloc-opt-list ] ) C644 (R640) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. R641 dealloc-opt is STAT = stat-variable or ERRMSG = errmsg-variable C645 (R641) No dealloc-opt shall appear more than once in a given dealloc-opt-list. Clause 7: R701 primary is constant or designator or array-constructor or structure-constructor 621 J3/07-007 WORKING DRAFT 2006/01/05 or function-reference or type-param-inquiry or type-param-name or ( expr ) C701 (R701) The type-param-name shall be the name of a type parameter. C702 (R701) The designator shall not be a whole assumed-size array. R702 level-1-expr is [ defined-unary-op ] primary R703 defined-unary-op is . letter [ letter ] ... . C703 (R703) A defined-unary-op shall not contain more than 63 letters and shall not be the same as any intrinsic-operator or logical-literal-constant. R704 mult-operand is level-1-expr [ power-op mult-operand ] R705 add-operand is [ add-operand mult-op ] mult-operand R706 level-2-expr is [ [ level-2-expr ] add-op ] add-operand R707 power-op is ** R708 mult-op is * or / R709 add-op is + or ­ R710 level-3-expr is [ level-3-expr concat-op ] level-2-expr R711 concat-op is // R712 level-4-expr is [ level-3-expr rel-op ] level-3-expr R713 rel-op is .EQ. or .NE. or .LT. or .LE. or .GT. or .GE. or == or /= or < or <= or > or >= R714 and-operand is [ not-op ] level-4-expr R715 or-operand is [ or-operand and-op ] and-operand R716 equiv-operand is [ equiv-operand or-op ] or-operand R717 level-5-expr is [ level-5-expr equiv-op ] equiv-operand R718 not-op is .NOT. R719 and-op is .AND. R720 or-op is .OR. R721 equiv-op is .EQV. or .NEQV. or .XOR. R722 expr is [ expr defined-binary-op ] level-5-expr R723 defined-binary-op is . letter [ letter ] ... . C704 (R723) A defined-binary-op shall not contain more than 63 letters and shall not be the same as any intrinsic-operator or logical-literal-constant. 622 2006/01/05 WORKING DRAFT J3/07-007 R724 logical-expr is expr C705 (R724) logical-expr shall be of type logical. R725 char-expr is expr C706 (R725) char-expr shall be of type character. R726 default-char-expr is expr C707 (R726) default-char-expr shall be of type default character. R727 int-expr is expr C708 (R727) int-expr shall be of type integer. R728 numeric-expr is expr C709 (R728) numeric-expr shall be of type integer, real, or complex. C710 The kind type parameter of the result of a bits concatenation operation expression shall be a bits kind type parameter value supported by the processor. R729 specification-expr is scalar-int-expr C711 (R729) The scalar-int-expr shall be a restricted expression. R730 initialization-expr is expr C712 (R730) initialization-expr shall be an initialization expression. R731 char-initialization-expr is char-expr C713 (R731) char-initialization-expr shall be an initialization expression. R732 int-initialization-expr is int-expr C714 (R732) int-initialization-expr shall be an initialization expression. R733 logical-initialization-expr is logical-expr C715 (R733) logical-initialization-expr shall be an initialization expression. R734 assignment-stmt is variable = expr C716 (R734) The variable shall not be a whole assumed-size array. R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] => data-target or data-pointer-object (bounds-remapping-list ) => data-target or proc-pointer-object => proc-target R736 data-pointer-object is variable-name or scalar-variable % data-pointer-component-name C717 (R735) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal. C718 (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- phic, of a sequence derived type, or of a type with the BIND attribute. C719 (R735) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data- pointer-object. C720 (R735) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the rank of data-pointer-object. C721 (R735) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target shall be the same. C722 (R736) A variable-name shall have the POINTER attribute. C723 (R736) A scalar-variable shall be a data-ref . C724 (R736) A data-pointer-component-name shall be the name of a component of scalar-variable that is a data pointer. C725 (R736) A data-pointer-object shall not be a co-indexed object. R737 bounds-spec is lower-bound-expr : R738 bounds-remapping is lower-bound-expr : upper-bound-expr R739 data-target is variable 623 J3/07-007 WORKING DRAFT 2006/01/05 or expr C726 (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an array section with a vector subscript. C727 (R739) A data-target shall not be a co-indexed object. C728 (R739) An expr shall be a reference to a function whose result is a data pointer. R740 proc-pointer-object is proc-pointer-name or proc-component-ref R741 proc-component-ref is scalar-variable % procedure-component-name C729 (R741) The scalar-variable shall be a data-ref . C730 (R741) The procedure-component-name shall be the name of a procedure pointer component of the declared type of scalar-variable. R742 proc-target is expr or procedure-name or proc-component-ref C731 (R742) An expr shall be a reference to a function whose result is a procedure pointer. C732 (R742) A procedure-name shall be the name of an external, internal, module, or dummy proce- dure, a procedure pointer, or a specific intrinsic function listed in 13.6 and not marked with a bullet (·). C733 (R742) The proc-target shall not be a nonintrinsic elemental procedure. R743 where-stmt is WHERE ( mask-expr ) where-assignment-stmt R744 where-construct is where-construct-stmt [ where-body-construct ] ... [ masked-elsewhere-stmt [ where-body-construct ] ... ] ... [ elsewhere-stmt [ where-body-construct ] ... ] end-where-stmt R745 where-construct-stmt is [where-construct-name:] WHERE ( mask-expr ) R746 where-body-construct is where-assignment-stmt or where-stmt or where-construct R747 where-assignment-stmt is assignment-stmt R748 mask-expr is logical-expr R749 masked-elsewhere-stmt is ELSEWHERE (mask-expr) [where-construct-name] R750 elsewhere-stmt is ELSEWHERE [where-construct-name] R751 end-where-stmt is END WHERE [where-construct-name] C734 (R747) A where-assignment-stmt that is a defined assignment shall be elemental. C735 (R744) If the where-construct-stmt is identified by a where-construct-name, the corresponding end-where-stmt shall specify the same where-construct-name. If the where-construct-stmt is not identified by a where-construct-name, the corresponding end-where-stmt shall not specify a where-construct-name. If an elsewhere-stmt or a masked-elsewhere-stmt is identified by a where-construct-name, the corresponding where-construct-stmt shall specify the same where- construct-name. C736 (R746) A statement that is part of a where-body-construct shall not be a branch target statement. R752 forall-construct is forall-construct-stmt [forall-body-construct ] ... end-forall-stmt R753 forall-construct-stmt is [forall-construct-name :] FORALL forall-header 624 2006/01/05 WORKING DRAFT J3/07-007 R754 forall-header is ( [ type-spec :: ] forall-triplet-spec-list [, scalar-mask-expr] ) R755 forall-triplet-spec is index-name = subscript : subscript [ : stride] R756 forall-body-construct is forall-assignment-stmt or where-stmt or where-construct or forall-construct or forall-stmt R757 forall-assignment-stmt is assignment-stmt or pointer-assignment-stmt R758 end-forall-stmt is END FORALL [forall-construct-name ] C737 (R758) If the forall-construct-stmt has a forall-construct-name, the end-forall-stmt shall have the same forall-construct-name. If the end-forall-stmt has a forall-construct-name, the forall- construct-stmt shall have the same forall-construct-name. C738 (R754) type-spec shall specify type integer. C739 (R754) The scalar-mask-expr shall be scalar and of type logical. C740 (R754) Any procedure referenced in the scalar-mask-expr, including one referenced by a defined operation, shall be a pure procedure (12.7). C741 (R755) The index-name shall be a named scalar variable of type integer. C742 (R755) A subscript or stride in a forall-triplet-spec shall not contain a reference to any index- name in the forall-triplet-spec-list in which it appears. C743 (R756) A statement in a forall-body-construct shall not define an index-name of the forall- construct. C744 (R756) Any procedure referenced in a forall-body-construct, including one referenced by a defined operation, assignment, or finalization, shall be a pure procedure. C745 (R756) A forall-body-construct shall not be a branch target. C746 (R757) The variable in an assignment-stmt that is a forall-assignment-stmt shall be a designator. R759 forall-stmt is FORALL forall-header forall-assignment-stmt Clause 8: R801 block is [ execution-part-construct ] ... R802 associate-construct is associate-stmt block end-associate-stmt R803 associate-stmt is [ associate-construct-name : ] ASSOCIATE (association-list ) R804 association is associate-name => selector R805 selector is expr or variable C801 (R804) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). C802 (R804) An associate-name shall not be the same as another associate-name in the same associate- stmt. C803 (R805) expr shall not be a reference to a function that has a pointer result. R806 end-associate-stmt is END ASSOCIATE [ associate-construct-name ] C804 (R806) If the associate-stmt of an associate-construct specifies an associate-construct-name, the corresponding end-associate-stmt shall specify the same associate-construct-name. If the associate-stmt of an associate-construct does not specify an associate-construct-name, the cor- responding end-associate-stmt shall not specify an associate-construct-name. 625 J3/07-007 WORKING DRAFT 2006/01/05 R807 block-construct is block-stmt [ specification-part ] block end-block-stmt R808 block-stmt is [ block-construct-name : ] BLOCK R809 end-block-stmt is END BLOCK [ block-construct-name ] C805 (R807) The specification-part of a BLOCK construct shall not contain a COMMON, EQUIVA- LENCE, IMPLICIT, INTENT, NAMELIST, OPTIONAL, or USE statement. C806 (R807) A SAVE statement in a BLOCK construct shall contain a saved-entity-list that does not specify a common-block-name. C807 (R807) If the block-stmt of a block-construct specifies a block-construct-name, the corresponding end-block-stmt shall specify the same block-construct-name. If the block-stmt does not specify a block-construct-name, the corresponding end-block-stmt shall not specify a block-construct- name. R810 case-construct is select-case-stmt [ case-stmt block ] ... end-select-stmt R811 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) R812 case-stmt is CASE case-selector [case-construct-name] R813 end-select-stmt is END SELECT [ case-construct-name ] C808 (R810) If the select-case-stmt of a case-construct specifies a case-construct-name, the corre- sponding end-select-stmt shall specify the same case-construct-name. If the select-case-stmt of a case-construct does not specify a case-construct-name, the corresponding end-select-stmt shall not specify a case-construct-name. If a case-stmt specifies a case-construct-name, the corresponding select-case-stmt shall specify the same case-construct-name. R814 case-expr is scalar-int-expr or scalar-char-expr or scalar-logical-expr R815 case-selector is ( case-value-range-list ) or DEFAULT C809 (R810) No more than one of the selectors of one of the CASE statements shall be DEFAULT. R816 case-value-range is case-value or case-value : or : case-value or case-value : case-value R817 case-value is scalar-int-initialization-expr or scalar-char-initialization-expr or scalar-logical-initialization-expr C810 (R810) For a given case-construct, each case-value shall be of the same type as case-expr. For character type, the kind type parameters shall be the same; character length differences are allowed. C811 (R810) A case-value-range using a colon shall not be used if case-expr is of type logical. C812 (R810) For a given case-construct, the case-value-ranges shall not overlap; that is, there shall be no possible value of the case-expr that matches more than one case-value-range. R818 critical-construct is critical-stmt block end-critical-stmt 626 2006/01/05 WORKING DRAFT J3/07-007 R819 critical-stmt is [ critical-construct-name : ] CRITICAL R820 end-critical-stmt is END CRITICAL [ critical-construct-name ] C813 (R818) If the critical-stmt of a critical-construct specifies a critical-construct-name, the corre- sponding end-critical-stmt shall specify the same critical-construct-name. If the critical-stmt of a critical-construct does not specify a critical-construct-name, the corresponding end-critical-stmt shall not specify a critical-construct-name. C814 (R818) The block of a critical-construct shall not contain an image control statement. R821 do-construct is block-do-construct or nonblock-do-construct R822 block-do-construct is do-stmt do-block end-do R823 do-stmt is label-do-stmt or nonlabel-do-stmt R824 label-do-stmt is [ do-construct-name : ] DO label [ loop-control ] R825 nonlabel-do-stmt is [ do-construct-name : ] DO [ loop-control ] R826 loop-control is [ , ] do-variable = scalar-int-expr, scalar-int-expr [ , scalar-int-expr ] or [ , ] WHILE ( scalar-logical-expr ) or [ , ] CONCURRENT forall-header R827 do-variable is scalar-int-variable-name C815 (R827) The do-variable shall be a variable of type integer. R828 do-block is block R829 end-do is end-do-stmt or continue-stmt R830 end-do-stmt is END DO [ do-construct-name ] C816 (R822) If the do-stmt of a block-do-construct specifies a do-construct-name, the corresponding end-do shall be an end-do-stmt specifying the same do-construct-name. If the do-stmt of a block-do-construct does not specify a do-construct-name, the corresponding end-do shall not specify a do-construct-name. C817 (R822) If the do-stmt is a nonlabel-do-stmt, the corresponding end-do shall be an end-do-stmt. C818 (R822) If the do-stmt is a label-do-stmt, the corresponding end-do shall be identified with the same label. R831 nonblock-do-construct is action-term-do-construct or outer-shared-do-construct R832 action-term-do-construct is label-do-stmt do-body do-term-action-stmt R833 do-body is [ execution-part-construct ] ... R834 do-term-action-stmt is action-stmt C819 (R834) A do-term-action-stmt shall not be an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, end-mp-subprogram-stmt, end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. C820 (R831) The do-term-action-stmt shall be identified with a label and the corresponding label-do- stmt shall refer to the same label. R835 outer-shared-do-construct is label-do-stmt do-body shared-term-do-construct 627 J3/07-007 WORKING DRAFT 2006/01/05 R836 shared-term-do-construct is outer-shared-do-construct or inner-shared-do-construct R837 inner-shared-do-construct is label-do-stmt do-body do-term-shared-stmt R838 do-term-shared-stmt is action-stmt C821 (R838) A do-term-shared-stmt shall not be an arithmetic-if-stmt, cycle-stmt, end-function-stmt, end-program-stmt, end-mp-subprogram-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return- stmt, or stop-stmt. C822 (R836) The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the inner-shared-do-construct and outer-shared-do-construct shall refer to the same label. R839 cycle-stmt is CYCLE [ do-construct-name ] C823 (R839) If a do-construct-name appears, the CYCLE statement shall be within the range of that do-construct; otherwise, it shall be within the range of at least one do-construct. C824 (R839) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it belongs to an outer construct. C825 A RETURN statement shall not appear within a DO CONCURRENT construct. C826 A branch (8.2) within a DO CONCURRENT construct shall not have a branch target that is outside the construct. C827 A reference to a nonpure procedure shall not appear within a DO CONCURRENT construct. C828 A reference to the procedure IEEE GET FLAG, IEEE SET HALTING MODE, or IEEE GET - HALTING MODE from the intrinsic module IEEE EXCEPTIONS, shall not appear within a DO CONCURRENT construct. R840 if-construct is if-then-stmt block [ else-if-stmt block ] ... [ else-stmt block ] end-if-stmt R841 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN R842 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] R843 else-stmt is ELSE [ if-construct-name ] R844 end-if-stmt is END IF [ if-construct-name ] C829 (R840) If the if-then-stmt of an if-construct specifies an if-construct-name, the corresponding end-if-stmt shall specify the same if-construct-name. If the if-then-stmt of an if-construct does not specify an if-construct-name, the corresponding end-if-stmt shall not specify an if-construct- name. If an else-if-stmt or else-stmt specifies an if-construct-name, the corresponding if-then- stmt shall specify the same if-construct-name. R845 if-stmt is IF ( scalar-logical-expr ) action-stmt C830 (R845) The action-stmt in the if-stmt shall not be an end-function-stmt, end-mp-subprogram- stmt, end-program-stmt, end-subroutine-stmt, or if-stmt. R846 select-type-construct is select-type-stmt [ type-guard-stmt block ] ... end-select-type-stmt R847 select-type-stmt is [ select-construct-name : ] SELECT TYPE 628 2006/01/05 WORKING DRAFT J3/07-007 ( [ associate-name => ] selector ) C831 (R847) If selector is not a named variable, associate-name => shall appear. C832 (R847) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). C833 (R847) The selector in a select-type-stmt shall be polymorphic. R848 type-guard-stmt is TYPE IS ( type-spec ) [ select-construct-name ] or CLASS IS ( derived-type-spec ) [ select-construct-name ] or CLASS DEFAULT [ select-construct-name ] C834 (R848) The type-spec or derived-type-spec shall specify that each length type parameter is as- sumed. C835 (R848) The type-spec or derived-type-spec shall not specify a sequence derived type or a type with the BIND attribute. C836 (R848) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify an extension of the declared type of selector. C837 (R848) For a given select-type-construct, the same type and kind type parameter values shall not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more than one CLASS IS type-guard-stmt. C838 (R848) For a given select-type-construct, there shall be at most one CLASS DEFAULT type- guard-stmt. R849 end-select-type-stmt is END SELECT [ select-construct-name ] C839 (R846) If the select-type-stmt of a select-type-construct specifies a select-construct-name, the corresponding end-select-type-stmt shall specify the same select-construct-name. If the select- type-stmt of a select-type-construct does not specify a select-construct-name, the corresponding end-select-type-stmt shall not specify a select-construct-name. If a type-guard-stmt specifies a select-construct-name, the corresponding select-type-stmt shall specify the same select-construct- name. R850 exit-stmt is EXIT [ construct-name ] C840 If a construct-name appears, the EXIT statement shall be within that construct; otherwise, it shall be within the range of at least one do-construct. C841 An exit-stmt shall not belong to a DO CONCURRENT construct, nor shall it appear within the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO CONCURRENT construct. R851 goto-stmt is GO TO label C842 (R851) The label shall be the statement label of a branch target statement that appears in the same scoping unit as the goto-stmt. R852 computed-goto-stmt is GO TO ( label-list ) [ , ] scalar-int-expr C843 (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. R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label C844 (R853) Each label shall be the label of a branch target statement that appears in the same scoping unit as the arithmetic-if-stmt. C845 (R853) The scalar-numeric-expr shall not be of type complex. R854 continue-stmt is CONTINUE R855 stop-stmt is STOP [ stop-code ] R856 stop-code is scalar-char-initialization-expr or scalar-int-initialization-expr C846 (R856) The scalar-char-initialization-expr shall be of default kind. C847 (R856) The scalar-int-initialization-expr shall be of default kind. R857 sync-all-stmt is SYNC ALL [ ( [ sync-stat-list ] ) ] 629 J3/07-007 WORKING DRAFT 2006/01/05 R858 sync-stat is STAT = stat-variable or ERRMSG = errmsg-variable C848 No specifier shall appear more than once in a given sync-stat-list. R859 sync-team-stmt is SYNC TEAM ( image-team [ , sync-stat-list ] ) R860 image-team is scalar-variable C849 The image-team shall be a scalar variable of type IMAGE TEAM from the intrinsic module ISO FORTRAN ENV. R861 sync-images-stmt is SYNC IMAGES ( image-set [ , sync-stat-list ] ) R862 image-set is int-expr or * C850 An image-set that is an int-expr shall be scalar or of rank one. R863 notify-stmt is NOTIFY ( image-set [ , sync-stat-list ] ) R864 query-stmt is QUERY ( image-set [ , query-spec-list ] ) R865 query-spec is READY = scalar-logical-variable or sync-stat C851 (R864) No specifier shall appear more than once in a given query-spec-list. R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat-list ] ) ] Clause 9: R901 io-unit is file-unit-number or * or internal-file-variable R902 file-unit-number is scalar-int-expr R903 internal-file-variable is char-variable C901 (R903) The char-variable shall not be an array section with a vector subscript. C902 (R903) The char-variable shall be of type default character, ASCII character, or ISO 10646 character. R904 open-stmt is OPEN ( connect-spec-list ) R905 connect-spec is [ UNIT = ] file-unit-number or ACCESS = scalar-default-char-expr or ACTION = scalar-default-char-expr or ASYNCHRONOUS = scalar-default-char-expr or BLANK = scalar-default-char-expr or DECIMAL = scalar-default-char-expr or DELIM = scalar-default-char-expr or ENCODING = scalar-default-char-expr or ERR = label or FILE = file-name-expr or FORM = scalar-default-char-expr or IOMSG = iomsg-variable or IOSTAT = scalar-int-variable or NEWUNIT = scalar-int-variable or PAD = scalar-default-char-expr or POSITION = scalar-default-char-expr or RECL = scalar-int-expr or ROUND = scalar-default-char-expr or SIGN = scalar-default-char-expr 630 2006/01/05 WORKING DRAFT J3/07-007 or STATUS = scalar-default-char-expr or TEAM = image-team R906 file-name-expr is scalar-default-char-expr R907 iomsg-variable is scalar-default-char-variable C903 No specifier shall appear more than once in a given connect-spec-list. C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be specified; if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the connect-spec-list. C905 (R904) The label used in the ERR= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the OPEN statement. C906 (R904) If a NEWUNIT= specifier appears, a file-unit-number shall not appear. R908 close-stmt is CLOSE ( close-spec-list ) R909 close-spec is [ UNIT = ] file-unit-number or IOSTAT = scalar-int-variable or IOMSG = iomsg-variable or ERR = label or STATUS = scalar-default-char-expr C907 No specifier shall appear more than once in a given close-spec-list. C908 A file-unit-number shall be specified in a close-spec-list; if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the close-spec-list. C909 (R909) The label used in the ERR= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the CLOSE statement. R910 read-stmt is READ ( io-control-spec-list ) [ input-item-list ] or READ format [ , input-item-list ] R911 write-stmt is WRITE ( io-control-spec-list ) [ output-item-list ] R912 print-stmt is PRINT format [ , output-item-list ] R913 io-control-spec is [ UNIT = ] io-unit or [ FMT = ] format or [ NML = ] namelist-group-name or ADVANCE = scalar-default-char-expr or ASYNCHRONOUS = scalar-char-initialization-expr or BLANK = scalar-default-char-expr or DECIMAL = scalar-default-char-expr or DELIM = scalar-default-char-expr or END = label or EOR = label or ERR = label or ID = scalar-int-variable or IOMSG = iomsg-variable or IOSTAT = scalar-int-variable or PAD = scalar-default-char-expr or POS = scalar-int-expr or REC = scalar-int-expr or ROUND = scalar-default-char-expr or SIGN = scalar-default-char-expr 631 J3/07-007 WORKING DRAFT 2006/01/05 or SIZE = scalar-int-variable C910 No specifier shall appear more than once in a given io-control-spec-list. C911 An io-unit shall be specified in an io-control-spec-list; if the optional characters UNIT= are omitted, the io-unit shall be the first item in the io-control-spec-list. C912 (R913) A DELIM= or SIGN= specifier shall not appear in a read-stmt. C913 (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt. C914 (R913) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the data transfer statement. C915 (R913) A namelist-group-name shall be the name of a namelist group. C916 (R913) A namelist-group-name shall not appear if an input-item-list or an output-item-list appears in the data transfer statement. C917 (R913) An io-control-spec-list shall not contain both a format and a namelist-group-name. C918 (R913) If format appears without a preceding FMT=, it shall be the second item in the io- control-spec-list and the first item shall be io-unit. C919 (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item in the io-control-spec-list and the first item shall be io-unit. C920 (R913) If io-unit is not a file-unit-number, the io-control-spec-list shall not contain a REC= specifier or a POS= specifier. C921 (R913) If the REC= specifier appears, an END= specifier shall not appear, a namelist-group- name shall not appear, and the format, if any, shall not be an asterisk. C922 (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- put/output statement with explicit format specification (10.2) whose control information list does not contain an internal-file-variable as the io-unit. C923 (R913) If an EOR= specifier appears, an ADVANCE= specifier also shall appear. C924 (R913) If a SIZE= specifier appears, an ADVANCE= specifier also shall appear. C925 (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type default character and shall have the value YES or NO. C926 (R913) An ASYNCHRONOUS= specifier with a value YES shall not appear unless io-unit is a file-unit-number. C927 (R913) If an ID= specifier appears, an ASYNCHRONOUS= specifier with the value YES shall also appear. C928 (R913) If a POS= specifier appears, the io-control-spec-list shall not contain a REC= specifier. C929 (R913) If a DECIMAL=, BLANK=, PAD=, SIGN=, or ROUND= specifier appears, a format or namelist-group-name shall also appear. C930 (R913) If a DELIM= specifier appears, either format shall be an asterisk or namelist-group-name shall appear. R914 format is default-char-expr or label or * C931 (R914) The label shall be the label of a FORMAT statement that appears in the same scoping unit as the statement containing the FMT= specifier. R915 input-item is variable or io-implied-do R916 output-item is expr or io-implied-do R917 io-implied-do is ( io-implied-do-object-list , io-implied-do-control ) R918 io-implied-do-object is input-item or output-item 632 2006/01/05 WORKING DRAFT J3/07-007 R919 io-implied-do-control is do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] C932 (R915) A variable that is an input-item shall not be a whole assumed-size array. C933 (R915) A variable that is an input-item shall not be a procedure pointer. C934 (R919) The do-variable shall be a named scalar variable of type integer. C935 (R918) In an input-item-list, an io-implied-do-object shall be an input-item. In an output-item- list, an io-implied-do-object shall be an output-item. C936 (R916) An expression that is an output-item shall not have a value that is a procedure pointer. R920 dtv-type-spec is TYPE( derived-type-spec ) or CLASS( derived-type-spec ) C937 (R920) If derived-type-spec specifies an extensible type, the CLASS keyword shall be used; otherwise, the TYPE keyword shall be used. C938 (R920) All length type parameters of derived-type-spec shall be assumed. R921 wait-stmt is WAIT (wait-spec-list) R922 wait-spec is [ UNIT = ] file-unit-number or END = label or EOR = label or ERR = label or ID = scalar-int-expr or IOMSG = iomsg-variable or IOSTAT = scalar-int-variable C939 No specifier shall appear more than once in a given wait-spec-list. C940 A file-unit-number shall be specified in a wait-spec-list; if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the wait-spec-list. C941 (R922) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the WAIT statement. R923 backspace-stmt is BACKSPACE file-unit-number or BACKSPACE ( position-spec-list ) R924 endfile-stmt is ENDFILE file-unit-number or ENDFILE ( position-spec-list ) R925 rewind-stmt is REWIND file-unit-number or REWIND ( position-spec-list ) R926 position-spec is [ UNIT = ] file-unit-number or IOMSG = iomsg-variable or IOSTAT = scalar-int-variable or ERR = label C942 No specifier shall appear more than once in a given position-spec-list. C943 A file-unit-number shall be specified in a position-spec-list; if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the position-spec-list. C944 (R926) The label in the ERR= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the file positioning statement. R927 flush-stmt is FLUSH file-unit-number or FLUSH ( flush-spec-list ) R928 flush-spec is [UNIT =] file-unit-number or IOSTAT = scalar-int-variable or IOMSG = iomsg-variable 633 J3/07-007 WORKING DRAFT 2006/01/05 or ERR = label C945 No specifier shall appear more than once in a given flush-spec-list. C946 A file-unit-number shall be specified in a flush-spec-list; if the optional characters UNIT= are omitted from the unit specifier, the file-unit-number shall be the first item in the flush-spec-list. C947 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the FLUSH statement. R929 inquire-stmt is INQUIRE ( inquire-spec-list ) or INQUIRE ( IOLENGTH = scalar-int-variable ) output-item-list R930 inquire-spec is [ UNIT = ] file-unit-number or FILE = file-name-expr or ACCESS = scalar-default-char-variable or ACTION = scalar-default-char-variable or ASYNCHRONOUS = scalar-default-char-variable or BLANK = scalar-default-char-variable or DECIMAL = scalar-default-char-variable or DELIM = scalar-default-char-variable or DIRECT = scalar-default-char-variable or ENCODING = scalar-default-char-variable or ERR = label or EXIST = scalar-default-logical-variable or FORM = scalar-default-char-variable or FORMATTED = scalar-default-char-variable or ID = scalar-int-expr or IOMSG = iomsg-variable or IOSTAT = scalar-int-variable or NAME = scalar-default-char-variable or NAMED = scalar-default-logical-variable or NEXTREC = scalar-int-variable or NUMBER = scalar-int-variable or OPENED = scalar-default-logical-variable or PAD = scalar-default-char-variable or PENDING = scalar-default-logical-variable or POS = scalar-int-variable or POSITION = scalar-default-char-variable or READ = scalar-default-char-variable or READWRITE = scalar-default-char-variable or RECL = scalar-int-variable or ROUND = scalar-default-char-variable or SEQUENTIAL = scalar-default-char-variable or SIGN = scalar-default-char-variable or SIZE = scalar-int-variable or STREAM = scalar-default-char-variable or TEAM = image-team or UNFORMATTED = scalar-default-char-variable 634 2006/01/05 WORKING DRAFT J3/07-007 or WRITE = scalar-default-char-variable C948 No specifier shall appear more than once in a given inquire-spec-list. C949 An inquire-spec-list shall contain one FILE= specifier or one UNIT= specifier, but not both. C950 In the inquire by unit form of the INQUIRE statement, if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the inquire-spec-list. C951 If an ID= specifier appears in an inquire-spec-list, a PENDING= specifier shall also appear. C952 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement that appears in the same scoping unit as the INQUIRE statement. Clause 10: R1001 format-stmt is FORMAT format-specification R1002 format-specification is ( [ format-item-list ] ) or ( [ format-item-list, ] unlimited-format-item ) C1001 (R1001) The format-stmt shall be labeled. C1002 (R1002) The comma used to separate format-items in a format-item-list may be omitted R1003 format-item is [ r ] data-edit-desc or control-edit-desc or char-string-edit-desc or [ r ] ( format-item-list ) R1004 unlimited-format-item is * ( format-item-list ) R1005 r is int-literal-constant C1003 (R1005) r shall be positive. C1004 (R1005) r shall not have a kind parameter specified for it. R1006 data-edit-desc is I w [ . m ] or B w [ . m ] or O w [ . m ] or Z w [ . m ] or F w . d or E w . d [ E e ] or EN w . d [ E e ] or ES w . d [ E e ] or G w [ . d [ E e ] ] or L w or A [ w ] or D w . d or DT [ char-literal-constant ] [ ( v-list ) ] R1007 w is int-literal-constant R1008 m is int-literal-constant R1009 d is int-literal-constant R1010 e is int-literal-constant R1011 v is signed-int-literal-constant C1005 (R1010) e shall be positive. C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be positive for all other edit descriptors. C1007 (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. C1008 (R1006) w, m, d, e, and v shall not have kind parameters specified for them. C1009 (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter 635 J3/07-007 WORKING DRAFT 2006/01/05 specified for it. R1012 control-edit-desc is position-edit-desc or [ r ] / or : or sign-edit-desc or k P or blank-interp-edit-desc or round-edit-desc or decimal-edit-desc R1013 k is signed-int-literal-constant C1010 (R1013) k shall not have a kind parameter specified for it. R1014 position-edit-desc is T n or TL n or TR n or n X R1015 n is int-literal-constant C1011 (R1015) n shall be positive. C1012 (R1015) n shall not have a kind parameter specified for it. R1016 sign-edit-desc is SS or SP or S R1017 blank-interp-edit-desc is BN or BZ R1018 round-edit-desc is RU or RD or RZ or RN or RC or RP R1019 decimal-edit-desc is DC or DP R1020 char-string-edit-desc is char-literal-constant C1013 (R1020) The char-literal-constant shall not have a kind parameter specified for it. R1021 hex-digit-string is hex-digit [ hex-digit ] ... Clause 11: R1101 main-program is [ program-stmt ] [ specification-part ] [ execution-part ] [ internal-subprogram-part ] end-program-stmt R1102 program-stmt is PROGRAM program-name R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] C1101 (R1101) In a main-program, the execution-part shall not contain a RETURN statement or an ENTRY statement. C1102 (R1101) The program-name may be included in the end-program-stmt only if the optional program-stmt is used and, if included, shall be identical to the program-name specified in the 636 2006/01/05 WORKING DRAFT J3/07-007 program-stmt. R1104 module is module-stmt [ specification-part ] [ module-subprogram-part ] end-module-stmt R1105 module-stmt is MODULE module-name R1106 end-module-stmt is END [ MODULE [ module-name ] ] R1107 module-subprogram-part is contains-stmt [ module-subprogram ] ... R1108 module-subprogram is function-subprogram or subroutine-subprogram or separate-module-subprogram C1103 (R1104) If the module-name is specified in the end-module-stmt, it shall be identical to the module-name specified in the module-stmt. C1104 (R1104) A module specification-part shall not contain a stmt-function-stmt, an entry-stmt, or a format-stmt. C1105 (R1104) If an object that has a default-initialized direct component is declared in the specifica- tion part of a module it shall have the ALLOCATABLE, POINTER, or SAVE attribute. C1106 If an object that has a co-array ultimate component is declared in the specification-part of a module it shall have the SAVE attribute. R1109 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename-list ] or USE [ [ , module-nature ] :: ] module-name , ONLY : [ only-list ] R1110 module-nature is INTRINSIC or NON INTRINSIC R1111 rename is local-name => use-name or OPERATOR (local-defined-operator) => OPERATOR (use-defined-operator) R1112 only is generic-spec or only-use-name or rename R1113 only-use-name is use-name C1107 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. C1108 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic module. C1109 (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the same name. C1110 (R1111) OPERATOR(use-defined-operator) shall not identify a type-bound generic interface. C1111 (R1112) The generic-spec shall not identify a type-bound generic interface. C1112 (R1112) Each generic-spec shall be a public entity in the module. C1113 (R1113) Each use-name shall be the name of a public entity in the module. R1114 local-defined-operator is defined-unary-op or defined-binary-op R1115 use-defined-operator is defined-unary-op or defined-binary-op C1114 (R1115) Each use-defined-operator shall be a public entity in the module. R1116 submodule is submodule-stmt 637 J3/07-007 WORKING DRAFT 2006/01/05 [ specification-part ] [ module-subprogram-part ] end-submodule-stmt R1117 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name R1118 parent-identifier is ancestor-module-name [ : parent-submodule-name ] R1119 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ] C1115 (R1116) A submodule specification-part shall not contain a format-stmt, entry-stmt, or stmt- function-stmt. C1116 (R1116) An object with a default-initialized direct component that is declared in the specification part of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. C1117 (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- submodule-name shall be the name of a descendant of that module. C1118 (R1116) If a submodule-name appears in the end-submodule-stmt, it shall be identical to the one in the submodule-stmt. R1120 block-data is block-data-stmt [ specification-part ] end-block-data-stmt R1121 block-data-stmt is BLOCK DATA [ block-data-name ] R1122 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ] C1119 (R1120) The block-data-name shall be included in the end-block-data-stmt only if it was provided in the block-data-stmt and, if included, shall be identical to the block-data-name in the block- data-stmt. C1120 (R1120) A block-data specification-part shall contain only derived-type definitions and ASYN- CHRONOUS, BIND, COMMON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRIN- SIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration statements. C1121 (R1120) A type declaration statement in a block-data specification-part shall not contain AL- LOCATABLE, EXTERNAL, or BIND attribute specifiers. Clause 12: R1201 interface-block is interface-stmt [ interface-specification ] ... end-interface-stmt R1202 interface-specification is interface-body or procedure-stmt R1203 interface-stmt is INTERFACE [ generic-spec ] or ABSTRACT INTERFACE R1204 end-interface-stmt is END INTERFACE [ generic-spec ] R1205 interface-body is function-stmt [ specification-part ] end-function-stmt or subroutine-stmt [ specification-part ] end-subroutine-stmt R1206 procedure-stmt is [ MODULE ] PROCEDURE [ :: ] procedure-name-list R1207 generic-spec is generic-name or OPERATOR ( defined-operator ) or ASSIGNMENT ( = ) 638 2006/01/05 WORKING DRAFT J3/07-007 or dtio-generic-spec R1208 dtio-generic-spec is READ (FORMATTED) or READ (UNFORMATTED) or WRITE (FORMATTED) or WRITE (UNFORMATTED) C1201 (R1201) An interface-block in a subprogram shall not contain an interface-body for a procedure defined by that subprogram. C1202 (R1201) The generic-spec shall be included in the end-interface-stmt only if it is provided in the interface-stmt. If the end-interface-stmt includes generic-name, the interface-stmt shall specify the same generic-name. If the end-interface-stmt includes ASSIGNMENT(=), the interface- stmt shall specify ASSIGNMENT(=). If the end-interface-stmt includes dtio-generic-spec, the interface-stmt shall specify the same dtio-generic-spec. If the end-interface-stmt includes OP- ERATOR(defined-operator), the interface-stmt shall specify the same defined-operator. If one defined-operator is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the corre- sponding operator <, <=, >, >=, ==, or /=. C1203 (R1203) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the function-stmt or the subroutine-name in the subroutine-stmt shall not be the same as a keyword that specifies an intrinsic type. C1204 (R1202) A procedure-stmt is allowed only in an interface block that has a generic-spec. C1205 (R1205) An interface-body of a pure procedure shall specify the intents of all dummy arguments except pointer, alternate return, and procedure arguments. C1206 (R1205) An interface-body shall not contain an entry-stmt, data-stmt, format-stmt, or stmt- function-stmt. C1207 (R1206) A procedure-name shall have an explicit interface and shall refer to an accessible pro- cedure pointer, external procedure, dummy procedure, or module procedure. C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in that statement shall be accessible in the current scope as a module procedure. C1209 (R1206) A procedure-name shall not specify a procedure that is specified previously in any procedure-stmt in any accessible interface with the same generic identifier. C1210 (R1205) A module procedure interface body shall not appear in an abstract interface block. R1209 import-stmt is IMPORT [[ :: ] import-name-list C1211 (R1209) The IMPORT statement is allowed only in an interface-body that is not a module procedure interface body. C1212 (R1209) Each import-name shall be the name of an entity in the host scoping unit. R1210 external-stmt is EXTERNAL [ :: ] external-name-list R1211 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] ) [ [ , proc-attr-spec ] ... :: ] proc-decl-list R1212 proc-interface is interface-name or declaration-type-spec R1213 proc-attr-spec is access-spec or proc-language-binding-spec or INTENT ( intent-spec ) or OPTIONAL or POINTER or SAVE R1214 proc-decl is procedure-entity-name [ => proc-pointer-init ] R1215 interface-name is name R1216 proc-pointer-init is null-init or initial-proc-target 639 J3/07-007 WORKING DRAFT 2006/01/05 R1217 initial-proc-target is procedure-name C1213 (R1215) The name shall be the name of an abstract interface or of a procedure that has an explicit interface. If name is declared by a procedure-declaration-stmt it shall be previously declared. If name denotes an intrinsic procedure it shall be one that is listed in 13.6 and not marked with a bullet (·). C1214 (R1215) The name shall not be the same as a keyword that specifies an intrinsic type. C1215 If a procedure entity has the INTENT attribute or SAVE attribute, it shall also have the POINTER attribute. C1216 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall specify an external procedure. C1217 (R1214) If => appears in proc-decl, the procedure entity shall have the POINTER attribute. C1218 (R1217) The procedure-name shall be the name of an initialization target. C1219 (R1211) If proc-language-binding-spec with a NAME= is specified, then proc-decl-list shall con- tain exactly one proc-decl, which shall neither have the POINTER attribute nor be a dummy procedure. C1220 (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an interface-name, and interface-name shall be declared with a proc-language-binding-spec. R1218 intrinsic-stmt is INTRINSIC [ :: ] intrinsic-procedure-name-list C1221 (R1218) Each intrinsic-procedure-name shall be the name of an intrinsic procedure. R1219 function-reference is procedure-designator ( [ actual-arg-spec-list ] ) C1222 (R1219) The procedure-designator shall designate a function. C1223 (R1219) The actual-arg-spec-list shall not contain an alt-return-spec. R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ] C1224 (R1220) The procedure-designator shall designate a subroutine. R1221 procedure-designator is procedure-name or proc-component-ref or data-ref % binding-name C1225 (R1221) A procedure-name shall be the name of a procedure or procedure pointer. C1226 (R1221) A binding-name shall be a binding name (4.5.5) of the declared type of data-ref . C1227 (R1221) If data-ref is an array, the referenced type-bound procedure shall have the PASS at- tribute. R1222 actual-arg-spec is [ keyword = ] actual-arg R1223 actual-arg is expr or variable or procedure-name or proc-component-ref or alt-return-spec R1224 alt-return-spec is * label C1228 (R1222) The keyword = shall not appear if the interface of the procedure is implicit in the scoping unit. C1229 (R1222) The keyword = shall not be omitted from an actual-arg-spec unless it has been omitted from each preceding actual-arg-spec in the argument list. C1230 (R1222) Each keyword shall be the name of a dummy argument in the explicit interface of the procedure. C1231 (R1223) A nonintrinsic elemental procedure shall not be used as an actual argument. C1232 (R1223) A procedure-name shall be the name of an external, internal, module, or dummy proce- dure, a specific intrinsic function listed in 13.6 and not marked with a bullet (·), or a procedure 640 2006/01/05 WORKING DRAFT J3/07-007 pointer. C1233 (R1224) The label shall be the statement label of a branch target statement that appears in the same scoping unit as the call-stmt. C1234 An actual argument that is a co-indexed object shall not correspond to a dummy argument that has either the ASYNCHRONOUS or VOLATILE attribute. C1235 (R1223) If an actual argument is an array section or an assumed-shape array, and the corre- sponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS attribute. C1236 (R1223) If an actual argument is a pointer array, and the corresponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS attribute or a pointer array. R1225 prefix is prefix-spec [ prefix-spec ] ... R1226 prefix-spec is declaration-type-spec or ELEMENTAL or IMPURE or MODULE or PURE or RECURSIVE C1237 (R1225) A prefix shall contain at most one of each prefix-spec. C1238 (R1225) A prefix shall not specify both PURE and IMPURE. C1239 (R1225) A prefix shall not specify both ELEMENTAL and RECURSIVE. C1240 (R1225) A prefix shall not specify ELEMENTAL if proc-language-binding-spec appears in the function-stmt or subroutine-stmt. C1241 (R1225) MODULE shall appear only within the function-stmt or subroutine-stmt of a module subprogram or of an interface body that is declared in the scoping unit of a module or submodule. C1242 (R1225) If MODULE appears within the prefix in a module subprogram, an accessible module procedure interface having the same name as the subprogram shall be declared in the module or submodule in which the subprogram is defined, or shall be declared in an ancestor of that program unit. C1243 (R1225) If MODULE appears within the prefix in a module subprogram, the subprogram shall specify the same characteristics and dummy argument names as its corresponding (12.6.2.5) module procedure interface body. C1244 (R1225) If MODULE appears within the prefix in a module subprogram and a binding label is specified, it shall be the same as the binding label specified in the corresponding module procedure interface body. C1245 (R1225) If MODULE appears within the prefix in a module subprogram, RECURSIVE shall appear if and only if RECURSIVE appears in the prefix in the corresponding module procedure interface body. R1227 function-subprogram is function-stmt [ specification-part ] [ execution-part ] [ internal-subprogram-part ] end-function-stmt R1228 function-stmt is [ prefix ] FUNCTION function-name ( [ dummy-arg-name-list ] ) [ suffix ] C1246 (R1228) If RESULT appears, result-name shall not be the same as function-name and shall not be the same as the entry-name in any ENTRY statement in the subprogram. C1247 (R1228) If RESULT appears, the function-name shall not appear in any specification statement 641 J3/07-007 WORKING DRAFT 2006/01/05 in the scoping unit of the function subprogram. R1229 proc-language-binding-spec is language-binding-spec C1248 (R1229) A proc-language-binding-spec with a NAME= specifier shall not be specified in the function-stmt or subroutine-stmt of an internal procedure, or of an interface body for an abstract interface or a dummy procedure. C1249 (R1229) If proc-language-binding-spec is specified for a procedure, each of the procedure's dummy arguments shall be a nonoptional interoperable variable (15.3.5, 15.3.6) or a nonoptional interop- erable procedure (15.3.7). If proc-language-binding-spec is specified for a function, the function result shall be an interoperable scalar variable. R1230 dummy-arg-name is name C1250 (R1230) A dummy-arg-name shall be the name of a dummy argument. R1231 suffix is proc-language-binding-spec [ RESULT ( result-name ) ] or RESULT ( result-name ) [ proc-language-binding-spec ] R1232 end-function-stmt is END [ FUNCTION [ function-name ] ] C1251 (R1227) An internal function subprogram shall not contain an ENTRY statement. C1252 (R1227) An internal function subprogram shall not contain an internal-subprogram-part. C1253 (R1232) If a function-name appears in the end-function-stmt, it shall be identical to the function- name specified in the function-stmt. R1233 subroutine-subprogram is subroutine-stmt [ specification-part ] [ execution-part ] [ internal-subprogram-part ] end-subroutine-stmt R1234 subroutine-stmt is [ prefix ] SUBROUTINE subroutine-name [ ( [ dummy-arg-list ] ) [ proc-language-binding-spec ] ] C1254 (R1234) The prefix of a subroutine-stmt shall not contain a declaration-type-spec. R1235 dummy-arg is dummy-arg-name or * R1236 end-subroutine-stmt is END [ SUBROUTINE [ subroutine-name ] ] C1255 (R1233) An internal subroutine subprogram shall not contain an ENTRY statement. C1256 (R1233) An internal subroutine subprogram shall not contain an internal-subprogram-part. C1257 (R1236) If a subroutine-name appears in the end-subroutine-stmt, it shall be identical to the subroutine-name specified in the subroutine-stmt. R1237 separate-module-subprogram is mp-subprogram-stmt [ specification-part ] [ execution-part ] [ internal-subprogram-part ] end-mp-subprogram-stmt R1238 mp-subprogram-stmt is MODULE PROCEDURE procedure-name R1239 end-mp-subprogram-stmt is END [PROCEDURE [procedure-name]] C1258 (R1237) The procedure-name shall be the same as the name of an accessible module procedure interface that is declared in the module or submodule in which the separate-module-subprogram is defined, or is declared in an ancestor of that program unit. C1259 (R1239) If a procedure-name appears in the end-mp-subprogram-stmt, it shall be identical to the procedure-name in the MODULE PROCEDURE statement. R1240 entry-stmt is ENTRY entry-name [ ( [ dummy-arg-list ] ) [ suffix ] ] C1260 (R1240) If RESULT appears, the entry-name shall not appear in any specification or type- 642 2006/01/05 WORKING DRAFT J3/07-007 declaration statement in the scoping unit of the function program. C1261 (R1240) An entry-stmt shall appear only in an external-subprogram or a module-subprogram that does not define a separate module procedure. An entry-stmt shall not appear within an executable-construct. C1262 (R1240) RESULT shall appear only if the entry-stmt is in a function subprogram. C1263 (R1240) A dummy-arg shall not be an alternate return indicator if the ENTRY statement is in a function subprogram. C1264 (R1240) If RESULT appears, result-name shall not be the same as the function-name in the FUNCTION statement and shall not be the same as the entry-name in any ENTRY statement in the subprogram. R1241 return-stmt is RETURN [ scalar-int-expr ] C1265 (R1241) The return-stmt shall be in the scoping unit of a function or subroutine subprogram. C1266 (R1241) The scalar-int-expr is allowed only in the scoping unit of a subroutine subprogram. R1242 contains-stmt is CONTAINS R1243 stmt-function-stmt is function-name ( [ dummy-arg-name-list ] ) = scalar-expr C1267 (R1243) The primaries of the scalar-expr shall be constants (literal and named), references to variables, references to functions and function dummy procedures, and intrinsic operations. If scalar-expr contains a reference to a function or a function dummy procedure, the reference shall not require an explicit interface, the function shall not require an explicit interface unless it is an intrinsic function, the function shall not be a transformational intrinsic, and the result shall be scalar. If an argument to a function or a function dummy procedure is an array, it shall be an array name. If a reference to a statement function appears in scalar-expr, its definition shall have been provided earlier in the scoping unit and shall not be the name of the statement function being defined. C1268 (R1243) Named constants in scalar-expr shall have been declared earlier in the scoping unit or made accessible by use or host association. If array elements appear in scalar-expr, the array shall have been declared as an array earlier in the scoping unit or made accessible by use or host association. C1269 (R1243) If a dummy-arg-name, variable, function reference, or dummy function reference is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm this implied type and the values of any implied type parameters. C1270 (R1243) The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar. C1271 (R1243) A given dummy-arg-name shall not appear more than once in any dummy-arg-name-list. C1272 (R1243) Each variable reference in scalar-expr may be either a reference to a dummy argument of the statement function or a reference to a variable accessible in the same scoping unit as the statement function statement. C1273 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data objects have INTENT(IN). C1274 The specification-part of a pure subroutine subprogram shall specify the intents of all its non- pointer dummy data objects. C1275 A local variable of a pure subprogram, or of a BLOCK construct within a pure subprogram, shall not have the SAVE attribute. C1276 The specification-part of a pure subprogram shall specify that all its dummy procedures are pure. C1277 If a procedure that is neither an intrinsic procedure nor a statement function is used in a context that requires it to be pure, then its interface shall be explicit in the scope of that use. The interface shall specify that the procedure is pure. C1278 All internal subprograms in a pure subprogram shall be pure. C1279 In a pure subprogram any designator with a base object that is in common or accessed by host or use association, is a dummy argument of a pure function, is a dummy argument with INTENT (IN) of a pure subroutine, or an object that is storage associated with any such variable, shall not be used C1280 Any procedure referenced in a pure subprogram, including one referenced via a defined operation, 643 J3/07-007 WORKING DRAFT 2006/01/05 defined assignment, user-defined derived-type input/output, or finalization, shall be pure. C1281 A pure subprogram shall not contain a print-stmt, open-stmt, close-stmt, backspace-stmt, endfile- stmt, rewind-stmt, flush-stmt, wait-stmt, or inquire-stmt. C1282 A pure subprogram shall not contain a read-stmt or write-stmt whose io-unit is a file-unit- number or *. C1283 A pure subprogram shall not contain a stop-stmt. C1284 A co-indexed object shall not appear in a variable definition context in a pure subprogram. C1285 A pure subprogram shall not contain an image control statement (8.5.1). C1286 All dummy arguments of an elemental procedure shall be scalar non-co-array dummy data objects and shall not have the POINTER or ALLOCATABLE attribute. C1287 The result variable of an elemental function shall be scalar and shall not have the POINTER or ALLOCATABLE attribute. C1288 In the scoping unit of an elemental subprogram, an object designator with a dummy argument as the base object shall not appear in a specification-expr except as the designator in a type parameter inquiry (6.1.4) or as the argument to one of the intrinsic functions BIT SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6). Clause 13: Clause 14: Clause 15: C1501 (R430) A derived type with the BIND attribute shall not be a SEQUENCE type. C1502 (R430) A derived type with the BIND attribute shall not have type parameters. C1503 (R430) A derived type with the BIND attribute shall not have the EXTENDS attribute. C1504 (R430) A derived type with the BIND attribute shall not have a type-bound-procedure-part. C1505 (R430) Each component of a derived type with the BIND attribute shall be a nonpointer, nonallocatable data component with interoperable type and type parameters. C1506 A procedure defined in a submodule shall not have a binding label unless its interface is declared in the ancestor module. Clause 16: E.2 Syntax rule cross-reference R474 ac-do-variable R473, C508 R472 ac-implied-do R471, C508 R473 ac-implied-do-control R472 R468 ac-spec R467 R471 ac-value R468, R472, C505, C506, C507 R525 access-id R524, C562 R507 access-spec R316, R432, R442, R446, R454, R455, R502, C517, R524, R1213 R524 access-stmt R212, C562 R214 action-stmt R213, C326, C327, R834, R838, R845, C830 R832 action-term-do-construct R831 R1223 actual-arg R1222 R1222 actual-arg-spec C501, R1219, C1223, R1220, C1229 R709 add-op R310, R706 R705 add-operand R705, R706 R627 alloc-opt R626, C636 644 2006/01/05 WORKING DRAFT J3/07-007 R527 allocatable-decl R526 R526 allocatable-stmt R212 R636 allocate-co-array-spec R631, C634, C635 R637 allocate-co-shape-spec R636, C635 R632 allocate-object R631, C628, C629, C630, C631, C632, C633, C634, C635, C638, C639, C642, R640, C644 R633 allocate-shape-spec R631, C633, C635 R626 allocate-stmt R214 R631 allocation R626 R302 alphanumeric-character R301, R304 R1224 alt-return-spec C1223, R1223 ancestor-module-name R1118, C1117 R719 and-op R310, R715 R714 and-operand R715 arg-name R446, C459, R455, C479 R348 arg-token R347 R853 arithmetic-if-stmt R214, C327, C819, C821, C844 R467 array-constructor C505, C506, C507, R701 R617 array-element R536, C569, C572, R566, R603, R610 array-name R543, R544 R618 array-section R603 R510 array-spec R502, R503, C515, R509, C532, R526, R527, R543, R544, R555, R556, R568, C597 R734 assignment-stmt R214, R747, R757, C746 R336 assignment-tok-sequence R335 R802 associate-construct R213, C804 associate-construct-name R803, R806, C804 associate-name R804, C801, C802, R847, C831, C832 R803 associate-stmt R802, C802, C804 R804 association R803 R515 assumed-shape-spec R510 R517 assumed-size-spec R510 R528 asynchronous-stmt R212 R502 attr-spec R501, C501, C579 R923 backspace-stmt R214, C1281 R346 basic-token R345, R348 R345 basic-token-sequence R341, R344, R345 R426 binary-constant R425 R530 bind-entity R529, C564 R529 bind-stmt R212 R455 binding-attr R453, C477, C480, C481 binding-name R453, R454, C472, R1221, C1226 R451 binding-private-stmt R450, C468 R425 bits-literal-constant R306 R1017 blank-interp-edit-desc R1012 R801 block R802, R807, R810, R818, C814, R828, R840, R846 R807 block-construct R213, C807 645 J3/07-007 WORKING DRAFT 2006/01/05 block-construct-name R808, R809, C807 R1120 block-data R202, C1120, C1121 block-data-name R1121, R1122, C1119 R1121 block-data-stmt R1120, C1119 R822 block-do-construct R821, C816 R808 block-stmt R807, C807 R738 bounds-remapping R735, C720, C721 R737 bounds-spec R735, C719 R1220 call-stmt R214, C1233 R810 case-construct R213, C808, C810, C812 case-construct-name R811, R812, R813, C808 R814 case-expr R811, C810, C811, C812 R815 case-selector R812 R812 case-stmt R810, C808 R817 case-value R816, C810 R816 case-value-range R815, C811, C812 R309 char-constant C303 R725 char-expr C706, R731, R814 R731 char-initialization-expr R508, C522, C713, R817, R856, C846, R913, C925 R422 char-length R421, C419, C454, R503, C504 R423 char-literal-constant R306, R1006, C1009, R1020, C1013 R420 char-selector R404 R1020 char-string-edit-desc R1003 R606 char-variable C606, R903, C901, C902 R909 close-spec R908, C907, C908 R908 close-stmt R214, C1281 R511 co-array-spec R442, C447, C448, R503, R509, C524, C536, C537, R527, R544 co-name R544 R625 co-subscript C615, R624 common-block-name R530, R553, R567, C806 R568 common-block-object R567, C597, C598, C599, C600 R567 common-stmt R212 R417 complex-literal-constant R306 R615 complex-part-designator R603, R618, C624 R444 component-array-spec R442, C446, C450 R442 component-attr-spec R441, C443, C464 R461 component-data-source R460 R443 component-decl R441, C462 R440 component-def-stmt R439, C443, C444, C445, C455 R447 component-initialization C462, C463, C464 component-name C465 R439 component-part R430 R460 component-spec R459, C495, C496, C497, C498, C500, C501 R852 computed-goto-stmt R214, C843 R711 concat-op R310, R710 R905 connect-spec R904, C903, C904 646 2006/01/05 WORKING DRAFT J3/07-007 R305 constant R308, R309, R540, R610, R701 R542 constant-subobject R540, R541, C577 construct-name R850, C840 R1242 contains-stmt R210, R450, R1107 R854 continue-stmt R214, C327, R829, C819 R1012 control-edit-desc R1003 R818 critical-construct R213, C813, C814 critical-construct-name R819, R820, C813 R819 critical-stmt R818, C813 R839 cycle-stmt R214, C327, C819, C821, C824 R1009 d R1006, C1007, C1008 R441 data-component-def-stmt R440 R1006 data-edit-desc R1003 R536 data-i-do-object R535, C565, C567, C568, C572 R537 data-i-do-variable R535, C572 R535 data-implied-do R534, R536, C572 data-pointer-component-name R736, C724 R736 data-pointer-object R735, C717, C718, C719, C720, C721, C725 R612 data-ref C612, C617, C618, R614, R617, R618, C723, C729, R1221, C1226, C1227 R532 data-stmt R209, R212, C1206 R540 data-stmt-constant R538, C575 R534 data-stmt-object R533, C565, C566, C567, C568 R539 data-stmt-repeat R538, C573 R533 data-stmt-set R532 R538 data-stmt-value R533 R739 data-target R461, C502, C503, C552, R735, C717, C718, C721, C727 R641 dealloc-opt R640, C645 R640 deallocate-stmt R214 R1019 decimal-edit-desc R1012 R207 declaration-construct R204 R403 declaration-type-spec C404, C405, C423, R441, C444, C445, R501, R560, R1212, R1226, C1254 R726 default-char-expr C707, R905, R906, R909, R913, R914 R607 default-char-variable C607, R629, R907, R930 R605 default-logical-variable C605, R930 R519 deferred-co-shape-spec C447, C524, R511, C536 R516 deferred-shape-spec R442, R444, C446, R510, C532, R550 R315 define-macro-stmt R314 R723 defined-binary-op R311, R722, C704, R1114, R1115 R311 defined-operator C474, R1207, C1202 R703 defined-unary-op R311, R702, C703, R1114, R1115 R430 derived-type-def R207, C437, C441, C442 R457 derived-type-spec R402, C403, R403, C405, C406, R459, C494, C501, R848, C834, C835, C836, R920, C937, C938 R431 derived-type-stmt R430, C431, C438, C441, C442 647 J3/07-007 WORKING DRAFT 2006/01/05 R603 designator R448, C466, R542, R601, C601, R615, C621, R616, C622, R701, C702, C746 digit R302, R313, R410, R426, C412, R427, C413, R429, R426, C428, R427, C429, R429 R410 digit-string R407, R408, R409, R413, R414 R544 dimension-decl R543 R543 dimension-stmt R212 R828 do-block R822 R833 do-body R832, R835, R837 R821 do-construct R213, C823, C840 do-construct-name R824, R825, R830, C816, R839, C823 R823 do-stmt R822, C816, C817, C818 R834 do-term-action-stmt C327, R832, C819, C820 R838 do-term-shared-stmt R837, C821, C822 R827 do-variable R474, R537, R826, C815, R919, C934 R1208 dtio-generic-spec C476, R1207, C1202 R1235 dummy-arg R1234, R1240, C1263 R1230 dummy-arg-name R545, R546, R557, R1228, C1250, R1235, R1243, C1269, C1270, C1271 R1010 e R1006, C1005, C1008 R842 else-if-stmt R840, C829 R843 else-stmt R840, C829 R750 elsewhere-stmt R744, C735 R806 end-associate-stmt R802, C804 R1122 end-block-data-stmt R1120, C1119 R809 end-block-stmt R807, C807 R820 end-critical-stmt R818, C813 R829 end-do R822, C816, C817, C818 R830 end-do-stmt R829, C816, C817 R466 end-enum-stmt R462 R758 end-forall-stmt R752, C737 R1232 end-function-stmt R214, C201, C326, C327, C819, C821, C830, R1205, R1227, C1253 R844 end-if-stmt R840, C829 R1204 end-interface-stmt R1201, C1202 R340 end-macro-stmt R314 R1106 end-module-stmt R1104, C1103 R1239 end-mp-subprogram-stmt R214, C201, C326, C327, C819, C821, C830, R1237, C1259 R1103 end-program-stmt R214, C201, C326, C327, C819, C821, C830, R1101, C1102 R813 end-select-stmt R810, C808 R849 end-select-type-stmt R846, C839 R1119 end-submodule-stmt R1116, C1118 R1236 end-subroutine-stmt R214, C201, C326, C327, C819, C821, C830, R1205, R1233, C1257 R434 end-type-stmt R430 R751 end-where-stmt R744, C735 R924 endfile-stmt R214, C1281 R503 entity-decl R501, C502, C503, C505 648 2006/01/05 WORKING DRAFT J3/07-007 entity-name R530, R551 entry-name C1246, R1240, C1260, C1264 R1240 entry-stmt R206, R207, R209, C1104, C1115, C1206, C1261, C1262 R462 enum-def R207 R463 enum-def-stmt R462 R465 enumerator R464, C504 R464 enumerator-def-stmt R462 R721 equiv-op R310, R717 R716 equiv-operand R716, R717 R566 equivalence-object R565, C585, C586, C587, C588, C589, C590, C591, C592, C593, C594, C595 R565 equivalence-set R564 R564 equivalence-stmt R212 R629 errmsg-variable R627, R641, R858 R213 executable-construct R208, R209, C1261 R208 execution-part C201, R1101, C1101, R1227, R1233, R1237 R209 execution-part-construct R208, R801, R833 R850 exit-stmt R214, C327, C819, C821, C841 R342 expand-stmt R323, C332 R520 explicit-co-shape-spec R511, C537 R512 explicit-shape-spec R444, C450, C451, C515, R510, C531, R517, C597 R416 exponent R413 R415 exponent-letter R413, C414 R722 expr R461, R471, R601, C602, R630, R701, R722, R724, R725, R726, R727, R728, R730, R734, R739, C728, R742, C731, R805, C803, R916, R1223, R1243, C1267, C1268, C1272 R312 extended-intrinsic-op R311 external-name R1210 R1210 external-stmt R212 R203 external-subprogram R202, C1261 R906 file-name-expr R905, R930 R902 file-unit-number R901, R905, C904, C906, R909, C908, C920, C926, R922, C940, R923, R924, R925, R926, C943, R927, R928, C946, R930, C950, C1282 R456 final-procedure-stmt R452 final-subroutine-name R456, C485, C486 R928 flush-spec R927, C945, C946 R927 flush-stmt R214, C1281 R757 forall-assignment-stmt R756, C746, R759 R756 forall-body-construct R752, C743, C744, C745 R752 forall-construct R213, R756, C743 forall-construct-name R753, R758, C737 R753 forall-construct-stmt R752, C737 R754 forall-header R753, R759, R826 R759 forall-stmt R214, R756 R755 forall-triplet-spec R754, C742 R914 format R910, R912, R913, C917, C918, C921, C929, C930 649 J3/07-007 WORKING DRAFT 2006/01/05 R1003 format-item R1002, C1002, R1003, R1004 R1002 format-specification R1001 R1001 format-stmt R206, R207, R209, C1001, C1104, C1115, C1206 function-name R503, C508, C1203, R1228, C1246, C1247, R1232, C1253, C1264, R1243, C1270 R1219 function-reference R506, C512, R701 R1228 function-stmt R1205, C1203, C1240, C1241, R1227, C1248, C1253 R1227 function-subprogram R203, R211, R1108 generic-name C473, R1207, C1202 R1207 generic-spec R454, C471, C473, C474, C475, C476, R525, R1112, C1111, C1112, R1203, R1204, C1202, C1204 R851 goto-stmt R214, C327, C819, C821, C842 R428 hex-constant R425 R429 hex-digit R428, R1021 R840 if-construct R213, C829 if-construct-name R841, R842, R843, R844, C829 R845 if-stmt R214, C326, C830 R841 if-then-stmt R840, C829 R419 imag-part R417 R624 image-selector R613, C615, C616, C617 R862 image-set C850, R863, R864 R860 image-team C849, R905, R930 R205 implicit-part R204 R206 implicit-part-stmt R205 R560 implicit-spec R559 R559 implicit-stmt R205, R206 R518 implied-shape-spec R510 import-name R1209, C1212 R1209 import-stmt R204 index-name R755, C741, C742, C743 R448 initial-data-target R447, C465, R505, C511, R540 R1217 initial-proc-target R1216 R505 initialization R503, C505, C506, C507, C510 R730 initialization-expr R447, R505, R548, C712 R837 inner-shared-do-construct R836, C822 R915 input-item R910, C916, R918, C932, C933, C935 R930 inquire-spec R929, C948, C949, C950, C951 R929 inquire-stmt R214, C1281 R308 int-constant C302, R539 int-constant-name R408, C409 R541 int-constant-subobject R539, C576 R727 int-expr R401, R473, R611, R619, R622, R623, R625, R634, R635, C708, R729, C711, R732, R814, R826, R852, R862, C850, R902, R905, R913, R919, R922, R930, R1241, C1266 R732 int-initialization-expr R405, C408, R420, C417, R437, R465, R535, C714, R817, R856, C847 R407 int-literal-constant R306, R406, R422, C418, R1005, R1007, R1008, R1009, R1010, R1015 650 2006/01/05 WORKING DRAFT J3/07-007 R608 int-variable C608, R628, R905, R909, R913, R922, R926, R928, R929, R930 int-variable-name R827 R523 intent-spec R502, R545, R1213 R545 intent-stmt R212 R1201 interface-block R207, C1201 R1205 interface-body R1202, C1201, C1205, C1206, C1211 R1215 interface-name R453, C482, R1212, C1220 R1202 interface-specification R1201 R1203 interface-stmt R1201, C1202, C1203 R903 internal-file-variable R901, C922 R211 internal-subprogram R210 R210 internal-subprogram-part R1101, R1227, C1252, R1233, C1256, R1237 R310 intrinsic-operator R312, C703, C704 intrinsic-procedure-name R1218, C1221 R1218 intrinsic-stmt R212 R404 intrinsic-type-spec R402, R403 R913 io-control-spec R910, R911, C910, C911, C917, C918, C919, C920, C928 R917 io-implied-do R915, R916 R919 io-implied-do-control R917 R918 io-implied-do-object R917, C935 R901 io-unit R913, C911, C918, C919, C920, C922, C926, C1282 R907 iomsg-variable R905, R909, R913, R922, R926, R928, R930 R1013 k R1012, C1010 R215 keyword R458, C491, C492, R460, C498, C499, R1222, C1228, C1229, C1230 R408 kind-param R407, C410, C411, R413, C414, C415, C418, R423, C426, R424, C427, R425 R405 kind-selector R404, R436 R313 label C304, R824, C818, R851, C842, R852, C843, R853, C844, R905, C905, R909, C909, R913, C914, R914, C931, R922, C941, R926, C944, R928, C947, R930, C952, R1224, C1233 R824 label-do-stmt R823, C818, R832, C820, R835, R837, C822 R508 language-binding-spec R502, C502, C503, R529, C564, R1229 R469 lbracket R347, R442, R467, R503, R509, R527, R544, R624, R631 R421 length-selector R420, C423, C424 letter R302, R304, R561, C581, R703, R723 R561 letter-spec R560 R702 level-1-expr R704 R706 level-2-expr R706, R710 R710 level-3-expr R710, R712 R712 level-4-expr R714 R717 level-5-expr R717, R722 R306 literal-constant R305 R1114 local-defined-operator R1111 local-name R1111 R724 logical-expr C705, R733, R748, R814, R826, R841, R842, R845 R733 logical-initialization-expr C715, R817 651 J3/07-007 WORKING DRAFT 2006/01/05 R424 logical-literal-constant R306, C703, C704 R604 logical-variable C604 R826 loop-control R824, R825 R513 lower-bound R512, R515, R517, R518 R634 lower-bound-expr R633, R636, R637, R737, R738 R521 lower-co-bound R520, C538 R1008 m R1006, C1008 R343 macro-actual-arg C329, C330, C332 R322 macro-body-block R314, R324, R328 R323 macro-body-construct R322, C309 R337 macro-body-stmt R323, C317, C318 R333 macro-condition R329, R330 R317 macro-declaration-stmt R314 R314 macro-definition R207, R323, C309 R324 macro-do-construct R323 R326 macro-do-limit C311 R325 macro-do-stmt R324 macro-do-variable-name C310 macro-dummy-arg-name C305, C307 macro-dummy-arg-name-list C305 macro-dummy-name C331, C332 R330 macro-else-if-stmt R328 R331 macro-else-stmt R328 R327 macro-end-do-stmt R324 R332 macro-end-if-stmt R328 R341 macro-expr R321, C308, R326, R333, R334, C320 R328 macro-if-construct R323 R329 macro-if-then-stmt R328 R334 macro-int-assignment-stmt R323 macro-integer-variable-name R334, C313 macro-local-variable-name C306 macro-local-variable-name-list R320 macro-name R340, C319, C321 R319 macro-optional-decl-stmt R317 R335 macro-tok-assignment-stmt R323 macro-tok-variable-name R335, C314 R318 macro-type-declaration-stmt R317 R320 macro-variable-decl-stmt R317, C306 R1101 main-program R202, C1101 R748 mask-expr R743, R745, R749, R754, C739, C740 R749 masked-elsewhere-stmt R744, C735 R1104 module R202 module-name R1105, R1106, C1103, R1109, C1107, C1108 R1110 module-nature R1109, C1107, C1108 R1105 module-stmt R1104, C1103 R1108 module-subprogram R1107, C1261 652 2006/01/05 WORKING DRAFT J3/07-007 R1107 module-subprogram-part R1104, R1116 R1238 mp-subprogram-stmt R1237 R708 mult-op R310, R705 R704 mult-operand R704, R705 R1015 n R1014, C1011, C1012 R304 name R102, R215, C301, R307, R504, R554, R602, R1215, C1213, C1214, R1230 R307 named-constant R305, R418, R419, R465, R548 R548 named-constant-def R547 namelist-group-name R562, C582, C584, R913, C915, C916, C917, C919, C921, C929, C930 R563 namelist-group-object R562, C583, C584 R562 namelist-stmt R212 R347 nested-token-sequence R345 R831 nonblock-do-construct R821 R825 nonlabel-do-stmt R823, C817 R718 not-op R310, R714 R863 notify-stmt R214 R506 null-init R447, R505, R540, R1216 R638 nullify-stmt R214 R728 numeric-expr C709, R853, C845 R504 object-name R503, C506, C509, C511, R526, R527, R528, R531, R550, R553, R555, R556, R558, R603 R427 octal-constant R425 R1112 only R1109 R1113 only-use-name R1112 R904 open-stmt R214, C1281 R546 optional-stmt R212 R720 or-op R310, R716 R715 or-operand R715, R716 R835 outer-shared-do-construct R831, R836, C822 R916 output-item R911, R912, C916, R918, C935, C936, R929 R547 parameter-stmt R206, R207 R1118 parent-identifier R1117 R610 parent-string R609, C609 parent-submodule-name R1118, C1117 parent-type-name R432, C432 part-name R613, C610, C611, C612, C613, C614, C615, C616, C619, C620, C625 R613 part-ref C568, C571, C586, R612, C619, C620, C623, C624 R735 pointer-assignment-stmt R214, C552, R757 R550 pointer-decl R549 R639 pointer-object R638, C643 R549 pointer-stmt R212 R1014 position-edit-desc R1012 R926 position-spec R923, R924, R925, C942, C943 R707 power-op R310, R704 653 J3/07-007 WORKING DRAFT 2006/01/05 R1225 prefix C1237, C1238, C1239, C1240, C1242, C1243, C1244, C1245, R1228, R1234, C1254 R1226 prefix-spec R1225, C1237 primaries C1267 R701 primary R702 R912 print-stmt R214, C1281 R449 private-components-stmt R433, C467 R433 private-or-sequence R430, C437 R1213 proc-attr-spec R1211 R446 proc-component-attr-spec R445, C456, C457, C460 R445 proc-component-def-stmt R440, C456 R741 proc-component-ref R740, R742, R1221, R1223 R1214 proc-decl R445, R1211, C1217, C1219 proc-entity-name R550 R1212 proc-interface R445, R1211, C1216, C1220 R1229 proc-language-binding-spec C516, R1213, C1219, C1220, C1240, C1248, C1249, R1231, R1234 R1216 proc-pointer-init R1214 R554 proc-pointer-name R553, R568, C598, C601, R639, R740 R740 proc-pointer-object R735 R742 proc-target R461, C502, C552, R735, C733 procedure-component-name C730 R1211 procedure-declaration-stmt R207, C1213 R1221 procedure-designator R1219, C1222, R1220, C1224 procedure-entity-name R1214, C1216 procedure-name R453, C469, C470, R742, C732, R1206, C1207, C1208, C1209, R1217, C1218, R1221, C1225, R1223, C1232, R1238, R1239, C1258, C1259 R1206 procedure-stmt R1202, C1204, C1208, C1209 program-name R1102, R1103, C1102 R1102 program-stmt R1101, C1102 R202 program-unit R201 R551 protected-stmt R212 R865 query-spec R864, C851 R864 query-stmt R214 R1005 r R1003, C1003, C1004, R1012 R470 rbracket R347, R442, R467, R503, R509, R527, R544, R624, R631 R910 read-stmt R214, C912, C1282 R413 real-literal-constant R306, R412 R418 real-part R417 R713 rel-op R310, R712 R1111 rename R1109, R1112 rep-char R423 result-name C1246, R1231, C1264 R338 result-token R336, R337, C315 R1241 return-stmt R214, C327, C819, C821, C1265 R925 rewind-stmt R214, C1281 654 2006/01/05 WORKING DRAFT J3/07-007 R1018 round-edit-desc R1012 R552 save-stmt R212 R553 saved-entity R552, C806 R103 scalar-xyz C101 R620 section-subscript R613, C614, C616, C624 R811 select-case-stmt R810, C808 select-construct-name R847, R848, R849, C839 R846 select-type-construct R213, C837, C838, C839 R847 select-type-stmt R846, C833, C839 R805 selector R804, C801, R847, C831, C832, C833, C836 R1237 separate-module-subprogram R1108, C1258 R435 sequence-stmt R433 R836 shared-term-do-construct R835 R411 sign R406, R409, R412 R1016 sign-edit-desc R1012 R409 signed-digit-string R416 R406 signed-int-literal-constant R418, R419, R540, R1011, R1013 R412 signed-real-literal-constant R418, R419, R540 R414 significand R413 R630 source-expr R627, C629, C633, C637, C638, C639, C641 special-character R301 R729 specification-expr C404, C419, R513, R514, R521, R522, C1288 R204 specification-part C471, C517, C562, R807, C805, R1101, R1104, C1104, C1106, R1116, C1115, R1120, C1120, C1121, R1205, R1227, R1233, R1237, C1273, C1274, C1276 R212 specification-stmt R207 R628 stat-variable R627, R641, R858 R1243 stmt-function-stmt R207, C1104, C1115, C1206 R856 stop-code R855 R855 stop-stmt R214, C327, C819, C821, C1283 R622 stride R621, R755, C742 R614 structure-component R536, C570, C571, C572, R603, R610, R632, R639 R459 structure-constructor R540, C575, R701 R1116 submodule R202 submodule-name R1117, R1119, C1118 R1117 submodule-stmt R1116, C1118 subroutine-name C1203, R1234, R1236, C1257 R1234 subroutine-stmt R1205, C1203, C1240, C1241, C1248, R1233, C1254, C1257 R1233 subroutine-subprogram R203, R211, R1108 R619 subscript C571, C623, R620, R621, R755, C742 R621 subscript-triplet R620, C627 R609 substring R566, C596, R603 R611 substring-range R609, R618, C625 R1231 suffix R1228, R1240 R857 sync-all-stmt R214 R861 sync-images-stmt R214 655 J3/07-007 WORKING DRAFT 2006/01/05 R866 sync-memory-stmt R214 R858 sync-stat R857, C848, R863, R865, R866 R859 sync-team-stmt R214 R556 target-decl R555 R555 target-stmt R212 R339 token R338 R432 type-attr-spec R431, C431 R454 type-bound-generic-stmt R452, C471 R452 type-bound-proc-binding R450 R450 type-bound-procedure-part R430, C440, C1504 R453 type-bound-procedure-stmt R452 R501 type-declaration-stmt R207, C423, C424, C501 R848 type-guard-stmt R846, C837, C838, C839 type-name R431, C430, R434, C438, C476, R457, C488 R438 type-param-attr-spec R436 R437 type-param-decl R436 R436 type-param-def-stmt R430, C441, C442 R616 type-param-inquiry R701 type-param-name R431, R437, C441, C442, R616, C622, R701, C701 R458 type-param-spec R457, C489, C490, C491, C493 R401 type-param-value C401, C402, C404, R420, R421, R422, C419, C420, C421, C422, C455, R458, C493, C631 R402 type-spec R468, C505, C506, C507, R626, C629, C630, C631, C632, C637, C640, R754, C738, R848, C834, C835, C836 R303 underscore R302 R1004 unlimited-format-item R1002 R514 upper-bound R512 R635 upper-bound-expr R633, R637, R738 R522 upper-co-bound R520, C538 R1115 use-defined-operator R1111, C1110, C1114 use-name R525, C563, R1111, R1113, C1113 R1109 use-stmt R204 R1011 v R1006, C1008 R557 value-stmt R212 R601 variable R534, C566, C568, R604, R605, R606, R607, R608, R734, C716, R736, C723, C724, R739, C726, C729, C730, C746, R805, C801, C831, C832, R915, R1223 R602 variable-name R563, R566, R568, C598, C601, C603, R610, R632, R639, R736, C722 R623 vector-subscript R620, C626 R558 volatile-stmt R212 R1007 w R1006, C1006, C1007, C1008 R922 wait-spec R921, C939, C940 R921 wait-stmt R214, C1281 R747 where-assignment-stmt R743, R746, C734 R746 where-body-construct R744, C736 R744 where-construct R213, R746, R756 where-construct-name R745, R749, R750, R751, C735 656 2006/01/05 WORKING DRAFT J3/07-007 R745 where-construct-stmt R744, C735 R743 where-stmt R214, R746, R756 R911 write-stmt R214, C913, C1282 657 J3/07-007 WORKING DRAFT 2006/01/05 658 Annex F (Informative) Index In this annex, entries in italics denote BNF terms, entries in bold face denote language keywords, and page numbers in bold face denote primary text or glossary definitions. Symbols access-stmt (R524), 11, 101, 101 <, 148 ACCESS= specifier, 218, 249 <=, 148 accessibility attribute, 88, 101 >, 148 accessibility statement, 101 >=, 148 action-stmt (R214), 11, 11, 38, 185, 191, 195 (, 147 action-term-do-construct (R832), 185, 185 *, 33, 44, 46, 47, 52, 93, 95, 103, 126, 143, 233, 265, ACTION= specifier, 218, 249 278, 284, 311, 332 actions, 208 **, 143 active, 186 +, 143 active combination, 172 -, 143 actual argument, 297, 505 .AND., 146, 147 actual-arg (R1223), 311, 311 .EQ., 148 actual-arg-spec (R1222), 78, 310, 311, 311 .EQV., 146, 147 add-op (R709), 28, 134, 134, 135 .GE., 148 add-operand (R705), 134, 134, 135, 138 .GT., 148 ADVANCE= specifier, 226 .LE., 148 advancing input/output statement, 212 .LT., 148 affector, 227 .NE., 148 alloc-opt (R627), 125, 126, 126 .NEQV., 146, 147 allocatable array, 92 .NOT., 146, 147 ALLOCATABLE attribute, 88, 102 .OR., 146, 147 ALLOCATABLE statement, 102 .XOR., 146, 147 allocatable variable, 505 /, 143 allocatable-decl (R527), 102, 102 //, 54, 145 allocatable-stmt (R526), 11, 102, 488 /=, 148 ALLOCATE statement, 125 ;, 33 allocate-co-array-spec (R636), 126, 126, 128 ==, 148 allocate-co-shape-spec (R637), 126, 126 &, 32, 282 allocate-object (R632), 52, 53, 126, 126, 127, 128, 130, 132, 503 A allocate-shape-spec (R633), 126, 126, 127, 128 abstract interface, 299 allocate-stmt (R626), 11, 125, 503 abstract interface block, 301 allocated, 129 abstract type, 74, 505 allocation (R631), 125, 126, 128 ac-do-variable (R474), 82, 82, 155, 157, 486, 487 alphanumeric-character (R302), 25, 25, 27 ac-implied-do (R472), 82, 82, 139, 487 alt-return-spec (R1224), 195, 311, 311 ac-implied-do-control (R473), 82, 82, 139, 154­157 ancestor, 294 ac-spec (R468), 82, 82 ancestor component, 75 ac-value (R471), 82, 82 ancestor-module-name, 294 access methods, 208 and-op (R719), 28, 136, 136 access-id (R525), 101, 101 and-operand (R714), 136, 136 access-spec (R507), 35, 58, 63, 64, 69­72, 85, 88, approximation methods, 48 88, 101, 308 arg-name, 64, 66, 71 659 J3/07-007 WORKING DRAFT 2006/01/05 arg-token (R348), 38, 38 sequence, 321 argument, 505 storage, 493 argument association, 313, 487, 505 use, 488 argument keyword, 21, 313, 341, 486 association (R804), 178, 178 arithmetic IF statement, 195 association status, pointer, 491 arithmetic-if-stmt (R853), 12, 38, 185, 195, 195 assumed type parameter, 45 array, 19, 90­94, 121, 121­124, 505 assumed-shape array, 92, 505 assumed-shape, 92 assumed-shape-spec (R515), 91, 92, 92 assumed-size, 93 assumed-size array, 93, 505 deferred-shape, 92 assumed-size-spec (R517), 91, 93 explicit-shape, 92 asynchronous, 219, 222, 226, 227, 229, 231­233, array constructor, 81, 81 240, 243­245, 247, 249, 251, 252 array element, 19, 121, 122, 505 ASYNCHRONOUS attribute, 88, 102 array element order, 123 ASYNCHRONOUS statement, 102 array intrinsic assignment statement, 159 asynchronous-stmt (R528), 11, 102 array pointer, 93, 505 ASYNCHRONOUS= specifier, 219, 226, 249 array section, 19, 123, 505 attr-spec (R502), 85, 85, 86, 87, 107 array-constructor (R467), 82, 82, 133 attribute, 85, 87­101, 505 array-element (R617), 103, 111, 117, 118, 122 accessibility, 88, 101 array-name, 105, 488 ALLOCATABLE, 88, 102 array-section (R618), 117, 122, 122, 123 ASYNCHRONOUS, 88, 102 array-spec (R510), 7, 86, 88, 90, 91, 91, 93, 102, BIND, 57, 60, 102 105, 107, 113, 114, 128 CONTIGUOUS, 89, 102, 319 ASCII character set, 51 DIMENSION, 90, 105 ASCII character type, 51, 158, 214, 231, 264, 279, EXTERNAL, 95, 302, 307, 308 410, 422 INTENT, 95, 105 ASCII collating sequence, 55, 352, 386, 389, 396­ INTRINSIC, 97, 310 398, 410 OPTIONAL, 97, 106 assignment, 157­175 PARAMETER, 98, 106 defined, 162 POINTER, 98, 106 elemental array (FORALL), 169 PRIVATE, 58, 88, 101 intrinsic, 158 PROTECTED, 98, 106 masked array (WHERE), 166 PUBLIC, 58, 88, 101 pointer, 163 SAVE, 103, 107 assignment statement, 157, 505 TARGET, 100, 107, 315 assignment-stmt (R734), 11, 158, 158, 167, 169, VALUE, 100, 107, 314 170, 172, 338, 503 VOLATILE, 100, 107 assignment-tok-sequence (R336), 36, 37 attribute specification statements, 101­116 ASSOCIATE construct, 178, 178, 487 automatic data object, 86, 505 associate name, 178, 505 ASSOCIATE statement, 490 B associate-construct (R802), 11, 178, 178 BACKSPACE statement, 245 associate-construct-name, 178 backspace-stmt (R923), 11, 244, 338 associate-name, 178, 192­194, 486, 515 base object, 119 associate-stmt (R803), 178, 178, 195 base type, 74, 506 associated, 20 basic-token (R346), 38, 38 associating entity, 497 basic-token-sequence (R345), 37, 38, 38 association, 22, 505 belong, 187, 194, 506 argument, 313, 487 belongs, 194 common, 114 binary-constant (R426), 56, 56 host, 488 BIND attribute, 57, 60, 102 inheritance, 497 BIND statement, 102 name, 487 BIND(C), 80, 89, 298, 300, 475, 477, 481 pointer, 491 bind-entity (R530), 102, 102 660 2006/01/05 WORKING DRAFT J3/07-007 bind-stmt (R529), 11, 102 case-value (R817), 180, 181, 181 binding, 71, 485 case-value-range (R816), 180, 180, 181 binding label, 480, 481, 506 CHAR intrinsic, 54 binding name, 71 char-constant (R309), 28, 28 binding-attr (R455), 70, 71, 71 char-expr (R725), 152, 152, 157, 180 binding-name, 70, 71, 311, 328, 486, 516 char-initialization-expr (R731), 89, 157, 157, 181, binding-private-stmt (R451), 70, 70, 72 196, 224, 225 bit model, 342 char-length (R422), 52, 52, 53, 63, 64, 85­87 bits compatible, 314, 506 char-literal-constant (R423), 28, 34, 53, 239, 261, bits conversion, 161 262, 593 bits editing, 265 char-selector (R420), 47, 52, 52 bits intrinsic assignment statement, 158 char-string-edit-desc (R1020), 260, 262 bits intrinsic operation, 140, 147 char-variable (R606), 117, 117, 214 bits intrinsic operator, 140 CHARACTER, 51 bits relational intrinsic operation, 140 character (R301), 25 bits type, 55 character context, 30 bits-literal-constant (R425), 28, 56 character intrinsic assignment statement, 158 blank common, 113 character intrinsic operation, 140 blank-interp-edit-desc (R1017), 261, 262 character intrinsic operator, 140 BLANK= specifier, 219, 227, 249 character length parameter, 506 block, 177, 506 character literal constant, 53 block (R801), 177, 178­180, 183, 185, 190, 192 character relational intrinsic operation, 140 BLOCK construct, 179 character sequence type, 59, 111, 496, 618 block data program unit, 294, 506 character set, 25 BLOCK DATA statement, 294 character storage unit, 494, 506 BLOCK statement, 179 character string, 51, 506 block-construct (R807), 11, 179, 180 character string edit descriptor, 260 block-construct-name, 179, 180 character type, 51, 51­55 block-data (R1120), 9, 294, 295 CHARACTER STORAGE SIZE, 436 block-data-name, 294, 295 characteristics, 506 block-data-stmt (R1121), 10, 294, 294 characteristics of a procedure, 298 block-do-construct (R822), 184, 184, 185 child, 294 block-stmt (R808), 179, 179, 180, 195 child data transfer statement, 236, 236­240, 257 blocking, 203 CLASS, 46 bounds, 506 class, 506 bounds-remapping (R738), 163, 164, 165 CLASS DEFAULT statement, 192 bounds-spec (R737), 163, 164, 165 CLASS IS statement, 192 branch target statement, 195 CLOSE statement, 222 branching, 195 close-spec (R909), 222, 222 close-stmt (R908), 11, 222, 338 C co-array, 20, 506 C address, 468 explicit-co-shape, 95 C character kind, 468 co-array-spec (R511), 63, 64, 86, 90, 91, 91, 94, 95, C (C type), 467­478 102, 105, 107 C LOC function, 471 co-bound, 20 CALL statement, 311 co-bounds, 94, 95, 507 call-stmt (R1220), 11, 311, 311, 314 co-dimension, 20 CASE construct, 180 co-indexed object, 20, 507 case index, 181 co-name, 105 case-construct (R810), 11, 180, 180, 181 co-rank, 20, 507 case-construct-name, 180 co-size, 20 case-expr (R814), 180, 180, 181 co-subscript, 507 case-selector (R815), 180, 180 co-subscript (R625), 20, 119, 125, 125 case-stmt (R812), 180, 180 collating sequence, 54, 54, 507 661 J3/07-007 WORKING DRAFT 2006/01/05 collective subroutine, 341, 507 construct association, 490, 507 comment, 32, 33 construct entity, 483, 507 common association, 114 construct-name, 194 common block, 113, 485, 507, 552 constructor common block storage sequence, 114 array, 81 COMMON statement, 113­116 derived-type, 77 common-block-name, 102, 107, 113, 180, 293 structure, 77 common-block-object (R568), 113, 113, 293, 488 CONTAINS statement, 70, 336 common-stmt (R567), 11, 113, 488 contains-stmt (R1242), 10, 70, 290, 336 companion processor, 23, 507 contiguous, 89 compatibility CONTIGUOUS attribute, 89, 102, 319 Fortran 77, 4 CONTIGUOUS statement, 102 Fortran 2003, 3 contiguous-stmt (R531), 102 Fortran 90, 4 continuation, 32, 33 Fortran 95, 3 CONTINUE statement, 196 COMPILER OPTIONS, 436 continue-stmt (R854), 11, 38, 185, 196 COMPILER VERSION, 436 control character, 25 COMPLEX, 50 control edit descriptor, 260, 274 complex part designator, 120 control information list, 224 complex type, 50, 50 control mask, 508 complex-literal-constant (R417), 28, 50 control-edit-desc (R1012), 260, 261 complex-part-designator (R615), 117, 120, 120, 122 conversion component, 62, 485, 507 bits, 161 component definition statement, 62 numeric, 160 component keyword, 21 correspond, 334 component order, 69, 507 CRITICAL construct, 183 component value, 77 CRITICAL statement, 183 component-array-spec (R444), 63, 63, 64 critical-construct (R818), 11, 183, 183 component-attr-spec (R442), 62, 63, 63, 65, 66 critical-construct-name, 183 component-data-source (R461), 77, 77, 78, 79 critical-stmt (R819), 183, 183, 195 component-decl (R443), 52, 62, 63, 64, 66 current record, 211 component-def-stmt (R440), 62, 62, 63, 64 CYCLE statement, 184, 187 component-initialization (R447), 63, 66, 66 cycle-stmt (R839), 11, 38, 185, 187, 187 component-name, 63, 67 component-part (R439), 57, 62, 69, 72 D component-spec (R460), 77, 77, 78, 156 d (R1009), 261, 261, 266­269, 272, 273, 281 computed GO TO statement, 195 data, 508 computed-goto-stmt (R852), 12, 195, 195 data edit descriptor, 260, 264 concat-op (R711), 28, 135, 135 data edit descriptors, 274 concatenation, 54 data entity, 18, 508 conform, 158 data object, 18, 508 conformable, 19, 507 data object reference, 22 conformance, 154, 507 data pointer, 20 connect team, 221, 223, 507 DATA statement, 102, 498 connect-spec (R905), 217, 217, 218, 221 data transfer, 233 connected, 216, 507 data transfer input statement, 207 constant, 18, 28, 43, 507 data transfer output statements, 207 character, 53 data transfer statements, 223 integer, 48 data type, see type, 508 named, 106 data-component-def-stmt (R441), 62, 62, 64 constant (R305), 28, 28, 104, 118, 133 data-edit-desc (R1006), 260, 261 constant subobject, 19 data-i-do-object (R536), 103, 103, 104 constant-subobject (R542), 104, 104 data-i-do-variable (R537), 103, 103, 104, 157, 486, construct, 507 487 662 2006/01/05 WORKING DRAFT J3/07-007 data-implied-do (R535), 103, 103, 104, 157, 487 defined operations, 150 data-pointer-component-name, 163 defined unary operation, 150 data-pointer-initialization compatible, 66 defined-binary-op (R723), 29, 136, 136, 137, 150, data-pointer-object (R736), 163, 163, 164, 165, 172, 151, 292 356, 503 defined-operator (R311), 29, 71, 292, 300, 301 data-ref (R612), 118, 119, 120, 122, 163, 164, 227, defined-unary-op (R703), 29, 134, 134, 137, 150, 311, 314, 320, 328 151, 292 data-stmt (R532), 10, 11, 102, 301, 337, 488 definition, 22 data-stmt-constant (R540), 103, 104, 104 definition of variables, 497 data-stmt-object (R534), 103, 103, 104 deleted feature, 508 data-stmt-repeat (R539), 103, 103, 104 deleted features, 7 data-stmt-set (R533), 102, 103 DELIM= specifier, 219, 227, 250 data-stmt-value (R538), 103, 103, 104 delimiters, 30 data-target (R739), 77­79, 99, 163, 164, 164, 165, derived type, 17, 57­80, 508 172, 322, 338, 356, 493 derived type determination, 60 datum, 508 derived-type intrinsic assignment statement, 158 dealloc-opt (R641), 130, 130, 131 derived-type type specifier, 46 DEALLOCATE statement, 130 derived-type-def (R430), 10, 46, 57, 58, 61 deallocate-stmt (R640), 11, 130, 503 derived-type-spec (R457), 45, 52, 77, 77, 78, 192, decimal symbol, 264, 508 237, 486 decimal-edit-desc (R1019), 261, 262 derived-type-stmt (R431), 57, 57, 58, 61, 488 DECIMAL= specifier, 219, 227, 249 descendant, 294 declaration, 22, 85­116 designator, 21, 509 declaration-construct (R207), 10, 10 designator (R603), 66, 67, 104, 117, 117, 120, 121, declaration-type-spec (R403), 45, 45, 46, 52, 62, 63, 133, 170 85, 87, 108, 154, 308, 309, 329, 332 designator, 133 declared type, 46, 508 digit, 6, 25, 25, 29, 48, 56, 279 default bits, 56 digit-string (R410), 48, 48, 49, 266, 271 default character, 51 digit-string, 48 default complex, 50 digits, 25 default initialization, 66, 508 DIMENSION attribute, 90, 105 default integer, 47 DIMENSION statement, 105 default logical, 55 dimension-decl (R544), 105, 105 default real, 49 dimension-spec (R509), 91 default-char-expr (R726), 152, 152, 217­228 dimension-stmt (R543), 11, 105, 488 default-char-variable (R607), 117, 117, 126, 218, direct access, 210 248­254 direct access input/output statement, 228 default-initialized, 67, 508 default-logical-variable (R605), 117, 117, 248, 250, direct component, 57 251 DIRECT= specifier, 250 deferred binding, 71, 508 disassociated, 20, 509 deferred type parameter, 44, 508 distinguishable, 306 deferred-co-shape-spec (R519), 63, 91, 94, 94 DO CONCURRENT construct, 184 deferred-shape array, 92 DO CONCURRENT statement, 184 deferred-shape-spec (R516), 63, 91, 93, 93, 106 DO construct, 184 definable, 508 DO statement, 184 define-macro-stmt (R315), 35, 35, 488 DO termination, 185 defined, 22, 508 DO WHILE statement, 184 defined assignment, 305 do-block (R828), 184, 185, 186 defined assignment statement, 162, 508 do-body (R833), 185, 185, 186 defined binary operation, 150 do-construct (R821), 11, 184, 187, 194 defined elemental assignment statement, 162 do-construct-name, 184, 185, 187 defined elemental operation, 151 do-stmt (R823), 184, 184, 185, 195, 503 defined operation, 150, 304, 508 do-term-action-stmt (R834), 38, 185, 185, 187, 195 663 J3/07-007 WORKING DRAFT 2006/01/05 do-term-shared-stmt (R838), 185, 185, 186, 187, end-mp-subprogram-stmt (R1239), 11, 12, 16, 38, 195 185, 191, 333, 333, 336 do-variable (R827), 82, 103, 184, 184, 185, 186, end-of-file condition, 254 229, 230, 255­257, 280, 499, 501, 503, 544 end-of-record condition, 254 DOUBLE PRECISION, 49 end-program-stmt (R1103), 9, 11, 12, 16, 17, 38, double precision real, 49 185, 191, 289, 289 dtio-generic-spec (R1208), 71, 236­238, 242, 300, end-select-stmt (R813), 180, 180, 181, 195 301, 301, 304, 307 end-select-type-stmt (R849), 192, 192, 193, 195 dtv-type-spec (R920), 237 end-submodule-stmt (R1119), 10, 16, 294, 294 dummy argument, 297, 509 end-subroutine-stmt (R1236), 9, 11, 12, 16, 38, 185, restrictions, 322 191, 300, 332, 332, 333, 336 dummy array, 509 end-type-stmt (R434), 57, 58 dummy data object, 509 end-where-stmt (R751), 167, 167 dummy procedure, 298, 509 END= specifier, 255 dummy-arg (R1235), 332, 332, 334 endfile record, 208 dummy-arg-name (R1230), 105­107, 330, 330, 331, ENDFILE statement, 208, 245 332, 336, 488 endfile-stmt (R924), 11, 244, 338 dynamic type, 46, 509 ending point, 118 entity, 509 E entity-decl (R503), 52, 85, 86, 86, 87, 156, 157, 488 e (R1010), 261, 261, 267­269, 272­274, 281 entity-name, 102, 106 edit descriptor, see format descriptor, 260 ENTRY statement, 334 effective argument, 314 entry-name, 330, 334, 485 effective item, 230, 509 entry-stmt (R1240), 10, 290, 294, 301, 334, 334, effective position, 307 485, 488 element sequence, 321 enum-def (R462), 10, 80, 80, 81 ELEMENTAL, 329 enum-def-stmt (R463), 80, 80 elemental, 20, 297, 509 enumeration, 80 elemental array assignment (FORALL), 169 enumerator, 80 elemental intrinsic function, 341 enumerator (R465), 80, 80 elemental operation, 154 enumerator-def-stmt (R464), 80, 80 elemental procedure, 339 EOR= specifier, 255 else-if-stmt (R842), 190, 190 equiv-op (R721), 28, 136, 136 else-stmt (R843), 190, 190 equiv-operand (R716), 136, 136 elsewhere-stmt (R750), 167, 167 EQUIVALENCE statement, 110­113 ENCODING= specifier, 219, 250 equivalence-object (R566), 111, 111, 112, 293 END BLOCK statement, 179 equivalence-set (R565), 110, 111, 112 END CRITICAL statement, 183 equivalence-stmt (R564), 11, 110, 488 END INTERFACE statement, 300 ERR= specifier, 255 END statement, 16, 16 errmsg-variable (R629), 126, 126, 127, 130, 132, end-associate-stmt (R806), 178, 178, 195 199, 503, 594 end-block-data-stmt (R1122), 10, 16, 294, 294 ERRMSG= specifier, 132 end-block-stmt (R809), 179, 179, 180, 195 ERROR UNIT, 215, 436 end-critical-stmt (R820), 183, 183, 195 evaluation end-do (R829), 184, 185, 185, 186­188 operations, 139 end-do-stmt (R830), 185, 185, 195 optional, 151 end-enum-stmt (R466), 80, 80 parentheses, 152 end-forall-stmt (R758), 169, 169 executable construct, 177, 509 end-function-stmt (R1232), 9, 11, 12, 16, 38, 185, executable statement, 15, 509 191, 300, 330, 331, 331, 336 executable-construct (R213), 10, 11, 15, 334 end-if-stmt (R844), 190, 190, 195 execution control, 177 end-interface-stmt (R1204), 300, 300, 301 execution cycle, 187 end-macro-stmt (R340), 35, 37 execution-part (R208), 9, 10, 10, 12, 289, 330­333 end-module-stmt (R1106), 9, 16, 290, 290 execution-part-construct (R209), 10, 10, 177, 185 664 2006/01/05 WORKING DRAFT J3/07-007 exist, 209, 215 FILE STORAGE SIZE, 436 EXIST= specifier, 250 files EXIT statement, 194 connected, 216 exit-stmt (R850), 11, 38, 185, 194, 195 external, 208 expand-stmt (R342), 35, 37, 38 internal, 214 explicit, 299 preconnected, 216 explicit formatting, 259­278 FINAL statement, 72 explicit initialization, 87, 102, 509 final subroutine, 73, 510 explicit interface, 299, 509 final-procedure-stmt (R456), 70, 72 explicit-co-shape co-array, 95 final-subroutine-name, 72 explicit-co-shape-spec (R520), 91, 95, 95 finalizable, 73, 510 explicit-shape array, 92, 509 finalization, 73, 510 explicit-shape-spec (R512), 63, 64, 88, 91, 92, 92, finalized, 73 93, 94, 113 fixed source form, 33, 33 exponent (R416), 49, 50 FLUSH statement, 246 exponent-letter (R415), 49, 49, 50 flush-spec (R928), 246, 246 expr (R722), 7, 74, 77, 78, 82, 117, 126, 133, 134, flush-stmt (R927), 11, 246, 338 136, 136, 137, 152, 153, 157­164, 168, FMT= specifier, 225 169, 172, 178, 229, 311, 336, 338, 462 FORALL construct, 169 expression, 19, 133, 133­157, 509 forall-assignment-stmt (R757), 169, 169, 170, 172, extended type, 74, 509 174, 338 extended-intrinsic-op (R312), 29, 29 forall-body-construct (R756), 169, 169, 170, 172, extensible type, 74, 509 174 extension operation, 137, 151 forall-construct (R752), 11, 169, 169, 170, 171, 173 extension operator, 151 forall-construct-name, 169, 170 extension type, 74, 510 forall-construct-stmt (R753), 169, 169, 170, 195 extent, 19, 510 forall-header (R754), 169, 169, 174, 175, 184, 487 EXTERNAL attribute, 95, 302, 307, 308 forall-stmt (R759), 11, 169, 173, 174, 174 external file, 208, 510 forall-triplet-spec (R755), 169, 169, 170, 171, 173 external linkage, 510 FORM= specifier, 220, 250 external procedure, 13, 297, 510 format (R914), 223­225, 225, 226, 233, 259, 260 EXTERNAL statement, 307 format control, 262 external subprogram, 12, 510 format descriptor external unit, 214, 510 /, 276 external-name, 307 :, 276 external-stmt (R1210), 11, 307, 488 A, 272 external-subprogram (R203), 9, 9, 334 BN, 277 BZ, 277 F control edit descriptor, 274 field, 262 D, 267 field width, 262 data edit descriptor, 264­274 file, 510 E, 267 file access, 209 EN, 268 file connection, 214 ES, 269 file connection statements, 207 F, 266 file inquiry statement, 207, 247 G, 272 file position, 211 I, 265 file positioning statements, 207, 244 L, 271 file storage unit, 213, 510 P, 276 file-name-expr (R906), 217, 218, 219, 248, 249, 251 S, 276 file-unit-number (R902), 214, 214, 215, 217, 218, SP, 276 222, 224, 225, 238, 244­246, 248, 249, 338, SS, 276 438 TL, 275 FILE= specifier, 219, 249 TR, 275 665 J3/07-007 WORKING DRAFT 2006/01/05 X, 275 host, 12, 13, 510 format descriptors host association, 488, 510 G, 272 host instance, 165 FORMAT statement, 226, 259, 632 host scoping unit, 12, 510 format-item (R1003), 259, 260, 260 format-specification (R1002), 259, 259 I format-stmt (R1001), 10, 259, 259, 290, 294, 301 ICHAR intrinsic, 54 formatted data transfer, 235 ID= specifier, 227, 250 formatted input/output statement, 225 IEEE , 352, 439­465 formatted record, 207 IF construct, 190, 190 FORMATTED= specifier, 250 IF statement, 190, 191 formatting if-construct (R840), 11, 190, 190 explicit, 259­278 if-construct-name, 190 list-directed, 235, 278­282 if-stmt (R845), 11, 38, 191, 191 namelist, 235, 282­287 if-then-stmt (R841), 190, 190, 195 forms, 208 imag-part (R419), 50, 50 Fortran 2003 compatibility, 3 image, 14, 510, 511 Fortran 77 compatibility, 4 image control, 197 Fortran 90 compatibility, 4 image index, 14, 511 Fortran 95 compatibility, 3 image selector, 125 Fortran character set, 25 image-selector (R624), 20, 118, 119, 125, 507 free source form, 30, 30 image-set (R862), 201, 201, 202, 203 function, 13, 510 image-team (R860), 200, 200, 203, 218, 221, 248, function reference, 19, 325 254 function result, 510 IMAGE TEAM, 437 FUNCTION statement, 329 imaginary part, 50 function subprogram, 329, 510 implicit, 299 function-name, 86, 301, 330, 331, 334, 336, 485, 488 implicit interface, 310, 511 function-reference (R1219), 78, 86, 133, 310, 314, IMPLICIT statement, 107 325 implicit-part (R205), 10, 10 function-stmt (R1228), 9, 300, 301, 329, 330, 330, implicit-part-stmt (R206), 10, 10 331, 485, 488 implicit-spec (R560), 108, 108 function-subprogram (R1227), 9, 10, 290, 330, 333 implicit-stmt (R559), 10, 108 implied-shape array, 94 G implied-shape-spec (R518), 91, 94, 94 generic identifier, 303, 510 IMPORT statement, 302 generic interface, 71, 303, 510 import-name, 302, 303 generic interface block, 301, 510 import-name-list, 303 generic name, 304, 341 import-stmt (R1209), 10, 302 generic procedure reference, 306 IMPURE, 329 GENERIC statement, 70 inactive, 186 generic-name, 71, 300, 301, 486, 488 INCLUDE, 34 generic-spec (R1207), 70­72, 76, 101, 150, 162, 291, INCLUDE line, 34 292, 300, 300, 301, 303, 486, 488 index-name, 169­175, 186, 187, 486, 487, 500, 502 global entity, 483, 510 inherit, 511 global identifier, 483 inheritance associated, 75 GO TO statement, 195 inheritance association, 497, 511 goto-stmt (R851), 11, 38, 185, 195, 195 inherited, 75 graphic character, 25 initial point, 211 initial-data-target (R448), 66, 66, 67, 86, 87, 104 H initial-proc-target (R1217), 67, 308, 308, 309 hex-constant (R428), 56, 56 initialization, 67, 86, 87, 498, 613 hex-digit (R429), 56, 56, 271 initialization (R505), 86, 86, 87 hex-digit-string (R1021), 271, 271 initialization expression, 156 666 2006/01/05 WORKING DRAFT J3/07-007 initialization target, 67, 309 interface-body (R1205), 300, 300, 301, 303, 488 initialization-expr (R730), 45, 66, 67, 86, 87, 94, interface-name (R1215), 308, 308, 309 98, 106, 157, 157 interface-name, 70­72 inner-shared-do-construct (R837), 185, 185, 186 interface-specification (R1202), 300, 300 input statement, 207 interface-stmt (R1203), 300, 300, 301, 303, 304, input-item (R915), 223, 224, 229, 229, 230, 243, 488 257, 503 internal file, 214, 511 input/output editing, 259­287 internal procedure, 13, 297, 511 input/output list, 229 internal subprogram, 12, 511 input/output statements, 207­257 internal unit, 214 INPUT UNIT, 215, 437 internal-file-variable (R903), 214, 214, 225, 503 inquire by file, 247 internal-subprogram (R211), 10, 10 inquire by output list, 247 internal-subprogram-part (R210), 9, 10, 11, 289, inquire by unit, 247 330­333 INQUIRE statement, 247 interoperable, 472, 472, 475­477, 478, 511 inquire-spec (R930), 247, 248, 248, 249, 257 interoperates, 472 inquire-stmt (R929), 11, 247, 338 intrinsic, 22, 511 inquiry function, 341, 511 elemental, 341 inquiry, type parameter, 121 inquiry function, 341 instance, 333, 511 transformational, 341 int-constant (R308), 28, 28, 103 intrinsic assignment statement, 158 int-constant-name, 48 INTRINSIC attribute, 97, 310 int-constant-subobject (R541), 103, 104, 104 intrinsic binary operation, 140 int-expr (R727), 16, 44, 82, 118, 122, 125, 126, 139, intrinsic module, 290 152, 152, 154­157, 169, 180, 184, 186, intrinsic operation, 140 195, 201, 214, 215, 217, 224, 229, 232, 244, intrinsic operations, 140­149 248, 335 intrinsic procedure, 297, 341­435 int-initialization-expr (R732), 47, 52, 61, 80, 81, INTRINSIC statement, 310 103, 157, 157, 181, 196 intrinsic type, 17, 47­55 int-literal-constant (R407), 28, 48, 48, 52, 260­262 intrinsic unary operation, 140 int-variable (R608), 117, 117, 126, 217, 222, 224, intrinsic-operator (R310), 28, 29, 134, 137, 140, 244­248, 251­256 150, 304 int-variable-name, 184 intrinsic-procedure-name, 310, 488 INTEGER, 47 intrinsic-stmt (R1218), 11, 310, 488 integer constant, 48 intrinsic-type-spec (R404), 45, 47, 52 integer editing, 265 invoke, 511 integer model, 343 io-control-spec (R913), 223, 224, 224, 225, 238, 257 integer type, 47, 47 io-implied-do (R917), 229, 229, 230, 231, 234, 257, INTENT, 342 499, 501, 503, 544 intent, 511 io-implied-do-control (R919), 229, 229, 232 INTENT attribute, 95, 105 io-implied-do-object (R918), 229, 229 INTENT statement, 105 io-unit (R901), 214, 214, 224, 225, 338 intent-spec (R523), 85, 95, 105, 308 iomsg-variable (R907), 217, 218, 222, 224, 244­ intent-stmt (R545), 11, 105 246, 248, 255­257, 499 interface, 299 IOMSG= specifier, 257 (procedure), 299 IOSTAT= specifier, 256 abstract, 299 IOSTAT END, 438 explicit, 299 IOSTAT INQUIRE INTERNAL UNIT, 438 generic, 303 ISO 10646 character set, 51 implicit, 310 ISO 10646 character type, 51, 158, 214, 219, 231, interface block, 13, 300­303, 511 264, 279, 410, 422 interface body, 13, 511 ISO C BINDING module, 467 INTERFACE statement, 300 ISO FORTRAN ENV module, 214, 215, 435 interface-block (R1201), 10, 300, 301 iteration count, 40, 186 667 J3/07-007 WORKING DRAFT 2006/01/05 K loop-control (R826), 184, 184, 186, 187, 189 k (R1013), 261, 261, 268, 273, 276 low-level syntax, 27 keyword, 21, 313, 512 lower-bound (R513), 92, 92, 93, 94 keyword (R215), 21, 21, 77, 78, 311 lower-bound-expr (R634), 126, 126, 128, 164 kind, 47, 48, 50, 51, 55 lower-co-bound (R521), 95, 95 KIND intrinsic, 47, 48, 50, 51, 55 kind type parameter, 17, 44, 47, 48, 50, 51, 55, 512M kind-param (R408), 48, 48, 49, 50, 52, 53, 55, 56 m (R1008), 261, 261, 265, 266, 271, 281 kind-selector (R405), 7, 47, 47, 61 macro-actual-arg (R343), 37, 38, 38 macro-actual-arg-value (R344), 38, 38 L macro-attr (R316), 35, 35 label, 512 macro-body-block (R322), 35, 35, 36 label (R313), 29, 29, 184, 185, 195, 217, 218, 222­ macro-body-construct (R323), 35, 35, 36 226, 244­246, 248, 249, 255, 256, 311 macro-body-stmt (R337), 35, 37, 37 label-do-stmt (R824), 184, 184, 185 macro-condition (R333), 36, 36 language-binding-spec (R508), 85, 89, 102, 330 macro-declaration-stmt (R317), 35, 35 lbracket (R469), 38, 63, 82, 82, 86, 91, 102, 105, macro-definition (R314), 10, 35, 35, 36 107, 125, 126 macro-do-construct (R324), 35, 36 left tab limit, 275 macro-do-limit (R326), 36, 36 length, 51 macro-do-stmt (R325), 36, 36, 40 length of a character string, 512 macro-do-variable-name, 36, 40 length type parameter, 44 macro-dummy-arg-name, 35 length-selector (R421), 7, 52, 52 macro-dummy-arg-name-list, 35 letter, 25 macro-dummy-name, 38 letter, 25, 25, 27, 29, 108, 134, 136 macro-else-if-stmt (R330), 36, 36 letter-spec (R561), 108, 108 macro-else-stmt (R331), 36, 36 level-1-expr (R702), 134, 134, 138 macro-end-do-stmt (R327), 36, 36 level-2-expr (R706), 134, 134, 135, 138 macro-end-if-stmt (R332), 36, 36 level-3-expr (R710), 135, 135, 136 macro-expr (R341), 35­37, 37, 40 level-4-expr (R712), 135, 136 macro-if-construct (R328), 35, 36 level-5-expr (R717), 136, 136, 137 macro-if-then-stmt (R329), 36, 36 lexical token, 27, 512 macro-int-assignment-stmt (R334), 36, 36 line, 30, 512 macro-integer-variable-name, 36 linkage association, 512 macro-local-variable-name, 35 list-directed formatting, 235, 278­282 macro-local-variable-name-list, 35 list-directed input/output statement, 226 macro-name, 35, 37 literal constant, 18, 118, 512 macro-optional-decl-stmt (R319), 35, 35 literal-constant (R306), 28, 28 macro-tok-assignment-stmt (R335), 36, 36 local entity, 512 macro-tok-variable-name, 36 local identifier, 483, 484 macro-type-declaration-stmt (R318), 35, 35 local variable, 18, 512 macro-type-spec (R321), 35, 35, 38 local-defined-operator (R1114), 291, 292, 292 macro-variable-decl-stmt (R320), 35, 35 local-name, 291­293 main program, 13, 289, 512 LOGICAL, 55 main-program (R1101), 9, 289, 289 logical intrinsic assignment statement, 158 many-one array section, 124, 512 logical intrinsic operation, 140, 146 mask-expr (R748), 166, 167, 167, 168­173 logical intrinsic operator, 140 masked array assignment (WHERE), 166 logical type, 55, 55 masked-elsewhere-stmt (R749), 167, 167, 168, 173 logical-expr (R724), 152, 152, 157, 167, 180, 184, model 186­188, 190, 191 bit, 342 logical-initialization-expr (R733), 157, 157, 181 integer, 343 logical-literal-constant (R424), 28, 55, 134, 137 real, 343 logical-variable (R604), 117, 117, 203 module, 14, 290, 512 loop, 184 module (R1104), 9, 290 668 2006/01/05 WORKING DRAFT J3/07-007 module procedure, 13, 298, 512 notify-stmt (R863), 11, 203 module procedure interface, 301, 512 null-init (R506), 66, 67, 86, 86, 87, 104, 308, 309 module procedure interface body, 301 NULLIFY statement, 130 module reference, 22 nullify-stmt (R638), 11, 130, 503 MODULE statement, 290 NUMBER= specifier, 251 module subprogram, 12, 512 numeric conversion, 160 module-name, 290­292, 488 numeric editing, 265 module-nature (R1110), 291, 291, 292 numeric intrinsic assignment statement, 158 module-stmt (R1105), 9, 290, 290 numeric intrinsic operation, 140, 142 module-subprogram (R1108), 10, 290, 290, 334 numeric intrinsic operator, 140 module-subprogram-part (R1107), 9, 10, 72, 76, numeric relational intrinsic operation, 140 290, 290, 294, 559 numeric sequence type, 59, 111, 496, 618 mp-subprogram-stmt (R1238), 10, 333, 333 numeric storage unit, 493, 513 mult-op (R708), 28, 134, 134 numeric type, 47, 513 mult-operand (R704), 134, 134, 138 numeric-expr (R728), 49, 152, 152, 195 NUMERIC STORAGE SIZE, 438 N n (R1015), 261, 262, 262 name, 21, 512 O name (R304), 6, 21, 27, 27, 28, 86, 107, 117, 193, object, see data object, 18, 513 234, 308, 330 object designator, 21, 513 name association, 487, 512 object-name (R504), 86, 86, 102, 106, 107, 117, 488 name-value subsequences, 282 obsolescent feature, 7, 513 NAME= specifier, 251 octal-constant (R427), 56, 56 named, 512 only (R1112), 291, 291, 292 named common block, 113 only-use-name (R1113), 291, 292, 292 named constant, 18, 98, 106, 118, 513 OPEN statement, 217 named file, 208 open-stmt (R904), 12, 217, 338 named-constant (R307), 28, 28, 34, 50, 51, 80, 106,OPENED= specifier, 251 488 operand, 23, 513 named-constant-def (R548), 106, 106, 488 operation, 513 NAMED= specifier, 251 defined, 150 namelist formatting, 235, 282­287 extension, 151 namelist input/output statement, 226 intrinsic, 140 NAMELIST statement, 110 intrinsic bits, 147 namelist-group-name, 110, 224­226, 233, 235, 259, logical intrinsic, 146 282, 286, 293, 488, 503 numeric intrinsic, 142 namelist-group-object (R563), 110, 110, 233, 234, relational intrinsic, 148 236, 243, 257, 282, 283, 293 operations, 43 namelist-stmt (R562), 11, 110, 488, 503 operator, 23, 28, 513 Names, 27 operator precedence, 137 NaN, 352, 444, 513 OPTIONAL attribute, 97, 106 nested-token-sequence (R347), 38, 38 next record, 211 optional dummy argument, 322 NEXTREC= specifier, 251 OPTIONAL statement, 106 NML= specifier, 226 optional-stmt (R546), 11, 106 nonadvancing input/output statement, 212 or-op (R720), 28, 136, 136 nonblock-do-construct (R831), 184, 185 or-operand (R715), 136, 136 nonexecutable statement, 15, 513 outer-shared-do-construct (R835), 185, 185 nonintrinsic module, 290 output statement, 207 nonlabel-do-stmt (R825), 184, 184, 185 output-item (R916), 223, 224, 229, 229, 243, 247 normal, 444 OUTPUT UNIT, 215, 438 not-op (R718), 28, 136, 136 override, 76, 513 NOTIFY statement, 203 overrides, 67 669 J3/07-007 WORKING DRAFT 2006/01/05 P primary, 133 PAD= specifier, 220, 228, 251 primary (R701), 133, 133, 134 PARAMETER attribute, 98, 106 PRINT statement, 223 PARAMETER statement, 106 print-stmt (R912), 12, 223, 338 parameter-stmt (R547), 10, 106, 488 PRIVATE attribute, 58, 88 parent, 294 PRIVATE statement, 69, 70, 101 parent component, 75, 513 private-components-stmt (R449), 58, 69, 69 parent data transfer statement, 236, 236­240, 257 private-or-sequence (R433), 57, 58, 58 parent type, 74, 513 proc-attr-spec (R1213), 308, 308, 309 parent-identifier (R1118), 294, 294 proc-component-attr-spec (R446), 64, 64 parent-string (R610), 90, 118, 118 proc-component-def-stmt (R445), 62, 64, 64 parent-submodule-name, 294 proc-component-ref (R741), 164, 164, 311 parent-type-name, 58 proc-decl (R1214), 64, 67, 308, 308, 309 parentheses, 152 proc-entity-name, 106, 309 part-name, 118, 119, 122 proc-interface (R1212), 64, 308, 308, 309 part-ref (R613), 90, 103, 111, 118, 118, 119, 122,proc-language-binding-spec (R1229), 88, 308, 309, 123, 319 329, 330, 330, 331, 332, 336, 477 partially [storage] associated, 495 proc-pointer-init (R1216), 308, 308 passed-object dummy argument, 66, 314, 513 proc-pointer-name (R554), 107, 107, 113, 130, 164, PENDING= specifier, 251 488 pointer, 20, 513 proc-pointer-object (R740), 163, 164, 165, 172, 356, pointer assignment, 163, 513 503 pointer assignment statement, 513 proc-target (R742), 77­79, 99, 163, 164, 164, 165, pointer associated, 513 172, 322, 356, 493 pointer association, 491, 513 procedure, 13, 514 pointer association context, 503 characteristics of, 298 pointer association status, 491 dummy, 298 POINTER attribute, 98, 106 elemental, 339 POINTER statement, 106 external, 297 pointer-assignment-stmt (R735), 12, 99, 163, 169, internal, 297 172, 338, 503 intrinsic, 341­435 pointer-decl (R550), 106, 106 non-Fortran, 336 pointer-object (R639), 130, 130, 503 pure, 337 pointer-stmt (R549), 11, 106, 488 type-bound, 71, 328 polymorphic, 46, 513 procedure declaration statement, 308 POS= specifier, 228, 252 procedure designator, 21, 514 position, 209 procedure interface, 299, 514 position-edit-desc (R1014), 261, 261 procedure pointer, 20, 308 position-spec (R926), 244, 245, 245 procedure reference, 22, 310 POSITION= specifier, 220, 252 generic, 306 positional arguments, 341 resolving, 326 power-op (R707), 28, 134, 134 type-bound, 328 pre-existing, 497 PROCEDURE statement, 303 precedence of operators, 137 procedure-component-name, 164 preceding record, 211 procedure-declaration-stmt (R1211), 10, 308, 308, preconnected, 514 309, 488 preconnected files, 216 procedure-designator (R1221), 310, 311, 311, 328 Preconnection, 216 procedure-entity-name, 308 prefix (R1225), 329, 329, 330, 332 procedure-name, 70, 71, 164, 165, 300, 301, 308, prefix-spec (R1226), 329, 329, 337, 339 311, 333 present, 321 procedure-stmt (R1206), 300, 300, 301 present (dummy argument), 321 processor, 1, 514 PRESENT intrinsic, 98 processor dependent, 3, 514 primaries, 336 program, 12, 514 670 2006/01/05 WORKING DRAFT J3/07-007 program (R201), 9, 9 representable character, 53 PROGRAM statement, 289 representation method, 47, 48, 51, 55 program unit, 12, 514 resolving procedure reference, 326 program-name, 289 resolving procedure references program-stmt (R1102), 9, 289, 289 derived-type input/output, 242 program-unit (R202), 7, 9, 9 restricted expression, 154 PROTECTED attribute, 98, 106 result variable, 13, 514 PROTECTED statement, 106 result-name, 330, 331, 334, 488 protected-stmt (R551), 11, 106 result-token (R338), 37, 37 prototype, 514 RETURN statement, 335 PUBLIC attribute, 58, 88 return-stmt (R1241), 12, 16, 38, 185, 335, 335 PUBLIC statement, 101 REWIND statement, 246 PURE, 329 rewind-stmt (R925), 12, 244, 338 pure procedure, 337, 514 round-edit-desc (R1018), 261, 262 ROUND= specifier, 221, 228, 253 Q rounding mode, 514 QUERY statement, 203 query-spec (R865), 203, 203 S query-stmt (R864), 12, 203 satisfied, 203 SAVE attribute, 103, 107 R SAVE statement, 107 r (R1005), 260, 260, 261, 263 save-stmt (R552), 11, 107, 488 range, 186 saved, 100 RANGE intrinsic, 47 saved-entity (R553), 107, 107, 180 rank, 19, 514 scalar, 19, 514 rbracket (R470), 38, 63, 82, 82, 86, 91, 102, 105, scalar-xyz (R103), 6, 6 107, 125, 126 scale factor, 261 READ statement, 223 scope, 483, 514 read-stmt (R910), 12, 223, 224, 338, 503 scoping unit, 12, 514 READ= specifier, 252 section subscript, 515 reading, 207 section-subscript (R620), 118, 119, 122, 122, 123, READWRITE= specifier, 253 319 REAL, 49 segment, 198 real and complex editing, 266 SELECT CASE statement, 180 real model, 343 SELECT TYPE construct, 192, 192, 487 real part, 50 SELECT TYPE statement, 192, 490 real type, 48, 48­50 select-case-stmt (R811), 180, 180, 195 real-literal-constant (R413), 28, 49, 49 select-construct-name, 192 real-part (R418), 50, 50 select-type-construct (R846), 11, 192, 192 REC= specifier, 228 select-type-stmt (R847), 192, 192, 195 RECL= specifier, 220, 253 SELECTED INT KIND intrinsic, 47 record, 207, 514 selector, 515 record file, 207 selector (R805), 178, 178, 179, 192, 193, 322, 491, record length, 208 503 record number, 210 separate module procedure, 333 RECURSIVE, 329 separate module subprogram statement, 333 recursive input/output statement, 257 separate-module-subprogram (R1237), 10, 290, 333, reference, 291, 514 333 rel-op (R713), 28, 135, 135, 149 sequence, 23 relational intrinsic operation, 140, 148 sequence association, 321 relational intrinsic operator, 140 SEQUENCE property, 60 rename (R1111), 291, 291, 292, 484 SEQUENCE statement, 59 rep-char, 53, 53, 262, 279, 284 sequence structure, 57 repeat specification., 260 sequence type, 59 671 J3/07-007 WORKING DRAFT 2006/01/05 sequence-stmt (R435), 58, 59 CALL, 311 sequential access, 209 CASE, 180 sequential access input/output statement, 228 CLASS DEFAULT, 192 SEQUENTIAL= specifier, 253 CLASS IS, 192 shape, 19, 515 CLOSE, 222 shape conformance, 154 COMMON, 113­116 shared-term-do-construct (R836), 185, 185 component definition, 62 sign (R411), 48, 48, 49, 266 computed GO TO, 195 sign-edit-desc (R1016), 261, 262 CONTAINS, 70, 336 SIGN= specifier, 221, 228, 253 CONTIGUOUS, 102 signed-digit-string (R409), 48, 50, 266 CONTINUE, 196 signed-int-literal-constant (R406), 48, 48, 50, 104, CRITICAL, 183 261 CYCLE, 187 signed-real-literal-constant (R412), 49, 50, 51, 104 DATA, 102 significand (R414), 49, 49 data transfer, 223 size, 19, 515 DEALLOCATE, 130 size of a common block, 114 DIMENSION, 105 size of a storage sequence, 493 DO, 184 SIZE= specifier, 228, 253 DO CONCURRENT, 184 source forms, 30 DO WHILE, 184 source-expr (R630), 126, 126, 127, 128 END, 16 special characters, 26 END BLOCK, 179 special-character, 25, 27 END CRITICAL, 183 specific interface, 301 END INTERFACE, 300 specific interface block, 301 ENDFILE, 245 specific name, 341 ENTRY, 334 specification, 85­116 EQUIVALENCE, 110­113 specification expression, 154, 515 executable, 15 specification function, 155, 515 EXIT, 194 specification inquiry, 155 EXTERNAL, 307 specification-expr (R729), 45, 52, 86, 92, 95, 154, file inquiry, 247 154, 339 file positioning, 244 specification-part (R204), 9, 10, 10, 15, 16, 70, 88, FINAL, 72 101, 155­157, 179, 180, 289, 290, 294, 295, FLUSH, 246 300, 330, 332, 333, 337 FORALL, 174 specification-stmt (R212), 10, 11 FORMAT, 259 standard-conforming program, 2, 515 formatted input/output, 225 starting point, 118 FUNCTION, 329 stat-variable (R628), 126, 126, 127, 130, 132, 199, GENERIC, 70 503, 594 GO TO, 195 STAT= specifier, 132 IF, 191 statement, 30, 515 IMPLICIT, 107 accessibility, 101 IMPORT, 302 ALLOCATABLE, 102 input/output, 207­257 ALLOCATE, 125 INTENT, 105 arithmetic IF, 195 INTERFACE, 300 assignment, 157 INTRINSIC, 310 ASSOCIATE, 178, 490 list-directed input/output, 226 ASYNCHRONOUS, 102 MODULE, 290 attribute specification, 101­116 NAMELIST, 110 BACKSPACE, 245 namelist input/output, 226 BIND, 102 NOTIFY, 203 BLOCK, 179 NULLIFY, 130 BLOCK DATA, 294 OPEN, 217 672 2006/01/05 WORKING DRAFT J3/07-007 OPTIONAL, 106 storage associated, 495 PARAMETER, 106 storage association, 110­116, 493, 493, 515 POINTER, 106 storage sequence, 114, 493, 515 pointer assignment, 163 storage unit, 493, 515 PRINT, 223 stream access, 210 PRIVATE, 69, 70, 101 stream access input/output statement, 228 PROCEDURE, 303 stream file, 207 procedure declaration, 308 STREAM= specifier, 253 PROGRAM, 289 stride, 124, 515 PROTECTED, 106 stride (R622), 122, 122, 169, 170, 173, 232, 319 PUBLIC, 101 string, see character string QUERY, 203 struct, 515 READ, 223 structure, 17, 57, 515 RETURN, 335 structure component, 118, 515 REWIND, 246 structure constructor, 77, 516 SAVE, 107 structure-component (R614), 103, 117, 118, 119, SELECT CASE, 180 126, 130 SELECT TYPE, 192, 490 structure-constructor (R459), 77, 78, 104, 133, 338 separate module subprogram, 333 subcomponent, 120, 516 SEQUENCE, 59 submodule, 14, 294, 516 statement function, 336 submodule (R1116), 9, 294 STOP, 196 submodule identifier, 294 SUBMODULE, 294 SUBMODULE statement, 294 SUBROUTINE, 332 submodule-name, 294 SYNC ALL, 199 submodule-stmt (R1117), 9, 294, 294 SYNC IMAGES, 201 subobject, 18, 516 SYNC MEMORY, 204 subprogram, 12, 516 SYNC TEAM, 200 subroutine, 13, 516 TARGET, 107 subroutine reference, 325 TYPE, 57 SUBROUTINE statement, 332 type declaration, 85­87 subroutine subprogram, 332, 516 TYPE IS, 192 subroutine-name, 301, 332, 333, 485 type parameter definition, 61 subroutine-stmt (R1234), 9, 300, 301, 329, 330, 332, type-bound procedure, 70 332, 333, 485, 488 unformatted input/output, 225 subroutine-subprogram (R1233), 9, 10, 290, 332, USE, 291 333 VALUE, 107 subscript, 516 VOLATILE, 107 subscript (R619), 7, 103, 122, 122, 169, 170, 173, WAIT, 244 232, 319 WHERE, 166 subscript triplet, 124, 516 WRITE, 223 subscript-triplet (R621), 122, 122, 123, 319 statement entity, 483, 515 substring, 118, 516 statement function, 298, 336, 515 substring (R609), 111, 117, 118 statement function statement, 336 substring-range (R611), 90, 118, 118, 120, 122, 232, statement label, 29, 29, 515 319 statement order, 15 suffix (R1231), 330, 331, 334 statements SYNC ALL statement, 199 INQUIRE, 247 SYNC IMAGES statement, 201 STATUS= specifier, 221, 223 SYNC MEMORY statement, 204 stmt-function-stmt (R1243), 10, 290, 294, 301, 336, SYNC TEAM statement, 200 488 sync-all-stmt (R857), 12, 199 STOP statement, 196 sync-images-stmt (R861), 12, 201 stop-code (R856), 196, 196, 197 sync-memory-stmt (R866), 12, 204 stop-stmt (R855), 12, 38, 185, 196, 338 sync-stat (R858), 199, 199, 200, 201, 203, 204 673 J3/07-007 WORKING DRAFT 2006/01/05 sync-team-stmt (R859), 12, 200 TYPE type specifier, 46 synchronous, 226, 228, 231 type-attr-spec (R432), 57, 57, 58 type-bound procedure, 71, 328, 516 T Type-bound procedure statement, 70 target, 20, 516 type-bound-generic-stmt (R454), 70, 70 TARGET attribute, 100, 107, 315 type-bound-proc-binding (R452), 70, 70 TARGET statement, 107 type-bound-procedure-part (R450), 57, 59, 70, 72, target-decl (R556), 107, 107 475 target-stmt (R555), 11, 107, 488 type-bound-procedure-stmt (R453), 70, 70 team, 14, 516 type-declaration-stmt (R501), 10, 52, 85, 85, 337, team synchronization, 200, 223, 341, 382, 516 488 TEAM= specifier, 221, 254 type-guard-stmt (R848), 192, 192 terminal point, 211 type-name, 57, 58, 61, 71, 77, 516 TKR compatible, 306 type-param-attr-spec (R438), 61, 61 token (R339), 37, 37 type-param-decl (R437), 61, 61 totally [storage] associated, 495 type-param-def-stmt (R436), 57, 61, 61 transfer of control, 177, 195, 255, 256 type-param-inquiry (R616), 121, 121, 133, 486 transformational function, 341, 516 type-param-name, 57, 61, 64, 121, 133, 134, 486, type, 17, 43­82, 516 488 abstract, 74 type-param-spec (R458), 77, 77 base, 74 type-param-value (R401), 44, 44, 45, 52, 64, 77, bits, 55­57 126, 127 character, 51­55 type-spec (R402), 45, 46, 52, 53, 82, 125­127, 169, complex, 50 170, 192, 487 concept, 43 declared, 46 U derived, 57­80 ultimate component, 57, 517 dynamic, 46 unallocated, 129 expression, 152 undefined, 22, 517 extended, 74 undefinition of variables, 497 extensible, 74 underscore (R303), 25, 25 extension, 74 unformatted data transfer, 234 integer, 47 unformatted input/output statement, 225 intrinsic, 47­55 unformatted record, 208 logical, 55 UNFORMATTED= specifier, 254 operation, 153 Unicode, 219 parent, 74 unit, 214 primary, 152 unlimited polymorphic, 46 real, 48­50 unlimited-format-item (R1004), 259, 260, 263 type compatible, 46, 516 unsaved, 100 type conformance, 158 unsigned, 517 type declaration statement, 85­87, 516 unspecified storage unit, 494, 517 type equality, 60 upper-bound (R514), 92, 92 type incompatible, 46 upper-bound-expr (R635), 126, 126, 128, 164 TYPE IS statement, 192 upper-co-bound (R522), 95, 95, 369 type parameter, 17, 44, 47, 48, 485, 516 use associated, 291 type parameter definition statement, 61 use association, 488, 517 type parameter inquiry, 121 USE statement, 291 type parameter keyword, 21 use-defined-operator (R1115), 291, 292, 292, 293 type parameter order, 62, 517 use-name, 101, 291­293, 484 type specifier, 45 use-stmt (R1109), 10, 291, 292, 488 derived type, 46 TYPE, 46 V TYPE statement, 57 v (R1011), 239, 261, 261, 274 674 2006/01/05 WORKING DRAFT J3/07-007 VALUE attribute, 100, 107, 314 writing, 207 value separator, 278 VALUE statement, 107 X value-stmt (R557), 11, 107 xyz-list (R101), 6 variable, 18, 517 xyz-name (R102), 6 variable (R601), xv, 78, 103, 117, 117, 158­161, 163, 164, 168, 170, 172, 178, 192, 193, 229,Z 311, 462, 503 zero-size array, 19, 92, 104 variable-name (R602), 110, 111, 113, 114, 117, 117, ZZZUTI005, 196 118, 126, 130, 163, 488, 503 ZZZUTI006, 197 variables ZZZUTI010, 290 definition & undefinition, 497 ZZZUTI016, 314 vector subscript, 124, 517 ZZZUTI050, 315 vector-subscript (R623), 122, 122, 123 ZZZUTI073, 437 void, 517 ZZZUTI076, 500 VOLATILE attribute, 100, 107 ZZZUTI080, xv VOLATILE statement, 107 ZZZUTI081, 128 volatile-stmt (R558), 11, 107 ZZZUTI082, 567 ZZZUTI084, 180 W ZZZUTI086, 200 w (R1007), 261, 261, 265­269, 271­274, 279, 281, ZZZUTI089, 120 284 ZZZUTI090, 437 wait operation, 222, 231, 243, 243 ZZZUTI091, 232 WAIT statement, 244 ZZZUTI092, 420 wait-spec (R922), 244, 244 ZZZUTI093, 424 wait-stmt (R921), 12, 244, 338 ZZZUTI094, 63 WHERE construct, 166 ZZZUTI096, 318 WHERE statement, 166 ZZZUTI097, 317 where-assignment-stmt (R747), 166, 167, 167, 168, ZZZUTI098, 440 169, 173, 508 ZZZUTI099, 2 where-body-construct (R746), 166, 167, 167, 168 ZZZUTI100, 596 where-construct (R744), 11, 166, 167, 169, 173 ZZZUTI101, 320 where-construct-name, 167 ZZZUTI103, 330 where-construct-stmt (R745), 166, 167, 167, 173, ZZZUTI104, 142 195 ZZZUTI105, 368 where-stmt (R743), 12, 166, 167, 169, 173 ZZZUTI106, 247 whole array, 121, 517 ZZZUTI107, 596 WRITE statement, 223 ZZZUTI108, 597 write-stmt (R911), 12, 223, 224, 338, 503 ZZZUTI192, 502 WRITE= specifier, 254 ZZZUTI5003, 512 675