WORKING DRAFT J3/06-007 July 11, 2006 18:25 This is an internal working document of J3. 2006/07/11 WORKING DRAFT J3/06-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 . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.7 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8 Deleted and obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.2 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.3 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Fortran terms and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5 Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.5 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 i J3/06-007 WORKING DRAFT 2006/07/11 2.4.6 Co-array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.7 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.8 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.10 Companion processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3 Characters, lexical tokens, and source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Processor character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.3 Underscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.4 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.5 Other characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5 Macro processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5.1 Macro definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5.2 Macro expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Relationship of types and values to ob jects . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1 Type specifiers and type compatibility . . . . . . . . . . . . . . . . . . . . . . . 43 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.1 Classification and specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.2 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4.3 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.4 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.5 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.6 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.7 Bits type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.1 Derived type concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 ii 2006/07/11 WORKING DRAFT J3/06-007 4.5.2 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.3 Derived-type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.5.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5.5 Type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5.6 Final subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.5.7 Type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.5.8 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.9 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.10 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.11 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 78 4.6 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.7 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5 Attribute declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.3 Examples of type declaration statements . . . . . . . . . . . . . . . . . . . . . . 85 5.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.2 Accessibility attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.3 ALLOCATABLE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.4 ASYNCHRONOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.5 BIND attribute for data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.6 CONTIGUOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.7 DIMENSION attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.8 EXTERNAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.3.9 INTENT attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.3.10 INTRINSIC attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.11 OPTIONAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.12 PARAMETER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.13 POINTER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.14 PROTECTED attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.15 SAVE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.16 TARGET attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.17 VALUE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.3.18 VOLATILE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4.1 Accessibility statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.4.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.5 CONTIGUOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.6 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.7 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.8 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.9 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4.10 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4.11 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4.12 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.13 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.14 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.15 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 iii J3/06-007 WORKING DRAFT 2006/07/11 5.4.16 VOLATILE statement . . . ....... . . . . . . . . . . . . . . . . . . . . . . 105 5.5 IMPLICIT statement . . . . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 106 5.6 NAMELIST statement . . . . . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 108 5.7 Storage association of data ob jects . ....... . . . . . . . . . . . . . . . . . . . . . . 108 5.7.1 EQUIVALENCE statement ....... . . . . . . . . . . . . . . . . . . . . . . 108 5.7.2 COMMON statement . . . . ....... . . . . . . . . . . . . . . . . . . . . . . 111 5.7.3 Restrictions on common and equivalence . . . . . . . . . . . . . . . . . . . . . . 114 6 Use of data ob jects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1.3 Complex parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.4 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.3 Image selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.1 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.2 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.1.3 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.1.4 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 139 7.1.5 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 141 7.1.6 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7.1.7 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.1.8 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.2 Interpretation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2.2 Numeric intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2.3 Character intrinsic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7.2.4 Relational intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.2.5 Logical intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 7.2.6 Bits intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.4 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.4.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.4.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.4.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 166 7.4.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1.2 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.1.3 IF construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.1.4 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.1.5 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 iv 2006/07/11 WORKING DRAFT J3/06-007 8.1.6 SELECT TYPE construct . . . . . . . . . . . . . . . ........... . . . . 182 8.1.7 DO construct . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 185 8.1.8 EXIT statement . . . . . . . . . . . . . . . . . . . . . ........... . . . . 191 8.1.9 BLOCK construct . . . . . . . . . . . . . . . . . . . . ........... . . . . 191 8.1.10 CRITICAL construct . . . . . . . . . . . . . . . . . . ........... . . . . 192 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 193 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . ........... . . . . 193 8.2.2 Computed GO TO statement . . . . . . . . . . . . . ........... . . . . 193 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . ........... . . . . 193 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 194 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 194 8.5 Image execution control . . . . . . . . . . . . . . . . . . . . . . ........... . . . . 196 8.5.1 Image control statements . . . . . . . . . . . . . . . . ........... . . . . 196 8.5.2 SYNC ALL statement . . . . . . . . . . . . . . . . . ........... . . . . 198 8.5.3 SYNC TEAM statement . . . . . . . . . . . . . . . . ........... . . . . 199 8.5.4 SYNC IMAGES statement . . . . . . . . . . . . . . . ........... . . . . 201 8.5.5 NOTIFY and QUERY statements . . . . . . . . . . . ........... . . . . 202 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.4.5 OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.4.6 NEWUNIT= specifier in the OPEN statement . . . . . . . . . . . . . . . . . . . 220 9.4.7 CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.5.1 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.5.2 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 9.5.3 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 232 9.5.4 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 243 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.6.1 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.6.2 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.7.1 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.7.2 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.7.3 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.9 File inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 9.9.1 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 v J3/06-007 WORKING DRAFT 2006/07/11 9.9.2 Restrictions on inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 255 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 . . . . . . . . . . . . . . . . . . 256 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.4 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.5 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 10.7.6 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.9 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.1 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 10.10.2 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 10.11 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 10.11.1 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 10.11.2 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 11 Program units . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 289 11.1 Main program . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 289 11.2 Modules . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 290 11.2.1 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 291 11.2.2 Submodules . . . . ............ . . . . . . . . . . . . . . . . . . . . . . 293 11.3 Block data program units . . ............ . . . . . . . . . . . . . . . . . . . . . . 294 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 vi 2006/07/11 WORKING DRAFT J3/06-007 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 of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.1 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.2 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.1 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.2 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 300 12.5 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 12.5.1 Actual arguments, dummy arguments, and argument association . . . . . . . . . 311 12.5.2 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 12.5.3 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 12.5.4 Resolving named procedure references . . . . . . . . . . . . . . . . . . . . . . . . 323 12.5.5 Resolving type-bound procedure references . . . . . . . . . . . . . . . . . . . . . 325 12.6 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.6.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.6.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.6.3 Definition and invocation of procedures by means other than Fortran . . . . . . 332 12.6.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 12.7 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 12.8 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 12.8.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 335 12.8.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 336 12.8.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 337 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.2.1 General rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 13.2.2 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.3 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.4 Arguments of collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.15 Collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.16 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.17 Allocation transfer procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 vii J3/06-007 WORKING DRAFT 2006/07/11 13.5.18 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.19 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 349 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 350 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 13.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 13.8.2 The IEEE modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 13.8.3 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 437 13.8.4 The ISO C BINDING module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 14 Exceptions and IEEE arithmetic . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 443 14.1 Derived types and constants defined in the modules . . . . . . . . . . . . . . . . . . . . . 444 14.2 The exceptions . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 445 14.3 The rounding modes . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 446 14.4 Underflow mode . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 447 14.5 Halting . . . . . . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 447 14.6 The floating point status . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 448 14.7 Exceptional values . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 448 14.8 IEEE arithmetic . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 448 14.9 Tables of the procedures . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 449 14.9.1 Inquiry functions . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 449 14.9.2 Elemental functions . . . . ......... . . . . . . . . . . . . . . . . . . . . . 450 14.9.3 Kind function . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 450 14.9.4 Elemental subroutines . . ......... . . . . . . . . . . . . . . . . . . . . . 450 14.9.5 Nonelemental subroutines ......... . . . . . . . . . . . . . . . . . . . . . 450 14.10 Specifications of the procedures . . ......... . . . . . . . . . . . . . . . . . . . . . 451 14.11 Examples . . . . . . . . . . . . . . . ......... . . . . . . . . . . . . . . . . . . . . . 466 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.2 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.2.1 Summary of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.2.2 Named constants and derived types in the module . . . . . . . . . . . . . . . . . 471 15.2.3 Procedures in the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 15.3 Interoperability between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.2 Interoperability of intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . 477 15.3.3 Interoperability with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . 479 15.3.4 Interoperability of derived types and C struct types . . . . . . . . . . . . . . . . 480 15.3.5 Interoperability of scalar variables . . . . . . . . . . . . . . . . . . . . . . . . . . 481 15.3.6 Interoperability of array variables . . . . . . . . . . . . . . . . . . . . . . . . . . 481 15.3.7 Interoperability of procedures and procedure interfaces . . . . . . . . . . . . . . 482 15.4 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 15.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 15.4.2 Binding labels for common blocks and variables . . . . . . . . . . . . . . . . . . 485 15.5 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 15.5.1 Definition and reference of interoperable procedures . . . . . . . . . . . . . . . . 485 15.5.2 Binding labels for procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 15.5.3 Exceptions and IEEE arithmetic procedures . . . . . . . . . . . . . . . . . . . . 486 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.1 Identifiers and entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.2 Scope of global identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.3 Scope of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 viii 2006/07/11 WORKING DRAFT J3/06-007 16.3.1 Classes of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 16.3.2 Local identifiers that are the same as common block names . . . . . . . . . . . . 489 16.3.3 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 16.3.4 Restrictions on generic declarations . . . . . . . . . . . . . . . . . . . . . . . . . 489 16.3.5 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . 491 16.3.6 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 16.4 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 16.5 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 16.5.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 16.5.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 16.5.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 16.5.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 16.5.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 16.6 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.1 Definition of ob jects and subob jects . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 504 16.6.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 504 16.6.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 506 16.6.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 16.6.8 Pointer association context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Annex A (informative)Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Annex B (informative)Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . 525 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . 525 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . 525 Annex C (informative)Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 C.1 Clause 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 C.1.1 Selection of the approximation methods (4.4.3) . . . . . . . . . . . . . . . . . . 527 C.1.2 Type extension and component accessibility (4.5.2.2, 4.5.4) . . . . . . . . . . . . 527 C.1.3 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 C.1.4 Pointers (4.5.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 C.1.5 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . 530 C.1.6 Generic type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 C.1.7 Final subroutines (4.5.6, 4.5.6.2, 4.5.6.3, 4.5.6.4) . . . . . . . . . . . . . . . . . . 533 C.2 Clause 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 C.2.1 The POINTER attribute (5.3.13) . . . . . . . . . . . . . . . . . . . . . . . . . . 535 C.2.2 The TARGET attribute (5.3.16) . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.2.3 The VOLATILE attribute (5.3.18) . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.3 Clause 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 538 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.4 Clause 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 ix J3/06-007 WORKING DRAFT 2006/07/11 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . 540 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . 540 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . 541 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . 542 C.5 Clause 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . 545 C.6 Clause 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 548 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 C.6.6 CLOSE statement (9.4.7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 C.7 Clause 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 C.7.1 Number of records (10.4, 10.5, 10.8.2) . . . . . . . . . . . . . . . . . . . . . . . . 552 C.7.2 List-directed input (10.10.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 C.8 Clause 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . 553 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 C.8.4 Modules with submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 C.9 Clause 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 C.9.1 Portability problems with external procedures (12.4.2.2) . . . . . . . . . . . . . 567 C.9.2 Procedures defined by means other than Fortran (12.6.3) . . . . . . . . . . . . . 567 C.9.3 Procedure interfaces (12.4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 C.9.4 Abstract interfaces (12.4) and procedure pointer components (4.5) . . . . . . . . 568 C.9.5 Argument association and evaluation (12.5.1.4) . . . . . . . . . . . . . . . . . . 570 C.9.6 Pointers and targets as arguments (12.5.1.4) . . . . . . . . . . . . . . . . . . . . 571 C.9.7 Polymorphic Argument Association (12.5.1.6) . . . . . . . . . . . . . . . . . . . 572 C.10 Clause 13 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 C.10.1 Module for THIS IMAGE and IMAGE INDEX . . . . . . . . . . . . . . . . . . 573 C.10.2 Collective co-array subroutine variations . . . . . . . . . . . . . . . . . . . . . . 574 C.11 Clause 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 C.11.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 C.11.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . 575 C.12 Clause 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 C.12.1 Examples of host association (16.5.1.4) . . . . . . . . . . . . . . . . . . . . . . . 580 C.12.2 Rules ensuring unambiguous generics (16.3.4) . . . . . . . . . . . . . . . . . . . 581 C.13 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 C.13.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 C.13.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588 C.13.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . 592 C.13.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 C.13.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 593 C.13.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 593 C.13.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 C.13.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 C.13.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . 595 C.13.10 Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . 595 x 2006/07/11 WORKING DRAFT J3/06-007 Annex D (informative)Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597 D.1 Extract of all syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597 D.2 Syntax rule cross-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 Annex E (informative)Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657 xi J3/06-007 WORKING DRAFT 2006/07/11 xii 2006/07/11 WORKING DRAFT J3/06-007 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Sp ecial characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.1 Typ e of op erands and results for intrinsic op erators . . . . . . . . . . . . . . . . . 137 7.2 Interpretation of the numeric intrinsic op erators . . . . . . . . . . . . . . . . . . . 151 7.3 Interpretation of the character intrinsic op erator // . . . . . . . . . . . . . . . . . 151 7.4 Interpretation of the relational intrinsic op erators . . . . . . . . . . . . . . . . . . 152 7.5 Interpretation of the logical intrinsic op erators . . . . . . . . . . . . . . . . . . . . 153 7.6 The values of op erations involving logical intrinsic op erators . . . . . . . . . . . . 153 7.7 Interpretation of the bits intrinsic op erators . . . . . . . . . . . . . . . . . . . . . . 154 7.8 The values of bitwise op erations involving bits intrinsic op erators . . . . . . . . 154 7.9 Categories of op erations and relative precedence . . . . . . . . . . . . . . . . . . . 154 7.10 Typ e conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 158 7.11 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 160 7.12 Bits conversion and the assignment statement . . . . . . . . . . . . . . . . . . . . . 160 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 413 15.1 Names of C characters with sp ecial semantics . . . . . . . . . . . . . . . . . . . . . 472 15.2 Interop erability b etween Fortran and C typ es . . . . . . . . . . . . . . . . . . . . . 477 xiii J3/06-007 WORKING DRAFT 2006/07/11 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 sub ject 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/07/11 WORKING DRAFT J3/06-007 Intro duction International Standard programming language Fortran This part of the International Standard comprises the specification of the base Fortran language, infor- mally known as Fortran 2008. With the limitations noted in 1.6.3, the syntax and semantics of Fortran 2003 are contained entirely within Fortran 2008. Therefore, any standard-conforming Fortran 2003 pro- gram not affected by such limitations is a standard-conforming Fortran 2008 program. New features of Fortran 2008 can be compatibly incorporated into such Fortran 2003 programs, with any exceptions indicated in the text of this part of the standard. Fortran 2008 contains several extensions to Fortran 2003; some of these are listed below. (1) The maximum rank of an array has been increased from seven to fifteen. (2) Performance enhancements: The DO CONCURRENT construct, which allows loop itera- tions to be executed in any order or potentially concurrently. (3) Pointers can be initialized to point to a target. (4) Performance enhancements: CONTIGUOUS attribute. (5) The ATAN intrinsic is extended so that ATAN (Y, X) is ATAN2 (Y,X). (6) Allocatable components of recursive type. (7) The MOLD= specifier has been added to the ALLOCATE statement. (8) OPEN statement enhancements that allow the processor to select a unit number when opening an external unit. Such a unit number is guaranteed not to interfere with any program-managed unit numbers. (9) The BLOCK construct (allows declarations within executable statements). (10) A disassociated or deallocated actual argument can correspond to an optional nonpointer nonallocatable dummy argument. (11) The concept of variable now includes references to pointer functions which return associated pointers. (12) The COMPILER VERSION and COMPILER OPTIONS functions provide information about the translation phase of the execution of a program. (13) The real and imaginary parts of a COMPLEX variable can be selected using a component- like syntax. (14) Scoped macros which can generate whole Fortran statements and subprograms. (15) A FINDLOC intrinsic was added and a BACK= argument was also added to MAXLOC and MINLOC. (16) Parallel programming support: SPMD parallel programming, co-arrays for data exchange between images, image control statements, and collective procedures. (17) A BITS data type for non-numeric programming and enhanced handling of BOZ constants. 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 xv J3/06-007 WORKING DRAFT 2006/07/11 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/07/11 WORKING DRAFT J3/06-007 Information technology -- Programming languages -- 1 Fortran -- 2 Part 1: 3 Base Language 4 1 Overview 5 1.1 Scope 6 ISO/IEC 1539 is a multipart International Standard; the parts are published separately. This publi- 7 cation, ISO/IEC 1539-1, which is the first part, specifies the form and establishes the interpretation 8 of programs expressed in the base Fortran language. The purpose of this part of ISO/IEC 1539 is to 9 promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on 10 a variety of computing systems. The second part, ISO/IEC 1539-2, defines additional facilities for the 11 manipulation of character strings of variable length. The third part, ISO/IEC 1539-3, defines a stan- 12 dard conditional compilation facility for Fortran. A processor conforming to part 1 need not conform to 13 ISO/IEC 1539-2 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. 14 Throughout this publication, the term "this standard" refers to ISO/IEC 1539-1. 15 1.2 Processor 16 The combination of a computing system and the mechanism by which programs are transformed for use 17 on that computing system is called a pro cessor in this part of ISO/IEC 1539. 18 1.3 Inclusions 19 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 1.4 Exclusions 25 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 (3) the method of transcription of programs or their input or output data to or from a storage 29 medium, 30 (4) the program and processor behavior when this part of ISO/IEC 1539 fails to establish an 31 interpretation except for the processor detection and reporting requirements in items (2) to 32 1 J3/06-007 WORKING DRAFT 2006/07/11 (8) of 1.5, 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, 3 (6) the physical properties of the representation of quantities and the method of rounding, 4 approximating, or computing numeric values on a particular processor, 5 (7) the physical properties of input/output records, files, and units, or 6 (8) the physical properties and implementation of storage. 7 1.5 Conformance 8 A program (2.2.1) is a standard-conforming program if it uses only those forms and relationships 9 described herein and if the program has an interpretation according to this part of ISO/IEC 1539. A 10 program unit (2.2) conforms to this part of ISO/IEC 1539 if it can be included in a program in a manner 11 that allows the program to be standard conforming. 12 A processor conforms to this part of ISO/IEC 1539 if: 13 (1) it executes any standard-conforming program in a manner that fulfills the interpretations 14 herein, sub ject to any limits that the processor may impose on the size and complexity of 15 the program; 16 (2) it contains the capability to detect and report the use within a submitted program unit of 17 a form designated herein as obsolescent, insofar as such use can be detected by reference to 18 the numbered syntax rules and constraints; 19 (3) it contains the capability to detect and report the use within a submitted program unit of 20 an additional form or relationship that is not permitted by the numbered syntax rules or 21 constraints, including the deleted features described in Annex B; 22 (4) it contains the capability to detect and report the use within a submitted program unit of 23 an intrinsic type with a kind type parameter value not supported by the processor (4.4); 24 (5) it contains the capability to detect and report the use within a submitted program unit of 25 source form or characters not permitted by Clause 3; 26 (6) it contains the capability to detect and report the use within a submitted program of name 27 usage not consistent with the scope rules for names, labels, operators, and assignment 28 symbols in Clause 16; 29 (7) it contains the capability to detect and report the use within a submitted program unit of 30 intrinsic procedures whose names are not defined in Clause 13; and 31 (8) it contains the capability to detect and report the reason for rejecting a submitted program. 32 However, in a format specification that is not part of a FORMAT statement (10.2.1), a processor need not 33 detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 34 A standard-conforming processor may allow additional forms and relationships provided that such ad- 35 ditions do not conflict with the standard forms and relationships. However, a standard-conforming 36 processor may allow additional intrinsic procedures even though this could cause a conflict with the 37 name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 38 of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 39 given the EXTERNAL attribute (5.3.8) in the scoping unit (16). A standard-conforming program shall 40 not use nonstandard intrinsic procedures or modules that have been added by the processor. 41 Because a standard-conforming program may place demands on a processor that are not within the 42 scope of this part of ISO/IEC 1539 or may include standard items that are not portable, such as 43 external procedures defined by means other than Fortran, conformance to this part of ISO/IEC 1539 44 does not ensure that a program will execute consistently on all or any standard-conforming processors. 45 2 2006/07/11 WORKING DRAFT J3/06-007 In some cases, this part of ISO/IEC 1539 allows the provision of facilities that are not completely specified 1 in the standard. These facilities are identified as pro cessor dep endent. They shall be provided, with 2 methods or semantics determined by the processor. 3 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 4 1.6.1 New intrinsic pro cedures 5 Each Fortran International Standard since ISO 1539:1980 (informally referred to as Fortran 77), defines 6 more intrinsic procedures than the previous one. Therefore, a Fortran program conforming to an older 7 standard may have a different interpretation under a newer standard if it invokes an external procedure 8 having the same name as one of the new standard intrinsic procedures, unless that procedure is specified 9 to have the EXTERNAL attribute. 10 1.6.2 New intrinsic data typ e and op erator 11 This part of ISO/IEC 1539 specifies a new intrinsic type, BITS, which will conflict with a derived type 12 of the same name. 13 This part of ISO/IEC 1539 specifies a new intrinsic operator, .XOR., which might conflict with a user- 14 defined operator of the same name, and has a different precedence than in previous revisions of this part 15 of ISO/IEC 1539. 16 1.6.3 Fortran 2003 compatibility 17 Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension 18 to the preceding Fortran International Standard, ISO/IEC 1539-1:2004 (Fortran 2003). Any standard- 19 conforming Fortran 2003 program that does not use a derived type called BITS, and does not use a 20 user-defined operator called .XOR., remains standard-conforming under this part of ISO/IEC 1539. 21 1.6.4 Fortran 95 compatibility 22 Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension to 23 ISO/IEC 1539-1:1997 (Fortran 95). Any standard-conforming Fortran 95 program remains standard- 24 conforming under this part of ISO/IEC 1539. The following Fortran 95 features may have different 25 interpretations in this part of ISO/IEC 1539. 26 (1) Earlier Fortran standards had the concept of printing, meaning that column one of formatted 27 output had special meaning for a processor-dependent (possibly empty) set of external 28 files. This could be neither detected nor specified by a standard-specified means. The 29 interpretation of the first column is not specified by this part of ISO/IEC 1539. 30 (2) This part of ISO/IEC 1539 specifies a different output format for real zero values in list- 31 directed and namelist output. 32 3 J3/06-007 WORKING DRAFT 2006/07/11 (3) If the processor can distinguish between positive and negative real zero, this part of ISO/IEC 1 1539 requires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real 2 zero and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative 3 zero imaginary part. 4 1.6.5 Fortran 90 compatibility 5 Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this 6 part of ISO/IEC 1539 is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any 7 standard-conforming Fortran 90 program that does not use one of the deleted features remains standard- 8 conforming under this part of ISO/IEC 1539. 9 The PAD= specifier in the INQUIRE statement in this part of ISO/IEC 1539 returns the value UNDE- 10 FINED if there is no connection or the connection is for unformatted input/output. Fortran 90 specified 11 YES. 12 Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor 13 dependent. this part of ISO/IEC 1539 specifies that the second argument shall not be zero. 14 1.6.6 FORTRAN 77 compatibility 15 Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 16 of ISO/IEC 1539 is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard- 17 conforming Fortran 77 program that does not use one of the deleted features noted in Annex B.1 and 18 that does not depend on the differences specified here remains standard-conforming under this part of 19 ISO/IEC 1539. This part of ISO/IEC 1539 restricts the behavior for some features that were processor 20 dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program that uses one of 21 these processor-dependent features may have a different interpretation under this part of ISO/IEC 1539, 22 yet remain a standard-conforming program. The following Fortran 77 features may have different 23 interpretations in this part of ISO/IEC 1539. 24 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 25 than can be represented in a real datum when the constant is used to initialize a data ob ject 26 of type double precision real in a DATA statement. This part of ISO/IEC 1539 does not 27 permit a processor this option. 28 (2) If a named variable that was not in a common block was initialized in a DATA statement and 29 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 30 dependent. This part of ISO/IEC 1539 specifies (5.4.6) that this named variable has the 31 SAVE attribute. 32 (3) Fortran 77 specified that the number of characters required by the input list was to be 33 less than or equal to the number of characters in the record during formatted input. This 34 part of ISO/IEC 1539 specifies (9.5.3.4.2) that the input record is logically padded with 35 blanks if there are not enough characters in the record, unless the PAD= specifier with the 36 value 'NO' is specified in an appropriate OPEN or READ statement. 37 (4) A value of 0 for a list item in a formatted output statement will be formatted in a different 38 form for some G edit descriptors. In addition, this part of ISO/IEC 1539 specifies how 39 rounding of values will affect the output field form, but Fortran 77 did not address this 40 issue. Therefore, some Fortran 77 processors may produce an output form different from 41 the output form produced by Fortran 2003 processors for certain combinations of values and 42 G edit descriptors. 43 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 44 SIGN intrinsic function when the second argument is negative real zero is changed by this 45 part of ISO/IEC 1539. 46 4 2006/07/11 WORKING DRAFT J3/06-007 1.7 Notation used in this part of ISO/IEC 1539 1 1.7.1 Applicability of requirements 2 In this part of ISO/IEC 1539, "shall" is to be interpreted as a requirement; conversely, "shall not" is 3 to be interpreted as a prohibition. Except where stated otherwise, such requirements and prohibitions 4 apply to programs rather than processors. 5 1.7.2 Informative notes 6 Informative notes of explanation, rationale, examples, and other material are interspersed with the 7 normative body of this part of ISO/IEC 1539. The informative material is nonnormative; it is identified 8 by being in shaded, framed boxes that have numbered headings beginning with "NOTE." 9 1.7.3 Syntax rules 10 Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These 11 syntax rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions. 12 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 13 where otherwise noted. 14 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 15 eral syntactic classes for which particular syntactic entities shall be substituted in actual 16 statements. 17 Common abbreviations used in syntactic terms are: 18 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: 19 is introduces a syntactic class definition or introduces a syntactic class alternative [] encloses an optional item [ ] ... encloses an optionally repeated item that may occur zero or more times continues a syntax rule (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a 20 one- or two-digit clause number and nn is a two-digit sequence number within that clause. 21 The syntax rules are distributed as appropriate throughout the text, and are referenced by 22 number as needed. Some rules in Clauses 2 and 3 are more fully described in later clauses; in 23 such cases, the clause number s is the number of the later clause where the rule is repeated. 24 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 25 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 26 restricted by corresponding constraints and text. 27 NOTE 1.2 An example of the use of the syntax rules is: digit-string is digit [ digit ] ... 5 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 1.2 (cont.) The following are examples of forms for a digit string allowed by the above rule: digit digit digit digit digit digit digit digit digit digit digit digit digit digit digit If particular entities are substituted for digit , actual digit strings might be: 4 67 1999 10243852 1.7.4 Constraints 1 Each constraint is given a unique identifying number of the form Csnn, where s is a one- or two-digit 2 clause number and nn is a two-digit sequence number within that clause. 3 Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 4 annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 5 rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places 6 where the syntax term appears. 7 Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 8 to that of a restriction stated in the text, except that a processor is required to have the capability to 9 detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 10 and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 11 conforming program is required to adhere to the broad requirement, but that a standard-conforming 12 processor is required only to have the capability of diagnosing violations of the constraint. 13 1.7.5 Assumed syntax rules 14 In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 15 tion, the following rules are assumed. 16 R101 xyz-list is xyz [ , xyz ] ... 17 R102 xyz-name is name 18 R103 scalar-xyz is xyz 19 C101 (R103) scalar-xyz shall be scalar. 20 The letters "xyz " stand for any syntactic class phrase. An explicit syntax rule for a term overrides an 21 assumed rule. 22 1.7.6 Syntax conventions and characteristics 23 (1) Any syntactic class name ending in "-stmt " follows the source form statement rules: it shall 24 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 25 statement (such as an IF or WHERE statement). Conversely, everything considered to be 26 a source form statement is given a "-stmt " ending in the syntax rules. 27 (2) The rules on statement ordering are described rigorously in the definition of program-unit 28 (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 29 6 2006/07/11 WORKING DRAFT J3/06-007 (3) The suffix "-spec " is used consistently for specifiers, such as input/output statement speci- 1 fiers. It also is used for type declaration attribute specifications (for example, "array-spec " 2 in R510), and in a few other cases. 3 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 4 suffix "-selector " is used. See, for example, "kind-selector " (R405) and "length-selector " 5 (R421). 6 (5) The term "subscript " (for example, R619, R620, and R621) is used consistently in array 7 definitions. 8 1.7.7 Text conventions 9 In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 10 Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 11 statement". Boldface words are used in the text where they are first defined with a specialized meaning. 12 The descriptions of obsolescent features appear in a smaller type size. 13 NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 1.8 Deleted and obsolescent features 14 1.8.1 General 15 This part of ISO/IEC 1539 protects the users' investment in existing software by including all but five 16 of the language elements of Fortran 90 that are not processor dependent. This part of ISO/IEC 1539 17 identifies two categories of outmoded features. There are five in the first category, deleted features, 18 which consists of features considered to have been redundant in Fortran 77 and largely unused in 19 Fortran 90. Those in the second category, obsolescent features, are considered to have been redundant 20 in Fortran 90 and Fortran 95, but are still frequently used. 21 1.8.2 Nature of deleted features 22 Better methods existed in Fortran 77 for each deleted feature. These features were not included in 23 Fortran 95 or Fortran 2003, and are not included in this revision of Fortran. 24 1.8.3 Nature of obsolescent features 25 Better methods existed in Fortran 90 and Fortran 95 for each obsolescent feature. It is recommended 26 that programmers use these better methods in new programs and convert existing code to these methods. 27 The obsolescent features are identified in the text of this part of ISO/IEC 1539 by a distinguishing type 28 font (1.7.7). 29 A future revision of this part of ISO/IEC 1539 might delete an obscolescent feature if its use has become 30 insignificant. 31 1.9 Normative references 32 The following referenced standards are indispensable for the application of this part of ISO/IEC 1539. 33 For dated references, only the edition cited applies. For undated references, the latest edition of the 34 referenced standard (including any amendments) applies. 35 ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 36 7 J3/06-007 WORKING DRAFT 2006/07/11 ISO 8601:1988, Data elements and interchange formats--Information interchange-- 1 Representation of dates and times. 2 ISO/IEC 9899:1999, Information technology--Programming languages--C. 3 ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 4 Part 1: Architecture and basic multilingual plane. 5 IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 6 ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 7 commonly known as ASCII. 8 This part of ISO/IEC 1539 refers to ISO/IEC 9899:1999 as the C International Standard. 9 Because IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arith- 10 metic, and is widely known by this name, this standard refers to it as the IEEE International Standard. 11 8 2006/07/11 WORKING DRAFT J3/06-007 2 Fortran terms and concepts 1 2.1 High level syntax 2 This clause introduces the terms associated with program units and other Fortran concepts above the 3 construct, statement, and expression levels and illustrates their relationships. The notation used in this 4 standard 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. R201 program is program-unit 6 [ program-unit ] ... 7 A program shall contain exactly one main-program program-unit or a main program defined by means 8 other than Fortran, but not both. 9 R202 program-unit is main-program 10 or external-subprogram 11 or module 12 or submodule 13 or block-data 14 R1101 main-program is [ program-stmt ] 15 [ specification-part ] 16 [ execution-part ] 17 [ internal-subprogram-part ] 18 end-program-stmt 19 R203 external-subprogram is function-subprogram 20 or subroutine-subprogram 21 R1225 function-subprogram is function-stmt 22 [ specification-part ] 23 [ execution-part ] 24 [ internal-subprogram-part ] 25 end-function-stmt 26 R1233 subroutine-subprogram is subroutine-stmt 27 [ specification-part ] 28 [ execution-part ] 29 [ internal-subprogram-part ] 30 end-subroutine-stmt 31 R1104 module is module-stmt 32 [ specification-part ] 33 [ module-subprogram-part ] 34 end-module-stmt 35 R1116 submodule is submodule-stmt 36 [ specification-part ] 37 [ module-subprogram-part ] 38 end-submodule-stmt 39 R1120 block-data is block-data-stmt 40 [ specification-part ] 41 9 J3/06-007 WORKING DRAFT 2006/07/11 end-block-data-stmt 1 R204 specification-part is [ use-stmt ] ... 2 [ import-stmt ] ... 3 [ implicit-part ] 4 [ declaration-construct ] ... 5 R205 implicit-part is [ implicit-part-stmt ] ... 6 implicit-stmt 7 R206 implicit-part-stmt is implicit-stmt 8 or parameter-stmt 9 or format-stmt 10 or entry-stmt 11 R207 declaration-construct is derived-type-def 12 or entry-stmt 13 or enum-def 14 or format-stmt 15 or interface-block 16 or macro-definition 17 or parameter-stmt 18 or procedure-declaration-stmt 19 or specification-stmt 20 or type-declaration-stmt 21 or stmt-function-stmt 22 R208 execution-part is executable-construct 23 [ execution-part-construct ] ... 24 R209 execution-part-construct is executable-construct 25 or format-stmt 26 or entry-stmt 27 or data-stmt 28 R210 internal-subprogram-part is contains-stmt 29 [ internal-subprogram ] ... 30 R211 internal-subprogram is function-subprogram 31 or subroutine-subprogram 32 R1107 module-subprogram-part is contains-stmt 33 [ module-subprogram ] ... 34 R1108 module-subprogram is function-subprogram 35 or subroutine-subprogram 36 or separate-module-subprogram 37 R212 specification-stmt is access-stmt 38 or al locatable-stmt 39 or asynchronous-stmt 40 or bind-stmt 41 or common-stmt 42 or data-stmt 43 or dimension-stmt 44 or equivalence-stmt 45 or external-stmt 46 or intent-stmt 47 or intrinsic-stmt 48 or namelist-stmt 49 or optional-stmt 50 or pointer-stmt 51 or protected-stmt 52 or save-stmt 53 or target-stmt 54 10 2006/07/11 WORKING DRAFT J3/06-007 or volatile-stmt 1 or value-stmt 2 R213 executable-construct is action-stmt 3 or associate-construct 4 or block-construct 5 or case-construct 6 or critical-construct 7 or do-construct 8 or foral l-construct 9 or if-construct 10 or select-type-construct 11 or where-construct 12 R214 action-stmt is al locate-stmt 13 or assignment-stmt 14 or backspace-stmt 15 or cal l-stmt 16 or close-stmt 17 or continue-stmt 18 or cycle-stmt 19 or deal locate-stmt 20 or endfile-stmt 21 or end-function-stmt 22 or end-program-stmt 23 or end-subroutine-stmt 24 or exit-stmt 25 or flush-stmt 26 or foral l-stmt 27 or goto-stmt 28 or if-stmt 29 or inquire-stmt 30 or notify-stmt 31 or nul lify-stmt 32 or open-stmt 33 or pointer-assignment-stmt 34 or print-stmt 35 or query-stmt 36 or read-stmt 37 or return-stmt 38 or rewind-stmt 39 or stop-stmt 40 or sync-al l-stmt 41 or sync-images-stmt 42 or sync-memory-stmt 43 or sync-team-stmt 44 or wait-stmt 45 or where-stmt 46 or write-stmt 47 or 48 arithmetic-if-stmt or 49 computed-goto-stmt C201 (R208) An execution-part shall not contain an end-function-stmt , end-program-stmt , or end- 50 subroutine-stmt . 51 Additionally, an EXPAND statement may occur anywhere that any statement may occur other than 52 11 J3/06-007 WORKING DRAFT 2006/07/11 as the first statement of a program unit. The syntax rules are applied to the program after macro 1 expansion, i.e. with each EXPAND statement replaced by the statements it produces. 2 2.2 Program unit concepts 3 Program units are the fundamental components of a Fortran program. A program unit may be a main 4 program, an external subprogram, a module, a submodule, or a block data program unit. A subprogram 5 may be a function subprogram or a subroutine subprogram. A module contains definitions that are to 6 be made accessible to other program units. A submodule is a extension of a module; it may contain 7 the definitions of procedures declared in a module or another submodule. A block data program unit is 8 used to specify initial values for data ob jects in named common blocks. Each type of program unit is 9 described in Clause 11 or 12. An external subprogram is a subprogram that is not in a main program, 10 a module, a submodule, or another subprogram. An internal subprogram is a subprogram that is in 11 a main program or another subprogram. A mo dule subprogram is a subprogram that is in a module 12 or submodule but is not an internal subprogram. 13 A program unit consists of a set of nonoverlapping scoping units. A scoping unit is 14 (1) a program unit or subprogram, excluding any scoping units in it, 15 (2) a derived-type definition (4.5.2), or 16 (3) an interface body, excluding any scoping units in it. 17 A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often 18 abbreviated to host). A module or submodule is also the host scoping unit of its child submodules. 19 2.2.1 Program 20 A program consists of exactly one main program, any number (including zero) of other kinds of program 21 units, and any number (including zero) of external procedures and other entities defined by means other 22 than Fortran. 23 NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). This standard 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.1) is processed, a processor may require a particular order of processing of the program units. 2.2.2 Main program 24 The Fortran main program is described in 11.1. 25 2.2.3 Pro cedure 26 A pro cedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 27 execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 28 in an expression; its invocation causes a value to be computed which is then used in evaluating the 29 expression. The variable that returns the value of a function is called the result variable. A subroutine 30 is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 31 operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 32 the program state by changing the values of any of the data ob jects accessible to the subroutine; unless 33 it is a pure procedure, a function may do this in addition to computing the function value. 34 12 2006/07/11 WORKING DRAFT J3/06-007 Procedures are described further in Clause 12. 1 2.2.3.1 External pro cedure 2 An external pro cedure is a procedure that is defined by an external subprogram or by means other 3 than Fortran. An external procedure may be invoked by the main program or by any procedure of a 4 program. 5 2.2.3.2 Mo dule pro cedure 6 A mo dule pro cedure is a procedure that is defined by a module subprogram (R1108). The module or 7 submodule containing the subprogram is the host scoping unit of the module procedure. 8 2.2.3.3 Internal pro cedure 9 An internal pro cedure is a procedure that is defined by an internal subprogram (R211). The containing 10 main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 11 is local to its host in the sense that the internal procedure is accessible within the host scoping unit and 12 all its other internal procedures but is not accessible elsewhere. 13 2.2.3.4 Interface blo ck 14 An interface b o dy describes an abstract interface or the interface of a dummy procedure, external 15 procedure, procedure pointer, or type-bound procedure. 16 An interface blo ck is a specific interface block, an abstract interface block, or a generic interface block. 17 A specific interface block is a collection of interface bodies. A generic interface block can also be used 18 to specify that a procedure can be invoked 19 (1) by using a generic name, 20 (2) by using a defined operator, 21 (3) by using a defined assignment, or 22 (4) for derived-type input/output. 23 2.2.4 Module 24 A mo dule contains (or accesses from other modules) definitions that are to be made accessible to other 25 program units. These definitions include data ob ject declarations, type definitions, procedure definitions, 26 and interface blocks. A scoping unit in another program unit may access the definitions in a module. 27 Modules are further described in Clause 11. 28 2.2.5 Submo dule 29 A submo dule is a program unit that extends a module or another submodule. It may provide definitions 30 (12.6) for procedures whose interfaces are declared (12.4.2.1) in an ancestor module or submodule. It 31 may also contain declarations and definitions of other entities, which are accessible in its descendants. 32 An entity declared in a submodule is not accessible by use association unless it is a module procedure 33 whose interface is declared in the ancestor module. Submodules are further described in Clause 11. 34 NOTE 2.3 The scoping unit of a submodule accesses the scoping unit of its parent module or submodule by host association. 13 J3/06-007 WORKING DRAFT 2006/07/11 2.3 Execution concepts 1 Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 2 There are restrictions on the order in which statements may appear in a program unit, and not all 3 executable statements may appear in all contexts. 4 2.3.1 Executable/nonexecutable statements 5 Program execution is a sequence, in time, of actions. An executable statement is an instruction to 6 perform or control one or more of these actions. Thus, the executable statements of a program unit 7 determine the behavior of the program unit. The executable statements are all of those that make up 8 the syntactic class executable-construct . 9 Nonexecutable statements do not specify actions; they are used to configure the program environment 10 in which actions take place. The nonexecutable statements are all those not classified as executable. 11 2.3.2 Statement order 12 The syntax rules of clause 2.1 specify the statement order within program units and subprograms. These 13 rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for statements and 14 applies to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of 15 statements that may be interspersed and horizontal lines delineate varieties of statements that shall not 16 be interspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE 17 and CONTAINS statements in a subprogram, nonexecutable statements generally precede executable 18 statements, although the ENTRY statement, FORMAT statement, and DATA statement may appear 19 among the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. 20 Table 2.1: Requirements on statement ordering PROGRAM, FUNCTION, SUBROUTINE, MODULE, SUBMODULE, or BLOCK DATA statement USE statements IMPORT statements IMPLICIT NONE PARAMETER IMPLICIT statements statements Derived-type definitions, FORMAT interface blocks, and PARAMETER type declaration statements, ENTRY and DATA enumeration definitions, statements statements procedure declarations, specification statements, and statement function statements Executable DATA constructs statements CONTAINS statement Internal subprograms or module subprograms END statement 14 2006/07/11 WORKING DRAFT J3/06-007 Table 2.2: Statements allowed in scoping units Kind of scoping unit: Main Module or Block External Module Internal Interface program submodule data subprog subprog subprog body USE statement Yes Yes Yes Yes Yes Yes Yes IMPORT statement No No No No No No Yes ENTRY statement No No No Yes Yes No No FORMAT statement Yes No No Yes Yes Yes No Misc. decls (see note) Yes Yes Yes Yes Yes Yes Yes DATA statement Yes Yes Yes Yes Yes Yes No Derived-type definition Yes Yes Yes Yes Yes Yes Yes Interface block Yes Yes No Yes Yes Yes Yes Executable statement Yes No No Yes Yes Yes No CONTAINS statement Yes Yes No Yes Yes No No Statement function stmt. Yes No No Yes Yes Yes No Notes for Table 2.2: 1) Misc. declarations are PARAMETER statements, IMPLICIT statements, type declaration statements, enumeration definitions, procedure declaration statements, and specification statements. 2) The scoping unit of a module or submodule does not include any module sub- programs that it contains. 2.3.3 The END statement 1 An end-program-stmt , end-function-stmt , end-subroutine-stmt , end-sep-subprogram-stmt , end-module- 2 stmt , end-submodule-stmt , or end-block-data-stmt is an END statement. Each program unit, module 3 subprogram, and internal subprogram shall have exactly one END statement. The end-program-stmt , 4 end-function-stmt , end-subroutine-stmt , and end-sep-subprogram-stmt statements are executable, and 5 may be branch target statements (8.2). Executing an end-program-stmt causes normal termination of 6 execution of the program. Executing an end-function-stmt , end-subroutine-stmt , or end-sep-subprogram- 7 stmt is equivalent to executing a return-stmt with no scalar-int-expr . 8 The end-module-stmt , end-submodule-stmt , and end-block-data-stmt statements are nonexecutable. 9 2.3.4 Execution sequence 10 If a program contains a Fortran main program, execution of the program begins with the first executable 11 construct of the main program. The execution of a main program or subprogram involves execution of 12 the executable constructs within its scoping unit. When a procedure is invoked, execution begins with 13 the first executable construct appearing after the invoked entry point. With the following exceptions, 14 the effect of execution is as if the executable constructs are executed in the order in which they appear 15 in the main program or subprogram until a STOP, RETURN, or END statement is executed. 16 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 17 explicitly specify a new starting place for the execution sequence. 18 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 19 an internal statement structure and execution of these constructs involves implicit internal 20 branching. See Clause 8 for the detailed semantics of each of these constructs. 21 (3) END=, ERR=, and EOR= specifiers may result in a branch. 22 (4) 23 Alternate returns may result in a branch. Internal subprograms may precede the END statement of a main program or a subprogram. The 24 execution sequence excludes all such definitions. 25 15 J3/06-007 WORKING DRAFT 2006/07/11 The relative ordering of the exeuction sequences of different images can be affected by image control 1 statements (8.5.1). 2 Normal termination of execution of the program occurs on all images if a STOP statement or end- 3 program-stmt is executed immediately after a SYNC ALL (8.5.2) statement on all images. The stop 4 code, if any, and warnings of any exceptions that are signaling (8.4) shall be made available only for 5 image 1. 6 J3 internal note Unresolved Technical Issue 3 Since there is only one program, I do not see how "Normal termination of execution" can be qualified by "occurs on all images". If execution of the program is terminated, since that execution is all of the image executions, each image is terminated. This is straightforward from the first sentence of 2.3.5. It was suggested to me that the issue was whether termination was "normal" on all images; well, if it is normal for the whole program, it is normal on all images. J3 internal note Unresolved Technical Issue 4 "shall be made available only for image 1" is problematic since after normal termination no images exist. I do not understand what is meant here. Maybe (?) it is that any signalling exception on any image other than 1 is not reported?" Subgroup says "This is in direct response to complaints about MPI programs printing "Fortran STOP" to the screen 10000 times." The editor says: There is nothing in the standard which prevents a processor from printing "Fortran STOP" to the screen 10000 times even in single-process Fortran 77. I think that is purely and simply a matter of QoI (or possibly even outwith the scope). If we want to say something here it should almost certainly be *a note* along the lines that since a program is a program, however many "images" it contains, that processors should be circumspect about reporting identical statuses multiple times on image termination. Anyway, failure to report signalling exceptions just because they are on images other than the image numbered "1" is poor design. The consequences of overflow and invalid operations are just as potentially serious whether the computation takes part on image 1 or some other image. It would be preferable not to disallow a conscientious processor from reporting such problems. Finally, this is a small detail. There is currently no mention of what happens with signalling exceptions in clause 2, and so no need to mention how it differs with co-arrays. Therefore the second sentence should be deleted. When a STOP or end-program-stmt that does not immediately follow a SYNC ALL statement is executed 7 on an image, normal termination occurs on that image. The stop code, if any, and warnings of any 8 exceptions that are signaling shall be made available only for that image. The executions of all other 9 images are terminated. 10 16 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 5 This is inconsistent with the behaviour after SYNC ALL (unless image 1 always restarts first after a SYNC ALL). This is going to cause headaches for the implementors (STOP has multiple meanings, and does different things according to context - ugh). There seems to be two competing theories for what STOP is for here: (1) a programmer-initiated error termination (2) a normal termination and the decision as to which STOP is which kind is being determined by whether it is preceded by SYNC ALL (not that this is adequately defined, see J3 notes in the STOP statement section). In previous Fortrans, STOP is normal termination. That's it. It is not "CALL ABORT". If we want a second kind of STOP, perhaps we should consider adding a second kind of STOP, perhaps spelled QUICKSTOP or something. And of course the wording is bad ("made available") but wordsmithing can wait until the text is fixed or deleted. NOTE 2.4 When a STOP or end-program-stmt statement is executed on an image, how soon termination takes place on another image is processor dependent. J3 internal note Unresolved Technical Issue 6 Presumably this is referring to the "error STOP" (or the "STOP not after a SYNC ALL") situation, since it does not appear to be processor-dependent in the "normal STOP" case. Or perhaps it is... again, this doesn't seem to be well-defined.". 2.3.5 Images 1 A Fortran program executes as if it were replicated a number of times (which may be one), the number 2 of replications remaining fixed during execution of the program. 3 J3 internal note Unresolved Technical Issue 1 In post-draft discussions it has been variously and contradictorily contended that the concept of program does not include all the images. It is certainly contradictory in the edits. Look, if we *have* a definition of single-threaded Fortran (like we used to) then we can layer ***SOMETHING ELSE*** on top of it and replicate as we please without affecting the single- threaded concepts. But tightly integrating them does not give us this ability. If "program" is meant to include only the execution and data entities of a single image, we still need a name for the concept that is the "Co-Fortran program" providing the semantics for the whole "Co-Fortran" thing. Each copy is called an image and has its own set of data ob jects and procedure pointers. Each image 4 executes asynchronously. 5 NOTE 2.5 The programmer controls the progress of execution in each image through explicit use of Fortran control constructs (8.1, 8.2). The image control statements (8.5.1) affect the relative progress of execution between images. Co-arrays (2.4.6) provide a mechanism for accessing data on one image from another image. 17 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 2 Missing from the "own set" is execution state, however we say it. It has been contended that all of that is implicit in "executes asynchronously", but since there are many points of non-asychronous behaviour - e.g. in image termination effects - just how far that extends is emphatically NOT obvious. IEEE modes, external units, file system, we all need to know. Otherwise it is not standardised (a situation we should all hope to avoid). Either we should say that "All other entities are shared between the images" (after putting execution state into the "own" set!), or we should specify the entities that are shared; at least then any entity that does not fall into either list can be seen to be a problem... I suppose I recommend the latter course. Once this is fixed the edit at [178:36] can be turned into a note instead. (Actually, I think the whole paragraph at 178:35-36 should probably be inside the note, since we already say this under "scoping".) Each image is identified by an image index, which is an integer value in the range one to the number 1 of images. 2 A processor shall contain the capability of executing a program on a single image. 3 NOTE 2.6 A processor might allow the number of images to be chosen at compile time, link time, or run time. It might be the same as the number of CPUs but this is not required. Compiling for a single image might permit the optimizer to eliminate overhead associated with parallel execution. Portable programs should not make assumptions about the exact number of images. The maximum number of images may be limited due to architectural constraints. A team is a set of images formed by invoking the intrinsic collective subroutine FORM TEAM (13.7.69) 4 for the purposes of collaboration. A team is identified by a scalar variable of type IMAGE TEAM 5 (13.8.3.5). 6 2.4 Data concepts 7 Nonexecutable statements are used to specify the characteristics of the data environment. This includes 8 typing variables, declaring arrays, and defining new types. 9 2.4.1 Type 10 A typ e is a named category of data that is characterized by a set of values, a syntax for denoting 11 these values, and a set of operations that interpret and manipulate the values. This central concept is 12 described in 4.1. 13 A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 14 the set of operations depend on the values of one or more parameters. Such a parameter is called a typ e 15 parameter (4.2). 16 There are two categories of types: intrinsic types and derived types. 17 2.4.1.1 Intrinsic typ e 18 An intrinsic typ e is a type that is defined by the language, along with operations, and is always 19 accessible. The intrinsic types are integer, real, complex, character, logical, and bits. The properties of 20 intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. 21 The kind typ e parameter indicates the representation method for the specified type. 22 18 2006/07/11 WORKING DRAFT J3/06-007 2.4.1.2 Derived typ e 1 A derived typ e is a type that is defined by a type definition or by an intrinsic module. A scalar ob ject of 2 derived type is called a structure (4.5). Derived types may be parameterized. Assignment of structures 3 is defined intrinsically (7.4.1.3), but there are no intrinsic operations for structures. For each derived 4 type, a structure constructor is available to provide values (4.5.10). In addition, data ob jects of derived 5 type may be used as procedure arguments and function results, and may appear in input/output lists. 6 If additional operations are needed for a derived type, they shall be supplied as procedure definitions. 7 Derived types are described further in 4.5. 8 2.4.2 Data value 9 Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 10 on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 11 that ob jects of a derived type may assume are determined by the type definition, type parameter values, 12 and the sets of values of its components. 13 2.4.3 Data entity 14 A data entity is a data ob ject, the result of the evaluation of an expression, or the result of the execution 15 of a function reference (called the function result). A data entity has a type and type parameters; it 16 may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 17 either a scalar or an array. 18 2.4.3.1 Data object 19 A data ob ject (often abbreviated to ob ject) is a constant (4.1.2), a variable (6), or a subob ject of a 20 constant. The type and type parameters of a named data ob ject may be specified explicitly (5.2) or 21 implicitly (5.5). 22 Sub ob jects are portions of certain ob jects that may be referenced and defined (variables only) inde- 23 pendently of the other portions. These include portions of arrays (array elements and array sections), 24 portions of character strings (substrings), portions of complex ob jects (real and imaginary parts), and 25 portions of structures (components). Subob jects are themselves data ob jects, but subob jects are refer- 26 enced only by ob ject designators or intrinsic functions. A subob ject of a variable is a variable. Subob jects 27 are described in Clause 6. 28 Ob jects referenced by a name are: 29 a named scalar (a scalar ob ject) 30 a named array (an array ob ject) Subob jects referenced by an ob ject designator are: 31 an array element (a scalar subob ject) an array section (an array subob ject) a structure component (a scalar or an array subob ject) 32 a substring (a scalar subob ject) 2.4.3.1.1 Variable 33 A variable may have a value and may be defined and redefined during execution of a program. 34 A named lo cal variable of the scoping unit of a module, submodule, main program, or subprogram, is a 35 named variable that is a local entity of the scoping unit, is not a dummy argument, is not in COMMON, 36 19 J3/06-007 WORKING DRAFT 2006/07/11 does not have the BIND attribute, and is not accessed by use or host association. A named local variable 1 of a BLOCK construct is a named variable that is declared in that construct, is not in COMMON, does 2 not have the BIND attribute, and is not accessed by use association. A subob ject of a named local 3 variable is also a local variable. 4 2.4.3.1.2 Constant 5 A constant has a value and cannot become defined, redefined, or undefined during execution of a 6 program. A constant with a name is called a named constant and has the PARAMETER attribute 7 (5.3.12). A constant without a name is called a literal constant (4.4). 8 2.4.3.1.3 Sub object of a constant 9 A sub ob ject of a constant is a portion of a constant. The portion referenced may depend on the 10 value of a variable. 11 NOTE 2.7 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 subob ject of the constant DIGITS. 2.4.3.2 Expression 12 An expression (7.1) produces a data entity when evaluated. An expression represents either a data 13 reference or a computation; it is formed from operands, operators, and parentheses. The type, type 14 parameters, value, and rank of an expression result are determined by the rules in Clause 7. 15 2.4.3.3 Function reference 16 A function reference (12.5.2) produces a data entity when the function is executed during expression 17 evaluation. The type, type parameters, and rank of a function result are determined by the interface of 18 the function (12.3.2). The value of a function result is determined by execution of the function. 19 2.4.4 Scalar 20 A scalar is a datum that is not an array. Scalars may be of any type. 21 NOTE 2.8 A structure is scalar even if it has arrays as components. The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. 22 2.4.5 Array 23 An array is a set of scalar data, all of the same type and type parameters, whose individual elements 24 are arranged in a rectangular pattern. An array element is one of the individual elements in the array 25 and is a scalar. An array section is a subset of the elements of an array and is itself an array. 26 20 2006/07/11 WORKING DRAFT J3/06-007 An array may have up to fifteen dimensions, and any extent (number of elements) in any dimension. 1 The rank of the array is the number of dimensions; its size is the total number of elements, which is 2 equal to the product of the extents. An array may have zero size. The shap e of an array is determined 3 by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 4 are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 5 declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 6 vary during execution. 7 Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 8 intrinsic operation defined for scalar ob jects may be applied to conformable ob jects. Such operations 9 are performed element-by-element to produce a resultant array conformable with the array operands. 10 Element-by-element operation means corresponding elements of the operand arrays are involved in a 11 scalar operation to produce the corresponding element in the result array. Such an operation is described 12 as elemental. 13 NOTE 2.9 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. A rank-one array may be constructed from scalars and other arrays and may be reshaped into any 14 allowable array shape (4.7). 15 Arrays may be of any type and are described further in 6.2. 16 2.4.6 Co-array 17 A co-array is a data entity that is declared with nonzero co-rank and may be referenced or defined by 18 any image. It may be a scalar or an array. For each co-array on an image, there is a corresponding 19 co-array with the same type, type parameters, and bounds on every other image. The co-array on any 20 image may be accessed by using co-subscript s. On its own image, a co-array may be accessed without 21 use of co-subscripts. 22 The co-rank of a co-array is the number of co-dimensions. The co-size of a co-array is always equal to 23 the number of images. 24 J3 internal note Unresolved Technical Issue 7 The term "co-dimension" is not defined. It might be better to define co-array in terms of being a rectangular set of ob jects in co-rank "co-dimensions" etc., similarly to how we define arrays. An ob ject whose designator includes an image-selector is a co-indexed ob ject. For each co-array, 25 co-subscripts are mapped to image indices in the same way as Fortran array subscripts are mapped to 26 the position of the array element in array element order (6.2.2.2). 27 Intrinsic procedures are provided for mapping between an image index and a list of co-subscripts. 28 NOTE 2.10 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. 21 J3/06-007 WORKING DRAFT 2006/07/11 2.4.7 Pointer 1 A data p ointer is a data entity that has the POINTER attribute. A pro cedure p ointer is a procedure 2 entity that has the POINTER attribute. A p ointer is either a data pointer or a procedure pointer. 3 A pointer is asso ciated with a target by pointer assignment (7.4.2). A data pointer may also be 4 associated with a target by allocation (6.3.1). A pointer is disasso ciated following execution of a 5 NULLIFY statement, following pointer assignment with a disassociated pointer, by default initialization, 6 or by explicit initialization. A data pointer may also be disassociated by execution of a DEALLOCATE 7 statement. A disassociated pointer is not associated with a target (16.5.2). 8 A pointer that is not associated shall not be referenced or defined. 9 If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 10 associated with a target. 11 2.4.8 Storage 12 Many of the facilities of this standard make no assumptions about the physical storage characteristics of 13 data ob jects. However, program units that include storage association dependent features shall observe 14 the storage restrictions described in 16.5.3. 15 2.5 Fundamental terms 16 For the purposes of this standard, the definitions of terms in this subclause apply. 17 2.5.1 Name and designator 18 A name is used to identify a program constituent, such as a program unit, named variable, named 19 constant, dummy argument, or derived type. The rules governing the construction of names are given 20 in 3.2.1. A designator is a name followed by zero or more component selectors, complex part selectors, 21 array section selectors, array element selectors, image selectors, and substring selectors. 22 An ob ject designator is a designator for a data ob ject. A pro cedure designator is a designator for 23 a procedure. 24 NOTE 2.11 An ob ject name is a special case of an ob ject designator. 2.5.2 Keyword 25 The term keyword is used in two ways. 26 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 27 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 28 such keywords appear literally. In descriptive text, this meaning is denoted by the term 29 "keyword" without any modifier. Examples of statement keywords are: IF, READ, UNIT, 30 KIND, and INTEGER. 31 (2) It is used to denote names that identify items in a list. In actual argument lists, type 32 parameter lists, and structure constructors, items may be identified by a preceding keyword = 33 rather than their position within the list. An argument keyword is the name of a dummy 34 argument in the interface for the procedure being referenced, a typ e parameter keyword 35 is the name of a type parameter in the type being specified, and a comp onent keyword 36 is the name of a component in a structure constructor. 37 22 2006/07/11 WORKING DRAFT J3/06-007 R215 keyword is name 1 NOTE 2.12 Use of keywords rather than position to identify items in a list can make such lists more readable and allows them to be reordered. This facilitates specification of a list in cases where optional items are omitted. 2.5.3 Association 2 Asso ciation is name association (16.5.1), pointer association (16.5.2), storage association (16.5.3), 3 or inheritance association (16.5.4). Name association is argument association, host association, use 4 association, linkage association, or construct association. 5 Storage association causes different entities to use the same storage. Any association permits an entity 6 to be identified by different names in the same scoping unit or by the same name or different names in 7 different scoping units. 8 2.5.4 Declaration 9 The term declaration refers to the specification of attributes for various program entities. Often this 10 involves specifying the type of a named data ob ject or specifying the shape of a named array ob ject. 11 2.5.5 Definition 12 The term definition is used in two ways. 13 (1) It refers to the specification of derived types and procedures. 14 (2) When an ob ject is given a valid value during program execution, it is said to become 15 defined. This is often accomplished by execution of an assignment or input statement. 16 When a variable does not have a predictable value, it is said to be undefined. Similarly, 17 when a pointer is associated with a target or nullified, its pointer association status is said 18 to become defined. When the association status of a pointer is not predictable, its pointer 19 association status is said to be undefined. 20 Clause 16 describes the ways in which variables may become defined and undefined. 21 2.5.6 Reference 22 A data ob ject reference is the appearance of the data ob ject designator in a context requiring its 23 value at that point during execution. 24 A pro cedure reference is the appearance of the procedure designator, operator symbol, or assignment 25 symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined 26 derived-type input/output (10.7.6) or derived-type finalization (4.5.6.2) is also a procedure reference. 27 The appearance of a data ob ject designator or procedure designator in an actual argument list does not 28 constitute a reference to that data ob ject or procedure unless such a reference is necessary to complete 29 the specification of the actual argument. 30 A mo dule reference is the appearance of a module name in a USE statement (11.2.1). 31 2.5.7 Intrinsic 32 The qualifier intrinsic has two meanings. 33 23 J3/06-007 WORKING DRAFT 2006/07/11 (1) The qualifier signifies that the term to which it is applied is defined in this standard. In- 1 trinsic applies to types, procedures, modules, assignment statements, and operators. All 2 intrinsic types, procedures, assignments, and operators may be used in any scoping unit 3 without further definition or specification. Intrinsic modules may be accessed by use as- 4 sociation. Intrinsic procedures and modules defined in this standard are called standard 5 intrinsic procedures and standard intrinsic modules, respectively. 6 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 7 defined in this standard (13, 14, 15.2). Such procedures and modules are called nonstandard 8 intrinsic procedures and nonstandard intrinsic modules, respectively. 9 2.5.8 Operator 10 An op erator specifies a computation involving one (unary operator) or two (binary operator) data values 11 (op erands). This standard specifies a number of intrinsic operators (e.g., the arithmetic operators +, ­, 12 *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). 13 Additional operators may be defined within a program (7.1.3). 14 2.5.9 Sequence 15 A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n. The 16 number of elements in the sequence is n. A sequence may be empty, in which case it contains no elements. 17 The elements of a nonempty sequence are referred to as the first element, second element, etc. The 18 nth element, where n is the number of elements in the sequence, is called the last element. An empty 19 sequence has no first or last element. 20 2.5.10 Companion processors 21 A processor has one or more companion processors. A companion pro cessor is a processor-dependent 22 mechanism by which global data and procedures may be referenced or defined. A companion processor 23 may be a mechanism that references and defines such entities by a means other than Fortran (12.6.3), 24 it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 25 one companion processor, the means by which the Fortran processor selects among them are processor 26 dependent. 27 If a procedure is defined by means of a companion processor that is not the Fortran processor itself, 28 this standard refers to the C function that defines the procedure, although the procedure need not be 29 defined by means of the C programming language. 30 NOTE 2.13 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. 24 2006/07/11 WORKING DRAFT J3/06-007 3 Characters, lexical tokens, and source form 1 This clause describes the Fortran character set and the various lexical tokens such as names and operators. 2 This clause also describes the rules for the forms that Fortran programs may take. 3 3.1 Processor character set 4 The processor character set is processor dependent. Each character in a processor character set is either 5 a control character or a graphic character. The set of graphics characters is further divided into 6 letters (3.1.1), digits (3.1.2), underscore (3.1.3), special characters (3.1.4), and other characters (3.1.5). 7 The letters, digits, underscore, and special characters make up the Fortran character set. 8 R301 character is alphanumeric-character 9 or special-character 10 R302 alphanumeric-character is letter 11 or digit 12 or underscore 13 Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 14 3.1.3, and 3.1.4. However, the style of any graphic is not specified. 15 The default character type shall support a character set that includes the Fortran character set. By sup- 16 plying nondefault character types, the processor may support additional character sets. The characters 17 available in the ASCII and ISO 10646 character sets are specified by ISO/IEC 646:1991 (International 18 Reference Version) and ISO/IEC 10646-1:2000 UCS-4, respectively; the characters available in other non- 19 default character types are not specified by this standard, except that one character in each nondefault 20 character type shall be designated as a blank character to be used as a padding character. 21 3.1.1 Letters 22 The twenty-six letters are: 23 ABCDEFGHIJKLMNOPQRSTUVWXYZ 24 The set of letters defines the syntactic class letter . The processor character set shall include lower- 25 case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in 26 program units except in a character context (3.3). 27 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 28 The ten digits are: 29 25 J3/06-007 WORKING DRAFT 2006/07/11 0123456789 1 The ten digits define the syntactic class digit . 2 3.1.3 Underscore 3 R303 underscore is 4 The underscore may be used as a significant character in a name. 5 3.1.4 Sp ecial characters 6 The sp ecial characters are shown in Table 3.1. 7 Table 3.1: Sp ecial characters Character Name of character Character Name of character Blank ; Semicolon = Equals ! Exclamation point + Plus Quotation mark or quote " - Minus % Percent * Asterisk & Ampersand / Slash Tilde ~ Backslash < Less than \ ( Left parenthesis > Greater than ) Right parenthesis ? Question mark [ Left square bracket Apostrophe ' ] Right square bracket ` Grave accent { Left curly bracket Circumflex accent ^ } | Right curly bracket Vertical line , Comma $ Currency symbol . Decimal point or period Number sign # : Colon @ Commercial at The special characters define the syntactic class special-character . Some of the special characters are 8 used for operator symbols, bracketing, and various forms of separating and delimiting other lexical 9 tokens. 10 3.1.5 Other characters 11 Additional characters may be representable in the processor, but may appear only in comments (3.3.1.1, 12 3.3.2.1), character constants (4.4.5), input/output records (9.1.1), and character string edit descriptors 13 (10.3.2). 14 3.2 Low-level syntax 15 The low-level syntax describes the fundamental lexical tokens of a program unit. Lexical tokens are 16 sequences of characters that constitute the building blocks of a program. They are keywords, names, 17 literal constants other than complex literal constants, operators, labels, delimiters, comma, =, =>, :, ::, 18 ;, and %. 19 26 2006/07/11 WORKING DRAFT J3/06-007 3.2.1 Names 1 Names are used for various entities such as variables, program units, dummy arguments, named con- 2 stants, and derived types. 3 R304 name is letter [ alphanumeric-character ] ... 4 C301 (R304) The maximum length of a name is 63 characters. 5 NOTE 3.2 Examples of names: A1 NAME LENGTH (single underscore) SPREAD OUT (two consecutive underscores) TRAILER (trailing underscore) NOTE 3.3 The word "name" always denotes this particular syntactic form. The word "identifier" is used where entities may be identified by other syntactic forms or by values; its particular meaning depends on the context in which it is used. 3.2.2 Constants 6 R305 constant is literal-constant 7 or named-constant 8 R306 literal-constant is int-literal-constant 9 or real-literal-constant 10 or complex-literal-constant 11 or logical-literal-constant 12 or char-literal-constant 13 or boz-literal-constant 14 R307 named-constant is name 15 R308 int-constant is constant 16 C302 (R308) int-constant shall be of type integer. 17 R309 char-constant is constant 18 C303 (R309) char-constant shall be of type character. 19 3.2.3 Operators 20 R310 intrinsic-operator is power-op 21 or mult-op 22 or add-op 23 or concat-op 24 or rel-op 25 or not-op 26 or and-op 27 or or-op 28 or equiv-op 29 R707 power-op is ** 30 R708 mult-op is * 31 27 J3/06-007 WORKING DRAFT 2006/07/11 or / 1 R709 add-op is + 2 or ­ 3 R711 concat-op is // 4 R713 rel-op is .EQ. 5 or .NE. 6 or .LT. 7 or .LE. 8 or .GT. 9 or .GE. 10 or == 11 or /= 12 or < 13 or <= 14 or > 15 or >= 16 R718 not-op is .NOT. 17 R719 and-op is .AND. 18 R720 or-op is .OR. 19 R721 equiv-op is .EQV. 20 or .NEQV. 21 or .XOR. 22 R311 defined-operator is defined-unary-op 23 or defined-binary-op 24 or extended-intrinsic-op 25 R703 defined-unary-op is . letter [ letter ] ... . 26 R723 defined-binary-op is . letter [ letter ] ... . 27 R312 extended-intrinsic-op is intrinsic-operator 28 3.2.4 Statement lab els 29 A statement lab el provides a means of referring to an individual statement. 30 R313 label is digit [ digit [ digit [ digit [ digit ] ] ] ] 31 C304 (R313) At least one digit in a label shall be nonzero. 32 If a statement is labeled, the statement shall contain a nonblank character. The same statement label 33 shall not be given to more than one statement in a scoping unit. Leading zeros are not significant in 34 distinguishing between statement labels. 35 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. 28 2006/07/11 WORKING DRAFT J3/06-007 Any statement may have a statement label, but the labels are used only in the following ways. 1 (1) The label on a branch target statement (8.2) is used to identify that statement as the 2 possible destination of a branch. 3 (2) The label on a FORMAT statement (10.2.1) is used to identify that statement as the format 4 specification for a data transfer statement (9.5). 5 (3) In some forms of the DO construct (8.1.7), the range of the DO construct is identified by 6 the label on the last statement in that range. 7 3.2.5 Delimiters 8 Delimiters are used to enclose syntactic lists. The following pairs are delimiters: 9 ( ... ) 10 / ... / 11 [ ... ] 12 (/ ... /) 13 3.3 Source form 14 A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, 15 and INCLUDE lines. A line is a sequence of zero or more characters. Lines following a program unit 16 END statement are not part of that program unit. A Fortran statement is a sequence of one or more 17 complete or partial lines. 18 A character context means characters within a character literal constant (4.4.5) or within a character 19 string edit descriptor (10.3.2). 20 A comment may contain any character that may occur in any character context. 21 There are two source forms: free and fixed. Free form and fixed form shall not be mixed in the same program unit. 22 23 The means for sp ecifying the source form of a program unit are pro cessor dep endent. 3.3.1 Free source form 24 In free source form there are no restrictions on where a statement (or portion of a statement) may 25 appear within a line. A line may contain zero characters. If a line consists entirely of characters of 26 default kind (4.4.5), it may contain at most 132 characters. If a line contains any character that is not 27 of default kind, the maximum number of characters allowed on the line is processor dependent. 28 Blank characters shall not appear within lexical tokens other than in a character context or in a format 29 specification. Blanks may be inserted freely between tokens to improve readability; for example, blanks 30 may occur between the tokens that form a complex literal constant. A sequence of blank characters 31 outside of a character context is equivalent to a single blank character. 32 A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, 33 or labels. 34 NOTE 3.5 For example, the blanks after REAL, READ, 30, and DO are required in the following: REAL X 29 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 3.5 (cont.) READ 10 30 DO K=1,3 One or more blanks shall be used to separate adjacent keywords except in the following cases, where 1 blanks are optional: 2 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 3.3.1.1 Free form commentary 3 The character "!" initiates a comment except where it appears within a character context. The 4 comment extends to the end of the line. If the first nonblank character on a line is an "!", the line 5 is a comment line. Lines containing only blanks or containing no characters are also comment lines. 6 Comments may appear anywhere in a program unit and may precede the first statement of a program 7 unit or may follow the last statement of a program unit. Comments have no effect on the interpretation 8 of the program unit. 9 NOTE 3.6 The standard does not restrict the number of consecutive comment lines. 3.3.1.2 Free form statement continuation 10 The character "&" is used to indicate that the current statement is continued on the next line that is not 11 a comment line. Comment lines cannot be continued; an "&" in a comment has no effect. Comments may 12 occur within a continued statement. When used for continuation, the "&" is not part of the statement. 13 No line shall contain a single "&" as the only nonblank character or as the only nonblank character 14 before an "!" that initiates a comment. 15 If a noncharacter context is to be continued, an "&" shall be the last nonblank character on the line, 16 or the last nonblank character before an "!". There shall be a later line that is not a comment; the 17 statement is continued on the next such line. If the first nonblank character on that line is an "&", the 18 statement continues at the next character position following that "&"; otherwise, it continues with the 19 first character position of that line. 20 If a lexical token is split across the end of a line, the first nonblank character on the first following 21 noncomment line shall be an "&" immediately followed by the successive characters of the split token. 22 30 2006/07/11 WORKING DRAFT J3/06-007 If a character context is to be continued, an "&" shall be the last nonblank character on the line and 1 shall not be followed by commentary. There shall be a later line that is not a comment; an "&" shall be 2 the first nonblank character on the next such line and the statement continues with the next character 3 following that "&". 4 3.3.1.3 Free form statement termination 5 If a statement is not continued, a comment or the end of the line terminates the statement. 6 A statement may alternatively be terminated by a ";" character that appears other than in a character 7 context or in a comment. The ";" is not part of the statement. After a ";" terminator, another statement 8 may appear on the same line, or begin on that line and be continued. A sequence consisting only of zero 9 or more blanks and one or more ";" terminators, in any order, is equivalent to a single ";" terminator. 10 3.3.1.4 Free form statements 11 A label may precede any statement not forming part of another statement. 12 NOTE 3.7 No Fortran statement begins with a digit. A statement shall not have more than 255 continuation lines. 13 3.3.2 Fixed source form 14 15 In fixed source form, there are restrictions on where a statement may app ear within a line. If a source line contains only 16 default kind characters, it shall contain exactly 72 characters; otherwise, its maximum numb er of characters is pro cessor 17 dependent. 18 Except in a character context, blanks are insignificant and may b e used freely throughout the program. 3.3.2.1 Fixed form commentary 19 20 The character "!" initiates a comment except where it app ears within a character context or in character p osition 6. The 21 comment extends to the end of the line. If the first nonblank character on a line is an "!" in any character p osition other 22 than character p osition 6, the line is a comment line. Lines b eginning with a "C" or "*" in character p osition 1 and lines 23 containing only blanks are also comment lines. Comments may app ear anywhere in a program unit and may precede the 24 first statement of the program unit or may follow the last statement of a program unit. Comments have no effect on the 25 interpretation of the program unit. NOTE 3.8 The standard do es not restrict the numb er of consecutive comment lines. 3.3.2.2 Fixed form statement continuation 26 27 Except within commentary, character p osition 6 is used to indicate continuation. If character position 6 contains a blank 28 or zero, the line is the initial line of a new statement, which b egins in character p osition 7. If character p osition 6 contains 29 any character other than blank or zero, character p ositions 7­72 of the line constitute a continuation of the preceding 30 noncomment line. NOTE 3.9 An "!" or ";" in character p osition 6 is interpreted as a continuation indicator unless it app ears within commentary indicated by a "C" or "*" in character p osition 1 or by an "!" in character positions 1­5. 31 Comment lines cannot be continued. Comment lines may o ccur within a continued statement. 31 J3/06-007 WORKING DRAFT 2006/07/11 3.3.2.3 Fixed form statement termination 1 2 If a statement is not continued, a comment or the end of the line terminates the statement. 3 A statement may alternatively b e terminated by a ";" character that app ears other than in a character context, in a 4 comment, or in character p osition 6. The ";" is not part of the statement. After a ";" terminator, another statement may 5 b egin on the same line, or b egin on that line and be continued. A ";" shall not app ear as the first nonblank character 6 on an initial line. A sequence consisting only of zero or more blanks and one or more ";" terminators, in any order, is 7 equivalent to a single ";" terminator. 3.3.2.4 Fixed form statements 8 9 A lab el, if present, shall occur in character positions 1 through 5 of the first line of a statement; otherwise, p ositions 1 10 through 5 shall b e blank. Blanks may app ear anywhere within a lab el. A statement following a ";" on the same line shall 11 not b e labeled. Character p ositions 1 through 5 of any continuation lines shall b e blank. A statement shall not have more 12 than 255 continuation lines. The program unit END statement shall not b e continued. A statement whose initial line 13 appears to b e a program unit END statement shall not b e continued. 3.4 Including source text 14 Additional text may be incorporated into the source text of a program unit during processing. This is 15 accomplished with the INCLUDE line, which has the form 16 INCLUDE char-literal-constant 17 The char-literal-constant shall not have a kind type parameter value that is a named-constant . 18 An INCLUDE line is not a Fortran statement. 19 An INCLUDE line shall appear on a single source line where a statement may appear; it shall be the 20 only nonblank text on this line other than an optional trailing comment. Thus, a statement label is not 21 allowed. 22 The effect of the INCLUDE line is as if the referenced source text physically replaced the INCLUDE line 23 prior to program processing. Included text may contain any source text, including additional INCLUDE 24 lines; such nested INCLUDE lines are similarly replaced with the specified source text. The maximum 25 depth of nesting of any nested INCLUDE lines is processor dependent. Inclusion of the source text 26 referenced by an INCLUDE line shall not, at any level of nesting, result in inclusion of the same source 27 text. 28 When an INCLUDE line is resolved, the first included statement line shall not be a continuation line 29 and the last included statement line shall not be continued. 30 The interpretation of char-literal-constant is processor dependent. An example of a possible valid inter- 31 pretation is that char-literal-constant is the name of a file that contains the source text to be included. 32 NOTE 3.10 In some circumstances, for example where source co de is maintained in an INCLUDE file for use in programs whose source form might b e either fixed or free, observing the following rules allows the co de to b e used with either source form: (1) Confine statement lab els to character p ositions 1 to 5 and statements to character p ositions 7 to 72; (2) Treat blanks as b eing significant; (3) Use only the exclamation mark (!) to indicate a comment, but do not start the comment in character p osition 6; 32 2006/07/11 WORKING DRAFT J3/06-007 NOTE 3.10 (cont.) (4) For continued statements, place an amp ersand (&) in b oth character p osition 73 of a continued line and character p osition 6 of a continuing line. 3.5 Macro processing 1 3.5.1 Macro definition 2 A macro definition defines a macro. A defined macro shall only be referenced by a USE statement, 3 IMPORT statement, or macro expansion statement. A defined macro shall not be redefined. 4 R314 macro-definition is define-macro-stmt 5 [ macro-declaration-stmt ] ... 6 macro-body-block 7 end-macro-stmt 8 R315 define-macro-stmt is DEFINE MACRO [ , macro-attribute -list ] :: macro-name 9 [ ( [ macro-dummy-arg-name-list ] ) ] 10 C305 (R315) A macro-dummy-arg-name shall not appear more than once in a macro-dummy-arg- 11 name-list . 12 R316 macro-attribute is access-spec 13 The DEFINE MACRO statement begins the definition of the macro macro-name . Appearance of an 14 access-spec in the DEFINE MACRO statement explicitly gives the macro the specified attribute. Each 15 macro-dummy-arg-name is a macro dummy argument. A macro dummy argument is a macro local 16 variable. 17 R317 macro-declaration-stmt is macro-type-declaration-stmt 18 or macro-optional-decl-stmt 19 R318 macro-type-declaration-stmt is MACRO macro-type-spec :: macro-local-variable-name-list 20 R319 macro-optional-decl-stmt is MACRO OPTIONAL :: macro-dummy-arg-name-list 21 R320 macro-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] 22 C306 (R318) A macro-local-variable-name shall not be the same as the name of a dummy argument 23 of the macro being defined. 24 C307 (R319) A macro-dummy-arg-name shall be the name of a dummy argument of the macro being 25 defined. 26 C308 (R320) If macro-expr appears, when the macro is expanded it shall be of type integer, and have 27 a non-negative value that specifies a representation method that exists on the processor. 28 A macro type declaration statement specifies that the named entities are macro local variables of the 29 specified type. If the kind is not specified, they are of default kind. A macro local variable that is not a 30 macro dummy argument shall appear in a macro type declaration statement. 31 R321 macro-body-block is [ macro-body-construct ] ... 32 R322 macro-body-construct is macro-definition 33 or expand-stmt 34 33 J3/06-007 WORKING DRAFT 2006/07/11 or macro-body-stmt 1 or macro-do-construct 2 or macro-if-construct 3 C309 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. 5 R323 macro-do-construct is macro-do-stmt 6 macro-body-block 7 macro-end-do-stmt 8 R324 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , 9 macro-do-limit [ , macro-do-limit ] 10 C310 (R324) A macro-do-variable-name shall be a local variable of the macro being defined, and shall 11 not be a macro dummy argument. 12 R325 macro-do-limit is macro-expr 13 C311 (R325) A macro-do-limit shall expand to an expression of type integer. 14 R326 macro-end-do-stmt is MACRO END DO 15 A macro DO construct iterates the expansion of its enclosed macro body block at macro expansion time. 16 The number of iterations is determined by the values of the expanded macro expressions in the MACRO 17 DO statement. 18 R327 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 25 R328 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN 26 R329 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN 27 R330 macro-else-stmt is MACRO ELSE 28 R331 macro-end-if-stmt is MACRO END IF 29 R332 macro-condition is macro-expr 30 C312 (R332) A macro condition shall expand to an expression of type logical. 31 A macro IF construct provides conditional expansion of its enclosed macro body blocks at macro expan- 32 sion time. Whether the enclosed macro body blocks contribute to the macro expansion is determined by 33 the logical value of the expanded macro expressions in the MACRO IF and MACRO ELSE IF statements. 34 R333 macro-body-stmt is result-token [ result-token ] ... [ && ] 35 C313 (R333) The first result-token shall not be MACRO unless the second result-token is not a keyword 36 or name. 37 R334 result-token is token [ %% token ] ... 38 C314 (R334) The concatenated textual token s in a result-token shall have the form of a lexical token. 39 34 2006/07/11 WORKING DRAFT J3/06-007 R335 token is any lexical token including labels, keywords, and semi-colon. 1 C315 && shall not appear in the last macro-body-stmt of a macro definition. 2 C316 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. 3 R336 end-macro-stmt is END MACRO [ macro-name ] 4 C317 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name 5 in the DEFINE MACRO statement. 6 R337 macro-expr is basic-token-sequence 7 C318 (R337) A macro-expr shall expand to a scalar initialization expression. 8 Macro expressions are used to control the behavior of the MACRO DO and MACRO IF constructs when 9 a macro is being expanded. The type, type parameters, and value of a macro expression are determined 10 when that macro expression is expanded. 11 3.5.2 Macro expansion 12 3.5.2.1 General 13 Macro expansion is the conceptual replacement of the EXPAND statement with the Fortran statements 14 that it produces. The semantics of an EXPAND statement are those of the Fortran statements that it 15 produces. It is recommended that a processor be capable of displaying the results of macro expansion. It 16 is processor-dependent whether comments in a macro definition appear in the expansion. It is processor- 17 dependent whether continuations and consecutive blanks that are not part of a token are preserved. 18 The process of macro expansion produces Fortran statements consisting of tokens. The combined length 19 of the tokens for a single statement, plus inter-token spacing, shall not be greater than 33280 characters. 20 If a statement contains any character that is not of default kind, the maximum number of characters 21 allowed is processor dependent. 22 NOTE 3.11 This length is so that the result of macro expansion can be formed into valid free form Fortran source, consisting of an initial line and 255 continuation lines, times 130 which allows for beginning and ending continuation characters (&) on each line. Also, breaking tokens across continuation lines in macro definitions and in EXPAND statements does not affect macro expansion: it is as if they were joined together before replacement. R338 expand-stmt is EXPAND macro-name [ ( macro-actual-arg -list ) ] 23 C319 (R338) macro-name shall be the name of a macro that was previously defined or accessed via 24 use or host association. 25 C320 (R338) The macro shall expand to a sequence or zero or more complete Fortran statements. 26 C321 (R338) The statements produced by a macro expansion shall conform to the syntax rules and 27 constraints as if they physically replaced the EXPAND statement prior to program processing. 28 C322 (R338) The statements produced by a macro expansion shall not include a statement which 29 ends the scoping unit containing the EXPAND statement. 30 C323 (R338) If a macro expansion produces a statement which begins a new scoping unit, it shall also 31 35 J3/06-007 WORKING DRAFT 2006/07/11 produce a statement which ends that scoping unit. 1 C324 (R338) If the EXPAND statement appears as the action-stmt of an if-stmt , it shall expand to 2 exactly one action-stmt that is not an if-stmt , end-program-stmt , end-function-stmt , or end- 3 subroutine-stmt . 4 5 C325 (R338) If the EXPAND statement app ears as a do-term-action-stmt , it shall expand to exactly one action-stmt 6 that is not a continue-stmt , a goto-stmt , a return-stmt , a stop-stmt , an exit-stmt , a cycle-stmt , an end-function-stmt , an 7 end-subroutine-stmt , an end-program-stmt , or an arithmetic-if-stmt . C326 (R338) If the EXPAND statement has a label, the expansion of the macro shall produce at least 8 one statement, and the first statement produced shall not have a label. 9 C327 (R338) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- 10 gument. 11 C328 (R338) At most one macro-actual-arg shall appear corresponding to each optional macro dummy 12 argument. 13 Expansion of a macro is performed by the EXPAND statement. If the EXPAND statement has a label, 14 the label is interpreted after expansion as belonging to the first statement of the expansion. 15 R339 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value 16 C329 (R339) macro-dummy-name shall be the name of a macro dummy argument of the macro being 17 expanded. 18 C330 (R338) The macro-dummy-name = shall not be omitted unless it has been omitted from each 19 preceding macro-actual-arg in the expand-stmt . 20 R340 macro-actual-arg-value is basic-token-sequence 21 R341 basic-token-sequence is basic-token 22 or [ basic-token-sequence ] nested-token-sequence 23 [ basic-token-sequence ] 24 or basic-token basic-token-sequence 25 R342 basic-token is any lexical token except comma, parentheses, array 26 constructor delimiters, and semi-colon. 27 R343 nested-token-sequence is ( [ arg-token ] ... ) 28 or (/ [ arg-token ] ... /) 29 or lbracket [ arg-token ] ... rbracket 30 R344 arg-token is basic-token 31 or , 32 Macro expansion processes any macro declarations of the macro definition, and then expands its macro 33 body block. Any macro expressions in macro-type-spec s are evaluated and the kinds of the macro 34 variables thereby declared are determined for that particular expansion. 35 Macro expansion of a macro body block processes each macro body construct of the macro body block 36 in turn, starting with the first macro body construct and ending with the last macro body construct. 37 Expansion of a statement within a macro body construct consists of three steps: 38 (1) token replacement, 39 (2) token concatenation, and 40 36 2006/07/11 WORKING DRAFT J3/06-007 (3) statement-dependent processing. 1 Token replacement replaces each token of a macro body statement or macro expression that is a macro 2 local variable with the value of that variable. In a macro expression, a reference to the PRESENT 3 intrinsic function with a macro dummy argument name as its actual argument is replaced by the token 4 .TRUE. if the specified macro dummy argument is present, and the token .FALSE. if the specified macro 5 dummy argument is not present. Otherwise, the value of a macro dummy argument that is present is 6 the sequence of tokens from the corresponding actual argument. The value of a macro dummy argument 7 that is not present is a zero-length token sequence. The value of an integer macro variable is its minimal- 8 length decimal representation; if negative this will produce two tokens, a minus sign and an unsigned 9 integer literal constant. 10 Token concatenation is performed with the %% operator, which is only permitted inside a macro defini- 11 tion. After expansion, each sequence of single tokens separated by %% operators is replaced by a single 12 token consisting of the concatenated text of the sequence of tokens. The result of a concatenation shall 13 be a valid Fortran token, and may be a different kind of token from one or more of the original sequence 14 of tokens. 15 NOTE 3.12 For example, the sequence 3 %% .14159 %% E %% + %% 0 forms the single real literal constant 3.14159E+0. 3.5.2.2 Macro b o dy statements 16 Processing a macro body statement produces a whole or partial Fortran statement. A macro body 17 statement that is either the first macro body statement processed by this macro expansion or the next 18 macro body statement processed after a macro body statement that did not end with the continuation 19 generation operator &&, is an initial macro body statement. The next macro body statement processed 20 after a macro body statement that ends with && is a continuation macro body statement. An initial 21 macro body statement that does not end with && produces a whole Fortran statement consisting of its 22 token sequence. All other macro body statements produce partial Fortran statements, and the sequence 23 of tokens starting with those produced by the initial macro body statement and appending the tokens 24 produced by each subsequent continuation macro body statement form a Fortran statement. The && 25 operators are not included in the token sequence. 26 3.5.2.3 The macro DO construct 27 The macro DO construct specifies the repeated expansion of a macro body block. Processing the macro 28 DO statement performs the following steps in sequence. 29 (1) The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter 30 m3 are of type integer with the same kind type parameter as the macro-do-variable-name . 31 Their values are given by the first macro-expr , the second macro-expr , and the third macro- 32 expr of the macro-do-stmt respectively, including, if necessary, conversion to the kind type 33 parameter of the macro-do-variable-name according to the rules for numeric conversion 34 (Table 7.11). If the third macro-expr does not appear, m3 has the value 1. The value of m3 35 shall not be zero. 36 (2) The macro DO variable becomes defined with the value of the initial parameter m1 . 37 The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , (3) 38 unless that value is negative, in which case the iteration count is 0. 39 37 J3/06-007 WORKING DRAFT 2006/07/11 After this, the following steps are performed repeatedly until processing of the macro DO construct is 1 finished. 2 (1) The iteration count is tested. If it is zero, the loop terminates and processing of the macro 3 DO construct is finished. 4 (2) If the iteration count is nonzero, the macro body block of the macro DO construct is 5 expanded. 6 (3) The iteration count is decremented by one. The macro DO variable is incremented by the 7 value of the incrementation parameter m3 . 8 3.5.2.4 The MACRO IF construct 9 The MACRO IF construct provides conditional expansion of macro body blocks. At most one of the 10 macro body blocks of the macro IF construct is expanded. The macro conditions of the construct are 11 evaluated in order until a true value is found or a MACRO ELSE or MACRO END IF statement is 12 encountered. If a true value or a MACRO ELSE statement is found, the macro body block immediately 13 following is expanded and this completes the processing of the construct. If none of the evaluated 14 conditions is true and there is no MACRO ELSE statement, the processing of the construct is completed 15 without expanding any of the macro body blocks within the construct. 16 3.5.2.5 Macro definitions 17 Processing a macro definition defines a new macro. If a macro definition is produced by a macro expan- 18 sion, all of the statements of the produced macro definition have token replacement and concatenation 19 applied to them before the new macro is defined. 20 3.5.2.6 Examples 21 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 38 2006/07/11 WORKING DRAFT J3/06-007 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) DO i=1,count EXPAND operation(i) 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) ... READ *,a(17) result(17) = process(a(17)) IF (17>1) PRINT *,'difference =',result(17)-result(17-1) NOTE 3.15 Using the ability to evaluate initialization expressions under macro control and test them, one can create interfaces and procedures for all kinds of a type, for example: DEFINE MACRO :: i_square_procs() MACRO INTEGER i MACRO DO i=1,1000 MACRO IF (SELECTED_INT_KIND(i)>=0 .AND. (i==1 .OR. SELECTED_INT_KIND(i)/=SELECTED_INT_KIND(i-1))) THEN FUNCTION i_square_range_%%i(a) RESULT(r) INTEGER(SELECTED_INT_KIND(i)) a,r r = a**2 END FUNCTION MACRO END IF MACRO END DO END MACRO 39 J3/06-007 WORKING DRAFT 2006/07/11 40 2006/07/11 WORKING DRAFT J3/06-007 4 Typ es 1 4.1 The concept of typ e 2 Fortran provides an abstract means whereby data may be categorized without relying on a particular 3 physical representation. This abstract means is the concept of type. 4 A type has a name, a set of valid values, a means to denote such values (constants), and a set of 5 operations to manipulate the values. 6 A type is either an intrinsic type or a derived type. 7 This part of ISO/IEC 1539 defines six intrinsic types: integer, real, complex, character, logical, and bits. 8 A derived type is one that is defined by a derived-type definition (4.5.2) or by an intrinsic module. It 9 shall be used only where it is accessible (4.5.2.2). An intrinsic type is always accessible. 10 4.1.1 Set of values 11 For each type, there is a set of valid values. The set of valid values may be completely determined, 12 as is the case for logical and bits, or may be determined by a processor-dependent method, as is the 13 case for integer, character, and real. For complex, the set of valid values consists of the set of all the 14 combinations of the values of the individual components. For derived types, the set of valid values is as 15 defined in 4.5.8. 16 4.1.2 Constants 17 The syntax for literal constants of each intrinsic type is specified in 4.4. 18 The syntax for denoting a value indicates the type, type parameters, and the particular value. 19 A constant value may be given a name (5.3.12, 5.4.10). 20 A structure constructor (4.5.10) may be used to construct a constant value of derived type from an 21 appropriate sequence of initialization expressions (7.1.7). Such a constant value is considered to be a 22 scalar even though the value may have components that are arrays. 23 4.1.3 Operations 24 For each of the intrinsic types, a set of operations and corresponding operators is defined intrinsically. 25 These are described in Clause 7. The intrinsic set may be augmented with operations and operators 26 defined by functions with the OPERATOR interface (12.4.2.1). Operator definitions are described in 27 Clauses 7 and 12. 28 For derived types, there are no intrinsic operations. Operations on derived types may be defined by the 29 program (4.5.11). 30 4.2 Typ e parameters 31 A type may be parameterized. In this case, the set of values, the syntax for denoting the values, and 32 the set of operations on the values of the type depend on the values of the parameters. 33 41 J3/06-007 WORKING DRAFT 2006/07/11 The intrinsic types are all parameterized. Derived types may be defined to be parameterized. 1 A type parameter is either a kind type parameter or a length type parameter. 2 A kind type parameter may be used in initialization and specification expressions within the derived-type 3 definition (4.5.2) for the type; it participates in generic resolution (16.3.4). Each of the intrinsic types 4 has a kind type parameter named KIND, which is used to distinguish multiple representations of the 5 intrinsic type. 6 NOTE 4.1 By design, the value of a kind type parameter is 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. Generics are designed to be resolvable at compile time. A length type parameter may be used in specification expressions within the derived-type definition for 7 the type, but it shall not be used in initialization expressions. The intrinsic character type has a length 8 type parameter named LEN, which is the length of the string. 9 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). 10 R401 type-param-value is scalar-int-expr 11 or * 12 or : 13 C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. 14 C402 (R401) A colon may be used as a type-param-value only in the declaration of an entity or 15 component that has the POINTER or ALLOCATABLE attribute. 16 A deferred typ e parameter is a length type parameter whose value can change during execution of 17 the program. A colon as a type-param-value specifies a deferred type parameter. 18 The values of the deferred type parameters of an ob ject are determined by successful execution of an 19 ALLOCATE statement (6.3.1), execution of an intrinsic assignment statement (7.4.1.3), execution of a 20 pointer assignment statement (7.4.2), or by argument association (12.5.1.4). 21 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. An assumed typ e parameter is a length type parameter for a dummy argument that assumes the 22 42 2006/07/11 WORKING DRAFT J3/06-007 type parameter value from the corresponding actual argument; it is also used for an associate name in a 1 SELECT TYPE construct that assumes the type parameter value from the corresponding selector. An 2 asterisk as a type-param-value specifies an assumed type parameter. 3 4.3 Relationship of typ es and values to objects 4 The name of a type serves as a type specifier and may be used to declare ob jects of that type. A 5 declaration specifies the type of a named ob ject. A data ob ject may be declared explicitly or implicitly. 6 Data ob jects may have attributes in addition to their types. Clause 5 describes the way in which a data 7 ob ject is declared and how its type and other attributes are specified. 8 Scalar data of any intrinsic or derived type may be shaped in a rectangular pattern to compose an array 9 of the same type and type parameters. An array ob ject has a type and type parameters just as a scalar 10 ob ject does. 11 A variable is a data ob ject. The type and type parameters of a variable determine which values that 12 variable may take. Assignment provides one means of defining or redefining the value of a variable of 13 any type. Assignment is defined intrinsically for all types where the type, type parameters, and shape 14 of both the variable and the value to be assigned to it are identical. Assignment between ob jects of 15 certain differing intrinsic types, type parameters, and shapes is described in Clause 7. A subroutine and 16 a generic interface (4.5.2, 12.4.2.1) whose generic specifier is ASSIGNMENT (=) define an assignment 17 that is not defined intrinsically or redefine an intrinsic derived-type assignment (7.4.1.4). 18 NOTE 4.4 For example, assignment of a real value to an integer variable is defined intrinsically. The type of a variable determines the operations that may be used to manipulate the variable. 19 4.3.1 Type sp ecifiers and typ e compatibility 20 4.3.1.1 General 21 A type is specified by a typ e sp ecifier. In an executable statement, or in an expression within a nonex- 22 ecutable statement, a type-spec is used. In a nonexecutable statement other than within an expression, 23 a declaration-type-spec is used. 24 R402 type-spec is intrinsic-type-spec 25 or derived-type-spec 26 C403 (R402) The derived-type-spec shall not specify an abstract type (4.5.7). 27 R403 declaration-type-spec is intrinsic-type-spec 28 or TYPE ( intrinsic-type-spec ) 29 or TYPE ( derived-type-spec ) 30 or CLASS ( derived-type-spec ) 31 or CLASS ( * ) 32 C404 (R403) In a declaration-type-spec , every type-param-value that is not a colon or an asterisk shall 33 be a specification-expr . 34 C405 (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify 35 43 J3/06-007 WORKING DRAFT 2006/07/11 an extensible type. 1 C406 (R403) The TYPE(derived-type-spec ) shall not specify an abstract type (4.5.7). 2 C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLO- 3 CATABLE or POINTER attribute. It shall not have the VALUE attribute. 4 An intrinsic-type-spec specifies the named intrinsic type and its type parameter values. A derived-type- 5 spec specifies the named derived type and its type parameter values. 6 NOTE 4.5 A type-spec is used in an array constructor, a SELECT TYPE construct, or an ALLOCATE statement. Elsewhere, a declaration-type-spec is used. 4.3.1.2 TYPE 7 A TYPE type specifier is used to declare entities of an intrinsic or derived type. 8 Where a data entity is declared explicitly using the TYPE type specifier to be of derived type, the 9 specified derived type shall have been defined previously in the scoping unit or be accessible there by 10 use or host association. If the data entity is a function result, the derived type may be specified in 11 the FUNCTION statement provided the derived type is defined within the body of the function or is 12 accessible there by use or host association. If the derived type is specified in the FUNCTION statement 13 and is defined within the body of the function, it is as if the function result variable was declared with 14 that derived type immediately following the derived-type-def of the specified derived type. 15 4.3.1.3 CLASS 16 A p olymorphic entity is a data entity that is able to be of differing types during program execution. 17 The type of a data entity at a particular point during execution of a program is its dynamic typ e. The 18 declared typ e of a data entity is the type that it is declared to have, either explicitly or implicitly. 19 A CLASS type specifier is used to declare polymorphic entities. The declared type of a polymorphic 20 entity is the specified type if the CLASS type specifier contains a type name. 21 An entity declared with the CLASS(*) specifier is an unlimited p olymorphic entity. An unlimited 22 polymorphic entity is not declared to have a type. It is not considered to have the same declared type 23 as any other entity, including another unlimited polymorphic entity. 24 A nonpolymorphic entity is typ e compatible only with entities of the same declared type. A poly- 25 morphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same 26 declared type or any of its extensions. Even though an unlimited polymorphic entity is not considered 27 to have a declared type, it is type compatible with all entities. An entity is said to be type compatible 28 with a type if it is type compatible with entities of that type. 29 Two entities are typ e incompatible if neither is type compatible with the other. 30 A scalar entity of type bits is bits compatible with a scalar entity of type bits, integer, real, complex, 31 or logical if and only if both entities have the same size expressed in bits. 32 J3 internal note Unresolved Technical Issue 14 This might belong in the BITS subclause, or somewhere else. TKR compatibility belongs in c12 (the only place it is used), maybe this should go there? Or maybe split this subclause into one which handles type compabilities of all kinds, and one which handles polymorphism? Anyway, it doesn't have anything to do with CLASS (title of subclause). 44 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 15 This leaves undefined whether entities of other types are bits compatible. Also, this term is often (always?) used as if it were symmetric, but like the other compatibility terms, it is not. It has been suggested that (1) the definition is meant to be symmetric, and (2) complete. Perhaps something like: An entity is bits compatible with another entity if and only if one is of type bits, the other is of type bits, integer, real, complex, or logical, and scalar entities of these types have the same size expressed in bits. It is not entirely obvious that this is correct, since the terms it is modelled on are not symmetric (and it is then used in those terms). The other terms are deliberately assymmetric in part to allow only safe associations, whereas it appears that a substantial point of BITS is perhaps to permit unsafe associations... if that is not the purpose of BITS, then making bits compatible symmetric is almost certainly incorrect. J3 internal note Unresolved Technical Issue 16 It is unclear whether the term "bits compatible" is useful or necessary. It is (mostly?) being used where otherwise we would be saying "type compatible with the same kind type parameters" (so-called TK compatibility). If that really is the only use, we should write the "TK compatibility" definition in one place and use it everywhere; otherwise, this extra complication is likely to lead to questions. (Alternative names for TK compatible are "kind compatible" and "type and kind compatible". The latter is probably the best.) An entity is type, kind, and rank compatible, or TKR compatible, with another entity if both entities 1 have the same rank, and either the first entity is type compatible with the second and the kind type 2 parameters of the first entity have the same values as corresponding kind type parameters of the second, 3 or the two entities are bits compatible. 4 J3 internal note Unresolved Technical Issue 17 This has wrecked generic resolution. It allows ambiguous procedures to be added to a generic set. BAD BAD BAD. Fixable by making bits only match bits in a generic setting, i.e. disable bits compatibility the same way we already disable sequence association. Other fixes possible. Note: If people want to use bits as a poor man's CLASS(*), for purposes of describing some MPI routines in a shorter "clever" way, it is certainly not going to be straight-forward to fix this in any sort of consistent way. Oh, and did I mention that the paragraph is getting harder to read? J3 internal note Unresolved Technical Issue 18 Since the "kind" type parameter of bits is inherently a length type parameter (being the number of bits), it behooves us not to arbitrarily prevent variable length bits in the future. (FWIW, it does not look substantially more difficult to implement variable-length bits than fixed-length ones to me, and without adversely affecting the performance of known-length bit operations too.) This should be borne in mind while considering how to fix generics, for example. 45 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 19 Given that having a "bits dummy" is semi-polymorphic, we should probably make "having a bits dummy argument" require an explicit interface, like we do with polymorphics. Given the arguments (from the same people) that in order to avoid errors in co-arrays, one should have an explicit interface merely to *pass* a co-indexed ob ject as an actual argument, it is hard to avoid the conclusion that it is warranted in this case too. Furthermore, requiring an explicit interface would facilitate future extension should that ever be contemplated. A polymorphic allocatable ob ject may be allocated to be of any type with which it is type compatible. 1 A polymorphic pointer or dummy argument may, during program execution, be associated with ob jects 2 with which it is type compatible. 3 The dynamic type of an allocated allocatable polymorphic ob ject is the type with which it was allocated. 4 The dynamic type of an associated polymorphic pointer is the dynamic type of its target. The dynamic 5 type of a nonallocatable nonpointer polymorphic dummy argument is the dynamic type of its associated 6 actual argument. The dynamic type of an unallocated allocatable or a disassociated pointer is the same 7 as its declared type. The dynamic type of an entity identified by an associate name (8.1.5) is the dynamic 8 type of the selector with which it is associated. The dynamic type of an ob ject that is not polymorphic 9 is its declared type. 10 NOTE 4.6 Only components of the declared type of a polymorphic ob ject may be designated by component selection (6.1.2). 4.4 Intrinsic types 11 4.4.1 Classification and sp ecification 12 Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric typ es are integer, 13 real, and complex. The nonnumeric intrinsic types are character, logical, and bits. 14 The numeric types are provided for numerical computation. The normal operations of arithmetic, 15 addition (+), subtraction (­), multiplication (*), division (/), exponentiation (**), identity (unary +), 16 and negation (unary ­), are defined intrinsically for the numeric types. 17 R404 intrinsic-type-spec is INTEGER [ kind-selector ] 18 or REAL [ kind-selector ] 19 or DOUBLE PRECISION 20 or COMPLEX [ kind-selector ] 21 or CHARACTER [ char-selector ] 22 or LOGICAL [ kind-selector ] 23 or BITS [ kind-selector ] 24 R405 kind-selector is ( [ KIND = ] scalar-int-initialization-expr ) 25 C408 (R405) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 26 resentation method that exists on the processor. 27 4.4.2 Integer type 28 The set of values for the integer typ e is a subset of the mathematical integers. The processor shall 29 provide one or more representation metho ds that define sets of values for data of type integer. Each 30 46 2006/07/11 WORKING DRAFT J3/06-007 such method is characterized by a value for a type parameter called the kind type parameter; this kind 1 type parameter is of type default integer. The kind type parameter of a representation method is returned 2 by the intrinsic inquiry function KIND (13.7.96). The decimal exponent range of a representation method 3 is returned by the intrinsic function RANGE (13.7.143). The intrinsic function SELECTED INT KIND 4 (13.7.153) returns a kind value based on a specified decimal range requirement. The integer type includes 5 a zero value, which is considered to be neither negative nor positive. The value of a signed integer zero 6 is the same as the value of an unsigned integer zero. 7 The processor shall provide at least one representation method with a decimal exponent range greater 8 than or equal to 18. 9 The type specifier for the integer type uses the keyword INTEGER. 10 If the kind type parameter is not specified, the default kind value is KIND (0) and the type specified is 11 default integer. The decimal exponent range of default integer shall be at least 5. 12 Any integer value may be represented as a signed-int-literal-constant . 13 R406 signed-int-literal-constant is [ sign ] int-literal-constant 14 R407 int-literal-constant is digit-string [ kind-param ] 15 R408 kind-param is digit-string 16 or scalar-int-constant-name 17 R409 signed-digit-string is [ sign ] digit-string 18 R410 digit-string is digit [ digit ] ... 19 R411 sign is + 20 or ­ 21 C409 (R408) A scalar-int-constant-name shall be a named constant of type integer. 22 C410 (R408) The value of kind-param shall be nonnegative. 23 C411 (R407) The value of kind-param shall specify a representation method that exists on the pro- 24 cessor. 25 The optional kind type parameter following digit-string specifies the kind type parameter of the integer 26 constant; if it is not present, the constant is of type default integer. 27 An integer constant is interpreted as a decimal value. 28 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 typ e 29 The real typ e has values that approximate the mathematical real numbers. The processor shall provide 30 two or more approximation metho ds that define sets of values for data of type real. Each such method 31 has a representation metho d and is characterized by a value for a type parameter called the kind 32 47 J3/06-007 WORKING DRAFT 2006/07/11 type parameter; this kind type parameter is of type default integer. The kind type parameter of an 1 approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 2 The decimal precision, decimal exponent range, and radix of an approximation method are returned by 3 the intrinsic functions PRECISION (13.7.137), RANGE (13.7.143), and RADIX (D13:RADIX (X)). The 4 intrinsic function SELECTED REAL KIND (13.7.154) returns a kind value based on specified precision, 5 range, and radix requirements. 6 NOTE 4.8 See C.1.1 for remarks concerning selection of approximation methods. The real type includes a zero value. Processors that distinguish between positive and negative zeros 7 shall treat them as mathematically equivalent 8 (1) in all relational operations, 9 (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified 10 that negative zero is distinguished, and 11 (3) 12 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 lab el "2" for b oth X = 0.0 and X = - 0 .0 . In order to distinguish between 0.0 and -0.0, a program should use the SIGN function. SIGN(1.0,X) will return -1.0 if X < 0.0 or if the processor distinguishes between 0.0 and -0.0 and X has the value -0.0. The type specifier for the real type uses the keyword REAL. The keyword DOUBLE PRECISION is an 13 alternate specifier for one kind of real type. 14 If the type keyword REAL is specified and the kind type parameter is not specified, the default kind 15 value is KIND (0.0) and the type specified is default real. If the type keyword DOUBLE PRECISION 16 is specified, the kind value is KIND (0.0D0) and the type specified is double precision real. The 17 decimal precision of the double precision real approximation method shall be greater than that of the 18 default real method. 19 The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall 20 be at least 37. It is recommended that the decimal precision of default real be at least 6, and that its 21 decimal exponent range be at least 37. 22 R412 signed-real-literal-constant is [ sign ] real-literal-constant 23 R413 real-literal-constant is significand [ exponent-letter exponent ] [ kind-param ] 24 or digit-string exponent-letter exponent [ kind-param ] 25 48 2006/07/11 WORKING DRAFT J3/06-007 R414 significand is digit-string . [ digit-string ] 1 or . digit-string 2 R415 exponent-letter is E 3 or D 4 R416 exponent is signed-digit-string 5 C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. 6 C413 (R413) The value of kind-param shall specify an approximation method that exists on the 7 processor. 8 A real literal constant without a kind type parameter is a default real constant if it is without an 9 exponent part or has exponent letter E, and is a double precision real constant if it has exponent letter 10 D. A real literal constant written with a kind type parameter is a real constant with the specified kind 11 type parameter. 12 The exponent represents the power of ten scaling to be applied to the significand or digit string. The 13 meaning of these constants is as in decimal scientific notation. 14 The significand may be written with more digits than a processor will use to approximate the value of 15 the constant. 16 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 17 The complex typ e has values that approximate the mathematical complex numbers. The values of a 18 complex type are ordered pairs of real values. The first real value is called the real part, and the second 19 real value is called the imaginary part. 20 Each approximation method used to represent data entities of type real shall be available for both the 21 real and imaginary parts of a data entity of type complex. A kind type parameter may be specified for 22 a complex entity and selects for both parts the real approximation method characterized by this kind 23 type parameter value; this kind type parameter is of type default integer. The kind type parameter of 24 an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 25 The type specifier for the complex type uses the keyword COMPLEX. There is no keyword for double 26 precision complex. If the type keyword COMPLEX is specified and the kind type parameter is not 27 specified, the default kind value is the same as that for default real, the type of both parts is default 28 real, and the type specified is default complex. 29 R417 complex-literal-constant is ( real-part , imag-part ) 30 R418 real-part is signed-int-literal-constant 31 49 J3/06-007 WORKING DRAFT 2006/07/11 or signed-real-literal-constant 1 or named-constant 2 R419 imag-part is signed-int-literal-constant 3 or signed-real-literal-constant 4 or named-constant 5 C414 (R417) Each named constant in a complex literal constant shall be of type integer or real. 6 If the real part and the imaginary part of a complex literal constant are both real, the kind type 7 parameter value of the complex literal constant is the kind type parameter value of the part with the 8 greater decimal precision; if the precisions are the same, it is the kind type parameter value of one of the 9 parts as determined by the processor. If a part has a kind type parameter value different from that of 10 the complex literal constant, the part is converted to the approximation method of the complex literal 11 constant. 12 If both the real and imaginary parts are integer, they are converted to the default real approximation 13 method and the constant is of type default complex. If only one of the parts is an integer, it is converted 14 to the approximation method selected for the part that is real and the kind type parameter value of the 15 complex literal constant is that of the part that is real. 16 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 typ e 17 4.4.5.1 Character sets 18 The character typ e has a set of values composed of character strings. A character string is a sequence 19 of characters, numbered from left to right 1, 2, 3, ... up to the number of characters in the string. The 20 number of characters in the string is called the length of the string. The length is a type parameter; its 21 value is greater than or equal to zero. The length type parameter is of type default integer. 22 The processor shall provide one or more representation metho ds that define sets of values for data 23 of type character. Each such method is characterized by a value for a type parameter called the kind 24 type parameter; this kind type parameter is of type default integer. The kind type parameter of a rep- 25 resentation method is returned by the intrinsic inquiry function KIND (13.7.96). The intrinsic function 26 SELECTED CHAR KIND (13.7.152) returns a kind value based on the name of a character type. Any 27 character of a particular representation method representable in the processor may occur in a character 28 string of that representation method. 29 The character set defined by ISO/IEC 646:1991 (International Reference Version) is referred to as the 30 ASCI I character set or the ASCI I character typ e. The character set defined by ISO/IEC 10646- 31 1:2000 UCS-4 is referred to as the ISO 10646 character set or the ISO 10646 character typ e. 32 4.4.5.2 Character typ e sp ecifier 33 The type specifier for the character type uses the keyword CHARACTER. 34 50 2006/07/11 WORKING DRAFT J3/06-007 If the kind type parameter is not specified, the default kind value is KIND ('A') and the type specified 1 is default character. 2 R420 char-selector is length-selector 3 or ( LEN = type-param-value , 4 KIND = scalar-int-initialization-expr ) 5 or ( type-param-value , 6 [ KIND = ] scalar-int-initialization-expr ) 7 or ( KIND = scalar-int-initialization-expr 8 [ , LEN =type-param-value ] ) 9 R421 length-selector is ( [ LEN = ] type-param-value ) 10 or * char-length [ , ] 11 R422 char-length is ( type-param-value ) 12 or scalar-int-literal-constant 13 C415 (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 14 resentation method that exists on the processor. 15 C416 (R422) The scalar-int-literal-constant shall not include a kind-param . 16 C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr . 17 C418 (R420 R421 R422) A type-param-value of * shall be used only 18 (1) to declare a dummy argument, 19 (2) to declare a named constant, 20 (3) in the type-spec of an ALLOCATE statement wherein each al locate-object is a dummy 21 argument of type CHARACTER with an assumed character length, 22 (4) in the type-spec or derived-type-spec of a type guard statement (8.1.6), or 23 (5) in an external function, to declare the character length parameter of the function result. 24 C419 A function name shall not be declared with an asterisk type-param-value unless it is of type CHAR- 25 26 ACTER and is the name of the result of an external function or the name of a dummy function. C420 27 A function name declared with an asterisk type-param-value shall not b e an array, a p ointer, recursive, or pure. C421 28 (R421) The optional comma in a length-selector is permitted only in a declaration-type-spec in a type-declaration- 29 stmt . C422 30 (R421) The optional comma in a length-selector is p ermitted only if no double-colon separator app ears in the 31 type-declaration-stmt . C423 32 (R420) The length sp ecified for a character statement function or for a statement function dummy argument of 33 typ e character shall b e an initialization expression. The char-selector in a CHARACTER intrinsic-type-spec and the * char-length in an entity-decl or in 34 a component-decl of a type definition specify character length. The * char-length in an entity-decl or 35 a component-decl specifies an individual length and overrides the length specified in the char-selector , 36 if any. If a * char-length is not specified in an entity-decl or a component-decl , the length-selector or 37 type-param-value specified in the char-selector is the character length. If the length is not specified in a 38 char-selector or a * char-length , the length is 1. 39 If the character length parameter value evaluates to a negative value, the length of character entities 40 declared is zero. A character length parameter value of : indicates a deferred type parameter (4.2). A 41 char-length type parameter value of * has the following meanings. 42 (1) If used to declare a dummy argument of a procedure, the dummy argument assumes the 43 51 J3/06-007 WORKING DRAFT 2006/07/11 length of the associated actual argument. 1 (2) If used to declare a named constant, the length is that of the constant value. 2 (3) If used in the type-spec of an ALLOCATE statement, each al locate-object assumes its length 3 from the associated actual argument. 4 (4) If used in the type-spec of a type guard statement, the associating entity assumes its length 5 from the selector. 6 (5) 7 If used to sp ecify the character length parameter of a function result, any scoping unit invoking the function shall declare the function name with a character length parameter value other than * or access such a 8 9 definition by host or use asso ciation. When the function is invoked, the length of the result variable in the function is assumed from the value of this type parameter. 10 4.4.5.3 Character literal constant 11 A character literal constant is written as a sequence of characters, delimited by either apostrophes 12 or quotation marks. 13 R423 char-literal-constant is [ kind-param ] ' [ rep-char ] ... ' 14 or [ kind-param ] " [ rep-char ] ... " 15 C424 (R423) The value of kind-param shall specify a representation method that exists on the pro- 16 cessor. 17 The optional kind type parameter preceding the leading delimiter specifies the kind type parameter of 18 the character constant; if it is not present, the constant is of type default character. 19 For the type character with kind kind-param , if present, and for type default character otherwise, a 20 representable character, rep-char , is defined as follows. 21 (1) In free source form, it is any graphic character in the processor-dependent character set. 22 (2) 23 In fixed source form, it is any character in the pro cessor-dep endent character set. A pro cessor may restrict 24 the o ccurrence of some or all of the control characters. NOTE 4.12 Fortran 77 allowed any character to occur in a character context. This standard allows a source program to contain characters of more than one kind. Some processors may identify characters of nondefault kinds by control characters (called "escape" or "shift" characters). It is difficult, if not impossible, to process, edit, and print files where some occurences of control characters have their intended meaning and some occurrences might not. Almost all control characters have uses or effects that effectively preclude their use in character contexts and this is why free source form allows only graphic characters as representable characters. Nevertheless, for compatibility with Fortran 77, control characters remain p ermitted in principle in fixed source form. The delimiting apostrophes or quotation marks are not part of the value of the character literal constant. 25 An apostrophe character within a character constant delimited by apostrophes is represented by two 26 consecutive apostrophes (without intervening blanks); in this case, the two apostrophes are counted as 27 one character. Similarly, a quotation mark character within a character constant delimited by quotation 28 marks is represented by two consecutive quotation marks (without intervening blanks) and the two 29 quotation marks are counted as one character. 30 A zero-length character literal constant is represented by two consecutive apostrophes (without inter- 31 vening blanks) or two consecutive quotation marks (without intervening blanks) outside of a character 32 context. 33 The intrinsic operation concatenation (//) is defined between two data entities of type character (7.2.3) 34 52 2006/07/11 WORKING DRAFT J3/06-007 with the same kind type parameter. 1 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. 4.4.5.4 Collating sequence 2 The processor defines a collating sequence for the character set of each kind of character. A collating 3 sequence is a one-to-one mapping of the characters into the nonnegative integers such that each charac- 4 ter corresponds to a different nonnegative integer. The intrinsic functions CHAR (13.7.30) and ICHAR 5 (13.7.84) provide conversions between the characters and the integers according to this mapping. 6 NOTE 4.15 For example: ICHAR ( 'X' ) returns the integer value of the character 'X' according to the collating sequence of the processor. The collating sequence of the default character type shall satisfy the following constraints. 7 (1) ICHAR ('A') < ICHAR ('B') < ... < ICHAR ('Z') for the twenty-six upper-case letters. 8 (2) ICHAR ('0') < ICHAR ('1') < ... < ICHAR ('9') for the ten digits. 9 (3) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('A') or 10 ICHAR (' ') < ICHAR ('A') < ICHAR ('Z') < ICHAR ('0'). 11 (4) ICHAR ('a') < ICHAR ('b') < ... < ICHAR ('z') for the twenty-six lower-case letters. 12 (5) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('a') or 13 ICHAR (' ') < ICHAR ('a') < ICHAR ('z') < ICHAR ('0'). 14 Except for blank, there are no constraints on the location of the special characters and underscore in 15 the collating sequence, nor is there any specified collating sequence relationship between the upper-case 16 and lower-case letters. 17 The collating sequence for the ASCII character type is as defined by ISO/IEC 646:1991 (International 18 Reference Version); this collating sequence is called the ASCI I collating sequence in this standard. 19 53 J3/06-007 WORKING DRAFT 2006/07/11 The collating sequence for the ISO 10646 character type is as defined by ISO/IEC 10646-1:2000. 1 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. The intrinsic functions LGT, LGE, LLE, and LLT (13.7.101-13.7.104) provide comparisons between 2 strings based on the ASCII collating sequence. International portability is guaranteed if the set of 3 characters used is limited to the letters, digits, underscore, and special characters. 4 4.4.6 Logical typ e 5 The logical typ e has two values, which represent true and false. 6 The processor shall provide one or more representation metho ds for data of type logical. Each such 7 method is characterized by a value for a type parameter called the kind type parameter; this kind type 8 parameter is of type default integer. The kind type parameter of a representation method is returned 9 by the intrinsic inquiry function KIND (13.7.96). 10 The type specifier for the logical type uses the keyword LOGICAL. 11 If the kind type parameter is not specified, the default kind value is KIND (.FALSE.) and the type 12 specified is default logical. 13 R424 logical-literal-constant is .TRUE. [ kind-param ] 14 or .FALSE. [ kind-param ] 15 C425 (R424) The value of kind-param shall specify a representation method that exists on the pro- 16 cessor. 17 The optional kind type parameter following the trailing delimiter specifies the kind type parameter of 18 the logical constant; if it is not present, the constant is of type default logical. 19 The intrinsic operations defined for data entities of logical type are: negation (.NOT.), conjunction 20 (.AND.), inclusive disjunction (.OR.), logical equivalence (.EQV.), and logical nonequivalence (.NEQV.) 21 as described in 7.2.5. There is also a set of intrinsically defined relational operators that compare the 22 values of data entities of other types and yield a value of type default logical. These operations are 23 described in 7.2.4. 24 4.4.7 Bits typ e 25 4.4.7.1 General 26 The bits typ e has a set of values composed of ordered sequences of bits. The number of bits in 27 the sequence is specified by the kind type parameter, which shall be greater than or equal to zero. 28 The processor shall provide representation methods with kind type parameter values equal to every 29 nonnegative integer less than or equal to a processor-determined limit. This limit shall be at least as 30 large as the storage size, expressed in bits, of every supported kind of type integer, real, complex, and 31 logical. Additional representation methods may be provided. 32 The type specifier for the bits type uses the keyword BITS. 33 If the kind type parameter is not specified for a bits variable, the default kind value is the size of a 34 numeric storage unit expressed in bits, and the type specified is default bits. 35 R425 boz-literal-constant is binary-constant [ kind-param ] 36 54 2006/07/11 WORKING DRAFT J3/06-007 or octal-constant [ kind-param ] 1 or hex-constant [ kind-param ] 2 R426 binary-constant is B ' digit [ digit ] ... ' 3 or B " digit [ digit ] ... " 4 C426 (R426) digit shall have one of the values 0 or 1. 5 R427 octal-constant is O ' digit [ digit ] ... ' 6 or O " digit [ digit ] ... " 7 C427 (R427) digit shall have one of the values 0 through 7. 8 R428 hex-constant is Z ' hex-digit [ hex-digit ] ... ' 9 or Z " hex-digit [ hex-digit ] ... " 10 R429 hex-digit is digit 11 or A 12 or B 13 or C 14 or D 15 or E 16 or F 17 The hex-digit s A through F represent the numbers ten through fifteen, respectively; they may be repre- 18 sented by their lower-case equivalents. 19 If the optional kind type parameter is not specified for a boz literal constant, the kind value is assumed 20 from the form of the constant. If the constant is a binary-constant the kind value is the number 21 of digit characters. If the constant is an octal-constant the kind value is three times the number of 22 digit characters. If the constant is a hex-constant the kind value is four times the number of hex-digit 23 characters. 24 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. Each digit of an octal constant represents three bits, and each hex digit of a hex constant represents 25 four bits, according to their numerical representations as binary integers, with leading zero bits where 26 needed. 27 If a kind-param is specified for a boz literal constant and has a value greater than the number of bits 28 specified by its digits, the constant is padded on the left (13.3) with enough zero bits to create a constant 29 of kind kind-param . If the kind-param specified has a value smaller the number of bits specified by its 30 digits, only the rightmost kind-param bits are used to determine the value of the constant. 31 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 ob jects with KIND values equal to small integer multiples of NUMERIC STORAGE SIZE should result in more efficient execution. 55 J3/06-007 WORKING DRAFT 2006/07/11 4.5 Derived typ es 1 4.5.1 Derived typ e concepts 2 Additional types may be derived from the intrinsic types and other derived types. A type definition is 3 required to define the name of the type and the names and attributes of its components and type-bound 4 procedures. 5 A derived type may be parameterized by multiple type parameters, each of which is defined to be either 6 a kind or length type parameter and may have a default value. 7 The ultimate comp onents of an ob ject of derived type are the components that are of intrinsic type 8 or have the POINTER or ALLOCATABLE attribute, plus the ultimate components of the components 9 of the ob ject that are of derived type and have neither the ALLOCATABLE nor POINTER attribute. 10 NOTE 4.19 The ultimate components of ob jects 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 By default, no storage sequence is implied by the order of the component definitions. However, a storage 11 order is implied for a sequence type (4.5.2.3). If the derived type has the BIND attribute, the storage 12 sequence is that required by the companion processor (2.5.10, 15.3.4). 13 A scalar entity of derived type is a structure. If a derived type has the SEQUENCE property, a scalar 14 entity of the type is a sequence structure. 15 4.5.2 Derived-typ e definition 16 4.5.2.1 Syntax 17 R430 derived-type-def is derived-type-stmt 18 [ type-param-def-stmt ] ... 19 [ private-or-sequence ] ... 20 [ component-part ] 21 [ type-bound-procedure-part ] 22 end-type-stmt 23 R431 derived-type-stmt is TYPE [ [ , type-attr-spec -list ] :: ] type-name 24 [ ( type-param-name -list ) ] 25 R432 type-attr-spec is ABSTRACT 26 or access-spec 27 or BIND (C) 28 or EXTENDS ( parent-type-name ) 29 C428 (R431) A derived type type-name shall not be DOUBLEPRECISION or the same as the name 30 56 2006/07/11 WORKING DRAFT J3/06-007 of any intrinsic type defined in this part of ISO/IEC 1539. 1 C429 (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt . 2 C430 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). 3 C431 (R430) If the type definition contains or inherits (4.5.7.2) a deferred binding (4.5.5), ABSTRACT 4 shall appear. 5 C432 (R430) If ABSTRACT appears, the type shall be extensible. 6 C433 (R430) If EXTENDS appears, SEQUENCE shall not appear. 7 R433 private-or-sequence is private-components-stmt 8 or sequence-stmt 9 C434 (R430) The same private-or-sequence shall not appear more than once in a given derived-type- 10 def . 11 R434 end-type-stmt is END TYPE [ type-name ] 12 C435 (R434) If END TYPE is followed by a type-name , the type-name shall be the same as that in 13 the corresponding derived-type-stmt . 14 Derived types with the BIND attribute are sub ject to additional constraints as specified in 15.3.4. 15 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 4.5.2.2 Accessibility 16 Types that are defined in a module or accessible in that module by use association have either the 17 PUBLIC or PRIVATE attribute. Types for which an access-spec is not explicitly specified in that 18 module have the default accessibility attribute for that module. The default accessibility attribute for a 19 module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only types that have 20 the PUBLIC attribute in that module are available to be accessed from that module by use association. 21 The accessibility of a type does not affect, and is not affected by, the accessibility of its components and 22 bindings. 23 If a type definition is private, then the type name, and thus the structure constructor (4.5.10) for the 24 type, are accessible only within the module containing the definition, and within its descendants. 25 NOTE 4.21 An example of a type with a private name is: TYPE, PRIVATE :: AUXILIARY 57 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 4.21 (cont.) 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. 4.5.2.3 Sequence typ e 1 R435 sequence-stmt is SEQUENCE 2 C436 (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type 3 or of a sequence derived type. 4 C437 (R430) If SEQUENCE appears, a type-bound-procedure-part shall not appear. 5 If the SEQUENCE statement appears, the type is a sequence typ e. The order of the component 6 definitions in a sequence type specifies a storage sequence for ob jects of that type. The type is a 7 numeric sequence typ e if there are no type parameters, no pointer or allocatable components, and 8 each component is of type default integer, default real, double precision real, default complex, default 9 logical, default bits, or a numeric sequence type. The type is a character sequence typ e if there 10 are no type parameters, no pointer or allocatable components, and each component is of type default 11 character or a character sequence type. 12 NOTE 4.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 ob ject of derived type will always be accessed by a component name except in the following contexts: the sequence of expressions in a derived-type value constructor, intrinsic assignment, the data values in namelist input data, and the inclusion of the structure in an input/output list of a formatted data transfer, where it is expanded to this sequence of components. Provided the processor adheres to the defined order in these cases, it is otherwise free to organize the storage of the components for any nonsequence structure in memory as best suited to the particular architecture. 4.5.2.4 Determination of derived typ es 13 Derived-type definitions with the same type name may appear in different scoping units, in which case 14 they may be independent and describe different derived types or they may describe the same type. 15 58 2006/07/11 WORKING DRAFT J3/06-007 Two data entities have the same type if they are declared with reference to the same derived-type 1 definition. The definition may be accessed from a module or from a host scoping unit. Data entities in 2 different scoping units also have the same type if they are declared with reference to different derived-type 3 definitions that specify the same type name, all have the SEQUENCE property or all have the BIND 4 attribute, have no components with PRIVATE accessibility, and have type parameters and components 5 that agree in order, name, and attributes. Otherwise, they are of different derived types. A data entity 6 declared using a type with the SEQUENCE property or with the BIND attribute is not of the same type 7 as an entity of a type declared to be PRIVATE or that has any components that are PRIVATE. 8 NOTE 4.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 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 59 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 4.25 (cont.) because they are declared with reference to a derived-type definition with the same name, the SEQUENCE property, and components that agree in order, name, and attributes. Suppose the component name ID NUMBER was ID NUM in the subroutine. Because all the component names are not identical to the component names in derived type EMPLOYEE in the main program, the actual argument PROGRAMMER would not be of the same type as the dummy argument POSITION. Thus, the program would not be standard-conforming. NOTE 4.26 The requirement that the two types have the same name applies to the type-name s of the respective derived-type-stmt s, not to local names introduced via renaming in USE statements. 4.5.3 Derived-typ e parameters 1 4.5.3.1 Declaration 2 R436 type-param-def-stmt is INTEGER [ kind-selector ] , type-param-attr-spec :: 3 type-param-decl -list 4 R437 type-param-decl is type-param-name [ = scalar-int-initialization-expr ] 5 C438 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the 6 type-param-name s in the derived-type-stmt of that derived-type-def . 7 C439 (R436) Each type-param-name in the derived-type-stmt in a derived-type-def shall appear as a 8 type-param-name in a type-param-def-stmt in that derived-type-def . 9 R438 type-param-attr-spec is KIND 10 or LEN 11 The derived type is parameterized if the derived-type-stmt has any type-param-name s. 12 Each type parameter is itself of type integer. If its kind selector is omitted, the kind type parameter is 13 default integer. 14 The type-param-attr-spec explicitly specifies whether a type parameter is a kind parameter or a length 15 parameter. 16 If a type-param-decl has a scalar-int-initialization-expr , the type parameter has a default value which 17 is specified by the expression. If necessary, the value is converted according to the rules of intrinsic 18 assignment (7.4.1.3) to a value of the same kind as the type parameter. 19 A type parameter may be used as a primary in a specification expression (7.1.6) in the derived-type- 20 def . A kind type parameter may also be used as a primary in an initialization expression (7.1.7) in the 21 derived-type-def . 22 NOTE 4.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) 60 2006/07/11 WORKING DRAFT J3/06-007 NOTE 4.27 (cont.) END TYPE In the following example, dim is declared to be a kind parameter, allowing generic overloading of procedures distinguished only by dim. TYPE general_point(dim) INTEGER, KIND :: dim REAL :: coordinates(dim) END TYPE 4.5.3.2 Typ e parameter order 1 Typ e parameter order is an ordering of the type parameters of a derived type; it is used for derived- 2 type specifiers. 3 The type parameter order of a nonextended type is the order of the type parameter list in the derived- 4 type definition. The type parameter order of an extended type consists of the type parameter order of 5 its parent type followed by any additional type parameters in the order of the type parameter list in the 6 derived-type definition. 7 NOTE 4.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 4.5.4.1 Syntax 9 R439 component-part is [ component-def-stmt ] ... 10 R440 component-def-stmt is data-component-def-stmt 11 or proc-component-def-stmt 12 R441 data-component-def-stmt is declaration-type-spec [ [ , component-attr-spec -list ] :: ] 13 component-decl -list 14 R442 component-attr-spec is access-spec 15 or ALLOCATABLE 16 or component-dim-spec 17 or CONTIGUOUS 18 or POINTER 19 R443 component-decl is component-name [ ( component-array-spec ) ] 20 [ lbracket co-array-spec rbracket ] 21 [ * char-length ] [ component-initialization ] 22 61 J3/06-007 WORKING DRAFT 2006/07/11 R444 component-dim-spec is DIMENSION ( component-array-spec ) 1 or DIMENSION [ ( deferred-shape-spec -list ) ] 2 lbracket co-array-spec rbracket 3 R445 component-array-spec is explicit-shape-spec -list 4 or deferred-shape-spec -list 5 6 C440 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt . 7 C441 (R441) If neither the POINTER nor ALLOCATABLE attribute is specified, the declaration-type- 8 spec in the component-def-stmt shall specify an intrinsic type or a previously defined derived 9 type. 10 C442 (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in 11 the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible 12 derived type including the type being defined. 13 C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec 14 shall be a deferred-shape-spec -list. 15 C444 (R441) If a co-array-spec appears, it shall be a deferred-shape-spec -list and the component shall 16 have the ALLOCATABLE attribute. 17 C445 A data component whose type has a co-array ultimate component shall be a nonpointer nonal- 18 locatable scalar and shall not be a co-array. 19 C446 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each 20 component-array-spec shall be an explicit-shape-spec -list. 21 C447 (R445) Each bound in the explicit-shape-spec shall either be an initialization expression or be a 22 specification expression that does not contain references to specification functions or any ob ject 23 designators other than named constants or subob jects thereof. 24 C448 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. 25 C449 (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the 26 POINTER attribute. 27 C450 (R443) The * char-length option is permitted only if the component is of type character. 28 C451 (R440) Each type-param-value within a component-def-stmt shall either be a colon, be an ini- 29 tialization expression, or be a specification expression that contains neither references to speci- 30 fication functions nor any ob ject designators other than named constants or subob jects thereof. 31 NOTE 4.29 Because a type parameter is not an ob ject, a type-param-value or a bound in an explicit-shape-spec may contain a type-param-name . R446 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , 32 proc-component-attr-spec -list :: proc-decl -list 33 NOTE 4.30 See 12.4.2.3 for definitions of proc-interface and proc-decl . R447 proc-component-attr-spec is POINTER 34 or PASS [ (arg-name ) ] 35 62 2006/07/11 WORKING DRAFT J3/06-007 or NOPASS 1 or access-spec 2 C452 (R446) The same proc-component-attr-spec shall not appear more than once in a given proc- 3 component-def-stmt . 4 C453 (R446) POINTER shall appear in each proc-component-attr-spec -list. 5 C454 (R446) If the procedure pointer component has an implicit interface or has no arguments, 6 NOPASS shall be specified. 7 C455 (R446) If PASS (arg-name ) appears, the interface shall have a dummy argument named arg- 8 name . 9 C456 (R446) PASS and NOPASS shall not both appear in the same proc-component-attr-spec -list. 10 4.5.4.2 Array comp onents 11 A data component is an array if its component-decl contains a component-array-spec or its data-compo- 12 nent-def-stmt contains the DIMENSION clause with a component-array-spec . If the component-decl 13 contains a component-array-spec , it specifies the array rank, and if the array is explicit shape (5.3.7.2), 14 the array bounds; otherwise, the component-array-spec in the DIMENSION clause specifies the array 15 rank, and if the array is explicit shape, the array bounds. 16 A data component is a co-array if its component-decl contains a co-array-spec or its data-component-def- 17 stmt contains a DIMENSION clause with a co-array-spec . If the component-decl contains a co-array-spec 18 it specifies the co-rank; otherwise, the co-array-spec in the DIMENSION clause specifies the co-rank. 19 NOTE 4.31 An example of a derived type definition with an array component is: TYPE LINE REAL, DIMENSION (2, 2) :: COORD ! ! COORD(:,1) has the value of (/X1, Y1/) ! COORD(:,2) has the value of (/X2, Y2/) REAL :: WIDTH ! Line width in centimeters INTEGER :: PATTERN ! 1 for solid, 2 for dash, 3 for dot END TYPE LINE An example of declaring a variable LINE SEGMENT to be of the type LINE is: TYPE (LINE) :: LINE_SEGMENT The scalar variable LINE SEGMENT has a component that is an array. In this case, the array is a subob ject 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 63 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 4.32 (cont.) 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. 4.5.4.3 Pointer comp onents 1 A component is a pointer (2.4.7) if its component-attr-spec -list contains the POINTER attribute. A 2 pointer component may be a data pointer or a procedure pointer. 3 NOTE 4.34 An example of a derived type definition with a pointer component is: TYPE REFERENCE INTEGER :: VOLUME, YEAR, PAGE CHARACTER (LEN = 50) :: TITLE CHARACTER, DIMENSION (:), POINTER :: SYNOPSIS END TYPE REFERENCE Any ob ject of type REFERENCE will have the four nonpointer components VOLUME, YEAR, PAGE, and TITLE, plus a pointer to an array of characters holding SYNOPSIS. The size of this target array will be determined by the length of the abstract. The space for the target may be allocated (6.3.1) or the pointer component may be associated with a target by a pointer assignment statement (7.4.2). 4.5.4.4 The passed-object dummy argument 4 A passed-ob ject dummy argument is a distinguished dummy argument of a procedure pointer 5 component or type-bound procedure. It affects procedure overriding (4.5.7.3) and argument association 6 (12.5.1.2). 7 If NOPASS is specified, the procedure pointer component or type-bound procedure has no passed-ob ject 8 dummy argument. 9 If neither PASS nor NOPASS is specified or PASS is specified without arg-name , the first dummy argu- 10 ment of a procedure pointer component or type-bound procedure is its passed-ob ject dummy argument. 11 If PASS (arg-name ) is specified, the dummy argument named arg-name is the passed-ob ject dummy 12 argument of the procedure pointer component or named type-bound procedure. 13 C457 The passed-ob ject dummy argument shall be a scalar, nonpointer, nonallocatable dummy data 14 ob ject with the same declared type as the type being defined; all of its length type parameters 15 shall be assumed; it shall be polymorphic (4.3.1.3) if and only if the type being defined is 16 extensible (4.5.7). It shall not have the VALUE attribute. 17 64 2006/07/11 WORKING DRAFT J3/06-007 NOTE 4.35 If a procedure is bound to several types as a type-bound procedure, different dummy arguments might be the passed-ob ject dummy argument in different contexts. 4.5.4.5 Default initialization for comp onents 1 Default initialization provides a means of automatically initializing pointer components to be disasso- 2 ciated, and nonpointer nonallocatable components to have a particular value. Allocatable components 3 are always initialized to not allocated. 4 A pointer variable or component is data-p ointer-initialization compatible with a target if the pointer 5 is type compatible with the target, they have the same rank, and the values of corresponding nondeferred 6 type parameters are specified by initialization expressions that have the same value. 7 R448 component-initialization is = initialization-expr 8 or => nul l-init 9 or => initial-data-target 10 R449 initial-data-target is designator 11 C458 (R441) If component-initialization appears, a double-colon separator shall appear before the 12 component-decl -list. 13 C459 (R441) If component-initialization appears, every type parameter and array bound of the com- 14 ponent shall be an initialization expression. 15 C460 (R441) If => appears in component-initialization , POINTER shall appear in the component- 16 attr-spec -list. If = appears in component-initialization , POINTER or ALLOCATABLE shall 17 not appear in the component-attr-spec -list. 18 C461 (R448) If initial-data-target appears, component-name shall be data-pointer-initialization com- 19 patible with it. 20 C462 (R449) The designator shall designate a variable that is an initialization target. Every subscript, 21 section subscript, substring starting point, and substring ending point in designator shall be an 22 initialization expression. 23 If nul l-init appears for a pointer component, that component in any ob ject of the type has an initial 24 association status of disassociated (16.5.2.2) or becomes disassociated as specified in 16.5.2.2.2. 25 A variable is an initialization target if it has the TARGET attribute, either has the SAVE attribute 26 or is declared in the main program, does not have the ALLOCATABLE attribute. 27 If initial-data-target appears for a data pointer component, that component in any ob ject of the type is 28 initially associated with the target or becomes associated with the target as specified in 16.5.2.2.1. 29 If initial-proc-target appears in proc-decl for a procedure pointer component, that component in any 30 ob ject of the type is initially associated with the target or becomes associated with the target as specified 31 in 16.5.2.2.1. 32 If initialization-expr appears for a nonpointer component, that component in any ob ject of the type 33 is initially defined (16.6.3) or becomes defined as specified in 16.6.5 with the value determined from 34 initialization-expr . If necessary, the value is converted according to the rules of intrinsic assignment 35 (7.4.1.3) to a value that agrees in type, type parameters, and shape with the component. If the compo- 36 nent is of a type for which default initialization is specified for a component, the default initialization 37 specified by initialization-expr overrides the default initialization specified for that component. When 38 one initialization overrides another it is as if only the overriding initialization were specified (see Note 39 65 J3/06-007 WORKING DRAFT 2006/07/11 4.37). Explicit initialization in a type declaration statement (5.2) overrides default initialization (see 1 Note 4.36). Unlike explicit initialization, default initialization does not imply that the ob ject has the 2 SAVE attribute. 3 A subcomponent (6.1.2) is default-initialized if the type of the ob ject of which it is a component 4 specifies default initialization for that component, and the subcomponent is not a subob ject of an ob ject 5 that is default-initialized or explicitly initialized. 6 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 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 ob ject of type MEMBER. 66 2006/07/11 WORKING DRAFT J3/06-007 NOTE 4.38 (cont.) Allocated ob jects 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 ob ject of that derived type. The type definition may specify that in ob jects 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 ob jects 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 TYPE(NODE), SAVE, TARGET :: SENTINEL 4.5.4.6 Comp onent order 1 Comp onent order is an ordering of the nonparent components of a derived type; it is used for intrinsic 2 formatted input/output and structure constructors (where component keywords are not used). Parent 3 components are excluded from the component order of an extended type (4.5.7). 4 The component order of a nonextended type is the order of the declarations of the components in the 5 derived-type definition. The component order of an extended type consists of the component order of 6 its parent type followed by any additional components in the order of their declarations in the extended 7 derived-type definition. 8 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. 4.5.4.7 Comp onent accessibility 9 R450 private-components-stmt is PRIVATE 10 C463 (R450) A private-components-stmt is permitted only if the type definition is within the specifi- 11 cation part of a module. 12 67 J3/06-007 WORKING DRAFT 2006/07/11 The default accessibility for the components that are declared in a type's component-part is private 1 if the type definition contains a private-components-stmt , and public otherwise. The accessibility of a 2 component may be explicitly declared by an access-spec ; otherwise its accessibility is the default for the 3 type definition in which it is declared. 4 If a component is private, that component name is accessible only within the module containing the 5 definition, and within its descendants. 6 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 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-b ound procedures 7 R451 type-bound-procedure-part is contains-stmt 8 [ binding-private-stmt ] 9 [ proc-binding-stmt ] ... 10 R452 binding-private-stmt is PRIVATE 11 C464 (R451) A binding-private-stmt is permitted only if the type definition is within the specification 12 68 2006/07/11 WORKING DRAFT J3/06-007 part of a module. 1 R453 proc-binding-stmt is specific-binding 2 or generic-binding 3 or final-binding 4 R454 specific-binding is PROCEDURE [ (interface-name ) ] 5 [ [ , binding-attr -list ] :: ] 6 binding-name [ => procedure-name ] 7 C465 (R454) If => procedure-name appears, the double-colon separator shall appear. 8 C466 (R454) If => procedure-name appears, interface-name shall not appear. 9 C467 (R454) The procedure-name shall be the name of an accessible module procedure or an external 10 procedure that has an explicit interface. 11 If neither => procedure-name nor interface-name appears, it is as though => procedure-name had 12 appeared with a procedure name the same as the binding name. 13 R455 generic-binding is GENERIC 14 [, access-spec ] :: generic-spec => binding-name -list 15 C468 (R455) Within the specification-part of a module, each generic-binding shall specify, either 16 implicitly or explicitly, the same accessibility as every other generic-binding with that generic- 17 spec in the same derived type. 18 C469 (R455) Each binding-name in binding-name -list shall be the name of a specific binding of the 19 type. 20 C470 (R455) If generic-spec is not generic-name , each of its specific bindings shall have a passed-ob ject 21 dummy argument (4.5.4.4). 22 C471 (R455) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall 23 be as specified in 12.4.2.1.1. 24 C472 (R455) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified 25 in 12.4.2.1.2. 26 C473 (R455) If generic-spec is dtio-generic-spec , the interface of each binding shall be as specified in 27 9.5.3.7. The type of the dtv argument shall be type-name . 28 R456 binding-attr is PASS [ (arg-name ) ] 29 or NOPASS 30 or NON OVERRIDABLE 31 or DEFERRED 32 or access-spec 33 C474 (R456) The same binding-attr shall not appear more than once in a given binding-attr -list. 34 C475 (R454) If the interface of the binding has no dummy argument of the type being defined, 35 NOPASS shall appear. 36 C476 (R454) If PASS (arg-name ) appears, the interface of the binding shall have a dummy argument 37 named arg-name . 38 C477 (R456) PASS and NOPASS shall not both appear in the same binding-attr -list. 39 C478 (R456) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- 40 69 J3/06-007 WORKING DRAFT 2006/07/11 attr -list. 1 C479 (R456) DEFERRED shall appear if and only if interface-name appears. 2 C480 (R454) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding 3 it overrides is deferred. 4 C481 (R454) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- 5 RIDABLE attribute. 6 Each binding in a proc-binding-stmt specifies a typ e-b ound pro cedure. A type-bound procedure 7 may have a passed-ob ject dummy argument (4.5.4.4). A generic-binding specifies a type-bound generic 8 interface for its specific bindings. A binding that specifies the DEFERRED attribute is a deferred 9 binding. A deferred binding shall appear only in the definition of an abstract type. 10 A type-bound procedure may be identified by a binding name in the scope of the type definition. 11 This name is the binding-name for a specific binding, and the generic-name for a generic binding whose 12 generic-spec is generic-name . A final binding, or a generic binding whose generic-spec is not generic- 13 name , has no binding name. 14 The interface of a specific binding is that of the procedure specified by procedure-name or the interface 15 specified by interface-name . 16 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 The same generic-spec may be used in several generic-binding s within a single derived-type definition. 17 Each additional generic-binding with the same generic-spec extends the generic interface. 18 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). The default accessibility for the procedure bindings of a type is private if the type definition contains a 19 binding-private-stmt , and public otherwise. The accessibility of a procedure binding may be explicitly 20 declared by an access-spec ; otherwise its accessibility is the default for the type definition in which it is 21 declared. 22 A public type-bound procedure is accessible via any accessible ob ject of the type. A private type-bound 23 procedure is accessible only within the module containing the type definition, and within its descendants. 24 70 2006/07/11 WORKING DRAFT J3/06-007 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 . 4.5.6 Final subroutines 1 4.5.6.1 Declaration 2 R457 final-binding is FINAL [ :: ] final-subroutine-name -list 3 C482 (R457) A final-subroutine-name shall be the name of a module procedure with exactly one 4 dummy argument. That argument shall be nonoptional and shall be a nonpointer, nonallocat- 5 able, nonpolymorphic variable of the derived type being defined. All length type parameters of 6 the dummy argument shall be assumed. The dummy argument shall not be INTENT(OUT). 7 C483 (R457) A final-subroutine-name shall not be one previously specified as a final subroutine for 8 that type. 9 C484 (R457) A final subroutine shall not have a dummy argument with the same kind type parameters 10 and rank as the dummy argument of another final subroutine of that type. 11 The FINAL keyword specifies a list of final subroutines. A final subroutine might be executed when 12 a data entity of that type is finalized (4.5.6.2). 13 A derived type is finalizable if it has any final subroutines or if it has any nonpointer, nonallocatable 14 component whose type is finalizable. A nonpointer data entity is finalizable if its type is finalizable. 15 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. 4.5.6.2 The finalization pro cess 16 Only finalizable entities are finalized. When an entity is finalized, the following steps are carried out 17 in sequence. 18 (1) If the dynamic type of the entity has a final subroutine whose dummy argument has the 19 same kind type parameters and rank as the entity being finalized, it is called with the entity 20 as an actual argument. Otherwise, if there is an elemental final subroutine whose dummy 21 argument has the same kind type parameters as the entity being finalized, it is called with 22 the entity as an actual argument. Otherwise, no subroutine is called at this point. 23 (2) Each finalizable component that appears in the type definition is finalized. If the entity 24 being finalized is an array, each finalizable component of each element of that entity is 25 finalized separately. 26 (3) If the entity is of extended type and the parent type is finalizable, the parent component is 27 finalized. 28 71 J3/06-007 WORKING DRAFT 2006/07/11 If several entities are to be finalized as a consequence of an event specified in 4.5.6.3, the order in which 1 they are finalized is processor-dependent. A final subroutine shall not reference or define an ob ject that 2 has already been finalized. 3 If an ob ject is not finalized, it retains its definition status and does not become undefined. 4 4.5.6.3 When finalization o ccurs 5 When a pointer is deallocated its target is finalized. When an allocatable entity is deallocated, it is 6 finalized. 7 A nonpointer, nonallocatable ob ject that is not a dummy argument or function result is finalized immedi- 8 ately before it would become undefined due to execution of a RETURN or END statement (16.6.6, item 9 (3)). If the ob ject is defined in a module or submodule, and there are no longer any active procedures 10 referencing the module or submodule, it is processor-dependent whether it is finalized. 11 A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it 12 would become undefined due to termination of the BLOCK construct (16.6.6, item (20)). 13 If an executable construct references a function, the result is finalized after execution of the innermost 14 executable construct containing the reference. 15 If an executable construct references a structure constructor or array constructor, the entity created by 16 the constructor is finalized after execution of the innermost executable construct containing the reference. 17 If a specification expression in a scoping unit references a function, the result is finalized before execution 18 of the executable constructs in the scoping unit. 19 If a specification expression in a scoping unit references a structure constructor or array constructor, the 20 entity created by the constructor is finalized before execution of the executable constructs in the scoping 21 unit. 22 When a procedure is invoked, a nonpointer, nonallocatable ob ject that is an actual argument associated 23 with an INTENT(OUT) dummy argument is finalized. 24 When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr 25 and before the definition of the variable. 26 NOTE 4.51 If finalization is used for storage management, it often needs to be combined with defined assign- ment. If an ob ject is allocated via pointer allocation and later becomes unreachable due to all pointers to that 27 ob ject having their pointer association status changed, it is processor dependent whether it is finalized. 28 If it is finalized, it is processor dependent as to when the final subroutines are called. 29 4.5.6.4 Entities that are not finalized 30 If program execution is terminated, either by an error (e.g. an allocation failure) or by execution of 31 a STOP or END PROGRAM statement, entities existing immediately prior to termination are not 32 finalized. 33 NOTE 4.52 A nonpointer, nonallocatable ob ject that has the SAVE attribute or that occurs in the main pro- gram is never finalized as a direct consequence of the execution of a RETURN or END statement. 72 2006/07/11 WORKING DRAFT J3/06-007 NOTE 4.52 (cont.) 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 1 4.5.7.1 Concepts 2 A nonsequence derived type that does not have the BIND attribute is an extensible typ e. 3 An extensible type that does not have the EXTENDS attribute is a base typ e. A type that has the 4 EXTENDS attribute is an extended typ e. The parent typ e of an extended type is the type named 5 in the EXTENDS attribute specification. 6 NOTE 4.53 The name of the parent type might be a local name introduced via renaming in a USE statement. A base type is an extension typ e of itself only. An extended type is an extension of itself and of all 7 types for which its parent type is an extension. 8 An abstract typ e is a type that has the ABSTRACT attribute. 9 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 ob ject cannot be abstract; therefore, a deferred binding cannot be invoked. An extension of an abstract type need not be abstract if it has no deferred bindings. A short example of an abstract type is: TYPE, ABSTRACT :: FILE_HANDLE CONTAINS PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN ... END TYPE For a more elaborate example see C.1.3. 4.5.7.2 Inheritance 10 An extended type includes all of the type parameters, all of the components, and the nonoverridden 11 (4.5.7.3) nonfinal procedure bindings of its parent type. These are said to be inherited by the extended 12 type from the parent type. They retain all of the attributes that they had in the parent type. Additional 13 type parameters, components, and procedure bindings may be declared in the derived-type definition of 14 the extended type. 15 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. 73 J3/06-007 WORKING DRAFT 2006/07/11 An extended type has a scalar, nonpointer, nonallocatable, parent comp onent with the type and 1 type parameters of the parent type. The name of this component is the parent type name. It has the 2 accessibility of the parent type. Components of the parent component are inheritance asso ciated 3 (16.5.4) with the corresponding components inherited from the parent type. An ancestor comp onent 4 of a type is the parent component of the type or an ancestor component of the parent component. 5 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 END TYPE COLOR_POINT 4.5.7.3 Typ e-b ound pro cedure overriding 6 If a nongeneric binding specified in a type definition has the same binding name as a binding from the 7 parent type then the binding specified in the type definition overrides the one from the parent type. 8 The overriding binding and the overridden binding shall satisfy the following conditions. 9 (1) Either both shall have a passed-ob ject dummy argument or neither shall. 10 (2) If the overridden binding is pure then the overriding binding shall also be pure. 11 (3) Either both shall be elemental or neither shall. 12 (4) They shall have the same number of dummy arguments. 13 (5) Passed-ob ject dummy arguments, if any, shall correspond by name and position. 14 (6) Dummy arguments that correspond by position shall have the same names and characteris- 15 tics, except for the type of the passed-ob ject dummy arguments. 16 (7) Either both shall be subroutines or both shall be functions having the same result charac- 17 teristics (12.3.2). 18 (8) If the overridden binding is PUBLIC then the overriding binding shall not be PRIVATE. 19 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: 74 2006/07/11 WORKING DRAFT J3/06-007 NOTE 4.59 (cont.) REAL FUNCTION POINT_3D_LENGTH ( A, B ) CLASS (POINT_3D), INTENT (IN) :: A CLASS (POINT), INTENT (IN) :: B SELECT TYPE(B) CLASS IS(POINT_3D) POINT_3D_LENGTH = SQRT( (A%X-B%X)**2 + (A%Y-B%Y)**2 + (A%Z-B%Z)**2 ) RETURN END SELECT PRINT *, 'In POINT_3D_LENGTH, dynamic type of argument is incorrect.' STOP END FUNCTION POINT_3D_LENGTH If a generic binding specified in a type definition has the same generic-spec as an inherited binding, it 1 extends the generic interface and shall satisfy the requirements specified in 16.3.4. 2 If a generic binding in a type definition has the same dtio-generic-spec as one inherited from the parent, it 3 extends the type-bound generic interface for dtio-generic-spec and shall satisfy the requirements specified 4 in 16.3.4. 5 A binding of a type and a binding of an extension of that type are said to correspond if the latter binding 6 is the same binding as the former, overrides a corresponding binding, or is an inherited corresponding 7 binding. 8 4.5.8 Derived-typ e values 9 The comp onent value of 10 (1) a pointer component is its pointer association, 11 (2) an allocatable component is its allocation status and, if it is allocated, its dynamic type and 12 type parameters, bounds and value, and 13 (3) a nonpointer nonallocatable component is its value. 14 The set of values of a particular derived type consists of all possible sequences of the component values 15 of its components. 16 4.5.9 Derived-typ e sp ecifier 17 A derived-type specifier is used in several contexts to specify a particular derived type and type param- 18 eters. 19 R458 derived-type-spec is type-name [ ( type-param-spec -list ) ] 20 R459 type-param-spec is [ keyword = ] type-param-value 21 C485 (R458) type-name shall be the name of an accessible derived type. 22 C486 (R458) type-param-spec -list shall appear only if the type is parameterized. 23 C487 (R458) There shall be at most one type-param-spec corresponding to each parameter of the type. 24 If a type parameter does not have a default value, there shall be a type-param-spec corresponding 25 to that type parameter. 26 C488 (R459) The keyword = may be omitted from a type-param-spec only if the keyword = has been 27 75 J3/06-007 WORKING DRAFT 2006/07/11 omitted from each preceding type-param-spec in the type-param-spec -list. 1 C489 (R459) Each keyword shall be the name of a parameter of the type. 2 C490 (R459) An asterisk may be used as a type-param-value in a type-param-spec only in the decla- 3 ration of a dummy argument or associate name or in the allocation of a dummy argument. 4 Type parameter values that do not have type parameter keywords specified correspond to type param- 5 eters in type parameter order (4.5.3.2). If a type parameter keyword is present, the value is assigned to 6 the type parameter named by the keyword. If necessary, the value is converted according to the rules of 7 intrinsic assignment (7.4.1.3) to a value of the same kind as the type parameter. 8 The value of a type parameter for which no type-param-value has been specified is its default value. 9 4.5.10 Construction of derived-typ e values 10 A derived-type definition implicitly defines a corresponding structure constructor that allows con- 11 struction of values of that derived type. The type and type parameters of a constructed value are 12 specified by a derived type specifier. 13 R460 structure-constructor is derived-type-spec ( [ component-spec -list ] ) 14 R461 component-spec is [ keyword = ] component-data-source 15 R462 component-data-source is expr 16 or data-target 17 or proc-target 18 C491 (R460) The derived-type-spec shall not specify an abstract type (4.5.7). 19 C492 (R460) At most one component-spec shall be provided for a component. 20 C493 (R460) If a component-spec is provided for an ancestor component, a component-spec shall not 21 be provided for any component that is inheritance associated with a subcomponent of that 22 ancestor component. 23 C494 (R460) A component-spec shall be provided for a nonallocatable component unless it has default 24 initialization or is inheritance associated with a subcomponent of another component for which 25 a component-spec is provided. 26 C495 (R461) The keyword = may be omitted from a component-spec only if the keyword = has been 27 omitted from each preceding component-spec in the constructor. 28 C496 (R461) Each keyword shall be the name of a component of the type. 29 C497 (R460) The type name and all components of the type for which a component-spec appears shall 30 be accessible in the scoping unit containing the structure constructor. 31 C498 (R460) If derived-type-spec is a type name that is the same as a generic name, the component- 32 spec -list shall not be a valid actual-arg-spec -list for a function reference that is resolvable as a 33 generic reference (12.5.4.1). 34 C499 (R462) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall 35 correspond to a procedure pointer component. 36 C4100 (R462) A data-target shall have the same rank as its corresponding component. 37 76 2006/07/11 WORKING DRAFT J3/06-007 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 . In the absence of a component keyword, each component-data-source is assigned to the corresponding 1 component in component order (4.5.4.6). If a component keyword appears, the expr is assigned to the 2 component named by the keyword. For a nonpointer component, the declared type and type parameters 3 of the component and expr shall conform in the same way as for a variable and expr in an intrinsic 4 assignment statement (7.4.1.2), as specified in Table 7.10. If necessary, each value of intrinsic type is 5 converted according to the rules of intrinsic assignment (7.4.1.3) to a value that agrees in type and type 6 parameters with the corresponding component of the derived type. For a nonpointer nonallocatable 7 component, the shape of the expression shall conform with the shape of the component. 8 If a component with default initialization has no corresponding component-data-source , then the default 9 initialization is applied to that component. If an allocatable component has no corresponding component- 10 data-source , then that component has an allocation status of unallocated. 11 NOTE 4.61 Because no parent components appear in the defined component ordering, a value for a parent component may 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) ! has private components COLOR_POINT( 1, 2, 3) ! All components of TYPE(point) ! need to be accessible. A structure constructor shall not appear before the referenced type is defined. 12 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. /) ) For a pointer component, the corresponding component-data-source shall be an allowable data-target or 13 proc-target for such a pointer in a pointer assignment statement (7.4.2). If the component data source is 14 77 J3/06-007 WORKING DRAFT 2006/07/11 a pointer, the association of the component is that of the pointer; otherwise, the component is pointer 1 associated with the component data source. 2 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 ob ject BIBLIO with the target ob ject TEXT. If a component of a derived type is allocatable, the corresponding constructor expression shall either be 3 a reference to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, 4 or shall evaluate to an entity of the same rank. If the expression is a reference to the intrinsic function 5 NULL, the corresponding component of the constructor has a status of unallocated. If the expression 6 is an allocatable entity, the corresponding component of the constructor has the same allocation status 7 as that allocatable entity and, if it is allocated, the same dynamic type, bounds, and value; if a length 8 parameter of the component is deferred, its value is the same as the corresponding parameter of the 9 expression. Otherwise the corresponding component of the constructor has an allocation status of 10 allocated and has the same bounds and value as the expression. 11 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-typ e op erations and assignment 12 Intrinsic assignment of derived-type entities is described in 7.4.1. This part of ISO/IEC 1539 does 13 not specify any intrinsic operations on derived-type entities. Any operation on derived-type entities 14 or defined assignment (7.4.1.4) for derived-type entities shall be defined explicitly by a function or a 15 subroutine, and a generic interface (4.5.2, 12.4.2.1). 16 4.6 Enumerations and enumerators 17 An enumeration is a set of enumerators. An enumerator is a named integer constant. An enumeration 18 definition specifies the enumeration and its set of enumerators of the corresponding integer kind. 19 R463 enum-def is enum-def-stmt 20 enumerator-def-stmt 21 [ enumerator-def-stmt ] ... 22 end-enum-stmt 23 R464 enum-def-stmt is ENUM, BIND(C) 24 R465 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator -list 25 78 2006/07/11 WORKING DRAFT J3/06-007 R466 enumerator is named-constant [ = scalar-int-initialization-expr ] 1 R467 end-enum-stmt is END ENUM 2 C4101 (R465) If = appears in an enumerator , a double-colon separator shall appear before the enu- 3 merator -list. 4 For an enumeration, the kind is selected such that an integer type with that kind is interoperable (15.3.2) 5 with the corresponding C enumeration type. The corresponding C enumeration type is the type that 6 would be declared by a C enumeration specifier (6.7.2.2 of the C International Standard) that specified 7 C enumeration constants with the same values as those specified by the enum-def , in the same order as 8 specified by the enum-def . 9 The companion processor (2.5.10) shall be one that uses the same representation for the types declared 10 by all C enumeration specifiers that specify the same values in the same order. 11 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 values of any such enumerators will be interoperable with the values 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 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. An enumerator is treated as if it were explicitly declared with the PARAMETER attribute. The enu- 12 merator is defined in accordance with the rules of intrinsic assignment (7.4) with the value determined 13 as follows. 14 (1) If scalar-int-initialization-expr is specified, the value of the enumerator is the result of 15 scalar-int-initialization-expr . 16 (2) If scalar-int-initialization-expr is not specified and the enumerator is the first enumerator 17 in enum-def , the enumerator has the value 0. 18 (3) If scalar-int-initialization-expr is not specified and the enumerator is not the first enumer- 19 ator in enum-def , its value is the result of adding 1 to the value of the enumerator that 20 immediately precedes it in the enum-def . 21 NOTE 4.69 Example of an enumeration definition: ENUM, BIND(C) ENUMERATOR :: RED = 4, BLUE = 9 ENUMERATOR YELLOW END ENUM 79 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 4.69 (cont.) 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 1 An array constructor is defined as a sequence of scalar values and is interpreted as a rank-one array 2 where the element values are those specified in the sequence. 3 R468 array-constructor is (/ ac-spec /) 4 or lbracket ac-spec rbracket 5 R469 ac-spec is type-spec :: 6 or [type-spec ::] ac-value -list 7 R470 lbracket is [ 8 R471 rbracket is ] 9 R472 ac-value is expr 10 or ac-implied-do 11 R473 ac-implied-do is ( ac-value -list , ac-implied-do-control ) 12 R474 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr 13 [ , scalar-int-expr ] 14 R475 ac-do-variable is do-variable 15 C4102 (R469) If type-spec is omitted, each ac-value expression in the array-constructor shall have the 16 same type and kind type parameters. 17 C4103 (R469) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor 18 shall be of an intrinsic type that is in type conformance with a variable of type type-spec as 19 specified in Table 7.10. 20 C4104 (R469) If type-spec specifies a derived type, all ac-value expressions in the array-constructor 21 shall be of that derived type and shall have the same kind type parameter values as specified by 22 type-spec . 23 C4105 (R473) The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear 24 as the ac-do-variable of the containing ac-implied-do . 25 If type-spec is omitted, each ac-value expression in the array constructor shall have the same length type 26 parameters; in this case, the type and type parameters of the array constructor are those of the ac-value 27 expressions. 28 80 2006/07/11 WORKING DRAFT J3/06-007 If type-spec appears, it specifies the type and type parameters of the array constructor. Each ac-value 1 expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this 2 type and type parameters. Each value is converted to the type parameters of the array-constructor in 3 accordance with the rules of intrinsic assignment (7.4.1.3). 4 The character length of an ac-value in an ac-implied-do whose iteration count is zero shall not depend 5 on the value of the ac-do-variable and shall not depend on the value of an expression that is not an 6 initialization expression. 7 If an ac-value is a scalar expression, its value specifies an element of the array constructor. If an ac- 8 value is an array expression, the values of the elements of the expression, in array element order (6.2.2.2), 9 specify the corresponding sequence of elements of the array constructor. If an ac-value is an ac-implied- 10 do , it is expanded to form a sequence of elements under the control of the ac-do-variable , as in the DO 11 construct (8.1.7.5). 12 For an ac-implied-do , the loop initialization and execution is the same as for a DO construct. 13 An empty sequence forms a zero-sized rank-one array. 14 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) 81 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 4.74 (cont.) 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 the constants with the same character length. 82 2006/07/11 WORKING DRAFT J3/06-007 5 Attribute declarations and sp ecifications 1 5.1 General 2 Every data ob ject has a type and rank and may have type parameters and other attributes that determine 3 the uses of the ob ject. Collectively, these properties are the attributes of the ob ject. The type of a 4 named data ob ject is either specified explicitly in a type declaration statement or determined implicitly 5 by the first letter of its name (5.5). All of its attributes may be specified in a type declaration statement 6 or individually in separate specification statements. 7 A function has a type and rank and may have type parameters and other attributes that determine the 8 uses of the function. The type, rank, and type parameters are the same as those of its result variable. 9 A subroutine does not have a type, rank, or type parameters, but may have other attributes that 10 determine the uses of the subroutine. 11 5.2 Typ e declaration statements 12 5.2.1 Syntax 13 R501 type-declaration-stmt is declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl -list 14 The type declaration statement specifies the type of the entities in the entity declaration list. The type 15 and type parameters are those specified by declaration-type-spec , except that the character length type 16 parameter may be overridden for an entity by the appearance of * char-length in its entity-decl . 17 R502 attr-spec is access-spec 18 or ALLOCATABLE 19 or ASYNCHRONOUS 20 or CONTIGUOUS 21 or dimension-spec 22 or EXTERNAL 23 or INTENT ( intent-spec ) 24 or INTRINSIC 25 or language-binding-spec 26 or OPTIONAL 27 or PARAMETER 28 or POINTER 29 or PROTECTED 30 or SAVE 31 or TARGET 32 or VALUE 33 or VOLATILE 34 35 C501 (R501) The same attr-spec shall not appear more than once in a given type-declaration-stmt . 36 C502 (R501) If a language-binding-spec with a NAME= specifier appears, the entity-decl -list shall 37 consist of a single entity-decl . 38 C503 (R501) If a language-binding-spec is specified, the entity-decl -list shall not contain any procedure 39 83 J3/06-007 WORKING DRAFT 2006/07/11 names. 1 The type declaration statement also specifies the attributes whose keywords appear in the attr-spec , 2 except that the DIMENSION attribute may be specified or overridden for an entity by the appearance 3 of array-spec in its entity-decl . 4 R503 entity-decl is object-name [( array-spec )] 5 [ lbracket co-array-spec rbracket ] 6 [ * char-length ] [ initialization ] 7 or function-name [ * char-length ] 8 C504 (R503) If the entity is not of type character, * char-length shall not appear. 9 C505 (R501) If initialization appears, a double-colon separator shall appear before the entity-decl -list. 10 C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, 11 an ob ject in a named common block unless the type declaration is in a block data program unit, 12 an ob ject in blank common, an allocatable variable, an external function, an intrinsic function, 13 or an automatic ob ject. 14 C507 (R503) An initialization shall appear if the entity is a named constant (5.3.12). 15 C508 (R503) The function-name shall be the name of an external function, an intrinsic function, a 16 function dummy procedure, a procedure pointer, or a statement function. 17 R504 object-name is name 18 C509 (R504) The object-name shall be the name of a data ob ject. 19 R505 initialization is = initialization-expr 20 or => nul l-init 21 or => initial-data-target 22 R506 nul l-init is function-reference 23 C510 (R503) If => appears in initialization , the entity shall have the POINTER attribute. If = 24 appears in initialization , the entity shall not have the POINTER attribute. 25 C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible 26 with it (4.5.4.5). 27 C512 (R506) The function-reference shall be a reference to the NULL intrinsic function with no 28 arguments. 29 A name that identifies a specific intrinsic function in a scoping unit has a type as specified in 13.6. An 30 explicit type declaration statement is not required; however, it is permitted. Specifying a type for a 31 generic intrinsic function name in a type declaration statement is not sufficient, by itself, to remove the 32 generic properties from that function. 33 An automatic data ob ject is a nondummy data ob ject with a type parameter or array bound that 34 depends on the value of a specification-expr that is not an initialization expression. 35 NOTE 5.1 An automatic ob ject shall not have the SAVE attribute and shall not appear in a common block. If a type parameter in a declaration-type-spec or in a char-length in an entity-decl is defined by an 36 expression that is not an initialization expression, the type parameter value is established on entry to 37 the procedure and is not affected by any redefinition or undefinition of the variables in the expression 38 84 2006/07/11 WORKING DRAFT J3/06-007 during execution of the procedure. 1 5.2.2 Initialization 2 The appearance of initialization in an entity-decl for an entity without the PARAMETER attribute 3 specifies that the entity is a variable with explicit initialization. Explicit initialization alternatively 4 may be specified in a DATA statement unless the variable is of a derived type for which default initial- 5 ization is specified. If initialization is =initialization-expr , the variable is initially defined with the value 6 specified by the initialization-expr ; if necessary, the value is converted according to the rules of intrinsic 7 assignment (7.4.1.3) to a value that agrees in type, type parameters, and shape with the variable. A 8 variable, or part of a variable, shall not be explicitly initialized more than once in a program. If the 9 variable is an array, it shall have its shape specified in either the type declaration statement or a previous 10 attribute specification statement in the same scoping unit. 11 If nul l-init appears, the initial association status of the ob ject is disassociated. If initial-data-target 12 appears, the ob ject is initially associated with the target. 13 Explicit initialization of a variable that is not in a common block implies the SAVE attribute, which 14 may be confirmed by explicit specification. 15 5.2.3 Examples of typ e declaration statements 16 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.) 5.3 Attributes 17 5.3.1 Constraints 18 An attribute may be explicitly specified by an attr-spec in a type declaration statement or by an attribute 19 specification statement (5.4). The following constraints apply to attributes. 20 C513 An entity shall not be explicitly given any attribute more than once in a scoping unit. 21 C514 An array-spec for a function result that does not have the ALLOCATABLE or POINTER 22 attribute shall be an explicit-shape-spec -list. 23 C515 The ALLOCATABLE, POINTER, or OPTIONAL attribute shall not be specified for a dummy 24 85 J3/06-007 WORKING DRAFT 2006/07/11 argument of a procedure that has a proc-language-binding-spec . 1 5.3.2 Accessibility attribute 2 The accessibility attribute specifies the accessibility of an entity via a particular identifier. 3 R507 access-spec is PUBLIC 4 or PRIVATE 5 C516 (R507) An access-spec shall appear only in the specification-part of a module. 6 Identifiers that are specified in a module or accessible in that module by use association have either 7 the PUBLIC or PRIVATE attribute. Identifiers for which an access-spec is not explicitly specified in 8 that module have the default accessibility attribute for that module. The default accessibility attribute 9 for a module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only identifiers 10 that have the PUBLIC attribute in that module are available to be accessed from that module by use 11 association. 12 NOTE 5.3 In order for an identifier to be accessed by use association, it must have the PUBLIC attribute in the module from which it is accessed. It can nonetheless have the PRIVATE attribute in a module in which it is accessed by use association, and therefore not be available for use association from a module where it is PRIVATE. NOTE 5.4 An example of an accessibility specification is: REAL, PRIVATE :: X, Y, Z 5.3.3 ALLOCATABLE attribute 13 An entity with the ALLOCATABLE attribute is a variable for which space is allocated by an AL- 14 LOCATE statement (6.3.1) or by an intrinsic assignment statement (7.4.1.3). 15 5.3.4 ASYNCHRONOUS attribute 16 An entity with the ASYNCHRONOUS attribute is a variable that may be sub ject to asynchronous 17 input/output. 18 The base ob ject of a variable shall have the ASYNCHRONOUS attribute in a scoping unit if 19 (1) the variable appears in an executable statement or specification expression in that scoping 20 unit and 21 (2) any statement of the scoping unit is executed while the variable is a pending I/O storage 22 sequence affector (9.5.1.4). 23 Use of a variable in an asynchronous input/output statement can imply the ASYNCHRONOUS attribute; 24 see subclause (9.5.1.4). 25 An ob ject may have the ASYNCHRONOUS attribute in a particular scoping unit without necessarily 26 having it in other scoping units (11.2.1, 16.5.1.4). If an ob ject has the ASYNCHRONOUS attribute, 27 then all of its subob jects also have the ASYNCHRONOUS attribute. 28 86 2006/07/11 WORKING DRAFT J3/06-007 NOTE 5.5 The ASYNCHRONOUS attribute specifies the variables that might be associated with a pending input/output storage sequence (the actual memory locations on which asynchronous input/output is being performed) while the scoping unit is in execution. This information could be used by the compiler to disable certain code motion optimizations. The ASYNCHRONOUS attribute is similar to the VOLATILE attribute. It is intended to facilitate traditional code motion optimizations in the presence of asynchronous input/output. 5.3.5 BIND attribute for data entities 1 The BIND attribute for a variable or common block specifies that it is capable of interoperating with a 2 C variable that has external linkage (15.4). 3 R508 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) 4 C517 An entity with the BIND attribute shall be a common block, variable, or procedure. 5 C518 A variable with the BIND attribute shall be declared in the specification part of a module. 6 C519 A variable with the BIND attribute shall be interoperable (15.3). 7 C520 Each variable of a common block with the BIND attribute shall be interoperable. 8 C521 (R508) The scalar-char-initialization-expr shall be of default character kind. If the value of the 9 scalar-char-initialization-expr after discarding leading and trailing blanks has nonzero length, 10 it shall be valid as an identifier on the companion processor. 11 NOTE 5.6 The C International Standard provides a facility for creating C identifiers whose characters are not restricted to the C basic character set. Such a C identifier is referred to as a universal character name (6.4.3 of the C International Standard). The name of such a C identifier might include characters that are not part of the representation method used by the processor for type default character. If so, the C entity cannot be referenced from Fortran. The BIND attribute for a variable or common block implies the SAVE attribute, which may be confirmed 12 by explicit specification. 13 5.3.6 CONTIGUOUS attribute 14 C522 An entity that has the CONTIGUOUS attribute shall be an array pointer or an assumed-shape 15 array. 16 The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated 17 with a contiguous ob ject, or that an array pointer can only be pointer associated with a contiguous target. 18 An ob ject is contiguous if it is not the real or imaginary part of an array of type complex, and is: 19 (1) an ob ject with the CONTIGUOUS attribute, 20 (2) a scalar ob ject, 21 (3) a nonpointer array that is not assumed-shape, 22 (4) an array allocated by an ALLOCATE statement, 23 (5) an assumed-shape array that is argument associated with an array that is contiguous, 24 (6) a pointer associated with a contiguous target, 25 87 J3/06-007 WORKING DRAFT 2006/07/11 (7) an array with at most one element, or 1 (8) a nonzero-sized array section (6.2.2) with the following properties: 2 (a) Its base ob ject is contiguous. 3 (b) It does not have a vector subscript. 4 (c) The elements of the section, in array element order, are a subset of the base ob ject 5 elements that are consecutive in array element order. 6 (d) If the array is of type character and a substring-range appears, the substring-range 7 specifies all of the characters of the parent-string (6.1.1). 8 (e) Only its final part-ref has nonzero rank. 9 J3 internal note Unresolved Technical Issue 11 The above list (CONTIGUOUS definition) does not conform to the ISO guidelines. An ob ject is not contiguous if it is an array subob ject, and 10 (1) the ob ject has two or more elements, 11 (2) the elements of the ob ject in array element order are not consecutive in the elements of the 12 base ob ject, 13 (3) the ob ject is not of type character with length zero, and 14 (4) the ob ject is not of a derived type that has no ultimate components other than zero-sized 15 arrays and characters with length zero. 16 It is processor-dependent whether any other ob ject is contiguous. 17 NOTE 5.7 If a derived type has only one component that is not zero-sized, it is processor-dependent whether a structure component of a contiguous array of that type is contiguous. That is, the derived type might contain padding on some processors. NOTE 5.8 The CONTIGUOUS attribute allows a processor to enable optimizations that depend on the memory layout of the ob ject occupying a contiguous block of memory. Examples of CONTIGUOUS attribute specifications are: REAL, POINTER, CONTIGUOUS :: SPTR(:) REAL, CONTIGUOUS, DIMENSION(:,:) :: D 5.3.7 DIMENSION attribute 18 5.3.7.1 General 19 The DIMENSION attribute specifies that an entity is an array, a co-array, or both. If an array-spec 20 appears, it is an array. If a co-array-spec appears, it is a co-array. 21 For an array, its array-spec specifies its rank or rank and shape. For a co-array, its co-array-spec specifies 22 its co-rank or co-rank and co-bounds. 23 The co-b ounds are given within square brackets in the co-array's declaration or allocation. If the co- 24 rank is r, the co-array has lower co-bounds li , i = 1, 2, ..., r, upper co-bounds ui , i = 1, 2, ..., r - 1, and 25 co-extents ui - li + 1, i = 1, 2, ..., r - 1. 26 88 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 12 The last sentence "... the co-array has lower co-bounds ..." is meaningless gibberish. Whence came these li et al? Not from around here as far as I see... Furthermore, it probably belongs somewhere else. Why is there not a specific subclause for co- array declarations? Surely if assumed-size arrays warrant their own subclause, co-arrays ought not to be lumped in with the general part of arrays. NOTE 5.9 Unless it is a dummy argument, a co-array has the same bounds and co-bounds on every image. See Note 12.28 for further discussion of the bounds and co-bounds of dummy co-arrays. R509 dimension-spec is DIMENSION ( array-spec ) 1 or DIMENSION [ ( array-spec ) ] lbracket co-array-spec rbracket 2 C523 (R501) A co-array that has the ALLOCATABLE attribute shall be specified with a co-array-spec 3 that is a deferred-shape-spec -list. 4 C524 A co-array shall be a component or a variable that is not a function result. 5 C525 An entity whose type has a co-array ultimate component shall be a nonpointer nonallocatable 6 scalar, shall not be a co-array, and shall not be a function result. 7 NOTE 5.10 A co-array is permitted to be of a derived type with pointer or allocatable components. The target of such a pointer component is always on the same image. An allocatable component of a co-array need be allocated on an image only if it is referenced or defined. R510 array-spec is explicit-shape-spec -list 8 or assumed-shape-spec -list 9 or deferred-shape-spec -list 10 or assumed-size-spec 11 or implied-shape-spec -list 12 R511 co-array-spec is deferred-shape-spec -list 13 or assumed-size-spec 14 J3 internal note Unresolved Technical Issue 13 This does not work, because there are no semantics for the use of the syntax terms deferred-shape- spec -list and assumed-size-spec out of their array-spec context. (In so far as there are semantics, they specify array bounds not co-array co-bounds.) C526 The sum of the rank and co-rank of an entity shall not exceed fifteen. 15 NOTE 5.11 Examples of DIMENSION attribute specifications are: SUBROUTINE EX (N, A, B) REAL, DIMENSION (N, 10) :: W ! Automatic explicit-shape array REAL A (:), B (0:) ! Assumed-shape arrays 89 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 5.11 (cont.) REAL, POINTER :: D (:, :) ! Array pointer REAL, DIMENSION (:), POINTER :: P ! Array pointer REAL, ALLOCATABLE, DIMENSION (:) :: E ! Allocatable array REAL, PARAMETER :: V(0:*) = [0.1, 1.1] ! Implied-shape array 5.3.7.2 Explicit-shap e array 1 An explicit-shap e array is a named array that is declared with an explicit-shape-spec -list. This specifies 2 explicit values for the bounds in each dimension of the array. 3 R512 explicit-shape-spec is [ lower-bound : ] upper-bound 4 R513 lower-bound is specification-expr 5 R514 upper-bound is specification-expr 6 C527 (R512) An explicit-shape-spec whose bounds are not initialization expressions shall appear only 7 in a subprogram or interface body. 8 If an explicit-shape array has bounds that are not initialization expressions, the bounds, and hence 9 shape, are determined at entry to the procedure by evaluating the bounds expressions. The bounds of 10 such an array are unaffected by the redefinition or undefinition of any variable during execution of the 11 procedure. 12 The values of each lower-bound and upper-bound determine the bounds of the array along a particular 13 dimension and hence the extent of the array in that dimension. The value of a lower bound or an upper 14 bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set 15 of integer values between and including the lower and upper bounds, provided the upper bound is not 16 less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the 17 extent in that dimension is zero, and the array is of zero size. If the lower-bound is omitted, the default 18 value is 1. The rank is equal to the number of explicit-shape-spec s. 19 5.3.7.3 Assumed-shap e array 20 An assumed-shap e array is a nonpointer dummy argument array that takes its shape from the asso- 21 ciated actual argument array. 22 R515 assumed-shape-spec is [ lower-bound ] : 23 The rank is equal to the number of colons in the assumed-shape-spec -list. 24 The extent of a dimension of an assumed-shape array dummy argument is the extent of the corresponding 25 dimension of the associated actual argument array. If the lower bound value is d and the extent of the 26 corresponding dimension of the associated actual argument array is s, then the value of the upper bound 27 is s + d - 1. If lower-bound appears it specifies the lower bound; otherwise the lower bound is 1. 28 5.3.7.4 Deferred-shap e array 29 A deferred-shap e array is an allocatable array or an array pointer. 30 An allo catable array is an array that has the ALLOCATABLE attribute and a specified rank, but its 31 bounds, and hence shape, are determined by allocation or argument association. 32 An array p ointer is an array with the POINTER attribute and a specified rank. Its bounds, and hence 33 shape, are determined when it is associated with a target. 34 90 2006/07/11 WORKING DRAFT J3/06-007 R516 deferred-shape-spec is : 1 C528 An array that has the POINTER or ALLOCATABLE attribute shall have an array-spec that is 2 a deferred-shape-spec -list. 3 The rank is equal to the number of colons in the deferred-shape-spec -list. 4 The size, bounds, and shape of an unallocated allocatable array or a disassociated array pointer are 5 undefined. No part of such an array shall be referenced or defined; however, the array may appear as an 6 argument to an intrinsic inquiry function as specified in 13.1. 7 The bounds of each dimension of an allocatable array are those specified when the array is allocated. 8 The bounds of each dimension of an array pointer may be specified in two ways: 9 (1) in an ALLOCATE statement (6.3.1) when the target is allocated; 10 (2) by pointer assignment (7.4.2). 11 The bounds of the array pointer or allocatable array are unaffected by any subsequent redefinition or 12 undefinition of variables on which the bounds' expressions depend. 13 5.3.7.5 Assumed-size array 14 An assumed-size array is a dummy argument array whose size is assumed from that of an associated 15 actual argument. The rank and extents may differ for the actual and dummy arrays; only the size of the 16 actual array is assumed by the dummy array. An assumed-size array is declared with an assumed-size- 17 spec. 18 R517 assumed-size-spec is [ explicit-shape-spec -list , ] [ lower-bound : ] * 19 C529 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy 20 data argument. 21 C530 An assumed-size array with INTENT (OUT) shall not be polymorphic, ofa finalizable type, of 22 a type with an ultimate allocatable component, or of a type for which default initialization is 23 specified. 24 The size of an assumed-size array is determined as follows. 25 (1) If the actual argument associated with the assumed-size dummy array is an array of any 26 type other than default character, the size is that of the actual array. 27 (2) If the actual argument associated with the assumed-size dummy array is an array element 28 of any type other than default character with a subscript order value of r (6.2.2.2) in an 29 array of size x, the size of the dummy array is x - r + 1. 30 (3) If the actual argument is a default character array, default character array element, or a 31 default character array element substring (6.1.1), and if it begins at character storage unit t 32 of an array with c character storage units, the size of the dummy array is MAX (INT ((c - 33 t + 1)/e), 0), where e is the length of an element in the dummy character array. 34 (4) If the actual argument is of type default character and is a scalar that is not an array element 35 or array element substring designator, the size of the dummy array is MAX (INT (l/e), 0), 36 where e is the length of an element in the dummy character array and l is the length of the 37 actual argument. 38 The rank is equal to one plus the number of explicit-shape-spec s. 39 An assumed-size array has no upper bound in its last dimension and therefore has no extent in its last 40 dimension and no shape. An assumed-size array name shall not be written as a whole array reference 41 except as an actual argument in a procedure reference for which the shape is not required. 42 91 J3/06-007 WORKING DRAFT 2006/07/11 If an explicit-shape-spec -list appears, it specifies the bounds of the first rank -1 dimensions. If lower- 1 bound appears it specifies the lower bound of the last dimension; otherwise that lower bound is 1. An 2 assumed-size array may be subscripted or sectioned (6.2.2.3). The upper bound shall not be omitted 3 from a subscript triplet in the last dimension. 4 If an assumed-size array has bounds that are not initialization expressions, the bounds are determined 5 at entry to the procedure. The bounds of such an array are unaffected by the redefinition or undefinition 6 of any variable during execution of the procedure. 7 5.3.7.6 Implied-shap e array 8 An implied-shap e array is a named constant that takes its shape from the initialization-expr in its 9 declaration. An implied-shape array is declared with an implied-shape-spec -list. 10 R518 implied-shape-spec is [ lower-bound : ] * 11 C531 An implied-shape array shall be a named constant. 12 The rank of an implied-shape array is the number of implied-shape-spec s in the implied-shape-spec -list. 13 The extent of each dimension of an implied-shape array is the same as the extent of the corresponding 14 dimension of the initialization-expr . The lower bound of each dimension is lower-bound , if it appears, 15 and 1 otherwise; the upper bound is one less than the sum of the lower bound and the extent. 16 5.3.8 EXTERNAL attribute 17 The EXTERNAL attribute specifies that an entity is an external procedure, dummy procedure, 18 procedure pointer, or block data subprogram. 19 C532 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. 20 In an external subprogram, the EXTERNAL attribute shall not be specified for a procedure defined by 21 the subprogram. 22 If an external procedure or dummy procedure is used as an actual argument or is the target of a procedure 23 pointer assignment, it shall be declared to have the EXTERNAL attribute. 24 A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer. 25 5.3.9 INTENT attribute 26 The INTENT attribute specifies the intended use of a dummy argument. An INTENT (IN) dummy 27 argument is suitable for receiving data from the invoking scoping unit, an INTENT (OUT) dummy 28 argument is suitable for returning data to the invoking scoping unit, and an INTENT (INOUT) dummy 29 argument is suitable for use both to receive data from and to return data to the invoking scoping unit. 30 R519 intent-spec is IN 31 or OUT 32 or INOUT 33 C533 An entity with the INTENT attribute shall be a dummy data ob ject or a dummy procedure 34 pointer. 35 C534 (R519) A nonpointer ob ject with the INTENT (IN) attribute shall not appear in a variable 36 definition context (16.6.7). 37 C535 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context 38 92 2006/07/11 WORKING DRAFT J3/06-007 (16.6.8). 1 The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be de- 2 fined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a 3 pointer dummy argument specifies that during the execution of the procedure its association shall not 4 be changed except that it may become undefined if the target is deallocated other than through the 5 pointer (16.5.2.2.3). 6 The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument 7 becomes undefined on invocation of the procedure, except for any subcomponents that are default- 8 initialized (4.5.4.5). Any actual argument that becomes associated with such a dummy argument shall 9 be definable. The INTENT (OUT) attribute for a pointer dummy argument specifies that on invocation 10 of the procedure the pointer association status of the dummy argument becomes undefined. Any actual 11 argument associated with such a pointer dummy shall be a pointer variable. 12 NOTE 5.12 If the actual argument is finalizable it will be finalized before undefinition and default initialization of the dummy argument (4.5.6). The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument 13 associated with the dummy argument shall be definable. The INTENT (INOUT) attribute for a pointer 14 dummy argument specifies that any actual argument associated with the dummy argument shall be a 15 pointer variable. 16 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). If no INTENT attribute is specified for a dummy argument, its use is sub ject to the limitations of the 17 argument associated entity (12.5.1.4, 12.5.1.6, 12.5.1.7). 18 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 If an ob ject has an INTENT attribute, then all of its subob jects have the same INTENT attribute. 19 NOTE 5.15 If a dummy argument is a derived-type ob ject with a pointer component, then the pointer as a pointer is a subob ject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subob jects of the dummy ob ject 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 93 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 5.15 (cont.) is prohibited, but X%P = 0 is allowed (provided that X%P is associated with a definable target). Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target. NOTE 5.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 there is any possibility that an argument should retain its current value rather than being redefined, INTENT (INOUT) should be used rather than INTENT (OUT), even if there is no explicit reference to the value of the dummy argument. Because an INTENT(OUT) variable is considered undefined on entry to the procedure, any default initialization specified for its type will be applied. INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The actual argument corresponding to an INTENT (INOUT) dummy argument is always required to be definable, while an argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. 5.3.10 INTRINSIC attribute 1 The INTRINSIC attribute specifies that the entity is an intrinsic procedure. It may be a generic 2 procedure (13.5), a specific procedure (13.6), or both. 3 If the specific name of an intrinsic procedure (13.6) is used as an actual argument, the name shall be 4 explicitly specified to have the INTRINSIC attribute. An intrinsic procedure whose specific name is 5 marked with a bullet (·) in 13.6 shall not be used as an actual argument. 6 C536 If the name of a generic intrinsic procedure is explicitly declared to have the INTRINSIC at- 7 tribute, and it is also the generic name of one or more generic interfaces (12.4.2.1) accessible in 8 the same scoping unit, the procedures in the interfaces and the specific intrinsic procedures shall 9 all be functions or all be subroutines, and the characteristics of the specific intrinsic procedures 10 and the procedures in the interfaces shall differ as specified in 16.3.4. 11 5.3.11 OPTIONAL attribute 12 The OPTIONAL attribute specifies that the dummy argument need not be associated with an actual 13 argument in a reference to the procedure (12.5.1.9). The PRESENT intrinsic function can be used to 14 94 2006/07/11 WORKING DRAFT J3/06-007 determine whether an optional dummy argument is associated with an actual argument. 1 C537 An entity with the OPTIONAL attribute shall be a dummy argument. 2 5.3.12 PARAMETER attribute 3 The PARAMETER attribute specifies that an entity is a named constant. The entity has the value 4 specified by its initialization-expr , converted, if necessary, to the type, type parameters and shape of the 5 entity. 6 C538 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. 7 A named constant shall not be referenced unless it has been defined previously in the same statement, 8 defined in a prior statement, or made accessible by use or host association. 9 NOTE 5.17 Examples of declarations with a PARAMETER attribute are: REAL, PARAMETER :: ONE = 1.0, Y = 4.1 / 3.0 INTEGER, DIMENSION (3), PARAMETER :: ORDER = (/ 1, 2, 3 /) TYPE(NODE), PARAMETER :: DEFAULT = NODE(0, NULL ( )) 5.3.13 POINTER attribute 10 Entities with the POINTER attribute can be associated with different data ob jects or procedures 11 during execution of a program. A pointer is either a data pointer or a procedure pointer. Procedure 12 pointers are described in 12.4.2.3. 13 C539 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or 14 TARGET attribute. 15 C540 A procedure with the POINTER attribute shall have the EXTERNAL attribute. 16 C541 A co-array shall not have the POINTER attribute. 17 A data pointer shall not be referenced unless it is pointer associated with a target ob ject that is defined. 18 A data pointer shall not be defined unless it is pointer associated with a target ob ject that is definable. 19 If a data pointer is associated, the values of its deferred type parameters are the same as the values of 20 the corresponding type parameters of its target. 21 A procedure pointer shall not be referenced unless it is pointer associated with a target procedure. 22 NOTE 5.18 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. 95 J3/06-007 WORKING DRAFT 2006/07/11 5.3.14 PROTECTED attribute 1 The PROTECTED attribute imposes limitations on the usage of module entities. 2 C542 The PROTECTED attribute shall be specified only in the specification part of a module. 3 C543 An entity with the PROTECTED attribute shall be a procedure pointer or variable. 4 C544 An entity with the PROTECTED attribute shall not be in a common block. 5 C545 A nonpointer ob ject that has the PROTECTED attribute and is accessed by use association 6 shall not appear in a variable definition context (16.6.7) or as the data-target or proc-target in 7 a pointer-assignment-stmt . 8 C546 A pointer that has the PROTECTED attribute and is accessed by use association shall not 9 appear in a pointer association context (16.6.8). 10 Other than within the module in which an entity is given the PROTECTED attribute, or within any of 11 its descendants, 12 (1) if it is a nonpointer ob ject, it is not definable, and 13 (2) if it is a pointer, its association status shall not be changed except that it may become 14 undefined if its target is deallocated other than through the pointer (16.5.2.2.3) or if its 15 target becomes undefined by execution of a RETURN or END statement. 16 If an ob ject has the PROTECTED attribute, all of its subob jects have the PROTECTED attribute. 17 NOTE 5.19 An example of the PROTECTED attribute: MODULE temperature REAL, PROTECTED :: temp_c, temp_f CONTAINS SUBROUTINE set_temperature_c(c) REAL, INTENT(IN) :: c temp_c = c temp_f = temp_c*(9.0/5.0) + 32 END SUBROUTINE END MODULE The PROTECTED attribute ensures that the variables temp c and temp f cannot be modified other than via the set temperature c procedure, thus keeping them consistent with each other. 5.3.15 SAVE attribute 18 The SAVE attribute specifies that a variable retains its association status, allocation status, definition 19 status, and value after execution of a RETURN or END statement unless it is a pointer and its target 20 becomes undefined (16.5.2.2.3(4)). If it is a local variable of a subprogram it is shared by all instances 21 (12.6.2.3) of the subprogram. 22 Giving a common block the SAVE attribute confers the attribute on all variables in the common block. 23 C547 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. 24 C548 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic 25 96 2006/07/11 WORKING DRAFT J3/06-007 data ob ject, or an ob ject that is in a common block. 1 C549 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared 2 in the main program, or allocatable and declared in a non-recursive procedure. 3 NOTE 5.20 An allocatable co-array is required to have the SAVE attribute in a recursive procedure because of the difficulties associated with defining the separate levels of recursion. Without the SAVE attribute, each would have a separate instance of the co-array and implicit synchronization would be required for each allocation and deallocation of each instance. 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 not dummy arguments are required to have the SAVE attribute because otherwise they might be implemented as if they were automatic co-arrays. J3 internal note Unresolved Technical Issue 8 This text about about automatic co-arrays not being permitted because of putative implicit synchronisation absolutely does NOT belong here (in the SAVE attribute), nor did it belong where 06-174r3 said to insert it (in the middle of a 2-page list of constraints!). Co-arrays probably need their own subclause and it can go there. Pity they didn't use the CODIMENSION keyword instead of hijacking the DIMENSION keyword, then it would be a lot tidier with things having a rather obvious home. Furthermore, the last sentence is incorrect, because not all explicit-shape co-arrays are required to have the SAVE attribute, viz ones declared in the main program. J3 internal note Unresolved Technical Issue 9 The note says that allocatable co-arrays have to be (inconsistently) saved, "because of the diffi- culties associated with defining the separate levels of recursion". That is utter nonsense. 12.5.2.3 "Instances of a subprogram" was in F2003 already. If there were such difficulties, we wouldn't be able to have host association in recursive procedures (there since F90), or to pass internal procedures (of recursive procedures) as actual arguments (new in F2008). C550 (R501) If the type specified has a co-array ultimate component, each entity in the entity-decl -list 4 shall have the SAVE attribute unless it is a dummy argument, declared in the main program, 5 or declared in a non-recursive procedure. 6 97 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 10 This is inconsistent. (1) We require the user to SAVE variables in non-recursive procedures if he wants the value to persist. (2) ALLOCATABLE arrays that are unsaved get deallocated in non-recursive proce- dures, not saved. (3) It requires SAVE in a MODULE, but not in a non-recursive procedure!?! If you are going to special-case ANYTHING, doing it for modules must be top priority, but it's better to avoid it entirely. A saved entity is an entity that has the SAVE attribute. An unsaved entity is an entity that does not 1 have the SAVE attribute. 2 The SAVE attribute has no effect on entities declared in a main program. If a common block has the 3 SAVE attribute in any scoping unit that is not a main program, it shall have the SAVE attribute in 4 every scoping unit that is not a main program. 5 5.3.16 TARGET attribute 6 The TARGET attribute specifies that a data ob ject may have a pointer associated with it (7.4.2). 7 An ob ject without the TARGET attribute shall not have an accessible pointer associated with it. 8 C551 An entity with the TARGET attribute shall be a variable. 9 C552 An entity with the TARGET attribute shall not have the POINTER attribute. 10 NOTE 5.21 In addition to variables explicitly declared to have the TARGET attribute, the ob jects created by allocation of pointers (6.3.1.2) have the TARGET attribute. If an ob ject has the TARGET attribute, then all of its nonpointer subob jects also have the TARGET 11 attribute. 12 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 ob ject designator that starts from a target ob ject will have either the TARGET or POINTER attribute. If pointers are involved, the designator might not necessarily be a subob ject of the original target ob ject, but because pointers may point only to targets, there is no way to end up at a nonpointer that is not a target. 98 2006/07/11 WORKING DRAFT J3/06-007 5.3.17 VALUE attribute 1 The VALUE attribute specifies a type of argument association (12.5.1.4) for a dummy argument. 2 C553 An entity with the VALUE attribute shall be a scalar dummy data ob ject. 3 C554 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), 4 INTENT(OUT), POINTER, or VOLATILE attributes. 5 C555 If an entity has the VALUE attribute, any length type parameter value in its declaration shall 6 be omitted or specified by an initialization expression. 7 5.3.18 VOLATILE attribute 8 The VOLATILE attribute specifies that an ob ject may be referenced, defined, or become undefined, 9 by means not specified by the program, or by another image without synchronization. 10 C556 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy 11 argument. 12 An ob ject may have the VOLATILE attribute in a particular scoping unit without necessarily having 13 it in other scoping units (11.2.1, 16.5.1.4). If an ob ject has the VOLATILE attribute, then all of its 14 subob jects also have the VOLATILE attribute. 15 NOTE 5.24 The Fortran processor should use the most recent definition of a volatile ob ject when a value is required. Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility to manage any interaction with non-Fortran processes. A pointer with the VOLATILE attribute may additionally have its association status, dynamic type and 16 type parameters, and array bounds changed by means not specified by the program. 17 NOTE 5.25 If the target of a pointer is referenced, defined, or becomes undefined, by means not specified by the program, while the pointer is associated with the target, then the pointer shall have the VOLATILE attribute. Usually a pointer should have the VOLATILE attribute if its target has the VOLATILE attribute. Similarly, all members of an EQUIVALENCE group should have the VOLATILE attribute if one member has the VOLATILE attribute. An allocatable ob ject with the VOLATILE attribute may additionally have its allocation status, dynamic 18 type and type parameters, and array bounds changed by means not specified by the program. 19 5.4 Attribute sp ecification statements 20 5.4.1 Accessibility statements 21 R520 access-stmt is access-spec [ [ :: ] access-id -list ] 22 R521 access-id is use-name 23 or generic-spec 24 C557 (R520) An access-stmt shall appear only in the specification-part of a module. Only one ac- 25 cessibility statement with an omitted access-id -list is permitted in the specification-part of a 26 99 J3/06-007 WORKING DRAFT 2006/07/11 module. 1 C558 (R521) Each use-name shall be the name of a named variable, procedure, derived type, named 2 constant, namelist group, or macro. 3 An access-stmt with an access-id -list specifies the accessibility attribute (5.3.2), PUBLIC or PRIVATE, 4 of each access-id in the list. An access-stmt without an access-id list specifies the default accessibility 5 that applies to all potentially accessible identifiers in the specification-part of the module. The statement 6 PUBLIC 7 specifies a default of public accessibility. The statement 8 PRIVATE 9 specifies a default of private accessibility. If no such statement appears in a module, the default is public 10 accessibility. 11 NOTE 5.26 Examples of accessibility statements are: MODULE EX PRIVATE PUBLIC :: A, B, C, ASSIGNMENT (=), OPERATOR (+) 5.4.2 ALLOCATABLE statement 12 R522 al locatable-stmt is ALLOCATABLE [ :: ] al locatable-decl -list 13 R523 al locatable-decl is object-name [ ( array-spec ) ] 14 [ lbracket co-array-spec rbracket ] 15 This statement specifies the ALLOCATABLE attribute (5.3.3) for a list of ob jects. 16 NOTE 5.27 An example of an ALLOCATABLE statement is: REAL A, B (:), SCALAR ALLOCATABLE :: A (:, :), B, SCALAR 5.4.3 ASYNCHRONOUS statement 17 R524 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name -list 18 The ASYNCHRONOUS statement specifies the ASYNCHRONOUS attribute (5.3.4) for a list of ob jects. 19 5.4.4 BIND statement 20 R525 bind-stmt is language-binding-spec [ :: ] bind-entity -list 21 R526 bind-entity is entity-name 22 or / common-block-name / 23 C559 (R525) If the language-binding-spec has a NAME= specifier, the bind-entity -list shall consist of 24 a single bind-entity . 25 The BIND statement specifies the BIND attribute (5.3.5) for a list of variables and common blocks. 26 100 2006/07/11 WORKING DRAFT J3/06-007 5.4.5 CONTIGUOUS statement 1 R527 contiguous-stmt is CONTIGUOUS [ :: ] object-name -list 2 The CONTIGUOUS statement specifies the CONTIGUOUS attribute (5.3.6) for a list of ob jects. 3 5.4.6 DATA statement 4 R528 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... 5 This statement specifies explicit initialization (5.2.2). 6 A variable, or part of a variable, shall not be explicitly initialized more than once in a program. If a 7 nonpointer ob ject has been specified with default initialization in a type definition, it shall not appear 8 in a data-stmt-object -list. 9 A variable that appears in a DATA statement and has not been typed previously may appear in a 10 subsequent type declaration only if that declaration confirms the implicit typing. An array name, 11 array section, or array element that appears in a DATA statement shall have had its array properties 12 established by a previous specification statement. 13 Except for variables in named common blocks, a named variable has the SAVE attribute if any part of 14 it is initialized in a DATA statement, and this may be confirmed by explicit specification. 15 R529 data-stmt-set is data-stmt-object -list / data-stmt-value -list / 16 R530 data-stmt-object is variable 17 or data-implied-do 18 R531 data-implied-do is ( data-i-do-object -list , data-i-do-variable = 19 scalar-int-initialization-expr , 20 scalar-int-initialization-expr 21 [ , scalar-int-initialization-expr ] ) 22 R532 data-i-do-object is array-element 23 or scalar-structure-component 24 or data-implied-do 25 R533 data-i-do-variable is do-variable 26 C560 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. 27 C561 (R530) In a variable that is a data-stmt-object , any subscript, section subscript, substring start- 28 ing point, and substring ending point shall be an initialization expression. 29 C562 (R530) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall 30 not be a dummy argument, made accessible by use association or host association, in a named 31 common block unless the DATA statement is in a block data program unit, in a blank common 32 block, a function name, a function result name, an automatic ob ject, or an allocatable variable. 33 C563 (R530) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an ob ject 34 designator in which a pointer appears other than as the entire rightmost part-ref . 35 C564 (R532) The array-element shall be a variable. 36 C565 (R532) The scalar-structure-component shall be a variable. 37 C566 (R532) The scalar-structure-component shall contain at least one part-ref that contains a sub- 38 script -list. 39 C567 (R532) In an array-element or scalar-structure-component that is a data-i-do-object , any sub- 40 script shall be an initialization expression, and any primary within that subscript that is a 41 101 J3/06-007 WORKING DRAFT 2006/07/11 data-i-do-variable shall be a DO variable of this data-implied-do or of a containing data-implied- 1 do . 2 R534 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant 3 R535 data-stmt-repeat is scalar-int-constant 4 or scalar-int-constant-subobject 5 C568 (R535) The data-stmt-repeat shall be positive or zero. If the data-stmt-repeat is a named con- 6 stant, it shall have been declared previously in the scoping unit or made accessible by use 7 association or host association. 8 R536 data-stmt-constant is scalar-constant 9 or scalar-constant-subobject 10 or signed-int-literal-constant 11 or signed-real-literal-constant 12 or nul l-init 13 or initial-data-target 14 or structure-constructor 15 C569 (R536) If a DATA statement constant value is a named constant or a structure constructor, the 16 named constant or derived type shall have been declared previously in the scoping unit or made 17 accessible by use or host association. 18 C570 (R536) If a data-stmt-constant is a structure-constructor , it shall be an initialization expression. 19 R537 int-constant-subobject is constant-subobject 20 C571 (R537) int-constant-subobject shall be of type integer. 21 R538 constant-subobject is designator 22 C572 (R538) constant-subobject shall be a subob ject of a constant. 23 C573 (R538) Any subscript, substring starting point, or substring ending point shall be an initializa- 24 tion expression. 25 The data-stmt-object -list is expanded to form a sequence of pointers and scalar variables, referred to 26 as "sequence of variables" in subsequent text. A nonpointer array whose unqualified name appears 27 as a data-stmt-object or data-i-do-object is equivalent to a complete sequence of its array elements in 28 array element order (6.2.2.2). An array section is equivalent to the sequence of its array elements in 29 array element order. A data-implied-do is expanded to form a sequence of array elements and structure 30 components, under the control of the data-i-do-variable , as in the DO construct (8.1.7.5). 31 The data-stmt-value -list is expanded to form a sequence of data-stmt-constant s. A data-stmt-repeat 32 indicates the number of times the following data-stmt-constant is to be included in the sequence; omission 33 of a data-stmt-repeat has the effect of a repeat factor of 1. 34 A zero-sized array or a data-implied-do with an iteration count of zero contributes no variables to the 35 expanded sequence of variables, but a zero-length scalar character variable does contribute a variable 36 to the expanded sequence. A data-stmt-constant with a repeat factor of zero contributes no data-stmt- 37 constant s to the expanded sequence of scalar data-stmt-constant s. 38 The expanded sequences of variables and data-stmt-constant s are in one-to-one correspondence. Each 39 data-stmt-constant specifies the initial value, initial data target, or nul l-init for the corresponding vari- 40 able. The lengths of the two expanded sequences shall be the same. 41 A data-stmt-constant shall be nul l-init or initial-data-target if and only if the corresponding data-stmt- 42 object has the POINTER attribute. If data-stmt-constant is nul l-init , the initial association status of 43 102 2006/07/11 WORKING DRAFT J3/06-007 the corresponding data statement ob ject is disassociated. If data-stmt-constant is initial-data-target the 1 corresponding data statement ob ject shall be data-pointer-initialization compatible with the initial data 2 target; the data statement ob ject is initially associated with the target. 3 A data-stmt-constant other than nul l-init or initial-data-target shall be compatible with its corresponding 4 variable according to the rules of intrinsic assignment (7.4.1.2). The variable is initially defined with 5 the value specified by the data-stmt-constant ; if necessary, the value is converted according to the rules 6 of intrinsic assignment (7.4.1.3) to a value that agrees in type, type parameters, and shape with the 7 variable. 8 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. 5.4.7 DIMENSION statement 9 R539 dimension-stmt is DIMENSION [ :: ] dimension-decl -list 10 R540 dimension-decl is array-name ( array-spec ) 11 or co-array-name [ ( array-spec ) ] lbracket co-array-spec rbracket 12 13 This statement specifies the DIMENSION attribute (5.3.7) for a list of ob jects. 14 NOTE 5.29 An example of a DIMENSION statement is: DIMENSION A (10), B (10, 70), C (:) 5.4.8 INTENT statement 15 R541 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name -list 16 This statement specifies the INTENT attribute (5.3.9) for the dummy arguments in the list. 17 103 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 5.30 An example of an INTENT statement is: SUBROUTINE EX (A, B) INTENT (INOUT) :: A, B 5.4.9 OPTIONAL statement 1 R542 optional-stmt is OPTIONAL [ :: ] dummy-arg-name -list 2 This statement specifies the OPTIONAL attribute (5.3.11) for the dummy arguments in the list. 3 NOTE 5.31 An example of an OPTIONAL statement is: SUBROUTINE EX (A, B) OPTIONAL :: B 5.4.10 PARAMETER statement 4 The PARAMETER statement specifies the PARAMETER attribute (5.3.12) and the values for the 5 named constants in the list. 6 R543 parameter-stmt is PARAMETER ( named-constant-def -list ) 7 R544 named-constant-def is named-constant = initialization-expr 8 If a named constant is defined by a PARAMETER statement, it shall not be subsequently declared to 9 have a type or type parameter value that differs from the type and type parameters it would have if 10 declared implicitly (5.5). A named array constant defined by a PARAMETER statement shall have its 11 shape specified in a prior specification statement. 12 The value of each named constant is that specified by the corresponding initialization expression; if 13 necessary, the value is converted according to the rules of intrinsic assignment (7.4.1.3) to a value that 14 agrees in type, type parameters, and shape with the named constant. 15 NOTE 5.32 An example of a PARAMETER statement is: PARAMETER (MODULUS = MOD (28, 3), NUMBER_OF_SENATORS = 100) 5.4.11 POINTER statement 16 R545 pointer-stmt is POINTER [ :: ] pointer-decl -list 17 R546 pointer-decl is object-name [ ( deferred-shape-spec -list ) ] 18 or proc-entity-name 19 This 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 (:, :) 104 2006/07/11 WORKING DRAFT J3/06-007 5.4.12 PROTECTED statement 1 R547 protected-stmt is PROTECTED [ :: ] entity-name -list 2 The PROTECTED statement specifies the PROTECTED attribute (5.3.14) for a list of entities. 3 5.4.13 SAVE statement 4 R548 save-stmt is SAVE [ [ :: ] saved-entity -list ] 5 R549 saved-entity is object-name 6 or proc-pointer-name 7 or / common-block-name / 8 R550 proc-pointer-name is name 9 C574 (R548) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no 10 other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. 11 A SAVE statement with a saved entity list specifies the SAVE attribute (5.3.15) for a list of entities. A 12 SAVE statement without a saved entity list is treated as though it contained the names of all allowed 13 items in the same scoping unit. 14 NOTE 5.34 An example of a SAVE statement is: SAVE A, B, C, / BLOCKA /, D 5.4.14 TARGET statement 15 R551 target-stmt is TARGET [ :: ] target-decl -list 16 R552 target-decl is object-name [ ( array-spec ) ] 17 [ lbracket co-array-spec rbracket ] 18 This statement specifies the TARGET attribute (5.3.16) for a list of ob jects. 19 NOTE 5.35 An example of a TARGET statement is: TARGET :: A (1000, 1000), B 5.4.15 VALUE statement 20 R553 value-stmt is VALUE [ :: ] dummy-arg-name -list 21 The VALUE statement specifies the VALUE attribute (5.3.17) for a list of dummy arguments. 22 5.4.16 VOLATILE statement 23 R554 volatile-stmt is VOLATILE [ :: ] object-name -list 24 The VOLATILE statement specifies the VOLATILE attribute (5.3.18) for a list of ob jects. 25 105 J3/06-007 WORKING DRAFT 2006/07/11 5.5 IMPLICIT statement 1 In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all 2 implicitly typed data entities whose names begin with one of the letters specified in the statement. 3 Alternatively, it may indicate that no implicit typing rules are to apply in a particular scoping unit. 4 R555 implicit-stmt is IMPLICIT implicit-spec -list 5 or IMPLICIT NONE 6 R556 implicit-spec is declaration-type-spec ( letter-spec -list ) 7 R557 letter-spec is letter [ ­ letter ] 8 C575 (R555) If IMPLICIT NONE is specified in a scoping unit, it shall precede any PARAMETER 9 statements that appear in the scoping unit and there shall be no other IMPLICIT statements 10 in the scoping unit. 11 C576 (R557) If the minus and second letter appear, the second letter shall follow the first letter 12 alphabetically. 13 A letter-spec consisting of two letter s separated by a minus is equivalent to writing a list containing all 14 of the letters in alphabetical order in the alphabetic sequence from the first letter through the second 15 letter. For example, A­C is equivalent to A, B, C. The same letter shall not appear as a single letter, or 16 be included in a range of letters, more than once in all of the IMPLICIT statements in a scoping unit. 17 In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z 18 and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in 19 its letter-spec -list. IMPLICIT NONE specifies the null mapping for all the letters. If a mapping is not 20 specified for a letter, the default for a program unit or an interface body is default integer if the letter 21 is I, J, ..., or N and default real otherwise, and the default for an internal or module procedure is the 22 mapping in the host scoping unit. 23 Any data entity that is not explicitly declared by a type declaration statement, is not an intrinsic 24 function, and is not made accessible by use association or host association is declared implicitly to be of 25 the type (and type parameters) mapped from the first letter of its name, provided the mapping is not 26 null. The mapping for the first letter of the data entity shall either have been established by a prior 27 IMPLICIT statement or be the default mapping for the letter. The mapping may be to a derived type 28 that is inaccessible in the local scope if the derived type is accessible in the host scoping unit. The data 29 entity is treated as if it were declared in an explicit type declaration in the outermost scoping unit in 30 which it appears. An explicit type specification in a FUNCTION statement overrides an IMPLICIT 31 statement for the name of the result variable of that function subprogram. 32 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. ... 106 2006/07/11 WORKING DRAFT J3/06-007 NOTE 5.36 (cont.) END FUNCTION JFUN END MODULE EXAMPLE_MODULE SUBROUTINE SUB IMPLICIT COMPLEX (C) C = (3.0, 2.0) ! C is implicitly declared COMPLEX ... CONTAINS SUBROUTINE SUB1 IMPLICIT INTEGER (A, C) C = (0.0, 0.0) ! C is host associated and of ! type complex Z = 1.0 ! Z is implicitly declared REAL A=2 ! A is implicitly declared INTEGER CC = 1 ! CC is implicitly declared INTEGER ... END SUBROUTINE SUB1 SUBROUTINE SUB2 Z = 2.0 ! Z is implicitly declared REAL and ! is different from the variable of ! 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 107 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 5.37 (cont.) to type BLOB, so AA is of type BLOB. 5.6 NAMELIST statement 1 A NAMELIST statement specifies a group of named data ob jects, which may be referred to by a 2 single name for the purpose of data transfer (9.5, 10.11). 3 R558 namelist-stmt is NAMELIST 4 / namelist-group-name / namelist-group-object -list 5 [ [ , ] / namelist-group-name / 6 namelist-group-object -list ] . . . 7 C577 (R558) The namelist-group-name shall not be a name accessed by use association. 8 R559 namelist-group-object is variable-name 9 C578 (R559) A namelist-group-object shall not be an assumed-size array. 10 C579 (R558) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- 11 name has the PUBLIC attribute. 12 The order in which the variables are specified in the NAMELIST statement determines the order in 13 which the values appear on output. 14 Any namelist-group-name may occur more than once in the NAMELIST statements in a scoping unit. 15 The namelist-group-object -list following each successive appearance of the same namelist-group-name in 16 a scoping unit is treated as a continuation of the list for that namelist-group-name . 17 A namelist group ob ject may be a member of more than one namelist group. 18 A namelist group ob ject shall either be accessed by use or host association or shall have its type, type 19 parameters, and shape specified by previous specification statements or the procedure heading in the 20 same scoping unit or by the implicit typing rules in effect for the scoping unit. If a namelist group ob ject 21 is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall 22 confirm the implied type and type parameters. 23 NOTE 5.38 An example of a NAMELIST statement is: NAMELIST /NLIST/ A, B, C 5.7 Storage association of data objects 24 5.7.1 EQUIVALENCE statement 25 5.7.1.1 General 26 An EQUIVALENCE statement is used to specify the sharing of storage units by two or more ob jects 27 in a scoping unit. This causes storage association (16.5.3) of the ob jects that share the storage units. 28 108 2006/07/11 WORKING DRAFT J3/06-007 NOTE 5.39 The co-size of a co-array is not a constant, therefore co-arrays are not allowed in COMMON or EQUIVALENCE. If the equivalenced ob jects have differing type or type parameters, the EQUIVALENCE statement does 1 not cause type conversion or imply mathematical equivalence. If a scalar and an array are equivalenced, 2 the scalar does not have array properties and the array does not have the properties of a scalar. 3 R560 equivalence-stmt is EQUIVALENCE equivalence-set -list 4 R561 equivalence-set is ( equivalence-object , equivalence-object -list ) 5 R562 equivalence-object is variable-name 6 or array-element 7 or substring 8 C580 (R562) An equivalence-object shall not be a designator with a base ob ject that is a dummy 9 argument, a pointer, an allocatable variable, a derived-type ob ject that has an allocatable ulti- 10 mate component, an ob ject of a nonsequence derived type, an ob ject of a derived type that has 11 a pointer at any level of component selection, an automatic ob ject, a function name, an entry 12 name, a result name, a variable with the BIND attribute, a variable in a common block that 13 has the BIND attribute, or a named constant. 14 C581 (R562) An equivalence-object shall not be a designator that has more than one part-ref . 15 C582 (R562) An equivalence-object shall not be a co-array or a subob ject thereof. 16 C583 (R562) An equivalence-object shall not have the TARGET attribute. 17 C584 (R562) Each subscript or substring range expression in an equivalence-object shall be an integer 18 initialization expression (7.1.7). 19 C585 (R561) If an equivalence-object is of type default integer, default real, double precision real, 20 default complex, default logical, or numeric sequence type, all of the ob jects in the equivalence 21 set shall be of these types. 22 C586 (R561) If an equivalence-object is of type default character or character sequence type, all of the 23 ob jects in the equivalence set shall be of these types. 24 C587 (R561) If an equivalence-object is of a sequence derived type that is not a numeric sequence or 25 character sequence type, all of the ob jects in the equivalence set shall be of the same type with 26 the same type parameter values. 27 C588 (R561) If an equivalence-object is of an intrinsic type other than default integer, default real, 28 double precision real, default complex, default logical, or default character, all of the ob jects in 29 the equivalence set shall be of the same type with the same kind type parameter value. 30 C589 (R562) If an equivalence-object has the PROTECTED attribute, all of the ob jects in the equiv- 31 alence set shall have the PROTECTED attribute. 32 C590 (R562) The name of an equivalence-object shall not be a name made accessible by use association. 33 C591 (R562) A substring shall not have length zero. 34 NOTE 5.40 The EQUIVALENCE statement allows the equivalencing of sequence structures and the equiv- alencing of ob jects of intrinsic type with nondefault type parameters, but there are strict rules regarding the appearance of these ob jects in an EQUIVALENCE statement. 109 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 5.40 (cont.) 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 ob jects 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 ob ject of default integer type, default real type, double precision real type, default complex type, or default logical type such that components of the structure ultimately become associated only with ob jects of these types. A structure of a character sequence type shall be equivalenced only to an ob ject of default character type or another structure of a character sequence type. An ob ject of intrinsic type with nondefault kind type parameters shall not be equivalenced to ob jects of different type or kind type parameters. Further rules on the interaction of EQUIVALENCE statements and default initialization are given in 16.5.3.4. 5.7.1.2 Equivalence asso ciation 1 An EQUIVALENCE statement specifies that the storage sequences (16.5.3.2) of the data ob jects specified 2 in an equivalence-set are storage associated. All of the nonzero-sized sequences in the equivalence-set , if 3 any, have the same first storage unit, and all of the zero-sized sequences in the equivalence-set , if any, 4 are storage associated with one another and with the first storage unit of any nonzero-sized sequences. 5 This causes the storage association of the data ob jects in the equivalence-set and may cause storage 6 association of other data ob jects. 7 5.7.1.3 Equivalence of default character objects 8 A data ob ject of type default character shall not be equivalenced to an ob ject that is not of type default 9 character and not of a character sequence type. The lengths of the equivalenced character ob jects need 10 not be the same. 11 An EQUIVALENCE statement specifies that the storage sequences of all the default character data 12 ob jects specified in an equivalence-set are storage associated. All of the nonzero-sized sequences in the 13 equivalence-set , if any, have the same first character storage unit, and all of the zero-sized sequences in 14 the equivalence-set , if any, are storage associated with one another and with the first character storage 15 unit of any nonzero-sized sequences. This causes the storage association of the data ob jects in the 16 equivalence-set and may cause storage association of other data ob jects. 17 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) ---| 110 2006/07/11 WORKING DRAFT J3/06-007 5.7.1.4 Array names and array element designators 1 For a nonzero-sized array, the use of the array name unqualified by a subscript list as an equivalence- 2 object has the same effect as using an array element designator that identifies the first element of the 3 array. 4 5.7.1.5 Restrictions on EQUIVALENCE statements 5 An EQUIVALENCE statement shall not specify that the same storage unit is to occur more than once 6 in a storage sequence. 7 NOTE 5.42 For example: REAL, DIMENSION (2) :: A REAL :: B EQUIVALENCE (A (1), B), (A (2), B) ! Not standard-conforming is prohibited, because it would specify the same storage unit for A (1) and A (2). An EQUIVALENCE statement shall not specify that consecutive storage units are to be nonconsecutive. 8 NOTE 5.43 For example, the following is prohibited: REAL A (2) DOUBLE PRECISION D (2) EQUIVALENCE (A (1), D (1)), (A (2), D (2)) ! Not standard-conforming 5.7.2 COMMON statement 9 5.7.2.1 General 10 The COMMON statement specifies blocks of physical storage, called common blo cks, that can be 11 accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global 12 data facility based on storage association (16.5.3). 13 The common blocks specified by the COMMON statement may be named and are called named com- 14 mon blo cks, or may be unnamed and are called blank common. 15 R563 common-stmt is COMMON 16 [ / [ common-block-name ] / ] common-block-object -list 17 [ [ , ] / [ common-block-name ] / 18 common-block-object -list ] ... 19 R564 common-block-object is variable-name [ ( array-spec ) ] 20 or proc-pointer-name 21 C592 (R564) An array-spec in a common-block-object shall be an explicit-shape-spec -list. 22 C593 (R564) Only one appearance of a given variable-name or proc-pointer-name is permitted in all 23 common-block-object -list s within a scoping unit. 24 C594 (R564) A common-block-object shall not be a dummy argument, an allocatable variable, a 25 derived-type ob ject with an ultimate component that is allocatable, an automatic ob ject, a 26 111 J3/06-007 WORKING DRAFT 2006/07/11 function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. 1 C595 (R564) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2) or a 2 type with the BIND attribute and it shall have no default initialization. 3 C596 (R564) A variable-name or proc-pointer-name shall not be a name made accessible by use 4 association. 5 In each COMMON statement, the data ob jects whose names appear in a common block ob ject list 6 following a common block name are declared to be in that common block. If the first common block 7 name is omitted, all data ob jects whose names appear in the first common block ob ject list are specified to 8 be in blank common. Alternatively, the appearance of two slashes with no common block name between 9 them declares the data ob jects whose names appear in the common block ob ject list that follows to be 10 in blank common. 11 Any common block name or an omitted common block name for blank common may occur more than 12 once in one or more COMMON statements in a scoping unit. The common block list following each 13 successive appearance of the same common block name in a scoping unit is treated as a continuation of 14 the list for that common block name. Similarly, each blank common block ob ject list in a scoping unit 15 is treated as a continuation of blank common. 16 The form variable-name (array-spec ) specifies the DIMENSION attribute for that variable. 17 If derived-type ob jects of numeric sequence type (4.5.2) or character sequence type (4.5.2) appear in 18 common, it is as if the individual components were enumerated directly in the common list. 19 NOTE 5.44 Examples of COMMON statements are: COMMON /BLOCKA/ A, B, D (10, 30) COMMON I, J, K 5.7.2.2 Common blo ck storage sequence 20 For each common block in a scoping unit, a common blo ck storage sequence is formed as follows: 21 (1) A storage sequence is formed consisting of the sequence of storage units in the storage 22 sequences (16.5.3.2) of all data ob jects in the common block ob ject lists for the common 23 block. The order of the storage sequences is the same as the order of the appearance of the 24 common block ob ject lists in the scoping unit. 25 (2) The storage sequence formed in (1) is extended to include all storage units of any storage 26 sequence associated with it by equivalence association. The sequence shall be extended only 27 by adding storage units beyond the last storage unit. Data ob jects associated with an entity 28 in a common block are considered to be in that common block. 29 Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute 30 to common block storage sequences formed in that scoping unit. 31 5.7.2.3 Size of a common blo ck 32 The size of a common blo ck is the size of its common block storage sequence, including any extensions 33 of the sequence resulting from equivalence association. 34 112 2006/07/11 WORKING DRAFT J3/06-007 5.7.2.4 Common asso ciation 1 Within a program, the common block storage sequences of all nonzero-sized common blocks with the 2 same name have the same first storage unit, and the common block storage sequences of all zero-sized 3 common blocks with the same name are storage associated with one another. Within a program, the 4 common block storage sequences of all nonzero-sized blank common blocks have the same first storage 5 unit and the storage sequences of all zero-sized blank common blocks are associated with one another and 6 with the first storage unit of any nonzero-sized blank common blocks. This results in the association of 7 ob jects in different scoping units. Use association or host association may cause these associated ob jects 8 to be accessible in the same scoping unit. 9 A nonpointer ob ject of default integer type, default real type, double precision real type, default complex 10 type, default logical type, or numeric sequence type shall be associated only with nonpointer ob jects of 11 these types. 12 A nonpointer ob ject of type default character or character sequence type shall be associated only with 13 nonpointer ob jects of these types. 14 A nonpointer ob ject of a derived type that is not a numeric sequence or character sequence type shall 15 be associated only with nonpointer ob jects of the same type with the same type parameter values. 16 A nonpointer ob ject of intrinsic type other than default integer, default real, double precision real, 17 default complex, default logical, or default character shall be associated only with nonpointer ob jects of 18 the same type and type parameters. 19 A data pointer shall be storage associated only with data pointers of the same type and rank. Data 20 pointers that are storage associated shall have deferred the same type parameters; corresponding non- 21 deferred type parameters shall have the same value. A procedure pointer shall be storage associated 22 only with another procedure pointer; either both interfaces shall be explicit or both interfaces shall be 23 implicit. If the interfaces are explicit, the characteristics shall be the same. If the interfaces are implicit, 24 either both shall be subroutines or both shall be functions with the same type and type parameters. 25 An ob ject with the TARGET attribute shall be storage associated only with another ob ject that has 26 the TARGET attribute and the same type and type parameters. 27 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 ob jects of default type, ob jects of double precision real type, and sequence structures is permitted according to the rules for equivalence ob jects (5.7.1). 5.7.2.5 Differences b etween named common and blank common 28 A blank common block has the same properties as a named common block, except for the following. 29 (1) Execution of a RETURN or END statement may cause data ob jects in a named common 30 block to become undefined unless the common block has the SAVE attribute, but never 31 causes data ob jects in blank common to become undefined (16.6.6). 32 (2) Named common blocks of the same name shall be of the same size in all scoping units of a 33 program in which they appear, but blank common blocks may be of different sizes. 34 (3) A data ob ject in a named common block may be initially defined by means of a DATA 35 statement or type declaration statement in a block data program unit (11.3), but ob jects in 36 113 J3/06-007 WORKING DRAFT 2006/07/11 blank common shall not be initially defined. 1 5.7.3 Restrictions on common and equivalence 2 An EQUIVALENCE statement shall not cause the storage sequences of two different common blocks to 3 be associated. 4 Equivalence association shall not cause a derived-type ob ject with default initialization to be associated 5 with an ob ject in a common block. 6 Equivalence association shall not cause a common block storage sequence to be extended by adding 7 storage units preceding the first storage unit of the first ob ject specified in a COMMON statement for 8 the common block. 9 NOTE 5.46 For example, the following is not permitted: COMMON /X/ A REAL B (2) EQUIVALENCE (A, B (2)) ! Not standard-conforming 114 2006/07/11 WORKING DRAFT J3/06-007 6 Use of data objects 1 The appearance of a data ob ject designator in a context that requires its value is termed a reference. A 2 reference is permitted only if the data ob ject is defined. A reference to a pointer is permitted only if the 3 pointer is associated with a target ob ject that is defined. A data ob ject becomes defined with a value 4 when events described in 16.6.5 occur. 5 R601 variable is designator 6 or expr 7 C601 (R601) designator shall not be a constant or a subob ject of a constant. 8 C602 (R601) The expr shall be a reference to a function that has a pointer result. 9 A variable is either the data ob ject denoted by designator or the target of expr . 10 R602 variable-name is name 11 C603 (R602) A variable-name shall be the name of a variable. 12 R603 designator is object-name 13 or array-element 14 or array-section 15 or complex-part-designator 16 or structure-component 17 or substring 18 R604 logical-variable is variable 19 C604 (R604) logical-variable shall be of type logical. 20 R605 default-logical-variable is variable 21 C605 (R605) default-logical-variable shall be of type default logical. 22 R606 char-variable is variable 23 C606 (R606) char-variable shall be of type character. 24 R607 default-char-variable is variable 25 C607 (R607) default-char-variable shall be of type default character. 26 R608 int-variable is variable 27 C608 (R608) int-variable shall be of type integer. 28 NOTE 6.1 For example, given the declarations: CHARACTER (10) A, B (10) TYPE (PERSON) P ! See Note 4.20 then A, B, B (1), B (1:5), P % AGE, and A (1:1) are all variables. 115 J3/06-007 WORKING DRAFT 2006/07/11 A constant (3.2.2) is a literal constant or a named constant. A literal constant is a scalar denoted by a 1 syntactic form, which indicates its type, type parameters, and value. A named constant is a constant 2 that has a name; the name has the PARAMETER attribute (5.3.12, 5.4.10). A reference to a constant 3 is always permitted; redefinition of a constant is never permitted. 4 6.1 Scalars 5 A scalar (2.4.4) is a data entity that can be represented by a single value of the type and that is not an 6 array (6.2). Its value, if defined, is a single element from the set of values that characterize its type. 7 NOTE 6.2 A scalar ob ject of derived type has a single value that consists of the values of its components (4.5.8). A scalar has rank zero. 8 6.1.1 Substrings 9 A substring is a contiguous portion of a character string (4.4.5). The following rules define the forms 10 of a substring: 11 R609 substring is parent-string ( substring-range ) 12 R610 parent-string is scalar-variable-name 13 or array-element 14 or scalar-structure-component 15 or scalar-constant 16 R611 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] 17 C609 (R610) parent-string shall be of type character. 18 The value of the first scalar-int-expr in substring-range is called the starting p oint and the value of 19 the second one is called the ending p oint. The length of a substring is the number of characters in the 20 substring and is MAX (l - f + 1, 0), where f and l are the starting and ending points, respectively. 21 Let the characters in the parent string be numbered 1, 2, 3, ..., n, where n is the length of the parent 22 string. Then the characters in the substring are those from the parent string from the starting point and 23 proceeding in sequence up to and including the ending point. Both the starting point and the ending 24 point shall be within the range 1, 2, ..., n unless the starting point exceeds the ending point, in which 25 case the substring has length zero. If the starting point is not specified, the default value is 1. If the 26 ending point is not specified, the default value is n. 27 If the parent is a variable, the substring is also a variable. 28 NOTE 6.3 Examples of character substrings are: B(1)(1:5) array element as parent string P%NAME(1:1) structure component as parent string ID(4:9) scalar variable name as parent string '0123456789'(N:N) character constant as parent string 116 2006/07/11 WORKING DRAFT J3/06-007 6.1.2 Structure comp onents 1 A structure comp onent is part of an ob ject of derived type; it may be referenced by an ob ject 2 designator. A structure component may be a scalar or an array. 3 R612 data-ref is part-ref [ % part-ref ] ... 4 R613 part-ref is part-name [ ( section-subscript -list ) ] [ image-selector ] 5 C610 (R612) Each part-name except the rightmost shall be of derived type. 6 C611 (R612) Each part-name except the leftmost shall be the name of a component of the declared 7 type of the preceding part-name . 8 C612 (R612) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. 9 C613 (R612) The leftmost part-name shall be the name of a data ob ject. 10 C614 (R613) If a section-subscript -list appears, the number of section-subscript s shall equal the rank 11 of part-name . 12 C615 (R613) If image-selector appears and part-name is an array, section-subscript -list shall appear. 13 C616 (R613) A data-ref that is a co-indexed ob ject shall not be of a type that has a pointer ultimate 14 component. 15 NOTE 6.4 This restriction is needed to avoid a disallowed pointer assignment for a component, such as Z[P] = Z ! Not allowed if Z has a pointer component Z = Z[P] ! Not allowed if Z has a pointer component J3 internal note Unresolved Technical Issue 20 Is "Z[P] = Z" allowed if Z has an allocatable component? This would imply remote (re)allocation, which I was told was bad when I asked why we were prohibiting "array[i]" forcing it to be "array(:)[i]". Also, constraint (C633a) in ALLOCATE prevents explicit remote allocation. If the answer is that remote reallocation is fine in this instance, we need to make that consistent (including allowing explicit remote allocation). Or if it is bad, we need to remove it consistently. Subgroup say they want to allow this, but require allocatable components in Z[P] to have the same shape as those in Z, removing the auto realloc. The editor disagrees that this is an obviously "good" technical fix; see discussion under assignment. The rank of a part-ref of the form part-name is the rank of part-name . The rank of a part-ref that has 16 a section subscript list is the number of subscript triplets and vector subscripts in the list. 17 C617 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right 18 of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. 19 The rank of a data-ref is the rank of the part-ref with nonzero rank, if any; otherwise, the rank is zero. 20 The base ob ject of a data-ref is the data ob ject whose name is the leftmost part name. 21 The type and type parameters, if any, of a data-ref are those of the rightmost part name. 22 A data-ref with more than one part-ref is a subob ject of its base ob ject if none of the part-name s, 23 except for possibly the rightmost, are pointers. If the rightmost part-name is the only pointer, then the 24 data-ref is a subob ject of its base ob ject in contexts that pertain to its pointer association status but 25 117 J3/06-007 WORKING DRAFT 2006/07/11 not in any other contexts. 1 NOTE 6.5 If X is an ob ject of derived type with a pointer component P, then the pointer X%P is a subob ject 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 subob ject of X. Thus, in contexts where X%P is dereferenced to refer to the target, it is not a subob ject of X. R614 structure-component is data-ref 2 C618 (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form 3 part-name . 4 A structure component shall be neither referenced nor defined before the declaration of the base ob ject. 5 A structure component is a pointer only if the rightmost part name is defined to have the POINTER 6 attribute. 7 NOTE 6.6 Examples of structure components are: SCALAR_PARENT%SCALAR_FIELD scalar component of scalar parent ARRAY_PARENT(J)%SCALAR_FIELD component of array element parent ARRAY_PARENT(1:N)%SCALAR_FIELD component of array section parent For a more elaborate example see C.3.1. NOTE 6.7 The syntax rules are structured such that a data-ref that ends in a component name without a following subscript list is a structure component, even when other component names in the data- ref are followed by a subscript list. A data-ref that ends in a component name with a following subscript list is either an array element or an array section. A data-ref of nonzero rank that ends with a substring-range is an array section. A data-ref of zero rank that ends with a substring-range is a substring. A sub comp onent of an ob ject of derived type is a component of that ob ject or of a subob ject of that 8 ob ject. 9 6.1.3 Complex parts 10 A complex part designator is used to designate the real or imaginary part of a complex data ob ject, 11 independently of the other part. 12 R615 complex-part-designator is designator % RE 13 or designator % IM 14 C619 (R615) The designator shall be of complex type. 15 If complex-part-designator is designator %RE it designates the real part of designator . If it is designa- 16 tor %IM it designates the imaginary part of designator . The type of a complex-part-designator is real, 17 and its kind and shape are those of the designator . 18 118 2006/07/11 WORKING DRAFT J3/06-007 NOTE 6.8 The following are examples of complex part designators: impedance%re !-- Same value as REAL(impedance) fft%im !-- Same value as AIMAG(fft) x%im = 0.0 !-- Sets the imaginary part of X to zero 6.1.4 Type parameter inquiry 1 A typ e parameter inquiry is used to inquire about a type parameter of a data ob ject. It applies to 2 both intrinsic and derived types. 3 R616 type-param-inquiry is designator % type-param-name 4 C620 (R616) The type-param-name shall be the name of a type parameter of the declared type of the 5 ob ject designated by the designator . 6 A deferred type parameter of a pointer that is not associated or of an unallocated allocatable variable 7 shall not be inquired about. 8 NOTE 6.9 A type-param-inquiry has a syntax like that of a structure component reference, but it does not have the same semantics. It is not a variable and thus can never be assigned to. It may be used only as a primary in an expression. It is scalar even if designator is an array. The intrinsic type parameters can also be inquired about by using the intrinsic functions KIND and LEN. NOTE 6.10 The following are examples of type parameter inquiries: a%kind !-- A is real. Same value as KIND(a). s%len !-- S is character. Same value as LEN(s). b(10)%kind !-- Inquiry about an array element. p%dim !-- P is of the derived type general_point. See Note 4.27 for the definition of the general point type used in the last example above. 6.2 Arrays 9 An array is a set of scalar data, all of the same type and type parameters, whose individual elements 10 are arranged in a rectangular pattern. The scalar data that make up an array are the array elements. 11 No order of reference to the elements of an array is indicated by the appearance of the array designator, 12 except where array element ordering (6.2.2.2) is specified. 13 6.2.1 Whole arrays 14 A whole array is a named array, which may be either a named constant (5.3.12, 5.4.10) or a variable; 15 no subscript list is appended to the name. 16 The appearance of a whole array variable in an executable construct specifies all the elements of the 17 array (2.4.5). An assumed-size array is permitted to appear as a whole array in an executable construct 18 119 J3/06-007 WORKING DRAFT 2006/07/11 only as an actual argument in a procedure reference that does not require the shape. 1 The appearance of a whole array name in a nonexecutable statement specifies the entire array except 2 for the appearance of a whole array name in an equivalence set (5.7.1.4). 3 6.2.2 Array elements and array sections 4 R617 array-element is data-ref 5 C621 (R617) Every part-ref shall have rank zero and the last part-ref shall contain a subscript -list. 6 R618 array-section is data-ref [ ( substring-range ) ] 7 or complex-part-designator 8 C622 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have a 9 section-subscript -list with nonzero rank, the array-section is a complex-part-designator that is 10 an array, or another part-ref shall have nonzero rank. 11 C623 (R618) If a substring-range appears, the rightmost part-name shall be of type character. 12 R619 subscript is scalar-int-expr 13 R620 section-subscript is subscript 14 or subscript-triplet 15 or vector-subscript 16 R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ] 17 R622 stride is scalar-int-expr 18 R623 vector-subscript is int-expr 19 C624 (R623) A vector-subscript shall be an integer array expression of rank one. 20 C625 (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension 21 of an assumed-size array. 22 An array element is a scalar. An array section is an array. If a substring-range is present in an array- 23 section , each element is the designated substring of the corresponding element of the array section. 24 NOTE 6.11 For example, with the declarations: REAL A (10, 10) CHARACTER (LEN = 10) B (5, 5, 5) A (1, 2) is an array element, A (1:N:2, M) is a rank-one array section, and B (:, :, :) (2:3) is an array of shape (5, 5, 5) whose elements are substrings of length 2 of the corresponding elements of B. NOTE 6.12 Unless otherwise specified, an array element or array section does not have an attribute of the whole array. In particular, an array element or an array section does not have the POINTER or ALLOCATABLE attribute. NOTE 6.13 Examples of array elements and array sections are: ARRAY_A(1:N:2)%ARRAY_B(I, J)%STRING(K)(:) array section 120 2006/07/11 WORKING DRAFT J3/06-007 NOTE 6.13 (cont.) SCALAR_PARENT%ARRAY_FIELD(J) array element SCALAR_PARENT%ARRAY_FIELD(1:N) array section SCALAR_PARENT%ARRAY_FIELD(1:N)%SCALAR_FIELD array section 6.2.2.1 Array elements 1 The value of a subscript in an array element shall be within the bounds for that dimension. 2 6.2.2.2 Array element order 3 The elements of an array form a sequence known as the array element order. The position of an array 4 element in this sequence is determined by the subscript order value of the subscript list designating the 5 element. The subscript order value is computed from the formulas in Table 6.1. 6 Table 6.1: Subscript order value Rank Subscript bounds Subscript list Subscript order value 1 + (s1 - j1 ) 1 j1 :k1 s1 1 + (s1 - j1 ) 2 j1 :k1 ,j2 :k2 s1 , s2 + (s2 - j2 ) × d1 1 + (s1 - j1 ) + (s2 - j2 ) × d1 3 j1 :k1 , j2 :k2 , j3 :k3 s1 , s2 , s3 + (s3 - j3 ) × d2 × d1 · · · · · · · · · · · · 1 + (s1 - j1 ) + (s2 - j2 ) × d1 + (s3 - j3 ) × d2 × d1 15 j1 :k1 , . . . , j15 :k15 s1 , . . . , s15 + ... + (s15 - j15 ) × d14 × d13 × . . . × d1 Notes for Table 6.1: 1) di = max (ki - ji + 1, 0) is the size of the ith dimension. 2) If the size of the array is nonzero, ji si ki for all i = 1, 2, ..., 15. 6.2.2.3 Array sections 7 An array section is an array subob ject optionally followed by a substring range. 8 In an array-section having a section-subscript -list, each subscript-triplet and vector-subscript in the 9 section subscript list indicates a sequence of subscripts, which may be empty. Each subscript in such a 10 sequence shall be within the bounds for its dimension unless the sequence is empty. The array section is 11 the set of elements from the array determined by all possible subscript lists obtainable from the single 12 subscripts or sequences of subscripts specified by each section subscript. 13 In an array-section with no section-subscript -list, the rank and shape of the array is the rank and shape 14 of the part-ref with nonzero rank; otherwise, the rank of the array section is the number of subscript 15 triplets and vector subscripts in the section subscript list. The shape is the rank-one array whose ith 16 element is the number of integer values in the sequence indicated by the ith subscript triplet or vector 17 subscript. If any of these sequences is empty, the array section has size zero. The subscript order of the 18 elements of an array section is that of the array data ob ject that the array section represents. 19 121 J3/06-007 WORKING DRAFT 2006/07/11 6.2.2.3.1 Subscript triplet 1 A subscript triplet designates a regular sequence of subscripts consisting of zero or more subscript values. 2 The third expression in the subscript triplet is the increment between the subscript values and is called 3 the stride. The subscripts and stride of a subscript triplet are optional. An omitted first subscript in a 4 subscript triplet is equivalent to a subscript whose value is the lower bound for the array and an omitted 5 second subscript is equivalent to the upper bound. An omitted stride is equivalent to a stride of 1. 6 The stride shall not be zero. 7 When the stride is positive, the subscripts specified by a triplet form a regularly spaced sequence of 8 integers beginning with the first subscript and proceeding in increments of the stride to the largest such 9 integer not greater than the second subscript; the sequence is empty if the first subscript is greater than 10 the second. 11 NOTE 6.14 For example, suppose an array is declared as A (5, 4, 3). The section A (3 : 5, 2, 1 : 2) is the array of shape (3, 2): A (3, 2, 1) A (3, 2, 2) A (4, 2, 1) A (4, 2, 2) A (5, 2, 1) A (5, 2, 2) When the stride is negative, the sequence begins with the first subscript and proceeds in increments of 12 the stride down to the smallest such integer equal to or greater than the second subscript; the sequence 13 is empty if the second subscript is greater than the first. 14 NOTE 6.15 For example, if an array is declared B (10), the section B (9 : 1 : ­2) is the array of shape (5) whose elements are B (9), B (7), B (5), B (3), and B (1), in that order. NOTE 6.16 A subscript in a subscript triplet need not be within the declared bounds for that dimension if all values used in selecting the array elements are within the declared bounds. For example, if an array is declared as B (10), the array section B (3 : 11 : 7) is the array of shape (2) consisting of the elements B (3) and B (10), in that order. 6.2.2.3.2 Vector subscript 15 A vector subscript designates a sequence of subscripts corresponding to the values of the elements 16 of the expression. Each element of the expression shall be defined. A many-one array section is an 17 array section with a vector subscript having two or more elements with the same value. A many-one 18 array section shall appear neither on the left of the equals in an assignment statement nor as an input 19 item in a READ statement. 20 An array section with a vector subscript shall not be argument associated with a dummy array that 21 is defined or redefined. An array section with a vector subscript shall not be the target in a pointer 22 assignment statement. An array section with a vector subscript shall not be an internal file. 23 NOTE 6.17 For example, suppose Z is a two-dimensional array of shape (5, 7) and U and V are one-dimensional arrays of shape (3) and (4), respectively. Assume the values of U and V are: 122 2006/07/11 WORKING DRAFT J3/06-007 NOTE 6.17 (cont.) 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 An image selector specifies the image index for co-array data. 2 R624 image-selector is lbracket co-subscript -list rbracket 3 R625 co-subscript is scalar-int-expr 4 The number of co-subscripts shall be equal to the co-rank of the ob ject. The value of a co-subscript in 5 an image selector shall be within the bounds for its co-dimension. An image selector shall specify an 6 image index value that is not greater than the number of images. 7 NOTE 6.18 For example, if there are 16 images and the co-array A is declared REAL :: A(10)[5,*] A(:)[1,4] is valid because it specifies image 16, but A(:)[2,4] is invalid because it specifies image 17. J3 internal note Unresolved Technical Issue 21 This does not appear to be adequately specified. The mapping between co-subscripts (or rather, co-subscript lists) and image indexes is done by handwaving analogy. It is probably not necessary to repeat the formulae, but we need to say exactly how we use those formulae in a more rigorous way. (For a start, "Subscript bounds" clearly does not apply to co-subscripts.) 6.3 Dynamic asso ciation 8 Dynamic control over the allocation, association, and deallocation of pointer targets is provided by 9 the ALLOCATE, NULLIFY, and DEALLOCATE statements and pointer assignment. ALLOCATE 10 (6.3.1) creates targets for pointers; pointer assignment (7.4.2) associates pointers with existing targets; 11 NULLIFY (6.3.2) disassociates pointers from targets, and DEALLOCATE (6.3.3) deallocates targets. 12 123 J3/06-007 WORKING DRAFT 2006/07/11 Dynamic association applies to scalars and arrays of any type. 1 The ALLOCATE and DEALLOCATE statements also are used to create and deallocate variables with 2 the ALLOCATABLE attribute. 3 NOTE 6.19 Detailed remarks regarding pointers and dynamic association are in C.3.3. 6.3.1 ALLOCATE statement 4 The ALLOCATE statement dynamically creates pointer targets and allocatable variables. 5 R626 al locate-stmt is ALLOCATE ( [ type-spec :: ] al location -list 6 [, al loc-opt -list ] ) 7 R627 al loc-opt is ERRMSG = errmsg-variable 8 or MOLD = source-expr 9 or SOURCE = source-expr 10 or STAT = stat-variable 11 R628 stat-variable is scalar-int-variable 12 R629 errmsg-variable is scalar-default-char-variable 13 R630 source-expr is expr 14 R631 al location is al locate-object [ ( al locate-shape-spec -list ) ] 15 [ lbracket al locate-co-array-spec rbracket ] 16 R632 al locate-object is variable-name 17 or structure-component 18 R633 al locate-shape-spec is [ lower-bound-expr : ] upper-bound-expr 19 R634 lower-bound-expr is scalar-int-expr 20 R635 upper-bound-expr is scalar-int-expr 21 R636 al locate-co-array-spec is [ al locate-co-shape-spec -list , ] [ lower-bound-expr : ] * 22 R637 al locate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr 23 C626 (R632) Each al locate-object shall be a nonprocedure pointer or an allocatable variable. 24 C627 (R626) If any al locate-object in the statement has a deferred type parameter, either type-spec or 25 SOURCE= shall appear. 26 C628 (R626) If a type-spec appears, it shall specify a type with which each al locate-object is type 27 compatible. 28 C629 (R626) If any al locate-object is unlimited polymorphic or is of abstract type, either type-spec or 29 SOURCE= shall appear. 30 C630 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each al locate-object 31 is a dummy argument for which the corresponding type parameter is assumed. 32 C631 (R626) If a type-spec appears, the kind type parameter values of each al locate-object shall be 33 the same as the corresponding type parameter values of the type-spec . 34 C632 (R631) An al locate-shape-spec -list shall appear if and only if the al locate-object is an array. An 35 al locate-co-array-spec shall appear if and only if the al locate-object is a co-array. 36 C633 (R631) The number of al locate-shape-spec s in an al locate-shape-spec -list shall be the same as the 37 rank of the al locate-object . The number of al locate-co-shape-spec s in an al locate-co-array-spec 38 124 2006/07/11 WORKING DRAFT J3/06-007 shall be one less than the co-rank of the al locate-object . 1 C634 (R627) No al loc-opt shall appear more than once in a given al loc-opt -list. 2 C635 (R626) At most one of SOURCE=, MOLD=, and type-spec shall appear. 3 C636 (R626) Each al locate-object shall be type compatible (4.3.1.3) with source-expr . If SOURCE= 4 appears, source-expr shall be a scalar or have the same rank as each al locate-object . 5 C637 (R626) Corresponding kind type parameters of al locate-object and source-expr shall have the 6 same values. 7 C638 (R632) An al locate-object shall not be a co-indexed ob ject. 8 NOTE 6.20 If a co-array is of a derived type that has an allocatable component, the component shall be allocated by its own image: TYPE(SOMETHING), ALLOCATABLE :: T[:] ... ALLOCATE(T[*]) ! Allowed - implies synchronization ALLOCATE(T%AAC(N)) ! Allowed - allocated by its own image ALLOCATE(T[Q]%AAC(N)) ! Not allowed, because it is not ! necessarily executed on image Q. An al locate-object or a bound or type parameter of an al locate-object shall not depend on the value of 9 stat-variable , the value of errmsg-variable , or on the value, bounds, length type parameters, allocation 10 status, or association status of any al locate-object in the same ALLOCATE statement. 11 Neither stat-variable , source-expr , nor errmsg-variable shall be allocated within the ALLOCATE state- 12 ment in which it appears; nor shall they depend on the value, bounds, length type parameters, allocation 13 status, or association status of any al locate-object in the same ALLOCATE statement. 14 If type-spec is specified, each al locate-object is allocated with the specified dynamic type and type pa- 15 rameter values; if source-expr is specified, each al locate-object is allocated with the dynamic type and 16 type parameter values of source-expr ; otherwise, each al locate-object is allocated with its dynamic type 17 the same as its declared type. The dynamic type shall not have a co-array ultimate component. 18 J3 internal note Unresolved Technical Issue 22 (minor) It is worth considering how this dynamic type could ever have a co-array subcomponent. In particular, we should constrain this type-spec against being such a type. (ma jor) This is a runtime problem which cannot be avoided by the user in any systematic way. It is a very bad idea to design the language so that "bad things happen" when the user is not in any position to detect that a bad thing might happen. The easy solution is (1) to prohibit type extension from adding co-array components, and (2) to constrain the declared type of source-expr from having any co-array ultimate components. Since co-array components are really really special (like, something with a co-array component cannot be pointed to) it does not seem too unreasonable for them not to be includable via type extension. If type-spec appears and the value of a type parameter it specifies differs from the value of the corre- 19 125 J3/06-007 WORKING DRAFT 2006/07/11 sponding nondeferred type parameter specified in the declaration of any al locate-object , an error condition 1 occurs. If the value of a nondeferred length type parameter of an al locate-object differs from the value 2 of the corresponding type parameter of source-expr , an error condition occurs. 3 If a type-param-value in a type-spec in an ALLOCATE statement is an asterisk, it denotes the current 4 value of that assumed type parameter. If it is an expression, subsequent redefinition or undefinition of 5 any entity in the expression does not affect the type parameter value. 6 NOTE 6.21 An example of an ALLOCATE statement is: ALLOCATE (X (N), B (-3 : M, 0:9), STAT = IERR_ALLOC) When an ALLOCATE statement is executed for an array, the values of the lower bound and upper 7 bound expressions determine the bounds of the array. Subsequent redefinition or undefinition of any 8 entities in the bound expressions do not affect the array bounds. If the lower bound is omitted, the 9 default value is 1. If the upper bound is less than the lower bound, the extent in that dimension is zero 10 and the array has zero size. 11 NOTE 6.22 An al locate-object may be of type character with zero character length. If SOURCE= appears, source-expr shall be conformable (2.4.5) with al location . If the value of a non- 12 deferred length type parameter of al locate-object is different from the value of the corresponding type 13 parameter of source-expr , an error condition occurs. If the allocation is successful, the value of al locate- 14 object becomes that of source-expr . 15 If MOLD= appears and source-expr is a variable, its value need not be defined. 16 NOTE 6.23 The source-expr can be an array or scalar independently of whether an al locate-object is an array or a scalar. For MOLD=source-expr , only the dynamic type and type parameter values of source-expr are relevant; its rank, shape, and value are not. NOTE 6.24 An example of an ALLOCATE statement in which the value and dynamic type are determined by reference to another ob ject is: CLASS(*), ALLOCATABLE :: NEW CLASS(*), POINTER :: OLD ! ... ALLOCATE (NEW, SOURCE=OLD) ! Allocate NEW with the value and dynamic type of OLD A more extensive example is given in C.3.2. If the STAT= specifier appears, successful execution of the ALLOCATE statement causes the stat- 17 variable to become defined with a value of zero. If an error condition occurs during the execution 18 of the ALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive 19 integer value and each al locate-object will have a processor-dependent status; each al locate-object that 20 was successfully allocated shall have an allocation status of allocated or a pointer association status of 21 associated; each al locate-object that was not successfully allocated shall retain its previous allocation 22 status or pointer association status. 23 126 2006/07/11 WORKING DRAFT J3/06-007 If an error condition occurs during execution of an ALLOCATE statement that does not contain the 1 STAT= specifier, execution of the program is terminated. 2 The ERRMSG= specifier is described in 6.3.1.3. 3 6.3.1.1 Allo cation of allo catable variables 4 The allocation status of an allocatable entity is one of the following at any time during the execution of 5 a program. 6 (1) The status of an allocatable variable becomes allo cated if it is allocated by an ALLOCATE 7 statement, if it is allocated during assignment, or if it is given that status by the allocation 8 transfer procedure (13.7.124). An allocatable variable with this status may be referenced, 9 defined, or deallocated; allocating it causes an error condition in the ALLOCATE statement. 10 The intrinsic function ALLOCATED (13.7.10) returns true for such a variable. 11 (2) An allocatable variable has a status of unallo cated if it is not allocated. The status of 12 an allocatable variable becomes unallocated if it is deallocated (6.3.3) or if it is given that 13 status by the allocation transfer procedure. An allocatable variable with this status shall 14 not be referenced or defined. It shall not be supplied as an actual argument corresponding 15 to a nonallocatable dummy argument, except to certain intrinsic inquiry functions. It may 16 be allocated with the ALLOCATE statement. Deallocating it causes an error condition in 17 the DEALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns false 18 for such a variable. 19 At the beginning of execution of a program, allocatable variables are unallocated. 20 A saved allocatable ob ject has an initial status of unallocated. The status may change during the 21 execution of the program. 22 When the allocation status of an allocatable variable changes, the allocation status of any associated 23 allocatable variable changes accordingly. Allocation of an allocatable variable establishes values for the 24 deferred type parameters of all associated allocatable variables. 25 An unsaved allocatable ob ject that is a local variable of a procedure has a status of unallocated at the 26 beginning of each invocation of the procedure. The status may change during execution of the procedure. 27 An unsaved allocatable ob ject that is a local variable of a module or submodule, or a subob ject thereof, 28 has an initial status of unallocated. The status may change during execution of the program. 29 When an ob ject of derived type is created by an ALLOCATE statement, any allocatable ultimate 30 components have an allocation status of unallocated. 31 The value of each lower-bound-expr and each upper-bound-expr in an al locate-co-array-spec shall be the 32 same on each image. 33 If an al location specifies a co-array, its dynamic type and the values of each length type parameter shall 34 be the same on each image. 35 There is implicit synchronization of all images in association with each ALLOCATE statement that 36 involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 37 is delayed until all other images have executed the same statement the same number of times. 38 NOTE 6.25 When an image executes an ALLOCATE statement, communication is not necessarily involved apart from any required for synchronization. The image allocates its co-array and records how the corresponding co-arrays on other images are to be addressed. The processor is not required to detect violations of the rule that the bounds are the same on all images, nor is it responsible 127 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 6.25 (cont.) for detecting or resolving deadlock problems (such as two images waiting on different ALLOCATE statements). 6.3.1.2 Allo cation of p ointer targets 1 Allocation of a pointer creates an ob ject that implicitly has the TARGET attribute. Following successful 2 execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may 3 be used to reference or define the target. Additional pointers may become associated with the pointer 4 target or a part of the pointer target by pointer assignment. It is not an error to allocate a pointer 5 that is already associated with a target. In this case, a new pointer target is created as required by the 6 attributes of the pointer and any array bounds, type, and type parameters specified by the ALLOCATE 7 statement. The pointer is then associated with this new target. Any previous association of the pointer 8 with a target is broken. If the previous target had been created by allocation, it becomes inaccessible 9 unless other pointers are associated with it. The ASSOCIATED intrinsic function (13.7.15) may be used 10 to determine whether a pointer that does not have undefined association status is associated. 11 At the beginning of execution of a function whose result is a pointer, the association status of the result 12 pointer is undefined. Before such a function returns, it shall either associate a target with this pointer 13 or cause the association status of this pointer to become defined as disassociated. 14 6.3.1.3 ERRMSG= sp ecifier 15 If an error condition occurs during execution of an ALLOCATE or DEALLOCATE statement, the 16 processor shall assign an explanatory message to errmsg-variable . If no such condition occurs, the 17 processor shall not change the value of errmsg-variable . 18 6.3.2 NULLIFY statement 19 The NULLIFY statement causes pointers to be disassociated. 20 R638 nul lify-stmt is NULLIFY ( pointer-object -list ) 21 R639 pointer-object is variable-name 22 or structure-component 23 or proc-pointer-name 24 C639 (R639) Each pointer-object shall have the POINTER attribute. 25 A pointer-object shall not depend on the value, bounds, or association status of another pointer-object 26 in the same NULLIFY statement. 27 NOTE 6.26 When a NULLIFY statement is applied to a polymorphic pointer (4.3.1.3), its dynamic type becomes the declared type. 6.3.3 DEALLOCATE statement 28 The DEALLOCATE statement causes allocatable variables to be deallocated; it causes pointer tar- 29 gets to be deallocated and the pointers to be disassociated. 30 R640 deal locate-stmt is DEALLOCATE ( al locate-object -list [ , deal loc-opt -list ] ) 31 C640 (R640) Each al locate-object shall be a nonprocedure pointer or an allocatable variable. 32 128 2006/07/11 WORKING DRAFT J3/06-007 R641 deal loc-opt is STAT = stat-variable 1 or ERRMSG = errmsg-variable 2 C641 (R641) No deal loc-opt shall appear more than once in a given deal loc-opt -list. 3 An al locate-object shall not depend on the value, bounds, allocation status, or association status of 4 another al locate-object in the same DEALLOCATE statement; it also shall not depend on the value of 5 the stat-variable or errmsg-variable in the same DEALLOCATE statement. 6 Neither stat-variable nor errmsg-variable shall be deallocated within the same DEALLOCATE state- 7 ment; they also shall not depend on the value, bounds, allocation status, or association status of any 8 al locate-object in the same DEALLOCATE statement. 9 If the STAT= specifier appears, successful execution of the DEALLOCATE statement causes the stat- 10 variable to become defined with a value of zero. If an error condition occurs during the execution of 11 the DEALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive 12 integer value and each al locate-object that was successfully deallocated shall have an allocation status of 13 unallocated or a pointer association status of disassociated. Each al locate-object that was not successfully 14 deallocated shall retain its previous allocation status or pointer association status. 15 NOTE 6.27 The status of ob jects that were not successfully deallocated can be individually checked with the ALLOCATED or ASSOCIATED intrinsic functions. If an error condition occurs during execution of a DEALLOCATE statement that does not contain the 16 STAT= specifier, execution of the program is terminated. 17 The ERRMSG= specifier is described in 6.3.1.3. 18 NOTE 6.28 An example of a DEALLOCATE statement is: DEALLOCATE (X, B) 6.3.3.1 Deallo cation of allo catable variables 19 Deallocating an unallocated allocatable variable causes an error condition in the DEALLOCATE state- 20 ment. Deallocating an allocatable variable with the TARGET attribute causes the pointer association 21 status of any pointer associated with it to become undefined. 22 When the execution of a procedure is terminated by execution of a RETURN or END statement, an 23 allocatable variable that is a named local variable of the procedure retains its allocation and definition 24 status if it has the SAVE attribute or is a function result variable or a subob ject thereof; otherwise, it 25 is deallocated. 26 When a BLOCK construct terminates, an allocatable variable that is a named local variable of the con- 27 struct retains its allocation and definition status if it has the SAVE attribute; otherwise it is deallocated. 28 NOTE 6.29 The ALLOCATED intrinsic function may be used to determine whether a variable is allocated or unallocated. If an unsaved allocatable ob ject is a local variable of a module or submodule, and it is allocated when 29 execution of a RETURN or END statement results in no active scoping unit referencing the module or 30 129 J3/06-007 WORKING DRAFT 2006/07/11 submodule, it is processor-dependent whether the ob ject retains its allocation status or is deallocated. 1 NOTE 6.30 The following example illustrates the effects of SAVE on allocation status. MODULE MOD1 TYPE INITIALIZED_TYPE INTEGER :: I = 1 ! Default initialization END TYPE INITIALIZED_TYPE SAVE :: SAVED1, SAVED2 INTEGER :: SAVED1, UNSAVED1 TYPE(INITIALIZED_TYPE) :: SAVED2, UNSAVED2 ALLOCATABLE :: SAVED1(:), SAVED2(:), UNSAVED1(:), UNSAVED2(:) END MODULE MOD1 PROGRAM MAIN CALL SUB1 ! The values returned by the ALLOCATED intrinsic calls ! in the PRINT statement are: ! .FALSE., .FALSE., .FALSE., and .FALSE. ! Module MOD1 is used, and its variables are allocated. ! After return from the subroutine, whether the variables ! which were not specified with the SAVE attribute ! retain their allocation status is processor dependent. CALL SUB1 ! The values returned by the first two ALLOCATED intrinsic ! calls in the PRINT statement are: ! .TRUE., .TRUE. ! The values returned by the second two ALLOCATED ! intrinsic calls in the PRINT statement are ! processor dependent and each could be either ! .TRUE. or .FALSE. CONTAINS SUBROUTINE SUB1 USE MOD1 ! Brings in saved and unsaved variables. PRINT *, ALLOCATED(SAVED1), ALLOCATED(SAVED2), & ALLOCATED(UNSAVED1), ALLOCATED(UNSAVED2) IF (.NOT. ALLOCATED(SAVED1)) ALLOCATE(SAVED1(10)) IF (.NOT. ALLOCATED(SAVED2)) ALLOCATE(SAVED2(10)) IF (.NOT. ALLOCATED(UNSAVED1)) ALLOCATE(UNSAVED1(10)) IF (.NOT. ALLOCATED(UNSAVED2)) ALLOCATE(UNSAVED2(10)) END SUBROUTINE SUB1 END PROGRAM MAIN If an executable construct references a function whose result is either allocatable or a structure with 2 a subob ject that is allocatable, and the function reference is executed, an allocatable result and any 3 subob ject that is an allocated allocatable entity in the result returned by the function is deallocated 4 after execution of the innermost executable construct containing the reference. 5 If a specification expression in a scoping unit references a function whose result is either allocatable or 6 a structure with a subob ject that is allocatable, and the function reference is executed, an allocatable 7 result and any subob ject that is an allocated allocatable entity in the result returned by the function is 8 deallocated before execution of the first executable statement in the scoping unit. 9 When a procedure is invoked, any allocated allocatable ob ject that is an actual argument associated with 10 an INTENT(OUT) allocatable dummy argument is deallocated; any allocated allocatable ob ject that is 11 a subob ject of an actual argument associated with an INTENT(OUT) dummy argument is deallocated. 12 130 2006/07/11 WORKING DRAFT J3/06-007 When an intrinsic assignment statement (7.4.1.3) is executed, any allocated allocatable subob ject of the 1 variable is deallocated before the assignment takes place. 2 When a variable of derived type is deallocated, any allocated allocatable subob ject is deallocated. 3 If an allocatable component is a subob ject of a finalizable ob ject, that ob ject is finalized before the 4 component is automatically deallocated. 5 The effect of automatic deallocation is the same as that of a DEALLOCATE statement without a 6 deal loc-opt -list. 7 NOTE 6.31 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. On the next invocation of PROCESS, TEMP will have an allocation status of unallocated. There is implicit synchronization of all images in association with each DEALLOCATE statement that 8 involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 9 is delayed until all other images have executed the same statement the same number of times. 10 There is also an implicit synchronization of all images in association with the deallocation of a co-array 11 or co-array subcomponent caused by the execution of a RETURN or END statement or the termination 12 of a BLOCK construct. 13 6.3.3.2 Deallo cation of p ointer targets 14 If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating 15 a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an 16 error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, 17 the pointer shall not be deallocated. 18 If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an ob ject 19 that was created by allocation. Deallocating a pointer target causes the pointer association status of 20 any other pointer that is associated with the target or a portion of the target to become undefined. 21 131 J3/06-007 WORKING DRAFT 2006/07/11 132 2006/07/11 WORKING DRAFT J3/06-007 7 Expressions and assignment 1 This clause describes the formation, interpretation, and evaluation rules for expressions, intrinsic and 2 defined assignment, pointer assignment, masked array assignment (WHERE), and FORALL. 3 7.1 Expressions 4 An expression represents either a data reference or a computation, and its value is either a scalar or 5 an array. An expression is formed from operands, operators, and parentheses. 6 An operand is either a scalar or an array. An operation is either intrinsic or defined (7.2). More 7 complicated expressions can be formed using operands which are themselves expressions. 8 Evaluation of an expression produces a value, which has a type, type parameters (if appropriate), and a 9 shape (7.1.4). 10 7.1.1 Form of an expression 11 An expression is defined in terms of several categories: primary, level-1 expression, level-2 expression, 12 level-3 expression, level-4 expression, and level-5 expression. 13 These categories are related to the different operator precedence levels and, in general, are defined in 14 terms of other categories. The simplest form of each expression category is a primary . The rules given 15 below specify the syntax of an expression. The semantics are specified in 7.2. 16 7.1.1.1 Primary 17 R701 primary is constant 18 or designator 19 or array-constructor 20 or structure-constructor 21 or function-reference 22 or type-param-inquiry 23 or type-param-name 24 or ( expr ) 25 C701 (R701) The type-param-name shall be the name of a type parameter. 26 C702 (R701) The designator shall not be a whole assumed-size array. 27 NOTE 7.1 Examples of a primary are: Example Syntactic class constant 1.0 designator 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' (I:I) array-constructor (/ 1.0, 2.0 /) structure-constructor PERSON (12, 'Jones') function-reference F (X, Y) type-param-inquiry X%KIND 133 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.1 (cont.) type-param-name KIND (expr ) (S + T) 7.1.1.2 Level-1 expressions 1 Defined unary operators have the highest operator precedence (Table 7.9). Level-1 expressions are 2 primaries optionally operated on by defined unary operators: 3 R702 level-1-expr is [ defined-unary-op ] primary 4 R703 defined-unary-op is . letter [ letter ] ... . 5 C703 (R703) A defined-unary-op shall not contain more than 63 letters and shall not be the same as 6 any intrinsic-operator or logical-literal-constant . 7 NOTE 7.2 Simple examples of a level-1 expression are: Example Syntactic class primary (R701) A level-1-expr (R702) .INVERSE. B A more complicated example of a level-1 expression is: .INVERSE. (A + B) 7.1.1.3 Level-2 expressions 8 Level-2 expressions are level-1 expressions optionally involving the numeric operators power-op , mult-op , 9 and add-op . 10 R704 mult-operand is level-1-expr [ power-op mult-operand ] 11 R705 add-operand is [ add-operand mult-op ] mult-operand 12 R706 level-2-expr is [ [ level-2-expr ] add-op ] add-operand 13 R707 power-op is ** 14 R708 mult-op is * 15 or / 16 R709 add-op is + 17 or ­ 18 NOTE 7.3 Simple examples of a level-2 expression are: Example Syntactic class Remarks level-1-expr A is a primary . (R702) A mult-operand B is a level-1-expr , ** is a power-op , B ** C and C is a mult-operand . (R704) add-operand D is an add-operand , * is a mult-op , D*E and E is a mult-operand . (R705) level-2-expr + is an add-op +1 and 1 is an add-operand . (R706) level-2-expr F is a level-2-expr , ­ is an add-op , F-I and I is an add-operand . (R706) 134 2006/07/11 WORKING DRAFT J3/06-007 NOTE 7.3 (cont.) A more complicated example of a level-2 expression is: - A + D * E + B ** C 7.1.1.4 Level-3 expressions 1 Level-3 expressions are level-2 expressions optionally involving the character operator and bits concate- 2 nation operator concat-op . 3 R710 level-3-expr is [ level-3-expr concat-op ] level-2-expr 4 R711 concat-op is // 5 NOTE 7.4 Simple examples of a level-3 expression are: Example Syntactic class level-2-expr (R706) A level-3-expr (R710) B // C A more complicated example of a level-3 expression is: X // Y // 'ABCD' 7.1.1.5 Level-4 expressions 6 Level-4 expressions are level-3 expressions optionally involving the relational operators rel-op . 7 R712 level-4-expr is [ level-3-expr rel-op ] level-3-expr 8 R713 rel-op is .EQ. 9 or .NE. 10 or .LT. 11 or .LE. 12 or .GT. 13 or .GE. 14 or == 15 or /= 16 or < 17 or <= 18 or > 19 or >= 20 NOTE 7.5 Simple examples of a level-4 expression are: Example Syntactic class level-3-expr (R710) A level-4-expr (R712) B == C D, >=, <, <= C C L .NOT. L, B L, B L L L .AND., .OR., .EQV., .NEQV. B B,I B I B B Note: The symbols I, R, Z, C, L, and B stand for the types integer, real, complex, character, logical, and bits, respectively. Where more than one type for x2 is given, the type of the result of the operation is given in the same relative position in the next column. For the intrinsic operators with operands of type character, the kind type parameters of the operands shall be the same. A numeric intrinsic op eration is an intrinsic operation for which the intrinsic-operator is a numeric 8 operator (+, ­, *, /, or **). A numeric intrinsic op erator is the operator in a numeric intrinsic 9 operation. 10 For numeric intrinsic binary operations, the two operands may be of different numeric types or different 11 kind type parameters. Except for a value raised to an integer power, if the operands have different types 12 or kind type parameters, the effect is as if each operand that differs in type or kind type parameter from 13 those of the result is converted to the type and kind type parameter of the result before the operation 14 is performed. When a value of type real or complex is raised to an integer power, the integer operand 15 137 J3/06-007 WORKING DRAFT 2006/07/11 need not be converted. 1 The character intrinsic op eration is the intrinsic operation for which the intrinsic-operator is (//) 2 and both operands are of type character. The operands shall have the same kind type parameter. The 3 character intrinsic op erator is the operator in a character intrinsic operation. 4 A logical intrinsic op eration is an intrinsic operation for which the intrinsic-operator is .AND., .OR., 5 .XOR., .NOT., .EQV., or .NEQV. and both operands are of type logical. A logical intrinsic op erator 6 is the operator in a logical intrinsic operation. 7 A bits intrinsic op eration is an intrinsic operation for which the intrinsic-operator is //, .AND., .OR., 8 .XOR., .NOT., .EQV., or .NEQV. and at least one operand is of type bits. A bits intrinsic op erator 9 is the operator in a bits intrinsic operation. 10 For bits intrinsic operations other than concatenation (//), the two operands may be of different types 11 or different kind type parameters. The effect is as if each operand that differs in type or kind type 12 parameter from those of the result is converted to the type and kind type parameter of the result before 13 the operation is performed. 14 A relational intrinsic op erator is an intrinsic-operator that is .EQ., .NE., .GT., .GE., .LT., .LE., 15 ==, /=, >, >=, <, or <=. A relational intrinsic op eration is an intrinsic operation for which the 16 intrinsic-operator is a relational intrinsic operator. A numeric relational intrinsic op eration is a 17 relational intrinsic operation for which both operands are of numeric type. A character relational 18 intrinsic op eration is a relational intrinsic operation for which both operands are of type character. 19 The kind type parameters of the operands of a character relational intrinsic operation shall be the same. 20 A bits relational intrinsic op eration is a relational intrinsic operation for which at least one of the 21 operands is of type bits. 22 If both operands of a bits relational operation do not have the same kind type parameter, the operand 23 with the smaller kind type parameter is converted to the same kind as the other operand. If one operand 24 of a bits relational operation is not of type bits, it is converted to type bits with the same kind type 25 parameter as the other operand. Any conversion takes place before the operation is evaluated. 26 7.1.3 Defined operations 27 A defined op eration is either a defined unary operation or a defined binary operation. A defined 28 unary op eration is an operation that has the form defined-unary-op x2 or intrinsic-operator x2 and 29 that is defined by a function and a generic interface (4.5.2, 12.4.2.1). 30 A function defines the unary operation op x2 if 31 (1) the function is specified with a FUNCTION (12.6.2.1) or ENTRY (12.6.2.5) statement that 32 specifies one dummy argument d2 , 33 (2) either 34 (a) a generic interface (12.4.2.1) provides the function with a generic-spec of OPERA- 35 TOR (op ), or 36 (b) there is a generic binding (4.5.2) in the declared type of x2 with a generic-spec of 37 OPERATOR (op ) and there is a corresponding binding to the function in the dynamic 38 type of x2 , 39 the type of d2 is compatible with the dynamic type of x2 , (3) 40 (4) the type parameters, if any, of d2 match the corresponding type parameters of x2 , and 41 (5) either 42 (a) the rank of x2 matches that of d2 or 43 (b) the function is elemental and there is no other function that defines the operation. 44 138 2006/07/11 WORKING DRAFT J3/06-007 If d2 is an array, the shape of x2 shall match the shape of d2 . 1 A defined binary op eration is an operation that has the form x1 defined-binary-op x2 or x1 intrinsic- 2 operator x2 and that is defined by a function and a generic interface. 3 A function defines the binary operation x1 op x2 if 4 (1) the function is specified with a FUNCTION (12.6.2.1) or ENTRY (12.6.2.5) statement that 5 specifies two dummy arguments, d1 and d2 , 6 (2) either 7 (a) a generic interface (12.4.2.1) provides the function with a generic-spec of OPERA- 8 TOR (op ), or 9 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic- 10 spec of OPERATOR (op ) and there is a corresponding binding to the function in the 11 dynamic type of x1 or x2 , respectively, 12 (3) the types of d1 and d2 are compatible with the dynamic types of x1 and x2 , respectively, 13 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 14 and x2 , respectively, and 15 (5) either 16 (a) the ranks of x1 and x2 match those of d1 and d2 or 17 (b) the function is elemental, x1 and x2 are conformable, and there is no other function 18 that defines the operation. 19 If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2 , respectively. 20 NOTE 7.8 An intrinsic operator may be used as the operator in a defined operation. In such a case, the generic properties of the operator are extended. An extension op eration is a defined operation in which the operator is of the form defined-unary-op 21 or defined-binary-op . Such an operator is called an extension op erator. The operator used in an 22 extension operation may be such that a generic interface for the operator may specify more than one 23 function. 24 A defined elemental op eration is a defined operation for which the function is elemental (12.8). 25 7.1.4 Type, typ e parameters, and shap e of an expression 26 The type, type parameters, and shape of an expression depend on the operators and on the types, type 27 parameters, and shapes of the primaries used in the expression, and are determined recursively from 28 the syntactic form of the expression. The type of an expression is one of the intrinsic types (4.4) or a 29 derived type (4.5). 30 If an expression is a polymorphic primary or defined operation, the type parameters and the declared and 31 dynamic types of the expression are the same as those of the primary or defined operation. Otherwise 32 the type parameters and dynamic type of the expression are the same as its declared type and type 33 parameters; they are referred to simply as the type and type parameters of the expression. 34 R724 logical-expr is expr 35 C705 (R724) logical-expr shall be of type logical. 36 139 J3/06-007 WORKING DRAFT 2006/07/11 R725 char-expr is expr 1 C706 (R725) char-expr shall be of type character. 2 R726 default-char-expr is expr 3 C707 (R726) default-char-expr shall be of type default character. 4 R727 int-expr is expr 5 C708 (R727) int-expr shall be of type integer. 6 R728 numeric-expr is expr 7 C709 (R728) numeric-expr shall be of type integer, real, or complex. 8 7.1.4.1 Typ e, typ e parameters, and shap e of a primary 9 The type, type parameters, and shape of a primary are determined according to whether the primary is a 10 constant, variable, array constructor, structure constructor, function reference, type parameter inquiry, 11 type parameter name, or parenthesized expression. If a primary is a constant, its type, type parameters, 12 and shape are those of the constant. If it is a structure constructor, it is scalar and its type and type 13 parameters are as described in 4.5.10. If it is an array constructor, its type, type parameters, and shape 14 are as described in 4.7. If it is a variable or function reference, its type, type parameters, and shape are 15 those of the variable (5.2, 5.3) or the function reference (12.5.2), respectively. If the function reference 16 is generic (12.4.2.1, 13.5) then its type, type parameters, and shape are those of the specific function 17 referenced, which is determined by the types, type parameters, and ranks of its actual arguments as 18 specified in 12.5.4.1. If it is a type parameter inquiry or type parameter name, it is a scalar integer with 19 the kind of the type parameter. 20 If a primary is a parenthesized expression, its type, type parameters, and shape are those of the expres- 21 sion. 22 The associated target ob ject is referenced if a pointer appears as 23 (1) a primary in an intrinsic or defined operation, 24 (2) the expr of a parenthesized primary, or 25 (3) the only primary on the right-hand side of an intrinsic assignment statement. 26 The type, type parameters, and shape of the primary are those of the current target. If the pointer is 27 not associated with a target, it may appear as a primary only as an actual argument in a reference to 28 a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a 29 pointer assignment statement. 30 A disassociated array pointer or an unallocated allocatable array has no shape but does have rank. 31 The type, type parameters, and rank of the result of the NULL intrinsic function depend on context 32 (13.7.131). 33 7.1.4.2 Typ e, typ e parameters, and shap e of the result of an op eration 34 The type of the result of an intrinsic operation [x1 ] op x2 is specified by Table 7.1. The shape of the 35 result of an intrinsic operation is the shape of x2 if op is unary or if x1 is scalar, and is the shape of x1 36 otherwise. 37 The type, type parameters, and shape of the result of a defined operation [x1 ] op x2 are specified by the 38 function defining the operation (7.2). 39 An expression of an intrinsic type has a kind type parameter. An expression of type character also has 40 140 2006/07/11 WORKING DRAFT J3/06-007 a character length parameter. 1 The type parameters of the result of an intrinsic operation are as follows. 2 (1) For an expression x1 // x2 where // is the character intrinsic operator and x1 and x2 are 3 of type character, the character length parameter is the sum of the lengths of the operands 4 and the kind type parameter is the kind type parameter of x1 , which shall be the same as 5 the kind type parameter of x2 . 6 (2) For an expression op x2 where op is an intrinsic unary operator and x2 is of type integer, 7 real, complex, logical, or bits, the kind type parameter of the expression is that of the 8 operand. 9 (3) For an expression x1 op x2 where op is a numeric intrinsic binary operator with one operand 10 of type integer and the other of type real or complex, the kind type parameter of the 11 expression is that of the real or complex operand. 12 (4) For an expression x1 op x2 where op is a numeric intrinsic binary operator with both 13 operands of the same type and kind type parameters, or with one real and one complex 14 with the same kind type parameters, the kind type parameter of the expression is identical 15 to that of each operand. In the case where both operands are integer with different kind type 16 parameters, the kind type parameter of the expression is that of the operand with the greater 17 decimal exponent range if the decimal exponent ranges are different; if the decimal exponent 18 ranges are the same, the kind type parameter of the expression is processor dependent, but 19 it is the same as that of one of the operands. In the case where both operands are any 20 of type real or complex with different kind type parameters, the kind type parameter of 21 the expression is that of the operand with the greater decimal precision if the decimal 22 precisions are different; if the decimal precisions are the same, the kind type parameter of 23 the expression is processor dependent, but it is the same as that of one of the operands. 24 (5) For an expression x1 op x2 where op is a logical intrinsic binary operator with both operands 25 of the same kind type parameter, the kind type parameter of the expression is identical to 26 that of each operand. In the case where both operands are of type logical with different 27 kind type parameters, the kind type parameter of the expression is processor dependent, 28 but it is the same as that of one of the operands. 29 (6) For an expression x1 // x2 where both operands are of type bits, the kind type parameter 30 of the result is the sum of the kind type parameters of the operands. 31 (7) For an expression x1 op x2 where op is a bits intrinsic binary operator other than //, the 32 type of the expression is bits and the kind type parameter of the expression is the maximum 33 of the kind type parameters of x1 and x2 . 34 (8) For an expression x1 op x2 where op is a relational intrinsic operator, the expression has 35 the default logical kind type parameter. 36 C710 The kind type parameter for the result of a bits concatenation operation expression shall be a 37 bits kind type parameter value supported by the processor. 38 7.1.5 Conformability rules for elemental op erations 39 An elemental op eration is an intrinsic operation or a defined elemental operation. Two entities are 40 in shap e conformance if both are arrays of the same shape, or one or both are scalars. 41 For all elemental binary operations, the two operands shall be in shape conformance. In the case where 42 one is a scalar and the other an array, the scalar is treated as if it were an array of the same shape as 43 the array operand with every element, if any, of the array equal to the value of the scalar. 44 141 J3/06-007 WORKING DRAFT 2006/07/11 7.1.6 Sp ecification expression 1 A sp ecification expression is an expression with limitations that make it suitable for use in speci- 2 fications such as length type parameters (C404) and array bounds (R513, R514). A specification-expr 3 shall be an initialization expression unless it is in an interface body (12.4.2.1), the specification part of 4 a subprogram, or the declaration-type-spec of a FUNCTION statement (12.6.2.1). 5 R729 specification-expr is scalar-int-expr 6 C711 (R729) The scalar-int-expr shall be a restricted expression. 7 A restricted expression is an expression in which each operation is intrinsic and each primary is 8 (1) a constant or subob ject of a constant, 9 (2) an ob ject designator with a base ob ject that is a dummy argument that has neither the 10 OPTIONAL nor the INTENT (OUT) attribute, 11 (3) an ob ject designator with a base ob ject that is in a common block, 12 (4) an ob ject designator with a base ob ject that is made accessible by use association or host 13 association, 14 (5) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 15 control is a restricted expression, 16 (6) a structure constructor where each component is a restricted expression, 17 (7) a specification inquiry where each designator or function argument is 18 (a) a restricted expression or 19 (b) a variable whose properties inquired about are not 20 (i) dependent on the upper bound of the last dimension of an assumed-size array, 21 (ii) deferred, or 22 (iii) defined by an expression that is not a restricted expression, 23 (8) a reference to any other standard intrinsic function where each argument is a restricted 24 expression, 25 (9) a reference to a specification function where each argument is a restricted expression, 26 (10) a type parameter of the derived type being defined, 27 (11) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 28 ing ac-implied-do-control is a restricted expression, or 29 (12) a restricted expression enclosed in parentheses, 30 where each subscript, section subscript, substring starting point, substring ending point, and type pa- 31 rameter value is a restricted expression, and where any final subroutine that is invoked is pure. 32 A sp ecification inquiry is a reference to 33 (1) an array inquiry function (13.5.7), 34 (2) the bit inquiry function BIT SIZE, 35 (3) the character inquiry function LEN, 36 (4) the kind inquiry function KIND, 37 (5) the bits kind inquiry function BITS KIND, 38 (6) the character inquiry function NEW LINE, 39 (7) a numeric inquiry function (13.5.6), 40 (8) a type parameter inquiry (6.1.4), 41 (9) an IEEE inquiry function (14.9.1), 42 (10) the function C SIZEOF from the intrinsic module ISO C BINDING (15.2.3.6) , or 43 142 2006/07/11 WORKING DRAFT J3/06-007 (11) the COMPILER VERSION or COMPILER OPTIONS inquiry functions from the intrinsic 1 module ISO FORTRAN ENV (13.8.3.3, 13.8.3.4). 2 A function is a sp ecification function if it is a pure function, is not a standard intrinsic function, is 3 not an internal function, is not a statement function, and does not have a dummy procedure argument. 4 Evaluation of a specification expression shall not directly or indirectly cause a procedure defined by the 5 subprogram in which it appears to be invoked. 6 NOTE 7.9 Specification functions are nonintrinsic functions that may be used in specification expressions to determine the attributes of data ob jects. The requirement that they be pure ensures that they cannot have side effects that could affect other ob jects being declared in the same specification-part . The requirement that they not be internal ensures that they cannot inquire, via host association, about other ob jects being declared in the same specification-part . The prohibition against recursion avoids the creation of a new instance of a procedure while construction of one is in progress. A variable in a specification expression shall have its type and type parameters, if any, specified by a 7 previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, 8 or by host or use association. If a variable in a specification expression is typed by the implicit typing 9 rules, its appearance in any subsequent type declaration statement shall confirm the implied type and 10 type parameters. 11 If a specification expression includes a specification inquiry that depends on a type parameter or an 12 array bound of an entity specified in the same specification-part , the type parameter or array bound 13 shall be specified in a prior specification of the specification-part . The prior specification may be to the 14 left of the specification inquiry in the same statement, but shall not be within the same entity-decl . If a 15 specification expression includes a reference to the value of an element of an array specified in the same 16 specification-part , the array shall be completely specified in prior declarations. 17 NOTE 7.10 The following are examples of specification expressions: LBOUND (B, 1) + 5 ! B is an assumed-shape dummy array M + LEN (C) ! M and C are dummy arguments 2 * PRECISION (A) ! A is a real variable made accessible ! by a USE statement 7.1.7 Initialization expression 18 An initialization expression is an expression with limitations that make it suitable for use as a kind 19 type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, 20 and each primary is 21 (1) a constant or subob ject of a constant, 22 (2) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 23 control is an initialization expression, 24 (3) a structure constructor where each component-spec corresponding to 25 (a) an allocatable component is a reference to the intrinsic function NULL, 26 (b) a pointer component is a reference to the intrinsic function NULL or an initialization 27 target, and 28 (c) any other component is an initialization expression, 29 143 J3/06-007 WORKING DRAFT 2006/07/11 (4) a reference to an elemental standard intrinsic function, where each argument is an initial- 1 ization expression, 2 (5) a reference to a transformational standard intrinsic function other than NULL, where each 3 argument is an initialization expression, 4 (6) A reference to the transformational intrinsic function NULL that does not have an argu- 5 ment with a type parameter that is assumed or is defined by an expression that is not an 6 initialization expression, 7 (7) a reference to the transformational function IEEE SELECTED REAL KIND from the in- 8 trinsic module IEEE ARITHMETIC (14), where each argument is an initialization expres- 9 sion. 10 (8) a specification inquiry where each designator or function argument is 11 (a) an initialization expression or 12 (b) a variable whose properties inquired about are not 13 (i) assumed, 14 (ii) deferred, or 15 (iii) defined by an expression that is not an initialization expression, 16 (9) a kind type parameter of the derived type being defined, 17 (10) a data-i-do-variable within a data-implied-do , 18 (11) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 19 ing ac-implied-do-control is an initialization expression, or 20 (12) an initialization expression enclosed in parentheses, 21 and where each subscript, section subscript, substring starting point, substring ending point, and type 22 parameter value is an initialization expression. 23 R730 initialization-expr is expr 24 C712 (R730) initialization-expr shall be an initialization expression. 25 R731 char-initialization-expr is char-expr 26 C713 (R731) char-initialization-expr shall be an initialization expression. 27 R732 int-initialization-expr is int-expr 28 C714 (R732) int-initialization-expr shall be an initialization expression. 29 R733 logical-initialization-expr is logical-expr 30 C715 (R733) logical-initialization-expr shall be an initialization expression. 31 If an initialization expression includes a specification inquiry that depends on a type parameter or an 32 array bound of an entity specified in the same specification-part , the type parameter or array bound 33 shall be specified in a prior specification of the specification-part . The prior specification may be to the 34 left of the specification inquiry in the same statement, but shall not be within the same entity-decl . 35 NOTE 7.11 The following are examples of initialization expressions: 3 -3 + 4 'AB' 'AB' // 'CD' 144 2006/07/11 WORKING DRAFT J3/06-007 NOTE 7.11 (cont.) ('AB' // 'CD') // 'EF' SIZE (A) DIGITS (X) + 4 4.0 * atan(1.0) ceiling(number_of_decimal_digits / log10(radix(0.0))) where A is an explicit-shaped array with constant bounds and X is of type default real. 7.1.8 Evaluation of operations 1 An intrinsic operation requires the values of its operands. 2 The execution of any numeric operation whose result is not defined by the arithmetic used by the 3 processor is prohibited. Raising a negative-valued primary of type real to a real power is prohibited. 4 The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other 5 entity within the statement. If a function reference causes definition or undefinition of an actual argument 6 of the function, that argument or any associated entities shall not appear elsewhere in the same statement. 7 However, execution of a function reference in the logical expression in an IF statement (8.1.3.4), the mask 8 expression in a WHERE statement (7.4.3.1), or the subscripts and strides in a FORALL statement (7.4.4) 9 is permitted to define variables in the statement that is conditionally executed. 10 NOTE 7.12 For example, the statements A (I) = F (I) Y = G (X) + X are prohibited if the reference to F defines or undefines I or the reference to G defines or undefines X. However, in the statements IF (F (X)) A = X WHERE (G (X)) B = X F or G may define X. The declared type of an expression in which a function reference appears does not affect, and is not 11 affected by, the evaluation of the actual arguments of the function. 12 Execution of an array element reference requires the evaluation of its subscripts. The type of an expres- 13 sion in which the array element reference appears does not affect, and is not affected by, the evaluation 14 of its subscripts. Execution of an array section reference requires the evaluation of its section subscripts. 15 The type of an expression in which an array section appears does not affect, and is not affected by, the 16 evaluation of the array section subscripts. Execution of a substring reference requires the evaluation of 17 its substring expressions. The type of an expression in which a substring appears does not affect, and 18 is not affected by, the evaluation of the substring expressions. It is not necessary for a processor to 19 evaluate any subscript expressions or substring expressions for an array of zero size or a character entity 20 of zero length. 21 The appearance of an array constructor requires the evaluation of each scalar-int-expr of the ac-implied- 22 do-control in any ac-implied-do it may contain. The type of an expression in which an array constructor 23 145 J3/06-007 WORKING DRAFT 2006/07/11 appears does not affect, and is not affected by, the evaluation of such bounds and stride expressions. 1 When an elemental binary operation is applied to a scalar and an array or to two arrays of the same 2 shape, the operation is performed element-by-element on corresponding array elements of the array 3 operands. 4 NOTE 7.13 For example, the array expression A+B produces an array of the same shape as A and B. The individual array elements of the result have the values of the first element of A added to the first element of B, the second element of A added to the second element of B, etc. When an elemental unary operator operates on an array operand, the operation is performed element- 5 by-element, and the result is the same shape as the operand. 6 NOTE 7.14 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. 7.1.8.1 Evaluation of op erands 7 It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely 8 each operand, if the value of the expression can be determined otherwise. 9 NOTE 7.15 This principle is most often applicable to logical expressions, zero-sized arrays, and zero-length strings, but it applies to all expressions. For example, in evaluating the expression X > Y .OR. L (Z) where X, Y, and Z are real and L is a function of type logical, the function reference L (Z) need not be evaluated if X is greater than Y. Similarly, in the array expression W (Z) + A where A is of size zero and W is a function, the function reference W (Z) need not be evaluated. If a statement contains a function reference in a part of an expression that need not be evaluated, all 10 entities that would have become defined in the execution of that reference become undefined at the 11 completion of evaluation of the expression containing the function reference. 12 NOTE 7.16 In the examples in Note 7.15, if L or W defines its argument, evaluation of the expressions under the specified conditions causes Z to become undefined, no matter whether or not L(Z) or W(Z) is evaluated. If a statement contains a function reference in a part of an expression that need not be evaluated, no 13 invocation of that function in that part of the expression shall execute an image control statement other 14 146 2006/07/11 WORKING DRAFT J3/06-007 than CRITICAL or END CRITICAL. 1 NOTE 7.17 This restriction is intended to avoid inadvertant deadlock caused by optimization. 7.1.8.2 Integrity of parentheses 2 Subclauses 7.1.8.2 to 7.1.8.7 state certain conditions under which a processor may evaluate an expression 3 that is different from the one specified by applying the rules given in 7.1.1 and 7.2. However, any 4 expression in parentheses shall be treated as a data entity. 5 NOTE 7.18 For example, in evaluating the expression A + (B ­ C) where A, B, and C are of numeric types, the difference of B and C shall be evaluated before the addition operation is performed; the processor shall not evaluate the mathematically equivalent expression (A + B) ­ C. 7.1.8.3 Evaluation of numeric intrinsic op erations 6 The rules given in 7.2.2 specify the interpretation of a numeric intrinsic operation. Once the interpreta- 7 tion has been established in accordance with those rules, the processor may evaluate any mathematically 8 equivalent expression, provided that the integrity of parentheses is not violated. 9 Two expressions of a numeric type are mathematically equivalent if, for all possible values of their 10 primaries, their mathematical values are equal. However, mathematically equivalent expressions of 11 numeric type may produce different computational results. 12 NOTE 7.19 Any difference between the values of the expressions (1./3.)*3. and 1. is a computational difference, not a mathematical difference. The difference between the values of the expressions 5/2 and 5./2. is a mathematical difference, not a computational difference. The mathematical definition of integer division is given in 7.2.2.1. NOTE 7.20 The following are examples of expressions with allowable alternative forms that may be used by the processor in the evaluation of those expressions. A, B, and C represent arbitrary real or complex operands; I and J represent arbitrary integer operands; and X, Y, and Z represent arbitrary operands of numeric type. Expression Allowable alternative form X+Y Y+X X*Y Y*X -X + Y Y-X X+Y+Z X + (Y + Z) X-Y+Z X - (Y - Z) X*A/Z X * (A / Z) X*Y-X*Z X * (Y - Z) A/B/C A / (B * C) A / 5.0 0.2 * A The following are examples of expressions with forbidden alternative forms that shall not be used by a processor in the evaluation of those expressions. 147 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.20 (cont.) Expression Forbidden alternative form I/2 0.5 * I X*I/J X * (I / J) I/J/A I / (J * A) (X + Y) + Z X + (Y + Z) (X * Y) - (X * Z) X * (Y - Z) X * (Y - Z) X*Y-X*Z In addition to the parentheses required to establish the desired interpretation, parentheses may be 1 included to restrict the alternative forms that may be used by the processor in the actual evaluation 2 of the expression. This is useful for controlling the magnitude and accuracy of intermediate values 3 developed during the evaluation of an expression. 4 NOTE 7.21 For example, in the expression A + (B - C) the parenthesized expression (B ­ C) shall be evaluated and then added to A. The inclusion of parentheses may change the mathematical value of an expression. For example, the two expressions A*I/J A * (I / J) may have different mathematical values if I and J are of type integer. Each operand in a numeric intrinsic operation has a type that may depend on the order of evaluation 5 used by the processor. 6 NOTE 7.22 For example, in the evaluation of the expression Z+R+I where Z, R, and I represent data ob jects of complex, real, and integer type, respectively, the type of the operand that is added to I may be either complex or real, depending on which pair of operands (Z and R, R and I, or Z and I) is added first. 7.1.8.4 Evaluation of the character intrinsic op eration 7 The rules given in 7.2.3 specify the interpretation of the character intrinsic operation. A processor is 8 only required to evaluate as much of the character intrinsic operation as is required by the context in 9 which the expression appears. 10 NOTE 7.23 For example, the statements CHARACTER (LEN = 2) C1, C2, C3, CF C1 = C2 // CF (C3) 148 2006/07/11 WORKING DRAFT J3/06-007 NOTE 7.23 (cont.) do not require the function CF to be evaluated, because only the value of C2 is needed to determine the value of C1 because C1 and C2 both have a length of 2. 7.1.8.5 Evaluation of relational intrinsic op erations 1 The rules given in 7.2.4 specify the interpretation of relational intrinsic operations. Once the interpre- 2 tation of an expression has been established in accordance with those rules, the processor may evaluate 3 any other expression that is relationally equivalent, provided that the integrity of parentheses in any 4 expression is not violated. 5 NOTE 7.24 For example, the processor may choose to evaluate the expression I>J where I and J are integer variables, as J-I<0 Two relational intrinsic operations are relationally equivalent if their logical values are equal for all 6 possible values of their primaries. 7 7.1.8.6 Evaluation of logical intrinsic op erations 8 The rules given in 7.2.5 specify the interpretation of logical intrinsic operations. Once the interpretation 9 of an expression has been established in accordance with those rules, the processor may evaluate any 10 other expression that is logically equivalent, provided that the integrity of parentheses in any expression 11 is not violated. 12 NOTE 7.25 For example, for the variables L1, L2, and L3 of type logical, the processor may choose to evaluate the expression L1 .AND. L2 .AND. L3 as L1 .AND. (L2 .AND. L3) Two expressions of type logical are logically equivalent if their values are equal for all possible values of 13 their primaries. 14 7.1.8.7 Evaluation of bits intrinsic op erations 15 The rules given in 7.2.6 specify the interpretation of bits intrinsic operations. Once the interpretation 16 of an expression has been established in accordance with those rules, the processor may evaluate any 17 other expression that is computationally equivalent, provided that the integrity of parentheses in any 18 expression is not violated. 19 149 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.26 For example, for the variables B1, B2, and B3 of type bits, the processor may choose to evaluate the expression B1 .XOR. B2 .XOR. B3 as B1 .XOR. (B2 .XOR. B3) Two expressions of type bits are computationally equivalent if their values are equal for all possible 1 values of their primaries. 2 7.1.8.8 Evaluation of a defined op eration 3 The rules given in 7.2 specify the interpretation of a defined operation. Once the interpretation of an 4 expression has been established in accordance with those rules, the processor may evaluate any other 5 expression that is equivalent, provided that the integrity of parentheses is not violated. 6 Two expressions of derived type are equivalent if their values are equal for all possible values of their 7 primaries. 8 7.2 Interpretation of op erations 9 7.2.1 General 10 The intrinsic operations are those defined in 7.1.2. These operations are divided into the following 11 categories: numeric, character, relational, logical, and bits. The interpretations defined in subclause 7.2 12 apply to both scalars and arrays; the interpretation for arrays is obtained by applying the interpretation 13 for scalars element by element. 14 The interpretation of a defined operation is provided by the function that defines the operation. The type, 15 type parameters and interpretation of an expression that consists of an intrinsic or defined operation are 16 independent of the type and type parameters of the context or any larger expression in which it appears. 17 NOTE 7.27 For example, if X is of type real, J is of type integer, and INT is the real-to-integer intrinsic conversion function, the expression INT (X + J) is an integer expression and X + J is a real expression. The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 18 .LE., .GT., .GE., .EQ., and .NE., respectively. 19 7.2.2 Numeric intrinsic op erations 20 A numeric operation is used to express a numeric computation. Evaluation of a numeric operation 21 produces a numeric value. The permitted data types for operands of the numeric intrinsic operations 22 are specified in 7.1.2. 23 The numeric operators and their interpretation in an expression are given in Table 7.2, where x1 denotes 24 the operand to the left of the operator and x2 denotes the operand to the right of the operator. 25 150 2006/07/11 WORKING DRAFT J3/06-007 Table 7.2: Interpretation of the numeric intrinsic op erators Operator Representing Use of operator Interpretation ** Exponentiation x1 ** x2 Raise x1 to the power x2 / Division x1 / x2 Divide x1 by x2 * Multiplication x1 * x2 Multiply x1 by x2 - Subtraction x1 - x2 Subtract x2 from x1 - Negation - x2 Negate x2 + Addition x1 + x2 Add x1 and x2 + Identity + x2 Same as x2 The interpretation of a division operation depends on the types of the operands (7.2.2.1). 1 If x1 and x2 are of type integer and x2 has a negative value, the interpretation of x1 ** x2 is the same 2 as the interpretation of 1/(x1 ** ABS (x2 )), which is sub ject to the rules of integer division (7.2.2.1). 3 NOTE 7.28 For example, 2 ** (­3) has the value of 1/(2 ** 3), which is zero. 7.2.2.1 Integer division 4 One operand of type integer may be divided by another operand of type integer. Although the math- 5 ematical quotient of two integers is not necessarily an integer, Table 7.1 specifies that an expression 6 involving the division operator with two operands of type integer is interpreted as an expression of type 7 integer. The result of such an operation is the integer closest to the mathematical quotient and between 8 zero and the mathematical quotient inclusively. 9 NOTE 7.29 For example, the expression (­8) / 3 has the value (­2). 7.2.2.2 Complex exp onentiation 10 In the case of a complex value raised to a complex power, the value of the operation x1 ** x2 is the 11 principal value of xx2 . 12 1 7.2.3 Character intrinsic op eration 13 The character intrinsic operator // is used to concatenate two operands of type character with the same 14 kind type parameter. Evaluation of the character intrinsic operation produces a result of type character. 15 The interpretation of the character intrinsic operator // when used to form an expression is given in 16 Table 7.3, where x1 denotes the operand to the left of the operator and x2 denotes the operand to the 17 right of the operator. 18 Table 7.3: Interpretation of the character intrinsic op erator // Operator Representing Use of operator Interpretation // Concatenation x1 // x2 Concatenate x1 with x2 The result of the character intrinsic operation // is a character string whose value is the value of x1 19 concatenated on the right with the value of x2 and whose length is the sum of the lengths of x1 and x2 . 20 Parentheses used to specify the order of evaluation have no effect on the value of a character expression. 21 151 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.30 For example, the value of ('AB' // 'CDE') // 'F' is the string 'ABCDEF'. Also, the value of 'AB' // ('CDE' // 'F') is the string 'ABCDEF'. 7.2.4 Relational intrinsic op erations 1 A relational intrinsic operation is used to compare values of two operands using the relational intrinsic 2 operators .LT., .LE., .GT., .GE., .EQ., .NE., <, <=, >, >=, ==, and /=. The permitted types for 3 operands of the relational intrinsic operators are specified in 7.1.2. 4 NOTE 7.31 As shown in Table 7.1, a relational intrinsic operator cannot be used to compare the value of an expression of a numeric type with one of type character or logical. Also, two operands of type logical cannot be compared, a complex operand may be compared with another numeric operand only when the operator is .EQ., .NE., ==, or /=, and two character operands cannot be compared unless they have the same kind type parameter value. Evaluation of a relational intrinsic operation produces a result of type default logical. 5 The interpretation of the relational intrinsic operators is given in Table 7.4, where x1 denotes the operand 6 to the left of the operator and x2 denotes the operand to the right of the operator. 7 Table 7.4: Interpretation of the relational intrinsic op erators Operator Representing Use of operator Interpretation .LT. Less than x1 .LT. x2 x1 less than x2 < Less than x1 < x2 x1 less than x2 .LE. Less than or equal to x1 .LE. x2 x1 less than or equal to x2 <= Less than or equal to x1 <= x2 x1 less than or equal to x2 .GT. Greater than x1 .GT. x2 x1 greater than x2 > Greater than x1 > x2 x1 greater than x2 .GE. Greater than or equal to x1 .GE. x2 x1 greater than or equal to x2 >= Greater than or equal to x1 >= x2 x1 greater than or equal to x2 .EQ. Equal to x1 .EQ. x2 x1 equal to x2 == Equal to x1 == x2 x1 equal to x2 .NE. Not equal to x1 .NE. x2 x1 not equal to x2 /= Not equal to x1 /= x2 x1 not equal to x2 A numeric relational intrinsic operation is interpreted as having the logical value true if and only if the 8 values of the operands satisfy the relation specified by the operator. 9 In the numeric relational operation 10 x1 rel-op x2 11 if the types or kind type parameters of x1 and x2 differ, their values are converted to the type and kind 12 type parameter of the expression x1 + x2 before evaluation. 13 A character relational intrinsic operation is interpreted as having the logical value true if and only if the 14 values of the operands satisfy the relation specified by the operator. 15 For a character relational intrinsic operation, the operands are compared one character at a time in 16 order, beginning with the first character of each character operand. If the operands are of unequal 17 length, the shorter operand is treated as if it were extended on the right with blanks to the length of 18 152 2006/07/11 WORKING DRAFT J3/06-007 the longer operand. If both x1 and x2 are of zero length, x1 is equal to x2 ; if every character of x1 is 1 the same as the character in the corresponding position in x2 , x1 is equal to x2 . Otherwise, at the first 2 position where the character operands differ, the character operand x1 is considered to be less than x2 3 if the character value of x1 at this position precedes the value of x2 in the collating sequence (4.4.5.4); 4 x1 is greater than x2 if the character value of x1 at this position follows the value of x2 in the collating 5 sequence. 6 NOTE 7.32 The collating sequence depends partially on the processor; however, the result of the use of the operators .EQ., .NE., ==, and /= does not depend on the collating sequence. For nondefault character types, the blank padding character is processor dependent. A bits relational intrinsic operation is interpreted as having the logical value true if and only if the values 7 of the operands satisfy the relation specified by the operator. 8 For a bits relational intrinsic operation, x1 and x2 are equal if and only if each corresponding bit has 9 the same value. If x1 and x2 are not equal, and the leftmost unequal corresponding bit of x1 is 1 and 10 x2 is 0 then x1 is greater than x2 ; otherwise x1 is less than x2 . 11 7.2.5 Logical intrinsic op erations 12 A logical operation is used to express a logical computation. Evaluation of a logical operation produces 13 a result of type logical. The permitted types for operands of the logical intrinsic operations are specified 14 in 7.1.2. 15 The logical operators and their interpretation when used to form an expression are given in Table 7.5, 16 where x1 denotes the operand to the left of the operator and x2 denotes the operand to the right of the 17 operator. 18 Table 7.5: Interpretation of the logical intrinsic op erators Representing Use of operator Interpretation Operator True if x2 is false Logical negation .NOT. .NOT. x2 True if x1 and x2 are both true Logical conjunction .AND. x1 .AND. x2 Logical inclusive disjunction True if x1 and/or x2 is true .OR. x1 .OR. x2 True if both x1 and x2 are true or Logical equivalence .EQV. x1 .EQV. x2 both are false True if either x1 or x2 is true, but Logical nonequivalence .NEQV. x1 .NEQV. x2 not both True if either x1 or x2 is true, but Logical nonequivalence .XOR. x1 .XOR. x2 not both The values of the logical intrinsic operations are shown in Table 7.6. 19 Table 7.6: The values of op erations involving logical intrinsic op erators x1 x2 .NOT. x2 x1 .AND. x2 x1 .OR. x2 x1 .EQV. x2 x1 .NEQV. x2 x1 .XOR. x2 true true false true true true false false true false true false true false true true false true false false true false true true false false true false false true false false 153 J3/06-007 WORKING DRAFT 2006/07/11 7.2.6 Bits intrinsic op erations 1 Bit operations are used to express bitwise operations on sequences of bits, or to concatenate such 2 sequences. Evaluation of a bits operation produces a result of type bits. The permitted types of 3 operands of the bits intrinsic operations are specified in 7.1.2. 4 The bits operators and their interpretation when used to form an expression are given in Table 7.7, 5 where x1 denotes the operand of type bits to the left of the operator and x2 denotes the operand of type 6 bits to the right of the operator. 7 Table 7.7: Interpretation of the bits intrinsic op erators Operator Representing Use of operator Interpretation (//) Concatenation x1 // x2 Concatenation of x1 and x2 .NOT. Bitwise NOT .NOT. x2 Bitwise NOT of x2 .AND. Bitwise AND x1 .AND. x2 Bitwise AND of x1 and x2 .OR. Bitwise inclusive OR x1 .OR. x2 Bitwise OR of x1 and x2 .EQV. Bitwise equivalence x1 .EQV. x2 Bitwise equivalence of x1 and x2 .NEQV. Bitwise nonequivalence x1 .NEQV. x2 Bitwise nonequivalence of x1 and x2 .XOR. Bitwise exclusive OR x1 .XOR. x2 Bitwise exclusive OR of x1 and x2 The leftmost KIND(x1 ) bits of the result of the bits concatenation operation are the value of x1 and the 8 rightmost KIND(x2 ) bits of the result are the value of x2 . 9 For a bits intrinsic operation other than //, the result value is computed separately for each pair of bits 10 at corresponding positions in each operand. The value of each bit operation, for bits denoted b1 and b2 11 are given in Table 7.8. 12 Table 7.8: The values of bitwise op erations involving bits intrinsic op era- tors x1 x2 .NOT. x2 x1 .AND. x2 x1 .OR. x2 x1 .EQV. x2 x1 .NEQV. x2 x1 .XOR. x2 1 1 0 1 1 1 0 0 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 0 0 1 0 0 7.3 Precedence of op erators 13 There is a precedence among the intrinsic and extension operations corresponding to the form of expres- 14 sions specified in 7.1.1, which determines the order in which the operands are combined unless the order 15 is changed by the use of parentheses. This precedence order is summarized in Table 7.9. 16 Table 7.9: Categories of op erations 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. . 154 2006/07/11 WORKING DRAFT J3/06-007 Categories of op erations and relative precedence (cont.) Category of operation Operators Precedence Logical, Bits .AND. . Logical, Bits .OR. . Logical, Bits .EQV., .NEQV., .XOR. . Extension defined-binary-op Lowest The precedence of a defined operation is that of its operator. 1 NOTE 7.33 For example, in the expression -A ** 2 the exponentiation operator (**) has precedence over the negation operator (­); therefore, the operands of the exponentiation operator are combined to form an expression that is used as the operand of the negation operator. The interpretation of the above expression is the same as the interpretation of the expression - (A ** 2) The general form of an expression (7.1.1) also establishes a precedence among operators in the same 2 syntactic class. This precedence determines the order in which the operands are to be combined in 3 determining the interpretation of the expression unless the order is changed by the use of parentheses. 4 NOTE 7.34 In interpreting a level-2-expr containing two or more binary operators + or ­, each operand (add- operand ) is combined from left to right. Similarly, the same left-to-right interpretation for a mult- operand in add-operand , as well as for other kinds of expressions, is a consequence of the general form. However, for interpreting a mult-operand expression when two or more exponentiation operators ** combine level-1-expr operands, each level-1-expr is combined from right to left. For example, the expressions 2.1 + 3.4 + 4.9 2.1 * 3.4 * 4.9 2.1 / 3.4 / 4.9 2 ** 3 ** 4 'AB' // 'CD' // 'EF' have the same interpretations as the expressions (2.1 + 3.4) + 4.9 (2.1 * 3.4) * 4.9 (2.1 / 3.4) / 4.9 2 ** (3 ** 4) ('AB' // 'CD') // 'EF' As a consequence of the general form (7.1.1), only the first add-operand of a level-2-expr may be preceded by the identity (+) or negation (­) operator. These formation rules do not permit expressions containing two consecutive numeric operators, such as A ** ­B or A + ­B. However, expressions such as A ** (­B) and A + (­B) are permitted. The rules do allow a binary operator 155 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.34 (cont.) 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.35 An expression may contain more than one category of operator. The logical expression L .OR. A + B >= C where A, B, and C are of type real, and L is of type logical, contains a numeric operator, a relational operator, and a logical operator. This expression would be interpreted the same as the expression L .OR. ((A + B) >= C) NOTE 7.36 If (1) The operator ** is extended to type logical, (2) The operator .STARSTAR. is defined to duplicate the function of ** on type real, (3) .MINUS. is defined to duplicate the unary operator ­, and (4) L1 and L2 are type logical and X and Y are type real, then in precedence: L1 ** L2 is higher than X * Y; X * Y is higher than X .STARSTAR. Y; and .MINUS. X is higher than ­X. 7.4 Assignment 1 Execution of an assignment statement causes a variable to become defined or redefined. Execution of a 2 pointer assignment statement causes a pointer to become associated with a target or causes its pointer 3 association status to become disassociated or undefined. Execution of a WHERE statement or WHERE 4 construct masks the evaluation of expressions and assignment of values in array assignment statements 5 according to the value of a logical array expression. Execution of a FORALL statement or FORALL 6 construct controls the assignment to elements of arrays by using a set of index variables and a mask 7 expression. 8 7.4.1 Assignment statement 9 A variable may be defined or redefined by execution of an assignment statement. 10 156 2006/07/11 WORKING DRAFT J3/06-007 7.4.1.1 General form 1 R734 assignment-stmt is variable = expr 2 C716 (R734) The variable shall not be a whole assumed-size array. 3 NOTE 7.37 Examples of an assignment statement are: A = 3.5 + X * Y I = INT (A) An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic 4 assignment statement. 5 7.4.1.2 Intrinsic assignment statement 6 An intrinsic assignment statement is an assignment statement that is not a defined assignment 7 statement (7.4.1.4). In an intrinsic assignment statement, 8 (1) if the variable is polymorphic it shall be allocatable, 9 (2) if variable is a co-indexed ob ject, it shall not be of a type that has an allocatable ultimate 10 component, 11 J3 internal note Unresolved Technical Issue 23 06-174r3 had no edit about this at all; when it came up in discussion with JKR et al they suggested making a runtime requirement that the types and shapes of the allocatable components must match; however, that would be very unsafe. Since the only safe way of programming such an assignment would be to avoid the intrinsic assignment altogether, we should not allow the intrinsic assignment in this case. Furthermore, giving different semantics to intrinsic assignment when a component is a co-indexed ob ject is a bad idea - it will confuse the users ­ better to disallow the discrepant inconsistency. The fact that this inherently unsafe idea affects cross-image variables with all the fun of race conditions and other goodies to make debugging impossible simply underlines that this is a bad idea." (3) if expr is an array then the variable shall also be an array, 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 ob ject, 14 (5) if the variable is an allocatable co-array or co-indexed ob ject, its dynamic type shall be the 15 same as that of expr , 16 J3 internal note Unresolved Technical Issue 24 Since this almost completely guts the polymorphic assignment feature for co-things, why not just disallow polymorphic assigment altogether for co-things? That would be MUCH SAFER, and result in the loss of almost no functionality (one can point a non-polymorphic pointer at the polymorphic co-thing if one wishes to do the required assignment. Furthermore, doing that would still allow co-arrays to be extended later on to "do the right thing" for polymorphic assignment. (6) if the variable is polymorphic it shall be type compatible with expr and have the same rank; 17 otherwise the declared types of the variable and expr shall conform as specified in Table 18 157 J3/06-007 WORKING DRAFT 2006/07/11 7.10, and 1 (7) if the variable is of derived type each kind type parameter of the variable shall have the 2 same value as the corresponding type parameter of expr , and 3 (8) if the variable is of derived type each length type parameter of the variable shall have the 4 same value as the corresponding type parameter of expr unless the variable is allocatable 5 and its corresponding type parameter is deferred. 6 7 Table 7.10: Typ e 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 A numeric intrinsic assignment statement is an intrinsic assignment statement for which the vari- 8 able and expr are of numeric type. A character intrinsic assignment statement is an intrinsic 9 assignment statement for which the variable and expr are of type character. A logical intrinsic as- 10 signment statement is an intrinsic assignment statement for which the variable and expr are of type 11 logical. A bits intrinsic assignment statement is an intrinsic assignment statement for which either 12 the variable or expr is of type bits. A derived-typ e intrinsic assignment statement is an intrinsic 13 assignment statement for which the variable and expr are of derived type. 14 An array intrinsic assignment statement is an intrinsic assignment statement for which the variable 15 is an array. The the variable shall not be a many-one array section (6.2.2.3.2). 16 If the variable is a pointer, it shall be associated with a definable target such that the type, type 17 parameters, and shape of the target and expr conform. 18 7.4.1.3 Interpretation of intrinsic assignments 19 Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expr and all 20 expressions within variable (7.1.8), the possible conversion of expr to the type and type parameters of 21 the variable (Table 7.11), and the definition of the variable with the resulting value. The execution of 22 the assignment shall have the same effect as if the evaluation of expr and the evaluation of all expressions 23 in variable occurred before any portion of the variable is defined by the assignment. The evaluation of 24 expressions within variable shall neither affect nor be affected by the evaluation of expr . No value is 25 assigned to the variable if it is of type character and zero length, or is an array of size zero. 26 If the variable is a pointer, the value of expr is assigned to the target of the variable. 27 If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, 28 any of the corresponding length type parameter values of the variable and expr differ, or the dynamic 29 type of the variable and ¡expr¿ differ. If the variable is or becomes an unallocated allocatable variable, 30 then it is allocated with each deferred type parameter equal to the corresponding type parameter of expr , 31 with the shape of expr , with each lower bound equal to the corresponding element of LBOUND(expr ), 32 and with the same dynamic type as expr . 33 158 2006/07/11 WORKING DRAFT J3/06-007 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. Both variable and expr may contain references to any portion of the variable. 1 NOTE 7.39 For example, in the character intrinsic assignment statement: STRING (2:5) = STRING (1:4) the assignment of the first character of STRING to the second character does not affect the evaluation of STRING (1:4). If the value of STRING prior to the assignment was 'ABCDEF', the value following the assignment is 'AABCDF'. If expr is a scalar and the variable is an array, the expr is treated as if it were an array of the same 2 shape as the variable with every element of the array equal to the scalar value of expr . 3 If the variable is an array, the assignment is performed element-by-element on corresponding array 4 elements of the variable and expr . 5 NOTE 7.40 For example, if A and B are arrays of the same shape, the array intrinsic assignment A=B assigns the corresponding elements of B to those of A; that is, the first element of B is assigned to the first element of A, the second element of B is assigned to the second element of A, etc. If C is an allocatable array of rank 1, then C = PACK(ARRAY,ARRAY>0) will cause C to contain all the positive elements of ARRAY in array element order; if C is not allocated or is allocated with the wrong size, it will be re-allocated to be of the correct size to hold the result of PACK. The processor may perform the element-by-element assignment in any order. 6 159 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.41 For example, the following program segment results in the values of the elements of array X being reversed: REAL X (10) ... X (1:10) = X (10:1:-1) For a numeric intrinsic assignment statement, the variable and expr may have different numeric types 1 or different kind type parameters, in which case the value of expr is converted to the type and kind type 2 parameter of the variable according to the rules of Table 7.11. 3 Table 7.11: Numeric conversion and the assignment statement Type of the variable Value Assigned integer INT (expr , KIND = KIND (variable )) real REAL (expr , KIND = KIND (variable )) complex CMPLX (expr , KIND = KIND (variable )) Note: The functions INT, REAL, CMPLX, and KIND are the generic functions defined in 13.7. For a logical intrinsic assignment statement, the variable and expr may have different kind type param- 4 eters, in which case the value of expr is converted to the kind type parameter of the variable. 5 For a character intrinsic assignment statement, the variable and expr may have different character length 6 parameters in which case the conversion of expr to the length of the variable is as follows. 7 (1) If the length of the variable is less than that of expr , the value of expr is truncated from 8 the right until it is the same length as the variable. 9 (2) If the length of the variable is greater than that of expr , the value of expr is extended on 10 the right with blanks until it is the same length as the variable. 11 If the variable and expr have different kind type parameters, each character c in expr is converted to 12 the kind type parameter of the variable by ACHAR(IACHAR(c ),KIND(variable )). 13 NOTE 7.42 For nondefault character types, the blank padding character is processor dependent. When assign- ing a character expression to a variable of a different kind, each character of the expression that is not representable in the kind of the variable is replaced by a processor-dependent character. For a bits intrinsic assignment statement, the variable and expr may have different types or different 14 kind type parameters, in which case the value of expr is converted to the type and kind type parameter 15 of the variable according to the rules of Table 7.12. 16 Table 7.12: Bits conversion and the assignment statement Type of the variable Value Assigned integer INT (expr , KIND = KIND (variable )) real REAL (expr , KIND = KIND (variable )) complex CMPLX (expr , KIND = KIND (variable )) logical LOGICAL (expr , KIND = KIND (variable )) bits BITS (expr , KIND = KIND (variable )) Note: The functions BITS, INT, REAL, CMPLX, and KIND are the generic functions defined in 13.7. 160 2006/07/11 WORKING DRAFT J3/06-007 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 copies it to the part of the result which occurs first in memory address order and leaves the remaining bits of the result processor-dependent, whereas bits assignment copies the source to the rightmost bits and makes the remaining bits all zero. A derived-type intrinsic assignment is performed as if each component of the variable were assigned 1 from the corresponding component of expr using pointer assignment (7.4.2) for each pointer component, 2 defined assignment for each nonpointer nonallocatable component of a type that has a type-bound 3 defined assignment consistent with the component, intrinsic assignment for each co-array component, and 4 intrinsic assignment for each other nonpointer nonallocatable component. For a non-co-array allocatable 5 component the following sequence of operations is applied. 6 (1) If the component of the variable is allocated, it is deallocated. 7 (2) If the component of the value of expr is allocated, the corresponding component of the 8 variable is allocated with the same dynamic type and type parameters as the component 9 of the value of expr . If it is an array, it is allocated with the same bounds. The value of 10 the component of the value of expr is then assigned to the corresponding component of the 11 variable using defined assignment if the declared type of the component has a type-bound 12 defined assignment consistent with the component, and intrinsic assignment for the dynamic 13 type of that component otherwise. 14 The processor may perform the component-by-component assignment in any order or by any means that 15 has the same effect. 16 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 ob jects of that type have a compatible type-bound defined assignment, and intrinsic assignment otherwise. NOTE 7.45 If an allocatable component of expr is unallocated, the corresponding component of the variable has an allocation status of unallocated after execution of the assignment. 7.4.1.4 Defined assignment statement 17 A defined assignment statement is an assignment statement that is defined by a subroutine and a 18 generic interface (4.5.2, 12.4.2.1.2) that specifies ASSIGNMENT (=). A defined elemental assign- 19 161 J3/06-007 WORKING DRAFT 2006/07/11 ment statement is a defined assignment statement for which the subroutine is elemental (12.8). 1 A subroutine defines the defined assignment x1 = x2 if 2 (1) the subroutine is specified with a SUBROUTINE (12.6.2.2) or ENTRY (12.6.2.5) statement 3 that specifies two dummy arguments, d1 and d2 , 4 (2) either 5 (a) a generic interface (12.4.2.1) provides the subroutine with a generic-spec of ASSIGN- 6 MENT (=), or 7 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic-spec 8 of ASSIGNMENT (=) and there is a corresponding binding to the subroutine in the 9 dynamic type of x1 or x2 , respectively, 10 (3) the types of d1 and d2 are compatible with the dynamic types of x1 and x2 , respectively, 11 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 12 and x2 , respectively, and 13 (5) either 14 (a) the ranks of x1 and x2 match those of d1 and d2 or 15 (b) the subroutine is elemental, x1 and x2 are conformable, and there is no other subrou- 16 tine that defines the operation. 17 If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2 , respectively. 18 7.4.1.5 Interpretation of defined assignment statements 19 The interpretation of a defined assignment is provided by the subroutine that defines it. 20 If the defined assignment is an elemental assignment and the the variable in the assignment is an array, 21 the defined assignment is performed element-by-element, on corresponding elements of the variable and 22 expr . If expr is a scalar, it is treated as if it were an array of the same shape as the variable with every 23 element of the array equal to the scalar value of expr . 24 NOTE 7.46 The rules of defined assignment (12.4.2.1.2), procedure references (12.5), subroutine references (12.5.3), and elemental subroutine arguments (12.8.3) ensure that the defined assignment has the same effect as if the evaluation of all operations in x2 and x1 occurs before any portion of x1 is defined. If an elemental assignment is defined by a pure elemental subroutine, the element assignments may be performed simultaneously or in any order. 7.4.2 Pointer assignment 25 Pointer assignment causes a pointer to become associated with a target or causes its pointer association 26 status to become disassociated or undefined. Any previous association between the pointer and a target 27 is broken. 28 Pointer assignment for a pointer component of a structure may also take place by execution of a derived- 29 type intrinsic assignment statement (7.4.1.3). 30 A pointer may also become associated with a target by allocation of the pointer. 31 R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec -list ) ] => data-target 32 or data-pointer-object (bounds-remapping -list ) => data-target 33 or proc-pointer-object => proc-target 34 162 2006/07/11 WORKING DRAFT J3/06-007 R736 data-pointer-object is variable-name 1 or scalar-variable % data-pointer-component-name 2 C717 (R735) If data-target is not unlimited polymorphic, either data-pointer-object shall be type 3 compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal, or 4 data-target and data-pointer-object shall be bits compatible. 5 C718 (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- 6 phic, of a sequence derived type, or of a type with the BIND attribute. 7 C719 (R735) If bounds-spec -list is specified, the number of bounds-spec s shall equal the rank of data- 8 pointer-object . 9 C720 (R735) If bounds-remapping -list is specified, the number of bounds-remapping s shall equal the 10 rank of data-pointer-object . 11 C721 (R735) If bounds-remapping -list is not specified, the ranks of data-pointer-object and data-target 12 shall be the same. 13 C722 (R736) A variable-name shall have the POINTER attribute. 14 C723 (R736) A scalar-variable shall be a data-ref . 15 C724 (R736) A data-pointer-component-name shall be the name of a component of scalar-variable 16 that is a data pointer. 17 C725 (R736) A data-pointer-object shall not be a co-indexed ob ject. 18 R737 bounds-spec is lower-bound-expr : 19 R738 bounds-remapping is lower-bound-expr : upper-bound-expr 20 R739 data-target is variable 21 or expr 22 C726 (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an 23 array section with a vector subscript. 24 C727 (R739) A data-target shall not be a co-indexed ob ject. 25 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. 26 R740 proc-pointer-object is proc-pointer-name 27 or proc-component-ref 28 R741 proc-component-ref is scalar-variable % procedure-component-name 29 C729 (R741) The scalar-variable shall be a data-ref . 30 C730 (R741) The procedure-component-name shall be the name of a procedure pointer component of 31 the declared type of scalar-variable . 32 R742 proc-target is expr 33 163 J3/06-007 WORKING DRAFT 2006/07/11 or procedure-name 1 or proc-component-ref 2 C731 (R742) An expr shall be a reference to a function whose result is a procedure pointer. 3 C732 (R742) A procedure-name shall be the name of an external, internal, module, or dummy proce- 4 dure, a procedure pointer, or a specific intrinsic function listed in 13.6 and not marked with a 5 bullet (·). 6 C733 (R742) The proc-target shall not be a nonintrinsic elemental procedure. 7 7.4.2.1 Data p ointer assignment 8 If data-pointer-object is not polymorphic and data-target is polymorphic with dynamic type that differs 9 from its declared type, the assignment target is the ancestor component of data-target that has the type 10 of data-pointer-object . Otherwise, the assignment target is data-target . 11 If data-target is not a pointer, data-pointer-object becomes pointer associated with the assignment target. 12 Otherwise, the pointer association status of data-pointer-object becomes that of data-target ; if data-target 13 is associated with an ob ject, data-pointer-object becomes associated with the assignment target. If data- 14 target is allocatable, it shall be allocated. 15 If data-pointer-object is polymorphic (4.3.1.3), it assumes the dynamic type of data-target . If data- 16 pointer-object is of sequence derived type or a type with the BIND attribute, the dynamic type of 17 data-target shall be that derived type. 18 If data-target is a disassociated pointer, all nondeferred type parameters of the declared type of data- 19 pointer-object that correspond to nondeferred type parameters of data-target shall have the same values 20 as the corresponding type parameters of data-target , or data-pointer-object and data-target shall be bits 21 compatible (4.3.1.3). 22 Otherwise, all nondeferred type parameters of the declared type of data-pointer-object shall have the 23 same values as the corresponding type parameters of data-target . 24 If data-pointer-object has nondeferred type parameters that correspond to deferred type parameters of 25 data-target , data-target shall not be a pointer with undefined association status. 26 If data-pointer-object has the CONTIGUOUS attribute, data-target shall be contiguous. 27 If bounds-remapping -list is specified, data-target shall be contiguous (5.3.6) or of rank one. It shall not 28 be a disassociated or undefined pointer, and the size of data-target shall not be less than the size of 29 data-pointer-object . The elements of the target of data-pointer-object , in array element order (6.2.2.2), 30 are the first SIZE(data-pointer-object ) elements of data-target . 31 If no bounds-remapping -list is specified, the extent of a dimension of data-pointer-object is the extent of 32 the corresponding dimension of data-target . If bounds-spec -list appears, it specifies the lower bounds; 33 otherwise, the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.97) 34 applied to the corresponding dimension of data-target . The upper bound of each dimension is one less 35 than the sum of the lower bound and the extent. 36 7.4.2.2 Pro cedure p ointer assignment 37 If the proc-target is not a pointer, proc-pointer-object becomes pointer associated with proc-target . Other- 38 wise, the pointer association status of proc-pointer-object becomes that of proc-target ; if proc-target is 39 associated with a procedure, proc-pointer-object becomes associated with the same procedure. 40 If proc-target is the name of an internal procedure the host instance of proc-pointer-object becomes 41 164 2006/07/11 WORKING DRAFT J3/06-007 the innermost currently executing instance of the host procedure. Otherwise if proc-target has a host 1 instance the host instance of proc-pointer-object becomes that instance. Otherwise proc-pointer-object 2 has no host instance. 3 If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except 4 that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental 5 intrinsic procedure even if proc-pointer-object is not elemental. 6 If the characteristics of proc-pointer-object or proc-target are such that an explicit interface is required, 7 both proc-pointer-object and proc-target shall have an explicit interface. 8 If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc- 9 target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, 10 proc-target shall be a subroutine. 11 If proc-target and proc-pointer-object are functions, they shall have the same type; corresponding type 12 parameters shall either both be deferred or both have the same value. 13 If procedure-name is a specific procedure name that is also a generic name, only the specific procedure 14 is associated with pointer-ob ject. 15 7.4.2.3 Examples 16 NOTE 7.48 The following are examples of pointer assignment statements. (See Note 12.14 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 ob ject by specifying upper bounds in pointer assignment statements. This requires that the ob ject 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 ob ject in MYDATA because its diagonal is needed for some reason ­ the diagonal cannot be gotten as a single ob ject 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 165 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.49 (cont.) VIEW_DIAG => MYDATA( 1::NR+1 ) ! The diagonal of MATRIX Rows, columns, or blocks of the matrix can be accessed as sections of MATRIX. 7.4.3 Masked array assignment ­ WHERE 1 The masked array assignment is used to mask the evaluation of expressions and assignment of values in 2 array assignment statements, according to the value of a logical array expression. 3 7.4.3.1 General form of the masked array assignment 4 A masked array assignment is either a WHERE statement or a WHERE construct. 5 R743 where-stmt is WHERE ( mask-expr ) where-assignment-stmt 6 R744 where-construct is where-construct-stmt 7 [ where-body-construct ] ... 8 [ masked-elsewhere-stmt 9 [ where-body-construct ] ... ] ... 10 [ elsewhere-stmt 11 [ where-body-construct ] ... ] 12 end-where-stmt 13 R745 where-construct-stmt is [where-construct-name :] WHERE ( mask-expr ) 14 R746 where-body-construct is where-assignment-stmt 15 or where-stmt 16 or where-construct 17 R747 where-assignment-stmt is assignment-stmt 18 R748 mask-expr is logical-expr 19 R749 masked-elsewhere-stmt is ELSEWHERE (mask-expr ) [where-construct-name ] 20 R750 elsewhere-stmt is ELSEWHERE [where-construct-name ] 21 R751 end-where-stmt is END WHERE [where-construct-name ] 22 C734 (R747) A where-assignment-stmt that is a defined assignment shall be elemental. 23 C735 (R744) If the where-construct-stmt is identified by a where-construct-name , the corresponding 24 end-where-stmt shall specify the same where-construct-name . If the where-construct-stmt is 25 not identified by a where-construct-name , the corresponding end-where-stmt shall not specify 26 a where-construct-name . If an elsewhere-stmt or a masked-elsewhere-stmt is identified by a 27 where-construct-name , the corresponding where-construct-stmt shall specify the same where- 28 construct-name . 29 C736 (R746) A statement that is part of a where-body-construct shall not be a branch target statement. 30 If a where-construct contains a where-stmt , a masked-elsewhere-stmt , or another where-construct then 31 each mask-expr within the where-construct shall have the same shape. In each where-assignment-stmt , 32 the mask-expr and the variable being defined shall be arrays of the same shape. 33 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 166 2006/07/11 WORKING DRAFT J3/06-007 NOTE 7.50 (cont.) ELSEWHERE RAINING = .TRUE. END WHERE 7.4.3.2 Interpretation of masked array assignments 1 When a WHERE statement or a where-construct-stmt is executed, a control mask is established. In 2 addition, when a WHERE construct statement is executed, a pending control mask is established. If 3 the statement does not appear as part of a where-body-construct , the mask-expr of the statement is 4 evaluated, and the control mask is established to be the value of mask-expr . The pending control mask 5 is established to have the value .NOT. mask-expr upon execution of a WHERE construct statement that 6 does not appear as part of a where-body-construct . The mask-expr is evaluated only once. 7 Each statement in a WHERE construct is executed in sequence. 8 Upon execution of a masked-elsewhere-stmt , the following actions take place in sequence. 9 (1) The control mask mc is established to have the value of the pending control mask. 10 (2) The pending control mask is established to have the value mc .AND. (.NOT. mask-expr ). 11 (3) The control mask mc is established to have the value mc .AND. mask-expr . 12 The mask-expr is evaluated at most once. 13 Upon execution of an ELSEWHERE statement, the control mask is established to have the value of the 14 pending control mask. No new pending control mask value is established. 15 Upon execution of an ENDWHERE statement, the control mask and pending control mask are es- 16 tablished to have the values they had prior to the execution of the corresponding WHERE construct 17 statement. Following the execution of a WHERE statement that appears as a where-body-construct , the 18 control mask is established to have the value it had prior to the execution of the WHERE statement. 19 NOTE 7.51 The establishment of control masks and the pending control mask is illustrated with the following example: WHERE(cond1) ! Statement 1 ... ELSEWHERE(cond2) ! Statement 2 ... ELSEWHERE ! Statement 3 ... END WHERE Following execution of statement 1, the control mask has the value cond1 and the pending control mask has the value .NOT. cond1. Following execution of statement 2, the control mask has the value (.NOT. cond1) .AND. cond2 and the pending control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). Following execution of statement 3, the control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). The false condition values are propagated through the execution of the masked ELSEWHERE statement. Upon execution of a WHERE construct statement that is part of a where-body-construct , the pending 20 control mask is established to have the value mc .AND. (.NOT. mask-expr ). The control mask is then 21 established to have the value mc .AND. mask-expr . The mask-expr is evaluated at most once. 22 167 J3/06-007 WORKING DRAFT 2006/07/11 Upon execution of a WHERE statement that is part of a where-body-construct , the control mask is 1 established to have the value mc .AND. mask-expr . The pending mask is not altered. 2 If a nonelemental function reference occurs in the expr or variable of a where-assignment-stmt or in a 3 mask-expr , the function is evaluated without any masked control; that is, all of its argument expressions 4 are fully evaluated and the function is fully evaluated. If the result is an array and the reference is not 5 within the argument list of a nonelemental function, elements corresponding to true values in the control 6 mask are selected for use in evaluating the expr , variable or mask-expr . 7 If an elemental operation or function reference occurs in the expr or variable of a where-assignment-stmt 8 or in a mask-expr , and is not within the argument list of a nonelemental function reference, the operation 9 is performed or the function is evaluated only for the elements corresponding to true values of the control 10 mask. 11 If an array constructor appears in a where-assignment-stmt or in a mask-expr , the array constructor is 12 evaluated without any masked control and then the where-assignment-stmt is executed or the mask-expr 13 is evaluated. 14 When a where-assignment-stmt is executed, the values of expr that correspond to true values of the 15 control mask are assigned to the corresponding elements of the variable. 16 The value of the control mask is established by the execution of a WHERE statement, a WHERE con- 17 struct statement, an ELSEWHERE statement, a masked ELSEWHERE statement, or an ENDWHERE 18 statement. Subsequent changes to the value of entities in a mask-expr have no effect on the value of the 19 control mask. The execution of a function reference in the mask expression of a WHERE statement is 20 permitted to affect entities in the assignment statement. 21 NOTE 7.52 Examples of function references in masked array assignments are: WHERE (A > 0.0) A = LOG (A) ! LOG is invoked only for positive elements. A = A / SUM (LOG (A)) ! LOG is invoked for all elements ! because SUM is transformational. END WHERE 7.4.4 FORALL 22 FORALL constructs and statements are used to control the execution of assignment and pointer assign- 23 ment statements with selection by sets of index values and an optional mask expression. 24 7.4.4.1 The FORALL Construct 25 The FORALL construct allows multiple assignments, masked array (WHERE) assignments, and nested 26 FORALL constructs and statements to be controlled by a single foral l-triplet-spec -list and scalar-mask- 27 expr . 28 R752 foral l-construct is foral l-construct-stmt 29 [foral l-body-construct ] ... 30 end-foral l-stmt 31 R753 foral l-construct-stmt is [foral l-construct-name :] FORALL foral l-header 32 R754 foral l-header is (foral l-triplet-spec -list [, scalar-mask-expr ] ) 33 R755 foral l-triplet-spec is index-name = subscript : subscript [ : stride ] 34 R619 subscript is scalar-int-expr 35 R622 stride is scalar-int-expr 36 168 2006/07/11 WORKING DRAFT J3/06-007 R756 foral l-body-construct is foral l-assignment-stmt 1 or where-stmt 2 or where-construct 3 or foral l-construct 4 or foral l-stmt 5 R757 foral l-assignment-stmt is assignment-stmt 6 or pointer-assignment-stmt 7 R758 end-foral l-stmt is END FORALL [foral l-construct-name ] 8 C737 (R758) If the foral l-construct-stmt has a foral l-construct-name , the end-foral l-stmt shall have 9 the same foral l-construct-name . If the end-foral l-stmt has a foral l-construct-name , the foral l- 10 construct-stmt shall have the same foral l-construct-name . 11 C738 (R754) The scalar-mask-expr shall be scalar and of type logical. 12 C739 (R754) Any procedure referenced in the scalar-mask-expr , including one referenced by a defined 13 operation, shall be a pure procedure (12.7). 14 C740 (R755) The index-name shall be a named scalar variable of type integer. 15 C741 (R755) A subscript or stride in a foral l-triplet-spec shall not contain a reference to any index- 16 name in the foral l-triplet-spec -list in which it appears. 17 C742 (R756) A statement in a foral l-body-construct shall not define an index-name of the foral l- 18 construct . 19 C743 (R756) Any procedure referenced in a foral l-body-construct , including one referenced by a defined 20 operation, assignment, or finalization, shall be a pure procedure. 21 C744 (R756) A foral l-body-construct shall not be a branch target. 22 C745 (R757) The variable in an assignment-stmt that is a foral l-assignment-stmt shall be a designator . 23 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 foral l-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. 169 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.55 An example of a FORALL construct containing a pointer assignment statement is: TYPE ELEMENT REAL ELEMENT_WT CHARACTER (32), POINTER :: NAME END TYPE ELEMENT TYPE(ELEMENT) CHART(200) REAL WEIGHTS (1000) CHARACTER (32), TARGET :: NAMES (1000) ... FORALL (I = 1:200, WEIGHTS (I + N - 1) > .5) CHART(I) % ELEMENT_WT = WEIGHTS (I + N - 1) CHART(I) % NAME => NAMES (I + N - 1) END FORALL The results of this FORALL construct cannot be achieved with a WHERE construct because a pointer assignment statement is not permitted in a WHERE construct. An index-name in a foral l-construct has a scope of the construct (16.4). It is a scalar variable that has 1 the type and type parameters that it would have if it were the name of a variable in the scoping unit 2 that includes the FORALL, and this type shall be integer type; it has no other attributes. 3 NOTE 7.56 The use of index-name variables in a FORALL construct does not affect variables of the same name, for example: INTEGER :: X = -1 REAL A(5, 4) J = 100 ... FORALL (X = 1:5, J = 1:4) A (X, J) = J END FORALL After execution of the FORALL, the variables X and J have the values -1 and 100 and A has the value 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 7.4.4.2 Execution of the FORALL construct 4 There are three stages in the execution of a FORALL construct: 5 (1) determination of the values for index-name variables, 6 (2) evaluation of the scalar-mask-expr , and 7 (3) execution of the FORALL body constructs. 8 170 2006/07/11 WORKING DRAFT J3/06-007 7.4.4.2.1 Determination of the values for index variables 1 The subscript and stride expressions in the foral l-triplet-spec -list are evaluated. These expressions may 2 be evaluated in any order. The set of values that a particular index-name variable assumes is determined 3 as follows. 4 (1) The lower bound m1 , the upper bound m2 , and the stride m3 are of type integer with the 5 same kind type parameter as the index-name . Their values are established by evaluating 6 the first subscript, the second subscript, and the stride expressions, respectively, including, 7 if necessary, conversion to the kind type parameter of the index-name according to the rules 8 for numeric conversion (Table 7.11). If a stride does not appear, m3 has the value 1. The 9 value m3 shall not be zero. 10 Let the value of max be (m2 - m1 + m3 )/m3 . If max 0 for some index-name , the execution (2) 11 of the construct is complete. Otherwise, the set of values for the index-name is 12 m1 + (k - 1) × m3 where k = 1, 2, ..., max. 13 The set of combinations of index-name values is the Cartesian product of the sets defined by each triplet 14 specification. An index-name becomes defined when this set is evaluated. 15 NOTE 7.57 The stride may be positive or negative; the FORALL body constructs are executed as long as max > 0. For the foral l-triplet-spec I = 10:1:-1 max has the value 10 7.4.4.2.2 Evaluation of the mask expression 16 The scalar-mask-expr , if any, is evaluated for each combination of index-name values. If the scalar- 17 mask-expr is not present, it is as if it were present with the value true. The index-name variables may 18 be primaries in the scalar-mask-expr . 19 The active combination of index-name values is defined to be the subset of all possible combinations 20 (7.4.4.2.1) for which the scalar-mask-expr has the value true. 21 NOTE 7.58 The index-name variables may appear in the mask, for example FORALL (I=1:10, J=1:10, A(I) > 0.0 .AND. B(J) < 1.0) ... 7.4.4.2.3 Execution of the FORALL b o dy constructs 22 The foral l-body-construct s are executed in the order in which they appear. Each construct is executed 23 for all active combinations of the index-name values with the following interpretation: 24 Execution of a foral l-assignment-stmt that is an assignment-stmt causes the evaluation of expr and all 25 expressions within variable for all active combinations of index-name values. These evaluations may be 26 done in any order. After all these evaluations have been performed, each expr value is assigned to the 27 corresponding variable . The assignments may occur in any order. 28 Execution of a foral l-assignment-stmt that is a pointer-assignment-stmt causes the evaluation of all 29 expressions within data-target and data-pointer-object or proc-target and proc-pointer-object , the de- 30 termination of any pointers within data-pointer-object or proc-pointer-object , and the determination of 31 171 J3/06-007 WORKING DRAFT 2006/07/11 the target for all active combinations of index-name values. These evaluations may be done in any 1 order. After all these evaluations have been performed, each data-pointer-object or proc-pointer-object 2 is associated with the corresponding target. These associations may occur in any order. 3 In a foral l-assignment-stmt , a defined assignment subroutine shall not reference any variable that be- 4 comes defined by the statement. 5 NOTE 7.59 The following FORALL construct contains two assignment statements. The assignment to array B uses the values of array A computed in the previous statement, not the values A had prior to execution of the FORALL. FORALL (I = 2:N-1, J = 2:N-1 ) A (I, J) = A(I, J-1) + A(I, J+1) + A(I-1, J) + A(I+1, J) B (I, J) = 1.0 / A(I, J) END FORALL Computations that would otherwise cause error conditions can be avoided by using an appropriate scalar-mask-expr that limits the active combinations of the index-name values. For example: FORALL (I = 1:N, Y(I) /= 0.0) X(I) = 1.0 / Y(I) END FORALL Each statement in a where-construct (7.4.3) within a foral l-construct is executed in sequence. When 6 a where-stmt , where-construct-stmt or masked-elsewhere-stmt is executed, the statement's mask-expr is 7 evaluated for all active combinations of index-name values as determined by the outer foral l-construct s, 8 masked by any control mask corresponding to outer where-construct s. Any where-assignment-stmt is 9 executed for all active combinations of index-name values, masked by the control mask in effect for the 10 where-assignment-stmt . 11 NOTE 7.60 This FORALL construct contains a WHERE statement and an assignment statement. INTEGER A(5,4), B(5,4) FORALL ( I = 1:5 ) WHERE ( A(I,:) == 0 ) A(I,:) = I B (I,:) = I / A(I,:) END FORALL When executed with the input array 0 0 0 0 1 1 1 0 A = 2 2 0 2 1 0 2 3 0 0 0 0 the results will be 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 1 A = 2 2 3 2 B = 1 1 1 1 172 2006/07/11 WORKING DRAFT J3/06-007 NOTE 7.60 (cont.) 1 4 2 3 4 1 2 1 5 5 5 5 1 1 1 1 For an example of a FORALL construct containing a WHERE construct with an ELSEWHERE statement, see C.4.5. Execution of a foral l-stmt or foral l-construct causes the evaluation of the subscript and stride expressions 1 in the foral l-triplet-spec -list for all active combinations of the index-name values of the outer FORALL 2 construct. The set of combinations of index-name values for the inner FORALL is the union of the sets 3 defined by these bounds and strides for each active combination of the outer index-name values; it also 4 includes the outer index-name values. The scalar-mask-expr is then evaluated for all combinations of the 5 index-name values of the inner construct to produce a set of active combinations for the inner construct. 6 If there is no scalar-mask-expr , it is as if it were present with the value .TRUE.. Each statement in the 7 inner FORALL is then executed for each active combination of the index-name values. 8 NOTE 7.61 This FORALL construct contains a nested FORALL construct. It assigns the transpose of the strict lower triangle of array A (the section below the main diagonal) to the strict upper triangle of A. INTEGER A (3, 3) FORALL (I = 1:N-1 ) FORALL ( J=I+1:N ) A(I,J) = A(J,I) END FORALL END FORALL If prior to execution N = 3 and 0 3 6 A = 1 4 7 2 5 8 then after execution 0 1 2 A = 1 4 5 2 5 8 7.4.4.3 The FORALL statement 9 The FORALL statement allows a single assignment statement or pointer assignment to be controlled by 10 a set of index values and an optional mask expression. 11 R759 foral l-stmt is FORALL foral l-header foral l-assignment-stmt 12 A FORALL statement is equivalent to a FORALL construct containing a single foral l-body-construct 13 that is a foral l-assignment-stmt . 14 The scope of an index-name in a foral l-stmt is the statement itself (16.4). 15 173 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 7.62 Examples of FORALL statements are: FORALL (I=1:N) A(I,I) = X(I) This statement assigns the elements of vector X to the elements of the main diagonal of matrix A. FORALL (I = 1:N, J = 1:N) X(I,J) = 1.0 / REAL (I+J-1) Array element X(I,J) is assigned the value (1.0 / REAL (I+J-1)) for values of I and J between 1 and N, inclusive. FORALL (I=1:N, J=1:N, Y(I,J) /= 0 .AND. I /= J) X(I,J) = 1.0 / Y(I,J) This statement takes the reciprocal of each nonzero off-diagonal element of array Y(1:N, 1:N) and assigns it to the corresponding element of array X. Elements of Y that are zero or on the diagonal do not participate, and no assignments are made to the corresponding elements of X. The results from the execution of the example in Note 7.61 could be obtained with a single FORALL statement: FORALL ( I = 1:N-1, J=1:N, J > I ) A(I,J) = A(J,I) For more examples of FORALL statements, see C.4.6. 7.4.4.4 Restrictions on FORALL constructs and statements 1 A many-to-one assignment is more than one assignment to the same ob ject, or association of more 2 than one target with the same pointer, whether the ob ject is referenced directly or indirectly through a 3 pointer. A many-to-one assignment shall not occur within a single statement in a FORALL construct or 4 statement. It is possible to assign or pointer assign to the same ob ject in different assignment statements 5 in a FORALL construct. 6 NOTE 7.63 The appearance of each index-name in the identification of the left-hand side of an assignment statement is helpful in eliminating many-to-one assignments, but it is not sufficient to guarantee there will be none. For example, the following is allowed FORALL (I = 1:10) A (INDEX (I)) = B(I) END FORALL if and only if INDEX(1:10) contains no repeated values. Within the scope of a FORALL construct, a nested FORALL statement or FORALL construct shall 7 not have the same index-name . The foral l-header expressions within a nested FORALL may depend on 8 the values of outer index-name variables. 9 174 2006/07/11 WORKING DRAFT J3/06-007 8 Execution control 1 8.1 Executable constructs containing blo cks 2 8.1.1 General 3 The following are executable constructs that contain blocks: 4 (1) ASSOCIATE construct; 5 (2) BLOCK construct; 6 (3) CASE construct; 7 (4) CRITICAL construct; 8 (5) DO construct; 9 (6) IF construct; 10 (7) SELECT TYPE construct. 11 12 There is also a nonblo ck form of the DO construct. A blo ck is a sequence of executable constructs that is treated as a unit. 13 R801 block is [ execution-part-construct ] ... 14 Executable constructs may be used to control which blocks of a program are executed or how many times 15 a block is executed. Blocks are always bounded by statements that are particular to the construct in 16 which they are embedded; however, in some forms of the DO construct, a sequence of executable constructs without 17 a terminating b oundary statement shall ob ey all other rules governing blo cks (8.1.2). 18 NOTE 8.1 A block need not contain any executable constructs. Execution of such a block has no effect. Any of these constructs may be named. If a construct is named, the name shall be the first lexical token 19 of the first statement of the construct and the last lexical token of the construct. In fixed source form, the 20 21 name preceding the construct shall be placed after character p osition 6. Except for a CYCLE statement, a statement b elongs to the innermost construct in which it appears 22 unless it contains a construct name, in which case it belongs to the named construct. 23 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 175 J3/06-007 WORKING DRAFT 2006/07/11 8.1.2 Rules governing blo cks 1 8.1.2.1 Executable constructs in blo cks 2 If a block contains an executable construct, the executable construct shall be entirely within the block. 3 8.1.2.2 Control flow in blo cks 4 Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a 5 block and transfers from the interior of a block to outside the block may occur. 6 Subroutine and function references (12.5.2, 12.5.3) may appear in a block. 7 8.1.2.3 Execution of a blo ck 8 Execution of a block begins with the execution of the first executable construct in the block. Execution 9 of the block is completed when the last executable construct in the sequence is executed or when a 10 branch out of the block takes place. 11 NOTE 8.3 The action that takes place at the terminal boundary depends on the particular construct and on the block within that construct. It is usually a transfer of control. 8.1.3 IF construct 12 The IF construct selects for execution at most one of its constituent blocks. The selection is based 13 on a sequence of logical expressions. The IF statement controls the execution of a single statement 14 (8.1.3.4) based on a single logical expression. 15 8.1.3.1 Form of the IF construct 16 R802 if-construct is if-then-stmt 17 block 18 [ else-if-stmt 19 block ] ... 20 [ else-stmt 21 block ] 22 end-if-stmt 23 R803 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN 24 R804 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] 25 R805 else-stmt is ELSE [ if-construct-name ] 26 R806 end-if-stmt is END IF [ if-construct-name ] 27 C801 (R802) If the if-then-stmt of an if-construct specifies an if-construct-name , the corresponding 28 end-if-stmt shall specify the same if-construct-name . If the if-then-stmt of an if-construct does 29 not specify an if-construct-name , the corresponding end-if-stmt shall not specify an if-construct- 30 name . If an else-if-stmt or else-stmt specifies an if-construct-name , the corresponding if-then- 31 stmt shall specify the same if-construct-name . 32 8.1.3.2 Execution of an IF construct 33 At most one of the blocks in the IF construct is executed. If there is an ELSE statement in the construct, 34 exactly one of the blocks in the construct is executed. The scalar logical expressions are evaluated in 35 the order of their appearance in the construct until a true value is found or an ELSE statement or END 36 IF statement is encountered. If a true value or an ELSE statement is found, the block immediately 37 176 2006/07/11 WORKING DRAFT J3/06-007 following is executed and this completes the execution of the construct. The scalar logical expressions 1 in any remaining ELSE IF statements of the IF construct are not evaluated. If none of the evaluated 2 expressions is true and there is no ELSE statement, the execution of the construct is completed without 3 the execution of any block within the construct. 4 An ELSE IF statement or an ELSE statement shall not be a branch target statement. It is permissible 5 to branch to an END IF statement only from within its IF construct. Execution of an END IF statement 6 has no effect. 7 8.1.3.3 Examples of IF constructs 8 NOTE 8.4 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 8.1.3.4 IF statement 9 The IF statement controls a single action statement (R214). 10 R807 if-stmt is IF ( scalar-logical-expr ) action-stmt 11 C802 (R807) The action-stmt in the if-stmt shall not be an if-stmt , end-program-stmt , end-function- 12 stmt , or end-subroutine-stmt . 13 Execution of an IF statement causes evaluation of the scalar logical expression. If the value of the 14 expression is true, the action statement is executed. If the value is false, the action statement is not 15 executed and execution continues. 16 The execution of a function reference in the scalar logical expression may affect entities in the action 17 statement. 18 NOTE 8.5 An example of an IF statement is: 177 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.5 (cont.) IF (A > 0.0) A = LOG (A) 8.1.4 CASE construct 1 The CASE construct selects for execution at most one of its constituent blocks. The selection is based 2 on the value of an expression. 3 8.1.4.1 Form of the CASE construct 4 R808 case-construct is select-case-stmt 5 [ case-stmt 6 block ] ... 7 end-select-stmt 8 R809 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) 9 R810 case-stmt is CASE case-selector [case-construct-name ] 10 R811 end-select-stmt is END SELECT [ case-construct-name ] 11 C803 (R808) If the select-case-stmt of a case-construct specifies a case-construct-name , the corre- 12 sponding end-select-stmt shall specify the same case-construct-name . If the select-case-stmt 13 of a case-construct does not specify a case-construct-name , the corresponding end-select-stmt 14 shall not specify a case-construct-name . If a case-stmt specifies a case-construct-name , the 15 corresponding select-case-stmt shall specify the same case-construct-name . 16 R812 case-expr is scalar-int-expr 17 or scalar-char-expr 18 or scalar-logical-expr 19 R813 case-selector is ( case-value-range -list ) 20 or DEFAULT 21 C804 (R808) No more than one of the selectors of one of the CASE statements shall be DEFAULT. 22 R814 case-value-range is case-value 23 or case-value : 24 or : case-value 25 or case-value : case-value 26 R815 case-value is scalar-int-initialization-expr 27 or scalar-char-initialization-expr 28 or scalar-logical-initialization-expr 29 C805 (R808) For a given case-construct , each case-value shall be of the same type as case-expr . For 30 character type, the kind type parameters shall be the same; character length differences are 31 allowed. 32 C806 (R808) A case-value-range using a colon shall not be used if case-expr is of type logical. 33 C807 (R808) For a given case-construct , the case-value-range s shall not overlap; that is, there shall 34 be no possible value of the case-expr that matches more than one case-value-range . 35 8.1.4.2 Execution of a CASE construct 36 The execution of the SELECT CASE statement causes the case expression to be evaluated. The resulting 37 value is called the case index. For a case value range list, a match occurs if the case index matches any 38 of the case value ranges in the list. For a case index with a value of c, a match is determined as follows. 39 178 2006/07/11 WORKING DRAFT J3/06-007 (1) If the case value range contains a single value v without a colon, a match occurs for type 1 logical if the expression c .EQV. v is true, and a match occurs for type integer or character 2 if the expression c == v is true. 3 (2) If the case value range is of the form low : high, a match occurs if the expression low <= c 4 .AND. c <= high is true. 5 (3) If the case value range is of the form low :, a match occurs if the expression low <= c is true. 6 (4) If the case value range is of the form : high, a match occurs if the expression c <= high is 7 true. 8 (5) If no other selector matches and a DEFAULT selector appears, it matches the case index. 9 (6) If no other selector matches and the DEFAULT selector does not appear, there is no match. 10 The block following the CASE statement containing the matching selector, if any, is executed. This 11 completes execution of the construct. 12 At most one of the blocks of a CASE construct is executed. 13 A CASE statement shall not be a branch target statement. It is permissible to branch to an end-select- 14 stmt only from within its CASE construct. 15 8.1.4.3 Examples of CASE constructs 16 NOTE 8.6 An integer signum function: INTEGER FUNCTION SIGNUM (N) SELECT CASE (N) CASE (:-1) SIGNUM = -1 CASE (0) SIGNUM = 0 CASE (1:) SIGNUM = 1 END SELECT END NOTE 8.7 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 179 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.7 (cont.) END SELECT CHECK_PARENS END DO SCAN_LINE IF (LEVEL > 0) THEN PRINT *, 'MISSING RIGHT PARENTHESIS' END IF NOTE 8.8 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.9 A code fragment showing several selections of one block: SELECT CASE (N) CASE (1, 3:5, 8) ! Selects 1, 3, 4, 5, 8 CALL SUB CASE DEFAULT CALL OTHER END SELECT 8.1.5 ASSOCIATE construct 1 The ASSOCIATE construct associates named entities with expressions or variables during the execution 2 of its block. These named construct entities (16.4) are associating entities (16.5.1.6). The names are 3 asso ciate names. 4 8.1.5.1 Form of the ASSOCIATE construct 5 R816 associate-construct is associate-stmt 6 block 7 end-associate-stmt 8 R817 associate-stmt is [ associate-construct-name : ] ASSOCIATE 9 (association -list ) 10 R818 association is associate-name => selector 11 180 2006/07/11 WORKING DRAFT J3/06-007 R819 selector is expr 1 or variable 2 C808 (R818) If selector is not a variable or is a variable that has a vector subscript, associate-name 3 shall not appear in a variable definition context (16.6.7). 4 C809 (R818) An associate-name shall not be the same as another associate-name in the same associate- 5 stmt . 6 R820 end-associate-stmt is END ASSOCIATE [ associate-construct-name ] 7 C810 (R820) If the associate-stmt of an associate-construct specifies an associate-construct-name , 8 the corresponding end-associate-stmt shall specify the same associate-construct-name . If the 9 associate-stmt of an associate-construct does not specify an associate-construct-name , the cor- 10 responding end-associate-stmt shall not specify an associate-construct-name . 11 8.1.5.2 Execution of the ASSOCIATE construct 12 Execution of an ASSOCIATE construct causes execution of its associate-stmt followed by execution 13 of its block. During execution of that block each associate name identifies an entity, which is associ- 14 ated (16.5.1.6) with the corresponding selector. The associating entity assumes the declared type and 15 type parameters of the selector. If and only if the selector is polymorphic, the associating entity is 16 polymorphic. 17 The other attributes of the associating entity are described in 8.1.5.3. 18 It is permissible to branch to an end-associate-stmt only from within its ASSOCIATE construct. 19 8.1.5.3 Attributes of asso ciate names 20 Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the same rank as its 21 associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND 22 (13.7.97) applied to the corresponding dimension of selector . The upper bound of each dimension is one 23 less than the sum of the lower bound and the extent. The associating entity has the ASYNCHRONOUS 24 or VOLATILE attribute if and only if the selector is a variable and has the attribute. The associating 25 entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET 26 or POINTER attribute. If the associating entity is polymorphic, it assumes the dynamic type and type 27 parameter values of the selector. If the selector has the OPTIONAL attribute, it shall be present. The 28 associating entity is contiguous if and only if the selector is contiguous. 29 If the selector (8.1.5.1) is not permitted to appear in a variable definition context (16.6.7) or is an array 30 with a vector subscript, the associate name shall not appear in a variable definition context. 31 8.1.5.4 Examples of the ASSOCIATE construct 32 NOTE 8.10 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)) 181 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.10 (cont.) END ASSOCIATE The following example illustrates association with an array section. ASSOCIATE ( ARRAY => AX%B(I,:)%C ) ARRAY(N)%EV = ARRAY(N-1)%EV END ASSOCIATE The following example illustrates multiple associations. ASSOCIATE ( W => RESULT(I,J)%W, ZX => AX%B(I,J)%D, ZY => AY%B(I,J)%D ) W = ZX*X + ZY*Y END ASSOCIATE 8.1.6 SELECT TYPE construct 1 The SELECT TYPE construct selects for execution at most one of its constituent blocks. The selection 2 is based on the dynamic type of an expression. A name is associated with the expression (16.4, 16.5.1.6), 3 in the same way as for the ASSOCIATE construct. 4 8.1.6.1 Form of the SELECT TYPE construct 5 R821 select-type-construct is select-type-stmt 6 [ type-guard-stmt 7 block ] ... 8 end-select-type-stmt 9 R822 select-type-stmt is [ select-construct-name : ] SELECT TYPE 10 ( [ associate-name => ] selector ) 11 C811 (R822) If selector is not a named variable , associate-name => shall appear. 12 C812 (R822) If selector is not a variable or is a variable that has a vector subscript, associate-name 13 shall not appear in a variable definition context (16.6.7). 14 C813 (R822) The selector in a select-type-stmt shall be polymorphic. 15 R823 type-guard-stmt is TYPE IS ( type-spec ) [ select-construct-name ] 16 or CLASS IS ( derived-type-spec ) [ select-construct-name ] 17 or CLASS DEFAULT [ select-construct-name ] 18 C814 (R823) The type-spec or derived-type-spec shall specify that each length type parameter is as- 19 sumed. 20 C815 (R823) The type-spec or derived-type-spec shall not specify a sequence derived type or a type 21 with the BIND attribute. 22 C816 (R823) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify 23 an extension of the declared type of selector . 24 C817 (R823) For a given select-type-construct , the same type and kind type parameter values shall 25 not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more 26 than one CLASS IS type-guard-stmt . 27 C818 (R823) For a given select-type-construct , there shall be at most one CLASS DEFAULT type- 28 182 2006/07/11 WORKING DRAFT J3/06-007 guard-stmt . 1 R824 end-select-type-stmt is END SELECT [ select-construct-name ] 2 C819 (R821) If the select-type-stmt of a select-type-construct specifies a select-construct-name , the 3 corresponding end-select-type-stmt shall specify the same select-construct-name . If the select- 4 type-stmt of a select-type-construct does not specify a select-construct-name , the corresponding 5 end-select-type-stmt shall not specify a select-construct-name . If a type-guard-stmt specifies a 6 select-construct-name , the corresponding select-type-stmt shall specify the same select-construct- 7 name . 8 The associate name of a SELECT TYPE construct is the associate-name if specified; otherwise it is the 9 name that constitutes the selector . 10 8.1.6.2 Execution of the SELECT TYPE construct 11 Execution of a SELECT TYPE construct whose selector is not a variable causes the selector expression 12 to be evaluated. 13 A SELECT TYPE construct selects at most one block to be executed. During execution of that block, 14 the associate name identifies an entity, which is associated (16.5.1.6) with the selector. 15 A TYPE IS type guard statement matches the selector if the dynamic type and kind type parameter 16 values of the selector are the same as those specified by the statement. A CLASS IS type guard 17 statement matches the selector if the dynamic type of the selector is an extension of the type specified 18 by the statement and the kind type parameter values specified by the statement are the same as the 19 corresponding type parameter values of the dynamic type of the selector. 20 The block to be executed is selected as follows. 21 (1) If a TYPE IS type guard statement matches the selector, the block following that statement 22 is executed. 23 (2) Otherwise, if exactly one CLASS IS type guard statement matches the selector, the block 24 following that statement is executed. 25 (3) Otherwise, if several CLASS IS type guard statements match the selector, one of these 26 statements must specify a type that is an extension of all the types specified in the others; 27 the block following that statement is executed. 28 (4) Otherwise, if there is a CLASS DEFAULT type guard statement, the block following that 29 statement is executed. 30 NOTE 8.11 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. Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not 31 polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter 32 values of the selector. 33 Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and 34 has the declared type named in the type guard statement. The type parameter values of the associating 35 entity are the corresponding type parameter values of the selector. 36 Within the block following a CLASS DEFAULT type guard statement, the associating entity is poly- 37 morphic and has the same declared type as the selector. The type parameter values of the associating 38 entity are those of the declared type of the selector. 39 183 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.12 If the declared type of the selector is T, specifying CLASS DEFAULT has the same effect as specifying CLASS IS (T). The other attributes of the associating entity are described in 8.1.5.3. 1 A type guard statement shall not be a branch target statement. It is permissible to branch to an 2 end-select-type-stmt only from within its SELECT TYPE construct. 3 8.1.6.3 Examples of the SELECT TYPE construct 4 NOTE 8.13 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.14 The following example illustrates the omission of associate-name . It uses the declarations from Note 8.13. 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 184 2006/07/11 WORKING DRAFT J3/06-007 8.1.7 DO construct 1 8.1.7.1 General 2 The DO construct specifies the repeated execution of a sequence of executable constructs. Such a 3 repeated sequence is called a lo op. 4 The number of iterations of a loop may be determined at the beginning of execution of the DO construct, 5 or may be left indefinite ("DO forever" or DO WHILE). Except in the case of a DO CONCURRENT 6 construct, an EXIT statement (8.1.7.5.4) anywhere in the DO construct may be executed to terminate the 7 loop immediately. The current iteration of the loop may be curtailed by executing a CYCLE statement 8 (8.1.7.5.3). 9 There are three phases in the execution of a DO construct: initiation of the loop, execution of the loop 10 range, and termination of the loop. 11 The DO CONCURRENT construct is a DO construct whose DO statement contains the CONCURRENT 12 keyword. 13 8.1.7.2 Forms of the DO construct 14 The DO construct may be written in either a block form or a nonblock form. 15 R825 do-construct is block-do-construct 16 or nonblock-do-construct 17 8.1.7.2.1 Form of the blo ck DO construct 18 R826 block-do-construct is do-stmt 19 do-block 20 end-do 21 R827 do-stmt is label-do-stmt 22 or nonlabel-do-stmt 23 R828 label-do-stmt is [ do-construct-name : ] DO label [ loop-control ] 24 R829 nonlabel-do-stmt is [ do-construct-name : ] DO [ loop-control ] 25 R830 loop-control is [ , ] do-variable = scalar-int-expr , scalar-int-expr 26 [ , scalar-int-expr ] 27 or [ , ] WHILE ( scalar-logical-expr ) 28 or [ , ] CONCURRENT foral l-header 29 R831 do-variable is scalar-int-variable-name 30 C820 (R831) The do-variable shall be a variable of type integer. 31 R832 do-block is block 32 R833 end-do is end-do-stmt 33 or continue-stmt 34 R834 end-do-stmt is END DO [ do-construct-name ] 35 C821 (R826) If the do-stmt of a block-do-construct specifies a do-construct-name , the corresponding 36 end-do shall be an end-do-stmt specifying the same do-construct-name . If the do-stmt of a 37 block-do-construct does not specify a do-construct-name , the corresponding end-do shall not 38 specify a do-construct-name . 39 C822 (R826) If the do-stmt is a nonlabel-do-stmt , the corresponding end-do shall be an end-do-stmt . 40 C823 (R826) If the do-stmt is a label-do-stmt , the corresponding end-do shall be identified with the 41 same label . 42 185 J3/06-007 WORKING DRAFT 2006/07/11 8.1.7.2.2 Form of the nonblo ck DO construct 1 2 R835 nonblock-do-construct is action-term-do-construct 3 or outer-shared-do-construct 4 R836 action-term-do-construct is label-do-stmt 5 do-body 6 do-term-action-stmt 7 R837 do-body is [ execution-part-construct ] ... 8 R838 do-term-action-stmt is action-stmt 9 C824 (R838) A do-term-action-stmt shall not b e a continue-stmt , a goto-stmt , a return-stmt , a stop-stmt , an exit-stmt , 10 a cycle-stmt , an end-function-stmt , an end-subroutine-stmt , an end-program-stmt , or an arithmetic-if-stmt . 11 C825 (R835) The do-term-action-stmt shall be identified with a lab el and the corresp onding label-do-stmt shall refer 12 to the same lab el. 13 R839 outer-shared-do-construct is label-do-stmt 14 do-body 15 shared-term-do-construct 16 R840 shared-term-do-construct is outer-shared-do-construct 17 or inner-shared-do-construct 18 R841 inner-shared-do-construct is label-do-stmt 19 do-body 20 do-term-shared-stmt 21 R842 do-term-shared-stmt is action-stmt 22 C826 (R842) A do-term-shared-stmt shall not be a goto-stmt , a return-stmt , a stop-stmt , an exit-stmt , a cycle-stmt , 23 an end-function-stmt , an end-subroutine-stmt , an end-program-stmt , or an arithmetic-if-stmt . 24 C827 (R840) The do-term-shared-stmt shall be identified with a lab el and all of the label-do-stmt s of the inner-shared- 25 do-construct and outer-shared-do-construct shall refer to the same label. 26 The do-term-action-stmt , do-term-shared-stmt , or shared-term-do-construct following the do-body of a nonblo ck DO con- 27 struct is called the DO termination of that construct. 28 Within a scoping unit, all DO constructs whose DO statements refer to the same label are nonblock DO constructs, and 29 are said to share the statement identified by that lab el. 8.1.7.3 Range of the DO construct 30 The range of a block DO construct is the do-block , which shall satisfy the rules for blocks (8.1.2). In 31 particular, transfer of control to the interior of such a block from outside the block is prohibited. It 32 is permitted to branch to the end-do of a block DO construct only from within the range of that DO 33 construct. 34 35 The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a 36 range is not b ounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the 37 range satisfies the rules for blo cks (8.1.2). Transfer of control into the do-body or to the DO termination from outside the 38 range is prohibited; in particular, it is p ermitted to branch to a do-term-shared-stmt only from within the range of the 39 corresp onding inner-shared-do-construct . 8.1.7.4 Active and inactive DO constructs 40 A DO construct is either active or inactive. Initially inactive, a DO construct becomes active only 41 when its DO statement is executed. 42 Once active, the DO construct becomes inactive only when it terminates (8.1.7.5.4). 43 8.1.7.5 Execution of a DO construct 44 8.1.7.5.1 Lo op initiation 45 When the DO statement is executed, the DO construct becomes active. If loop-control is 46 186 2006/07/11 WORKING DRAFT J3/06-007 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 1 the following steps are performed in sequence. 2 (1) The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter 3 m3 are of type integer with the same kind type parameter as the do-variable . Their values 4 are established by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , re- 5 spectively, including, if necessary, conversion to the kind type parameter of the do-variable 6 according to the rules for numeric conversion (Table 7.11). If scalar-int-expr 3 does not 7 appear, m3 has the value 1. The value of m3 shall not be zero. 8 (2) The DO variable becomes defined with the value of the initial parameter m1 . 9 The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , (3) 10 unless that value is negative, in which case the iteration count is 0. 11 NOTE 8.15 The iteration count is zero whenever: m1 > m2 and m3 > 0, or m1 < m2 and m3 < 0. If loop-control is omitted, no iteration count is calculated. The effect is as if a large positive iteration 12 count, impossible to decrement to zero, were established. If loop-control is [ , ] WHILE (scalar-logical- 13 expr ), the effect is as if loop-control were omitted and the following statement inserted as the first 14 statement of the do-block : 15 IF (.NOT. (scalar- logical-expr )) EXIT 16 For a DO CONCURRENT construct, the values of the index variables for the iterations of the construct 17 are determined by the rules for the index variables of the FORALL construct (7.4.4.2.1 and 7.4.4.2.2). 18 The number of distinct index value combinations in the active combination of index-name values is the 19 iteration count for the construct. 20 An index-name in a DO CONCURRENT construct has a scope of the construct (16.4). It is a scalar 21 variable that has the type and type parameters that it would have if it were the name of a variable in 22 the scoping unit that includes the DO CONCURRENT, and this type shall be integer type; it has no 23 other attributes. 24 At the completion of the execution of the DO statement, the execution cycle begins. 25 8.1.7.5.2 The execution cycle 26 The execution cycle of a DO construct that is not a DO CONCURRENT construct consists of the 27 following steps performed in sequence repeatedly until termination. 28 (1) The iteration count, if any, is tested. If it is zero, the loop terminates and the DO construct 29 becomes inactive. If loop-control is [ , ] WHILE (scalar-logical-expr ), the scalar-logical-expr 30 is evaluated; if the value of this expression is false, the loop terminates and the DO construct 31 becomes inactive. If, as a result, all of the DO constructs sharing the do-term-shared-stmt are inactive, 32 33 the execution of all of these constructs is complete. However, if some of the DO constructs sharing the 34 do-term-shared-stmt are active, execution continues with step (3) of the execution cycle of the active DO 35 construct whose DO statement was most recently executed. (2) If the iteration count is nonzero, the range of the loop is executed. 36 (3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented 37 by the value of the incrementation parameter m3 . 38 187 J3/06-007 WORKING DRAFT 2006/07/11 Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither 1 be redefined nor become undefined while the DO construct is active. 2 The range of a DO CONCURRENT construct is executed for all of the active combinations of the 3 index-name values. Each execution of the range is an iteration. The executions may occur in any 4 order. 5 J3 internal note Unresolved Technical Issue 25 This definition of "iteration" for DO CONCURRENT almost certainly breaks the use of the term elsewhere throughout the standard. Making it not a definition of "iteration" would probably suffice to fix this. 8.1.7.5.3 CYCLE statement 6 Execution of the range of the loop may be curtailed by executing a CYCLE statement from within the 7 range of the loop. 8 R843 cycle-stmt is CYCLE [ do-construct-name ] 9 C828 (R843) If a cycle-stmt refers to a do-construct-name , it shall be within the range of that do- 10 construct ; otherwise, it shall be within the range of at least one do-construct . 11 C829 (R843) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it 12 belongs to an outer construct. 13 A CYCLE statement belongs to a particular DO construct. If the CYCLE statement refers to a DO 14 construct name, it belongs to that DO construct; otherwise, it belongs to the innermost DO construct 15 in which it appears. 16 Execution of a CYCLE statement that belongs to a DO construct that is not a DO CONCURRENT 17 construct causes immediate progression to step (3) of the current execution cycle of the DO construct 18 to which it belongs. If this construct is a nonblock DO construct, the do-term-action-stmt or do-term-shared-stmt is 19 20 not executed. Execution of a CYCLE statement that belongs to a DO CONCURRENT construct completes execution 21 of that iteration of the construct. 22 In a block DO construct, a transfer of control to the end-do has the same effect as execution of a CYCLE 23 statement belonging to that construct. In a nonblock DO construct, transfer of control to the do-term-action-stmt 24 25 or do-term-shared-stmt causes that statement or construct itself to b e executed. Unless a further transfer of control results, 26 step (3) of the current execution cycle of the DO construct is then executed. 8.1.7.5.4 Lo op termination 27 For a DO construct that is not a DO CONCURRENT construct, the loop terminates, and the DO 28 construct becomes inactive, when any of the following occurs. 29 (1) The iteration count is determined to be zero or the scalar-logical-expr is false, when tested 30 during step (1) of the above execution cycle. 31 (2) An EXIT statement belonging to the DO construct is executed. 32 (3) An EXIT or CYCLE statement that belongs to an outer construct and is within the range 33 of the DO construct is executed. 34 (4) Control is transferred from a statement within the range of a DO construct to a statement 35 that is neither the end-do nor within the range of the same DO construct. 36 188 2006/07/11 WORKING DRAFT J3/06-007 (5) A RETURN statement within the range of the DO construct is executed. 1 (6) A STOP statement anywhere in the program is executed, or the program is terminated for 2 any other reason. 3 For a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive when 4 all of the iterations have completed execution. 5 When a DO construct becomes inactive, the DO variable, if any, of the DO construct retains its last 6 defined value. 7 8.1.7.6 Restrictions on DO CONCURRENT constructs 8 The following restrictions apply to DO CONCURRENT constructs. 9 · A statement in the loop range shall not cause a branch out of the construct. 10 · A variable that is referenced in an iteration shall either be previously defined during that iteration, 11 or shall be defined or become undefined during any other iteration of the current execution of 12 the construct. A variable that is defined or becomes undefined by more than one iteration of the 13 current execution of the construct becomes undefined when the current execution of the construct 14 terminates. 15 · A pointer that is referenced in an iteration either shall be previously pointer associated during that 16 iteration, or shall not have its pointer association changed during any iteration. A pointer that has 17 its pointer association changed in more than one iteration has a processor dependent association 18 status when the construct terminates. 19 · An allocatable ob ject that is allocated in more than one iteration shall be subsequently deallocated 20 during the same iteration in which it was allocated. An ob ject that is allocated or deallocated in 21 only one iteration shall not be deallocated, allocated, referenced, defined, or become undefined in 22 a different iteration. 23 · An input/output statement shall not write data to a file record or position in one iteration and 24 read from the same record or position in a different iteration of the same execution of the construct. 25 · Records written by output statements in the loop range to a sequential access file appear in the 26 file in an indeterminate order. 27 · Procedures referenced in the loop range shall be PURE. References to the procedures IEEE GET FLAG, 28 IEEE SET HALTING MODE, and IEEE GET HALTING MODE from the intrinsic module IEEE EXCEPTIONS 29 shall not appear in the loop range. 30 NOTE 8.16 The restrictions on referencing variables defined in an iteration of a DO CONCURRENT construct apply to any procedure invoked within the loop. NOTE 8.17 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. 189 J3/06-007 WORKING DRAFT 2006/07/11 8.1.7.7 Examples of DO constructs 1 NOTE 8.18 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.19 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.20 The following example behaves exactly the same as the one in Note 8.19. However, the READ statement has been moved to the interior of the range, so that only one READ statement is needed. Also, a CYCLE statement has been used to avoid an extra level of IF nesting. DO ! A "DO WHILE + 1/2" loop READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X IF (IOS /= 0) EXIT IF (X < 0.) CYCLE CALL SUBA (X) CALL SUBB (X) ... CALL SUBZ (X) END DO NOTE 8.21 The following example represents a case in which the user knows that the elements of the array IND form a permutation of the integers 1, ..., N. The DO CONCURRENT construct will allow the compiler to generate vector gather/scatter code, unroll the loop, or parallelize the code for this loop, significantly improving performance. INTEGER :: A(N,N),IND(N) 190 2006/07/11 WORKING DRAFT J3/06-007 NOTE 8.21 (cont.) DO CONCURRENT (I=1:N, J=1:N) A(IND(I),IND(J)) = A(IND(I),IND(J)) + 1 END DO NOTE 8.22 Additional examples of DO constructs are in C.5.3. 8.1.8 EXIT statement 1 The EXIT statement provides one way of terminating a construct. 2 R844 exit-stmt is EXIT [ construct-name ] 3 C830 If an exit-stmt refers to a construct-name , it shall be within that construct; otherwise, it shall 4 be within the range of at least one do-construct . 5 An EXIT statement belongs to a particular construct. If the EXIT statement refers to a construct name, 6 it belongs to that construct; otherwise, it belongs to the innermost DO construct in which it appears. 7 C831 An exit-stmt shall not belong to a DO CONCURRENT construct, nor shall it appear within 8 the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO 9 CONCURRENT construct. 10 When an EXIT statement that belongs to a DO construct is executed, it terminates the loop (8.1.7.5.4) 11 and any active loops contained within the terminated loop. When an EXIT statement that belongs to 12 a non-DO construct is executed, it terminates any active loops contained within that construct, and 13 completes execution of that construct. 14 8.1.9 BLOCK construct 15 The BLOCK construct is a block which may contain declarations. 16 R845 block-construct is block-stmt 17 [ specification-part ] 18 block 19 end-block-stmt 20 R846 block-stmt is [ block-construct-name : ] BLOCK 21 R847 end-block-stmt is END BLOCK [ block-construct-name ] 22 C832 (R845) If the block-stmt of a block-construct specifies a block-construct-name , the corresponding 23 end-block-stmt shall specify the same block-construct-name . If the block-stmt does not specify 24 a block-construct-name , the corresponding end-block-stmt shall not specify a block-construct- 25 name . 26 Specifications in a BLOCK construct declare construct entities whose scope is that of the BLOCK 27 construct. 28 Specification expressions in the specification-part of a BLOCK construct are evaluated when the BLOCK 29 statement is executed. 30 The BLOCK construct terminates when a RETURN statement within the block is executed, or when 31 transfer of control to a statement outside the block occurs. 32 191 J3/06-007 WORKING DRAFT 2006/07/11 8.1.10 CRITICAL construct 1 A CRITICAL construct limits execution of a block to one image at a time. 2 R848 critical-construct is critical-stmt 3 block 4 end-critical-stmt 5 R849 critical-stmt is [ critical-construct-name : ] CRITICAL 6 R850 end-critical-stmt is END CRITICAL [ critical-construct-name ] 7 C833 (R848) If the critical-stmt of a critical-construct specifies a critical-construct-name , the corre- 8 sponding end-critical-stmt shall specify the same critical-construct-name . If the critical-stmt of a 9 critical-construct does not specify a critical-construct-name , the corresponding end-critical-stmt 10 shall not specify a critical-construct-name . 11 C834 (R848) The block of a critical-construct shall not contain an image control statement. 12 A CRITICAL construct completes execution if the END CRITICAL statement is executed or if control 13 is transferred to a branch target outside the block. 14 The processor shall ensure that once an image has commenced executing block , no other image shall 15 commence executing it until the image has completed executing it. If image T is the next to execute the 16 construct after image M, the segments (8.5.1) that executed before the construct on image M precede 17 the segments that execute after the construct on image T. No image control statement shall be executed 18 during the execution of a critical construct by the image executing the CRITICAL construct. 19 NOTE 8.23 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.24 The following example permits a large number of jobs to be shared among the images: INTEGER :: NUM_JOBS[*], JOB IF (THIS_IMAGE() == 1) READ(*,*) NUM_JOBS SYNC_ALL DO CRITICAL JOB = NUM_JOBS[1] NUM_JOBS[1] = JOB - 1 END CRITICAL IF (JOB > 0) THEN ! Work on JOB 192 2006/07/11 WORKING DRAFT J3/06-007 NOTE 8.24 (cont.) ELSE EXIT END IF END DO SYNC_ALL 8.2 Branching 1 Branching is used to alter the normal execution sequence. A branch causes a transfer of control from 2 one statement in a scoping unit to a labeled branch target statement in the same scoping unit. Branching 3 may be caused by a GOTO statement, a computed GOTO statement, an arithmetic IF statement, a 4 CALL statement that has an alt-return-spec , or an input/output statement that has an END= or ERR= 5 specifier. Although procedure references and control constructs can cause transfer of control, they are 6 not branches. A branch target statement is an action-stmt , an associate-stmt , an end-associate-stmt , 7 an if-then-stmt , an end-if-stmt , a select-case-stmt , an end-select-stmt , a select-type-stmt , an end-select- 8 type-stmt , a do-stmt , an end-do-stmt , a foral l-construct-stmt , a do-term-action-stmt , a do-term-shared-stmt , or 9 a where-construct-stmt . 10 8.2.1 GO TO statement 11 R851 goto-stmt is GO TO label 12 C835 (R851) The label shall be the statement label of a branch target statement that appears in the 13 same scoping unit as the goto-stmt . 14 Execution of a GO TO statement causes a transfer of control so that the branch target statement 15 identified by the label is executed next. 16 8.2.2 Computed GO TO statement 17 18 R852 computed-goto-stmt is GO TO ( label -list ) [ , ] scalar-int-expr 19 C836 (R852 Each label in label -list shall b e the statement lab el of a branch target statement that app ears in the same 20 scoping unit as the computed-goto-stmt . NOTE 8.25 The same statement lab el may app ear more than once in a lab el list. 21 Execution of a computed GO TO statement causes evaluation of the scalar integer expression. If this value is i such that 1 i n where n is the numb er of lab els in label -list, a transfer of control o ccurs so that the next statement executed is 22 23 the one identified by the ith label in the list of lab els. If i is less than 1 or greater than n, the execution sequence continues 24 as though a CONTINUE statement were executed. 8.2.3 Arithmetic IF statement 25 26 R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label 27 C837 (R853) Each label shall be the lab el of a branch target statement that app ears in the same scoping unit as the 28 arithmetic-if-stmt . 29 C838 (R853) The scalar-numeric-expr shall not b e of typ e complex. 193 J3/06-007 WORKING DRAFT 2006/07/11 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. The 2 branch target statement identified by the first lab el, the second lab el, or the third lab el is executed next dep ending on 3 whether the value of the numeric expression is less than zero, equal to zero, or greater than zero, resp ectively. 8.3 CONTINUE statement 4 Execution of a CONTINUE statement has no effect. 5 R854 continue-stmt is CONTINUE 6 8.4 STOP statement 7 R855 stop-stmt is STOP [ stop-code ] 8 R856 stop-code is scalar-char-initialization-expr 9 or scalar-int-initialization-expr 10 C839 (R856) The scalar-char-initialization-expr shall be of default kind. 11 C840 (R856) The scalar-int-initialization-expr shall be of default kind. 12 Normal termination of execution of the program occurs on all images if a STOP statement or end- 13 program-stmt is executed immediately after a SYNC ALL statement (8.5.2) on all images. The stop 14 code, if any, and warnings of any exceptions that are signaling shall be made available only for image 1. 15 J3 internal note Unresolved Technical Issue 26 What happens with execution of an end-program-stmt is not a proper sub ject for the STOP statement subclause. It is probably duplicative as well. This applies to later paragraphs as well as the above paragraph. J3 internal note Unresolved Technical Issue 27 The first sentence is ambiguous on several levels. Does it mean a particular SYNC ALL statement on all images? ...Or the usual "any SYNC ALL statement" syncs with any other? Does it mean that a STOP or end-program-stmt is executed on all images? ...Or can one image decide unilaterally to normally terminate the program? ...And then, is it ok for some images to execute STOP and other to execute an end-program-stmt ? From the alternative (STOP statement that does not immediately follow a SYNC ALL statement) it seems that unilateralism might be what is intended, except that then not all cases seem to be covered in the "how many images execute a STOP" situation... J3 internal note Unresolved Technical Issue 28 "made available" is not a particularly meaningful phrase. It's use seems to contradict the (non- deleted) later paragraphs of STOP. The processor shall ensure that once an image has commenced executing a STOP or an end-program-stmt 16 statement that does not immediately follow a SYNC ALL statement, no other image shall commence 17 executing such a statement. It causes normal termination (2.3.4) of execution of the program on that 18 image. The stop code, if any, and warnings of any exceptions that are signaling shall be made available 19 194 2006/07/11 WORKING DRAFT J3/06-007 only for that image. The executions of all other images are terminated. 1 J3 internal note Unresolved Technical Issue 29 What does this mean? The other image hangs forever? The other image is terminated imme- diately? How can you tell it doesn't execute a STOP (since presumably it terminates somehow anyway...). Why does this only apply to STOP not preceded by SYNC ALL? Editor's suggested rewrite of the ab ove paragraphs 2 Execution of a STOP statement causes normal termination of that image and termination of the program. 3 If there is only one image, or the STOP statement is executed immediately after a SYNC ALL statement 4 (8.5.2), the program is terminated normally (2.3.4). 5 If several images execute a STOP statement or end-program-stmt , it is processor-dependent which image's 6 stop code or signalling exception warning is made available, except that if a STOP statement is executed 7 immediately after a SYNC ALL statement on image 1, the stop code and signaling exceptions on image 8 1 are reported. 9 End of editor's suggestion 10 At the time of termination, the stop code, if any, is available in a processor-dependent manner. If 11 any exception (14) is signaling, the processor shall issue a warning indicating which exceptions are 12 signaling; this warning shall be on the unit identified by the named constant ERROR UNIT from the 13 ISO FORTRAN ENV intrinsic module (13.8.3.6). 14 J3 internal note Unresolved Technical Issue 30 Why is image 1 special? What if image 2 does all the real work? What if every other image terminates first, before image 1 does? Nearly everything about CAF is very symmetric with regards to images, having weird special abilities on termination of image 1 seems to be unnecessary and to have dubious value. J3 internal note Unresolved Technical Issue 31 If some image registers an "atexit" procedure, normal termination of execution is required to invoke it. Obviously this invocation ought to occur on the registering image, even if it is not image 1, but I'm less convinced that this is well-specified. We say that normal termination of execution includes the effect of executing the C exit function, one question is whether this is on every image or just one image? This is a relatively "soft" UTI, but I think this text needs to be looked at very carefully and thought about. J3 internal note Unresolved Technical Issue 32 Exception warnings appear to be only required in F2003 for STOP, not for end-program-stmt . Assuming that was a deliberate decision, changing this requirement for co-arrays seems outwith the scope of the feature. Not that it might not be a good idea, but it just does not seem to have anything to do with co-arrays as such. Perhaps this should be an F2003 interp? It is recommended that the stop-code is made available by formatted output to the processor-dependent 15 external unit identified by the named constant ERROR UNIT of the ISO FORTRAN ENV intrinsic 16 module (13.8.3.6). 17 195 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.27 If the stop-code is an integer, it is recommended that the value also be used as the process exit status, if the operating system supports that concept. If the integer stop-code is used as the process exit status, the operating system might be able to interpret only values within a limited range, or only a limited portion of the integer value (for example, only the least-significant 8 bits). J3 internal note Unresolved Technical Issue 33 This recommendation for the process exit status does not provide any help for STOP without a code, or for END PROGRAM. Perhaps "STOP" should be equivalent to "STOP 42" whereas "END PROGRAM" should be equivalent to "STOP 5"? Not giving an exit code recommendation for "STOP charstring" is not very good either. 8.5 Image execution control 1 8.5.1 Image control statements 2 The execution sequence on each image is as specified in 2.3.4. 3 An image control statement affects the execution ordering between images. Each of the following is 4 an image control statement: 5 · SYNC ALL statement; 6 · SYNC TEAM statement; 7 · SYNC IMAGES statement; 8 · SYNC MEMORY statement; 9 · NOTIFY statement; 10 · QUERY statement; 11 · ALLOCATE or DEALLOCATE statement involving a co-array; 12 · CRITICAL or END CRITICAL statement (8.1.10); 13 · OPEN statement with a TEAM= specifier; 14 · CLOSE statement for a file that is open with a TEAM= specifier; 15 · END, END BLOCK, or RETURN statement that involves an implicit deallocation of a co-array; 16 · CALL statement for a collective subroutine (13.1). 17 During an execution of a statement that contains more than one reference to a procedure, image control 18 statements other than CRITICAL or END CRITICAL shall be executed in at most one of the procedures 19 invoked. 20 On each image, the sequence of statements executed before the first image control statement, between 21 the execution of two image control statements, or after the last image control statement is known as 22 a segment. The segment executed immediately before the execution of an image control statement 23 includes the evaluation of all expressions within the statement. 24 By execution of image control statements or user-defined ordering (8.5.6), the program can ensure 25 that the execution of the ith segment on image P, Pi , either precedes or succeeds the execution of the 26 196 2006/07/11 WORKING DRAFT J3/06-007 j th segment on another image Q, Qj . If the program does not ensure this, segments Pi and Qj are 1 unordered; depending on the relative execution speeds of the images, some or all of the execution of 2 the segment Pi may take place at the same time as some or all of the execution of the segment Qj . 3 NOTE 8.28 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 or user-defined ordering. A scalar co-variable that is of type default integer, default logical, default real, or default bits, and has 4 the VOLATILE attribute (5.3.18) may be referenced during the execution of a segment that is unordered 5 relative to the execution of a segment in which the co-variable is defined. Otherwise, 6 · if a co-array variable is defined on an image in a segment, it shall not be referenced or defined in 7 a segment on another image unless the segments are ordered, 8 · if the allocation of an allocatable subob ject of a co-array or the association of a pointer subob ject 9 of a co-array is changed on an image in a segment, that subob ject shall not be referenced or defined 10 in a segment on another image unless the segments are ordered, and 11 · if a procedure invocation on image P is in execution in segments Pi , Pi+1 , ..., Pk and defines a 12 non-co-array dummy argument, the argument associated entity shall not be referenced or defined 13 on another image Q in a segment Qj unless Qj precedes Pi or succeeds Pk . 14 J3 internal note Unresolved Technical Issue 34 But ... re the middle item above .. you say the target of a pointer component of a co-array is always on the same image. So how can it be referenced by a remote image? Does this not mean that even non-coarrays have to be stored in remotely-accessible memory if they have the TARGET attribute? BTW, here are what some possibilities for segment notation look like: (1) The ith segment of P is Pi : e.g. in Pi , Pi+1 , ..., Pk and defines a (2) The ith segment of P is SP,i : e.g. in SP,i , SP,i+1 , ..., SP,k and defines a (3) The ith segment of P is Si,P : e.g. in Si,P , Si+1,P , ..., Sk,P and defines a (4) The ith segment of P is S(i,P): e.g. in S(i,P), S(i+1,P), ..., S(k,P) and defines a And here are some possibilities for the Notify/Query notation: (1) Count of NOTIFYs from image T to image M is NT M , Count of successful QUERYs on image M of image T is QM T , e.g. until, ... , NT M > QM T . (2) Count of NOTIFYs from image T to image M is NT ,M , Count of successful QUERYs on image M of image T is QM ,T , e.g. until, ... , NT ,M > QM ,T . (3) Count of NOTIFYs from image T to image M is n(T,M), Count of successful QUERYs on image M of image T is b(M,T), e.g. until, ... , n(T,M) > b(M,T). 197 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.29 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.30 The model upon which the interpretation of a program is based is that there is a permanent memory location for each co-array variable and that all images can access it. In practice, an image may make a copy of a non-volatile co-array variable (in cache or a register, for example) and, as an optimization, defer copying a changed value back to the permanent location while it is still being used. Since the variable is not volatile, it is safe to defer this transfer until the end of the current segment and thereafter to reload from permanent memory any co-array variable that was not defined within the segment. It would not be safe to defer these actions beyond the end of the current segment since another image might reference the variable then. If an image P writes a record during the execution of Pi to a file that is opened for direct access with a 1 TEAM= specifier, no other image Q shall read or write the record during execution of a segment that 2 is unordered with Pi . Furthermore, it shall not read the record in a segment that succeeds Pi unless 3 · after image P writes the record, it executes a FLUSH statement (9.8) for the file during the 4 execution of a segment Pk , where k >= i, and 5 · before image Q reads the record, it executes a FLUSH statement for the file during the execution 6 of a segment Qj that succeeds Pk . 7 NOTE 8.31 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. 8.5.2 SYNC ALL statement 8 R857 sync-al l-stmt is SYNC ALL [ ( [ sync-stat -list ] ) ] 9 R858 sync-stat is STAT = stat-variable 10 or ERRMSG = errmsg-variable 11 C841 No specifier shall appear more than once in a given sync-stat -list. 12 The STAT= and ERRMSG= specifiers for image execution control statements are described in 8.5.7. 13 Execution of a SYNC ALL statement performs a synchronization of all images. Execution on an image, 14 M, of the segment following the SYNC ALL statement is delayed until each other image has executed a 15 SYNC ALL statement as many times as has image M. The segments that executed before the SYNC ALL 16 statement on an image precede the segments that execute after the SYNC ALL statement on another 17 image. 18 NOTE 8.32 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. 198 2006/07/11 WORKING DRAFT J3/06-007 NOTE 8.33 The processor might have special hardware or employ an optimized algorithm to make the SYNC ALL statement execute efficiently. Here is a simple example of its use. Image 1 reads data and broadcasts it to other images: REAL :: P[*] ... SYNC_ALL IF (THIS_IMAGE()==1) THEN READ (*,*) P DO I = 2, NUM_IMAGES() P[I] = P END DO END IF SYNC_ALL 8.5.3 SYNC TEAM statement 1 R859 sync-team-stmt is SYNC TEAM ( image-team [ , sync-stat -list ] ) 2 R860 image-team is scalar-variable 3 C842 The image-team shall be a scalar variable of type IMAGE TEAM from the intrinsic module 4 ISO FORTRAN ENV. 5 Execution of a SYNC TEAM statement performs a team synchronization, which is a synchronization 6 of the images in a team. The team is specified by the value of image-team and shall include the executing 7 image. All images of the team shall execute a SYNC TEAM statement with a value of image-team that 8 was constructed by invoking the intrinsic function FORM TEAM for the team. They do not commence 9 executing subsequent statements until all images in the team have executed a SYNC TEAM statement 10 for the team an equal number of times since FORM TEAM was invoked for the team. If images M 11 and T are any two members of the team, the segments that execute before the statement on image M 12 precede the segments that execute after the statement on image T. 13 Team synchronization is also performed by an OPEN statement with a TEAM= specifier, a CLOSE 14 statement for a file that is open with a TEAM= specifier, or the invocation of a collective subroutine. 15 199 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 35 It is not clear whether "the team" refers to the value gotten back from FORM TEAM, or the input value to FORM TEAM. Yes, I know FORM TEAM is a "collective", but that does not resolve this ambiguity. Images 1-6 do CALL form_team(team1,image_list) CALL form_team(team2,image_list) ! same list as in previous statement then images 1-3 do SYNC_TEAM(team1) whereas images 4-6 do SYNC_TEAM(team2) The question is, is this equivalent to them all doing SYNC_TEAM(team1) ??? If it is, how can SYNC_TEAM(team1) offer any advantage over SYNC_IMAGES(image_list)? SYNC_TEAM seems completely redundant. Anyway, it needs to be made clear what the answer is. NOTE 8.34 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) 200 2006/07/11 WORKING DRAFT J3/06-007 NOTE 8.34 (cont.) IF ( ... ) EXIT ! Ready to swap data END DO END IF SYNC_ALL : ! Swap data END DO In the inner loops, each set of images first works entirely with its own data and each image synchronizes with the rest of its team. The number of synchronizations for the ocean team might differ from the number for the atmosphere team. The SYNC ALL statement that follows is needed to ensure that both teams have done their calculations before data are swapped. 8.5.4 SYNC IMAGES statement 1 R861 sync-images-stmt is SYNC IMAGES ( image-set [ , sync-stat -list ] ) 2 R862 image-set is int-expr 3 or * 4 C843 An image-set that is an int-expr shall be scalar or of rank one and shall not be a co-indexed 5 ob ject. 6 J3 internal note Unresolved Technical Issue 36 The restriction on image-set not being a co-indexed ob ject seems to be a restriction which has no purpose and no effect. I note that it is an expression, not a variable, so the user can just write SYNC_IMAGES((x[i]%imagelist)) instead of SYNC_IMAGES(x[i]%imagelist) This kind of thing is not going to improve the reputation of the Fortran standard and the com- mittees. If image-set is an array expression, the value of each element shall be positive and not greater than the 7 number of images, and there shall be no repeated values. 8 If image-set is a scalar expression, its value shall be positive and not greater than the number of images. 9 An image-set that is an asterisk specifies all images. 10 Execution of a SYNC IMAGES statement performs a synchronization of the image with each of the 11 other images in the image-set . Execution on an image, M, of the segment following the SYNC IMAGES 12 statement is delayed until each other image T in the image-set has executed a SYNC IMAGES statement 13 with M in its image-set as many times as image M has executed a SYNC IMAGES statement with T in 14 the image-set . The segments that executed before the SYNC IMAGES statement on image M precede 15 the segments that execute after the SYNC IMAGES statement on image T. 16 NOTE 8.35 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 201 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.35 (cont.) execution in the limiting case of the number of images being equal to one. NOTE 8.36 Execution of a SYNC IMAGES(*) statement is not equivalent to the execution of a SYNC ALL statement. SYNC ALL causes all images to wait for each other. SYNC IMAGES statements are not required to specify the same image set on all the images participating in the synchronization. In the following example, image 1 will wait for each of the other images to complete its use of the data. The other images wait for image 1 to set up the data, but do not wait on any of the other images. IF (THIS IMAGE() == 1) then ! 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.37 Execution of a SYNC TEAM statement causes all the images of the team to wait for each other. There might, however, be situations where this is not efficient. In the following example, each image synchronizes with its neighbor. INTEGER :: ME, NE, STEP, NSTEPS NE = NUM_IMAGES() ME = THIS_IMAGE() ! Initial calculation SYNC_ALL DO STEP = 1, NSTEPS IF (ME > 1) SYNC_IMAGES(ME-1) ! Perform calculation IF (ME < NE) SYNC_IMAGES(ME+1) END DO SYNC_ALL The calculation starts on image 1 since all the others will be waiting on SYNC IMAGES(ME- 1). When this is done, image 2 can start and image 1 can perform its second calculation. This continues until they are all executing different steps at the same time. Eventually, image 1 will finish and then the others will finish one by one. The SYNC IMAGES syntax involves image-set rather than image-team to allow the set of images to vary from image to image. 8.5.5 NOTIFY and QUERY statements 1 R863 notify-stmt is NOTIFY ( image-set [ , sync-stat -list ] ) 2 R864 query-stmt is QUERY ( image-set [ , query-spec -list ] ) 3 R865 query-spec is READY = scalar-logical-variable 4 202 2006/07/11 WORKING DRAFT J3/06-007 or sync-stat 1 C844 (R864) No specifier shall appear more than once in a given query-spec -list. 2 Execution on image M of a NOTIFY statement with a different image T in its image-set increments by 3 1 a record of the number of times, NM T , image M executed such a NOTIFY statement. 4 A QUERY statement is blo cking if and only if it has no READY= specifier. A QUERY statement 5 is satisfied on completion of its execution if and only if it is a blocking QUERY statement or it set 6 the variable specified by its READY= specifier to true. Execution on image M of a satisfied QUERY 7 statement with a different image T included in its image set increases by 1 a record of the number of 8 times, QM T , image M executed such a QUERY statement. This increase is made after its value has 9 been compared with NT M . 10 If a READY= specifier appears, execution on image M of a QUERY statement causes the scalar-logical- 11 variable to become defined. The value is false if, for a different image T in the image set, NT M <= 12 QM T . Otherwise, the value is true. 13 If a READY= specifier does not appear, increasing QM T and completing execution of the statement 14 is delayed until, for each different T in the image set, NT M > QM T . 15 A NOTIFY statement execution on image T and a satisfied QUERY statement on image M correspond 16 if and only if 17 · the NOTIFY statement's image set includes image M, 18 · the QUERY statement's image set includes image T, and 19 · after execution of both statements has completed, NT M = QM T . 20 Segments on an image executed before the execution of a NOTIFY statement precede the segments on 21 other images that follow its corresponding QUERY statements. 22 NOTE 8.38 The NOTIFY and QUERY statements can be used to order statement executions between a producer and consumer image. INTEGER,PARAMETER :: PRODUCER = 1, CONSUMER = 2 INTEGER :: VALUE[*] LOGICAL :: READY SELECT CASE (THIS_IMAGE()) CASE (PRODUCER) VALUE[CONSUMER] = 3 NOTIFY (CONSUMER) CASE (CONSUMER) WaitLoop: DO QUERY (PRODUCER,READY=READY) IF (READY) EXIT WaitLoop ! Statements neither referencing VALUE[CONSUMER], nor causing it to ! become defined or undefined END DO WaitLoop ! references to VALUE CASE DEFAULT ! Statements neither referencing VALUE[CONSUMER], nor causing it to 203 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.38 (cont.) ! 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.39 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 8.5.6 SYNC MEMORY statement 1 The SYNC MEMORY statement provides a means of dividing a segment on an image into two segments, 2 each of which can be ordered in some user-defined way with respect to segments on other images. 3 R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat -list ] ) ] 4 NOTE 8.40 SYNC MEMORY usually suppresses compiler optimizations that might reorder memory operations across the segment boundary defined by the SYNC MEMORY statement and ensures that all memory operations initiated in the preceding segments in its image complete before any memory operations in the subsequent segment in its image are initiated. It needs to do this unless it can establish that failure to do so could not alter processing on another image. All of the other image control statements include the effect of executing a SYNC MEMORY statement. 5 In addition, the other image control statements cause some form of cooperation with other images for 6 the purpose of ordering execution between images. 7 SYNC MEMORY in combination with user-written code that forces synchronization between images 8 can provide an effective and flexible alternative to the image control statements described in 8.5.2 to 9 8.5.5. 10 J3 internal note Unresolved Technical Issue 37 The above paragraph contributes nothing of substance, being only an advertisement for this subfeature. 204 2006/07/11 WORKING DRAFT J3/06-007 NOTE 8.41 A common example of user-written code that can be used in conjunction with SYNC MEMORY to implement specialized schemes for segment ordering is the spin-wait loop. For example: LOGICAL,VOLATILE :: LOCKED[*] = .TRUE. INTEGER :: IAM, P, Q IAM = THIS_IMAGE() IF (IAM == P) THEN ! Preceding segment SYNC_MEMORY !A ! segment Pi LOCKED[Q] = .FALSE. SYNC_MEMORY !B ELSE IF (IAM == Q) THEN ! segment Qj DO WHILE (LOCKED); END DO SYNC_MEMORY !C ! Subsequent segment END IF Here, image Q does not complete the segment Qj until image P executes segment Pi . This ensures that executions of segments before Pi on image P precede executions of segments on image Q after 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.42 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 MEMORY statement provides the needed memory ordering that enables the safe use of the external synchro- nization routine. For example: INTEGER :: IAM REAL :: X[*] IAM = THIS_IMAGE() IF (IAM == 1) X = 1.0 SYNC_MEMORY CALL EXTERNAL SYNC() SYNC_MEMORY IF (IAM == 2) WRITE(*,*) X[1] 205 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 8.42 (cont.) where executing the subroutine EXTERNAL SYNC has an image synchronization effect similar to executing a SYNC ALL statement. 8.5.7 STAT= and ERRMSG= sp ecifiers in image execution control statements 1 If the STAT= specifier appears, successful execution of the SYNC ALL, SYNC TEAM, SYNC IMAGES, 2 SYNC MEMORY, NOTIFY, or QUERY statement causes the specified variable to become defined with 3 the value zero. If an error occurs during execution of one of these statements, the variable becomes 4 defined with a processor-dependent positive integer value. If an error condition occurs during execution 5 of a SYNC ALL, SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement 6 that does not contain the STAT= specifier, the effect is processor dependent. 7 J3 internal note Unresolved Technical Issue 38 This is substantially different from our existing uses of STAT=; there, any error condition that is not handled by STAT= causes termination of the program. Similarly for IOSTAT=. The CoFortran programmer deserves no less consideration. He should not be required to use STAT= followed by "IF (stat/=0) STOP" to ensure his program doesn't just go off the deep end with a processor-detected error. This doesn't close the door to processor extensions to return "non-fatal" errors as negative values. If the ERRMSG= specifier appears and an error condition occurs during execution of the SYNC ALL, 8 SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement, the processor shall 9 assign an explanatory message to the specified variable. If no such condition occurs, the processor shall 10 not change the value of the variable. 11 NOTE 8.43 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/07/11 WORKING DRAFT J3/06-007 9 Input/output statements 1 Input statements provide the means of transferring data from external media to internal storage or 2 from an internal file to internal storage. This process is called reading. Output statements provide 3 the means of transferring data from internal storage to external media or from internal storage to an 4 internal file. This process is called writing. Some input/output statements specify that editing of the 5 data is to be performed. 6 In addition to the statements that transfer data, there are auxiliary input/output statements to ma- 7 nipulate the external medium, or to describe or inquire about the properties of the connection to the 8 external medium. 9 The input/output statements are the OPEN, CLOSE, READ, WRITE, PRINT, BACKSPACE, END- 10 FILE, REWIND, FLUSH, WAIT, and INQUIRE statements. 11 The READ statement is a data transfer input statement. The WRITE statement and the PRINT 12 statement are data transfer output statements. The OPEN statement and the CLOSE state- 13 ment are file connection statements. The INQUIRE statement is a file inquiry statement. The 14 BACKSPACE, ENDFILE, and REWIND statements are file p ositioning statements. 15 A file is composed of either a sequence of file storage units (9.2.4) or a sequence of records, which 16 provide an extra level of organization to the file. A file composed of records is called a record file. A 17 file composed of file storage units is called a stream file. A processor may allow a file to be viewed 18 both as a record file and as a stream file; in this case the relationship between the file storage units when 19 viewed as a stream file and the records when viewed as a record file is processor dependent. 20 A file is either an external file (9.2) or an internal file (9.3). 21 9.1 Records 22 A record is a sequence of values or a sequence of characters. For example, a line on a terminal is usually 23 considered to be a record. However, a record does not necessarily correspond to a physical entity. There 24 are three kinds of records: 25 (1) formatted; 26 (2) unformatted; 27 (3) endfile. 28 NOTE 9.1 What is called a "record" in Fortran is commonly called a "logical record". There is no concept in Fortran of a "physical record." 9.1.1 Formatted record 29 A formatted record consists of a sequence of characters that are capable of representation in the 30 processor; however, a processor may prohibit some control characters (3.1) from appearing in a formatted 31 record. The length of a formatted record is measured in characters and depends primarily on the number 32 of characters put into the record when it is written. However, it may depend on the processor and the 33 external medium. The length may be zero. Formatted records may be read or written only by formatted 34 input/output statements. 35 207 J3/06-007 WORKING DRAFT 2006/07/11 Formatted records may be prepared by means other than Fortran. 1 9.1.2 Unformatted record 2 An unformatted record consists of a sequence of values in a processor-dependent form and may contain 3 data of any type or may contain no data. The length of an unformatted record is measured in file storage 4 units (9.2.4) and depends on the output list (9.5.2) used when it is written, as well as on the processor 5 and the external medium. The length may be zero. Unformatted records may be read or written only 6 by unformatted input/output statements. 7 9.1.3 Endfile record 8 An endfile record is written explicitly by the ENDFILE statement; the file shall be connected for 9 sequential access. An endfile record is written implicitly to a file connected for sequential access when 10 the most recent data transfer statement referring to the file is a data transfer output statement, no 11 intervening file positioning statement referring to the file has been executed, and 12 (1) a REWIND or BACKSPACE statement references the unit to which the file is connected, 13 or 14 (2) the unit is closed, either explicitly by a CLOSE statement, implicitly by a program termi- 15 nation not caused by an error condition, or implicitly by another OPEN statement for the 16 same unit. 17 An endfile record may occur only as the last record of a file. An endfile record does not have a length 18 property. 19 NOTE 9.2 An endfile record does not necessarily have any physical embodiment. The processor may use a record count or other means to register the position of the file at the time an ENDFILE statement is executed, so that it can take appropriate action when that position is reached again during a read operation. The endfile record, however it is implemented, is considered to exist for the BACKSPACE statement (9.7.1). 9.2 External files 20 An external file is any file that exists in a medium external to the program. 21 At any given time, there is a processor-dependent set of allowed access metho ds, a processor-dependent 22 set of allowed forms, a processor-dependent set of allowed actions, and a processor-dependent set of 23 allowed record lengths for a file. 24 NOTE 9.3 For example, the processor-dependent set of allowed actions for a printer would likely include the write action, but not the read action. A file may have a name; a file that has a name is called a named file. The name of a named file is 25 represented by a character string value. The set of allowable names for a file is processor dependent. 26 NOTE 9.4 Named files that are opened with the TEAM= specifier (9.4.6.7) 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/07/11 WORKING DRAFT J3/06-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 p osition property (9.2.3). 1 NOTE 9.5 For more explanatory information on external files, see C.6.1. 9.2.1 File existence 2 At any given time, there is a processor-dependent set of external files that are said to exist for a program. 3 A file may be known to the processor, yet not exist for a program at a particular time. 4 NOTE 9.6 Security reasons may prevent a file from existing for a program. A newly created file may exist but contain no records. To create a file means to cause a file to exist that did not exist previously. To delete a file means to 5 terminate the existence of the file. 6 All input/output statements may refer to files that exist. An INQUIRE, OPEN, CLOSE, WRITE, 7 PRINT, REWIND, FLUSH, or ENDFILE statement also may refer to a file that does not exist. Execu- 8 tion of a WRITE, PRINT, or ENDFILE statement referring to a preconnected file that does not exist 9 creates the file. 10 9.2.2 File access 11 There are three methods of accessing the data of an external file: sequential, direct, and stream. Some 12 files may have more than one allowed access method; other files may be restricted to one access method. 13 NOTE 9.7 For example, a processor may allow only sequential access to a file on magnetic tape. Thus, the set of allowed access methods depends on the file and the processor. The method of accessing a file is determined when the file is connected to a unit (9.4.3) or when the file 14 is created if the file is preconnected (9.4.4). 15 9.2.2.1 Sequential access 16 Sequential access is a method of accessing the records of an external record file in order. 17 When connected for sequential access, an external file has the following properties. 18 (1) The order of the records is the order in which they were written if the direct access method 19 is not a member of the set of allowed access methods for the file. If the direct access method 20 is also a member of the set of allowed access methods for the file, the order of the records 21 is the same as that specified for direct access. In this case, the first record accessible by 22 sequential access is the record whose record number is 1 for direct access. The second record 23 accessible by sequential access is the record whose record number is 2 for direct access, etc. 24 A record that has not been written since the file was created shall not be read. 25 (2) The records of the file are either all formatted or all unformatted, except that the last record 26 of the file may be an endfile record. Unless the previous reference to the file was a data 27 209 J3/06-007 WORKING DRAFT 2006/07/11 transfer output statement, the last record, if any, of the file shall be an endfile record. 1 (3) The records of the file shall be read or written only by sequential access input/output 2 statements. 3 (4) Each record shall be read or written by a single image. The processor shall ensure that once 4 an image commences transferring the data of a record to the file, no other image transfers 5 data to the file until the whole record has been transferred. 6 9.2.2.2 Direct access 7 Direct access is a method of accessing the records of an external record file in arbitrary order. 8 When connected for direct access, an external file has the following properties. 9 (1) Each record of the file is uniquely identified by a positive integer called the record numb er. 10 The record number of a record is specified when the record is written. Once established, 11 the record number of a record can never be changed. The order of the records is the order 12 of their record numbers. 13 NOTE 9.8 A record cannot be deleted; however, a record may be rewritten. (2) The records of the file are either all formatted or all unformatted. If the sequential access 14 method is also a member of the set of allowed access methods for the file, its endfile record, 15 if any, is not considered to be part of the file while it is connected for direct access. If the 16 sequential access method is not a member of the set of allowed access methods for the file, 17 the file shall not contain an endfile record. 18 (3) The records of the file shall be read or written only by direct access input/output statements. 19 (4) All records of the file have the same length. 20 (5) Records need not be read or written in the order of their record numbers. Any record may 21 be written into the file while it is connected to a unit. For example, it is permissible to write 22 record 3, even though records 1 and 2 have not been written. Any record may be read from 23 the file while it is connected to a unit, provided that the record has been written since the 24 file was created, and if a READ statement for this connection is permitted. 25 (6) The records of the file shall not be read or written using list-directed formatting (10.10), 26 namelist formatting (10.11), or a nonadvancing input/output statement (9.2.3.1). 27 9.2.2.3 Stream access 28 Stream access is a method of accessing the file storage units (9.2.4) of an external stream file. 29 The properties of an external file connected for stream access depend on whether the connection is for 30 unformatted or formatted access. 31 When connected for unformatted stream access, an external file has the following properties. 32 (1) The file storage units of the file shall be read or written only by stream access input/output 33 statements. 34 (2) Each file storage unit in the file is uniquely identified by a positive integer called the position. 35 The first file storage unit in the file is at position 1. The position of each subsequent file 36 storage unit is one greater than that of its preceding file storage unit. 37 (3) If it is possible to position the file, the file storage units need not be read or written in 38 order of their position. For example, it might be permissible to write the file storage unit 39 at position 3, even though the file storage units at positions 1 and 2 have not been written. 40 Any file storage unit may be read from the file while it is connected to a unit, provided that 41 210 2006/07/11 WORKING DRAFT J3/06-007 the file storage unit has been written since the file was created, and if a READ statement 1 for this connection is permitted. 2 When connected for formatted stream access, an external file has the following properties. 3 (1) Some file storage units of the file may contain record markers; this imposes a record structure 4 on the file in addition to its stream structure. There might or might not be a record marker 5 at the end of the file. If there is no record marker at the end of the file, the final record is 6 incomplete. 7 (2) No maximum length (9.4.6.3) is applicable to these records. 8 (3) Writing an empty record with no record marker has no effect. 9 NOTE 9.9 Because the record structure is determined from the record markers that are stored in the file itself, an incomplete record at the end of the file is necessarily not empty. (4) The file storage units of the file shall be read or written only by formatted stream access 10 input/output statements. 11 (5) Each file storage unit in the file is uniquely identified by a positive integer called the position. 12 The first file storage unit in the file is at position 1. The relationship between positions of 13 successive file storage units is processor dependent; not all positive integers need correspond 14 to valid positions. 15 (6) If it is possible to position the file, the file position can be set to a position that was 16 previously identified by the POS= specifier in an INQUIRE statement. 17 NOTE 9.10 There may be some character positions in the file that do not correspond to characters written; this is because on some processors a record marker may be written to the file as a carriage-return/line- feed or other sequence. The means of determining the position in a file connected for stream access is via the POS= specifier in an INQUIRE statement (9.9.1.21). (7) A processor may prohibit some control characters (3.1) from appearing in a formatted stream 18 file. 19 9.2.3 File p osition 20 Execution of certain input/output statements affects the position of an external file. Certain circum- 21 stances can cause the position of a file to become indeterminate. 22 The initial p oint of a file is the position just before the first record or file storage unit. The terminal 23 p oint is the position just after the last record or file storage unit. If there are no records or file storage 24 units in the file, the initial point and the terminal point are the same position. 25 If a record file is positioned within a record, that record is the current record; otherwise, there is no 26 current record. 27 Let n be the number of records in the file. If 1 < i n and a file is positioned within the ith record or 28 between the (i - 1)th record and the ith record, the (i - 1)th record is the preceding record. If n 1 29 and the file is positioned at its terminal point, the preceding record is the nth and last record. If n = 0 30 or if a file is positioned at its initial point or within the first record, there is no preceding record. 31 If 1 i < n and a file is positioned within the ith record or between the ith and (i + 1)th record, the 32 (i + 1)th record is the next record. If n 1 and the file is positioned at its initial point, the first record 33 is the next record. If n = 0 or if a file is positioned at its terminal point or within the nth (last) record, 34 there is no next record. 35 211 J3/06-007 WORKING DRAFT 2006/07/11 For a file connected for stream access, the file position is either between two file storage units, at the 1 initial point of the file, at the terminal point of the file, or undefined. 2 9.2.3.1 Advancing and nonadvancing input/output 3 An advancing input/output statement always positions a record file after the last record read or 4 written, unless there is an error condition. 5 A nonadvancing input/output statement may position a record file at a character position within 6 the current record, or a subsequent record (10.8.2). Using nonadvancing input/output, it is possible to 7 read or write a record of the file by a sequence of input/output statements, each accessing a portion 8 of the record. It is also possible to read variable-length records and be notified of their lengths. If a 9 nonadvancing output statement leaves a file positioned within a current record and no further output 10 statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement 11 is executed for it, the effect is as if the output statement were the corresponding advancing output 12 statement. 13 9.2.3.2 File p osition prior to data transfer 14 The positioning of the file prior to data transfer depends on the method of access: sequential, direct, or 15 stream. 16 For sequential access on input, if there is a current record, the file position is not changed. Otherwise, 17 the file is positioned at the beginning of the next record and this record becomes the current record. 18 Input shall not occur if there is no next record or if there is a current record and the last data transfer 19 statement accessing the file performed output. 20 If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data 21 transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file. 22 For sequential access on output, if there is a current record, the file position is not changed and the 23 current record becomes the last record of the file. Otherwise, a new record is created as the next record 24 of the file; this new record becomes the last and current record of the file and the file is positioned at 25 the beginning of this record. 26 For direct access, the file is positioned at the beginning of the record specified by the REC= specifier. 27 This record becomes the current record. 28 For stream access, the file is positioned immediately before the file storage unit specified by the POS= 29 specifier; if there is no POS= specifier, the file position is not changed. 30 File positioning for child data transfer statements is described in 9.5.3.7. 31 9.2.3.3 File p osition after data transfer 32 If an error condition (9.10) occurred, the position of the file is indeterminate. If no error condition 33 occurred, but an end-of-file condition (9.10) occurred as a result of reading an endfile record, the file is 34 positioned after the endfile record. 35 For unformatted stream access, if no error condition occurred, the file position is not changed. For 36 unformatted stream output, if the file position exceeds the previous terminal point of the file, the 37 terminal point is set to the file position. 38 NOTE 9.11 An unformatted stream output statement with a POS= specifier and an empty output list can have the effect of extending the terminal point of a file without actually writing any data. 212 2006/07/11 WORKING DRAFT J3/06-007 For a formatted stream output statement, if no error condition occurred, the terminal point of the file 1 is set to the highest-numbered position to which data was transferred by the statement. 2 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). For formatted stream input, if an end-of-file condition occurred, the file position is not changed. 3 For nonadvancing input, if no error condition or end-of-file condition occurred, but an end-of-record 4 condition (9.10) occurred, the file is positioned after the record just read. If no error condition, end-of- 5 file condition, or end-of-record condition occurred in a nonadvancing input statement, the file position 6 is not changed. If no error condition occurred in a nonadvancing output statement, the file position is 7 not changed. 8 In all other cases, the file is positioned after the record just read or written and that record becomes the 9 preceding record. 10 9.2.4 File storage units 11 A file storage unit is the basic unit of storage in a stream file or an unformatted record file. It is the 12 unit of file position for stream access, the unit of record length for unformatted files, and the unit of file 13 size for all external files. 14 Every value in a stream file or an unformatted record file shall occupy an integer number of file storage 15 units; if the stream or record file is unformatted, this number shall be the same for all scalar values of 16 the same type and type parameters. The number of file storage units required for an item of a given type 17 and type parameters may be determined using the IOLENGTH= specifier of the INQUIRE statement 18 (9.9.3). 19 For a file connected for unformatted stream access, the processor shall not have alignment restrictions 20 that prevent a value of any type from being stored at any positive integer file position. 21 The number of bits in a file storage unit is given by the constant FILE STORAGE SIZE (13.8.3.7) 22 defined in the intrinsic module ISO FORTRAN ENV. It is recommended that the file storage unit be 23 an 8-bit octet where this choice is practical. 24 NOTE 9.13 The requirement that every data value occupy an integer number of file storage units implies that data items inherently smaller than a file storage unit will require padding. This suggests that the file storage unit be small to avoid wasted space. Ideally, the file storage unit would be chosen such that padding is never required. A file storage unit of one bit would always meet this goal, but would likely be impractical because of the alignment requirements. The prohibition on alignment restrictions prohibits the processor from requiring data alignments larger than the file storage unit. The 8-bit octet is recommended as a good compromise that is small enough to accommodate the requirements of many applications, yet not so small that the data alignment requirements are likely to cause significant performance problems. 213 J3/06-007 WORKING DRAFT 2006/07/11 9.3 Internal files 1 Internal files provide a means of transferring and converting data from internal storage to internal 2 storage. 3 An 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. 6 (2) A record of an internal file is a scalar character variable. 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.2) or the array section (6.2.2.3). 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. 17 (5) A record may be read only if the record is defined. 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, 22 except for child data transfer statements (9.5.3.7). This record becomes the current record. 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 26 input/output statements. 27 (10) An internal file shall not be specified as the unit in a file connection statement or a file 28 positioning statement. 29 9.4 File connection 30 A unit, specified by an io-unit , provides a means for referring to a file. 31 R901 io-unit is file-unit-number 32 or * 33 or internal-file-variable 34 R902 file-unit-number is scalar-int-expr 35 R903 internal-file-variable is char-variable 36 C901 (R903) The char-variable shall not be an array section with a vector subscript. 37 C902 (R903) The char-variable shall be of type default character, ASCII character, or ISO 10646 38 character. 39 A unit is either an external unit or an internal unit. An external unit is used to refer to an external 40 file and is specified by an asterisk or a file-unit-number . The value of file-unit-number shall be non- 41 negative, equal to one of the named constants INPUT UNIT, OUTPUT UNIT, or ERROR UNIT of 42 the ISO FORTRAN ENV module (13.8.3), or a NEWUNIT value (9.4.6). An internal unit is used to 43 refer to an internal file and is specified by an internal-file-variable or a file-unit-number whose value is 44 214 2006/07/11 WORKING DRAFT J3/06-007 equal to the unit argument of an active derived-type input/output procedure (9.5.3.7). The value of a 1 file-unit-number shall identify a valid unit. 2 The external unit identified by a particular value of a scalar-int-expr is the same external unit in all 3 program units of the program, and on all images. 4 NOTE 9.14 In the example: SUBROUTINE A READ (6) X ... SUBROUTINE B N=6 REWIND N the value 6 used in both program units identifies the same external unit. An asterisk identifies particular processor-dependent external units that are preconnected for format- 5 ted sequential access (9.5.3.2). These units are also identified by unit numbers defined by the named 6 constants INPUT UNIT and OUTPUT UNIT of the ISO FORTRAN ENV module (13.8.3). 7 This standard identifies a processor-dependent external unit for the purpose of error reporting. This 8 unit shall be preconnected for sequential formatted output. The processor may define this to be the 9 same as the output unit identified by an asterisk. This unit is also identified by a unit number defined 10 by the named constant ERROR UNIT of the ISO FORTRAN ENV intrinsic module. 11 9.4.1 Connection mo des 12 A connection for formatted input/output has several changeable modes: the blank interpretation mode 13 (10.8.6), delimiter mode (10.10.2, 10.11.2.1), sign mode (10.8.4), decimal edit mode (10.8.8), I/O round- 14 ing mode (10.7.2.3.7), pad mode (9.5.3.4.2), and scale factor (10.8.5). A connection for unformatted 15 input/output has no changeable modes. 16 Values for the modes of a connection are established when the connection is initiated. If the connection 17 is initiated by an OPEN statement, the values are as specified, either explicitly or implicitly, by the 18 OPEN statement. If the connection is initiated other than by an OPEN statement (that is, if the file is 19 an internal file or preconnected file) the values established are those that would be implied by an initial 20 OPEN statement without the corresponding keywords. 21 The scale factor cannot be explicitly specified in an OPEN statement; it is implicitly 0. 22 The modes of a connection to an external file may be changed by a subsequent OPEN statement that 23 modifies the connection. 24 The modes of a connection may be temporarily changed by a corresponding keyword specifier in a 25 data transfer statement or by an edit descriptor. Keyword specifiers take effect at the beginning of 26 execution of the data transfer statement. Edit descriptors take effect when they are encountered in 27 format processing. When a data transfer statement terminates, the values for the modes are reset to the 28 values in effect immediately before the data transfer statement was executed. 29 9.4.2 Unit existence 30 At any given time, there is a processor-dependent set of external units that are said to exist for a 31 program. 32 215 J3/06-007 WORKING DRAFT 2006/07/11 All input/output statements may refer to units that exist. The CLOSE, INQUIRE, and WAIT state- 1 ments also may refer to units that do not exist. 2 9.4.3 Connection of a file to a unit 3 An external unit has a property of being connected or not connected. If connected, it refers to an 4 external file, and the connection is for a team of images. An external unit may become connected by 5 preconnection or by the execution of an OPEN statement. The property of connection is symmetric; the 6 unit is connected to a file if and only if the file is connected to the unit. 7 J3 internal note Unresolved Technical Issue 39 The second sentence now contradicts the first sentence. Sorry guys, but the unit ***is global*** and only has one state, that of being connected or not. This subclause is about connection, not about whether it is formatted or unformatted, or whether there is some restriction about what image is permitted to reference it. Not doing the edit to the second sentence would be sufficient to resolve this issue here, but later edits (under the TEAM= description) also need changing. Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement shall refer to 8 a unit that is connected to a file and thereby make use of or affect that file. 9 A file may be connected and not exist (9.2.1). 10 NOTE 9.15 An example is a preconnected external file that has not yet been written. A unit shall not be connected to more than one file at the same time, and a file shall not be connected to 11 more than one unit at the same time. However, means are provided to change the status of an external 12 unit and to connect a unit to a different file. 13 This standard defines means of portable interoperation with C. C streams are described in 7.19.2 of the C 14 International Standard. Whether a unit may be connected to a file that is also connected to a C stream 15 is processor dependent. If the processor allows a unit to be connected to a file that is also connected to 16 a C stream, the results of performing input/output operations on such a file are processor dependent. 17 It is processor dependent whether the files connected to the units INPUT UNIT, OUTPUT UNIT, 18 and ERROR UNIT correspond to the predefined C text streams standard input, standard output, and 19 standard error. If a procedure defined by means of Fortran and a procedure defined by means other than 20 Fortran perform input/output operations on the same external file, the results are processor dependent. 21 A procedure defined by means of Fortran and a procedure defined by means other than Fortran can 22 perform input/output operations on different external files without interference. 23 After an external unit has been disconnected by the execution of a CLOSE statement, it may be con- 24 nected again within the same program to the same file or to a different file. After an external file has 25 been disconnected by the execution of a CLOSE statement, it may be connected again within the same 26 program to the same unit or to a different unit. 27 NOTE 9.16 The only means of referencing a file that has been disconnected is by the appearance of its name in an OPEN or INQUIRE statement. There might be no means of reconnecting an unnamed file once it is disconnected. An internal unit is always connected to the internal file designated by the variable that identifies the 28 216 2006/07/11 WORKING DRAFT J3/06-007 unit. 1 NOTE 9.17 For more explanatory information on file connection properties, see C.6.5. 9.4.4 Preconnection 2 Preconnection means that the unit is connected to a file at the beginning of execution of the program 3 and therefore it may be specified in input/output statements without the prior execution of an OPEN 4 statement. 5 9.4.5 OPEN statement 6 An OPEN statement initiates or modifies the connection between an external file and a specified unit. 7 The OPEN statement may be used to connect an existing file to a unit, create a file that is preconnected, 8 create a file and connect it to a unit, or change certain modes of a connection between a file and a unit. 9 An external unit may be connected by an OPEN statement in any program unit of a program and, once 10 connected, a reference to it may appear in any program unit of the program. 11 If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. 12 If the FILE= specifier is not included in such an OPEN statement, the file to be connected to the unit 13 is the same as the file to which the unit is already connected. 14 If the file to be connected to the unit does not exist but is the same as the file to which the unit is 15 preconnected, the modes specified by an OPEN statement become a part of the connection. 16 If the file to be connected to the unit is not the same as the file to which the unit is connected, the effect 17 is as if a CLOSE statement without a STATUS= specifier had been executed for the unit immediately 18 prior to the execution of an OPEN statement. 19 If the file to be connected to the unit is the same as the file to which the unit is connected, only the 20 specifiers for changeable modes (9.4.1) may have values different from those currently in effect. If the 21 POSITION= specifier appears in such an OPEN statement, the value specified shall not disagree with 22 the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it shall 23 be specified with the value OLD. Execution of such an OPEN statement causes any new values of the 24 specifiers for changeable modes to be in effect, but does not cause any change in any of the unspecified 25 specifiers and the position of the file is unaffected. The ERR=, IOSTAT=, and IOMSG= specifiers from 26 any previously executed OPEN statement have no effect on any currently executed OPEN statement. 27 A STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is 28 the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH 29 before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the 30 file is still considered to have a status of SCRATCH. 31 If a file is already connected to a unit, execution of an OPEN statement on that file and a different unit 32 is not permitted. 33 R904 open-stmt is OPEN ( connect-spec -list ) 34 R905 connect-spec is [ UNIT = ] file-unit-number 35 or ACCESS = scalar-default-char-expr 36 or ACTION = scalar-default-char-expr 37 or ASYNCHRONOUS = scalar-default-char-expr 38 or BLANK = scalar-default-char-expr 39 or DECIMAL = scalar-default-char-expr 40 217 J3/06-007 WORKING DRAFT 2006/07/11 or DELIM = scalar-default-char-expr 1 or ENCODING = scalar-default-char-expr 2 or ERR = label 3 or FILE = file-name-expr 4 or FORM = scalar-default-char-expr 5 or IOMSG = iomsg-variable 6 or IOSTAT = scalar-int-variable 7 or NEWUNIT = scalar-int-variable 8 or PAD = scalar-default-char-expr 9 or POSITION = scalar-default-char-expr 10 or RECL = scalar-int-expr 11 or ROUND = scalar-default-char-expr 12 or SIGN = scalar-default-char-expr 13 or STATUS = scalar-default-char-expr 14 or TEAM = image-team 15 R906 file-name-expr is scalar-default-char-expr 16 R907 iomsg-variable is scalar-default-char-variable 17 C903 No specifier shall appear more than once in a given connect-spec -list. 18 C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be specified; if 19 the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the 20 connect-spec -list. 21 C905 (R904) The label used in the ERR= specifier shall be the statement label of a branch target 22 statement that appears in the same scoping unit as the OPEN statement. 23 C906 (R904) If a NEWUNIT= specifier appears, a file-unit-number shall not appear. 24 If the STATUS= specifier has the value NEW or REPLACE, the FILE= specifier shall appear. If the 25 STATUS= specifier has the value SCRATCH, the FILE= specifier shall not appear. If the STATUS= 26 specifier has the value OLD, the FILE= specifier shall appear unless the unit is connected and the file 27 connected to the unit exists. 28 If the NEWUNIT= specifier appears in an OPEN statement, either the FILE= specifier shall appear, 29 or the STATUS= specifier shall appear with a value of SCRATCH. The unit identified by a NEWUNIT 30 value shall not be preconnected. 31 A specifier that requires a scalar-default-char-expr may have a limited list of character values. These 32 values are listed for each such specifier. Any trailing blanks are ignored. The value specified is without 33 regard to case. Some specifiers have a default value if the specifier is omitted. 34 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 35 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. 218 2006/07/11 WORKING DRAFT J3/06-007 9.4.5.1 ACCESS= sp ecifier in the OPEN statement 1 The scalar-default-char-expr shall evaluate to SEQUENTIAL, DIRECT, or STREAM. The ACCESS= 2 specifier specifies the access method for the connection of the file as being sequential, direct, or stream. 3 If this specifier is omitted, the default value is SEQUENTIAL. For an existing file, the specified access 4 method shall be included in the set of allowed access methods for the file. For a new file, the processor 5 creates the file with a set of allowed access methods that includes the specified method. 6 9.4.5.2 ACTION= sp ecifier in the OPEN statement 7 The scalar-default-char-expr shall evaluate to READ, WRITE, or READWRITE. READ specifies that 8 the WRITE, PRINT, and ENDFILE statements shall not refer to this connection. WRITE specifies 9 that READ statements shall not refer to this connection. READWRITE permits any input/output 10 statements to refer to this connection. If this specifier is omitted, the default value is processor dependent. 11 If READWRITE is included in the set of allowable actions for a file, both READ and WRITE also shall 12 be included in the set of allowed actions for that file. For an existing file, the specified action shall be 13 included in the set of allowed actions for the file. For a new file, the processor creates the file with a set 14 of allowed actions that includes the specified action. 15 9.4.5.3 ASYNCHRONOUS= sp ecifier in the OPEN statement 16 The scalar-default-char-expr shall evaluate to YES or NO. If YES is specified, asynchronous input/output 17 on the unit is allowed. If NO is specified, asynchronous input/output on the unit is not allowed. If this 18 specifier is omitted, the default value is NO. 19 9.4.5.4 BLANK= sp ecifier in the OPEN statement 20 The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier is permitted only 21 for a connection for formatted input/output. It specifies the current value of the blank interpretation 22 mode (10.8.6, 9.5.1.5) for input for this connection. This mode has no effect on output. It is a changeable 23 mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the default 24 value is NULL. 25 9.4.5.5 DECIMAL= sp ecifier in the OPEN statement 26 The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier is per- 27 mitted only for a connection for formatted input/output. It specifies the current value of the decimal 28 edit mode (10.8.8, 9.5.1.6) for this connection. This is a changeable mode (9.4.1). If this specifier is 29 omitted in an OPEN statement that initiates a connection, the default value is POINT. 30 9.4.5.6 DELIM= sp ecifier in the OPEN statement 31 The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 32 ifier is permitted only for a connection for formatted input/output. It specifies the current value of the 33 delimiter mode (9.5.1.7) for list-directed (10.10.2) and namelist (10.11.2.1) output for the connection. 34 This mode has no effect on input. It is a changeable mode (9.4.1). If this specifier is omitted in an 35 OPEN statement that initiates a connection, the default value is NONE. 36 9.4.5.7 ENCODING= sp ecifier in the OPEN statement 37 The scalar-default-char-expr shall evaluate to UTF-8 or DEFAULT. The ENCODING= specifier is 38 permitted only for a connection for formatted input/output. The value UTF-8 specifies that the encoding 39 form of the file is UTF-8 as specified by ISO/IEC 10646-1:2000. Such a file is called a Unico de file, 40 and all characters therein are of ISO 10646 character type. The value UTF-8 shall not be specified if 41 the processor does not support the ISO 10646 character type. The value DEFAULT specifies that the 42 219 J3/06-007 WORKING DRAFT 2006/07/11 encoding form of the file is processor-dependent. If this specifier is omitted in an OPEN statement that 1 initiates a connection, the default value is DEFAULT. 2 9.4.5.8 FILE= sp ecifier in the OPEN statement 3 The value of the FILE= specifier is the name of the file to be connected to the specified unit. Any trailing 4 blanks are ignored. The file-name-expr shall be a name that is allowed by the processor. If this specifier 5 is omitted and the unit is not connected to a file, the STATUS= specifier shall be specified with a value 6 of SCRATCH; in this case, the connection is made to a processor-dependent file. The interpretation of 7 case is processor dependent. 8 9.4.5.9 FORM= sp ecifier in the OPEN statement 9 The scalar-default-char-expr shall evaluate to FORMATTED or UNFORMATTED. The FORM= spec- 10 ifier determines whether the file is being connected for formatted or unformatted input/output. If this 11 specifier is omitted, the default value is UNFORMATTED if the file is being connected for direct access 12 or stream access, and the default value is FORMATTED if the file is being connected for sequential 13 access. For an existing file, the specified form shall be included in the set of allowed forms for the file. 14 For a new file, the processor creates the file with a set of allowed forms that includes the specified form. 15 9.4.6 NEWUNIT= sp ecifier in the OPEN statement 16 The variable is defined with a processor determined NEWUNIT value if no error occurs during the 17 execution of the OPEN statement. If an error occurs, the processor shall not change the value of the 18 variable. 19 A NEWUNIT value is a negative number, and shall not be equal to -1, any of the named constants 20 ERROR UNIT, INPUT UNIT, or OUTPUT UNIT from the ISO FORTRAN ENV intrinsic module 21 (13.8.3), any value used by the processor for the unit argument to a user-defined derived-type in- 22 put/output procedure, nor any previous NEWUNIT value that identifies a file that is currently con- 23 nected. 24 9.4.6.1 PAD= sp ecifier in the OPEN statement 25 The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier is permitted only for a 26 connection for formatted input/output. It specifies the current value of the pad mode (9.5.3.4.2, 9.5.1.9) 27 for input for this connection. This mode has no effect on output. It is a changeable mode (9.4.1). If this 28 specifier is omitted in an OPEN statement that initiates a connection, the default value is YES. 29 NOTE 9.20 For nondefault character types, the blank padding character is processor dependent. 9.4.6.2 POSITION= sp ecifier in the OPEN statement 30 The scalar-default-char-expr shall evaluate to ASIS, REWIND, or APPEND. The connection shall be 31 for sequential or stream access. A new file is positioned at its initial point. REWIND positions an 32 existing file at its initial point. APPEND positions an existing file such that the endfile record is the 33 next record, if it has one. If an existing file does not have an endfile record, APPEND positions the 34 file at its terminal point. ASIS leaves the position unchanged if the file exists and already is connected. 35 ASIS leaves the position unspecified if the file exists but is not connected. If this specifier is omitted, 36 the default value is ASIS. 37 220 2006/07/11 WORKING DRAFT J3/06-007 9.4.6.3 RECL= sp ecifier in the OPEN statement 1 The value of the RECL= specifier shall be positive. It specifies the length of each record in a file being 2 connected for direct access, or specifies the maximum length of a record in a file being connected for 3 sequential access. This specifier shall not appear when a file is being connected for stream access. This 4 specifier shall appear when a file is being connected for direct access. If this specifier is omitted when 5 a file is being connected for sequential access, the default value is processor dependent. If the file is 6 being connected for formatted input/output, the length is the number of characters for all records that 7 contain only characters of type default character. When a record contains any nondefault characters, 8 the appropriate value for the RECL= specifier is processor dependent. If the file is being connected for 9 unformatted input/output, the length is measured in file storage units. For an existing file, the value of 10 the RECL= specifier shall be included in the set of allowed record lengths for the file. For a new file, 11 the processor creates the file with a set of allowed record lengths that includes the specified value. 12 9.4.6.4 ROUND= sp ecifier in the OPEN statement 13 The scalar-default-char-expr shall evaluate to one of UP, DOWN, ZERO, NEAREST, COMPATIBLE, 14 or PROCESSOR DEFINED. The ROUND= specifier is permitted only for a connection for formatted 15 input/output. It specifies the current value of the I/O rounding mode (10.7.2.3.7, 9.5.1.12) for this 16 connection. This is a changeable mode (9.4.1). If this specifier is omitted in an OPEN statement that 17 initiates a connection, the I/O rounding mode is processor dependent; it shall be one of the above modes. 18 NOTE 9.21 A processor is free to select any I/O rounding mode for the default mode. The mode might correspond to UP, DOWN, ZERO, NEAREST, or COMPATIBLE; or it might be a completely different I/O rounding mode. 9.4.6.5 SIGN= sp ecifier in the OPEN statement 19 The scalar-default-char-expr shall evaluate to one of PLUS, SUPPRESS, or PROCESSOR DEFINED. 20 The SIGN= specifier is permitted only for a connection for formatted input/output. It specifies the 21 current value of the sign mode (10.8.4, 9.5.1.13) for this connection. This is a changeable mode (9.4.1). 22 If this specifier is omitted in an OPEN statement that initiates a connection, the default value is PRO- 23 CESSOR DEFINED. 24 9.4.6.6 STATUS= sp ecifier in the OPEN statement 25 The scalar-default-char-expr shall evaluate to OLD, NEW, SCRATCH, REPLACE, or UNKNOWN. If 26 OLD is specified, the file shall exist. If NEW is specified, the file shall not exist. 27 Successful execution of an OPEN statement with NEW specified creates the file and changes the status 28 to OLD. If REPLACE is specified and the file does not already exist, the file is created and the status is 29 changed to OLD. If REPLACE is specified and the file does exist, the file is deleted, a new file is created 30 with the same name, and the status is changed to OLD. If SCRATCH is specified, the file is created 31 and connected to the specified unit for use by the program but is deleted at the execution of a CLOSE 32 statement referring to the same unit or at the normal termination of the program. 33 NOTE 9.22 SCRATCH shall not be specified with a named file. If UNKNOWN is specified, the status is processor dependent. If this specifier is omitted, the default 34 value is UNKNOWN. 35 221 J3/06-007 WORKING DRAFT 2006/07/11 9.4.6.7 TEAM= sp ecifier in the OPEN statement 1 The image-team specifies the connect team for the unit, which is the set of images that are permitted 2 to reference the unit. The team shall include the executing image. If there is no TEAM= specifier, the 3 connect team consists of only the executing image." 4 J3 internal note Unresolved Technical Issue 40 There is no INQUIRE(TEAM=) which is rather a glaring omission, since that particular charac- teristic of a unit is even more important than things like the BLANK= mode, since it determines whether an image is permitted to use the unit. After that is fixed, one might consider allowing INQUIRE to reference a unit even from an image that is not part of the team, at least to find out whether it is connected and what the team is... It was suggested (with edits) that OPENED= should return true only for images in the connect- team. That is completely unacceptable. We cannot seriously think about breaking existing carefully-written libraries and programs that use INQUIRE to discover unused units to use for i/o. That mandates us to have OPENED= return true for any unit that is open, no matter what the TEAM= status. All images in the connect team, and no others, shall invoke the same OPEN statement with identical 5 values for the connect-spec s. There is an implicit team synchronization. 6 The OPEN statement connects the file on the invoking images only. If the OPEN statement does not 7 have a FILE= specifier and the unit is not connected to a file, the processor shall connect the same file 8 to the unit on all images in the connect team. 9 J3 internal note Unresolved Technical Issue 41 A few problems: (1) The bit about connection and "invoking images" appears to be completely unneces- sary, since we already say elsewhere what the effect of TEAM= is (and the effect of leaving TEAM= off ). (2) This shares the same problem as the earlier edit where the concept of connection state is contradictory. (3) The bit about "shall connect the same file" appears to be completely unnecessary given the bit about the same name identifying the same file in the TEAM= case, plus the TEAM= requirement that all the connect-spec s be the same on all the team. If the connect team contains more than one image, the OPEN statement shall 10 · specify direct access or 11 · specify sequential access and have an ACTION= specifier that evaluates to WRITE. 12 NOTE 9.23 Writing to a sequential file from more than one image without using synchronization is permitted, but is only useful for situations in which the ordering of records is unimportant. An example is for diagnostic output that is labeled with the image index. Preconnected units and the units identified by the values INPUT UNIT, OUTPUT UNIT, and ER- 13 ROR UNIT in the intrinsic module ISO FORTRAN ENV have a connect team consisting of all the 14 222 2006/07/11 WORKING DRAFT J3/06-007 images. If an image with index greater than one executes an input/output statement on one of these 1 units, it shall be a WRITE or PRINT statement. 2 J3 internal note Unresolved Technical Issue 42 Prohibiting INQUIRE seems ... excessive and unwarranted to say the least. Subgroup agree, but there is still a question-mark over other i/o statements. (BACKSPACE, ENDFILE, WAIT, FLUSH, CLOSE, OPEN, REWIND). J3 internal note Unresolved Technical Issue 43 Since READ is prohibited except on image one, in what way does INPUT UNIT have a connect team (since no-one can do anything)? Surely it would be simpler if its connect term were image 1 only? As implied by the following note... NOTE 9.24 The input unit identified by * is therefore only available on the image with index one. 9.4.7 CLOSE statement 3 The CLOSE statement is used to terminate the connection of a specified unit to an external file. 4 Execution of a CLOSE statement for a unit may occur in any program unit of a program and need not 5 occur in the same program unit as the execution of an OPEN statement referring to that unit. 6 Execution of a CLOSE statement performs a wait operation for any pending asynchronous data transfer 7 operations for the specified unit. 8 Execution of a CLOSE statement specifying a unit that does not exist or has no file connected to it is 9 permitted and affects no file. 10 After a unit has been disconnected by execution of a CLOSE statement, it may be connected again 11 within the same program, either to the same file or to a different file. After a named file has been 12 disconnected by execution of a CLOSE statement, it may be connected again within the same program, 13 either to the same unit or to a different unit, provided that the file still exists. 14 At normal termination of execution of a program, all units that are connected are closed. Each unit 15 is closed with status KEEP unless the file status prior to termination of execution was SCRATCH, in 16 which case the unit is closed with status DELETE. 17 NOTE 9.25 The effect is as though a CLOSE statement without a STATUS= specifier were executed on each connected unit. R908 close-stmt is CLOSE ( close-spec -list ) 18 R909 close-spec is [ UNIT = ] file-unit-number 19 or IOSTAT = scalar-int-variable 20 or IOMSG = iomsg-variable 21 or ERR = label 22 or STATUS = scalar-default-char-expr 23 C907 (R909) No specifier shall appear more than once in a given close-spec -list. 24 C908 (R909) A file-unit-number shall be specified; if the optional characters UNIT= are omitted, the 25 223 J3/06-007 WORKING DRAFT 2006/07/11 file-unit-number shall be the first item in the close-spec -list. 1 C909 (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. 3 The scalar-default-char-expr has a limited list of character values. Any trailing blanks are ignored. The 4 value specified is without regard to case. 5 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 6 NOTE 9.26 An example of a CLOSE statement is: CLOSE (10, STATUS = 'KEEP') NOTE 9.27 For more explanatory information on the CLOSE statement, see C.6.6. 9.4.7.1 STATUS= sp ecifier in the CLOSE statement 7 The scalar-default-char-expr shall evaluate to KEEP or DELETE. The STATUS= specifier determines 8 the disposition of the file that is connected to the specified unit. KEEP shall not be specified for a file 9 whose status prior to execution of a CLOSE statement is SCRATCH. If KEEP is specified for a file that 10 exists, the file continues to exist after the execution of a CLOSE statement. If KEEP is specified for a 11 file that does not exist, the file will not exist after the execution of a CLOSE statement. If DELETE is 12 specified, the file will not exist after the execution of a CLOSE statement. If this specifier is omitted, the 13 default value is KEEP, unless the file status prior to execution of the CLOSE statement is SCRATCH, 14 in which case the default value is DELETE. 15 9.5 Data transfer statements 16 The READ statement is the data transfer input statement. The WRITE statement and the 17 PRINT statement are the data transfer output statements. 18 R910 read-stmt is READ ( io-control-spec -list ) [ input-item -list ] 19 or READ format [ , input-item -list ] 20 R911 write-stmt is WRITE ( io-control-spec -list ) [ output-item -list ] 21 R912 print-stmt is PRINT format [ , output-item -list ] 22 NOTE 9.28 Examples of data transfer statements are: READ (6, *) SIZE READ 10, A, B WRITE (6, 10) A, S, J PRINT 10, A, S, J 10 FORMAT (2E16.3, I5) 9.5.1 Control information list 23 A control information list is an io-control-spec -list. It governs data transfer. 24 224 2006/07/11 WORKING DRAFT J3/06-007 R913 io-control-spec is [ UNIT = ] io-unit 1 or [ FMT = ] format 2 or [ NML = ] namelist-group-name 3 or ADVANCE = scalar-default-char-expr 4 or ASYNCHRONOUS = scalar-char-initialization-expr 5 or BLANK = scalar-default-char-expr 6 or DECIMAL = scalar-default-char-expr 7 or DELIM = scalar-default-char-expr 8 or END = label 9 or EOR = label 10 or ERR = label 11 or ID = scalar-int-variable 12 or IOMSG = iomsg-variable 13 or IOSTAT = scalar-int-variable 14 or PAD = scalar-default-char-expr 15 or POS = scalar-int-expr 16 or REC = scalar-int-expr 17 or ROUND = scalar-default-char-expr 18 or SIGN = scalar-default-char-expr 19 or SIZE = scalar-int-variable 20 C910 (R913) No specifier shall appear more than once in a given io-control-spec -list. 21 C911 (R913) An io-unit shall be specified; if the optional characters UNIT= are omitted, the io-unit 22 shall be the first item in the io-control-spec -list. 23 C912 (R913) A DELIM= or SIGN= specifier shall not appear in a read-stmt . 24 C913 (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt . 25 C914 (R913) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 26 branch target statement that appears in the same scoping unit as the data transfer statement. 27 C915 (R913) A namelist-group-name shall be the name of a namelist group. 28 C916 (R913) A namelist-group-name shall not appear if an input-item -list or an output-item -list 29 appears in the data transfer statement. 30 C917 (R913) An io-control-spec -list shall not contain both a format and a namelist-group-name . 31 C918 (R913) If format appears without a preceding FMT=, it shall be the second item in the io- 32 control-spec -list and the first item shall be io-unit . 33 C919 (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item 34 in the io-control-spec -list and the first item shall be io-unit . 35 C920 (R913) If io-unit is not a file-unit-number , the io-control-spec -list shall not contain a REC= 36 specifier or a POS= specifier. 37 C921 (R913) If the REC= specifier appears, an END= specifier shall not appear, a namelist-group- 38 name shall not appear, and the format , if any, shall not be an asterisk. 39 C922 (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- 40 put/output statement with explicit format specification (10.2) whose control information list 41 225 J3/06-007 WORKING DRAFT 2006/07/11 does not contain an internal-file-variable as the io-unit . 1 C923 (R913) If an EOR= specifier appears, an ADVANCE= specifier also shall appear. 2 C924 (R913) If a SIZE= specifier appears, an ADVANCE= specifier also shall appear. 3 C925 (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type 4 default character and shall have the value YES or NO. 5 C926 (R913) An ASYNCHRONOUS= specifier with a value YES shall not appear unless io-unit is a 6 file-unit-number . 7 C927 (R913) If an ID= specifier appears, an ASYNCHRONOUS= specifier with the value YES shall 8 also appear. 9 C928 (R913) If a POS= specifier appears, the io-control-spec -list shall not contain a REC= specifier. 10 C929 (R913) If a DECIMAL=, BLANK=, PAD=, SIGN=, or ROUND= specifier appears, a format 11 or namelist-group-name shall also appear. 12 C930 (R913) If a DELIM= specifier appears, either format shall be an asterisk or namelist-group-name 13 shall appear. 14 A SIZE= specifier may appear only in an input statement that contains an ADVANCE= specifier with 15 the value NO. 16 An EOR= specifier may appear only in an input statement that contains an ADVANCE= specifier with 17 the value NO. 18 If the data transfer statement contains a format or namelist-group-name , the statement is a formatted 19 input/output statement; otherwise, it is an unformatted input/output statement. 20 The ADVANCE=, ASYNCHRONOUS=, DECIMAL=, BLANK=, DELIM=, PAD=, SIGN=, and 21 ROUND= specifiers have a limited list of character values. Any trailing blanks are ignored. The 22 values specified are without regard to case. 23 The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 24 NOTE 9.29 An example of a READ statement is: READ (IOSTAT = IOS, UNIT = 6, FMT = '(10F8.2)') A, B 9.5.1.1 FMT= sp ecifier in a data transfer statement 25 The FMT= specifier supplies a format specification or specifies list-directed formatting for a formatted 26 input/output statement. 27 R914 format is default-char-expr 28 or label 29 or * 30 C931 (R914) The label shall be the label of a FORMAT statement that appears in the same scoping 31 unit as the statement containing the FMT= specifier. 32 The default-char-expr shall evaluate to a valid format specification (10.2.1 and 10.2.2). 33 226 2006/07/11 WORKING DRAFT J3/06-007 NOTE 9.30 A default-char-expr includes a character constant. If default-char-expr is an array, it is treated as if all of the elements of the array were specified in array 1 element order and were concatenated. 2 If format is *, the statement is a list-directed input/output statement. 3 NOTE 9.31 An example in which the format is a character expression is: READ (6, FMT = "(" // CHAR_FMT // ")" ) X, Y, Z where CHAR FMT is a default character variable. 9.5.1.2 NML= sp ecifier in a data transfer statement 4 The NML= specifier supplies the namelist-group-name (5.6). This name identifies a particular collection 5 of data ob jects on which transfer is to be performed. 6 If a namelist-group-name appears, the statement is a namelist input/output statement. 7 9.5.1.3 ADVANCE= sp ecifier in a data transfer statement 8 The scalar-default-char-expr shall evaluate to YES or NO. The ADVANCE= specifier determines wheth- 9 er advancing input/output occurs for a nonchild input/output statement. If YES is specified, advancing 10 input/output occurs. If NO is specified, nonadvancing input/output occurs (9.2.3.1). If this specifier is 11 omitted from a nonchild input/output statement that allows the specifier, the default value is YES. A for- 12 matted child input/output statement is a nonadvancing input/output statement, and any ADVANCE= 13 specifier is ignored. 14 9.5.1.4 ASYNCHRONOUS= sp ecifier in a data transfer statement 15 The ASYNCHRONOUS= specifier determines whether this input/output statement is synchronous or 16 asynchronous. If YES is specified, the statement and the input/output operation are said to be asyn- 17 chronous. If NO is specified or if the specifier is omitted, the statement and the input/output operation 18 are said to be synchronous. 19 Asynchronous input/output is permitted only for external files opened with an ASYNCHRONOUS= 20 specifier with the value YES in the OPEN statement. 21 NOTE 9.32 Both synchronous and asynchronous input/output are allowed for files opened with an ASYN- CHRONOUS= specifier of YES. For other files, only synchronous input/output is allowed; this includes files opened with an ASYNCHRONOUS= specifier of NO, files opened without an ASYN- CHRONOUS= specifier, preconnected files accessed without an OPEN statement, and internal files. The ASYNCHRONOUS= specifier value in a data transfer statement is an initialization expression because it effects compiler optimizations and, therefore, needs to be known at compile time. The processor may perform an asynchronous data transfer operation asynchronously, but it is not re- 22 quired to do so. For each external file, records and file storage units read or written by asynchronous 23 data transfer statements are read, written, and processed in the same order as they would have been if 24 227 J3/06-007 WORKING DRAFT 2006/07/11 the data transfer statements were synchronous. 1 If a variable is used in an asynchronous data transfer statement as 2 (1) an item in an input/output list, 3 (2) a group ob ject in a namelist, or 4 (3) a SIZE= specifier 5 the base ob ject of the data-ref is implicitly given the ASYNCHRONOUS attribute in the scoping unit 6 of the data transfer statement. This attribute may be confirmed by explicit declaration. 7 When an asynchronous input/output statement is executed, the set of storage units specified by the 8 item list or NML= specifier, plus the storage units specified by the SIZE= specifier, is defined to be the 9 pending input/output storage sequence for the data transfer operation. 10 NOTE 9.33 A pending input/output storage sequence is not necessarily a contiguous set of storage units. A pending input/output storage sequence affector is a variable of which any part is associated with a 11 storage unit in a pending input/output storage sequence. 12 9.5.1.5 BLANK= sp ecifier in a data transfer statement 13 The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier temporarily 14 changes (9.4.1) the blank interpretation mode (10.8.6, 9.4.5.4) for the connection. If the specifier is 15 omitted, the mode is not changed. 16 9.5.1.6 DECIMAL= sp ecifier in a data transfer statement 17 The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier temporar- 18 ily changes (9.4.1) the decimal edit mode (10.8.8, 9.4.5.5) for the connection. If the specifier is omitted, 19 the mode is not changed. 20 9.5.1.7 DELIM= sp ecifier in a data transfer statement 21 The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 22 ifier temporarily changes (9.4.1) the delimiter mode (10.10.2, 10.11.2.1, 9.4.5.6) for the connection. If 23 the specifier is omitted, the mode is not changed. 24 9.5.1.8 ID= sp ecifier in a data transfer statement 25 Successful execution of an asynchronous data transfer statement containing an ID= specifier causes the 26 variable specified in the ID= specifier to become defined with a processor-dependent value. This value 27 is referred to as the identifier of the data transfer operation. It can be used in a subsequent WAIT or 28 INQUIRE statement to identify the particular data transfer operation. 29 If an error occurs during the execution of a data transfer statement containing an ID= specifier, the 30 variable specified in the ID= specifier becomes undefined. 31 A child data transfer statement shall not specify the ID= specifier. 32 9.5.1.9 PAD= sp ecifier in a data transfer statement 33 The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier temporarily changes 34 (9.4.1) the pad mode (9.5.3.4.2, 9.4.6.1) for the connection. If the specifier is omitted, the mode is not 35 changed. 36 228 2006/07/11 WORKING DRAFT J3/06-007 9.5.1.10 POS= sp ecifier in a data transfer statement 1 The POS= specifier specifies the file position in file storage units. This specifier may appear in a data 2 transfer statement only if the statement specifies a unit connected for stream access. A child data 3 transfer statement shall not specify this specifier. 4 A processor may prohibit the use of POS= with particular files that do not have the properties necessary 5 to support random positioning. A processor may also prohibit positioning a particular file to any 6 position prior to its current file position if the file does not have the properties necessary to support such 7 positioning. 8 NOTE 9.34 A file that represents connection to a device or data stream might not be positionable. If the file is connected for formatted stream access, the file position specified by POS= shall be equal to 9 either 1 (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE 10 statement for the file. 11 9.5.1.11 REC= sp ecifier in a data transfer statement 12 The REC= specifier specifies the number of the record that is to be read or written. This specifier 13 may appear only in an input/output statement that specifies a unit connected for direct access; it 14 shall not appear in a child data transfer statement. If the control information list contains a REC= 15 specifier, the statement is a direct access input/output statement. A child data transfer statement 16 is a direct access data transfer statement if the parent is a direct access data transfer statement. Any 17 other data transfer statement is a sequential access input/output statement or a stream access 18 input/output statement, depending on whether the file connection is for sequential access or stream 19 access. 20 9.5.1.12 ROUND= sp ecifier in a data transfer statement 21 The scalar-default-char-expr shall evaluate to one of the values specified in 9.4.6.4. The ROUND= 22 specifier temporarily changes (9.4.1) the I/O rounding mode (10.7.2.3.7, 9.4.6.4) for the connection. If 23 the specifier is omitted, the mode is not changed. 24 9.5.1.13 SIGN= sp ecifier in a data transfer statement 25 The scalar-default-char-expr shall evaluate to PLUS, SUPPRESS, or PROCESSOR DEFINED. The 26 SIGN= specifier temporarily changes (9.4.1) the sign mode (10.8.4, 9.4.6.5) for the connection. If the 27 specifier is omitted, the mode is not changed. 28 9.5.1.14 SIZE= sp ecifier in a data transfer statement 29 When a synchronous nonadvancing input statement terminates, the variable specified in the SIZE= 30 specifier becomes defined with the count of the characters transferred by data edit descriptors during 31 execution of the current input statement. Blanks inserted as padding (9.5.3.4.2) are not counted. 32 For asynchronous nonadvancing input, the storage units specified in the SIZE= specifier become defined 33 with the count of the characters transferred when the corresponding wait operation is executed. 34 9.5.2 Data transfer input/output list 35 An input/output list specifies the entities whose values are transferred by a data transfer input/output 36 statement. 37 229 J3/06-007 WORKING DRAFT 2006/07/11 R915 input-item is variable 1 or io-implied-do 2 R916 output-item is expr 3 or io-implied-do 4 R917 io-implied-do is ( io-implied-do-object -list , io-implied-do-control ) 5 R918 io-implied-do-object is input-item 6 or output-item 7 R919 io-implied-do-control is do-variable = scalar-int-expr , 8 scalar-int-expr [ , scalar-int-expr ] 9 C932 (R915) A variable that is an input-item shall not be a whole assumed-size array. 10 C933 (R915) A variable that is an input-item shall not be a procedure pointer. 11 C934 (R919) The do-variable shall be a named scalar variable of type integer. 12 C935 (R918) In an input-item -list, an io-implied-do-object shall be an input-item . In an output-item - 13 list, an io-implied-do-object shall be an output-item . 14 C936 (R916) An expression that is an output-item shall not have a value that is a procedure pointer. 15 An input-item shall not appear as, nor be associated with, the do-variable of any io-implied-do that 16 contains the input-item . 17 NOTE 9.35 A constant, an expression involving operators or function references, or an expression enclosed in parentheses may appear as an output list item but shall not appear as an input list item. If an input item is a pointer, it shall be associated with a definable target and data are transferred from 18 the file to the associated target. If an output item is a pointer, it shall be associated with a target and 19 data are transferred from the target to the file. 20 NOTE 9.36 Data transfers always involve the movement of values between a file and internal storage. A pointer as such cannot be read or written. Therefore, a pointer shall not appear as an item in an input/output list unless it is associated with a target that can receive a value (input) or can deliver a value (output). If an input item or an output item is allocatable, it shall be allocated. 21 A list item shall not be polymorphic unless it is processed by a user-defined derived-type input/output 22 procedure (9.5.3.7). 23 The do-variable of an io-implied-do that is in another io-implied-do shall not appear as, nor be associated 24 with, the do-variable of the containing io-implied-do . 25 The following rules describing whether to expand an input/output list item are re-applied to each 26 expanded list item until none of the rules apply. 27 If an array appears as an input/output list item, it is treated as if the elements, if any, were specified in 28 array element order (6.2.2.2). However, no element of that array may affect the value of any expression 29 in the input-item , nor may any element appear more than once in an input-item . 30 230 2006/07/11 WORKING DRAFT J3/06-007 NOTE 9.37 For example: INTEGER A (100), J (100) ... READ *, A (A) ! Not allowed READ *, A (LBOUND (A, 1) : UBOUND (A, 1)) ! Allowed READ *, A (J) ! Allowed if no two elements ! of J have the same value A(1) = 1; A(10) = 10 READ *, A (A (1) : A (10)) ! Not allowed If a list item of derived type in an unformatted input/output statement is not processed by a user-defined 1 derived-type input/output procedure (9.5.3.7), and if any subob ject of that list item would be processed 2 by a user-defined derived-type input/output procedure, the list item is treated as if all of the components 3 of the ob ject were specified in the list in component order (4.5.4.6); those components shall be accessible 4 in the scoping unit containing the input/output statement and shall not be pointers or allocatable. 5 An effective input/output list item of derived type in an unformatted input/output statement is treated 6 as a single value in a processor-dependent form unless the list item or a subob ject thereof is processed 7 by a user-defined derived-type input/output procedure (9.5.3.7). 8 NOTE 9.38 The appearance of a derived-type ob ject 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 ob ject to similar sequences for aggregate ob jects 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. If a list item of derived type in a formatted input/output statement is not processed by a user-defined 9 derived-type input/output procedure, that list item is treated as if all of the components of the list item 10 were specified in the list in component order; those components shall be accessible in the scoping unit 11 containing the input/output statement and shall not be pointers or allocatable. 12 If a derived-type list item is not treated as a list of its individual components, that list item's ultimate 13 components shall not have the POINTER or ALLOCATABLE attribute unless that list item is processed 14 by a user-defined derived-type input/output procedure. 15 The scalar ob jects resulting when a data transfer statement's list items are expanded according to the 16 rules in this subclause for handling array and derived-type list items are called effective items. Zero- 17 sized arrays and io-implied-do s with an iteration count of zero do not contribute to the effective list 18 items. A scalar character item of zero length is an effective list item. 19 NOTE 9.39 In a formatted input/output statement, edit descriptors are associated with effective list items, which are always scalar. The rules in 9.5.2 determine the set of effective list items corresponding to each actual list item in the statement. These rules may have to be applied repetitively until all of the effective list items are scalar items. 231 J3/06-007 WORKING DRAFT 2006/07/11 For an io-implied-do , the loop initialization and execution is the same as for a DO construct (8.1.7.5). 1 An input/output list shall not contain an item of nondefault character type if the input/output statement 2 specifies an internal file of default character type. An input/output list shall not contain an item of 3 nondefault character type other than ISO 10646 or ASCII character type if the input/output statement 4 specifies an internal file of ISO 10646 character type. An input/output list shall not contain a character 5 item of any character type other than ASCII character type if the input/output statement specifies an 6 internal file of ASCII character type. 7 NOTE 9.40 An example of an output list with an implied DO is: WRITE (LP, FMT = '(10F8.2)') (LOG (A (I)), I = 1, N + 9, K), G 9.5.3 Execution of a data transfer input/output statement 8 Execution of a WRITE or PRINT statement for a file that does not exist creates the file unless an error 9 condition occurs. 10 The effect of executing a synchronous data transfer input/output statement shall be as if the following 11 operations were performed in the order specified. 12 (1) Determine the direction of data transfer. 13 (2) Identify the unit. 14 (3) Perform a wait operation for all pending input/output operations for the unit. If an error, 15 end-of-file, or end-of-record condition occurs during any of the wait operations, steps 4 16 through 8 are skipped for the current data transfer statement. 17 (4) Establish the format if one is specified. 18 (5) If the statement is not a child data transfer statement (9.5.3.7), 19 (a) position the file prior to data transfer (9.2.3.2), and 20 (b) for formatted data transfer, set the left tab limit (10.8.1.1). 21 (6) Transfer data between the file and the entities specified by the input/output list (if any) or 22 namelist. 23 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. 24 (8) Position the file after data transfer (9.2.3.3) unless the statement is a child data transfer 25 statement (9.5.3.7). 26 (9) Cause any variable specified in a SIZE= specifier to become defined. 27 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 28 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 29 The effect of executing an asynchronous data transfer input/output statement shall be as if the following 30 operations were performed in the order specified. 31 (1) Determine the direction of data transfer. 32 (2) Identify the unit. 33 (3) Establish the format if one is specified. 34 (4) Position the file prior to data transfer (9.2.3.2) and, for formatted data transfer, set the left 35 tab limit (10.8.1.1). 36 (5) Establish the set of storage units identified by the input/output list. For a READ statement, 37 this might require some or all of the data in the file to be read if an input variable is used 38 as a scalar-int-expr in an io-implied-do-control in the input/output list, as a subscript , 39 substring-range , stride , or is otherwise referenced. 40 232 2006/07/11 WORKING DRAFT J3/06-007 (6) Initiate an asynchronous data transfer between the file and the entities specified by the 1 input/output list (if any) or namelist. The asynchronous data transfer may complete (and 2 an error, end-of-file, or end-of-record condition may occur) during the execution of this data 3 transfer statement or during a later wait operation. 4 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. The con- 5 ditions may occur during the execution of this data transfer statement or during the corre- 6 sponding wait operation, but not both. 7 Also, any of these conditions that would have occurred during the corresponding wait oper- 8 ation for a previously pending data transfer operation that does not have an ID= specifier 9 may occur during the execution of this data transfer statement. 10 (8) Position the file as if the data transfer had finished (9.2.3.3). 11 (9) Cause any variable specified in a SIZE= specifier to become undefined. 12 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 13 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 14 For an asynchronous data transfer statement, the data transfers may occur during execution of the 15 statement, during execution of the corresponding wait operation, or anywhere between. The data transfer 16 operation is considered to be pending until a corresponding wait operation is performed. 17 For asynchronous output, a pending input/output storage sequence affector (9.5.1.4) shall not be rede- 18 fined, become undefined, or have its pointer association status changed. 19 For asynchronous input, a pending input/output storage sequence affector shall not be referenced, be- 20 come defined, become undefined, become associated with a dummy argument that has the VALUE 21 attribute, or have its pointer association status changed. 22 Error, end-of-file, and end-of-record conditions in an asynchronous data transfer operation may occur 23 during execution of either the data transfer statement or the corresponding wait operation. If an ID= 24 specifier does not appear in the initiating data transfer statement, the conditions may occur during the 25 execution of any subsequent data transfer or wait operation for the same unit. When a condition occurs 26 for a previously executed asynchronous data transfer statement, a wait operation is performed for all 27 pending data transfer operations on that unit. When a condition occurs during a subsequent statement, 28 any actions specified by IOSTAT=, IOMSG=, ERR=, END=, and EOR= specifiers for that statement 29 are taken. 30 NOTE 9.41 Because end-of-file and error conditions for asynchronous data transfer statements without an ID= specifier may be reported by the processor during the execution of a subsequent data transfer statement, it may be impossible for the user to determine which input/output statement caused the condition. Reliably detecting which READ statement caused an end-of-file condition requires that all asynchronous READ statements for the unit include an ID= specifier. 9.5.3.1 Direction of data transfer 31 Execution of a READ statement causes values to be transferred from a file to the entities specified by 32 the input list, if any, or specified within the file itself for namelist input. Execution of a WRITE or 33 PRINT statement causes values to be transferred to a file from the entities specified by the output list 34 and format specification, if any, or by the namelist-group-name for namelist output. 35 9.5.3.2 Identifying a unit 36 A data transfer input/output statement that contains an input/output control list includes a UNIT= 37 specifier that identifies an external or internal unit. A READ statement that does not contain an 38 input/output control list specifies a particular processor-dependent unit, which is the same as the unit 39 233 J3/06-007 WORKING DRAFT 2006/07/11 identified by * in a READ statement that contains an input/output control list. The PRINT statement 1 specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE 2 statement. Thus, each data transfer input/output statement identifies an external or internal unit. 3 The unit identified by a data transfer input/output statement shall be connected to a file when execution 4 of the statement begins. 5 NOTE 9.42 The file may be preconnected. 9.5.3.3 Establishing a format 6 If the input/output control list contains * as a format, list-directed formatting is established. If namelist- 7 group-name appears, namelist formatting is established. If no format or namelist-group-name is spec- 8 ified, unformatted data transfer is established. Otherwise, the format specification identified by the 9 FMT= specifier is established. 10 On output, if an internal file has been specified, a format specification that is in the file or is associated 11 with the file shall not be specified. 12 9.5.3.4 Data transfer 13 Data are transferred between the file and the entities specified by the input/output list or namelist. 14 The list items are processed in the order of the input/output list for all data transfer input/output 15 statements except namelist formatted data transfer statements. The list items for a namelist input 16 statement are processed in the order of the entities specified within the input records. The list items 17 for a namelist output statement are processed in the order in which the variables are specified in the 18 namelist-group-object -list. Effective items are derived from the input/output list items as described in 19 9.5.2. 20 All values needed to determine which entities are specified by an input/output list item are determined 21 at the beginning of the processing of that item. 22 All values are transmitted to or from the entities specified by a list item prior to the processing of any 23 succeeding list item for all data transfer input/output statements. 24 NOTE 9.43 In the example, READ (N) N, X (N) the old value of N identifies the unit, but the new value of N is the subscript of X. All values following the name = part of the namelist entity (10.11) within the input records are transmit- 25 ted to the matching entity specified in the namelist-group-object -list prior to processing any succeeding 26 entity within the input record for namelist input statements. If an entity is specified more than once 27 within the input record during a namelist formatted data transfer input statement, the last occurrence 28 of the entity specifies the value or values to be used for that entity. 29 An input list item, or an entity associated with it, shall not contain any portion of an established format 30 specification. 31 If the input/output item is a pointer, data are transferred between the file and the associated target. 32 If an internal file has been specified, an input/output list item shall not be in the file or associated with 33 234 2006/07/11 WORKING DRAFT J3/06-007 the file. 1 NOTE 9.44 The file is a data ob ject. A DO variable becomes defined and its iteration count established at the beginning of processing of the 2 items that constitute the range of an io-implied-do . 3 On output, every entity whose value is to be transferred shall be defined. 4 9.5.3.4.1 Unformatted data transfer 5 During unformatted data transfer, data are transferred without editing between the file and the entities 6 specified by the input/output list. If the file is connected for sequential or direct access, exactly one 7 record is read or written. 8 Ob jects of intrinsic or derived types may be transferred by means of an unformatted data transfer 9 statement. 10 A value in the file is stored in a contiguous sequence of file storage units, beginning with the file storage 11 unit immediately following the current file position. 12 After each value is transferred, the current file position is moved to a point immediately after the last 13 file storage unit of the value. 14 On input from a file connected for sequential or direct access, the number of file storage units required 15 by the input list shall be less than or equal to the number of file storage units in the record. 16 On input, if the file storage units transferred do not contain a value with the same type and type 17 parameters as the input list entity, then the resulting value of the entity is processor-dependent except 18 in the following cases. 19 (1) A complex list entity may correspond to two real values of the same kind stored in the file, 20 or vice-versa. 21 (2) A default character list entity of length n may correspond to n default characters stored in 22 the file, regardless of the length parameters of the entities that were written to these storage 23 units of the file. If the file is connected for stream input, the characters may have been 24 written by formatted stream output. 25 On output to a file connected for unformatted direct access, the output list shall not specify more values 26 than can fit into the record. If the file is connected for direct access and the values specified by the 27 output list do not fill the record, the remainder of the record is undefined. 28 If the file is connected for unformatted sequential access, the record is created with a length sufficient 29 to hold the values from the output list. This length shall be one of the set of allowed record lengths for 30 the file and shall not exceed the value specified in the RECL= specifier, if any, of the OPEN statement 31 that established the connection. 32 If the file is not connected for unformatted input/output, unformatted data transfer is prohibited. 33 The unit specified shall be an external unit. 34 9.5.3.4.2 Formatted data transfer 35 During formatted data transfer, data are transferred with editing between the file and the entities 36 specified by the input/output list or by the namelist-group-name . Format control is initiated and editing 37 is performed as described in Clause 10. 38 235 J3/06-007 WORKING DRAFT 2006/07/11 The current record and possibly additional records are read or written. 1 Values may be transferred by means of a formatted data transfer statement to or from ob jects of intrinsic 2 or derived types. In the latter case, the transfer is in the form of values of intrinsic types to or from the 3 components of intrinsic types that ultimately comprise these structured ob jects unless the derived-type 4 list item is processed by a user-defined derived-type input/output procedure (9.5.3.7). 5 If the file is not connected for formatted input/output, formatted data transfer is prohibited. 6 During advancing input when the pad mode has the value NO, the input list and format specification 7 shall not require more characters from the record than the record contains. 8 During advancing input when the pad mode has the value YES, blank characters are supplied by the 9 processor if the input list and format specification require more characters from the record than the 10 record contains. 11 During nonadvancing input when the pad mode has the value NO, an end-of-record condition (9.10) 12 occurs if the input list and format specification require more characters from the record than the record 13 contains, and the record is complete (9.2.2.3). If the record is incomplete, an end-of-file condition occurs 14 instead of an end-of-record condition. 15 During nonadvancing input when the pad mode has the value YES, blank characters are supplied by the 16 processor if an input item and its corresponding data edit descriptor require more characters from the 17 record than the record contains. If the record is incomplete, an end-of-file condition occurs; otherwise 18 an end-of-record condition occurs. 19 If the file is connected for direct access, the record number is increased by one as each succeeding record 20 is read or written. 21 On output, if the file is connected for direct access or is an internal file and the characters specified by 22 the output list and format do not fill a record, blank characters are added to fill the record. 23 On output, the output list and format specification shall not specify more characters for a record than 24 have been specified by a RECL= specifier in the OPEN statement or the record length of an internal 25 file. 26 9.5.3.5 List-directed formatting 27 If list-directed formatting has been established, editing is performed as described in 10.10. 28 9.5.3.6 Namelist formatting 29 If namelist formatting has been established, editing is performed as described in 10.11. 30 Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist- 31 group-object that is a pointer shall be associated with a target. If a namelist-group-object is polymorphic 32 or has an ultimate component that is allocatable or a pointer, that ob ject shall be processed by a user- 33 defined derived-type input/output procedure (9.5.3.7). 34 9.5.3.7 User-defined derived-typ e input/output 35 User-defined derived-type input/output procedures allow a program to override the default handling of 36 derived-type ob jects and values in data transfer input/output statements described in 9.5.2. 37 A user-defined derived-type input/output procedure is a procedure accessible by a dtio-generic-spec 38 (12.4.2.1). A particular user-defined derived-type input/output procedure is selected as described in 39 9.5.3.7.3. 40 236 2006/07/11 WORKING DRAFT J3/06-007 9.5.3.7.1 Executing user-defined derived-typ e input/output data transfers 1 If a derived-type input/output procedure is selected as specified in 9.5.3.7.3, the processor shall call the se- 2 lected user-defined derived-type input/output procedure for any appropriate data transfer input/output 3 statements executed in that scoping unit. The user-defined derived-type input/output procedure controls 4 the actual data transfer operations for the derived-type list item. 5 A data transfer statement that includes a derived-type list item and that causes a user-defined derived- 6 type input/output procedure to be invoked is called a parent data transfer statement. A data 7 transfer statement that is executed while a parent data transfer statement is being processed and that 8 specifies the unit passed into a user-defined derived-type input/output procedure is called a child data 9 transfer statement. 10 NOTE 9.45 A user-defined derived-type input/output procedure will usually contain child data transfer state- ments that read values from or write values to the current record or at the current file position. The effect of executing the user-defined derived-type input/output procedure is similar to that of substituting the list items from any child data transfer statements into the parent data transfer statement's list items, along with similar substitutions in the format specification. NOTE 9.46 A particular execution of a READ, WRITE or PRINT statement can be both a parent and a child data transfer statement. A user-defined derived-type input/output procedure can indirectly call itself or another user-defined derived-type input/output procedure by executing a child data transfer statement containing a list item of derived type, where a matching interface is accessible for that derived type. If a user-defined derived-type input/output procedure calls itself indirectly in this manner, it shall be declared RECURSIVE. A child data transfer statement is processed differently from a nonchild data transfer statement in the 11 following ways. 12 · Executing a child data transfer statement does not position the file prior to data transfer. 13 · An unformatted child data transfer statement does not position the file after data transfer is 14 complete. 15 · Any ADVANCE= specifier in a child input/output statement is ignored. 16 9.5.3.7.2 User-defined derived-typ e input/output pro cedures 17 For a particular derived type and a particular set of kind type parameter values, there are four possible 18 sets of characteristics for user-defined derived-type input/output procedures; one each for formatted 19 input, formatted output, unformatted input, and unformatted output. The user need not supply all four 20 procedures. The procedures are specified to be used for derived-type input/output by interface blocks 21 (12.4.2.1) or by generic bindings (4.5.5), with a dtio-generic-spec (R1208). 22 In the four interfaces, which specify the characteristics of user-defined procedures for derived-type in- 23 put/output, the following syntax term is used: 24 R920 dtv-type-spec is TYPE( derived-type-spec ) 25 or CLASS( derived-type-spec ) 26 C937 (R920) If derived-type-spec specifies an extensible type, the CLASS keyword shall be used; 27 237 J3/06-007 WORKING DRAFT 2006/07/11 otherwise, the TYPE keyword shall be used. 1 C938 (R920) All length type parameters of derived-type-spec shall be assumed. 2 If the dtio-generic-spec is READ (FORMATTED), the characteristics shall be the same as those specified 3 by the following interface: 4 SUBROUTINE my_read_routine_formatted & 5 (dtv, & 6 unit, & 7 iotype, v_list, & 8 iostat, iomsg) 9 ! the derived-type value/variable 10 dtv-type-spec , INTENT(INOUT) :: dtv 11 INTEGER, INTENT(IN) :: unit ! unit number 12 ! the edit descriptor string 13 CHARACTER (LEN=*), INTENT(IN) :: iotype 14 INTEGER, INTENT(IN) :: v_list(:) 15 INTEGER, INTENT(OUT) :: iostat 16 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 17 END 18 If the dtio-generic-spec is READ (UNFORMATTED), the characteristics shall be the same as those 19 specified by the following interface: 20 SUBROUTINE my_read_routine_unformatted & 21 (dtv, & 22 unit, & 23 iostat, iomsg) 24 ! the derived-type value/variable 25 dtv-type-spec , INTENT(INOUT) :: dtv 26 INTEGER, INTENT(IN) :: unit 27 INTEGER, INTENT(OUT) :: iostat 28 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 29 END 30 If the dtio-generic-spec is WRITE (FORMATTED), the characteristics shall be the same as those spec- 31 ified by the following interface: 32 SUBROUTINE my_write_routine_formatted & 33 (dtv, & 34 unit, & 35 iotype, v_list, & 36 iostat, iomsg) 37 ! the derived-type value/variable 38 dtv-type-spec , INTENT(IN) :: dtv 39 INTEGER, INTENT(IN) :: unit 40 ! the edit descriptor string 41 CHARACTER (LEN=*), INTENT(IN) :: iotype 42 INTEGER, INTENT(IN) :: v_list(:) 43 INTEGER, INTENT(OUT) :: iostat 44 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 45 END 46 238 2006/07/11 WORKING DRAFT J3/06-007 If the dtio-generic-spec is WRITE (UNFORMATTED), the characteristics shall be the same as those 1 specified by the following interface: 2 SUBROUTINE my_write_routine_unformatted & 3 (dtv, & 4 unit, & 5 iostat, iomsg) 6 ! the derived-type value/variable 7 dtv-type-spec , INTENT(IN) :: dtv 8 INTEGER, INTENT(IN) :: unit 9 INTEGER, INTENT(OUT) :: iostat 10 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 11 END 12 The actual specific procedure names (the my ... routine ... procedure names above) are not signifi- 13 cant. In the discussion here and elsewhere, the dummy arguments in these interfaces are referred by the 14 names given above; the names are, however, arbitrary. 15 When a user-defined derived-type input/output procedure is invoked, the processor shall pass a unit 16 argument that has a value as follows. 17 · If the parent data transfer statement uses a file-unit-number , the value of the unit argument shall 18 be that of the file-unit-number . 19 · If the parent data transfer statement is a WRITE statement with an asterisk unit or a PRINT 20 statement, the unit argument shall have the same value as the OUTPUT UNIT named constant 21 of the ISO FORTRAN ENV intrinsic module (13.8.3). 22 · If the parent data transfer statement is a READ statement with an asterisk unit or a READ 23 statement without an io-control-spec -list, the unit argument shall have the same value as the 24 INPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.3). 25 · Otherwise the parent data transfer statement must access an internal file, in which case the unit 26 argument shall have a processor-dependent negative value. 27 NOTE 9.47 The unit argument passed to a user-defined derived-type input/output procedure will be negative when the parent input/output statement specified an internal unit, or specified an external unit that is a NEWUNIT value. When an internal unit is used with the INQUIRE statement, an error condition will occur, and any variable specified in an IOSTAT= specifier will be assigned the value IOSTAT INQUIRE INTERNAL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.3). For formatted data transfer, the processor shall pass an iotype argument that has the value 28 · "LISTDIRECTED" if the parent data transfer statement specified list directed formatting, 29 · "NAMELIST" if the parent data transfer statement specified namelist formatting, or 30 · "DT" concatenated with the char-literal-constant , if any, of the edit descriptor, if the parent data 31 transfer statement contained a format specification and the list item's corresponding edit descriptor 32 was a DT edit descriptor. 33 239 J3/06-007 WORKING DRAFT 2006/07/11 If the parent data transfer statement is a READ statement, the dtv dummy argument is argument 1 associated with the effective list item that caused the user-defined derived-type input procedure to be 2 invoked, as if the effective list item were an actual argument in this procedure reference (2.5.6). 3 If the parent data transfer statement is a WRITE or PRINT statement, the processor shall provide the 4 value of the effective list item in the dtv dummy argument. 5 If the v -list of the edit descriptor appears in the parent data transfer statement, the processor shall 6 provide the values from it in the v list dummy argument, with the same number of elements in the 7 same order as v -list. If there is no v -list in the edit descriptor or if the data transfer statement specifies 8 list-directed or namelist formatting, the processor shall provide v list as a zero-sized array. 9 NOTE 9.48 The user's procedure may choose to interpret an element of the v list argument as a field width, but this is not required. If it does, it would be appropriate to fill an output field with "*"s if the width is too small. The iostat argument is used to report whether an error, end-of-record, or end-of-file condition (9.10) 10 occurs. If an error condition occurs, the user-defined derived-type input/output procedure shall assign 11 a positive value to the iostat argument. Otherwise, if an end-of-file condition occurs, the user-defined 12 derived-type input procedure shall assign the value of the named constant IOSTAT END (13.8.3.10) 13 to the iostat argument. Otherwise, if an end-of-record condition occurs, the user-defined derived- 14 type input procedure shall assign the value of the named constant IOSTAT EOR (13.8.3.11) to iostat. 15 Otherwise, the user-defined derived-type input/output procedure shall assign the value zero to the 16 iostat argument. 17 If the user-defined derived-type input/output procedure returns a nonzero value for the iostat argument, 18 the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure 19 shall not change the value of the iomsg argument. 20 NOTE 9.49 The values of the iostat and iomsg arguments set in a user-defined derived-type input/output procedure need not be passed to all of the parent data transfer statements. If the iostat argument of the user-defined derived-type input/output procedure has a nonzero value 21 when that procedure returns, and the processor therefore terminates execution of the program as de- 22 scribed in 9.10, the processor shall make the value of the iomsg argument available in a processor- 23 dependent manner. 24 When a parent READ statement is active, an input/output statement shall not read from any external 25 unit other than the one specified by the dummy argument unit and shall not perform output to any 26 external unit. 27 When a parent WRITE or PRINT statement is active, an input/output statement shall not perform 28 output to any external unit other than the one specified by the dummy argument unit and shall not 29 read from any external unit. 30 When a parent data transfer statement is active, a data transfer statement that specifies an internal file 31 is permitted. 32 OPEN, CLOSE, BACKSPACE, ENDFILE, and REWIND statements shall not be executed while a 33 parent data transfer statement is active. 34 A user-defined derived-type input/output procedure may use a FORMAT with a DT edit descriptor for 35 handling a component of the derived type that is itself of a derived type. A child data transfer statement 36 240 2006/07/11 WORKING DRAFT J3/06-007 that is a list directed or namelist input/output statement may contain a list item of derived type. 1 Because a child data transfer statement does not position the file prior to data transfer, the child data 2 transfer statement starts transferring data from where the file was positioned by the parent data transfer 3 statement's most recently processed effective list item or record positioning edit descriptor. This is not 4 necessarily at the beginning of a record. 5 A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement 6 shall not cause the record position to be positioned before the record position at the time the user-defined 7 derived-type input/output procedure was invoked. 8 NOTE 9.50 A robust user-defined derived-type input/output procedure may wish to use INQUIRE to deter- mine the settings of BLANK=, PAD=, ROUND=, DECIMAL=, and DELIM= for an external unit. The INQUIRE provides values as specified in 9.9. Neither a parent nor child data transfer statement shall be asynchronous. 9 A user-defined derived-type input/output procedure, and any procedures invoked therefrom, shall not 10 define, nor cause to become undefined, any storage location referenced by any input/output list item, 11 the corresponding format, or any specifier in any active parent data transfer statement, except through 12 the dtv argument. 13 NOTE 9.51 A child data transfer statement shall not specify the ID=, POS=, or REC= specifiers in an input/output control list. NOTE 9.52 A simple example of derived type formatted output follows. The derived type variable chairman has two components. The type and an associated write formatted procedure are defined in a module so as to be accessible from wherever they might be needed. It would also be possible to check that iotype indeed has the value 'DT' and to set iostat and iomsg accordingly. MODULE p TYPE :: person CHARACTER (LEN=20) :: name INTEGER :: age CONTAINS 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 241 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 9.52 (cont.) 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.53 In the following example, the variables of the derived type node form a linked list, with a single value at each node. The subroutine pwf is used to write the values in the list, one per line. MODULE p TYPE node INTEGER :: value = 0 TYPE (NODE), POINTER :: next_node => NULL ( ) CONTAINS 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 242 2006/07/11 WORKING DRAFT J3/06-007 NOTE 9.53 (cont.) IF(ASSOCIATED(dtv%next_node)) WRITE(unit,'(dt)', IOSTAT=iostat) dtv%next_node END SUBROUTINE pwf END MODULE p 9.5.3.7.3 Resolving derived-typ e input/output pro cedure references 1 A suitable generic interface for user-defined derived-type input/output of an effective item is one that 2 has a dtio-generic-spec that is appropriate to the direction (read or write) and form (formatted or 3 unformatted) of the data transfer as specified in 9.5.3.7, and has a specific interface whose dtv argument 4 is compatible with the effective item according to the rules for argument association in 12.5.1.4. 5 When an effective item (9.5.2) that is of derived-type is encountered during a data transfer, user-defined 6 derived-type input/output occurs if both of the following conditions are true. 7 (1) The circumstances of the input/output are such that user-defined derived-type input/output 8 is permitted; that is, either 9 (a) the transfer was initiated by a list-directed, namelist, or unformatted input/output 10 statement, or 11 (b) a format specification is supplied for the input/output statement, and the edit de- 12 scriptor corresponding to the effective item is a DT edit descriptor. 13 (2) A suitable user-defined derived-type input/output procedure is available; that is, either 14 (a) the declared type of the effective item has a suitable generic type-bound procedure, 15 or 16 (b) a suitable generic interface is accessible. 17 If (2a) is true, the procedure referenced is determined as for explicit type-bound procedure references 18 (12.5); that is, the binding with the appropriate specific interface is located in the declared type of the 19 effective item, and the corresponding binding in the dynamic type of the effective item is selected. 20 If (2a) is false and (2b) is true, the reference is to the procedure identified by the appropriate specific 21 interface in the interface block. This reference shall not be to a dummy procedure that is not present, 22 or to a disassociated procedure pointer. 23 9.5.4 Termination of data transfer statements 24 Termination of an input/output data transfer statement occurs when 25 (1) format processing encounters a data edit descriptor and there are no remaining elements in 26 the input-item -list or output-item -list, 27 (2) unformatted or list-directed data transfer exhausts the input-item -list or output-item -list, 28 (3) namelist output exhausts the namelist-group-object -list, 29 (4) an error condition occurs, 30 (5) an end-of-file condition occurs, 31 (6) a slash (/) is encountered as a value separator (10.10, 10.11) in the record being read during 32 list-directed or namelist input, or 33 (7) an end-of-record condition occurs during execution of a nonadvancing input statement 34 (9.10). 35 243 J3/06-007 WORKING DRAFT 2006/07/11 9.6 Waiting on pending data transfer 1 Execution of an asynchronous data transfer statement in which neither an error, end-of-record, nor end- 2 of-file condition occurs initiates a pending data transfer operation. There may be multiple pending data 3 transfer operations for the same or multiple units simultaneously. A pending data transfer operation 4 remains pending until a corresponding wait operation is performed. A wait operation may be performed 5 by a WAIT, INQUIRE, CLOSE, or file positioning statement. 6 9.6.1 WAIT statement 7 A WAIT statement performs a wait operation for specified pending asynchronous data transfer opera- 8 tions. 9 NOTE 9.54 The CLOSE, INQUIRE, and file positioning statements may also perform wait operations. R921 wait-stmt is WAIT (wait-spec -list ) 10 R922 wait-spec is [ UNIT = ] file-unit-number 11 or END = label 12 or EOR = label 13 or ERR = label 14 or ID = scalar-int-expr 15 or IOMSG = iomsg-variable 16 or IOSTAT = scalar-int-variable 17 C939 (R922) No specifier shall appear more than once in a given wait-spec -list. 18 C940 (R922) A file-unit-number shall be specified; if the optional characters UNIT= are omitted, the 19 file-unit-number shall be the first item in the wait-spec -list. 20 C941 (R922) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 21 branch target statement that appears in the same scoping unit as the WAIT statement. 22 The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 23 The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 24 operation for the specified unit. If the ID= specifier appears, a wait operation for the specified data 25 transfer operation is performed. If the ID= specifier is omitted, wait operations for all pending data 26 transfers for the specified unit are performed. 27 Execution of a WAIT statement specifying a unit that does not exist, has no file connected to it, or was 28 not opened for asynchronous input/output is permitted, provided that the WAIT statement has no ID= 29 specifier; such a WAIT statement does not cause an error or end-of-file condition to occur. 30 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.6.2 Wait op eration 31 A wait operation completes the processing of a pending data transfer operation. Each wait operation 32 completes only a single data transfer operation, although a single statement may perform multiple wait 33 operations. 34 If the actual data transfer is not yet complete, the wait operation first waits for its completion. If the 35 244 2006/07/11 WORKING DRAFT J3/06-007 data transfer operation is an input operation that completed without error, the storage units of the 1 input/output storage sequence then become defined with the values as described in 9.5.1.14 and 9.5.3.4. 2 If any error, end-of-file, or end-of-record conditions occur, the applicable actions specified by the IO- 3 STAT=, IOMSG=, ERR=, END=, and EOR= specifiers of the statement that performs the wait oper- 4 ation are taken. 5 If an error or end-of-file condition occurs during a wait operation for a unit, the processor performs a 6 wait operation for all pending data transfer operations for that unit. 7 NOTE 9.56 Error, end-of-file, and end-of-record conditions may be raised either during the data transfer state- ment that initiates asynchronous input/output, a subsequent asynchronous data transfer statement for the same unit, or during the wait operation. If such conditions are raised during a data transfer statement, they trigger actions according to the IOSTAT=, ERR=, END=, and EOR= specifiers of that statement; if they are raised during the wait operation, the actions are in accordance with the specifiers of the statement that performs the wait operation. After completion of the wait operation, the data transfer operation and its input/output storage sequence 8 are no longer considered to be pending. 9 9.7 File positioning statements 10 R923 backspace-stmt is BACKSPACE file-unit-number 11 or BACKSPACE ( position-spec -list ) 12 R924 endfile-stmt is ENDFILE file-unit-number 13 or ENDFILE ( position-spec -list ) 14 R925 rewind-stmt is REWIND file-unit-number 15 or REWIND ( position-spec -list ) 16 A file that is connected for direct access shall not be referred to by a BACKSPACE, ENDFILE, or 17 REWIND statement. A file that is connected for unformatted stream access shall not be referred to by a 18 BACKSPACE statement. A file that is connected with an ACTION= specifier having the value READ 19 shall not be referred to by an ENDFILE statement. 20 R926 position-spec is [ UNIT = ] file-unit-number 21 or IOMSG = iomsg-variable 22 or IOSTAT = scalar-int-variable 23 or ERR = label 24 C942 (R926) No specifier shall appear more than once in a given position-spec -list. 25 C943 (R926) A file-unit-number shall be specified; if the optional characters UNIT= are omitted, the 26 file-unit-number shall be the first item in the position-spec -list. 27 C944 (R926) The label in the ERR= specifier shall be the statement label of a branch target statement 28 that appears in the same scoping unit as the file positioning statement. 29 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 30 Execution of a file positioning statement performs a wait operation for all pending asynchronous data 31 transfer operations for the specified unit. 32 245 J3/06-007 WORKING DRAFT 2006/07/11 9.7.1 BACKSPACE statement 1 Execution of a BACKSPACE statement causes the file connected to the specified unit to be positioned 2 before the current record if there is a current record, or before the preceding record if there is no current 3 record. If the file is at its initial point, the position of the file is not changed. 4 NOTE 9.57 If the preceding record is an endfile record, the file is positioned before the endfile record. If a BACKSPACE statement causes the implicit writing of an endfile record, the file is positioned before 5 the record that precedes the endfile record. 6 Backspacing a file that is connected but does not exist is prohibited. 7 Backspacing over records written using list-directed or namelist formatting is prohibited. 8 A BACKSPACE statement shall not reference a unit whose connect team has more than one image. 9 NOTE 9.58 An example of a BACKSPACE statement is: BACKSPACE (10, IOSTAT = N) 9.7.2 ENDFILE statement 10 Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record 11 as the next record of the file. The file is then positioned after the endfile record, which becomes the last 12 record of the file. If the file also may be connected for direct access, only those records before the endfile 13 record are considered to have been written. Thus, only those records may be read during subsequent 14 direct access connections to the file. 15 After execution of an ENDFILE statement for a file connected for sequential access, a BACKSPACE 16 or REWIND statement shall be used to reposition the file prior to execution of any data transfer 17 input/output statement or ENDFILE statement. 18 Execution of an ENDFILE statement for a file connected for stream access causes the terminal point of 19 the file to become equal to the current file position. Only file storage units before the current position are 20 considered to have been written; thus only those file storage units may be subsequently read. Subsequent 21 stream output statements may be used to write further data to the file. 22 Execution of an ENDFILE statement for a file that is connected but does not exist creates the file; if 23 the file is connected for sequential access, it is created prior to writing the endfile record. 24 An ENDFILE statement shall not reference a unit whose connect team has more than one image. 25 NOTE 9.59 An example of an ENDFILE statement is: ENDFILE K 9.7.3 REWIND statement 26 Execution of a REWIND statement causes the specified file to be positioned at its initial point. 27 246 2006/07/11 WORKING DRAFT J3/06-007 NOTE 9.60 If the file is already positioned at its initial point, execution of this statement has no effect on the position of the file. Execution of a REWIND statement for a file that is connected but does not exist is permitted and has 1 no effect on any file. 2 A REWIND statement shall not reference a unit whose connect team has more than one image. 3 NOTE 9.61 An example of a REWIND statement is: REWIND 10 9.8 FLUSH statement 4 The form of the FLUSH statement is: 5 R927 flush-stmt is FLUSH file-unit-number 6 or FLUSH ( flush-spec -list ) 7 R928 flush-spec is [UNIT =] file-unit-number 8 or IOSTAT = scalar-int-variable 9 or IOMSG = iomsg-variable 10 or ERR = label 11 C945 (R928) No specifier shall appear more than once in a given flush-spec -list. 12 C946 (R928) A file-unit-number shall be specified; if the optional characters UNIT= are omitted from 13 the unit specifier, the file-unit-number shall be the first item in the flush-spec -list. 14 C947 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 15 that appears in the same scoping unit as the FLUSH statement. 16 The IOSTAT=, IOMSG= and ERR= specifiers are described in 9.10. The IOSTAT= variable shall 17 be set to a processor-dependent positive value if an error occurs, to zero if the processor-dependent 18 flush operation was successful, or to a processor-dependent negative value if the flush operation is not 19 supported for the unit specified. 20 Execution of a FLUSH statement causes data written to an external unit to be made available to other 21 images of the unit's connect team which execute a FLUSH statement in a subsequent segment for that 22 unit. It also causes data written to an external file to be available to other processes, or causes data 23 placed in an external file by means other than Fortran to be available to a READ statement. The action 24 is processor dependent. 25 Execution of a FLUSH statement for a file that is connected but does not exist is permitted and has no 26 effect on any file. A FLUSH statement has no effect on file position. 27 NOTE 9.62 Because this standard does not specify the mechanism of file storage, the exact meaning of the flush operation is not precisely defined. The intention is that the flush operation should make all data written to a file available to other processes or devices, or make data recently added to a file by other processes or devices available to the program via a subsequent read operation. This is commonly called "flushing I/O buffers". 247 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 9.63 An example of a FLUSH statement is: FLUSH( 10, IOSTAT=N) 9.9 File inquiry 1 The INQUIRE statement may be used to inquire about properties of a particular named file or of the 2 connection to a particular unit. There are three forms of the INQUIRE statement: inquire by file, 3 which uses the FILE= specifier, inquire by unit, which uses the UNIT= specifier, and inquire by 4 output list, which uses only the IOLENGTH= specifier. All specifier value assignments are performed 5 according to the rules for assignment statements. 6 An INQUIRE statement may be executed before, while, or after a file is connected to a unit. All values 7 assigned by an INQUIRE statement are those that are current at the time the statement is executed. 8 R929 inquire-stmt is INQUIRE ( inquire-spec -list ) 9 or INQUIRE ( IOLENGTH = scalar-int-variable ) 10 output-item -list 11 NOTE 9.64 Examples of INQUIRE statements are: INQUIRE (IOLENGTH = IOL) A (1:N) INQUIRE (UNIT = JOAN, OPENED = LOG_01, NAMED = LOG_02, & FORM = CHAR_VAR, IOSTAT = IOS) 9.9.1 Inquiry sp ecifiers 12 Unless constrained, the following inquiry specifiers may be used in either of the inquire by file or inquire 13 by unit forms of the INQUIRE statement: 14 R930 inquire-spec is [ UNIT = ] file-unit-number 15 or FILE = file-name-expr 16 or ACCESS = scalar-default-char-variable 17 or ACTION = scalar-default-char-variable 18 or ASYNCHRONOUS = scalar-default-char-variable 19 or BLANK = scalar-default-char-variable 20 or DECIMAL = scalar-default-char-variable 21 or DELIM = scalar-default-char-variable 22 or DIRECT = scalar-default-char-variable 23 or ENCODING = scalar-default-char-variable 24 or ERR = label 25 or EXIST = scalar-default-logical-variable 26 or FORM = scalar-default-char-variable 27 or FORMATTED = scalar-default-char-variable 28 or ID = scalar-int-expr 29 or IOMSG = iomsg-variable 30 or IOSTAT = scalar-int-variable 31 or NAME = scalar-default-char-variable 32 or NAMED = scalar-default-logical-variable 33 or NEXTREC = scalar-int-variable 34 248 2006/07/11 WORKING DRAFT J3/06-007 or NUMBER = scalar-int-variable 1 or OPENED = scalar-default-logical-variable 2 or PAD = scalar-default-char-variable 3 or PENDING = scalar-default-logical-variable 4 or POS = scalar-int-variable 5 or POSITION = scalar-default-char-variable 6 or READ = scalar-default-char-variable 7 or READWRITE = scalar-default-char-variable 8 or RECL = scalar-int-variable 9 or ROUND = scalar-default-char-variable 10 or SEQUENTIAL = scalar-default-char-variable 11 or SIGN = scalar-default-char-variable 12 or SIZE = scalar-int-variable 13 or STREAM = scalar-default-char-variable 14 or UNFORMATTED = scalar-default-char-variable 15 or WRITE = scalar-default-char-variable 16 C948 (R930) No specifier shall appear more than once in a given inquire-spec -list. 17 C949 (R930) An inquire-spec -list shall contain one FILE= specifier or one UNIT= specifier, but not 18 both. 19 C950 (R930) In the inquire by unit form of the INQUIRE statement, if the optional characters UNIT= 20 are omitted, the file-unit-number shall be the first item in the inquire-spec -list. 21 C951 (R930) If an ID= specifier appears, a PENDING= specifier shall also appear. 22 C952 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 23 that appears in the same scoping unit as the INQUIRE statement. 24 If file-unit-number identifies an internal unit (9.5.3.7.2), an error condition occurs. 25 When a returned value of a specifier other than the NAME= specifier is of type character, the value 26 returned is in upper case. 27 If an error condition occurs during execution of an INQUIRE statement, all of the inquiry specifier 28 variables become undefined, except for variables in the IOSTAT= and IOMSG= specifiers (if any). 29 The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 30 9.9.1.1 FILE= sp ecifier in the INQUIRE statement 31 The value of the file-name-expr in the FILE= specifier specifies the name of the file being inquired about. 32 The named file need not exist or be connected to a unit. The value of the file-name-expr shall be of a 33 form acceptable to the processor as a file name. Any trailing blanks are ignored. The interpretation of 34 case is processor dependent. 35 9.9.1.2 ACCESS= sp ecifier in the INQUIRE statement 36 The scalar-default-char-variable in the ACCESS= specifier is assigned the value SEQUENTIAL if the 37 file is connected for sequential access, DIRECT if the file is connected for direct access, or STREAM if 38 the file is connected for stream access. If there is no connection, it is assigned the value UNDEFINED. 39 9.9.1.3 ACTION= sp ecifier in the INQUIRE statement 40 The scalar-default-char-variable in the ACTION= specifier is assigned the value READ if the file is 41 connected for input only, WRITE if the file is connected for output only, and READWRITE if it 42 249 J3/06-007 WORKING DRAFT 2006/07/11 is connected for both input and output. If there is no connection, the scalar-default-char-variable is 1 assigned the value UNDEFINED. 2 9.9.1.4 ASYNCHRONOUS= sp ecifier in the INQUIRE statement 3 The scalar-default-char-variable in the ASYNCHRONOUS= specifier is assigned the value YES if the 4 file is connected and asynchronous input/output on the unit is allowed; it is assigned the value NO if the 5 file is connected and asynchronous input/output on the unit is not allowed. If there is no connection, 6 the scalar-default-char-variable is assigned the value UNDEFINED. 7 9.9.1.5 BLANK= sp ecifier in the INQUIRE statement 8 The scalar-default-char-variable in the BLANK= specifier is assigned the value ZERO or NULL, corre- 9 sponding to the blank interpretation mode in effect for a connection for formatted input/output. If there 10 is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 11 is assigned the value UNDEFINED. 12 9.9.1.6 DECIMAL= sp ecifier in the INQUIRE statement 13 The scalar-default-char-variable in the DECIMAL= specifier is assigned the value COMMA or POINT, 14 corresponding to the decimal edit mode in effect for a connection for formatted input/output. If there 15 is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 16 is assigned the value UNDEFINED. 17 9.9.1.7 DELIM= sp ecifier in the INQUIRE statement 18 The scalar-default-char-variable in the DELIM= specifier is assigned the value APOSTROPHE, QUOTE, 19 or NONE, corresponding to the delimiter mode in effect for a connection for formatted input/output. 20 If there is no connection or if the connection is not for formatted input/output, the scalar-default-char- 21 variable is assigned the value UNDEFINED. 22 9.9.1.8 DIRECT= sp ecifier in the INQUIRE statement 23 The scalar-default-char-variable in the DIRECT= specifier is assigned the value YES if DIRECT is 24 included in the set of allowed access methods for the file, NO if DIRECT is not included in the set of 25 allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether or 26 not DIRECT is included in the set of allowed access methods for the file. 27 9.9.1.9 ENCODING= sp ecifier in the INQUIRE statement 28 The scalar-default-char-variable in the ENCODING= specifier is assigned the value UTF-8 if the file 29 is connected for formatted input/output with an encoding form of UTF-8, and is assigned the value 30 UNDEFINED if the file is connected for unformatted input/output. If there is no connection, it is 31 assigned the value UTF-8 if the processor is able to determine that the encoding form of the file is 32 UTF-8. If the processor is unable to determine the encoding form of the file, the variable is assigned the 33 value UNKNOWN. 34 NOTE 9.65 The value assigned may be something other than UTF-8, UNDEFINED, or UNKNOWN if the processor supports other specific encoding forms (e.g. UTF-16BE). 9.9.1.10 EXIST= sp ecifier in the INQUIRE statement 35 Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the EXIST= 36 specifier to be assigned the value true if there exists a file with the specified name; otherwise, false is 37 250 2006/07/11 WORKING DRAFT J3/06-007 assigned. Execution of an INQUIRE by unit statement causes true to be assigned if the specified unit 1 exists; otherwise, false is assigned. 2 9.9.1.11 FORM= sp ecifier in the INQUIRE statement 3 The scalar-default-char-variable in the FORM= specifier is assigned the value FORMATTED if the 4 file is connected for formatted input/output, and is assigned the value UNFORMATTED if the file is 5 connected for unformatted input/output. If there is no connection, it is assigned the value UNDEFINED. 6 9.9.1.12 FORMATTED= sp ecifier in the INQUIRE statement 7 The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FORMAT- 8 TED is included in the set of allowed forms for the file, NO if FORMATTED is not included in the set 9 of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether or not 10 FORMATTED is included in the set of allowed forms for the file. 11 9.9.1.13 ID= sp ecifier in the INQUIRE statement 12 The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 13 operation for the specified unit. This specifier interacts with the PENDING= specifier (9.9.1.20). 14 9.9.1.14 NAME= sp ecifier in the INQUIRE statement 15 The scalar-default-char-variable in the NAME= specifier is assigned the value of the name of the file if 16 the file has a name; otherwise, it becomes undefined. 17 NOTE 9.66 If this specifier appears in an INQUIRE by file statement, its value is not necessarily the same as the name given in the FILE= specifier. However, the value returned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement. The processor may return a file name qualified by a user identification, device, directory, or other relevant information. The case of the characters assigned to scalar-default-char-variable is processor dependent. 18 9.9.1.15 NAMED= sp ecifier in the INQUIRE statement 19 The scalar-default-logical-variable in the NAMED= specifier is assigned the value true if the file has a 20 name; otherwise, it is assigned the value false. 21 9.9.1.16 NEXTREC= sp ecifier in the INQUIRE statement 22 The scalar-int-variable in the NEXTREC= specifier is assigned the value n + 1, where n is the record 23 number of the last record read from or written to the file connected for direct access. If the file is con- 24 nected but no records have been read or written since the connection, the scalar-int-variable is assigned 25 the value 1. If the file is not connected for direct access or if the position of the file is indeterminate 26 because of a previous error condition, the scalar-int-variable becomes undefined. If there are pending 27 data transfer operations for the specified unit, the value assigned is computed as if all the pending data 28 transfers had already completed. 29 J3 internal note Unresolved Technical Issue 44 NEXTREC= does not have a well-defined meaning in the context of a unit opened with the TEAM= specifier. 251 J3/06-007 WORKING DRAFT 2006/07/11 9.9.1.17 NUMBER= sp ecifier in the INQUIRE statement 1 The scalar-int-variable in the NUMBER= specifier is assigned the value of the external unit number of 2 the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. 3 9.9.1.18 OPENED= sp ecifier in the INQUIRE statement 4 Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the OPENED= 5 specifier to be assigned the value true if the file specified is connected to a unit; otherwise, false is 6 assigned. Execution of an INQUIRE by unit statement causes the scalar-default-logical-variable to be 7 assigned the value true if the specified unit is connected to a file; otherwise, false is assigned. 8 9.9.1.19 PAD= sp ecifier in the INQUIRE statement 9 The scalar-default-char-variable in the PAD= specifier is assigned the value YES or NO, corresponding 10 to the pad mode in effect for a connection for formatted input/output. If there is no connection or if 11 the connection is not for formatted input/output, the scalar-default-char-variable is assigned the value 12 UNDEFINED. 13 9.9.1.20 PENDING= sp ecifier in the INQUIRE statement 14 The PENDING= specifier is used to determine whether or not previously pending asynchronous data 15 transfers are complete. A data transfer operation is previously pending if it is pending at the beginning 16 of execution of the INQUIRE statement. 17 If an ID= specifier appears and the specified data transfer operation is complete, then the variable 18 specified in the PENDING= specifier is assigned the value false and the INQUIRE statement performs 19 the wait operation for the specified data transfer. 20 If the ID= specifier is omitted and all previously pending data transfer operations for the specified unit 21 are complete, then the variable specified in the PENDING= specifier is assigned the value false and the 22 INQUIRE statement performs wait operations for all previously pending data transfers for the specified 23 unit. 24 In all other cases, the variable specified in the PENDING= specifier is assigned the value true and no 25 wait operations are performed; in this case the previously pending data transfers remain pending after 26 the execution of the INQUIRE statement. 27 NOTE 9.67 The processor has considerable flexibility in defining when it considers a transfer to be complete. Any of the following approaches could be used: (1) The INQUIRE statement could consider an asynchronous data transfer to be incom- plete until after the corresponding wait operation. In this case PENDING= would always return true unless there were no previously pending data transfers for the unit. (2) The INQUIRE statement could wait for all specified data transfers to complete and then always return false for PENDING=. (3) The INQUIRE statement could actually test the state of the specified data transfer operations. 9.9.1.21 POS= sp ecifier in the INQUIRE statement 28 The scalar-int-variable in the POS= specifier is assigned the number of the file storage unit immediately 29 following the current position of a file connected for stream access. If the file is positioned at its terminal 30 position, the variable is assigned a value one greater than the number of the highest-numbered file storage 31 252 2006/07/11 WORKING DRAFT J3/06-007 unit in the file. If the file is not connected for stream access or if the position of the file is indeterminate 1 because of previous error conditions, the variable becomes undefined. 2 9.9.1.22 POSITION= sp ecifier in the INQUIRE statement 3 The scalar-default-char-variable in the POSITION= specifier is assigned the value REWIND if the file 4 is connected by an OPEN statement for positioning at its initial point, APPEND if the file is connected 5 for positioning before its endfile record or at its terminal point, and ASIS if the file is connected without 6 changing its position. If there is no connection or if the file is connected for direct access, the scalar- 7 default-char-variable is assigned the value UNDEFINED. If the file has been repositioned since the 8 connection, the scalar-default-char-variable is assigned a processor-dependent value, which shall not be 9 REWIND unless the file is positioned at its initial point and shall not be APPEND unless the file is 10 positioned so that its endfile record is the next record or at its terminal point if it has no endfile record. 11 9.9.1.23 READ= sp ecifier in the INQUIRE statement 12 The scalar-default-char-variable in the READ= specifier is assigned the value YES if READ is included 13 in the set of allowed actions for the file, NO if READ is not included in the set of allowed actions for 14 the file, and UNKNOWN if the processor is unable to determine whether or not READ is included in 15 the set of allowed actions for the file. 16 9.9.1.24 READWRITE= sp ecifier in the INQUIRE statement 17 The scalar-default-char-variable in the READWRITE= specifier is assigned the value YES if READ- 18 WRITE is included in the set of allowed actions for the file, NO if READWRITE is not included in the 19 set of allowed actions for the file, and UNKNOWN if the processor is unable to determine whether or 20 not READWRITE is included in the set of allowed actions for the file. 21 9.9.1.25 RECL= sp ecifier in the INQUIRE statement 22 The scalar-int-variable in the RECL= specifier is assigned the value of the record length of a file con- 23 nected for direct access, or the value of the maximum record length for a file connected for sequential 24 access. If the file is connected for formatted input/output, the length is the number of characters for all 25 records that contain only characters of type default character. If the file is connected for unformatted 26 input/output, the length is measured in file storage units. If there is no connection, or if the connection 27 is for stream access, the scalar-int-variable becomes undefined. 28 9.9.1.26 ROUND= sp ecifier in the INQUIRE statement 29 The scalar-default-char-variable in the ROUND= specifier is assigned the value UP, DOWN, ZERO, 30 NEAREST, COMPATIBLE, or PROCESSOR DEFINED, corresponding to the I/O rounding mode in 31 effect for a connection for formatted input/output. If there is no connection or if the connection is not 32 for formatted input/output, the scalar-default-char-variable is assigned the value UNDEFINED. The 33 processor shall return the value PROCESSOR DEFINED only if the I/O rounding mode currently in 34 effect behaves differently than the UP, DOWN, ZERO, NEAREST, and COMPATIBLE modes. 35 9.9.1.27 SEQUENTIAL= sp ecifier in the INQUIRE statement 36 The scalar-default-char-variable in the SEQUENTIAL= specifier is assigned the value YES if SEQUEN- 37 TIAL is included in the set of allowed access methods for the file, NO if SEQUENTIAL is not included 38 in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine 39 whether or not SEQUENTIAL is included in the set of allowed access methods for the file. 40 253 J3/06-007 WORKING DRAFT 2006/07/11 9.9.1.28 SIGN= sp ecifier in the INQUIRE statement 1 The scalar-default-char-variable in the SIGN= specifier is assigned the value PLUS, SUPPRESS, or 2 PROCESSOR DEFINED, corresponding to the sign mode in effect for a connection for formatted in- 3 put/output. If there is no connection, or if the connection is not for formatted input/output, the 4 scalar-default-char-variable is assigned the value UNDEFINED. 5 9.9.1.29 SIZE= sp ecifier in the INQUIRE statement 6 The scalar-int-variable in the SIZE= specifier is assigned the size of the file in file storage units. If the 7 file size cannot be determined, the variable is assigned the value -1. 8 For a file that may be connected for stream access, the file size is the number of the highest-numbered 9 file storage unit in the file. 10 For a file that may be connected for sequential or direct access, the file size may be different from the 11 number of storage units implied by the data in the records; the exact relationship is processor-dependent. 12 9.9.1.30 STREAM= sp ecifier in the INQUIRE statement 13 The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is 14 included in the set of allowed access methods for the file, NO if STREAM is not included in the set of 15 allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether or 16 not STREAM is included in the set of allowed access methods for the file. 17 9.9.1.31 UNFORMATTED= sp ecifier in the INQUIRE statement 18 The scalar-default-char-variable in the UNFORMATTED= specifier is assigned the value YES if UN- 19 FORMATTED is included in the set of allowed forms for the file, NO if UNFORMATTED is not included 20 in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 21 or not UNFORMATTED is included in the set of allowed forms for the file. 22 9.9.1.32 WRITE= sp ecifier in the INQUIRE statement 23 The scalar-default-char-variable in the WRITE= specifier is assigned the value YES if WRITE is included 24 in the set of allowed actions for the file, NO if WRITE is not included in the set of allowed actions for 25 the file, and UNKNOWN if the processor is unable to determine whether or not WRITE is included in 26 the set of allowed actions for the file. 27 9.9.2 Restrictions on inquiry sp ecifiers 28 The inquire-spec -list in an INQUIRE by file statement shall contain exactly one FILE= specifier and 29 shall not contain a UNIT= specifier. The inquire-spec -list in an INQUIRE by unit statement shall 30 contain exactly one UNIT= specifier and shall not contain a FILE= specifier. The unit specified need 31 not exist or be connected to a file. If it is connected to a file, the inquiry is being made about the 32 connection and about the file connected. 33 9.9.3 Inquire by output list 34 The inquire by output list form of the INQUIRE statement has only an IOLENGTH= specifier and an 35 output list. 36 The scalar-int-variable in the IOLENGTH= specifier is assigned the processor-dependent number of file 37 storage units that would be required to store the data of the output list in an unformatted file. The 38 value shall be suitable as a RECL= specifier in an OPEN statement that connects a file for unformatted 39 direct access when there are input/output statements with the same input/output list. 40 254 2006/07/11 WORKING DRAFT J3/06-007 The output list in an INQUIRE statement shall not contain any derived-type list items that require 1 a user-defined derived-type input/output procedure as described in subclause 9.5.2. If a derived-type 2 list item appears in the output list, the value returned for the IOLENGTH= specifier assumes that no 3 user-defined derived-type input/output procedure will be invoked. 4 9.10 Error, end-of-record, and end-of-file conditions 5 The set of input/output error conditions is processor dependent. 6 An end-of-record condition occurs when a nonadvancing input statement attempts to transfer data 7 from a position beyond the end of the current record, unless the file is a stream file and the current 8 record is at the end of the file (an end-of-file condition occurs instead). 9 An end-of-file condition occurs when 10 (1) an endfile record is encountered during the reading of a file connected for sequential access, 11 (2) an attempt is made to read a record beyond the end of an internal file, or 12 (3) an attempt is made to read beyond the end of a stream file. 13 An end-of-file condition may occur at the beginning of execution of an input statement. An end-of-file 14 condition also may occur during execution of a formatted input statement when more than one record 15 is required by the interaction of the input list and the format. An end-of-file condition also may occur 16 during execution of a stream input statement. 17 9.10.1 Error conditions and the ERR= sp ecifier 18 If an error condition occurs during execution of an input/output statement, the position of the file 19 becomes indeterminate. 20 If an error condition occurs during execution of an input/output statement that contains neither an 21 ERR= nor IOSTAT= specifier, execution of the program is terminated. If an error condition occurs 22 during execution of an input/output statement that contains either an ERR= specifier or an IOSTAT= 23 specifier then 24 (1) processing of the input/output list, if any, terminates, 25 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 26 do-variable s in the statement that initiated the transfer become undefined, 27 (3) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 28 defined as specified in 9.10.4, 29 (4) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 30 (5) if the statement is a READ statement and it contains a SIZE= specifier, the scalar-int- 31 variable in the SIZE= specifier becomes defined as specified in 9.5.1.14, 32 (6) if the statement is a READ statement or the error condition occurs in a wait operation for 33 a transfer initiated by a READ statement, all input items or namelist group ob jects in the 34 statement that initiated the transfer become undefined, and 35 (7) if an ERR= specifier appears, execution continues with the statement labeled by the label 36 in the ERR= specifier. 37 9.10.2 End-of-file condition and the END= sp ecifier 38 If an end-of-file condition occurs during execution of an input/output statement that contains neither 39 an END= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of-file 40 condition occurs during execution of an input/output statement that contains either an END= specifier 41 or an IOSTAT= specifier, and an error condition does not occur then 42 255 J3/06-007 WORKING DRAFT 2006/07/11 (1) processing of the input list, if any, terminates, 1 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 2 do-variable s in the statement that initiated the transfer become undefined, 3 (3) if the statement is a READ statement or the end-of-file condition occurs in a wait operation 4 for a transfer initiated by a READ statement, all input list items or namelist group ob jects 5 in the statement that initiated the transfer become undefined, 6 (4) if the file specified in the input statement is an external record file, it is positioned after the 7 endfile record, 8 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 9 defined as specified in 9.10.4, 10 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 11 and 12 (7) if an END= specifier appears, execution continues with the statement labeled by the label 13 in the END= specifier. 14 9.10.3 End-of-record condition and the EOR= sp ecifier 15 If an end-of-record condition occurs during execution of an input/output statement that contains neither 16 an EOR= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of- 17 record condition occurs during execution of an input/output statement that contains either an EOR= 18 specifier or an IOSTAT= specifier, and an error condition does not occur then 19 (1) If the pad mode has the value 20 (a) YES, the record is padded with blanks to satisfy the input list item (9.5.3.4.2) and 21 corresponding data edit descriptor that requires more characters than the record con- 22 tains, 23 (b) NO, the input list item becomes undefined, 24 (2) processing of the input list, if any, terminates, 25 (3) if the statement is a data transfer statement or the error occurs during a wait operation, all 26 do-variable s in the statement that initiated the transfer become undefined, 27 (4) the file specified in the input statement is positioned after the current record, 28 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 29 defined as specified in 9.10.4, 30 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 31 (7) if a SIZE= specifier appears, the scalar-int-variable in the SIZE= specifier becomes defined 32 as specified in (9.5.1.14), and 33 (8) if an EOR= specifier appears, execution continues with the statement labeled by the label 34 in the EOR= specifier. 35 9.10.4 IOSTAT= specifier 36 Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable 37 in the IOSTAT= specifier to become defined with 38 (1) a zero value if neither an error condition, an end-of-file condition, nor an end-of-record 39 condition occurs, 40 (2) the processor-dependent positive integer value of the constant IOSTAT INQUIRE INTERNAL - 41 UNIT from the ISO FORTRAN ENV intrinsic module (13.8.3) if a unit number in an IN- 42 QUIRE statement identifies an internal file, 43 (3) a processor-dependent positive integer value different from IOSTAT INQUIRE INTERNAL - 44 UNIT if any other error condition occurs, 45 256 2006/07/11 WORKING DRAFT J3/06-007 (4) the processor-dependent negative integer value of the constant IOSTAT END (13.8.3.10) if 1 an end-of-file condition occurs and no error condition occurs, or 2 (5) the processor-dependent negative integer value of the constant IOSTAT EOR (13.8.3.11) if 3 an end-of-record condition occurs and no error condition or end-of-file condition occurs. 4 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= sp ecifier 5 If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, 6 the processor shall assign an explanatory message to iomsg-variable . If no such condition occurs, the 7 processor shall not change the value of iomsg-variable . 8 9.11 Restrictions on input/output statements 9 If a unit, or a file connected to a unit, does not have all of the properties required for the execution of 10 certain input/output statements, those statements shall not refer to the unit. 11 An input/output statement that is executed while another input/output statement is being executed is 12 called a recursive input/output statement. 13 A recursive input/output statement shall not identify an external unit that is identified by another 14 input/output statement being executed except that a child data transfer statement may identify its 15 parent data transfer statement external unit. 16 An input/output statement shall not cause the value of any established format specification to be 17 modified. 18 A recursive input/output statement shall not modify the value of any internal unit except that a recursive 19 WRITE statement may modify the internal unit identified by that recursive WRITE statement. 20 The value of a specifier in an input/output statement shall not depend on any input-item , io-implied- 21 do do-variable , or on the definition or evaluation of any other specifier in the io-control-spec -list or 22 inquire-spec -list in that statement. 23 The value of any subscript or substring bound of a variable that appears in a specifier in an input/output 24 statement shall not depend on any input-item , io-implied-do do-variable , or on the definition or evalua- 25 tion of any other specifier in the io-control-spec -list or inquire-spec -list in that statement. 26 In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if 27 any, shall not be associated with any entity in the data transfer input/output list (9.5.2) or namelist- 28 group-object -list, nor with a do-variable of an io-implied-do in the data transfer input/output list. 29 257 J3/06-007 WORKING DRAFT 2006/07/11 In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an 1 array element reference, its subscript values shall not be affected by the data transfer, the io-implied-do 2 processing, or the definition or evaluation of any other specifier in the io-control-spec -list. 3 A variable that may become defined or undefined as a result of its use in a specifier in an INQUIRE 4 statement, or any associated entity, shall not appear in another specifier in the same INQUIRE statement. 5 A STOP statement shall not be executed during execution of an input/output statement. 6 NOTE 9.69 Restrictions on the evaluation of expressions (7.1.8) prohibit certain side effects. 258 2006/07/11 WORKING DRAFT J3/06-007 10 Input/output editing 1 10.1 Format sp ecifications 2 A format used in conjunction with an input/output statement provides information that directs the 3 editing between the internal representation of data and the characters of a sequence of formatted records. 4 A FMT= specifier (9.5.1.1) in an input/output statement may refer to a FORMAT statement or to a 5 character expression that contains a format specification. A format specification provides explicit editing 6 information. The FMT= specifier alternatively may be an asterisk (*), which indicates list-directed 7 formatting (10.10). Namelist formatting (10.11) may be indicated by specifying a namelist-group-name 8 instead of a format . 9 10.2 Explicit format specification methods 10 10.2.1 FORMAT statement 11 R1001 format-stmt is FORMAT format-specification 12 R1002 format-specification is ( [ format-item -list ] ) 13 or ( [ format-item -list, ] unlimited-format-item ) 14 C1001 (R1001) The format-stmt shall be labeled. 15 C1002 (R1002) The comma used to separate format-item s in a format-item -list may be omitted 16 (1) between a P edit descriptor and an immediately following F, E, EN, ES, D, or G edit 17 descriptor (10.8.5), possibly preceded by a repeat specifier, 18 (2) before a slash edit descriptor when the optional repeat specification is not present (10.8.2), 19 (3) after a slash edit descriptor, or 20 (4) before or after a colon edit descriptor (10.8.3) 21 Blank characters may precede the initial left parenthesis of the format specification. Additional blank 22 characters may appear at any point within the format specification, with no effect on the interpretation 23 of the format specification, except within a character string edit descriptor (10.9). 24 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 25 A character expression used as a format in a formatted input/output statement shall evaluate to a 26 character string whose leading part is a valid format specification. 27 NOTE 10.2 The format specification begins with a left parenthesis and ends with a right parenthesis. 259 J3/06-007 WORKING DRAFT 2006/07/11 All character positions up to and including the final right parenthesis of the format specification shall be 1 defined at the time the input/output statement is executed, and shall not become redefined or undefined 2 during the execution of the statement. Character positions, if any, following the right parenthesis that 3 ends the format specification need not be defined and may contain any character data with no effect on 4 the interpretation of the format specification. 5 If the format is a character array, it is treated as if all of the elements of the array were specified in array 6 element order and were concatenated. However, if a format is a character array element, the format 7 specification shall be entirely within that array element. 8 NOTE 10.3 If a character constant is used as a format in an input/output statement, care shall be taken that the value of the character constant is a valid format specification. In particular, if a format specification delimited by apostrophes contains a character constant edit descriptor delimited with apostrophes, two apostrophes shall be written to delimit the edit descriptor and four apostrophes shall be written for each apostrophe that occurs within the edit descriptor. For example, the text: 2 ISN'T 3 may be written by various combinations of output statements and format specifications: WRITE (6, 100) 2, 3 100 FORMAT (1X, I1, 1X, 'ISN''T', 1X, I1) WRITE (6, '(1X, I1, 1X, ''ISN''''T'', 1X, I1)') 2, 3 WRITE (6, '(A)') ' 2 ISN''T 3' Doubling of internal apostrophes usually can be avoided by using quotation marks to delimit the format specification and doubling of internal quotation marks usually can be avoided by using apostrophes as delimiters. 10.3 Form of a format item list 9 10.3.1 Syntax 10 R1003 format-item is [ r ] data-edit-desc 11 or control-edit-desc 12 or char-string-edit-desc 13 or [ r ] ( format-item -list ) 14 R1004 unlimited-format-item is * ( format-item -list ) 15 R1005 r is int-literal-constant 16 C1003 (R1005) r shall be positive. 17 C1004 (R1005) r shall not have a kind parameter specified for it. 18 The integer literal constant r is called a rep eat sp ecification. 19 10.3.2 Edit descriptors 20 An edit descriptor is a data edit descriptor, a control edit descriptor, or a character string 21 edit descriptor. 22 R1006 data-edit-desc is I w [ . m ] 23 or B w [ . m ] 24 260 2006/07/11 WORKING DRAFT J3/06-007 or Ow [. m] 1 or Zw [. m] 2 or Fw . d 3 or Ew . d [Ee] 4 or EN w . d [ E e ] 5 or ES w . d [ E e ] 6 or Gw [. d [Ee]] 7 or Lw 8 or A[w ] 9 or Dw . d 10 or DT [ char-literal-constant ] [ ( v -list ) ] 11 R1007 w is int-literal-constant 12 R1008 m is int-literal-constant 13 R1009 d is int-literal-constant 14 R1010 e is int-literal-constant 15 R1011 v is signed-int-literal-constant 16 C1005 (R1010) e shall be positive. 17 C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be 18 positive for all other edit descriptors. 19 C1007 (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. 20 C1008 (R1006) w , m , d , e , and v shall not have kind parameters specified for them. 21 C1009 (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter 22 specified for it. 23 I, B, O, Z, F, E, EN, ES, G, L, A, D, and DT indicate the manner of editing. 24 R1012 control-edit-desc is position-edit-desc 25 or [r ]/ 26 or : 27 or sign-edit-desc 28 or kP 29 or blank-interp-edit-desc 30 or round-edit-desc 31 or decimal-edit-desc 32 R1013 k is signed-int-literal-constant 33 C1010 (R1013) k shall not have a kind parameter specified for it. 34 In k P, k is called the scale factor. 35 R1014 position-edit-desc is Tn 36 or TL n 37 or TR n 38 or nX 39 R1015 n is int-literal-constant 40 C1011 (R1015) n shall be positive. 41 C1012 (R1015) n shall not have a kind parameter specified for it. 42 R1016 sign-edit-desc is SS 43 or SP 44 261 J3/06-007 WORKING DRAFT 2006/07/11 or S 1 R1017 blank-interp-edit-desc is BN 2 or BZ 3 R1018 round-edit-desc is RU 4 or RD 5 or RZ 6 or RN 7 or RC 8 or RP 9 R1019 decimal-edit-desc is DC 10 or DP 11 T, TL, TR, X, slash, colon, SS, SP, S, P, BN, BZ, RU, RD, RZ, RN, RC, RP, DC, and DP indicate the 12 manner of editing. 13 R1020 char-string-edit-desc is char-literal-constant 14 C1013 (R1020) The char-literal-constant shall not have a kind parameter specified for it. 15 Each rep-char in a character string edit descriptor shall be one of the characters capable of representation 16 by the processor. 17 The character string edit descriptors provide constant data to be output, and are not valid for input. 18 The edit descriptors are without regard to case except for the characters in the character constants. 19 10.3.3 Fields 20 A field is a part of a record that is read on input or written on output when format control encounters 21 a data edit descriptor or a character string edit descriptor. The field width is the size in characters of 22 the field. 23 10.4 Interaction b etween input/output list and format 24 The start of formatted data transfer using a format specification initiates format control (9.5.3.4.2). 25 Each action of format control depends on information jointly provided by the next edit descriptor in the 26 format specification and the next effective item in the input/output list, if one exists. 27 If an input/output list specifies at least one effective list item, at least one data edit descriptor shall 28 exist in the format specification. 29 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.3.4). Zero length character items are effective list items, but zero sized arrays and implied DO lists with an iteration count of zero are not. A format specification is interpreted from left to right. The exceptions are format items preceded by a 30 repeat specification r , and format reversion (described below). 31 A format item preceded by a repeat specification is processed as a list of r items, each identical to the 32 format item but without the repeat specification and separated by commas. 33 262 2006/07/11 WORKING DRAFT J3/06-007 NOTE 10.5 An omitted repeat specification is treated in the same way as a repeat specification whose value is one. To each data edit descriptor interpreted in a format specification, there corresponds one effective item 1 specified by the input/output list (9.5.2), except that an input/output list item of type complex requires 2 the interpretation of two F, E, EN, ES, D, or G edit descriptors. For each control edit descriptor or 3 character edit descriptor, there is no corresponding item specified by the input/output list, and format 4 control communicates information directly with the record. 5 Whenever format control encounters a data edit descriptor in a format specification, it determines 6 whether there is a corresponding effective item specified by the input/output list. If there is such an 7 item, it transmits appropriately edited information between the item and the record, and then format 8 control proceeds. If there is no such item, format control terminates. 9 If format control encounters a colon edit descriptor in a format specification and another effective in- 10 put/output list item is not specified, format control terminates. 11 If format control encounters the rightmost parenthesis of a complete format specification and another 12 effective input/output list item is not specified, format control terminates. However, if another effective 13 input/output list item is specified, format control then reverts to the beginning of the format item 14 terminated by the last preceding right parenthesis that is not part of a DT edit descriptor. If there 15 is no such preceding right parenthesis, format control reverts to the first left parenthesis of the format 16 specification. If any reversion occurs, the reused portion of the format specification shall contain at 17 least one data edit descriptor. If format control reverts to a parenthesis that is preceded by a repeat 18 specification, the repeat specification is reused. Reversion of format control, of itself, has no effect on 19 the changeable modes (9.4.1). If format control reverts to a parenthesis that is not the beginning of an 20 unlimited-format-item , the file is positioned in a manner identical to the way it is positioned when a 21 slash edit descriptor is processed (10.8.2). 22 NOTE 10.6 Example: The format specification: 10 FORMAT (1X, 2(F10.3, I5)) with an output list of WRITE (10,10) 10.1, 3, 4.7, 1, 12.4, 5, 5.2, 6 produces the same output as the format specification: 10 FORMAT (1X, F10.3, I5, F10.3, I5/F10.3, I5, F10.3, I5) NOTE 10.7 The effect of an unlimited-format-item is as if its enclosed list were preceded by a very large repeat count. There is no file positioning implied by unlimited-format-item reversion. This may be used to write what is commonly called a comma separated value record. For example, WRITE( 10, '( "IARRAY =", *( I0, :, ","))') IARRAY produces a single record with a header and a comma separated list of integer values. 263 J3/06-007 WORKING DRAFT 2006/07/11 10.5 Positioning by format control 1 After each data edit descriptor or character string edit descriptor is processed, the file is positioned after 2 the last character read or written in the current record. 3 After each T, TL, TR, or X edit descriptor is processed, the file is positioned as described in 10.8.1. 4 After each slash edit descriptor is processed, the file is positioned as described in 10.8.2. 5 During formatted stream output, processing of an A edit descriptor may cause file positioning to occur 6 (10.7.4). 7 If format control reverts as described in 10.4, the file is positioned in a manner identical to the way it is 8 positioned when a slash edit descriptor is processed (10.8.2). 9 During a read operation, any unprocessed characters of the current record are skipped whenever the 10 next record is read. 11 10.6 Decimal symbol 12 The decimal symb ol is the character that separates the whole and fractional parts in the decimal 13 representation of a real number in an internal or external file. When the decimal edit mode is POINT, 14 the decimal symbol is a decimal point. When the decimal edit mode is COMMA, the decimal symbol is 15 a comma. 16 10.7 Data edit descriptors 17 10.7.1 General 18 Data edit descriptors cause the conversion of data to or from its internal representation; during formatted 19 stream output, the A data edit descriptor may also cause file positioning. On input, the specified variable 20 becomes defined unless an error condition, an end-of-file condition, or an end-of-record condition occurs. 21 On output, the specified expression is evaluated. 22 During input from a Unicode file, 23 (1) characters in the record that correspond to an ASCII character variable shall have a position 24 in the ISO 10646 character type collating sequence of 127 or less, and 25 (2) characters in the record that correspond to a default character variable shall be representable 26 in the default character type. 27 During input from a non-Unicode file, 28 (1) characters in the record that correspond to a character variable shall have the kind of the 29 character variable, and 30 (2) characters in the record that correspond to a numeric logical, or bits variable shall be of 31 default character type. 32 During output to a Unicode file, all characters transmitted to the record are of ISO 10646 character 33 type. If a character input/output list item or character string edit descriptor contains a character that 34 is not representable in the ISO 10646 character type, the result is processor-dependent. 35 During output to a non-Unicode file, characters transmitted to the record as a result of processing a 36 character string edit descriptor or as a result of evaluating a numeric, logical, bits, or default character 37 data entity, are of type default character. 38 264 2006/07/11 WORKING DRAFT J3/06-007 10.7.2 Numeric and bits editing 1 10.7.2.1 General rules 2 The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify the input/output of 3 integer, real, complex, and bits data. The following general rules apply. 4 (1) On input, leading blanks are not significant. When the input field is not an IEEE excep- 5 tional specification (10.7.2.3.2), the interpretation of blanks, other than leading blanks, is 6 determined by the blank interpretation mode (10.8.6). Plus signs may be omitted. A field 7 containing only blanks is considered to be zero. 8 (2) On input, with F, E, EN, ES, D, and G editing, a decimal symbol appearing in the input 9 field overrides the portion of an edit descriptor that specifies the decimal symbol location. 10 The input field may have more digits than the processor uses to approximate the value of 11 the datum. 12 (3) On output with I, F, E, EN, ES, D, and G editing, the representation of a positive or zero 13 internal value in the field may be prefixed with a plus sign, as controlled by the S, SP, and 14 SS edit descriptors or the processor. The representation of a negative internal value in the 15 field shall be prefixed with a minus sign. 16 (4) On output, the representation is right justified in the field. If the number of characters 17 produced by the editing is smaller than the field width, leading blanks are inserted in the 18 field. 19 (5) On output, if the number of characters produced exceeds the field width or if an exponent 20 exceeds its specified length using the Ew.d Ee, ENw.d Ee, ESw.d Ee, or Gw.d Ee edit 21 descriptor, the processor shall fill the entire field of width w with asterisks. However, 22 the processor shall not produce asterisks if the field width is not exceeded when optional 23 characters are omitted. 24 NOTE 10.8 When an SP edit descriptor is in effect, a plus sign is not optional. (6) On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may 25 be zero. In such cases, the processor selects the smallest positive actual field width that 26 does not result in a field filled with asterisks. The specified value of w shall not be zero on 27 input. 28 10.7.2.2 Integer editing 29 The Iw and Iw.m, edit descriptors indicate that the field to be edited occupies w positions, except when 30 w is zero. When w is zero, the processor selects the field width. On input, w shall not be zero. The 31 specified input/output list item shall be of type integer or bits. The G, B, O, and Z edit descriptor also 32 may be used to edit integer data (10.7.5.2.1, 10.7.2.4). 33 If the input list item is of type bits, the input field is edited as if the input list item were of type integer 34 and bits compatible with the actual list item, followed by the effect of an intrinsic assignment of the 35 resulting integer value to the actual list item. 36 265 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note (cont.) J3 internal note Unresolved Technical Issue 45 This is misplaced and/or misguided. The type and kind of the input item do not affect input editing (read through the existing subclause - nowhere does this even mention the type or more pertinantly kind of the input item). Nor does input editing define the list item, that is "data transfer" (04-007: 9.5.3.4 and in particular 9.5.3.4.2). Worse, one of the bits paper's own edits makes a change to how input editing is done (!) depending on the type of the list item, but the "as if " rule above means that is ineffective. J3 internal note Unresolved Technical Issue 46 This proposal appears to be requiring unsigned integers by the back door. However, since we don't actually have unsigned integers it does not work. Consider, for example, an 8-bit bits variable, reading the value "130". According to the above, this is equivalent to reading it into a one-byte integer - but that is not valid, 130 not being in the set of values. So it may fail. J3 internal note Unresolved Technical Issue 47 This feature is unusable by the normal user. If he has a bits variable of KIND==7, what is the effect? It is all very well saying "as if" there was an integer variable of the right kind, but that kind is not guaranteed to exist and might well not exist. On input, m has no effect. 1 In the input field for the I edit descriptor, the character string shall be a signed-digit-string (R409) if 2 the list item is of type integer and a digit-string (R410) if it is of type bits, except for the interpretation 3 of blanks. 4 The output field for the Iw edit descriptor consists of zero or more leading blanks followed by a minus 5 sign if the internal value is negative, or an optional plus sign otherwise, followed by the magnitude of 6 the internal value as a digit-string without leading zeros. 7 NOTE 10.9 A digit-string always consists of at least one digit. The output field for the Iw.m edit descriptor is the same as for the Iw edit descriptor, except that the 8 digit-string consists of at least m digits. If necessary, sufficient leading zeros are included to achieve the 9 minimum of m digits. The value of m shall not exceed the value of w , except when w is zero. If m is 10 zero and the internal value is zero, the output field consists of only blank characters, regardless of the 11 sign control in effect. When m and w are both zero, and the internal value is zero, one blank character 12 is produced. 13 10.7.2.3 Real and complex editing 14 10.7.2.3.1 General 15 The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output 16 list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G, B, O, 17 and Z edit descriptors also may be used to edit real and complex data (10.7.5.2.2). 18 A lower-case letter is equivalent to the corresponding upper-case letter in an IEEE exceptional specifi- 19 266 2006/07/11 WORKING DRAFT J3/06-007 cation or the exponent in a numeric input field. 1 10.7.2.3.2 F editing 2 The Fw.d edit descriptor indicates that the field occupies w positions, the fractional part of which 3 consists of d digits. When w is zero, the processor selects the field width. On input, w shall not be zero. 4 The input field is either an IEEE exceptional specification or consists of an optional sign, followed by a 5 string of one or more digits optionally containing a decimal symbol, including any blanks interpreted as 6 zeros. The d has no effect on input if the input field contains a decimal symbol. If the decimal symbol 7 is omitted, the rightmost d digits of the string, with leading zeros assumed if necessary, are interpreted 8 as the fractional part of the value represented. The string of digits may contain more digits than a 9 processor uses to approximate the value. The basic form may be followed by an exponent of one of the 10 following forms: 11 (1) a sign followed by a digit-string ; 12 (2) the letter E followed by zero or more blanks, followed by a signed-digit-string ; 13 (3) the letter D followed by zero or more blanks, followed by a signed-digit-string . 14 An exponent containing a D is processed identically to an exponent containing an E. 15 NOTE 10.10 If the input field does not contain an exponent, the effect is as if the basic form were followed by an exponent with a value of -k , where k is the established scale factor (10.8.5). An input field that is an IEEE exceptional specification consists of optional blanks, followed by either 16 (1) an optional sign, followed by the string 'INF' or the string 'INFINITY', or 17 (2) an optional sign, followed by the string 'NAN', optionally followed by zero or more alphanu- 18 meric characters enclosed in parentheses, 19 optionally followed by blanks. 20 The value specified by form (1) is an IEEE infinity; this form shall not be used if the processor does 21 not support IEEE infinities for the input variable. The value specified by form (2) is an IEEE NaN; 22 this form shall not be used if the processor does not support IEEE NaNs for the input variable. The 23 NaN value is a quiet NaN if the only nonblank characters in the field are 'NAN' or 'NAN()'; otherwise, 24 the NaN value is processor-dependent. The interpretation of a sign in a NaN input field is processor 25 dependent. 26 For an internal value that is an IEEE infinity, the output field consists of blanks, if necessary, followed 27 by a minus sign for negative infinity or an optional plus sign otherwise, followed by the letters 'Inf ' or 28 'Infinity', right justified within the field. If w is less than 3, the field is filled with asterisks; otherwise, 29 if w is less than 8, 'Inf ' is produced. 30 For an internal value that is an IEEE NaN, the output field consists of blanks, if necessary, followed by 31 the letters 'NaN' and optionally followed by one to w - 5 alphanumeric processor-dependent characters 32 enclosed in parentheses, right justified within the field. If w is less than 3, the field is filled with asterisks. 33 NOTE 10.11 The processor-dependent characters following 'NaN' may convey additional information about that particular NaN. For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if 34 necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, 35 267 J3/06-007 WORKING DRAFT 2006/07/11 followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal 1 value, as modified by the established scale factor and rounded to d fractional digits. Leading zeros are 2 not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude 3 of the value in the output field is less than one. The optional zero shall appear if there would otherwise 4 be no digits in the output field. 5 10.7.2.3.3 E and D editing 6 The Ew.d, Dw.d, and Ew.d Ee edit descriptors indicate that the external field occupies w positions, the 7 fractional part of which consists of d digits, unless a scale factor greater than one is in effect, and the 8 exponent part consists of e digits. The e has no effect on input. 9 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 10 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 11 Fw.d. 12 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field for a scale 13 factor of zero is: 14 [ ± ] [0].x1 x2 . . . xd exp 15 where: 16 ± signifies a plus sign or a minus sign. 17 . signifies a decimal symbol (10.6). 18 x1 x2 . . . xd are the d most significant digits of the internal value after rounding. 19 exp is a decimal exponent having one of the following forms: 20 Edit Absolute Value Form of Descriptor of Exponent Exponent |exp| 99 E±z1 z2 or ±0z1 z2 Ew.d 99 < |exp| 999 ±z1 z2 z3 |exp| 10e - 1 E±z1 z2 . . . ze Ew.d Ee |exp| 99 D±z1 z2 or E±z1 z2 Dw.d or ±0z1 z2 99 < |exp| 999 ±z1 z2 z3 where each z is a digit. 21 The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 22 descriptor forms Ew.d and Dw.d shall not be used if |exp| > 999. 23 The scale factor k controls the decimal normalization (10.3.2, 10.8.5). If -d < k 0, the output field 24 contains exactly |k | leading zeros and d - |k | significant digits after the decimal symbol. If 0 < k < d + 2, 25 the output field contains exactly k significant digits to the left of the decimal symbol and d - k + 1 26 significant digits to the right of the decimal symbol. Other values of k are not permitted. 27 10.7.2.3.4 EN editing 28 The EN edit descriptor produces an output field in the form of a real number in engineering notation 29 such that the decimal exponent is divisible by three and the absolute value of the significand (R414) is 30 greater than or equal to 1 and less than 1000, except when the output value is zero. The scale factor 31 has no effect on output. 32 The forms of the edit descriptor are ENw.d and ENw.d Ee indicating that the external field occupies w 33 268 2006/07/11 WORKING DRAFT J3/06-007 positions, the fractional part of which consists of d digits and the exponent part consists of e digits. 1 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 2 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 3 Fw.d. 4 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is: 5 [ ± ] yyy . x1 x2 . . . xd exp 6 where: 7 ± signifies a plus sign or a minus sign. 8 yyy are the 1 to 3 decimal digits representative of the most significant digits of the internal 9 value after rounding (yyy is an integer such that 1 y y y < 1000 or, if the output value is 10 zero, y y y = 0). 11 . signifies a decimal symbol (10.6). 12 x1 x2 . . . xd are the d next most significant digits of the internal value after rounding. 13 exp is a decimal exponent, divisible by three, of one of the following forms: 14 Edit Absolute Value Form of Descriptor of Exponent Exponent |exp| 99 E±z1 z2 or ±0z1 z2 ENw.d 99 < |exp| 999 ±z1 z2 z3 |exp| 10e - 1 E±z1 z2 . . . ze ENw.d Ee where each z is a digit. 15 The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 16 descriptor form ENw.d shall not be used if |exp| > 999. 17 NOTE 10.12 Examples: Internal Value Output field Using SS, EN12.3 6.421 6.421E+00 -.5 -500.000E-03 .00217 2.170E-03 4721.3 4.721E+03 10.7.2.3.5 ES editing 18 The ES edit descriptor produces an output field in the form of a real number in scientific notation such 19 that the absolute value of the significand (R414) is greater than or equal to 1 and less than 10, except 20 when the output value is zero. The scale factor has no effect on output. 21 The forms of the edit descriptor are ESw.d and ESw.d Ee indicating that the external field occupies w 22 positions, the fractional part of which consists of d digits and the exponent part consists of e digits. 23 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 24 For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 25 Fw.d. 26 For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is: 27 269 J3/06-007 WORKING DRAFT 2006/07/11 [ ± ] y . x1 x2 . . . xd exp 1 where: 2 ± signifies a plus sign or a minus sign. 3 y is a decimal digit representative of the most significant digit of the internal value after 4 rounding. 5 . signifies a decimal symbol (10.6). 6 x1 x2 . . . xd are the d next most significant digits of the internal value after rounding. 7 exp is a decimal exponent having one of the following forms: 8 Edit Absolute Value Form of Descriptor of Exponent Exponent |exp| 99 E±z1 z2 or ±0z1 z2 ESw.d 99 < |exp| 999 ±z1 z2 z3 |exp| 10e - 1 E±z1 z2 . . . ze ESw.d Ee where each z is a digit. 9 The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit 10 descriptor form ESw.d shall not be used if |exp | > 999. 11 NOTE 10.13 Examples: Internal Value Output field Using SS, ES12.3 6.421 6.421E+00 -.5 -5.000E-01 .00217 2.170E-03 4721.3 4.721E+03 10.7.2.3.6 Complex editing 12 A complex datum consists of a pair of separate real data. The editing of a scalar datum of complex type 13 is specified by two edit descriptors each of which specifies the editing of real data. The first of the edit 14 descriptors specifies the real part; the second specifies the imaginary part. The two edit descriptors may 15 be different. Control and character string edit descriptors may be processed between the edit descriptor 16 for the real part and the edit descriptor for the imaginary part. 17 10.7.2.3.7 Rounding mo de 18 The rounding mode can be specified by an OPEN statement (9.4.1), a data transfer input/output 19 statement (9.5.1.12), or an edit descriptor (10.8.7). 20 In what follows, the term "decimal value" means the exact decimal number as given by the character 21 string, while the term "internal value" means the number actually stored (typically in binary form) in 22 the processor. For example, in dealing with the decimal constant 0.1, the decimal value is the exact 23 mathematical quantity 1/10, which has no exact representation on most processors. Formatted output 24 of real data involves conversion from an internal value to a decimal value; formatted input involves 25 conversion from a decimal value to an internal value. 26 When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest repre- 27 sentable value that is greater than or equal to the original value. When the I/O rounding mode is 28 DOWN, the value resulting from conversion shall be the largest representable value that is less than or 29 270 2006/07/11 WORKING DRAFT J3/06-007 equal to the original value. When the I/O rounding mode is ZERO, the value resulting from conversion 1 shall be the value closest to the original value and no greater in magnitude than the original value. When 2 the I/O rounding mode is NEAREST, the value resulting from conversion shall be the closer of the two 3 nearest representable values if one is closer than the other. If the two nearest representable values are 4 equidistant from the original value, it is processor dependent which one of them is chosen. When the 5 I/O rounding mode is COMPATIBLE, the value resulting from conversion shall be the closer of the 6 two nearest representable values or the value away from zero if halfway between them. When the I/O 7 rounding mode is PROCESSOR DEFINED, rounding during conversion shall be a processor dependent 8 default mode, which may correspond to one of the other modes. 9 On processors that support IEEE rounding on conversions, NEAREST shall correspond to round to 10 nearest, as specified in the IEEE International Standard. 11 NOTE 10.14 On processors that support IEEE rounding on conversions, the I/O rounding modes COMPATI- BLE and NEAREST will produce the same results except when the datum is halfway between the two representable values. In that case, NEAREST will pick the even value, but COMPATIBLE will pick the value away from zero. The I/O rounding modes UP, DOWN, and ZERO have the same effect as those specified in the IEEE International Standard for round toward +, round toward -, and round toward 0, respectively. 10.7.2.4 Bits editing 12 The Bw , Bw .m , Ow , Ow .m , Zw , and Zw.m edit descriptors indicate that the field to be edited occupies 13 w positions, except when w is zero. When w is zero, the processor selects the field width. On input, 14 w shall not be zero. The input/output list item shall be of type bits, integer, real, complex, or logical. 15 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. 16 If the input list item is not of type bits, the input field is edited as if the input list item were of type 17 bits and bits compatible with the actual list item. 18 On input, m has no effect. 19 In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, 20 or hexadecimal digits (as in R426, R427, R428) in the respective input field. The lower-case hexadecimal 21 digits a through f in a hexadecimal input field are equivalent to the corresponding upper-case hexadecimal 22 digits. 23 If the output list item is not of type bits, it is first converted to a list item of type bits that is bits 24 compatible with it. 25 If the output list item, x, is not of type bits, it is interpreted as if it were of type bits with the value 26 BITS(x ). 27 The output field for the Bw , Ow , and Zw descriptors consists of zero or more leading blanks followed by 28 the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, 29 with the same value and without leading zeros. 30 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 ] ... 31 The output field for the Bw.m, Ow.m, and Zw.m edit descriptor is the same as for the Bw , Ow , and Zw 32 edit descriptor, except that the digit-string or hex-digit-string consists of at least m digits. If necessary, 33 271 J3/06-007 WORKING DRAFT 2006/07/11 sufficient leading zeros are included to achieve the minimum of m digits. The value of m shall not exceed 1 the value of w , except when w is zero. If m is zero and the internal value consists of all zero bits, the 2 output field consists of only blank characters. When m and w are both zero, and the internal value 3 consists of all zero bits, one blank character is produced. 4 10.7.3 Logical editing 5 The Lw edit descriptor indicates that the field occupies w positions. The specified input/output list 6 item shall be of type logical. The G edit descriptor also may be used to edit logical data (10.7.5.4). 7 The input field consists of optional blanks, optionally followed by a period, followed by a T for true or 8 F for false. The T or F may be followed by additional characters in the field, which are ignored. 9 A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field. 10 NOTE 10.16 The logical constants .TRUE. and .FALSE. are acceptable input forms. The output field consists of w - 1 blanks followed by a T or F, depending on whether the internal value 11 is true or false, respectively. 12 10.7.4 Character editing 13 The A[w ] edit descriptor is used with an input/output list item of type character. The G edit descriptor 14 also may be used to edit character data (10.7.5.5). The kind type parameter of all characters transferred 15 and converted under control of one A or G edit descriptor is implied by the kind of the corresponding 16 list item. 17 If a field width w is specified with the A edit descriptor, the field consists of w characters. If a field 18 width w is not specified with the A edit descriptor, the number of characters in the field is the length of 19 the corresponding list item, regardless of the value of the kind type parameter. 20 Let len be the length of the input/output list item. If the specified field width w for an A edit descriptor 21 corresponding to an input item is greater than or equal to len, the rightmost len characters will be taken 22 from the input field. If the specified field width w is less than len, the w characters will appear left 23 justified with len -w trailing blanks in the internal value. 24 If the specified field width w for an A edit descriptor corresponding to an output item is greater than 25 len, the output field will consist of w - len blanks followed by the len characters from the internal value. 26 If the specified field width w is less than or equal to len, the output field will consist of the leftmost w 27 characters from the internal value. 28 NOTE 10.17 For nondefault character types, the blank padding character is processor dependent. If the file is connected for stream access, the output may be split across more than one record if it 29 contains newline characters. A newline character is a nonblank character returned by the intrinsic 30 function NEW LINE. Beginning with the first character of the output field, each character that is not 31 a newline is written to the current record in successive positions; each newline character causes file 32 positioning at that point as if by slash editing (the current record is terminated at that point, a new 33 empty record is created following the current record, this new record becomes the last and current record 34 of the file, and the file is positioned at the beginning of this new record). 35 272 2006/07/11 WORKING DRAFT J3/06-007 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 1 10.7.5.1 Overview 2 The Gw , Gw.d and Gw.d Ee edit descriptors are used with an input/output list item of any intrinsic 3 type. When w is nonzero, these edit descriptors indicate that the external field occupies w positions, 4 the fractional part of which consists of a maximum of d digits and the exponent part consists of e digits. 5 When these edit descriptors are used to specify the input/output of integer, logical, bits, or character 6 data, d and e have no effect. When w is zero the processor selects the field width. On input, w shall 7 not be zero." 8 10.7.5.2 Generalized numeric editing 9 When used to specify the input/output of integer, real, and complex data, the Gw , Gw.d and Gw.d Ee 10 edit descriptors follow the general rules for numeric editing (10.7.2). 11 NOTE 10.19 The Gw.d Ee edit descriptor follows any additional rules for the Ew.d Ee edit descriptor. 10.7.5.2.1 Generalized integer editing 12 When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow 13 the rules for the Iw edit descriptor (10.7.2.2), except that w shall not be zero. When used to specify the 14 output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor. 15 10.7.5.2.2 Generalized real and complex editing 16 The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 17 When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for 18 the ESw.d Ee edit descriptor. Reasonable processor-dependent values of w , d , and e are used with each 19 output value. 20 For an internal value that is an IEEE infinity or NaN, the form of the output field for the Gw.d and 21 Gw.d Ee edit descriptors is the same as for Fw.d. 22 Otherwise, the method of representation in the output field depends on the magnitude of the internal 23 value being edited. Let N be the magnitude of the internal value and r be the rounding mode value 24 defined in the table below. If 0 < N < 0.1 - r × 10-d-1 or N 10d - r, or N is identically 0 and 25 d is 0, Gw.d output editing is the same as k PEw.d output editing and Gw.d Ee output editing is 26 the same as k PEw.d Ee output editing, where k is the scale factor (10.8.5) currently in effect. If 27 0.1 - r × 10-d-1 N < 10d - r or N is identically 0 and d is not zero, the scale factor has no effect, 28 and the value of N determines the editing as follows: 29 Magnitude of Internal Value Equivalent Conversion F(w - n).(d - 1), n('b') N =0 0.1 - r × 10-d-1 N < 1 - r × 10-d F(w - n).d, n('b') 1 - r × 10-d N < 10 - r × 10-d+1 F(w - n).(d - 1), n('b') 10 - r × 10-d+1 N < 100 - r × 10-d+2 F(w - n).(d - 2), n('b') 273 J3/06-007 WORKING DRAFT 2006/07/11 Magnitude of Internal Value Equivalent Conversion · · · · · · 10d-2 - r × 10-2 N < 10d-1 - r × 10-1 F(w - n).1, n('b') 10d-1 - r × 10-1 N < 10d - r F(w - n).0, n('b') where b is a blank, n is 4 for Gw.d and e + 2 for Gw.d Ee, and r is defined for each rounding mode as 1 follows: 2 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 1 if internal value is negative ZERO 0 if internal value is positive The value of w - n shall be positive 3 NOTE 10.20 The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range that permits effective use of F editing. 10.7.5.3 Generalized bits editing 4 When used to specify the input/output of bits data, the Gw.d and Gw.d Ee edit descriptors follow the 5 rules for the Zw edit descriptor (10.7.2.4), except that w shall not be zero. When used to specify the 6 output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor. 7 10.7.5.4 Generalized logical editing 8 When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors follow 9 the rules for the Lw edit descriptor (10.7.3). When used to specify the output of logical data, the G0 10 edit descriptor follows the rules for the L1 edit descriptor. 11 10.7.5.5 Generalized character editing 12 When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors follow 13 the rules for the Aw edit descriptor (10.7.4). When used to specify the output of character data, the G0 14 edit descriptor follows the rules for the A edit descriptor with no field width. 15 10.7.6 User-defined derived-type editing 16 The DT edit descriptor allows a user-provided procedure to be used instead of the processor's default 17 input/output formatting for processing a list item of derived type. 18 The DT edit descriptor may include a character literal constant. The character value "DT" concatenated 19 with the character literal constant is passed to the user-defined derived-type input/output procedure as 20 the iotype argument (9.5.3.7). The v values of the edit descriptor are passed to the user-defined 21 derived-type input/output procedure as the v list array argument. 22 274 2006/07/11 WORKING DRAFT J3/06-007 NOTE 10.21 For the edit descriptor DT'Link List'(10, 4, 2), iotype is "DTLink List" and v list is (/10, 4, 2/). If a derived-type variable or value corresponds to a DT edit descriptor, there shall be an accessible 1 interface to a corresponding derived-type input/output procedure for that derived type (9.5.3.7). A DT 2 edit descriptor shall not correspond with a list item that is not of a derived type. 3 10.8 Control edit descriptors 4 A control edit descriptor does not cause the transfer of data or the conversion of data to or from internal 5 representation, but may affect the conversions performed by subsequent data edit descriptors. 6 10.8.1 Position editing 7 The T, TL, TR, and X edit descriptors specify the position at which the next character will be transmitted 8 to or from the record. If any character skipped by a T, TL, TR, or X edit descriptor is of type nondefault 9 character, and the unit is an internal file of type default character or an external non-Unicode file, the 10 result of that position editing is processor dependent. 11 The position specified by a T edit descriptor may be in either direction from the current position. On 12 input, this allows portions of a record to be processed more than once, possibly with different editing. 13 The position specified by an X edit descriptor is forward from the current position. On input, a position 14 beyond the last character of the record may be specified if no characters are transmitted from such 15 positions. 16 NOTE 10.22 An n X edit descriptor has the same effect as a TRn edit descriptor. On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to be transmitted and 17 therefore does not by itself affect the length of the record. If characters are transmitted to positions at 18 or after the position specified by a T, TL, TR, or X edit descriptor, positions skipped and not previously 19 filled are filled with blanks. The result is as if the entire record were initially filled with blanks. 20 On output, a character in the record may be replaced. However, a T, TL, TR, or X edit descriptor never 21 directly causes a character already placed in the record to be replaced. Such edit descriptors may result 22 in positioning such that subsequent editing causes a replacement. 23 10.8.1.1 T, TL, and TR editing 24 The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to 25 nonchild data transfer, the left tab limit becomes defined as the character position of the current record 26 or the current position of the stream file. If, during data transfer, the file is positioned to another record, 27 the left tab limit becomes defined as character position one of that record. 28 The Tn edit descriptor indicates that the transmission of the next character to or from a record is to 29 occur at the n th character position of the record, relative to the left tab limit. 30 The TLn edit descriptor indicates that the transmission of the next character to or from the record is 31 to occur at the character position n characters backward from the current position. However, if n is 32 greater than the difference between the current position and the left tab limit, the TLn edit descriptor 33 indicates that the transmission of the next character to or from the record is to occur at the left tab 34 limit. 35 275 J3/06-007 WORKING DRAFT 2006/07/11 The TRn edit descriptor indicates that the transmission of the next character to or from the record is 1 to occur at the character position n characters forward from the current position. 2 NOTE 10.23 The n in a Tn, TLn, or TRn edit descriptor shall be specified and shall be greater than zero. 10.8.1.2 X editing 3 The n X edit descriptor indicates that the transmission of the next character to or from a record is to 4 occur at the position n characters forward from the current position. 5 NOTE 10.24 The n in an n X edit descriptor shall be specified and shall be greater than zero. 10.8.2 Slash editing 6 The slash edit descriptor indicates the end of data transfer to or from the current record. 7 On input from a file connected for sequential or stream access, the remaining portion of the current 8 record is skipped and the file is positioned at the beginning of the next record. This record becomes 9 the current record. On output to a file connected for sequential or stream access, a new empty record 10 is created following the current record; this new record then becomes the last and current record of the 11 file and the file is positioned at the beginning of this new record. 12 For a file connected for direct access, the record number is increased by one and the file is positioned 13 at the beginning of the record that has that record number, if there is such a record, and this record 14 becomes the current record. 15 NOTE 10.25 A record that contains no characters may be written on output. If the file is an internal file or a file connected for direct access, the record is filled with blank characters. An entire record may be skipped on input. The repeat specification is optional in the slash edit descriptor. If it is not specified, the default value is 16 one. 17 10.8.3 Colon editing 18 The colon edit descriptor terminates format control if there are no more effective items in the in- 19 put/output list (9.5.2). The colon edit descriptor has no effect if there are more effective items in the 20 input/output list. 21 10.8.4 SS, SP, and S editing 22 The SS, SP, and S edit descriptors temporarily change (9.4.1) the sign mode (9.4.6.5, 9.5.1.13) for the 23 connection. The edit descriptors SS, SP, and S set the sign mode corresponding to the SIGN= specifier 24 values SUPPRESS, PLUS, and PROCESSOR DEFINED, respectively. 25 The sign mode controls optional plus characters in numeric output fields. When the sign mode is PLUS, 26 the processor shall produce a plus sign in any position that normally contains an optional plus sign. 27 When the sign mode is SUPPRESS, the processor shall not produce a plus sign in such positions. When 28 the sign mode is PROCESSOR DEFINED, the processor has the option of producing a plus sign or not 29 in such positions, sub ject to 10.7.2(5). 30 276 2006/07/11 WORKING DRAFT J3/06-007 The SS, SP, and S edit descriptors affect only I, F, E, EN, ES, D, and G editing during the execution of 1 an output statement. The SS, SP, and S edit descriptors have no effect during the execution of an input 2 statement. 3 10.8.5 P editing 4 The k P edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k . The scale 5 factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities. 6 The scale factor k affects the appropriate editing in the following manner. 7 (1) On input, with F, E, EN, ES, D, and G editing (provided that no exponent exists in the 8 field) and F output editing, the scale factor effect is that the externally represented number 9 equals the internally represented number multiplied by 10k . 10 (2) On input, with F, E, EN, ES, D, and G editing, the scale factor has no effect if there is an 11 exponent in the field. 12 (3) On output, with E and D editing, the significand (R414) part of the quantity to be produced 13 is multiplied by 10k and the exponent is reduced by k . 14 (4) On output, with G editing, the effect of the scale factor is suspended unless the magnitude 15 of the datum to be edited is outside the range that permits the use of F editing. If the use 16 of E editing is required, the scale factor has the same effect as with E output editing. 17 (5) On output, with EN and ES editing, the scale factor has no effect. 18 If UP, DOWN, ZERO, or NEAREST I/O rounding mode is in effect, 19 (1) on input, the scale factor is applied to the external decimal value and then this is converted 20 using the current I/O rounding mode, and 21 (2) on output, the internal value is converted using the current I/O rounding mode and then 22 the scale factor is applied to the converted decimal value. 23 10.8.6 BN and BZ editing 24 The BN and BZ edit descriptors temporarily change (9.4.1) the blank interpretation mode (9.4.5.4, 25 9.5.1.5) for the connection. The edit descriptors BN and BZ set the blank interpretation mode corre- 26 sponding to the BLANK= specifier values NULL and ZERO, respectively. 27 The blank interpretation mode controls the interpretation of nonleading blanks in numeric and bits 28 input fields. Such blank characters are interpreted as zeros when the blank interpretation mode has the 29 value ZERO; they are ignored when the blank interpretation mode has the value NULL. The effect of 30 ignoring blanks is to treat the input field as if blanks had been removed, the remaining portion of the 31 field right justified, and the blanks replaced as leading blanks. However, a field containing only blanks 32 has the value zero. 33 The blank interpretation mode affects only numeric editing, bits editing, generalized numeric editing, 34 and generalized bits editing on input. It has no effect on output. 35 10.8.7 RU, RD, RZ, RN, RC, and RP editing 36 The round edit descriptors temporarily change (9.4.1) the connection's I/O rounding mode (9.4.6.4, 37 9.5.1.12, 10.7.2.3.7). The round edit descriptors RU, RD, RZ, RN, RC, and RP set the I/O rounding 38 mode corresponding to the ROUND= specifier values UP, DOWN, ZERO, NEAREST, COMPATIBLE, 39 and PROCESSOR DEFINED, respectively. The I/O rounding mode affects the conversion of real and 40 complex values in formatted input/output. It affects only D, E, EN, ES, F, and G editing. 41 277 J3/06-007 WORKING DRAFT 2006/07/11 10.8.8 DC and DP editing 1 The decimal edit descriptors temporarily change (9.4.1) the decimal edit mode (9.4.5.5, 9.5.1.6) for the 2 connection. The edit descriptors DC and DP set the decimal edit mode corresponding to the DECIMAL= 3 specifier values COMMA and POINT, respectively. 4 The decimal edit mode controls the representation of the decimal symbol (10.6) during conversion of 5 real and complex values in formatted input/output. The decimal edit mode affects only D, E, EN, ES, 6 F, and G editing. If the mode is COMMA during list-directed input/output, the character used as a 7 value separator is a semicolon in place of a comma. 8 10.9 Character string edit descriptors 9 A character string edit descriptor shall not be used on input. 10 The character string edit descriptor causes characters to be written from the enclosed characters of the 11 edit descriptor itself, including blanks. For a character string edit descriptor, the width of the field is 12 the number of characters between the delimiting characters. Within the field, two consecutive delimiting 13 characters are counted as a single character. 14 NOTE 10.26 A delimiter for a character string edit descriptor is either an apostrophe or quote. 10.10 List-directed formatting 15 List-directed input/output allows data editing according to the type of the list item instead of by a 16 format specification. It also allows data to be free-field, that is, separated by commas (or semicolons) 17 or blanks. 18 The characters in one or more list-directed records constitute a sequence of values and value separators. 19 The end of a record has the same effect as a blank character, unless it is within a character constant. Any 20 sequence of two or more consecutive blanks is treated as a single blank, unless it is within a character 21 constant. 22 Each value is either a null value, c, r *c, or r *, where c is a literal constant, optionally signed if integer 23 or real, or an undelimited character constant and r is an unsigned, nonzero, integer literal constant. 24 Neither c nor r shall have kind type parameters specified. The constant c is interpreted as though 25 it had the same kind type parameter as the corresponding list item. The r *c form is equivalent to r 26 successive appearances of the constant c, and the r * form is equivalent to r successive appearances of 27 the null value. Neither of these forms may contain embedded blanks, except where permitted within the 28 constant c. 29 A value separator is 30 (1) a comma optionally preceded by one or more contiguous blanks and optionally followed by 31 one or more contiguous blanks, unless the decimal edit mode is COMMA, in which case a 32 semicolon is used in place of the comma, 33 (2) a slash optionally preceded by one or more contiguous blanks and optionally followed by 34 one or more contiguous blanks, or 35 (3) one or more contiguous blanks between two nonblank values or following the last nonblank 36 value, where a nonblank value is a constant, an r *c form, or an r * form. 37 278 2006/07/11 WORKING DRAFT J3/06-007 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. 10.10.1 List-directed input 1 Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting, 2 except as noted below. The form of the input value shall be acceptable for the type of the next effective 3 item in the list. Blanks are never used as zeros, and embedded blanks are not permitted in constants, 4 except within character constants and complex constants as specified below. 5 For the r *c form of an input value, the constant c is interpreted as an undelimited character constant 6 if the first list item corresponding to this value is of type default, ASCII, or ISO 10646 character, there 7 is a nonblank character immediately after r *, and that character is not an apostrophe or a quotation 8 mark; otherwise, c is interpreted as a literal constant. 9 NOTE 10.29 The end of a record has the effect of a blank, except when it appears within a character constant. When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 10 edit descriptor with a suitable value of w were used. 11 When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 12 descriptor with a suitable value of w were used. 13 When the next effective item is of type real, the input form is that of a numeric input field. A numeric 14 input field is a field suitable for F editing (10.7.2.3.2) that is assumed to have no fractional digits unless 15 a decimal symbol appears within the field. 16 When the next effective item is of type complex, the input form consists of a left parenthesis followed 17 by an ordered pair of numeric input fields separated by a separator, and followed by a right parenthesis. 18 The first numeric input field is the real part of the complex constant and the second is the imaginary 19 part. Each of the numeric input fields may be preceded or followed by any number of blanks and ends of 20 records. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal 21 edit mode is COMMA. The end of a record may occur between the real part and the separator or between 22 the separator and the imaginary part. 23 When the next effective item is of type logical, the input form shall not include value separators among 24 the optional characters permitted for L editing. 25 When the next effective item is of type character, the input form consists of a possibly delimited sequence 26 of zero or more rep-char s whose kind type parameter is implied by the kind of the effective list item. 27 Character sequences may be continued from the end of one record to the beginning of the next record, 28 but the end of record shall not occur between a doubled apostrophe in an apostrophe-delimited character 29 sequence, nor between a doubled quote in a quote-delimited character sequence. The end of the record 30 does not cause a blank or any other character to become part of the character sequence. The character 31 sequence may be continued on as many records as needed. The characters blank, comma, semicolon, 32 and slash may appear in default, ASCII, or ISO 10646 character sequences. 33 279 J3/06-007 WORKING DRAFT 2006/07/11 If the next effective item is of type default, ASCII, or ISO 10646 character and 1 (1) the character sequence does not contain value separators, 2 (2) the character sequence does not cross a record boundary, 3 (3) the first nonblank character is not a quotation mark or an apostrophe, 4 (4) the leading characters are not digit s followed by an asterisk, and 5 (5) the character sequence contains at least one character, 6 the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the 7 character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), 8 semicolon (if the decimal edit mode is COMMA), slash, or end of record; in this case apostrophes and 9 quotation marks within the datum are not to be doubled. 10 Let len be the length of the next effective item, and let w be the length of the character sequence. If 11 len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 12 effective item. If len is greater than w, the sequence is transmitted to the leftmost w characters of the 13 next effective item and the remaining len -w characters of the next effective item are filled with blanks. 14 The effect is as though the sequence were assigned to the next effective item in a character assignment 15 statement (7.4.1.3). 16 10.10.1.1 Null values 17 A null value is specified by 18 (1) the r * form, 19 (2) no characters between consecutive value separators, or 20 (3) no characters before the first value separator in the first record read by each execution of a 21 list-directed input statement. 22 NOTE 10.30 The end of a record following any other value separator, with or without separating blanks, does not specify a null value in list-directed input. A null value has no effect on the definition status of the next effective item. A null value shall not be 23 used for either the real or imaginary part of a complex constant, but a single null value may represent 24 an entire complex constant. 25 A slash encountered as a value separator during execution of a list-directed input statement causes 26 termination of execution of that input statement after the assignment of the previous value. Any 27 characters remaining in the current record are ignored. If there are additional items in the input list, 28 the effect is as if null values had been supplied for them. Any do-variable in the input list is defined as 29 though enough null values had been supplied for any remaining input list items. 30 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. 280 2006/07/11 WORKING DRAFT J3/06-007 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$ 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 ISN'T BOB'S P Z (123.0,0.0) G true 10.10.2 List-directed output 1 The form of the values produced is the same as that required for input, except as noted otherwise. With 2 the exception of adjacent undelimited character sequences, the values are separated by one or more 3 blanks or by a comma, or a semicolon if the decimal edit mode is comma, optionally preceded by one or 4 more blanks and optionally followed by one or more blanks. 5 The processor may begin new records as necessary, but the end of record shall not occur within a 6 constant except for complex constants and character sequences. The processor shall not insert blanks 7 within character sequences or within constants, except for complex constants. 8 Logical output values are T for the value true and F for the value false. 9 Integer output constants are produced with the effect of an Iw edit descriptor. 10 k+3 Bits output constants are produced with the effect of a Zw edit descriptor with w equal to where 11 4 k is the kind type parameter value of the list item. 12 281 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note (cont.) J3 internal note Unresolved Technical Issue 48 The above formula was based on the idea that leading zeros of bit values are significant. However, this cannot be true, since they are suppressed using the normal edit descriptors and in particular for B0 O0 and Z0. Therefore I recommend changing the above to Z0. Actually, there is another question, which is why is it that bits values are apparently "naturally" written with Z notation? I would have expected B notation. Furthermore, the above formula is ambiguous. Does it mean k+3 , k+3 , or [ k+3 ]? Should we 4 4 4 stick to something like this formula, I think it should be k . 4 BTW, when this gets changed, the corresponding change should be made for namelist output. Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, 1 depending on the magnitude x of the value and a range 10d1 x < 10d2 , where d1 and d2 are processor- 2 dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 3 0PFw.d ; otherwise, 1PEw.d Ee is used. 4 For numeric output, reasonable processor-dependent values of w , d , and e are used for each of the 5 numeric constants output. 6 Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, 7 each produced as defined above for real constants. The separator is a comma if the decimal edit mode is 8 POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between 9 the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire 10 record. The only embedded blanks permitted within a complex constant are between the separator and 11 the end of a record and one blank at the beginning of the next record. 12 Character sequences produced when the delimiter mode has a value of NONE 13 (1) are not delimited by apostrophes or quotation marks, 14 (2) are not separated from each other by value separators, 15 (3) have each internal apostrophe or quotation mark represented externally by one apostrophe 16 or quotation mark, and 17 (4) have a blank character inserted by the processor at the beginning of any record that begins 18 with the continuation of a character sequence from the preceding record. 19 Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, 20 are preceded and followed by a value separator, and have each internal quote represented on the external 21 medium by two contiguous quotes. 22 Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited 23 by apostrophes, are preceded and followed by a value separator, and have each internal apostrophe 24 represented on the external medium by two contiguous apostrophes. 25 If two or more successive values in an output record have identical values, the processor has the option 26 of producing a repeated constant of the form r *c instead of the sequence of identical values. 27 Slashes, as value separators, and null values are not produced as output by list-directed formatting. 28 Except for continuation of delimited character sequences, each output record begins with a blank char- 29 acter. 30 282 2006/07/11 WORKING DRAFT J3/06-007 NOTE 10.33 The length of the output records is not specified exactly and may be processor dependent. 10.11 Namelist formatting 1 Namelist input/output allows data editing with NAME=value subsequences. This facilitates documen- 2 tation of input and output files and more flexibility on input. 3 The characters in one or more namelist records constitute a sequence of name-value subsequences, 4 each of which consists of an ob ject designator followed by an equals and followed by one or more values 5 and value separators. The equals may optionally be preceded or followed by one or more contiguous 6 blanks. The end of a record has the same effect as a blank character, unless it is within a character 7 constant. Any sequence of two or more consecutive blanks is treated as a single blank, unless it is within 8 a character constant. 9 The name may be any name in the namelist-group-object -list (5.6). 10 Each value is either a null value (10.11.1.4), c, r *c, or r *, where c is a literal constant, optionally signed 11 if integer or real, and r is an unsigned, nonzero, integer literal constant. A kind type parameter shall 12 not be specified for c or r. The constant c is interpreted as though it had the same kind type parameter 13 as the corresponding list item. The r *c form is equivalent to r successive appearances of the constant c, 14 and the r * form is equivalent to r successive null values. Neither of these forms may contain embedded 15 blanks, except where permitted within the constant c. 16 A value separator for namelist formatting is the same as for list-directed formatting (10.10). 17 10.11.1 Namelist input 18 Input for a namelist input statement consists of 19 (1) optional blanks and namelist comments, 20 (2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST 21 statement, 22 (3) one or more blanks, 23 (4) a sequence of zero or more name-value subsequences separated by value separators, and 24 (5) a slash to terminate the namelist input. 25 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. In each name-value subsequence, the name shall be the name of a namelist group ob ject list item with 26 an optional qualification and the name with the optional qualification shall not be a zero-sized array, a 27 zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not 28 contain a vector subscript. 29 A group name or ob ject name is without regard to case. 30 10.11.1.1 Namelist group object names 31 Within the input data, each name shall correspond to a particular namelist group ob ject name. Sub- 32 scripts, strides, and substring range expressions used to qualify group ob ject names shall be optionally 33 signed integer literal constants with no kind type parameters specified. If a namelist group ob ject is 34 283 J3/06-007 WORKING DRAFT 2006/07/11 an array, the input record corresponding to it may contain either the array name or the designator of 1 a subob ject of that array, using the syntax of ob ject designators (R603). If the namelist group ob ject 2 name is the name of a variable of derived type, the name in the input record may be either the name of 3 the variable or the designator of one of its components, indicated by qualifying the variable name with 4 the appropriate component name. Successive qualifications may be applied as appropriate to the shape 5 and type of the variable represented. 6 The order of names in the input records need not match the order of the namelist group ob ject items. 7 The input records need not contain all the names of the namelist group ob ject items. The definition 8 status of any names from the namelist-group-object -list that do not occur in the input record remains 9 unchanged. In the input record, each ob ject name or subob ject designator may be preceded and followed 10 by one or more optional blanks but shall not contain embedded blanks. 11 10.11.1.2 Namelist input values 12 The datum c (10.11) is any input value acceptable to format specifications for a given type, except for 13 a restriction on the form of input values corresponding to list items of types logical, integer, bits, and 14 character as specified in 10.11.1.3. The form of a real or complex value is dependent on the decimal edit 15 mode in effect (10.8.8). The form of an input value shall be acceptable for the type of the namelist group 16 ob ject list item. The number and forms of the input values that may follow the equals in a name-value 17 subsequence depend on the shape and type of the ob ject represented by the name in the input record. 18 When the name in the input record is that of a scalar variable of an intrinsic type, the equals shall 19 not be followed by more than one value. Blanks are never used as zeros, and embedded blanks are not 20 permitted in constants except within character constants and complex constants as specified in 10.11.1.3. 21 The name-value subsequences are evaluated serially, in left-to-right order. A namelist group ob ject 22 designator may appear in more than one name-value sequence. 23 When the name in the input record represents an array variable or a variable of derived type, the effect 24 is as if the variable represented were expanded into a sequence of scalar list items, in the same way 25 that formatted input/output list items are expanded (9.5.2). Each input value following the equals shall 26 then be acceptable to format specifications for the type of the list item in the corresponding position in 27 the expanded sequence, except as noted in 10.11.1.3. The number of values following the equals shall 28 not exceed the number of list items in the expanded sequence, but may be less; in the latter case, the 29 effect is as if sufficient null values had been appended to match any remaining list items in the expanded 30 sequence. 31 NOTE 10.35 For example, if the name in the input record is the name of an integer array of size 100, at most 100 values, each of which is either a digit string or a null value, may follow the equals; these values would then be assigned to the elements of the array in array element order. A slash encountered as a value separator during the execution of a namelist input statement causes 32 termination of execution of that input statement after assignment of the previous value. If there are 33 additional items in the namelist group ob ject being transferred, the effect is as if null values had been 34 supplied for them. 35 A namelist comment may appear after any value separator except a slash. A namelist comment is also 36 permitted to start in the first nonblank position of an input record except within a character literal 37 constant. 38 Successive namelist records are read by namelist input until a slash is encountered; the remainder of the 39 record is ignored and need not follow the rules for namelist input values. 40 284 2006/07/11 WORKING DRAFT J3/06-007 10.11.1.3 Namelist group object list items 1 When the next effective namelist group ob ject list item is of type real, the input form of the input value 2 is that of a numeric input field. A numeric input field is a field suitable for F editing (10.7.2.3.2) that is 3 assumed to have no fractional digits unless a decimal symbol appears within the field. 4 When the next effective item is of type complex, the input form of the input value consists of a left 5 parenthesis followed by an ordered pair of numeric input fields separated by a comma (if the decimal 6 edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA), and followed by a right 7 parenthesis. The first numeric input field is the real part of the complex constant and the second part 8 is the imaginary part. Each of the numeric input fields may be preceded or followed by any number of 9 blanks and ends of records. The end of a record may occur between the real part and the comma or 10 semicolon, or between the comma or semicolon and the imaginary part. 11 When the next effective item is of type logical, the input form of the input value shall not include equals 12 or value separators among the optional characters permitted for L editing (10.7.3). 13 When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 14 edit descriptor with a suitable value of w were used. 15 When the next effective list item is of type bits, the value in the input record is interpreted as if a Zw 16 edit descriptor with a suitable value of w were used. 17 When the next effective item is of type character, the input form consists of a delimited sequence of zero 18 or more rep-char s whose kind type parameter is implied by the kind of the corresponding list item. Such 19 a sequence may be continued from the end of one record to the beginning of the next record, but the 20 end of record shall not occur between a doubled apostrophe in an apostrophe-delimited sequence, nor 21 between a doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or 22 any other character to become part of the sequence. The sequence may be continued on as many records 23 as needed. The characters blank, comma, semicolon, and slash may appear in such character sequences. 24 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 ob ject 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). Let len be the length of the next effective item, and let w be the length of the character sequence. If 25 len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 26 effective item. If len is greater than w, the constant is transmitted to the leftmost w characters of the 27 next effective item and the remaining len -w characters of the next effective item are filled with blanks. 28 The effect is as though the sequence were assigned to the next effective item in a character assignment 29 statement (7.4.1.3). 30 10.11.1.4 Null values 31 A null value is specified by 32 (1) the r * form, 33 (2) blanks between two consecutive value separators following an equals, 34 (3) zero or more blanks preceding the first value separator and following an equals, or 35 (4) two consecutive nonblank value separators. 36 A null value has no effect on the definition status of the corresponding input list item. If the namelist 37 group ob ject list item is defined, it retains its previous value; if it is undefined, it remains undefined. A 38 285 J3/06-007 WORKING DRAFT 2006/07/11 null value shall not be used as either the real or imaginary part of a complex constant, but a single null 1 value may represent an entire complex constant. 2 NOTE 10.37 The end of a record following a value separator, with or without intervening blanks, does not specify a null value in namelist input. 10.11.1.5 Blanks 3 All blanks in a namelist input record are considered to be part of some value separator except for 4 (1) blanks embedded in a character constant, 5 (2) embedded blanks surrounding the real or imaginary part of a complex constant, 6 (3) leading blanks following the equals unless followed immediately by a slash or comma, or a 7 semicolon if the decimal edit mode is comma, and 8 (4) blanks between a name and the following equals. 9 10.11.1.6 Namelist Comments 10 Except within a character literal constant, a "!" character after a value separator or in the first nonblank 11 position of a namelist input record initiates a comment. The comment extends to the end of the current 12 input record and may contain any graphic character in the processor-dependent character set. The 13 comment is ignored. A slash within the namelist comment does not terminate execution of the namelist 14 input statement. Namelist comments are not allowed in stream input because comments depend on 15 record structure. 16 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: &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 ISN'T BOB'S P Z (123.0,0.0) G unchanged 286 2006/07/11 WORKING DRAFT J3/06-007 10.11.2 Namelist output 1 The form of the output produced is the same as that required for input, except for the forms of real, 2 character, and logical values. The name in the output is in upper case. With the exception of adjacent 3 undelimited character values, the values are separated by one or more blanks or by a comma, or a 4 semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and optionally 5 followed by one or more blanks. 6 Namelist output shall not include namelist comments. 7 The processor may begin new records as necessary. However, except for complex constants and character 8 values, the end of a record shall not occur within a constant, character value, or name, and blanks shall 9 not appear within a constant, character value, or name. 10 NOTE 10.39 The length of the output records is not specified exactly and may be processor dependent. 10.11.2.1 Namelist output editing 11 Logical output values are T for the value true and F for the value false. 12 Integer output constants are produced with the effect of an Iw edit descriptor. 13 k+3 Bits output constants are produced with the effect of a Zw edit descriptor with w equal to where 14 4 k is the kind type parameter value of the list item. 15 Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, 16 depending on the magnitude x of the value and a range 10d1 x < 10d2 , where d1 and d2 are processor- 17 dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 18 0PFw.d ; otherwise, 1PEw.d Ee is used. 19 For numeric output, reasonable processor-dependent integer values of w, d, and e are used for each of 20 the numeric constants output. 21 Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, 22 each produced as defined above for real constants. The separator is a comma if the decimal edit mode is 23 POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between 24 the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire 25 record. The only embedded blanks permitted within a complex constant are between the separator and 26 the end of a record and one blank at the beginning of the next record. 27 Character sequences produced when the delimiter mode has a value of NONE 28 (1) are not delimited by apostrophes or quotation marks, 29 (2) are not separated from each other by value separators, 30 (3) have each internal apostrophe or quotation mark represented externally by one apostrophe 31 or quotation mark, and 32 (4) have a blank character inserted by the processor at the beginning of any record that begins 33 with the continuation of a character sequence from the preceding record. 34 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. Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, 35 287 J3/06-007 WORKING DRAFT 2006/07/11 are preceded and followed by a value separator, and have each internal quote represented on the external 1 medium by two contiguous quotes. 2 Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited 3 by apostrophes, are preceded and followed by a value separator, and have each internal apostrophe 4 represented on the external medium by two contiguous apostrophes. 5 10.11.2.2 Namelist output records 6 If two or more successive values in an array in an output record produced have identical values, the 7 processor has the option of producing a repeated constant of the form r *c instead of the sequence of 8 identical values. 9 The name of each namelist group ob ject list item is placed in the output record followed by an equals 10 and a list of values of the namelist group ob ject list item. 11 An ampersand character followed immediately by a namelist-group-name will be produced by namelist 12 formatting at the start of the first output record to indicate which particular group of data ob jects is 13 being output. A slash is produced by namelist formatting to indicate the end of the namelist formatting. 14 A null value is not produced by namelist formatting. 15 Except for new records created by explicit formatting within a user-defined derived-type output pro- 16 cedure or by continuation of delimited character sequences, each output record begins with a blank 17 character. 18 288 2006/07/11 WORKING DRAFT J3/06-007 11 Program units 1 The terms and basic concepts of program units were introduced in 2.2. A program unit is a main 2 program, an external subprogram, a module, a submodule, or a block data program unit. 3 This clause describes main programs, modules, submodules, and block data program units. Clause 12 4 describes external subprograms. 5 11.1 Main program 6 A Fortran main program is a program unit that does not contain a SUBROUTINE, FUNCTION, 7 MODULE, or BLOCK DATA statement as its first statement. 8 R1101 main-program is [ program-stmt ] 9 [ specification-part ] 10 [ execution-part ] 11 [ internal-subprogram-part ] 12 end-program-stmt 13 R1102 program-stmt is PROGRAM program-name 14 R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] 15 C1101 (R1101) In a main-program , the execution-part shall not contain a RETURN statement or an 16 ENTRY statement. 17 C1102 (R1101) The program-name may be included in the end-program-stmt only if the optional 18 program-stmt is used and, if included, shall be identical to the program-name specified in the 19 program-stmt . 20 C1103 (R1101) An automatic ob ject shall not appear in the specification-part (R204) of a main program. 21 NOTE 11.1 The program name is global to the program (16.2). For explanatory information about uses for the program name, see subclause C.8.1. NOTE 11.2 An example of a main program is: PROGRAM ANALYZE REAL A, B, C (10,10) ! Specification part CALL FIND ! Execution part CONTAINS SUBROUTINE FIND ! Internal subprogram ... END SUBROUTINE FIND END PROGRAM ANALYZE The main program may be defined by means other than Fortran; in that case, the program shall not 22 contain a main-program program unit. 23 A reference to a Fortran main-program shall not appear in any program unit in the program, including 24 289 J3/06-007 WORKING DRAFT 2006/07/11 itself. 1 11.2 Mo dules 2 A mo dule contains specifications and definitions that are to be accessible to other program units. A 3 module that is provided as an inherent part of the processor is an intrinsic mo dule. A nonintrinsic 4 mo dule is defined by a module program unit or a means other than Fortran. 5 Procedures and types defined in an intrinsic module are not themselves intrinsic. 6 R1104 module is module-stmt 7 [ specification-part ] 8 [ module-subprogram-part ] 9 end-module-stmt 10 R1105 module-stmt is MODULE module-name 11 R1106 end-module-stmt is END [ MODULE [ module-name ] ] 12 R1107 module-subprogram-part is contains-stmt 13 [ module-subprogram ] ... 14 R1108 module-subprogram is function-subprogram 15 or subroutine-subprogram 16 or separate-module-subprogram 17 C1104 (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 . 19 C1105 (R1104) A module specification-part shall not contain a stmt-function-stmt , an entry-stmt , or a 20 format-stmt . 21 C1106 (R1104) An automatic ob ject shall not appear in the specification-part of a module. 22 C1107 (R1104) If an ob ject of a type for which component-initialization is specified (R448) appears 23 in the specification-part of a module and does not have the ALLOCATABLE or POINTER 24 attribute, the ob ject shall have the SAVE attribute. 25 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. A module is host to any module subprograms (12.2.2.2) it contains, and the entities in the module are therefore accessible in the module subprograms through host association. 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. If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the 26 290 2006/07/11 WORKING DRAFT J3/06-007 EXTERNAL attribute in that scoping unit; if it is a function, its type and type parameters shall be 1 explicitly declared in a type declaration statement in that scoping unit. 2 If an intrinsic procedure is declared in the scoping unit of a module, it shall explicitly be given the 3 INTRINSIC attribute in that scoping unit or be used as an intrinsic procedure in that scoping unit. 4 11.2.1 The USE statement and use asso ciation 5 The USE statement specifies use association. A USE statement is a mo dule reference to the module 6 it specifies. At the time a USE statement is processed, the public portions of the specified module shall 7 be available. A module shall not reference itself, either directly or indirectly. A submodule shall not 8 reference its ancestor module by use association, either directly or indirectly. 9 NOTE 11.7 It is possible for submodules with different ancestor modules to reference each others' ancestor modules by use association. The USE statement provides the means by which a scoping unit accesses named data ob jects, derived 10 types, interface blocks, procedures, abstract interfaces, module procedure interfaces, generic identifiers, 11 macros, and namelist groups in a module. The entities in the scoping unit are said to be use asso ciated 12 with the entities in the module. The accessed entities have the attributes specified in the module, except 13 that an entity may have a different accessibility attribute or it may have the ASYNCHRONOUS or 14 VOLATILE attribute in the local scoping unit even if the associated module entity does not. The 15 entities made accessible are identified by the names or generic identifiers used to identify them in the 16 module. By default, they are identified by the same identifiers in the scoping unit containing the USE 17 statement, but it is possible to specify that different local identifiers are used. 18 NOTE 11.8 The accessibility of module entities may be controlled by accessibility attributes (4.5.2.2, 5.3.2), and the ONLY option of the USE statement. Definability of module entities can be controlled by the PROTECTED attribute (5.3.14). R1109 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename -list ] 19 or USE [ [ , module-nature ] :: ] module-name , 20 ONLY : [ only -list ] 21 R1110 module-nature is INTRINSIC 22 or NON INTRINSIC 23 R1111 rename is local-name => use-name 24 or OPERATOR (local-defined-operator ) => 25 OPERATOR (use-defined-operator ) 26 R1112 only is generic-spec 27 or only-use-name 28 or rename 29 R1113 only-use-name is use-name 30 C1108 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. 31 C1109 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic 32 module. 33 C1110 (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the 34 291 J3/06-007 WORKING DRAFT 2006/07/11 same name. 1 C1111 (R1111) OPERATOR(use-defined-operator ) shall not identify a generic-binding . 2 C1112 (R1112) The generic-spec shall not identify a generic-binding . 3 NOTE 11.9 The above two constraints do not prevent accessing a generic-spec that is declared by an interface block, even if a generic-binding has the same generic-spec . C1113 (R1112) Each generic-spec shall be a public entity in the module. 4 C1114 (R1113) Each use-name shall be the name of a public entity in the module. 5 R1114 local-defined-operator is defined-unary-op 6 or defined-binary-op 7 R1115 use-defined-operator is defined-unary-op 8 or defined-binary-op 9 C1115 (R1115) Each use-defined-operator shall be a public entity in the module. 10 A use-stmt without a module-nature provides access either to an intrinsic or to a nonintrinsic module. 11 If the module-name is the name of both an intrinsic and a nonintrinsic module, the nonintrinsic module 12 is accessed. 13 The USE statement without the ONLY option provides access to all public entities in the specified 14 module. 15 A USE statement with the ONLY option provides access only to those entities that appear as generic- 16 spec s, use-name s, or use-defined-operator s in the only -list. 17 More than one USE statement for a given module may appear in a scoping unit. If one of the USE 18 statements is without an ONLY option, all public entities in the module are accessible. If all the USE 19 statements have ONLY options, only those entities in one or more of the only -list s are accessible. 20 An accessible entity in the referenced module has one or more local identifiers. These identifiers are 21 (1) the identifier of the entity in the referenced module if that identifier appears as an only-use- 22 name or as the defined-operator of a generic-spec in any only for that module, 23 (2) each of the local-name s or local-defined-operator s that the entity is given in any rename for 24 that module, and 25 (3) the identifier of the entity in the referenced module if that identifier does not appear as a 26 use-name or use-defined-operator in any rename for that module. 27 Two or more accessible entities, other than generic interfaces or defined operators, may have the same 28 identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces 29 and defined operators are handled as described in subclause 16.3.4. Except for these cases, the local 30 identifier of any entity given accessibility by a USE statement shall differ from the local identifiers of all 31 other entities accessible to the scoping unit through USE statements and otherwise. 32 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. The local identifier of an entity made accessible by a USE statement shall not appear in any other 33 292 2006/07/11 WORKING DRAFT J3/06-007 nonexecutable statement that would cause any attribute (5.3) of the entity to be specified in the scoping 1 unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE statement 2 in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE attribute. 3 The appearance of such a local identifier in a PUBLIC statement in a module causes the entity accessible 4 by the USE statement to be a public entity of that module. If the identifier appears in a PRIVATE 5 statement in a module, the entity is not a public entity of that module. If the local identifier does not 6 appear in either a PUBLIC or PRIVATE statement, it assumes the default accessibility attribute (5.4.1) 7 of that scoping unit. 8 NOTE 11.11 The constraints in subclauses 5.7.1, 5.7.2, and 5.6 prohibit the local-name from appearing as a common-block-object in a COMMON statement, an equivalence-object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST statement, respectively. There is no prohi- bition against the local-name appearing as a common-block-name or a namelist-group-object . NOTE 11.12 For a discussion of the impact of the ONLY option and renaming on dependent compilation, see subclause C.8.2.1. NOTE 11.13 Examples: USE STATS LIB provides access to all public entities in the module STATS LIB. USE MATH LIB; USE STATS LIB, SPROD => PROD makes all public entities in both MATH LIB and STATS LIB accessible. If MATH LIB contains an entity called PROD, it is accessible by its own name while the entity PROD of STATS LIB is accessible by the name SPROD. USE STATS LIB, ONLY: YPROD; USE STATS LIB, ONLY : PROD makes public entities YPROD and PROD in STATS LIB accessible. USE STATS LIB, ONLY : YPROD; USE STATS LIB makes all public entities in STATS LIB accessible. 11.2.2 Submo dules 9 A submo dule is a program unit that extends a module or another submodule. The program unit that 10 it extends is its parent, and is specified by the parent-identifier in the submodule-stmt . A submodule 11 is a child of its parent. An ancestor of a submodule is its parent or an ancestor of its parent. A 12 descendant of a module or submodule is one of its children or a descendant of one of its children. The 13 submo dule identifier is the ordered pair whose first element is the ancestor module name and whose 14 second element is the submodule name. 15 293 J3/06-007 WORKING DRAFT 2006/07/11 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. 1 A submodule may provide implementations for module procedures, each of which is declared by a module 2 procedure interface body (12.4.2.1) within that submodule or one of its ancestors, and declarations and 3 definitions of other entities that are accessible by host association in its descendants. 4 R1116 submodule is submodule-stmt 5 [ specification-part ] 6 [ module-subprogram-part ] 7 end-submodule-stmt 8 R1117 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name 9 R1118 parent-identifier is ancestor-module-name [ : parent-submodule-name ] 10 R1119 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ] 11 C1116 (R1116) An automatic ob ject shall not appear in the specification-part of a submodule. 12 C1117 (R1116) A submodule specification-part shall not contain a format-stmt or a stmt-function-stmt . 13 C1118 (R1116) An ob ject with default initialization that is declared in the specification-part of a 14 submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. 15 C1119 (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- 16 submodule-name shall be the name of a descendant of that module. 17 C1120 (R1116) If a submodule-name appears in the end-submodule-stmt , it shall be identical to the one 18 in the submodule-stmt . 19 11.3 Blo ck data program units 20 A blo ck data program unit is used to provide initial values for data ob jects in named common blocks. 21 R1120 block-data is block-data-stmt 22 [ specification-part ] 23 end-block-data-stmt 24 R1121 block-data-stmt is BLOCK DATA [ block-data-name ] 25 R1122 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ] 26 C1121 (R1120) The block-data-name shall be included in the end-block-data-stmt only if it was provided 27 in the block-data-stmt and, if included, shall be identical to the block-data-name in the block- 28 data-stmt . 29 C1122 (R1120) A block-data specification-part shall contain only derived-type definitions and ASYN- 30 CHRONOUS, BIND, COMMON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRIN- 31 SIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration 32 statements. 33 C1123 (R1120) A type declaration statement in a block-data specification-part shall not contain AL- 34 294 2006/07/11 WORKING DRAFT J3/06-007 LOCATABLE, EXTERNAL, or BIND attribute specifiers. 1 NOTE 11.15 For explanatory information about the uses for the block-data-name , see subclause C.8.1. If an ob ject in a named common block is initially defined, all storage units in the common block storage 2 sequence shall be specified even if they are not all initially defined. More than one named common block 3 may have ob jects initially defined in a single block data program unit. 4 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 ob jects that are being initialized in a single block data program unit. B, D, and E are not initialized but they need to be specified as part of the common blocks. Only an ob ject in a named common block may be initially defined in a block data program unit. 5 NOTE 11.17 Ob jects associated with an ob ject in a common block are considered to be in that common block. The same named common block shall not be specified in more than one block data program unit in a 6 program. 7 There shall not be more than one unnamed block data program unit in a program. 8 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/06-007 WORKING DRAFT 2006/07/11 296 2006/07/11 WORKING DRAFT J3/06-007 12 Procedures 1 12.1 Concepts 2 The concept of a procedure was introduced in 2.2.3. This clause contains a complete description of 3 procedures. The actions specified by a procedure are performed when the procedure is invoked by 4 execution of a reference to it. 5 The sequence of actions encapsulated by a procedure has access to entities in the invoking scoping 6 unit by way of argument association (12.5.1). A dummy argument is a name that appears in the 7 SUBROUTINE, FUNCTION, or ENTRY statement in the declaration of a procedure (R1235). Dummy 8 arguments are also specified for intrinsic procedures and procedures in intrinsic modules in Clauses 13, 9 14, and 15. 10 The entities in the invoking scoping unit are specified by actual arguments. An actual argument is an 11 entity that appears in a procedure reference (R1223). 12 A procedure may also have access to entities in other scoping units, not necessarily the invoking scoping 13 unit, by use association (16.5.1.3), host association (16.5.1.4), linkage association (16.5.1.5), storage 14 association (16.5.3), or by reference to external procedures (5.3.8). 15 12.2 Procedure classifications 16 A procedure is classified according to the form of its reference and the way it is defined. 17 12.2.1 Pro cedure classification by reference 18 The definition of a procedure specifies it to be a function or a subroutine. A reference to a function either 19 appears explicitly as a primary within an expression, or is implied by a defined operation (7.1.3) within 20 an expression. A reference to a subroutine is a CALL statement or a defined assignment statement 21 (7.4.1.4). 22 A procedure is classified as elemental if it is a procedure that may be referenced elementally (12.8). 23 12.2.2 Pro cedure classification by means of definition 24 A procedure is either an intrinsic procedure, an external procedure, a module procedure, an internal 25 procedure, a dummy procedure (which may be a dummy procedure pointer), a nondummy procedure 26 pointer, or a statement function. 27 12.2.2.1 Intrinsic pro cedures 28 A procedure that is provided as an inherent part of the processor is an intrinsic pro cedure. 29 12.2.2.2 External, internal, and mo dule pro cedures 30 An external pro cedure is a procedure that is defined by an external subprogram or by a means other 31 than Fortran. 32 An internal pro cedure is a procedure that is defined by an internal subprogram. Internal subprograms 33 may appear in the main program, in an external subprogram, or in a module subprogram. Internal 34 297 J3/06-007 WORKING DRAFT 2006/07/11 subprograms shall not appear in other internal subprograms. Internal subprograms are the same as 1 external subprograms except that the name of the internal procedure is not a global identifier, an 2 internal subprogram shall not contain an ENTRY statement, the internal procedure name shall not be 3 argument associated with a dummy procedure (12.5.1.6), and the internal subprogram has access to host 4 entities by host association. 5 A mo dule pro cedure is a procedure that is defined by a module subprogram. 6 A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement. If the subprogram 7 has one or more ENTRY statements, it also defines a procedure for each of them. 8 12.2.2.3 Dummy pro cedures 9 A dummy argument that is specified to be a procedure or appears in a procedure reference is a dummy 10 pro cedure. A dummy procedure with the POINTER attribute is a dummy procedure pointer. 11 12.2.2.4 Pro cedure p ointers 12 A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes; it may be 13 pointer associated with an external procedure, a module procedure, an intrinsic procedure, or a dummy 14 procedure that is not a procedure pointer. 15 12.2.2.5 Statement functions 16 17 A function that is defined by a single statement is a statement function (12.6.4). 12.3 Characteristics of pro cedures 18 The characteristics of a pro cedure are the classification of the procedure as a function or subroutine, 19 whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its 20 dummy arguments, and the characteristics of its result value if it is a function. 21 12.3.1 Characteristics of dummy arguments 22 Each dummy argument has the characteristic that it is a dummy data ob ject, a dummy procedure, a 23 dummy procedure pointer, or an asterisk (alternate return indicator). A dummy argument other than an asterisk 24 may be specified to have the OPTIONAL attribute. This attribute means that the dummy argument 25 need not be associated with an actual argument for any particular reference to the procedure. 26 12.3.1.1 Characteristics of dummy data objects 27 The characteristics of a dummy data ob ject are its type, its type parameters (if any), its shape, its intent 28 (5.3.9, 5.4.8), whether it is optional (5.3.11, 5.4.9), whether it is allocatable (5.3.7.4), whether it has the 29 ASYNCHRONOUS (5.3.4), CONTIGUOUS (5.3.6), VALUE (5.3.17), or VOLATILE (5.3.18) attributes, 30 whether it is polymorphic, and whether it is a pointer (5.3.13, 5.4.11) or a target (5.3.16, 5.4.14). If 31 a type parameter of an ob ject or a bound of an array is not an initialization expression, the exact 32 dependence on the entities in the expression is a characteristic. If a shape, size, or type parameter is 33 assumed or deferred, it is a characteristic. 34 12.3.1.2 Characteristics of dummy pro cedures and dummy pro cedure p ointers 35 The characteristics of a dummy procedure are the explicitness of its interface (12.4.1), its characteristics 36 as a procedure if the interface is explicit, whether it is a pointer, and whether it is optional (5.3.11, 5.4.9). 37 298 2006/07/11 WORKING DRAFT J3/06-007 12.3.1.3 Characteristics of asterisk dummy arguments 1 2 An asterisk as a dummy argument has no characteristics. 12.3.2 Characteristics of function results 3 The characteristics of a function result are its type, type parameters (if any), rank, whether it is poly- 4 morphic, whether it is allocatable, whether it is a pointer, whether it has the CONTIGUOUS attribute, 5 and whether it is a procedure pointer. If a function result is an array that is not allocatable or a pointer, 6 its shape is a characteristic. If a type parameter of a function result or a bound of a function result 7 array is not an initialization expression, the exact dependence on the entities in the expression is a 8 characteristic. If type parameters of a function result are deferred, which parameters are deferred is a 9 characteristic. If the length of a character function result is assumed, this is a characteristic. 10 12.4 Procedure interface 11 The interface of a procedure determines the forms of reference through which it may be invoked. 12 The procedure's interface consists of its abstract interface, its name, its binding label if any, and the 13 procedure's generic identifiers, if any. The characteristics of a procedure are fixed, but the remainder 14 of the interface may differ in different scoping units, except that for a separate module procedure body 15 (12.6.2.4), the dummy argument names, binding label, and whether it is recursive shall be the same as 16 in its corresponding module procedure interface body (12.4.2.1). 17 An abstract interface consists of procedure characteristics and the names of dummy arguments. 18 NOTE 12.1 For more explanatory information on procedure interfaces, see C.9.3. 12.4.1 Implicit and explicit interfaces 19 If a procedure is accessible in a scoping unit, its interface is either explicit or implicit in that scoping 20 unit. The interface of an internal procedure, module procedure, or intrinsic procedure is always explicit 21 in such a scoping unit. The interface of a subroutine or a function with a separate result name is explicit 22 within the subprogram that defines it. The interface of a statement function is always implicit. The interface of 23 an external procedure or dummy procedure is explicit in a scoping unit other than its own if an interface 24 body (12.4.2.1) for the procedure is supplied or accessible, and implicit otherwise. 25 NOTE 12.2 For example, the subroutine LLS of C.8.3.5 has an explicit interface. 12.4.1.1 Explicit interface 26 A procedure other than a statement function shall have an explicit interface if it is referenced and 27 (1) a reference to the procedure appears 28 (a) with an argument keyword (12.5.1), 29 (b) with an argument that is a co-indexed ob ject (2.4.6), 30 299 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 49 This makes most old (F77-style) procedures useless for operating on co-indexed ob jects. I'm not convinced it is necessary. I was told: "Surely it makes sense to prevent programming errors when possible." However, this achieves it not. Forcing the user to lie about his INTENT, use error-suppressing compiler switches, or forego the use of a third-party library which has unspecified intent arguments (in other words, the vast ma jority of software) does not prevent programming errors, it encourages them. (c) as a reference by its generic name (12.4.2.1), 1 (d) as a defined assignment (subroutines only), 2 (e) in an expression as a defined operator (functions only), or 3 (f ) in a context that requires it to be pure, 4 (2) the procedure has a dummy argument that 5 (a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, 6 VALUE, or VOLATILE attribute, 7 (b) is an assumed-shape array, 8 (c) is a co-array, 9 (d) is of a parameterized derived type, or 10 (e) is polymorphic, 11 (3) the procedure has a result that 12 (a) is an array, 13 (b) is a pointer or is allocatable, or 14 (c) has a nonassumed type parameter value that is not an initialization expression, 15 (4) the procedure is elemental, or 16 (5) the procedure has the BIND attribute. 17 12.4.2 Sp ecification of the procedure interface 18 The interface for an internal, external, module, or dummy procedure is specified by a FUNCTION, 19 SUBROUTINE, or ENTRY statement and by specification statements for the dummy arguments and 20 the result of a function. These statements may appear in the procedure definition, in an interface body, 21 or both, except that the ENTRY statement shall not appear in an interface body. 22 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.2.1). 12.4.2.1 Interface blo ck 23 R1201 interface-block is interface-stmt 24 [ interface-specification ] ... 25 end-interface-stmt 26 R1202 interface-specification is interface-body 27 or procedure-stmt 28 R1203 interface-stmt is INTERFACE [ generic-spec ] 29 or ABSTRACT INTERFACE 30 300 2006/07/11 WORKING DRAFT J3/06-007 R1204 end-interface-stmt is END INTERFACE [ generic-spec ] 1 R1205 interface-body is function-stmt 2 [ specification-part ] 3 end-function-stmt 4 or subroutine-stmt 5 [ specification-part ] 6 end-subroutine-stmt 7 R1206 procedure-stmt is [ MODULE ] PROCEDURE procedure-name -list 8 R1207 generic-spec is generic-name 9 or OPERATOR ( defined-operator ) 10 or ASSIGNMENT ( = ) 11 or dtio-generic-spec 12 R1208 dtio-generic-spec is READ (FORMATTED) 13 or READ (UNFORMATTED) 14 or WRITE (FORMATTED) 15 or WRITE (UNFORMATTED) 16 R1209 import-stmt is IMPORT [[ :: ] import-name -list ] 17 C1201 (R1201) An interface-block in a subprogram shall not contain an interface-body for a procedure 18 defined by that subprogram. 19 C1202 (R1201) The generic-spec shall be included in the end-interface-stmt only if it is provided in the 20 interface-stmt . If the end-interface-stmt includes generic-name , the interface-stmt shall specify 21 the same generic-name . If the end-interface-stmt includes ASSIGNMENT(=), the interface- 22 stmt shall specify ASSIGNMENT(=). If the end-interface-stmt includes dtio-generic-spec , 23 the interface-stmt shall specify the same dtio-generic-spec . If the end-interface-stmt includes 24 OPERATOR(defined-operator ), the interface-stmt shall specify the same defined-operator . If 25 one defined-operator is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the 26 corresponding operator <, <=, >, >=, ==, or /=. 27 C1203 (R1203) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the 28 function-stmt or the subroutine-name in the subroutine-stmt shall not be the same as a keyword 29 that specifies an intrinsic type. 30 C1204 (R1202) A procedure-stmt is allowed only in an interface block that has a generic-spec . 31 C1205 (R1205) An interface-body of a pure procedure shall specify the intents of all dummy arguments 32 except pointer, alternate return, and procedure arguments. 33 C1206 (R1205) An interface-body shall not contain an entry-stmt , data-stmt , format-stmt , or stmt- 34 function-stmt . 35 C1207 (R1206) A procedure-name shall have an explicit interface and shall refer to an accessible pro- 36 cedure pointer, external procedure, dummy procedure, or module procedure. 37 C1208 (R1206) If MODULE appears in a procedure-stmt , each procedure-name in that statement shall 38 be accessible in the current scope as a module procedure. 39 C1209 (R1206) A procedure-name shall not specify a procedure that is specified previously in any 40 procedure-stmt in any accessible interface with the same generic identifier. 41 C1210 (R1209) The IMPORT statement is allowed only in an interface-body that is not a module 42 procedure interface body. 43 C1211 (R1209) Each import-name shall be the name of an entity in the host scoping unit. 44 An external or module subprogram specifies a sp ecific interface for the procedures defined in that 45 301 J3/06-007 WORKING DRAFT 2006/07/11 subprogram. Such a specific interface is explicit for module procedures and implicit for external proce- 1 dures. 2 An interface block introduced by ABSTRACT INTERFACE is an abstract interface blo ck. An 3 interface body in an abstract interface block specifies an abstract interface. An interface block with a 4 generic specification is a generic interface blo ck. An interface block with neither ABSTRACT nor a 5 generic specification is a sp ecific interface blo ck. 6 The name of the entity declared by an interface body is the function-name in the function-stmt or the 7 subroutine-name in the subroutine-stmt that begins the interface body. 8 A mo dule pro cedure interface b o dy is an interface body whose initial statement contains the 9 keyword MODULE. It defines the mo dule pro cedure interface for a separate module procedure 10 (12.6.2.4). A separate module procedure is accessible by use association if and only if its interface body 11 is declared in the specification part of a module and is public. If a corresponding (12.6.2.4) separate 12 module procedure is not defined, the interface may be used to specify an explicit specific interface but 13 the procedure shall not be used in any other way. 14 C1212 (R1205) A module procedure interface body shall not appear in an abstract interface block. 15 An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an 16 explicit specific interface for an external procedure or a dummy procedure. If the name of the declared 17 procedure is that of a dummy argument in the subprogram containing the interface body, the procedure 18 is a dummy procedure; otherwise, it is an external procedure. 19 An interface body specifies all of the characteristics of the explicit specific interface or abstract interface. 20 The specification part of an interface body may specify attributes or define values for data entities that 21 do not determine characteristics of the procedure. Such specifications have no effect. 22 If an explicit specific interface is specified by an interface body or a procedure declaration statement 23 (12.4.2.3) for an external procedure, the characteristics shall be consistent with those specified in the 24 procedure definition, except that the interface may specify a procedure that is not pure if the procedure 25 is defined to be pure. An interface for a procedure named by an ENTRY statement may be specified by 26 using the entry name as the procedure name in the interface body. An explicit specific interface may 27 be specified by an interface body for an external procedure that does not exist in the program if the 28 procedure is never used in any way. A procedure shall not have more than one explicit specific interface 29 in a given scoping unit. 30 NOTE 12.4 The dummy argument names may be different because the name of a dummy argument is not a characteristic. The IMPORT statement specifies that the named entities from the host scoping unit are accessible in 31 the interface body by host association. An entity that is imported in this manner and is defined in the 32 host scoping unit shall be explicitly declared prior to the interface body. The name of an entity made 33 accessible by an IMPORT statement shall not appear in any of the contexts described in 16.5.1.4 that 34 cause the host entity of that name to be inaccessible. 35 Within an interface body, if an IMPORT statement with no import-name-list appears, each host entity 36 not named in an IMPORT statement also is made accessible by host association if its name does not 37 appear in any of the contexts described in 16.5.1.4 that cause the host entity of that name to be 38 inaccessible. If an entity that is made accessible by this means is accessed by host association and is 39 defined in the host scoping unit, it shall be explicitly declared prior to the interface body. 40 302 2006/07/11 WORKING DRAFT J3/06-007 NOTE 12.5 An example of an interface block without a generic specification 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.1); for example: EXT3 (Q = P_MASK (N+1 : N+1000), P = ACTUAL_P) 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. A generic interface block specifies a generic interface for each of the procedures in the interface 1 303 J3/06-007 WORKING DRAFT 2006/07/11 block. The PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, 1 or module procedures that have this generic interface. A generic interface is always explicit. 2 Any procedure may be referenced via its specific interface if the specific interface is accessible. It also 3 may be referenced via a generic interface. The generic-spec in an interface-stmt is a generic identifier 4 for all the procedures in the interface block. The rules specifying how any two procedures with the same 5 generic identifier shall differ are given in 16.3.4. They ensure that any generic invocation applies to at 6 most one specific procedure. 7 A generic name specifies a single name to reference all of the procedure names in the interface block. 8 A generic name may be the same as any one of the procedure names in the interface block, or the same 9 as any accessible generic name. 10 A generic name may be the same as a derived-type name, in which case all of the procedures in the 11 interface block shall be functions. 12 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 An interface-stmt having a dtio-generic-spec is an interface for a user-defined derived-type input/output 13 procedure (9.5.3.7) 14 12.4.2.1.1 Defined op erations 15 If OPERATOR is specified in a generic specification, all of the procedures specified in the generic interface 16 shall be functions that may be referenced as defined operations (7.1.3, 7.1.8.8, 7.2, 12.5). In the case of 17 functions of two arguments, infix binary operator notation is implied. In the case of functions of one 18 argument, prefix operator notation is implied. OPERATOR shall not be specified for functions with no 19 arguments or for functions with more than two arguments. The dummy arguments shall be nonoptional 20 dummy data ob jects and shall be specified with INTENT (IN). The function result shall not have assumed 21 character length. If the op erator is an intrinsic-operator (R310), the numb er of function arguments shall 22 be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of 23 the dummy arguments shall differ from those required for the intrinsic operation (7.1.2). 24 A defined operation is treated as a reference to the function. For a unary defined operation, the operand 25 corresponds to the function's dummy argument; for a binary operation, the left-hand operand corre- 26 304 2006/07/11 WORKING DRAFT J3/06-007 sponds to the first dummy argument of the function and the right-hand operand corresponds to the 1 second dummy argument. 2 NOTE 12.8 An example of the use of the OPERATOR generic specification is: INTERFACE OPERATOR ( * ) 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 A given defined operator may, as with generic names, apply to more than one function, in which case 3 it is generic in exact analogy to generic procedure names. For intrinsic operator symbols, the generic 4 properties include the intrinsic operations they represent. Because both forms of each relational operator 5 have the same interpretation (7.2), extending one form (such as <=) has the effect of defining both forms 6 (<= and .LE.). 7 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 (16.3.4), so it is not possible to define a generic operator that has one procedure for pointers and another procedure for nonpointers. 12.4.2.1.2 Defined assignments 8 If ASSIGNMENT ( = ) is specified in a generic specification, all the procedures in the generic interface 9 shall be subroutines that may be referenced as defined assignments (7.4.1.4). Defined assignment may, 10 as with generic names, apply to more than one subroutine, in which case it is generic in exact analogy 11 to generic procedure names. 12 Each of these subroutines shall have exactly two dummy arguments. The dummy arguments shall be 13 nonoptional dummy data ob jects. The first argument shall have INTENT (OUT) or INTENT (INOUT) 14 and the second argument shall have INTENT (IN). Either the second argument shall be an array whose 15 rank differs from that of the first argument, the declared types and kind type parameters of the arguments 16 shall not conform as specified in Table 7.10, or the first argument shall be of derived type. A defined 17 assignment is treated as a reference to the subroutine, with the left-hand side as the first argument 18 and the right-hand side enclosed in parentheses as the second argument. The ASSIGNMENT generic 19 305 J3/06-007 WORKING DRAFT 2006/07/11 specification specifies that assignment is extended or redefined. 1 NOTE 12.10 An example of the use of the ASSIGNMENT generic specification is: INTERFACE ASSIGNMENT ( = ) 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.2.1.3 User-defined derived-typ e input/output pro cedure interfaces 2 All of the procedures specified in an interface block for a user-defined derived-type input/output proce- 3 dure shall be subroutines that have interfaces as described in 9.5.3.7.2. 4 12.4.2.2 EXTERNAL statement 5 An EXTERNAL statement specifies the EXTERNAL attribute (5.3.8) for a list of names. 6 R1210 external-stmt is EXTERNAL [ :: ] external-name -list 7 The appearance of the name of a block data program unit in an EXTERNAL statement confirms that 8 the block data program unit is a part of the program. 9 NOTE 12.11 For explanatory information on potential portability problems with external procedures, see sub- clause C.9.1. NOTE 12.12 An example of an EXTERNAL statement is: EXTERNAL FOCUS 12.4.2.3 Pro cedure declaration statement 10 A procedure declaration statement declares procedure pointers, dummy procedures, and external pro- 11 cedures. It specifies the EXTERNAL attribute (5.3.8) for all procedure entities in the proc-decl -list. 12 R1211 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] ) 13 [ [ , proc-attr-spec ] ... :: ] proc-decl -list 14 306 2006/07/11 WORKING DRAFT J3/06-007 R1212 proc-interface is interface-name 1 or declaration-type-spec 2 R1213 proc-attr-spec is access-spec 3 or proc-language-binding-spec 4 or INTENT ( intent-spec ) 5 or OPTIONAL 6 or POINTER 7 or SAVE 8 R1214 proc-decl is procedure-entity-name [ => proc-pointer-init ] 9 R1215 interface-name is name R1216 proc-pointer-init is nul l-init 10 or initial-proc-target 11 R1217 initial-proc-target is procedure-name 12 13 C1213 (R1215) The name shall be the name of an abstract interface or of a procedure that has an 14 explicit interface. If name is declared by a procedure-declaration-stmt it shall be previously 15 declared. If name denotes an intrinsic procedure it shall be one that is listed in 13.6 and not 16 marked with a bullet (·). 17 C1214 (R1215) The name shall not be the same as a keyword that specifies an intrinsic type. 18 C1215 If a procedure entity has the INTENT attribute or SAVE attribute, it shall also have the 19 POINTER attribute. 20 C1216 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall 21 specify an external procedure. 22 C1217 (R1214) If => appears in proc-decl , the procedure entity shall have the POINTER attribute. 23 C1218 (R1217) The procedure-name shall be the name of an initialization target. 24 C1219 (R1211) If proc-language-binding-spec with a NAME= is specified, then proc-decl -list shall con- 25 tain exactly one proc-decl , which shall neither have the POINTER attribute nor be a dummy 26 procedure. 27 C1220 (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an 28 interface-name , and interface-name shall be declared with a proc-language-binding-spec . 29 If proc-interface appears and consists of interface-name , it specifies an explicit specific interface (12.4.2.1) 30 for the declared procedures or procedure pointers. The abstract interface (12.4) is that specified by the 31 interface named by interface-name . 32 If proc-interface appears and consists of declaration-type-spec , it specifies that the declared procedures 33 or procedure pointers are functions having implicit interfaces and the specified result type. If a type is 34 specified for an external function, its function definition (12.6.2.1) shall specify the same result type and 35 type parameters. 36 If proc-interface does not appear, the procedure declaration statement does not specify whether the 37 declared procedures or procedure pointers are subroutines or functions. 38 If a proc-attr-spec other than a proc-language-binding-spec appears, it specifies that the declared proce- 39 dures or procedure pointers have that attribute. These attributes are described in 5.3. If a proc-language- 40 binding-spec with NAME= appears, it specifies a binding label or its absence, as described in 15.5.2. 41 A proc-language-binding-spec without a NAME= is allowed, but is redundant with the proc-interface 42 required by C1220. 43 A procedure is an initialization target if it is a nonelemental external or module procedure, or a specific 44 307 J3/06-007 WORKING DRAFT 2006/07/11 intrinsic function listed in 13.6 and not marked with a bullet (·). 1 If => appears in a proc-decl in a procedure-declaration-stmt it specifies the initial association status 2 of the corresponding procedure entity, and implies the SAVE attribute, which may be confirmed by 3 explicit specification. If => nul l-init appears, the procedure entity is initially disassociated. If => 4 initial-proc-target appears, the procedure entity is initially associated with the target. 5 If proc-entity-name has an explicit interface, its characteristics shall be the same as initial-proc-target 6 except that initial-proc-target may be pure even if proc-entity-name is not pure and initial-proc-target 7 may be an elemental intrinsic procedure. 8 If the characteristics of proc-entity-name or initial-proc-target are such that an explicit interface is 9 required, both proc-entity-name and initial-proc-target shall have an explicit interface. 10 If proc-entity-name has an implicit interface and is explicitly typed or referenced as a function, initial- 11 proc-target shall be a function. If proc-entity-name has an implicit interface and is referenced as a 12 subroutine, initial-proc-target shall be a subroutine. 13 If initial-proc-target and proc-entity-name are functions, they shall have the same type; corresponding 14 type parameters shall either both be deferred or both have the same value. 15 NOTE 12.13 In contrast to the EXTERNAL statement, it is not possible to use the PROCEDURE statement to identify a BLOCK DATA subprogram. NOTE 12.14 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) REAL, INTENT (IN) :: X END SUBROUTINE SUB END INTERFACE !-- Some external or dummy procedures with explicit interface. PROCEDURE (REAL_FUNC) :: BESSEL, GAMMA 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_GAMMA !-- 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. 308 2006/07/11 WORKING DRAFT J3/06-007 NOTE 12.14 (cont.) TYPE(STRUCT_TYPE) :: STRUCT !-- An external or dummy function with implicit interface PROCEDURE (REAL) :: PSI 12.4.2.4 INTRINSIC statement 1 An INTRINSIC statement specifies a list of names that have the INTRINSIC attribute (5.3.10). 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.15 A name shall not be explicitly specified to have both the EXTERNAL and INTRINSIC attributes in the same scoping unit. 12.4.2.5 Implicit interface sp ecification 5 In a scoping unit where the interface of a function is implicit, the type and type parameters of the 6 function result are specified by an implicit or explicit type specification of the function name. The type, 7 type parameters, and shape of dummy arguments of a procedure invoked from a scoping unit where the 8 interface of the procedure is implicit shall be such that the actual arguments are consistent with the 9 characteristics of the dummy arguments. 10 12.5 Procedure reference 11 The form of a procedure reference is dependent on the interface of the procedure or procedure pointer, 12 but is independent of the means by which the procedure is defined. The forms of procedure references 13 are: 14 R1219 function-reference is procedure-designator ( [ actual-arg-spec -list ] ) 15 C1222 (R1219) The procedure-designator shall designate a function. 16 C1223 (R1219) The actual-arg-spec -list shall not contain an alt-return-spec . 17 R1220 cal l-stmt is CALL procedure-designator [ ( [ actual-arg-spec -list ] ) ] 18 C1224 (R1220) The procedure-designator shall designate a subroutine. 19 R1221 procedure-designator is procedure-name 20 or proc-component-ref 21 or data-ref % binding-name 22 C1225 (R1221) A procedure-name shall be the name of a procedure or procedure pointer. 23 C1226 (R1221) A binding-name shall be a binding name (4.5.5) of the declared type of data-ref . 24 C1227 (R1221) If data-ref is an array, the referenced type-bound procedure shall have the PASS at- 25 tribute. 26 Resolving references to type-bound procedures is described in 12.5.5. 27 A function may also be referenced as a defined operation (12.4.2.1.1). A subroutine may also be referenced 28 309 J3/06-007 WORKING DRAFT 2006/07/11 as a defined assignment (12.4.2.1.2). 1 NOTE 12.16 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 2 R1223 actual-arg is expr 3 or variable 4 or procedure-name 5 or proc-component-ref 6 or 7 alt-return-spec 8 R1224 alt-return-spec is * label C1228 (R1222) The keyword = shall not appear if the interface of the procedure is implicit in the 9 scoping unit. 10 C1229 (R1222) The keyword = shall not be omitted from an actual-arg-spec unless it has been omitted 11 from each preceding actual-arg-spec in the argument list. 12 C1230 (R1222) Each keyword shall be the name of a dummy argument in the explicit interface of the 13 procedure. 14 C1231 (R1223) A nonintrinsic elemental procedure shall not be used as an actual argument. 15 C1232 (R1223) A procedure-name shall be the name of an external, internal, module, or dummy proce- 16 dure, a specific intrinsic function listed in 13.6 and not marked with a bullet (·), or a procedure 17 pointer. 18 C1233 (R1223) In a reference to a pure procedure, a procedure-name actual-arg shall be the name of a 19 pure procedure (12.7). 20 NOTE 12.17 This constraint ensures that the purity of a procedure cannot be undermined by allowing it to call a nonpure procedure. C1234 (R1224) The label shall be the statement label of a branch target statement that appears in the same scoping 21 22 unit as the cal l-stmt . NOTE 12.18 Successive commas shall not be used to omit optional arguments. NOTE 12.19 Examples of procedure reference using procedure pointers: P => BESSEL WRITE (*, *) P(2.5) !-- BESSEL(2.5) S => PRINT_REAL CALL S(3.14) 310 2006/07/11 WORKING DRAFT J3/06-007 12.5.1 Actual arguments, dummy arguments, and argument asso ciation 1 12.5.1.1 Argument corresp ondence 2 In either a subroutine reference or a function reference, the actual argument list identifies the corre- 3 spondence between the actual arguments supplied and the dummy arguments of the procedure. This 4 correspondence may be established either by keyword or by position. If an argument keyword appears, 5 the actual argument corresponds to the dummy argument whose name is the same as the argument 6 keyword (using the dummy argument names from the interface accessible in the scoping unit containing 7 the procedure reference). In the absence of an argument keyword, an actual argument corresponds to the 8 dummy argument occupying the corresponding position in the reduced dummy argument list; that is, 9 the first actual argument corresponds to the first dummy argument in the reduced list, the second actual 10 argument corresponds to the second dummy argument in the reduced list, etc. The reduced dummy 11 argument list is either the full dummy argument list or, if there is a passed-ob ject dummy argument 12 (4.5.4.4), the dummy argument list with the passed ob ject dummy argument omitted. Exactly one 13 actual argument shall correspond to each nonoptional dummy argument. At most one actual argument 14 shall correspond to each optional dummy argument. Each actual argument shall correspond to a dummy 15 argument. 16 NOTE 12.20 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. 12.5.1.2 The passed-object dummy argument and argument corresp ondence 17 In a reference to a type-bound procedure, or a procedure pointer component, that has a passed-ob ject 18 dummy argument (4.5.4.4), the data-ref of the function-reference or cal l-stmt corresponds, as an actual 19 argument, with the passed-ob ject dummy argument. 20 12.5.1.3 Argument asso ciation 21 Except in references to intrinsic inquiry functions, if a nonoptional nonpointer dummy argument corre- 22 sponds to a pointer actual argument, the actual argument shall be pointer associated with a target and 23 the dummy argument becomes argument associated with that target. If an optional nonpointer dummy 24 argument corresponds to a pointer actual argument that is pointer associated with a target the dummy 25 argument becomes argument associated with that target. A present nonpointer dummy argument that 26 corresponds to a nonpointer actual argument becomes argument associated with that actual argument. 27 311 J3/06-007 WORKING DRAFT 2006/07/11 A present pointer dummy argument that corresponds to a pointer actual argument becomes argument 1 associated with that actual argument. A present pointer dummy argument that does not correspond to 2 a pointer actual argument is not argument associated. 3 12.5.1.4 Actual arguments asso ciated with dummy data objects 4 If a dummy argument is neither allocatable nor a pointer, it shall be type compatible or bits compatible 5 (4.3.1.3) with the associated actual argument. If a dummy argument is allocatable or a pointer, the 6 associated actual argument shall be polymorphic if and only if the dummy argument is polymorphic, 7 and either both the actual and dummy arguments shall be unlimited polymorphic, or the declared type 8 of the actual argument shall be the same as the declared type of the dummy argument. 9 NOTE 12.21 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. Unless the actual argument and the corresponding dummy argument are bits compatible, the type 10 parameter values of the actual argument shall agree with the corresponding ones of the dummy argument 11 that are not assumed or deferred, except for the case of the character length parameter of an actual 12 argument of type default character associated with a dummy argument that is not assumed shape. 13 If a scalar dummy argument is of type default character, the length len of the dummy argument shall 14 be less than or equal to the length of the actual argument. The dummy argument becomes associated 15 with the leftmost len characters of the actual argument. If an array dummy argument is of type default 16 character and is not assumed shape, it becomes associated with the leftmost characters of the actual 17 argument element sequence (12.5.1.8) and it shall not extend beyond the end of that sequence. 18 The values of assumed type parameters of a dummy argument are assumed from the corresponding type 19 parameters of the associated actual argument. 20 An actual argument associated with a dummy argument that is allocatable or a pointer shall have 21 deferred the same type parameters as the dummy argument. 22 If the actual argument is a co-indexed ob ject, the dummy argument shall not be a co-array and shall 23 have the INTENT(IN) or the VALUE attribute. 24 312 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 50 It doesn't seem like forcing the user to write localvar = x[i] CALL sub(localvar) x[i] = localvar is a substantial improvement in, well, anything. Not to mention that the user cannot do that if x[i] is undefined or only partially defined before the call to sub. It doesn't seem to be any more work for the processor than what it already does for CALL sub(a(1:n:2)) for explicit-shape dummies. And, MUCH WORSE, this makes defined assignment unusable with co-arrays. Can we say "not even integrated with Fortran 90"? Subgroup said: "this requires more complications to the memory consistency rules since the copy out may overwrite other changes to the variable." The editor says: That is just so untrue it is not funny. Is everyone REALLY that ignorant of our dummy argument aliasing rules? We've not repealed them, and there are no edits to subvert them for co-arrays. If they need to be subverted (something I doubt, but maybe the go-faster department want to go slower), something needs to be done. Either way this is a serious technical flaw. NOTE 12.22 If the actual argument is a co-indexed ob ject and the corresponding dummy argument is not a co- array, it is likely that a processor will make a copy on the executing image of the actual argument, including copies of any allocated allocatable subcomponents, before argument association occurs. J3 internal note Unresolved Technical Issue 51 That doesn't seem likely for the vast ma jority of Fortran processing systems, which are going to be shared-memory small-cpu-count. They are, presumably, going to do the "right thing" here. That does not involve making any copies. Anyway, what's this "and the ... dummy is not a co-array." guff. Last time I looked, a co-indexed ob ject was not a valid actual argument to a co-array dummy. If the dummy argument is a pointer that does not have the INTENT(IN) attribute, the actual argument 1 shall be a pointer. Otherwise, the actual argument shall be a pointer or a valid target for the dummy 2 pointer in an assignment statement. If the actual argument is not a pointer, the dummy pointer becomes 3 pointer-associated with the actual argument. 4 If the dummy argument and actual argument are pointers, the ranks shall agree and either the non- 5 deferred type parameters shall agree or the actual argument and the dummy argument shall be bits 6 compatible. If a dummy pointer has the CONTIGUOUS attribute, the actual argument shall have the 7 CONTIGUOUS attribute. 8 313 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 52 Argument-associating pointers of different types does not seem to be in accordance with the spirit of our current rules. It requires a processor to use the same representation for pointers of different kinds or to do copyin/copyout conversions. Why are we doing this? Furthermore, this "pseudo-polymorphism" for bits leads directly to INTEGER pointers being associated with REAL targets. This will be a serious inhibition on optimisation. It is an open invitation to programming errors and nonportable hacks. NOTE: A similar comment would apply to pointer assignment if one is allowed to turn a bits pointer into another pointer (the term "bits compatible" not being well-defined as yet, I don't know whether this is the case). Fiddling with the bits is one thing, but removing the type restrictions on our pointers is simply unacceptable both from a software engineering point of view and from a performance point of view. If a dummy argument is allocatable, the actual argument shall be allocatable, the ranks shall agree, and 1 either the nondeferred type parameters shall agree or the actual argument and the dummy argument 2 shall be bits compatible. It is permissible for the actual argument to have an allocation status of 3 unallocated. 4 J3 internal note Unresolved Technical Issue 53 Argument-associating allocatables of different types does not seem to be in accordance with the spirit of our current rules. It requires a processor to use the same representation for allocatables of different kinds or to do copyin/copyout conversions. Why are we doing this? Furthermore, the very concept of having allocatable entities of REAL and INTEGER types being associated with one another is blood-curdling. Just how far the implications of this would go I am not sure; certainly they are not good for reliability and portability, whether performance suffers as well I cannot say without spending considerable effort. This butchery of our association rules does not seem at all necessary for BITS to be useful. At the invocation of the procedure, the pointer association status of an actual argument associated with 5 a pointer dummy argument becomes undefined if the dummy argument has INTENT(OUT). 6 Except in references to intrinsic inquiry functions, if a nonoptional dummy argument is not allocatable 7 and the actual argument is allocatable, the corresponding actual argument shall be allocated. 8 If the dummy argument has the VALUE attribute it becomes associated with a definable anonymous 9 data ob ject whose initial value is that of the actual argument. Subsequent changes to the value or 10 definition status of the dummy argument do not affect the actual argument. 11 NOTE 12.23 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. The actual mechanism by which this happens is determined by the processor. If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with 12 the actual argument do not become associated with the corresponding dummy argument on invocation 13 of the procedure. If such a dummy argument is used as an actual argument that is associated with 14 a dummy argument with the TARGET attribute, whether any pointers associated with the original 15 actual argument become associated with the dummy argument with the TARGET attribute is processor 16 dependent. 17 If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and is either a 18 314 2006/07/11 WORKING DRAFT J3/06-007 scalar or an assumed-shape array that does not have the CONTIGUOUS attribute, and the corresponding 1 actual argument has the TARGET attribute but is not a co-indexed ob ject or an array section with a 2 vector subscript then 3 (1) any pointers associated with the actual argument become associated with the corresponding 4 dummy argument on invocation of the procedure, and 5 (2) when execution of the procedure completes, any pointers that do not become undefined 6 (16.5.2.2.3) and are associated with the dummy argument remain associated with the actual 7 argument. 8 If the dummy argument has the TARGET attribute and is an explicit-shape array, an assumed-shape ar- 9 ray with the CONTIGUOUS attribute, or an assumed-size array, and the corresponding actual argument 10 has the TARGET attribute but is not an array section with a vector subscript then 11 (1) on invocation of the procedure, whether any pointers associated with the actual argument 12 become associated with the corresponding dummy argument is processor dependent, and 13 (2) when execution of the procedure completes, the pointer association status of any pointer 14 that is pointer associated with the dummy argument is processor dependent. 15 If the dummy argument has the TARGET attribute and the corresponding actual argument does not 16 have the TARGET attribute or is an array section with a vector subscript, any pointers associated with 17 the dummy argument become undefined when execution of the procedure completes. 18 If the dummy argument has the TARGET attribute and the VALUE attribute, any pointers associated 19 with the dummy argument become undefined when execution of the procedure completes. 20 If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual 21 argument is of type default character, of type character with the C character kind (15.2), or is an element 22 or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array. If 23 the procedure is nonelemental and is referenced by a generic name or as a defined operator or defined 24 assignment, the ranks of the actual arguments and corresponding dummy arguments shall agree. 25 If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as 26 the rank of the dummy argument; the actual argument shall not be an assumed-size array (including an 27 array element designator or an array element substring designator). 28 Except when a procedure reference is elemental (12.8), each element of an array actual argument or of 29 a sequence in a sequence association (12.5.1.8) is associated with the element of the dummy array that 30 has the same position in array element order (6.2.2.2). 31 NOTE 12.24 For type default character sequence associations, the interpretation of element is provided in 12.5.1.8. A scalar dummy argument of a nonelemental procedure may be associated only with a scalar actual 32 argument. 33 If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT), the argument associated 34 entity shall be definable. If a dummy argument has INTENT (OUT), the argument associated entity 35 becomes undefined at the time the association is established, except for components of an ob ject of de- 36 rived type for which default initialization has been specified. If the dummy argument is not polymorphic 37 and the type of the actual argument is an extension type of the type of the dummy argument, only the 38 part of the actual argument that is of the same type as the dummy argument becomes undefined. 39 If the actual argument is an array section having a vector subscript, the dummy argument is not defin- 40 able and shall not have the INTENT (OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS 41 315 J3/06-007 WORKING DRAFT 2006/07/11 attributes. 1 NOTE 12.25 Argument intent specifications serve several purposes. See Note 5.16. NOTE 12.26 For more explanatory information on argument association and evaluation, see subclause C.9.5. For more explanatory information on pointers and targets as dummy arguments, see subclause C.9.6. J3 internal note Unresolved Technical Issue 55 Probably need this constraint: C1235 An actual argument that is a co-indexed ob ject shall not be associated with a dummy argument that has the ASYNCHRONOUS attribute. It is true that allowing VALUE+ASYNCHRONOUS makes a mockery of the restrictions on ASYNCHRONOUS dummies and note (04-007) 12.26 about their purpose. But should co-arrays try to be consistent or should they copy this inconsistency? C1236 (R1223) If an actual argument is an array section or an assumed-shape array, and the corre- 2 sponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that 3 dummy argument shall be an assumed-shape array. 4 C1237 (R1223) If an actual argument is a pointer array, and the corresponding dummy argument 5 has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an 6 assumed-shape array that does not have the CONTIGUOUS attribute or a pointer array. 7 NOTE 12.27 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. 12.5.1.5 Co-array arguments 8 The actual argument shall be an allocatable co-array if and only if the dummy argument is an allocatable 9 co-array with the same rank and co-rank. 10 If a dummy argument is a nonallocatable co-array, the co-rank and co-bounds are specified by the local 11 declaration and are independent of those of the actual argument. The actual argument shall be a co-array 12 or a subob ject of a co-array without any co-subscripts, vector-valued subscripts, allocatable component 13 selection, or pointer component selection. 14 316 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note (cont.) J3 internal note Unresolved Technical Issue 54 Broken. I assume you want to be able to pass VARIABLE%CO_ARRAY_COMPONENT to a dummy co-array, no? Subgroup says yes. It's not entirely trivial to fix the wording though. (It probably needs to be something like "no part-ref after the part-ref with co-rank non-zero shall have the pointer or allocatable attribute, or have a vector-valued subscript".) NOTE 12.28 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.29 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. If an assumed-shape co-array that does not have the CONTIGUOUS attribute or a subob ject of an 1 assumed-shape co-array that does not have the CONTIGUOUS attribute is an actual argument associ- 2 ated with a dummy co-array, the dummy co-array shall be of assumed shape. 3 If an array section is an actual argument associated with a dummy co-array that is not of assumed shape 4 or has the CONTIGUOUS attribute, the section shall be contiguous (5.3.6). 5 NOTE 12.30 The constraints on actual arguments that correspond 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. J3 internal note Unresolved Technical Issue 79 This constraint on dummy co-arrays and their arguments appears to be unnecessary without some relaxation in the rules in 12.5.1.10 (the "high performance" rules for Fortran dummy arguments). 317 J3/06-007 WORKING DRAFT 2006/07/11 12.5.1.6 Actual arguments asso ciated with dummy pro cedure entities 1 If the actual argument is the name of an internal subprogram, the host instance of the dummy argument 2 is the innermost currently executing instance of the host of that internal subprogram. If the actual 3 argument has a host instance the host instance of the dummy argument is that instance. Otherwise the 4 dummy argument has no host instance. 5 If a dummy argument is a procedure pointer, the associated actual argument shall be a procedure pointer, 6 a reference to a function that returns a procedure pointer, or a reference to the NULL intrinsic function. 7 If a dummy argument is a dummy procedure without the POINTER attribute, the associated actual 8 argument shall be an external, internal, module, or dummy procedure, or a specific intrinsic procedure 9 listed in 13.6 and not marked with a bullet (·). If the specific name is also a generic name, only the 10 specific procedure is associated with the dummy argument. 11 If an external procedure name or a dummy procedure name is used as an actual argument, its interface 12 shall be explicit or it shall be explicitly declared to have the EXTERNAL attribute. 13 If the interface of the dummy argument is explicit, the characteristics listed in 12.3 shall be the same 14 for the associated actual argument and the corresponding dummy argument, except that a pure actual 15 argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual 16 procedure may be associated with a dummy procedure (which is prohibited from being elemental). 17 If the interface of the dummy argument is implicit and either the name of the dummy argument is 18 explicitly typed or it is referenced as a function, the dummy argument shall not be referenced as a 19 subroutine and the actual argument shall be a function, function procedure pointer, or dummy procedure. 20 If the interface of the dummy argument is implicit and a reference to it appears as a subroutine reference, 21 the actual argument shall be a subroutine, subroutine procedure pointer, or dummy procedure. 22 12.5.1.7 Actual arguments asso ciated with alternate return indicators 23 24 If a dummy argument is an asterisk (12.6.2.2), the asso ciated actual argument shall be an alternate return specifier (12.5). 12.5.1.8 Sequence asso ciation 25 An actual argument represents an element sequence if it is an array expression, an array element 26 designator, a scalar of type default character, or a scalar of type character with the C character kind 27 (15.2.2). If the actual argument is an array expression, the element sequence consists of the elements 28 in array element order. If the actual argument is an array element designator, the element sequence 29 consists of that array element and each element that follows it in array element order. 30 If the actual argument is of type default character or of type character with the C character kind, and is 31 an array expression, array element, or array element substring designator, the element sequence consists 32 of the storage units beginning with the first storage unit of the actual argument and continuing to the 33 end of the array. The storage units of an array element substring designator are viewed as array elements 34 consisting of consecutive groups of storage units having the character length of the dummy array. 35 If the actual argument is of type default character or of type character with the C character kind, and 36 is a scalar that is not an array element or array element substring designator, the element sequence 37 consists of the storage units of the actual argument. 38 NOTE 12.31 Some of the elements in the element sequence may consist of storage units from different elements of the original array. 318 2006/07/11 WORKING DRAFT J3/06-007 An actual argument that represents an element sequence and corresponds to a dummy argument that is 1 an array is sequence associated with the dummy argument if the dummy argument is an explicit-shape 2 or assumed-size array. The rank and shape of the actual argument need not agree with the rank and 3 shape of the dummy argument, but the number of elements in the dummy argument shall not exceed 4 the number of elements in the element sequence of the actual argument. If the dummy argument is 5 assumed-size, the number of elements in the dummy argument is exactly the number of elements in the 6 element sequence. 7 12.5.1.9 Argument presence and restrictions on arguments not present 8 A dummy argument or an entity that is host associated with a dummy argument is not present if the 9 dummy argument 10 (1) does not correspond to an actual argument, 11 (2) corresponds to an actual argument that is not present, or 12 (3) does not have the ALLOCATABLE or POINTER attribute, and corresponds to an actual 13 argument that 14 (a) has the ALLOCATABLE attribute and is not allocated, or 15 (b) has the POINTER attribute and is disassociated. 16 Otherwise, it is present. A nonoptional dummy argument shall be present. If an optional nonpointer 17 dummy argument corresponds to a pointer actual argument, the pointer association status of the actual 18 argument shall not be undefined. 19 An optional dummy argument that is not present is sub ject to the following restrictions. 20 (1) If it is a data ob ject, it shall not be referenced or be defined. If it is of a type for which 21 default initialization is specified for some component, the initialization has no effect. 22 (2) It shall not be used as the data-target or proc-target of a pointer assignment. 23 (3) If it is a procedure or procedure pointer, it shall not be invoked. 24 (4) It shall not be supplied as an actual argument corresponding to a nonoptional dummy 25 argument other than as the argument of the PRESENT intrinsic function or as an argument 26 of a function reference that meets the requirements of (6) or (8) in 7.1.7. 27 (5) A designator with it as the base ob ject and with at least one subob ject selector shall not 28 be supplied as an actual argument. 29 (6) If it is an array, it shall not be supplied as an actual argument to an elemental procedure 30 unless an array of the same rank is supplied as an actual argument corresponding to a 31 nonoptional dummy argument of that elemental procedure. 32 (7) If it is a pointer, it shall not be allocated, deallocated, nullified, pointer-assigned, or supplied 33 as an actual argument corresponding to an optional nonpointer dummy argument. 34 (8) If it is allocatable, it shall not be allocated, deallocated, or supplied as an actual argument 35 corresponding to an optional nonallocatable dummy argument. 36 (9) If it has length type parameters, they shall not be the sub ject of an inquiry. 37 (10) It shall not be used as the selector in a SELECT TYPE or ASSOCIATE construct. 38 Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional 39 dummy argument, which is then also considered not to be associated with an actual argument. 40 12.5.1.10 Restrictions on entities asso ciated with dummy arguments 41 While an entity is associated with a dummy argument, the following restrictions hold. 42 (1) Action that affects the allocation status of the entity or a subob ject thereof shall be taken 43 through the dummy argument. Action that affects the value of the entity or any subob ject 44 319 J3/06-007 WORKING DRAFT 2006/07/11 of it shall be taken only through the dummy argument unless 1 (a) the dummy argument has the POINTER attribute or 2 (b) the dummy argument has the TARGET attribute, the dummy argument does not 3 have INTENT (IN), the dummy argument is a scalar ob ject or an assumed-shape 4 array, and the actual argument is a target other than an array section with a vector 5 subscript. 6 NOTE 12.32 In SUBROUTINE OUTER REAL, POINTER :: A (:) ... 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 320 2006/07/11 WORKING DRAFT J3/06-007 NOTE 12.32 (cont.) DEALLOCATE (A) and DEALLOCATE (B) would be permitted, but not both. NOTE 12.33 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 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.34 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.35 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. (2) If the allocation status of the entity or a subob ject thereof is affected through the dummy 1 argument, then at any time during the execution of the procedure, either before or after 2 the allocation or deallocation, it may be referenced only through the dummy argument. If 3 the value the entity or any subob ject of it is affected through the dummy argument, then 4 at any time during the execution of the procedure, either before or after the definition, it 5 may be referenced only through that dummy argument unless 6 (a) the dummy argument has the POINTER attribute or 7 (b) the dummy argument has the TARGET attribute, the dummy argument does not 8 have INTENT (IN), the dummy argument is a scalar ob ject or an assumed-shape 9 321 J3/06-007 WORKING DRAFT 2006/07/11 array, and the actual argument is a target other than an array section with a vector 1 subscript. 2 NOTE 12.36 In MODULE DATA REAL :: W, X, Y, Z END MODULE DATA PROGRAM MAIN 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.37 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. 12.5.2 Function reference 3 A function is invoked during expression evaluation by a function-reference or by a defined operation 4 (7.1.3). When it is invoked, all actual argument expressions are evaluated, then the arguments are 5 associated, and then the function is executed. When execution of the function is complete, the value 6 of the function result is available for use in the expression that caused the function to be invoked. The 7 characteristics of the function result (12.3.2) are determined by the interface of the function. A reference 8 to an elemental function (12.8) is an elemental reference if one or more actual arguments are arrays and 9 all array arguments have the same shape. 10 12.5.3 Subroutine reference 11 A subroutine is invoked by execution of a CALL statement, execution of a defined assignment statement 12 (7.4.1.4), user-defined derived-type input/output(9.5.3.7.1), or finalization(4.5.6). When a subroutine is 13 invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the 14 subroutine is executed. When the actions specified by the subroutine are completed, the execution of 15 the CALL statement, the execution of the defined assignment statement, or the processing of an input 16 or output list item is also completed. If a CALL statement includes one or more alternate return specifiers among 17 18 its arguments, control may b e transferred to one of the statements indicated, dep ending on the action sp ecified by the 322 2006/07/11 WORKING DRAFT J3/06-007 A reference to an elemental subroutine (12.8) is an elemental reference if there is at least one 1 subroutine. actual argument corresponding to an INTENT(OUT) or INTENT(INOUT) dummy argument, all such 2 actual arguments are arrays, and all actual arguments are conformable. 3 12.5.4 Resolving named pro cedure references 4 The rules for interpreting a procedure reference depend on whether the procedure name in the reference 5 is established by the available declarations and specifications to be generic in the scoping unit containing 6 the reference, is established to be only specific in the scoping unit containing the reference, or is not 7 established. 8 A procedure name is established to be generic in a scoping unit 9 (1) if that scoping unit contains an interface block with that name; 10 (2) if that scoping unit contains an INTRINSIC attribute specification for that name and it is 11 the name of a generic intrinsic procedure; 12 (3) if that scoping unit contains a USE statement that makes that procedure name accessible 13 and the corresponding name in the module is established to be generic; or 14 (4) if that scoping unit contains no declarations of that name, that scoping unit has a host 15 scoping unit, and that name is established to be generic in the host scoping unit. 16 A procedure name is established to be only specific in a scoping unit if it is established to be specific 17 and not established to be generic. It is established to be specific 18 (1) if that scoping unit contains a module subprogram, internal subprogram, or statement function 19 that defines a procedure with that name; 20 (2) if that scoping unit contains an INTRINSIC attribute specification for that name and if it 21 is the name of a specific intrinsic procedure; 22 (3) if that scoping unit contains an explicit EXTERNAL attribute specification (5.3.8) for that 23 name; 24 (4) if that scoping unit contains a USE statement that makes that procedure name accessible 25 and the corresponding name in the module is established to be specific; or 26 (5) if that scoping unit contains no declarations of that name, that scoping unit has a host 27 scoping unit, and that name is established to be specific in the host scoping unit. 28 A procedure name is not established in a scoping unit if it is neither established to be generic nor 29 established to be specific. 30 12.5.4.1 Resolving pro cedure references to names established to b e generic 31 If the reference is consistent with a nonelemental reference to one of the specific interfaces of a generic 32 interface that has that name and either is in the scoping unit in which the reference appears or is made 33 accessible by a USE statement in the scoping unit, the reference is to the specific procedure in the 34 interface block that provides that interface. The rules in 16.3.4 ensure that there can be at most one 35 such specific procedure. 36 Otherwise, if the reference is consistent with an elemental reference to one of the specific interfaces of 37 a generic interface that has that name and either is in the scoping unit in which the reference appears 38 or is made accessible by a USE statement in the scoping unit, the reference is to the specific elemental 39 procedure in the interface block that provides that interface. The rules in 16.3.4 ensure that there can 40 be at most one such specific elemental procedure. 41 Otherwise, if the scoping unit contains either an INTRINSIC attribute specification for that name or 42 a USE statement that makes that name accessible from a module in which the corresponding name is 43 specified to have the INTRINSIC attribute, and if the reference is consistent with the interface of that 44 intrinsic procedure, the reference is to that intrinsic procedure. 45 323 J3/06-007 WORKING DRAFT 2006/07/11 Otherwise, if the scoping unit has a host scoping unit, if the name is established to be generic in that 1 host scoping unit, and if there is agreement between the scoping unit and the host scoping unit as to 2 whether the name is a function name or a subroutine name, the name is resolved by applying the rules 3 in this subclause to the host scoping unit. 4 NOTE 12.38 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 = RANF(AA(6:10,2)) is a nonelemental reference to VECTOR RANDOM. NOTE 12.39 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. 12.5.4.2 Resolving pro cedure references to names established to b e only sp ecific 5 If the scoping unit contains an interface body or EXTERNAL attribute specification for the name and 6 the name is the name of a dummy argument of the scoping unit, the dummy argument is a dummy 7 procedure and the reference is to that dummy procedure. That is, the procedure invoked by executing 8 that reference is the procedure supplied as the actual argument corresponding to that dummy procedure. 9 If the scoping unit contains an interface body or EXTERNAL attribute specification for the name and 10 the name is not the name of a dummy argument of the scoping unit, the reference is to an external 11 procedure with that name. 12 If the scoping unit contains a module subprogram, internal subprogram, or statement function that defines 13 a procedure with the name, the reference is to the procedure so defined. 14 If the scoping unit contains an INTRINSIC attribute specification for the name, the reference is to the 15 intrinsic with that name. 16 324 2006/07/11 WORKING DRAFT J3/06-007 If the scoping unit contains a USE statement that makes a procedure accessible by the name, the 1 reference is to that procedure. 2 NOTE 12.40 Because of the renaming facility of the USE statement, the name in the reference may be different from the original name of the procedure. If none of the above apply, the scoping unit shall have a host scoping unit, and the reference is resolved 3 by applying the rules in this subclause to the host scoping unit. 4 12.5.4.3 Resolving pro cedure references to names not established 5 If the name is the name of a dummy argument of the scoping unit, the dummy argument is a dummy 6 procedure and the reference is to that dummy procedure. That is, the procedure invoked by executing 7 that reference is the procedure supplied as the actual argument corresponding to that dummy procedure. 8 Otherwise, if the name is the name of an intrinsic procedure, and if there is agreement between the 9 reference and the status of the intrinsic procedure as being a function or subroutine, the reference is to 10 that intrinsic procedure. 11 Otherwise, the reference is to an external procedure with that name. 12 12.5.5 Resolving typ e-bound pro cedure references 13 If the binding-name in a procedure-designator (R1221) is that of a specific type-bound procedure, the 14 procedure referenced is the one bound to that name in the dynamic type of the data-ref . 15 If the binding-name in a procedure-designator is that of a generic type bound procedure, the generic 16 binding with that name in the declared type of the data-ref is used to select a specific binding using the 17 following criteria. 18 (1) If the reference is consistent with one of the specific bindings of that generic binding, that 19 specific binding is selected. 20 (2) Otherwise, the reference shall be consistent with an elemental reference to one of the specific 21 bindings of that generic binding; that specific binding is selected. 22 The reference is to the procedure bound to the same name as the selected specific binding in the dynamic 23 type of the data-ref . 24 12.6 Procedure definition 25 12.6.1 Intrinsic pro cedure definition 26 Intrinsic procedures are defined as an inherent part of the processor. A standard-conforming processor 27 shall include the intrinsic procedures described in Clause 13, but may include others. However, a 28 standard-conforming program shall not make use of intrinsic procedures other than those described in 29 Clause 13. 30 12.6.2 Pro cedures defined by subprograms 31 When a procedure defined by a subprogram is invoked, an instance (12.6.2.3) of the subprogram is 32 created and executed. Execution begins with the first executable construct following the FUNCTION, 33 SUBROUTINE, or ENTRY statement specifying the name of the procedure invoked. 34 325 J3/06-007 WORKING DRAFT 2006/07/11 12.6.2.1 Function subprogram 1 A function subprogram is a subprogram that has a FUNCTION statement as its first statement. 2 R1225 function-subprogram is function-stmt 3 [ specification-part ] 4 [ execution-part ] 5 [ internal-subprogram-part ] 6 end-function-stmt 7 R1226 function-stmt is [ prefix ] FUNCTION function-name 8 ( [ dummy-arg-name -list ] ) [ suffix ] 9 C1238 (R1226) If RESULT appears, result-name shall not be the same as function-name and shall not 10 be the same as the entry-name in any ENTRY statement in the subprogram. 11 C1239 (R1226) If RESULT appears, the function-name shall not appear in any specification statement 12 in the scoping unit of the function subprogram. 13 R1227 proc-language-binding-spec is language-binding-spec 14 C1240 (R1227) A proc-language-binding-spec with a NAME= specifier shall not be specified in the 15 function-stmt or subroutine-stmt of an interface body for an abstract interface or a dummy 16 procedure. 17 C1241 (R1227) A proc-language-binding-spec shall not be specified for an internal procedure. 18 C1242 (R1227) If proc-language-binding-spec is specified for a procedure, each of the procedure's dummy 19 arguments shall be a nonoptional interoperable variable (15.3.5, 15.3.6) or a nonoptional interop- 20 erable procedure (15.3.7). If proc-language-binding-spec is specified for a function, the function 21 result shall be an interoperable scalar variable. 22 R1228 dummy-arg-name is name 23 C1243 (R1228) A dummy-arg-name shall be the name of a dummy argument. 24 R1229 prefix is prefix-spec [ prefix-spec ] ... 25 R1230 prefix-spec is declaration-type-spec 26 or ELEMENTAL 27 or IMPURE 28 or MODULE 29 or PURE 30 or RECURSIVE 31 C1244 (R1229) A prefix shall contain at most one of each prefix-spec . 32 C1245 (R1229) A prefix shall not specify both PURE and IMPURE. 33 C1246 (R1229) A prefix shall not specify both ELEMENTAL and RECURSIVE. 34 C1247 (R1229) A prefix shall not specify ELEMENTAL if proc-language-binding-spec appears in the 35 function-stmt or subroutine-stmt . 36 C1248 (R1229) MODULE shall appear only within the function-stmt or subroutine-stmt of a module 37 subprogram or of an interface body that is declared in the scoping unit of a module or submodule. 38 C1249 (R1229) If MODULE appears within the prefix in a module subprogram, an accessible module 39 procedure interface having the same name as the subprogram shall be declared in the module 40 or submodule in which the subprogram is defined, or shall be declared in an ancestor of that 41 326 2006/07/11 WORKING DRAFT J3/06-007 program unit. 1 C1250 (R1229) If MODULE appears within the prefix in a module subprogram, the subprogram shall 2 specify the same characteristics and dummy argument names as its corresponding (12.6.2.4) 3 module procedure interface body. 4 C1251 (R1229) If MODULE appears within the prefix in a module subprogram and a binding label 5 is specified, it shall be the same as the binding label specified in the corresponding module 6 procedure interface body. 7 C1252 (R1229) If MODULE appears within the prefix in a module subprogram, RECURSIVE shall 8 appear if and only if RECURSIVE appears in the prefix in the corresponding module procedure 9 interface body. 10 R1231 suffix is proc-language-binding-spec [ RESULT ( result-name ) ] 11 or RESULT ( result-name ) [ proc-language-binding-spec ] 12 R1232 end-function-stmt is END [ FUNCTION [ function-name ] ] 13 C1253 (R1225) An internal function subprogram shall not contain an ENTRY statement. 14 C1254 (R1225) An internal function subprogram shall not contain an internal-subprogram-part . 15 C1255 (R1232) If a function-name appears in the end-function-stmt , it shall be identical to the function- 16 name specified in the function-stmt . 17 The name of the function is function-name . 18 The type and type parameters (if any) of the result of the function defined by a function subprogram 19 may be specified by a type specification in the FUNCTION statement or by the name of the result 20 variable appearing in a type declaration statement in the declaration part of the function subprogram. 21 They shall not be specified both ways. If they are not specified either way, they are determined by 22 the implicit typing rules in force within the function subprogram. If the function result is an array, 23 allocatable, or a pointer, this shall be specified by specifications of the name of the result variable within 24 the function body. The specifications of the function result attributes, the specification of dummy 25 argument attributes, and the information in the procedure heading collectively define the characteristics 26 of the function (12.3). 27 The prefix-spec RECURSIVE shall appear if the function directly or indirectly invokes itself or a function 28 defined by an ENTRY statement in the same subprogram. Similarly, RECURSIVE shall appear if a 29 function defined by an ENTRY statement in the subprogram directly or indirectly invokes itself, another 30 function defined by an ENTRY statement in that subprogram, or the function defined by the FUNCTION 31 statement. 32 If RESULT appears, the name of the result variable of the function is result-name and all occurrences 33 of the function name in execution-part statements in the scoping unit refer to the function itself. If 34 RESULT does not appear, the result variable is function-name and all occurrences of the function name 35 in execution-part statements in the scoping unit are references to the result variable. The characteristics 36 (12.3.2) of the function result are those of the result variable. On completion of execution of the function, 37 the value returned is that of its result variable. If the function result is a pointer, the shape of the value 38 returned by the function is determined by the shape of the result variable when the execution of the 39 function is completed. If the result variable is not a pointer, its value shall be defined by the function. 40 If the function result is a pointer, the function shall either associate a target with the result variable 41 pointer or cause the association status of this pointer to become defined as disassociated. 42 327 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 12.41 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. If the prefix-spec PURE appears, or the prefix-spec ELEMENTAL appears and IMPURE does not appear, 1 the subprogram is a pure subprogram and shall meet the additional constraints of 12.7. 2 If the prefix-spec ELEMENTAL appears, the subprogram is an elemental subprogram and shall meet 3 the additional constraints of 12.8.1. 4 NOTE 12.42 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 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.43 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); 328 2006/07/11 WORKING DRAFT J3/06-007 12.6.2.2 Subroutine subprogram 1 A subroutine subprogram is a subprogram that has a SUBROUTINE statement as its first statement. 2 R1233 subroutine-subprogram is subroutine-stmt 3 [ specification-part ] 4 [ execution-part ] 5 [ internal-subprogram-part ] 6 end-subroutine-stmt 7 R1234 subroutine-stmt is [ prefix ] SUBROUTINE subroutine-name 8 [ ( [ dummy-arg -list ] ) [ proc-language-binding-spec ] ] 9 C1256 (R1234) The prefix of a subroutine-stmt shall not contain a declaration-type-spec . 10 R1235 dummy-arg is dummy-arg-name 11 or * 12 R1236 end-subroutine-stmt is END [ SUBROUTINE [ subroutine-name ] ] 13 C1257 (R1233) An internal subroutine subprogram shall not contain an ENTRY statement. 14 C1258 (R1233) An internal subroutine subprogram shall not contain an internal-subprogram-part . 15 C1259 (R1236) If a subroutine-name appears in the end-subroutine-stmt , it shall be identical to the 16 subroutine-name specified in the subroutine-stmt . 17 The name of the subroutine is subroutine-name . 18 The prefix-spec RECURSIVE shall appear if the subroutine directly or indirectly invokes itself or a 19 subroutine defined by an ENTRY statement in the same subprogram. Similarly, RECURSIVE shall 20 appear if a subroutine defined by an ENTRY statement in the subprogram directly or indirectly invokes 21 itself, another subroutine defined by an ENTRY statement in that subprogram, or the subroutine defined 22 by the SUBROUTINE statement. 23 If the prefix-spec PURE appears, or the prefix-spec ELEMENTAL appears and IMPURE does not appear, 24 the subprogram is a pure subprogram and shall meet the additional constraints of 12.7. 25 If the prefix-spec ELEMENTAL appears, the subprogram is an elemental subprogram and shall meet 26 the additional constraints of 12.8.1. 27 12.6.2.3 Instances of a subprogram 28 When a function or subroutine defined by a subprogram is invoked, an instance of that subprogram is 29 created. When a statement function is invoked, an instance of that statement function is created. 30 Each instance has an independent sequence of execution and an independent set of dummy arguments 31 and local unsaved data ob jects. If an internal procedure or statement function in the subprogram is invoked 32 by name from an instance of the subprogram or from an internal subprogram or statement function that 33 has access to the entities of that instance, the created instance of the internal subprogram or statement 34 function also has access to the entities of that instance of the host subprogram. If an internal pro cedure 35 is invoked via a dummy procedure or procedure pointer, the internal procedure has access to the entities 36 of the host instance of that dummy procedure or procedure pointer. 37 All other entities are shared by all instances of the subprogram. 38 329 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 12.44 The value of a saved data ob ject appearing in one instance may have been defined in a previous instance or by initialization in a DATA statement or type declaration statement. 12.6.2.4 Separate mo dule pro cedures 1 A separate mo dule pro cedure is a module procedure defined by a separate-module-subprogram , 2 by a function-subprogram whose initial statement contains the keyword MODULE, or by a subroutine- 3 subprogram whose initial statement contains the keyword MODULE. Its interface is declared by a module 4 procedure interface body (12.4.2.1) in the specification-part of the module or submodule in which the 5 procedure is defined, or in an ancestor module or submodule. 6 R1237 separate-module-subprogram is MODULE PROCEDURE procedure-name 7 [ specification-part ] 8 [ execution-part ] 9 [ internal-subprogram-part ] 10 end-sep-subprogram-stmt 11 R1238 end-sep-subprogram-stmt is END [PROCEDURE [procedure-name ]] 12 C1260 (R1237) The procedure-name shall be the same as the name of an accessible module procedure 13 interface that is declared in the module or submodule in which the separate-module-subprogram 14 is defined, or is declared in an ancestor of that program unit. 15 C1261 (R1238) If a procedure-name appears in the end-sep-subprogram-stmt , it shall be identical to the 16 procedure-name in the MODULE PROCEDURE statement. 17 A module procedure interface body and a subprogram that defines a separate module procedure corre- 18 sp ond if they have the same name, and the module procedure interface is declared in the same program 19 unit as the subprogram or is declared in an ancestor of the program unit in which the procedure is 20 defined and is accessible by host association from that ancestor. A module procedure interface body 21 shall not correspond to more than one subprogram that defines a separate module procedure. 22 NOTE 12.45 A separate module procedure is only accessible by use association if its interface body is declared in the specification part of a module and is public. If a procedure is defined by a separate-module-subprogram, its characteristics are specified by the corre- 23 sponding module procedure interface body. 24 If a separate module procedure is a function defined by a separate-module-subprogram, the result variable 25 name is determined by the FUNCTION statement in the module procedure interface body. Otherwise, 26 the result variable name is determined by the FUNCTION statement in the module subprogram. 27 12.6.2.5 ENTRY statement 28 An ENTRY statement permits a procedure reference to begin with a particular executable statement 29 within the function or subroutine subprogram in which the ENTRY statement appears. 30 R1239 entry-stmt is ENTRY entry-name [ ( [ dummy-arg -list ] ) [ suffix ] ] 31 C1262 (R1239) If RESULT appears, the entry-name shall not appear in any specification or type- 32 declaration statement in the scoping unit of the function program. 33 C1263 (R1239) An entry-stmt shall appear only in an external-subprogram or a module-subprogram 34 330 2006/07/11 WORKING DRAFT J3/06-007 that does not define a separate module procedure. An entry-stmt shall not appear within an 1 executable-construct . 2 C1264 (R1239) RESULT shall appear only if the entry-stmt is in a function subprogram. 3 C1265 (R1239) Within the subprogram containing the entry-stmt , the entry-name shall not appear 4 as a dummy argument in the FUNCTION or SUBROUTINE statement or in another ENTRY 5 statement nor shall it appear in an EXTERNAL, INTRINSIC, or PROCEDURE statement. 6 C1266 (R1239) A dummy-arg shall not be an alternate return indicator if the ENTRY statement is in a function 7 8 subprogram. C1267 (R1239) If RESULT appears, result-name shall not be the same as the function-name in the 9 FUNCTION statement and shall not be the same as the entry-name in any ENTRY statement 10 in the subprogram. 11 Optionally, a subprogram may have one or more ENTRY statements. 12 If the ENTRY statement is in a function subprogram, an additional function is defined by that subpro- 13 gram. The name of the function is entry-name and the name of its result variable is result-name or 14 is entry-name if no result-name is provided. The characteristics of the function result are specified by 15 specifications of the result variable. The dummy arguments of the function are those specified in the 16 ENTRY statement. If the characteristics of the result of the function named in the ENTRY statement 17 are the same as the characteristics of the result of the function named in the FUNCTION statement, 18 their result variables identify the same variable, although their names need not be the same. Otherwise, 19 they are storage associated and shall all be nonpointer, nonallocatable scalars of type default integer, 20 default real, double precision real, default complex, or default logical. 21 If the ENTRY statement is in a subroutine subprogram, an additional subroutine is defined by that 22 subprogram. The name of the subroutine is entry-name . The dummy arguments of the subroutine are 23 those specified in the ENTRY statement. 24 The order, number, types, kind type parameters, and names of the dummy arguments in an ENTRY 25 statement may differ from the order, number, types, kind type parameters, and names of the dummy 26 arguments in the FUNCTION or SUBROUTINE statement in the containing subprogram. 27 Because an ENTRY statement defines an additional function or an additional subroutine, it is referenced 28 in the same manner as any other function or subroutine (12.5). 29 In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear 30 in an executable statement preceding that ENTRY statement, unless it also appears in a FUNCTION, 31 SUBROUTINE, or ENTRY statement that precedes the executable statement. 32 33 In a subprogram, a name that app ears as a dummy argument in an ENTRY statement shall not app ear in the expression 34 of a statement function unless the name is also a dummy argument of the statement function, app ears in a FUNCTION 35 or SUBROUTINE statement, or appears in an ENTRY statement that precedes the statement function statement. If a dummy argument appears in an executable statement, the execution of the executable statement is 36 permitted during the execution of a reference to the function or subroutine only if the dummy argument 37 appears in the dummy argument list of the procedure name referenced. 38 If a dummy argument is used in a specification expression to specify an array bound or character length 39 of an ob ject, the appearance of the ob ject in a statement that is executed during a procedure reference 40 is permitted only if the dummy argument appears in the dummy argument list of the procedure name 41 referenced and it is present (12.5.1.9). 42 A scoping unit containing a reference to a procedure defined by an ENTRY statement may have access to 43 331 J3/06-007 WORKING DRAFT 2006/07/11 an interface body for the procedure. The procedure header for the interface body shall be a FUNCTION 1 statement for an entry in a function subprogram and shall be a SUBROUTINE statement for an entry 2 in a subroutine subprogram. 3 The keyword RECURSIVE is not used in an ENTRY statement. Instead, the presence or absence of 4 RECURSIVE in the initial SUBROUTINE or FUNCTION statement controls whether the procedure 5 defined by an ENTRY statement is permitted to reference itself. 6 The keywords PURE and IMPURE are not used in an ENTRY statement. Instead, the procedure 7 defined by an ENTRY statement is pure if and only if PURE is specified or ELEMENTAL is specified 8 and IMPURE is not specified in the SUBROUTINE or FUNCTION statement. 9 The keyword ELEMENTAL is not used in an ENTRY statement. Instead, the procedure defined by 10 an ENTRY statement is elemental if and only if ELEMENTAL is specified in the SUBROUTINE or 11 FUNCTION statement. 12 12.6.2.6 RETURN statement 13 R1240 return-stmt is RETURN [ scalar-int-expr ] 14 C1268 (R1240) The return-stmt shall be in the scoping unit of a function or subroutine subprogram. 15 C1269 (R1240) The scalar-int-expr is allowed only in the scoping unit of a subroutine subprogram. 16 Execution of the RETURN statement completes execution of the instance of the subprogram in which 17 it appears. If the expression appears and has a value n between 1 and the number of asterisks in the dummy argument 18 19 list, the CALL statement that invoked the subroutine transfers control to the statement identified by the nth alternate 20 return sp ecifier in the actual argument list. If the expression is omitted or has a value outside the required range, there is 21 no transfer of control to an alternate return. Execution of an end-function-stmt or end-subroutine-stmt is equivalent to executing a RETURN state- 22 ment with no expression. 23 12.6.2.7 CONTAINS statement 24 R1241 contains-stmt is CONTAINS 25 The CONTAINS statement separates the body of a main program, module, submodule, or subprogram 26 from any internal or module subprograms it may contain, or it introduces the type-bound procedure 27 part of a derived-type definition (4.5.2). The CONTAINS statement is not executable. 28 12.6.3 Definition and invocation of pro cedures by means other than Fortran 29 A procedure may be defined by means other than Fortran. The interface of a procedure defined by 30 means other than Fortran may be specified by an interface body or procedure declaration statement. If 31 the interface of such a procedure does not have a proc-language-binding-spec , the means by which the 32 procedure is defined are processor dependent. A reference to such a procedure is made as though it were 33 defined by an external subprogram. 34 If the interface of a procedure has a proc-language-binding-spec , the procedure is interoperable (15.5). 35 Interoperation with C functions is described in 15.5. 36 NOTE 12.46 For explanatory information on definition of procedures by means other than Fortran, see subclause C.9.2. 332 2006/07/11 WORKING DRAFT J3/06-007 12.6.4 Statement function 1 2 A statement function is a function defined by a single statement. 3 R1242 stmt-function-stmt is function-name ( [ dummy-arg-name -list ] ) = scalar-expr C1270 (R1242) The primaries of the scalar-expr shall be constants (literal and named), references to variables, references 4 5 to functions and function dummy pro cedures, and intrinsic op erations. If scalar-expr contains a reference to a 6 function or a function dummy pro cedure, the reference shall not require an explicit interface, the function shall 7 not require an explicit interface unless it is an intrinsic, the function shall not b e a transformational intrinsic, 8 and the result shall be scalar. If an argument to a function or a function dummy pro cedure is an array, it shall 9 b e an array name. If a reference to a statement function app ears in scalar-expr , its definition shall have b een 10 provided earlier in the scoping unit and shall not be the name of the statement function b eing defined. C1271 (R1242) Named constants in scalar-expr shall have been declared earlier in the scoping unit or made accessible 11 12 by use or host asso ciation. If array elements app ear in scalar-expr , the array shall have b een declared as an array 13 earlier in the scoping unit or made accessible by use or host asso ciation. C1272 (R1242) If a dummy-arg-name , variable, function reference, or dummy function reference is typed by the implicit 14 15 typing rules, its app earance in any subsequent typ e declaration statement shall confirm this implied typ e and 16 the values of any implied typ e parameters. C1273 (R1242) The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar. 17 C1274 (R1242) A given dummy-arg-name shall not appear more than once in any dummy-arg-name -list. 18 C1275 (R1242) Each variable reference in scalar-expr may be either a reference to a dummy argument of the statement 19 20 function or a reference to a variable accessible in the same scoping unit as the statement function statement. 21 The definition of a statement function with the same name as an accessible entity from the host shall b e preceded by the 22 declaration of its typ e in a typ e declaration statement. 23 The dummy arguments have a scop e of the statement function statement. Each dummy argument has the same typ e and 24 typ e parameters as the entity of the same name in the scoping unit containing the statement function. 25 A statement function shall not b e supplied as a pro cedure argument. 26 The value of a statement function reference is obtained by evaluating the expression using the values of the actual arguments 27 for the values of the corresp onding dummy arguments and, if necessary, converting the result to the declared typ e and 28 typ e attributes of the function. 29 A function reference in the scalar expression shall not cause a dummy argument of the statement function to b ecome 30 redefined or undefined. 12.7 Pure pro cedures 31 A pure pro cedure is 32 (1) a pure intrinsic function (13.1), 33 (2) a pure intrinsic subroutine (13.1), 34 (3) defined by a pure subprogram, or 35 (4) 36 a statement function that references only pure functions. A pure subprogram is a subprogram that has the prefix-spec PURE or that has the prefix-spec ELE- 37 MENTAL and does not have the prefix-spec IMPURE. The following additional constraints apply to 38 333 J3/06-007 WORKING DRAFT 2006/07/11 pure subprograms. 1 C1276 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy 2 data ob jects have INTENT(IN). 3 C1277 The specification-part of a pure subroutine subprogram shall specify the intents of all its non- 4 pointer dummy data ob jects. 5 C1278 A local variable declared in the specification-part or internal-subprogram-part of a pure subpro- 6 gram shall not have the SAVE attribute. 7 NOTE 12.47 Variable initialization in a type-declaration-stmt or a data-stmt implies the SAVE attribute; there- fore, such initialization is also disallowed. C1279 The specification-part of a pure subprogram shall specify that all its dummy procedures are 8 pure. 9 C1280 If a procedure that is neither an intrinsic procedure nor a statement function is used in a context 10 that requires it to be pure, then its interface shall be explicit in the scope of that use. The 11 interface shall specify that the procedure is pure. 12 C1281 All internal subprograms in a pure subprogram shall be pure. 13 C1282 In a pure subprogram any designator with a base ob ject that is in common or accessed by 14 host or use association, is a dummy argument of a pure function, is a dummy argument with 15 INTENT (IN) of a pure subroutine, or an ob ject that is storage associated with any such variable, 16 shall not be used 17 (1) in a variable definition context(16.6.7), 18 (2) as the data-target in a pointer-assignment-stmt , 19 (3) as the expr corresponding to a component with the POINTER attribute in a structure- 20 constructor , 21 (4) as the expr of an intrinsic assignment statement in which the variable is of a derived type 22 if the derived type has a pointer component at any level of component selection, or 23 (5) as an actual argument associated with a dummy argument with INTENT (OUT) or IN- 24 TENT (INOUT) or with the POINTER attribute. 25 NOTE 12.48 Item 3 requires that processors be able to determine if entities with the PRIVATE attribute or with private components have a pointer component. 334 2006/07/11 WORKING DRAFT J3/06-007 C1283 Any procedure referenced in a pure subprogram, including one referenced via a defined operation, 1 assignment, or finalization, shall be pure. 2 C1284 A pure subprogram shall not contain a print-stmt , open-stmt , close-stmt , backspace-stmt , endfile- 3 stmt , rewind-stmt , flush-stmt , wait-stmt , or inquire-stmt . 4 C1285 A pure subprogram shall not contain a read-stmt or write-stmt whose io-unit is a file-unit- 5 number or *. 6 C1286 A pure subprogram shall not contain a stop-stmt . 7 C1287 A co-indexed ob ject shall not appear in a variable definition context in a pure subprogram. 8 C1288 A pure subprogram shall not contain an image control statement (8.5.1). 9 NOTE 12.49 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.50 Pure subroutines are included to allow subroutine calls from pure procedures in a safe way, and to allow foral l-assignment-stmt s 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), INTENT (INOUT), and pointer dummy arguments are permitted. 12.8 Elemental pro cedures 10 12.8.1 Elemental procedure declaration and interface 11 An elemental pro cedure is an elemental intrinsic procedure or a procedure that is defined by an 12 elemental subprogram. 13 An elemental subprogram has the prefix-spec ELEMENTAL. An elemental subprogram is a pure sub- 14 program unless it has the prefix-spec IMPURE. The following additional constraints apply to elemental 15 335 J3/06-007 WORKING DRAFT 2006/07/11 subprograms. 1 C1289 All dummy arguments of an elemental procedure shall be scalar dummy data ob jects and shall 2 not have the POINTER or ALLOCATABLE attribute. 3 C1290 The result variable of an elemental function shall be scalar and shall not have the POINTER or 4 ALLOCATABLE attribute. 5 C1291 In the scoping unit of an elemental subprogram, an ob ject designator with a dummy argument 6 as the base ob ject shall not appear in a specification-expr except as the argument to one of the 7 intrinsic functions BIT SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6). 8 NOTE 12.51 An elemental subprogram is a pure subprogram and all of the constraints for pure subprograms also apply. NOTE 12.52 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 9 If a generic name or a specific name is used to reference an elemental function, the shape of the result is 10 the same as the shape of the actual argument with the greatest rank. If there are no actual arguments 11 or the actual arguments are all scalar, the result is scalar. For those elemental functions that have more 12 than one argument, all actual arguments shall be conformable. In the array case, the values of the 13 elements, if any, of the result are the same as would have been obtained if the scalar function had been 14 applied separately, in array element order, to corresponding elements of each array actual argument. 15 NOTE 12.53 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 336 2006/07/11 WORKING DRAFT J3/06-007 NOTE 12.53 (cont.) 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 An elemental subroutine is one that has only scalar dummy arguments, but may have array actual 2 arguments. In a reference to an elemental subroutine, either all actual arguments shall be scalar, or 3 all actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments shall 4 be arrays of the same shape and the remaining actual arguments shall be conformable with them. In 5 the case that the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy 6 arguments are arrays, the values of the elements, if any, of the results are the same as would be obtained 7 if the subroutine had been applied separately, in array element order, to corresponding elements of each 8 array actual argument. 9 In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and 10 FROM dummy arguments may be the same variable and may be associated scalar variables or associated 11 array variables all of whose corresponding elements are associated. Apart from this, the actual arguments 12 in a reference to an elemental subroutine must satisfy the restrictions of 12.5.1.10. 13 337 J3/06-007 WORKING DRAFT 2006/07/11 338 2006/07/11 WORKING DRAFT J3/06-007 13 Intrinsic pro cedures and mo dules 1 13.1 Classes of intrinsic procedures 2 There are four classes of intrinsic procedures: inquiry functions, elemental functions, transformational 3 functions, and subroutines. Some intrinsic subroutines are elemental. Some intrinsic subroutines are 4 collective. 5 An inquiry function is one whose result depends on the properties of one or more of its arguments 6 instead of their values; in fact, these argument values may be undefined. Unless the description of 7 an inquiry function states otherwise, these arguments are permitted to be unallocated allocatables or 8 pointers that are not associated. An elemental intrinsic function is one that is specified for scalar 9 arguments, but may be applied to array arguments as described in 12.8. All other intrinsic functions 10 are transformational functions; they almost all have one or more array arguments or an array result. 11 All standard intrinsic functions are pure. 12 The subroutine MOVE ALLOC and the elemental subroutine MVBITS are pure. No other standard 13 intrinsic subroutine is pure. 14 A collective subroutine is one that has an argument of type IMAGE TEAM (13.8.3.5). If it is invoked 15 by one image of a team, it shall be invoked by the same statement on all images of the team. There 16 is an implicit team synchronization (8.5.3) at the beginning and end of the execution of a collective 17 subroutine. 18 J3 internal note Unresolved Technical Issue 56 According to the above definition, if a user-defined procedure has a dummy argument of type IMAGE TEAM, it is a collective subroutine AND THEREFORE there is an implicit team syn- chronisation at the beginning and end of its execution. You cannot be serious. Also, RESHAPE, TRANSFER, and SPREAD can all take arguments of type IMAGE TEAM, so that makes them collective subroutines when given such an argument? J3 internal note Unresolved Technical Issue 57 The term "implicit team synchronization" is used twice and never defined. Define it. It is not as simple as "all the members of the team": which team ­ an image can be a member of several teams, no? Similarly, it cannot be as simple as "the value of the argument type IMAGE TEAM, since that is an output argument of FORM TEAM. NOTE 13.1 The subroutine FORM TEAM forms a team of images. The other collective subroutines return an array of the same shape as the given co-array after having applied an operation on the images in a team. The simple case of wanting the operation to be applied to all the elements of the co-array can easily be programmed, for example: REAL FUNCTION GLOBAL_SUM(ARRAY) REAL :: ARRAY(:,:)[*] REAL,SAVE :: TEMP[*] 339 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 13.1 (cont.) TEMP = SUM(ARRAY) ! Sum on the executing image CALL CO_SUM(TEMP,GLOBAL_SUM) END FUNCTION GLOBAL_SUM Versions with other arguments can be programmed similarly, see C.10.2. J3 internal note Unresolved Technical Issue 58 Sorry, but this tutorial does not belong in "Classes of intrinsic procedures". Even the normative stuff is probably a bit long for that (if there were a subclause about collective subroutines this bit should be simplified and the details moved there). Since this is all basic "how to do parallel programming with coarrays", I'm not sure it belongs in the standard at all; if it is needed, it ought to be in a separate subclause. Why the advertising-speak "easily be programmed"? That is inappropriate for a standard. Finally, this invocation of CO SUM does not have any argument of type IMAGE TEAM, and therefore is not a collective subroutine! NOTE 13.2 As with user-written elemental subroutines, an elemental intrinsic subroutine is pure. The effects of MOVE ALLOC are limited to its arguments. The remaining nonelemental intrinsic subroutines all have side effects (or reflect system side effects) and thus are not pure. Generic names of standard intrinsic procedures are listed in 13.5. In most cases, generic functions 1 accept arguments of more than one type and the type of the result is the same as the type of the 2 arguments. Sp ecific names of standard intrinsic functions with corresponding generic names are listed 3 in 13.6. 4 If an intrinsic procedure is used as an actual argument to a procedure, its specific name shall be used 5 and it may be referenced in the called procedure only with scalar arguments. If an intrinsic procedure 6 does not have a specific name, it shall not be used as an actual argument (12.5.1.6). 7 Elemental intrinsic procedures behave as described in 12.8. 8 13.2 Arguments to intrinsic procedures 9 13.2.1 General rules 10 All intrinsic procedures may be invoked with either positional arguments or argument keywords (12.5). 11 The descriptions in 13.5 through 13.7 give the argument keyword names and positional sequence for 12 standard intrinsic procedures. 13 Many of the intrinsic procedures have optional arguments. These arguments are identified by the notation 14 "optional" in the argument descriptions. In addition, the names of the optional arguments are enclosed 15 in square brackets in description headings and in lists of procedures. The valid forms of reference for 16 procedures with optional arguments are described in 12.5.1. 17 NOTE 13.3 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 ). 340 2006/07/11 WORKING DRAFT J3/06-007 NOTE 13.4 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. The dummy arguments of the specific intrinsic procedures in 13.6 have INTENT(IN). The dummy 1 arguments of the generic intrinsic procedures in 13.7 have INTENT(IN) if the intent is not stated 2 explicitly. 3 The actual argument associated with an intrinsic function dummy argument named KIND shall be a 4 scalar integer initialization expression and its value shall specify a representation method for the function 5 result that exists on the processor. 6 Intrinsic subroutines that assign values to arguments of type character do so in accordance with the 7 rules of intrinsic assignment (7.4.1.3). 8 13.2.2 The shap e of array arguments 9 Unless otherwise specified, the inquiry intrinsic functions accept array arguments for which the shape 10 need not be defined. The shape of array arguments to transformational and elemental intrinsic functions 11 shall be defined. 12 13.2.3 Mask arguments 13 Some array intrinsic functions have an optional MASK argument of type logical that is used by the 14 function to select the elements of one or more arguments to be operated on by the function. Any 15 element not selected by the mask need not be defined at the time the function is invoked. 16 The MASK affects only the value of the function, and does not affect the evaluation, prior to invoking 17 the function, of arguments that are array expressions. 18 13.2.4 Arguments of collective subroutines 19 Each argument of a collective subroutine shall have the same shape on all images of the team. A co-array 20 argument shall have the same bounds on all images of the team. An INTENT(IN) argument of type 21 IMAGE TEAM shall have a value that was constructed by invoking FORM TEAM for the team. 22 13.3 Bit mo del 23 The bit manipulation procedures and inquiry functions are described in terms of a model for the repre- 24 sentation and behaviour of bits on a processor. 25 For an integer, a bit is defined to be a binary digit w located at position k of a nonnegative integer scalar 26 ob ject based on a model nonnegative integer defined by 27 k-1 z wk × 2k j= =0 and for which wk may have the value 0 or 1. An example of a model number compatible with the 28 examples used in 13.4 would have z = 32, thereby defining a 32-bit integer. 29 341 J3/06-007 WORKING DRAFT 2006/07/11 Using the notation of the formula above, the value of an ob ject of type bits and kind z is represented as 1 the ordered sequence of bits with wk the bit at position k . The rightmost bit is w0 and the leftmost bit 2 is wz-1 . Such a bits ob ject can be interpreted as a nonnegative integer with the value j . 3 An inquiry function BIT SIZE is available to determine the parameter z of the model. 4 Effectively, this model defines an integer ob ject to consist of z bits in sequence numbered from right 5 to left from 0 to z - 1. This model is valid only in the context of the use of such an ob ject as the 6 argument or result of one of the bit manipulation procedures. In all other contexts, the model defined 7 for an integer in 13.4 applies. In particular, whereas the models are identical for wz-1 = 0, they do not 8 correspond for wz-1 = 1 and the interpretation of bits in such ob jects is processor dependent. 9 13.4 Numeric models 10 The numeric manipulation and inquiry functions are described in terms of a model for the representation 11 and behavior of numbers on a processor. The model has parameters that are determined so as to make 12 the model best fit the machine on which the program is executed. 13 The model set for integer i is defined by 14 k-1 q wk × rk i=s× =0 where r is an integer exceeding one, q is a positive integer, each wk is a nonnegative integer less than r, 15 and s is +1 or -1. 16 The model set for real x is defined by 17 0 or kp x= fk × b-k , s × be × =1 where b and p are integers exceeding one; each fk is a nonnegative integer less than b, with f1 nonzero; s 18 is +1 or -1; and e is an integer that lies between some integer maximum emax and some integer minimum 19 emin inclusively. For x = 0, its exponent e and digits fk are defined to be zero. The integer parameters 20 r and q determine the set of model integers and the integer parameters b, p, emin , and emax determine 21 the set of model floating point numbers. The parameters of the integer and real models are available 22 for each representation method of the integer and real types. The parameters characterize the set of 23 available numbers in the definition of the model. The floating-point manipulation functions (13.5.10) 24 and numeric inquiry functions (13.5.6) provide values of some parameters and other values related to 25 the models. 26 NOTE 13.5 Examples of these functions in 13.7 use the models k30 wk × 2k i=s× =0 and 342 2006/07/11 WORKING DRAFT J3/06-007 NOTE 13.5 (cont.) 1 , k24 fk × 2-k x = 0 or s × 2e × - 126 e 127 + 2 =2 13.5 Standard generic intrinsic procedures 1 For all of the standard intrinsic procedures, the arguments shown are the names that shall be used for 2 argument keywords if the keyword form is used for actual arguments. 3 NOTE 13.6 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.7 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 13.5.1 Numeric functions 4 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 NINT (A [, KIND]) Nearest integer 21 REAL (A [, KIND]) Conversion to real type 22 SIGN (A, B) Transfer of sign 23 13.5.2 Mathematical functions 24 ACOS (X) Arccosine 25 ACOSH (X) Hyperbolic arccosine 26 ASIN (X) Arcsine 27 343 J3/06-007 WORKING DRAFT 2006/07/11 ASINH (X) Hyperbolic arcsine 1 ATAN (X) or ATAN (Y, X) Arctangent 2 ATAN2 (Y, X) Arctangent 3 ATANH (X) Hyperbolic arctangent 4 BESSEL J0 (X) Bessel function of the first kind of order zero 5 BESSEL J1 (X) Bessel function of the first kind of order one 6 BESSEL JN (N,X) Bessel function of the first kind of order N 7 BESSEL Y0 (X) Bessel function of the second kind of order zero 8 BESSEL Y1 (X) Bessel function of the second kind of order one 9 BESSEL YN (N, X) Bessel function of the second kind of order N 10 COS (X) Cosine 11 COSH (X) Hyperbolic cosine 12 ERF (X) Error function 13 ERFC (X) Complementary error function 14 ERFC SCALED (X) Exponentially-scaled complementary error 15 function 16 EXP (X) Exponential 17 GAMMA (X) Gamma function 18 HYPOT (X, Y) Euclidean distance function 19 LOG (X) Natural logarithm 20 LOG GAMMA (X) Logarithm of absolute value of gamma function 21 LOG10 (X) Common logarithm (base 10) 22 SIN (X) Sine 23 SINH (X) Hyperbolic sine 24 SQRT (X) Square root 25 TAN (X) Tangent 26 TANH (X) Hyperbolic tangent 27 13.5.3 Character functions 28 ACHAR (I [, KIND]) Character in given position in ASCII collating 29 sequence 30 ADJUSTL (STRING) Adjust left 31 ADJUSTR (STRING) Adjust right 32 CHAR (I [, KIND]) Character in given position in processor collating 33 sequence 34 IACHAR (C [, KIND]) Position of a character in ASCII collating 35 sequence 36 ICHAR (C [, KIND]) Position of a character in processor collating 37 sequence 38 INDEX (STRING, SUBSTRING [, BACK, Starting position of a substring 39 KIND]) LEN TRIM (STRING [, KIND]) Length without trailing blank characters 40 LGE (STRING A, STRING B) Lexically greater than or equal 41 LGT (STRING A, STRING B) Lexically greater than 42 LLE (STRING A, STRING B) Lexically less than or equal 43 LLT (STRING A, STRING B) Lexically less than 44 MAX (A1, A2 [, A3,...]) Maximum value 45 MIN (A1, A2 [, A3,...]) Minimum value 46 REPEAT (STRING, NCOPIES) Repeated concatenation 47 SCAN (STRING, SET [, BACK, KIND]) Scan a string for a character in a set 48 TRIM (STRING) Remove trailing blank characters 49 VERIFY (STRING, SET [, BACK, KIND]) Verify the set of characters in a string 50 344 2006/07/11 WORKING DRAFT J3/06-007 13.5.4 Kind functions 1 BITS KIND (X [, KIND]) Bits kind type parameter value, compatible with 2 the argument 3 KIND (X) Kind type parameter value 4 SELECTED BITS KIND (N) Bits kind type parameter value, given number of 5 bits 6 SELECTED CHAR KIND (NAME) Character kind type parameter value, given 7 character set name 8 SELECTED INT KIND (R) Integer kind type parameter value, given range 9 SELECTED REAL KIND ([P, R, RADIX]) Real kind type parameter value, given precision, 10 range, and radix 11 13.5.5 Miscellaneous type conversion functions 12 BITS (A [, KIND]) Convert to bits type 13 LOGICAL (L [, KIND]) Convert between ob jects of type logical with 14 different kind type parameters 15 TRANSFER (SOURCE, MOLD [, SIZE]) Treat first argument as if of type of second 16 argument 17 13.5.6 Numeric inquiry functions 18 DIGITS (X) Number of significant digits of the model 19 EPSILON (X) Number that is almost negligible compared to 20 one 21 HUGE (X) Largest number of the model 22 MAXEXPONENT (X) Maximum exponent of the model 23 MINEXPONENT (X) Minimum exponent of the model 24 PRECISION (X) Decimal precision 25 RADIX (X) Base of the model 26 RANGE (X) Decimal exponent range 27 TINY (X) Smallest positive number of the model 28 13.5.7 Array inquiry functions 29 CO LBOUND (CO ARRAY [, DIM, KIND]) Lower co-bounds of a co-array 30 CO UBOUND (CO ARRAY [, DIM, KIND]) Upper co-bounds of a co-array 31 LBOUND (ARRAY [, DIM, KIND]) Lower dimension bounds of an array 32 SHAPE (SOURCE [, KIND]) Shape of an array or scalar 33 SIZE (ARRAY [, DIM, KIND]) Total number of elements in an array 34 UBOUND (ARRAY [, DIM, KIND]) Upper dimension bounds of an array 35 13.5.8 Other inquiry functions 36 ALLOCATED (ARRAY) or Allocation status 37 ALLOCATED (SCALAR) ASSOCIATED (POINTER [, TARGET]) Association status inquiry or comparison 38 BIT SIZE (I) Number of bits of the model 39 EXTENDS TYPE OF (A, MOLD) Same dynamic type or an extension 40 IS CONTIGUOUS Contiguity inquiry 41 LEN (STRING [, KIND]) Length of a character entity 42 NEW LINE (A) Newline character 43 345 J3/06-007 WORKING DRAFT 2006/07/11 PRESENT (A) Argument presence 1 SAME TYPE AS (A, B) Same dynamic type 2 13.5.9 Bit manipulation pro cedures 3 BTEST (I, POS) Bit testing 4 DSHIFTL (I, J, SHIFT) Combined left shift 5 DSHIFTR (I, J, SHIFT) Combined right shift 6 IAND (I, J) Bitwise AND 7 IBCLR (I, POS) Clear bit 8 IBITS (I, POS, LEN) Bit extraction 9 IBSET (I, POS) Set bit 10 IEOR (I, J) Exclusive OR 11 IOR (I, J) Inclusive OR 12 ISHFT (I, SHIFT) Logical shift 13 ISHFTC (I, SHIFT [, SIZE]) Circular shift 14 LEADZ (I [, KIND]) Number of leading zero bits 15 MASKL (I [, KIND]) Left justified bit mask 16 MASKR (I [, KIND]) Right justified bit mask 17 MERGE BITS (I, J, MASK) Merge bits under mask 18 MVBITS (FROM, FROMPOS, LEN, TO, Copies bits from one integer to another 19 TOPOS) NOT (I) Bitwise complement 20 POPCNT (I [, KIND]) Number of one bits 21 POPPAR (I [, KIND]) Parity of one bits 22 SHIFTA (I, SHIFT) Arithmetic right shift 23 SHIFTL (I, SHIFT) Left shift 24 SHIFTR (I, SHIFT) Right shift 25 TRAILZ (I [, KIND]) Number of trailing zero bits 26 13.5.10 Floating-p oint manipulation functions 27 EXPONENT (X) Exponent part of a model number 28 FRACTION (X) Fractional part of a number 29 NEAREST (X, S) Nearest different processor number in given 30 direction 31 RRSPACING (X) Reciprocal of the relative spacing of model 32 numbers near given number 33 SCALE (X, I) Multiply a real by its base to an integer power 34 SET EXPONENT (X, I) Set exponent part of a number 35 SPACING (X) Absolute spacing of model numbers near given 36 number 37 13.5.11 Vector and matrix multiply functions 38 DOT PRODUCT (VECTOR A, Dot product of two rank-one arrays 39 VECTOR B) MATMUL (MATRIX A, MATRIX B) Matrix multiplication 40 13.5.12 Array reduction functions 41 ALL (MASK [, DIM]) True if all values are true 42 ANY (MASK [, DIM]) True if any value is true 43 COUNT (MASK [, DIM, KIND]) Number of true elements in an array 44 346 2006/07/11 WORKING DRAFT J3/06-007 IALL (ARRAY, DIM [, MASK]) or Bitwise AND of array elements 1 IALL (ARRAY [, MASK]) IANY (ARRAY, DIM [, MASK]) or Bitwise OR of array elements 2 IANY (ARRAY [, MASK]) IPARITY (ARRAY, DIM [, MASK]) or Bitwise exclusive OR of array elements 3 IPARITY (ARRAY [, MASK]) MAXVAL (ARRAY, DIM [, MASK]) or Maximum value in an array 4 MAXVAL (ARRAY [, MASK]) MINVAL (ARRAY, DIM [, MASK]) or Minimum value in an array 5 MINVAL (ARRAY [, MASK]) NORM2 (X) L2 norm of an array 6 PARITY (MASK [, DIM]) True if an odd number of values is true 7 PRODUCT (ARRAY, DIM [, MASK]) or Product of array elements 8 PRODUCT (ARRAY [, MASK]) SUM (ARRAY, DIM [, MASK]) or Sum of array elements 9 SUM (ARRAY [, MASK]) 13.5.13 Array construction functions 10 CSHIFT (ARRAY, SHIFT [, DIM]) Circular shift 11 EOSHIFT (ARRAY, SHIFT [, BOUNDARY, End-off shift 12 DIM]) MERGE (TSOURCE, FSOURCE, MASK) Merge under mask 13 PACK (ARRAY, MASK [, VECTOR]) Pack an array into an array of rank one under a 14 mask 15 RESHAPE (SOURCE, SHAPE[, PAD, Reshape an array 16 ORDER]) SPREAD (SOURCE, DIM, NCOPIES) Replicates array by adding a dimension 17 TRANSPOSE (MATRIX) Transpose of an array of rank two 18 UNPACK (VECTOR, MASK, FIELD) Unpack an array of rank one into an array under 19 a mask 20 13.5.14 Array location functions 21 FINDLOC (ARRAY, VALUE, DIM, [, Location of value in an array MASK, KIND, BACK]) or FINDLOC (ARRAY, VALUE, [, MASK, 22 KIND, BACK]) MAXLOC (ARRAY, DIM [, MASK, KIND, Location of a maximum value in an array BACK]) or MAXLOC (ARRAY [, 23 MASK, KIND, BACK]) MINLOC (ARRAY, DIM [, MASK, KIND, Location of a minimum value in an array BACK]) or MINLOC (ARRAY [, 24 MASK, KIND, BACK]) 13.5.15 Collective subroutines 25 CO ALL (MASK, RESULT [, TEAM]) Whether all values are true 26 CO ANY (MASK, RESULT [, TEAM]) Whether any value is true 27 CO COUNT (MASK, RESULT [, TEAM]) Number of true elements in a co-array 28 CO MAXLOC (CO ARRAY, RESULT [, Image indices of maximum values 29 TEAM]) CO MAXVAL (CO ARRAY, RESULT [, Maximum values 30 TEAM]) 347 J3/06-007 WORKING DRAFT 2006/07/11 CO MINLOC (CO ARRAY, RESULT [, Image indices of minimum values 1 TEAM]) CO MINVAL (CO ARRAY, RESULT [, Minimum values 2 TEAM]) CO PRODUCT (CO ARRAY, RESULT [, Products of elements 3 TEAM]) CO SUM (CO ARRAY, RESULT [, TEAM]) Sums of elements 4 FORM TEAM (TEAM, IMAGES) Forms a team of images 5 13.5.16 Null function 6 NULL ([MOLD]) Returns disassociated or unallocated result 7 13.5.17 Allocation transfer procedure 8 MOVE ALLOC (FROM, TO) Moves an allocation from one allocatable ob ject 9 to another 10 13.5.18 Random numb er subroutines 11 RANDOM NUMBER (HARVEST) Returns pseudorandom number 12 RANDOM SEED ([SIZE, PUT, GET]) Initializes or restarts the pseudorandom number 13 generator 14 13.5.19 System environment pro cedures 15 COMMAND ARGUMENT COUNT () Number of command arguments 16 CPU TIME (TIME) Obtain processor time 17 DATE AND TIME ([DATE, TIME, ZONE, Obtain date and time 18 VALUES]) EXECUTE COMMAND LINE (COM- Execute a command line MAND, [WAIT, EXITSTAT, 19 CMDSTAT, CMDMSG]) GET COMMAND ([COMMAND, Returns entire command 20 LENGTH, STATUS]) GET COMMAND ARGUMENT (NUMBER Returns a command argument 21 [, VALUE, LENGTH, STATUS]) GET ENVIRONMENT VARIABLE (NAME Obtain the value of an environment variable [, VALUE, LENGTH, STATUS, 22 TRIM NAME]) IMAGE INDEX (CO ARRAY, SUB) Index of an image 23 IS IOSTAT END (I) Test for end-of-file value 24 IS IOSTAT EOR (I) Test for end-of-record value 25 NUM IMAGES () Number of images 26 SYSTEM CLOCK ([COUNT, Obtain data from the system clock 27 COUNT RATE, COUNT MAX]) THIS IMAGE () Index of the invoking image 28 THIS IMAGE (CO ARRAY [, DIM]) Co-subscript list 29 J3 internal note Unresolved Technical Issue 59 These two uses of THIS IMAGE are completely different (to the extent of needing separate summary lines). This is likely to confuse users. Consider changing the name of the second one, perhaps to something like CO SUBSCRIPTS, to avoid confusion. 348 2006/07/11 WORKING DRAFT J3/06-007 13.6 Specific names for standard intrinsic functions 1 Except for AMAX0, AMIN0, MAX1, and MIN1, the result type of the specific function is the same as the 2 result type of the corresponding generic function would be if it were invoked with the same arguments 3 as the specific function. 4 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 DPROD DPROD default real DSIGN SIGN double precision real DSIN SIN double precision real DSINH SINH double precision real 349 J3/06-007 WORKING DRAFT 2006/07/11 Specific Name Generic Name Argument Type 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 A specific intrinsic function marked with a bullet (·) shall not be used as an actual argument or as a 1 target in a procedure pointer assignment statement. 2 13.7 Specifications of the standard intrinsic procedures 3 Detailed specifications of the standard generic intrinsic procedures are provided here in alphabetical 4 order. 5 The types and type parameters of standard intrinsic procedure arguments and function results are de- 6 termined by these specifications. The "Argument(s)" paragraphs specify requirements on the actual 7 arguments of the procedures. The result characteristics are sometimes specified in terms of the char- 8 acteristics of dummy arguments. A program is prohibited from invoking an intrinsic procedure under 9 circumstances where a value to be returned in a subroutine argument or function result is outside the 10 range of values representable by ob jects of the specified type and type parameters, unless the intrinsic 11 module IEEE ARITHMETIC (clause 14) is accessible and there is support for an infinite or a NaN result, 12 as appropriate. If an infinite result is returned, the flag IEEE OVERFLOW or IEEE DIVIDE BY ZERO 13 shall signal; if a NaN result is returned, the flag IEEE INVALID shall signal. If all results are normal, 14 350 2006/07/11 WORKING DRAFT J3/06-007 these flags shall have the same status as when the intrinsic procedure was invoked. 1 13.7.1 ABS (A) 2 Description. Absolute value. 3 Class. Elemental function. 4 Argument. A shall be of type integer, real, or complex. 5 Result Characteristics. The same as A except that if A is complex, the result is real. 6 Result Value. If A is of type integer or real, the value of the result is |A|; if A is complex with 7 x 2 + y2 . value (x, y ), the result is equal to a processor-dependent approximation to 8 Example. ABS ((3.0, 4.0)) has the value 5.0 (approximately). 9 13.7.2 ACHAR (I [, KIND]) 10 Description. Returns the character in a specified position of the ASCII collating sequence. It 11 is the inverse of the IACHAR function. 12 Class. Elemental function. 13 Arguments. 14 I shall be of type integer or bits. If it is of type bits, it is interpreted as a 15 nonnegative integer as described in 13.3. KIND (optional) shall be a scalar integer initialization expression. 16 Result Characteristics. Character of length one. If KIND is present, the kind type parameter 17 is that specified by the value of KIND; otherwise, the kind type parameter is that of default 18 character type. 19 Result Value. If I has a value in the range 0 I 127, the result is the character in 20 position I of the ASCII collating sequence, provided the processor is capable of representing 21 that character in the character type of the result; otherwise, the result is processor dependent. 22 ACHAR (IACHAR (C)) shall have the value C for any character C capable of representation in 23 the default character type. 24 Examples. ACHAR (88) has the value 'X'. ACHAR (Z'41') has the value 'A'. 25 13.7.3 ACOS (X) 26 Description. Arccosine (inverse cosine) function. 27 Class. Elemental function. 28 Argument. X shall be of type real with a value that satisfies the inequality |X| 1, or of type 29 complex. 30 Result Characteristics. Same as X. 31 Result Value. The result has a value equal to a processor-dependent approximation to arc- 32 cos(X). If it is real it is expressed in radians and lies in the range 0 ACOS(X) . If it is 33 complex the real part is expressed in radians and lies in the range 0 REAL(ACOS(X)) . 34 351 J3/06-007 WORKING DRAFT 2006/07/11 Example. ACOS (0.54030231) has the value 1.0 (approximately). 1 13.7.4 ADJUSTL (STRING) 2 Description. Adjust to the left, removing leading blanks and inserting trailing blanks. 3 Class. Elemental function. 4 Argument. STRING shall be of type character. 5 Result Characteristics. Character of the same length and kind type parameter as STRING. 6 Result Value. The value of the result is the same as STRING except that any leading blanks 7 have been deleted and the same number of trailing blanks have been inserted. 8 Example. ADJUSTL (' WORD') has the value 'WORD '. 9 13.7.5 ACOSH (X) 10 Description. Inverse hyperbolic cosine function. 11 Class. Elemental function. 12 Argument. X shall be of type real or complex. 13 Result Characteristics. Same as X. 14 Result Value. The result has a value equal to a processor-dependent approximation to the 15 inverse hyperbolic cosine function of X. If the result is complex the imaginary part is expressed 16 in radians and lies in the range 0 AIMAG(ACOSH(X)) 17 Example. ACOSH(1.5430806) has the value 1.0 (approximately). 18 13.7.6 ADJUSTR (STRING) 19 Description. Adjust to the right, removing trailing blanks and inserting leading blanks. 20 Class. Elemental function. 21 Argument. STRING shall be of type character. 22 Result Characteristics. Character of the same length and kind type parameter as STRING. 23 Result Value. The value of the result is the same as STRING except that any trailing blanks 24 have been deleted and the same number of leading blanks have been inserted. 25 Example. ADJUSTR ('WORD ') has the value ' WORD'. 26 13.7.7 AIMAG (Z) 27 Description. Imaginary part of a complex number. 28 Class. Elemental function. 29 Argument. Z shall be of type complex. 30 Result Characteristics. Real with the same kind type parameter as Z. 31 Result Value. If Z has the value (x, y ), the result has the value y . 32 352 2006/07/11 WORKING DRAFT J3/06-007 Example. AIMAG ((2.0, 3.0)) has the value 3.0. 1 13.7.8 AINT (A [, KIND]) 2 Description. Truncation to a whole number. 3 Class. Elemental function. 4 Arguments. 5 A shall be of type real. 6 KIND (optional) shall be a scalar integer initialization expression. 7 Result Characteristics. The result is of type real. If KIND is present, the kind type parameter 8 is that specified by the value of KIND; otherwise, the kind type parameter is that of A. 9 Result Value. If |A| < 1, AINT (A) has the value 0; if |A| 1, AINT (A) has a value equal 10 to the integer whose magnitude is the largest integer that does not exceed the magnitude of A 11 and whose sign is the same as the sign of A. 12 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 Description. Determine whether all values are true in MASK along dimension DIM. 15 Class. Transformational function. 16 Arguments. 17 MASK shall be of type logical. It shall be an array. 18 shall be scalar and of type integer with value in the range 1 DIM n, DIM (optional) where n is the rank of MASK. The corresponding actual argument shall not 19 be an optional dummy argument. Result Characteristics. The result is of type logical with the same kind type parameter as 20 MASK. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 21 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of MASK. 22 Result Value. 23 Case (i): The result of ALL (MASK) has the value true if all elements of MASK are true 24 or if MASK has size zero, and the result has value false if any element of MASK 25 is false. 26 Case (ii): If MASK has rank one, ALL(MASK,DIM) is equal to ALL(MASK). Otherwise, 27 the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of ALL (MASK, DIM) 28 is equal to ALL (MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn )). 29 Examples. 30 Case (i): The value of ALL ((/ .TRUE., .FALSE., .TRUE. /)) is false. 31 1 a 0 t 35 35 Case (ii): If B is the array nd C is the array hen ALL (B /= C, 32 246 748 DIM = 1) is [true, false, false] and ALL (B /= C, DIM = 2) is [false, false]. 33 13.7.10 ALLOCATED (ARRAY) or ALLOCATED (SCALAR) 34 353 J3/06-007 WORKING DRAFT 2006/07/11 Description. Indicate whether an allocatable variable is allocated. 1 Class. Inquiry function. 2 Arguments. 3 ARRAY shall be an allocatable array. 4 SCALAR shall be an allocatable scalar. 5 Result Characteristics. Default logical scalar. 6 Result Value. The result has the value true if the argument (ARRAY or SCALAR) is allocated 7 and has the value false if the argument is unallocated. 8 13.7.11 ANINT (A [, KIND]) 9 Description. Nearest whole number. 10 Class. Elemental function. 11 Arguments. 12 A shall be of type real. 13 KIND (optional) shall be a scalar integer initialization expression. 14 Result Characteristics. The result is of type real. If KIND is present, the kind type parameter 15 is that specified by the value of KIND; otherwise, the kind type parameter is that of A. 16 Result Value. The result is the integer nearest A, or if there are two integers equally near A, 17 the result is whichever such integer has the greater magnitude. 18 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 Description. Determine whether any value is true in MASK along dimension DIM. 21 Class. Transformational function. 22 Arguments. 23 MASK shall be of type logical. It shall be an array. 24 shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of MASK. The corresponding actual argument shall not 25 be an optional dummy argument. Result Characteristics. The result is of type logical with the same kind type parameter as 26 MASK. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 27 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of MASK. 28 Result Value. 29 Case (i): The result of ANY (MASK) has the value true if any element of MASK is true 30 and has the value false if no elements are true or if MASK has size zero. 31 Case (ii): If MASK has rank one, ANY(MASK,DIM) is equal to ANY(MASK). Otherwise, 32 the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of ANY(MASK, DIM) 33 354 2006/07/11 WORKING DRAFT J3/06-007 is equal to ANY(MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn )). 1 Examples. 2 Case (i): The value of ANY ((/ .TRUE., .FALSE., .TRUE. /)) is true. 3 1 a 0 t 35 35 Case (ii): If B is the array nd C is the array hen ANY(B /= C, 4 246 748 DIM = 1) is [true, false, true] and ANY(B /= C, DIM = 2) is [true, true]. 5 13.7.13 ASIN (X) 6 Description. Arcsine (inverse sine) function. 7 Class. Elemental function. 8 Argument. X shall be of type real with a value that satisfies the inequality |X| 1, or of type 9 complex. 10 Result Characteristics. Same as X. 11 Result Value. The result has a value equal to a processor-dependent approximation to arc- 12 sin(X). If it is real it is expressed in radians and and lies in the range - /2 ASIN(X) 13 /2. If it is complex the real part is expressed in radians and lies in the range - /2 14 REAL(ASIN(X)) /2. 15 Example. ASIN (0.84147098) has the value 1.0 (approximately). 16 13.7.14 ASINH (X) 17 Description. Inverse hyperbolic sine function. 18 Class. Elemental function. 19 Argument. X shall be of type real or complex. 20 Result Characteristics. Same as X. 21 Result Value. The result has a value equal to a processor-dependent approximation to the 22 inverse hyperbolic sine function of X. If the result is complex the imaginary part is expressed 23 in radians and lies in the range - /2 AIMAG(ASINH(X)) /2. If it is real it is expressed 24 in radians and and lies in the range - /2 ASIN(X) /2. If it is complex the real part is 25 expressed in radians and lies in the range - /2 REAL(ASIN(X)) /2. 26 Example. ASINH(1.1752012) has the value 1.0 (approximately). 27 13.7.15 ASSOCIATED (POINTER [, TARGET]) 28 Description. Returns the association status of its pointer argument or indicates whether the 29 pointer is associated with the target. 30 Class. Inquiry function. 31 Arguments. 32 POINTER shall be a pointer. It may be of any type or may be a procedure pointer. Its 33 pointer association status shall not be undefined. 355 J3/06-007 WORKING DRAFT 2006/07/11 TARGET shall be allowable as the data-target or proc-target in a pointer assignment (optional) statement (7.4.2) in which POINTER is data-pointer-object or proc-pointer- object . If TARGET is a pointer then its pointer association status shall not 1 be undefined. Result Characteristics. Default logical scalar. 2 Result Value. 3 Case (i): If TARGET is absent, the result is true if POINTER is associated with a target 4 and false if it is not. 5 Case (ii): If TARGET is present and is a procedure, the result is true if POINTER is 6 associated with TARGET. 7 Case (iii): If TARGET is present and is a procedure pointer, the result is true if POINTER 8 and TARGET are associated with the same procedure. If either POINTER or 9 TARGET is disassociated, the result is false. 10 Case (iv): If TARGET is present and is a scalar target, the result is true if TARGET is not a 11 zero-sized storage sequence and the target associated with POINTER occupies the 12 same storage units as TARGET. Otherwise, the result is false. If the POINTER 13 is disassociated, the result is false. 14 Case (v): If TARGET is present and is an array target, the result is true if the target 15 associated with POINTER and TARGET have the same shape, are neither of 16 size zero nor arrays whose elements are zero-sized storage sequences, and occupy 17 the same storage units in array element order. Otherwise, the result is false. If 18 POINTER is disassociated, the result is false. 19 Case (vi): If TARGET is present and is a scalar pointer, the result is true if the target 20 associated with POINTER and the target associated with TARGET are not zero- 21 sized storage sequences and they occupy the same storage units. Otherwise, the 22 result is false. If either POINTER or TARGET is disassociated, the result is 23 false. 24 Case (vii): If TARGET is present and is an array pointer, the result is true if the target 25 associated with POINTER and the target associated with TARGET have the 26 same shape, are neither of size zero nor arrays whose elements are zero-sized 27 storage sequences, and occupy the same storage units in array element order. 28 Otherwise, the result is false. If either POINTER or TARGET is disassociated, 29 the result is false. 30 Examples. ASSOCIATED (CURRENT, HEAD) is true if CURRENT is associated with the 31 target HEAD. After the execution of 32 A PART => A (:N) 33 ASSOCIATED (A PART, A) is true if N is equal to UBOUND (A, DIM = 1). After the 34 execution of 35 NULLIFY (CUR); NULLIFY (TOP) 36 ASSOCIATED (CUR, TOP) is false. 37 13.7.16 ATAN (X) or ATAN (Y, X) 38 Description. Arctangent (inverse tangent) function. 39 Class. Elemental function. 40 Arguments. 41 356 2006/07/11 WORKING DRAFT J3/06-007 Y shall be of type real. 1 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 2 shall be of type real or complex. Result Characteristics. Same as X. 3 Result Value. If Y is present, the result is the same as the result of ATAN2(Y,X). If Y is 4 absent, the result has a value equal to a processor-dependent approximation to arctan(X) whose 5 real part is expressed in radians and lies in the range - /2 ATAN(X) /2. 6 Example. ATAN (1.5574077) has the value 1.0 (approximately). 7 13.7.17 ATAN2 (Y, X) 8 Description. Arctangent (inverse tangent) function. The result is the principal value of the 9 argument of the nonzero complex number (X, Y). 10 Class. Elemental function. 11 Arguments. 12 Y shall be of type real. 13 X shall be of the same type and kind type parameter as Y. If Y has the value 14 zero, X shall not have the value zero. Result Characteristics. Same as X. 15 Result Value. The result has a value equal to a processor-dependent approximation to the 16 principal value of the argument of the complex number (X, Y), expressed in radians. It lies in 17 the range - ATAN2(Y,X) and is equal to a processor-dependent approximation to a 18 value of arctan(Y/X) if X = 0. If Y > 0, the result is positive. If Y = 0 and X > 0, the result 19 is Y. If Y = 0 and X < 0, then the result is if Y is positive real zero or the processor cannot 20 distinguish between positive and negative real zero, and - if Y is negative real zero. If Y < 0, 21 the result is negative. If X = 0, the absolute value of the result is /2. 22 Examples. ATAN2 (1.5574077, 1.0)- as the , value 1.0 (approximately). If Y has the value h 23 1 a 1 11 nd X has the value the value of ATAN2 (Y, X) is approximately -1 -1 -1 1 24 3 . 4 4 -3 - 25 4 4 13.7.18 ATANH (X) 26 Description. Inverse hyperbolic tangent function. 27 Class. Elemental function. 28 Argument. X shall be of type real or complex. 29 Result Characteristics. Same as X. 30 Result Value. The result has a value equal to a processor-dependent approximation to the 31 inverse hyperbolic tangent function of X. If the result is complex the imaginary part is expressed 32 in radians and lies in the range - /2 AIMAG(ATANH(X)) /2. 33 357 J3/06-007 WORKING DRAFT 2006/07/11 Example. ATANH(0.76159416) has the value 1.0 (approximately). 1 13.7.19 BESSEL J0 (X) 2 Description. Bessel function of the first kind of order zero. 3 Class. Elemental function. 4 Argument. X shall be of type real. 5 Result Characteristics. Same as X. 6 Result Value. The result has a value equal to a processor-dependent approximation to the 7 Bessel function of the first kind of order zero of X. 8 Example. BESSEL J0 (1.0) has the value 0.765 (approximately). 9 13.7.20 BESSEL J1 (X) 10 Description. Bessel function of the first kind of order one. 11 Class. Elemental function. 12 Argument. X shall be of type real. 13 Result Characteristics. Same as X. 14 Result Value. The result has a value equal to a processor-dependent approximation to the 15 Bessel function of the first kind of order one of X. 16 Example. BESSEL J1 (1.0) has the value 0.440 (approximately). 17 13.7.21 BESSEL JN (N, X) 18 Description. Bessel function of the first kind of order N. 19 Class. Elemental function. 20 Arguments. 21 N shall be of type integer and nonnegative. 22 X shall be of type real. 23 Result Characteristics. Same as X. 24 Result Value. The result has a value equal to a processor-dependent approximation to the 25 Bessel function of the first kind of order N of X. 26 Example. BESSEL JN (2, 1.0) has the value 0.115 (approximately). 27 13.7.22 BESSEL Y0 (X) 28 Description. Bessel function of the second kind of order zero. 29 Class. Elemental function. 30 Argument. X shall be of type real. Its value shall be greater than zero. 31 Result Characteristics. Same as X. 32 358 2006/07/11 WORKING DRAFT J3/06-007 Result Value. The result has a value equal to a processor-dependent approximation to the 1 Bessel function of the second kind of order zero of X. 2 Example. BESSEL Y0(1.0) has the value 0.088 (approximately). 3 13.7.23 BESSEL Y1 (X) 4 Description. Bessel function of the second kind of order one. 5 Class. Elemental function. 6 Argument. X shall be of type real. Its value shall be greater than zero. 7 Result Characteristics. Same as X. 8 Result Value. The result has a value equal to a processor-dependent approximation to the 9 Bessel function of the second kind of order one of X. 10 Example. BESSEL Y1 (1.0) has the value -0.781 (approximately). 11 13.7.24 BESSEL YN (N, X) 12 Description. Bessel function of the second kind of order N. 13 Class. Elemental function. 14 Arguments. 15 N shall be of type integer and nonnegative. 16 X shall be of type real. Its value shall be greater than zero. 17 Result Characteristics. Same as X. 18 Result Value. The result has a value equal to a processor-dependent approximation to the 19 Bessel function of the second kind of order N of X. 20 Example. BESSEL YN (2, 1.0) has the value -1.651 (approximately). 21 13.7.25 BIT SIZE (I [, KIND]) 22 J3 internal note Unresolved Technical Issue 62 Another totally useless ineffective KIND argument. While intrinsic KINDs are default integer, this is a waste of effort. And what half-baked idea is this, that we provide for bits capabilities for strings not only up to, but beyond 512MB(?!) but oh no, it's much too hard to have variable -length ones?!?!! What on earth are you thinking; only a complete loon would implement more than 4 billion different lengths of bitstring without building variable-length infrastructure. Description. Returns the number of bits z defined by the model of 13.3. 23 Class. Inquiry function. 24 Arguments. 25 359 J3/06-007 WORKING DRAFT 2006/07/11 I shall be of type integer or bits. It may be a scalar or an array. 1 KIND (optional) shall be a scalar integer initialization expression. 2 Result Characteristics. Scalar integer. If KIND is present, the kind type parameter is that 3 specified by the value of KIND. If KIND is not present and I is of type integer the result is a 4 scalar integer with the same kind type parameter as I. If KIND is not present and I is of type 5 bits, the result is a scalar of type default integer. 6 Result Value. If I is of type integer, result has the value of the number of bits z of the model 7 integer defined for bit manipulation contexts in 13.3. If I is of type bits, the result has the value 8 KIND(I). 9 Examples. BIT SIZE (1) has the value 32 if z of the model is 32. BIT SIZE(Z'00FF') has the 10 value 16. 11 13.7.26 BITS (A [, KIND]) 12 Description. Convert to bits type. 13 Class. Elemental function. 14 Arguments. 15 A shall be of type integer, real, complex, logical, or bits. 16 KIND (optional) shall be a scalar integer initialization expression. 17 Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified 18 by the value of KIND; otherwise, the kind type parameter is BITS KIND(A). 19 Result Value. If A is of type bits and the kind type parameter of A is the same as that of the 20 result, the result value is the value of A. 21 If A is of type bits with a smaller kind type parameter value than that of the result, the rightmost 22 KIND(A) bits of the result value are the same as those of A and the remaining bits of the result are 0. 23 If A is of type bits with a larger kind type parameter value than that of the result, the result value 24 consists of the rightmost KIND(result ) bits of A. 25 If A is not of type bits and BITS KIND(A) is greater than or equal to the kind type parameter of the 26 result, the result value consists of the rightmost KIND(result ) bits of the physical representation of A. 27 If A is not of type bits and BITS KIND(A) is less than or equal to the kind type parameter of the result, 28 the rightmost bits of the result are those of the physical representation of A and the remaining bits of 29 the result are 0. 30 Examples. BITS (Z'ABCD', 32) has the value Z'0000ABCD'. BITS (-1) has the value 31 Z'FFFFFFFF' for a processor whose default integer representation is 32-bit two's-complement. 32 BITS (.TRUE., 5) has the value B'00001' for a processor that represents the logical value true 33 by setting the low order bit of the internal value and clearing the other bits. BITS (X) has the 34 value Z'7F800000' if the value of X is an IEEE single precision positive infinity. 35 13.7.27 BITS KIND (X [, KIND]) 36 Description. Return bits kind compatible with the argument. 37 Class. Inquiry function. 38 360 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 X shall be of type bits, integer, real, complex, or logical. 2 KIND (optional) shall be a scalar integer initialization expression. 3 Result Characteristics. Scalar integer. If KIND is present, the kind type parameter is that 4 specified by the value of KIND; otherwise, the kind type parameter is that of default integer 5 type. 6 J3 internal note Unresolved Technical Issue 60 Maybe it is good that people are thinking about bitstrings greater than 512MB, but since intrinsic kind type parameters are of default integer type, there is a problem here. Two choices: (1) make the kind type parameter for bits type processor-dependent or something, AND change the KIND intrinsic to have a KIND argument (bleurgh), or (2) remove the useless KIND argument from this intrinsic since it will indeed be useless. Result Characteristics. If X is of type bits, the result has the value KIND (X). If X is of type 7 default integer, default real, or default logical, the result has the value NUMERIC STORAGE SIZE 8 (13.8.3.13). If X is of type double precision or default complex, the result has the value 9 2 × NUMERIC STORAGE SIZE. If X is of type complex with the same kind type parame- 10 ter as that of double precision, the result has the value 4 × NUMERIC STORAGE SIZE. If X 11 is of type non-default integer, the result has the value BIT SIZE (X). If X is of a non-default 12 logical or non-default non-integer numeric type, the result value is the number of bits of storage 13 used by the processor to represent scalar ob jects of that type and kind. 14 J3 internal note Unresolved Technical Issue 61 COMPLEX(KIND(0d0)) is neither required nor guaranteed to take double the space of DOUBLE PRECISION; it takes a single (unique) storage unit. BIT SIZE(X) does not return the number of bits taken for the storage of X, and indeed the earlier Cray models had "small integers" which took the full 60 bits of storage but were only calculated to rather fewer (something like 32ish and 48ish IIRC). Machines which use a unified FP/Integer representation will also have a BIT SIZE smaller than the actual storage. Indeed, BIT SIZE(default integer) is neither required nor guaranteed to be the same as NU- MERIC STORAGE SIZE. Therefore the sentence about non-default integers should be struck, as well as the sentence about double precision complex. Example. The value of BITS KIND (0) is 32 if the size of a numeric storage unit is 32 bits. 15 13.7.28 BTEST (I, POS) 16 Description. Tests a bit of an integer or bits value. 17 Class. Elemental function. 18 Arguments. 19 I shall be of type integer or bits. 20 POS shall be of type integer. It shall be nonnegative and be less than BIT SIZE (I). 21 361 J3/06-007 WORKING DRAFT 2006/07/11 Result Characteristics. Default logical. 1 Result Value. The result has the value true if bit POS of I has the value 1 and has the value 2 false if bit POS of I has the value 0. The model for the interpretation of an integer value as a 3 sequence of bits is in 13.3. 4 1 , 2 Examples. BTEST (8, 3) has the value true. If A has the value the value of 5 34 f a t . alse false rue false BTEST (A, 2) is nd the value of BTEST (2, A) is BTEST (B'01000', 6 false true false false 3) has the value true. 7 13.7.29 CEILING (A [, KIND]) 8 Description. Returns the least integer greater than or equal to its argument. 9 Class. Elemental function. 10 Arguments. 11 A shall be of type real. 12 KIND (optional) shall be a scalar integer initialization expression. 13 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 14 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 15 Result Value. The result has a value equal to the least integer greater than or equal to A. 16 Examples. CEILING (3.7) has the value 4. CEILING (­3.7) has the value ­3. 17 13.7.30 CHAR (I [, KIND]) 18 Description. Returns the character in a given position of the processor collating sequence 19 associated with the specified kind type parameter. It is the inverse of the ICHAR function. 20 Class. Elemental function. 21 Arguments. 22 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 23 associated with the specified kind type parameter. KIND (optional) shall be a scalar integer initialization expression. 24 Result Characteristics. Character of length one. If KIND is present, the kind type parameter 25 is that specified by the value of KIND; otherwise, the kind type parameter is that of default 26 character type. 27 Result Value. The result is the character in position I of the collating sequence associated 28 with the specified kind type parameter. ICHAR (CHAR (I, KIND (C))) shall have the value I 29 for 0 I n - 1 and CHAR (ICHAR (C), KIND (C)) shall have the value C for any character 30 C capable of representation in the processor. 31 Examples. CHAR (88) has the value 'X' on a processor using the ASCII collating sequence 32 for the default character type. CHAR (Z'41') has the value 'A' on a processor using the ASCII 33 362 2006/07/11 WORKING DRAFT J3/06-007 collating sequence. 1 13.7.31 CMPLX (X [, Y, KIND]) 2 Description. Convert to complex type. 3 Class. Elemental function. 4 Arguments. 5 X shall be of type integer, real, or complex, or bits. 6 Y (optional) shall be of type integer or real, or bits. If X is of type complex, Y shall not 7 be present, nor shall Y be associated with an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 8 Result Characteristics. The result is of type complex. If KIND is present, the kind type 9 parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of 10 default real type. 11 Result Value. If Y is absent and X is not complex, it is as if Y were present with the value 12 zero. If X is complex, it is as if X were real with the value REAL (X, KIND) and Y were present 13 with the value AIMAG (X, KIND). CMPLX (X, Y, KIND) has the complex value whose real 14 part is REAL (X, KIND) and whose imaginary part is REAL (Y, KIND). 15 Example. CMPLX (­3) has the value (­3.0, 0.0). 16 13.7.32 COMMAND ARGUMENT COUNT () 17 Description. Returns the number of command arguments. 18 Class. Inquiry function. 19 Argument. None. 20 Result Characteristics. Scalar default integer. 21 Result Value. The result value is equal to the number of command arguments available. 22 If there are no command arguments available or if the processor does not support command 23 arguments, then the result has the value zero. If the processor has a concept of a command 24 name, the command name does not count as one of the command arguments. 25 Example. See 13.7.73. 26 13.7.33 CO ALL (MASK, RESULT [, TEAM]) 27 Description. Determine whether all values are true on a team of images. 28 Class. Collective subroutine. 29 Arguments. 30 MASK shall be a co-array of type logical. It may be a scalar or an array. It is an 31 INTENT(IN) argument. 363 J3/06-007 WORKING DRAFT 2006/07/11 RESULT shall be of type logical and have the same shape as MASK. It is an IN- TENT(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 cor- responding elements of MASK are true on all the images of the team, and 1 the value false otherwise. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO ALL is performed. If TEAM 2 is not present, the team consists of all images. Example. If the number of images is two and MASK is the array [true, false, true] on one 3 image and [true, true, true] on the other image, the value of RESULT after the statement 4 CALL CO ALL (MASK, RESULT) is [true, false, true]. 5 13.7.34 CO ANY (MASK, RESULT [, TEAM]) 6 Description. Determine whether any value is true on a team of images. 7 Class. Collective subroutine. 8 Arguments. 9 MASK shall be a co-array of type logical. It may be a scalar or an array. It is an 10 INTENT(IN) argument. RESULT shall be of type logical and have the same shape as MASK. It is an IN- TENT(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 11 elements of MASK are true on any image of the team, and false otherwise. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO ANY is performed. If TEAM 12 is not present, the team consists of all images. Example. If the number of images is two and MASK is the array [true, false, false] on one 13 image and [true, true, false] on the other image, the value of RESULT after the statement 14 CALL CO ANY (MASK, RESULT) is [true, true, false]. 15 13.7.35 CO COUNT (MASK, RESULT [, TEAM]) 16 Description. Count the numbers of true elements on a team of images. 17 Class. Collective subroutine. 18 Arguments. 19 MASK shall be a co-array of type logical. It may be a scalar or an array. It is an 20 INTENT(IN) argument. RESULT shall be of type integer and have the same shape as MASK. It is an IN- TENT(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 21 elements of MASK on the images of the team that have the value true. 364 2006/07/11 WORKING DRAFT J3/06-007 TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO COUNT is performed. If 1 TEAM is not present, the team consists of all images. Example. If the number of images is two and MASK is the array [true, false, false] on 2 one image and [true, true, false] on the other image, the value of result after the statement 3 CALL CO COUNT (MASK, RESULT) is [2, 1, 0]. 4 13.7.36 CO LBOUND (CO ARRAY [, DIM, KIND]) 5 Description. Returns all the lower co-bounds or a specified lower co-bound of a co-array. 6 Class. Inquiry function. 7 Arguments. 8 CO ARRAY shall be a co-array and may be of any type. It may be a scalar or an array. 9 If it is allocatable it shall be allocated. shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the co-rank of CO ARRAY. The corresponding actual argument 10 shall not be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 11 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 12 by the value of KIND; otherwise, the kind type parameter is that of default integer type. The 13 result is scalar if DIM is present; otherwise, the result is an array of rank one and size n, where 14 n is the co-rank of CO ARRAY. 15 Result Value. 16 Case (i): CO LBOUND (CO ARRAY, DIM) has a value equal to the lower co-bound for 17 co-subscript DIM of CO ARRAY. 18 CO LBOUND (CO ARRAY) has a value whose ith element is equal to Case (ii): 19 CO LBOUND (CO ARRAY, i), for i = 1, 2,. . . , n, where n is the co-rank of 20 CO ARRAY. 21 Examples. If A is allocated by the statement ALLOCATE (A [2:3, 7:*]) then CO LBOUND (A) 22 is [2, 7] and CO LBOUND (A, DIM=2) is 7. 23 13.7.37 CO MAXLOC (CO ARRAY, RESULT [, TEAM]) 24 Description. Image indices of the maximum values of the elements on a team of images. 25 Class. Collective subroutine. 26 Arguments. 27 CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar 28 or an array. It is an INTENT(IN) argument. 365 J3/06-007 WORKING DRAFT 2006/07/11 RESULT shall be of type integer and 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 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 characters with the kind type parameter of the argument is 1 applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO MAXLOC is performed. If 2 TEAM is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 6] on one image 3 and [4, 1, 6] on the other image, the value of RESULT after the statement 4 CALL CO MAXLOC (CO ARRAY, RESULT) is [2, 1, 1]. 5 13.7.38 CO MAXVAL (CO ARRAY, RESULT [, TEAM]) 6 Description. Maximum values of the elements on a team of images. 7 Class. Collective subroutine. 8 Arguments. 9 CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar 10 or an array. It is an INTENT(IN) argument. 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 characters with the kind type parameter of the argument is 11 applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO MAXVAL is performed. If 12 TEAM is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image 13 and [4, 1, 6] on the other image, the value of RESULT after the statement 14 CALL CO MAXVAL (CO ARRAY, RESULT) is [4, 5, 6]. 15 13.7.39 CO MINLOC (CO ARRAY, RESULT [, TEAM]) 16 Description. Image indices of the minimum values of the elements on a team of images. 17 Class. Collective subroutine. 18 366 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 CO ARRAY shall a co-array of type integer, real, bits, or character. It may be a scalar or 2 an array. It is an INTENT(IN) argument. RESULT shall be of type integer and 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 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 characters with the kind type parameter of the argument is 3 applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO MINLOC is performed. If 4 TEAM is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 6] on one image 5 and [4, 1, 6] on the other image, the value of RESULT after the statement 6 CALL CO MINLOC (ARRAY, RESULT) is [1, 2, 1]. 7 13.7.40 CO MINVAL (CO ARRAY, RESULT [, TEAM]) 8 Description. Minimum values of the elements on a team of images. 9 Class. Collective subroutine. 10 Arguments. 11 CO ARRAY shall be a co-array of type integer, real, bits, or character. It may be a scalar 12 or an array. It is an INTENT(IN) argument. 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 13 applied. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO MINVAL is performed. If 14 TEAM is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image 15 and [4, 1, 6] on the other image, the value of RESULT after the statement 16 CALL CO MINVAL (CO ARRAY, RESULT) is [1, 1, 3]. 17 13.7.41 CO PRODUCT (CO ARRAY, RESULT [, TEAM]) 18 367 J3/06-007 WORKING DRAFT 2006/07/11 Description. Products of elements on a team of images. 1 Class. Collective subroutine. 2 Arguments. 3 CO ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an 4 array. It is an INTENT(IN) argument. 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 the images of 5 the team. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO PRODUCT is performed. If 6 TEAM is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image 7 and [4, 1, 6] on the other image, the value of RESULT after the statement 8 CALL CO PRODUCT (CO ARRAY, RESULT) is [4, 5, 18]. 9 13.7.42 CO SUM (CO ARRAY, RESULT [, TEAM]) 10 Description. Sums of elements on a team of images. 11 Class. Collective subroutine. 12 Arguments. 13 CO ARRAY shall be a co-array of type integer, real, or complex. It may be a scalar or an 14 array. It is an INTENT(IN) argument. 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 15 all the corresponding elements of CO ARRAY on the images of the team. TEAM (optional) shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(IN) argument that specifies the team for which CO SUM is performed. If TEAM 16 is not present, the team consists of all images. Example. If the number of images is two and CO ARRAY is the array [1, 5, 3] on one image 17 and [4, 1, 6] on the other image, the value of RESULT after the statement 18 CALL CO SUM (CO ARRAY, RESULT) is [5, 6, 9]. 19 13.7.43 CO UBOUND (CO ARRAY [, DIM, KIND]) 20 Description. Returns all the upper co-bounds or a specified upper co-bound of a co-array of 21 co-rank greater than one. 22 368 2006/07/11 WORKING DRAFT J3/06-007 Class. Inquiry function. 1 Arguments. 2 CO ARRAY shall be a co-array of any type and of co-rank greater than one. It may be a 3 scalar or an array. If it is allocatable it shall be allocated. d shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the co-rank of CO ARRAY. The corresponding actual argument 4 shall not be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 5 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 6 by the value of KIND; otherwise, the kind type parameter is that of default integer type. The 7 result is scalar if DIM is present; otherwise, the result is an array of rank one and size n - 1, 8 where n is the co-rank of CO ARRAY. 9 Result Value. 10 Case (i): CO UBOUND (CO ARRAY, DIM) has a value equal to the upper co-bound for 11 co-subscript DIM of CO ARRAY. 12 CO UBOUND (CO ARRAY) has a value whose ith element is equal to Case (ii): 13 CO UBOUND (CO ARRAY, i), for i = 1, 2,. . . , n - 1, where n is the co-rank of 14 CO ARRAY. 15 Examples. If A is allocated by the statement ALLOCATE (A [2:3, 0:7, *]) then 16 CO UBOUND (A) is [3, 7] and CO UBOUND (A, DIM=2) is 7. 17 13.7.44 CONJG (Z) 18 Description. Conjugate of a complex number. 19 Class. Elemental function. 20 Argument. Z shall be of type complex. 21 Result Characteristics. Same as Z. 22 Result Value. If Z has the value (x, y ), the result has the value (x, -y ). 23 Example. CONJG ((2.0, 3.0)) has the value (2.0, ­3.0). 24 13.7.45 COS (X) 25 Description. Cosine function. 26 Class. Elemental function. 27 Argument. X shall be of type real or complex. 28 Result Characteristics. Same as X. 29 Result Value. The result has a value equal to a processor-dependent approximation to cos(X). 30 If X is of type real, it is regarded as a value in radians. If X is of type complex, its real part is 31 regarded as a value in radians. 32 369 J3/06-007 WORKING DRAFT 2006/07/11 Example. COS (1.0) has the value 0.54030231 (approximately). 1 13.7.46 COSH (X) 2 Description. Hyperbolic cosine function. 3 Class. Elemental function. 4 Argument. X shall be of type real or complex. 5 Result Characteristics. Same as X. 6 Result Value. The result has a value equal to a processor-dependent approximation to cosh(X). 7 If X is of type complex its imaginary part is regarded as a value in radians. 8 Example. COSH (1.0) has the value 1.5430806 (approximately). 9 13.7.47 COUNT (MASK [, DIM, KIND]) 10 Description. Count the number of true elements of MASK along dimension DIM. 11 Class. Transformational function. 12 Arguments. 13 MASK shall be of type logical. It shall be an array. 14 shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of MASK. The corresponding actual argument shall not 15 be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 16 Result Characteristics. Integer. If KIND is present, the kind type parameter is that spec- 17 ified by the value of KIND; otherwise the kind type parameter is that of default integer type. 18 The result is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 19 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of MASK. 20 Result Value. 21 Case (i): The result of COUNT (MASK) has a value equal to the number of true elements 22 of MASK or has the value zero if MASK has size zero. 23 Case (ii): If MASK has rank one, COUNT (MASK, DIM) has a value equal to that of 24 COUNT (MASK). Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , 25 . . . , sn ) of COUNT (MASK, DIM) is equal to COUNT (MASK (s1 , s2 , . . . , 26 sDIM-1 , :, sDIM+1 , . . . , sn )). 27 Examples. 28 Case (i): The value of COUNT ((/ .TRUE., .FALSE., .TRUE. /)) is 2. 29 1 a 0 , 35 35 Case (ii): If B is the array nd C is the array COUNT (B /= C, 30 246 748 DIM = 1) is [2, 0, 1] and COUNT (B /= C, DIM = 2) is [1, 2]. 31 13.7.48 CPU TIME (TIME) 32 Description. Returns the processor time. 33 Class. Subroutine. 34 370 2006/07/11 WORKING DRAFT J3/06-007 Argument. TIME shall be scalar and of type real. It is an INTENT(OUT) argument that is 1 assigned a processor-dependent approximation to the processor time in seconds. If the processor 2 cannot return a meaningful time, a processor-dependent negative value is returned. 3 Example. 4 REAL T1, T2 5 ... 6 CALL CPU TIME(T1) 7 ... ! Code to be timed. 8 CALL CPU TIME(T2) 9 WRITE (*,*) 'Time taken by code was ', T2-T1, ' seconds' 10 writes the processor time taken by a piece of code. 11 NOTE 13.8 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. 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]) 12 Description. Perform a circular shift on an array expression of rank one or perform circular 13 shifts on all the complete rank one sections along a given dimension of an array expression of 14 rank two or greater. Elements shifted out at one end of a section are shifted in at the other end. 15 Different sections may be shifted by different amounts and in different directions. 16 Class. Transformational function. 17 Arguments. 18 ARRAY may be of any type. It shall be an array. 19 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-1 , dDIM+1 , 20 . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of ARRAY. If DIM is omitted, it is as if it were present 21 with the value 1. Result Characteristics. The result is of the type and type parameters of ARRAY, and has 22 the shape of ARRAY. 23 Result Value. 24 371 J3/06-007 WORKING DRAFT 2006/07/11 Case (i): If ARRAY has rank one, element i of the result is ARRAY (1 + MODULO (i + 1 SHIFT ­ 1, SIZE (ARRAY))). 2 Case (ii): If ARRAY has rank greater than one, section (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , 3 . . . ., sn ) of the result has a value equal to CSHIFT (ARRAY (s1 , s2 , . . . , sDIM-1 , 4 :, sDIM+1 , . . . ., sn ), sh, 1), where sh is SHIFT or SHIFT (s1 , s2 , . . . , sDIM-1 , 5 sDIM+1 , . . . , sn ). 6 Examples. 7 Case (i): If V is the array [1, 2, 3, 4, 5, 6], the effect of shifting V circularly to the left by 8 two positions is achieved by CSHIFT (V, SHIFT = 2) which has the value [3, 4, 9 5, 6, 1, 2]; CSHIFT (V, SHIFT = ­2) achieves a circular shift to the right by two 10 positions and has the value [5, 6, 1, 2, 3, 4]. 11 Case (ii): The rows of an array of rank two my all be a shifted by the same amount or by 12 123 different amounts. If M is the array 4 56 , the value of 13 789 312 CSHIFT (M, SHIFT = ­1, DIM = 2) is 6 4 5 , and the value of 14 978 312 CSHIFT (M, SHIFT = (/ ­1, 1, 0 /), DIM = 2) is 5 6 4 . 15 789 13.7.50 DATE AND TIME ([DATE, TIME, ZONE, VALUES]) 16 Description. Returns data about the real-time clock and date in a form compatible with the 17 representations defined in ISO 8601:1988. 18 Class. Subroutine. 19 Arguments. 20 DATE (optional) shall be scalar and of type default character. It is an INTENT (OUT) ar- gument. 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 the month. If there is no date available, DATE is 21 assigned all blanks. TIME (optional) shall be scalar and of type default character. It is an INTENT (OUT) argu- ment. 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 there is no clock available, TIME is assigned 22 all blanks. ZONE (optional) shall be scalar and of type default character. It is an INTENT (OUT) argu- ment. 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, respectively. If this information is not available, ZONE 23 is assigned all blanks. VALUES shall be of type default integer and of rank one. It is an INTENT (OUT) (optional) argument. Its size shall be at least 8. The values returned in VALUES are 24 as follows: VALUES (1) the year, including the century (for example, 1990), or ­HUGE (0) if there is 25 no date available; 372 2006/07/11 WORKING DRAFT J3/06-007 VALUES (2) the month of the year, or ­HUGE (0) if there is no date available; 1 VALUES (3) the day of the month, or ­HUGE (0) if there is no date available; 2 VALUES (4) the time difference with respect to Coordinated Universal Time (UTC) in 3 minutes, or ­HUGE (0) if this information is not available; VALUES (5) the hour of the day, in the range of 0 to 23, or ­HUGE (0) if there is no clock; 4 VALUES (6) the minutes of the hour, in the range 0 to 59, or ­HUGE (0) if there is no 5 clock; VALUES (7) the seconds of the minute, in the range 0 to 60, or ­HUGE (0) if there is no 6 clock; VALUES (8) the milliseconds of the second, in the range 0 to 999, or ­HUGE (0) if there 7 is no clock. Example. 8 INTEGER DATE_TIME (8) 9 CHARACTER (LEN = 10) BIG_BEN (3) 10 CALL DATE_AND_TIME (BIG_BEN (1), BIG_BEN (2), & 11 BIG_BEN (3), DATE_TIME) 12 If run in Geneva, Switzerland on April 12, 1985 at 15:27:35.5 with a system configured for the 13 local time zone, this sample would have assigned the value 19850412 to BIG BEN (1), the value 14 152735.500 to BIG BEN (2), the value +0100 to BIG BEN (3), and the value (/ 1985, 4, 12, 15 60, 15, 27, 35, 500 /) to DATE TIME. 16 NOTE 13.9 UTC is defined by ISO 8601:1988. 13.7.51 DBLE (A) 17 Description. Convert to double precision real type. 18 Class. Elemental function. 19 Argument. A shall be of type integer, real, or complex, or bits. 20 Result Characteristics. Double precision real. 21 Result Value. The result has the value REAL (A, KIND (0.0D0)). 22 Example. DBLE (­3) has the value ­3.0D0. 23 13.7.52 DIGITS (X) 24 Description. Returns the number of significant digits of the model representing numbers of 25 the same type and kind type parameter as the argument. 26 Class. Inquiry function. 27 Argument. X shall be of type integer or real. It may be a scalar or an array. 28 Result Characteristics. Default integer scalar. 29 373 J3/06-007 WORKING DRAFT 2006/07/11 Result Value. The result has the value q if X is of type integer and p if X is of type real, 1 where q and p are as defined in 13.4 for the model representing numbers of the same type and 2 kind type parameter as X. 3 Example. DIGITS (X) has the value 24 for real X whose model is as in Note 13.5. 4 13.7.53 DIM (X, Y) 5 Description. The difference X­Y if it is positive; otherwise zero. 6 Class. Elemental function. 7 Arguments. 8 X shall be of type integer or real. 9 Y shall be of the same type and kind type parameter as X. 10 Result Characteristics. Same as X. 11 Result Value. The value of the result is X­Y if X>Y and zero otherwise. 12 Example. DIM (­3.0, 2.0) has the value 0.0. 13 13.7.54 DOT PRODUCT (VECTOR A, VECTOR B) 14 Description. Performs dot-product multiplication of numeric or logical vectors. 15 Class. Transformational function. 16 Arguments. 17 VECTOR A shall be of numeric type (integer, real, or complex) or of logical type. It shall 18 be a rank-one array. VECTOR B shall be of numeric type if VECTOR A is of numeric type or of type logical if VECTOR A is of type logical. It shall be a rank-one array. It shall be of 19 the same size as VECTOR A. Result Characteristics. If the arguments are of numeric type, the type and kind type pa- 20 rameter of the result are those of the expression VECTOR A * VECTOR B determined by the 21 types of the arguments according to 7.1.4.2. If the arguments are of type logical, the result is 22 of type logical with the kind type parameter of the expression VECTOR A .AND. VECTOR B 23 according to 7.1.4.2. The result is scalar. 24 Result Value. 25 Case (i): If VECTOR A is of type integer or real, the result has the value SUM (VEC- 26 TOR A*VECTOR B). If the vectors have size zero, the result has the value zero. 27 Case (ii): If VECTOR A is of type complex, the result has the value SUM (CONJG (VEC- 28 TOR A)*VECTOR B). If the vectors have size zero, the result has the value 29 zero. 30 Case (iii): If VECTOR A is of type logical, the result has the value ANY (VECTOR A 31 .AND. VECTOR B). If the vectors have size zero, the result has the value false. 32 Example. DOT PRODUCT ((/ 1, 2, 3 /), (/ 2, 3, 4 /)) has the value 20. 33 13.7.55 DPROD (X, Y) 34 374 2006/07/11 WORKING DRAFT J3/06-007 Description. Double precision real product. 1 Class. Elemental function. 2 Arguments. 3 X shall be of type default real. 4 Y shall be of type default real. 5 Result Characteristics. Double precision real. 6 Result Value. The result has a value equal to a processor-dependent approximation to the 7 product of X and Y. 8 Example. DPROD (­3.0, 2.0) has the value ­6.0D0. 9 13.7.56 DSHIFTL (I, J, SHIFT) 10 Description. Performs a combined left shift. 11 Class. Elemental function. 12 Arguments. 13 I shall be of type integer or bits. 14 J shall be of the same type and kind as I. 15 SHIFT shall be of type integer. It shall be nonnegative and less than or equal to 16 BIT SIZE (I). Result Characteristics. Same as I. 17 Result Value. The result has the value 18 IOR (SHIFTL (I, SHIFT), SHIFTR (J, BIT SIZE (J)-SHIFT)). DSHIFTL (I, I, SHIFT) has 19 the same result value as ISHFTC (I, SHIFT). 20 Example. DSHIFTL (Z'01234567', Z'89ABCDEF', 8) has the value Z'23456789'. 21 13.7.57 DSHIFTR (I, J, SHIFT) 22 Description. Performs a combined right shift. 23 Class. Elemental function. 24 Arguments. 25 I shall be of type integer or bits. 26 J shall be of the same type and kind as I. 27 SHIFT shall be of type integer. It shall be nonnegative and less than or equal to 28 BIT SIZE (I). Result Characteristics. Same as I. 29 Result Value. The result has the value IOR (SHIFTL (I, BIT SIZE (I)-SHIFT), SHIFTR (J, SHIFT)). 30 DSHIFTR (I, I, SHIFT) has the same result value as ISHFTC (I,-SHIFT). 31 Examples. DSHIFTR(Z'01234567', Z'89ABCDEF', 8) has the value Z'6789ABCD'. 32 375 J3/06-007 WORKING DRAFT 2006/07/11 DSHIFTR (B'111', B'000', 2) has the value B'110'. 1 13.7.58 EOSHIFT (ARRAY, SHIFT [, BOUNDARY, DIM]) 2 Description. Perform an end-off shift on an array expression of rank one or perform end-off 3 shifts on all the complete rank-one sections along a given dimension of an array expression of 4 rank two or greater. Elements are shifted off at one end of a section and copies of a boundary 5 value are shifted in at the other end. Different sections may have different boundary values and 6 may be shifted by different amounts and in different directions. 7 Class. Transformational function. 8 Arguments. 9 ARRAY may be of any type. It shall be an array. 10 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-1 , dDIM+1 , 11 . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. BOUNDARY shall be of the same type and type parameters as ARRAY and shall be scalar if ARRAY has rank one; otherwise, it shall be either scalar or of rank n - 1 (optional) and of shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ). BOUNDARY may be omitted for the types in the following table and, in this case, it is as if it were present with the scalar value shown. Type of ARRAY Value of BOUNDARY Integer 0 Real 0.0 Complex (0.0, 0.0) Logical false 12 Character (len ) len blanks J3 internal note Unresolved Technical Issue 64 No default padding value in EOSHIFT for type Bits. Is this deliberate? shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of ARRAY. If DIM is omitted, it is as if it were present 13 with the value 1. Result Characteristics. The result has the type, type parameters, and shape of ARRAY. 14 Result Value. Element (s1 , s2 , . . . , sn ) of the result has the value ARRAY (s1 , s2 , . . . , sDIM-1 , 15 sDIM + sh, sDIM+1 , . . . , sn ) where sh is SHIFT or SHIFT (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) 16 provided the inequality LBOUND (ARRAY, DIM) sDIM + sh UBOUND (ARRAY, DIM) 17 holds and is otherwise BOUNDARY or BOUNDARY (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ). 18 Examples. 19 Case (i): If V is the array [1, 2, 3, 4, 5, 6], the effect of shifting V end-off to the left by 3 20 positions is achieved by EOSHIFT (V, SHIFT = 3), which has the value [4, 5, 21 6, 0, 0, 0]; EOSHIFT (V, SHIFT = ­2, BOUNDARY = 99) achieves an end-off 22 shift to the right by 2 positions with the boundary value of 99 and has the value 23 [99, 99, 1, 2, 3, 4]. 24 Case (ii): The rows of an array of rank two may all be shifted by the same amount or by 25 different amounts and the boundary elements can be the same or different. If M is 26 376 2006/07/11 WORKING DRAFT J3/06-007 A BC the array D E F , then the value of EOSHIFT (M, SHIFT = ­1, BOUND- 1 G HI *AB ARY = '*', DIM = 2) is * D E , and the value of EOSHIFT (M, SHIFT = GH 2 *AB (/ ­1, 1, 0 /), BOUNDARY = (/ '*', '/', ' ?' /), DIM = 2) is E F / . 3 GHI 13.7.59 EPSILON (X) 4 Description. Returns a positive model number that is almost negligible compared to unity of 5 the model representing numbers of the same type and kind type parameter as the argument. 6 Class. Inquiry function. 7 Argument. X shall be of type real. It may be a scalar or an array. 8 Result Characteristics. Scalar of the same type and kind type parameter as X. 9 Result Value. The result has the value b1-p where b and p are as defined in 13.4 for the model 10 representing numbers of the same type and kind type parameter as X. 11 Example. EPSILON (X) has the value 2-23 for real X whose model is as in Note 13.5. 12 13.7.60 ERF (X) 13 Description. Error function. 14 Class. Elemental function. 15 Argument. X shall be of type real. 16 Result Characteristics. Same as X. 17 Result Value. The result has a value equal to a processor-dependent approximation to the 18 2 error function of X, 0 exp -t2 dt. X 19 Example. ERF (1.0) has the value 0.843 (approximately). 20 13.7.61 ERFC (X) 21 Description. Complementary error function. 22 Class. Elemental function. 23 Argument. X shall be of type real. 24 Result Characteristics. Same as X. 25 Result Value. The result has a value equal to a processor-dependent approximation to the 26 complementary error function (that is, 1 - ERF (X)) of X. 27 Example. ERFC (1.0) has the value 0.157 (approximately). 28 13.7.62 ERFC SCALED (X) 29 377 J3/06-007 WORKING DRAFT 2006/07/11 Description. Exponentially-scaled complementary error function. 1 Class. Elemental function. 2 Argument. X shall be of type real. 3 Result Characteristics. Same as X. 4 Result Value. The result has a value equal to a processor-depndent approximation to the e 5 2 exponentially-scaled complementary error function, exp(X 2 ) X exp(-t2 )dt. 6 Example. ERFC SCALED (20.0) has the value 0.02817434874 (approximately). 7 NOTE 13.10 The complementary error function is asymptotic to exp(-X 2 )/(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 ]) 8 Description. Execute the command line specified by the string COMMAND. If the processor 9 supports command line execution, it shall support synchronous and may support asynchronous 10 execution of the command line. 11 Class. Subroutine. 12 Arguments. 13 COMMAND shall be of type default character and shall be scalar. It is an INTENT(IN) argument. Its value is the command line to be executed. The interpretation 14 is processor-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 sup- ports asynchronous execution of the command, the command is executed 15 asynchronously; otherwise it is executed synchronously. EXITSTAT shall be of type default integer and shall be a scalar. It is an IN- (optional) TENT(INOUT) argument. If the command is executed synchronously, it is assigned the value of the processor-dependent exit status. Otherwise, the 16 value of EXITSTAT is unchanged. CMDSTAT shall be of type default integer and shall be a scalar. It is an INTENT(OUT) argument. It is assigned the value -1 if the processor does not support (optional) 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 17 execution. Otherwise it is assigned the value 0. 378 2006/07/11 WORKING DRAFT J3/06-007 CMDMSG shall be of type default character and shall be a scalar. It is an IN- (optional) TENT(INOUT) argument. If an error condition occurs, it is assigned a processor-dependent explanatory message. Otherwise, it is unchanged. When the command is executed synchronously, EXE- CUTE COMMAND LINE returns after the command line has completed execution. Otherwise, EXECUTE COMMAND LINE returns without waiting. If an error condition occurs and CMDSTAT is not present, execution of the 1 program is terminated. 13.7.64 EXP (X) 2 Description. Exponential. 3 Class. Elemental function. 4 Argument. X shall be of type real or complex. 5 Result Characteristics. Same as X. 6 Result Value. The result has a value equal to a processor-dependent approximation to eX . If 7 X is of type complex, its imaginary part is regarded as a value in radians. 8 Example. EXP (1.0) has the value 2.7182818 (approximately). 9 13.7.65 EXPONENT (X) 10 Description. Returns the exponent part of the argument when represented as a model number. 11 Class. Elemental function. 12 Argument. X shall be of type real. 13 Result Characteristics. Default integer. 14 Result Value. The result has a value equal to the exponent e of the representation for the 15 value of X in the model (13.4) that has the radix of X but no limits on exponent values, provided 16 X is nonzero and e is within the range for default integers. If X has the value zero, the result 17 has the value zero. If X is an IEEE infinity or NaN, the result has the value HUGE(0). 18 Examples. EXPONENT (1.0) has the value 1 and EXPONENT (4.1) has the value 3 for reals 19 whose model is as in Note 13.5. 20 13.7.66 EXTENDS TYPE OF (A, MOLD) 21 Description. Inquires whether the dynamic type of A is an extension type (4.5.7) of the 22 dynamic type of MOLD. 23 Class. Inquiry function. 24 Arguments. 25 A shall be an ob ject of extensible type. If it is a pointer, it shall not have an 26 undefined association status. MOLD shall be an ob ject of extensible type. If it is a pointer, it shall not have an 27 undefined association status. Result Characteristics. Default logical scalar. 28 379 J3/06-007 WORKING DRAFT 2006/07/11 Result Value. If MOLD is unlimited polymorphic and is either a disassociated pointer or 1 unallocated allocatable, the result is true; otherwise if A is unlimited polymorphic and is either 2 a disassociated pointer or unallocated allocatable, the result is false; otherwise the result is true 3 if and only if the dynamic type of A is an extension type of the dynamic type of MOLD. 4 NOTE 13.11 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]) 5 Description. Determine the location of the first element of ARRAY identified by MASK along 6 dimension DIM having a value equal to VALUE. 7 Class. Transformational function. 8 Arguments. 9 ARRAY shall be of intrinsic type. It shall be an array. 10 VALUE shall be in type conformance with ARRAY, as specified in Table 7.10. 11 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 12 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 13 KIND (optional) shall be a scalar integer initialization expression. 14 BACK (optional) shall be scalar and of type logical. 15 NOTE TO THE EDITOR: type set the d1, ei, sDIM+1, etc. as in MAXLOC 16 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 17 by the value of KIND; otherwise the kind type parameter is that of default integer type. If DIM 18 is absent, the result is an array of rank one and of size equal to the rank of ARRAY; otherwise, 19 the result is of rank n - 1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ), where (d1 , d2 , . . . , 20 dn ) is the shape of ARRAY. 21 Result Value. 22 Case (i): The result of FINDLOC (ARRAY, VALUE) is a rank-one array whose element 23 values are the values of the subscripts of an element of ARRAY whose value 24 matches VALUE. The ith subscript returned lies in the range 1 to ei , where ei 25 is the extent of the ith dimension of ARRAY. If no elements match VALUE or 26 ARRAY has size zero, all elements of the result are zero. 27 Case (ii): The result of FINDLOC (ARRAY, VALUE, MASK = MASK) is a rank-one array 28 whose element values are the values of the subscripts of an element of ARRAY, 29 corresponding to a true element of MASK, whose value matches VALUE. The 30 ith subscript returned lies in the range 1 to ei , where ei is the extent of the ith 31 dimension of ARRAY. If no elements match VALUE, ARRAY has size zero, or 32 every element of MASK has the value false, all elements of the result are zero. 33 Case (iii): If ARRAY has rank one, 34 FINDLOC (ARRAY, VALUE, DIM=DIM [, MASK = MASK]) is a scalar whose 35 value is equal to that of the first element of FINDLOC (ARRAY, VALUE [, 36 380 2006/07/11 WORKING DRAFT J3/06-007 MASK = MASK]). Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , 1 . . . , sn ) of the result is equal to FINDLOC (ARRAY (s1 , s2 , . . . , sDIM-1 , :, 2 sDIM+1 , . . . , sn ), VALUE, DIM=1, [, MASK = MASK (s1 , s2 , . . . , sDIM-1 , :, 3 sDIM+1 , . . . , sn )]). 4 If both ARRAY and VALUE are of type logical, the comparison is performed as 5 array-element .EQV. VALUE; otherwise, the comparison is performed as array- 6 element == VALUE. If the value of the comparison is true, array-element matches 7 VALUE. 8 If only one element matches VALUE, that element's subscripts are returned. 9 Otherwise, if more than one element matches VALUE and BACK is absent or 10 present with the value false, the element whose subscripts are returned is the first 11 such element, taken in array element order. If BACK is present with the value 12 true, the element whose subscripts are returned is the last such element, taken in 13 array element order. 14 Examples. 15 Case (i): The value of FINDLOC ((/2, 6, 4, 6 /), 6) is [2], and the value of FIND- 16 LOC ((/2, 6, 4, 6 /), 6, BACK=.TRUE.) is [4]. 17 0 -5 7 7 TT F T If A has the value 3 4 -1 2 , and M has the value T T F T , Case (ii): 18 15 67 TT F T FINDLOC (A, 7, MASK = M) has the value [1, 4] and 19 FINDLOC (A, 7, MASK = M, BACK = .TRUE.) has the value [3, 4]. Note that 20 this is independent of the declared lower bounds for A. 21 Case (iii): The value of FINDLOC ([2, 6, 4], VALUE=6, DIM=1) is 2. If B has the value 22 1 , 2 -9 FINDLOC (B, 2, DIM=1) has the value [2, 1, 0] and FIND- 23 22 6 LOC (B, 2, DIM=2) has the value [2, 1]. Note that this is true even if B has a 24 declared lower bound other than 1. 25 13.7.68 FLOOR (A [, KIND]) 26 Description. Returns the greatest integer less than or equal to its argument. 27 Class. Elemental function. 28 Arguments. 29 A shall be of type real. 30 KIND (optional) shall be a scalar integer initialization expression. 31 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 32 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 33 Result Value. The result has a value equal to the greatest integer less than or equal to A. 34 Examples. FLOOR (3.7) has the value 3. FLOOR (­3.7) has the value ­4. 35 13.7.69 FORM TEAM (TEAM, IMAGES) 36 Description. Form a team of images. 37 Class. Collective subroutine. 38 381 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 63 I don't see why FORM TEAM needs synchronisation ­ that seems completely unnecessary (it has no co-array argument, no need for communication ­ its actual arguments are all simple local variables). If this needs synchronisation, why does SYNC IMAGES not need synchronisation? Arguments. 1 TEAM shall be a scalar of type IMAGE TEAM (13.8.3.5). It is an INTENT(OUT) 2 argument. 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 have the same value 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. It 3 shall not have size zero. Example. 4 The following splits images into two equal groups and implicitly synchronizes each of the teams 5 if there are two or more images. If there is only one image, that image becomes the only team 6 member. 7 USE, INTRINSIC :: ISO_FORTRAN_ENV 8 INTEGER :: I 9 TYPE(IMAGE_TEAM) :: TEAM 10 IF (THIS_IMAGE()<=NUM_IMAGES()/2) THEN 11 CALL FORM_TEAM(TEAM,[(I,I=1,NUM_IMAGES()/2)]) 12 ELSE 13 CALL FORM_TEAM(TEAM,[(I,I=NUM_IMAGES()/2+1,NUM_IMAGES())]) 14 END IF 15 13.7.70 FRACTION (X) 16 Description. Returns the fractional part of the model representation of the argument value. 17 Class. Elemental function. 18 Argument. X shall be of type real. 19 Result Characteristics. Same as X. 20 Result Value. The result has the value X × b-e , where b and e are as defined in 13.4 for the 21 model representation of X. If X has the value zero, the result has the value zero. If X is an IEEE 22 infinity, the result is that infinity. If X is an IEEE NaN, the result is that NaN. 23 Example. FRACTION (3.0) has the value 0.75 for reals whose model is as in Note 13.5. 24 13.7.71 GAMMA (X) 25 Description. Gamma function. 26 Class. Elemental function. 27 382 2006/07/11 WORKING DRAFT J3/06-007 Argument. X shall be of type real. Its value shall not be a negative integer or zero. 1 Result Characteristics. Same as X. 2 Result Value. The result has value equal to a processor-dependent approximation to the a 3 gamma function of X, (X ) = 0 exp -ttX -1 dt. 4 Example. GAMMA (1.0) has the value 1.000 (approximately). 5 13.7.72 GET COMMAND ([COMMAND, LENGTH, STATUS]) 6 Description. Returns the entire command by which the program was invoked. 7 Class. Subroutine. 8 Arguments. 9 COMMAND shall be scalar and of type default character. It is an INTENT(OUT) argu- (optional) ment. It is assigned the entire command by which the program was invoked. 10 If the command cannot be determined, COMMAND is assigned all blanks. LENGTH shall be scalar and of type default integer. It is an INTENT(OUT) argument. (optional) It is assigned the significant length of the command by which the program was invoked. The significant length may include trailing blanks if the pro- cessor allows commands with significant trailing blanks. This length does not consider any possible truncation 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 determined, a length of 0 11 is assigned. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. (optional) It 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 positive value if the command retrieval fails. Otherwise 12 it is assigned the value 0. 13.7.73 GET COMMAND ARGUMENT (NUMBER [, VALUE, LENGTH, STA- TUS]) 13 Description. Returns a command argument. 14 Class. Subroutine. 15 Arguments. 16 NUMBER shall be scalar and of type default integer. It is an INTENT(IN) argument. 17 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 18 below). 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 processor does not define command names or other 19 command arguments. 383 J3/06-007 WORKING DRAFT 2006/07/11 The remaining command arguments are numbered consecutively from 1 to 1 the argument count in an order determined by the processor. VALUE shall be scalar and of type default character. It is an INTENT(OUT) ar- (optional) gument. It is assigned the value of the command argument specified by NUMBER. If the command argument value cannot be determined, VALUE 2 is assigned all blanks. LENGTH shall be scalar and of type default integer. It is an INTENT(OUT) argument. (optional) It 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 possible 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 argument length cannot be determined, 3 a length of 0 is assigned. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. (optional) It is 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 4 retrieval fails. Otherwise it is assigned the value 0. NOTE 13.12 One possible reason for failure is that NUMBER is negative or greater than COMMAND ARGU- MENT COUNT(). Example. 5 Program echo 6 integer :: i 7 character :: command*32, arg*128 8 call get_command_argument(0, command) 9 write (*,*) "Command name is: ", command 10 do i = 1 , command_argument_count() 11 call get_command_argument(i, arg) 12 write (*,*) "Argument ", i, " is ", arg 13 end do 14 end program echo 15 13.7.74 GET ENVIRONMENT VARIABLE (NAME [, VALUE, LENGTH, STA- TUS, TRIM NAME]) 16 Description. Gets the value of an environment variable. 17 Class. Subroutine. 18 Arguments. 19 NAME shall be scalar and of type default character. It is an INTENT(IN) argument. 20 The interpretation of case is processor dependent 384 2006/07/11 WORKING DRAFT J3/06-007 VALUE shall be a scalar of type default character. It is an INTENT(OUT) argu- (optional) ment. It is 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 processor does not support environment vari- 1 ables. LENGTH shall be a scalar of type default integer. It is an INTENT(OUT) argument. (optional) If the specified environment variable exists and has a value, LENGTH is set 2 to the length of that value. Otherwise LENGTH is set to 0. STATUS shall be scalar and of type default integer. It is an INTENT(OUT) argument. (optional) If the 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 greater than 2 may be 3 returned for other error conditions. TRIM NAME shall be a scalar of type logical. It is an INTENT(IN) argument. If (optional) TRIM NAME is present with the value false then trailing blanks in NAME are considered significant if the processor supports trailing blanks in environ- ment variable names. Otherwise trailing blanks in NAME are not considered 4 part of the environment variable's name. 13.7.75 HUGE (X) 5 Description. Returns the largest number of the model representing numbers of the same type 6 and kind type parameter as the argument. 7 Class. Inquiry function. 8 Argument. X shall be of type integer, real, or bits. It may be a scalar or an array. 9 Result Characteristics. Scalar of the same type and kind type parameter as X. 10 Result Value. The result has the value rq - 1 if X is of type integer and (1 - b-p )bemax if X is 11 of type real, where r, q , b, p, and emax are as defined in 13.4 for the model representing numbers 12 of the same type and kind type parameter as X. If X is of type bits, the result value has all of 13 its bits set to 1. 14 Example. HUGE (X) has the value (1 - 2-24 ) × 2127 for real X whose model is as in Note 13.5. 15 13.7.76 HYPOT (X, Y) 16 Description. Euclidean distance function. 17 Class. Elemental function. 18 Arguments. 19 X shall be of type real. 20 Y shall be of type real with the same kind type parameter as X. 21 Result Characteristics. Same as X. 22 Result Value. The result has a value equal to a processor-dependent approximation to the 23 385 J3/06-007 WORKING DRAFT 2006/07/11 X 2 + Y2 , without undue overflow or underflow. Euclidean distance, 1 Example. HYPOT (2.0, 1.0) has the value 2.236 (approximately). 2 13.7.77 IACHAR (C [, KIND]) 3 Description. Returns the position of a character in the ASCII collating sequence. This is the 4 inverse of the ACHAR function. 5 Class. Elemental function. 6 Arguments. 7 C shall be of type character and of length one. 8 KIND (optional) shall be a scalar integer initialization expression. 9 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 10 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 11 Result Value. If C is in the collating sequence defined by the codes specified in ISO/IEC 12 646:1991 (International Reference Version), the result is the position of C in that sequence and 13 satisfies the inequality (0 IACHAR(C) 127). A processor-dependent value is returned if C 14 is not in the ASCII collating sequence. The results are consistent with the LGE, LGT, LLE, 15 and LLT lexical comparison functions. For example, if LLE (C, D) is true, IACHAR (C) <= 16 IACHAR (D) is true where C and D are any two characters representable by the processor. 17 Example. IACHAR ('X') has the value 88. 18 13.7.78 IALL (ARRAY, DIM [, MASK]) or IALL (ARRAY, [MASK]) 19 Description. Bitwise AND of all the elements of ARRAY along dimension DIM corresponding 20 to the true elements of MASK. 21 Class. Transformational function. 22 Arguments. 23 ARRAY shall be of type integer or bits. It shall be an array. 24 shall be a scalar of type integer with a value in the range 1 DIM n, where DIM (optional) n is the rank of ARRAY. The corresponding actual argument shall not be an 25 optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 26 Result Characteristics. The result is of the same type and kind type parameter as ARRAY. 27 It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank 28 n - 1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of 29 ARRAY. 30 Result Value. 31 Case (i): The result of IALL (ARRAY) has a value equal to the bitwise AND of all 32 the elements of ARRAY. If ARRAY has size zero the result value is equal to 33 NOT (INT (0, KIND (ARRAY))) if ARRAY is of type integer, and 34 NOT (BITS (B'0', KIND (ARRAY))) otherwise. 35 Case (ii): The result of IALL (ARRAY, MASK=MASK) has a value equal to 36 386 2006/07/11 WORKING DRAFT J3/06-007 IALL (PACK (ARRAY, MASK)). 1 Case (iii): The result of IALL (ARRAY, DIM=DIM [ , MASK=MASK]) has a value equal to 2 that of IALL (ARRAY, [ , MASK=MASK]) if ARRAY has rank one. Otherwise, 3 the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of the result is equal to 4 IALL (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) [, MASK = MASK (s1 , 5 s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn )]). 6 Examples. IALL ([B'1110', B'1101', B'1011']) has the value B'1000'. IALL ([B'1110', B'1101', 7 B'1011'], MASK=[.true., .false., .true]) has the value B'1010'. IALL([14, 13, 11]) has the value 8 8. IALL([14, 13, 11], MASK=[.true., .false., .true]) has the value 10. 9 13.7.79 IAND (I, J) 10 Description. Performs a bitwise AND. 11 Class. Elemental function. 12 Arguments. 13 I shall be of type integer or bits. 14 J shall be of type integer or bits. BITS KIND (I) shall be equal to 15 BITS KIND (J). Result Characteristics. If I and J have the same type, the result characteristics are the same 16 as I. Otherwise, the result characteristics are the same as those of the argument with integer 17 type. 18 Result Value. The result has the value obtained by combining I and J bit-by-bit according to 19 the following truth table: 20 I J IAND (I, J) 1 1 1 1 0 0 0 1 0 0 0 0 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 21 Examples. IAND (1, 3) has the value 1. IAND (Z'12345678', Z'0000FFFF') has the value 22 Z'00005678'. 23 13.7.80 IANY (ARRAY, DIM [, MASK]) or IANY (ARRAY, [MASK]) 24 Description. Bitwise OR of all the elements of ARRAY along dimension DIM corresponding 25 to the true elements of MASK. 26 Class. Transformational function. 27 Arguments. 28 ARRAY shall be of type integer or bits. It shall be an array. 29 shall be a scalar and of type integer with a value in the range 1 DI M n, DIM (optional) where n is the rank of ARRAY. The corresponding actual argument shall not 30 be an optional dummy argument. 387 J3/06-007 WORKING DRAFT 2006/07/11 MASK (optional) shall be of type logical and shall be conformable with ARRAY. 1 Result Characteristics. The result is of the same type and kind type parameter as ARRAY. 2 It is scalar if DIM is absent or if ARRAY has rank one; otherwise, the result is an array of rank 3 n - 1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of 4 ARRAY. 5 Result Value. 6 Case (i): The result of IANY (ARRAY) is the bitwise OR of all the elements of ARRAY. 7 If ARRAY has size zero the result value is equal to zero if ARRAY is of type 8 integer, and BITS (B'0', KIND(ARRAY)) otherwise. 9 Case (ii): The result of IANY (ARRAY, MASK=MASK) has a value equal to 10 IANY (PACK (ARRAY, MASK)). 11 Case (iii): The result of IANY (ARRAY, DIM=DIM [, MASK=MASK]) has a value equal to 12 that of IANY (ARRAY, [, MASK=MASK]) if ARRAY has rank one. Otherwise, 13 the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of the result is equal to 14 IANY (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) [, MASK = MASK(s1 , 15 s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn )]). 16 Examples. IANY ([B'1110', B'1101', B'1000']) has the value B'1111'. IANY ([B'1110', B'1101', 17 B'1000'], MASK=[.true., .false., .true]) has the value B'1110'. IANY ([14, 13, 8]) has the value 18 15. IANY ([14, 13, 8], MASK=[.true., .false., .true]) has the value 14. 19 13.7.81 IBCLR (I, POS) 20 Description. Clears one bit to zero. 21 Class. Elemental function. 22 Arguments. 23 I shall be of type integer or bits. 24 POS shall be of type integer. It shall be nonnegative and less than BIT SIZE (I). 25 Result Characteristics. Same as I. 26 Result Value. The result has the value of the sequence of bits of I, except that bit POS is 27 zero. The model for the interpretation of an integer value as a sequence of bits is in 13.3. 28 Examples. IBCLR (14, 1) has the value 12. If V has the value [1, 2, 3, 4], the value of 29 IBCLR (POS = V, I = 31) is [29, 27, 23, 15].IBCLR (B'11111', 3) has the value B'10111'. 30 13.7.82 IBITS (I, POS, LEN) 31 Description. Extracts a sequence of bits. 32 Class. Elemental function. 33 Arguments. 34 I shall be of type integer or bits. 35 POS shall be of type integer. It shall be nonnegative and POS + LEN shall be 36 less than or equal to BIT SIZE (I). LEN shall be of type integer and nonnegative. 37 388 2006/07/11 WORKING DRAFT J3/06-007 Result Characteristics. Same as I. 1 Result Value. The result has the value of the sequence of LEN bits in I beginning at bit POS, 2 right-adjusted and with all other bits zero. The model for the interpretation of an integer value 3 as a sequence of bits is in 13.3. 4 Examples. IBITS (14, 1, 3) has the value 7. IBITS (Z'ABCD', 4, 8) has the value Z'00BC'. 5 13.7.83 IBSET (I, POS) 6 Description. Sets one bit to one. 7 Class. Elemental function. 8 Arguments. 9 I shall be of type integer or bits. 10 POS shall be of type integer. It shall be nonnegative and less than BIT SIZE (I). 11 Result Characteristics. Same as I. 12 Result Value. The result has the value of the sequence of bits of I, except that bit POS is one. 13 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 14 Examples. IBSET (12, 1) has the value 14. If V has the value [1, 2, 3, 4], the value of 15 IBSET (POS = V, I = 0) is [2, 4, 8, 16]. IBSET (B'00000', 3) has the value B'01000'. 16 13.7.84 ICHAR (C [, KIND]) 17 Description. Returns the position of a character in the processor collating sequence associated 18 with the kind type parameter of the character. This is the inverse of the CHAR function. 19 Class. Elemental function. 20 Arguments. 21 C shall be of type character and of length one. Its value shall be that of a 22 character capable of representation in the processor. KIND (optional) shall be a scalar integer initialization expression. 23 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 24 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 25 Result Value. The result is the position of C in the processor collating sequence associated 26 with the kind type parameter of C and is in the range 0 ICHAR(C) n - 1, where n is 27 the number of characters in the collating sequence. For any characters C and D capable of 28 representation in the processor, C <= D is true if and only if ICHAR (C) <= ICHAR (D) is true 29 and C == D is true if and only if ICHAR (C) == ICHAR (D) is true. 30 Example. ICHAR ('X') has the value 88 on a processor using the ASCII collating sequence for 31 the default character type. 32 13.7.85 IEOR (I, J) 33 Description. Performs a bitwise exclusive OR. 34 Class. Elemental function. 35 389 J3/06-007 WORKING DRAFT 2006/07/11 Arguments. 1 I shall be of type integer or bits. 2 J shall be of type integer or bits. BITS KIND (I) shall be equal to 3 BITS KIND (J). Result Characteristics. If I and J have the same type, the result characteristics are the same 4 as I. Otherwise, the result characteristics are the same as those of the argument with integer 5 type. 6 Result Value. The result has the value obtained by combining I and J bit-by-bit according to 7 the following truth table: 8 I J IEOR (I, J) 1 1 0 1 0 1 0 1 1 0 0 0 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 9 Examples. IEOR (1, 3) has the value 2. IEOR (Z'12340000', Z'1234FFFF') has the value 10 Z'0000FFFF'. 11 13.7.86 IMAGE INDEX (CO ARRAY, SUB) 12 Description. Returns the index of the image corresponding to the co-subscripts SUB for 13 CO ARRAY. 14 Class. Inquiry function. 15 Arguments. 16 CO ARRAY shall be a co-array of any type. 17 SUB shall be a rank-one array of size equal to the co-rank of CO ARRAY and 18 shall be of type integer. Result Characteristics. Default integer scalar. 19 Result Value. If the value of SUB is a valid sequence of co-subscripts for CO ARRAY, the 20 result is the index of the corresponding image. Otherwise, the result is zero. 21 Examples. If A is declared A [0:*], IMAGE INDEX (A, (/0/)) has the value 1. If B is declared 22 REAL B (10, 20) [10, 0:9, 0:*], IMAGE INDEX (B, [3, 1, 2]) has the value 213 (on any image). 23 NOTE 13.13 For an example of a module that implements a function similar to the intrinsic THIS IMAGE, see subclause C.10.1. 13.7.87 INDEX (STRING, SUBSTRING [, BACK, KIND]) 24 Description. Returns the starting position of a substring within a string. 25 Class. Elemental function. 26 390 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 STRING shall be of type character. 2 SUBSTRING shall be of type character with the same kind type parameter as STRING. 3 BACK (optional) shall be of type logical. 4 KIND (optional) shall be a scalar integer initialization expression. 5 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 6 by the value of KIND; otherwise the kind type parameter is that of default integer type. 7 Result Value. 8 Case (i): If BACK is absent or has the value false, the result is the minimum positive value 9 of I such that STRING (I : I + LEN (SUBSTRING) ­ 1) = SUBSTRING or zero if 10 there is no such value. Zero is returned if LEN (STRING) < LEN (SUBSTRING) 11 and one is returned if LEN (SUBSTRING) = 0. 12 Case (ii): If BACK is present with the value true, the result is the maximum value of 13 I less than or equal to LEN (STRING) ­ LEN (SUBSTRING) + 1 such that 14 STRING (I : I + LEN (SUBSTRING) ­ 1) = SUBSTRING or zero if there is 15 no such value. Zero is returned if LEN (STRING) < LEN (SUBSTRING) and 16 LEN (STRING) + 1 is returned if LEN (SUBSTRING) = 0. 17 Examples. INDEX ('FORTRAN', 'R') has the value 3. 18 INDEX ('FORTRAN', 'R', BACK = .TRUE.) has the value 5. 19 13.7.88 INT (A [, KIND]) 20 Description. Convert to integer type. 21 Class. Elemental function. 22 Arguments. 23 A shall be of type integer, real, complex, or bits. 24 KIND (optional) shall be a scalar integer initialization expression. 25 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 26 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 27 Result Value. 28 Case (i): If A is of type integer, INT (A) = A. 29 If A is of type real, there are two cases: if |A| < 1, INT (A) has the value 0; if Case (ii): 30 |A| 1, INT (A) is the integer whose magnitude is the largest integer that does 31 not exceed the magnitude of A and whose sign is the same as the sign of A. 32 Case (iii): If A is of type complex, INT(A) = INT(REAL(A, KIND(A))). 33 Case (iv): If A is of type bits, the result has the integer value such that 34 BITS (INT (A, kind )) = BITS (A, BITS KIND (INT (0, kind ))), where kind is 35 the kind of the result. If the value specified by the model in 13.3 for interpreting 36 the bits as an integer is a valid value for the result, it has that value. 37 Example. INT (­3.7) has the value ­3. 38 13.7.89 IOR (I, J) 39 391 J3/06-007 WORKING DRAFT 2006/07/11 Description. Performs a bitwise inclusive OR. 1 Class. Elemental function. 2 Arguments. 3 I shall be of type integer or bits. 4 J shall be of type integer or bits. BITS KIND (I) shall be equal to 5 BITS KIND (J). Result Characteristics. If I and J have the same type, the result characteristics are the same 6 as I. Otherwise, the result characteristics are the same as those of the argument with integer 7 type. 8 Result Value. The result has the value obtained by combining I and J bit-by-bit according to 9 the following truth table: 10 I J IOR (I, J) 1 1 1 1 0 1 0 1 1 0 0 0 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 11 Examples. IOR (5, 3) has the value 7. IOR (Z'12345678', Z'0000FFFF') has the value 12 Z'1234FFFF'. 13 13.7.90 IPARITY (ARRAY, DIM [, MASK]) or IPARITY (ARRAY, [MASK]) 14 Description. Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corre- 15 sponding to the true elements of MASK. 16 Class. Transformational function. 17 Arguments. 18 ARRAY shall be of type integer or bits. It shall be an array. 19 shall be a scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of ARRAY. The corresponding actual argument shall not 20 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 21 Result Characteristics. The result is of the same type and kind type parameter as AR- 22 RAY. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 23 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. 24 Result Value. 25 Case (i): The result of IPARITY (ARRAY) has a value equal to the bitwise exclusive OR 26 of all the elements of ARRAY. If ARRAY has size zero the result has the value 27 zero if ARRAY is of type integer, and BITS (B'0', KIND (ARRAY)) otherwise. 28 Case (ii): The result of IPARITY (ARRAY, MASK=MASK) has a value equal to that of 29 IPARITY (PACK (ARRAY, MASK)). 30 392 2006/07/11 WORKING DRAFT J3/06-007 Case (iii): The result of IPARITY (ARRAY, DIM=DIM [, MASK=MASK]) has a value 1 equal to that of IPARITY (ARRAY, [, MASK=MASK]) if ARRAY has rank one. 2 Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of the result 3 is equal to IPARITY (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) [, MASK 4 = MASK(s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn )]). 5 Examples. IPARITY ([B'1110', B'1101', B'1000']) has the value B'1011'. 6 IPARITY ([B'1110', B'1101', B'1000'], MASK=[.true., .false., .true]) has the value B'0110'. 7 IPARITY ([14, 13, 8]) has the value 11. IPARITY ([14, 13, 8], MASK=[.true., .false., .true]) 8 has the value 6. 9 13.7.91 ISHFT (I, SHIFT) 10 Description. Performs a logical shift. 11 Class. Elemental function. 12 Arguments. 13 I shall be of type integer or bits. 14 SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or 15 equal to BIT SIZE (I). Result Characteristics. Same as I. 16 Result Value. The result has the value obtained by shifting the bits of I by SHIFT positions. 17 If SHIFT is positive, the shift is to the left; if SHIFT is negative, the shift is to the right; 18 and if SHIFT is zero, no shift is performed. Bits shifted out from the left or from the right, as 19 appropriate, are lost. Zeros are shifted in from the opposite end. The model for the interpretation 20 of an integer value as a sequence of bits is in 13.3. 21 Examples. ISHFT (3, 1) has the value 6. ISHFT (B'00000011', 1) has the value B'00000110'. 22 13.7.92 ISHFTC (I, SHIFT [, SIZE]) 23 Description. Performs a circular shift of the rightmost bits. 24 Class. Elemental function. 25 Arguments. 26 I shall be of type integer or bits. 27 SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or 28 equal to 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 29 value of BIT SIZE (I). Result Characteristics. Same as I. 30 Result Value. The result has the value obtained by shifting the SIZE rightmost bits of I 31 circularly by SHIFT positions. If SHIFT is positive, the shift is to the left; if SHIFT is negative, 32 the shift is to the right; and if SHIFT is zero, no shift is performed. No bits are lost. The 33 unshifted bits are unaltered. The model for the interpretation of an integer value as a sequence 34 of bits is in 13.3. 35 393 J3/06-007 WORKING DRAFT 2006/07/11 Examples. ISHFTC (3, 2, 3) has the value 5. ISHFTC (Z'ABCD', 4, 8) has the value Z'ABDC'. 1 13.7.93 IS CONTIGUOUS (A) 2 Description. Determine whether an ob ject is contiguous (5.3.6). 3 Class. Inquiry function. 4 Argument. A may be of any type. It shall be an assumed-shape array or an array pointer. If 5 it is a pointer it shall be associated. 6 Result Characteristics. Default logical scalar. 7 Result Value. The result has the value true if A is contiguous, and false otherwise. 8 Example. After the pointer assignment AP => TARGET (1:10:2), IS CONTIGUOUS (AP) 9 will have the value false. 10 13.7.94 IS IOSTAT END (I) 11 Description. Determine whether a value indicates an end-of-file condition. 12 Class. Elemental function. 13 Argument. I shall be of type integer. 14 Result Characteristics. Default logical. 15 Result Value. The result has the value true if and only if I is a value for the scalar-int-variable 16 in an IOSTAT= specifier (9.10.4) that would indicate an end-of-file condition. 17 13.7.95 IS IOSTAT EOR (I) 18 Description. Determine whether a value indicates an end-of-record condition. 19 Class. Elemental function. 20 Argument. I shall be of type integer. 21 Result Characteristics. Default logical. 22 Result Value. The result has the value true if and only if I is a value for the scalar-int-variable 23 in an IOSTAT= specifier (9.10.4) that would indicate an end-of-record condition. 24 13.7.96 KIND (X) 25 Description. Returns the value of the kind type parameter of X. 26 Class. Inquiry function. 27 Argument. X may be of any intrinsic type. It may be a scalar or an array. 28 Result Characteristics. Default integer scalar. 29 Result Value. The result has a value equal to the kind type parameter value of X. 30 Example. KIND (0.0) has the kind type parameter value of default real. 31 13.7.97 LBOUND (ARRAY [, DIM, KIND]) 32 394 2006/07/11 WORKING DRAFT J3/06-007 Description. Returns all the lower bounds or a specified lower bound of an array. 1 Class. Inquiry function. 2 Arguments. 3 ARRAY may be of any type. It shall be an array. It shall not be an unallocated 4 allocatable or a pointer that is not associated. shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of ARRAY. The corresponding actual argument shall not 5 be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 6 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 7 by the value of KIND; otherwise the kind type parameter is that of default integer type. The 8 result is scalar if DIM is present; otherwise, the result is an array of rank one and size n, where 9 n is the rank of ARRAY. 10 Result Value. 11 Case (i): If ARRAY is a whole array or array structure component and either ARRAY is an 12 assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, 13 LBOUND (ARRAY, DIM) has a value equal to the lower bound for subscript DIM 14 of ARRAY. Otherwise the result value is 1. 15 Case (ii): LBOUND (ARRAY) has a value whose ith element is equal to LBOUND (AR- 16 RAY, i), for i = 1, 2, . . . , n, where n is the rank of ARRAY. 17 Examples. If A is declared by the statement 18 REAL A (2:3, 7:10) 19 then LBOUND (A) is [2, 7] and LBOUND (A, DIM=2) is 7. 20 13.7.98 LEADZ (I [, KIND]) 21 Description. Count the number of leading zero bits. 22 Class. Elemental function. 23 Arguments. 24 I shall be of type integer or bits. 25 KIND (optional) shall be a scalar integer initialization expression. 26 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 27 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 28 J3 internal note Unresolved Technical Issue 65 This is another spurious and ineffective useless KIND argument. Lots of these abound in the "BITS" feature. Result Value. If all of the bits of I are zero, the result has the value BIT SIZE (I). Otherwise, 29 the result has the value BIT SIZE (I) - 1 - k , where k is the position of the leftmost 1 bit in I. 30 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 31 395 J3/06-007 WORKING DRAFT 2006/07/11 Examples. LEADZ (B'001101000') has the value 2. LEADZ (1) has the value 31 if BIT SIZE (1) 1 has the value 32. 2 13.7.99 LEN (STRING [, KIND]) 3 Description. Returns the length of a character entity. 4 Class. Inquiry function. 5 Arguments. 6 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 7 not be deferred. KIND (optional) shall be a scalar integer initialization expression. 8 Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that 9 specified by the value of KIND; otherwise the kind type parameter is that of default integer 10 type. 11 Result Value. The result has a value equal to the number of characters in STRING if it is 12 scalar or in an element of STRING if it is an array. 13 Example. If C is declared by the statement 14 CHARACTER (11) C (100) 15 LEN (C) has the value 11. 16 13.7.100 LEN TRIM (STRING [, KIND]) 17 Description. Returns the length of the character argument without counting trailing blank 18 characters. 19 Class. Elemental function. 20 Arguments. 21 STRING shall be of type character. 22 KIND (optional) shall be a scalar integer initialization expression. 23 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 24 by the value of KIND; otherwise the kind type parameter is that of default integer type. 25 Result Value. The result has a value equal to the number of characters remaining after any 26 trailing blanks in STRING are removed. If the argument contains no nonblank characters, the 27 result is zero. 28 Examples. LEN TRIM (' A B ') has the value 4 and LEN TRIM (' ') has the value 0. 29 13.7.101 LGE (STRING A, STRING B) 30 Description. Test whether a string is lexically greater than or equal to another string, based 31 on the ASCII collating sequence. 32 Class. Elemental function. 33 396 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 STRING A shall be of type default character of type ASCII character. 2 STRING B shall be of type character with the same kind type parameter as STRING A. 3 Result Characteristics. Default logical. 4 Result Value. If the strings are of unequal length, the comparison is made as if the shorter 5 string were extended on the right with blanks to the length of the longer string. If either string 6 contains a character not in the ASCII character set, the result is processor dependent. The 7 result is true if the strings are equal or if STRING A follows STRING B in the ASCII collating 8 sequence; otherwise, the result is false. 9 NOTE 13.14 The result is true if both STRING A and STRING B are of zero length. Example. LGE ('ONE', 'TWO') has the value false. 10 13.7.102 LGT (STRING A, STRING B) 11 Description. Test whether a string is lexically greater than another string, based on the ASCII 12 collating sequence. 13 Class. Elemental function. 14 Arguments. 15 STRING A shall be of type default character of type ASCII character. 16 STRING B shall be of type character with the same kind type parameter as STRING A. 17 Result Characteristics. Default logical. 18 Result Value. If the strings are of unequal length, the comparison is made as if the shorter 19 string were extended on the right with blanks to the length of the longer string. If either string 20 contains a character not in the ASCII character set, the result is processor dependent. The 21 result is true if STRING A follows STRING B in the ASCII collating sequence; otherwise, the 22 result is false. 23 NOTE 13.15 The result is false if both STRING A and STRING B are of zero length. Example. LGT ('ONE', 'TWO') has the value false. 24 13.7.103 LLE (STRING A, STRING B) 25 Description. Test whether a string is lexically less than or equal to another string, based on 26 the ASCII collating sequence. 27 Class. Elemental function. 28 Arguments. 29 STRING A shall be of type default character of type ASCII character. 30 STRING B shall be of type character with the same kind type parameter as STRING A. 31 397 J3/06-007 WORKING DRAFT 2006/07/11 Result Characteristics. Default logical. 1 Result Value. If the strings are of unequal length, the comparison is made as if the shorter 2 string were extended on the right with blanks to the length of the longer string. If either 3 string contains a character not in the ASCII character set, the result is processor dependent. 4 The result is true if the strings are equal or if STRING A precedes STRING B in the ASCII 5 collating sequence; otherwise, the result is false. 6 NOTE 13.16 The result is true if both STRING A and STRING B are of zero length. Example. LLE ('ONE', 'TWO') has the value true. 7 13.7.104 LLT (STRING A, STRING B) 8 Description. Test whether a string is lexically less than another string, based on the ASCII 9 collating sequence. 10 Class. Elemental function. 11 Arguments. 12 STRING A shall be of type default character of type ASCII character. 13 STRING B shall be of type character with the same kind type parameter as STRING A. 14 Result Characteristics. Default logical. 15 Result Value. If the strings are of unequal length, the comparison is made as if the shorter 16 string were extended on the right with blanks to the length of the longer string. If either string 17 contains a character not in the ASCII character set, the result is processor dependent. The 18 result is true if STRING A precedes STRING B in the ASCII collating sequence; otherwise, the 19 result is false. 20 NOTE 13.17 The result is false if both STRING A and STRING B are of zero length. Example. LLT ('ONE', 'TWO') has the value true. 21 13.7.105 LOG (X) 22 Description. Natural logarithm. 23 Class. Elemental function. 24 Argument. X shall be of type real or complex. If X is real, its value shall be greater than zero. 25 If X is complex, its value shall not be zero. 26 Result Characteristics. Same as X. 27 Result Value. The result has a value equal to a processor-dependent approximation to loge X. 28 A result of type complex is the principal value with imaginary part in the range - . 29 If the real part of X is less than zero and the imaginary part of X is zero, then the imaginary 30 part of the result is if the imaginary part of X is positive real zero or the processor cannot 31 distinguish between positive and negative real zero, and - if the imaginary part of X is negative 32 real zero. 33 398 2006/07/11 WORKING DRAFT J3/06-007 Example. LOG (10.0) has the value 2.3025851 (approximately). 1 13.7.106 LOG GAMMA (X) 2 Description. Logarithm of the absolute value of the gamma function. 3 Class. Elemental function. 4 Argument. X shall be of type real. Its value shall not be a negative integer or zero. 5 Result Characteristics. Same as X. 6 Result Value. The result has a value equal to a processor-dependent approximation to the 7 natural logarithm of the absolute value of the gamma function of X. 8 Example. LOG GAMMA (3.0) has the value 0.693 (approximately). 9 13.7.107 LOG10 (X) 10 Description. Common logarithm. 11 Class. Elemental function. 12 Argument. X shall be of type real. The value of X shall be greater than zero. 13 Result Characteristics. Same as X. 14 Result Value. The result has a value equal to a processor-dependent approximation to log10 X. 15 Example. LOG10 (10.0) has the value 1.0 (approximately). 16 13.7.108 LOGICAL (L [, KIND]) 17 Description. Converts between kinds of logical or from bits to logical. 18 Class. Elemental function. 19 Arguments. 20 L shall be of type logical or bits. 21 KIND (optional) shall be a scalar integer initialization expression. 22 Result Characteristics. Logical. If KIND is present, the kind type parameter is that specified 23 by the value of KIND; otherwise, the kind type parameter is that of default logical. 24 Result Value. 25 Case (i): If L is of type logical, the value is that of L. 26 Case (ii): If L is of type bits and KIND (L) is greater than or equal to BITS KIND (result ), 27 the result has the value whose physical representation is the same as the rightmost 28 bits of L. 29 Case (iii): If L is of type bits and KIND (L) is less than BITS KIND (result ), the rightmost 30 KIND(L) bits of the physical representation of the result value are the same as 31 those of L, and the remaining bits of the physical representation of the result 32 value are zero. 33 399 J3/06-007 WORKING DRAFT 2006/07/11 J3 internal note Unresolved Technical Issue 66 This might not be a value. Seriously. We don't provide semantics for physical representations that don't represent a logical value. There are certainly systems that use the fastest test, which might be all-zero for a "FALSE" test and lowest-bit-set for a "TRUE" test... which is not going to give sensible results if you whack any old set of bits into the LOGICAL. Should we not say something about that here? Or rather, say less (don't say this returns a value...) see below. At least with TRANSFER we give what the use can rely on, viz that converting LOGICAL to something else and back again gives you what you start with. Note that also with TRANSFER we carefully don't say that the result is a "value" of the result type, we only say what it's physical representation is. That is, I think, what is needed here. Actually, it's also probably what is needed for INT (bits) and REAL (bits) too. We get this right for CHAR already, but by a different means. Examples. LOGICAL (L .OR. .NOT. L) has the value true and is of type default logical, 1 regardless of the kind type parameter of the logical variable L. LOGICAL (BITS (.TRUE.)) has 2 the value true. 3 13.7.109 MASKL (I, [, KIND]) 4 Description. Generate a left justified mask. 5 Class. Elemental function. 6 Arguments. 7 I shall be of type integer. It shall be nonnegative and less than or equal to the 8 kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. 9 Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified 10 by the value of KIND; otherwise, the kind type parameter is that of default bits type. 11 Result Value. The result value has its leftmost I bits set to 1 and the remaining bits set to 0. 12 Example. MASKL (12) has the value Z'FFF00000' if the default bits kind type parameter 13 value is 32. 14 13.7.110 MASKR (I, [, KIND]) 15 Description. Generate a right justified mask. 16 Class. Elemental function. 17 Arguments. 18 I shall be of type integer. It shall be nonnegative and less than or equal to the 19 kind type parameter of the result. KIND (optional) shall be a scalar integer initialization expression. 20 Result Characteristics. Bits. If KIND is present, the kind type parameter is that specified 21 by the value of KIND; otherwise, the kind type parameter is that of default bits type. 22 Result Value. The result value has its rightmost I bits set to 1 and the remaining bits set to 23 400 2006/07/11 WORKING DRAFT J3/06-007 0. 1 Example. MASKR (12) has the value Z'00000FFF' if the default bits kind type parameter 2 value is 32. 3 13.7.111 MATMUL (MATRIX A, MATRIX B) 4 Description. Performs matrix multiplication of numeric or logical matrices. 5 Class. Transformational function. 6 Arguments. 7 MATRIX A shall be of numeric type (integer, real, or complex) or of logical type. It shall 8 be an 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 MATRIX 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 9 of MATRIX A. Result Characteristics. If the arguments are of numeric type, the type and kind type pa- 10 rameter of the result are determined by the types of the arguments as specified in 7.1.4.2 for 11 the * operator. If the arguments are of type logical, the result is of type logical with the kind 12 type parameter of the arguments as specified in 7.1.4.2 for the .AND. operator. The shape of 13 the result depends on the shapes of the arguments as follows: 14 Case (i): If MATRIX A has shape (n, m) and MATRIX B has shape (m, k ), the result has 15 shape (n, k ). 16 Case (ii): If MATRIX A has shape (m) and MATRIX B has shape (m, k ), the result has 17 shape (k ). 18 Case (iii): If MATRIX A has shape (n, m) and MATRIX B has shape (m), the result has 19 shape (n). 20 Result Value. 21 Case (i): Element (i, j ) of the result has the value SUM (MATRIX A (i, :) * MATRIX B (:, 22 j )) if the arguments are of numeric type and has the value ANY (MATRIX A (i, 23 :) .AND. MATRIX B (:, j )) if the arguments are of logical type. 24 Case (ii): Element (j ) of the result has the value SUM (MATRIX A (:) * MATRIX B (:, 25 j )) if the arguments are of numeric type and has the value ANY (MATRIX A (:) 26 .AND. MATRIX B (:, j )) if the arguments are of logical type. 27 Case (iii): Element (i) of the result has the value SUM (MATRIX A (i, :) * MATRIX B (:)) 28 if the arguments are of numeric type and has the value ANY (MATRIX A (i, :) 29 .AND. MATRIX B (:)) if the arguments are of logical type. 30 1 2 1 a 2 3 2 3 ; let X and Y be the Examples. Let A and B be the matrices nd 2 3 4 31 3 4 vectors [1, 2] and [1, 2, 3]. 32 Case (i): The result of MATMUL (A, B) is the matrix-matrix product AB with the value 33 1 . 4 20 34 20 29 401 J3/06-007 WORKING DRAFT 2006/07/11 Case (ii): The result of MATMUL (X, A) is the vector-matrix product XA with the value 1 [5, 8, 11]. 2 Case (iii): The result of MATMUL (A, Y) is the matrix-vector product AY with the value 3 [14, 20]. 4 13.7.112 MAX (A1, A2 [, A3, ...]) 5 Description. Maximum value. 6 Class. Elemental function. 7 Arguments. The arguments shall all have the same type which shall be integer, real, bits, or 8 character and they shall all have the same kind type parameter. 9 Result Characteristics. The type and kind type parameter of the result are the same as those 10 of the arguments. For arguments of character type, the length of the result is the length of the 11 longest argument. 12 Result Value. The value of the result is that of the largest argument. For arguments of 13 character type, the result is the value that would be selected by application of intrinsic relational 14 operators; that is, the collating sequence for characters with the kind type parameter of the 15 arguments is applied. If the selected argument is shorter than the longest argument, the result 16 is extended with blanks on the right to the length of the longest argument. 17 Examples. MAX (­9.0, 7.0, 2.0) has the value 7.0, MAX ('Z', 'BB') has the value 'Z ', and 18 MAX ((/'A', 'Z'/), (/'BB', 'Y '/)) has the value (/'BB', 'Z '/).MAX (B'10000', B'01111') has 19 the value B'10000'. 20 13.7.113 MAXEXPONENT (X) 21 Description. Returns the maximum exponent of the model representing numbers of the same 22 type and kind type parameter as the argument. 23 Class. Inquiry function. 24 Argument. X shall be of type real. It may be a scalar or an array. 25 Result Characteristics. Default integer scalar. 26 Result Value. The result has the value emax , as defined in 13.4 for the model representing 27 numbers of the same type and kind type parameter as X. 28 Example. MAXEXPONENT (X) has the value 127 for real X whose model is as in Note 13.5. 29 13.7.114 MAXLOC (ARRAY, DIM [, MASK, KIND, BACK]) or MAXLOC (ARRAY [, MASK, KIND, BACK]) 30 Description. Determine the location of the first element of ARRAY along dimension DIM 31 having the maximum value of the elements identified by MASK. 32 Class. Transformational function. 33 Arguments. 34 ARRAY shall be of type integer, real, bits, or character. It shall be an array. 35 402 2006/07/11 WORKING DRAFT J3/06-007 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 1 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 2 KIND (optional) shall be a scalar integer initialization expression. 3 BACK (optional) shall be scalar and of type logical. 4 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 5 by the value of KIND; otherwise the kind type parameter is that of default integer type. If DIM 6 is absent, the result is an array of rank one and of size equal to the rank of ARRAY; otherwise, 7 the result is of rank n - 1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ), where (d1 , d2 , . . . , 8 dn ) is the shape of ARRAY. 9 Result Value. 10 Case (i): The result of MAXLOC (ARRAY) is a rank-one array whose element values are 11 the values of the subscripts of an element of ARRAY whose value equals the 12 maximum value of all of the elements of ARRAY. The ith subscript returned lies 13 in the range 1 to ei , where ei is the extent of the ith dimension of ARRAY. If 14 ARRAY has size zero, all elements of the result are zero. 15 Case (ii): The result of MAXLOC (ARRAY, MASK = MASK) is a rank-one array whose 16 element values are the values of the subscripts of an element of ARRAY, corre- 17 sponding to a true element of MASK, whose value equals the maximum value of 18 all such elements of ARRAY. The ith subscript returned lies in the range 1 to ei , 19 where ei is the extent of the ith dimension of ARRAY. If ARRAY has size zero 20 or every element of MASK has the value false, all elements of the result are zero. 21 Case (iii): If ARRAY has rank one, MAXLOC (ARRAY, DIM = DIM [, MASK = MASK]) 22 is a scalar whose value is equal to that of the first element of MAXLOC (ARRAY [, 23 MASK = MASK]). Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , 24 . . . , sn ) of the result is equal to 25 MAXLOC (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ), DIM=1 26 [, MASK = MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 27 If only one element has the maximum value, that element's subscripts are returned. Otherwise, 28 if more than one element has the maximum value and BACK is absent or present with the value 29 false, the element whose subscripts are returned is the first such element, taken in array element 30 order. If BACK is present with the value true, the element whose subscripts are returned is the 31 last such element, taken in array element order. 32 If ARRAY has type character, the result is the value that would be selected by application of 33 intrinsic relational operators; that is, the collating sequence for characters with the kind type 34 parameter of the arguments is applied. 35 Examples. 36 Case (i): The value of MAXLOC ((/ 2, 6, 4, 6 /)) is [2] and the value of MAXLOC ([2, 6, 4, 6], 37 BACK=.TRUE.) is [4]. 38 0 -5 8 -3 If A has the value 3 4 -1 2 , MAXLOC (A, MASK = A < 6) has Case (ii): 6 -4 39 15 the value [3, 2]. Note that this is independent of the declared lower bounds for 40 A. 41 Case (iii): The value of MAXLOC ((/ 5, -9, 3 /), DIM = 1) is 1. If B has the value 42 403 J3/06-007 WORKING DRAFT 2006/07/11 1 , 3 -9 MAXLOC (B, DIM = 1) is [2, 1, 2] and MAXLOC (B, DIM = 2) 1 22 6 is [2, 3]. Note that this is independent of the declared lower bounds for B. 2 13.7.115 MAXVAL (ARRAY, DIM [, MASK]) or MAXVAL (ARRAY [, MASK]) 3 Description. Maximum value of the elements of ARRAY along dimension DIM corresponding 4 to the true elements of MASK. 5 Class. Transformational function. 6 Arguments. 7 ARRAY shall be of type integer, real, bits, or character. It shall be an array. 8 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 9 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 10 Result Characteristics. The result is of the same type and type parameters as ARRAY. It is 11 scalar if DIM is absent; otherwise, the result has rank n-1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , 12 . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. 13 Result Value. 14 Case (i): The result of MAXVAL (ARRAY) has a value equal to the maximum value of 15 all the elements of ARRAY if the size of ARRAY is not zero. If ARRAY has size 16 zero and type integer or real, the result has the value of the negative number of 17 the largest magnitude supported by the processor for numbers of the type and 18 kind type parameter of ARRAY. If ARRAY has size zero and type character, the 19 result has the value of a string of characters of length LEN (ARRAY), with each 20 character equal to CHAR (0, KIND = KIND (ARRAY)). 21 Case (ii): The result of MAXVAL (ARRAY, MASK = MASK) has a value equal to that of 22 MAXVAL (PACK (ARRAY, MASK)). 23 Case (iii): The result of MAXVAL (ARRAY, DIM = DIM [,MASK = MASK]) has a value 24 equal to that of MAXVAL (ARRAY [,MASK = MASK]) if ARRAY has rank 25 one. Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of the 26 result is equal to 27 MAXVAL (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) 28 [, MASK = MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 29 If ARRAY has type character, the result is the value that would be selected by application of 30 intrinsic relational operators; that is, the collating sequence for characters with the kind type 31 parameter of the arguments is applied. 32 Examples. 33 Case (i): The value of MAXVAL ((/ 1, 2, 3 /)) is 3. 34 Case (ii): MAXVAL (C, MASK = C < 0.0) finds the maximum of the negative elements of 35 C. 36 1 , 35 Case (iii): If B is the array MAXVAL (B, DIM = 1) is [2, 4, 6] and MAX- 37 2 46 VAL (B, DIM = 2) is [5, 6]. 38 404 2006/07/11 WORKING DRAFT J3/06-007 13.7.116 MERGE (TSOURCE, FSOURCE, MASK) 1 Description. Choose alternative value according to the value of a mask. 2 Class. Elemental function. 3 Arguments. 4 TSOURCE may be of any type. 5 FSOURCE shall be of the same type and type parameters as TSOURCE. 6 MASK shall be of type logical. 7 Result Characteristics. Same as TSOURCE. 8 Result Value. The result is TSOURCE if MASK is true and FSOURCE otherwise. 9 1 , 0 a 65 32 Examples. If TSOURCE is the array FSOURCE is the array nd 10 246 748 , T .T where "T" represents true and "." represents false, then MASK is the array 11 ..T . 1 35 The value of MERGE (1.0, 0.0, MERGE (TSOURCE, FSOURCE, MASK) is 12 746 K > 0) is 1.0 for K = 5 and 0.0 for K = ­2. 13 13.7.117 MERGE BITS (I, J, MASK) 14 Description. Merge bits under mask. 15 Class. Elemental function. 16 Arguments. 17 I shall be of type bits or integer. 18 J shall have the same type and type parameters as I. 19 J3 internal note Unresolved Technical Issue 67 If MERGE BITS only handles "int,int" and "bits,bits" ... and not "int,bits" and "bits,int" ... why do IAND IOR IEOR have to handle the mixed-type cases? This is inconsistent. Probably best fixed by removal of the mixed-type cases of IAND et al. MASK shall be of type bits. Its kind type parameter shall be equal to BITS KIND (I). 20 J3 internal note Unresolved Technical Issue 68 So why does this have such different requirements to J? It's not like it's being used in such a conceptually different way. That is, why do we have "int,int,bits" and "bits,bits,bits" but not "int,int,int"? This brings into question the whole idea of whether MERGE BITS should take integer at all. Result Characteristics. Same as I. 21 Result Value. The result has the value of IOR (IAND (I, MASK), IAND (J, NOT (MASK))). 22 405 J3/06-007 WORKING DRAFT 2006/07/11 Example. MERGE BITS(Z'01234567', Z'89ABCDEF', Z'FFFF0000') has the value Z'0123CDEF'. 1 13.7.118 MIN (A1, A2 [, A3, ...]) 2 Description. Minimum value. 3 Class. Elemental function. 4 Arguments. The arguments shall all be of the same type which shall be integer, real, bits, or 5 character and they shall all have the same kind type parameter. 6 Result Characteristics. The type and kind type parameter of the result are the same as those 7 of the arguments. For arguments of character type, the length of the result is the length of the 8 longest argument. 9 Result Value. The value of the result is that of the smallest argument. For arguments 10 of character type, the result is the value that would be selected by application of intrinsic 11 relational operators; that is, the collating sequence for characters with the kind type parameter 12 of the arguments is applied. If the selected argument is shorter than the longest argument, the 13 result is extended with blanks on the right to the length of the longest argument. 14 Examples. MIN (­9.0, 7.0, 2.0) has the value ­9.0, MIN ('A', 'YY') has the value 'A ', and 15 MIN ((/'Z', 'A'/), (/'YY', 'B '/)) has the value (/'YY', 'A '/). MIN (B'10000', B'01111') has 16 the value B'01111'. 17 13.7.119 MINEXPONENT (X) 18 Description. Returns the minimum (most negative) exponent of the model representing num- 19 bers of the same type and kind type parameter as the argument. 20 Class. Inquiry function. 21 Argument. X shall be of type real. It may be a scalar or an array. 22 Result Characteristics. Default integer scalar. 23 Result Value. The result has the value emin , as defined in 13.4 for the model representing 24 numbers of the same type and kind type parameter as X. 25 Example. MINEXPONENT (X) has the value ­126 for real X whose model is as in Note 13.5. 26 13.7.120 MINLOC (ARRAY, DIM [, MASK, KIND, BACK]) or MINLOC (ARRAY [, MASK, KIND, BACK]) 27 Description. Determine the location of the first element of ARRAY along dimension DIM 28 having the minimum value of the elements identified by MASK. 29 Class. Transformational function. 30 Arguments. 31 ARRAY shall be of type integer, real, bits, or character. It shall be an array. 32 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 33 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 34 406 2006/07/11 WORKING DRAFT J3/06-007 KIND (optional) shall be a scalar integer initialization expression. 1 BACK (optional) shall be scalar and of type logical. 2 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 3 by the value of KIND; otherwise the kind type parameter is that of default integer type. If DIM 4 is absent, the result is an array of rank one and of size equal to the rank of ARRAY; otherwise, 5 the result is of rank n - 1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , . . . , dn ), where (d1 , d2 , 6 . . . , dn ) is the shape of ARRAY. 7 Result Value. 8 Case (i): The result of MINLOC (ARRAY) is a rank-one array whose element values are 9 the values of the subscripts of an element of ARRAY whose value equals the 10 minimum value of all the elements of ARRAY. The ith subscript returned lies 11 in the range 1 to ei , where ei is the extent of the ith dimension of ARRAY. If 12 ARRAY has size zero, all elements of the result are zero. 13 Case (ii): The result of MINLOC (ARRAY, MASK = MASK) is a rank-one array whose 14 element values are the values of the subscripts of an element of ARRAY, corre- 15 sponding to a true element of MASK, whose value equals the minimum value of 16 all such elements of ARRAY. The ith subscript returned lies in the range 1 to ei , 17 where ei is the extent of the ith dimension of ARRAY. If ARRAY has size zero 18 or every element of MASK has the value false, all elements of the result are zero. 19 Case (iii): If ARRAY has rank one, MINLOC (ARRAY, DIM = DIM [, MASK = MASK]) is 20 a scalar whose value is equal to that of the first element of MINLOC (ARRAY [, 21 MASK = MASK]). Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , 22 . . . , sn ) of the result is equal to 23 MINLOC (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ), DIM=1 24 [, MASK = MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 25 If only one element has the minimum value, that elements subscripts are returned. Otherwise, 26 if more than one element has the minimum value and BACK is absent or present with the value 27 false, the element whose subscripts are returned is the first such element, taken in array element 28 order. If BACK is present with the value true, the element whose subscripts are returned is the 29 last such element, taken in array element order. 30 If ARRAY has type character, the result is the value that would be selected by application of 31 intrinsic relational operators; that is, the collating sequence for characters with the kind type 32 parameter of the arguments is applied. 33 Examples. 34 Case (i): The value of MINLOC ((/ 4, 3, 6, 3 /)) is [2] and the value of MINLOC ([4, 3, 6, 3], 35 BACK = .TRUE.) is [4]. 36 0 -5 8 -3 If A has the value 3 4 -1 2 , MINLOC (A, MASK = A > ­4) has Case (ii): 6 -4 37 15 the value [1, 4]. Note that this is independent of the declared lower bounds for 38 A. 39 Case (iii): The value of MINLOC ((/ 5, -9, 3 /), DIM = 1) is 2. If B has the value 40 1 , 3 -9 MINLOC (B, DIM = 1) is [1, 2, 1] and MINLOC (B, DIM = 2) 41 22 6 is [3, 1]. Note that this is independent of the declared lower bounds for B. 42 13.7.121 MINVAL (ARRAY, DIM [, MASK]) or MINVAL (ARRAY [, MASK]) 43 407 J3/06-007 WORKING DRAFT 2006/07/11 Description. Minimum value of all the elements of ARRAY along dimension DIM correspond- 1 ing to true elements of MASK. 2 Class. Transformational function. 3 Arguments. 4 ARRAY shall be of type integer, real, bits, or character. It shall be an array. 5 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 6 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 7 Result Characteristics. The result is of the same type and type parameters as ARRAY. It is 8 scalar if DIM is absent; otherwise, the result has rank n-1 and shape (d1 , d2 , . . . , dDIM-1 , dDIM+1 , 9 . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. 10 Result Value. 11 Case (i): The result of MINVAL (ARRAY) has a value equal to the minimum value of all 12 the elements of ARRAY if the size of ARRAY is not zero. If ARRAY has size 13 zero and type integer or real, the result has the value of the positive number of 14 the largest magnitude supported by the processor for numbers of the type and 15 kind type parameter of ARRAY. If ARRAY has size zero and type character, 16 the result has the value of a string of characters of length LEN (ARRAY), with 17 each character equal to CHAR (n - 1, KIND = KIND (ARRAY)), where n is the 18 number of characters in the collating sequence for characters with the kind type 19 parameter of ARRAY. 20 Case (ii): The result of MINVAL (ARRAY, MASK = MASK) has a value equal to that of 21 MINVAL (PACK (ARRAY, MASK)). 22 Case (iii): The result of MINVAL (ARRAY, DIM = DIM [, MASK = MASK]) has a value 23 equal to that of MINVAL (ARRAY [, MASK = MASK]) if ARRAY has rank 24 one. Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of the 25 result is equal to 26 MINVAL (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) 27 [, MASK= MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 28 If ARRAY has type character, the result is the value that would be selected by application of 29 intrinsic relational operators; that is, the collating sequence for characters with the kind type 30 parameter of the arguments is applied. 31 Examples. 32 Case (i): The value of MINVAL ((/ 1, 2, 3 /)) is 1. 33 Case (ii): MINVAL (C, MASK = C > 0.0) forms the minimum of the positive elements of 34 C. 35 1 , 35 Case (iii): If B is the array MINVAL (B, DIM = 1) is [1, 3, 5] and MINVAL (B, 36 246 DIM = 2) is [1, 2]. 37 13.7.122 MOD (A, P) 38 Description. Remainder function. 39 Class. Elemental function. 40 408 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 A shall be of type integer or real. 2 P shall be of the same type and kind type parameter as A. P shall not be zero. 3 Result Characteristics. Same as A. 4 Result Value. The value of the result is A­INT (A/P) * P. 5 Examples. MOD (3.0, 2.0) has the value 1.0 (approximately). MOD (8, 5) has the value 3. 6 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 Description. Modulo function. 9 Class. Elemental function. 10 Arguments. 11 A shall be of type integer or real. 12 P shall be of the same type and kind type parameter as A. P shall not be zero. 13 Result Characteristics. Same as A. 14 Result Value. 15 A is of type integer. MODULO (A, P) has the value R such that A = Q × P + R, Case (i): 16 where Q is an integer, the inequalities 0 R < P hold if P > 0, and P < R 0 17 hold if P < 0. 18 Case (ii): A is of type real. The value of the result is A ­ FLOOR (A / P) * P. 19 Examples. MODULO (8, 5) has the value 3. MODULO (-8, 5) has the value 2. MOD- 20 ULO (8, -5) has the value -2. MODULO (-8, -5) has the value -3. 21 13.7.124 MOVE ALLOC (FROM, TO) 22 Description. Moves an allocation from one allocatable ob ject to another. 23 Class. Pure subroutine. 24 Arguments. 25 FROM may be of any type and rank. It shall be allocatable. It is an IN- 26 TENT(INOUT) 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 value as the corresponding parameter of the 27 declared type of FROM. The allocation status of TO becomes unallocated if FROM is unallocated on entry to MOVE - 28 ALLOC. Otherwise, TO becomes allocated with dynamic type, type parameters, array bounds, 29 and value identical to those that FROM had on entry to MOVE ALLOC. 30 If TO has the TARGET attribute, any pointer associated with FROM on entry to MOVE - 31 409 J3/06-007 WORKING DRAFT 2006/07/11 ALLOC becomes correspondingly associated with TO. If TO does not have the TARGET at- 1 tribute, the pointer association status of any pointer associated with FROM on entry becomes 2 undefined. 3 The allocation status of FROM becomes unallocated. 4 Example. 5 REAL,ALLOCATABLE :: GRID(:),TEMPGRID(:) 6 ... 7 ALLOCATE(GRID(-N:N)) ! initial allocation of GRID 8 ... 9 ! "reallocation" of GRID to allow intermediate points 10 ALLOCATE(TEMPGRID(-2*N:2*N)) ! allocate bigger grid 11 TEMPGRID(::2)=GRID ! distribute values to new locations 12 CALL MOVE ALLOC(TO=GRID,FROM=TEMPGRID) 13 ! old grid is deallocated because TO is 14 ! INTENT(OUT), and GRID then "takes over" 15 ! new grid allocation 16 NOTE 13.18 It is expected that the implementation of allocatable ob jects 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) 17 Description. Copies a sequence of bits from one data ob ject to another. 18 Class. Elemental subroutine. 19 Arguments. 20 FROM shall be of type integer or bits. It is an INTENT (IN) argument. 21 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 for the interpretation of an integer value as a sequence of bits is in 22 13.3. LEN shall be of type integer and nonnegative. It is an INTENT (IN) argument. 23 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 integer value as a sequence 24 of bits is in 13.3. TOPOS shall be of type integer and nonnegative. It is an INTENT (IN) argument. 25 TOPOS + LEN shall be less than or equal to BIT SIZE (TO). 410 2006/07/11 WORKING DRAFT J3/06-007 Examples. If TO has the initial value 6, the value of TO after the statement 1 CALL MVBITS (7, 2, 2, TO, 0) is 5. If TO has the initial value B'000000111111', the value of 2 TO after the statement CALL MVBITS (B'000000000011', 0, 2, TO, 8) is B'001100111111'. 3 13.7.126 NEAREST (X, S) 4 Description. Returns the nearest different machine-representable number in a given direction. 5 Class. Elemental function. 6 Arguments. 7 X shall be of type real. 8 S shall be of type real and not equal to zero. 9 Result Characteristics. Same as X. 10 Result Value. The result has a value equal to the machine-representable number distinct from 11 X and nearest to it in the direction of the infinity with the same sign as S. 12 Example. NEAREST (3.0, 2.0) has the value 3 + 2-22 on a machine whose representation is 13 that of the model in Note 13.5. 14 NOTE 13.19 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) 15 Description. Returns a newline character. 16 Class. Inquiry function. 17 Argument. A shall be of type character. It may be a scalar or an array. 18 Result Characteristics. Character scalar of length one with the same kind type parameter 19 as A. 20 Result Value. 21 Case (i): If A is of the default character type and the character in position 10 of the ASCII 22 collating sequence is representable in the default character set, then the result is 23 ACHAR(10). 24 Case (ii): If A is of the ASCII character type or the ISO 10646 character type, then the 25 result is CHAR(10,KIND(A)). 26 Case (iii): Otherwise, the result is a processor-dependent character that represents a new- 27 line in output to files connected for formatted stream output if there is such a 28 character. 29 Case (iv): Otherwise, the result is the blank character. 30 13.7.128 NINT (A [, KIND]) 31 Description. Nearest integer. 32 411 J3/06-007 WORKING DRAFT 2006/07/11 Class. Elemental function. 1 Arguments. 2 A shall be of type real. 3 KIND (optional) shall be a scalar integer initialization expression. 4 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 5 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 6 Result Value. The result is the integer nearest A, or if there are two integers equally near A, 7 the result is whichever such integer has the greater magnitude. 8 Example. NINT (2.783) has the value 3. 9 13.7.129 NOT (I) 10 Description. Performs a bitwise complement. 11 Class. Elemental function. 12 Argument. I shall be of type integer or bits. 13 Result Characteristics. Same as I. 14 Result Value. The result has the value obtained by complementing I bit-by-bit according to 15 the following truth table: 16 I NOT (I) 1 0 0 1 The model for the interpretation of an integer value as a sequence of bits is in 13.3. 17 Examples. If I is represented by the string of bits 01010101, NOT (I) has the binary value 18 10101010. NOT (Z'FFFF0000') has the value Z'0000FFFF'. 19 13.7.130 NORM2 (X) 20 Description. L2 norm of an array. 21 Class. Transformational function. 22 Argument. X shall be of type real. It shall be an array. 23 Result Characteristics. Scalar of the same type and kind type parameter value as X. 24 Result Value. The result has a value equal to a processor-dependent approximation to the 25 generalized L2 norm of X, which is the square root of the sum of the squares of the elements of 26 X. 27 Example. The value of NORM2 ((/ 3.0, 4.0 /)) is 5.0 (approximately). 28 NOTE 13.20 It is recommended that the processor compute NORM2 in such a way that intermediate results do not overflow or underflow unless the final result would overflow or underflow, respectively. 412 2006/07/11 WORKING DRAFT J3/06-007 13.7.131 NULL ([MOLD]) 1 Description. Returns a disassociated pointer or designates an unallocated allocatable compo- 2 nent of a structure constructor. 3 Class. Transformational function. 4 Argument. MOLD shall be a pointer or allocatable. It may be of any type or may be a 5 procedure pointer. If MOLD is a pointer its pointer association status may be undefined, 6 disassociated, or associated. If MOLD is allocatable its allocation status may be allocated or 7 unallocated. It need not be defined with a value. 8 Result Characteristics. If MOLD is present, the characteristics are the same as MOLD. If 9 MOLD has deferred type parameters, those type parameters of the result are deferred. 10 If MOLD is absent, the characteristics of the result are determined by the entity with which the 11 reference is associated. See Table 13.1. MOLD shall not be absent in any other context. If any 12 type parameters of the contextual entity are deferred, those type parameters of the result are 13 deferred. If any type parameters of the contextual entity are assumed, MOLD shall be present. 14 If the context of the reference to NULL is an actual argument to a generic procedure, MOLD 15 shall be present if the type, type parameters, or rank is required to resolve the generic reference. 16 MOLD shall also be present if the reference appears as an actual argument corresponding to a 17 dummy argument with assumed character length. 18 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 ob ject in a declaration the ob ject 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 ob ject Result. The result is a disassociated pointer or an unallocated allocatable entity. 19 Examples. 20 Case (i): REAL, POINTER, DIMENSION(:) :: VEC => NULL ( ) defines the initial 21 association status of VEC to be disassociated. 22 Case (ii): The MOLD argument is required in the following: 23 INTERFACE GEN 24 SUBROUTINE S1 (J, PI) 25 INTEGER J 26 INTEGER, POINTER :: PI 27 END SUBROUTINE S1 28 SUBROUTINE S2 (K, PR) 29 INTEGER K 30 REAL, POINTER :: PR 31 END SUBROUTINE S2 32 END INTERFACE 33 413 J3/06-007 WORKING DRAFT 2006/07/11 REAL, POINTER :: REAL_PTR 1 CALL GEN (7, NULL (REAL_PTR) ) ! Invokes S2 2 13.7.132 NUM IMAGES () 3 Description. Returns the number of images. 4 Class. Inquiry function. 5 Argument. None. 6 Result Characteristics. Default integer scalar. 7 Result Value. The number of images. 8 Example. The following code uses image 1 to read data and broadcast it to other images. 9 REAL :: P[*] 10 ... 11 IF (THIS_IMAGE()==1) THEN 12 READ (6,*) P 13 DO I = 2, NUM_IMAGES() 14 P[I] = P 15 END DO 16 END IF 17 SYNC_ALL 18 NOTE 13.21 The following two functions might be useful in connection with NUM IMAGES. PURE INTEGER FUNCTION LOG2_IMAGES() ! Returns the base-2 logarithm of the number of images, ! truncated to an integer. LOG2_IMAGES = LOG(NUM_IMAGES()+0.5)/LOG(2.0) END FUNCTION LOG2_IMAGES PURE INTEGER FUNCTION REM_IMAGES() ! Returns MOD(NUM_IMAGES(),2**LOG2_IMAGES()). REM_IMAGES = MOD(NUM_IMAGES(),2**LOG2_IMAGES()) END FUNCTION REM_IMAGES J3 internal note Unresolved Technical Issue 69 These two extra examples are extra examples, but that don't show anything terribly useful. In particular, the "comment" in the second example is atrocious and unacceptable. Perhaps these two functions should be moved into Annex C together with a paragraph or so of witter explaining just how one might use such functions and what for (and, maybe even some code *showing* how they might profitably be used). In which case, leaving a note here saying that the user might find these functions useful with a forward ref would certainly be in order. 414 2006/07/11 WORKING DRAFT J3/06-007 13.7.133 PACK (ARRAY, MASK [, VECTOR]) 1 Description. Pack an array into an array of rank one under the control of a mask. 2 Class. Transformational function. 3 Arguments. 4 ARRAY may be of any type. It shall be an array. 5 MASK shall be of type logical and shall be conformable with ARRAY. 6 VECTOR shall be of the same type and type parameters as ARRAY and shall have (optional) rank one. 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 7 have at least as many elements as there are in ARRAY. Result Characteristics. The result is an array of rank one with the same type and type 8 parameters as ARRAY. If VECTOR is present, the result size is that of VECTOR; otherwise, 9 the result size is the number t of true elements in MASK unless MASK is scalar with the value 10 true, in which case the result size is the size of ARRAY. 11 Result Value. Element i of the result is the element of ARRAY that corresponds to the ith 12 true element of MASK, taking elements in array element order, for i = 1, 2, . . . , t. If VECTOR 13 is present and has size n > t, element i of the result has the value VECTOR (i), for i = t + 1, 14 . . . , n. 15 000 Examples. The nonzero elements of an array M with the value 9 0 0 may be "gathered" 16 007 by the function PACK. The result of PACK (M, MASK = M /= 0) is [9, 7] and the result of 17 PACK (M, M /= 0, VECTOR = (/ 2, 4, 6, 8, 10, 12 /)) is [9, 7, 6, 8, 10, 12]. 18 13.7.134 PARITY (MASK [, DIM]) 19 Description. Determine whether an odd number of values are true in MASK along dimension 20 DIM. 21 Class. Transformational function. 22 Arguments. 23 MASK shall be of type logical. It shall be an array. 24 shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of MASK. The corresponding actual argument shall not 25 be an optional dummy argument. Result Characteristics. The result is of type logical with the same kind type parameter as 26 MASK. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 27 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of MASK. 28 Result Value. 29 Case (i): The result of ALL (MASK) has the value true if an odd number of the elements 30 of MASK are true, and false otherwise. 31 Case (ii): If MASK has rank one, PARITY (MASK, DIM) is equal to PARITY (MASK). 32 415 J3/06-007 WORKING DRAFT 2006/07/11 Otherwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of PAR- 1 ITY (MASK, DIM) is equal to PARITY (MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , 2 . . . , sn )). 3 Examples. 4 Case (i): The value of PARITY ([T, T, T, F]) is true if T has the value true and F has the 5 value false. 6 T , TF Case (ii): If B is the array where T has the value true and F has the value 7 TTT false, then PARITY (B, DIM=1) has the value [F, F, T] and PARITY (B, DIM=2) 8 has the value [F, T]. 9 13.7.135 POPCNT (I [, KIND]) 10 Description. Return the number of one bits. 11 Class. Elemental function. 12 Arguments. 13 I shall be of type integer or bits. 14 KIND (optional) shall be a scalar integer initialization expression. 15 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 16 by the value of KIND; otherwise, the kind type parameter is that of the default integer type. 17 Result Value. If I is of type integer, the result value is equal to the number of one bits in the 18 sequence of bits of I. The model for the interpretation of an integer value as a sequence of bits 19 is in 13.3. If I is of type bits, the result value is the number of one bits in I. 20 Examples. POPCNT ([1, 2, 3, 4, 5, 6]) has the value [1, 1, 2, 1, 2, 2]. POPCNT (Z'FFFF0000') 21 has the value 16. If B is of type bits, POPCNT (HUGE (B)) has the same value as KIND (B). 22 13.7.136 POPPAR (I [, KIND]) 23 Description. Return the bitwise parity. 24 Class. Elemental function. 25 Arguments. 26 I shall be of type integer or bits. 27 KIND (optional) shall be a scalar integer initialization expression. 28 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 29 by the value of KIND; otherwise, the kind type parameter is that of the default integer type. 30 Result Value. POPPAR (I) has the value 1 if POPCNT (I) is odd, and 0 if POPCNT (I) is 31 even. 32 Examples. POPPAR ([1, 2, 3, 4, 5, 6]) has the value [1, 1, 0, 1, 0, 0]. POPPAR (Z'FFFF0000') 33 has the value 0. 34 13.7.137 PRECISION (X) 35 416 2006/07/11 WORKING DRAFT J3/06-007 Description. Returns the decimal precision of the model representing real numbers with the 1 same kind type parameter as the argument. 2 Class. Inquiry function. 3 Argument. X shall be of type real or complex. It may be a scalar or an array. 4 Result Characteristics. Default integer scalar. 5 Result Value. The result has the value INT ((p - 1) * LOG10 (b)) + k , where b and p are as 6 defined in 13.4 for the model representing real numbers with the same value for the kind type 7 parameter as X, and where k is 1 if b is an integral power of 10 and 0 otherwise. 8 Example. PRECISION (X) has the value INT (23 * LOG10 (2.)) = INT (6.92. . . ) = 6 for real 9 X whose model is as in Note 13.5. 10 13.7.138 PRESENT (A) 11 Description. Determine whether an optional argument is present. 12 Class. Inquiry function. 13 Argument. A shall be the name of an optional dummy argument that is accessible in the 14 subprogram in which the PRESENT function reference appears. It may be of any type and it 15 may be a pointer. It may be a scalar or an array. It may be a dummy procedure. The dummy 16 argument A has no INTENT attribute. 17 Result Characteristics. Default logical scalar. 18 Result Value. The result has the value true if A is present (12.5.1.9) and otherwise has the 19 value false. 20 13.7.139 PRODUCT (ARRAY, DIM [, MASK]) or PRODUCT (ARRAY [, MASK]) 21 Description. Product of all the elements of ARRAY along dimension DIM corresponding to 22 the true elements of MASK. 23 Class. Transformational function. 24 Arguments. 25 ARRAY shall be of type integer, real, or complex. It shall be an array. 26 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 27 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 28 Result Characteristics. The result is of the same type and kind type parameter as AR- 29 RAY. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 30 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. 31 Result Value. 32 Case (i): The result of PRODUCT (ARRAY) has a value equal to a processor-dependent 33 approximation to the product of all the elements of ARRAY or has the value one 34 if ARRAY has size zero. 35 Case (ii): The result of PRODUCT (ARRAY, MASK = MASK) has a value equal to a 36 417 J3/06-007 WORKING DRAFT 2006/07/11 processor-dependent approximation to the product of the elements of ARRAY 1 corresponding to the true elements of MASK or has the value one if there are no 2 true elements. 3 Case (iii): If ARRAY has rank one, PRODUCT (ARRAY, DIM = DIM [, MASK = MASK]) 4 has a value equal to that of PRODUCT (ARRAY [, MASK = MASK ]). Oth- 5 erwise, the value of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) of PROD- 6 UCT (ARRAY, DIM = DIM [ ,MASK = MASK]) is equal to 7 PRODUCT (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) [, MASK = 8 MASK (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 9 Examples. 10 Case (i): The value of PRODUCT ((/ 1, 2, 3 /)) is 6. 11 Case (ii): PRODUCT (C, MASK = C > 0.0) forms the product of the positive elements of 12 C. 13 1 , 35 Case (iii): If B is the array PRODUCT (B, DIM = 1) is [2, 12, 30] and 14 246 PRODUCT (B, DIM = 2) is [15, 48]. 15 13.7.140 RADIX (X) 16 Description. Returns the base of the model representing numbers of the same type and kind 17 type parameter as the argument. 18 Class. Inquiry function. 19 Argument. X shall be of type integer or real. It may be a scalar or an array. 20 Result Characteristics. Default integer scalar. 21 Result Value. The result has the value r if X is of type integer and the value b if X is of type 22 real, where r and b are as defined in 13.4 for the model representing numbers of the same type 23 and kind type parameter as X. 24 Example. RADIX (X) has the value 2 for real X whose model is as in Note 13.5. 25 13.7.141 RANDOM NUMBER (HARVEST) 26 Description. Returns one pseudorandom number or an array of pseudorandom numbers from 27 the uniform distribution over the range 0 x < 1. 28 J3 internal note Unresolved Technical Issue 70 The description does not make sense for bits. No problem with "pseudorandom number" for bits (since that's exactly what is being generated ­ lots of 0s and 1s, which last time I looked were numbers). However, there is definitely a problem with requiring each bit to be less than 1! Class. Subroutine. 29 Argument. HARVEST shall be of type real or bits. It is an INTENT (OUT) argument. 30 It may be a scalar or an array variable. If it is real, it is assigned pseudorandom numbers 31 from the uniform distribution in the interval 0 x < 1.If it is of type bits, it is assigned 32 pseudorandom values with each of the KIND (HARVEST) bits of each value having a probability 33 of approximately 0.5 of being 1. 34 418 2006/07/11 WORKING DRAFT J3/06-007 Examples. 1 REAL X, Y (10, 10) 2 BITS B 3 ! Initialize X with a pseudorandom number 4 CALL RANDOM_NUMBER (HARVEST = X) 5 CALL RANDOM_NUMBER (Y) 6 ! X and Y contain uniformly distributed random numbers 7 CALL RANDOM_NUMBER(B) 8 ! B contains a uniformly random collection of 0 and 1 bits. 9 13.7.142 RANDOM SEED ([SIZE, PUT, GET]) 10 Description. Restarts or queries the pseudorandom number generator used by RANDOM - 11 NUMBER. 12 Class. Subroutine. 13 Arguments. There shall either be exactly one or no arguments present. 14 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 15 value of the seed. shall be a default integer array of rank one and size N . It is an IN- PUT (optional) TENT (IN) argument. It is used in a processor-dependent manner to compute 16 the seed value accessed by the pseudorandom number generator. shall be a default integer array of rank one and size N It is an IN- GET (optional) 17 TENT (OUT) argument. It is assigned the current value of the seed. If no argument is present, the processor assigns a processor-dependent value to the seed. 18 The pseudorandom number generator used by RANDOM NUMBER maintains a seed that is 19 updated during the execution of RANDOM NUMBER and that may be specified or returned by 20 RANDOM SEED. Computation of the seed from the argument PUT is performed in a processor- 21 dependent manner. The value returned by GET need not be the same as the value specified 22 by PUT in an immediately preceding reference to RANDOM SEED. For example, following 23 execution of the statements 24 CALL RANDOM_SEED (PUT=SEED1) 25 CALL RANDOM_SEED (GET=SEED2) 26 SEED2 need not equal SEED1. When the values differ, the use of either value as the PUT 27 argument in a subsequent call to RANDOM SEED shall result in the same sequence of pseudo- 28 random numbers being generated. For example, after execution of the statements 29 CALL RANDOM_SEED (PUT=SEED1) 30 CALL RANDOM_SEED (GET=SEED2) 31 CALL RANDOM_NUMBER (X1) 32 CALL RANDOM_SEED (PUT=SEED2) 33 CALL RANDOM_NUMBER (X2) 34 419 J3/06-007 WORKING DRAFT 2006/07/11 X2 equals X1. 1 Examples. 2 CALL RANDOM_SEED ! Processor initialization 3 CALL RANDOM_SEED (SIZE = K) ! Puts size of seed in K 4 CALL RANDOM_SEED (PUT = SEED (1 : K)) ! Define seed 5 CALL RANDOM_SEED (GET = OLD (1 : K)) ! Read current seed 6 13.7.143 RANGE (X) 7 Description. Returns the decimal exponent range of the model representing integer or real 8 numbers with the same kind type parameter as the argument. 9 Class. Inquiry function. 10 Argument. X shall be of type integer, real, or complex. It may be a scalar or an array. 11 Result Characteristics. Default integer scalar. 12 Result Value. 13 Case (i): For an integer argument, the result has the value INT (LOG10 (HUGE(X))). 14 Case (ii): For a real argument, the result has the value INT (MIN (LOG10 (HUGE(X)), 15 ­LOG10 (TINY(X)))). 16 Case (iii): For a complex argument, the result has the value RANGE(REAL(X)). 17 Examples. RANGE (X) has the value 38 for real X whose model is as in Note 13.5, because 18 in this case HUGE(X) = (1 - 2-24 ) × 2127 and TINY(X) = 2-127 . 19 13.7.144 REAL (A [, KIND]) 20 Description. Convert to real type. 21 Class. Elemental function. 22 Arguments. 23 A shall be of type integer, real, complex, or bits. 24 KIND (optional) shall be a scalar integer initialization expression. 25 Result Characteristics. Real. 26 Case (i): If A is of type integer, real, or bits, and KIND is present, the kind type parameter 27 is that specified by the value of KIND. If A is of type integer, real, or bits, and 28 KIND is not present, the kind type parameter is that of default real type. 29 Case (ii): If A is of type complex and KIND is present, the kind type parameter is that 30 specified by the value of KIND. If A is of type complex and KIND is not present, 31 the kind type parameter is the kind type parameter of A. 32 Result Value. 33 Case (i): If A is of type integer or real, the result is equal to a processor-dependent ap- 34 proximation to A. 35 420 2006/07/11 WORKING DRAFT J3/06-007 Case (ii): If A is of type complex, the result is equal to a processor-dependent approximation 1 to the real part of A. 2 Case (iii): If A is of type bits and KIND (A) is greater than or equal to BITS KIND (result ), 3 the result has the value whose physical representation is the same as the rightmost 4 bits of A. 5 Case (iv): If A is of type bits and KIND (A) is less than BITS KIND (result ), the rightmost 6 KIND (A) bits of the physical representation of the result value are the same as 7 those of A, and the remaining bits of the physical represention of the result value 8 are zero. 9 Examples. REAL (­3) has the value ­3.0. REAL (Z) has the same kind type parameter and 10 the same value as the real part of the complex variable Z. REAL (Z'7F800000') has the value 11 positive infinity if the default real kind is IEEE single precision. 12 13.7.145 REPEAT (STRING, NCOPIES) 13 Description. Concatenate several copies of a string. 14 Class. Transformational function. 15 Arguments. 16 STRING shall be scalar and of type character. 17 NCOPIES shall be scalar and of type integer. Its value shall not be negative. 18 Result Characteristics. Character scalar of length NCOPIES times that of STRING, with 19 the same kind type parameter as STRING. 20 Result Value. The value of the result is the concatenation of NCOPIES copies of STRING. 21 Examples. REPEAT ('H', 2) has the value HH. REPEAT ('XYZ', 0) has the value of a zero- 22 length string. 23 13.7.146 RESHAPE (SOURCE, SHAPE [, PAD, ORDER]) 24 Description. Constructs an array of a specified shape from the elements of a given array. 25 Class. Transformational function. 26 Arguments. 27 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). 28 The size of the 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 29 and less 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 30 array. ORDER shall be of type integer, shall have the same shape as SHAPE, and its value (optional) shall be a permutation of (1, 2, . . . , n), where n is the size of SHAPE. If 31 absent, it is as if it were present with value (1, 2, . . . , n). Result Characteristics. The result is an array of shape SHAPE (that is, SHAPE (RE- 32 SHAPE (SOURCE, SHAPE, PAD, ORDER)) is equal to SHAPE) with the same type and type 33 421 J3/06-007 WORKING DRAFT 2006/07/11 parameters as SOURCE. 1 Result Value. The elements of the result, taken in permuted subscript order ORDER (1), 2 . . . , ORDER (n), are those of SOURCE in normal array element order followed if necessary by 3 those of PAD in array element order, followed if necessary by additional copies of PAD in array 4 element order. 5 1 . 35 Examples. RESHAPE ((/ 1, 2, 3, 4, 5, 6 /), (/ 2, 3 /)) has the value RE- 6 246 1 . 234 SHAPE ((/ 1, 2, 3, 4, 5, 6 /), (/ 2, 4 /), (/ 0, 0 /), (/ 2, 1 /)) has the value 7 5600 13.7.147 RRSPACING (X) 8 Description. Returns the reciprocal of the relative spacing of model numbers near the argument 9 value. 10 Class. Elemental function. 11 Argument. X shall be of type real. 12 Result Characteristics. Same as X. 13 Result Value. The result has the value |X × b-e | × bp , where b, e, and p are as defined in 13.4 14 for the model representation of X. If X is an IEEE infinity, the result is zero. If X is an IEEE 15 NaN, the result is that NaN. 16 Example. RRSPACING (­3.0) has the value 0.75 × 224 for reals whose model is as in Note 17 13.5. 18 13.7.148 SAME TYPE AS (A, B) 19 Description. Inquires whether the dynamic type of A is the same as the dynamic type of B. 20 Class. Inquiry function. 21 Arguments. 22 A shall be an ob ject of extensible type. If it is a pointer, it shall not have an 23 undefined association status. B shall be an ob ject of extensible type. If it is a pointer, it shall not have an 24 undefined association status. Result Characteristics. Default logical scalar. 25 Result Value. The result is true if and only if the dynamic type of A is the same as the 26 dynamic type of B. 27 NOTE 13.22 The dynamic type of a disassociated pointer or unallocated allocatable is its declared type. 13.7.149 SCALE (X, I) 28 Description. Returns X × bI where b is the base of the model representation of X. 29 Class. Elemental function. 30 422 2006/07/11 WORKING DRAFT J3/06-007 Arguments. 1 X shall be of type real. 2 I shall be of type integer. 3 Result Characteristics. Same as X. 4 Result Value. The result has the value X × bI , where b is defined in 13.4 for model numbers 5 representing values of X, provided this result is within range; if not, the result is processor 6 dependent. 7 Example. SCALE (3.0, 2) has the value 12.0 for reals whose model is as in Note 13.5. 8 13.7.150 SCAN (STRING, SET [, BACK, KIND]) 9 Description. Scan a string for any one of the characters in a set of characters. 10 Class. Elemental function. 11 Arguments. 12 STRING shall be of type character. 13 SET shall be of type character with the same kind type parameter as STRING. 14 BACK (optional) shall be of type logical. 15 KIND (optional) shall be a scalar integer initialization expression. 16 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 17 by the value of KIND; otherwise the kind type parameter is that of default integer type. 18 Result Value. 19 Case (i): If BACK is absent or is present with the value false and if STRING contains at 20 least one character that is in SET, the value of the result is the position of the 21 leftmost character of STRING that is in SET. 22 Case (ii): If BACK is present with the value true and if STRING contains at least one 23 character that is in SET, the value of the result is the position of the rightmost 24 character of STRING that is in SET. 25 Case (iii): The value of the result is zero if no character of STRING is in SET or if the 26 length of STRING or SET is zero. 27 Examples. 28 Case (i): SCAN ('FORTRAN', 'TR') has the value 3. 29 Case (ii): SCAN ('FORTRAN', 'TR', BACK = .TRUE.) has the value 5. 30 Case (iii): SCAN ('FORTRAN', 'BCD') has the value 0. 31 13.7.151 SELECTED BITS KIND (N) 32 Description. Returns a value of the kind type parameter of a bits type with N bits. 33 Class. Transformational function. 34 Argument. N shall be scalar and of type integer. 35 423 J3/06-007 WORKING DRAFT 2006/07/11 Result Characteristics. Default integer scalar. 1 Result Value. The result value is N if the processor supports a bits type with a kind type 2 parameter equal to N; otherwise the result value is -1. 3 Example. If the value of NUMERIC STORAGE SIZE is 32, SELECT BITS KIND (43) has 4 the value 43. 5 13.7.152 SELECTED CHAR KIND (NAME) 6 Description. Returns the value of the kind type parameter of the character set named by the 7 argument. 8 Class. Transformational function. 9 Argument. NAME shall be scalar and of type default character. 10 Result Characteristics. Default integer scalar. 11 Result Value. If NAME has the value DEFAULT, then the result has a value equal to that of 12 the kind type parameter of the default character type. If NAME has the value ASCII, then the 13 result has a value equal to that of the kind type parameter of the ASCII character type if the 14 processor supports such a type; otherwise the result has the value -1. If NAME has the value 15 ISO 10646, then the result has a value equal to that of the kind type parameter of the ISO/IEC 16 10646-1:2000 UCS-4 character type if the processor supports such a type; otherwise the result 17 has the value -1. If NAME is a processor-defined name of some other character type supported 18 by the processor, then the result has a value equal to that of the kind type parameter of that 19 character type. If NAME is not the name of a supported character type, then the result has the 20 value -1. The NAME is interpreted without respect to case or trailing blanks. 21 Examples. SELECTED CHAR KIND ('ASCII') has the value 1 on a processor that uses 1 22 as the kind type parameter for the ASCII character set. The following subroutine produces a 23 Japanese date stamp. 24 SUBROUTINE create_date_string(string) 25 INTRINSIC date_and_time,selected_char_kind 26 INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646") 27 CHARACTER(1,UCS4),PARAMETER :: nen=CHAR(INT(Z'5e74'),UCS4), & !year 28 gatsu=CHAR(INT(Z'6708'),UCS4), & !month 29 nichi=CHAR(INT(Z'65e5'),UCS4) !day 30 CHARACTER(len= *, kind= ucs4) string 31 INTEGER values(8) 32 CALL date_and_time(values=values) 33 WRITE(string,1) values(1),nen,values(2),gatsu,values(3),nichi 34 1 FORMAT(I0,A,I0,A,I0,A) 35 END SUBROUTINE" 36 13.7.153 SELECTED INT KIND (R) 37 Description. Returns a value of the kind type parameter of an integer type that represents all 38 integer values n with -10R < n < 10R . 39 Class. Transformational function. 40 424 2006/07/11 WORKING DRAFT J3/06-007 Argument. R shall be scalar and of type integer. 1 Result Characteristics. Default integer scalar. 2 Result Value. The result has a value equal to the value of the kind type parameter of an 3 integer type that represents all values n in the range -10R < n < 10R , or if no such kind type 4 parameter is available on the processor, the result is ­1. If more than one kind type parameter 5 meets the criterion, the value returned is the one with the smallest decimal exponent range, 6 unless there are several such values, in which case the smallest of these kind values is returned. 7 Example. Assume a processor supports two integer kinds, 32 with representation method 8 r = 2 and q = 31, and 64 with representation method r = 2 and q = 63. On this processor 9 SELECTED INT KIND(9) has the value 32 and SELECTED INT KIND(10) has the value 64. 10 13.7.154 SELECTED REAL KIND ([P, R, RADIX]) 11 Description. Returns a value of the kind type parameter of a real type with decimal precision 12 of at least P digits, a decimal exponent range of at least R, and a radix of RADIX. 13 Class. Transformational function. 14 Arguments. At least one argument shall be present. 15 P (optional) shall be scalar and of type integer. 16 R (optional) shall be scalar and of type integer. 17 RADIX (optional) shall be scalar and of type integer. 18 Result Characteristics. Default integer scalar. 19 Result Value. If P or R is absent, the result value is the same as if it were present with the 20 value zero. If RADIX is absent, there is no requirement on the radix of the selected kind. 21 The result has a value equal to a value of the kind type parameter of a real type with decimal precision, 22 as returned by the function PRECISION, of at least P digits, a decimal exponent range, as returned by 23 the function RANGE, of at least R, and a radix, as returned by the function RADIX, of RADIX, if such 24 a kind type parameter is available on the processor. 25 Otherwise, the result is -1 if the processor supports a real type with radix RADIX and exponent range 26 of at least R but not with precision of at least P, -2 if the processor supports a real type with radix 27 RADIX and precision of at least P but not with exponent range of at least R, -3 if the processor 28 supports a real type with radix RADIX but with neither precision of at least P nor exponent range of 29 at least R, -4 if the processor supports a real type with radix RADIX and either precision of at least 30 P or exponent range of at least R but not both together, and -5 if the processor supports no real type 31 with radix RADIX. 32 If more than one kind type parameter value meets the criteria, the value returned is the one with the 33 smallest decimal precision, unless there are several such values, in which case the smallest of these kind 34 values is returned. 35 Example. SELECTED REAL KIND (6, 70) has the value KIND (0.0) on a machine that 36 supports a default real approximation method with b = 16, p = 6, emin = -64, and emax = 63 37 and does not have a less precise approximation method. 38 13.7.155 SET EXPONENT (X, I) 39 Description. Returns the model number whose fractional part is the fractional part of the 40 425 J3/06-007 WORKING DRAFT 2006/07/11 model representation of X and whose exponent part is I. 1 Class. Elemental function. 2 Arguments. 3 X shall be of type real. 4 I shall be of type integer. 5 Result Characteristics. Same as X. 6 Result Value. The result has the value X × bI-e , where b and e are as defined in 13.4 for the 7 model representation of X. If X has value zero, the result has value zero. 8 Example. SET EXPONENT (3.0, 1) has the value 1.5 for reals whose model is as in Note 9 13.5. 10 13.7.156 SHAPE (SOURCE [, KIND]) 11 Description. Returns the shape of an array or a scalar. 12 Class. Inquiry function. 13 Arguments. 14 SOURCE may be of any type. It may be a scalar or an array. It shall not be an unallocated allocatable or a pointer that is not associated. It shall not be an 15 assumed-size array. KIND (optional) shall be a scalar integer initialization expression. 16 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 17 by the value of KIND; otherwise the kind type parameter is that of default integer type. The 18 result is an array of rank one whose size is equal to the rank of SOURCE. 19 Result Value. The value of the result is the shape of SOURCE. 20 Examples. The value of SHAPE (A (2:5, ­1:1) ) is [4, 3]. The value of SHAPE (3) is the 21 rank-one array of size zero. 22 13.7.157 SHIFTA (I, SHIFT) 23 Description. Performs an arithmetic right shift. 24 Class. Elemental function. 25 Arguments. 26 I shall be of type integer or bits. 27 SHIFT shall be of type integer. It shall be nonnegative and less than or equal to 28 BIT SIZE (I). Result Characteristics. Same as I. 29 Result Value. The result has the value obtained by shifting the bits of I to the right SHIFT 30 bits and replicating the leftmost bit of I in the left SHIFT bits. 31 426 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 71 This does not just assume integers are binary, but that they are twos complement binary. Other machines have existed and I believe even still exist. If this is meant to be an arithmetic shift surely it should give the right answer on all machines? After all, if we are only going to support binary twos complement, we can define negative integer bit patterns (and we have not done that, nor should we). NOTE: I am complaining about the Description, not about the functionality. Or maybe I'm complaining that the functionality doesn't match my signed-magnitude machines version. Who knows. If SHIFT is zero the result is I. Bits shifted out from the right are lost. The model for the interpretation 1 of an integer value as a sequence of bits is in 13.3. 2 J3 internal note Unresolved Technical Issue 72 That model does not interpret values with the top bit set, i.e. is completely irrelevant to this function. 13.3 says that if it has the top bit set, the interpretation is "processor dependent"; this is not useful for this function. Maybe there is no fix possible here... Example. SHIFTA (B'10000', 2) has the value B'11100'. 3 13.7.158 SHIFTL (I, SHIFT) 4 Description. Performs a left shift. 5 Class. Elemental function. 6 Arguments. 7 I shall be of type integer or bits. 8 SHIFT shall be of type integer. It shall be nonnegative and less than or equal to 9 BIT SIZE (I). Result Characteristics. Same as I. 10 Result Value. The result has a value equal to ISHFT (I, SHIFT). 11 Examples. SHIFTL (3, 1) has the value 6. SHIFTL (B'00001', 2) has the value B'00100'. 12 13.7.159 SHIFTR (I, SHIFT) 13 Description. Performs a right shift. 14 Class. Elemental function. 15 Arguments. 16 I shall be of type integer or bits. 17 SHIFT shall be of type integer. It shall be nonnegative and less than or equal to 18 BIT SIZE (I). Result Characteristics. Same as I. 19 Result Value. The value of the result is ISHFT (I, -SHIFT). 20 427 J3/06-007 WORKING DRAFT 2006/07/11 Examples. SHIFTR (3, 1) has the value 1. SHIFTR (B'10000', 2) has the value B'00100'. 1 13.7.160 SIGN (A, B) 2 Description. Magnitude of A with the sign of B. 3 Class. Elemental function. 4 Arguments. 5 A shall be of type integer or real. 6 B shall be of the same type and kind type parameter as A. 7 Result Characteristics. Same as A. 8 Result Value. 9 If B > 0, the value of the result is |A|. Case (i): 10 If B < 0, the value of the result is -|A|. Case (ii): 11 If B is of type integer and B=0, the value of the result is |A|. Case (iii): 12 Case (iv): If B is of type real and is zero, then 13 (1) If the processor cannot distinguish between positive and negative real zero, 14 the value of the result is |A|. 15 If B is positive real zero, the value of the result is |A|. (2) 16 If B is negative real zero, the value of the result is -|A|. (3) 17 Example. SIGN (­3.0, 2.0) has the value 3.0. 18 13.7.161 SIN (X) 19 Description. Sine function. 20 Class. Elemental function. 21 Argument. X shall be of type real or complex. 22 Result Characteristics. Same as X. 23 Result Value. The result has a value equal to a processor-dependent approximation to sin(X). 24 If X is of type real, it is regarded as a value in radians. If X is of type complex, its real part is 25 regarded as a value in radians. 26 Example. SIN (1.0) has the value 0.84147098 (approximately). 27 13.7.162 SINH (X) 28 Description. Hyperbolic sine function. 29 Class. Elemental function. 30 Argument. X shall be of type real or complex. 31 Result Characteristics. Same as X. 32 Result Value. The result has a value equal to a processor-dependent approximation to sinh(X). 33 If X is of type complex its imaginary part is regarded as a value in radians. 34 428 2006/07/11 WORKING DRAFT J3/06-007 Example. SINH (1.0) has the value 1.1752012 (approximately). 1 13.7.163 SIZE (ARRAY [, DIM, KIND]) 2 Description. Returns the extent of an array along a specified dimension or the total number 3 of elements in the array. 4 Class. Inquiry function. 5 Arguments. 6 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 7 array, DIM shall be present with a value less than the rank of ARRAY. shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) 8 where n is the rank of ARRAY. KIND (optional) shall be a scalar integer initialization expression. 9 Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that 10 specified by the value of KIND; otherwise the kind type parameter is that of default integer 11 type. 12 Result Value. The result has a value equal to the extent of dimension DIM of ARRAY or, if 13 DIM is absent, the total number of elements of ARRAY. 14 Examples. The value of SIZE (A (2:5, ­1:1), DIM=2) is 3. The value of SIZE (A (2:5, ­1:1)) 15 is 12. 16 13.7.164 SPACING (X) 17 Description. Returns the absolute spacing of model numbers near the argument value. 18 Class. Elemental function. 19 Argument. X shall be of type real. 20 Result Characteristics. Same as X. 21 Result Value. If X does not have the value zero, the result has the value bmax(e-p,eMIN -1) , 22 where b, e, and p are as defined in 13.4 for the model representation of X. If X has the value 23 zero, the result is the same as that of TINY (X). If X is an IEEE infinity, the result is positive 24 infinity. If X is an IEEE NaN, the result is that NaN. 25 Example. SPACING (3.0) has the value 2-22 for reals whose model is as in Note 13.5. 26 13.7.165 SPREAD (SOURCE, DIM, NCOPIES) 27 Description. Replicates an array by adding a dimension. Broadcasts several copies of SOURCE 28 along a specified dimension (as in forming a book from copies of a single page) and thus forms 29 an array of rank one greater. 30 Class. Transformational function. 31 Arguments. 32 SOURCE may be of any type. It may be a scalar or an array. The rank of SOURCE 33 shall be less than 15. 429 J3/06-007 WORKING DRAFT 2006/07/11 shall be scalar and of type integer with value in the range 1 DIM n + 1, DIM 1 where n is the rank of SOURCE. NCOPIES shall be scalar and of type integer. 2 Result Characteristics. The result is an array of the same type and type parameters as 3 SOURCE and of rank n + 1, where n is the rank of SOURCE. 4 Case (i): If SOURCE is scalar, the shape of the result is (MAX (NCOPIES, 0)). 5 Case (ii): If SOURCE is an array with shape (d1 , d2 , . . . , dn ), the shape of the result is 6 (d1 , d2 , . . . , dDIM-1 , MAX (NCOPIES, 0), dDIM , . . . , dn ). 7 Result Value. 8 Case (i): If SOURCE is scalar, each element of the result has a value equal to SOURCE. 9 Case (ii): If SOURCE is an array, the element of the result with subscripts (r1 , r2 , . . . , rn+1 ) 10 has the value SOURCE (r1 , r2 , . . . , rDIM-1 , rDIM+1 , . . . , rn+1 ). 11 Examples. If A is the array [2, 3, 4], SPREAD (A, DIM=1, NCOPIES=NC) is the array 12 234 2 3 4 if NC has the value 3 and is a zero-sized array if NC has the value 0. 13 234 13.7.166 SQRT (X) 14 Description. Square root. 15 Class. Elemental function. 16 Argument. X shall be of type real or complex. Unless X is complex, its value shall be greater 17 than or equal to zero. 18 Result Characteristics. Same as X. 19 Result Value. The result has a value equal to a processor-dependent approximation to the 20 square root of X. A result of type complex is the principal value with the real part greater than 21 or equal to zero. When the real part of the result is zero, the imaginary part has the same sign 22 as the imaginary part of X. 23 Example. SQRT (4.0) has the value 2.0 (approximately). 24 13.7.167 SUM (ARRAY, DIM [, MASK]) or SUM (ARRAY [, MASK]) 25 Description. Sum all the elements of ARRAY along dimension DIM corresponding to the true 26 elements of MASK. 27 Class. Transformational function. 28 Arguments. 29 ARRAY shall be of type integer, real, or complex. It shall be an array. 30 shall be scalar and of type integer with a value in the range 1 DIM n, DIM where n is the rank of ARRAY. The corresponding actual argument shall not 31 be an optional dummy argument. MASK (optional) shall be of type logical and shall be conformable with ARRAY. 32 Result Characteristics. The result is of the same type and kind type parameter as AR- 33 430 2006/07/11 WORKING DRAFT J3/06-007 RAY. It is scalar if DIM is absent; otherwise, the result has rank n - 1 and shape (d1 , d2 , 1 . . . , dDIM-1 , dDIM+1 , . . . , dn ) where (d1 , d2 , . . . , dn ) is the shape of ARRAY. 2 Result Value. 3 Case (i): The result of SUM (ARRAY) has a value equal to a processor-dependent approx- 4 imation to the sum of all the elements of ARRAY or has the value zero if ARRAY 5 has size zero. 6 Case (ii): The result of SUM (ARRAY, MASK = MASK) has a value equal to a processor- 7 dependent approximation to the sum of the elements of ARRAY corresponding 8 to the true elements of MASK or has the value zero if there are no true elements. 9 Case (iii): If ARRAY has rank one, SUM (ARRAY, DIM = DIM [, MASK = MASK]) has a 10 value equal to that of SUM (ARRAY [,MASK = MASK ]). Otherwise, the value 11 of element (s1 , s2 , . . . , sDIM-1 , sDIM+1 , . . . , sn ) SUM (ARRAY, DIM = DIM [ 12 , MASK = MASK]) is equal to 13 SUM (ARRAY (s1 , s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) [, MASK= MASK (s1 , 14 s2 , . . . , sDIM-1 , :, sDIM+1 , . . . , sn ) ] ). 15 Examples. 16 Case (i): The value of SUM ((/ 1, 2, 3 /)) is 6. 17 Case (ii): SUM (C, MASK= C > 0.0) forms the sum of the positive elements of C. 18 , 1 35 Case (iii): If B is the array SUM (B, DIM = 1) is [3, 7, 11] and SUM (B, 19 246 DIM = 2) is [9, 12]. 20 13.7.168 SYSTEM CLOCK ([COUNT, COUNT RATE, COUNT MAX]) 21 Description. Returns numeric data from a real-time clock. 22 Class. Subroutine. 23 Arguments. 24 shall be scalar and of type integer. It is an INTENT (OUT) argument. It COUNT (optional) is assigned 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 zero at the next count. It lies in the 25 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. (optional) It is assigned a processor-dependent approximation to the number of processor 26 clock 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 (optional) assigned the maximum value that COUNT can have, or zero if there is no 27 clock. Example. If the processor clock is a 24-hour clock that registers time at approximately 28 18.20648193 ticks per second, at 11:30 A.M. the reference 29 CALL SYSTEM CLOCK (COUNT = C, COUNT RATE = R, COUNT MAX = M) 30 defines C = (11 × 3600 + 30 × 60) × 18.20648193 = 753748, R = 18.20648193, and M = 31 431 J3/06-007 WORKING DRAFT 2006/07/11 24 × 3600 × 18.20648193 - 1 = 1573039. 1 13.7.169 TAN (X) 2 Description. Tangent function. 3 Class. Elemental function. 4 Argument. X shall be of type real or complex. 5 Result Characteristics. Same as X. 6 Result Value. The result has a value equal to a processor-dependent approximation to tan(X). 7 If X is of type real, it is regarded as a value in radians. If X is of type complex, its real part is 8 regarded as a value in radians. 9 Example. TAN (1.0) has the value 1.5574077 (approximately). 10 13.7.170 TANH (X) 11 Description. Hyperbolic tangent function. 12 Class. Elemental function. 13 Argument. X shall be of type real or complex. 14 Result Characteristics. Same as X. 15 Result Value. The result has a value equal to a processor-dependent approximation to tanh(X). 16 If X is of type complex its imaginary part is regarded as a value in radians. 17 Example. TANH (1.0) has the value 0.76159416 (approximately). 18 13.7.171 THIS IMAGE () or THIS IMAGE (CO ARRAY [, DIM]) 19 Description. Returns the index of the invoking image, a single co-subscript, or a list of co- 20 subscripts. 21 Class. Inquiry function. 22 Arguments. 23 CO ARRAY shall be a co-array and may be of any type. 24 (optional) 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 25 absent optional dummy argument. Result Characteristics. Type default integer. It is scalar if CO ARRAY is absent or DIM is 26 present; otherwise, the result has rank one and its size is equal to the co-rank of CO ARRAY. 27 Result Value. 28 Case (i): The result of THIS IMAGE () is a scalar with a value equal to the index of the 29 invoking image. 30 Case (ii): The result of THIS IMAGE (CO ARRAY) is the sequence of co-subscript values 31 for CO ARRAY that would specify the invoking image. 32 432 2006/07/11 WORKING DRAFT J3/06-007 Case (iii): The result of THIS IMAGE (CO ARRAY, DIM) is the value of co-subscript DIM 1 in the sequence of co-subscript values for CO ARRAY that would specify the 2 invoking image. 3 Examples. If A is declared by the statement REAL A (10, 20) [10, 0:9, 0:*] 4 then on image 5, THIS IMAGE () has the value 5 and THIS IMAGE (A) has the value [5, 0, 0]. 5 For the same co-array on image 213, THIS IMAGE (A) has the value [3, 1, 2]. 6 The following code uses image 1 to read data. The other images then copy the data. 7 IF (THIS_IMAGE()==1) READ (*,*) P 8 SYNC_ALL 9 P = P[1] 10 NOTE 13.23 For an example of a module that implements a function similar to the intrinsic IMAGE INDEX, see subclause C.10.1. 13.7.172 TINY (X) 11 Description. Returns the smallest positive number of the model representing numbers of the 12 same type and kind type parameter as the argument. 13 Class. Inquiry function. 14 Argument. X shall be of type real. It may be a scalar or an array. 15 Result Characteristics. Scalar with the same type and kind type parameter as X. 16 Result Value. The result has the value bemin -1 where b and emin are as defined in 13.4 for the 17 model representing numbers of the same type and kind type parameter as X. 18 Example. TINY (X) has the value 2-127 for real X whose model is as in Note 13.5. 19 13.7.173 TRAILZ (I [, KIND]) 20 Description. Count the number of trailing zero bits. 21 Class. Elemental function. 22 Arguments. 23 I shall be of type integer or bits. 24 KIND (optional) shall be a scalar integer initialization expression. 25 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 26 by the value of KIND; otherwise, the kind type parameter is that of default integer type. 27 Result Value. If all of the bits of I are zero, the result value is BIT SIZE (I). Otherwise, the 28 result value is the position of the rightmost 1 bit in I. The model for the interpretation of an 29 integer value as a sequence of bits is in 13.3. 30 433 J3/06-007 WORKING DRAFT 2006/07/11 Examples. TRAILZ (8) has the value 3. TRAILZ (B'101101000') has the value 3. 1 13.7.174 TRANSFER (SOURCE, MOLD [, SIZE]) 2 Description. Returns a result with a physical representation identical to that of SOURCE but 3 interpreted with the type and type parameters of MOLD. 4 Class. Transformational function. 5 Arguments. 6 SOURCE may be of any type. It may be a scalar or an array. 7 MOLD may be of any type. It may be a scalar or an array. If it is a variable, it need 8 not be defined. SIZE (optional) shall be scalar and of type integer. The corresponding actual argument shall 9 not be an optional dummy argument. Result Characteristics. The result is of the same type and type parameters as MOLD. 10 Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar. 11 Case (ii): If MOLD is an array and SIZE is absent, the result is an array and of rank one. 12 Its size is as small as possible such that its physical representation is not shorter 13 than that of SOURCE. 14 Case (iii): If SIZE is present, the result is an array of rank one and size SIZE. 15 Result Value. If the physical representation of the result has the same length as that of 16 SOURCE, the physical representation of the result is that of SOURCE. If the physical rep- 17 resentation of the result is longer than that of SOURCE, the physical representation of the 18 leading part is that of SOURCE and the remainder is processor dependent. If the physical 19 representation of the result is shorter than that of SOURCE, the physical representation of the 20 result is the leading part of SOURCE. If D and E are scalar variables such that the physical 21 representation of D is as long as or longer than that of E, the value of TRANSFER (TRANS- 22 FER (E, D), E) shall be the value of E. IF D is an array and E is an array of rank one, the 23 value of TRANSFER (TRANSFER (E, D), E, SIZE (E)) shall be the value of E. 24 Examples. 25 Case (i): TRANSFER (1082130432, 0.0) has the value 4.0 on a processor that represents 26 the values 4.0 and 1082130432 as the string of binary digits 0100 0000 1000 0000 27 0000 0000 0000 0000. 28 Case (ii): TRANSFER ((/ 1.1, 2.2, 3.3 /), (/ (0.0, 0.0) /)) is a complex rank-one array of 29 length two whose first element has the value (1.1, 2.2) and whose second element 30 has a real part with the value 3.3. The imaginary part of the second element is 31 processor dependent. 32 Case (iii): TRANSFER ((/ 1.1, 2.2, 3.3 /), (/ (0.0, 0.0) /), 1) is a complex rank-one array 33 of length one whose only element has the value (1.1, 2.2). 34 13.7.175 TRANSPOSE (MATRIX) 35 Description. Transpose an array of rank two. 36 Class. Transformational function. 37 Argument. MATRIX may be of any type and shall have rank two. 38 434 2006/07/11 WORKING DRAFT J3/06-007 Result Characteristics. The result is an array of the same type and type parameters as 1 MATRIX and with rank two and shape (n, m) where (m, n) is the shape of MATRIX. 2 Result Value. Element (i, j ) of the result has the value MATRIX (j, i), i = 1, 2, . . . , n; 3 j = 1, 2, . . . , m. 4 123 147 Example. If A is the array 4 5 6 , then TRANSPOSE (A) has the value 2 5 8 . 5 789 369 13.7.176 TRIM (STRING) 6 Description. Returns the argument with trailing blank characters removed. 7 Class. Transformational function. 8 Argument. STRING shall be of type character and shall be scalar. 9 Result Characteristics. Character with the same kind type parameter value as STRING and 10 with a length that is the length of STRING less the number of trailing blanks in STRING. 11 Result Value. The value of the result is the same as STRING except any trailing blanks are 12 removed. If STRING contains no nonblank characters, the result has zero length. 13 Example. TRIM (' A B ') has the value ' A B'. 14 13.7.177 UBOUND (ARRAY [, DIM, KIND]) 15 Description. Returns all the upper bounds of an array or a specified upper bound. 16 Class. Inquiry function. 17 Arguments. 18 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 19 array, DIM shall be present with a value less than the rank of ARRAY. shall be scalar and of type integer with a value in the range 1 DIM n, DIM (optional) where n is the rank of ARRAY. The corresponding actual argument shall not 20 be an optional dummy argument. KIND (optional) shall be a scalar integer initialization expression. 21 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 22 by the value of KIND; otherwise the kind type parameter is that of default integer type. The 23 result is scalar if DIM is present; otherwise, the result is an array of rank one and size n, where 24 n is the rank of ARRAY. 25 Result Value. 26 Case (i): For an array section or for an array expression, other than a whole array or array 27 structure component, UBOUND (ARRAY, DIM) has a value equal to the number 28 of elements in the given dimension; otherwise, it has a value equal to the upper 29 bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have 30 size zero and has the value zero if dimension DIM has size zero. 31 Case (ii): UBOUND (ARRAY) has a value whose ith element is equal to UBOUND (AR- 32 RAY, i), for i = 1, 2, . . . , n, where n is the rank of ARRAY. 33 435 J3/06-007 WORKING DRAFT 2006/07/11 Examples. If A is declared by the statement 1 REAL A (2:3, 7:10) 2 then UBOUND (A) is [3, 10] and UBOUND (A, DIM = 2) is 10. 3 13.7.178 UNPACK (VECTOR, MASK, FIELD) 4 Description. Unpack an array of rank one into an array under the control of a mask. 5 Class. Transformational function. 6 Arguments. 7 VECTOR may be of any type. It shall have rank one. Its size shall be at least t where 8 t is the number of true elements in MASK. MASK shall be an array of type logical. 9 FIELD shall be of the same type and type parameters as VECTOR and shall be 10 conformable with MASK. Result Characteristics. The result is an array of the same type and type parameters as 11 VECTOR and the same shape as MASK. 12 Result Value. The element of the result that corresponds to the ith true element of MASK, 13 in array element order, has the value VECTOR (i) for i = 1, 2, . . . , t, where t is the number of 14 true values in MASK. Each other element has a value equal to FIELD if FIELD is scalar or to 15 the corresponding element of FIELD if it is an array. 16 Examples. Particular values may be "scattred" to particular positions in an array by us- e 17 100 ing UNPACK. If M is the array 0 1 0 , V is the array [1, 2, 3], and Q is the logical 18 001 .T. mask T . . , where "T" represents true and "." represents false, then the result of 19 ..T 120 UNPACK (V, MASK = Q, FIELD = M) has the value 1 1 0 and the result of UN- 20 003 020 PACK (V, MASK = Q, FIELD = 0) has the value 1 0 0 . 21 003 13.7.179 VERIFY (STRING, SET [, BACK, KIND]) 22 Description. Verify that a set of characters contains all the characters in a string by identifying 23 the position of the first character in a string of characters that does not appear in a given set of 24 characters. 25 Class. Elemental function. 26 Arguments. 27 STRING shall be of type character. 28 SET shall be of type character with the same kind type parameter as STRING. 29 BACK (optional) shall be of type logical. 30 436 2006/07/11 WORKING DRAFT J3/06-007 KIND (optional) shall be a scalar integer initialization expression. 1 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified 2 by the value of KIND; otherwise the kind type parameter is that of default integer type. 3 Result Value. 4 Case (i): If BACK is absent or has the value false and if STRING contains at least one 5 character that is not in SET, the value of the result is the position of the leftmost 6 character of STRING that is not in SET. 7 Case (ii): If BACK is present with the value true and if STRING contains at least one 8 character that is not in SET, the value of the result is the position of the rightmost 9 character of STRING that is not in SET. 10 Case (iii): The value of the result is zero if each character in STRING is in SET or if STRING 11 has zero length. 12 Examples. 13 Case (i): VERIFY ('ABBA', 'A') has the value 2. 14 Case (ii): VERIFY ('ABBA', 'A', BACK = .TRUE.) has the value 3. 15 Case (iii): VERIFY ('ABBA', 'AB') has the value 0. 16 13.8 Standard intrinsic modules 17 13.8.1 General 18 This part of ISO/IEC 1539 defines five standard intrinsic modules: a Fortran environment module, a 19 set of three modules to support exception handling and IEEE arithmetic, and a module to support 20 interoperability with the C programming language. 21 A processor may extend the standard intrinsic modules to provide public entities in them in addition to 22 those specified in this standard. 23 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. 13.8.2 The IEEE mo dules 24 The IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES intrinsic modules are describ- 25 ed in Clause 14. 26 13.8.3 The ISO FORTRAN ENV intrinsic mo dule 27 13.8.3.1 General 28 The intrinsic module ISO FORTRAN ENV provides public entities relating to the Fortran environment. 29 The processor shall provide the named constants, derived type, and procedures described in subclause 30 13.8.3. 31 437 J3/06-007 WORKING DRAFT 2006/07/11 13.8.3.2 CHARACTER STORAGE SIZE 1 The value of the default integer scalar constant CHARACTER STORAGE SIZE is the size expressed 2 in bits of the character storage unit (16.5.3.2). 3 13.8.3.3 COMPILER OPTIONS () 4 Description. Returns a processor-dependent string describing the options that controlled the 5 program translation phase. 6 Class. Inquiry function. 7 Argument. None. 8 Result Characteristics. Default character scalar with processor-dependent length. 9 Result Value. A processor-dependent value which describes the options that controlled the 10 translation phase of program execution. 11 Example. COMPILER OPTIONS () might have the value 12 '/OPTIMIZE /FLOAT=IEEE /CHECK:SUBSCRIPTS'. 13 13.8.3.4 COMPILER VERSION () 14 Description. Returns a processor-dependent string identifying the program translation phase. 15 Class. Inquiry function. 16 Argument. None. 17 Result Characteristics. Default character scalar with processor-dependent length. 18 Result Value. A processor-dependent value that identifies the name and version of the program 19 translation phase of the processor. 20 Example. COMPILER VERSION () might have the value 21 'Super-fast KL-10 Compiler Version 0.1'. 22 NOTE 13.25 For both COMPILER OPTIONS and COMPILER VERSIONS the processor should include rel- evant 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 ob ject file automatically, without the user needing to save the result of this function in a variable. 13.8.3.5 IMAGE TEAM 23 A scalar ob ject of type IMAGE TEAM identifies a team of images. It shall have only private components. 24 438 2006/07/11 WORKING DRAFT J3/06-007 J3 internal note Unresolved Technical Issue 73 Email from ``the subgroup'' follows: > *** Teams are always built locally from an image list using the > FORM_TEAM intrinsic. You would not want to use in this image a team > variable value from a different image. The values may differ among the > images of a team. These variables might contain detailed information > on such things as which images are its neighbors in the hardware, or > the location of the image in a reduction tree. > > As you noted, the normative text supporting Note 13.19 is missing. This > was removed recently, but we feel it should be put back. The "special" > derived types IMAGE_TEAM, C_PTR, and C_FUNPTR are very likely to contain > information that is specific to the image where it was defined. Use of > these data on a different image could lead to various errors. The > changes required are: > > 1) Restore Note 13.19. > > 2) Modify the edit for [50:25+] to add another constraint: > > "C440d (R440) A component of derived type image_team (13.8.2.x), c_ptr, > or c_funptr (15.2.2) shall not be a co-array." > > 3) In the edit at [73:1+] replace the text for C517b with: > > "C517b (R501) A co-array shall not be of derived type image_team > (13.8.2.x) or c_ptr (15.2.2) and shall not have the POINTER attribute." > > 4) In the edit at [105:9+] replace the text for C613b with: > > "C613b (R613) A that is a co-indexed object shall not be of a > type that has a pointer ultimate component or has a subcomponent of > derived type image_team (13.8.2.x), c_ptr, or c_funptr (15.2.2)." The editor doesn't think that this is quite right on technical grounds, let alone editorial, so it needs further development. 13.8.3.6 ERROR UNIT 1 The value of the default integer scalar constant ERROR UNIT identifies the processor-dependent pre- 2 connected external unit used for the purpose of error reporting (9.4). This unit may be the same as 3 OUTPUT UNIT. The value shall not be -1. 4 439 J3/06-007 WORKING DRAFT 2006/07/11 13.8.3.7 FILE STORAGE SIZE 1 The value of the default integer scalar constant FILE STORAGE SIZE is the size expressed in bits of 2 the file storage unit (9.2.4). 3 13.8.3.8 INPUT UNIT 4 The value of the default integer scalar constant INPUT UNIT identifies the same processor-dependent 5 preconnected external unit as the one identified by an asterisk in a READ statement (9.4). The value 6 shall not be -1. 7 13.8.3.9 INT8, INT16, INT32, and INT64 8 The values of these default integer scalar named constants shall be those of the kind type parameters that 9 specify an INTEGER type whose storage size expressed in bits is 8, 16, 32, and 64 respectively. If, for 10 any of these constants, the processor supports more than one kind of that size, it is processor-dependent 11 which kind value is provided. If the processor supports no kind of a particular size, that constant shall 12 be equal to -2 if the processor supports kinds of a larger size and -1 otherwise. 13 13.8.3.10 IOSTAT END 14 The value of the default integer scalar constant IOSTAT END is assigned to the variable specified in 15 an IOSTAT= specifier (9.10.4) if an end-of-file condition occurs during execution of an input/output 16 statement and no error condition occurs. This value shall be negative. 17 13.8.3.11 IOSTAT EOR 18 The value of the default integer scalar constant IOSTAT EOR is assigned to the variable specified in 19 an IOSTAT= specifier (9.10.4) if an end-of-record condition occurs during execution of an input/output 20 statement and no end-of-file or error condition occurs. This value shall be negative and different from 21 the value of IOSTAT END. 22 13.8.3.12 IOSTAT INQUIRE INTERNAL UNIT 23 The value of the default integer scalar constant IOSTAT INQUIRE INTERNAL UNIT is assigned to 24 the variable specified in an IOSTAT= specifier in an INQUIRE statement (9.9) if a file-unit-number 25 identifies an internal unit in that statement. 26 NOTE 13.26 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. 13.8.3.13 NUMERIC STORAGE SIZE 27 The value of the default integer scalar constant NUMERIC STORAGE SIZE is the size expressed in 28 bits of the numeric storage unit (16.5.3.2). 29 13.8.3.14 OUTPUT UNIT 30 The value of the default integer scalar constant OUTPUT UNIT identifies the same processor-dependent 31 preconnected external unit as the one identified by an asterisk in a WRITE statement (9.4). The value 32 shall not be -1. 33 440 2006/07/11 WORKING DRAFT J3/06-007 13.8.3.15 REAL32, REAL64, and REAL128 1 The values of these default integer scalar named constants shall be those of the kind type parameters 2 that specify a REAL type whose storage size expressed in bits is 32, 64, and 128 respectively. If, for 3 any of these constants, the processor supports more than one kind of that size, it is processor-dependent 4 which kind value is provided. If the processor supports no kind of a particular size, that constant shall 5 be equal to -2 if the processor supports kinds of a larger size and -1 otherwise. 6 13.8.4 The ISO C BINDING mo dule 7 The ISO C BINDING intrinsic module is described in Clause 15. 8 441 J3/06-007 WORKING DRAFT 2006/07/11 442 2006/07/11 WORKING DRAFT J3/06-007 14 Exceptions and IEEE arithmetic 1 The intrinsic modules IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES provide sup- 2 port for exceptions and IEEE arithmetic. Whether the modules are provided is processor dependent. 3 If the module IEEE FEATURES is provided, which of the named constants defined in this standard 4 are included is processor dependent. The module IEEE ARITHMETIC behaves as if it contained a 5 USE statement for IEEE EXCEPTIONS; everything that is public in IEEE EXCEPTIONS is public in 6 IEEE ARITHMETIC. 7 NOTE 14.1 The types and procedures defined in these modules are not themselves intrinsic. If IEEE EXCEPTIONS or IEEE ARITHMETIC is accessible in a scoping unit, IEEE OVERFLOW 8 and IEEE DIVIDE BY ZERO are supported in the scoping unit for all kinds of real and complex 9 data. Which other exceptions are supported can be determined by the function IEEE SUPPORT - 10 FLAG (14.10.26); whether control of halting is supported can be determined by the function IEEE SUP- 11 PORT HALTING. The extent of support of the other exceptions may be influenced by the accessibility 12 of the named constants IEEE INEXACT FLAG, IEEE INVALID FLAG, and IEEE UNDERFLOW - 13 FLAG of the module IEEE FEATURES. If a scoping unit has access to IEEE UNDERFLOW FLAG 14 of IEEE FEATURES, within the scoping unit the processor shall support underflow and return true 15 from IEEE SUPPORT FLAG( IEEE UNDERFLOW, X) for at least one kind of real. Similarly, if 16 IEEE INEXACT FLAG or IEEE INVALID FLAG is accessible, within the scoping unit the processor 17 shall support the exception and return true from the corresponding inquiry for at least one kind of real. 18 Also, if IEEE HALTING is accessible, within the scoping unit the processor shall support control of 19 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. 443 J3/06-007 WORKING DRAFT 2006/07/11 If a scoping unit does not access IEEE FEATURES, IEEE EXCEPTIONS, or IEEE ARITHMETIC, 1 the level of support is processor dependent, and need not include support for any exceptions. If a flag is 2 signaling on entry to such a scoping unit, the processor ensures that it is signaling on exit. If a flag is 3 quiet on entry to such a scoping unit, whether it is signaling on exit is processor dependent. 4 Further IEEE support is available through the module IEEE ARITHMETIC. The extent of support 5 may be influenced by the accessibility of the named constants of the module IEEE FEATURES. If a 6 scoping unit has access to IEEE DATATYPE of IEEE FEATURES, within the scoping unit the pro- 7 cessor shall support IEEE arithmetic and return true from IEEE SUPPORT DATATYPE(X) (14.10.23) 8 for at least one kind of real. Similarly, if IEEE DENORMAL, IEEE DIVIDE, IEEE INF, IEEE NAN, 9 IEEE ROUNDING, or IEEE SQRT is accessible, within the scoping unit the processor shall support the 10 feature and return true from the corresponding inquiry function for at least one kind of real. In the case of 11 IEEE ROUNDING, it shall return true for all the rounding modes IEEE NEAREST, IEEE TO ZERO, 12 IEEE UP, and IEEE DOWN. 13 Execution might be slowed on some processors by the support of some features. If IEEE EXCEPTIONS 14 or IEEE ARITHMETIC is accessed but IEEE FEATURES is not accessed, the supported subset of fea- 15 tures is processor dependent. The processor's fullest support is provided when all of IEEE FEATURES 16 is accessed as in 17 USE, INTRINSIC :: IEEE_ARITHMETIC; USE, INTRINSIC :: IEEE_FEATURES 18 but execution might then be slowed by the presence of a feature that is not needed. In all cases, the 19 extent of support can be determined by the inquiry functions. 20 14.1 Derived typ es and constants defined in the mo dules 21 The modules IEEE EXCEPTIONS, IEEE ARITHMETIC, and IEEE FEATURES define five derived 22 types, whose components are all private. 23 The module IEEE EXCEPTIONS defines the following types. 24 · IEEE FLAG TYPE is for identifying a particular exception flag. Its only possible values are those 25 of named constants defined in the module: IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE - 26 BY ZERO, IEEE UNDERFLOW, and IEEE INEXACT. The module also defines the array named 27 constants IEEE USUAL = (/ IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE INVALID /) 28 and IEEE ALL = (/ IEEE USUAL, IEEE UNDERFLOW, IEEE INEXACT /). 29 · IEEE STATUS TYPE is for saving the current floating point status. 30 The module IEEE ARITHMETIC defines the following. 31 · The type IEEE CLASS TYPE, for identifying a class of floating-point values. Its only possible 32 values are those of named constants defined in the module: IEEE SIGNALING NAN, IEEE QUI- 33 ET NAN, IEEE NEGATIVE INF, IEEE NEGATIVE NORMAL, IEEE NEGATIVE DENORM- 34 AL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO, IEEE POSITIVE DENORMAL, IEEE - 35 POSITIVE NORMAL, IEEE POSITIVE INF, and IEEE OTHER VALUE. 36 · The type IEEE ROUND TYPE, for identifying a particular rounding mode. Its only possible 37 values are those of named constants defined in the module: IEEE NEAREST, IEEE TO ZERO, 38 IEEE UP, and IEEE DOWN for the IEEE modes; and IEEE OTHER for any other mode. 39 444 2006/07/11 WORKING DRAFT J3/06-007 · The elemental operator == for two values of one of these types to return true if the values are the 1 same and false otherwise. 2 · The elemental operator /= for two values of one of these types to return true if the values differ 3 and false otherwise. 4 The module IEEE FEATURES defines the type IEEE FEATURES TYPE, for expressing the 5 need for particular IEEE features. Its only possible values are those of named constants de- 6 fined in the module: IEEE DATATYPE, IEEE DENORMAL, IEEE DIVIDE, IEEE HALTING, 7 IEEE INEXACT FLAG, IEEE INF, IEEE INVALID FLAG, IEEE NAN, IEEE ROUNDING, 8 IEEE SQRT, and IEEE UNDERFLOW FLAG. 9 14.2 The exceptions 10 The exceptions are the following. 11 · IEEE OVERFLOW occurs when the result for an intrinsic real operation or assignment has an 12 absolute value greater than a processor-dependent limit, or the real or imaginary part of the result 13 for an intrinsic complex operation or assignment has an absolute value greater than a processor- 14 dependent limit. 15 · IEEE DIVIDE BY ZERO occurs when a real or complex division has a nonzero numerator and a 16 zero denominator. 17 · IEEE INVALID occurs when a real or complex operation or assignment is invalid; possible examples 18 are SQRT(X) when X is real and has a nonzero negative value, and conversion to an integer (by 19 assignment, an intrinsic procedure, or a procedure defined in an intrinsic module) when the result 20 is too large to be representable. 21 · IEEE UNDERFLOW occurs when the result for an intrinsic real operation or assignment has an 22 absolute value less than a processor-dependent limit and loss of accuracy is detected, or the real 23 or imaginary part of the result for an intrinsic complex operation or assignment has an absolute 24 value less than a processor-dependent limit and loss of accuracy is detected. 25 · IEEE INEXACT occurs when the result of a real or complex operation or assignment is not exact. 26 Each exception has a flag whose value is either quiet or signaling. The value can be determined by 27 the function IEEE GET FLAG. Its initial value is quiet and it signals when the associated excep- 28 tion occurs. Its status can also be changed by the subroutine IEEE SET FLAG or the subroutine 29 IEEE SET STATUS. Once signaling within a procedure, it remains signaling unless set quiet by an 30 invocation of the subroutine IEEE SET FLAG or the subroutine IEEE SET STATUS. 31 If a flag is signaling on entry to a procedure other than IEEE GET FLAG or IEEE GET STATUS, the 32 processor will set it to quiet on entry and restore it to signaling on return. 33 NOTE 14.4 If a flag signals during execution of a procedure, the processor shall not set it to quiet on return. Evaluation of a specification expression may cause an exception to signal. 34 In a scoping unit that has access to IEEE EXCEPTIONS or IEEE ARITHMETIC, if an intrinsic 35 procedure or a procedure defined in an intrinsic module executes normally, the values of the flags 36 IEEE OVERFLOW, IEEE DIVIDE BY ZERO, and IEEE INVALID shall be as on entry to the proce- 37 dure, even if one or more signals during the calculation. If a real or complex result is too large for the 38 445 J3/06-007 WORKING DRAFT 2006/07/11 procedure to handle, IEEE OVERFLOW may signal. If a real or complex result is a NaN because of an 1 invalid operation (for example, LOG(-1.0)), IEEE INVALID may signal. Similar rules apply to format 2 processing and to intrinsic operations: no signaling flag shall be set quiet and no quiet flag shall be set 3 signaling because of an intermediate calculation that does not affect the result. 4 In a sequence of statements that has no invocations of IEEE GET FLAG, IEEE SET FLAG, IEEE - 5 GET STATUS, IEEE SET HALTING MODE, or IEEE SET STATUS, if the execution of an operation 6 would cause an exception to signal but after execution of the sequence no value of a variable depends 7 on the operation, whether the exception is signaling is processor dependent. For example, when Y has 8 the value zero, whether the code 9 X = 1.0/Y 10 X = 3.0 11 signals IEEE DIVIDE BY ZERO is processor dependent. Another example is the following: 12 REAL, PARAMETER :: X=0.0, Y=6.0 13 IF (1.0/X == Y) PRINT *,'Hello world' 14 where the processor is permitted to discard the IF statement because the logical expression can never 15 be true and no value of a variable depends on it. 16 An exception shall not signal if this could arise only during execution of an operation beyond those 17 required or permitted by the standard. For example, the statement 18 IF (F(X)>0.0) Y = 1.0/Z 19 shall not signal IEEE DIVIDE BY ZERO when both F(X) and Z are zero and the statement 20 WHERE(A>0.0) A = 1.0/A 21 shall not signal IEEE DIVIDE BY ZERO. On the other hand, when X has the value 1.0 and Y has the 22 value 0.0, the expression 23 X>0.00001 .OR. X/Y>0.00001 24 is permitted to cause the signaling of IEEE DIVIDE BY ZERO. 25 The processor need not support IEEE INVALID, IEEE UNDERFLOW, and IEEE INEXACT. If an 26 exception is not supported, its flag is always quiet. The function IEEE SUPPORT FLAG can be used 27 to inquire whether a particular flag is supported. 28 14.3 The rounding mo des 29 The IEEE International Standard specifies four rounding modes. 30 · IEEE NEAREST rounds the exact result to the nearest representable value. 31 446 2006/07/11 WORKING DRAFT J3/06-007 · IEEE TO ZERO rounds the exact result towards zero to the next representable value. 1 · IEEE UP rounds the exact result towards +infinity to the next representable value. 2 · IEEE DOWN rounds the exact result towards -infinity to the next representable value. 3 The function IEEE GET ROUNDING MODE can be used to inquire which rounding mode is in opera- 4 tion. Its value is one of the above four or IEEE OTHER if the rounding mode does not conform to the 5 IEEE International Standard. 6 If the processor supports the alteration of the rounding mode during execution, the subroutine IEEE - 7 SET ROUNDING MODE can be used to alter it. The function IEEE SUPPORT ROUNDING can be 8 used to inquire whether this facility is available for a particular mode. The function IEEE SUPPORT IO 9 can be used to inquire whether rounding for base conversion in formatted input/output (9.4.6.4, 9.5.1.12, 10 10.7.2.3.7) is as specified in the IEEE International Standard. 11 In a procedure other than IEEE SET ROUNDING MODE or IEEE SET STATUS, the processor shall 12 not change the rounding mode on entry, and on return shall ensure that the rounding mode is the same 13 as it was on entry. 14 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. 14.4 Underflow mo de 15 Some processors allow control during program execution of whether underflow produces a denormalized 16 number in conformance with the IEEE International Standard (gradual underflow) or produces zero 17 instead (abrupt underflow). On some processors, floating-point performance is typically better in abrupt 18 underflow mode than in gradual underflow mode. 19 Control over the underflow mode is exercised by invocation of IEEE SET UNDERFLOW MODE. The 20 function IEEE GET UNDERFLOW MODE can be used to inquire which underflow mode is in op- 21 eration. The function IEEE SUPPORT UNDERFLOW MODE can be used to inquire whether this 22 facility is available. The initial underflow mode is processor dependent. In a procedure other than 23 IEEE SET UNDERFLOW MODE or IEEE SET STATUS, the processor shall not change the under- 24 flow mode on entry, and on return shall ensure that the underflow mode is the same as it was on entry. 25 The underflow mode affects only floating-point calculations whose type is that of an X for which 26 IEEE SUPPORT UNDERFLOW CONTROL returns true. 27 14.5 Halting 28 Some processors allow control during program execution of whether to abort or continue execution after 29 an exception. Such control is exercised by invocation of the subroutine IEEE SET HALTING MODE. 30 Halting is not precise and may occur any time after the exception has occurred. The function IEEE SUP- 31 PORT HALTING can be used to inquire whether this facility is available. The initial halting mode is 32 processor dependent. In a procedure other than IEEE SET HALTING MODE or IEEE SET STATUS, 33 the processor shall not change the halting mode on entry, and on return shall ensure that the halting 34 mode is the same as it was on entry. 35 447 J3/06-007 WORKING DRAFT 2006/07/11 14.6 The floating p oint status 1 The values of all the supported flags for exceptions, rounding mode, underflow mode, and halting are 2 called the floating point status. The floating point status can be saved in a scalar variable of type 3 TYPE(IEEE STATUS TYPE) with the subroutine IEEE GET STATUS and restored with the subrou- 4 tine IEEE SET STATUS. There are no facilities for finding the values of particular flags held within such 5 a variable. Portions of the floating point status can be saved with the subroutines IEEE GET FLAG, 6 IEEE GET HALTING MODE, and IEEE GET ROUNDING MODE, and set with the subroutines 7 IEEE SET FLAG, IEEE SET HALTING MODE, and IEEE SET ROUNDING MODE. 8 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 9 The IEEE International Standard specifies the following exceptional floating point values. 10 · Denormalized values have very small absolute values and lowered precision. 11 · Infinite values (+infinity and -infinity) are created by overflow or division by zero. 12 · Not-a-Number ( NaN) values are undefined values or values created by an invalid operation. 13 In this standard, the term normal is used for values that are not in one of these exceptional classes. 14 The functions IEEE IS FINITE, IEEE IS NAN, IEEE IS NEGATIVE, and IEEE IS NORMAL are pro- 15 vided to test whether a value is finite, NaN, negative, or normal. The function IEEE VALUE is pro- 16 vided to generate an IEEE number of any class, including an infinity or a NaN. The functions IEEE - 17 SUPPORT DENORMAL, IEEE SUPPORT INF, and IEEE SUPPORT NAN are provided to determine 18 whether these facilities are available for a particular kind of real. 19 14.8 IEEE arithmetic 20 The function IEEE SUPPORT DATATYPE can be used to inquire whether IEEE arithmetic is sup- 21 ported for a particular kind of real. Complete conformance with the IEEE International Standard is not 22 required, but the normalized numbers shall be exactly those of an IEEE floating-point format; the oper- 23 ations of addition, subtraction, and multiplication shall conform with at least one of the IEEE rounding 24 modes; the IEEE operation rem shall be provided by the function IEEE REM; and the IEEE functions 25 copysign, scalb, logb, nextafter, and unordered shall be provided by the functions IEEE COPY SIGN, 26 IEEE SCALB, IEEE LOGB, IEEE NEXT AFTER, and IEEE UNORDERED, respectively. The in- 27 quiry function IEEE SUPPORT DIVIDE is provided to inquire whether the processor supports divide 28 with the accuracy specified by the IEEE International Standard. For each of the operations of addi- 29 tion, subtraction, and multiplication, the result shall be as specified in the IEEE International Standard 30 whenever the IEEE result is normalized and the operands are normalized (if floating point) or are valid 31 and within range (if another type). 32 448 2006/07/11 WORKING DRAFT J3/06-007 The inquiry function IEEE SUPPORT NAN is provided to inquire whether the processor supports 1 IEEE NaNs. Where these are supported, their behavior for unary and binary operations, including 2 those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the 3 specifications in the IEEE International Standard. 4 The inquiry function IEEE SUPPORT INF is provided to inquire whether the processor supports IEEE 5 infinities. Where these are supported, their behavior for unary and binary operations, including those 6 defined by intrinsic functions and by functions in intrinsic modules, shall be consistent with the specifi- 7 cations in the IEEE International Standard. 8 The inquiry function IEEE SUPPORT DENORMAL is provided to inquire whether the processor sup- 9 ports IEEE denormals. Where these are supported, their behavior for unary and binary operations, 10 including those defined by intrinsic functions and by functions in intrinsic modules, shall be consistent 11 with the specifications in the IEEE International Standard. 12 The IEEE International Standard specifies a square root function that returns -0.0 for the square root 13 of -0.0 and has certain accuracy requirements. The function IEEE SUPPORT SQRT can be used to 14 inquire whether SQRT conforms to the IEEE International Standard for a particular kind of real. 15 The inquiry function IEEE SUPPORT STANDARD is provided to inquire whether the processor sup- 16 ports all the IEEE facilities defined in this standard for a particular kind of real. 17 14.9 Tables of the pro cedures 18 For all of the procedures defined in the modules, the arguments shown are the names that shall be used 19 for argument keywords if the keyword form is used for the actual arguments. 20 The procedure classification terms "inquiry function" and "transformational function" are used here 21 with the same meanings as in 13.1. 22 14.9.1 Inquiry functions 23 The module IEEE EXCEPTIONS contains the following inquiry functions. 24 IEEE SUPPORT FLAG (FLAG [, X]) Are IEEE exceptions supported? 25 IEEE SUPPORT HALTING (FLAG) Is IEEE halting control supported? 26 The module IEEE ARITHMETIC contains the following inquiry functions. 27 IEEE SUPPORT DATATYPE ([X]) Is IEEE arithmetic supported? 28 IEEE SUPPORT DENORMAL ([X]) Are IEEE denormalized numbers supported? 29 IEEE SUPPORT DIVIDE ([X]) Is IEEE divide supported? 30 IEEE SUPPORT INF ([X]) Is IEEE infinity supported? 31 IEEE SUPPORT IO ([X]) Is IEEE formatting supported? 32 IEEE SUPPORT NAN ([X]) Are IEEE NaNs supported? 33 IEEE SUPPORT ROUNDING Is IEEE rounding supported? 34 (ROUND VALUE [, X]) IEEE SUPPORT SQRT ([X]) Is IEEE square root supported? 35 IEEE SUPPORT STANDARD ([X]) Are all IEEE facilities supported? 36 IEEE SUPPORT UNDERFLOW CONTROL Is IEEE underflow control supported? 37 ([X]) 449 J3/06-007 WORKING DRAFT 2006/07/11 14.9.2 Elemental functions 1 The module IEEE ARITHMETIC contains the following elemental functions for reals X and Y for which 2 IEEE SUPPORT DATATYPE(X) and IEEE SUPPORT DATATYPE(Y) are true. 3 IEEE CLASS (X) IEEE class. 4 IEEE COPY SIGN (X,Y) IEEE copysign function. 5 IEEE IS FINITE (X) Determine if value is finite. 6 IEEE IS NAN (X) Determine if value is IEEE Not-a-Number. 7 IEEE IS NORMAL (X) Determine if a value is normal, that is, neither an 8 infinity, a NaN, nor denormalized. 9 IEEE IS NEGATIVE (X) Determine if value is negative. 10 IEEE LOGB (X) Unbiased exponent in the IEEE floating point 11 format. 12 IEEE NEXT AFTER (X,Y) Returns the next representable neighbor of X in 13 the direction toward Y. 14 IEEE REM (X,Y) The IEEE REM function, that is X - Y*N, where 15 N is the integer nearest to the exact value 16 X/Y. 17 IEEE RINT (X) Round to an integer value according to the 18 current rounding mode. 19 Returns X × 2I . IEEE SCALB (X,I) 20 IEEE UNORDERED (X,Y) IEEE unordered function. True if X or Y is a 21 NaN and false otherwise. 22 IEEE VALUE (X,CLASS) Generate an IEEE value. 23 14.9.3 Kind function 24 The module IEEE ARITHMETIC contains the following transformational function. 25 IEEE SELECTED REAL KIND ([P, R, Kind type parameter value for an IEEE real with 26 RADIX]) given precision, range, and radix. 27 14.9.4 Elemental subroutines 28 The module IEEE EXCEPTIONS contains the following elemental subroutines. 29 IEEE GET FLAG (FLAG,FLAG VALUE) Get an exception flag. 30 IEEE GET HALTING MODE (FLAG, Get halting mode for an exception. 31 HALTING) 14.9.5 Nonelemental subroutines 32 The module IEEE EXCEPTIONS contains the following nonelemental subroutines. 33 IEEE GET STATUS (STATUS VALUE) Get the current state of the floating point 34 environment. 35 IEEE SET FLAG (FLAG,FLAG VALUE) Set an exception flag. 36 IEEE SET HALTING MODE (FLAG, Controls continuation or halting on exceptions. 37 HALTING) IEEE SET STATUS (STATUS VALUE) Restore the state of the floating point 38 environment. 39 450 2006/07/11 WORKING DRAFT J3/06-007 The nonelemental subroutines IEEE SET FLAG and IEEE SET HALTING MODE are pure. No other 1 nonelemental subroutine contained in IEEE EXCEPTIONS is pure. 2 The module IEEE ARITHMETIC contains the following nonelemental subroutines. 3 IEEE GET ROUNDING MODE Get the current IEEE rounding mode. 4 (ROUND VALUE) IEEE GET UNDERFLOW MODE Get the current underflow mode. 5 (GRADUAL) IEEE SET ROUNDING MODE Set the current IEEE rounding mode. 6 (ROUND VALUE) IEEE SET UNDERFLOW MODE Set the current underflow mode. 7 (GRADUAL) No nonelemental subroutine contained in IEEE ARITHMETIC is pure. 8 14.10 Specifications of the procedures 9 In the detailed descriptions below, procedure names are generic and are not specific. All the functions 10 are pure. The dummy arguments of the intrinsic module procedures in 14.9.1, 14.9.2, and 14.9.3 have 11 INTENT(IN). The dummy arguments of the intrinsic module procedures in 14.9.4 and 14.9.5 have 12 INTENT(IN) if the intent is not stated explicitly. In the examples, it is assumed that the processor 13 supports IEEE arithmetic for default real. 14 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. For the elemental functions of IEEE ARITHMETIC, as tabulated in 14.9.2, if X or Y has a value that 15 is an infinity or a NaN, the result shall be consistent with the general rules in 6.1 and 6.2 of the IEEE 16 International Standard. For example, the result for an infinity shall be constructed as the limiting case 17 of the result with a value of arbitrarily large magnitude, if such a limit exists. 18 14.10.1 IEEE CLASS (X) 19 Description. IEEE class function. 20 Class. Elemental function. 21 Argument. X shall be of type real. 22 Restriction. IEEE CLASS(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has 23 the value false. 24 451 J3/06-007 WORKING DRAFT 2006/07/11 Result Characteristics. TYPE(IEEE CLASS TYPE). 1 Result Value. The result value shall be IEEE SIGNALING NAN or IEEE QUIET NAN 2 if IEEE SUPPORT NAN(X) has the value true and the value of X is a signaling or quiet 3 NaN, respectively. The result value shall be IEEE NEGATIVE INF or IEEE POSITIVE INF 4 if IEEE SUPPORT INF(X) has the value true and the value of X is negative or positive 5 infinity, respectively. The result value shall be IEEE NEGATIVE DENORMAL or IEEE- 6 POSITIVE DENORMAL if IEEE SUPPORT DENORMAL(X) has the value true and the 7 value of X is a negative or positive denormalized value, respectively. The result value shall be 8 IEEE NEGATIVE NORMAL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO, or IEEE- 9 POSITIVE NORMAL if value of X is negative normal, negative zero, positive zero, or positive 10 normal, respectively. Otherwise, the result value shall be IEEE OTHER VALUE. 11 Example. IEEE CLASS(-1.0) has the value IEEE NEGATIVE NORMAL. 12 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) 13 Description. IEEE copysign function. 14 Class. Elemental function. 15 Arguments. The arguments shall be of type real. 16 Restriction. IEEE COPY SIGN(X,Y) shall not be invoked if IEEE SUPPORT DATA- 17 TYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 18 Result Characteristics. Same as X. 19 Result Value. The result has the value of X with the sign of Y. This is true even for IEEE 20 special values, such as a NaN or an infinity (on processors supporting such values). 21 Example. The value of IEEE COPY SIGN(X,1.0) is ABS(X) even when X is NaN. 22 14.10.3 IEEE GET FLAG (FLAG, FLAG VALUE) 23 Description. Get an exception flag. 24 Class. Elemental subroutine. 25 Arguments. 26 FLAG shall be of type TYPE(IEEE FLAG TYPE). It specifies the IEEE flag to be 27 obtained. 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 28 corresponding exception flag is signaling and is false otherwise. Example. Following CALL IEEE GET FLAG(IEEE OVERFLOW,FLAG VALUE), FLAG - 29 452 2006/07/11 WORKING DRAFT J3/06-007 VALUE is true if the IEEE OVERFLOW flag is signaling and is false if it is quiet. 1 14.10.4 IEEE GET HALTING MODE (FLAG, HALTING) 2 Description. Get halting mode for an exception. 3 Class. Elemental subroutine. 4 Arguments. 5 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 - 6 DIVIDE BY ZERO, IEEE UNDERFLOW, or IEEE INEXACT. HALTING shall be of type default logical. It is of INTENT(OUT). The value is true if the exception specified by FLAG will cause halting. Otherwise, the value is 7 false. Example. To store the halting mode for IEEE OVERFLOW, do a calculation without halting, 8 and restore the halting mode later: 9 USE, INTRINSIC :: IEEE_ARITHMETIC 10 LOGICAL HALTING 11 ... 12 CALL IEEE_GET_HALTING_MODE(IEEE_OVERFLOW,HALTING) ! Store halting mode 13 CALL IEEE_SET_HALTING_MODE(IEEE_OVERFLOW,.FALSE.) ! No halting 14 ...! calculation without halting 15 CALL IEEE_SET_HALTING_MODE(IEEE_OVERFLOW,HALTING) ! Restore halting mode 16 14.10.5 IEEE GET ROUNDING MODE (ROUND VALUE) 17 Description. Get the current IEEE rounding mode. 18 Class. Subroutine. 19 Argument. ROUND VALUE shall be scalar of type TYPE(IEEE ROUND TYPE). It is an IN- 20 TENT(OUT) argument and returns the floating point rounding mode, with value IEEE NEAR- 21 EST, IEEE TO ZERO, IEEE UP, or IEEE DOWN if one of the IEEE modes is in operation 22 and IEEE OTHER otherwise. 23 Example. To store the rounding mode, do a calculation with round to nearest, and restore the 24 rounding mode later: 25 USE, INTRINSIC :: IEEE_ARITHMETIC 26 TYPE(IEEE_ROUND_TYPE) ROUND_VALUE 27 ... 28 CALL IEEE_GET_ROUNDING_MODE(ROUND_VALUE) ! Store the rounding mode 29 CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) 30 ... ! calculation with round to nearest 31 CALL IEEE_SET_ROUNDING_MODE(ROUND_VALUE) ! Restore the rounding mode 32 14.10.6 IEEE GET STATUS (STATUS VALUE) 33 453 J3/06-007 WORKING DRAFT 2006/07/11 Description. Get the current value of the floating point status (14.6). 1 Class. Subroutine. 2 Argument. STATUS VALUE shall be scalar of type TYPE(IEEE STATUS TYPE). It is an 3 INTENT(OUT) argument and returns the floating point status. 4 Example. To store all the exception flags, do a calculation involving exception handling, and 5 restore them later: 6 USE, INTRINSIC :: IEEE_ARITHMETIC 7 TYPE(IEEE_STATUS_TYPE) STATUS_VALUE 8 ... 9 CALL IEEE_GET_STATUS(STATUS_VALUE) ! Get the flags 10 CALL IEEE_SET_FLAG(IEEE_ALL,.FALSE.) ! Set the flags quiet. 11 ... ! calculation involving exception handling 12 CALL IEEE_SET_STATUS(STATUS_VALUE) ! Restore the flags 13 14.10.7 IEEE GET UNDERFLOW MODE (GRADUAL) 14 Description. Get the current underflow mode (14.4). 15 Class. Subroutine. 16 Argument. GRADUAL shall be scalar and of type default logical. It is an INTENT(OUT) 17 argument. The value is true if the current underflow mode is gradual underflow, and false if the 18 current underflow mode is abrupt underflow. 19 Restriction. IEEE GET UNDERFLOW MODE shall not be invoked unless IEEE SUPPORT- 20 UNDERFLOW CONTROL(X) is true for some X. 21 Example. After CALL IEEE SET UNDERFLOW MODE(.FALSE.), a subsequent CALL 22 IEEE GET UNDERFLOW MODE(GRADUAL) will set GRADUAL to false. 23 14.10.8 IEEE IS FINITE (X) 24 Description. Determine if a value is finite. 25 Class. Elemental function. 26 Argument. X shall be of type real. 27 Restriction. IEEE IS FINITE(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) 28 has the value false. 29 Result Characteristics. Default logical. 30 Result Value. The result has the value true if the value of X is finite, that is, IEEE CLASS(X) 31 has one of the values IEEE NEGATIVE NORMAL, IEEE NEGATIVE DENORMAL, IEEE - 32 NEGATIVE ZERO, IEEE POSITIVE ZERO, IEEE POSITIVE DENORMAL, or IEEE POS- 33 ITIVE NORMAL; otherwise, the result has the value false. 34 Example. IEEE IS FINITE(1.0) has the value true. 35 14.10.9 IEEE IS NAN (X) 36 454 2006/07/11 WORKING DRAFT J3/06-007 Description. Determine if a value is IEEE Not-a-Number. 1 Class. Elemental function. 2 Argument. X shall be of type real. 3 Restriction. IEEE IS NAN(X) shall not be invoked if IEEE SUPPORT NAN(X) has the value 4 false. 5 Result Characteristics. Default logical. 6 Result Value. The result has the value true if the value of X is an IEEE NaN; otherwise, it 7 has the value false. 8 Example. IEEE IS NAN(SQRT(-1.0)) has the value true if IEEE SUPPORT SQRT(1.0) has 9 the value true. 10 14.10.10 IEEE IS NEGATIVE (X) 11 Description. Determine if a value is negative. 12 Class. Elemental function. 13 Argument. X shall be of type real. 14 Restriction. IEEE IS NEGATIVE(X) shall not be invoked if IEEE SUPPORT DATA- 15 TYPE(X) has the value false. 16 Result Characteristics. Default logical. 17 Result Value. The result has the value true if IEEE CLASS(X) has one of the values 18 IEEE NEGATIVE NORMAL, IEEE NEGATIVE DENORMAL, IEEE NEGATIVE ZERO or 19 IEEE NEGATIVE INF; otherwise, the result has the value false. 20 Example. IEEE IS NEGATIVE(0.0)) has the value false. 21 14.10.11 IEEE IS NORMAL (X) 22 Description. Determine if a value is normal, that is, neither an infinity, a NaN, nor denormal- 23 ized. 24 Class. Elemental function. 25 Argument. X shall be of type real. 26 Restriction. IEEE IS NORMAL(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) 27 has the value false. 28 Result Characteristics. Default logical. 29 Result Value. The result has the value true if IEEE CLASS(X) has one of the values 30 IEEE NEGATIVE NORMAL, IEEE NEGATIVE ZERO, IEEE POSITIVE ZERO or IEEE - 31 POSITIVE NORMAL; otherwise, the result has the value false. 32 Example. IEEE IS NORMAL(SQRT(-1.0)) has the value false if IEEE SUPPORT SQRT(1.0) 33 has the value true. 34 14.10.12 IEEE LOGB (X) 35 455 J3/06-007 WORKING DRAFT 2006/07/11 Description. Unbiased exponent in the IEEE floating point format. 1 Class. Elemental function. 2 Argument. X shall be of type real. 3 Restriction. IEEE LOGB(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has 4 the value false. 5 Result Characteristics. Same as X. 6 Result Value. 7 Case (i): If the value of X is neither zero, infinity, nor NaN, the result has the value of the 8 unbiased exponent of X. Note: this value is equal to EXPONENT(X)-1. 9 Case (ii): If X==0, the result is -infinity if IEEE SUPPORT INF(X) is true and -HUGE(X) 10 otherwise; IEEE DIVIDE BY ZERO signals. 11 Example. IEEE LOGB(-1.1) has the value 0.0. 12 14.10.13 IEEE NEXT AFTER (X, Y) 13 Description. Returns the next representable neighbor of X in the direction toward Y. 14 Class. Elemental function. 15 Arguments. The arguments shall be of type real. 16 Restriction. IEEE NEXT AFTER(X,Y) shall not be invoked if IEEE SUPPORT DATA- 17 TYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 18 Result Characteristics. Same as X. 19 Result Value. 20 Case (i): If X == Y, the result is X and no exception is signaled. 21 Case (ii): If X /= Y, the result has the value of the next representable neighbor of X 22 in the direction of Y. The neighbors of zero (of either sign) are both nonzero. 23 IEEE OVERFLOW is signaled when X is finite but IEEE NEXT AFTER(X,Y) 24 is infinite; IEEE UNDERFLOW is signaled when IEEE NEXT AFTER(X,Y) is 25 denormalized; in both cases, IEEE INEXACT signals. 26 Example. The value of IEEE NEXT AFTER(1.0,2.0) is 1.0+EPSILON(X). 27 14.10.14 IEEE REM (X, Y) 28 Description. IEEE REM function. 29 Class. Elemental function. 30 Arguments. The arguments shall be of type real. 31 Restriction. IEEE REM(X,Y) shall not be invoked if IEEE SUPPORT DATATYPE(X) or 32 IEEE SUPPORT DATATYPE(Y) has the value false. 33 Result Characteristics. Real with the kind type parameter of whichever argument has the 34 greater precision. 35 Result Value. The result value, regardless of the rounding mode, shall be exactly X - Y*N, 36 456 2006/07/11 WORKING DRAFT J3/06-007 where N is the integer nearest to the exact value X/Y; whenever |N - X/Y| = 1/2, N shall be 1 even. If the result value is zero, the sign shall be that of X. 2 Examples. The value of IEEE REM(4.0,3.0) is 1.0, the value of IEEE REM(3.0,2.0) is -1.0, 3 and the value of IEEE REM(5.0,2.0) is 1.0. 4 14.10.15 IEEE RINT (X) 5 Description. Round to an integer value according to the current rounding mode. 6 Class. Elemental function. 7 Argument. X shall be of type real. 8 Restriction. IEEE RINT(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has the 9 value false. 10 Result Characteristics. Same as X. 11 Result Value. The value of the result is the value of X rounded to an integer according to the 12 current rounding mode. If the result has the value zero, the sign is that of X. 13 Examples. If the current rounding mode is round to nearest, the value of IEEE RINT(1.1) is 14 1.0. If the current rounding mode is round up, the value of IEEE RINT(1.1) is 2.0. 15 14.10.16 IEEE SCALB (X, I) 16 Description. Returns X × 2I . 17 Class. Elemental function. 18 Arguments. 19 X shall be of type real. 20 I shall be of type integer. 21 Restriction. IEEE SCALB(X) shall not be invoked if IEEE SUPPORT DATATYPE(X) has 22 the value false. 23 Result Characteristics. Same as X. 24 Result Value. 25 If X × 2I is representable as a normal number, the result has this value. Case (i): 26 If X is finite and X × 2I is too large, the IEEE OVERFLOW exception shall Case (ii): 27 occur. If IEEE SUPPORT INF(X) is true, the result value is infinity with the 28 sign of X; otherwise, the result value is SIGN(HUGE(X),X). 29 If X × 2I is too small and there is loss of accuracy, the IEEE UNDERFLOW Case (iii): 30 exception shall occur. The result is the representable number having a magnitude 31 nearest to |2I | and the same sign as X. 32 Case (iv): If X is infinite, the result is the same as X; no exception signals. 33 Example. The value of IEEE SCALB(1.0,2) is 4.0. 34 14.10.17 IEEE SELECTED REAL KIND ([P, R, RADIX]) 35 457 J3/06-007 WORKING DRAFT 2006/07/11 Description. Returns a value of the kind type parameter of an IEEE real data type with 1 decimal precision of at least P digits, a decimal exponent range of at least R, and a radix of 2 RADIX. For data ob jects of such a type, IEEE SUPPORT DATATYPE(X) has the value true. 3 Class. Transformational function. 4 Arguments. At least one argument shall be present. 5 P (optional) shall be scalar and of type integer. 6 R (optional) shall be scalar and of type integer. 7 RADIX (optional) shall be scalar and of type integer. 8 Result Characteristics. Default integer scalar. 9 Result Value. If P or R is absent, the result value is the same as if it were present with the 10 value zero. If RADIX is absent, there is no requirement on the radix of the selected kind. The 11 result has a value equal to a value of the kind type parameter of an IEEE real type with decimal 12 precision, as returned by the function PRECISION, of at least P digits, a decimal exponent 13 range, as returned by the function RANGE, of at least R, and a radix, as returned by the 14 function RADIX, of RADIX, if such a kind type parameter is available on the processor. 15 Otherwise, the result is -1 if the processor supports an IEEE real type with radix RADIX and exponent 16 range of at least R but not with precision of at least P, -2 if the processor supports an IEEE real 17 type with radix RADIX and precision of at least P but not with exponent range of at least R, -3 if 18 the processor supports an IEEE real type with radix RADIX but with neither precision of at least P 19 nor exponent range of at least R, -4 if the processor supports an IEEE real type with radix RADIX 20 and either precision of at least P or exponent range of at least R but not both together, and -5 if the 21 processor supports no IEEE real type with radix RADIX. 22 If more than one kind type parameter value meets the criteria, the value returned is the one with the 23 smallest decimal precision, unless there are several such values, in which case the smallest of these kind 24 values is returned. 25 Example. IEEE SELECTED REAL KIND(6,30) has the value KIND(0.0) on a machine that 26 supports IEEE single precision arithmetic for its default real approximation method. 27 14.10.18 IEEE SET FLAG (FLAG, FLAG VALUE) 28 Description. Assign a value to an exception flag. 29 Class. Pure subroutine. 30 Arguments. 31 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 UNDERFLOW, or IEEE INEXACT, the corresponding exception flag 32 is assigned a value. No 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 33 signaling; otherwise, the flag is set to be quiet. Example. CALL IEEE SET FLAG(IEEE OVERFLOW,.TRUE.) sets the IEEE OVERFLOW 34 458 2006/07/11 WORKING DRAFT J3/06-007 flag to be signaling. 1 14.10.19 IEEE SET HALTING MODE (FLAG, HALTING) 2 Description. Controls continuation or halting after an exception. 3 Class. Pure subroutine. 4 Arguments. 5 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 6 shall have the same value. HALTING shall be a scalar or array of type default logical. It shall be conformable with FLAG. If an element has the value is true, the corresponding exception specified by FLAG will cause halting. Otherwise, execution will continue 7 after this exception. Restriction. IEEE SET HALTING MODE(FLAG,HALTING) shall not be invoked if IEEE - 8 SUPPORT HALTING(FLAG) has the value false. 9 Example. CALL IEEE SET HALTING MODE(IEEE DIVIDE BY ZERO,.TRUE.) causes 10 halting after a divide by zero exception. 11 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) 12 Description. Set the current IEEE rounding mode. 13 Class. Subroutine. 14 Argument. ROUND VALUE shall be scalar and of type TYPE(IEEE ROUND TYPE). It 15 specifies the mode to be set. 16 Restriction. IEEE SET ROUNDING MODE(ROUND VALUE) shall not be invoked un- 17 less IEEE SUPPORT ROUNDING(ROUND VALUE,X) is true for some X such that IEEE - 18 SUPPORT DATATYPE(X) is true. 19 Example. To store the rounding mode, do a calculation with round to nearest, and restore the 20 rounding mode later: 21 USE, INTRINSIC :: IEEE_ARITHMETIC 22 TYPE(IEEE_ROUND_TYPE) ROUND_VALUE 23 ... 24 CALL IEEE_GET_ROUNDING_MODE(ROUND_VALUE) ! Store the rounding mode 25 CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST) 26 : ! calculation with round to nearest 27 CALL IEEE_SET_ROUNDING_MODE(ROUND_VALUE) ! Restore the rounding mode 28 14.10.21 IEEE SET STATUS (STATUS VALUE) 29 459 J3/06-007 WORKING DRAFT 2006/07/11 Description. Restore the value of the floating point status (14.6). 1 Class. Subroutine. 2 Argument. STATUS VALUE shall be scalar and of type TYPE(IEEE STATUS TYPE). Its 3 value shall have been set in a previous invocation of IEEE GET STATUS. 4 Example. To store all the exceptions flags, do a calculation involving exception handling, and 5 restore them later: 6 USE, INTRINSIC :: IEEE_EXCEPTIONS 7 TYPE(IEEE_STATUS_TYPE) STATUS_VALUE 8 ... 9 CALL IEEE_GET_STATUS(STATUS_VALUE) ! Store the flags 10 CALL IEEE_SET_FLAGS(IEEE_ALL,.FALSE.) ! Set them quiet 11 ... ! calculation involving exception handling 12 CALL IEEE_SET_STATUS(STATUS_VALUE) ! Restore the flags 13 NOTE 14.11 On some processors this may be a very time consuming process. 14.10.22 IEEE SET UNDERFLOW MODE (GRADUAL) 14 Description. Set the current underflow mode. 15 Class. Subroutine. 16 Argument. GRADUAL shall be scalar and of type default logical. If it is true, the current 17 underflow mode is set to gradual underflow. If it is false, the current underflow mode is set to 18 abrupt underflow. 19 Restriction. IEEE SET UNDERFLOW MODE shall not be invoked unless IEEE SUPPORT- 20 UNDERFLOW CONTROL(X) is true for some X. 21 Example. To perform some calculations with abrupt underflow and then restore the previous 22 mode: 23 USE,INTRINSIC :: IEEE_ARITHMETIC 24 LOGICAL SAVE_UNDERFLOW_MODE 25 ... 26 CALL IEEE_GET_UNDERFLOW_MODE(SAVE_UNDERFLOW_MODE) 27 CALL IEEE_SET_UNDERFLOW_MODE(GRADUAL=.FALSE.) 28 ... ! Perform some calculations with abrupt underflow 29 CALL IEEE_SET_UNDERFLOW_MODE(SAVE_UNDERFLOW_MODE) 30 14.10.23 IEEE SUPPORT DATATYPE () or IEEE SUPPORT DATATYPE (X) 31 Description. Inquire whether the processor supports IEEE arithmetic. 32 Class. Inquiry function. 33 460 2006/07/11 WORKING DRAFT J3/06-007 Argument. X shall be of type real. It may be a scalar or an array. 1 Result Characteristics. Default logical scalar. 2 Result Value. The result has the value true if the processor supports IEEE arithmetic for all 3 reals (X absent) or for real variables of the same kind type parameter as X; otherwise, it has 4 the value false. Here, support is as defined in the first paragraph of 14.8. 5 Example. If default real type conforms to the IEEE International Standard except that un- 6 derflow values flush to zero instead of being denormal, IEEE SUPPORT DATATYPE(1.0) has 7 the value true. 8 14.10.24 IEEE SUPPORT DENORMAL () or IEEE SUPPORT DENORMAL (X) 9 Description. Inquire whether the processor supports IEEE denormalized numbers. 10 Class. Inquiry function. 11 Argument. X shall be of type real. It may be a scalar or an array. 12 Result Characteristics. Default logical scalar. 13 Result Value. 14 Case (i): IEEE SUPPORT DENORMAL(X) has the value true if IEEE SUPPORT - 15 DATATYPE(X) has the value true and the processor supports arithmetic op- 16 erations and assignments with denormalized numbers (biased exponent e = 0 17 and fraction f = 0, see subclause 3.2 of the IEEE International Standard) for 18 real variables of the same kind type parameter as X; otherwise, it has the value 19 false. 20 Case (ii): IEEE SUPPORT DENORMAL() has the value true if and only if IEEE SUP- 21 PORT DENORMAL(X) has the value true for all real X. 22 Example. IEEE SUPPORT DENORMAL(X) has the value true if the processor supports 23 denormalized numbers for X. 24 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) 25 Description. Inquire whether the processor supports divide with the accuracy specified by the 26 IEEE International Standard. 27 Class. Inquiry function. 28 Argument. X shall be of type real. It may be a scalar or an array. 29 Result Characteristics. Default logical scalar. 30 Result Value. 31 Case (i): IEEE SUPPORT DIVIDE(X) has the value true if the processor supports divide 32 with the accuracy specified by the IEEE International Standard for real variables 33 461 J3/06-007 WORKING DRAFT 2006/07/11 of the same kind type parameter as X; otherwise, it has the value false. 1 Case (ii): IEEE SUPPORT DIVIDE() has the value true if and only if IEEE SUPPORT - 2 DIVIDE(X) has the value true for all real X. 3 Example. IEEE SUPPORT DIVIDE(X) has the value true if the processor supports IEEE 4 divide for X. 5 14.10.26 IEEE SUPPORT FLAG (FLAG) or IEEE SUPPORT FLAG (FLAG, X) 6 Description. Inquire whether the processor supports an exception. 7 Class. Inquiry function. 8 Arguments. 9 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, 10 IEEE UNDERFLOW, or IEEE INEXACT. X shall be of type real. It may be a scalar or an array. 11 Result Characteristics. Default logical scalar. 12 Result Value. 13 Case (i): IEEE SUPPORT FLAG(FLAG, X) has the value true if the processor supports 14 detection of the specified exception for real variables of the same kind type pa- 15 rameter as X; otherwise, it has the value false. 16 Case (ii): IEEE SUPPORT FLAG(FLAG) has the value true if and only if IEEE SUP- 17 PORT FLAG(FLAG, X) has the value true for all real X. 18 Example. IEEE SUPPORT FLAG(IEEE INEXACT) has the value true if the processor sup- 19 ports the inexact exception. 20 14.10.27 IEEE SUPPORT HALTING (FLAG) 21 Description. Inquire whether the processor supports the ability to control during program 22 execution whether to abort or continue execution after an exception. 23 Class. Inquiry function. 24 Argument. FLAG shall be scalar and of type TYPE(IEEE FLAG TYPE). Its value shall be 25 one of IEEE INVALID, IEEE OVERFLOW, IEEE DIVIDE BY ZERO, IEEE UNDERFLOW, 26 or IEEE INEXACT. 27 Result Characteristics. Default logical scalar. 28 Result Value. The result has the value true if the processor supports the ability to control 29 during program execution whether to abort or continue execution after the exception specified 30 by FLAG; otherwise, it has the value false. Support includes the ability to change the mode by 31 CALL IEEE SET HALTING(FLAG). 32 Example. IEEE SUPPORT HALTING(IEEE OVERFLOW) has the value true if the proces- 33 sor supports control of halting after an overflow. 34 14.10.28 IEEE SUPPORT INF () or IEEE SUPPORT INF (X) 35 Description. Inquire whether the processor supports the IEEE infinity facility. 36 462 2006/07/11 WORKING DRAFT J3/06-007 Class. Inquiry function. 1 Argument. X shall be of type real. It may be a scalar or an array. 2 Result Characteristics. Default logical scalar. 3 Result Value. 4 Case (i): IEEE SUPPORT INF(X) has the value true if the processor supports IEEE in- 5 finities (positive and negative) for real variables of the same kind type parameter 6 as X; otherwise, it has the value false. 7 Case (ii): IEEE SUPPORT INF() has the value true if and only if IEEE SUPPORT - 8 INF(X) has the value true for all real X. 9 Example. IEEE SUPPORT INF(X) has the value true if the processor supports IEEE infinities 10 for X. 11 14.10.29 IEEE SUPPORT IO () or IEEE SUPPORT IO (X) 12 Description. Inquire whether the processor supports IEEE base conversion rounding during 13 formatted input/output (9.4.6.4, 9.5.1.12, 10.7.2.3.7). 14 Class. Inquiry function. 15 Argument. X shall be of type real. It may be a scalar or an array. 16 Result Characteristics. Default logical scalar. 17 Result Value. 18 Case (i): IEEE SUPPORT IO(X) has the value true if the processor supports IEEE base 19 conversion during formatted input/output (9.4.6.4, 9.5.1.12, 10.7.2.3.7) as de- 20 scribed in the IEEE International Standard for the modes UP, DOWN, ZERO, 21 and NEAREST for real variables of the same kind type parameter as X; otherwise, 22 it has the value false. 23 Case (ii): IEEE SUPPORT IO() has the value true if and only if IEEE SUPPORT IO(X) 24 has the value true for all real X. 25 Example. IEEE SUPPORT IO(X) has the value true if the processor supports IEEE base 26 conversion for X. 27 14.10.30 IEEE SUPPORT NAN () or IEEE SUPPORT NAN (X) 28 Description. Inquire whether the processor supports the IEEE Not-a-Number facility. 29 Class. Inquiry function. 30 Argument. X shall be of type real. It may be a scalar or an array. 31 Result Characteristics. Default logical scalar. 32 Result Value. 33 Case (i): IEEE SUPPORT NAN(X) has the value true if the processor supports IEEE 34 NaNs for real variables of the same kind type parameter as X; otherwise, it has 35 the value false. 36 Case (ii): IEEE SUPPORT NAN() has the value true if and only if IEEE SUPPORT - 37 NAN(X) has the value true for all real X. 38 463 J3/06-007 WORKING DRAFT 2006/07/11 Example. IEEE SUPPORT NAN(X) has the value true if the processor supports IEEE NaNs 1 for X. 2 14.10.31 IEEE SUPPORT ROUNDING (ROUND VALUE) or IEEE SUPPORT ROUNDING (ROUND VALUE, X) 3 Description. Inquire whether the processor supports a particular IEEE rounding mode. 4 Class. Inquiry function. 5 Arguments. 6 ROUND VALUE shall be of type TYPE(IEEE ROUND TYPE). 7 X shall be of type real. It may be a scalar or an array. 8 Result Characteristics. Default logical scalar. 9 Result Value. 10 Case (i): IEEE SUPPORT ROUNDING(ROUND VALUE, X) has the value true if the 11 processor supports the rounding mode defined by ROUND VALUE for real vari- 12 ables of the same kind type parameter as X; otherwise, it has the value false. Sup- 13 port includes the ability to change the mode by CALL IEEE SET ROUNDING- 14 MODE(ROUND VALUE). 15 Case (ii): IEEE SUPPORT ROUNDING(ROUND VALUE) has the value true if and only 16 if IEEE SUPPORT ROUNDING(ROUND VALUE, X) has the value true for all 17 real X. 18 Example. IEEE SUPPORT ROUNDING(IEEE TO ZERO) has the value true if the processor 19 supports rounding to zero for all reals. 20 14.10.32 IEEE SUPPORT SQRT () or IEEE SUPPORT SQRT (X) 21 Description. Inquire whether the intrinsic function SQRT conforms to the IEEE International 22 Standard. 23 Class. Inquiry function. 24 Argument. X shall be of type real. It may be a scalar or an array. 25 Result Characteristics. Default logical scalar. 26 Result Value. 27 Case (i): IEEE SUPPORT SQRT(X) has the value true if the intrinsic function SQRT 28 conforms to the IEEE International Standard for real variables of the same kind 29 type parameter as X; otherwise, it has the value false. 30 Case (ii): IEEE SUPPORT SQRT() has the value true if and only if IEEE SUPPORT - 31 SQRT(X) has the value true for all real X. 32 Example. If IEEE SUPPORT SQRT(1.0) has the value true, SQRT(-0.0) will have the value 33 -0.0. 34 14.10.33 IEEE SUPPORT STANDARD () or IEEE SUPPORT STANDARD (X) 35 Description. Inquire whether the processor supports all the IEEE facilities defined in this 36 standard. 37 464 2006/07/11 WORKING DRAFT J3/06-007 Class. Inquiry function. 1 Argument. X shall be of type real. It may be a scalar or an array. 2 Result Characteristics. Default logical scalar. 3 Result Value. 4 Case (i): IEEE SUPPORT STANDARD(X) has the value true if the results of all the func- 5 tions IEEE SUPPORT DATATYPE(X), IEEE SUPPORT DENORMAL(X), 6 IEEE SUPPORT DIVIDE(X), IEEE SUPPORT FLAG(FLAG,X) for valid 7 FLAG, IEEE SUPPORT HALTING(FLAG) for valid FLAG, IEEE SUP- 8 PORT INF(X), IEEE SUPPORT NAN(X), IEEE SUPPORT ROUNDING 9 (ROUND VALUE,X) for valid ROUND VALUE, and IEEE SUPPORT SQRT 10 (X) are all true; otherwise, the result has the value false. 11 Case (ii): IEEE SUPPORT STANDARD() has the value true if and only if IEEE SUP- 12 PORT STANDARD(X) has the value true for all real X. 13 Example. IEEE SUPPORT STANDARD() has the value false if the processor supports both 14 IEEE and non-IEEE kinds of reals. 15 14.10.34 IEEE SUPPORT UNDERFLOW CONTROL() or 16 IEEE SUPPORT UNDERFLOW CONTROL(X) 17 Description. Inquire whether the procedure supports the ability to control the underflow mode 18 during program execution. 19 Class. Inquiry function. 20 Argument. X shall be of type real. It may be a scalar or an array. 21 Result Characteristics. Default logical scalar. 22 Result Value. 23 Case (i): IEEE SUPPORT UNDERFLOW CONTROL(X) has the value true if the pro- 24 cessor supports control of the underflow mode for floating-point calculations with 25 the same type as X, and false otherwise. 26 Case (ii): IEEE SUPPORT UNDERFLOW CONTROL() has the value true if the proces- 27 sor supports control of the underflow mode for all floating-point calculations, and 28 false otherwise. 29 Example. IEEE SUPPORT UNDERFLOW CONTROL(2.5) has the value true if the proces- 30 sor supports underflow mode control for calculations of type default real. 31 14.10.35 IEEE UNORDERED (X, Y) 32 Description. IEEE unordered function. True if X or Y is a NaN, and false otherwise. 33 Class. Elemental function. 34 Arguments. The arguments shall be of type real. 35 Restriction. IEEE UNORDERED(X,Y) shall not be invoked if IEEE SUPPORT DATA- 36 TYPE(X) or IEEE SUPPORT DATATYPE(Y) has the value false. 37 Result Characteristics. Default logical. 38 465 J3/06-007 WORKING DRAFT 2006/07/11 Result Value. The result has the value true if X or Y is a NaN or both are NaNs; otherwise, 1 it has the value false. 2 Example. IEEE UNORDERED(0.0,SQRT(-1.0)) has the value true if IEEE SUPPORT - 3 SQRT(1.0) has the value true. 4 14.10.36 IEEE VALUE (X, CLASS) 5 Description. Generate an IEEE value. 6 Class. Elemental function. 7 Arguments. 8 X shall be of type real. 9 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 DE- NORMAL(X) has the value true, IEEE NEGATIVE NORMAL, IEEE NEG- 10 ATIVE ZERO, IEEE POSITIVE ZERO or IEEE POSITIVE NORMAL. Restriction. IEEE VALUE(X,CLASS) shall not be invoked if IEEE SUPPORT DATA- 11 TYPE(X) has the value false. 12 Result Characteristics. Same as X. 13 Result Value. The result value is an IEEE value as specified by CLASS. Although in most 14 cases the value is processor dependent, the value shall not vary between invocations for any 15 particular X kind type parameter and CLASS value. 16 Example. IEEE VALUE(1.0,IEEE NEGATIVE INF) has the value -infinity. 17 14.11 Examples 18 NOTE 14.13 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 466 2006/07/11 WORKING DRAFT J3/06-007 NOTE 14.13 (cont.) IF (SIZE(A)/=SIZE(B)) THEN 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.14 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 467 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 14.14 (cont.) CALL IEEE_SET_STATUS(STATUS_VALUE) In this example, the function FAST INV may 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.15 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.16 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 ) 468 2006/07/11 WORKING DRAFT J3/06-007 NOTE 14.16 (cont.) CALL IEEE_GET_FLAG(OUT_OF_RANGE,FLAGS) 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) ) ! may 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. 469 J3/06-007 WORKING DRAFT 2006/07/11 470 2006/07/11 WORKING DRAFT J3/06-007 15 Interop erability with C 1 15.1 General 2 Fortran provides a means of referencing procedures that are defined by means of the C programming 3 language or procedures that can be described by C prototypes as defined in 6.7.5.3 of the C International 4 Standard, even if they are not actually defined by means of C. Conversely, there is a means of specifying 5 that a procedure defined by a Fortran subprogram can be referenced from a function defined by means 6 of C. In addition, there is a means of declaring global variables that are associated with C variables that 7 have external linkage as defined in 6.2.2 of the C International Standard. 8 The ISO C BINDING module provides access to named constants that represent kind type parameters 9 of data representations compatible with C types. Fortran also provides facilities for defining derived 10 types (4.5) and enumerations (4.6) that correspond to C types. 11 15.2 The ISO C BINDING intrinsic mo dule 12 15.2.1 Summary of contents 13 The processor shall provide the intrinsic module ISO C BINDING. This module shall make accessible 14 the following entities: named constants with the names listed in the second column of Table 15.2 and 15 the first column of Table 15.1, the procedures specified in 15.2.3, C PTR, C FUNPTR, C NULL PTR, 16 and C NULL FUNPTR. A processor may provide other public entities in the ISO C BINDING intrinsic 17 module in addition to those listed here. 18 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 typ es in the mo dule 19 The entities listed in the second column of Table 15.2, shall be named constants of type default integer. 20 The value of C INT shall be a valid value for an integer kind parameter on the processor. The values 21 of C SHORT, C LONG, C LONG LONG, C SIGNED CHAR, C SIZE T, C INT8 T, C INT16 T, C - 22 INT32 T, C INT64 T, C INT LEAST8 T, C INT LEAST16 T, C INT LEAST32 T, C INT LEAST64- 23 T, C INT FAST8 T, C INT FAST16 T, C INT FAST32 T, C INT FAST64 T, C INTMAX T, and C - 24 INTPTR T shall each be a valid value for an integer kind type parameter on the processor or shall be 25 -1 if the companion C processor defines the corresponding C type and there is no interoperating Fortran 26 processor kind or -2 if the C processor does not define the corresponding C type. 27 The values of C FLOAT, C DOUBLE, and C LONG DOUBLE shall each be a valid value for a real 28 kind type parameter on the processor or shall be -1 if the C processor's type does not have a precision 29 equal to the precision of any of the Fortran processor's real kinds, -2 if the C processor's type does not 30 have a range equal to the range of any of the Fortran processor's real kinds, -3 if the C processor's type 31 has neither the precision nor range of any of the Fortran processor's real kinds, and equal to -4 if there 32 is no interoperating Fortran processor kind for other reasons. The values of C FLOAT COMPLEX, 33 C DOUBLE COMPLEX, and C LONG DOUBLE COMPLEX shall be the same as those of C FLOAT, 34 471 J3/06-007 WORKING DRAFT 2006/07/11 C DOUBLE, and C LONG DOUBLE, respectively. 1 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. The value of C BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1. 2 The value of C UINT shall be a valid value for a bits kind type parameter of the processor. The val- 3 ues of C USHORT, C ULONG, C ULONG LONG, C UNSIGNED CHAR, C UINT8 T, C UINT16 T, 4 C UINT32 T, C UINT64 T, C UINT LEAST8 T, C UINT LEAST16 T, C UINT LEAST32 T, C UINT - 5 LEAST64 T, C UINT FAST8 T, C UINT FAST16 T, C UINT FAST32 T, C UINT FAST64 T, C UINTMAX - 6 T, C UINTPTR T, C FLOAT BITS, C DOUBLE BITS, C LONG DOUBLE BITS, C FLOAT COMPLEX - 7 BITS, C DOUBLE COMPLEX BITS, C LONG DOUBLE COMPLEX BITS, and C BOOL BITS shall 8 each be a valid value for a bits kind type parameter on the processor, -1 if the companion C processor 9 defines the corresponding C type and there is no interoperating Fortran processor kind, or -2 if the C 10 processor does not define the corresponding C type. 11 J3 internal note Unresolved Technical Issue 74 This has taken all the "obvious" names for constants that interoperate with unsigned integers, should we consider adding proper unsigned integer support in a future Fortran. And all for the dubious pleasure of saving a few keystrokes from BITS KIND(0 C SHORT) et al, when one wants to declare BITS arguments or components. But since BITS actuals are compatible with INTEGER dummies, that seems like an almost complete waste of namespace. As for C FLOAT COMPLEX BITS, instead of BITS KIND(C FLOAT COMPLEX)... Furthermore, the names are completely misleading, because they interoperate equally well with signed as well as unsigned just like the existing C INT et al. The right name for these is C INT BITS et al, if we need them at all. The value of C CHAR shall be a valid value for a character kind type parameter on the processor or 12 shall be -1. The value of C CHAR is known as the C character kind. 13 The following entities shall be named constants of type character with a length parameter of one. The 14 kind parameter value shall be equal to the value of C CHAR unless C CHAR = -1, in which case the 15 kind parameter value shall be the same as for default kind. The values of these constants are specified 16 in Table 15.1. In the case that C CHAR = -1 the value is specified using C syntax. The semantics of 17 these values are explained in 5.2.1 and 5.2.2 of the C International Standard. 18 Table 15.1: Names of C characters with sp ecial semantics Value C CHAR = -1 C CHAR = -1 Name C definition 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' 472 2006/07/11 WORKING DRAFT J3/06-007 NOTE 15.3 The value of NEW LINE(C NEW LINE) is C NEW LINE (13.7.127). The entities C PTR and C FUNPTR are described in 15.3.3. 1 The entity C NULL PTR shall be a named constant of type C PTR. The value of C NULL PTR shall 2 be the same as the value NULL in C. The entity C NULL FUNPTR shall be a named constant of type 3 C FUNPTR. The value of C NULL FUNPTR shall be that of a null pointer to a function in C. 4 15.2.3 Pro cedures in the module 5 In the detailed descriptions below, procedure names are generic and not specific. 6 A C procedure argument is often defined in terms of a C address. The C LOC and C FUNLOC 7 functions are provided so that Fortran applications can determine the appropriate value to use with C 8 facilities. The C ASSOCIATED function is provided so that Fortran programs can compare C addresses. 9 The C F POINTER and C F PROCPOINTER subroutines provide a means of associating a Fortran 10 pointer with the target of a C pointer. 11 15.2.3.1 C ASSOCIATED (C PTR 1 [, C PTR 2]) 12 Description. Indicates the association status of C PTR 1 or indicates whether C PTR 1 and 13 C PTR 2 are associated with the same entity. 14 Class. Inquiry function. 15 Arguments. 16 C PTR 1 shall be a scalar of type C PTR or C FUNPTR. 17 C PTR 2 shall be a scalar of the same type as C PTR 1. 18 (optional) Result Characteristics. Default logical scalar. 19 Result Value. 20 Case (i): If C PTR 2 is absent, the result is false if C PTR 1 is a C null pointer and true 21 otherwise. 22 Case (ii): If C PTR 2 is present, the result is false if C PTR 1 is a C null pointer. Otherwise, 23 the result is true if C PTR 1 compares equal to C PTR 2 in the sense of 6.3.2.3 24 and 6.5.9 of the C International Standard, and false otherwise. 25 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 473 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 15.4 (cont.) 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]) 1 Description. Associates a data pointer with the target of a C pointer and specifies its shape. 2 Class. Subroutine. 3 Arguments. 4 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 ar- 5 gument. The value of CPTR shall not be the C address of a Fortran variable that does 6 not have the TARGET attribute. FPTR shall be a pointer. 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 noninter- operable 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 statement since the reference. FPTR 7 becomes pointer associated with X or its target. SHAPE shall be of type integer and rank one. It is an INTENT(IN) argument. (optional) SHAPE shall be present if and only if FPTR is an array; its size shall be 8 equal to the rank of FPTR. 15.2.3.3 C F PROCPOINTER (CPTR, FPTR) 9 Description. Associates a procedure pointer with the target of a C function pointer. 10 Class. Subroutine. 11 Arguments. 12 CPTR shall be a scalar of type C FUNPTR. It is an INTENT(IN) argument. Its 13 value shall be the C address of a procedure that is interoperable. 474 2006/07/11 WORKING DRAFT J3/06-007 FPTR shall be a procedure pointer. It is an INTENT(OUT) argument. The interface for FPTR shall be interoperable with the prototype that describes the target 1 of CPTR. FPTR becomes pointer associated with 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) 2 Description. Returns the C address of the argument. 3 Class. Inquiry function. 4 Argument. X shall either be a procedure that is interoperable, or a procedure pointer associ- 5 ated with an interoperable procedure. 6 Result Characteristics. Scalar of type C FUNPTR. 7 Result Value. 8 The result value is described using the result name CPTR. The result is determined as if 9 C FUNPTR were a derived type containing an implicit-interface procedure pointer component 10 PX and the pointer assignment CPTR%PX => X were executed. 11 The result is a value that can be used as an actual CPTR argument in a call to C F PROC- 12 POINTER where FPTR has attributes that would allow the pointer assignment FPTR => X. 13 Such a call to C F PROCPOINTER shall have the effect of the pointer assignment FPTR => 14 X. 15 15.2.3.5 C LOC (X) 16 Description. Returns the C address of the argument. 17 Class. Inquiry function. 18 Argument. X shall either 19 (1) have interoperable type and type parameters and be 20 (a) a variable that has the TARGET attribute and is interoperable, 21 (b) an allocated allocatable variable that has the TARGET attribute and is not an array 22 of zero size, or 23 (c) an associated scalar pointer, or 24 (2) be a nonpolymorphic scalar, have no length type parameters, and be 25 (a) a nonallocatable, nonpointer variable that has the TARGET attribute, 26 (b) an allocated allocatable variable that has the TARGET attribute, or 27 (c) an associated pointer. 28 Result Characteristics. Scalar of type C PTR. 29 Result Value. 30 The result value is described using the result name CPTR. 31 If X is a scalar data entity, the result is determined as if C PTR were a derived type containing a scalar 32 475 J3/06-007 WORKING DRAFT 2006/07/11 pointer component PX of the type and type parameters of X and the pointer assignment CPTR%PX 1 => X were executed. 2 If X is an array data entity, the result is determined as if C PTR were a derived type containing a scalar 3 pointer component PX of the type and type parameters of X and the pointer assignment of CPTR%PX 4 to the first element of X were executed. 5 If X is a data entity that is interoperable or has interoperable type and type parameters, the 6 result is the value that the C processor returns as the result of applying the unary "&" operator 7 (as defined in the C International Standard, 6.5.3.2) to the target of CPTR%PX. 8 The result is a value that can be used as an actual CPTR argument in a call to C F POINTER 9 where FPTR has attributes that would allow the pointer assignment FPTR => X. Such a call 10 to C F POINTER shall have the effect of the pointer assignment FPTR => X. 11 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) 12 Description. Returns the size of X in bytes. 13 Class. Inquiry function. 14 Argument. X shall be an interoperable data entity that is not an assumed-size array. 15 Result Characteristics. Scalar integer of kind C SIZE T (15.3.2). 16 Result Value. 17 If X is scalar, the result value is the value that the C processor returns as the result of applying 18 the sizeof operator (C International Standard, subclause 6.5.3.4) to an ob ject of a type that 19 interoperates with the type and type parameters of X. 20 If X is an array, the result value is the value that the C processor returns as the result of applying 21 the sizeof operator to an ob ject of a type that interoperates with the type and type parameters of X, 22 multiplied by the number of elements in X. 23 15.3 Interoperability between Fortran and C entities 24 15.3.1 General 25 Subclause 15.3 define the conditions under which a Fortran entity is interoperable. If a Fortran entity 26 is interoperable, an equivalent entity may be defined by means of C and the Fortran entity is said to be 27 interoperable with the C entity. There does not have to be such an interoperating C entity. 28 476 2006/07/11 WORKING DRAFT J3/06-007 NOTE 15.7 A Fortran entity can be interoperable with more than one C entity. 15.3.2 Interop erability of intrinsic typ es 1 Table 15.2 shows the interoperability between Fortran intrinsic types and C types. A Fortran intrinsic 2 type with particular type parameter values is interoperable with a C type if the type and kind type 3 parameter value are listed in the table on the same row as that C type; if the type is character, inter- 4 operability also requires that the length type parameter be omitted or be specified by an initialization 5 expression whose value is one. A combination of Fortran type and type parameters that is interoperable 6 with a C type listed in the table is also interoperable with any unqualified C type that is compatible 7 with the listed C type. 8 The second column of the table refers to the named constants made accessible by the ISO C BINDING 9 intrinsic module. If the value of any of these named constants is negative, there is no combination of 10 Fortran type and type parameters interoperable with the C type shown in that row. 11 A combination of intrinsic type and type parameters is interop erable if it is interoperable with a C 12 type. 13 Table 15.2: Interop erability b etween Fortran and C typ es Named constant from the ISO C BINDING module C type Fortran type (kind type parameter if value is positive) int C INT short int C SHORT long int C LONG long long int C LONG LONG signed char C SIGNED CHAR unsigned char size t C SIZE T int8 t C INT8 T int16 t C INT16 T int32 t C INT32 T int64 t C INT64 T int least8 t C INT LEAST8 T int least16 t C INT LEAST16 T int least32 t C INT LEAST32 T int least64 t INTEGER C INT LEAST64 T int fast8 t C INT FAST8 T int fast16 t C INT FAST16 T int fast32 t C INT FAST32 T int fast64 t C INT FAST64 T intmax t C INTMAX T intptr t C INTPTR T float C FLOAT double REAL C DOUBLE long double C LONG DOUBLE float Complex C FLOAT COMPLEX 477 J3/06-007 WORKING DRAFT 2006/07/11 Interop erability b etween Fortran and C typ es (cont.) Named constant from the ISO C BINDING module C type Fortran type (kind type parameter if value is positive) double Complex COMPLEX C DOUBLE COMPLEX long double Complex C LONG DOUBLE COMPLEX Bool LOGICAL C BOOL unsigned int or int C UINT unsigned short or short C USHORT unsigned long or long C ULONG unsigned long long C ULONG LONG long long unsigned char C UNSIGNED CHAR signed char uint8 t or int8 t C UINT8 T uint16 t or int16 t C UINT16 T uint32 t or int32 t C UINT32 T uint64 t or int64 t C UINT64 T uint least8 t C UINT LEAST8 T int least8 t uint least16 t C UINT LEAST16 T int least16 t uint least32 t C UINT LEAST32 T int least32 t uint least64 t BITS C UINT LEAST64 T int least64 t uint fast8 t or int fast8 t C UINT FAST8 T uint fast16 t C UINT FAST16 T int fast16 t uint fast32 t C UINT FAST32 T int fast32 t uint fast64 t C UINT FAST64 T int fast64 t uintmax t or intmax t C UINTMAX T uintptr t or intptr t C UINTPTR T float C FLOAT BITS double C DOUBLE BITS long double C LONG DOUBLE BITS float Complex C FLOAT COMPLEX BITS double Complex C DOUBLE COMPLEX BITS long double Complex C LONG DOUBLE COMPLEX BITS Bool C BOOL BITS char CHARACTER C CHAR The above mentioned C types are defined in the C International Standard, subclauses 6.2.5, 7.17, and 7.18.1. 478 2006/07/11 WORKING DRAFT J3/06-007 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. Because Fortran does not provide direct support for unsigned kinds of integers, the ISO C BINDING module does not make accessible named constants for their kind type parameter values. Instead 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 Interop erability with C pointer typ es 1 C PTR and C FUNPTR shall be derived types with only private components. C PTR is interoperable 2 with any C ob ject pointer type. C FUNPTR is interoperable with any C function pointer type. 3 NOTE 15.11 This implies that a C processor is required to have the same representation method for all C ob ject 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. 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. 479 J3/06-007 WORKING DRAFT 2006/07/11 15.3.4 Interop erability of derived types and C struct types 1 A Fortran derived type is interop erable if it has the BIND attribute. 2 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 C1505 (R430) Each component of a derived type with the BIND attribute shall be a nonpointer, 7 nonallocatable data component with interoperable type and type parameters. 8 NOTE 15.13 The syntax rules and their constraints require that a derived type that is interoperable have components that are all data ob jects 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. A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran 9 type specifies BIND(C) (4.5.2), the Fortran derived type and the C struct type have the same number 10 of components, and the components of the Fortran derived type have types and type parameters that 11 are interoperable with the types of the corresponding components of the struct type. A component of 12 a Fortran derived type and a component of a C struct type correspond if they are declared in the same 13 relative position in their respective type definitions. 14 NOTE 15.14 The names of the corresponding components of the derived type and the C struct type need not be the same. There is no Fortran type that is interoperable with a C struct type that contains a bit field or that 15 contains a flexible array member. There is no Fortran type that is interoperable with a C union type. 16 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 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. 480 2006/07/11 WORKING DRAFT J3/06-007 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 sequence derived types are considered to be the same 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 Interop erability of scalar variables 1 A scalar Fortran variable is interop erable if its type and type parameters are interoperable and it has 2 neither the pointer nor the allocatable attribute. 3 An interoperable scalar Fortran variable is interoperable with a scalar C entity if their types and type 4 parameters are interoperable. 5 15.3.6 Interop erability of array variables 6 An array Fortran variable is interop erable if its type and type parameters are interoperable and it is 7 of explicit shape or assumed size. 8 e i . . . er An explicit-shape or assumed-size array of rank r, with a shape of s interoperable with 9 1 a C array if its size is nonzero and 10 (1) either 11 (a) the array is assumed size, and the C array does not specify a size, or 12 (b) the array is an explicit shape array, and the extent of the last dimension (er ) is the 13 same as the size of the C array, and 14 (2) either 15 (a) r is equal to one, and an element of the array is interoperable with an element of the 16 C array, or 17 e , . . . er-1 (b) r is greater than one, and an explicit-shape array with shape of 18 1 with the same type and type parameters as the original array, is interoperable with a 19 C array of a type equal to the element type of the original C array. 20 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 A polymorphic, allocatable, or pointer array is never interoperable. Such arrays are not explicit shape or assumed size. 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] 481 J3/06-007 WORKING DRAFT 2006/07/11 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.1.8) 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 Interop erability of procedures and pro cedure interfaces 1 A Fortran procedure is interop erable if it has the BIND attribute, that is, if its interface is specified 2 with a proc-language-binding-spec . 3 A Fortran procedure interface is interoperable with a C function prototype if 4 (1) the interface has the BIND attribute, 5 (2) either 6 (a) the interface describes a function whose result variable is a scalar that is interoperable 7 with the result of the prototype or 8 (b) the interface describes a subroutine and the prototype has a result type of void, 9 (3) the number of dummy arguments of the interface is equal to the number of formal parameters 10 of the prototype, 11 (4) any dummy argument with the VALUE attribute is interoperable with the corresponding 12 formal parameter of the prototype, 13 (5) any dummy argument without the VALUE attribute corresponds to a formal parameter 14 of the prototype that is of a pointer type, and the dummy argument is interoperable with 15 an entity of the referenced type (C International Standard, 6.2.5, 7.17, and 7.18.1) of the 16 formal parameter, and 17 (6) the prototype does not have variable arguments as denoted by the ellipsis (...). 18 NOTE 15.21 The referenced typ e of a C pointer type is the C type of the ob ject 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 standard does not provide a mechanism for Fortran procedures to interoperate with such C functions. A formal parameter of a C function prototype corresponds to a dummy argument of a Fortran interface if 19 they are in the same relative positions in the C parameter list and the dummy argument list, respectively. 20 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 482 2006/07/11 WORKING DRAFT J3/06-007 NOTE 15.23 (cont.) 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 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) :: & & 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 483 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 15.24 (cont.) 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.1.8). 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 15.4.1 General 2 A C variable with external linkage may interoperate with a common block or with a variable declared 3 in the scope of a module. The common block or variable shall be specified to have the BIND attribute. 4 At most one variable that is associated with a particular C variable with external linkage is permitted 5 to be declared within a program. A variable shall not be initially defined by more than one processor. 6 If a common block is specified in a BIND statement, it shall be specified in a BIND statement with 7 the same binding label in each scoping unit in which it is declared. A C variable with external linkage 8 interoperates with a common block that has been specified in a BIND statement 9 (1) if the C variable is of a struct type and the variables that are members of the common block 10 are interoperable with corresponding components of the struct type, or 11 (2) if the common block contains a single variable, and the variable is interoperable with the C 12 variable. 13 There does not have to be an associated C entity for a Fortran entity with the BIND attribute. 14 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/ COMMON /SINGLE/ T END MODULE LINK_TO_C_VARS int c_extern; long myVariable; struct {float r, s;} com; float single; 484 2006/07/11 WORKING DRAFT J3/06-007 15.4.2 Binding lab els for common blocks and variables 1 The binding lab el of a variable or common block is a value of type default character that specifies the 2 name by which the variable or common block is known to the companion processor. 3 If a variable or common block has the BIND attribute with the NAME= specifier and the value of its 4 expression, after discarding leading and trailing blanks, has nonzero length, the variable or common 5 block has this as its binding label. The case of letters in the binding label is significant. If a variable 6 or common block has the BIND attribute specified without a NAME= specifier, the binding label is the 7 same as the name of the entity using lower case letters. Otherwise, the variable of common block has 8 no binding label. 9 The binding label of a C variable with external linkage is the same as the name of the C variable. A 10 Fortran variable or common block with the BIND attribute that has the same binding label as a C 11 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 interop erable procedures 14 A procedure that is interoperable may be defined either by means other than Fortran or by means of a 15 Fortran subprogram, but not both. 16 If the procedure is defined by means other than Fortran, it shall 17 (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 A reference to such a procedure causes the function described by the C prototype to be called as specified 21 in the C International Standard. 22 A reference in C to a procedure that has the BIND attribute, has the same binding label, and is defined 23 by means of Fortran, causes the Fortran procedure to be invoked. 24 A procedure defined by means of Fortran shall not invoke setjmp or longjmp (C International Standard, 25 7.13). If a procedure defined by means other than Fortran invokes setjmp or longjmp, that procedure 26 shall not cause any procedure defined by means of Fortran to be invoked. A procedure defined by means 27 of Fortran shall not be invoked as a signal handler (C International Standard, 7.14.1). 28 If a procedure defined by means of Fortran and a procedure defined by means other than Fortran perform 29 input/output operations on the same external file, the results are processor dependent (9.4.3). 30 15.5.2 Binding lab els for pro cedures 31 The binding lab el of a procedure is a value of type default character that specifies the name by which 32 a procedure with the BIND attribute is known to the companion processor. 33 If a procedure has the BIND attribute with the NAME= specifier and the value of its expression, after 34 discarding leading and trailing blanks, has nonzero length, the procedure has this as its binding label. 35 The case of letters in the binding label is significant. If a procedure has the BIND attribute with no 36 NAME= specifier, and the procedure is not a dummy procedure or procedure pointer, then the binding 37 label of the procedure is the same as the name of the procedure using lower case letters. Otherwise, the 38 485 J3/06-007 WORKING DRAFT 2006/07/11 procedure has no binding label. 1 C1506 A procedure defined in a submodule shall not have a binding label unless its interface is declared 2 in the ancestor module. 3 The binding label for a C function with external linkage is the same as the C function name. 4 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 5 A procedure defined by means other than Fortran shall not use signal (C International Standard, 7.14.1) 6 to change the handling of any exception that is being handled by the Fortran processor. 7 A procedure defined by means other than Fortran shall not alter the floating point status (14.6) other 8 than by setting an exception flag to signaling. 9 The values of the floating point exception flags on entry to a procedure defined by means other than 10 Fortran are processor-dependent. 11 486 2006/07/11 WORKING DRAFT J3/06-007 16 Scope, asso ciation, and definition 1 16.1 Identifiers and entities 2 Entities are identified by identifiers within a scop e that is a program, a scoping unit, a construct, a 3 single statement, or part of a statement. 4 · A global identifier has a scope of a program (2.2.1); 5 · A lo cal identifier has a scope of a scoping unit (2.2); 6 · An identifier of a construct entity has a scope of a construct (7.4.3, 7.4.4, 8.1); 7 · An identifier of a statement entity has a scope of a statement or part of a statement (3.3). 8 An entity may be identified by 9 (1) a name (3.2.1), 10 (2) a statement label (3.2.4), 11 (3) an external input/output unit number (9.4), 12 (4) an identifier of a pending data transfer operation (9.5.1.8, 9.6), 13 (5) a submodule identifier (11.2.2), 14 (6) a generic identifier (12.4.2.1), or 15 (7) a binding label (15.5.2, 15.4.2). 16 By means of association, an entity may be referred to by the same identifier or a different identifier in 17 a different scoping unit, or by a different identifier in the same scoping unit. 18 16.2 Scope of global identifiers 19 Program units, common blocks, external procedures, and entities with binding labels are global entities 20 of a program. The name of a non-submodule program unit, common block, or external procedure is 21 a global identifier and shall not be the same as the name of any other such global entity in the same 22 program, except that an intrinsic module may have the same name as another program unit, common 23 block, or external procedure in the same program. The submodule identifier of a submodule is a global 24 identifier and shall not be the same as the submodule identifier of any other submodule. A binding 25 label of an entity of the program is a global identifier and shall not be the same as the binding label of 26 any other entity of the program; nor shall it be the same as the name of any other global entity of the 27 program that is not an intrinsic module, ignoring differences in case. An entity of the program shall not 28 be identified by more than one binding label. 29 NOTE 16.1 The name of a global entity may be the same as a binding label that identifies the same global entity. 487 J3/06-007 WORKING DRAFT 2006/07/11 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 lo cal identifiers 2 16.3.1 Classes of local identifiers 3 Within a scoping unit, identifiers of entities in the classes 4 (1) named variables that are not statement or construct entities (16.4), named constants, named 5 constructs, statement functions, internal procedures, module procedures, dummy procedures, 6 intrinsic procedures, abstract interfaces, module procedure interfaces, generic interfaces, de- 7 rived types, namelist groups, external procedures accessed via USE, macros, and statement 8 labels, 9 (2) type parameters, components, and type-bound procedure bindings, in a separate class for 10 each type, and 11 (3) argument keywords, in a separate class for each procedure with an explicit interface 12 are local identifiers in that scoping unit. 13 Within a scoping unit, a local identifier of an entity of class (1) shall not be the same as a global identifier 14 used in that scoping unit unless the global identifier 15 (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 Within a scoping unit, a local identifier of one class shall not be the same as another local identifier of 20 the same class, except that a generic name may be the same as the name of a procedure as explained 21 in 12.4.2.1 or the same as the name of a derived type (4.5.10), and a separate module procedure shall 22 have the same name as its corresponding module procedure interface body (12.6.2.4). A local identifier 23 of one class may be the same as a local identifier of another class. 24 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 488 2006/07/11 WORKING DRAFT J3/06-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. A local identifier identifies an entity in a scoping unit and may be used to identify an entity in another 1 scoping unit except in the following cases. 2 (1) The name that appears as a subroutine-name in a subroutine-stmt has limited use within 3 the scope established by the subroutine-stmt . It can be used to identify recursive references 4 of the subroutine or to identify a common block (the latter is possible only for internal and 5 module subroutines). 6 (2) The name that appears as a function-name in a function-stmt has limited use within the 7 scope established by that function-stmt . It can be used to identify the result variable, to 8 identify recursive references of the function, or to identify a common block (the latter is 9 possible only for internal and module functions). 10 (3) The name that appears as an entry-name in an entry-stmt has limited use within the scope 11 of the subprogram in which the entry-stmt appears. It can be used to identify the result 12 variable if the subprogram is a function, to identify recursive references, or to identify a 13 common block (the latter is possible only if the entry-stmt is in a module subprogram). 14 16.3.2 Local identifiers that are the same as common block names 15 A name that identifies a common block in a scoping unit shall not be used to identify a constant or an 16 intrinsic procedure in that scoping unit. If a local identifier is also the name of a common block, the 17 appearance of that name in any context other than as a common block name in a COMMON or SAVE 18 statement is an appearance of the local identifier. 19 NOTE 16.5 An intrinsic procedure name may be a common block name in a scoping unit that does not reference the intrinsic procedure. 16.3.3 Function results 20 For each FUNCTION statement or ENTRY statement in a function subprogram, there is a result 21 variable. If there is no RESULT clause, the result variable has the same name as the function being 22 defined; otherwise, the result variable has the name specified in the RESULT clause. 23 16.3.4 Restrictions on generic declarations 24 This subclause contains the rules that shall be satisfied by every pair of specific procedures that have 25 the same generic identifier within a scoping unit. If a generic procedure is accessed from a module, the 26 489 J3/06-007 WORKING DRAFT 2006/07/11 rules apply to all the specific versions even if some of them are inaccessible by their specific names. 1 NOTE 16.6 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 ob jects in that scoping unit. In a type definition, they are the generic bindings, including those from a parent type. Two dummy arguments are distinguishable if neither is a subroutine and neither is TKR compatible 2 (4.3.1.3) with the other. 3 Within a scoping unit, if two procedures have the same generic operator and the same number of 4 arguments or both define assignment, one shall have a dummy argument that corresponds by position 5 in the argument list to a dummy argument of the other that is distinguishable with it. 6 Within a scoping unit, if two procedures have the same dtio-generic-spec (12.4.2.1), their dtv arguments 7 shall be type incompatible or have different kind type parameters. 8 Within a scoping unit, two procedures that have the same generic name shall both be subroutines or 9 both be functions, and 10 (1) there is a non-passed-ob ject dummy data ob ject in one or the other of them such that 11 (a) the number of dummy data ob jects in one that are nonoptional, are not passed-ob ject, 12 and with which that dummy data ob ject is TKR compatible, possibly including that 13 dummy data ob ject itself, 14 exceeds 15 (b) the number of non-passed-ob ject dummy data ob jects, both optional and nonoptional, 16 in the other that are not distinguishable with that dummy data ob ject, 17 (2) both have passed-ob ject dummy arguments and the passed-ob ject dummy arguments are 18 distinguishable, or 19 (3) at least one of them shall have both 20 (a) a nonoptional non-passed-ob ject dummy argument at an effective position such that 21 either the other procedure has no dummy argument at that effective position or the 22 dummy argument at that position is distinguishable with it, and 23 (b) a nonoptional non-passed-ob ject dummy argument whose name is such that either the 24 other procedure has no dummy argument with that name or the dummy argument 25 with that name is distinguishable with it. 26 and the dummy argument that disambiguates by position shall either be the same as or 27 occur earlier in the argument list than the one that disambiguates by name. 28 The effective p osition of a dummy argument is its position in the argument list after any passed-ob ject 29 dummy argument has been removed. 30 Within a scoping unit, if a generic name is the same as the name of a generic intrinsic procedure, the 31 generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure 32 are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure 33 from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the 34 interface that is referenced. 35 NOTE 16.7 An extensive explanation of the application of these rules is in C.12.2. 490 2006/07/11 WORKING DRAFT J3/06-007 16.3.5 Components, typ e parameters, and bindings 1 A component name has the scope of its derived-type definition. Outside the type definition, it may 2 appear only within a designator of a component of a structure of that type or as a component keyword 3 in a structure constructor for that type. 4 A type parameter name has the scope of its derived-type definition. Outside the derived-type definition, 5 it may appear only as a type parameter keyword in a derived-type-spec for the type or as the type-param- 6 name of a type-param-inquiry . 7 The binding name (4.5.5)of a type-bound procedure has the scope of its derived-type definition. Outside 8 of the derived-type definition, it may appear only as the binding-name in a procedure reference. 9 A generic binding for which the generic-spec is not a generic-name has a scope that consists of all scoping 10 units in which an entity of the type is accessible. 11 A component name or binding name may appear only in scoping units in which it is accessible. 12 The accessibility of components and bindings is specified in 4.5.4.7 and 4.5.5. 13 16.3.6 Argument keywords 14 As an argument keyword, a dummy argument name in an internal procedure, module procedure, or 15 an interface body has a scope of the scoping unit of the host of the procedure or interface body. It 16 may appear only in a procedure reference for the procedure of which it is a dummy argument. If the 17 procedure or interface body is accessible in another scoping unit by use association or host association 18 (16.5.1.3, 16.5.1.4), the argument keyword is accessible for procedure references for that procedure in 19 that scoping unit. 20 A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping 21 unit in which the reference to the procedure occurs. As an argument keyword, it may appear only in a 22 procedure reference for the procedure of which it is a dummy argument. 23 16.4 Statement and construct entities 24 A variable that appears as a data-i-do-variable in a DATA statement or an ac-do-variable in an array 25 constructor, as a dummy argument in a statement function statement, or as an index-name in a FORALL 26 statement is a statement entity. A variable that appears as an index-name in a FORALL or DO 27 CONCURRENT construct or as an associate-name in a SELECT TYPE or ASSOCIATE construct is 28 a construct entity. A macro local variable is a construct entity. An entity that is declared in a BLOCK 29 construct and is not accessed by use association is a construct entity. 30 If a global or local identifier is the same as that of a construct entity, the identifier is interpreted within 31 the construct as that of the construct entity. Elsewhere in the scoping unit, the identifier is interpreted 32 as the global or local identifier. 33 If a global or local identifier accessible in the scoping unit of a statement is the same as the name of a 34 statement entity in that statement, the name is interpreted within the scope of the statement entity as 35 that of the statement entity. Elsewhere in the scoping unit, including parts of the statement outside the 36 scope of the statement entity, the name is interpreted as the global or local identifier. 37 If the name of a statement entity is the same as the name of a construct entity and the statement is 38 within the scope of the construct entity, the name is interpreted within the scope of the statement entity 39 as that of the statement entity. Elsewhere in the construct, including parts of the statement outside the 40 scope of the statement entity, the name is interpreted as that of the construct entity. 41 491 J3/06-007 WORKING DRAFT 2006/07/11 Except for a common block name or a scalar variable name, a global identifier or a local identifier of 1 class (1) (16.3) in the scoping unit that contains a statement shall not be the name of a statement entity 2 of that statement. Within the scope of a statement entity, another statement entity shall not have the 3 same name. 4 The name of a data-i-do-variable in a DATA statement or an ac-do-variable in an array constructor 5 has a scope of its data-implied-do or ac-implied-do . It is a scalar variable that has the type and type 6 parameters that it would have if it were the name of a variable in the scoping unit that includes the 7 DATA statement or array constructor, and this type shall be integer type; it has no other attributes. 8 The appearance of a name as a data-i-do-variable of an implied DO in a DATA statement or an ac-do- 9 variable in an array constructor is not an implicit declaration of a variable whose scope is the scoping 10 unit that contains the statement. 11 The name of a variable that appears as an index-name in a FORALL statement or FORALL or DO 12 CONCURRENT construct has a scope of the statement or construct. It is a scalar variable that has the 13 type and type parameters that it would have if it were the name of a variable in the scoping unit that 14 includes the FORALL, and this type shall be integer type; it has no other attributes. The appearance 15 of a name as an index-name in a FORALL statement or FORALL or DO CONCURRENT construct is 16 not an implicit declaration of a variable whose scope is the scoping unit that contains the statement or 17 construct. 18 19 The name of a variable that app ears as a dummy argument in a statement function statement has a scop e of the statement 20 in which it app ears. It is a scalar that has the typ e and typ e parameters that it would have if it were the name of a variable 21 in the scoping unit that includes the statement function; it has no other attributes. Except for a common block name or a scalar variable name, a global identifier or a local identifier of class 22 (1) (16.3) in the scoping unit of a FORALL statement, FORALL construct, or DO CONCURRENT 23 construct shall not be the same as any of its index-name s. An index-name of a contained FORALL 24 statement, FORALL construct, or DO CONCURRENT construct shall not be the same as an index- 25 name of any of its containing FORALL or DO CONCURRENT constructs. 26 The associate name of a SELECT TYPE construct has a separate scope for each block of the construct. 27 Within each block, it has the declared type, dynamic type, type parameters, rank, and bounds specified 28 in 8.1.6.2. 29 The associate names of an ASSOCIATE construct have the scope of the block. They have the declared 30 type, dynamic type, type parameters, rank, and bounds specified in 8.1.5.2. 31 The macro local variables of a macro definition have the scope of the macro definition. 32 16.5 Asso ciation 33 16.5.1 Name asso ciation 34 16.5.1.1 Forms of name asso ciation 35 There are five forms of name asso ciation: argument association, use association, host association, 36 linkage association, and construct association. Argument, use, and host association provide mechanisms 37 by which entities known in one scoping unit may be accessed in another scoping unit. 38 16.5.1.2 Argument asso ciation 39 The rules governing argument association are given in Clause 12. As explained in 12.5, execution of a 40 procedure reference establishes an association between an actual argument and its corresponding dummy 41 492 2006/07/11 WORKING DRAFT J3/06-007 argument. Argument association may be sequence association (12.5.1.8). 1 The name of the dummy argument may be different from the name, if any, of its associated actual 2 argument. The dummy argument name is the name by which the associated actual argument is known, 3 and by which it may be accessed, in the referenced procedure. 4 NOTE 16.8 An actual argument may be a nameless data entity, such as an expression that is not simply a variable or constant. Upon termination of execution of a procedure reference, all argument associations established by that 5 reference are terminated. A dummy argument of that procedure may be associated with an entirely 6 different actual argument in a subsequent invocation of the procedure. 7 16.5.1.3 Use asso ciation 8 Use asso ciation is the association of names in different scoping units specified by a USE statement. The 9 rules governing use association are given in 11.2.1. They allow for renaming of entities being accessed. 10 Use association allows access in one scoping unit to entities defined in another scoping unit; it remains 11 in effect throughout the execution of the program. 12 16.5.1.4 Host asso ciation 13 An internal subprogram, a module subprogram, a submodule subprogram, a module procedure interface 14 body, or a derived-type definition has access to entities from its host via host asso ciation. An interface 15 body that is not a module procedure interface body has access via host association to the named entities 16 from its host that are made accessible by IMPORT statements in the interface body. The accessed 17 entities are identified by the same identifier and have the same attributes as in the host, except that an 18 accessed entity may have the VOLATILE or ASYNCHRONOUS attribute even if the host entity does 19 not. The accessed entities are named data ob jects, derived types, abstract interfaces, module procedure 20 interfaces, procedures, generic identifiers, macros, and namelist groups. 21 If an entity that is accessed by use association has the same nongeneric name as a host entity, the host 22 entity is inaccessible by that name. Within the scoping unit, a name that is declared to be an external 23 procedure name by an external-stmt , procedure-declaration-stmt , or interface-body , or that appears as a 24 module-name in a use-stmt is a global identifier; any entity of the host that has this as its nongeneric 25 name is inaccessible by that name. A name that appears in the scoping unit as 26 (1) a function-name in a stmt-function-stmt or in an entity-decl in a type-declaration-stmt , 27 (2) an object-name in an entity-decl in a type-declaration-stmt , in a pointer-stmt , in a save-stmt , 28 in an al locatable-stmt , or in a target-stmt , 29 (3) a type-param-name in a derived-type-stmt , 30 (4) a named-constant in a named-constant-def in a parameter-stmt , 31 (5) an array-name in a dimension-stmt , 32 (6) a variable-name in a common-block-object in a common-stmt , 33 (7) a proc-pointer-name in a common-block-object in a common-stmt , 34 (8) the name of a variable that is wholly or partially initialized in a data-stmt , 35 (9) the name of an ob ject that is wholly or partially equivalenced in an equivalence-stmt , 36 (10) a dummy-arg-name in a function-stmt , in a subroutine-stmt , in an entry-stmt , or in a stmt- 37 function-stmt , 38 (11) a result-name in a function-stmt or in an entry-stmt , 39 (12) the name of an entity declared by an interface body, 40 493 J3/06-007 WORKING DRAFT 2006/07/11 (13) an intrinsic-procedure-name in an intrinsic-stmt , 1 (14) a namelist-group-name in a namelist-stmt , 2 (15) the name of a macro in a define-macro-stmt , 3 (16) a generic-name in a generic-spec in an interface-stmt , or 4 (17) the name of a named construct 5 is a local identifier in the scoping unit and any entity of the host that has this as its nongeneric name is 6 inaccessible by that name by host association. If a scoping unit is the host of a derived-type definition 7 or a subprogram that does not define a separate module procedure, the name of the derived type or of 8 any procedure defined by the subprogram is a local identifier in the scoping unit; any entity of the host 9 that has this as its nongeneric name is inaccessible by that name. Local identifiers of a subprogram are 10 not accessible to its host. 11 NOTE 16.9 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. If a host entity is inaccessible only because a local variable with the same name is wholly or partially 12 initialized in a DATA statement, the local variable shall not be referenced or defined prior to the DATA 13 statement. 14 If a derived-type name of a host is inaccessible, data entities of that type or subob jects of such data 15 entities still can be accessible. 16 NOTE 16.10 An interface body that is not a module procedure interface body accesses by host association only those entities made accessible by IMPORT statements. If an external or dummy procedure with an implicit interface is accessed via host association, then it 17 shall have the EXTERNAL attribute in the host scoping unit; if it is invoked as a function in the inner 18 scoping unit, its type and type parameters shall be established in the host scoping unit. The type and 19 type parameters of a function with the EXTERNAL attribute are established in a scoping unit if that 20 scoping unit explicitly declares them, invokes the function, accesses the function from a module, or 21 accesses the function from its host where its type and type parameters are established. 22 If an intrinsic procedure is accessed via host association, then it shall be established to be intrinsic in the 23 host scoping unit. An intrinsic procedure is established to be intrinsic in a scoping unit if that scoping 24 unit explicitly gives it the INTRINSIC attribute, invokes it as an intrinsic procedure, accesses it from a 25 module, or accesses it from its host where it is established to be intrinsic. 26 NOTE 16.11 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 494 2006/07/11 WORKING DRAFT J3/06-007 NOTE 16.11 (cont.) PROGRAM A USE B; USE C; USE D ... 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 IN- NER 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.12 For more examples of host association, see subclause C.12.1. 16.5.1.5 Linkage asso ciation 1 Linkage association occurs between a module variable that has the BIND attribute and the C variable 2 with which it interoperates, or between a Fortran common block and the C variable with which it 3 interoperates (15.4). Such association remains in effect throughout the execution of the program. 4 495 J3/06-007 WORKING DRAFT 2006/07/11 16.5.1.6 Construct asso ciation 1 Execution of a SELECT TYPE statement establishes an association between the selector and the asso- 2 ciate name of the construct. Execution of an ASSOCIATE statement establishes an association between 3 each selector and the corresponding associate name of the construct. 4 If the selector is allocatable, it shall be allocated; the associate name is associated with the data ob ject 5 and does not have the ALLOCATABLE attribute. 6 If the selector has the POINTER attribute, it shall be associated; the associate name is associated with 7 the target of the pointer and does not have the POINTER attribute. 8 If the selector is a variable other than an array section having a vector subscript, the association is 9 with the data ob ject specified by the selector; otherwise, the association is with the value of the selector 10 expression, which is evaluated prior to execution of the block. 11 Each associate name remains associated with the corresponding selector throughout the execution of the 12 executed block. Within the block, each selector is known by and may be accessed by the corresponding 13 associate name. Upon termination of the construct, the association is terminated. 14 NOTE 16.13 The association between the associate name and a data ob ject 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 . 16.5.2 Pointer association 15 16.5.2.1 General 16 Pointer association between a pointer and a target allows the target to be referenced by a reference to the 17 pointer. At different times during the execution of a program, a pointer may be undefined, associated 18 with different targets, or be disassociated. If a pointer is associated with a target, the definition status 19 of the pointer is either defined or undefined, depending on the definition status of the target. If the 20 pointer has deferred type parameters or shape, their values are assumed from the target. If the pointer 21 is polymorphic, its dynamic type is the dynamic type of the target. 22 16.5.2.2 Pointer asso ciation status 23 A pointer may have a p ointer asso ciation status of associated, disassociated, or undefined. Its 24 association status may change during execution of a program. Unless a pointer is initialized (explicitly 25 or by default), it has an initial association status of undefined. A pointer may be initialized to have an 26 association status of disassociated or associated. 27 NOTE 16.14 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 standard 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. 496 2006/07/11 WORKING DRAFT J3/06-007 16.5.2.2.1 Events that cause p ointers to b ecome asso ciated 1 A pointer becomes associated when any of the following events occur. 2 · The pointer is allocated (6.3.1) as the result of the successful execution of an ALLOCATE statement 3 referencing the pointer. 4 · The pointer is pointer-assigned to a target (7.4.2) that is associated or is specified with the TAR- 5 GET attribute and, if allocatable, is allocated. 6 · A nonpointer scalar ob ject of type bits with a kind type parameter that is an integer multiple, N, 7 of the size of a numeric storage unit occupies N contiguous numeric storage units. The ordering of 8 these consecutive numeric storage units is processor dependent. A nonpointer scalar ob ject of type 9 bits with a kind type parameter that is not an integer multiple of the size of a numeric storage 10 unit occupies an unspecified storage unit that is different for each such kind value. 11 J3 internal note Unresolved Technical Issue 75 The "ordering" sentence is trying to say something subtle about endianness. X(1)//X(2) gives the same result on all machines, but whether when that is stored X(1) or X(2) occurs first is processor (endian) dependent. This should be reworded as the technical effect in the user program, which is maybe only visible as BITS X(2) BITS(KIND(X)*2) Y,ZLE,ZBE ... X = TRANSFER(Y,X) ZLE = X(1)//X(2) ZBE = X(2)//X(1) ... ! On some processors Y==ZLE, and on other processors Y==ZBE. ! Inconceivably, it might differ from both. · The pointer is a dummy argument and its corresponding actual argument is not a pointer. 12 · The pointer is an ultimate component of an ob ject of a type for which default initialization is 13 specified for the component, and the corresponding initializer is an initialization target, and 14 ­ a procedure is invoked with this ob ject as an actual argument corresponding to a nonpointer 15 nonallocatable dummy argument with INTENT (OUT), 16 ­ a procedure with this ob ject as an unsaved nonpointer nonallocatable local ob ject that is not 17 accessed by use or host association is invoked, or 18 ­ this ob ject is allocated. 19 J3 internal note Unresolved Technical Issue 76 Does defining a bits storage unit associated with a numeric storage unit define the numeric value? Presumably not. What about the other way round? Maybe, but no words to support that. How does this interact with argument association - since the types are different, defining the dummy isn't going to define the actual! 497 J3/06-007 WORKING DRAFT 2006/07/11 16.5.2.2.2 Events that cause p ointers to b ecome disasso ciated 1 A pointer becomes disassociated when 2 (1) the pointer is nullified (6.3.2), 3 (2) the pointer is deallocated (6.3.3), 4 (3) the pointer is pointer-assigned (7.4.2) to a disassociated pointer, or 5 (4) the pointer is an ultimate component of an ob ject of a type for which default initialization is 6 specified for the component, and the corresponding initializer is a reference to the intrinsic 7 function NULL, and 8 ·a procedure is invoked with this ob ject as an actual argument corresponding to a 9 nonpointer nonallocatable dummy argument with INTENT (OUT), 10 ·a procedure with this ob ject as an unsaved nonpointer nonallocatable local ob ject 11 that is not accessed by use or host association is invoked, or 12 ·this ob ject is allocated. 13 16.5.2.2.3 Events that cause the asso ciation status of p ointers to b ecome undefined 14 The association status of a pointer becomes undefined when 15 (1) the pointer is pointer-assigned to a target that has an undefined association status, 16 (2) the target of the pointer is deallocated other than through the pointer, 17 (3) the allocation transfer procedure (13.7.124) is executed, the pointer is associated with the 18 argument FROM, and an ob ject without the target attribute associated with the argument 19 TO, 20 (4) execution of a RETURN or END statement causes the pointer's target to become undefined 21 (item (3) of 16.6.6), 22 (5) execution of the host instance of a procedure pointer is completed by execution of a RE- 23 TURN or END statement, 24 (6) a procedure is terminated by execution of a RETURN or END statement and the pointer 25 is declared or accessed in the subprogram that defines the procedure unless the pointer 26 (a) has the SAVE attribute, 27 (b) is in blank common, 28 (c) is in a named common block that appears in at least one other scoping unit that is 29 in execution, 30 (d) is in the scoping unit of a module if the module also is accessed by another scoping 31 unit that is in execution, 32 (e) is in the scoping unit of a submodule if any scoping unit in that submodule or any of 33 its descendant submodules is in execution, 34 (f ) is accessed by host association, or 35 (g) is the return value of a function declared to have the POINTER attribute, 36 (7) the pointer is an ultimate component of an ob ject, default initialization is not specified 37 for the component, and a procedure is invoked with this ob ject as an actual argument 38 corresponding to a dummy argument with INTENT(OUT), or 39 (8) a procedure is invoked with the pointer as an actual argument corresponding to a pointer 40 dummy argument with INTENT(OUT). 41 16.5.2.2.4 Other events that change the asso ciation status of p ointers 42 When a pointer becomes associated with another pointer by argument association, construct association, 43 or host association, the effects on its association status are specified in 16.5.5. 44 498 2006/07/11 WORKING DRAFT J3/06-007 While two pointers are name associated, storage associated, or inheritance associated, if the association 1 status of one pointer changes, the association status of the other changes accordingly. 2 16.5.2.3 Pointer definition status 3 The definition status of a pointer is that of its target. If a pointer is associated with a definable target, 4 the definition status of the pointer may be defined or undefined according to the rules for a variable 5 (16.6). 6 16.5.2.4 Relationship b etween asso ciation status and definition status 7 If the association status of a pointer is disassociated or undefined, the pointer shall not be referenced 8 or deallocated. Whatever its association status, a pointer always may be nullified, allocated, or pointer 9 assigned. A nullified pointer is disassociated. When a pointer is allocated, it becomes associated but 10 undefined. When a pointer is pointer assigned, its association and definition status become those of the 11 specified data-target or proc-target . 12 16.5.3 Storage asso ciation 13 16.5.3.1 General 14 Storage sequences are used to describe relationships that exist among variables, common blocks, and 15 result variables. Storage asso ciation is the association of two or more data ob jects that occurs when 16 two or more storage sequences share or are aligned with one or more storage units. 17 16.5.3.2 Storage sequence 18 A storage sequence is a sequence of storage units. The size of a storage sequence is the number 19 of storage units in the storage sequence. A storage unit is a character storage unit, a numeric storage 20 unit, a file storage unit(9.2.4), or an unspecified storage unit. The sizes of the numeric storage unit, the 21 character storage unit and the file storage unit are the value of constants in the ISO FORTRAN ENV 22 intrinsic module (13.8.3). 23 In a storage association context 24 (1) a nonpointer scalar ob ject of type default integer, default real, default logical, or default 25 bits occupies a single numeric storage unit, 26 (2) a nonpointer scalar ob ject of type double precision real or default complex occupies two 27 contiguous numeric storage units, 28 (3) a nonpointer scalar ob ject of type default character and character length len occupies len 29 contiguous character storage units, 30 (4) a nonpointer scalar ob ject of type character with the C character kind (15.2.2) and character 31 length len occupies len contiguous unsp ecified storage units, 32 (5) a nonpointer scalar ob ject of sequence type with no type parameters occupies a sequence of 33 storage sequences corresponding to the sequence of its ultimate components, 34 (6) a nonpointer scalar ob ject of any type not specified in items (1)-(6) occupies a single un- 35 specified storage unit that is different for each case and each set of type parameter values, 36 and that is different from the unspecified storage units of item (4), 37 (7) a nonpointer array occupies a sequence of contiguous storage sequences, one for each array 38 element, in array element order (6.2.2.2), and 39 (8) a pointer occupies a single unspecified storage unit that is different from that of any non- 40 pointer ob ject and is different for each combination of type, type parameters, and rank. A 41 499 J3/06-007 WORKING DRAFT 2006/07/11 pointer that has the CONTIGUOUS attribute occupies a storage unit that is different from 1 that of a pointer that does not have the CONTIGUOUS attribute. 2 A sequence of storage sequences forms a storage sequence. The order of the storage units in such a 3 composite storage sequence is that of the individual storage units in each of the constituent storage 4 sequences taken in succession, ignoring any zero-sized constituent sequences. 5 Each common block has a storage sequence (5.7.2.2). 6 Two ob jects for which the intrinsic function BITS KIND returns the same value occupy the same amount 7 of storage. 8 J3 internal note Unresolved Technical Issue 77 The purpose of the above paragraph here seems to be to promote rampant nonportability. We have always been at liberty to allow this in the past, and we have never done so, because it runs directly counter to our portability goal. This effect is to al low storage association of non-default kinds of integer, real et al. The fact that BITS KIND returns different values on different systems is no consolation to the user who is faced with mysterious failures; even with accurate diagnostics he will face the daunting task of unravelling someone else's nonportable code (and he might not be in a position to unravel it all anyway). NOTE 16.15 A nonpointer nonallocatable scalar BITS ob ject 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 ob ject of the same kind. 16.5.3.3 Asso ciation of storage sequences 9 Two nonzero-sized storage sequences s1 and s2 are storage asso ciated if the ith storage unit of s1 is 10 the same as the j th storage unit of s2 . This causes the (i + k )th storage unit of s1 to be the same as 11 the (j + k )th storage unit of s2 , for each integer k such that 1 i + k size of s1 and 1 j + k 12 size of s2 . 13 Storage association also is defined between two zero-sized storage sequences, and between a zero-sized 14 storage sequence and a storage unit. A zero-sized storage sequence in a sequence of storage sequences is 15 storage associated with its successor, if any. If the successor is another zero-sized storage sequence, the 16 two sequences are storage associated. If the successor is a nonzero-sized storage sequence, the zero-sized 17 sequence is storage associated with the first storage unit of the successor. Two storage units that are 18 each storage associated with the same zero-sized storage sequence are the same storage unit. 19 NOTE 16.16 Zero-sized ob jects 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 ... 500 2006/07/11 WORKING DRAFT J3/06-007 NOTE 16.16 (cont.) 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. 16.5.3.4 Asso ciation of scalar data objects 1 Two scalar data ob jects are storage associated if their storage sequences are storage associated. Two 2 scalar entities are totally asso ciated if they have the same storage sequence. Two scalar entities are 3 partially asso ciated if they are associated without being totally associated. 4 The definition status and value of a data ob ject affects the definition status and value of any storage 5 associated entity. An EQUIVALENCE statement, a COMMON statement, or an ENTRY statement 6 may cause storage association of storage sequences. 7 An EQUIVALENCE statement causes storage association of data ob jects only within one scoping unit, 8 unless one of the equivalenced entities is also in a common block (5.7.1.2 and 5.7.2.2). 9 COMMON statements cause data ob jects in one scoping unit to become storage associated with data 10 ob jects in another scoping unit. 11 A common block is permitted to contain a sequence of differing storage units. All scoping units that 12 access named common blocks with the same name shall specify an identical sequence of storage units. 13 Blank common blocks may be declared with differing sizes in different scoping units. For any two blank 14 common blocks, the initial sequence of storage units of the longer blank common block shall be identical 15 to the sequence of storage units of the shorter common block. If two blank common blocks are the same 16 length, they shall have the same sequence of storage units. 17 An ENTRY statement in a function subprogram causes storage association of the result variables. 18 Partial association shall exist only between 19 (1) an ob ject of default character or character sequence type and an ob ject of default character 20 or character sequence type, or 21 (2) an ob ject of default complex, double precision real, or numeric sequence type and an ob ject 22 of default integer, default real, default logical, double precision real, default complex, or 23 numeric sequence type. 24 For noncharacter entities, partial association may occur only through the use of COMMON, EQUIV- 25 ALENCE, or ENTRY statements. For character entities, partial association may occur only through 26 argument association or the use of COMMON or EQUIVALENCE statements. 27 NOTE 16.17 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 501 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 16.17 (cont.) 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. Partial association of character entities occurs when some, but not all, of the storage units of the entities 1 are the same. 2 NOTE 16.18 In the example: CHARACTER A*4, B*4, C*3 EQUIVALENCE (A (2:3), B, C) A, B, and C are partially associated. A storage unit shall not be explicitly initialized more than once in a program. Explicit initialization 3 overrides default initialization, and default initialization for an ob ject of derived type overrides default 4 initialization for a component of the ob ject (4.5.2). Default initialization may be specified for a storage 5 unit that is storage associated provided the ob jects supplying the default initialization are of the same 6 type and type parameters, and supply the same value for the storage unit. 7 16.5.4 Inheritance asso ciation 8 Inheritance association occurs between components of the parent component and components inherited 9 by type extension into an extended type (4.5.7.2). This association is persistent; it is not affected by the 10 accessibility of the inherited components. 11 16.5.5 Establishing asso ciations 12 When an association is established between two entities by argument association, host association, 13 or construct association, certain characteristics of the asso ciating entity become those of the pre- 14 existing entity. 15 For argument association, if the dummy argument is not a pointer and the corresponding actual argument 16 is a pointer, the pre-existing entity is the target of that pointer. Otherwise the pre-existing entity is the 17 corresponding actual argument. In either case, the associating entity is the dummy argument. 18 For host association, the associating entity is the entity in the host scoping unit and the pre-existing 19 entity is the entity in the contained scoping unit. If an internal procedure is invoked via a dummy 20 procedure or procedure pointer, the pre-existing entity that participates in the association is the one 21 from the host instance. Otherwise, if the host scoping unit is a recursive procedure, the pre-existing entity 22 502 2006/07/11 WORKING DRAFT J3/06-007 that participates in the association is the one from the innermost subprogram instance that invoked, 1 directly or indirectly, the contained procedure. 2 For construct association, the associating entity is identified by the associate name and the pre-existing 3 entity is the selector. 4 When an association is established by argument association, host association, or construct association, 5 the following applies. 6 (1) If the associating entity has the POINTER attribute, its pointer association status becomes 7 the same as that of the pre-existing entity. If the pre-existing entity has a pointer association 8 status of associated, the associating entity becomes pointer associated with the same target 9 and, if they are arrays, the bounds of the associating entity become the same as those of 10 the pre-existing entity. 11 (2) If the associating entity has the ALLOCATABLE attribute, its allocation status becomes 12 the same as that of the pre-existing entity. If the pre-existing entity is allocated, the bounds 13 (if it is an array), values of deferred type parameters, definition status, and value (if it is 14 defined) become the same as those of the pre-existing entity. If the associating entity is 15 polymorphic and the pre-existing entity is allocated, the dynamic type of the associating 16 entity becomes the same as that of the pre-existing entity. 17 If the associating entity is neither a pointer nor allocatable, its definition status and value (if it is defined) 18 become the same as those of the pre-existing entity. If the entities are arrays and the association is not 19 argument association, the bounds of the associating entity become the same as those of the pre-existing 20 entity. 21 16.6 Definition and undefinition of variables 22 16.6.1 Definition of objects and sub objects 23 A variable may be defined or may be undefined and its definition status may change during execution of 24 a program. An action that causes a variable to become undefined does not imply that the variable was 25 previously defined. An action that causes a variable to become defined does not imply that the variable 26 was previously undefined. 27 Arrays, including sections, and variables of derived, character, or complex type are ob jects that consist of 28 zero or more subob jects. Associations may be established between variables and subob jects and between 29 subob jects of different variables. These subob jects may become defined or undefined. 30 An array is defined if and only if all of its elements are defined. 31 A derived-type scalar ob ject is defined if and only if all of its nonpointer components are defined. 32 A complex or character scalar ob ject is defined if and only if all of its subob jects are defined. 33 If an ob ject is undefined, at least one (but not necessarily all) of its subob jects are undefined. 34 16.6.2 Variables that are always defined 35 Zero-sized arrays and zero-length strings are always defined. 36 16.6.3 Variables that are initially defined 37 The following variables are initially defined: 38 503 J3/06-007 WORKING DRAFT 2006/07/11 (1) variables specified to have initial values by DATA statements; 1 (2) variables specified to have initial values by type declaration statements; 2 (3) nonpointer default-initialized subcomponents of variables that do not have the ALLOCAT- 3 ABLE or POINTER attribute, and are saved, local variables of a main program, or declared 4 in a MODULE or BLOCK DATA scoping unit; 5 (4) pointers specified to be initially associated with a variable that is initially defined; 6 (5) variables that are always defined; 7 (6) variables with the BIND attribute that are initialized by means other than Fortran. 8 NOTE 16.19 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 9 All other variables are initially undefined. 10 16.6.5 Events that cause variables to b ecome defined 11 Variables become defined by the following events. 12 (1) Execution of an intrinsic assignment statement other than a masked array assignment or 13 FORALL assignment statement causes the variable that precedes the equals to become 14 defined. Execution of a defined assignment statement may cause all or part of the variable 15 that precedes the equals to become defined. 16 (2) Execution of a masked array assignment or FORALL assignment statement may cause some 17 or all of the array elements in the assignment statement to become defined (7.4.3). 18 (3) As execution of an input statement proceeds, each variable that is assigned a value from 19 the input file becomes defined at the time that data is transferred to it. (See (4) in 16.6.6.) 20 Execution of a WRITE statement whose unit specifier identifies an internal file causes each 21 record that is written to become defined. 22 (4) Execution of a DO statement causes the DO variable, if any, to become defined. 23 (5) Beginning of execution of the action specified by an io-implied-do in a synchronous in- 24 put/output statement causes the do-variable to become defined. 25 (6) A reference to a procedure causes the entire dummy argument data ob ject to become defined 26 if the dummy argument does not have INTENT(OUT) and the entire corresponding actual 27 argument is defined. 28 A reference to a procedure causes a subob ject of a dummy argument to become defined if 29 the dummy argument does not have INTENT(OUT) and the corresponding subob ject of 30 the corresponding actual argument is defined. 31 504 2006/07/11 WORKING DRAFT J3/06-007 (7) Execution of an input/output statement containing an IOSTAT= specifier causes the spec- 1 ified integer variable to become defined. 2 (8) Execution of a synchronous READ statement containing a SIZE= specifier causes the spec- 3 ified integer variable to become defined. 4 (9) Execution of a wait operation corresponding to an asynchronous input statement containing 5 a SIZE= specifier causes the specified integer variable to become defined. 6 (10) Execution of an INQUIRE statement causes any variable that is assigned a value during the 7 execution of the statement to become defined if no error condition exists. 8 (11) If an error, end-of-file, or end-of-record condition occurs during execution of an input/output 9 statement that has an IOMSG= specifier, the iomsg-variable becomes defined. 10 (12) When a character storage unit becomes defined, all associated character storage units be- 11 come defined. 12 When a numeric storage unit becomes defined, all associated numeric storage units of the 13 same type become defined. When an entity of double precision real type becomes defined, 14 all totally associated entities of double precision real type become defined. 15 When an unspecified storage unit becomes defined, all associated unspecified storage units 16 become defined. 17 (13) When a default complex entity becomes defined, all partially associated default real entities 18 become defined. 19 (14) When both parts of a default complex entity become defined as a result of partially associ- 20 ated default real or default complex entities becoming defined, the default complex entity 21 becomes defined. 22 (15) When all components of a structure of a numeric sequence type or character sequence type 23 become defined as a result of partially associated ob jects becoming defined, the structure 24 becomes defined. 25 (16) Execution of an ALLOCATE, DEALLOCATE, NOTIFY, QUERY, SYNC ALL, SYNC IMAGES, 26 SYNC MEMORY, or SYNC TEAM statement with a STAT= specifier causes the variable 27 specified by the STAT= specifier to become defined. 28 (17) If an error condition occurs during execution of an ALLOCATE, DEALLOCATE, NOTIFY, 29 QUERY, SYNC ALL, SYNC IMAGES, SYNC MEMORY, or SYNC TEAM statement that 30 has an ERRMSG= specifier, the variable specified by the ERRMSG= specifier becomes 31 defined. 32 (18) Allocation of a zero-sized array causes the array to become defined. 33 (19) Allocation of an ob ject that has a nonpointer default-initialized subcomponent causes that 34 subcomponent to become defined. 35 (20) Invocation of a procedure causes any automatic ob ject of zero size in that procedure to 36 become defined. 37 (21) Execution of a pointer assignment statement that associates a pointer with a target that is 38 defined causes the pointer to become defined. 39 (22) Invocation of a procedure that contains an unsaved nonpointer nonallocatable local variable 40 causes all nonpointer default-initialized subcomponents of the ob ject to become defined. 41 (23) Invocation of a procedure that has a nonpointer nonallocatable INTENT (OUT) dummy 42 argument causes all nonpointer default-initialized subcomponents of the dummy argument 43 to become defined. 44 (24) Invocation of a nonpointer function of a derived type causes all nonpointer default-initialized 45 subcomponents of the function result to become defined. 46 (25) In a FORALL construct, the index-name becomes defined when the index-name value set 47 is evaluated. 48 (26) An ob ject with the VOLATILE attribute that is changed by a means not specified by the 49 program becomes defined (see 5.3.18). 50 505 J3/06-007 WORKING DRAFT 2006/07/11 (27) Execution of the BLOCK statement of a BLOCK construct that has an unsaved nonpointer 1 nonallocatable local variable causes all nonpointer default-initialized subcomponents of the 2 variable to become defined. 3 (28) Execution of an OPEN statement containing a NEWUNIT= specifier causes the specified 4 integer variable to become defined. 5 16.6.6 Events that cause variables to b ecome undefined 6 Variables become undefined by the following events. 7 (1) When a variable of a given type becomes defined, all associated variables of different type 8 become undefined. However, when a variable of type default real is partially associated with 9 a variable of type default complex, the complex variable does not become undefined when 10 the real variable becomes defined and the real variable does not become undefined when 11 the complex variable becomes defined. When a variable of type default complex is partially 12 associated with another variable of type default complex, definition of one does not cause 13 the other to become undefined. 14 (2) If the evaluation of a function may cause a variable to become defined and if a reference to 15 the function appears in an expression in which the value of the function is not needed to 16 determine the value of the expression, the variable becomes undefined when the expression 17 is evaluated. 18 (3) When execution of an instance of a subprogram completes, 19 (a) its unsaved local variables become undefined, 20 (b) unsaved variables in a named common block that appears in the subprogram become 21 undefined if they have been defined or redefined, unless another active scoping unit 22 is referencing the common block, 23 (c) unsaved nonfinalizable local variables of a module or submodule become undefined 24 unless another active scoping unit is referencing the module or submodule, and 25 NOTE 16.20 A module subprogram inherently references the module that is its host. Therefore, for processors that keep track of when modules are in use, a module is in use whenever any procedure in the module is active, even if no other active scoping units reference the module; this situation can arise if a module procedure is invoked via a procedure pointer, a type-bound procedure, or a companion processor. (d) unsaved finalizable local variables of a module or submodule may be finalized if no 26 other active scoping unit is referencing the module or submodule ­ following which 27 they become undefined. 28 (4) When an error condition or end-of-file condition occurs during execution of an input state- 29 ment, all of the variables specified by the input list or namelist group of the statement 30 become undefined. 31 (5) When an error condition, end-of-file condition, or end-of-record condition occurs during 32 execution of an input/output statement and the statement contains any io-implied-do s, all 33 of the do-variable s in the statement become undefined (9.10). 34 (6) Execution of a direct access input statement that specifies a record that has not been written 35 previously causes all of the variables specified by the input list of the statement to become 36 undefined. 37 (7) Execution of an INQUIRE statement may cause the NAME=, RECL=, and NEXTREC= 38 variables to become undefined (9.9). 39 (8) When a character storage unit becomes undefined, all associated character storage units 40 become undefined. 41 506 2006/07/11 WORKING DRAFT J3/06-007 When a numeric storage unit becomes undefined, all associated numeric storage units be- 1 come undefined unless the undefinition is a result of defining an associated numeric storage 2 unit of different type (see (1) above). 3 When an entity of double precision real type becomes undefined, all totally associated 4 entities of double precision real type become undefined. 5 When an unspecified storage unit becomes undefined, all associated unspecified storage units 6 become undefined. 7 (9) When an allocatable entity is deallocated, it becomes undefined. 8 (10) When the allocation transfer procedure (13.5.17) causes the allocation status of an allocat- 9 able entity to become unallocated, the entity becomes undefined. 10 (11) Successful execution of an ALLOCATE statement for a nonzero-sized ob ject that has a sub- 11 component for which default initialization has not been specified causes the subcomponent 12 to become undefined. 13 (12) Execution of an INQUIRE statement causes all inquiry specifier variables to become un- 14 defined if an error condition exists, except for any variable in an IOSTAT= or IOMSG= 15 specifier. 16 (13) When a procedure is invoked 17 (a) an optional dummy argument that is not associated with an actual argument becomes 18 undefined, 19 (b) a dummy argument with INTENT (OUT) becomes undefined except for any non- 20 pointer default-initialized subcomponents of the argument, 21 (c) an actual argument associated with a dummy argument with INTENT (OUT) be- 22 comes undefined except for any nonpointer default-initialized subcomponents of the 23 argument, 24 (d) a subob ject of a dummy argument that does not have INTENT (OUT) becomes 25 undefined if the corresponding subob ject of the actual argument is undefined, and 26 (e) the result variable of a function becomes undefined except for any of its nonpointer 27 default-initialized subcomponents. 28 (14) When the association status of a pointer becomes undefined or disassociated (16.5.2.2.2- 29 16.5.2.2.3), the pointer becomes undefined. 30 (15) When the execution of a FORALL or DO CONCURRENT construct completes, the index- 31 name s become undefined. 32 (16) When a DO CONCURRENT construct terminates, a variable that is defined or becomes 33 undefined during more than one iteration of the construct becomes undefined. 34 (17) Execution of an asynchronous READ statement causes all of the variables specified by the 35 input list or SIZE= specifier to become undefined. Execution of an asynchronous namelist 36 READ statement causes any variable in the namelist group to become undefined if that 37 variable will subsequently be defined during the execution of the READ statement or the 38 corresponding WAIT operation. 39 (18) When execution of a RETURN or END statement causes a variable to become undefined, 40 any variable of type C PTR becomes undefined if its value is the C address of any part of 41 the variable that becomes undefined. 42 (19) When a variable with the TARGET attribute is deallocated, any variable of type C PTR 43 becomes undefined if its value is the C address of any part of the variable that is deallocated. 44 (20) When a BLOCK construct terminates, its unsaved local variables become undefined. 45 507 J3/06-007 WORKING DRAFT 2006/07/11 NOTE 16.21 Execution of a defined assignment statement may leave all or part of the variable undefined. 16.6.7 Variable definition context 1 Some variables are prohibited from appearing in a syntactic context that would imply definition or 2 undefinition of the variable (5.3.9, 5.3.14, 12.7). The following are the contexts in which the appearance 3 of a variable implies such definition or undefinition of the variable: 4 · the variable of an assignment-stmt ; 5 · a pointer-object in a nul lify-stmt ; 6 · a data-pointer-object or proc-pointer-object in a pointer-assignment-stmt ; 7 · a do-variable in a do-stmt or io-implied-do ; 8 · an input-item in a read-stmt ; 9 · a variable-name in a namelist-stmt if the namelist-group-name appears in a NML= specifier in a 10 read-stmt ; 11 · an internal-file-variable in a write-stmt ; 12 · an IOSTAT=, SIZE=, or IOMSG= specifier in an input/output statement; 13 · a specifier in an INQUIRE statement other than FILE=, ID=, and UNIT=; 14 · a NEWUNIT= specifier in an OPEN statement; 15 · a READY= specifier in a QUERY statement; 16 · a stat-variable , al locate-object , or errmsg-variable ; 17 · an actual argument in a reference to a procedure with an explicit interface if the associated dummy 18 argument has the INTENT(OUT) or INTENT(INOUT) attribute; 19 · a variable that is the selector in a SELECT TYPE or ASSOCIATE construct if the associate name 20 of that construct appears in a variable definition context. 21 16.6.8 Pointer association context 22 Some pointers are prohibited from appearing in a syntactic context that would imply alteration of the 23 pointer association status (16.5.2.2,5.3.9, 5.3.14). The following are the contexts in which the appearance 24 of a pointer implies such alteration of its pointer association status: 25 · a pointer-object in a nul lify-stmt ; 26 · a data-pointer-object or proc-pointer-object in a pointer-assignment-stmt ; 27 · an al locate-object in an al locate-stmt or deal locate-stmt ; 28 · an actual argument in a reference to a procedure if the associated dummy argument is a pointer 29 with the INTENT (OUT) or INTENT (INOUT) attribute. 30 If a reference to a function appears in a variable definition context the result of the function reference 31 shall be a pointer that is associated with a definable target. That target is the variable that becomes 32 defined or undefined. 33 508 2006/07/11 WORKING DRAFT J3/06-007 Annex A 1 (Informative) 2 Glossary of technical terms 3 The following is a list of the principal technical terms used in the standard and their definitions. A 4 reference in parentheses immediately after a term is to the clause or subclause where the term is defined 5 or explained. The wording of a definition here is not necessarily the same as in the standard. 6 abstract typ e (4.5.7) : A type that has the ABSTRACT attribute. A nonpolymorphic ob ject shall not 7 be declared to be of abstract type. A polymorphic ob ject shall not be constructed or allocated to have 8 a dynamic abstract type. 9 action statement (2.1) : A single statement specifying or controlling a computational action (R214). 10 actual argument (12, 12.5.1) : An expression, a variable, a procedure, or an alternate return specifier that 11 is specified in a procedure reference. 12 allo catable variable (5.3.3) : A variable having the ALLOCATABLE attribute. It may be referenced 13 or defined only when it is allocated. If it is an array, it has a shape only when it is allocated. It may be 14 a named variable or a structure component. 15 argument (12) : An actual argument or a dummy argument. 16 argument asso ciation (16.5.1.2) : The relationship between an actual argument and a dummy argu- 17 ment during the execution of a procedure reference. 18 array (2.4.5) : A set of scalar data, all of the same type and type parameters, whose individual elements 19 are arranged in a rectangular pattern. It may be a named array, an array section, a structure component, 20 a function value, or an expression. Its rank is at least one. Note that in Fortran 77, arrays were always 21 named and never constants. 22 array element (2.4.5, 6.2.2) : One of the scalar data that make up an array that is either named or is 23 a structure component. 24 array p ointer (5.3.7.4) : A pointer to an array. 25 array section (2.4.5, 6.2.2.3) : A subob ject that is an array and is not a structure component. 26 assignment statement (7.4.1.1) : A statement that evaluates an expression and assigns its value to a 27 variable. 28 asso ciate name (8.1.5.1) : The name of the construct entity with which a selector of a SELECT TYPE 29 or ASSOCIATE construct is associated within the construct. 30 asso ciation (16.5) : Name association, pointer association, storage association, or inheritance associa- 31 tion. 32 assumed-shap e array (5.3.7.3) : A nonpointer dummy array that takes its shape from the associated 33 actual argument. 34 assumed-size array (5.3.7.5) : A dummy array whose size is assumed from the associated actual 35 argument. Its last upper bound is specified by an asterisk. 36 509 J3/06-007 WORKING DRAFT 2006/07/11 attribute (5) : A property of an entity that determines its uses. 1 automatic data ob ject (5.2) : A data ob ject that is a local entity of a subprogram, that is not a dummy 2 argument, and that has a length type parameter or array bound that is specified by an expression that 3 is not an initialization expression. 4 base typ e (4.5.7) : An extensible type that is not an extension of another type. 5 b elong (8.1.7.5.3, 8.1.7.5.4) : If an EXIT or a CYCLE statement contains a construct name, the 6 statement b elongs to the construct using that name. Otherwise, it b elongs to the innermost DO 7 construct in which it appears. 8 binding lab el (15.5.2, 15.4.2) : A value of type default character that uniquely identifies how a variable, 9 common block, subroutine, or function is known to a companion processor. 10 blo ck (8.1) : A sequence of executable constructs embedded in another executable construct, bounded 11 by statements that are particular to the construct, and treated as an integral unit. 12 blo ck data program unit (11.3) : A program unit that provides initial values for data ob jects in 13 named common blocks. 14 b ounds (5.3.7.2) : For a named array, the limits within which the values of the subscripts of its array 15 elements shall lie. 16 character (3.1) : A letter, digit, or other symbol. 17 character length parameter (2.4.1.1) : The type parameter that specifies the number of characters 18 for an entity of type character. 19 character storage unit (16.5.3.2) : The unit of storage for holding a scalar that is not a pointer and 20 is of type default character and character length one. 21 character string (4.4.5) : A sequence of characters numbered from left to right 1, 2, 3, ... 22 characteristics (12.3) : 23 Of a procedure, its classification as a function or subroutine, whether it is pure, whether it is elemental, 24 whether it has the BIND attribute, the value of its binding label, the characteristics of its dummy 25 arguments, and the characteristics of its function result if it is a function. 26 Of a dummy argument, whether it is a data ob ject, is a procedure, is a procedure pointer, is an asterisk 27 (alternate return indicator), or has the OPTIONAL attribute. 28 Of a dummy data ob ject, its type, type parameters, shape, the exact dependence of an array bound 29 or type parameter on other entities, intent, whether it is optional, whether it is a pointer or a target, 30 whether it is allocatable, whether it has the VALUE, ASYNCHRONOUS, or VOLATILE attributes, 31 whether it is polymorphic, and whether the shape, size, or a type parameter is assumed. 32 Of a dummy procedure or procedure pointer, whether the interface is explicit, the characteristics of the 33 procedure if the interface is explicit, and whether it is optional. 34 Of a function result, its type, type parameters, which type parameters are deferred, whether it is poly- 35 morphic, whether it is a pointer or allocatable, whether it is a procedure pointer, rank if it is a pointer 36 or allocatable, shape if it is not a pointer or allocatable, the exact dependence of an array bound or type 37 parameter on other entities, and whether the character length is assumed. 38 class (4.3.1.3) : A class named N is the set of types extended from the type named N. 39 co-array (2.4.6) A data entity that has nonzero co-rank. A non-dummy co-array has the same shape 40 510 2006/07/11 WORKING DRAFT J3/06-007 on every image and its values may be referenced or defined by any image. 1 co-b ounds (5.3.7) : For a co-array, the limits within which the values of the co-subscripts of its co- 2 indexed ob jects shall lie. 3 co-indexed ob ject (2.4.6) : An ob ject whose designator includes an image-selector . 4 co-rank (2.4.6) : The number of co-dimensions of a co-array. 5 co-subscript (6.2.3) : One of the list of scalar integer expressions in an image-selector . 6 collating sequence (4.4.5.4) : An ordering of all the different characters of a particular kind type 7 parameter. 8 collective subroutine (13.1) : An intrinsic subroutine that has an argument of type IMAGE TEAM. 9 common blo ck (5.7.2) : A block of physical storage that may be accessed by any of the scoping units 10 in a program. 11 companion pro cessor (2.5.10): A mechanism by which global data and procedures may be referenced 12 or defined. It may be a mechanism that references and defines such entities by means other than Fortran. 13 The procedures can be described by a C function prototype. 14 comp onent (4.5) : A constituent of a derived type. 15 comp onent order (4.5.4.6) : The ordering of the components of a derived type that is used for intrinsic 16 formatted input/output and for structure constructors. 17 conformable (2.4.5) : Two arrays are said to be conformable if they have the same shape. A scalar 18 is conformable with any array. 19 conformance (1.5) : A program conforms to the standard if it uses only those forms and relationships 20 described therein and if the program has an interpretation according to the standard. A program unit 21 conforms to the standard if it can be included in a program in a manner that allows the program to be 22 standard-conforming. A processor conforms to the standard if it executes standard-conforming programs 23 in a manner that fulfills the interpretations prescribed in the standard and contains the capability of 24 detection and reporting as listed in 1.5. 25 connect team (9.4.6.7) : The set of images that are permitted to reference a particular external 26 input/output unit. 27 connected (9.4.3) : 28 For an external unit, the property of referring to an external file. 29 For an external file, the property of having an external unit that refers to it. 30 constant (2.4.3.1.2) : A data ob ject whose value shall not change during execution of a program. It 31 may be a named constant or a literal constant. 32 construct (7.4.3, 7.4.4, 8.1) : A sequence of statements starting with an ASSOCIATE, BLOCK, DO, 33 FORALL, IF, SELECT CASE, SELECT TYPE, or WHERE statement and ending with the correspond- 34 ing terminal statement. 35 construct asso ciation (16.5.1.6) : The association between the selector of an ASSOCIATE or SELECT 36 TYPE construct and the associate name. 37 construct entity (16) : An entity defined by a lexical token whose scope is a construct. 38 511 J3/06-007 WORKING DRAFT 2006/07/11 control mask (7.4.3) : In a WHERE statement or construct, an array of type logical whose value 1 determines which elements of an array, in a where-assignment-stmt , will be defined. 2 data : Plural of datum. 3 data entity (2.4.3) : A data ob ject, the result of the evaluation of an expression, or the result of the 4 execution of a function reference (called the function result). A data entity has a type (either intrinsic 5 or derived) and has, or may have, a data value (the exception is an undefined variable). Every data 6 entity has a rank and is thus either a scalar or an array. 7 data ob ject (2.4.3.1) : A data entity that is a constant, a variable, or a subob ject of a constant. 8 data typ e (4) : See type. 9 datum : A single quantity that may have any of the set of values specified for its type. 10 decimal symb ol (9.9.1.6, 10.6, 10.8.8) : The character that separates the whole and fractional parts in 11 the decimal representation of a real number in a file. By default the decimal symbol is a decimal point 12 (also known as a period). The current decimal symbol is determined by the current decimal edit mode. 13 declared typ e (4.3.1.3, 7.1.4) : The type that a data entity is declared to have. May differ from the 14 type during execution (the dynamic type) for polymorphic data entities. 15 default initialization (4.5) : If initialization is specified in a type definition, an ob ject of the type will 16 be automatically initialized. Nonpointer components may be initialized with values by default; pointer 17 components may be initially disassociated by default. Default initialization is not provided for ob jects 18 of intrinsic type. 19 default-initialized (4.5.4.5) : A subcomponent is said to be default-initialized if it will be initialized 20 by default initialization. 21 deferred binding (4.5.5) : A binding with the DEFERRED attribute. A deferred binding shall appear 22 only in an abstract type definition (4.5.7). 23 deferred typ e parameter (4.3) : A length type parameter whose value is not specified in the decla- 24 ration of an ob ject, but instead is specified when the ob ject is allocated or pointer-assigned. 25 definable (2.5.5) : A variable is definable if its value may be changed by the appearance of its 26 designator on the left of an assignment statement. An allocatable variable that has not been allocated 27 is an example of a data ob ject that is not definable. An example of a subob ject that is not definable is 28 C (I) when C is an array that is a constant and I is an integer variable. 29 defined (2.5.5) : For a data ob ject, the property of having or being given a valid value. 30 defined assignment statement (7.4.1.4, 12.4.2.1.2) : An assignment statement that is not an intrinsic 31 assignment statement; it is defined by a subroutine and a generic interface that specifies ASSIGNMENT 32 (=). 33 defined op eration (7.1.3, 12.4.2.1.1) : An operation that is not an intrinsic operation and is defined 34 by a function that is associated with a generic identifier. 35 deleted feature (1.8) : A feature in a previous Fortran standard that is considered to have been 36 redundant and largely unused. See B.1 for a list of features that are in a previous Fortran standard, but 37 are not in this standard. A feature designated as an obsolescent feature in the standard may become a 38 deleted feature in the next revision. 39 derived typ e (2.4.1.2, 4.5) : A type whose data have components, each of which is either of intrinsic 40 type or of another derived type. 41 512 2006/07/11 WORKING DRAFT J3/06-007 designator (2.5.1) : A name, followed by zero or more subob ject selectors. 1 disasso ciated (2.4.7) : A disassociated pointer is not associated with a target. A pointer is disassociated 2 following execution of a NULLIFY statement, following pointer assignment with a disassociated pointer, 3 by default initialization, or by explicit initialization. A data pointer may also be disassociated by 4 execution of a DEALLOCATE statement. 5 dummy argument (12, 12.6.2.1, 12.6.2.2, 12.6.2.5, 12.6.4) : An entity by which an associated actual 6 argument is accessed during execution of a procedure. 7 dummy array : A dummy argument that is an array. 8 dummy data ob ject (12.3.1.1, 12.5.1.4) : A dummy argument that is a data ob ject. 9 dummy pro cedure (12.2.2.3) : A dummy argument that is specified or referenced as a procedure. 10 dynamic typ e (4.3.1.3, 7.1.4) : The type of a data entity during execution of a program. The dynamic 11 type of a data entity that is not polymorphic is the same as its declared type. 12 effective item (9.5.2) : A scalar ob ject resulting from expanding an input/output list according to the 13 rules in 9.5.2. 14 elemental (2.4.5, 7.4.1.4, 12.8) : An adjective applied to an operation, procedure, or assignment state- 15 ment that is applied independently to elements of an array or corresponding elements of a set of con- 16 formable arrays and scalars. 17 entity : The term used for any of the following: an abstract interface, common block, construct, 18 data entity, external unit, generic interface,, macro namelist group, operator, procedure, program unit, 19 statement function, statement lab el, or typ e. 20 executable construct (2.1) : An action statement (R214) or an ASSOCIATE, CASE, DO, FORALL, 21 IF, SELECT TYPE, or WHERE construct. 22 executable statement (2.3.1) : An instruction to perform or control one or more computational 23 actions. 24 explicit initialization (5.2) : Explicit initialization may be specified for ob jects of intrinsic or derived 25 type in type declaration statements or DATA statements. An ob ject of a derived type that specifies 26 default initialization shall not appear in a DATA statement. 27 explicit interface (12.4.1) : If a procedure has an explicit interface at the point of a reference to it, the 28 processor is able to verify that the characteristics of the reference and declaration are related as required 29 by this standard. A procedure has an explicit interface if it is an internal procedure, a module procedure, 30 an intrinsic procedure, an external procedure that has an interface body, a procedure reference in its 31 own scoping unit, or a dummy procedure that has an interface body. 32 explicit-shap e array (5.3.7.2) : A named array that is declared with explicit bounds. 33 expression (2.4.3.2, 7.1) : A sequence of operands, operators, and parentheses (R722). It may be a 34 variable, a constant, a function reference, or may represent a computation. 35 extended typ e (4.5.7) : An extensible type that is an extension of another type. A type that is declared 36 with the EXTENDS attribute. 37 extensible typ e (4.5.7) : A type from which new types may be derived using the EXTENDS attribute. 38 A nonsequence type that does not have the BIND attribute. 39 extension typ e (4.5.7) : A base type is an extension type of itself only. An extended type is an 40 513 J3/06-007 WORKING DRAFT 2006/07/11 extension type of itself and of all types for which its parent type is an extension. 1 extent (2.4.5) : The size of one dimension of an array. 2 external file (9.2) : A sequence of records that exists in a medium external to the program. 3 external linkage : The characteristic describing that a C entity is global to the program; defined in 4 subclause 6.2.2 of the C International Standard. 5 external pro cedure (2.2.3.1) : A procedure that is defined by an external subprogram or by a means 6 other than Fortran. 7 external subprogram (2.2) : A subprogram that is not in a main program, module, or another 8 subprogram. Note that a module is not called a subprogram. Note that in Fortran 77, a block data 9 program unit is called a subprogram. 10 external unit (9.4) : A mechanism that is used to refer to an external file. It is identified by a 11 nonnegative integer. 12 file (9) : An internal file or an external file. 13 file storage unit (9.2.4) : The unit of storage for an unformatted or stream file. 14 final subroutine (4.5.6) : A subroutine that is called automatically by the processor during finalization. 15 finalizable (4.5.6) : A type that has final subroutines, or that has a finalizable component. An ob ject 16 of finalizable type. 17 finalization (4.5.6.2) : The process of calling user-defined final subroutines immediately before destroy- 18 ing an ob ject. 19 function (2.2.3) : A procedure that is invoked in an expression and computes a value which is then 20 used in evaluating the expression. 21 function result (12.6.2.1) : The data ob ject that returns the value of a function. 22 function subprogram (12.6.2.1) : A sequence of statements beginning with a FUNCTION statement 23 that is not in an interface block and ending with the corresponding END statement. 24 generic identifier (12.4.2.1) : A lexical token that appears in an INTERFACE statement and is 25 associated with all the procedures in the interface block or that appears in a GENERIC statement and 26 is associated with the specific type-bound procedures. 27 generic interface (4.5.2, 12.4.2.1) : An interface specified by a generic procedure binding or a generic 28 interface block. 29 generic interface blo ck (12.4.2.1) : An interface block with a generic specification. 30 global entity (16.2) : An entity with an identifier whose scope is a program. 31 host (2.2) : Host scoping unit. 32 host asso ciation (16.5.1.4) : The process by which a contained scoping unit accesses entities of its 33 host. 34 host scoping unit (2.2) : A scoping unit that immediately surrounds another scoping unit. 35 image (2.3.5) : A Fortran program executes as if it were replicated a number of times, the number of 36 replications remaining fixed during execution of the program. Each copy is called an image and each 37 514 2006/07/11 WORKING DRAFT J3/06-007 image executes asynchronously. 1 image index (2.3.5) : An integer value that identifies an image. 2 J3 internal note Unresolved Technical Issue 78 Clause 16 is missing edits about images. (And so is Annex A.) In particular: · images are entities ­ add them to the entity gloss; · they are identified by integer image indexes ­ add that fact to the first numbered list in clause 16; · they are global entities ­ this should be noted at the end of "Scope of global identifiers" (was 16.1). While I'm here, I can well imagine an obvious implementation technique for co-arrays/images on shared-memory machines which would result in pending data transfer operations being per- program not per-image. I've not been back to check to see whether this is relevant to the current set of things one is allowed to do to a connect-team file, though I can well imagine that it might be (once the rules are sorted out). Finally, there are very real questions (hinted at if not raised elsewhere) about the adequacy of our simple local+global scoping model w.r.t. co-arrays. Maybe this needs to have three levels rather than two? implicit interface (12.4.1) : For a procedure referenced in a scoping unit, the property of not having 3 an explicit interface. A statement function always has an implicit interface 4 inherit (4.5.7) : To acquire from a parent. Type parameters, components, or procedure bindings of an 5 extended type that are automatically acquired from its parent type without explicit declaration in the 6 extended type are said to be inherited. 7 inheritance asso ciation (4.5.7.2, 16.5.4) : The relationship between the inherited components and the 8 parent component in an extended type. 9 inquiry function (13.1) : A function that is either intrinsic or is defined in an intrinsic module and 10 whose result depends on properties of one or more of its arguments instead of their values. 11 instance of a subprogram (12.6.2.3) : The copy of a subprogram that is created when a procedure 12 defined by the subprogram is invoked. 13 intent (5.3.9) : An attribute of a dummy data ob ject that indicates whether it is used to transfer data 14 into the procedure, out of the procedure, or both. 15 interface blo ck (12.4.2.1) : A sequence of statements from an INTERFACE statement to the corre- 16 sponding END INTERFACE statement. 17 interface b o dy (12.4.2.1) : A sequence of statements in an interface block from a FUNCTION or 18 SUBROUTINE statement to the corresponding END statement. 19 interface of a pro cedure (12.4) : See procedure interface. 20 internal file (9.3) : A character variable that is used to transfer and convert data from internal storage 21 to internal storage. 22 internal pro cedure (2.2.3.3) : A procedure that is defined by an internal subprogram. 23 internal subprogram (2.2) : A subprogram in a main program or another subprogram. 24 515 J3/06-007 WORKING DRAFT 2006/07/11 interop erable (15.3) : The property of a Fortran entity that ensures that an equivalent entity may be 1 defined by means of C. 2 intrinsic (2.5.7) : An adjective that may be applied to types, operators, assignment statements, proce- 3 dures, and modules. Intrinsic types, operators, and assignment statements are defined in this standard 4 and may be used in any scoping unit without further definition or specification. Intrinsic procedures are 5 defined in this standard or provided by a processor, and may be used in a scoping unit without further 6 definition or specification. Intrinsic modules are defined in this standard or provided by a processor, 7 and may be accessed by use association; procedures and types defined in an intrinsic module are not 8 themselves intrinsic. 9 Intrinsic procedures and modules that are not defined in this standard are called nonstandard intrinsic 10 procedures and modules. 11 invoke (2.2.3) : 12 To call a subroutine by a CALL statement or by a defined assignment statement. 13 To call a function by a reference to it by name or operator during the evaluation of an expression. 14 To call a final subroutine by finalization. 15 keyword (2.5.2) : A word that is part of the syntax of a statement or a name that is used to identify 16 an item in a list. 17 kind typ e 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 18 the available kinds of an intrinsic type, or a derived-type parameter that is declared to have the KIND 19 attribute. 20 lab el : See binding label or statement label. 21 length of a character string (4.4.5) : The number of characters in the character string. 22 lexical token (3.2) : A sequence of one or more characters with a specified interpretation. 23 line (3.3) : A sequence of 0 to 132 characters, which may contain Fortran statements, a comment, or 24 an INCLUDE line. 25 linkage asso ciation (16.5.1.5) : The association between interoperable Fortran entities and their C 26 counterparts. 27 literal constant (2.4.3.1.2, 4.4) : A constant without a name. Note that in Fortran 77, this was 28 called simply a constant. 29 lo cal entity (16.3) : An entity identified by a lexical token whose scope is a scoping unit. 30 lo cal variable (2.4.3.1.1) : A variable local to a particular scoping unit; not imported through use or 31 host association, not a dummy argument, and not a variable in common. 32 main program (2.3.4, 11.1) : A Fortran main program or a replacement defined by means other than 33 Fortran. 34 many-one array section (6.2.2.3.2) : An array section with a vector subscript having two or more 35 elements with the same value. 36 mo dule (2.2.4, 11.2) : A program unit that contains or accesses definitions to be accessed by other 37 program units. 38 mo dule pro cedure (2.2.3.2) : A procedure that is defined by a module subprogram. 39 516 2006/07/11 WORKING DRAFT J3/06-007 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. mo dule pro cedure interface (12.4.2.1) : The interface for a separate module procedure. 1 mo dule subprogram (2.2) : A subprogram that is in a module but is not an internal subprogram. 2 name (3.2.1) : A lexical token consisting of a letter followed by up to 62 alphanumeric characters 3 (letters, digits, and underscores). Note that in Fortran 77, this was called a symbolic name. 4 name asso ciation (16.5.1) : Argument association, use association, host association, linkage associa- 5 tion, or construct association. 6 named : Having a name. That is, in a phrase such as "named variable," the word "named" signifies that 7 the variable name is not qualified by a subscript list, substring specification, and so on. For example, 8 if X is an array variable, the reference "X" is a named variable while the reference "X(1)" is an ob ject 9 designator. 10 named constant (2.4.3.1.2) : A constant that has a name. Note that in Fortran 77, this was called 11 a symbolic constant. 12 NaN (14.7) : A Not-a-Number value of IEEE arithmetic. It represents an undefined value or a value 13 created by an invalid operation. 14 nonexecutable statement (2.3.1) : A statement used to configure the program environment in which 15 computational actions take place. 16 numeric storage unit (16.5.3.2) : The unit of storage for holding a scalar that is not a pointer and is 17 of type default real, default integer, or default logical. 18 numeric typ e (4.4) : Integer, real or complex type. 19 ob ject (2.4.3.1) : Data ob ject. 20 ob ject designator (2.5.1) : A designator for a data ob ject. 21 obsolescent feature (1.8) : A feature that is considered to have been redundant but that is still in 22 frequent use. 23 op erand (2.5.8) : An expression that precedes or succeeds an operator. 24 op eration (7.1.2) : A computation involving one or two operands. 25 op erator (2.5.8) : A lexical token that specifies an operation. 26 override (4.5.2, 4.5.7) : When explicit initialization or default initialization overrides default initializa- 27 tion, it is as if only the overriding initialization were specified. If a procedure is bound to an extensible 28 type, it overrides the one that would have been inherited from the parent type. 29 parent comp onent (4.5.7.2) : The component of an entity of extended type that corresponds to its 30 inherited portion. 31 517 J3/06-007 WORKING DRAFT 2006/07/11 parent typ e (4.5.7) : The extensible type from which an extended type is derived. 1 passed-ob ject dummy argument (4.5.4.4) : The dummy argument of a type-bound procedure or 2 procedure pointer component that becomes associated with the ob ject through which the procedure was 3 invoked. 4 p ointer (2.4.7) : An entity that has the POINTER attribute. 5 p ointer assignment (7.4.2) : The pointer association of a pointer with a target by the execution of a 6 pointer assignment statement or the execution of an assignment statement for a data ob ject of derived 7 type having the pointer as a subob ject. 8 p ointer assignment statement (7.4.2) : A statement of the form "pointer-ob ject => target". 9 p ointer asso ciated (6.3, 7.4.2) : The relationship between a pointer and a target following a pointer 10 assignment or a valid execution of an ALLOCATE statement. 11 p ointer asso ciation (16.5.2) : The process by which a pointer becomes pointer associated with a target. 12 p olymorphic (4.3.1.3) : Able to be of differing types during program execution. An ob ject declared 13 with the CLASS keyword is polymorphic. 14 preconnected (9.4.4) : A property describing a unit that is connected to an external file at the beginning 15 of execution of a program. Such a unit may be specified in input/output statements without an OPEN 16 statement being executed for that unit. 17 pro cedure (2.2.3, 12.2) : A computation that may be invoked during program execution. It may be a 18 function or a subroutine. It may be an intrinsic procedure, an external procedure, a module procedure, 19 an internal procedure, a dummy procedure, or a statement function. A subprogram may define more than 20 one procedure if it contains ENTRY statements. 21 pro cedure designator (2.5.1) : A designator for a procedure. 22 pro cedure interface (12.4) : The characteristics of a procedure, the name of the procedure, the name 23 of each dummy argument, and the generic identifiers (if any) by which it may be referenced. 24 pro cessor (1.2) : The combination of a computing system and the mechanism by which programs are 25 transformed for use on that computing system. 26 pro cessor dep endent (1.5) : The designation given to a facility that is not completely specified by 27 this standard. Such a facility shall be provided by a processor, with methods or semantics determined 28 by the processor. 29 program (2.2.1) : A set of program units that includes exactly one main program. 30 program unit (2.2) : The fundamental component of a program. A sequence of statements, comments, 31 and INCLUDE lines. It may be a main program, a module, an external subprogram, or a block data 32 program unit. 33 prototyp e : The C analog of a function interface body; defined in 6.7.5.3 of the C International 34 Standard. 35 pure pro cedure (12.7) : A procedure that is a pure intrinsic procedure (13.1), is defined by a pure 36 subprogram, or is a statement function that references only pure functions. 37 rank (2.4.4, 2.4.5) : The number of dimensions of an array. Zero for a scalar. 38 record (9.1) : A sequence of values or characters that is treated as a whole within a file. 39 518 2006/07/11 WORKING DRAFT J3/06-007 reference (2.5.6) : The appearance of an ob ject designator in a context requiring the value at that 1 point during execution, the appearance of a procedure designator, its operator symbol, or a defined 2 assignment statement in a context requiring execution of the procedure at that point, or the appearance 3 of a module name in a USE statement. Neither the act of defining a variable nor the appearance of the 4 name of a procedure as an actual argument is regarded as a reference. 5 result variable (2.2.3, 12.6.2.1) : The variable that returns the value of a function. 6 rounding mo de (14.3, 10.7.2.3.7) : The method used to choose the result of an operation that cannot 7 be represented exactly. In IEEE arithmetic, there are four modes; nearest, towards zero, up (towards 8 ), and down (towards -). In addition, for input/output the two additional modes COMPATIBLE 9 and PROCESSOR DEFINED are provided. 10 scalar (2.4.4) : 11 Not being an array. 12 scop e (16) : That part of a program within which a lexical token has a single interpretation. It may be 13 a program, a scoping unit, a construct, a single statement, or a part of a statement. 14 scoping unit (2.2) : One of the following: 15 (1) A program unit or subprogram, excluding any scoping units in it, 16 (2) A derived-type definition, or 17 (3) An interface body, excluding any scoping units in it. 18 section subscript (6.2.2) : A subscript, vector subscript, or subscript triplet in an array section selector. 19 selector (6.1.1, 6.1.2, 6.1.4, 8.1.4, 8.1.5) : A syntactic mechanism for designating 20 (1) a subob ject, 21 (2) the set of values for which a CASE block is executed, 22 (3) the ob ject whose type determines which branch of a SELECT TYPE construct is executed, 23 or 24 (4) the ob ject that is associated with the associate-name in an ASSOCIATE construct. 25 shap e (2.4.5) : The rank and extents of an array. The shape may be represented by the rank-one array 26 whose elements are the extents in each dimension. 27 size (2.4.5) : The total number of elements of an array. 28 sp ecification expression (7.1.6) : An expression with limitations that make it suitable for use in 29 specifications such as length type parameters or array bounds. 30 sp ecification function (7.1.6) : A nonintrinsic function that may be used in a specification expression. 31 standard-conforming program (1.5) : A program that uses only those forms and relationships de- 32 scribed in this standard, and that has an interpretation according to this standard. 33 statement (3.3) : A sequence of lexical tokens. It usually consists of a single line, but a statement may 34 be continued from one line to another and the semicolon symbol may be used to separate statements 35 within a line. 36 statement entity (16) : An entity identified by a lexical token whose scope is a single statement or 37 part of a statement. 38 statement function (12.6.4) : A procedure specified by a single statement that is similar in form to an assignment 39 statement. 40 519 J3/06-007 WORKING DRAFT 2006/07/11 statement lab el (3.2.4) : A lexical token consisting of up to five digits that precedes a statement and 1 may be used to refer to the statement. 2 storage asso ciation (16.5.3) : The relationship between two storage sequences if a storage unit of one 3 is the same as a storage unit of the other. 4 storage sequence (16.5.3.2) : A sequence of contiguous storage units. 5 storage unit (16.5.3.2) : A character storage unit, a numeric storage unit, a file storage unit, or an 6 unspecified storage unit. 7 stride (6.2.2.3.1) : The increment specified in a subscript triplet. 8 struct : The C analog of a sequence derived type; defined in 6.2.5 of the C International Standard. 9 structure (2.4.1.2) : A scalar data ob ject of derived type. 10 structure comp onent (6.1.2) : A part of an ob ject of derived type. It may be referenced by an ob ject 11 designator. 12 structure constructor (4.5.10) : A syntactic mechanism for constructing a value of derived type. 13 sub comp onent (6.1.2) : A subcomponent of an ob ject of derived type is a component of that ob ject 14 or of a subob ject of that ob ject. 15 submo dule (2.2.5, 11.2.2) : A program unit that extends a module or another submodule. 16 sub ob ject (2.4.3.1) : A portion of a data ob ject that may be referenced or defined independently of 17 other portions. It may be an array element, an array section, a structure component, a substring, or the 18 real or imaginary part of a complex ob ject. 19 subprogram (2.2) : A function subprogram or a subroutine subprogram. Note that in Fortran 77, a 20 block data program unit was called a subprogram. 21 subroutine (2.2.3) : A procedure that is invoked by a CALL statement or by a defined assignment 22 statement. 23 subroutine subprogram (12.6.2.2) : A sequence of statements beginning with a SUBROUTINE state- 24 ment that is not in an interface block and ending with the corresponding END statement. 25 subscript (6.2.2) : One of the list of scalar integer expressions in an array element selector. Note that 26 in Fortran 77, the whole list was called the subscript. 27 subscript triplet (6.2.2) : An item in the list of an array section selector that contains a colon and 28 specifies a regular sequence of integer values. 29 substring (6.1.1) : A contiguous portion of a scalar character string. Note that an array section can 30 include a substring selector; the result is called an array section and not a substring. 31 target (2.4.7, 5.3.16, 6.3.1.2) : A data entity that has the TARGET attribute, or an entity that is 32 associated with a pointer. 33 team (2.3.5) : A set of images formed by invoking the intrinsic collective subroutine FORM TEAM 34 (13.7.69). 35 team synchronization (8.5.3) : Synchronization of the images in a team. 36 transformational function (13.1) : A function that is either intrinsic or is defined in an intrinsic 37 module and that is neither an elemental function nor an inquiry function. 38 520 2006/07/11 WORKING DRAFT J3/06-007 typ e (2.4.1) : A named category of data that is characterized by a set of values, together with a way to 1 denote these values and a collection of operations that interpret and manipulate the values. The set of 2 data values depends on the values of the type parameters. 3 typ e-b ound pro cedure (4.5.5) : A procedure binding in a type definition. The procedure may be 4 referenced by the binding-name via any ob ject of that dynamic type, as a defined operator, by defined 5 assignment, or as part of the finalization process. 6 typ e compatible (4.3.1.3) : All entities are type compatible with other entities of the same type. 7 Unlimited polymorphic entities are type compatible with all entities; other polymorphic entities are type 8 compatible with entities whose dynamic type is an extension type of the polymorphic entity's declared 9 type. 10 typ e declaration statement (5.2) : An INTEGER, REAL, DOUBLE PRECISION, COMPLEX, 11 CHARACTER, LOGICAL, TYPE (type-name ), or CLASS (type-name ) statement. 12 typ e parameter (2.4.1.1) : A parameter of a data type. KIND and LEN are the type parameters of 13 intrinsic types. The type parameters of a derived type are defined in the derived-type definition. 14 typ e parameter order (4.5.3.2) : The ordering of the type parameters of a derived type that is used 15 for derived-type specifiers. 16 ultimate comp onent (4.5) : For a structure, a component that is of intrinsic type, has the ALLOCAT- 17 ABLE attribute, or has the POINTER attribute, or an ultimate component of a derived-type component 18 that does not have the POINTER attribute or the ALLOCATABLE attribute. 19 undefined (2.5.5) : For a data ob ject, the property of not having a determinate value. 20 unsigned : A qualifier of a C numeric type indicating that it is comprised only of nonnegative values; 21 defined in 6.2.5 of the C International Standard. There is nothing analogous in Fortran. 22 unsp ecified storage unit (16.5.3.2) : A unit of storage for holding a pointer or a scalar that is not a 23 pointer and is of type other than default integer, default character, default real, double precision real, 24 default logical, or default complex. 25 use asso ciation (16.5.1.3) : The association of names in different scoping units specified by a USE 26 statement. 27 variable (2.4.3.1.1) : A data ob ject whose value can be defined and redefined during the execution of 28 a program. It may be a named data ob ject, an array element, an array section, a structure component, 29 or a substring. Note that in Fortran 77, a variable was always scalar and named. 30 vector subscript (6.2.2.3.2) : A section subscript that is an integer expression of rank one. 31 void : A C type comprising an empty set of values; defined in 6.2.5 of the C International Standard. 32 There is nothing analogous in Fortran. 33 whole array (6.2.1) : A named array. 34 521 J3/06-007 WORKING DRAFT 2006/07/11 522 2006/07/11 WORKING DRAFT J3/06-007 Annex B 1 (Informative) 2 Decremental features 3 B.1 Deleted features 4 The deleted features are those features of Fortran 90 that were redundant and considered largely unused. 5 The following Fortran 90 features are not required by Fortran 95, Fortran 2003, or this part of ISO/IEC 6 1539. 7 (1) Real and double precision DO variables. 8 The ability present in Fortran 77, and for consistency also in Fortran 90, for a DO variable 9 to be of type real or double precision in addition to type integer, has been deleted. A similar 10 result can be achieved by using a DO construct with no loop control and the appropriate 11 exit test. 12 (2) Branching to an END IF statement from outside its block. 13 In Fortran 77, and for consistency also in Fortran 90, it was possible to branch to an END 14 IF statement from outside the IF construct; this has been deleted. A similar result can be 15 achieved by branching to a CONTINUE statement that is immediately after the END IF 16 statement. 17 (3) PAUSE statement. 18 The PAUSE statement, present in Fortran 66, Fortran 77 and for consistency also in 19 Fortran 90, has been deleted. A similar result can be achieved by writing a message to the 20 appropriate unit, followed by reading from the appropriate unit. 21 (4) ASSIGN and assigned GO TO statements and assigned format specifiers. 22 The ASSIGN statement and the related assigned GO TO statement, present in Fortran 66, 23 Fortran 77 and for consistency also in Fortran 90, have been deleted. Further, the ability to 24 use an assigned integer as a format, present in Fortran 77 and Fortran 90, has been deleted. 25 A similar result can be achieved by using other control constructs instead of the assigned 26 GOTO statement and by using a default character variable to hold a format specification 27 instead of using an assigned integer. 28 (5) H edit descriptor. 29 In Fortran 77, and for consistency also in Fortran 90, there was an alternative form of 30 character string edit descriptor, which had been the only such form in Fortran 66; this has 31 been deleted. A similar result can be achieved by using a character string edit descriptor. 32 The following is a list of the previous editions of the Fortran International Standard, along with their 33 informal names. 34 · ISO R 1539-1972, Fortran 66; 35 · ISO 1539-1980, Fortran 77; 36 · 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 523 J3/06-007 WORKING DRAFT 2006/07/11 B.2 Obsolescent features 1 The obsolescent features are those features of Fortran 90 that were redundant and for which better 2 methods were available in Fortran 90. Subclause 1.8.3 describes the nature of the obsolescent features. 3 The obsolescent features in this standard are the following. 4 (1) Arithmetic IF -- use the IF statement (8.1.3.4) or IF construct (8.1.3). 5 (2) Shared DO termination and termination on a statement other than END DO or CON- 6 TINUE -- use an END DO or a CONTINUE statement for each DO statement. 7 (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 B.2.1 Alternate return 15 An alternate return introduces labels into an argument list to allow the called procedure to direct the 16 execution of the caller upon return. The same effect can be achieved with a return code that is used 17 in a CASE construct on return. This avoids an irregularity in the syntax and semantics of argument 18 association. For example, 19 CALL SUBR NAME (X, Y, Z, *100, *200, *300) 20 may be replaced by 21 CALL SUBR NAME (X, Y, Z, RETURN CODE) 22 SELECT CASE (RETURN CODE) 23 CASE (1) 24 ... 25 CASE (2) 26 ... 27 CASE (3) 28 ... 29 CASE DEFAULT 30 ... 31 END SELECT 32 B.2.2 Computed GO TO statement 33 The computed GO TO has been superseded by the CASE construct, which is a generalized, easier to 34 use and more efficient means of expressing the same computation. 35 B.2.3 Statement functions 36 Statement functions are sub ject to a number of nonintuitive restrictions and are a potential source of 37 error because their syntax is easily confused with that of an assignment statement. 38 The internal function is a more generalized form of the statement function and completely supersedes 39 it. 40 524 2006/07/11 WORKING DRAFT J3/06-007 B.2.4 DATA statements among executables 1 The statement ordering rules of Fortran 66, and hence of Fortran 77 and Fortran 90 for compatibility, 2 allowed DATA statements to appear anywhere in a program unit after the specification statements. The 3 ability to position DATA statements amongst executable statements is very rarely used, is unnecessary 4 and is a potential source of error. 5 B.2.5 Assumed character length functions 6 Assumed character length for functions is an irregularity in the language in that elsewhere in Fortran 7 the philosophy is that the attributes of a function result depend only on the actual arguments of the 8 invocation and on any data accessible by the function through host or use association. Some uses of this 9 facility can be replaced with an automatic character length function, where the length of the function 10 result is declared in a specification expression. Other uses can be replaced by the use of a subroutine 11 whose arguments correspond to the function result and the function arguments. 12 Note that dummy arguments of a function may be assumed character length. 13 B.2.6 Fixed form source 14 Fixed form source was designed when the principal machine-readable input medium for new programs 15 was punched cards. Now that new and amended programs are generally entered via keyboards with 16 screen displays, it is an unnecessary overhead, and is potentially error-prone, to have to locate positions 17 6, 7, or 72 on a line. Free form source was designed expressly for this more modern technology. 18 It is a simple matter for a software tool to convert from fixed to free form source. 19 B.2.7 CHARACTER* form of CHARACTER declaration 20 Fortran 90 had two different forms of specifying the length selector in CHARACTER declarations. The 21 older form (CHARACTER*char-length) is redundant. 22 525 J3/06-007 WORKING DRAFT 2006/07/11 526 2006/07/11 WORKING DRAFT J3/06-007 Annex C 1 (Informative) 2 Extended notes 3 C.1 Clause 4 notes 4 C.1.1 Selection of the approximation metho ds (4.4.3) 5 One can select the real approximation method for an entire program through the use of a module and 6 the parameterized real type. This is accomplished by defining a named integer constant to have a 7 particular kind type parameter value and using that named constant in all real, complex, and derived- 8 type declarations. For example, the specification statements 9 INTEGER, PARAMETER :: LONG_FLOAT = 8 10 REAL (LONG_FLOAT) X, Y 11 COMPLEX (LONG_FLOAT) Z 12 specify that the approximation method corresponding to a kind type parameter value of 8 is supplied for 13 the data ob jects X, Y, and Z in the program unit. The kind type parameter value LONG FLOAT can 14 be made available to an entire program by placing the INTEGER specification statement in a module 15 and accessing the named constant LONG FLOAT with a USE statement. Note that by changing 8 to 4 16 once in the module, a different approximation method is selected. 17 To avoid the use of the processor-dependent values 4 or 8, replace 8 by KIND (0.0) or KIND (0.0D0). 18 Another way to avoid these processor-dependent values is to select the kind value using the intrinsic 19 inquiry function SELECTED REAL KIND. This function, given integer arguments P and R specifying 20 minimum requirements for decimal precision and decimal exponent range, respectively, returns the kind 21 type parameter value of the approximation method that has at least P decimal digits of precision and 22 at least a range for positive numbers of 10-R to 10R . In the above specification statement, the 8 may be 23 replaced by, for instance, SELECTED REAL KIND (10, 50), which requires an approximation method 24 to be selected with at least 10 decimal digits of precision and a range from 10-50 to 1050 . There are no 25 magnitude or ordering constraints placed on kind values, in order that implementers may have flexibility 26 in assigning such values and may add new kinds without changing previously assigned kind values. 27 As kind values have no portable meaning, a good practice is to use them in programs only through 28 named constants as described above (for example, SINGLE, IEEE SINGLE, DOUBLE, and QUAD), 29 rather than using the kind values directly. 30 C.1.2 Type extension and comp onent accessibility (4.5.2.2, 4.5.4) 31 The default accessibility of an extended type may be specified in the type definition. The accessibility 32 of its components may be specified individually. 33 module types 34 type base_type 35 private !-- Sets default accessibility 36 527 J3/06-007 WORKING DRAFT 2006/07/11 integer :: i !-- a private component 1 integer, private :: j !-- another private component 2 integer, public :: k !-- a public component 3 end type base_type 4 5 type, extends(base_type) :: my_type 6 private !-- Sets default for components declared in my_type 7 integer :: l !-- A private component. 8 integer, public :: m !-- A public component. 9 end type my_type 10 11 end module types 12 13 subroutine sub 14 use types 15 type (my_type) :: x 16 17 .... 18 19 call another_sub( & 20 x%base_type, & !-- ok because base_type is a public subobject of x 21 x%base_type%k, & !-- ok because x%base_type is ok and has k as a 22 !-- public component. 23 x%k, & !-- ok because it is shorthand for x%base_type%k 24 x%base_type%i, & !-- Invalid because i is private. 25 x%i) !-- Invalid because it is shorthand for x%base_type%i 26 end subroutine sub 27 C.1.3 Abstract types 28 The following defines an ob ject that can be displayed in an X window: 29 TYPE, ABSTRACT :: DRAWABLE_OBJECT 30 REAL, DIMENSION(3) :: RGB_COLOR=(/1.0,1.0,1.0/) ! White 31 REAL, DIMENSION(2) :: POSITION=(/0.0,0.0/) ! Centroid 32 CONTAINS 33 PROCEDURE(RENDER_X), PASS(OBJECT), DEFERRED :: RENDER 34 END TYPE DRAWABLE_OBJECT 35 36 ABSTRACT INTERFACE 37 SUBROUTINE RENDER_X(OBJECT, WINDOW) 38 CLASS(DRAWABLE_OBJECT), INTENT(IN) :: OBJECT 39 CLASS(X_WINDOW), INTENT(INOUT) :: WINDOW 40 END SUBROUTINE RENDER_X 41 END INTERFACE 42 528 2006/07/11 WORKING DRAFT J3/06-007 We can declare a nonabstract type by extending the abstract type: 1 TYPE, EXTENDS(DRAWABLE_OBJECT) :: DRAWABLE_TRIANGLE ! Not ABSTRACT 2 REAL, DIMENSION(2,3) :: VERTICES ! In relation to centroid 3 CONTAINS 4 PROCEDURE, PASS(OBJECT) :: RENDER=>RENDER_TRIANGLE_X 5 END TYPE DRAWABLE_TRIANGLE 6 The actual drawing procedure will draw a triangle in WINDOW with vertices at x coordinates 7 OBJECT%POSITION(1)+OBJECT%VERTICES(1,:) and y coordinates 8 OBJECT%POSITION(2)+OBJECT%VERTICES(2,:): 9 SUBROUTINE RENDER_TRIANGLE_X(OBJECT, WINDOW) 10 CLASS(DRAWABLE_TRIANGLE), INTENT(IN) :: OBJECT 11 CLASS(X_WINDOW), INTENT(INOUT) :: WINDOW 12 ... 13 END SUBROUTINE RENDER_TRIANGLE_X 14 C.1.4 Pointers (4.5.2) 15 Pointers are names that can change dynamically their association with a target ob ject. In a sense, a 16 normal variable is a name with a fixed association with a particular ob ject. A normal variable name 17 refers to the same storage space throughout the lifetime of the variable. A pointer name may refer 18 to different storage space, or even no storage space, at different times. A variable may be considered 19 to be a descriptor for space to hold values of the appropriate type, type parameters, and array rank 20 such that the values stored in the descriptor are fixed when the variable is created. A pointer also may 21 be considered to be a descriptor, but one whose values may be changed dynamically so as to describe 22 different pieces of storage. When a pointer is declared, space to hold the descriptor is created, but the 23 space for the target ob ject is not created. 24 A derived type may have one or more components that are defined to be pointers. It may have a 25 component that is a pointer to an ob ject of the same derived type. This "recursive" data definition 26 allows dynamic data structures such as linked lists, trees, and graphs to be constructed. For example: 27 TYPE NODE ! Define a ''recursive'' type 28 INTEGER :: VALUE = 0 29 TYPE (NODE), POINTER :: NEXT_NODE => NULL ( ) 30 END TYPE NODE 31 32 TYPE (NODE), TARGET :: HEAD ! Automatically initialized 33 TYPE (NODE), POINTER :: CURRENT, TEMP ! Declare pointers 34 INTEGER :: IOEM, K 35 36 CURRENT => HEAD ! CURRENT points to head of list 37 38 DO 39 READ (*, *, IOSTAT = IOEM) K ! Read next value, if any 40 529 J3/06-007 WORKING DRAFT 2006/07/11 IF (IOEM /= 0) EXIT 1 ALLOCATE (TEMP) ! Create new cell each iteration 2 TEMP % VALUE = K ! Assign value to cell 3 CURRENT % NEXT_NODE => TEMP ! Attach new cell to list 4 CURRENT => TEMP ! CURRENT points to new end of list 5 END DO 6 A list is now constructed and the last linked cell contains a disassociated pointer. A loop can be used 7 to "walk through" the list. 8 CURRENT => HEAD 9 DO 10 IF (.NOT. ASSOCIATED (CURRENT % NEXT_NODE)) EXIT 11 CURRENT => CURRENT % NEXT_NODE 12 WRITE (*, *) CURRENT % VALUE 13 END DO 14 C.1.5 Structure constructors and generic names 15 A generic name may be the same as a type name. This can be used to emulate user-defined structure 16 constructors for that type, even if the type has private components. For example: 17 MODULE mytype_module 18 TYPE mytype 19 PRIVATE 20 COMPLEX value 21 LOGICAL exact 22 END TYPE 23 INTERFACE mytype 24 MODULE PROCEDURE int_to_mytype 25 END INTERFACE 26 ! Operator definitions etc. 27 ... 28 CONTAINS 29 TYPE(mytype) FUNCTION int_to_mytype(i) 30 INTEGER,INTENT(IN) :: i 31 int_to_mytype%value = i 32 int_to_mytype%exact = .TRUE. 33 END FUNCTION 34 ! Procedures to support operators etc. 35 ... 36 END 37 38 PROGRAM example 39 USE mytype_module 40 530 2006/07/11 WORKING DRAFT J3/06-007 TYPE(mytype) x 1 x = mytype(17) 2 END 3 The type name may still be used as a generic name if the type has type parameters. For example: 4 MODULE m 5 TYPE t(kind) 6 INTEGER, KIND :: kind 7 COMPLEX(kind) value 8 END TYPE 9 INTEGER,PARAMETER :: single = KIND(0.0), double = KIND(0d0) 10 INTERFACE t 11 MODULE PROCEDURE real_to_t1, dble_to_t2, int_to_t1, int_to_t2 12 END INTERFACE 13 ... 14 CONTAINS 15 TYPE(t(single)) FUNCTION real_to_t1(x) 16 REAL(single) x 17 real_to_t1%value = x 18 END FUNCTION 19 TYPE(t(double)) FUNCTION dble_to_t2(x) 20 REAL(double) x 21 dble_to_t2%value = x 22 END FUNCTION 23 TYPE(t(single)) FUNCTION int_to_t1(x,mold) 24 INTEGER x 25 TYPE(t(single)) mold 26 int_to_t1%value = x 27 END FUNCTION 28 TYPE(t(double)) FUNCTION int_to_t2(x,mold) 29 INTEGER x 30 TYPE(t(double)) mold 31 int_to_t2%value = x 32 END FUNCTION 33 ... 34 END 35 36 PROGRAM example 37 USE m 38 TYPE(t(single)) x 39 TYPE(t(double)) y 40 x = t(1.5) ! References real_to_t1 41 x = t(17,mold=x) ! References int_to_t1 42 y = t(1.5d0) ! References dble_to_t2 43 531 J3/06-007 WORKING DRAFT 2006/07/11 y = t(42,mold=y) ! References int_to_t2 1 y = t(kind(0d0)) ((0,1)) ! Uses the structure constructor for type t 2 END 3 C.1.6 Generic type-b ound pro cedures 4 Example of a derived type with generic type-bound procedures: 5 The only difference between this example and the same thing rewritten to use generic interface blocks 6 is that with type-bound procedures, 7 USE(rational_numbers),ONLY :: rational 8 does not block the type-bound procedures; the user still gets access to the defined assignment and 9 extended operations. 10 MODULE rational_numbers 11 IMPLICIT NONE 12 PRIVATE 13 TYPE,PUBLIC :: rational 14 PRIVATE 15 INTEGER n,d 16 CONTAINS 17 ! ordinary type-bound procedure 18 PROCEDURE :: real => rat_to_real 19 ! specific type-bound procedures for generic support 20 PROCEDURE,PRIVATE :: rat_asgn_i 21 PROCEDURE,PRIVATE :: rat_plus_rat 22 PROCEDURE,PRIVATE :: rat_plus_i 23 PROCEDURE,PRIVATE,PASS(b) :: i_plus_rat 24 ! generic type-bound procedures 25 GENERIC :: ASSIGNMENT(=) => rat_asgn_i 26 GENERIC :: OPERATOR(+) => rat_plus_rat, rat_plus_i, i_plus_rat 27 END TYPE 28 CONTAINS 29 ELEMENTAL REAL FUNCTION rat_to_real(this) RESULT(r) 30 CLASS(rational),INTENT(IN) :: this 31 r = REAL(this%n)/this%d 32 END FUNCTION 33 ELEMENTAL SUBROUTINE rat_asgn_i(a,b) 34 CLASS(rational),INTENT(OUT) :: a 35 INTEGER,INTENT(IN) :: b 36 a%n = b 37 a%d = 1 38 END SUBROUTINE 39 ELEMENTAL TYPE(rational) FUNCTION rat_plus_i(a,b) RESULT(r) 40 532 2006/07/11 WORKING DRAFT J3/06-007 CLASS(rational),INTENT(IN) :: a 1 INTEGER,INTENT(IN) :: b 2 r%n = a%n + b*a%d 3 r%d = a%d 4 END FUNCTION 5 ELEMENTAL TYPE(rational) FUNCTION i_plus_rat(a,b) RESULT(r) 6 INTEGER,INTENT(IN) :: a 7 CLASS(rational),INTENT(IN) :: b 8 r%n = b%n + a*b%d 9 r%d = b%d 10 END FUNCTION 11 ELEMENTAL TYPE(rational) FUNCTION rat_plus_rat(a,b) RESULT(r) 12 CLASS(rational),INTENT(IN) :: a,b 13 r%n = a%n*b%d + b%n*a%d 14 r%d = a%d*b%d 15 END FUNCTION 16 END 17 C.1.7 Final subroutines (4.5.6, 4.5.6.2, 4.5.6.3, 4.5.6.4) 18 Example of a parameterized derived type with final subroutines: 19 MODULE m 20 TYPE t(k) 21 INTEGER, KIND :: k 22 REAL(k),POINTER :: vector(:) => NULL() 23 CONTAINS 24 FINAL :: finalize_t1s, finalize_t1v, finalize_t2e 25 END TYPE 26 CONTAINS 27 SUBROUTINE finalize_t1s(x) 28 TYPE(t(KIND(0.0))) x 29 IF (ASSOCIATED(x%vector)) DEALLOCATE(x%vector) 30 END SUBROUTINE 31 SUBROUTINE finalize_t1v(x) 32 TYPE(t(KIND(0.0))) x(:) 33 DO i=LBOUND(x,1),UBOUND(x,1) 34 IF (ASSOCIATED(x(i)%vector)) DEALLOCATE(x(i)%vector) 35 END DO 36 END SUBROUTINE 37 ELEMENTAL SUBROUTINE finalize_t2e(x) 38 TYPE(t(KIND(0.0d0))),INTENT(INOUT) :: x 39 IF (ASSOCIATED(x%vector)) DEALLOCATE(x%vector) 40 END SUBROUTINE 41 END MODULE 42 533 J3/06-007 WORKING DRAFT 2006/07/11 1 SUBROUTINE example(n) 2 USE m 3 TYPE(t(KIND(0.0))) a,b(10),c(n,2) 4 TYPE(t(KIND(0.0d0))) d(n,n) 5 ... 6 ! Returning from this subroutine will effectively do 7 ! CALL finalize_t1s(a) 8 ! CALL finalize_t1v(b) 9 ! CALL finalize_t2e(d) 10 ! No final subroutine will be called for variable C because the user 11 ! omitted to define a suitable specific procedure for it. 12 END SUBROUTINE 13 Example of extended types with final subroutines: 14 MODULE m 15 TYPE t1 16 REAL a,b 17 END TYPE 18 TYPE,EXTENDS(t1) :: t2 19 REAL,POINTER :: c(:),d(:) 20 CONTAINS 21 FINAL :: t2f 22 END TYPE 23 TYPE,EXTENDS(t2) :: t3 24 REAL,POINTER :: e 25 CONTAINS 26 FINAL :: t3f 27 END TYPE 28 ... 29 CONTAINS 30 SUBROUTINE t2f(x) ! Finalizer for TYPE(t2)'s extra components 31 TYPE(t2) :: x 32 IF (ASSOCIATED(x%c)) DEALLOCATE(x%c) 33 IF (ASSOCIATED(x%d)) DEALLOCATE(x%d) 34 END SUBROUTINE 35 SUBROUTINE t3f(y) ! Finalizer for TYPE(t3)'s extra components 36 TYPE(t3) :: y 37 IF (ASSOCIATED(y%e)) DEALLOCATE(y%e) 38 END SUBROUTINE 39 END MODULE 40 41 SUBROUTINE example 42 USE m 43 534 2006/07/11 WORKING DRAFT J3/06-007 TYPE(t1) x1 1 TYPE(t2) x2 2 TYPE(t3) x3 3 ... 4 ! Returning from this subroutine will effectively do 5 ! ! Nothing to x1; it is not finalizable 6 ! CALL t2f(x2) 7 ! CALL t3f(x3) 8 ! CALL t2f(x3%t2) 9 END SUBROUTINE 10 C.2 Clause 5 notes 11 C.2.1 The POINTER attribute (5.3.13) 12 The POINTER attribute shall be specified to declare a pointer. The type, type parameters, and rank, 13 which may be specified in the same statement or with one or more attribute specification statements, 14 determine the characteristics of the target ob jects that may be associated with the pointers declared 15 in the statement. An obvious model for interpreting declarations of pointers is that such declarations 16 create for each name a descriptor. Such a descriptor includes all the data necessary to describe fully 17 and locate in memory an ob ject and all subob jects of the type, type parameters, and rank specified. 18 The descriptor is created empty; it does not contain values describing how to access an actual memory 19 space. These descriptor values will be filled in when the pointer is associated with actual target space. 20 The following example illustrates the use of pointers in an iterative algorithm: 21 PROGRAM DYNAM_ITER 22 REAL, DIMENSION (:, :), POINTER :: A, B, SWAP ! Declare pointers 23 ... 24 READ (*, *) N, M 25 ALLOCATE (A (N, M), B (N, M)) ! Allocate target arrays 26 ! Read values into A 27 ... 28 ITER: DO 29 ... 30 ! Apply transformation of values in A to produce values in B 31 ... 32 IF (CONVERGED) EXIT ITER 33 ! Swap A and B 34 SWAP => A; A => B; B => SWAP 35 END DO ITER 36 ... 37 END PROGRAM DYNAM_ITER 38 535 J3/06-007 WORKING DRAFT 2006/07/11 C.2.2 The TARGET attribute (5.3.16) 1 The TARGET attribute shall be specified for any nonpointer ob ject that may, during the execution of the 2 program, become associated with a pointer. This attribute is defined primarily for optimization purposes. 3 It allows the processor to assume that any nonpointer ob ject not explicitly declared as a target may 4 be referred to only by way of its original declared name. It also means that implicitly-declared ob jects 5 shall not be used as pointer targets. This will allow a processor to perform optimizations that otherwise 6 would not be possible in the presence of certain pointers. 7 The following example illustrates the use of the TARGET attribute in an iterative algorithm: 8 PROGRAM ITER 9 REAL, DIMENSION (1000, 1000), TARGET :: A, B 10 REAL, DIMENSION (:, :), POINTER :: IN, OUT, SWAP 11 ... 12 ! Read values into A 13 ... 14 IN => A ! Associate IN with target A 15 OUT => B ! Associate OUT with target B 16 ... 17 ITER:DO 18 ... 19 ! Apply transformation of IN values to produce OUT 20 ... 21 IF (CONVERGED) EXIT ITER 22 ! Swap IN and OUT 23 SWAP => IN; IN => OUT; OUT => SWAP 24 END DO ITER 25 ... 26 END PROGRAM ITER 27 C.2.3 The VOLATILE attribute (5.3.18) 28 The following example shows the use of a variable with the VOLATILE attribute to communicate with 29 an asynchronous process, in this case the operating system. The program detects a user keystroke on 30 the terminal and reacts at a convenient point in its processing. 31 The VOLATILE attribute is necessary to prevent an optimizing compiler from storing the communication 32 variable in a register or from doing flow analysis and deciding that the EXIT statement can never be 33 executed. 34 SUBROUTINE TERMINATE_ITERATIONS 35 36 LOGICAL, VOLATILE :: USER_HIT_ANY_KEY 37 38 ! Have the OS start to look for a user keystroke and set the variable 39 ! "USER_HIT_ANY_KEY" to TRUE as soon as it detects a keystroke. 40 ! This pseudo call is operating system dependent. 41 536 2006/07/11 WORKING DRAFT J3/06-007 1 CALL OS_BEGIN_DETECT_USER_KEYSTROKE( USER_HIT_ANY_KEY ) 2 3 USER_HIT_ANY_KEY = .FALSE. ! This will ignore any recent keystrokes 4 5 PRINT *, " Hit any key to terminate iterations!" 6 7 DO I = 1,100 8 ... ! Compute a value for R 9 PRINT *, I, R 10 IF (USER_HIT_ANY_KEY) EXIT 11 ENDDO 12 13 ! Have the OS stop looking for user keystrokes 14 CALL OS_STOP_DETECT_USER_KEYSTROKE 15 16 END SUBROUTINE TERMINATE_ITERATIONS 17 C.3 Clause 6 notes 18 C.3.1 Structure comp onents (6.1.2) 19 Components of a structure are referenced by writing the components of successive levels of the structure 20 hierarchy until the desired component is described. For example, 21 TYPE ID_NUMBERS 22 INTEGER SSN 23 INTEGER EMPLOYEE_NUMBER 24 END TYPE ID_NUMBERS 25 26 TYPE PERSON_ID 27 CHARACTER (LEN=30) LAST_NAME 28 CHARACTER (LEN=1) MIDDLE_INITIAL 29 CHARACTER (LEN=30) FIRST_NAME 30 TYPE (ID_NUMBERS) NUMBER 31 END TYPE PERSON_ID 32 33 TYPE PERSON 34 INTEGER AGE 35 TYPE (PERSON_ID) ID 36 END TYPE PERSON 37 38 TYPE (PERSON) GEORGE, MARY 39 40 PRINT *, GEORGE % AGE ! Print the AGE component 41 537 J3/06-007 WORKING DRAFT 2006/07/11 PRINT *, MARY % ID % LAST_NAME ! Print LAST_NAME of MARY 1 PRINT *, MARY % ID % NUMBER % SSN ! Print SSN of MARY 2 PRINT *, GEORGE % ID % NUMBER ! Print SSN and EMPLOYEE_NUMBER of GEORGE 3 A structure component may be a data ob ject of intrinsic type as in the case of GEORGE % AGE or it 4 may be of derived type as in the case of GEORGE % ID % NUMBER. The resultant component may 5 be a scalar or an array of intrinsic or derived type. 6 TYPE LARGE 7 INTEGER ELT (10) 8 INTEGER VAL 9 END TYPE LARGE 10 11 TYPE (LARGE) A (5) ! 5 element array, each of whose elements 12 ! includes a 10 element array ELT and 13 ! a scalar VAL. 14 PRINT *, A (1) ! Prints 10 element array ELT and scalar VAL. 15 PRINT *, A (1) % ELT (3) ! Prints scalar element 3 16 ! of array element 1 of A. 17 PRINT *, A (2:4) % VAL ! Prints scalar VAL for array elements 18 ! 2 to 4 of A. 19 Components of an ob ject of extensible type that are inherited from the parent type may be accessed as 20 a whole by using the parent component name, or individually, either with or without qualifying them 21 by the parent component name. 22 For example: 23 TYPE POINT ! A base type 24 REAL :: X, Y 25 END TYPE POINT 26 TYPE, EXTENDS(POINT) :: COLOR_POINT ! An extension of TYPE(POINT) 27 ! Components X and Y, and component name POINT, inherited from parent 28 INTEGER :: COLOR 29 END TYPE COLOR_POINT 30 31 TYPE(POINT) :: PV = POINT(1.0, 2.0) 32 TYPE(COLOR_POINT) :: CPV = COLOR_POINT(PV, 3) ! Nested form constructor 33 34 PRINT *, CPV%POINT ! Prints 1.0 and 2.0 35 PRINT *, CPV%POINT%X, CPV%POINT%Y ! And this does, too 36 PRINT *, CPV%X, CPV%Y ! And this does, too 37 C.3.2 Allo cation with dynamic typ e (6.3.1) 38 The following example illustrates the use of allocation with the value and dynamic type of the allocated 39 ob ject given by another ob ject. The example copies a list of ob jects of any type. It copies the list 40 538 2006/07/11 WORKING DRAFT J3/06-007 starting at IN LIST. After copying, each element of the list starting at LIST COPY has a polymorphic 1 component, ITEM, for which both the value and type are taken from the ITEM component of the 2 corresponding element of the list starting at IN LIST. 3 TYPE :: LIST ! A list of anything 4 TYPE(LIST), POINTER :: NEXT => NULL() 5 CLASS(*), ALLOCATABLE :: ITEM 6 END TYPE LIST 7 ... 8 TYPE(LIST), POINTER :: IN_LIST, LIST_COPY => NULL() 9 TYPE(LIST), POINTER :: IN_WALK, NEW_TAIL 10 ! Copy IN_LIST to LIST_COPY 11 IF (ASSOCIATED(IN_LIST)) THEN 12 IN_WALK => IN_LIST 13 ALLOCATE(LIST_COPY) 14 NEW_TAIL => LIST_COPY 15 DO 16 ALLOCATE(NEW_TAIL%ITEM, SOURCE=IN_WALK%ITEM) 17 IN_WALK => IN_WALK%NEXT 18 IF (.NOT. ASSOCIATED(IN_WALK)) EXIT 19 ALLOCATE(NEW_TAIL%NEXT) 20 NEW_TAIL => NEW_TAIL%NEXT 21 END DO 22 END IF 23 C.3.3 Pointer allo cation and asso ciation 24 The effect of ALLOCATE, DEALLOCATE, NULLIFY, and pointer assignment is that they are inter- 25 preted as changing the values in the descriptor that is the pointer. An ALLOCATE is assumed to create 26 space for a suitable ob ject and to "assign" to the pointer the values necessary to describe that space. 27 A NULLIFY breaks the association of the pointer with the space. A DEALLOCATE breaks the asso- 28 ciation and releases the space. Depending on the implementation, it could be seen as setting a flag in 29 the pointer that indicates whether the values in the descriptor are valid, or it could clear the descriptor 30 values to some (say zero) value indicative of the pointer not pointing to anything. A pointer assignment 31 copies the values necessary to describe the space occupied by the target into the descriptor that is the 32 pointer. Descriptors are copied, values of ob jects are not. 33 If PA and PB are both pointers and PB is associated with a target, then 34 PA => PB 35 results in PA being associated with the same target as PB. If PB was disassociated, then PA becomes 36 disassociated. 37 The standard is specified so that such associations are direct and independent. A subsequent statement 38 PB => D 39 or 40 ALLOCATE (PB) 41 539 J3/06-007 WORKING DRAFT 2006/07/11 has no effect on the association of PA with its target. A statement 1 DEALLOCATE (PB) 2 deallocates the space that is associated with both PA and PB. PB becomes disassociated, but there is 3 no requirement that the processor make it explicitly recognizable that PA no longer has a target. This 4 leaves PA as a "dangling pointer" to space that has been released. The program shall not use PA again 5 until it becomes associated via pointer assignment or an ALLOCATE statement. 6 DEALLOCATE may only be used to release space that was created by a previous ALLOCATE. Thus 7 the following is invalid: 8 REAL, TARGET :: T 9 REAL, POINTER :: P 10 ... 11 P=> T 12 DEALLOCATE (P) ! Not allowed: P's target was not allocated 13 The basic principle is that ALLOCATE, NULLIFY, and pointer assignment primarily affect the pointer 14 rather than the target. ALLOCATE creates a new target but, other than breaking its connection with 15 the specified pointer, it has no effect on the old target. Neither NULLIFY nor pointer assignment has 16 any effect on targets. A piece of memory that was allocated and associated with a pointer will become 17 inaccessible to a program if the pointer is nullified or associated with a different target and no other 18 pointer was associated with this piece of memory. Such pieces of memory may be reused by the processor 19 if this is expedient. However, whether such inaccessible memory is in fact reused is entirely processor 20 dependent. 21 C.4 Clause 7 notes 22 C.4.1 Character assignment 23 The Fortran 77 restriction that none of the character positions being defined in the character assign- 24 ment statement may be referenced in the expression has been removed (7.4.1.3). 25 C.4.2 Evaluation of function references 26 If more than one function reference appears in a statement, they may be executed in any order (sub ject to 27 a function result being evaluated after the evaluation of its arguments) and their values shall not depend 28 on the order of execution. This lack of dependence on order of evaluation permits parallel execution of 29 the function references (7.1.8.1). 30 C.4.3 Pointers in expressions 31 A pointer is basically considered to be like any other variable when it is used as a primary in an expression. 32 If a pointer is used as an operand to an operator that expects a value, the pointer will automatically 33 deliver the value stored in the space described by the pointer, that is, the value of the target ob ject 34 associated with the pointer. 35 C.4.4 Pointers on the left side of an assignment 36 A pointer that appears on the left of an intrinsic assignment statement also is dereferenced and is taken 37 to be referring to the space that is its current target. Therefore, the assignment statement specifies the 38 540 2006/07/11 WORKING DRAFT J3/06-007 normal copying of the value of the right-hand expression into this target space. All the normal rules of 1 intrinsic assignment hold; the type and type parameters of the expression and the pointer target shall 2 agree and the shapes shall be conformable. 3 For intrinsic assignment of derived types, nonpointer components are assigned and pointer components 4 are pointer assigned. Dereferencing is applied only to entire scalar ob jects, not selectively to pointer 5 subob jects. 6 For example, suppose a type such as 7 TYPE CELL 8 INTEGER :: VAL 9 TYPE (CELL), POINTER :: NEXT_CELL 10 END TYPE CELL 11 is defined and ob jects such as HEAD and CURRENT are declared using 12 TYPE (CELL), TARGET :: HEAD 13 TYPE (CELL), POINTER :: CURRENT 14 If a linked list has been created and attached to HEAD and the pointer CURRENT has been allocated 15 space, statements such as 16 CURRENT = HEAD 17 CURRENT = CURRENT % NEXT CELL 18 cause the contents of the cells referenced on the right to be copied to the cell referred to by CURRENT. 19 In particular, the right-hand side of the second statement causes the pointer component in the cell, 20 CURRENT, to be selected. This pointer is dereferenced because it is in an expression context to produce 21 the target's integer value and a pointer to a cell that is in the target's NEXT CELL component. The 22 left-hand side causes the pointer CURRENT to be dereferenced to produce its present target, namely 23 space to hold a cell (an integer and a cell pointer). The integer value on the right is copied to the integer 24 space on the left and the pointer component is pointer assigned (the descriptor on the right is copied 25 into the space for a descriptor on the left). When a statement such as 26 CURRENT => CURRENT % NEXT CELL 27 is executed, the descriptor value in CURRENT % NEXT CELL is copied to the descriptor named 28 CURRENT. In this case, CURRENT is made to point at a different target. 29 In the intrinsic assignment statement, the space associated with the current pointer does not change but 30 the values stored in that space do. In the pointer assignment, the current pointer is made to associate 31 with different space. Using the intrinsic assignment causes a linked list of cells to be moved up through 32 the current "window"; the pointer assignment causes the current pointer to be moved down through the 33 list of cells. 34 C.4.5 An example of a FORALL construct containing a WHERE construct 35 INTEGER :: A(5,5) 36 ... 37 FORALL (I = 1:5) 38 WHERE (A(I,:) == 0) 39 541 J3/06-007 WORKING DRAFT 2006/07/11 A(:,I) = I 1 ELSEWHERE (A(I,:) > 2) 2 A(I,:) = 6 3 END WHERE 4 END FORALL 5 If prior to execution of the FORALL, A has the value 6 A= 1 0 0 0 0 7 2 1 1 1 0 8 1 2 2 0 2 9 2 1 0 2 3 10 1 0 0 0 0 11 After execution of the assignment statements following the WHERE statement A has the value A'. The 12 mask created from row one is used to mask the assignments to column one; the mask from row two is 13 used to mask assignments to column two; etc. 14 A' = 1 0 0 0 0 15 1 1 1 1 5 16 1 2 2 4 5 17 1 1 3 2 5 18 1 2 0 0 5 19 The masks created for assignments following the ELSEWHERE statement are 20 > 2) .NOT. (A(I,:) == 0) .AND. (A'(I,:) 21 Thus the only elements affected by the assignments following the ELSEWHERE statement are A(3, 5) 22 and A(4, 5). After execution of the FORALL construct, A has the value 23 A= 1 0 0 0 0 24 1 1 1 1 5 25 1 2 2 4 6 26 1 1 3 2 6 27 1 2 0 0 5 28 C.4.6 Examples of FORALL statements 29 Example 1: 30 FORALL (J=1:M, K=1:N) X(K, J) = Y(J, K) 31 FORALL (K=1:N) X(K, 1:M) = Y(1:M, K) 32 These statements both copy columns 1 through N of array Y into rows 1 through N of array X. They 33 are equivalent to 34 X(1:N, 1:M) = TRANSPOSE (Y(1:M, 1:N) ) 35 542 2006/07/11 WORKING DRAFT J3/06-007 Example 2: 1 The following FORALL statement computes five partial sums of subarrays of J. 2 J = (/ 1, 2, 3, 4, 5 /) 3 FORALL (K = 1:5) J(K) = SUM (J(1:K) ) 4 SUM is allowed in a FORALL because intrinsic functions are pure (12.7). After execution of the FORALL 5 statement, J = (/ 1, 3, 6, 10, 15 /). 6 Example 3: 7 FORALL (I = 2:N-1) X(I) = (X(I-1) + 2*X(I) + X(I+1) ) / 4 8 has the same effect as 9 X(2:N-1) = (X(1:N-2) + 2*X(2:N-1) + X(3:N) ) / 4 10 C.5 Clause 8 notes 11 C.5.1 Lo op control 12 Fortran provides several forms of loop control: 13 (1) With an iteration count and a DO variable. This is the classic Fortran DO loop. 14 (2) Test a logical condition before each execution of the loop (DO WHILE). 15 (3) DO "forever". 16 C.5.2 The CASE construct 17 At most one case block is selected for execution within a CASE construct, and there is no fall-through 18 from one block into another block within a CASE construct. Thus there is no requirement for the user 19 to exit explicitly from a block. 20 C.5.3 Examples of DO constructs 21 The following are all valid examples of block DO constructs. 22 Example 1: 23 SUM = 0.0 24 READ (IUN) N 25 OUTER: DO L = 1, N ! A DO with a construct name 26 READ (IUN) IQUAL, M, ARRAY (1:M) 27 IF (IQUAL < IQUAL_MIN) CYCLE OUTER ! Skip inner loop 28 INNER: DO 40 I = 1, M ! A DO with a label and a name 29 CALL CALCULATE (ARRAY (I), RESULT) 30 IF (RESULT < 0.0) CYCLE 31 SUM = SUM + RESULT 32 IF (SUM > SUM_MAX) EXIT OUTER 33 40 END DO INNER 34 END DO OUTER 35 543 J3/06-007 WORKING DRAFT 2006/07/11 The outer loop has an iteration count of MAX (N, 0), and will execute that number of times or until 1 SUM exceeds SUM MAX, in which case the EXIT OUTER statement terminates both loops. The inner 2 loop is skipped by the first CYCLE statement if the quality flag, IQUAL, is too low. If CALCULATE 3 returns a negative RESULT, the second CYCLE statement prevents it from being summed. Both loops 4 have construct names and the inner loop also has a label. A construct name is required in the EXIT 5 statement in order to terminate both loops, but is optional in the CYCLE statements because each 6 belongs to its innermost loop. 7 Example 2: 8 N=0 9 DO 50, I = 1, 10 10 J=I 11 DO K = 1, 5 12 L=K 13 N = N + 1 ! This statement executes 50 times 14 END DO ! Nonlabeled DO inside a labeled DO 15 50 CONTINUE 16 After execution of the above program fragment, I = 11, J = 10, K = 6, L = 5, and N = 50. 17 Example 3: 18 N=0 19 DO I = 1, 10 20 J=I 21 DO 60, K = 5, 1 ! This inner loop is never executed 22 L=K 23 N=N+1 24 60 CONTINUE ! Labeled DO inside a nonlabeled DO 25 END DO 26 After execution of the above program fragment, I = 11, J = 10, K = 5, N = 0, and L is not defined by 27 these statements. 28 29 The following are all valid examples of nonblo ck DO constructs: 30 Example 4: 31 DO 70 32 READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X 33 IF (IOS /= 0) EXIT 34 IF (X < 0.) GOTO 70 35 CALL SUBA (X) 36 CALL SUBB (X) 37 .. . 38 CALL SUBY (X) 39 CYCLE 40 70 CALL SUBNEG (X) ! SUBNEG called only when X < 0. 544 2006/07/11 WORKING DRAFT J3/06-007 1 This is not a blo ck DO construct b ecause it ends with a statement other than END DO or CONTINUE. The lo op will 2 continue to execute until an end-of-file condition or input/output error o ccurs. 3 Example 5: 4 SUM = 0.0 5 READ (IUN) N 6 DO 80, L = 1, N 7 READ (IUN) IQUAL, M, ARRAY (1:M) 8 IF (IQUAL < IQUAL_MIN) M = 0 ! Skip inner loop 9 DO 80 I = 1, M 10 CALL CALCULATE (ARRAY (I), RESULT) 11 IF (RESULT < 0.) CYCLE 12 SUM = SUM + RESULT 13 IF (SUM > SUM_MAX) GOTO 81 14 80 CONTINUE ! This CONTINUE is shared by both loops 15 81 CONTINUE 16 This example is similar to Example 1 ab ove, except that the two loops are not blo ck DO constructs because they share 17 the CONTINUE statement with the lab el 80. The terminal construct of the outer DO is the entire inner DO construct. 18 The inner lo op is skipp ed by forcing M to zero. If SUM grows to o large, b oth lo ops are terminated by branching to the 19 CONTINUE statement lab eled 81. The CYCLE statement in the inner loop is used to skip negative values of RESULT. 20 Example 6: 21 N=0 22 DO 100 I = 1, 10 23 J=I 24 DO 100 K = 1, 5 25 L=K 26 100 N = N + 1 ! This statement executes 50 times 27 In this example, the two loops share an assignment statement. After execution of this program fragment, I = 11, J = 10, 28 K = 6, L = 5, and N = 50. 29 Example 7: 30 N=0 31 DO 200 I = 1, 10 32 J=I 33 DO 200 K = 5, 1 ! This inner loop is never executed 34 L=K 35 200 N=N+1 36 This example is very similar to the previous one, except that the inner lo op is never executed. After execution of this 37 program fragment, I = 11, J = 10, K = 5, N = 0, and L is not defined by these statements. C.5.4 Examples of invalid DO constructs 38 The following are all examples of invalid skeleton DO constructs: 39 Example 1: 40 545 J3/06-007 WORKING DRAFT 2006/07/11 DO I = 1, 10 1 ... 2 END DO LOOP ! No matching construct name 3 Example 2: 4 LOOP: DO 1000 I = 1, 10 ! No matching construct name 5 ... 6 1000 CONTINUE 7 Example 3: 8 LOOP1: DO 9 ... 10 END DO LOOP2 ! Construct names don't match 11 Example 4: 12 DO I = 1, 10 ! Label required or ... 13 ... 14 1010 CONTINUE ! ... END DO required 15 Example 5: 16 DO 1020 I = 1, 10 17 ... 18 1021 END DO ! Labels don't match 19 Example 6: 20 FIRST: DO I = 1, 10 21 SECOND: DO J = 1, 5 22 ... 23 END DO FIRST ! Improperly nested DOs 24 END DO SECOND 25 C.6 Clause 9 notes 26 C.6.1 External files (9.2) 27 This standard accommodates, but does not require, file cataloging. To do this, several concepts are 28 introduced. 29 546 2006/07/11 WORKING DRAFT J3/06-007 C.6.1.1 File connection (9.4) 1 Before any input/output may be performed on a file, it shall be connected to a unit. The unit then serves 2 as a designator for that file as long as it is connected. To be connected does not imply that "buffers" 3 have or have not been allocated, that "file-control tables" have or have not been filled, or that any other 4 method of implementation has been used. Connection means that (barring some other fault) a READ 5 or WRITE statement may be executed on the unit, hence on the file. Without a connection, a READ 6 or WRITE statement shall not be executed. 7 C.6.1.2 File existence (9.2.1) 8 Totally independent of the connection state is the property of existence, this being a file property. The 9 processor "knows" of a set of files that exist at a given time for a given program. This set would include 10 tapes ready to read, files in a catalog, a keyboard, a printer, etc. The set may exclude files inaccessible 11 to the program because of security, because they are already in use by another program, etc. This 12 standard does not specify which files exist, hence wide latitude is available to a processor to implement 13 security, locks, privilege techniques, etc. Existence is a convenient concept to designate all of the files 14 that a program can potentially process. 15 All four combinations of connection and existence may occur: 16 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 Means are provided to create, delete, connect, and disconnect files. 17 C.6.1.3 File names (9.4.5.8) 18 A file may have a name. The form of a file name is not specified. If a system does not have some form of 19 cataloging or tape labeling for at least some of its files, all file names will disappear at the termination 20 of execution. This is a valid implementation. Nowhere does this standard require names to survive for 21 any period of time longer than the execution time span of a program. Therefore, this standard does not 22 impose cataloging as a prerequisite. The naming feature is intended to allow use of a cataloging system 23 where one exists. 24 C.6.1.4 File access (9.2.2) 25 This standard does not address problems of security, protection, locking, and many other concepts that 26 may be part of the concept of "right of access". Such concepts are considered to be in the province of 27 an operating system. 28 The OPEN and INQUIRE statements can be extended naturally to consider these things. 29 Possible access methods for a file are: sequential and direct. The processor may implement two different 30 types of files, each with its own access method. It might also implement one type of file with two different 31 access methods. 32 Direct access to files is of a simple and commonly available type, that is, fixed-length records. The key 33 is a positive integer. 34 547 J3/06-007 WORKING DRAFT 2006/07/11 C.6.2 Nonadvancing input/output (9.2.3.1) 1 Data transfer statements affect the positioning of an external file. In Fortran 77, if no error or end-of- 2 file condition exists, the file is positioned after the record just read or written and that record becomes 3 the preceding record. This standard contains the record positioning ADVANCE= specifier in a data 4 transfer statement that provides the capability of maintaining a position within the current record from 5 one formatted data transfer statement to the next data transfer statement. The value NO provides this 6 capability. The value YES positions the file after the record just read or written. The default is YES. 7 The tab edit descriptor and the slash are still appropriate for use with this type of record access but the 8 tab will not reposition before the left tab limit. 9 A BACKSPACE of a file that is positioned within a record causes the specified unit to be positioned 10 before the current record. 11 If the last data transfer statement was WRITE and the file is positioned within a record, the file will be 12 positioned implicitly after the current record before an ENDFILE record is written to the file, that is, a 13 REWIND, BACKSPACE, or ENDFILE statement following a nonadvancing WRITE statement causes 14 the file to be positioned at the end of the current output record before the endfile record is written to 15 the file. 16 This standard provides a SIZE= specifier to be used with nonadvancing data transfer statements. The 17 variable in the SIZE= specifier will contain the count of the number of characters that make up the 18 sequence of values read by the data edit descriptors in this input statement. 19 The count is especially helpful if there is only one list item in the input list because it will contain the 20 number of characters that were present for the item. 21 The EOR= specifier is provided to indicate when an end-of-record condition has been encountered during 22 a nonadvancing data transfer statement. The end-of-record condition is not an error condition. If this 23 specifier is present, the current input list item that required more characters than the record contained 24 will be padded with blanks if PAD= 'YES' is in effect. This means that the input list item was successfully 25 completed. The file will then be positioned after the current record. The IOSTAT= specifier, if present, 26 will be defined with the value of the named constant IOSTAT EOR from the ISO FORTRAN ENV 27 module and the data transfer statement will be terminated. Program execution will continue with the 28 statement specified in the EOR= specifier. The EOR= specifier gives the capability of taking control 29 of execution when the end-of-record has been found. The do-variable s in io-implied-do s retain their 30 last defined value and any remaining items in the input-item-list retain their definition status when an 31 end-of-record condition occurs. The SIZE= specifier, if present, will contain the number of characters 32 read with the data edit descriptors during this READ statement. 33 For nonadvancing input, the processor is not required to read partial records. The processor may read 34 the entire record into an internal buffer and make successive portions of the record available to successive 35 input statements. 36 In an implementation of nonadvancing input/output in which a nonadvancing write to a terminal device 37 causes immediate display of the output, such a write can be used as a mechanism to output a prompt. 38 In this case, the statement 39 WRITE (*, FMT='(A)', ADVANCE='NO') 'CONTINUE?(Y/N): ' 40 would result in the prompt 41 CONTINUE?(Y/N): 42 being displayed with no subsequent line feed. 43 548 2006/07/11 WORKING DRAFT J3/06-007 The response, which might be read by a statement of the form 1 READ (*, FMT='(A)') ANSWER 2 can then be entered on the same line as the prompt as in 3 CONTINUE?(Y/N): Y 4 The standard does not require that an implementation of nonadvancing input/output operate in this 5 manner. For example, an implementation of nonadvancing output in which the display of the output is 6 deferred until the current record is complete is also standard-conforming. Such an implementation will 7 not, however, allow a prompting mechanism of this kind to operate. 8 C.6.3 Asynchronous input/output 9 Rather than limit support for asynchronous input/output to what has been traditionally provided by 10 facilities such as BUFFERIN/BUFFEROUT, this standard builds upon existing Fortran syntax. This 11 permits alternative approaches for implementing asynchronous input/output, and simplifies the task of 12 adapting existing standard-conforming programs to use asynchronous input/output. 13 Not all processors will actually perform input/output asynchronously, nor will every processor that does 14 be able to handle data transfer statements with complicated input/output item lists in an asynchronous 15 manner. Such processors can still be standard-conforming. Hopefully, the documentation for each 16 Fortran processor will describe when, if ever, input/output will be performed asynchronously. 17 This standard allows for at least two different conceptual models for asynchronous input/output. 18 Model 1: the processor will perform asynchronous input/output when the item list is simple (perhaps 19 one contiguous named array) and the input/output is unformatted. The implementation cost is reduced, 20 and this is the scenario most likely to be beneficial on traditional "big-iron" machines. 21 Model 2: The processor is free to do any of the following: 22 (1) on output, create a buffer inside the input/output library, completely formatted, and then 23 start an asynchronous write of the buffer, and immediately return to the next statement in 24 the program. The processor is free to wait for previously issued WRITEs, or not, or 25 (2) pass the input/output list addresses to another processor/process, which will process the 26 list items independently of the processor that executes the user's code. The addresses of the 27 list items must be computed before the asynchronous READ/WRITE statement completes. 28 There is still an ordering requirement on list item processing to handle things like READ 29 (...) N,(a(i),i=1,N). 30 The standard allows a user to issue a large number of asynchronous input/output requests, without 31 waiting for any of them to complete, and then wait for any or all of them. It may be impossible, and 32 undesirable to keep track of each of these input/output requests individually. 33 It is not necessary for all requests to be tracked by the runtime library. If an ID= specifier does not 34 appear in on a READ or WRITE statement, the runtime is free to forget about this particular request 35 once it has successfully completed. If it gets an ERR or END condition, the processor is free to report 36 this during any input/output operation to that unit. When an ID= specifier is present, the processor's 37 runtime input/output library is required to keep track of any END or ERR conditions for that particular 38 input/output request. However, if the input/output request succeeds without any exceptional conditions 39 occurring, then the runtime can forget that ID= value if it wishes. Typically, a runtime might only keep 40 track of the last request made, or perhaps a very few. Then, when a user WAITs for a particular request, 41 either the library knows about it (and does the right thing with respect to error handling, etc.), or will 42 assume it is one of those requests that successfully completed and was forgotten about (and will just 43 return without signaling any end or error conditions). It is incumbent on the user to pass valid ID= 44 549 J3/06-007 WORKING DRAFT 2006/07/11 values. There is no requirement on the processor to detect invalid ID= values. There is of course, 1 a processor dependent limit on how many outstanding input/output requests that generate an end or 2 error condition can be handled before the processor runs out of memory to keep track of such conditions. 3 The restrictions on the SIZE= variables are designed to allow the processor to update such variables at 4 any time (after the request has been processed, but before the WAIT operation), and then forget about 5 them. That's why there is no SIZE= specifier allowed in the various WAIT operations. Only exceptional 6 conditions (errors or ends of files) are expected to be tracked by individual request by the runtime, and 7 then only if an ID= specifier was present. The END= and EOR= specifiers have not been added to all 8 statements that can be WAIT operations. Instead, the IOSTAT variable will have to be queried after a 9 WAIT operation to handle this situation. This choice was made because we expect the WAIT statement 10 to be the usual method of waiting for input/output to complete (and WAIT does support the END= 11 and EOR= specifiers). This particular choice is philosophical, and was not based on significant technical 12 difficulties. 13 Note that the requirement to set the IOSTAT variable correctly requires an implementation to remember 14 which input/output requests got an EOR condition, so that a subsequent wait operation will return the 15 correct IOSTAT value. This means there is a processor defined limit on the number of outstanding 16 nonadvancing input/output requests that got an EOR condition (constrained by available memory to 17 keep track of this information, similar to END/ERR conditions). 18 C.6.4 OPEN statement (9.4.5) 19 A file may become connected to a unit either by preconnection or by execution of an OPEN statement. 20 Preconnection is performed prior to the beginning of execution of a program by means external to For- 21 tran. For example, it may be done by job control action or by processor-established defaults. Execution 22 of an OPEN statement is not required to access preconnected files (9.4.4). 23 The OPEN statement provides a means to access existing files that are not preconnected. An OPEN 24 statement may be used in either of two ways: with a file name (open-by-name) and without a file name 25 (open-by-unit). A unit is given in either case. Open-by-name connects the specified file to the specified 26 unit. Open-by-unit connects a processor-dependent default file to the specified unit. (The default file 27 might or might not have a name.) 28 Therefore, there are three ways a file may become connected and hence processed: preconnection, open- 29 by-name, and open-by-unit. Once a file is connected, there is no means in standard Fortran to determine 30 how it became connected. 31 An OPEN statement may also be used to create a new file. In fact, any of the foregoing three connection 32 methods may be performed on a file that does not exist. When a unit is preconnected, writing the first 33 record creates the file. With the other two methods, execution of the OPEN statement creates the file. 34 When an OPEN statement is executed, the unit specified in the OPEN might or might not already be 35 connected to a file. If it is already connected to a file (either through preconnection or by a prior OPEN), 36 then omitting the FILE= specifier in the OPEN statement implies that the file is to remain connected 37 to the unit. Such an OPEN statement may be used to change the values of the blank interpretation 38 mode, decimal edit mode, pad mode, input/output rounding mode, delimiter mode, and sign mode. 39 If the value of the ACTION= specifier is WRITE, then READ statements shall not refer to this connec- 40 tion. ACTION = 'WRITE' does not restrict positioning by a BACKSPACE statement or positioning 41 specified by the POSITION= specifier with the value APPEND. However, a BACKSPACE statement 42 or an OPEN statement containing POSITION = 'APPEND' may fail if the processor requires reading 43 of the file to achieve the positioning. 44 The following examples illustrate these rules. In the first example, unit 10 is preconnected to a SCRATCH 45 file; the OPEN statement changes the value of PAD= to YES. 46 550 2006/07/11 WORKING DRAFT J3/06-007 CHARACTER (LEN = 20) CH1 1 WRITE (10, '(A)') 'THIS IS RECORD 1' 2 OPEN (UNIT = 10, STATUS = 'OLD', PAD = 'YES') 3 REWIND 10 4 READ (10, '(A20)') CH1 ! CH1 now has the value 5 ! 'THIS IS RECORD 1 ' 6 In the next example, unit 12 is first connected to a file named FRED, with a status of OLD. The second 7 OPEN statement then opens unit 12 again, retaining the connection to the file FRED, but changing the 8 value of the DELIM= specifier to QUOTE. 9 CHARACTER (LEN = 25) CH2, CH3 10 OPEN (12, FILE = 'FRED', STATUS = 'OLD', DELIM = 'NONE') 11 CH2 = '''THIS STRING HAS QUOTES.''' 12 ! Quotes in string CH2 13 WRITE (12, *) CH2 ! Written with no delimiters 14 OPEN (12, DELIM = 'QUOTE') ! Now quote is the delimiter 15 REWIND 12 16 READ (12, *) CH3 ! CH3 now has the value 17 ! 'THIS STRING HAS QUOTES. ' 18 The next example is invalid because it attempts to change the value of the STATUS= specifier. 19 OPEN (10, FILE = 'FRED', STATUS = 'OLD') 20 WRITE (10, *) A, B, C 21 OPEN (10, STATUS = 'SCRATCH') ! Attempts to make FRED 22 ! a SCRATCH file 23 The previous example could be made valid by closing the unit first, as in the next example. 24 OPEN (10, FILE = 'FRED', STATUS = 'OLD') 25 WRITE (10, *) A, B, C 26 CLOSE (10) 27 OPEN (10, STATUS = 'SCRATCH') ! Opens a different 28 ! SCRATCH file 29 C.6.5 Connection prop erties (9.4.3) 30 When a unit becomes connected to a file, either by execution of an OPEN statement or by preconnection, 31 the following connection properties, among others, may be established. 32 (1) An access method, which is sequential, direct, or stream, is established for the connection 33 (9.4.5.1). 34 (2) A form, which is formatted or unformatted, is established for a connection to a file that 35 exists or is created by the connection. For a connection that results from execution of an 36 OPEN statement, a default form (which depends on the access method, as described in 37 551 J3/06-007 WORKING DRAFT 2006/07/11 9.2.2) is established if no form is specified. For a preconnected file that exists, a form is 1 established by preconnection. For a preconnected file that does not exist, a form may be 2 established, or the establishment of a form may be delayed until the file is created (for 3 example, by execution of a formatted or unformatted WRITE statement) (9.4.5.9). 4 (3) A record length may be established. If the access method is direct, the connection establishes 5 a record length that specifies the length of each record of the file. An existing file with records 6 that are not all of equal length shall not be connected for direct access. 7 If the access method is sequential, records of varying lengths are permitted. In this case, 8 the record length established specifies the maximum length of a record in the file (9.4.6.3). 9 A processor has wide latitude in adapting these concepts and actions to its own cataloging and job 10 control conventions. Some processors may require job control action to specify the set of files that 11 exist or that will be created by a program. Some processors may require no job control action prior to 12 execution. This standard enables processors to perform dynamic open, close, or file creation operations, 13 but it does not require such capabilities of the processor. 14 The meaning of "open" in contexts other than Fortran may include such things as mounting a tape, 15 console messages, spooling, label checking, security checking, etc. These actions may occur upon job 16 control action external to Fortran, upon execution of an OPEN statement, or upon execution of the first 17 read or write of the file. The OPEN statement describes properties of the connection to the file and 18 might or might not cause physical activities to take place. It is a place for an implementation to define 19 properties of a file beyond those required in standard Fortran. 20 C.6.6 CLOSE statement (9.4.7) 21 Similarly, the actions of dismounting a tape, protection, etc. of a "close" may be implicit at the end of 22 a run. The CLOSE statement might or might not cause such actions to occur. This is another place to 23 extend file properties beyond those of standard Fortran. Note, however, that the execution of a CLOSE 24 statement on a unit followed by an OPEN statement on the same unit to the same file or to a different 25 file is a permissible sequence of events. The processor shall not deny this sequence solely because the 26 implementation chooses to do the physical act of closing the file at the termination of execution of the 27 program. 28 C.7 Clause 10 notes 29 C.7.1 Numb er of records (10.4, 10.5, 10.8.2) 30 The number of records read by an explicitly formatted advancing input statement can be determined 31 from the following rule: a record is read at the beginning of the format scan (even if the input list is 32 empty), at each slash edit descriptor encountered in the format, and when a format rescan occurs at the 33 end of the format. 34 The number of records written by an explicitly formatted advancing output statement can be determined 35 from the following rule: a record is written when a slash edit descriptor is encountered in the format, 36 when a format rescan occurs at the end of the format, and at completion of execution of the output 37 statement (even if the output list is empty). Thus, the occurrence of n successive slashes between two 38 other edit descriptors causes n - 1 blank lines if the records are printed. The occurrence of n slashes at 39 the beginning or end of a complete format specification causes n blank lines if the records are printed. 40 However, a complete format specification containing n slashes (n > 0) and no other edit descriptors 41 causes n + 1 blank lines if the records are printed. For example, the statements 42 PRINT 3 43 3 FORMAT (/) 44 552 2006/07/11 WORKING DRAFT J3/06-007 will write two records that cause two blank lines if the records are printed. 1 C.7.2 List-directed input (10.10.1) 2 The following examples illustrate list-directed input. A blank character is represented by b. 3 Example 1: 4 Program: 5 J=3 6 READ *, I 7 READ *, J 8 Sequential input file: 9 record 1: b1b,4bbbbb 10 record 2: ,2bbbbbbbb 11 Result: I = 1, J = 3. 12 Explanation: The second READ statement reads the second record. The initial comma in the record 13 designates a null value; therefore, J is not redefined. 14 Example 2: 15 Program: 16 CHARACTER A *8, B *1 17 READ *, A, B 18 Sequential input file: 19 record 1: 'bbbbbbbb' 20 record 2: 'QXY'b'Z' 21 Result: A = 'bbbbbbbb', B = 'Q' 22 Explanation: In the first record, the rightmost apostrophe is interpreted as delimiting the constant (it 23 cannot be the first of a pair of embedded apostrophes representing a single apostrophe because this 24 would involve the prohibited "splitting" of the pair by the end of a record); therefore, A is assigned 25 the character constant 'bbbbbbbb'. The end of a record acts as a blank, which in this case is a value 26 separator because it occurs between two constants. 27 C.8 Clause 11 notes 28 C.8.1 Main program and block data program unit (11.1, 11.3) 29 The name of the main program or of a block data program unit has no explicit use within the Fortran 30 language. It is available for documentation and for possible use by a processor. 31 553 J3/06-007 WORKING DRAFT 2006/07/11 A processor may implement an unnamed main program or unnamed block data program unit by assigning 1 it a default name. However, this name shall not conflict with any other global name in a standard- 2 conforming program. This might be done by making the default name one that is not permitted in a 3 standard-conforming program (for example, by including a character not normally allowed in names) 4 or by providing some external mechanism such that for any given program the default name can be 5 changed to one that is otherwise unused. 6 C.8.2 Dep endent compilation (11.2) 7 This standard, like its predecessors, is intended to permit the implementation of conforming processors 8 in which a program can be broken into multiple units, each of which can be separately translated in 9 preparation for execution. Such processors are commonly described as supporting separate compilation. 10 There is an important difference between the way separate compilation can be implemented under this 11 standard and the way it could be implemented under the Fortran 77 International Standard. Under 12 the Fortran 77 standard, any information required to translate a program unit was specified in that 13 program unit. Each translation was thus totally independent of all others. Under this standard, a 14 program unit can use information that was specified in a separate module and thus may be dependent 15 on that module. The implementation of this dependency in a processor may be that the translation of a 16 program unit may depend on the results of translating one or more modules. Processors implementing 17 the dependency this way are commonly described as supporting dependent compilation. 18 The dependencies involved here are new only in the sense that the Fortran processor is now aware of 19 them. The same information dependencies existed under the Fortran 77 International Standard, but 20 it was the programmer's responsibility to transport the information necessary to resolve them by making 21 redundant specifications of the information in multiple program units. The availability of separate but 22 dependent compilation offers several potential advantages over the redundant textual specification of 23 information. 24 (1) Specifying information at a single place in the program ensures that different program units 25 using that information will be translated consistently. Redundant specification leaves the 26 possibility that different information will erroneously be specified. Even if an INCLUDE line 27 is used to ensure that the text of the specifications is identical in all involved program units, 28 the presence of other specifications (for example, an IMPLICIT statement) may change the 29 interpretation of that text. 30 (2) During the revision of a program, it is possible for a processor to assist in determining 31 whether different program units have been translated using different (incompatible) versions 32 of a module, although there is no requirement that a processor provide such assistance. 33 Inconsistencies in redundant textual specification of information, on the other hand, tend 34 to be much more difficult to detect. 35 (3) Putting information in a module provides a way of packaging it. Without modules, redun- 36 dant specifications frequently shall be interleaved with other specifications in a program 37 unit, making convenient packaging of such information difficult. 38 (4) Because a processor may be implemented such that the specifications in a module are 39 translated once and then repeatedly referenced, there is the potential for greater efficiency 40 than when the processor shall translate redundant specifications of information in multiple 41 program units. 42 The exact meaning of the requirement that the public portions of a module be available at the time of 43 reference is processor dependent. For example, a processor could consider a module to be available only 44 after it has been compiled and require that if the module has been compiled separately, the result of 45 that compilation shall be identified to the compiler when compiling program units that use it. 46 554 2006/07/11 WORKING DRAFT J3/06-007 C.8.2.1 USE statement and dep endent compilation (11.2.1) 1 Another benefit of the USE statement is its enhanced facilities for name management. If one needs to 2 use only selected entities in a module, one can do so without having to worry about the names of all 3 the other entities in that module. If one needs to use two different modules that happen to contain 4 entities with the same name, there are several ways to deal with the conflict. If none of the entities with 5 the same name are to be used, they can simply be ignored. If the name happens to refer to the same 6 entity in both modules (for example, if both modules obtained it from a third module), then there is no 7 confusion about what the name denotes and the name can be freely used. If the entities are different 8 and one or both is to be used, the local renaming facility in the USE statement makes it possible to give 9 those entities different names in the program unit containing the USE statements. 10 A benefit of using the ONLY option consistently, as compared to USE without it, is that the module 11 from which each accessed entity is accessed is explicitly specified in each program unit. This means that 12 one need not search other program units to find where each one is defined. This reduces maintenance 13 costs. 14 A typical implementation of dependent but separate compilation may involve storing the result of trans- 15 lating a module in a file (or file element) whose name is derived from the name of the module. Note, 16 however, that the name of a module is limited only by the Fortran rules and not by the names allowed 17 in the file system. Thus the processor may have to provide a mapping between Fortran names and file 18 system names. 19 The result of translating a module could reasonably either contain only the information textually specified 20 in the module (with "pointers" to information originally textually specified in other modules) or contain 21 all information specified in the module (including copies of information originally specified in other 22 modules). Although the former approach would appear to save on storage space, the latter approach 23 can greatly simplify the logic necessary to process a USE statement and can avoid the necessity of 24 imposing a limit on the logical "nesting" of modules via the USE statement. 25 Variables declared in a module retain their definition status on much the same basis as variables in 26 a common block. That is, saved variables retain their definition status throughout the execution of a 27 program, while variables that are not saved retain their definition status only during the execution of 28 scoping units that reference the module. In some cases, it may be appropriate to put a USE statement 29 such as 30 USE MY MODULE, ONLY: 31 in a scoping unit in order to assure that other procedures that it references can communicate through 32 the module. In such a case, the scoping unit would not access any entities from the module, but the 33 variables not saved in the module would retain their definition status throughout the execution of the 34 scoping unit. 35 There is an increased potential for undetected errors in a scoping unit that uses both implicit typing 36 and the USE statement. For example, in the program fragment 37 SUBROUTINE SUB 38 USE MY_MODULE 39 IMPLICIT INTEGER (I-N), REAL (A-H, O-Z) 40 X = F (B) 41 A = G (X) + H (X + 1) 42 END SUBROUTINE SUB 43 X could be either an implicitly typed real variable or a variable obtained from the module MY MODULE 44 555 J3/06-007 WORKING DRAFT 2006/07/11 and might change from one to the other because of changes in MY MODULE unrelated to the action 1 performed by SUB. Logic errors resulting from this kind of situation can be extremely difficult to locate. 2 Thus, the use of these features together is discouraged. 3 C.8.2.2 Accessibility attributes 4 The PUBLIC and PRIVATE attributes, which can be declared only in modules, divide the entities in a 5 module into those that are actually relevant to a scoping unit referencing the module and those that are 6 not. This information may be used to improve the performance of a Fortran processor. For example, 7 it may be possible to discard much of the information about the private entities once a module has 8 been translated, thus saving on both storage and the time to search it. Similarly, it may be possible 9 to recognize that two versions of a module differ only in the private entities they contain and avoid 10 retranslating program units that use that module when switching from one version of the module to the 11 other. 12 C.8.3 Examples of the use of mo dules 13 C.8.3.1 Identical common blo cks 14 A common block and all its associated specification statements may be placed in a module named, for 15 example, MY COMMON and accessed by a USE statement of the form 16 USE MY COMMON 17 that accesses the whole module without any renaming. This ensures that all instances of the common 18 block are identical. Module MY COMMON could contain more than one common block. 19 C.8.3.2 Global data 20 A module may contain only data ob jects, for example: 21 MODULE DATA_MODULE 22 SAVE 23 REAL A (10), B, C (20,20) 24 INTEGER :: I=0 25 INTEGER, PARAMETER :: J=10 26 COMPLEX D (J,J) 27 END MODULE DATA_MODULE 28 Data ob jects made global in this manner may have any combination of data types. 29 Access to some of these may be made by a USE statement with the ONLY option, such as: 30 USE DATA MODULE, ONLY: A, B, D 31 and access to all of them may be made by the following USE statement: 32 USE DATA MODULE 33 Access to all of them with some renaming to avoid name conflicts may be made by: 34 USE DATA MODULE, AMODULE => A, DMODULE => D 35 556 2006/07/11 WORKING DRAFT J3/06-007 C.8.3.3 Derived typ es 1 A derived type may be defined in a module and accessed in a number of program units. For example: 2 MODULE SPARSE 3 TYPE NONZERO 4 REAL A 5 INTEGER I, J 6 END TYPE NONZERO 7 END MODULE SPARSE 8 defines a type consisting of a real component and two integer components for holding the numerical 9 value of a nonzero matrix element and its row and column indices. 10 C.8.3.4 Global allocatable arrays 11 Many programs need large global allocatable arrays whose sizes are not known before program execution. 12 A simple form for such a program is: 13 PROGRAM GLOBAL_WORK 14 CALL CONFIGURE_ARRAYS ! Perform the appropriate allocations 15 CALL COMPUTE ! Use the arrays in computations 16 END PROGRAM GLOBAL_WORK 17 MODULE WORK_ARRAYS ! An example set of work arrays 18 INTEGER N 19 REAL, ALLOCATABLE, SAVE :: A (:), B (:, :), C (:, :, :) 20 END MODULE WORK_ARRAYS 21 SUBROUTINE CONFIGURE_ARRAYS ! Process to set up work arrays 22 USE WORK_ARRAYS 23 READ (*, *) N 24 ALLOCATE (A (N), B (N, N), C (N, N, 2 * N)) 25 END SUBROUTINE CONFIGURE_ARRAYS 26 SUBROUTINE COMPUTE 27 USE WORK_ARRAYS 28 ... ! Computations involving arrays A, B, and C 29 END SUBROUTINE COMPUTE 30 Typically, many subprograms need access to the work arrays, and all such subprograms would contain 31 the statement 32 USE WORK ARRAYS 33 C.8.3.5 Pro cedure libraries 34 Interface bodies for external procedures in a library may be gathered into a module. This permits the 35 use of argument keywords and optional arguments, and allows static checking of the references. Different 36 versions may be constructed for different applications, using argument keywords in common use in each 37 application. 38 557 J3/06-007 WORKING DRAFT 2006/07/11 An example is the following library module: 1 MODULE LIBRARY_LLS 2 INTERFACE 3 SUBROUTINE LLS (X, A, F, FLAG) 4 REAL X (:, :) 5 ! The SIZE in the next statement is an intrinsic function 6 REAL, DIMENSION (SIZE (X, 2)) :: A, F 7 INTEGER FLAG 8 END SUBROUTINE LLS 9 ... 10 END INTERFACE 11 ... 12 END MODULE LIBRARY_LLS 13 This module allows the subroutine LLS to be invoked: 14 USE LIBRARY_LLS 15 ... 16 CALL LLS (X = ABC, A = D, F = XX, FLAG = IFLAG) 17 ... 18 C.8.3.6 Op erator extensions 19 In order to extend an intrinsic operator symbol to have an additional meaning, an interface block 20 specifying that operator symbol in the OPERATOR option of the INTERFACE statement may be 21 placed in a module. 22 For example, // may be extended to perform concatenation of two derived-type ob jects serving as varying 23 length character strings and + may be extended to specify matrix addition for type MATRIX or interval 24 arithmetic addition for type INTERVAL. 25 A module might contain several such interface blocks. An operator may be defined by an external 26 function (either in Fortran or some other language) and its procedure interface placed in the module. 27 C.8.3.7 Data abstraction 28 In addition to providing a portable means of avoiding the redundant specification of information in 29 multiple program units, a module provides a convenient means of "packaging" related entities, such as 30 the definitions of the representation and operations of an abstract data type. The following example 31 of a module defines a data abstraction for a SET type where the elements of each set are of type 32 integer. The standard set operations of UNION, INTERSECTION, and DIFFERENCE are provided. 33 The CARDINALITY function returns the cardinality of (number of elements in) its set argument. 34 Two functions returning logical values are included, ELEMENT and SUBSET. ELEMENT defines the 35 operator .IN. and SUBSET extends the operator <=. ELEMENT determines if a given scalar integer 36 value is an element of a given set, and SUBSET determines if a given set is a subset of another given 37 set. (Two sets may be checked for equality by comparing cardinality and checking that one is a subset 38 of the other, or checking to see if each is a subset of the other.) 39 558 2006/07/11 WORKING DRAFT J3/06-007 The transfer function SETF converts a vector of integer values to the corresponding set, with duplicate 1 values removed. Thus, a vector of constant values can be used as set constants. An inverse transfer 2 function VECTOR returns the elements of a set as a vector of values in ascending order. In this SET 3 implementation, set data ob jects have a maximum cardinality of 200. 4 MODULE INTEGER_SETS 5 ! This module is intended to illustrate use of the module facility 6 ! to define a new type, along with suitable operators. 7 8 INTEGER, PARAMETER :: MAX_SET_CARD = 200 9 10 TYPE SET ! Define SET type 11 PRIVATE 12 INTEGER CARD 13 INTEGER ELEMENT (MAX_SET_CARD) 14 END TYPE SET 15 16 INTERFACE OPERATOR (.IN.) 17 MODULE PROCEDURE ELEMENT 18 END INTERFACE OPERATOR (.IN.) 19 20 INTERFACE OPERATOR (<=) 21 MODULE PROCEDURE SUBSET 22 END INTERFACE OPERATOR (<=) 23 24 INTERFACE OPERATOR (+) 25 MODULE PROCEDURE UNION 26 END INTERFACE OPERATOR (+) 27 28 INTERFACE OPERATOR (-) 29 MODULE PROCEDURE DIFFERENCE 30 END INTERFACE OPERATOR (-) 31 32 INTERFACE OPERATOR (*) 33 MODULE PROCEDURE INTERSECTION 34 END INTERFACE OPERATOR (*) 35 36 CONTAINS 37 38 INTEGER FUNCTION CARDINALITY (A) ! Returns cardinality of set A 39 TYPE (SET), INTENT (IN) :: A 40 CARDINALITY = A % CARD 41 END FUNCTION CARDINALITY 42 43 LOGICAL FUNCTION ELEMENT (X, A) ! Determines if 44 559 J3/06-007 WORKING DRAFT 2006/07/11 INTEGER, INTENT(IN) :: X ! element X is in set A 1 TYPE (SET), INTENT(IN) :: A 2 ELEMENT = ANY (A % ELEMENT (1 : A % CARD) == X) 3 END FUNCTION ELEMENT 4 5 FUNCTION UNION (A, B) ! Union of sets A and B 6 TYPE (SET) UNION 7 TYPE (SET), INTENT(IN) :: A, B 8 INTEGER J 9 UNION = A 10 DO J = 1, B % CARD 11 IF (.NOT. (B % ELEMENT (J) .IN. A)) THEN 12 IF (UNION % CARD < MAX_SET_CARD) THEN 13 UNION % CARD = UNION % CARD + 1 14 UNION % ELEMENT (UNION % CARD) = & 15 B % ELEMENT (J) 16 ELSE 17 ! Maximum set size exceeded . . . 18 END IF 19 END IF 20 END DO 21 END FUNCTION UNION 22 23 FUNCTION DIFFERENCE (A, B) ! Difference of sets A and B 24 TYPE (SET) DIFFERENCE 25 TYPE (SET), INTENT(IN) :: A, B 26 INTEGER J, X 27 DIFFERENCE % CARD = 0 ! The empty set 28 DO J = 1, A % CARD 29 X = A % ELEMENT (J) 30 IF (.NOT. (X .IN. B)) DIFFERENCE = DIFFERENCE + SET (1, X) 31 END DO 32 END FUNCTION DIFFERENCE 33 34 FUNCTION INTERSECTION (A, B) ! Intersection of sets A and B 35 TYPE (SET) INTERSECTION 36 TYPE (SET), INTENT(IN) :: A, B 37 INTERSECTION = A - (A - B) 38 END FUNCTION INTERSECTION 39 40 LOGICAL FUNCTION SUBSET (A, B) ! Determines if set A is 41 TYPE (SET), INTENT(IN) :: A, B ! a subset of set B 42 INTEGER I 43 SUBSET = A % CARD <= B % CARD 44 IF (.NOT. SUBSET) RETURN ! For efficiency 45 560 2006/07/11 WORKING DRAFT J3/06-007 DO I = 1, A % CARD 1 SUBSET = SUBSET .AND. (A % ELEMENT (I) .IN. B) 2 END DO 3 END FUNCTION SUBSET 4 5 TYPE (SET) FUNCTION SETF (V) ! Transfer function between a vector 6 INTEGER V (:) ! of elements and a set of elements 7 INTEGER J ! removing duplicate elements 8 SETF % CARD = 0 9 DO J = 1, SIZE (V) 10 IF (.NOT. (V (J) .IN. SETF)) THEN 11 IF (SETF % CARD < MAX_SET_CARD) THEN 12 SETF % CARD = SETF % CARD + 1 13 SETF % ELEMENT (SETF % CARD) = V (J) 14 ELSE 15 ! Maximum set size exceeded . . . 16 END IF 17 END IF 18 END DO 19 END FUNCTION SETF 20 21 FUNCTION VECTOR (A) ! Transfer the values of set A 22 TYPE (SET), INTENT (IN) :: A ! into a vector in ascending order 23 INTEGER, POINTER :: VECTOR (:) 24 INTEGER I, J, K 25 ALLOCATE (VECTOR (A % CARD)) 26 VECTOR = A % ELEMENT (1 : A % CARD) 27 DO I = 1, A % CARD - 1 ! Use a better sort if 28 DO J = I + 1, A % CARD ! A % CARD is large 29 IF (VECTOR (I) > VECTOR (J)) THEN 30 K = VECTOR (J); VECTOR (J) = VECTOR (I); VECTOR (I) = K 31 END IF 32 END DO 33 END DO 34 END FUNCTION VECTOR 35 36 END MODULE INTEGER_SETS 37 Examples of using INTEGER_SETS (A, B, and C are variables of type SET; X 38 is an integer variable): 39 ! Check to see if A has more than 10 elements 40 IF (CARDINALITY (A) > 10) ... 41 42 ! Check for X an element of A but not of B 43 IF (X .IN. (A - B)) ... 44 561 J3/06-007 WORKING DRAFT 2006/07/11 1 ! C is the union of A and the result of B intersected 2 ! with the integers 1 to 100 3 C = A + B * SETF ((/ (I, I = 1, 100) /)) 4 5 ! Does A have any even numbers in the range 1:100? 6 IF (CARDINALITY (A * SETF ((/ (I, I = 2, 100, 2) /))) > 0) ... 7 8 PRINT *, VECTOR (B) ! Print out the elements of set B, in ascending order 9 C.8.3.8 Public entities renamed 10 At times it may be necessary to rename entities that are accessed with USE statements. Care should be 11 taken if the referenced modules also contain USE statements. 12 The following example illustrates renaming features of the USE statement. 13 MODULE J; REAL JX, JY, JZ; END MODULE J 14 MODULE K 15 USE J, ONLY : KX => JX, KY => JY 16 ! KX and KY are local names to module K 17 REAL KZ ! KZ is local name to module K 18 REAL JZ ! JZ is local name to module K 19 END MODULE K 20 PROGRAM RENAME 21 USE J; USE K 22 ! Module J's entity JX is accessible under names JX and KX 23 ! Module J's entity JY is accessible under names JY and KY 24 ! Module K's entity KZ is accessible under name KZ 25 ! Module J's entity JZ and K's entity JZ are different entities 26 ! and shall not be referenced 27 ... 28 END PROGRAM RENAME 29 C.8.4 Modules with submo dules 30 Each submodule specifies that it is the child of exactly one parent module or submodule. Therefore, a 31 module and all of its descendant submodules stand in a tree-like relationship one to another. 32 If a module procedure interface body that is specified in a module has public accessibility, and its 33 corresponding separate module procedure is defined in a descendant of that module, the procedure can 34 be accessed by use association. No other entity in a submodule can be accessed by use association. Each 35 program unit that references a module by use association depends on it, and each submodule depends 36 on its ancestor module. Therefore, if one changes a separate module procedure body in a submodule but 37 does not change its corresponding module procedure interface, a tool for automatic program translation 38 would not need to reprocess program units that reference the module by use association. This is so 39 even if the tool exploits the relative modification times of files as opposed to comparing the result of 40 translating the module to the result of a previous translation. 41 562 2006/07/11 WORKING DRAFT J3/06-007 By constructing taller trees, one can put entities at intermediate levels that are shared by submodules 1 at lower levels; changing these entities cannot change the interpretation of anything that is accessible 2 from the module by use association. Developers of modules that embody large complicated concepts 3 can exploit this possibility to organize components of the concept into submodules, while preserving the 4 privacy of entities that are shared by the submodules and that ought not to be exposed to users of the 5 module. Putting these shared entities at an intermediate level also prevents cascades of reprocessing 6 and testing if some of them are changed. 7 The following example illustrates a module, color points, with a submodule, color points a, that in 8 turn has a submodule, color points b. Public entities declared within color points can be accessed by 9 use association. The submodules color points a and color points b can be changed without causing 10 retranslation of program units that reference the module color points. 11 The module color points does not have a module-subprogram-part , but a module-subprogram-part is not 12 prohibited. The module could be published as definitive specification of the interface, without revealing 13 trade secrets contained within color points a or color points b. Of course, a similar module without 14 the module prefix in the interface bodies would serve equally well as documentation ­ but the procedures 15 would be external procedures. It would make little difference to the consumer, but the developer would 16 forfeit all of the advantages of modules. 17 module color_points 18 19 type color_point 20 private 21 real :: x, y 22 integer :: color 23 end type color_point 24 25 interface ! Interfaces for procedures with separate 26 ! bodies in the submodule color_points_a 27 module subroutine color_point_del ( p ) ! Destroy a color_point object 28 type(color_point), allocatable :: p 29 end subroutine color_point_del 30 ! Distance between two color_point objects 31 real module function color_point_dist ( a, b ) 32 type(color_point), intent(in) :: a, b 33 end function color_point_dist 34 module subroutine color_point_draw ( p ) ! Draw a color_point object 35 type(color_point), intent(in) :: p 36 end subroutine color_point_draw 37 module subroutine color_point_new ( p ) ! Create a color_point object 38 type(color_point), allocatable :: p 39 end subroutine color_point_new 40 end interface 41 42 end module color_points 43 The only entities within color points a that can be accessed by use association are separate module 44 procedures for which corresponding module procedure interface bodies are provided in color points. 45 563 J3/06-007 WORKING DRAFT 2006/07/11 If the procedures are changed but their interfaces are not, the interface from program units that access 1 them by use association is unchanged. If the module and submodule are in separate files, utilities that 2 examine the time of modification of a file would notice that changes in the module could affect the 3 translation of its submodules or of program units that reference the module by use association, but 4 that changes in submodules could not affect the translation of the parent module or program units that 5 reference it by use association. 6 The variable instance count is not accessible by use association of color points, but is accessible 7 within color points a, and its submodules. 8 submodule ( color_points ) color_points_a ! Submodule of color_points 9 10 integer, save :: instance_count = 0 11 12 interface ! Interface for a procedure with a separate 13 ! body in submodule color_points_b 14 module subroutine inquire_palette ( pt, pal ) 15 use palette_stuff ! palette_stuff, especially submodules 16 ! thereof, can reference color_points by use 17 ! association without causing a circular 18 ! dependence during translation because this 19 ! use is not in the module. Furthermore, 20 ! changes in the module palette_stuff do not 21 ! affect the translation of color_points. 22 type(color_point), intent(in) :: pt 23 type(palette), intent(out) :: pal 24 end subroutine inquire_palette 25 26 end interface 27 28 contains ! Invisible bodies for public module procedure interfaces 29 ! declared in the module 30 31 module subroutine color_point_del ( p ) 32 type(color_point), allocatable :: p 33 instance_count = instance_count - 1 34 deallocate ( p ) 35 end subroutine color_point_del 36 real module function color_point_dist ( a, b ) result ( dist ) 37 type(color_point), intent(in) :: a, b 38 dist = sqrt( (b%x - a%x)**2 + (b%y - a%y)**2 ) 39 end function color_point_dist 40 module subroutine color_point_new ( p ) 41 type(color_point), allocatable :: p 42 instance_count = instance_count + 1 43 allocate ( p ) 44 564 2006/07/11 WORKING DRAFT J3/06-007 end subroutine color_point_new 1 2 end submodule color_points_a 3 The subroutine inquire palette is accessible within color points a because its interface is declared 4 therein. It is not, however, accessible by use association, because its interface is not declared in the 5 module, color points. Since the interface is not declared in the module, changes in the interface 6 cannot affect the translation of program units that reference the module by use association. 7 submodule ( color_points:color_points_a ) color_points_b ! Subsidiary**2 submodule 8 9 contains 10 ! Invisible body for interface declared in the ancestor module 11 module subroutine color_point_draw ( p ) 12 use palette_stuff, only: palette 13 type(color_point), intent(in) :: p 14 type(palette) :: MyPalette 15 ...; call inquire_palette ( p, MyPalette ); ... 16 end subroutine color_point_draw 17 18 ! Invisible body for interface declared in the parent submodule 19 module procedure inquire_palette 20 ... implementation of inquire_palette 21 end procedure inquire_palette 22 23 subroutine private_stuff ! not accessible from color_points_a 24 ... 25 end subroutine private_stuff 26 27 end submodule color_points_b 28 29 module palette_stuff 30 type :: palette ; ... ; end type palette 31 contains 32 subroutine test_palette ( p ) 33 ! Draw a color wheel using procedures from the color_points module 34 type(palette), intent(in) :: p 35 use color_points ! This does not cause a circular dependency because 36 ! the "use palette_stuff" that is logically within 37 ! color_points is in the color_points_a submodule. 38 ... 39 end subroutine test_palette 40 end module palette_stuff 41 There is a use palette stuff in color points a, and a use color points in palette stuff. The 42 use palette stuff would cause a circular reference if it appeared in color points. In this case, it does 43 565 J3/06-007 WORKING DRAFT 2006/07/11 not cause a circular dependence because it is in a submodule. Submodules cannot be referenced by use 1 association, and therefore what would be a circular appearance of use palette stuff is not accessed. 2 3 program main 4 use color_points 5 ! "instance_count" and "inquire_palette" are not accessible here 6 ! because they are not declared in the "color_points" module. 7 ! "color_points_a" and "color_points_b" cannot be referenced by 8 ! use association. 9 interface draw ! just to demonstrate it's possible 10 module procedure color_point_draw 11 end interface 12 type(color_point) :: C_1, C_2 13 real :: RC 14 ... 15 call color_point_new (c_1) ! body in color_points_a, interface in color_points 16 ... 17 call draw (c_1) ! body in color_points_b, specific interface 18 ! in color_points, generic interface here. 19 ... 20 rc = color_point_dist (c_1, c_2) ! body in color_points_a, interface in color_points 21 ... 22 call color_point_del (c_1) ! body in color_points_a, interface in color_points 23 ... 24 end program main A multilevel submodule system can be used to package and organize a large and interconnected concept 25 without exposing entities of one subsystem to other subsystems. 26 Consider a Plasma module from a Tokomak simulator. A plasma simulation requires attention at least to 27 fluid flow, thermodynamics, and electromagnetism. Fluid flow simulation requires simulation of subsonic, 28 supersonic, and hypersonic flow. This problem decomposition can be reflected in the submodule structure 29 of the Plasma module: 30 Plasma module 31 | 32 |---------------------|---------------------| 33 | | | 34 Flow submodule Thermal submodule Electromagnetics 35 | Submodule 36 |-------------------|-------------------| 37 | | | 38 Subsonic Supersonic Hypersonic 39 Entities can be shared among the Subsonic, Supersonic, and Hypersonic submodules by putting 40 them within the Flow submodule. One then need not worry about accidental use of these entities by 41 use association or by the Thermal or Electromagnetics modules, or the development of a dependency 42 of correct operation of those subsystems upon the representation of entities of the Flow subsystem as a 43 566 2006/07/11 WORKING DRAFT J3/06-007 consequence of maintenance. Since these these entities are not accessible by use association, if any of 1 them are changed, the new values cannot be accessed in program units that reference the Plasma module 2 by use association; the answer to the question "where are these entities used" is therefore confined to 3 the set of descendant submodules of the Flow submodule. 4 C.9 Clause 12 notes 5 C.9.1 Portability problems with external pro cedures (12.4.2.2) 6 There is a potential portability problem in a scoping unit that references an external procedure without 7 explicitly declaring it to have the EXTERNAL attribute (5.3.8). On a different processor, the name 8 of that procedure may be the name of a nonstandard intrinsic procedure and the processor would 9 be permitted to interpret those procedure references as references to that intrinsic procedure. (On that 10 processor, the program would also be viewed as not conforming to the standard because of the references 11 to the nonstandard intrinsic procedure.) Declaration of the EXTERNAL attribute causes the references 12 to be to the external procedure regardless of the availability of an intrinsic procedure with the same 13 name. Note that declaration of the type of a procedure is not enough to make it external, even if the 14 type is inconsistent with the type of the result of an intrinsic of the same name. 15 C.9.2 Procedures defined by means other than Fortran (12.6.3) 16 A processor is not required to provide any means other than Fortran for defining external procedures. 17 Among the means that might be supported are the machine assembly language, other high level lan- 18 guages, the Fortran language extended with nonstandard features, and the Fortran language as supported 19 by another Fortran processor (for example, a previously existing Fortran 77 processor). 20 Procedures defined by means other than Fortran are considered external procedures because their def- 21 initions are not in a Fortran program unit and because they are referenced using global names. The 22 use of the term external should not be construed as any kind of restriction on the way in which these 23 procedures may be defined. For example, if the means other than Fortran has its own facilities for 24 internal and external procedures, it is permissible to use them. If the means other than Fortran can 25 create an "internal" procedure with a global name, it is permissible for such an "internal" procedure 26 to be considered by Fortran to be an external procedure. The means other than Fortran for defining 27 external procedures, including any restrictions on the structure for organization of those procedures, are 28 entirely processor dependent. 29 A Fortran processor may limit its support of procedures defined by means other than Fortran such that 30 these procedures may affect entities in the Fortran environment only on the same basis as procedures 31 written in Fortran. For example, it might prohibit the value of a local variable from being changed by 32 a procedure reference unless that variable were one of the arguments to the procedure. 33 C.9.3 Procedure interfaces (12.4) 34 In Fortran 77, the interface to an external procedure was always deduced from the form of references 35 to that procedure and any declarations of the procedure name in the referencing program unit. In this 36 standard, features such as argument keywords and optional arguments make it impossible to deduce 37 sufficient information about the dummy arguments from the nature of the actual arguments to be 38 associated with them, and features such as array function results and pointer function results make 39 necessary extensions to the declaration of a procedure that cannot be done in a way that would be 40 analogous with the handling of such declarations in Fortran 77. Hence, mechanisms are provided 41 through which all the information about a procedure's interface may be made available in a scoping 42 unit that references it. A procedure whose interface shall be deduced as in Fortran 77 is described 43 567 J3/06-007 WORKING DRAFT 2006/07/11 as having an implicit interface. A procedure whose interface is fully known is described as having an 1 explicit interface. 2 A scoping unit is allowed to contain an interface body for a procedure that does not exist in the program, 3 provided the procedure described is never referenced or used in any other way. The purpose of this rule is 4 to allow implementations in which the use of a module providing interface bodies describing the interface 5 of every routine in a library would not automatically cause each of those library routines to be a part of 6 the program referencing the module. Instead, only those library procedures actually referenced would 7 be a part of the program. (In implementation terms, the mere presence of an interface body would not 8 generate an external reference in such an implementation.) 9 C.9.4 Abstract interfaces (12.4) and pro cedure p ointer comp onents (4.5) 10 This is an example of a library module providing lists of callbacks that the user may register and invoke. 11 MODULE callback_list_module 12 ! 13 ! Type for users to extend with their own data, if they so desire 14 ! 15 TYPE callback_data 16 END TYPE 17 ! 18 ! Abstract interface for the callback procedures 19 ! 20 ABSTRACT INTERFACE 21 SUBROUTINE callback_procedure(data) 22 IMPORT callback_data 23 CLASS(callback_data),OPTIONAL :: data 24 END SUBROUTINE 25 END INTERFACE 26 ! 27 ! The callback list type. 28 ! 29 TYPE callback_list 30 PRIVATE 31 CLASS(callback_record),POINTER :: first => NULL() 32 END TYPE 33 ! 34 ! Internal: each callback registration creates one of these 35 ! 36 TYPE,PRIVATE :: callback_record 37 PROCEDURE(callback_procedure),POINTER,NOPASS :: proc 38 CLASS(callback_record),POINTER :: next 39 CLASS(callback_data),POINTER :: data => NULL(); 40 END TYPE 41 PRIVATE invoke,forward_invoke 42 CONTAINS 43 568 2006/07/11 WORKING DRAFT J3/06-007 ! 1 ! Register a callback procedure with optional data 2 ! 3 SUBROUTINE register_callback(list, entry, data) 4 TYPE(callback_list),INTENT(INOUT) :: list 5 PROCEDURE(callback_procedure) :: entry 6 CLASS(callback_data),OPTIONAL :: data 7 TYPE(callback_record),POINTER :: new,last 8 ALLOCATE(new) 9 new%proc => entry 10 IF (PRESENT(data)) ALLOCATE(new%data,SOURCE=data) 11 new%next => list%first 12 list%first => new 13 END SUBROUTINE 14 ! 15 ! Internal: Invoke a single callback and destroy its record 16 ! 17 SUBROUTINE invoke(callback) 18 TYPE(callback_record),POINTER :: callback 19 IF (ASSOCIATED(callback%data) THEN 20 CALL callback%proc(list%first%data) 21 DEALLOCATE(callback%data) 22 ELSE 23 CALL callback%proc 24 END IF 25 DEALLOCATE(callback) 26 END SUBROUTINE 27 ! 28 ! Call the procedures in reverse order of registration 29 ! 30 SUBROUTINE invoke_callback_reverse(list) 31 TYPE(callback_list),INTENT(INOUT) :: list 32 TYPE(callback_record),POINTER :: next,current 33 current => list%first 34 NULLIFY(list%first) 35 DO WHILE (ASSOCIATED(current)) 36 next => current%next 37 CALL invoke(current) 38 current => next 39 END DO 40 END SUBROUTINE 41 ! 42 ! Internal: Forward mode invocation 43 ! 44 RECURSIVE SUBROUTINE forward_invoke(callback) 45 569 J3/06-007 WORKING DRAFT 2006/07/11 IF (ASSOCIATED(callback%next)) CALL forward_invoke(callback%next) 1 CALL invoke(callback) 2 END SUBROUTINE 3 ! 4 ! Call the procedures in forward order of registration 5 ! 6 SUBROUTINE invoke_callback_forward(list) 7 TYPE(callback_list),INTENT(INOUT) :: list 8 IF (ASSOCIATED(list%first)) CALL forward_invoke(list%first) 9 END SUBROUTINE 10 END 11 C.9.5 Argument association and evaluation (12.5.1.4) 12 There is a significant difference between the argument association allowed in this standard and that 13 supported by Fortran 77 and Fortran 66. In Fortran 77 and 66, actual arguments were limited 14 to consecutive storage units. With the exception of assumed length character dummy arguments, the 15 structure imposed on that sequence of storage units was always determined in the invoked procedure and 16 not taken from the actual argument. Thus it was possible to implement Fortran 66 and Fortran 77 17 argument association by supplying only the location of the first storage unit (except for character argu- 18 ments, where the length would also have to be supplied). However, this standard allows arguments that 19 do not reside in consecutive storage locations (for example, an array section), and dummy arguments that 20 assume additional structural information from the actual argument (for example, assumed-shape dummy 21 arguments). Thus, the mechanism to implement the argument association allowed in this standard needs 22 to be more general. 23 Because there are practical advantages to a processor that can support references to and from pro- 24 cedures defined by a Fortran 77 processor, requirements for explicit interfaces make it possible to 25 determine whether a simple (Fortran 66/Fortran 77) argument association implementation mecha- 26 nism is sufficient or whether the more general mechanism is necessary (12.4.1.1). Thus a processor can 27 be implemented whose procedures expect the simple mechanism to be used whenever the procedure's 28 interface is one that uses only Fortran 77 features and that expects the more general mechanism 29 otherwise (for example, if there are assumed-shape or optional arguments). At the point of reference, 30 the appropriate mechanism can be determined from the interface if it is explicit and can be assumed to 31 be the simple mechanism if it is not. Note that if the simple mechanism is determined to be what the 32 procedure expects, it may be necessary for the processor to allocate consecutive temporary storage for 33 the actual argument, copy the actual argument to the temporary storage, reference the procedure using 34 the temporary storage in place of the actual argument, copy the contents of temporary storage back to 35 the actual argument, and deallocate the temporary storage. 36 While this is the particular implementation method these rules were designed to support, it is not 37 the only one possible. For example, on some processors, it may be possible to implement the general 38 argument association in such a way that the information involved in Fortran 77 argument association 39 may be found in the same places and the "extra" information is placed so it does not disturb a procedure 40 expecting only Fortran 77 argument association. With such an implementation, argument association 41 could be translated without regard to whether the interface is explicit or implicit. 42 The provisions for expression evaluation give the processor considerable flexibility for obtaining expres- 43 sion values in the most efficient way possible. This includes not evaluating or only partially evaluating 44 an operand, for example, if the value of the expression can be determined otherwise (7.1.8.1). This 45 flexibility applies to function argument evaluation, including the order of argument evaluation, delay- 46 ing argument evaluation, and omitting argument evaluation. A processor may delay the evaluation of 47 570 2006/07/11 WORKING DRAFT J3/06-007 an argument in a procedure reference until the execution of the procedure refers to the value of that 1 argument, provided delaying the evaluation of the argument does not otherwise affect the results of 2 the program. The processor may, with similar restrictions, entirely omit the evaluation of an argument 3 not referenced in the execution of the procedure. This gives processors latitude for optimization (for 4 example, for parallel processing). 5 C.9.6 Pointers and targets as arguments (12.5.1.4) 6 If a dummy argument is declared to be a pointer, it may be matched only by an actual argument that 7 also is a pointer, and the characteristics of both arguments shall agree. A model for such an association is 8 that descriptor values of the actual pointer are copied to the dummy pointer. If the actual pointer has an 9 associated target, this target becomes accessible via the dummy pointer. If the dummy pointer becomes 10 associated with a different target during execution of the procedure, this target will be accessible via the 11 actual pointer after the procedure completes execution. If the dummy pointer becomes associated with 12 a local target that ceases to exist when the procedure completes, the actual pointer will be left dangling 13 in an undefined state. Such dangling pointers shall not be used. 14 When execution of a procedure completes, any pointer that remains defined and that is associated with 15 a dummy argument that has the TARGET attribute and is either a scalar or an assumed-shape array, 16 remains associated with the corresponding actual argument if the actual argument has the TARGET 17 attribute and is not an array section with a vector subscript. 18 REAL, POINTER :: PBEST 19 REAL, TARGET :: B (10000) 20 CALL BEST (PBEST, B) ! Upon return PBEST is associated 21 ... ! with the ``best'' element of B 22 CONTAINS 23 SUBROUTINE BEST (P, A) 24 REAL, POINTER, INTENT (OUT) :: P 25 REAL, TARGET, INTENT (IN) :: A (:) 26 ... ! Find the ``best'' element A(I) 27 P => A (I) 28 RETURN 29 END SUBROUTINE BEST 30 END 31 When procedure BEST completes, the pointer PBEST is associated with an element of B. 32 An actual argument without the TARGET attribute can become associated with a dummy argument 33 with the TARGET attribute. This permits pointers to become associated with the dummy argument 34 during execution of the procedure that contains the dummy argument. For example: 35 INTEGER LARGE(100,100) 36 CALL SUB (LARGE) 37 ... 38 CALL SUB () 39 CONTAINS 40 SUBROUTINE SUB(ARG) 41 INTEGER, TARGET, OPTIONAL :: ARG(100,100) 42 571 J3/06-007 WORKING DRAFT 2006/07/11 INTEGER, POINTER, DIMENSION(:,:) :: PARG 1 IF (PRESENT(ARG)) THEN 2 PARG => ARG 3 ELSE 4 ALLOCATE (PARG(100,100)) 5 PARG = 0 6 ENDIF 7 ... ! Code with lots of references to PARG 8 IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) 9 END SUBROUTINE SUB 10 END 11 Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is 12 associated with an allocated target. The bulk of the code can reference PARG without further calls to 13 the PRESENT intrinsic. 14 C.9.7 Polymorphic Argument Asso ciation (12.5.1.6) 15 The following example illustrates polymorphic argument association rules using the derived types defined 16 in Note 4.58. 17 TYPE(POINT) :: T2 18 TYPE(COLOR_POINT) :: T3 19 CLASS(POINT) :: P2 20 CLASS(COLOR_POINT) :: P3 21 ! Dummy argument is polymorphic and actual argument is of fixed type 22 SUBROUTINE SUB2 ( X2 ); CLASS(POINT) :: X2; ... 23 SUBROUTINE SUB3 ( X3 ); CLASS(COLOR_POINT) :: X3; ... 24 25 CALL SUB2 ( T2 ) ! Valid -- The declared type of T2 is the same as the 26 ! declared type of X2. 27 CALL SUB2 ( T3 ) ! Valid -- The declared type of T3 is extended from 28 ! the declared type of X2. 29 CALL SUB3 ( T2 ) ! Invalid -- The declared type of T2 is neither the 30 ! same as nor extended from the declared type 31 ! type of X3. 32 CALL SUB3 ( T3 ) ! Valid -- The declared type of T3 is the same as the 33 ! declared type of X3. 34 ! Actual argument is polymorphic and dummy argument is of fixed type 35 SUBROUTINE TUB2 ( D2 ); TYPE(POINT) :: D2; ... 36 SUBROUTINE TUB3 ( D3 ); TYPE(COLOR_POINT) :: D3; ... 37 38 CALL TUB2 ( P2 ) ! Valid -- The declared type of P2 is the same as the 39 ! declared type of D2. 40 CALL TUB2 ( P3 ) ! Invalid -- The declared type of P3 differs from the 41 ! declared type of D2. 42 572 2006/07/11 WORKING DRAFT J3/06-007 CALL TUB2 ( P3%POINT ) ! Valid alternative to the above 1 CALL TUB3 ( P2 ) ! Invalid -- The declared type of P2 differs from the 2 ! declared type of D3. 3 SELECT TYPE ( P2 ) ! Valid conditional alternative to the above 4 CLASS IS ( COLOR_POINT ) ! Works if the dynamic type of P2 is the same 5 CALL TUB3 ( P2 ) ! as the declared type of D3, or a type 6 ! extended therefrom. 7 CLASS DEFAULT 8 ! Cannot work if not. 9 END SELECT 10 CALL TUB3 ( P3 ) ! Valid -- The declared type of P3 is the same as the 11 ! declared type of D3. 12 ! Both the actual and dummy arguments are of polymorphic type. 13 CALL SUB2 ( P2 ) ! Valid -- The declared type of P2 is the same as the 14 ! declared type of X2. 15 CALL SUB2 ( P3 ) ! Valid -- The declared type of P3 is extended from 16 ! the declared type of X2. 17 CALL SUB3 ( P2 ) ! Invalid -- The declared type of P2 is neither the 18 ! same as nor extended from the declared 19 ! type of X3. 20 SELECT TYPE ( P2 ) ! Valid conditional alternative to the above 21 CLASS IS ( COLOR_POINT ) ! Works if the dynamic type of P2 is the 22 CALL SUB3 ( P2 ) ! same as the declared type of X3, or a 23 ! type extended therefrom. 24 CLASS DEFAULT 25 ! Cannot work if not. 26 END SELECT 27 CALL SUB3 ( P3 ) ! Valid -- The declared type of P3 is the same as the 28 ! declared type of X3. 29 C.10 Clause 13 notes 30 C.10.1 Module for THIS IMAGE and IMAGE INDEX 31 The intrinsics THIS IMAGE (CO ARRAY) and IMAGE INDEX (CO ARRAY, SUB) cannot be written 32 in Fortran since CO ARRAY may be of any type and THIS IMAGE (CO ARRAY) needs to know the 33 index of the image on which the code is running. 34 As an example, here are simple versions that require the co-bounds to be specified as integer arrays and 35 require the image index for THIS IMAGE (CO ARRAY). 36 MODULE index 37 CONTAINS 38 INTEGER FUNCTION image_index(lbound, ubound, sub) 39 INTEGER, INTENT(IN) :: lbound(:), ubound(:), sub(:) 40 INTEGER :: i, n 41 573 J3/06-007 WORKING DRAFT 2006/07/11 n = SIZE(sub) 1 image_index = sub(n) - lbound(n) 2 DO i = n-1, 1, -1 3 image_index = image_index*(ubound(i)-lbound(i)+1) + sub(i) - lbound(i) 4 END DO 5 image_index = image_index + 1 6 END FUNCTION image_index 7 8 INTEGER FUNCTION this_image(lbound, ubound, me) RESULT(sub) 9 INTEGER, INTENT(IN) :: lbound(:), ubound(:), me 10 INTEGER :: sub(SIZE(lbound)) 11 INTEGER :: extent, i, m, ml, n 12 n = SIZE(sub) 13 m = me - 1 14 DO i = 1, n-1 15 extent = ubound(i) - lbound(i) + 1 16 ml = m 17 m = m/extent 18 sub(i) = ml - m*extent + lbound(i) 19 END DO 20 sub(n) = m + lbound(n) 21 END FUNCTION this_IMAGE 22 END MODULE index 23 C.10.2 Collective co-array subroutine variations 24 The subroutines of 13.5.15 return an array of the same shape as the given co-array after having applied 25 an operation on the images involved. A note there shows how to program the operation being applied to 26 all the elements of the co-array to produce a scalar result. Versions with other arguments can similarly 27 be programmed, for example: 28 MODULE global_sum_module 29 INTRINSIC, PRIVATE :: CO_SUM, SIZE, SUM 30 CONTAINS 31 REAL FUNCTION global_sum_mask(array, mask) 32 REAL,INTENT(IN) :: array(:,:)[*], mask(:,:) 33 REAL,SAVE :: temp[*] 34 temp = SUM(array, MASK=mask) ! Sum of the local part of the co-array. 35 CALL CO_SUM(temp, global_sum_mask) 36 END FUNCTION global_sum_mask 37 38 FUNCTION global_sum(array, dim) 39 REAL, INTENT(IN) :: array(:,:)[*] 40 INTEGER, INTENT(IN) :: dim 41 REAL, ALLOCATABLE :: global_sum(:) 42 REAL, ALLOCATABLE :: temp(:)[:] 43 574 2006/07/11 WORKING DRAFT J3/06-007 ALLOCATE (global_sum(SIZE(array, 3-dim))) 1 ALLOCATE ( temp(SIZE(array, 3-dim))[*]) 2 temp = SUM(array, dim) ! Sum of the local part of the co-array. 3 CALL CO_SUM(temp, global_sum) 4 END FUNCTION global_sum 5 END MODULE global_sum_module 6 C.11 Clause 15 notes 7 C.11.1 Runtime environments 8 This standard allows programs to contain procedures defined by means other than Fortran. That raises 9 the issues of initialization of and interaction between the runtime environments involved. 10 Implementations are free to solve these issues as they see fit, provided that 11 (1) heap allocation/deallocation (e.g., (DE)ALLOCATE in a Fortran subprogram and mal- 12 loc/free in a C function) can be performed without interference, 13 (2) input/output to and from external files can be performed without interference, as long as 14 procedures defined by different means do not do input/output with the same external file, 15 (3) input/output preconnections exist as required by the respective standards, and 16 (4) initialized data is initialized according to the respective standards. 17 C.11.2 Examples of Interop eration between Fortran and C Functions 18 The following examples illustrate the interoperation of Fortran and C functions. Two examples are 19 shown: one of Fortran calling C, and one of C calling Fortran. In each of the examples, the correspon- 20 dences of Fortran actual arguments, Fortran dummy arguments, and C formal parameters are described. 21 C.11.2.1 Example of Fortran calling C 22 C Function Prototype: 23 int C_Library_Function(void* sendbuf, int sendcount, 24 int *recvcounts); 25 Fortran Modules: 26 MODULE FTN_C_1 27 USE, INTRINSIC :: ISO_C_BINDING 28 END MODULE FTN_C_1 29 30 MODULE FTN_C_2 31 INTERFACE 32 INTEGER (C_INT) FUNCTION C_LIBRARY_FUNCTION & 33 (SENDBUF, SENDCOUNT, RECVCOUNTS) & 34 575 J3/06-007 WORKING DRAFT 2006/07/11 BIND(C, NAME='C_Library_Function') 1 USE FTN_C_1 2 IMPLICIT NONE 3 TYPE (C_PTR), VALUE :: SENDBUF 4 INTEGER (C_INT), VALUE :: SENDCOUNT 5 TYPE (C_PTR), VALUE :: RECVCOUNTS 6 END FUNCTION C_LIBRARY_FUNCTION 7 END INTERFACE 8 END MODULE FTN_C_2 9 The module FTN C 2 contains the declaration of the Fortran dummy arguments, which correspond to 10 the C formal parameters. The intrinsic module ISO C BINDING is referenced in the module FTN C 1. 11 The NAME specifier is used in the BIND attribute in order to handle the case-sensitive name change 12 between Fortran and C from 'C LIBRARY FUNCTION' to 'C Library Function'. See also Note 12.43. 13 The first C formal parameter is the pointer to void sendbuf, which corresponds to the Fortran dummy 14 argument SENDBUF, which has the type C PTR and the VALUE attribute. 15 The second C formal parameter is the int sendcount, which corresponds to the Fortran dummy argument 16 SENDCOUNT, which has the type INTEGER(C INT) and the VALUE attribute. 17 The third C formal parameter is the pointer to int recvcounts, which corresponds to the Fortran dummy 18 argument RECVCOUNTS, which has the type C PTR and the VALUE attribute. 19 Fortran Calling Sequence: 20 USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT, C_FLOAT, C_LOC 21 USE FTN_C_2 22 ... 23 REAL (C_FLOAT), TARGET :: SEND(100) 24 INTEGER (C_INT) :: SENDCOUNT 25 INTEGER (C_INT), ALLOCATABLE, TARGET :: RECVCOUNTS(100) 26 ... 27 ALLOCATE( RECVCOUNTS(100) ) 28 ... 29 CALL C_LIBRARY_FUNCTION(C_LOC(SEND), SENDCOUNT, & 30 C_LOC(RECVCOUNTS)) 31 ... 32 The preceding code contains the declaration of the Fortran actual arguments associated with the above- 33 listed Fortran dummy arguments. 34 The first Fortran actual argument is the address of the first element of the array SEND, which has the 35 type REAL(C FLOAT) and the TARGET attribute. This address is returned by the intrinsic function 36 C LOC. This actual argument is associated with the Fortran dummy argument SENDBUF, which has 37 the type C PTR and the VALUE attribute. 38 The second Fortran actual argument is SENDCOUNT of type INTEGER(C INT), which is associated 39 with the Fortran dummy argument SENDCOUNT, which has the type INTEGER(C INT) and the 40 VALUE attribute. 41 576 2006/07/11 WORKING DRAFT J3/06-007 The third Fortran actual argument is the address of the first element of the allocatable array RECV- 1 COUNTS, with has the type REAL(C FLOAT) and the TARGET attribute. This address is returned 2 by the intrinsic function C LOC. This actual argument is associated with the Fortran dummy argument 3 RECVCOUNTS, which has the type C PTR and the VALUE attribute. 4 C.11.2.2 Example of C calling Fortran 5 Fortran Code: 6 SUBROUTINE SIMULATION(ALPHA, BETA, GAMMA, DELTA, ARRAYS) BIND(C) 7 USE, INTRINSIC :: ISO_C_BINDING 8 IMPLICIT NONE 9 INTEGER (C_LONG), VALUE :: ALPHA 10 REAL (C_DOUBLE), INTENT(INOUT) :: BETA 11 INTEGER (C_LONG), INTENT(OUT) :: GAMMA 12 REAL (C_DOUBLE),DIMENSION(*),INTENT(IN) :: DELTA 13 TYPE, BIND(C) :: PASS 14 INTEGER (C_INT) :: LENC, LENF 15 TYPE (C_PTR) :: C, F 16 END TYPE PASS 17 TYPE (PASS), INTENT(INOUT) :: ARRAYS 18 REAL (C_FLOAT), ALLOCATABLE, TARGET, SAVE :: ETA(:) 19 REAL (C_FLOAT), POINTER :: C_ARRAY(:) 20 ... 21 ! Associate C_ARRAY with an array allocated in C 22 CALL C_F_POINTER (ARRAYS%C, C_ARRAY, (/ARRAYS%LENC/) ) 23 ... 24 ! Allocate an array and make it available in C 25 ARRAYS%LENF = 100 26 ALLOCATE (ETA(ARRAYS%LENF)) 27 ARRAYS%F = C_LOC(ETA) 28 ... 29 END SUBROUTINE SIMULATION 30 C Struct Declaration 31 struct pass {int lenc, lenf; float *c, *f;}; 32 C Function Prototype: 33 void simulation(long alpha, double *beta, long *gamma, 34 double delta[], struct pass *arrays); 35 C Calling Sequence: 36 simulation(alpha, &beta, &gamma, delta, &arrays); 37 577 J3/06-007 WORKING DRAFT 2006/07/11 The above-listed Fortran code specifies a subroutine SIMULATION. This subroutine corresponds to the 1 C void function simulation. 2 The Fortran subroutine references the intrinsic module ISO C BINDING. 3 The first Fortran dummy argument of the subroutine is ALPHA, which has the type INTEGER(C - 4 LONG) and the attribute VALUE. This dummy argument corresponds to the C formal parameter 5 alpha, which is a long. The actual C parameter is also a long. 6 The second Fortran dummy argument of the subroutine is BETA, which has the type REAL(C - 7 DOUBLE) and the INTENT(INOUT) attribute. This dummy argument corresponds to the C formal 8 parameter beta, which is a pointer to double. An address is passed as the actual parameter in the C 9 calling sequence. 10 The third Fortran dummy argument of the subroutine is GAMMA, which has the type INTEGER(C - 11 LONG) and the INTENT(OUT) attribute. This dummy argument corresponds to the C formal param- 12 eter gamma, which is a pointer to long. An address is passed as the actual parameter in the C calling 13 sequence. 14 The fourth Fortran dummy argument is the assumed-size array DELTA, which has the type REAL 15 (C DOUBLE) and the attribute INTENT(IN). This dummy argument corresponds to the C formal 16 parameter delta, which is a double array. The actual C parameter is also a double array. 17 The fifth Fortran dummy argument is ARRAYS, which is a structure for accessing an array allocated 18 in C and an array allocated in Fortran. The lengths of these arrays are held in the components LENC 19 and LENF; their C addresses are held in components C and F. 20 C.11.2.3 Example of calling C functions with noninterop erable data 21 Many Fortran processors support 16-byte real numbers, which might not be supported by the C processor. 22 Assume a Fortran programmer wants to use a C procedure from a message passing library for an array 23 of these reals. The C prototype of this procedure is 24 void ProcessBuffer(void *buffer, int n_bytes); 25 with the corresponding Fortran interface 26 USE, INTRINSIC :: ISO_C_BINDING 27 28 INTERFACE 29 SUBROUTINE PROCESS_BUFFER(BUFFER,N_BYTES) BIND(C,NAME="ProcessBuffer") 30 IMPORT :: C_PTR, C_INT 31 TYPE(C_PTR), VALUE :: BUFFER ! The ``C address'' of the array buffer 32 INTEGER(C_INT), VALUE :: N_BYTES ! Number of bytes in buffer 33 END SUBROUTINE PROCESS_BUFFER 34 END INTERFACE 35 This may be done using C LOC if the particular Fortran processor specifies that C LOC returns an 36 appropriate address: 37 REAL(R_QUAD), DIMENSION(:), ALLOCATABLE, TARGET :: QUAD_ARRAY 38 578 2006/07/11 WORKING DRAFT J3/06-007 ... 1 CALL PROCESS_BUFFER(C_LOC(QUAD_ARRAY), INT(16*SIZE(QUAD_ARRAY),C_INT)) 2 ! One quad real takes 16 bytes on this processor 3 C.11.2.4 Example of opaque communication b etween C and Fortran 4 The following example demonstrates how a Fortran processor can make a modern OO random number 5 generator written in Fortran available to a C program: 6 USE, INTRINSIC :: ISO_C_BINDING 7 ! Assume this code is inside a module 8 9 TYPE RANDOM_STREAM 10 ! A (uniform) random number generator (URNG) 11 CONTAINS 12 PROCEDURE(RANDOM_UNIFORM), DEFERRED, PASS(STREAM) :: NEXT 13 ! Generates the next number from the stream 14 END TYPE RANDOM_STREAM 15 16 ABSTRACT INTERFACE 17 ! Abstract interface of Fortran URNG 18 SUBROUTINE RANDOM_UNIFORM(STREAM, NUMBER) 19 IMPORT :: RANDOM_STREAM, C_DOUBLE 20 CLASS(RANDOM_STREAM), INTENT(INOUT) :: STREAM 21 REAL(C_DOUBLE), INTENT(OUT) :: NUMBER 22 END SUBROUTINE RANDOM_UNIFORM 23 END INTERFACE 24 A polymorphic ob ject of base type RANDOM STREAM is not interoperable with C. However, we can 25 make such a random number generator available to C by packaging it inside another nonpolymorphic, 26 nonparameterized derived type: 27 TYPE :: URNG_STATE ! No BIND(C), as this type is not interoperable 28 CLASS(RANDOM_STREAM), ALLOCATABLE :: STREAM 29 END TYPE URNG_STATE 30 The following two procedures will enable a C program to use our Fortran uniform random number 31 generator: 32 ! Initialize a uniform random number generator: 33 SUBROUTINE INITIALIZE_URNG(STATE_HANDLE, METHOD) & 34 BIND(C, NAME="InitializeURNG") 35 TYPE(C_PTR), INTENT(OUT) :: STATE_HANDLE 36 ! An opaque handle for the URNG 37 CHARACTER(C_CHAR), DIMENSION(*), INTENT(IN) :: METHOD 38 ! The algorithm to be used 39 579 J3/06-007 WORKING DRAFT 2006/07/11 1 TYPE(URNG_STATE), POINTER :: STATE 2 ! An actual URNG object 3 4 ALLOCATE(STATE) 5 ! There needs to be a corresponding finalization 6 ! procedure to avoid memory leaks, not shown in this example 7 ! Allocate STATE%STREAM with a dynamic type depending on METHOD 8 ... 9 STATE_HANDLE=C_LOC(STATE) 10 ! Obtain an opaque handle to return to C 11 END SUBROUTINE INITIALIZE_URNG 12 13 ! Generate a random number: 14 SUBROUTINE GENERATE_UNIFORM(STATE_HANDLE, NUMBER) & 15 BIND(C, NAME="GenerateUniform") 16 TYPE(C_PTR), INTENT(IN), VALUE :: STATE_HANDLE 17 ! An opaque handle: Obtained via a call to INITIALIZE_URNG 18 REAL(C_DOUBLE), INTENT(OUT) :: NUMBER 19 20 TYPE(URNG_STATE), POINTER :: STATE 21 ! A pointer to the actual URNG 22 23 CALL C_F_POINTER(CPTR=STATE_HANDLE, FPTR=STATE) 24 ! Convert the opaque handle into a usable pointer 25 CALL STATE%STREAM%NEXT(NUMBER) 26 ! Use the type-bound procedure NEXT to generate NUMBER 27 END SUBROUTINE GENERATE_UNIFORM 28 C.12 Clause 16 notes 29 C.12.1 Examples of host asso ciation (16.5.1.4) 30 The first two examples are examples of valid host association. The third example is an example of invalid 31 host association. 32 Example 1: 33 PROGRAM A 34 INTEGER I, J 35 ... 36 CONTAINS 37 SUBROUTINE B 38 INTEGER I ! Declaration of I hides 39 ! program A's declaration of I 40 ... 41 580 2006/07/11 WORKING DRAFT J3/06-007 I=J ! Use of variable J from program A 1 ! through host association 2 END SUBROUTINE B 3 END PROGRAM A 4 Example 2: 5 PROGRAM A 6 TYPE T 7 ... 8 END TYPE T 9 ... 10 CONTAINS 11 SUBROUTINE B 12 IMPLICIT TYPE (T) (C) ! Refers to type T declared below 13 ! in subroutine B, not type T 14 ! declared above in program A 15 ... 16 TYPE T 17 ... 18 END TYPE T 19 ... 20 END SUBROUTINE B 21 END PROGRAM A 22 Example 3: 23 PROGRAM Q 24 REAL (KIND = 1) :: C 25 ... 26 CONTAINS 27 SUBROUTINE R 28 REAL (KIND = KIND (C)) :: D ! Invalid declaration 29 ! See below 30 REAL (KIND = 2) :: C 31 ... 32 END SUBROUTINE R 33 END PROGRAM Q 34 In the declaration of D in subroutine R, the use of C would refer to the declaration of C in subroutine 35 R, not program Q. However, it is invalid because the declaration of C is required to occur before it is 36 used in the declaration of D (7.1.7). 37 C.12.2 Rules ensuring unambiguous generics (16.3.4) 38 The rules in 16.3.4 are intended to ensure 39 581 J3/06-007 WORKING DRAFT 2006/07/11 · that it is possible to reference each specific procedure in the generic collection, 1 · that for any valid reference to the generic procedure, the determination of the specific procedure 2 referenced is unambiguous, and 3 · that the determination of the specific procedure referenced can be made before execution of the 4 program begins (during compilation). 5 Specific procedures are distinguished by fixed properties of their arguments, specifically type, kind type 6 parameters, and rank. A valid reference to one procedure in a generic collection will differ from another 7 because it has an argument that the other cannot accept, because it is missing an argument that the 8 other requires, or because one of these fixed properties is different. 9 Although the declared type of a data entity is a fixed property, polymorphic variables allow for a 10 limited degree of type mismatch between dummy arguments and actual arguments, so the requirement 11 for distinguishing two dummy arguments is type incompatibility, not merely different types. (This is 12 illustrated in the BAD6 example later in this note.) 13 That same limited type mismatch means that two dummy arguments that are not type incompatible 14 can be distinguished on the basis of the values of the kind type parameters they have in common; if one 15 of them has a kind type parameter that the other does not, that is irrelevant in distinguishing them. 16 Rank is a fixed property, but some forms of array dummy arguments allow rank mismatches when a 17 procedure is referenced by its specific name. In order to allow rank to always be usable in distinguishing 18 generics, such rank mismatches are disallowed for those arguments when the procedure is referenced as 19 part of a generic. Additionally, the fact that elemental procedures can accept array arguments is not 20 taken into account when applying these rules, so apparent ambiguity between elemental and nonelemental 21 procedures is possible; in such cases, the reference is interpreted as being to the nonelemental procedure. 22 For procedures referenced as operators or defined-assignment, syntactically distinguished arguments are 23 mapped to specific positions in the argument list, so the rule for distinguishing such procedures is that 24 it be possible to distinguish the arguments at one of the argument positions. 25 For user-defined derived-type input/output procedures, only the dtv argument corresponds to something 26 explicitly written in the program, so it is the dtv that is required to be distinguished. Because dtv 27 arguments are required to be scalar, they cannot differ in rank. Thus this rule effectively involves only 28 type and kind type parameters. 29 For generic procedures identified by names, the rules are more complicated because optional arguments 30 may be omitted and because arguments may be specified either positionally or by name. 31 In the special case of type-bound procedures with passed-ob ject dummy arguments, the passed-ob ject 32 argument is syntactically distinguished in the reference, so rule (2) can be applied. The type of passed- 33 ob ject arguments is constrained in ways that prevent passed-ob ject arguments in the same scoping unit 34 from being type incompatible. Thus this rule effectively involves only kind type parameters and rank. 35 The primary means of distinguishing named generics is rule (3). The most common application of that 36 rule is a single argument satisfying both (3a) and (3b): 37 INTERFACE GOOD1 38 FUNCTION F1A(X) 39 REAL :: F1A,X 40 END FUNCTION F1A 41 FUNCTION F1B(X) 42 INTEGER :: F1B,X 43 582 2006/07/11 WORKING DRAFT J3/06-007 END FUNCTION F1B 1 END INTERFACE GOOD1 2 Whether one writes GOOD1(1.0) or GOOD1(X=1.0), the reference is to F1A because F1B would require an 3 integer argument whereas these references provide the real constant 1.0. 4 This example and those that follow are expressed using interface bodies, with type as the distinguishing 5 property. This was done to make it easier to write and describe the examples. The principles being 6 illustrated are equally applicable when the procedures get their explicit interfaces in some other way or 7 when kind type parameters or rank are the distinguishing property. 8 Another common variant is the argument that satisfies (3a) and (3b) by being required in one specific 9 and completely missing in the other: 10 INTERFACE GOOD2 11 FUNCTION F2A(X) 12 REAL :: F2A,X 13 END FUNCTION F2A 14 FUNCTION F2B(X,Y) 15 COMPLEX :: F2B 16 REAL :: X,Y 17 END FUNCTION F2B 18 END INTERFACE GOOD2 19 Whether 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 20 F2B, because F2A has no argument in the second position or with the name Y. This approach is used as 21 an alternative to optional arguments when one wants a function to have different result type, kind type 22 parameters, or rank, depending on whether the argument is present. In many of the intrinsic functions, 23 the DIM argument works this way. 24 It is possible to construct cases where different arguments are used to distinguish positionally and by 25 name: 26 INTERFACE GOOD3 27 SUBROUTINE S3A(W,X,Y,Z) 28 REAL :: W,Y 29 INTEGER :: X,Z 30 END SUBROUTINE S3A 31 SUBROUTINE S3B(X,W,Z,Y) 32 REAL :: W,Z 33 INTEGER :: X,Y 34 END SUBROUTINE S3B 35 END INTERFACE GOOD3 36 If one writes GOOD3(1.0,2,3.0,4) to reference S3A, then the third and fourth arguments are consistent 37 with a reference to S3B, but the first and second are not. If one switches to writing the first two 38 arguments as keyword arguments in order for them to be consistent with a reference to S3B, the latter 39 two arguments must also be written as keyword arguments, GOOD3(X=2,W= 1.0,Z=4,Y=3.0), and the 40 named arguments Y and Z are distinguished. 41 583 J3/06-007 WORKING DRAFT 2006/07/11 The ordering requirement in rule (3) is critical: 1 INTERFACE BAD4 ! this interface is invalid ! 2 SUBROUTINE S4A(W,X,Y,Z) 3 REAL :: W,Y 4 INTEGER :: X,Z 5 END SUBROUTINE S4A 6 SUBROUTINE S4B(X,W,Z,Y) 7 REAL :: X,Y 8 INTEGER :: W,Z 9 END SUBROUTINE S4B 10 END INTERFACE BAD4 11 In this example, the positionally distinguished arguments are Y and Z, and it is W and X that are 12 distinguished by name. In this order it is possible to write BAD4(1.0,2,Y=3.0,Z=4), which is a valid 13 reference for both S4A and S4B. 14 Rule (1) can be used to distinguish some cases that are not covered by rule (3): 15 INTERFACE GOOD5 16 SUBROUTINE S5A(X) 17 REAL :: X 18 END SUBROUTINE S5A 19 SUBROUTINE S5B(Y,X) 20 REAL :: Y,X 21 END SUBROUTINE S5B 22 END INTERFACE GOOD5 23 In attempting to apply rule (3), position 2 and name Y are distinguished, but they are in the wrong 24 order, just like the BAD4 example. However, when we try to construct a similarly ambiguous reference, 25 we get GOOD5(1.0,X=2.0), which can't be a reference to S5A because it would be attempting to associate 26 two different actual arguments with the dummy argument X. Rule (3) catches this case by recognizing 27 that S5B requires two real arguments, and S5A cannot possibly accept more than one. 28 The application of rule (1) becomes more complicated when extensible types are involved. If FRUIT is 29 an extensible type, PEAR and APPLE are extensions of FRUIT, and BOSC is an extension of PEAR, then 30 INTERFACE BAD6 ! this interface is invalid ! 31 SUBROUTINE S6A(X,Y) 32 CLASS(PEAR) :: X,Y 33 END SUBROUTINE S6A 34 SUBROUTINE S6B(X,Y) 35 CLASS(FRUIT) :: X 36 CLASS(BOSC) :: Y 37 END SUBROUTINE S6B 38 END INTERFACE BAD6 39 584 2006/07/11 WORKING DRAFT J3/06-007 might, at first glance, seem distinguishable this way, but because of the limited type mismatching allowed, 1 BAD6(A PEAR,A BOSC) is a valid reference to both S6A and S6B. 2 It is important to try rule (1) for each type present: 3 INTERFACE GOOD7 4 SUBROUTINE S7A(X,Y,Z) 5 CLASS(PEAR) :: X,Y,Z 6 END SUBROUTINE S7A 7 SUBROUTINE S7B(X,Z,W) 8 CLASS(FRUIT) :: X 9 CLASS(BOSC) :: Z 10 CLASS(APPLE),OPTIONAL :: W 11 END SUBROUTINE S7B 12 END INTERFACE GOOD7 13 Looking at the most general type, S7A has a minimum and maximum of 3 FRUIT arguments, while S7B 14 has a minimum of 2 and a maximum of three. Looking at the most specific, S7A has a minimum of 0 15 and a maximum of 3 BOSC arguments, while S7B has a minimum of 1 and a maximum of 2. However, 16 when we look at the intermediate, S7A has a minimum and maximum of 3 PEAR arguments, while S7B 17 has a minimum of 1 and a maximum of 2. Because S7A's minimum exceeds S7B's maximum, they can 18 be distinguished. 19 In identifying the minimum number of arguments with a particular set of properties, we exclude optional 20 arguments and test TKR compatibility, so the corresponding actual arguments are required to have 21 those properties. In identifying the maximum number of arguments with those properties, we include 22 the optional arguments and test not distinguishable, so we include actual arguments which could have 23 those properties but are not required to have them. 24 These rules are sufficient to ensure that references to procedures that meet them are unambiguous, but 25 there remain examples that fail to meet these rules but which can be shown to be unambiguous: 26 INTERFACE BAD8 ! this interface is invalid ! 27 ! despite the fact that it is unambiguous ! 28 SUBROUTINE S8A(X,Y,Z) 29 REAL,OPTIONAL :: X 30 INTEGER :: Y 31 REAL :: Z 32 END SUBROUTINE S8A 33 SUBROUTINE S8B(X,Z,Y) 34 INTEGER,OPTIONAL :: X 35 INTEGER :: Z 36 REAL :: Y 37 END SUBROUTINE S8B 38 END INTERFACE BAD8 39 This interface fails rule (3) because there are no required arguments that can be distinguished from the 40 positionally corresponding argument, but in order for the mismatch of the optional arguments not to 41 be relevant, the later arguments must be specified as keyword arguments, so distinguishing by name 42 585 J3/06-007 WORKING DRAFT 2006/07/11 does the trick. This interface is nevertheless invalid so a standard- conforming Fortran processor is not 1 required to do such reasoning. The rules to cover all cases are too complicated to be useful. 2 In addition to not recognizing distinguishable patterns like the one in BAD8, the rules do not distinguish 3 on the basis of any properties other than type, kind type parameters, and rank: 4 INTERFACE BAD9 ! this interface is invalid ! 5 ! despite the fact that it is unambiguous ! 6 SUBROUTINE S9A(X) 7 REAL :: X 8 END SUBROUTINE S9A 9 SUBROUTINE S9B(X) 10 INTERFACE 11 FUNCTION X(A) 12 REAL :: X,A 13 END FUNCTION X 14 END INTERFACE 15 END SUBROUTINE S9B 16 SUBROUTINE S9C(X) 17 INTERFACE 18 FUNCTION X(A) 19 REAL :: X 20 INTEGER :: A 21 END FUNCTION X 22 END INTERFACE 23 END SUBROUTINE S9C 24 END INTERFACE BAD9 25 The real data ob jects that would be valid arguments for S9A are entirely disjoint from procedures that 26 are valid arguments to S9B and S9C, and the procedures that valid arguments for S9B are disjoint from 27 the procedures that are valid arguments to S9C because the former are required to accept real arguments 28 and the latter integer arguments. Again, this interface is invalid, so a standard-conforming Fortran 29 processor need not examine such properties when deciding whether a generic collection is valid. Again, 30 the rules to cover all cases are too complicated to be useful. 31 C.13 Array feature notes 32 C.13.1 Summary of features 33 This subclause is a summary of the principal array features. 34 C.13.1.1 Whole array expressions and assignments (7.4.1.2, 7.4.1.3) 35 An important feature is that whole array expressions and assignments are permitted. For example, the 36 statement 37 A = B + C * SIN (D) 38 where A, B, C, and D are arrays of the same shape, is permitted. It is interpreted element-by-element; 39 586 2006/07/11 WORKING DRAFT J3/06-007 that is, the sine function is taken on each element of D, each result is multiplied by the corresponding 1 element of C, added to the corresponding element of B, and assigned to the corresponding element of 2 A. Functions, including user-written functions, may be arrays and may be generic with scalar versions. 3 All arrays in an expression or across an assignment shall conform; that is, have exactly the same shape 4 (number of dimensions and extents in each dimension), but scalars may be included freely and these are 5 interpreted as being broadcast to a conforming array. Expressions are evaluated before any assignment 6 takes place. 7 C.13.1.2 Array sections (2.4.5, 6.2.2.3) 8 Whenever whole arrays may be used, it is also possible to use subarrays called "sections". For example: 9 A (:, 1:N, 2, 3:1:-1) 10 consists of a subarray containing the whole of the first dimension, positions 1 to N of the second dimen- 11 sion, position 2 of the third dimension and positions 1 to 3 in reverse order of the fourth dimension. 12 This is an artificial example chosen to illustrate the different forms. Of course, a common use may be 13 to select a row or column of an array, for example: 14 A (:, J) 15 C.13.1.3 WHERE statement (7.4.3) 16 The WHERE statement applies a conforming logical array as a mask on the individual operations in the 17 expression and in the assignment. For example: 18 WHERE (A > 0) B = LOG (A) 19 takes the logarithm only for positive components of A and makes assignments only in these positions. 20 The WHERE statement also has a block form (WHERE construct). 21 C.13.1.4 Automatic arrays and allo catable variables (5.2, 5.3.7.4) 22 Two features useful for writing modular software are automatic arrays, created on entry to a subprogram 23 and destroyed on return, and allocatable variables, including arrays whose rank is fixed but whose actual 24 size and lifetime is fully under the programmer's control through explicit ALLOCATE and DEALLO- 25 CATE statements. The declarations 26 SUBROUTINE X (N, A, B) 27 REAL WORK (N, N); REAL, ALLOCATABLE :: HEAP (:, :) 28 specify an automatic array WORK and an allocatable array HEAP. Note that a stack is an adequate 29 storage mechanism for the implementation of automatic arrays, but a heap will be needed for some 30 allocatable variables. 31 C.13.1.5 Array constructors (4.7) 32 Arrays, and in particular array constants, may be constructed with array constructors exemplified by: 33 (/ 1.0, 3.0, 7.2 /) 34 which is a rank-one array of size 3, 35 (/ (1.3, 2.7, L = 1, 10), 7.1 /) 36 587 J3/06-007 WORKING DRAFT 2006/07/11 which is a rank-one array of size 21 and contains the pair of real constants 1.3 and 2.7 repeated 10 times 1 followed by 7.1, and 2 (/ (I, I = 1, N) /) 3 which contains the integers 1, 2, ..., N. Only rank-one arrays may be constructed in this way, but higher 4 dimensional arrays may be made from them by means of the intrinsic function RESHAPE. 5 C.13.2 Examples 6 The array features have the potential to simplify the way that almost any array-using program is con- 7 ceived and written. Many algorithms involving arrays can now be written conveniently as a series of 8 computations with whole arrays. 9 C.13.2.1 Unconditional array computations 10 At the simplest level, statements such as 11 A=B+C 12 or 13 S = SUM (A) 14 can take the place of entire DO loops. The loops were required to perform array addition or to sum all 15 the elements of an array. 16 Further examples of unconditional operations on arrays that are simple to write are: 17 matrix multiply P = MATMUL (Q, R) largest array element L = MAXVAL (P) factorial N F = PRODUCT ((/ (K, K = 2, N) /)) N The Fourier sum F = i=1 ai × cos xi may also be computed without writing a DO loop if one makes 18 use of the element-by-element definition of array expressions as described in Clause 7. Thus, we can 19 write 20 F = SUM (A * COS (X)) 21 The successive stages of calculation of F would then involve the arrays: 22 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)) /) The final scalar result is obtained simply by summing the elements of the last of these arrays. Thus, the 23 processor is dealing with arrays at every step of the calculation. 24 C.13.2.2 Conditional array computations 25 Suppose we wish to compute the Fourier sum in the above example, but to include only those terms 26 a(i) cos x(i) that satisfy the condition that the coefficient a(i) is less than 0.01 in absolute value. More 27 precisely, we are now interested in evaluating the conditional Fourier sum 28 588 2006/07/11 WORKING DRAFT J3/06-007 | ai × cos xi CF = ai |<0.01 where the index runs from 1 to N as before. 1 This can be done by using the MASK parameter of the SUM function, which restricts the summation 2 of the elements of the array A * COS (X) to those elements that correspond to true elements of MASK. 3 Clearly, the mask required is the logical array expression ABS (A) < 0.01. Note that the stages of 4 evaluation of this expression are: 5 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 /) The conditional Fourier sum we arrive at is: 6 CF = SUM (A * COS (X), MASK = ABS (A) < 0.01) 7 If the mask is all false, the value of CF is zero. 8 The use of a mask to define a subset of an array is crucial to the action of the WHERE statement. Thus 9 for example, to zero an entire array, we may write simply A = 0; but to set only the negative elements 10 to zero, we need to write the conditional assignment 11 WHERE (A .LT. 0) A=0 12 The WHERE statement complements ordinary array assignment by providing array assignment to any 13 subset of an array that can be restricted by a logical expression. 14 In the Ising model described below, the WHERE statement predominates in use over the ordinary array 15 assignment statement. 16 C.13.2.3 A simple program: the Ising mo del 17 The Ising model is a well-known Monte Carlo simulation in 3-dimensional Euclidean space which is 18 useful in certain physical studies. We will consider in some detail how this might be programmed. The 19 model may be described in terms of a logical array of shape N by N by N. Each gridpoint is a single 20 logical variable which is to be interpreted as either an up-spin (true) or a down-spin (false). 21 The Ising model operates by passing through many successive states. The transition to the next state is 22 governed by a local probabilistic process. At each transition, all gridpoints change state simultaneously. 23 Every spin either flips to its opposite state or not according to a rule that depends only on the states 24 of its 6 nearest neighbors in the surrounding grid. The neighbors of gridpoints on the boundary faces of 25 the model cube are defined by assuming cubic periodicity. In effect, this extends the grid periodically 26 by replicating it in all directions throughout space. 27 The rule states that a spin is flipped to its opposite parity for certain gridpoints where a mere 3 or 28 fewer of the 6 nearest neighbors have the same parity as it does. Also, the flip is executed only with 29 probability 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 30 rule seems to promote neighborhood alignments that may presumably lead to equilibrium in the long 31 run.) 32 589 J3/06-007 WORKING DRAFT 2006/07/11 C.13.2.3.1 Problems to b e solved 1 Some of the programming problems that we will need to solve in order to translate the Ising model into 2 Fortran statements using entire arrays are 3 (1) counting nearest neighbors that have the same spin, 4 (2) providing an array function to return an array of random numbers, and 5 (3) determining which gridpoints are to be flipped. 6 C.13.2.3.2 Solutions in Fortran 7 The arrays needed are: 8 LOGICAL ISING (N, N, N), FLIPS (N, N, N) 9 INTEGER ONES (N, N, N), COUNT (N, N, N) 10 REAL THRESHOLD (N, N, N) 11 The array function needed is: 12 FUNCTION RAND (N) 13 REAL RAND (N, N, N) 14 The transition probabilities are specified in the array 15 REAL P (6) 16 The first task is to count the number of nearest neighbors of each gridpoint g that have the same spin 17 as g . 18 Assuming that ISING is given to us, the statements 19 ONES = 0 20 WHERE (ISING) ONES = 1 21 make the array ONES into an exact analog of ISING in which 1 stands for an up-spin and 0 for a 22 down-spin. 23 The next array we construct, COUNT, will record for every gridpoint of ISING the number of spins to 24 be found among the 6 nearest neighbors of that gridpoint. COUNT will be computed by adding together 25 6 arrays, one for each of the 6 relative positions in which a nearest neighbor is found. Each of the 6 26 arrays is obtained from the ONES array by shifting the ONES array one place circularly along one of 27 its dimensions. This use of circular shifting imparts the cubic periodicity. 28 COUNT = CSHIFT (ONES, SHIFT = -1, DIM = 1) & 29 + CSHIFT (ONES, SHIFT = 1, DIM = 1) & 30 + CSHIFT (ONES, SHIFT = -1, DIM = 2) & 31 + CSHIFT (ONES, SHIFT = 1, DIM = 2) & 32 + CSHIFT (ONES, SHIFT = -1, DIM = 3) & 33 + CSHIFT (ONES, SHIFT = 1, DIM = 3) 34 At this point, COUNT contains the count of nearest neighbor up-spins even at the gridpoints where 35 the Ising model has a down-spin. But we want a count of down-spins at those gridpoints, so we correct 36 COUNT at the down (false) points of ISING by writing: 37 590 2006/07/11 WORKING DRAFT J3/06-007 WHERE (.NOT. ISING) COUNT = 6 - COUNT 1 Our ob ject now is to use these counts of what may be called the "like-minded nearest neighbors" to 2 decide which gridpoints are to be flipped. This decision will be recorded as the true elements of an array 3 FLIPS. The decision to flip will be based on the use of uniformly distributed random numbers from the 4 interval 0 p < 1. These will be provided at each gridpoint by the array function RAND. The flip will 5 occur at a given point if and only if the random number at that point is less than a certain threshold 6 value. In particular, by making the threshold value equal to 1 at the points where there are 3 or fewer 7 like-minded nearest neighbors, we guarantee that a flip occurs at those points (because p is always less 8 than 1). Similarly, the threshold values corresponding to counts of 4, 5, and 6 are assigned P (4), P (5), 9 and P (6) in order to achieve the desired probabilities of a flip at those points (P (4), P (5), and P (6) 10 are input parameters in the range 0 to 1). 11 The thresholds are established by the statements: 12 THRESHOLD = 1.0 13 WHERE (COUNT == 4) THRESHOLD = P (4) 14 WHERE (COUNT == 5) THRESHOLD = P (5) 15 WHERE (COUNT == 6) THRESHOLD = P (6) 16 and the spins that are to be flipped are located by the statement: 17 FLIPS = RAND (N) <= THRESHOLD 18 All that remains to complete one transition to the next state of the ISING model is to reverse the spins 19 in ISING wherever FLIPS is true: 20 WHERE (FLIPS) ISING = .NOT. ISING 21 C.13.2.3.3 The complete Fortran subroutine 22 The complete code, enclosed in a subroutine that performs a sequence of transitions, is as follows: 23 SUBROUTINE TRANSITION (N, ISING, ITERATIONS, P) 24 25 LOGICAL ISING (N, N, N), FLIPS (N, N, N) 26 INTEGER ONES (N, N, N), COUNT (N, N, N) 27 REAL THRESHOLD (N, N, N), P (6) 28 29 DO I = 1, ITERATIONS 30 ONES = 0 31 WHERE (ISING) ONES = 1 32 COUNT = CSHIFT (ONES, -1, 1) + CSHIFT (ONES, 1, 1) & 33 + CSHIFT (ONES, -1, 2) + CSHIFT (ONES, 1, 2) & 34 + CSHIFT (ONES, -1, 3) + CSHIFT (ONES, 1, 3) 35 WHERE (.NOT. ISING) COUNT = 6 - COUNT 36 THRESHOLD = 1.0 37 WHERE (COUNT == 4) THRESHOLD = P (4) 38 WHERE (COUNT == 5) THRESHOLD = P (5) 39 WHERE (COUNT == 6) THRESHOLD = P (6) 40 591 J3/06-007 WORKING DRAFT 2006/07/11 FLIPS = RAND (N) <= THRESHOLD 1 WHERE (FLIPS) ISING = .NOT. ISING 2 END DO 3 4 CONTAINS 5 FUNCTION RAND (N) 6 REAL RAND (N, N, N) 7 CALL RANDOM_NUMBER (HARVEST = RAND) 8 RETURN 9 END FUNCTION RAND 10 END 11 C.13.2.3.4 Reduction of storage 12 The array ISING could be removed (at some loss of clarity) by representing the model in ONES all the 13 time. The array FLIPS can be avoided by combining the two statements that use it as: 14 WHERE (RAND (N) <= THRESHOLD) ISING = .NOT. ISING 15 but an extra temporary array would probably be needed. Thus, the scope for saving storage while 16 performing whole array operations is limited. If N is small, this will not matter and the use of whole 17 array operations is likely to lead to good execution speed. If N is large, storage may be very important 18 and adequate efficiency will probably be available by performing the operations plane by plane. The 19 resulting code is not as elegant, but all the arrays except ISING will have size of order N2 instead of N3 . 20 C.13.3 FORmula TRANslation and array pro cessing 21 Many mathematical formulas can be translated directly into Fortran by use of the array processing 22 features. 23 We assume the following array declarations: 24 REAL X (N), A (M, N) 25 Some examples of mathematical formulas and corresponding Fortran expressions follow. 26 C.13.3.1 A sum of pro ducts 27 The expression jN iM aij =1 =1 can be formed using the Fortran expression 28 SUM (PRODUCT (A, DIM=1)) 29 The argument DIM=t means that the product is to be computed down each column of A. If A had the 1 30 B CD value he result of this expression is BE + CF + DG. 31 EFG 592 2006/07/11 WORKING DRAFT J3/06-007 C.13.3.2 A pro duct of sums 1 The expression iM jN aij =1 =1 can be formed using the Fortran expression 2 PRODUCT (SUM (A, DIM = 2)) 3 The argument DIM t= 2 means that the sum is to be computed along each row of A. If A had the 4 B CD value he result of this expression is (B+C+D)(E+F+G). 5 EFG C.13.3.3 Addition of selected elements 6 The expression x xi i >0.0 can be formed using the Fortran expression 7 SUM (X, MASK = X > 0.0) 8 The mask locates the positive elements of the array of rank one. If X has the vector value (0.0, -0.1, 9 0.2, 0.3, 0.2, -0.1, 0.0), the result of this expression is 0.7. 10 C.13.4 Sum of squared residuals 11 The expression iN (xi - xmean )2 =1 can be formed using the Fortran statements 12 XMEAN = SUM (X) / SIZE (X) 13 SS = SUM ((X - XMEAN) ** 2) 14 Thus, SS is the sum of the squared residuals. 15 C.13.5 Vector norms: infinity-norm and one-norm 16 The infinity-norm of vector X = (X (1), ..., X(N)) is defined as the largest of the numbers ABS (X(1)), 17 ..., ABS(X(N)) and therefore has the value MAXVAL (ABS(X)). 18 The one-norm of vector X is defined as the sum of the numbers ABS (X (1)), ..., ABS (X (N)) and 19 therefore has the value SUM ( ABS (X)). 20 C.13.6 Matrix norms: infinity-norm and one-norm 21 The infinity-norm of the matrix A = (A (I, J)) is the largest row-sum of the matrix ABS (A (I, J)) and 22 therefore has the value MAXVAL (SUM (ABS (A), DIM = 2)). 23 The one-norm of the matrix A = (A (I, J)) is the largest column-sum of the matrix ABS (A (I, J)) and 24 therefore has the value MAXVAL (SUM (ABS (A), DIM = 1)). 25 593 J3/06-007 WORKING DRAFT 2006/07/11 C.13.7 Logical queries 1 The intrinsic functions allow quite complicated questions about tabular data to be answered without 2 use of loops or conditional constructs. Consider, for example, the questions asked below about a simple 3 tabulation of students' test scores. 4 Suppose the rectangular table T (M, N) contains the test scores of M students who have taken N different 5 tests. T is an integer matrix with entries in the range 0 to 100. 6 Example: The scores on 4 tests made by 3 students are held as the table 7 T= 85 76 90 60 71 45 50 80 66 45 21 55 Question: What is each student's top score? 8 Answer: MAXVAL (T, DIM = 2); in the example: [90, 80, 66]. 9 Question: What is the average of all the scores? 10 Answer: SUM (T) / SIZE (T); in the example: 62. 11 Question: How many of the scores in the table are above average? 12 Answer: ABOVE = T > SUM (T) / IZE (T); S N = COUNT (ABOVE); in the example: ABOVE is the 13 ttt . logical array (t = true, . = false): t . . t and COUNT (ABOVE) is 6. 14 t.. . Question: What was the lowest score in the above-average group of scores? 15 Answer: MINVAL (T, MASK = ABOVE), where ABOVE is as defined previously; in the example: 66. 16 Question: Was there a student whose scores were all above average? 17 Answer: With ABOVE as previously defined, the answer is yes or no according as the value of the 18 expression ANY (ALL (ABOVE, DIM = 2)) is true or false; in the example, the answer is no. 19 C.13.8 Parallel computations 20 The most straightforward kind of parallel processing is to do the same thing at the same time to many 21 operands. Matrix addition is a good example of this very simple form of parallel processing. Thus, the 22 array assignment A = B + C specifies that corresponding elements of the identically-shaped arrays B 23 and C be added together in parallel and that the resulting sums be assigned in parallel to the array A. 24 The process being done in parallel in the example of matrix addition is of course the process of addi- 25 tion; the array feature that implements matrix addition as a parallel process is the element-by-element 26 evaluation of array expressions. 27 These observations lead us to look to element-by-element computation as a means of implementing other 28 simple parallel processing algorithms. 29 594 2006/07/11 WORKING DRAFT J3/06-007 C.13.9 Example of element-by-element computation 1 Several polynomials of the same degree may be evaluated at the same point by arranging their coefficients 2 as the rows of a matrix and applying Horner's method for polynomial evaluation to the columns of the 3 matrix so formed. 4 The procedure is illustrated by the code to evaluate the three cubic polynomials 5 P (t) = 1 + 2t - 3t2 + 4t3 Q(t) = 2 - 3t + 4t2 - 5t3 R(t) = 3 + 4t - 5t2 + 6t3 in parallel at the point t = X and to place the resulting vector of numbers [P (X), Q (X), R (X)] in the 6 real array RESULT (3). 7 The code to compute RESULT is just the one statement 8 RESULT = M (:, 1) + X * (M (:, 2) + X * (M (:, 3) + X * M (:, 4))) 9 1 2 -3 4 where M represents the matrix M (3, 4) with value 2 -3 4 -5 . 3 4 -5 6 10 C.13.10 Bit manipulation and inquiry pro cedures 11 The procedures IOR, IAND, NOT, IEOR, ISHFT, ISHFTC, IBITS, MVBITS, BTEST, IBSET, and 12 IBCLR are defined by MIL-STD 1753 for scalar arguments and are extended in this standard to accept 13 array arguments and to return array results. 14 595 J3/06-007 WORKING DRAFT 2006/07/11 596 2006/07/11 WORKING DRAFT J3/06-007 Annex D (Informative) Syntax rules D.1 Extract of all syntax rules Section 1: R101 xyz-list is xyz [ , xyz ] ... R102 xyz-name is name R103 scalar-xyz is xyz (R103) scalar-xyz shall be scalar. C101 Section 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 597 J3/06-007 WORKING DRAFT 2006/07/11 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 al locatable-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 foral l-construct or if-construct or select-type-construct or where-construct R214 action-stmt is al locate-stmt or assignment-stmt or backspace-stmt or cal l-stmt or close-stmt or continue-stmt or cycle-stmt 598 2006/07/11 WORKING DRAFT J3/06-007 or deal locate-stmt or endfile-stmt or end-function-stmt or end-program-stmt or end-subroutine-stmt or exit-stmt or flush-stmt or foral l-stmt or goto-stmt or if-stmt or inquire-stmt or notify-stmt or nul lify-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-al l-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 (R208) An execution-part shall not contain an end-function-stmt , end-program-stmt , or end- C201 subroutine-stmt . R215 keyword is name Section 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 or real-literal-constant 599 J3/06-007 WORKING DRAFT 2006/07/11 or complex-literal-constant or logical-literal-constant or char-literal-constant or boz-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-attribute -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-attribute is access-spec R317 macro-declaration-stmt is macro-type-declaration-stmt or macro-optional-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-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] C306 (R318) 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 (R320) If macro-expr appears, when the macro is expanded it shall be of type integer, and have a non-negative value that specifies a representation method that exists on the processor. R321 macro-body-block is [ macro-body-construct ] ... R322 macro-body-construct is macro-definition or expand-stmt 600 2006/07/11 WORKING DRAFT J3/06-007 or macro-body-stmt or macro-do-construct or macro-if-construct 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. R323 macro-do-construct is macro-do-stmt macro-body-block macro-end-do-stmt R324 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , macro-do-limit [ , macro-do-limit ] C310 (R324) A macro-do-variable-name shall be a local variable of the macro being defined, and shall not be a macro dummy argument. R325 macro-do-limit is macro-expr (R325) A macro-do-limit shall expand to an expression of type integer. C311 R326 macro-end-do-stmt is MACRO END DO R327 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 R328 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN R329 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN R330 macro-else-stmt is MACRO ELSE R331 macro-end-if-stmt is MACRO END IF R332 macro-condition is macro-expr C312 (R332) A macro condition shall expand to an expression of type logical. R333 macro-body-stmt is result-token [ result-token ] ... [ && ] (R333) The first result-token shall not be MACRO unless the second result-token is not a keyword C313 or name. R334 result-token is token [ %% token ] ... C314 (R334) The concatenated textual token s in a result-token shall have the form of a lexical token. R335 token is any lexical token including labels, keywords, and semi-colon. C315 && shall not appear in the last macro-body-stmt of a macro definition. C316 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. R336 end-macro-stmt is END MACRO [ macro-name ] C317 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name in the DEFINE MACRO statement. R337 macro-expr is basic-token-sequence C318 (R337) A macro-expr shall expand to a scalar initialization expression. R338 expand-stmt is EXPAND macro-name [ ( macro-actual-arg -list ) ] C319 (R338) macro-name shall be the name of a macro that was previously defined or accessed via use or host association. (R338) The macro shall expand to a sequence or zero or more complete Fortran statements. C320 C321 (R338) The statements produced by a macro expansion shall conform to the syntax rules and 601 J3/06-007 WORKING DRAFT 2006/07/11 constraints as if they physically replaced the EXPAND statement prior to program processing. (R338) The statements produced by a macro expansion shall not include a statement which C322 ends the scoping unit containing the EXPAND statement. C323 (R338) If a macro expansion produces a statement which begins a new scoping unit, it shall also produce a statement which ends that scoping unit. (R338) If the EXPAND statement appears as the action-stmt of an if-stmt , it shall expand to C324 exactly one action-stmt that is not an if-stmt , end-program-stmt , end-function-stmt , or end- subroutine-stmt . C325 (R338) If the EXPAND statement appears as a do-term-action-stmt , it shall expand to exactly one action-stmt that is not a continue-stmt , a goto-stmt , a return-stmt , a stop-stmt , an exit- stmt , a cycle-stmt , an end-function-stmt , an end-subroutine-stmt , an end-program-stmt , or an arithmetic-if-stmt . (R338) If the EXPAND statement has a label, the expansion of the macro shall produce at least C326 one statement, and the first statement produced shall not have a label. (R338) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- C327 gument. C328 (R338) At most one macro-actual-arg shall appear corresponding to each optional macro dummy argument. R339 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value C329 (R339) macro-dummy-name shall be the name of a macro dummy argument of the macro being expanded. C330 (R338) The macro-dummy-name = shall not be omitted unless it has been omitted from each preceding macro-actual-arg in the expand-stmt . R340 macro-actual-arg-value is basic-token-sequence R341 basic-token-sequence is basic-token or [ basic-token-sequence ] nested-token-sequence [ basic-token-sequence ] or basic-token basic-token-sequence R342 basic-token is any lexical token except comma, parentheses, array constructor delimiters, and semi-colon. R343 nested-token-sequence is ( [ arg-token ] ... ) or (/ [ arg-token ] ... /) or lbracket [ arg-token ] ... rbracket R344 arg-token is basic-token or , Section 4: R401 type-param-value is scalar-int-expr or * or : C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. C402 (R401) A colon may be used as a type-param-value only 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 ) 602 2006/07/11 WORKING DRAFT J3/06-007 or CLASS ( derived-type-spec ) or CLASS ( * ) (R403) In a declaration-type-spec , every type-param-value that is not a colon or an asterisk shall C404 be a specification-expr . (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify C405 an extensible type. 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 or D R416 exponent is signed-digit-string C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. (R413) The value of kind-param shall specify an approximation method that exists on the C413 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 603 J3/06-007 WORKING DRAFT 2006/07/11 or signed-real-literal-constant or named-constant (R417) Each named constant in a complex literal constant shall be of type integer or real. C414 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 scalar-int-literal-constant (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- C415 resentation method that exists on the processor. C416 (R422) The scalar-int-literal-constant shall not include a kind-param . (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr . C417 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 b e an array, a p ointer, 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 p ermitted only if no double-colon separator app ears in the type-declaration-stmt . C423 (R420) The length sp ecified for a character statement function or for a statement function dummy argument of typ e character shall b e 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 boz-literal-constant is binary-constant [ kind-param ] 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 ] ... " 604 2006/07/11 WORKING DRAFT J3/06-007 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. (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt . C429 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). C430 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. R433 private-or-sequence is private-components-stmt or sequence-stmt C434 (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 ] C435 (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 . R435 sequence-stmt is SEQUENCE (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type C436 or of a sequence derived type. C437 (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 ] C438 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the type-param-name s in the derived-type-stmt of that derived-type-def . C439 (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 605 J3/06-007 WORKING DRAFT 2006/07/11 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 component-dim-spec or CONTIGUOUS or POINTER R443 component-decl is component-name [ ( component-array-spec ) ] [ lbracket co-array-spec rbracket ] [ * char-length ] [ component-initialization ] R444 component-dim-spec is DIMENSION ( component-array-spec ) or DIMENSION [ ( deferred-shape-spec -list ) ] lbracket co-array-spec rbracket R445 component-array-spec is explicit-shape-spec -list or deferred-shape-spec -list C440 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt . C441 (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. (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in C442 the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible derived type including the type being defined. C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec shall be a deferred-shape-spec -list. C444 (R441) If a co-array-spec appears, it shall be a deferred-shape-spec -list and the component shall have the ALLOCATABLE attribute. C445 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. C446 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each component-array-spec shall be an explicit-shape-spec -list. C447 (R445) Each bound in the explicit-shape-spec shall either be an initialization expression or be a specification expression that does not contain references to specification functions or any ob ject designators other than named constants or subob jects thereof. C448 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the C449 POINTER attribute. C450 (R443) The * char-length option is permitted only if the component is of type character. C451 (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 ob ject designators other than named constants or subob jects thereof. R446 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , proc-component-attr-spec -list :: proc-decl -list R447 proc-component-attr-spec is POINTER or PASS [ (arg-name ) ] or NOPASS 606 2006/07/11 WORKING DRAFT J3/06-007 or access-spec (R446) The same proc-component-attr-spec shall not appear more than once in a given proc- C452 component-def-stmt . C453 (R446) POINTER shall appear in each proc-component-attr-spec -list. C454 (R446) If the procedure pointer component has an implicit interface or has no arguments, NOPASS shall be specified. C455 (R446) If PASS (arg-name ) appears, the interface shall have a dummy argument named arg- name . (R446) PASS and NOPASS shall not both appear in the same proc-component-attr-spec -list. C456 C457 The passed-ob ject dummy argument shall be a scalar, nonpointer, nonallocatable dummy data ob ject 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. R448 component-initialization is = initialization-expr or => nul l-init or => initial-data-target R449 initial-data-target is designator C458 (R441) If component-initialization appears, a double-colon separator shall appear before the component-decl -list. C459 (R441) If component-initialization appears, every type parameter and array bound of the com- ponent shall be an initialization expression. (R441) If => appears in component-initialization , POINTER shall appear in the component- C460 attr-spec -list. If = appears in component-initialization , POINTER or ALLOCATABLE shall not appear in the component-attr-spec -list. C461 (R448) If initial-data-target appears, component-name shall be data-pointer-initialization com- patible with it. (R449) The designator shall designate a variable that is an initialization target. Every subscript, C462 section subscript, substring starting point, and substring ending point in designator shall be an initialization expression. R450 private-components-stmt is PRIVATE C463 (R450) A private-components-stmt is permitted only if the type definition is within the specifi- cation part of a module. R451 type-bound-procedure-part is contains-stmt [ binding-private-stmt ] [ proc-binding-stmt ] ... R452 binding-private-stmt is PRIVATE C464 (R451) A binding-private-stmt is permitted only if the type definition is within the specification part of a module. R453 proc-binding-stmt is specific-binding or generic-binding or final-binding R454 specific-binding is PROCEDURE [ (interface-name ) ] [ [ , binding-attr -list ] :: ] binding-name [ => procedure-name ] C465 (R454) If => procedure-name appears, the double-colon separator shall appear. (R454) If => procedure-name appears, interface-name shall not appear. C466 C467 (R454) The procedure-name shall be the name of an accessible module procedure or an external procedure that has an explicit interface. R455 generic-binding is GENERIC 607 J3/06-007 WORKING DRAFT 2006/07/11 [, access-spec ] :: generic-spec => binding-name -list (R455) Within the specification-part of a module, each generic-binding shall specify, either C468 implicitly or explicitly, the same accessibility as every other generic-binding with that generic- spec in the same derived type. C469 (R455) Each binding-name in binding-name -list shall be the name of a specific binding of the type. (R455) If generic-spec is not generic-name , each of its specific bindings shall have a passed-ob ject C470 dummy argument (4.5.4.4). C471 (R455) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall be as specified in 12.4.2.1.1. C472 (R455) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified in 12.4.2.1.2. (R455) If generic-spec is dtio-generic-spec , the interface of each binding shall be as specified in C473 9.5.3.7. The type of the dtv argument shall be type-name . R456 binding-attr is PASS [ (arg-name ) ] or NOPASS or NON OVERRIDABLE or DEFERRED or access-spec C474 (R456) The same binding-attr shall not appear more than once in a given binding-attr -list. C475 (R454) If the interface of the binding has no dummy argument of the type being defined, NOPASS shall appear. (R454) If PASS (arg-name ) appears, the interface of the binding shall have a dummy argument C476 named arg-name . C477 (R456) PASS and NOPASS shall not both appear in the same binding-attr -list. C478 (R456) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- attr -list. (R456) DEFERRED shall appear if and only if interface-name appears. C479 C480 (R454) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding it overrides is deferred. (R454) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- C481 RIDABLE attribute. R457 final-binding is FINAL [ :: ] final-subroutine-name -list C482 (R457) A final-subroutine-name shall be the name of a module procedure with exactly one 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 be INTENT(OUT). C483 (R457) A final-subroutine-name shall not be one previously specified as a final subroutine for that type. (R457) A final subroutine shall not have a dummy argument with the same kind type parameters C484 and rank as the dummy argument of another final subroutine of that type. R458 derived-type-spec is type-name [ ( type-param-spec -list ) ] R459 type-param-spec is [ keyword = ] type-param-value C485 (R458) type-name shall be the name of an accessible derived type. C486 (R458) type-param-spec -list shall appear only if the type is parameterized. C487 (R458) 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. C488 (R459) The keyword = may be omitted from a type-param-spec only if the keyword = has been 608 2006/07/11 WORKING DRAFT J3/06-007 omitted from each preceding type-param-spec in the type-param-spec -list. (R459) Each keyword shall be the name of a parameter of the type. C489 C490 (R459) 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. R460 structure-constructor is derived-type-spec ( [ component-spec -list ] ) R461 component-spec is [ keyword = ] component-data-source R462 component-data-source is expr or data-target or proc-target C491 (R460) The derived-type-spec shall not specify an abstract type (4.5.7). C492 (R460) At most one component-spec shall be provided for a component. C493 (R460) 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. C494 (R460) 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. C495 (R461) The keyword = may be omitted from a component-spec only if the keyword = has been omitted from each preceding component-spec in the constructor. C496 (R461) Each keyword shall be the name of a component of the type. C497 (R460) 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. C498 (R460) 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 (12.5.4.1). C499 (R462) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall correspond to a procedure pointer component. C4100 (R462) A data-target shall have the same rank as its corresponding component. R463 enum-def is enum-def-stmt enumerator-def-stmt [ enumerator-def-stmt ] ... end-enum-stmt R464 enum-def-stmt is ENUM, BIND(C) R465 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator -list R466 enumerator is named-constant [ = scalar-int-initialization-expr ] R467 end-enum-stmt is END ENUM C4101 (R465) If = appears in an enumerator , a double-colon separator shall appear before the enu- merator -list. R468 array-constructor is (/ ac-spec /) or lbracket ac-spec rbracket R469 ac-spec is type-spec :: or [type-spec ::] ac-value -list R470 lbracket is [ R471 rbracket is ] R472 ac-value is expr or ac-implied-do R473 ac-implied-do is ( ac-value -list , ac-implied-do-control ) R474 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr 609 J3/06-007 WORKING DRAFT 2006/07/11 [ , scalar-int-expr ] R475 ac-do-variable is do-variable C4102 (R469) If type-spec is omitted, each ac-value expression in the array-constructor shall have the same type and kind type parameters. C4103 (R469) 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.10. C4104 (R469) 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 . C4105 (R473) 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 . Section 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 consist of a single entity-decl . (R501) If a language-binding-spec is specified, the entity-decl -list shall not contain any procedure C503 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 ob ject in a named common block unless the type declaration is in a block data program unit, an ob ject in blank common, an allocatable variable, an external function, an intrinsic function, 610 2006/07/11 WORKING DRAFT J3/06-007 or an automatic ob ject. (R503) An initialization shall appear if the entity is a named constant (5.3.12). C507 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 (R504) The object-name shall be the name of a data ob ject. C509 R505 initialization is = initialization-expr or => nul l-init or => initial-data-target R506 nul l-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. (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible C511 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 entity shall not be explicitly given any attribute more than once in a scoping unit. C514 An array-spec for a function result that does not have the ALLOCATABLE or POINTER attribute shall be an explicit-shape-spec -list. C515 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 C516 (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 ]) C517 An entity with the BIND attribute shall be a common block, variable, or procedure. C518 A variable with the BIND attribute shall be declared in the specification part of a module. C519 A variable with the BIND attribute shall be interoperable (15.3). C520 Each variable of a common block with the BIND attribute shall be interoperable. C521 (R508) The scalar-char-initialization-expr shall be of default character kind. C522 An entity that has 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 C523 (R501) A co-array that has the ALLOCATABLE attribute shall be specified with a co-array-spec that is a deferred-shape-spec -list. C524 A co-array shall be a component or a variable that is not a function result. C525 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. 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-shape-spec -list or assumed-size-spec C526 The sum of the rank and co-rank of an entity shall not exceed fifteen. R512 explicit-shape-spec is [ lower-bound : ] upper-bound 611 J3/06-007 WORKING DRAFT 2006/07/11 R513 lower-bound is specification-expr R514 upper-bound is specification-expr C527 (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 : C528 An array that has 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 -list , ] [ lower-bound : ] * C529 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy data argument. C530 An assumed-size array with INTENT (OUT) shall not be polymorphic, ofa 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 : ] * C531 An implied-shape array shall be a named constant. C532 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. R519 intent-spec is IN or OUT or INOUT C533 An entity with the INTENT attribute shall be a dummy data ob ject or a dummy procedure pointer. C534 (R519) A nonpointer ob ject with the INTENT (IN) attribute shall not appear in a variable definition context (16.6.7). C535 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context (16.6.8). C536 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.2.1) 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 16.3.4. C537 An entity with the OPTIONAL attribute shall be a dummy argument. C538 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. C539 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or TARGET attribute. C540 A procedure with the POINTER attribute shall have the EXTERNAL attribute. C541 A co-array shall not have the POINTER attribute. C542 The PROTECTED attribute shall be specified only in the specification part of a module. C543 An entity with the PROTECTED attribute shall be a procedure pointer or variable. C544 An entity with the PROTECTED attribute shall not be in a common block. C545 A nonpointer ob ject 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 . C546 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 nul lify-stmt , (2) An al locate-object in an al locate-stmt or deal locate-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. 612 2006/07/11 WORKING DRAFT J3/06-007 C547 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. C548 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic data ob ject, or an ob ject that is in a common block. C549 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared in the main program, or allocatable and declared in a non-recursive procedure. (R501) If the type specified has a co-array ultimate component, each entity in the entity-decl -list C550 shall have the SAVE attribute unless it is a dummy argument, declared in the main program, or declared in a non-recursive procedure. C551 An entity with the TARGET attribute shall be a variable. C552 An entity with the TARGET attribute shall not have the POINTER attribute. C553 An entity with the VALUE attribute shall be a scalar dummy data ob ject. C554 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. C555 If an entity has the VALUE attribute, any length type parameter value in its declaration shall be omitted or specified by an initialization expression. C556 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy argument. R520 access-stmt is access-spec [ [ :: ] access-id -list ] R521 access-id is use-name or generic-spec (R520) An access-stmt shall appear only in the specification-part of a module. Only one ac- C557 cessibility statement with an omitted access-id -list is permitted in the specification-part of a module. C558 (R521) Each use-name shall be the name of a named variable, procedure, derived type, named constant, namelist group, or macro. R522 al locatable-stmt is ALLOCATABLE [ :: ] al locatable-decl -list R523 al locatable-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] R524 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name -list R525 bind-stmt is language-binding-spec [ :: ] bind-entity -list R526 bind-entity is entity-name or / common-block-name / C559 (R525) If the language-binding-spec has a NAME= specifier, the bind-entity -list shall consist of a single bind-entity . R527 contiguous-stmt is CONTIGUOUS [ :: ] object-name -list R528 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... R529 data-stmt-set is data-stmt-object -list / data-stmt-value -list / R530 data-stmt-object is variable or data-implied-do R531 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 ] ) R532 data-i-do-object is array-element or scalar-structure-component or data-implied-do 613 J3/06-007 WORKING DRAFT 2006/07/11 R533 data-i-do-variable is do-variable C560 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. (R530) In a variable that is a data-stmt-object , any subscript, section subscript, substring start- C561 ing point, and substring ending point shall be an initialization expression. (R530) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall C562 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 ob ject, or an allocatable variable. C563 (R530) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an ob ject designator in which a pointer appears other than as the entire rightmost part-ref . (R532) The array-element shall be a variable. C564 (R532) The scalar-structure-component shall be a variable. C565 C566 (R532) The scalar-structure-component shall contain at least one part-ref that contains a sub- script -list. (R532) In an array-element or scalar-structure-component that is a data-i-do-object , any sub- C567 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 . R534 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant R535 data-stmt-repeat is scalar-int-constant or scalar-int-constant-subobject C568 (R535) 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. R536 data-stmt-constant is scalar-constant or scalar-constant-subobject or signed-int-literal-constant or signed-real-literal-constant or nul l-init or initial-data-target or structure-constructor C569 (R536) 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. (R536) If a data-stmt-constant is a structure-constructor , it shall be an initialization expression. C570 R537 int-constant-subobject is constant-subobject C571 (R537) int-constant-subobject shall be of type integer. R538 constant-subobject is designator (R538) constant-subobject shall be a subob ject of a constant. C572 C573 (R538) Any subscript, substring starting point, or substring ending point shall be an initializa- tion expression. R539 dimension-stmt is DIMENSION [ :: ] dimension-decl -list R540 dimension-decl is array-name ( array-spec ) or co-array-name [ ( array-spec ) ] lbracket co-array-spec rbracket R541 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name -list R542 optional-stmt is OPTIONAL [ :: ] dummy-arg-name -list R543 parameter-stmt is PARAMETER ( named-constant-def -list ) R544 named-constant-def is named-constant = initialization-expr 614 2006/07/11 WORKING DRAFT J3/06-007 R545 pointer-stmt is POINTER [ :: ] pointer-decl -list R546 pointer-decl is object-name [ ( deferred-shape-spec -list ) ] or proc-entity-name R547 protected-stmt is PROTECTED [ :: ] entity-name -list R548 save-stmt is SAVE [ [ :: ] saved-entity -list ] R549 saved-entity is object-name or proc-pointer-name or / common-block-name / R550 proc-pointer-name is name (R548) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no C574 other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. R551 target-stmt is TARGET [ :: ] target-decl -list R552 target-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] R553 value-stmt is VALUE [ :: ] dummy-arg-name -list R554 volatile-stmt is VOLATILE [ :: ] object-name -list R555 implicit-stmt is IMPLICIT implicit-spec -list or IMPLICIT NONE R556 implicit-spec is declaration-type-spec ( letter-spec -list ) R557 letter-spec is letter [ ­ letter ] C575 (R555) 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. C576 (R557) If the minus and second letter appear, the second letter shall follow the first letter alphabetically. R558 namelist-stmt is NAMELIST / namelist-group-name / namelist-group-object -list [ [ , ] / namelist-group-name / namelist-group-object -list ] . . . C577 (R558) The namelist-group-name shall not be a name accessed by use association. R559 namelist-group-object is variable-name C578 (R559) A namelist-group-object shall not be an assumed-size array. C579 (R558) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- name has the PUBLIC attribute. R560 equivalence-stmt is EQUIVALENCE equivalence-set -list R561 equivalence-set is ( equivalence-object , equivalence-object -list ) R562 equivalence-object is variable-name or array-element or substring C580 (R562) An equivalence-object shall not be a designator with a base ob ject that is a dummy argument, a pointer, an allocatable variable, a derived-type ob ject that has an allocatable ulti- mate component, an ob ject of a nonsequence derived type, an ob ject of a derived type that has a pointer at any level of component selection, an automatic ob ject, a function name, an entry name, a result name, a variable with the BIND attribute, a variable in a common block that 615 J3/06-007 WORKING DRAFT 2006/07/11 has the BIND attribute, or a named constant. (R562) An equivalence-object shall not be a designator that has more than one part-ref . C581 C582 (R562) An equivalence-object shall not be a co-array or a subob ject thereof. (R562) An equivalence-object shall not have the TARGET attribute. C583 C584 (R562) Each subscript or substring range expression in an equivalence-object shall be an integer initialization expression (7.1.7). C585 (R561) If an equivalence-object is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the ob jects in the equivalence set shall be of these types. (R561) If an equivalence-object is of type default character or character sequence type, all of the C586 ob jects in the equivalence set shall be of these types. C587 (R561) If an equivalence-object is of a sequence derived type that is not a numeric sequence or character sequence type, all of the ob jects in the equivalence set shall be of the same type with the same type parameter values. (R561) If an equivalence-object is of an intrinsic type other than default integer, default real, C588 double precision real, default complex, default logical, or default character, all of the ob jects in the equivalence set shall be of the same type with the same kind type parameter value. C589 (R562) If an equivalence-object has the PROTECTED attribute, all of the ob jects in the equiv- alence set shall have the PROTECTED attribute. C590 (R562) The name of an equivalence-object shall not be a name made accessible by use association. C591 (R562) A substring shall not have length zero. R563 common-stmt is COMMON [ / [ common-block-name ] / ] common-block-object -list [ [ , ] / [ common-block-name ] / common-block-object -list ] ... R564 common-block-object is variable-name [ ( array-spec ) ] or proc-pointer-name C592 (R564) An array-spec in a common-block-object shall be an explicit-shape-spec -list. C593 (R564) Only one appearance of a given variable-name or proc-pointer-name is permitted in all common-block-object -list s within a scoping unit. (R564) A common-block-object shall not be a dummy argument, an allocatable variable, a C594 derived-type ob ject with an ultimate component that is allocatable, an automatic ob ject, a function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. C595 (R564) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2) or a type with the BIND attribute and it shall have no default initialization. (R564) A variable-name or proc-pointer-name shall not be a name made accessible by use C596 association. Section 6: R601 variable is designator or expr C601 (R601) designator shall not be a constant or a subob ject of a constant. C602 (R601) The expr shall be a reference to a function that has a pointer result. R602 variable-name is name C603 (R602) A variable-name shall be the name of a variable. R603 designator is object-name or array-element or array-section or complex-part-designator 616 2006/07/11 WORKING DRAFT J3/06-007 or structure-component or substring R604 logical-variable is variable (R604) logical-variable shall be of type logical. C604 R605 default-logical-variable is variable (R605) default-logical-variable shall be of type default logical. C605 R606 char-variable is variable (R606) char-variable shall be of type character. C606 R607 default-char-variable is variable (R607) default-char-variable shall be of type default character. C607 R608 int-variable is variable (R608) int-variable shall be of type integer. C608 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 ] (R610) parent-string shall be of type character. C609 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 ob ject. (R613) If a section-subscript -list appears, the number of section-subscript s shall equal the rank C614 of part-name . C615 (R613) If image-selector appears and part-name is an array, section-subscript -list shall appear. (R613) A data-ref that is a co-indexed ob ject shall not be of a type that has a pointer ultimate C616 component. (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right C617 of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. R614 structure-component is data-ref (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form C618 part-name . R615 complex-part-designator is designator % RE or designator % IM C619 (R615) The designator shall be of complex type. R616 type-param-inquiry is designator % type-param-name (R616) The type-param-name shall be the name of a type parameter of the declared type of the C620 ob ject designated by the designator . R617 array-element is data-ref C621 (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 C622 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have a 617 J3/06-007 WORKING DRAFT 2006/07/11 section-subscript -list with nonzero rank, the array-section is a complex-part-designator that is an array, or another part-ref shall have nonzero rank. (R618) If a substring-range appears, the rightmost part-name shall be of type character. C623 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 C624 (R623) A vector-subscript shall be an integer array expression of rank one. (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension C625 of an assumed-size array. R624 image-selector is lbracket co-subscript -list rbracket R625 co-subscript is scalar-int-expr R626 al locate-stmt is ALLOCATE ( [ type-spec :: ] al location -list [, al loc-opt -list ] ) R627 al loc-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 al location is al locate-object [ ( al locate-shape-spec -list ) ] [ lbracket al locate-co-array-spec rbracket ] R632 al locate-object is variable-name or structure-component R633 al locate-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 al locate-co-array-spec is [ al locate-co-shape-spec -list , ] [ lower-bound-expr : ] * R637 al locate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr C626 (R632) Each al locate-object shall be a nonprocedure pointer or an allocatable variable. C627 (R626) If any al locate-object in the statement has a deferred type parameter, either type-spec or SOURCE= shall appear. (R626) If a type-spec appears, it shall specify a type with which each al locate-object is type C628 compatible. C629 (R626) If any al locate-object is unlimited polymorphic or is of abstract type, either type-spec or SOURCE= shall appear. (R626) A type-param-value in a type-spec shall be an asterisk if and only if each al locate-object C630 is a dummy argument for which the corresponding type parameter is assumed. C631 (R626) If a type-spec appears, the kind type parameter values of each al locate-object shall be the same as the corresponding type parameter values of the type-spec . C632 (R631) An al locate-shape-spec -list shall appear if and only if the al locate-object is an array. An al locate-co-array-spec shall appear if and only if the al locate-object is a co-array. (R631) The number of al locate-shape-spec s in an al locate-shape-spec -list shall be the same as the C633 rank of the al locate-object . The number of al locate-co-shape-spec s in an al locate-co-array-spec 618 2006/07/11 WORKING DRAFT J3/06-007 shall be one less than the co-rank of the al locate-object . (R627) No al loc-opt shall appear more than once in a given al loc-opt -list. C634 C635 (R626) At most one of SOURCE=, MOLD=, and type-spec shall appear. (R626) Each al locate-object shall be type compatible (4.3.1.3) with source-expr . If SOURCE= C636 appears, source-expr shall be a scalar or have the same rank as each al locate-object . C637 (R626) Corresponding kind type parameters of al locate-object and source-expr shall have the same values. C638 (R632) An al locate-object shall not be a co-indexed ob ject. R638 nul lify-stmt is NULLIFY ( pointer-object -list ) R639 pointer-object is variable-name or structure-component or proc-pointer-name (R639) Each pointer-object shall have the POINTER attribute. C639 R640 deal locate-stmt is DEALLOCATE ( al locate-object -list [ , deal loc-opt -list ] ) (R640) Each al locate-object shall be a nonprocedure pointer or an allocatable variable. C640 R641 deal loc-opt is STAT = stat-variable or ERRMSG = errmsg-variable C641 (R641) No deal loc-opt shall appear more than once in a given deal loc-opt -list. Section 7: R701 primary is constant or designator or array-constructor or structure-constructor 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. (R701) The designator shall not be a whole assumed-size array. C702 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. 619 J3/06-007 WORKING DRAFT 2006/07/11 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 . 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 for 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 (R732) int-initialization-expr shall be an initialization expression. C714 R733 logical-initialization-expr is logical-expr C715 (R733) logical-initialization-expr shall be an initialization expression. 620 2006/07/11 WORKING DRAFT J3/06-007 R734 assignment-stmt is variable = expr (R734) The variable shall not be a whole assumed-size array. C716 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, either data-pointer-object shall be type compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal, or data-target and data-pointer-object shall be bits compatible. (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- C718 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-spec s shall equal the rank of data- pointer-object . (R735) If bounds-remapping -list is specified, the number of bounds-remapping s shall equal the C720 rank of data-pointer-object . (R735) If bounds-remapping -list is not specified, the ranks of data-pointer-object and data-target C721 shall be the same. C722 (R736) A variable-name shall have the POINTER attribute. C723 (R736) A scalar-variable shall be a data-ref . (R736) A data-pointer-component-name shall be the name of a component of scalar-variable C724 that is a data pointer. C725 (R736) A data-pointer-object shall not be a co-indexed ob ject. R737 bounds-spec is lower-bound-expr : R738 bounds-remapping is lower-bound-expr : upper-bound-expr R739 data-target is variable or expr (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an C726 array section with a vector subscript. C727 (R739) A data-target shall not be a co-indexed ob ject. 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 . (R741) The procedure-component-name shall be the name of a procedure pointer component of C730 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 ] ... 621 J3/06-007 WORKING DRAFT 2006/07/11 [ 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 foral l-construct is foral l-construct-stmt [foral l-body-construct ] ... end-foral l-stmt R753 foral l-construct-stmt is [foral l-construct-name :] FORALL foral l-header R754 foral l-header is (foral l-triplet-spec -list [, scalar-mask-expr ] ) R755 foral l-triplet-spec is index-name = subscript : subscript [ : stride ] R756 foral l-body-construct is foral l-assignment-stmt or where-stmt or where-construct or foral l-construct or foral l-stmt R757 foral l-assignment-stmt is assignment-stmt or pointer-assignment-stmt R758 end-foral l-stmt is END FORALL [foral l-construct-name ] C737 (R758) If the foral l-construct-stmt has a foral l-construct-name , the end-foral l-stmt shall have the same foral l-construct-name . If the end-foral l-stmt has a foral l-construct-name , the foral l- construct-stmt shall have the same foral l-construct-name . C738 (R754) The scalar-mask-expr shall be scalar and of type logical. C739 (R754) Any procedure referenced in the scalar-mask-expr , including one referenced by a defined operation, shall be a pure procedure (12.7). C740 (R755) The index-name shall be a named scalar variable of type integer. C741 (R755) A subscript or stride in a foral l-triplet-spec shall not contain a reference to any index- name in the foral l-triplet-spec -list in which it appears. C742 (R756) A statement in a foral l-body-construct shall not define an index-name of the foral l- construct . C743 (R756) Any procedure referenced in a foral l-body-construct , including one referenced by a defined 622 2006/07/11 WORKING DRAFT J3/06-007 operation, assignment, or finalization, shall be a pure procedure. (R756) A foral l-body-construct shall not be a branch target. C744 C745 (R757) The variable in an assignment-stmt that is a foral l-assignment-stmt shall be a designator . R759 foral l-stmt is FORALL foral l-header foral l-assignment-stmt Section 8: R801 block is [ execution-part-construct ] ... R802 if-construct is if-then-stmt block [ else-if-stmt block ] ... [ else-stmt block ] end-if-stmt R803 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN R804 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] R805 else-stmt is ELSE [ if-construct-name ] R806 end-if-stmt is END IF [ if-construct-name ] C801 (R802) 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 . R807 if-stmt is IF ( scalar-logical-expr ) action-stmt C802 (R807) The action-stmt in the if-stmt shall not be an if-stmt , end-program-stmt , end-function- stmt , or end-subroutine-stmt . R808 case-construct is select-case-stmt [ case-stmt block ] ... end-select-stmt R809 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) R810 case-stmt is CASE case-selector [case-construct-name ] R811 end-select-stmt is END SELECT [ case-construct-name ] C803 (R808) 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 . R812 case-expr is scalar-int-expr or scalar-char-expr or scalar-logical-expr R813 case-selector is ( case-value-range -list ) or DEFAULT (R808) No more than one of the selectors of one of the CASE statements shall be DEFAULT. C804 R814 case-value-range is case-value or case-value : or : case-value or case-value : case-value 623 J3/06-007 WORKING DRAFT 2006/07/11 R815 case-value is scalar-int-initialization-expr or scalar-char-initialization-expr or scalar-logical-initialization-expr (R808) For a given case-construct , each case-value shall be of the same type as case-expr . For C805 character type, the kind type parameters shall be the same; character length differences are allowed. C806 (R808) A case-value-range using a colon shall not be used if case-expr is of type logical. (R808) For a given case-construct , the case-value-range s shall not overlap; that is, there shall C807 be no possible value of the case-expr that matches more than one case-value-range . R816 associate-construct is associate-stmt block end-associate-stmt R817 associate-stmt is [ associate-construct-name : ] ASSOCIATE (association -list ) R818 association is associate-name => selector R819 selector is expr or variable C808 (R818) 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). C809 (R818) An associate-name shall not be the same as another associate-name in the same associate- stmt . R820 end-associate-stmt is END ASSOCIATE [ associate-construct-name ] (R820) If the associate-stmt of an associate-construct specifies an associate-construct-name , C810 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 . R821 select-type-construct is select-type-stmt [ type-guard-stmt block ] ... end-select-type-stmt R822 select-type-stmt is [ select-construct-name : ] SELECT TYPE ( [ associate-name => ] selector ) C811 (R822) If selector is not a named variable , associate-name => shall appear. C812 (R822) 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). C813 (R822) The selector in a select-type-stmt shall be polymorphic. R823 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 ] (R823) The type-spec or derived-type-spec shall specify that each length type parameter is as- C814 sumed. C815 (R823) The type-spec or derived-type-spec shall not specify a sequence derived type or a type with the BIND attribute. C816 (R823) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify an extension of the declared type of selector . (R823) For a given select-type-construct , the same type and kind type parameter values shall C817 not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more 624 2006/07/11 WORKING DRAFT J3/06-007 than one CLASS IS type-guard-stmt . (R823) For a given select-type-construct , there shall be at most one CLASS DEFAULT type- C818 guard-stmt . R824 end-select-type-stmt is END SELECT [ select-construct-name ] C819 (R821) 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 . R825 do-construct is block-do-construct or nonblock-do-construct R826 block-do-construct is do-stmt do-block end-do R827 do-stmt is label-do-stmt or nonlabel-do-stmt R828 label-do-stmt is [ do-construct-name : ] DO label [ loop-control ] R829 nonlabel-do-stmt is [ do-construct-name : ] DO [ loop-control ] R830 loop-control is [ , ] do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] or [ , ] WHILE ( scalar-logical-expr ) or [ , ] CONCURRENT foral l-header R831 do-variable is scalar-int-variable-name (R831) The do-variable shall be a variable of type integer. C820 R832 do-block is block R833 end-do is end-do-stmt or continue-stmt R834 end-do-stmt is END DO [ do-construct-name ] C821 (R826) 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 . C822 (R826) If the do-stmt is a nonlabel-do-stmt , the corresponding end-do shall be an end-do-stmt . C823 (R826) If the do-stmt is a label-do-stmt , the corresponding end-do shall be identified with the same label . R835 nonblock-do-construct is action-term-do-construct or outer-shared-do-construct R836 action-term-do-construct is label-do-stmt do-body do-term-action-stmt R837 do-body is [ execution-part-construct ] ... R838 do-term-action-stmt is action-stmt C824 (R838) A do-term-action-stmt shall not be a continue-stmt , a goto-stmt , a return-stmt , a stop- stmt , an exit-stmt , a cycle-stmt , an end-function-stmt , an end-subroutine-stmt , an end-program- stmt , or an arithmetic-if-stmt . C825 (R835) The do-term-action-stmt shall be identified with a label and the corresponding label-do- stmt shall refer to the same label. 625 J3/06-007 WORKING DRAFT 2006/07/11 R839 outer-shared-do-construct is label-do-stmt do-body shared-term-do-construct R840 shared-term-do-construct is outer-shared-do-construct or inner-shared-do-construct R841 inner-shared-do-construct is label-do-stmt do-body do-term-shared-stmt R842 do-term-shared-stmt is action-stmt (R842) A do-term-shared-stmt shall not be a goto-stmt , a return-stmt , a stop-stmt , an exit- C826 stmt , a cycle-stmt , an end-function-stmt , an end-subroutine-stmt , an end-program-stmt , or an arithmetic-if-stmt . C827 (R840) The do-term-shared-stmt shall be identified with a label and all of the label-do-stmt s of the inner-shared-do-construct and outer-shared-do-construct shall refer to the same label. R843 cycle-stmt is CYCLE [ do-construct-name ] (R843) If a cycle-stmt refers to a do-construct-name , it shall be within the range of that do- C828 construct ; otherwise, it shall be within the range of at least one do-construct . C829 (R843) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it belongs to an outer construct. R844 exit-stmt is EXIT [ construct-name ] C830 If an exit-stmt refers to a construct-name , it shall be within that construct; otherwise, it shall be within the range of at least one do-construct . C831 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. R845 block-construct is block-stmt [ specification-part ] block end-block-stmt R846 block-stmt is [ block-construct-name : ] BLOCK R847 end-block-stmt is END BLOCK [ block-construct-name ] C832 (R845) 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 . R848 critical-construct is critical-stmt block end-critical-stmt R849 critical-stmt is [ critical-construct-name : ] CRITICAL R850 end-critical-stmt is END CRITICAL [ critical-construct-name ] C833 (R848) 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 . C834 (R848) The block of a critical-construct shall not contain an image control statement. R851 goto-stmt is GO TO label C835 (R851) The label shall be the statement label of a branch target statement that appears in the same scoping unit as the goto-stmt . 626 2006/07/11 WORKING DRAFT J3/06-007 R852 computed-goto-stmt is GO TO ( label -list ) [ , ] scalar-int-expr (R852 Each label in label -list shall be the statement label of a branch target statement that C836 appears in the same scoping unit as the computed-goto-stmt . R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label C837 (R853) Each label shall be the label of a branch target statement that appears in the same scoping unit as the arithmetic-if-stmt . C838 (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 (R856) The scalar-char-initialization-expr shall be of default kind. C839 C840 (R856) The scalar-int-initialization-expr shall be of default kind. R857 sync-al l-stmt is SYNC ALL [ ( [ sync-stat -list ] ) ] R858 sync-stat is STAT = stat-variable or ERRMSG = errmsg-variable C841 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 C842 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 * C843 An image-set that is an int-expr shall be scalar or of rank one and shall not be a co-indexed ob ject. 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 C844 (R864) No specifier shall appear more than once in a given query-spec -list. R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat -list ] ) ] Section 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 627 J3/06-007 WORKING DRAFT 2006/07/11 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 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. (R904) The label used in the ERR= specifier shall be the statement label of a branch target C905 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 (R909) No specifier shall appear more than once in a given close-spec -list. C907 C908 (R909) 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 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 628 2006/07/11 WORKING DRAFT J3/06-007 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 or SIZE = scalar-int-variable (R913) No specifier shall appear more than once in a given io-control-spec -list. C910 C911 (R913) An io-unit shall be specified; 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 . (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt . C913 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. (R913) A namelist-group-name shall not appear if an input-item -list or an output-item -list C916 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 . (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item C919 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. (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- C922 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. (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type C925 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. (R913) If a POS= specifier appears, the io-control-spec -list shall not contain a REC= specifier. C928 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. 629 J3/06-007 WORKING DRAFT 2006/07/11 R914 format is default-char-expr or label or * (R914) The label shall be the label of a FORMAT statement that appears in the same scoping C931 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 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. (R915) A variable that is an input-item shall not be a procedure pointer. C933 C934 (R919) The do-variable shall be a named scalar variable of type integer. (R918) In an input-item -list, an io-implied-do-object shall be an input-item . In an output-item - C935 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 (R922) No specifier shall appear more than once in a given wait-spec -list. C939 C940 (R922) 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 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 630 2006/07/11 WORKING DRAFT J3/06-007 or ERR = label (R926) No specifier shall appear more than once in a given position-spec -list. C942 C943 (R926) 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 position-spec -list. (R926) The label in the ERR= specifier shall be the statement label of a branch target statement C944 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 or ERR = label (R928) No specifier shall appear more than once in a given flush-spec -list. C945 (R928) A file-unit-number shall be specified; if the optional characters UNIT= are omitted from C946 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 631 J3/06-007 WORKING DRAFT 2006/07/11 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 UNFORMATTED = scalar-default-char-variable or WRITE = scalar-default-char-variable (R930) No specifier shall appear more than once in a given inquire-spec -list. C948 C949 (R930) An inquire-spec -list shall contain one FILE= specifier or one UNIT= specifier, but not both. C950 (R930) 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. (R930) If an ID= specifier appears, a PENDING= specifier shall also appear. C951 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. Section 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-item s 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 (R1005) r shall be positive. C1003 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 632 2006/07/11 WORKING DRAFT J3/06-007 R1009 d is int-literal-constant R1010 e is int-literal-constant R1011 v is signed-int-literal-constant (R1010) e shall be positive. C1005 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. (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. C1007 C1008 (R1006) w , m , d , e , and v shall not have kind parameters specified for them. (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter C1009 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 ] ... Section 11: R1101 main-program is [ program-stmt ] [ specification-part ] 633 J3/06-007 WORKING DRAFT 2006/07/11 [ execution-part ] [ internal-subprogram-part ] end-program-stmt R1102 program-stmt is PROGRAM program-name R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] (R1101) In a main-program , the execution-part shall not contain a RETURN statement or an C1101 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 program-stmt . (R1101) An automatic ob ject shall not appear in the specification-part (R204) of a main program. C1103 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 (R1104) If the module-name is specified in the end-module-stmt , it shall be identical to the C1104 module-name specified in the module-stmt . (R1104) A module specification-part shall not contain a stmt-function-stmt , an entry-stmt , or a C1105 format-stmt . C1106 (R1104) An automatic ob ject shall not appear in the specification-part of a module. C1107 (R1104) If an ob ject of a type for which component-initialization is specified (R448) appears in the specification-part of a module and does not have the ALLOCATABLE or POINTER attribute, the ob ject 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 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. C1108 C1109 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic module. (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the C1110 634 2006/07/11 WORKING DRAFT J3/06-007 same name. (R1111) OPERATOR(use-defined-operator ) shall not identify a generic-binding . C1111 C1112 (R1112) The generic-spec shall not identify a generic-binding . (R1112) Each generic-spec shall be a public entity in the module. C1113 C1114 (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 (R1115) Each use-defined-operator shall be a public entity in the module. C1115 R1116 submodule is submodule-stmt [ 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 ] ] C1116 (R1116) An automatic ob ject shall not appear in the specification-part of a submodule. (R1116) A submodule specification-part shall not contain a format-stmt or a stmt-function-stmt . C1117 C1118 (R1116) An ob ject with default initialization that is declared in the specification-part of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- C1119 submodule-name shall be the name of a descendant of that module. C1120 (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 ] ] C1121 (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 . C1122 (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. (R1120) A type declaration statement in a block-data specification-part shall not contain AL- C1123 LOCATABLE, EXTERNAL, or BIND attribute specifiers. Section 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 635 J3/06-007 WORKING DRAFT 2006/07/11 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 ( = ) or dtio-generic-spec R1208 dtio-generic-spec is READ (FORMATTED) or READ (UNFORMATTED) or WRITE (FORMATTED) or WRITE (UNFORMATTED) R1209 import-stmt is IMPORT [[ :: ] import-name -list C1201 (R1201) An interface-block in a subprogram shall not contain an interface-body for a procedure defined by that subprogram. (R1201) The generic-spec shall be included in the end-interface-stmt only if it is provided in the C1202 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 OPERATOR(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 corresponding operator <, <=, >, >=, ==, or /=. (R1203) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the C1203 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. (R1206) If MODULE appears in a procedure-stmt , each procedure-name in that statement shall C1208 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 (R1209) The IMPORT statement is allowed only in an interface-body that is not a module procedure interface body. C1211 (R1209) Each import-name shall be the name of an entity in the host scoping unit. C1212 (R1205) A module procedure interface body shall not appear in an abstract interface block. 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 636 2006/07/11 WORKING DRAFT J3/06-007 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 nul l-init or initial-proc-target 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. (R1217) The procedure-name shall be the name of an initialization target. C1218 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. (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an C1220 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 cal l-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 637 J3/06-007 WORKING DRAFT 2006/07/11 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 pointer. C1233 (R1223) In a reference to a pure procedure, a procedure-name actual-arg shall be the name of a pure procedure (12.7). C1234 (R1224) The label shall be the statement label of a branch target statement that appears in the same scoping unit as the cal l-stmt . C1235 An actual argument that is a co-indexed ob ject shall not be associated with a dummy argument that has the ASYNCHRONOUS attribute. C1236 (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. C1237 (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 function-subprogram is function-stmt [ specification-part ] [ execution-part ] [ internal-subprogram-part ] end-function-stmt R1226 function-stmt is [ prefix ] FUNCTION function-name ( [ dummy-arg-name -list ] ) [ suffix ] C1238 (R1226) 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. C1239 (R1226) If RESULT appears, the function-name shall not appear in any specification statement in the scoping unit of the function subprogram. R1227 proc-language-binding-spec is language-binding-spec C1240 (R1227) A proc-language-binding-spec with a NAME= specifier shall not be specified in the function-stmt or subroutine-stmt of an interface body for an abstract interface or a dummy procedure. C1241 (R1227) A proc-language-binding-spec shall not be specified for an internal procedure. C1242 (R1227) 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. R1228 dummy-arg-name is name C1243 (R1228) A dummy-arg-name shall be the name of a dummy argument. R1229 prefix is prefix-spec [ prefix-spec ] ... R1230 prefix-spec is declaration-type-spec or ELEMENTAL or IMPURE 638 2006/07/11 WORKING DRAFT J3/06-007 or MODULE or PURE or RECURSIVE (R1229) A prefix shall contain at most one of each prefix-spec . C1244 C1245 (R1229) A prefix shall not specify both PURE and IMPURE. (R1229) A prefix shall not specify both ELEMENTAL and RECURSIVE. C1246 C1247 (R1229) A prefix shall not specify ELEMENTAL if proc-language-binding-spec appears in the function-stmt or subroutine-stmt . (R1229) MODULE shall appear only within the function-stmt or subroutine-stmt of a module C1248 subprogram or of an interface body that is declared in the scoping unit of a module or submodule. (R1229) If MODULE appears within the prefix in a module subprogram, an accessible module C1249 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. (R1229) If MODULE appears within the prefix in a module subprogram, the subprogram shall C1250 specify the same characteristics and dummy argument names as its corresponding (12.6.2.4) module procedure interface body. C1251 (R1229) 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. C1252 (R1229) 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. 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 ] ] C1253 (R1225) An internal function subprogram shall not contain an ENTRY statement. (R1225) An internal function subprogram shall not contain an internal-subprogram-part . C1254 C1255 (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 ] ] (R1234) The prefix of a subroutine-stmt shall not contain a declaration-type-spec . C1256 R1235 dummy-arg is dummy-arg-name or * R1236 end-subroutine-stmt is END [ SUBROUTINE [ subroutine-name ] ] C1257 (R1233) An internal subroutine subprogram shall not contain an ENTRY statement. C1258 (R1233) An internal subroutine subprogram shall not contain an internal-subprogram-part . C1259 (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 MODULE PROCEDURE procedure-name [ specification-part ] [ execution-part ] 639 J3/06-007 WORKING DRAFT 2006/07/11 [ internal-subprogram-part ] end-sep-subprogram-stmt R1238 end-sep-subprogram-stmt is END [PROCEDURE [procedure-name ]] (R1237) The procedure-name shall be the same as the name of an accessible module procedure C1260 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. C1261 (R1238) If a procedure-name appears in the end-sep-subprogram-stmt , it shall be identical to the procedure-name in the MODULE PROCEDURE statement. R1239 entry-stmt is ENTRY entry-name [ ( [ dummy-arg -list ] ) [ suffix ] ] (R1239) If RESULT appears, the entry-name shall not appear in any specification or type- C1262 declaration statement in the scoping unit of the function program. C1263 (R1239) 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 . (R1239) RESULT shall appear only if the entry-stmt is in a function subprogram. C1264 C1265 (R1239) Within the subprogram containing the entry-stmt , the entry-name shall not appear as a dummy argument in the FUNCTION or SUBROUTINE statement or in another ENTRY statement nor shall it appear in an EXTERNAL, INTRINSIC, or PROCEDURE statement. C1266 (R1239) A dummy-arg shall not be an alternate return indicator if the ENTRY statement is in a function subprogram. C1267 (R1239) 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. R1240 return-stmt is RETURN [ scalar-int-expr ] C1268 (R1240) The return-stmt shall be in the scoping unit of a function or subroutine subprogram. C1269 (R1240) The scalar-int-expr is allowed only in the scoping unit of a subroutine subprogram. R1241 contains-stmt is CONTAINS R1242 stmt-function-stmt is function-name ( [ dummy-arg-name -list ] ) = scalar-expr C1270 (R1242) The primaries of the scalar-expr shall be constants (literal and named), references to variables, references to functions and function dummy pro cedures, and intrinsic op erations. If scalar-expr contains a reference to a function or a function dummy pro cedure, the reference shall not require an explicit interface, the function shall not require an explicit interface unless it is an intrinsic, the function shall not b e a transformational intrinsic, and the result shall be scalar. If an argument to a function or a function dummy pro cedure is an array, it shall b e an array name. If a reference to a statement function app ears in scalar-expr , its definition shall have b een provided earlier in the scoping unit and shall not be the name of the statement function b eing defined. C1271 (R1242) Named constants in scalar-expr shall have been declared earlier in the scoping unit or made accessible by use or host asso ciation. If array elements app ear in scalar-expr , the array shall have b een declared as an array earlier in the scoping unit or made accessible by use or host asso ciation. C1272 (R1242) If a dummy-arg-name , variable, function reference, or dummy function reference is typed by the implicit typing rules, its app earance in any subsequent typ e declaration statement shall confirm this implied typ e and the values of any implied typ e parameters. C1273 (R1242) The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar. C1274 (R1242) A given dummy-arg-name shall not appear more than once in any dummy-arg-name -list. C1275 (R1242) 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. C1276 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data ob jects have INTENT(IN). C1277 The specification-part of a pure subroutine subprogram shall specify the intents of all its non- pointer dummy data ob jects. C1278 A local variable declared in the specification-part or internal-subprogram-part of a pure subpro- 640 2006/07/11 WORKING DRAFT J3/06-007 gram shall not have the SAVE attribute. C1279 The specification-part of a pure subprogram shall specify that all its dummy procedures are pure. C1280 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. C1281 All internal subprograms in a pure subprogram shall be pure. C1282 In a pure subprogram any designator with a base ob ject 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 ob ject that is storage associated with any such variable, shall not be used C1283 Any procedure referenced in a pure subprogram, including one referenced via a defined operation, assignment, or finalization, shall be pure. C1284 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 . C1285 A pure subprogram shall not contain a read-stmt or write-stmt whose io-unit is a file-unit-number or *. C1286 A pure subprogram shall not contain a stop-stmt . C1287 A co-indexed ob ject shall not appear in a variable definition context in a pure subprogram. C1288 A pure subprogram shall not contain an image control statement (8.5.1). C1289 All dummy arguments of an elemental procedure shall be scalar dummy data ob jects and shall not have the POINTER or ALLOCATABLE attribute. C1290 The result variable of an elemental function shall be scalar and shall not have the POINTER or ALLOCATABLE attribute. C1291 In the scoping unit of an elemental subprogram, an ob ject designator with a dummy argument as the base ob ject shall not appear in a specification-expr except as the argument to one of the intrinsic functions BIT SIZE, KIND, LEN, or the numeric inquiry functions (13.5.6). Section 13: Section 14: Section 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. Section 16: D.2 Syntax rule cross-reference R475 ac-do-variable R474, C508, R474, C508 R473 ac-implied-do R472, C508, R472, C508 R474 ac-implied-do-control R473 R469 ac-spec R468 R472 ac-value R469, R473, C505, C506, C507, R469, R473, C505, C506, C507 641 J3/06-007 WORKING DRAFT 2006/07/11 R521 access-id R520, C558, R520, C558 R507 access-spec R316, R432, R442, R447, R455, R456, R432, R442, R447, R455, R456, R502, C516, R520, R502, C516, R520, R1213 R520 access-stmt R212, C558 R214 action-stmt R213, C324, C325, C324, C325, R807, C802, R807, C802 R836 action-term-do-construct R835 R1223 actual-arg R1222, C1233, R1222, C1233 R1222 actual-arg-spec C501, R1219, C1223, R1220, C1229, R1219, C1223, R1220, C1229 R709 add-op R310, R706 R705 add-operand R705, R706, R705, R706 R627 al loc-opt R626, C634, R626, C634 R523 al locatable-decl R522 R522 al locatable-stmt R212 R636 al locate-co-array-spec R631, C632, C633, R631, C632, C633 R637 al locate-co-shape-spec R636, C633, R636, C633 R632 al locate-object R631, C626, C627, C628, C629, C630, C631, C632, C633, C636, C637, C638, R640, C640, R631, C626, C627, C628, C629, C630, C631, C632, C633, C636, C637, C638, R640, C640 R633 al locate-shape-spec R631, C632, C633, R631, C632, C633 R626 al locate-stmt R214 R631 al location R626 R302 alphanumeric-character R301, R304, R301, R304 R1224 alt-return-spec C1223, R1223, C1223, R1223 ancestor-module-name R1118, C1119, R1118, C1120 R719 and-op R310, R715 R714 and-operand R715 arg-name R447, C458, R456, C479, R447, C458, R456, C479 R344 arg-token R343 R853 arithmetic-if-stmt R214, C325, C824, C826, C837, C824, C826, C837 R468 array-constructor C505, C506, C507, C505, C506, C507, R701 R617 array-element R532, C565, C568, R562, R532, C565, C568, R562, R603, R610, R603, R610 array-name R539, R540, R539, R540 R618 array-section R603, C622, R603, C622 R510 array-spec R502, R503, C514, R509, C529, R522, R523, R539, R540, R551, R552, R564, C593, R502, R503, C514, R509, C529, R522, R523, R539, R540, R551, R552, R564, C593 R734 assignment-stmt R214, R747, R757, C745, R747, R757, C744 R816 associate-construct R213, C810 associate-construct-name R817, R820, C810, R817, R820, C810 associate-name R818, C808, C809, R822, C811, C812, R818, C808, C809, R822, C811, C812 R817 associate-stmt R816, C809, C810, R816, C809, C810 R818 association R817 R515 assumed-shape-spec R510 R517 assumed-size-spec R510, R511, R510, R511 R524 asynchronous-stmt R212 642 2006/07/11 WORKING DRAFT J3/06-007 R502 attr-spec R501, C501, C575, R501, C501, C575 R923 backspace-stmt R214, C1284 R342 basic-token R341, R344, R341, R344 R341 basic-token-sequence R337, R341, R337, R341 R426 binary-constant R425 R526 bind-entity R525, C560, R525, C560 R525 bind-stmt R212 R456 binding-attr R454, C477, C480, C481, R454, C477, C480, C481 binding-name R454, R455, C472, R454, R455, C472, R1221, C1226, R1221, C1226 R452 binding-private-stmt R451, C467, R451, C467 R1017 blank-interp-edit-desc R1012 R801 block R802, R808, R816, R821, R832, R845, R848, C834, R802, R808, R816, R821, R832, R845, R848, C834 R845 block-construct R213, C832 block-construct-name R846, R847, C832, R846, R847, C832 R1120 block-data R202, C1122, C1123, C1124 block-data-name R1121, R1122, C1121, R1121, R1122, C1122 R1121 block-data-stmt R1120, C1121, R1120, C1122 R826 block-do-construct R825, C821, R825, C821 R846 block-stmt R845, C832, R845, C832 R738 bounds-remapping R735, C720, C721, R735, C720, C721 R737 bounds-spec R735, C719, R735, C719 R425 boz-literal-constant R306, C414 R1220 cal l-stmt R214, C1234 R808 case-construct R213, C803, C805, C807, C803, C805, C807 case-construct-name R809, R810, R811, C803, R809, R810, R811, C803 R812 case-expr R809, C805, C806, C807, R809, C805, C806, C807 R813 case-selector R810 R810 case-stmt R808, C803, R808, C803 R815 case-value R814, C805, R814, C805 R814 case-value-range R813, C806, C807, R813, C806, C807 R309 char-constant C303 R725 char-expr C706, R731, C706, R731, R812 R731 char-initialization-expr R508, C521, R508, C521, C713, R815, R856, C839, R815, R856, C839, R913, C925, R913, C925 R422 char-length R421, C420, C453, R421, C420, C453, R503, C504, R503, C504 R423 char-literal-constant R306, R1006, C1009, R1020, C1013, R1006, C1009, R1020, C1013 R420 char-selector R404 R1020 char-string-edit-desc R1003 R606 char-variable C606, R903, C901, C902, R903, C901, C902 R909 close-spec R908, C907, C908, R908, C907, C908 R908 close-stmt R214, C1284 co-array-name R540 R511 co-array-spec R444, C447, R444, C447, R503, R509, C523, R523, R540, R552, R503, R509, C523, R523, R540, R552 643 J3/06-007 WORKING DRAFT 2006/07/11 R625 co-subscript R624 co-subscript-list R624 common-block-name R526, R549, R563, R526, R549, R563 R564 common-block-object R563, C593, C594, C595, C596, R563, C593, C594, C595, C596 R563 common-stmt R212 R417 complex-literal-constant R306 R615 complex-part-designator R603, R618, C622, R603, R618, C622 R445 component-array-spec R442, R444, C446, C449, R442, R444, C446, C449 R442 component-attr-spec R441, C443, C463, R441, C443, C463 R462 component-data-source R461 R443 component-decl R441, C461, R441, C461 R440 component-def-stmt R439, C443, C444, C445, C454, R439, C443, C444, C445, C454 R444 component-dim-spec R442 R448 component-initialization C461, C462, C463, C461, C462, C463, C1107 component-name C464 R439 component-part R430 R461 component-spec R460, C495, C496, C497, C498, C500, C501, R460, C495, C496, C497, C498, C500, C501 R852 computed-goto-stmt R214, C836 R711 concat-op R310, R710 R905 connect-spec R904, C903, C904, R904, C903, C904 R305 constant R308, R309, R308, R309, R536, R610, R701 R538 constant-subobject R536, R537, C573, R536, R537, C573 construct-name R844, C830, R844, C830 R1241 contains-stmt R210, R451, R1107 R854 continue-stmt R214, C325, R833, C824, R833, C824 R1012 control-edit-desc R1003 R848 critical-construct R213, C833, C834, C833, C834 critical-construct-name R849, R850, C833, R849, R850, C833 R849 critical-stmt R848, C833, R848, C833 R843 cycle-stmt R214, C325, C824, C826, C828, C829, C824, C826, C828, C829 R1009 d R1006, C1007, C1008, R1006, C1007, C1008 R441 data-component-def-stmt R440 R1006 data-edit-desc R1003 R532 data-i-do-object R531, C561, C563, C564, C568, R531, C561, C563, C564, C568 R533 data-i-do-variable R531, C568, R531, C568 R531 data-implied-do R530, R532, C568, R530, R532, C568 data-pointer-component-name R736, C724, R736, C724 R736 data-pointer-object R735, C717, C718, C719, C720, C721, C725, R735, C717, C718, C719, C720, C721, C725 R612 data-ref C612, C616, R614, R617, R618, C612, C616, R614, R617, R618, C723, C729, C723, R1221, C1226, C1227, R1221, C1226, C1227 R528 data-stmt R209, R212, R209, R212, C1206 R536 data-stmt-constant C414, R534, C571, R534, C571 644 2006/07/11 WORKING DRAFT J3/06-007 R530 data-stmt-object R529, C561, C562, C563, C564, R529, C561, C562, C563, C564 R535 data-stmt-repeat R534, C569, R534, C569 R529 data-stmt-set R528 R534 data-stmt-value R529 R739 data-target R462, C502, C503, R462, C502, C503, C546, R735, C717, C718, C721, C727, R735, C717, C718, C721, C727 R641 deal loc-opt R640, C641, R640, C641 R640 deal locate-stmt R214 R1019 decimal-edit-desc R1012 R207 declaration-construct R204 R403 declaration-type-spec C404, C405, C424, R441, C444, C445, C404, C405, C424, R441, C444, C445, R501, R556, R501, R556, R1212, R1230, C1256, R1212, R1230, C1256 R726 default-char-expr C707, R905, R906, R909, R913, R914, R905, R906, R909, R913, R914 R607 default-char-variable C607, R629, C607, R629, R907, R930, R907, R930 R605 default-logical-variable C605, R930 R516 deferred-shape-spec R444, R445, C446, C447, R444, R445, C446, C447, C523, R510, R511, C529, R546, R510, R511, C529, R546 deferred-shape-spec-list C523 R315 define-macro-stmt R314 R723 defined-binary-op R311, R722, C704, R722, C704, R1114, R1115, R1114, R1115 R311 defined-operator C474, R1207, C1202, R1207, C1202 R703 defined-unary-op R311, R702, C703, R702, C703, R1114, R1115, R1114, R1115 R430 derived-type-def R207, C437, C441, C442, C437, C441, C442 R458 derived-type-spec R402, C403, R403, C405, C406, R460, C494, C501, R402, C403, R403, C405, C406, R460, C494, C501, R823, C814, C815, C816, R823, C814, C815, C816, R920, C937, C938, R920, C937, C938 R431 derived-type-stmt R430, C432, C438, C441, C442, R430, C432, C438, C441, C442 R603 designator R449, C465, R449, C465, R538, R601, C601, R615, C619, R616, C620, R601, C601, R615, C619, R616, C620, R701, C702, C745, R701, C702, C744 digit R302, R313, R302, R313, R410, R426, C412, R427, C413, R429, R426, C429, R427, C430, R429, R410, R426, C412, R427, C413, R429, R426, C429, R427, C430, R429 R410 digit-string R407, R408, R409, R413, R414, R407, R408, R409, R413, R414 R540 dimension-decl R539 R539 dimension-stmt R212 R832 do-block R826 R837 do-body R836, R839, R841, R836, R839, R841 R825 do-construct R213, C828, C830, C828, C830 do-construct-name R828, R829, R834, C821, R843, C828, R828, R829, R834, C821, R843, C828 R827 do-stmt R826, C821, C822, C823, R826, C821, C822, C823 R838 do-term-action-stmt C325, R836, C824, C825, R836, C824, C825 645 J3/06-007 WORKING DRAFT 2006/07/11 R842 do-term-shared-stmt R841, C826, C827, R841, C826, C827 R831 do-variable R475, R533, R830, C820, R830, C820, R919, C934, R919, C934 R1208 dtio-generic-spec C476, R1207, C1202, R1207, C1202 R1235 dummy-arg R1234, R1239, C1266, R1234, R1239, C1266 R1228 dummy-arg-name R541, R542, R553, R541, R542, R553, R1226, C1243, R1235, R1242, C1272, C1273, C1274, R1226, C1243, R1235, R1242, C1272, C1273, C1274 R1010 e R1006, C1005, C1008, R1006, C1005, C1008 R804 else-if-stmt R802, C801, R802, C801 R805 else-stmt R802, C801, R802, C801 R750 elsewhere-stmt R744, C735, R744, C734 R820 end-associate-stmt R816, C810, R816, C810 R1122 end-block-data-stmt R1120, C1121, R1120, C1122 R847 end-block-stmt R845, C832, R845, C832 R850 end-critical-stmt R848, C833, R848, C833 R833 end-do R826, C821, C822, C823, R826, C821, C822, C823 R834 end-do-stmt R833, C821, C822, R833, C821, C822 R467 end-enum-stmt R463 R758 end-foral l-stmt R752, C737, R752, C736 R1232 end-function-stmt R214, C201, R214, C201, C324, C325, C324, C325, C802, C824, C826, C802, C824, C826, R1205, R1225, C1255, R1205, R1225, C1255 R806 end-if-stmt R802, C801, R802, C801 R1204 end-interface-stmt R1201, C1202, R1201, C1202 R336 end-macro-stmt R314 R1106 end-module-stmt R1104, C1104, R1104, C1104 R1103 end-program-stmt R214, C201, R214, C201, C324, C325, C324, C325, C802, C824, C826, C802, C824, C826, R1101, C1102, R1101, C1102 R811 end-select-stmt R808, C803, R808, C803 R824 end-select-type-stmt R821, C819, R821, C819 R1238 end-sep-subprogram-stmt R1237, C1261, R1237, C1261 R1119 end-submodule-stmt R1116, C1120, R1116, C1121 R1236 end-subroutine-stmt R214, C201, R214, C201, C324, C325, C324, C325, C802, C824, C826, C802, C824, C826, R1205, R1233, C1259, R1205, R1233, C1259 R434 end-type-stmt R430 R751 end-where-stmt R744, C735, R744, C734 R924 endfile-stmt R214, C1284 R503 entity-decl R501, C502, C503, C505, C551, R501, C502, C503, C505 entity-decl-list C551 entity-name R526, R547, R526, R547 entry-name C1238, R1239, C1262, C1265, C1267, C1238, R1239, C1262, C1265, C1267 R1239 entry-stmt R206, R207, R209, R206, R207, R209, C1105, C1206, C1263, C1264, C1265, C1206, C1263, C1264, C1265 R463 enum-def R207 R464 enum-def-stmt R463 646 2006/07/11 WORKING DRAFT J3/06-007 R466 enumerator R465, C504, R465, C504 R465 enumerator-def-stmt R463 R721 equiv-op R310, R717 R716 equiv-operand R716, R717, R716, R717 R562 equivalence-object R561, C581, C582, C583, C584, C585, C586, C587, C588, C589, C590, C591, R561, C581, C582, C583, C584, C585, C586, C587, C588, C589, C590, C591 R561 equivalence-set R560 R560 equivalence-stmt R212 R629 errmsg-variable R627, R641, R627, R641, R858 R213 executable-construct R208, R209, R208, R209, C1263 R208 execution-part C201, R1101, C1101, R1101, C1101, R1225, R1233, R1237, R1225, R1233, R1237 R209 execution-part-construct R208, R801, R837, R801, R837 R844 exit-stmt R214, C325, C824, C826, C830, C831, C824, C826, C830, C831 R338 expand-stmt R322, C330, R322, C330 R512 explicit-shape-spec R445, C449, C450, R445, C449, C450, C514, R510, C528, R517, C593, C514, R510, C528, R517, C593 R416 exponent R413 R415 exponent-letter R413, C415, R413, C415 R722 expr R462, R472, R462, R472, R601, C602, R630, R601, C602, R630, R701, R722, R724, R725, R726, R727, R728, R730, R734, R739, C728, R742, C731, R701, R722, R724, R725, R726, R727, R728, R730, R734, R739, C728, R742, C730, R819, R916, R1223, R1242, C1270, C1271, C1275, R1223, R1242, C1270, C1271, C1275 R312 extended-intrinsic-op R311 external-name R1210 R1210 external-stmt R212 R203 external-subprogram R202, C1263 R906 file-name-expr R905, R930, 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, R901, R905, C904, C906, R909, C908, C920, C926, R922, C940, R923, R924, R925, R926, C943, R927, R928, C946, R930, C950, C1285 R457 final-binding R453 final-subroutine-name R457, C485, C486, R457, C485, C486 R928 flush-spec R927, C945, C946, R927, C945, C946 R927 flush-stmt R214, C1284 R757 foral l-assignment-stmt R756, C745, R759, R756, C744, R759 R756 foral l-body-construct R752, C742, C743, C744, R752, C741, C742, C743 R752 foral l-construct R213, R756, C742, R756, C741 foral l-construct-name R753, R758, C737, R753, R758, C736 R753 foral l-construct-stmt R752, C737, R752, C736 R754 foral l-header R753, R759, R753, R759, R830 R759 foral l-stmt R214, R756 R755 foral l-triplet-spec R754, C741, R754, C740 647 J3/06-007 WORKING DRAFT 2006/07/11 R914 format R910, R912, R913, C917, C918, C921, C929, C930, R910, R912, R913, C917, C918, C921, C929, C930 R1003 format-item R1002, C1002, R1003, R1004, R1002, C1002, R1003, R1004 R1002 format-specification R1001 R1001 format-stmt R206, R207, R209, R206, R207, R209, C1001, C1105, C1117, C1105, C1118, C1206 function-name R503, C508, R503, C508, C1203, R1226, C1238, C1239, R1232, C1255, C1267, R1242, C1273, C1203, R1226, C1238, C1239, R1232, C1255, C1267, R1242, C1273 R1219 function-reference R506, C512, R506, C512, R701 R1226 function-stmt R1205, C1203, R1225, C1240, C1247, C1248, C1255, R1205, C1203, R1225, C1240, C1247, C1248, C1255 R1225 function-subprogram R203, R211, R203, R211, R1108 R455 generic-binding R453, C471, R453, C471, C1111, C1112, C1113 generic-name C473, R1207, C1202, R1207, C1202 R1207 generic-spec R455, C471, C473, C474, C475, C476, R455, C471, C473, C474, C475, C476, R521, R1112, C1112, C1113, R1112, C1113, C1114, R1203, R1204, C1202, C1204, R1203, R1204, C1202, C1204 R851 goto-stmt R214, C325, C824, C826, C835, C824, C826, C835 R428 hex-constant R425 R429 hex-digit R428, R1021 R802 if-construct R213, C801 if-construct-name R803, R804, R805, R806, C801, R803, R804, R805, R806, C801 R807 if-stmt R214, C324, C802 R803 if-then-stmt R802, C801, R802, C801 R419 imag-part R417 R624 image-selector R613, C615, R613, C615 R862 image-set C843, R863, R864, C843, R863, R864 R860 image-team C842, R905 R205 implicit-part R204 R206 implicit-part-stmt R205 R556 implicit-spec R555 R555 implicit-stmt R205, R206, R205, R206 R518 implied-shape-spec R510 import-name R1209, C1211, R1209, C1211 R1209 import-stmt R204 index-name R755, C740, C741, C742, R755, C739, C740, C741 R449 initial-data-target R448, C464, R448, C464, R505, C511, R536, R505, C511, R536 R505 initialization R503, C505, C506, C507, C510, R503, C505, C506, C507, C510 R730 initialization-expr R448, R505, R544, R505, R544, C712 R841 inner-shared-do-construct R840, C827, R840, C827 R915 input-item R910, C916, R918, C932, C933, C935, R910, C916, R918, C932, C933, C935 R930 inquire-spec R929, C948, C949, C950, R929, C948, C949, C950 R929 inquire-stmt R214, C1284 648 2006/07/11 WORKING DRAFT J3/06-007 R308 int-constant C302, R535 int-constant-name R408, C409, R408, C409 R537 int-constant-subobject R535, C572, R535, C572 R727 int-expr R401, R474, R401, R474, R611, R619, R622, R623, R625, R634, R635, R611, R619, R622, R623, R625, R634, R635, C708, R729, C711, R732, C708, R729, C711, R732, R812, R830, R852, R862, C843, R812, R830, R852, R862, C843, R902, R905, R913, R919, R922, R930, R902, R905, R913, R919, R922, R930, R1240, C1269, R1240, C1269 R732 int-initialization-expr R405, C408, R420, C418, R437, R466, R405, C408, R420, C418, R437, R466, R531, C714, R815, R856, C840, R815, R856, C840 R407 int-literal-constant R306, R406, R422, C419, R406, R422, C419, R1005, R1007, R1008, R1009, R1010, R1015, R1005, R1007, R1008, R1009, R1010, R1015 R608 int-variable C608, R628, C608, R628, R905, R909, R913, R922, R926, R928, R929, R930, R905, R909, R913, R922, R926, R928, R929, R930 int-variable-name R831 R519 intent-spec R502, R541, R502, R541, R1213 R541 intent-stmt R212 R1201 interface-block R207, C1201 R1205 interface-body R1202, C1201, C1205, C1206, C1210, R1202, C1201, C1205, C1206, C1210 R1215 interface-name R454, C469, C482, R454, C469, C482, R1212, C1220, R1212, C1220 R1202 interface-specification R1201 R1203 interface-stmt R1201, C1202, C1203, R1201, C1202, C1203 R903 internal-file-variable R901, C922, R901, C922 R211 internal-subprogram R210 R210 internal-subprogram-part R1101, R1225, C1254, R1233, C1258, R1237, C1278, R1225, C1254, R1233, C1258, R1237, C1278 R310 intrinsic-operator R312, C703, C704, C703, C704 intrinsic-procedure-name R1218, C1221, R1218, C1221 R1218 intrinsic-stmt R212 R404 intrinsic-type-spec R402, R403, R402, R403 R913 io-control-spec R910, R911, C910, C911, C917, C918, C919, C920, C928, R910, R911, C910, C911, C917, C918, C919, C920, C928 R917 io-implied-do R915, R916, R915, R916 R919 io-implied-do-control R917 R918 io-implied-do-object R917, C935, R917, C935 R901 io-unit R913, C911, C918, C919, C920, C922, C926, R913, C911, C918, C919, C920, C922, C926, C1285 R907 iomsg-variable R905, R909, R913, R922, R926, R928, R930, R905, R909, R913, R922, R926, R928, R930 R1013 k R1012, C1010, R1012, C1010 R215 keyword R459, C491, C492, R461, C498, C499, R459, C491, C492, R461, C498, C499, R1222, C1228, C1229, C1230, R1222, C1228, C1229, C1230 649 J3/06-007 WORKING DRAFT 2006/07/11 R408 kind-param R407, C410, C411, R413, C415, C416, C419, R423, C427, R424, C428, R425, R407, C410, C411, R413, C415, C416, C419, R423, C427, R424, C428, R425 R405 kind-selector R404, R436, R404, R436 R313 label C304, R828, C823, R851, C835, R852, C836, R853, C837, R828, C823, R851, C835, R852, C836, R853, C837, R905, C905, R909, C909, R913, C914, R914, C931, R922, C941, R926, C944, R928, C947, R930, C952, R905, C905, R909, C909, R913, C914, R914, C931, R922, C941, R926, C944, R928, C947, R930, C952, R1224, C1234, R1224, C1234 R828 label-do-stmt R827, C823, R836, C825, R839, R841, C827, R827, C823, R836, C825, R839, R841, C827 R508 language-binding-spec R502, C502, C503, R525, C560, R502, C502, C503, R525, C560, R1227 R470 lbracket R343, R444, R468, R444, R468, R503, R509, R523, R540, R552, R503, R509, R523, R540, R552, R624, R631, R624, R631 R421 length-selector R420, C424, C425, R420, C424, C425 letter R302, R304, R302, R304, R557, C577, R557, C577, R703, R723, R703, R723 R557 letter-spec R556 R702 level-1-expr R704 R706 level-2-expr R706, R710, R706, R710 R710 level-3-expr R710, R712, R710, R712 R712 level-4-expr R714 R717 level-5-expr R717, R722, R717, R722 R306 literal-constant R305 R1114 local-defined-operator R1111 local-name R1111 R724 logical-expr C705, R733, R748, C705, R733, R748, R803, R804, R807, R812, R830, R803, R804, R807, R812, R830 R733 logical-initialization-expr C715, R815 R424 logical-literal-constant R306, C703, C704, C703, C704 R604 logical-variable C604 R830 loop-control R828, R829, R828, R829 R513 lower-bound R512, R515, R517, R518, R512, R515, R517, R518 R634 lower-bound-expr R633, R636, R637, R633, R636, R637, R737, R738, R737, R738 R1008 m R1006, C1008, R1006, C1008 R339 macro-actual-arg C327, C328, C330, C327, C328, C330 R321 macro-body-block R314, R323, R327, R314, R323, R327 R322 macro-body-construct R321, C309, R321, C309 R333 macro-body-stmt R322, C315, C316, R322, C315, C316 R332 macro-condition R328, R329, R328, R329 R317 macro-declaration-stmt R314 R314 macro-definition R207, R322, C309, R322, C309 R323 macro-do-construct R322 R325 macro-do-limit C311 R324 macro-do-stmt R323 macro-do-variable-name C310 650 2006/07/11 WORKING DRAFT J3/06-007 macro-dummy-arg-name C305, C307, C305, C307 macro-dummy-arg-name-list C305 macro-dummy-name C329, C330, C329, C330 R329 macro-else-if-stmt R327 R330 macro-else-stmt R327 R326 macro-end-do-stmt R323 R331 macro-end-if-stmt R327 R337 macro-expr R320, C308, R325, R332, C318, R320, C308, R325, R332, C318 R327 macro-if-construct R322 R328 macro-if-then-stmt R327 macro-local-variable-name C306 macro-name R336, C317, C319, R336, C317, C319 R318 macro-type-declaration-stmt R317 R1101 main-program R202, C1101 R748 mask-expr R743, R745, R749, R754, C738, C739, R743, R745, R749, R754, C737, C738 R749 masked-elsewhere-stmt R744, C735, R744, C734 R1104 module R202 module-name R1105, R1106, C1104, R1109, C1108, C1109, R1105, R1106, C1104, R1109, C1108, C1109, C1111 R1110 module-nature R1109, C1108, C1109, R1109, C1108, C1109 R1105 module-stmt R1104, C1104, R1104, C1104 R1108 module-subprogram R1107, C1263 R1107 module-subprogram-part R1104, R1116, R1104, R1116 R708 mult-op R310, R705 R704 mult-operand R704, R705, R704, R705 R1015 n R1014, C1011, C1012, R1014, C1011, C1012 R304 name R102, R215, C301, R307, C301, R307, R504, R550, R504, R550, R602, R1215, C1213, C1214, R1228, R1215, C1213, C1214, R1228 R307 named-constant R305, R418, R419, R466, R418, R419, R466, R544 R544 named-constant-def R543 namelist-group-name R558, C578, C580, R558, C578, C580, R913, C915, C916, C917, C919, C921, C929, C930, R913, C915, C916, C917, C919, C921, C929, C930 R559 namelist-group-object R558, C579, C580, R558, C579, C580 R558 namelist-stmt R212 R343 nested-token-sequence R341 R835 nonblock-do-construct R825 R829 nonlabel-do-stmt R827, C822, R827, C822 R718 not-op R310, R714 R863 notify-stmt R214 R506 nul l-init R448, R505, R536, R505, R536, R1216 R638 nul lify-stmt R214 R728 numeric-expr C709, R853, C838, R853, C838 R504 object-name R503, C506, C509, C511, R522, R523, R524, R527, R546, R549, R551, R552, R554, R503, C506, C509, C511, R522, R523, R524, R527, R546, R549, R551, R552, R554, R603 651 J3/06-007 WORKING DRAFT 2006/07/11 R427 octal-constant R425 R1112 only R1109 R1113 only-use-name R1112 R904 open-stmt R214, C1284 R542 optional-stmt R212 R720 or-op R310, R716 R715 or-operand R715, R716, R715, R716 R839 outer-shared-do-construct R835, R840, C827, R835, R840, C827 R916 output-item R911, R912, C916, R918, C935, C936, R929, R911, R912, C916, R918, C935, C936, R929 R543 parameter-stmt R206, R207, R206, R207 R1118 parent-identifier R1117 R610 parent-string R609, C609, R609, C609 parent-submodule-name R1118, C1119, R1118, C1120 parent-type-name R432, C433, R432, C433 part-name R613, C610, C611, C612, C613, C614, C615, C617, C618, C623, R613, C610, C611, C612, C613, C614, C615, C617, C618, C623 R613 part-ref C564, C567, C582, C564, C567, C582, R612, C617, C618, C621, C622, R612, C617, C618, C621, C622 R735 pointer-assignment-stmt R214, C546, R757 R546 pointer-decl R545 R639 pointer-object R638, C639, R638, C639 R545 pointer-stmt R212 R1014 position-edit-desc R1012 R926 position-spec R923, R924, R925, C942, C943, R923, R924, R925, C942, C943 R707 power-op R310, R704 R1229 prefix R1226, C1244, C1245, C1246, C1247, C1249, C1250, C1251, C1252, R1234, C1256, R1226, C1244, C1245, C1246, C1247, C1249, C1250, C1251, C1252, R1234, C1256 R1230 prefix-spec R1229, C1244, R1229, C1244 primaries C1270 R701 primary R702 R912 print-stmt R214, C1284 R450 private-components-stmt R433, C466, R433, C466 R433 private-or-sequence R430, C437, R430, C437 R1213 proc-attr-spec R1211 R453 proc-binding-stmt R451 R447 proc-component-attr-spec R446, C455, C456, C459, R446, C455, C456, C459 R446 proc-component-def-stmt R440, C455, R440, C455 R741 proc-component-ref R740, R742, R740, R742, R1221, R1223, R1221, R1223 R1214 proc-decl R446, R1211, C1217, C1219, R1211, C1217, C1219 proc-entity-name R546 R1212 proc-interface R446, R1211, C1216, C1220, R1211, C1216, C1220 R1227 proc-language-binding-spec C515, R1213, C1219, C1220, C1240, C1241, C1242, C1247, R1231, R1234, R1213, C1219, C1220, C1240, C1241, C1242, C1247, R1231, R1234 652 2006/07/11 WORKING DRAFT J3/06-007 R1216 proc-pointer-init R1214 R550 proc-pointer-name R549, R564, C594, C597, R549, R564, C594, C597, R639, R740 R740 proc-pointer-object R735 R742 proc-target R462, C502, R462, C502, C546, R735, C733, R735, C732 procedure-component-name C730, R741, C729 R1211 procedure-declaration-stmt R207, C1213 R1221 procedure-designator R1219, C1222, R1220, C1224, R1219, C1222, R1220, C1224 procedure-entity-name R1214, C1216, R1214, C1216 procedure-name R454, C468, C469, C470, R454, C468, C469, C470, R742, C732, R742, C731, R1206, C1207, C1208, C1209, R1217, C1218, R1221, C1225, R1223, C1232, C1233, R1237, R1238, C1260, C1261, R1206, C1207, C1208, C1209, C1218, R1221, C1225, R1223, C1232, C1233, R1237, R1238, C1260, C1261 R1206 procedure-stmt R1202, C1204, C1208, C1209, R1202, C1204, C1208, C1209 program-name R1102, R1103, C1102, R1102, R1103, C1102 R1102 program-stmt R1101, C1102, R1101, C1102 R202 program-unit R201 R547 protected-stmt R212 R865 query-spec R864, C844, R864, C844 R864 query-stmt R214 R1005 r R1003, C1003, C1004, R1012, R1003, C1003, C1004, R1012 R471 rbracket R343, R444, R468, R444, R468, R503, R509, R523, R540, R552, R503, R509, R523, R540, R552, R624, R631, R624, R631 R910 read-stmt R214, C912, C1285 R413 real-literal-constant R306, R412 R418 real-part R417 R713 rel-op R310, R712 R1111 rename R1109, R1112, R1109, R1112 rep-char R423 result-name C1238, R1231, C1267, C1238, R1231, C1267 R334 result-token R333, C313, C314, R333, C313, C314 R1240 return-stmt R214, C325, C824, C826, C824, C826, C1268 R925 rewind-stmt R214, C1284 R1018 round-edit-desc R1012 R548 save-stmt R212 R549 saved-entity R548 R103 scalar-xyz C101 R620 section-subscript R613, C614, C615, C622, R613, C614, C622 section-subscript-list C615 R809 select-case-stmt R808, C803, R808, C803 select-construct-name R822, R823, R824, C819, R822, R823, R824, C819 R821 select-type-construct R213, C817, C818, C819, C817, C818, C819 R822 select-type-stmt R821, C813, C819, R821, C813, C819 653 J3/06-007 WORKING DRAFT 2006/07/11 R819 selector R818, C808, R822, C811, C812, C813, C816, R818, C808, R822, C811, C812, C813, C816 R1237 separate-module-subprogram R1108, C1260 R435 sequence-stmt R433 R840 shared-term-do-construct R839 R411 sign R406, R409, R412, R406, R409, R412 R1016 sign-edit-desc R1012 R409 signed-digit-string R416 R406 signed-int-literal-constant R418, R419, R418, R419, R536, R1011, R1013, R1011, R1013 R412 signed-real-literal-constant R418, R419, R418, R419, R536 R414 significand R413 R630 source-expr R627, C636, C637, R627, C636, C637 special-character R301 R454 specific-binding R453 R729 specification-expr C404, C420, C404, C420, R513, R514, R513, R514, C1291 R204 specification-part C471, C516, C558, C516, C558, R845, R1101, C1103, R1104, C1105, C1106, C1107, R1116, C1116, C1117, C1118, R1120, C1122, C1123, R1101, C1103, R1104, C1105, C1106, C1107, R1116, C1117, C1118, C1119, R1120, C1123, C1124, R1205, R1225, R1233, R1237, C1276, C1277, C1278, C1279, R1205, R1225, R1233, R1237, C1276, C1277, C1278, C1279 R212 specification-stmt R207 R628 stat-variable R627, R641, R627, R641, R858 R1242 stmt-function-stmt R207, C1105, C1117, C1105, C1118, C1206 R856 stop-code R855 R855 stop-stmt R214, C325, C824, C826, C824, C826, C1286 R622 stride R621, R755, C741, R755, C740 R614 structure-component R532, C566, C567, C568, R532, C566, C567, C568, R603, R610, R632, R639, R603, R610, R632, R639 R460 structure-constructor R536, C571, R536, C571, R701 R1116 submodule R202 submodule-name R1117, R1119, C1120, R1117, R1119, C1121 R1117 submodule-stmt R1116, C1120, R1116, C1121 subroutine-name C1203, R1234, R1236, C1259, C1203, R1234, R1236, C1259 R1234 subroutine-stmt R1205, C1203, C1240, C1247, C1248, R1233, C1256, C1259, R1205, C1203, C1240, C1247, C1248, R1233, C1256, C1259 R1233 subroutine-subprogram R203, R211, R203, R211, R1108 R619 subscript C567, C621, R620, R621, C621, R620, R621, R755, C741, R755, C740 R621 subscript-triplet R620, C625, R620, C625 R609 substring R562, C592, R562, C592, R603 R611 substring-range R609, R618, C623, R609, R618, C623 R1231 suffix R1226, R1239, R1226, R1239 R857 sync-al l-stmt R214 R861 sync-images-stmt R214 654 2006/07/11 WORKING DRAFT J3/06-007 R866 sync-memory-stmt R214 R858 sync-stat R857, C841, R863, R865, R866, R857, C841, R863, R865, R866 R859 sync-team-stmt R214 R552 target-decl R551 R551 target-stmt R212 R335 token R334, C314, R334, C314 R432 type-attr-spec R431, C432, R431, C432 R451 type-bound-procedure-part R430, C440, R430, C440, C1504 R501 type-declaration-stmt R207, C424, C425, C424, C425, C501 R823 type-guard-stmt R821, C817, C818, C819, R821, C817, C818, C819 type-name R431, C431, R434, C438, C476, R458, C488, R431, C431, R434, C438, C476, R458, C488 R438 type-param-attr-spec R436 R437 type-param-decl R436 R436 type-param-def-stmt R430, C441, C442, R430, C441, C442 R616 type-param-inquiry R701 type-param-name R431, R437, C441, C442, R431, R437, C441, C442, R616, C620, R616, C620, R701, C701, R701, C701 R459 type-param-spec R458, C489, C490, C491, C493, R458, C489, C490, C491, C493 R401 type-param-value C401, C402, C404, R420, R421, R422, C420, C421, C422, C423, C454, R459, C493, C401, C402, C404, R420, R421, R422, C420, C421, C422, C423, C454, R459, C493, C630 R402 type-spec R469, C505, C506, C507, R469, C505, C506, C507, R626, C627, C628, C629, C630, C631, C635, R626, C627, C628, C629, C630, C631, C635, R823, C814, C815, C816, R823, C814, C815, C816 R303 underscore R302 R1004 unlimited-format-item R1002 R514 upper-bound R512 R635 upper-bound-expr R633, R637, R633, R637, R738 R1115 use-defined-operator R1111, C1111, C1115, R1111, C1112, C1116 use-name R521, C559, R521, C559, R1111, R1113, C1114, R1111, R1113, C1115 R1109 use-stmt R204 R1011 v R1006, C1008, R1006, C1008 R553 value-stmt R212 R601 variable R530, C562, C564, R530, C562, C564, R604, R605, R606, R607, R608, R604, R605, R606, R607, R608, R734, C716, R736, C723, C724, R739, C726, C729, C730, C745, R734, C716, R736, C723, C724, R739, C726, R741, C729, C744, R819, C808, C811, C812, R819, C808, C811, C812, R915, R1223 R602 variable-name R559, R562, R564, C594, C597, R559, R562, R564, C594, C597, C603, R610, R632, R639, C603, R610, R632, R639, R736, C722, R736, C722 R623 vector-subscript R620, C624, R620, C624 R554 volatile-stmt R212 R1007 w R1006, C1006, C1007, C1008, R1006, C1006, C1007, C1008 655 J3/06-007 WORKING DRAFT 2006/07/11 R922 wait-spec R921, C939, C940, R921, C939, C940 R921 wait-stmt R214, C1284 R747 where-assignment-stmt R743, R746, C734, R743, R746, C733 R746 where-body-construct R744, C736, R744, C735 R744 where-construct R213, R746, R756, R746, R756 where-construct-name R745, R749, R750, R751, C735, R745, R749, R750, R751, C734 R745 where-construct-stmt R744, C735, R744, C734 R743 where-stmt R214, R746, R756, R746, R756 R911 write-stmt R214, C913, C1285 656 Annex E (Informative) Index In this index, entries in italics denote BNF terms, entries in b old face denote language keywords, and page numbers in b old face denote primary text or glossary definitions. Symb ols <, 152 <=, 152 >, 152 >=, 152 (, 154 *, 31, 42, 44, 46, 51, 91, 102, 124, 151, 234, 265, 278, 283, 310, 329 **, 151 +, 151 -, 151 .AND., 153, 154 .EQ., 152 .EQV., 153, 154 .GE., 152 .GT., 152 .LE., 152 .LT., 152 .NE., 152 .NEQV., 153, 154 .NOT., 153, 154 .OR., 153, 154 .XOR., 153, 154 /, 151 //, 52, 151 /=, 152 ;, 31 ==, 152 &, 30 &, 283 A abstract interface, 299 abstract interface block, 302 abstract type, 73, 509 ac-do-variable (R475), 80, 80, 81, 142, 144, 491, 492 ac-implied-do (R473), 80, 80, 81, 145, 492 ac-implied-do-control (R474), 80, 80, 142­145 ac-spec (R469), 80, 80 ac-value (R472), 80, 80, 81 access methods, 208 access-id (R521), 99, 99, 100 657 access-spec (R507), 33, 56, 57, 61, 63, 68­70, 83, 86, 86, 99, 307 access-stmt (R520), 10, 99, 99, 100 ACCESS= sp ecifier, 219, 249 accessibility attribute, 86 accessibility statements, 99 J3/06-007 WORKING DRAFT 2006/07/11 action-stmt (R214), 11, 11, 36, 177, 193 array element order, 121 action-term-do-construct (R836), 186, 186 array elements, 119 ACTION= sp ecifier, 219, 249 array intrinsic assignment statement, 158 actions, 208 array pointer, 90, 509 active, 186 array section, 20, 121, 509 active combination of, 171 array-constructor (R468), 80, 80, 81, 133 actual argument, 297, 509 array-element (R617), 101, 109, 115, 116, 120 actual-arg (R1223), 310, 310 array-name, 103, 493 actual-arg-spec (R1222), 76, 309, 310, 310 array-section (R618), 115, 120, 120, 121 add-op (R709), 27, 134, 134 array-spec (R510), 7, 84, 85, 88, 89, 89, 91, 100, add-operand (R705), 134, 134, 155 103, 105, 111, 112 ADVANCE= sp ecifier, 227 ASCII, 424 advancing input/output statement, 212 ASCII character set, 50 affector, 228 ASCII character type, 50 al loc-opt (R627), 124, 124, 125 ASCII collating sequence, 53 allocatable array, 90 assignment, 156­174 ALLOCATABLE attribute, 86, 100 defined, 161 ALLOCATABLE statement, 100 elemental array (FORALL), 168 allocatable variable, 509 intrinsic, 157 al locatable-decl (R523), 100, 100 masked array (WHERE), 166 al locatable-stmt (R522), 10, 100, 493 pointer, 162 ALLOCATE statement, 124 assignment statement, 156, 509 al locate-co-array-spec (R636), 124, 124, 127 assignment-stmt (R734), 11, 157, 157, 166, 169, al locate-co-shape-spec (R637), 124, 124 171, 335, 508 al locate-object (R632), 51, 52, 124, 124, 125, ASSOCIATE construct, 180 126, 128, 129, 508 ASSOCIATE construct, 492 al locate-shape-spec (R633), 124, 124 associate name, 509 al locate-stmt (R626), 11, 124, 508 associate names, 180 allocated, 127 associate-construct (R816), 11, 180, 181 al location (R631), 124, 124, 126, 127 associate-construct-name, 180, 181 alphanumeric-character (R302), 25, 25, 27 associate-name, 180­184, 491, 519 alt-return-spec (R1224), 193, 309, 310, 310 associate-stmt (R817), 180, 180, 181, 193 ancestor, 293 associated, 22 ancestor component, 74 associating entity, 502 ancestor-module-name, 294 association, 23, 509 and-op (R719), 27, 136, 136 argument, 311, 492 and-operand (R714), 136, 136 host, 493 APOSTROPHE (DELIM value), 288 name, 492 approximation methods, 47 pointer, 496 arg-name, 62­64, 69 sequence, 318 arg-token (R344), 36, 36 storage, 499 argument, 509 use, 493 argument association, 311, 492, 509 association (R818), 180, 180 argument keyword, 22, 311 association status argument keywords, 340, 491 pointer, 496 arithmetic IF statement, 193 assumed type parameter, 42 arithmetic-if-stmt (R853), 11, 36, 186, 193, 193 assumed-shape array, 90, 509 array, 20, 88­92, 119, 119­122, 509 assumed-shape-spec (R515), 89, 90, 90 assumed-shape, 90 assumed-size array, 91, 509 assumed-size, 91 assumed-size-spec (R517), 89, 91 deferred-shape, 90 ASYNCHRONOUS attribute, 86, 100 explicit-shape, 90 ASYNCHRONOUS statement, 100 array constructor, 80, 80 array element, 20, 121, 509 asynchronous-stmt (R524), 10, 100 658 2006/07/11 WORKING DRAFT J3/06-007 ASYNCHRONOUS= sp ecifier, 219, 227, bits relational intrinsic operation, 138 250 bits type, 54 attr-spec (R502), 83, 83, 84, 85, 105 blank common, 111 attribute, 509 blank-interp-edit-desc (R1017), 261, 262 accessibility, 86 BLANK= sp ecifier, 219, 228, 250 ALLOCATABLE, 86, 100 block, 175, 510 ASYNCHRONOUS, 86, 100 block (R801), 175, 176, 178, 180, 182, 185, 191, BIND, 56, 59, 100 192 DIMENSION, 88, 103 block data program unit, 294, 510 EXTERNAL, 92 block-construct (R845), 11, 191, 191 INTENT, 92, 103 block-construct-name, 191 INTRINSIC, 94 block-data (R1120), 9, 294, 294 OPTIONAL, 94, 104 block-data-name, 294, 295 PARAMETER, 95, 104 block-data-stmt (R1121), 9, 294, 294 POINTER, 95, 104 block-do-construct (R826), 185, 185 PRIVATE, 57, 86, 100 block-stmt (R846), 191, 191 PROTECTED, 96, 105 blocking, 203 PUBLIC, 57, 86, 100 bounds, 510 SAVE, 101, 105 bounds-remapping (R738), 162, 163, 163, 164 TARGET, 98, 105 bounds-spec (R737), 162, 163, 163, 164 VALUE, 99, 105 boz-literal-constant (R425), 27, 54 VOLATILE, 99, 105 branch target statement, 193 attribute specification statements, 99­114 Branching, 193 attributes, 83, 85­99 C automatic data ob ject, 84, 510 C address, 473 B C character kind, 472 BACKSPACE statement, 246 C (C type), 471­483 backspace-stmt (R923), 11, 245, 335 C LOC function, 475 base ob ject, 117 CALL statement, 309 base type, 73, 510 cal l-stmt (R1220), 11, 309, 310, 311 basic-token (R342), 36, 36 CASE construct, 178 basic-token-sequence (R341), 35, 36, 36 case index, 178 belong, 510 case-construct (R808), 11, 178, 178 belongs, 175, 510 case-construct-name, 178 binary-constant (R426), 54, 55, 55 case-expr (R812), 178, 178 BIND attribute, 56, 59, 100 case-selector (R813), 178, 178 BIND statement, 100 case-stmt (R810), 178, 178 BIND(C), 78, 87, 298, 300, 480, 482, 485 case-value (R815), 178, 178 bind-entity (R526), 100, 100 case-value-range (R814), 178, 178 bind-stmt (R525), 10, 100 CHAR intrinsic, 53 binding, 70 char-constant (R309), 27, 27 binding label, 485, 510 char-expr (R725), 140, 140, 144, 178 binding name, 70 char-initialization-expr (R731), 87, 144, 144, binding-attr (R456), 69, 69, 70 178, 194, 225, 226 binding-name, 69, 70, 309, 325, 491, 521 char-length (R422), 51, 51, 61, 62, 83, 84 binding-private-stmt (R452), 68, 68, 70 char-literal-constant (R423), 27, 32, 52, 239, 261, 262 bit model, 341 char-selector (R420), 46, 51, 51 bits compatible, 44, 45 char-string-edit-desc (R1020), 260, 262 bits conversion, 160 char-variable (R606), 115, 115, 214 bits editing, 265 CHARACTER, 50 bits intrinsic assignment statement, 158 character, 510 bits intrinsic operation, 138 bits intrinsic operator, 138 character (R301), 25 659 J3/06-007 WORKING DRAFT 2006/07/11 character context, 29 complex-part-designator (R615), 115, 118, 118, 120 CHARACTER declaration, 525 component, 511 character intrinsic assignment statement, 158 component keyword, 22 character intrinsic operation, 138, 151 Component order, 67 character intrinsic operator, 138 component order, 511 character length parameter, 510 component value, 75 character literal constant, 52 component-array-spec (R445), 61, 62, 62, 63 character relational intrinsic operation, 138 component-attr-spec (R442), 61, 61, 62, 64, 65 character sequence type, 58, 109, 501, 616 component-data-source (R462), 76, 76, 77 character set, 25 component-decl (R443), 51, 61, 61, 63, 65 character storage unit, 499, 510 component-def-stmt (R440), 61, 61, 62 character string, 50, 510 component-dim-spec (R444), 61, 62 character string edit descriptor, 260 component-initialization (R448), 61, 65, 65, 290 character type, 50, 50­54 component-name, 61, 65 characteristics, 510 component-part (R439), 56, 61, 68, 71 characteristics of a procedure, 298 component-spec (R461), 76, 76, 143 child, 293 components, 491 child data transfer statement, 237, 236­241, 257 computed GO TO statement, 193 CLASS, 44 computed-goto-stmt (R852), 11, 193, 193 class, 510 concat-op (R711), 27, 135, 135 CLOSE statement, 223 concatenation, 52 close-spec (R909), 223, 223, 224 conform, 157 close-stmt (R908), 11, 223, 335 conformable, 21, 511 co-array, 21, 510 conformance, 141, 511 co-array-name, 103 connect team, 222, 511 co-array-spec (R511), 61­63, 84, 88, 89, 89, 100, connect-spec (R905), 217, 217, 218, 222 103, 105 connected, 216, 511 co-bounds, 88, 511 connected files, 216 co-indexed ob ject, 21, 511 constant, 20, 27, 41, 511 co-rank, 21, 511 character, 52 co-size, 21 integer, 47 co-subscript, 511 named, 104 co-subscript (R625), 21, 123, 123 constant (R305), 27, 27, 102, 116, 133 collating sequence, 53, 53, 511 constant subob ject, 20 collective subroutine, 339, 511 constant-subobject (R538), 102, 102 comment, 30, 31 construct, 511 common association, 113 Construct association, 496 common block, 111, 489, 511, 556 construct association, 511 common block storage sequence, 112 construct entity, 487, 511 COMMON statement, 111, 111­114 construct-name, 191 common-block-name, 100, 105, 111, 293 constructor common-block-object (R564), 111, 111, 112, 293, 493 array, 80 common-stmt (R563), 10, 111, 493 derived-type, 76 companion processor, 24, 511 structure, 76 compatibility CONTAINS statement, 332 Fortran 77, 4 contains-stmt (R1241), 10, 68, 290, 332 Fortran 2003, 3 contiguous, 87 Fortran 90, 4 CONTIGUOUS attribute, 87 Fortran 95, 3 contiguous-stmt (R527), 101 COMPLEX, 49 continuation, 30, 31 complex part designator, 118 CONTINUE statement, 194 complex type, 49, 49 continue-stmt (R854), 11, 36, 185, 186, 194 complex-literal-constant (R417), 27, 49 control character, 25 660 2006/07/11 WORKING DRAFT J3/06-007 control edit descriptor, 260 deal locate-stmt (R640), 11, 128, 508 control edit descriptors, 275 decimal symbol, 264, 512 control information list, 224 decimal-edit-desc (R1019), 261, 262 control mask, 511 DECIMAL= sp ecifier, 219, 228, 250 control-edit-desc (R1012), 260, 261 declaration, 23 conversion declaration-construct (R207), 10, 10 bits, 160 declaration-type-spec (R403), 43, 43, 44, 51, 61, numeric, 160 62, 83, 84, 106, 142, 307, 326, 329 correspond, 330 declarations, 83­114 critical-construct (R848), 11, 192, 192 declared type, 44, 512 critical-construct-name, 192 default bits, 54 critical-stmt (R849), 192, 192 default character, 51 current record, 211 default complex, 49 CYCLE statement, 185, 188 default initialization, 512 cycle-stmt (R843), 11, 36, 186, 188, 188 default integer, 47 default logical, 54 D default real, 48 default-char-expr (R726), 140, 140, 217­221, d (R1009), 261, 261, 267­270, 273, 282 223­229 data, 512 default-char-variable (R607), 115, 115, 124, 218, data edit descriptor, 260 248­254 data edit descriptors, 264­274 default-initialized, 66, 512 data entity, 19, 512 default-logical-variable (R605), 115, 115, 248­ data ob ject, 19, 512 252 data ob ject reference, 23 deferred binding, 70, 512 data pointer, 22 deferred type parameter, 42, 512 DATA statement, 101, 504 deferred-shape array, 90 data transfer, 234 deferred-shape-spec (R516), 62, 89, 91, 91, 104 data transfer input statement, 207 definable, 512 data transfer output statements, 207 define-macro-stmt (R315), 33, 33, 494 data transfer statements, 224 defined, 23, 512 data type, see type, 512 defined assignment, 305 data-component-def-stmt (R441), 61, 61, 63 defined assignment statement, 161, 512 data-edit-desc (R1006), 260, 260 defined binary operation, 139 data-i-do-object (R532), 101, 101, 102 defined elemental assignment statement, 161 data-i-do-variable (R533), 101, 101, 102, 144, defined elemental operation, 139 491, 492 defined operation, 138, 304, 512 data-implied-do (R531), 101, 101, 102, 144, 492 defined unary operation, 138 data-pointer-component-name, 163 defined-binary-op (R723), 28, 136, 136, 139, data-pointer-initialization compatible, 65 155, 292 data-pointer-object (R736), 162, 163, 163, 164, defined-operator (R311), 28, 69, 292, 301 171, 172, 356, 508 defined-unary-op (R703), 28, 134, 134, 138, 139, data-ref (R612), 117, 117, 118, 120, 163, 228, 154, 292 309, 311, 317, 325 definition, 23 data-stmt (R528), 10, 101, 301, 334, 493 definition of variables, 503 data-stmt-constant (R536), 102, 102, 103 deleted feature, 512 data-stmt-object (R530), 101, 101, 102 deleted features, 7 data-stmt-repeat (R535), 102, 102 DELIM= sp ecifier, 219, 228, 250 data-stmt-set (R529), 101, 101 Delimiters, 29 data-stmt-value (R534), 101, 102, 102 derived type, 19, 512 data-target (R739), 76, 77, 96, 162, 163, 163, derived type determination, 58 164, 171, 319, 334, 356, 499 derived types, 56­78 datum, 512 deal loc-opt (R641), 128, 129, 129, 131 derived-type intrinsic assignment statement, DEALLOCATE statement, 128 158 661 J3/06-007 WORKING DRAFT 2006/07/11 E derived-type type specifier, 44 derived-type-def (R430), 10, 44, 56, 57, 60 e (R1010), 261, 261, 268, 269, 273, 274, 282 derived-type-spec (R458), 43, 44, 51, 75, 76, 182, edit descriptor, 260 237, 238, 491 edit descriptors, see format descriptors derived-type-stmt (R431), 56, 56, 57, 60, 493 effective item, 231, 513 descendant, 293 effective position, 490 designator, 22, 512 element array assignment (FORALL), 168 designator (R603), 65, 102, 115, 115, 118, 119, element sequence, 318 133, 169 elemental, 21, 297, 513 designator, 133 elemental intrinsic function, 339 digit, 5, 6, 25, 26, 28, 47, 55, 280 elemental operation, 141 digit-string (R410), 47, 47, 48, 49, 266, 267, 271 elemental procedure, 335 digit-string, 47 else-if-stmt (R804), 176, 176 digits, 25 else-stmt (R805), 176, 176 DIMENSION attribute, 88, 103 elsewhere-stmt (R750), 166, 166 DIMENSION statement, 103 ENCODING= sp ecifier, 219, 250 dimension-decl (R540), 103, 103 END statement, 15, 15 dimension-spec (R509), 89 end-associate-stmt (R820), 180, 181, 181, 193 dimension-stmt (R539), 10, 103, 493 end-block-data-stmt (R1122), 10, 15, 294, 294 direct access, 210 end-block-stmt (R847), 191, 191 direct access input/output statement, 229 end-critical-stmt (R850), 192, 192 DIRECT= sp ecifier, 250 end-do (R833), 185, 185, 186, 188 disassociated, 22, 513 end-do-stmt (R834), 185, 185, 193 distinguishable, 490 end-enum-stmt (R467), 78, 79 DO construct, 185 end-foral l-stmt (R758), 168, 169, 169 DO statement, 185 end-function-stmt (R1232), 9, 11, 15, 36, 177, DO termination, 186 186, 301, 326, 327, 327, 332 DO WHILE statement, 185 end-if-stmt (R806), 176, 176, 193 do-block (R832), 185, 185, 186, 187 end-interface-stmt (R1204), 300, 301, 301 do-body (R837), 186, 186 end-macro-stmt (R336), 33, 35 do-construct (R825), 11, 185, 188, 191 end-module-stmt (R1106), 9, 15, 290, 290 do-construct-name, 185, 188 end-of-file condition, 255 do-stmt (R827), 185, 185, 193, 508 end-of-record condition, 255 do-term-action-stmt (R838), 36, 186, 186, 188, end-program-stmt (R1103), 9, 11, 15­17, 36, 193 177, 186, 194, 195, 289, 289 do-term-shared-stmt (R842), 186, 186, 187, 188, end-select-stmt (R811), 178, 178, 179, 193 193 end-select-type-stmt (R824), 182, 183, 183, 184, do-variable (R831), 80, 101, 185, 185, 187, 230, 193 255­257, 280, 504, 506, 508, 548 end-sep-subprogram-stmt (R1238), 15, 330, 330 DOUBLE PRECISION, 48 end-submodule-stmt (R1119), 9, 15, 294, 294 double precision real, 48 end-subroutine-stmt (R1236), 9, 11, 15, 36, 177, dtio-generic-spec (R1208), 69, 75, 236­239, 243, 186, 301, 329, 329, 332 301, 301, 304, 490 end-type-stmt (R434), 56, 57 dtv-type-spec (R920), 237 end-where-stmt (R751), 166, 166 dummy argument, 297, 513 END= sp ecifier, 255 dummy arguments endfile record, 208 restrictions, 319 ENDFILE statement, 208, 246 dummy array, 513 endfile-stmt (R924), 11, 245, 335 dummy data ob ject, 513 ending point, 116 dummy procedure, 298, 513 entity, 513 dummy-arg (R1235), 329, 329, 330, 331 entity-decl (R503), 51, 83, 84, 84, 85, 97, 143, 144, 493 dummy-arg-name (R1228), 103­105, 326, 326, 329, 333, 493 entity-name, 100, 105 dynamic type, 44, 513 ENTRY statement, 330, 330 662 2006/07/11 WORKING DRAFT J3/06-007 entry-name, 326, 330, 331, 489 extended-intrinsic-op (R312), 28, 28 entry-stmt (R1239), 10, 290, 301, 330, 330, 331, extensible type, 73, 513 489, 493 extension operation, 139, 154 enum-def (R463), 10, 78, 79 extension operator, 139 enum-def-stmt (R464), 78, 78 extension type, 73, 513 enumeration, 78 extent, 21, 514 enumerator, 78 EXTERNAL attribute, 92 enumerator (R466), 78, 79, 79 external file, 208, 514 enumerator-def-stmt (R465), 78, 78 external linkage, 514 EOR= sp ecifier, 256 external procedure, 13, 297, 514 equiv-op (R721), 27, 136, 136 EXTERNAL statement, 306 equiv-operand (R716), 136, 136 external subprogram, 12, 514 EQUIVALENCE statement, 108, 108­111 external unit, 214, 514 equivalence-object (R562), 109, 109, 111, 293 external-name, 306 equivalence-set (R561), 109, 109, 110 external-stmt (R1210), 10, 306, 493 equivalence-stmt (R560), 10, 109, 493 external-subprogram (R203), 9, 9, 330 ERR= sp ecifier, 255 errmsg-variable (R629), 124, 124, 125, 128, 129, F 198, 508 field, 262 ERRMSG= sp ecifier, 128 field width, 262 ERROR UNIT, 215, 439 file, 514 evaluation file access, 209 optional, 146 file connection, 214 operations, 145 file connection statements, 207 parentheses, 147 file inquiry, 248 executable construct, 513 file inquiry statement, 207 executable constructs, 175 file position, 211 executable statement, 14, 513 file positioning statements, 207, 245 executable-construct (R213), 10, 11, 14, 331 file storage unit, 213, 514 execution control, 175­195 file-name-expr (R906), 218, 218, 220, 248, 249, execution cycle, 187 251 execution-part (R208), 9, 10, 11, 289, 326, 327, file-unit-number (R902), 214, 214, 215, 217, 329, 330 218, 223­226, 239, 244, 245, 247­249, execution-part-construct (R209), 10, 10, 175, 335, 440 186 FILE= sp ecifier, 220, 249 exist, 209 files EXIST= sp ecifier, 250 connected, 216 exit-stmt (R844), 11, 36, 186, 191, 191 external, 208 expand-stmt (R338), 33, 35, 36 internal, 214 explicit, 299 preconnected, 217 explicit formatting, 259­278 final subroutine, 514 explicit initialization, 85, 101, 513 final subroutines, 71 explicit interface, 299, 513 final-binding (R457), 69, 71 explicit-shape array, 90, 513 final-subroutine-name, 71 explicit-shape-spec (R512), 62, 85, 89, 90, 90, finalizable, 71, 514 91, 92, 111 finalization, 71, 514 exponent (R416), 48, 49 finalized, 71 exponent-letter (R415), 48, 49, 49 fixed source form, 31, 31 expr (R722), 6, 72, 76, 77, 80, 115, 124, 133, FLUSH statement, 247 134, 136, 136, 139, 140, 144, 157­164, flush-spec (R928), 247, 247 168, 171, 181, 230, 310, 333, 334 flush-stmt (R927), 11, 247, 335 expression, 133, 513 FMT= sp ecifier, 226 expressions, 20, 133­155 extended type, 73, 513 FORALL construct, 168 663 J3/06-007 WORKING DRAFT 2006/07/11 foral l-assignment-stmt (R757), 169, 169, 171­ Fortran 90 compatibility, 4 173, 335 Fortran 95 compatibility, 3 foral l-body-construct (R756), 168, 169, 169, 171, Fortran character set, 25 173 free source form, 29, 29 foral l-construct (R752), 11, 168, 169, 170, 172, function, 12, 514 173 function reference, 20, 322 foral l-construct-name, 168, 169 function result, 514 FUNCTION statement, 326 foral l-construct-stmt (R753), 168, 168, 169, 193 function subprogram, 326, 514 foral l-header (R754), 168, 168, 173, 174, 185 function-name, 84, 301, 302, 326, 327, 331, 333, foral l-stmt (R759), 11, 169, 173, 173 489, 493 foral l-triplet-spec (R755), 168, 168, 169, 171, function-reference (R1219), 77, 84, 133, 309, 173 311, 322 FORM= sp ecifier, 220, 251 function-stmt (R1226), 9, 301, 302, 326, 326, format (R914), 224­226, 226, 227, 234, 259, 260 327, 489, 493 format control, 262 function-subprogram (R1225), 9, 10, 290, 326, format descriptors 330 /, 276 :, 276 G A, 272 generic identifier, 304, 514 BN, 277 generic interface, 70, 303, 514 BZ, 277 generic interface block, 302, 514 control edit descriptors, 275 generic name, 304 D, 268 Generic names, 340 data edit descriptors, 264­274 generic procedure references, 489 E, 268 generic-binding (R455), 69, 69, 70, 292 EN, 268 generic-name, 69, 70, 301, 491, 494 ES, 269 generic-spec (R1207), 69, 70, 75, 99, 138, 139, F, 267 162, 291, 292, 300, 301, 301, 304, 491, G, 272, 273 494 I, 265 global entities, 487 L, 272 global entity, 514 P, 277 global identifier, 487 S, 276 GO TO statement, 193 SP, 276 goto-stmt (R851), 11, 36, 186, 193, 193 SS, 276 graphic character, 25 TL, 275 TR, 275 H X, 276 hex-constant (R428), 55, 55 FORMAT statement, 226, 259, 630 hex-digit (R429), 55, 55, 271 format-item (R1003), 259, 260, 260 hex-digit-string (R1021), 271, 271 format-specification (R1002), 259, 259 host, 12, 13, 514 format-stmt (R1001), 10, 259, 259, 290, 294, host association, 493, 514 301 host instance, 164 formatted data transfer, 235 host scoping unit, 12, 514 formatted input/output statement, 226 formatted record, 207 I FORMATTED= sp ecifier, 251 formatting ICHAR intrinsic, 53 explicit, 259­278 ID= sp ecifier, 228, 251 list-directed, 236, 278­282 IEEE , 350, 443­469 namelist, 236, 283­288 IF construct, 176, 176 forms, 208 IF statement, 176, 177 Fortran 2003 compatibility, 3 if-construct (R802), 11, 176, 176 Fortran 77 compatibility, 4 if-construct-name, 176 664 2006/07/11 WORKING DRAFT J3/06-007 if-stmt (R807), 11, 36, 177, 177 INQUIRE statement, 248 if-then-stmt (R803), 176, 176, 193 inquire-spec (R930), 248, 248, 249, 254, 257 imag-part (R419), 49, 50 inquire-stmt (R929), 11, 248, 335 image, 17, 514 inquiry function, 339, 515 image control, 196 inquiry, type parameter, 119 image index, 18, 515 instance, 329 image selector, 123 instance of a subprogram, 515 image-selector (R624), 21, 117, 123, 511 int-constant (R308), 27, 27, 102 image-set (R862), 201, 201, 202, 203 int-constant-name, 47 image-team (R860), 199, 199, 202, 218, 222 int-constant-subobject (R537), 102, 102 IMAGE TEAM, 438 int-expr (R727), 15, 42, 80, 116, 120, 123, 124, imaginary part, 49 140, 140, 142­145, 168, 178, 185, 187, implicit, 299 193, 201, 214, 215, 218, 225, 230, 232, implicit interface, 309, 515 244, 248, 332 IMPLICIT statement, 106, 106 int-initialization-expr (R732), 46, 51, 60, 79, implicit-part (R205), 10, 10 101, 144, 144, 178, 194 implicit-part-stmt (R206), 10, 10 int-literal-constant (R407), 27, 47, 47, 51, 260, implicit-spec (R556), 106, 106 261 implicit-stmt (R555), 10, 106 int-variable (R608), 115, 115, 124, 218, 223, implied-shape array, 92 225, 244, 245, 247­249, 251­256 implied-shape-spec (R518), 89, 92, 92 int-variable-name, 185 import-name, 301 INTEGER, 47 import-name-list, 302 integer constant, 47 import-stmt (R1209), 10, 301 integer editing, 265 inactive, 186 integer model, 342 INCLUDE, 32 integer type, 46, 46 INCLUDE line, 32 INTENT, 341 index-name, 168­174, 187, 188, 491, 492, 505, intent, 515 507 INTENT attribute, 92, 103 inherit, 515 INTENT statement, 103 inheritance associated, 74 intent-spec (R519), 83, 92, 103, 307 inheritance association, 502, 515 intent-stmt (R541), 10, 103 inherited, 73 interface, 299 initial point, 211 (procedure), 299 initial-data-target (R449), 65, 65, 84, 85, 102, explicit, 299 103 generic, 303 initial-proc-target (R1217), 65, 307, 308 implicit, 309 initialization, 65, 84, 85, 503, 610 interface block, 13, 515 initialization (R505), 84, 84, 85 interface body, 13, 515 initialization expression, 143 interface of a procedure, 515 initialization target, 65 interface-block (R1201), 10, 300, 301 initialization-expr (R730), 65, 84, 85, 92, 95, interface-body (R1205), 300, 301, 301, 493 104, 144, 144 interface-name (R1215), 307, 307 inner-shared-do-construct (R841), 186, 186 interface-name, 69, 70 Input statements, 207 interface-specification (R1202), 300, 300 input-item (R915), 224, 225, 230, 230, 243, 257, interface-stmt (R1203), 300, 300, 301, 304, 494 508 internal file, 515 input/output editing, 259­288 internal files, 214 input/output list, 229 internal procedure, 13, 297, 515 input/output statements, 207­257 internal subprogram, 12, 515 INPUT UNIT, 215, 440 internal unit, 214 inquire by file, 248 internal-file-variable (R903), 214, 214, 226, 508 inquire by output list, 248 inquire by unit, 248 internal-subprogram (R211), 10, 10 665 J3/06-007 WORKING DRAFT 2006/07/11 internal-subprogram-part (R210), 9, 10, 289, kind-selector (R405), 7, 46, 46, 60 326, 327, 329, 330, 334 interoperable, 476, 477, 480­482, 483, 515 L intrinsic, 23, 516 label, 516 elemental, 339 label (R313), 28, 28, 185, 193, 218, 223­226, 244, inquiry function, 339 245, 247­249, 255, 256, 310 transformational, 339 label-do-stmt (R828), 185, 185, 186 intrinsic assignment statement, 157 language-binding-spec (R508), 83, 87, 100, 326 INTRINSIC attribute, 94 lbracket (R470), 36, 61, 62, 80, 80, 84, 89, 100, intrinsic binary operation, 137 103, 105, 123, 124 intrinsic module, 290 left tab limit, 275 intrinsic operation, 137 length, 50 intrinsic operations, 150­153 length of a character string, 516 logical, 54 length type parameter, 42 intrinsic procedure, 297 length-selector (R421), 7, 51, 51 intrinsic procedures, 350, 437 letter, 25, 25, 27, 28, 106, 134, 136 INTRINSIC statement, 309 letter-spec (R557), 106, 106 intrinsic type, 18 letters, 25 intrinsic types, 46­54 level-1-expr (R702), 134, 134, 155 intrinsic unary operation, 137 level-2-expr (R706), 134, 134, 135, 155 intrinsic-operator (R310), 27, 28, 134, 136­139, level-3-expr (R710), 135, 135 304 level-4-expr (R712), 135, 135, 136 intrinsic-procedure-name, 309, 494 level-5-expr (R717), 136, 136 intrinsic-stmt (R1218), 10, 309, 494 lexical token, 516 intrinsic-type-spec (R404), 43, 44, 46, 51 Lexical tokens, 26 invoke, 516 line, 29, 516 io-control-spec (R913), 224, 225, 225, 226, 239, linkage association, 516 257, 258 list-directed formatting, 236, 278­282 io-implied-do (R917), 230, 230, 231, 232, 235, list-directed input/output statement, 227 257, 258, 504, 506, 508, 548 literal constant, 20, 116, 516 io-implied-do-control (R919), 230, 230, 232 literal-constant (R306), 27, 27 io-implied-do-object (R918), 230, 230 local entity, 516 io-unit (R901), 214, 214, 225, 226, 335 local identifier, 487 iomsg-variable (R907), 218, 218, 223, 225, 244, local identifiers, 488 245, 247, 248, 255­257, 505 local variable, 19, 516 IOMSG= sp ecifier, 257 local-defined-operator (R1114), 291, 292, 292 IOSTAT= sp ecifier, 256 local-name, 291­293 ISO 10646, 424 LOGICAL, 54 ISO 10646 character set, 50 logical intrinsic assignment statement, 158 ISO 10646 character type, 50 logical intrinsic operation, 138 ISO C BINDING module, 471 logical intrinsic operations, 54, 153 ISO FORTRAN ENV module, 214, 215, 437 logical intrinsic operator, 138 iteration, 188 iteration count, 37, 187 logical type, 54, 54 logical-expr (R724), 139, 139, 144, 166, 176­178, K 185, 187, 188 logical-initialization-expr (R733), 144, 144, 178 k (R1013), 261, 261, 268, 273, 277 logical-literal-constant (R424), 27, 54, 134, 136 keyword, 22, 311, 516 logical-variable (R604), 115, 115, 203 keyword (R215), 22, 23, 75, 76, 310 loop, 185 kind, 47, 49, 50, 54 loop-control (R830), 185, 185, 186, 187, 190 KIND intrinsic, 47­50, 54 low-level syntax, 26 kind type parameter, 18, 42, 47, 49, 50, 54, 516 lower-bound (R513), 90, 90, 91, 92 kind-param (R408), 47, 47, 48, 49, 51, 52, 54, 55 lower-bound-expr (R634), 124, 124, 127, 163 666 2006/07/11 WORKING DRAFT J3/06-007 M module-subprogram-part (R1107), 9, 70, 74, 290, 290, 294, 563 m (R1008), 260, 261, 261, 266, 271, 272 mult-op (R708), 27, 134, 134 macro-actual-arg (R339), 35, 36, 36 mult-operand (R704), 134, 134, 155 macro-actual-arg-value (R340), 36, 36 macro-attribute (R316), 33, 33 N macro-body-block (R321), 33, 33, 34 macro-body-construct (R322), 33, 33, 34 n (R1015), 261, 261 macro-body-stmt (R333), 34, 34, 35 name, 22, 517 macro-condition (R332), 34, 34 name (R304), 6, 23, 27, 27, 84, 105, 115, 183, macro-declaration-stmt (R317), 33, 33 234, 307, 326 macro-definition (R314), 10, 33, 33, 34 name association, 492, 517 macro-do-construct (R323), 34, 34 name-value subsequences, 283 macro-do-limit (R325), 34, 34 NAME= sp ecifier, 251 macro-do-stmt (R324), 34, 34, 37 named, 517 macro-do-variable-name, 34, 37 named common block, 111 macro-dummy-arg-name, 33 named constant, 20, 95, 104, 116, 517 macro-dummy-arg-name-list, 33 named file, 208 macro-dummy-name, 36 named-constant (R307), 27, 27, 32, 50, 79, 104, macro-else-if-stmt (R329), 34, 34 493 macro-else-stmt (R330), 34, 34 named-constant-def (R544), 104, 104, 493 macro-end-do-stmt (R326), 34, 34 NAMED= sp ecifier, 251 macro-end-if-stmt (R331), 34, 34 namelist formatting, 236, 283­288 macro-expr (R337), 33­35, 35, 37 namelist input/output statement, 227 macro-if-construct (R327), 34, 34 NAMELIST statement, 108, 108 macro-if-then-stmt (R328), 34, 34 namelist-group-name, 108, 225­227, 233­235, macro-local-variable-name, 33 259, 283, 288, 293, 494, 508 macro-local-variable-name-list, 33 namelist-group-object (R559), 108, 108, 234, macro-name, 33, 35 236, 243, 257, 283, 284, 293 macro-optional-decl-stmt (R319), 33 namelist-stmt (R558), 10, 108, 494, 508 macro-type-declaration-stmt (R318), 33, 33 Names, 27 macro-type-spec (R320), 33, 33, 36 NaN, 350, 448, 517 main program, 12, 289, 516 nested-token-sequence (R343), 36, 36 main-program (R1101), 9, 289, 289 next record, 211 many-one array section, 122, 516 NEXTREC= sp ecifier, 251 mask-expr (R748), 166, 166, 167­173 NML= sp ecifier, 227 masked array assignment, 166 nonadvancing input/output statement, 212 masked array assignment (WHERE), 166 nonblock-do-construct (R835), 185, 186 masked-elsewhere-stmt (R749), 166, 166, 167, NONE (DELIM value), 287 172 nonexecutable statement, 517 model Nonexecutable statements, 14 bit, 341 nonintrinsic module, 290 integer, 342 nonlabel-do-stmt (R829), 185, 185 real, 342 normal, 448 module, 13, 290, 516 not-op (R718), 27, 136, 136 module (R1104), 9, 290 notify-stmt (R863), 11, 202 module procedure, 13, 298, 516 nul l-init (R506), 65, 84, 84, 85, 102, 103, 307, module procedure interface, 302, 517 308 module procedure interface body, 302 NULLIFY statement, 128 module reference, 23, 291 nul lify-stmt (R638), 11, 128, 508 module subprogram, 12, 517 NUMBER= sp ecifier, 252 module-name, 290­292, 493 numeric conversion, 160 module-nature (R1110), 291, 291, 292 numeric editing, 265 module-stmt (R1105), 9, 290, 290 numeric intrinsic assignment statement, 158 module-subprogram (R1108), 10, 290, 290, 330 numeric intrinsic operation, 137 667 J3/06-007 WORKING DRAFT 2006/07/11 numeric intrinsic operations, 150 parent data transfer statement, 237, 236­241, 257 numeric intrinsic operator, 137 numeric relational intrinsic operation, 138 parent type, 73, 517 numeric sequence type, 58, 109, 501, 616 parent-identifier (R1118), 293, 294, 294 numeric storage unit, 499, 517 parent-string (R610), 88, 116, 116 numeric type, 517 parent-submodule-name, 294 numeric types, 46 parent-type-name, 56, 57 numeric-expr (R728), 48, 140, 140, 193 parentheses, 147 part-name, 117, 118, 120 O part-ref (R613), 88, 101, 109, 117, 117, 118, 120, 121, 317 ob ject, see data ob ject, 19, 517 partially [storage] associated, 501 ob ject designator, 22, 517 PASS attribute, 311 object-name (R504), 84, 84, 100, 101, 104, 105, passed-ob ject dummy argument, 64, 518 115, 493 PENDING= sp ecifier, 252 obsolescent feature, 517 pointer, 22, 518 obsolescent features, 7 pointer assignment, 162, 518 octal-constant (R427), 55, 55 pointer assignment statement, 518 only (R1112), 291, 291, 292 pointer associated, 518 only-use-name (R1113), 291, 291, 292 pointer association, 496, 518 OPEN statement, 217, 217 pointer association context, 508 open-stmt (R904), 11, 217, 335 pointer association status, 496 OPENED= sp ecifier, 252 POINTER attribute, 95, 104 operand, 517 POINTER statement, 104 operands, 24 pointer-assignment-stmt (R735), 11, 96, 162, operation, 517 169, 171, 334, 508 operations, 41 pointer-decl (R546), 104, 104 character intrinsic, 151 pointer-object (R639), 128, 128, 508 logical intrinsic, 153 pointer-stmt (R545), 10, 104, 493 numeric intrinsic, 150 polymorphic, 44, 518 relational intrinsic, 152 POS= sp ecifier, 229, 252 operator, 24, 517 position, 209 operator precedence, 154 position-edit-desc (R1014), 261, 261 operators, 27 OPTIONAL attribute, 94, 104 position-spec (R926), 245, 245 optional dummy argument, 319 POSITION= sp ecifier, 220, 253 OPTIONAL statement, 104 positional arguments, 340 optional-stmt (R542), 10, 104 power-op (R707), 27, 134, 134 or-op (R720), 27, 136, 136 pre-existing, 502 or-operand (R715), 136, 136 precedence of operators, 154 outer-shared-do-construct (R839), 186, 186 preceding record, 211 Output statements, 207 preconnected, 518 output-item (R916), 224, 225, 230, 230, 243, 248 preconnected files, 217 OUTPUT UNIT, 215, 440 Preconnection, 217 override, 74, 517 prefix (R1229), 326, 326, 327, 329 overrides, 65 prefix-spec (R1230), 326, 326, 327­329, 333, 335 present, 319 P present (dummy argument), 319 PRESENT intrinsic, 94 PAD= sp ecifier, 220, 228, 252 primaries, 333 PARAMETER, 20 primary, 133 PARAMETER attribute, 95, 104 primary (R701), 133, 133, 134 PARAMETER statement, 104, 104 PRINT statement, 224 parameter-stmt (R543), 10, 104, 493 print-stmt (R912), 11, 224, 335 parent, 293 parent component, 74, 517 PRIVATE attribute, 57, 86 668 2006/07/11 WORKING DRAFT J3/06-007 PRIVATE statement, 100 PROTECTED statement, 105, 105 protected-stmt (R547), 10, 105 private-components-stmt (R450), 57, 67, 67, 68 prototype, 518 private-or-sequence (R433), 56, 57, 57 PUBLIC attribute, 57, 86 proc-attr-spec (R1213), 306, 307, 307 PUBLIC statement, 100 proc-binding-stmt (R453), 68, 69, 70 pure procedure, 333, 518 proc-component-attr-spec (R447), 62, 62, 63 proc-component-def-stmt (R446), 61, 62, 63 Q proc-component-ref (R741), 163, 163, 164, 309, 310 query-spec (R865), 202, 202, 203 proc-decl (R1214), 62, 65, 306, 307, 307, 308 query-stmt (R864), 11, 202 proc-entity-name, 104, 308 QUOTE (DELIM value), 287 proc-interface (R1212), 62, 306, 307, 307 R proc-language-binding-spec (R1227), 86, 307, 326, 326, 327, 329, 332, 482 r (R1005), 260, 260, 261, 262 proc-pointer-init (R1216), 307, 307 range, 186 proc-pointer-name (R550), 105, 105, 111, 112, RANGE intrinsic, 47 128, 163, 493 rank, 20, 21, 518 proc-pointer-object (R740), 162, 163, 164, 165, rbracket (R471), 36, 61, 62, 80, 80, 84, 89, 100, 171, 172, 356, 508 103, 105, 123, 124 proc-target (R742), 76, 77, 96, 162, 163, 164, READ statement, 224 165, 171, 319, 356, 499 read-stmt (R910), 11, 224, 225, 335, 508 procedure, 12, 518 READ= sp ecifier, 253 characteristics of, 298 reading, 207 dummy, 298 READWRITE= sp ecifier, 253 elemental, 335 REAL, 48 external, 297 real and complex editing, 266 internal, 297 real model, 342 intrinsic, 339­437 real part, 49 non-Fortran, 332 real type, 47, 47­49 pure, 333 real-literal-constant (R413), 27, 48, 48 procedure designator, 22, 518 real-part (R418), 49, 49 procedure interface, 299, 518 REC= sp ecifier, 229 procedure pointer, 22, 306 RECL= sp ecifier, 221, 253 procedure reference, 23, 309 record, 207, 518 procedure references record file, 207 generic, 489 record lengths, 208 resolving, 323 record number, 210 procedure-component-name, 163 RECURSIVE, 329 procedure-declaration-stmt (R1211), 10, 306, recursive input/output statement, 257 307, 308, 493 reference, 518 procedure-designator (R1221), 309, 309, 325 rel-op (R713), 27, 135, 135, 152 procedure-entity-name, 307 relational intrinsic operation, 138 procedure-name, 69, 70, 164, 165, 301, 307, 309, relational intrinsic operations, 152 310, 330 relational intrinsic operator, 138 procedure-stmt (R1206), 300, 301, 301 rename (R1111), 291, 291, 292, 488 processor, 1, 518 rep-char, 52, 52, 262, 279, 285 processor dependent, 3, 518 repeat specification., 260 program, 12, 518 representable character, 52 program (R201), 9, 9 representation method, 47 program unit, 12, 518 representation methods, 46, 50, 54 program-name, 289 resolving procedure references, 323 program-stmt (R1102), 9, 289, 289 derived-type input/output, 243 program-unit (R202), 6, 9, 9 restricted expression, 142 PROTECTED attribute, 96, 105 result variable, 12, 519 669 J3/06-007 WORKING DRAFT 2006/07/11 result-name, 326, 327, 331, 493 SIGN= sp ecifier, 221, 229, 254 result-token (R334), 34, 34 signed-digit-string (R409), 47, 49, 266, 267 RETURN statement, 332 signed-int-literal-constant (R406), 47, 47, 49, return-stmt (R1240), 11, 15, 36, 186, 332, 332 50, 102, 261 REWIND statement, 246 signed-real-literal-constant (R412), 48, 50, 102 rewind-stmt (R925), 11, 245, 335 significand (R414), 48, 49 round-edit-desc (R1018), 261, 262 size, 21, 519 ROUND= sp ecifier, 221, 229, 253 size of a common block, 112 rounding mode, 519 size of a storage sequence, 499 SIZE= sp ecifier, 229, 254 S source forms, 29 source-expr (R630), 124, 124, 125, 126 satisfied, 203 special characters, 26 SAVE attribute, 101, 105 special-character, 25, 26 SAVE statement, 105 specific interface, 301 save-stmt (R548), 10, 105, 493 specific interface block, 302 saved, 98 Specific names, 340 saved-entity (R549), 105, 105 specific-binding (R454), 69, 69 scalar, 20, 116, 519 specification expression, 142, 519 scalar-xyz (R103), 6, 6 specification function, 143, 519 scale factor, 261 specification inquiry, 142 scope, 487, 519 specification-expr (R729), 43, 51, 84, 90, 142, scoping unit, 12, 519 142, 336 section subscript, 519 specification-part (R204), 9, 10, 69, 86, 99, 100, section-subscript (R620), 117, 120, 120, 121 143, 144, 191, 289, 290, 294, 301, 326, segment, 196 329, 330, 334 SELECT CASE statement, 178 specification-stmt (R212), 10, 10 SELECT TYPE construct, 182 specifications, 83­114 SELECT TYPE construct, 492, 496 standard-conforming program, 2, 519 select-case-stmt (R809), 178, 178, 193 starting point, 116 select-construct-name, 182, 183 stat-variable (R628), 124, 124, 125, 126, 129, select-type-construct (R821), 11, 182, 182, 183 198, 508 select-type-stmt (R822), 182, 182, 183, 193 statement, 29, 519 SELECTED INT KIND intrinsic, 47 statement entity, 487, 519 selector, 519 statement function, 298, 333, 519 selector (R819), 180, 181, 181, 182­184, 319, Statement functions, 524 496, 508 statement label, 28, 28, 519 separate module procedure, 330 statement order, 14 separate-module-subprogram (R1237), 10, 290, statements 330, 330 accessibility, 99 sequence, 24 ALLOCATABLE, 100 sequence association, 318 ALLOCATE, 124 SEQUENCE property, 59 arithmetic IF, 193 SEQUENCE statement, 58 assignment, 156 sequence structure, 56 ASSOCIATE, 180 sequence type, 58 ASYNCHRONOUS, 100 sequence-stmt (R435), 57, 58 attribute specification, 99­114 sequential access, 209 BACKSPACE, 246 sequential access input/output statement, 229 BIND, 100 SEQUENTIAL= sp ecifier, 253 CALL, 309 shape, 21, 519 CASE, 178 shape conformance, 141 CLASS IS, 182 shared-term-do-construct (R840), 186, 186 CLOSE, 223 sign (R411), 47, 47, 48, 267 sign-edit-desc (R1016), 261, 261 COMMON, 111­114 670 2006/07/11 WORKING DRAFT J3/06-007 computed GO TO, 193 WHERE, 166 CONTAINS, 332 WRITE, 224 CONTINUE, 194 STATUS= sp ecifier, 221, 224 CYCLE, 188 stmt-function-stmt (R1242), 10, 290, 294, 301, 333, 493 DATA, 101 STOP statement, 194 data transfer, 224 stop-code (R856), 194, 194, 195, 196 DEALLOCATE, 128 stop-stmt (R855), 11, 36, 186, 194, 335 DIMENSION, 103 DO, 185 storage associated, 500 DO WHILE, 185 Storage association, 499 END, 15 storage association, 108­114, 499, 520 ENDFILE, 246 storage sequence, 112, 499, 520 ENTRY, 330 storage unit, 499, 520 EQUIVALENCE, 108­111 stream access, 210 EXTERNAL, 306 stream access input/output statement, 229 file positioning, 245 stream file, 207 FLUSH, 247 STREAM= sp ecifier, 254 FORALL, 168, 173 stride, 122, 520 FORMAT, 259 stride (R622), 120, 120, 168, 169, 171, 173, 232 formatted input/output, 226 string, see character string FUNCTION, 326 struct, 520 GO TO, 193 structure, 19, 56, 520 IF, 177 structure component, 117, 520 IMPLICIT, 106 structure constructor, 76, 520 input/output, 207­257 structure-component (R614), 101, 115, 116, 118, INQUIRE, 248 124, 128 INTENT, 103 structure-constructor (R460), 76, 77, 102, 133, INTRINSIC, 309 334 list-directed input/output, 227 subcomponent, 118, 520 NAMELIST, 108 submodule, 13, 293, 520 namelist input/output, 227 submodule (R1116), 9, 294 NULLIFY, 128 submodule identifier, 293 OPEN, 217 submodule-name, 294 OPTIONAL, 104 submodule-stmt (R1117), 9, 293, 294, 294 PARAMETER, 104 subob ject, 520 POINTER, 104 subob jects, 19 PRINT, 224 subprogram, 520 PRIVATE, 100 subroutine, 12, 520 PROTECTED, 105 subroutine reference, 322 PUBLIC, 100 subroutine subprogram, 329, 520 READ, 224 subroutine-name, 301, 302, 329, 489 RETURN, 332 subroutine-stmt (R1234), 9, 301, 302, 326, 329, REWIND, 246 329, 489, 493 SAVE, 105 subroutine-subprogram (R1233), 9, 10, 290, 329, SELECT CASE, 178 330 SELECT TYPE, 182 subscript, 520 STOP, 194 subscript (R619), 7, 101, 120, 120, 168, 169, TARGET, 105 173, 232 TYPE, 56 subscript triplet, 122, 520 type declaration, 83­99 subscript-triplet (R621), 120, 120, 121 TYPE IS, 182 substring, 116, 520 unformatted input/output, 226 substring (R609), 109, 115, 116 VALUE, 105 substring-range (R611), 88, 116, 116, 118, 120, VOLATILE, 105 232 671 J3/06-007 WORKING DRAFT 2006/07/11 suffix (R1231), 326, 327, 330 TYPE, 44 TYPE type specifier, 44 sync-al l-stmt (R857), 11, 198 type-attr-spec (R432), 56, 56, 57 sync-images-stmt (R861), 11, 201 type-bound procedure, 70, 521 sync-memory-stmt (R866), 11, 204 type-bound-procedure-part (R451), 56, 58, 68, sync-stat (R858), 198, 198, 199, 201­204 71, 480 sync-team-stmt (R859), 11, 199 type-declaration-stmt (R501), 10, 51, 83, 83, T 334, 493 type-guard-stmt (R823), 182, 182, 183 target, 22, 520 type-name, 56, 57, 60, 69, 75, 521 TARGET attribute, 98, 105 type-param-attr-spec (R438), 60, 60 TARGET statement, 105 type-param-decl (R437), 60, 60 target-decl (R552), 105, 105 type-param-def-stmt (R436), 56, 60, 60 target-stmt (R551), 10, 105, 493 type-param-inquiry (R616), 119, 119, 133, 491 team, 18, 520 type-param-name, 56, 60, 62, 119, 133, 134, 491, team synchronization, 199, 520 493 terminal point, 211 type-param-spec (R459), 75, 75, 76 TKR compatible, 45 type-param-value (R401), 42, 42, 43, 51, 62, 75, token (R335), 34, 35 76, 124, 126 totally [storage] associated, 501 type-spec (R402), 43, 43, 44, 51, 52, 80, 81, 124­ transfer of control, 176, 193, 255, 256 126, 182 transformational function, 520 transformational functions, 339 U type, 18, 41­81, 520 ultimate component, 521 base, 73 ultimate components, 56 character, 50­54 unallocated, 127 complex, 49 undefined, 23, 521 concept, 41 undefinition of variables, 503 declared, 44 underscore (R303), 25, 26 derived types, 78 unformatted data transfer, 235 dynamic, 44 unformatted input/output statement, 226 expression, 139 unformatted record, 208 extended, 73 UNFORMATTED= sp ecifier, 254 extensible, 73 Unicode, 219 extension, 73 unit, 214 integer, 46 unlimited polymorphic, 44 intrinsic types, 46­54 unlimited-format-item (R1004), 259, 260, 263 logical, 54 unordered, 197 operation, 140 unsaved, 98 parent, 73 unsigned, 521 primary, 140 unspecified storage unit, 499, 521 real, 47­49 upper-bound (R514), 90, 90 type compatible, 44, 521 upper-bound-expr (R635), 124, 124, 127, 163 type conformance, 158 use associated, 291 type declaration statement, 521 Use association, 493 type declaration statements, 83­99 use association, 493, 521 type equality, 58 USE statement, 291 type incompatible, 44 use-defined-operator (R1115), 291, 292, 292 type parameter, 18, 42, 47, 521 use-name, 99, 100, 291, 292, 488 type parameter inquiry, 119 use-stmt (R1109), 10, 291, 292, 493 type parameter keyword, 22 Type parameter order, 61 V type parameter order, 521 type specifier, 43 v (R1011), 240, 261, 261, 274 derived type, 44 value, 171 672 2006/07/11 WORKING DRAFT J3/06-007 VALUE attribute, 99, 105 ZZZUTI15, 45 value separator, 278 ZZZUTI16, 45 VALUE statement, 105 ZZZUTI17, 45 value-stmt (R553), 11, 105 ZZZUTI18, 45 variable, 521 ZZZUTI19, 46 variable (R601), 77, 101, 115, 115, 157­160, 163, ZZZUTI2, 18 168, 169, 171, 172, 181­183, 230, 310, ZZZUTI20, 117 508 ZZZUTI21, 123 variable-name (R602), 108, 109, 111, 112, 115, ZZZUTI22, 125 115, 116, 124, 128, 163, 493, 508 ZZZUTI23, 157 variables, 19 ZZZUTI24, 157 definition & undefinition, 503 ZZZUTI25, 188 vector subscript, 122, 521 ZZZUTI26, 194 vector-subscript (R623), 120, 120, 121 ZZZUTI27, 194 void, 521 ZZZUTI28, 194 VOLATILE attribute, 99, 105 ZZZUTI29, 195 VOLATILE statement, 105 ZZZUTI3, 16 volatile-stmt (R554), 11, 105 ZZZUTI30, 195 ZZZUTI31, 195 W ZZZUTI32, 195 ZZZUTI33, 196 w (R1007), 260, 261, 261, 265­269, 271­274, 279, 281, 282, 285, 287 ZZZUTI34, 197 wait operation, 223, 232, 244 ZZZUTI35, 200 WAIT statement, 244 ZZZUTI36, 201 wait-spec (R922), 244, 244 ZZZUTI37, 204 wait-stmt (R921), 11, 244, 335 ZZZUTI38, 206 WHERE construct, 166 ZZZUTI39, 216 WHERE statement, 166 ZZZUTI4, 16 where-assignment-stmt (R747), 166, 166, 168, ZZZUTI40, 222 172, 512 ZZZUTI41, 222 where-body-construct (R746), 166, 166, 167, 168 ZZZUTI42, 223 where-construct (R744), 11, 166, 166, 169, 172 ZZZUTI43, 223 where-construct-name, 166 ZZZUTI44, 251 where-construct-stmt (R745), 166, 166, 167, ZZZUTI45, 266 172, 193 ZZZUTI46, 266 where-stmt (R743), 11, 166, 166, 169, 172 ZZZUTI47, 266 whole array, 119, 521 ZZZUTI48, 282 WRITE statement, 224 ZZZUTI49, 300 write-stmt (R911), 11, 224, 225, 335, 508 ZZZUTI5, 17 WRITE= sp ecifier, 254 ZZZUTI50, 313 writing, 207 ZZZUTI5003, 517 ZZZUTI51, 313 X ZZZUTI52, 314 xyz-list (R101), 6 ZZZUTI53, 314 xyz-name (R102), 6 ZZZUTI54, 317 ZZZUTI55, 316 Z ZZZUTI56, 339 ZZZUTI57, 339 zero-size array, 21, 90, 102 ZZZUTI58, 340 ZZZUTI1, 17 ZZZUTI59, 348 ZZZUTI10, 98 ZZZUTI6, 17 ZZZUTI11, 88 ZZZUTI60, 361 ZZZUTI12, 89 ZZZUTI61, 361 ZZZUTI13, 89 ZZZUTI14, 44 ZZZUTI62, 359 673 J3/06-007 WORKING DRAFT 2006/07/11 ZZZUTI63, 382 ZZZUTI64, 376 ZZZUTI65, 395 ZZZUTI66, 400 ZZZUTI67, 405 ZZZUTI68, 405 ZZZUTI69, 414 ZZZUTI7, 21 ZZZUTI70, 418 ZZZUTI71, 427 ZZZUTI72, 427 ZZZUTI73, 439 ZZZUTI74, 472 ZZZUTI75, 497 ZZZUTI76, 497 ZZZUTI77, 500 ZZZUTI78, 515 ZZZUTI79, 317 ZZZUTI8, 97 ZZZUTI9, 97 674 2006/07/11 WORKING DRAFT J3/06-007 Index 675