---

Manual Reference Pages  - untitled ()

---

                                                 PDF disclaimer

printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed

on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not

infringing Adobe’s licensing policy. The ISO Central Secretariat accepts no liability in this area.

Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create this PDF file can be found in the General Info relative to the file;

the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is

suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform

the Central Secretariat at the address given below.

This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted

under the applicable laws of the user’s country, neither this ISO draft nor any extract from it may be reproduced,

stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or

otherwise, without prior written permission being secured.

Requests for permission to reproduce should be addressed to either ISO at the address below or ISO’s member

body in the country of the requester.

      ISO copyright office

      Case postale 56 • CH-1211 Geneva 20

      Tel. + 41 22 749 01 11

      Fax + 41 22 734 10 79

      E-mail copyright@iso.ch

      Web www.iso.ch

Violators may be prosecuted.

                                                                                  ISO/IEC DIS 1539-1:2017 (E)

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xviii

1	Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2	Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3	Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4	Notation, conformance, and compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Notation, symbols and abbreviated terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1 Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.3 Assumed syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.4 Syntax conventions and characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.5 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.1 Previous Fortran standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.2 New intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.3 Fortran 2008 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.4 Fortran 2003 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3.5 Fortran 95 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3.6 Fortran 90 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3.7 FORTRAN 77 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4 Deleted and obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.2 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.3 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5	Fortran concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.1 Program units and scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.5 Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.1 Statement classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.2 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.3 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.4 Program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.5 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.3.6 Image execution states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
⃝c ISO/IEC 2017 – All rights reserved
	iii

         5.3.7     Termination of execution . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

         5.4.1     Type . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

         5.4.2     Data value . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

         5.4.3     Data entity . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

         5.4.4     Definition of objects and pointers     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

         5.4.5     Reference . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

         5.4.6     Array . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

         5.4.7     Coarray . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

         5.4.8     Established coarrays . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

         5.4.9     Pointer . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

         5.4.10 Allocatable variables . . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

         5.4.11 Storage . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

         5.5.1     Names and designators . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

         5.5.2     Statement keyword . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

         5.5.3     Other keywords . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

         5.5.4     Association . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

         5.5.5     Intrinsic . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

         5.5.6     Operator . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

         5.5.7     Companion processors . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

   6.1   Processor character set . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.1     Characters . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.2     Letters . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.3     Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.4     Underscore . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.5     Special characters . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

         6.1.6     Other characters . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

   6.2   Low-level syntax . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

         6.2.1     Tokens . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

         6.2.2     Names . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

         6.2.3     Constants . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

         6.2.4     Operators . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

         6.2.5     Statement labels . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

         6.2.6     Delimiters . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

   6.3   Source form . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

         6.3.1     Program units, statements,     and lines   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

         6.3.2     Free source form . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

         6.3.3     Fixed source form . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

   6.4   Including source text . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

   7.1   Characteristics of types . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . 57

         7.1.1     The concept of type . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . 57

         7.1.2     Type classification . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . 57

         7.1.3     Set of values . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . 57

         7.1.4     Constants . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . 57

         7.1.5     Operations . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . 57

   7.2   Type parameters . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . 58

   7.3   Types, type specifiers, and values . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . 58

         7.3.1     Relationship of types and values to objects      . . . . . . . . . . . . . . . . . . . . . . . . . . 58

         7.3.2     Type specifiers and type compatibility . .       . . . . . . . . . . . . . . . . . . . . . . . . . . 59

   7.4   Intrinsic types . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . 61

         7.4.1     Classification and specification . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . 61

                                                                                  ISO/IEC DIS 1539-1:2017 (E)

          7.5.1     Derived type concepts . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . .  68

          7.5.2     Derived-type definition . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . .  69

          7.5.3     Derived-type parameters . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . .  73

          7.5.4     Components . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . .  74

          7.5.5     Type-bound procedures . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . .  81

          7.5.6     Final subroutines . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . .  83

          7.5.7     Type extension . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . .  85

          7.5.8     Derived-type values . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . .  87

          7.5.9     Derived-type specifier . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . .  87

          7.5.10 Construction of derived-type values . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . .  88

          7.5.11 Derived-type operations and assignment            . . . . . . . . . . . . . . . . . . . . . . . . . . .  90

   8.1    Attributes of procedures and data objects        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  95

   8.2    Type declaration statement . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  95

   8.3    Automatic data objects . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  97

   8.4    Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  97

   8.5    Attributes . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  97

          8.5.1     Attribute specification . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  97

          8.5.2     Accessibility attribute . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  98

          8.5.3     ALLOCATABLE attribute . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  98

          8.5.4     ASYNCHRONOUS attribute . .             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  98

          8.5.5     BIND attribute for data entities .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  99

          8.5.6     CODIMENSION attribute . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  99

          8.5.7     CONTIGUOUS attribute . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

          8.5.8     DIMENSION attribute . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

          8.5.9     EXTERNAL attribute . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

          8.5.10 INTENT attribute . . . . . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

          8.5.11 INTRINSIC attribute . . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

          8.5.12 OPTIONAL attribute . . . . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

          8.5.13 PARAMETER attribute . . . . .             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

          8.5.14 POINTER attribute . . . . . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

          8.5.15 PROTECTED attribute . . . . .             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

          8.5.16 SAVE attribute . . . . . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

          8.5.17 TARGET attribute . . . . . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

          8.5.18 VALUE attribute . . . . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

          8.5.19 VOLATILE attribute . . . . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

   8.6    Attribute specification statements . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

          8.6.1     Accessibility statement . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

          8.6.2     ALLOCATABLE statement . . .            . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

          8.6.3     ASYNCHRONOUS statement . .             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

          8.6.4     BIND statement . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

          8.6.5     CODIMENSION statement . . .            . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

          8.6.6     CONTIGUOUS statement . . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

          8.6.7     DATA statement . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

          8.6.8     DIMENSION statement . . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

          8.6.9     INTENT statement . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

          8.6.10 OPTIONAL statement . . . . . .            . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

         8.6.11 PARAMETER statement . .            . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

         8.6.12 POINTER statement . . . .          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

         8.6.13 PROTECTED statement . .            . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

         8.6.14 SAVE statement . . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

         8.6.15 TARGET statement . . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

         8.6.16 VALUE statement . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

         8.6.17 VOLATILE statement . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

         8.10.1 EQUIVALENCE statement              . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

         8.10.2 COMMON statement . . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

         8.10.3 Restrictions on common and         equivalence   . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

   9.1   Designator . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

   9.2   Variable . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

   9.3   Constants . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

   9.4   Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

         9.4.1    Substrings . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

         9.4.2    Structure components . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

         9.4.3    Coindexed named objects . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

         9.4.4    Complex parts . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

         9.4.5    Type parameter inquiry . . . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

   9.5   Arrays . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

         9.5.1    Order of reference . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

         9.5.2    Whole arrays . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

         9.5.3    Array elements and array sections .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

         9.5.4    Simply contiguous array designators      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

   9.6   Image selectors . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

   9.7   Dynamic association . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

         9.7.1    ALLOCATE statement . . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

         9.7.2    NULLIFY statement . . . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

         9.7.3    DEALLOCATE statement . . . . .           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

         9.7.4    STAT= specifier . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

         9.7.5    ERRMSG= specifier . . . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

   10.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . 147

         10.1.1 Expression semantics . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . 147

         10.1.2 Form of an expression . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . 147

         10.1.3 Precedence of operators . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . 151

         10.1.4 Evaluation of operations . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . 153

         10.1.5 Intrinsic operations . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . 153

         10.1.6 Defined operations . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . 160

         10.1.7 Evaluation of operands . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . 161

         10.1.8 Integrity of parentheses . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . 162

         10.1.9 Type, type parameters, and shape of an expression            . . . . . . . . . . . . . . . . . . . . . 162

         10.1.10 Conformability rules for elemental operations . . .         . . . . . . . . . . . . . . . . . . . . . 163

         10.1.11 Specification expression . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . 164

         10.1.12 Constant expression . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . 165

   10.2 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . . 167

         10.2.1 Assignment statement . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . . . . . . . . 167

         10.2.2 Pointer assignment . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . . 171

         10.2.3 Masked array assignment – WHERE . . . . . . . .              . . . . . . . . . . . . . . . . . . . . . 175

                                                                                ISO/IEC DIS 1539-1:2017 (E)

   11.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . 181

        11.1.1 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . 181

        11.1.2 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . 181

        11.1.3 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . .           . . . . . . . . . . . . . . 182

        11.1.4 BLOCK construct . . . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . 183

        11.1.5 CHANGE TEAM construct . . . . . . . . . . . . . . . . . . . .               . . . . . . . . . . . . . . 185

        11.1.6 CRITICAL construct . . . . . . . . . . . . . . . . . . . . . . . .          . . . . . . . . . . . . . . 187

        11.1.7 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . 188

        11.1.8 IF construct and statement . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . 195

        11.1.9 SELECT CASE construct . . . . . . . . . . . . . . . . . . . . .             . . . . . . . . . . . . . . 196

        11.1.10 SELECT RANK construct . . . . . . . . . . . . . . . . . . . . .            . . . . . . . . . . . . . . 199

        11.1.11 SELECT TYPE construct . . . . . . . . . . . . . . . . . . . . .            . . . . . . . . . . . . . . 201

        11.1.12 EXIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . 204

   11.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . 204

        11.2.1 Branch concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . 204

        11.2.2 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . 204

        11.2.3 Computed GO TO statement . . . . . . . . . . . . . . . . . . .              . . . . . . . . . . . . . . 205

   11.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . 205

   11.4 STOP and ERROR STOP statements . . . . . . . . . . . . . . . . . . .               . . . . . . . . . . . . . . 205

   11.5 FAIL IMAGE statement . . . . . . . . . . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . 206

   11.6 Image execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . 206

        11.6.1 Image control statements . . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . 206

        11.6.2 Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . 207

        11.6.3 SYNC ALL statement . . . . . . . . . . . . . . . . . . . . . . .            . . . . . . . . . . . . . . 208

        11.6.4 SYNC IMAGES statement . . . . . . . . . . . . . . . . . . . . .             . . . . . . . . . . . . . . 209

        11.6.5 SYNC MEMORY statement . . . . . . . . . . . . . . . . . . . .               . . . . . . . . . . . . . . 210

        11.6.6 SYNC TEAM statement . . . . . . . . . . . . . . . . . . . . . .             . . . . . . . . . . . . . . 211

        11.6.7 EVENT POST statement . . . . . . . . . . . . . . . . . . . . .              . . . . . . . . . . . . . . 211

        11.6.8 EVENT WAIT statement . . . . . . . . . . . . . . . . . . . . .              . . . . . . . . . . . . . . 212

        11.6.9 FORM TEAM statement . . . . . . . . . . . . . . . . . . . . . .             . . . . . . . . . . . . . . 212

        11.6.10 LOCK and UNLOCK statements . . . . . . . . . . . . . . . . .               . . . . . . . . . . . . . . 213

        11.6.11 STAT= and ERRMSG= specifiers in image control statements .                 . . . . . . . . . . . . . . 215

          12.5.6 OPEN statement . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . 226

          12.5.7 CLOSE statement . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . 230

          12.6.1 Form of input and output statements . . . . . . . . .        . . . . . . . . . . . . . . . . . . . . 231

          12.6.2 Control information list . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . 232

          12.6.3 Data transfer input/output list . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . 236

          12.6.4 Execution of a data transfer input/output statement          . . . . . . . . . . . . . . . . . . . . 239

          12.6.5 Termination of data transfer statements . . . . . . .        . . . . . . . . . . . . . . . . . . . . 249

          12.7.1 Wait operation . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . 250

          12.7.2 WAIT statement . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . . 250

          12.8.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . 251

          12.8.2 BACKSPACE statement . . . . . . . . . . . . . . . .          . . . . . . . . . . . . . . . . . . . . 251

          12.8.3 ENDFILE statement . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . . . . . . . 252

          12.8.4 REWIND statement . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . . . . . . . . . . 252

          12.10.1 Forms of the INQUIRE statement . . . . . . . . . . .        . . . . . . . . . . . . . . . . . . . . 253

          12.10.2 Inquiry specifiers . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . 254

          12.10.3 Inquire by output list . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . 260

          12.11.1 Occurrence of input/output conditions . . . . . . . .       . . . . . . . . . . . . . . . . . . . . 260

          12.11.2 Error conditions and the ERR= specifier . . . . . . .       . . . . . . . . . . . . . . . . . . . . 260

          12.11.3 End-of-file condition and the END= specifier . . . . .      . . . . . . . . . . . . . . . . . . . . 261

          12.11.4 End-of-record condition and the EOR= specifier . . .        . . . . . . . . . . . . . . . . . . . . 261

          12.11.5 IOSTAT= specifier . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . . 262

          12.11.6 IOMSG= specifier . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . 262

    13.1 Format specifications . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

    13.2 Explicit format specification methods . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

          13.2.1 FORMAT statement . . . . . . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

          13.2.2 Character format specification . . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

    13.3 Form of a format item list . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

          13.3.1 Syntax . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

          13.3.2 Edit descriptors . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

          13.3.3 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

    13.4 Interaction between input/output list and format       . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

    13.5 Positioning by format control . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

    13.6 Decimal symbol . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

    13.7 Data edit descriptors . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

          13.7.1 Purpose of data edit descriptors . . . . .     . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

          13.7.2 Numeric editing . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

          13.7.3 Logical editing . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

          13.7.4 Character editing . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

          13.7.5 Generalized editing . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

          13.7.6 User-defined derived-type editing . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

    13.8 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

          13.8.1 Position edit descriptors . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

          13.8.2 Slash editing . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

          13.8.3 Colon editing . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

          13.8.4 SS, SP, and S editing . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

          13.8.5 P editing . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

          13.8.6 BN and BZ editing . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

                                                                               ISO/IEC DIS 1539-1:2017 (E)

         13.10.1 Purpose of list-directed formatting . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

         13.10.2 Values and value separators . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

         13.10.3 List-directed input . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

         13.10.4 List-directed output . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

         13.11.1 Purpose of namelist formatting . . . .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

         13.11.2 Name-value subsequences . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

         13.11.3 Namelist input . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

         13.11.4 Namelist output . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

   14.1 Main program . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

   14.2 Modules . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

         14.2.1 Module syntax and semantics . . . . . .         . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

         14.2.2 The USE statement and use association .         . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

         14.2.3 Submodules . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

   14.3 Block data program units . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

   15.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . 299

   15.2 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . 299

         15.2.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . 299

         15.2.2 Procedure classification by means of definition . . . . . . . . . . . . .       . . . . . . . . . . . 299

   15.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

         15.3.1 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . 300

         15.3.2 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . .          . . . . . . . . . . . 300

         15.3.3 Characteristics of function results . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . 300

   15.4 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . 301

         15.4.1 Interface and abstract interface . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . 301

         15.4.2 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . 301

         15.4.3 Specification of the procedure interface . . . . . . . . . . . . . . . . .      . . . . . . . . . . . 302

   15.5 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . 311

         15.5.1 Syntax of a procedure reference . . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . 311

         15.5.2 Actual arguments, dummy arguments, and argument association . . .               . . . . . . . . . . . 313

         15.5.3 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . 324

         15.5.4 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . 324

         15.5.5 Resolving named procedure references . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . 324

         15.5.6 Resolving type-bound procedure references . . . . . . . . . . . . . . .         . . . . . . . . . . . 326

   15.6 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . 327

         15.6.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . 327

         15.6.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . .         . . . . . . . . . . . 327

         15.6.3 Definition and invocation of procedures by means other than Fortran             . . . . . . . . . . . 332

         15.6.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . 333

   15.7 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . 333

   15.8 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . 335

         15.8.1 Elemental procedure declaration and interface . . . . . . . . . . . . .         . . . . . . . . . . . 335

         15.8.2 Elemental function actual arguments and results . . . . . . . . . . . .         . . . . . . . . . . . 336

         15.8.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . .         . . . . . . . . . . . 336

   16.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

   16.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

         16.2.1 General rules . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . 337

         16.2.2 The shape of array arguments . . . . . . . . .        . . . . . . . . . . . . . . . . . . . . . . . . 338

         16.2.3 Mask arguments . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . 338

         16.2.4 DIM arguments and reduction functions . . .           . . . . . . . . . . . . . . . . . . . . . . . . 338

         16.3.1 General . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . 338

         16.3.2 Bit sequence comparisons . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . 339

         16.3.3 Bit sequences as arguments to INT and REAL            . . . . . . . . . . . . . . . . . . . . . . . . 339

         16.9.1 General . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . 349

         16.10.1 General . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . 436

         16.10.2 The ISO_FORTRAN_ENV intrinsic module                 . . . . . . . . . . . . . . . . . . . . . . . . 436

   17.1 Overview of IEEE arithmetic support .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

   17.2 Derived types, constants, and operators     defined in  the modules     . . . . . . . . . . . . . . . . . . . 444

   17.3 The exceptions . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

   17.4 The rounding modes . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

   17.5 Underflow mode . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

   17.6 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

   17.7 The floating-point modes and status .       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

   17.8 Exceptional values . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

   17.9 IEEE arithmetic . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

   17.10 Summary of the procedures . . . . . .      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

   17.11 Specifications of the procedures . . . .   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

         17.11.1 General . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

   17.12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

   18.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

   18.2 The ISO_C_BINDING intrinsic module . . . . . . . . . . . . .            . . . . . . . . . . . . . . . . . . . 479

         18.2.1 Summary of contents . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . 479

         18.2.2 Named constants and derived types in the module . . .           . . . . . . . . . . . . . . . . . . . 479

         18.2.3 Procedures in the module . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . . . . . . . 480

   18.3 Interoperability between Fortran and C entities . . . . . . . . .       . . . . . . . . . . . . . . . . . . . 485

         18.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . 485

         18.3.2 Interoperability of intrinsic types . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . 485

         18.3.3 Interoperability with C pointer types . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . 486

         18.3.4 Interoperability of derived types and C struct types . .        . . . . . . . . . . . . . . . . . . . 486

         18.3.5 Interoperability of scalar variables . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . . . 488

         18.3.6 Interoperability of array variables . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . . . 488

         18.3.7 Interoperability of procedures and procedure interfaces         . . . . . . . . . . . . . . . . . . . 489

   18.4 C descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

   18.5 The source file ISO_Fortran_binding.h . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . 492

         18.5.1 Summary of contents . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . . . 492

         18.5.2 The CFI_dim_t structure type . . . . . . . . . . . . .          . . . . . . . . . . . . . . . . . . . 492

         18.5.3 The CFI_cdesc_t structure type . . . . . . . . . . . .          . . . . . . . . . . . . . . . . . . . 492

         18.5.4 Macros and typedefs in ISO_Fortran_binding.h . . . .            . . . . . . . . . . . . . . . . . . . 493

         18.5.5 Functions declared in ISO_Fortran_binding.h . . . . .           . . . . . . . . . . . . . . . . . . . 496

   18.6 Restrictions on C descriptors . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . 503

                                                                               ISO/IEC DIS 1539-1:2017 (E)

         18.9.1 General . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . . . . . . . . . 505

         18.9.2 Binding labels for common blocks and variables . .          . . . . . . . . . . . . . . . . . . . . . 506

         18.10.1 Definition and reference of interoperable procedures       . . . . . . . . . . . . . . . . . . . . . 506

         18.10.2 Binding labels for procedures . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . . . . . 506

         18.10.3 Exceptions and IEEE arithmetic procedures . . . .          . . . . . . . . . . . . . . . . . . . . . 507

         18.10.4 Asynchronous communication . . . . . . . . . . . .         . . . . . . . . . . . . . . . . . . . . . 507

   19.1 Scopes, identifiers, and entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

   19.2 Global identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . 509

   19.3 Local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

         19.3.1 Classes of local identifiers . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . . . . . 510

         19.3.2 Local identifiers that are the same as common block names           . . . . . . . . . . . . . . . . . 511

         19.3.3 Function results . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . 511

         19.3.4 Components, type parameters, and bindings . . . . . . . .           . . . . . . . . . . . . . . . . . 511

         19.3.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . 511

   19.4 Statement and construct entities . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . 512

   19.5 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

         19.5.1 Name association . . . . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . 513

         19.5.2 Pointer association . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 517

         19.5.3 Storage association . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 520

         19.5.4 Inheritance association . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 522

         19.5.5 Establishing associations . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 522

   19.6 Definition and undefinition of variables . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . 523

         19.6.1 Definition of objects and subobjects . . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . 523

         19.6.2 Variables that are always defined . . . . . . . . . . . . . .       . . . . . . . . . . . . . . . . . 523

         19.6.3 Variables that are initially defined . . . . . . . . . . . . . .    . . . . . . . . . . . . . . . . . 523

         19.6.4 Variables that are initially undefined . . . . . . . . . . . .      . . . . . . . . . . . . . . . . . 524

         19.6.5 Events that cause variables to become defined . . . . . . .         . . . . . . . . . . . . . . . . . 524

         19.6.6 Events that cause variables to become undefined . . . . . .         . . . . . . . . . . . . . . . . . 526

         19.6.7 Variable definition context . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 528

         19.6.8 Pointer association context . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . . . . . 528

   A.1 Unspecified items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

   A.2 Processor dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

         B.3.12  Specific names for intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

         B.3.13  FORALL construct and statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

    C.1 Fortran 2008 features not mentioned in its Introduction . . . . . . . . . . .      . . . . . . . . . . . . . 543

    C.2 Clause 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

         C.2.1   Selection of the approximation methods (7.4.3.2) . . . . . . . . .        . . . . . . . . . . . . . 543

         C.2.2   Type extension and component accessibility (7.5.2.2, 7.5.4) . . . .       . . . . . . . . . . . . . 544

         C.2.3   Generic type-bound procedures (7.5.5) . . . . . . . . . . . . . . .       . . . . . . . . . . . . . 545

         C.2.4   Abstract types (7.5.7.1) . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 546

         C.2.5   Structure constructors and generic names (7.5.10) . . . . . . . . .       . . . . . . . . . . . . . 547

         C.2.6   Final subroutines (7.5.6, 7.5.6.2, 7.5.6.3, 7.5.6.4) . . . . . . . . . .  . . . . . . . . . . . . . 548

    C.3 Clause 8 notes: The VOLATILE attribute (8.5.19) . . . . . . . . . . . . .          . . . . . . . . . . . . . 550

    C.4 Clause 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

         C.4.1   Structure components (9.4.2) . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . 551

         C.4.2   Allocation with dynamic type (9.7.1) . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . 552

    C.5 Clause 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 553

         C.5.1   Evaluation of function references (10.1.7) . . . . . . . . . . . . . .    . . . . . . . . . . . . . 553

         C.5.2   Pointers in expressions (10.1.9.2) . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . 553

         C.5.3   Pointers in variable definition contexts (10.2.1.3, 19.6.7) . . . . .     . . . . . . . . . . . . . 553

    C.6 Clause 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 553

         C.6.1   The SELECT CASE construct (11.1.9) . . . . . . . . . . . . . . .          . . . . . . . . . . . . . 553

         C.6.2   Loop control (11.1.7) . . . . . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . 554

         C.6.3   Examples of DO constructs (11.1.7) . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . 554

         C.6.4   Examples of invalid DO constructs (11.1.7) . . . . . . . . . . . . .      . . . . . . . . . . . . . 555

         C.6.5   Simple example using events . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 556

         C.6.6   Example using three teams . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 557

         C.6.7   Accessing coarrays in sibling teams . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 557

         C.6.8   Example involving failed images . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 558

         C.6.9   EVENT_QUERY example that tolerates image failure . . . . . .              . . . . . . . . . . . . . 560

    C.7 Clause 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 562

         C.7.1   External files (12.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

         C.7.2   Nonadvancing input/output (12.3.4.2) . . . . . . . . . . . . . . .        . . . . . . . . . . . . . 563

         C.7.3   OPEN statement (12.5.6) . . . . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 565

         C.7.4   Connection properties (12.5.4) . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . 566

         C.7.5   Asynchronous input/output (12.6.2.5) . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . 567

    C.8 Clause 13 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 568

         C.8.1   Number of records (13.4, 13.5, 13.8.2) . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . 568

         C.8.2   List-directed input (13.10.3) . . . . . . . . . . . . . . . . . . . . .   . . . . . . . . . . . . . 568

    C.9 Clause 14 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . 569

         C.9.1   Main program and block data program unit (14.1, 14.3) . . . . .           . . . . . . . . . . . . . 569

         C.9.2   Dependent compilation (14.2) . . . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . 569

         C.9.3   Examples of the use of modules (14.2.1) . . . . . . . . . . . . . .       . . . . . . . . . . . . . 571

         C.9.4   Modules with submodules (14.2.3) . . . . . . . . . . . . . . . . . .      . . . . . . . . . . . . . 577

    C.10 Clause 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582

         C.10.1 Portability problems with external procedures (15.4.3.5) . . . . .         . . . . . . . . . . . . . 582

         C.10.2 Procedures defined by means other than Fortran (15.6.3) . . . . .          . . . . . . . . . . . . . 582

         C.10.3 Abstract interfaces and procedure pointer components (15.4, 7.5)           . . . . . . . . . . . . . 582

         C.10.4 Pointers and targets as arguments (15.5.2.4, 15.5.2.6, 15.5.2.7) . .       . . . . . . . . . . . . . 584

         C.10.5 Polymorphic Argument Association (15.5.2.9) . . . . . . . . . . .          . . . . . . . . . . . . . 586

         C.10.6 Rules ensuring unambiguous generics (15.4.3.4.5) . . . . . . . . .         . . . . . . . . . . . . . 587

    C.11 Clause 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591

         C.11.1 Atomic memory consistency . . . . . . . . . . . . . . . . . . . . .        . . . . . . . . . . . . . 591

         C.11.2 EVENT_QUERY example . . . . . . . . . . . . . . . . . . . . . .            . . . . . . . . . . . . . 593

         C.11.3 Collective subroutine examples . . . . . . . . . . . . . . . . . . . .     . . . . . . . . . . . . . 595

    C.12 Clause 18 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

                                                                                 ISO/IEC DIS 1539-1:2017 (E)

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

⃝c ISO/IEC 2017 – All rights reserved
	xiii

                            (Blank page)

                                         c ISO/IEC 2017 – All rights reserved


                                                                           ISO/IEC DIS 1539-1:2017 (E)

  4.3  Previous editions of the Fortran International Standard . . . . . . . . . . . . . . . . . . . . 30

  5.1  Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

  5.2  Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

  6.1  Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

  6.2  Adjacent keywords where separating blanks are optional . . . . . . . . . . . . . . . . . . . 53

  9.1  Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

  10.1 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . . . . . . 151

  10.2 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . . . . . . 154

  10.3 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . . . . . . 155

  10.4 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . . . . . . 157

  10.5 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . . . . . . 158

  10.6 The values of operations involving logical intrinsic operators . . . . . . . . . . . . . . . . . 158

  10.7 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . . . . . . 159

  10.8 Intrinsic assignment type conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

  10.9 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . . . . . . 169

  13.1 E and D exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

  13.2 EN exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

  13.3 ES exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

  16.1 Standard generic intrinsic procedure summary . . . . . . . . . . . . . . . . . . . . . . . . . 342

  16.2 Unrestricted specific intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

  16.3 Restricted specific intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

  16.4 Default BOUNDARY values for EOSHIFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

  16.5 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

  17.1 IEEE relational operator correspondence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

  17.2 IEEE_ARITHMETIC module procedure summary . . . . . . . . . . . . . . . . . . . . . . 450

   17.3 IEEE_EXCEPTIONS module procedure summary . . . . . . . . . . . . . . . . . . . . . . . 451

   18.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 480

   18.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . . . . . . 485

   18.3 ISO_Fortran_binding.h macros for attribute codes . . . . . . . . . . . . . . . . . . . . . . 494

   18.4 ISO_Fortran_binding.h macros for type codes . . . . . . . . . . . . . . . . . . . . . . . . . 494

   18.5 ISO_Fortran_binding.h macros for error codes . . . . . . . . . . . . . . . . . . . . . . . . . 495

                                                                               ISO/IEC DIS 1539-1:2017 (E)

1 ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commis-

  sion) 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 organizations, 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.

3 The main task of the joint technical committee is to prepare International Standards. Draft International Stand-

  ards 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.

  rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

  mittee SC 22, Programming languages, their environments and system software interfaces.

  ally revised. It also incorporates the Technical Corrigenda ISO/IEC 1539-1:2010/Cor. 1:2012, ISO/IEC 1539-

  1:2010/Cor. 2:2013, ISO/IEC 1539-1:2010/Cor. 3:2014, and ISO/IEC 1539-1:2010/Cor. 4:2016, and the Technical

  Specifications ISO/IEC TS 29113:2012 and ISO/IEC TS 18508:2015.

  languages — Fortran:

9 — Part 2: Varying length character strings

  ⃝c ISO/IEC 2017 – All rights reserved                                                                        xvii


  ISO/IEC DIS 1539-1:2017 (E)

  Introduction

  With the limitations noted in 4.3.3, the syntax and semantics of Fortran 2008 are contained entirely within

  Fortran 2018. Therefore, any standard-conforming Fortran 2008 program not affected by such limitations is a

  standard-conforming Fortran 2018 program. New features of Fortran 2018 can be compatibly incorporated into

  such Fortran 2008 programs, with any exceptions indicated in the text of this document.

     • Data declaration:

        Constant properties of an object declared in its entity-decl can be used in its initialization. The EQUIVAL-

        ENCE and COMMON statements and the block data program unit have been redundant since Fortran 90

        and are now specified to be obsolescent. Diagnosis of the appearance of a PROTECTED TARGET variable

        accessed by use association as a data-target in a structure constructor is required.

     • Data usage and computation:

        The declared type of the value supplied for a polymorphic allocatable component in a structure constructor

        is no longer required to be the same as the declared type of the component. FORALL is now specified to

        be obsolescent. The type and kind of an implied DO variable in an array constructor or DATA statement

        can be specified within the constructor or statement. The SELECT RANK construct provides structured

        access to the elements of an assumed-rank array. Completing execution of a BLOCK construct can cause

        the association status of a pointer with the PROTECTED attribute to become undefined. The standard

        intrinsic operations <, <=, >, and >= (also known as .LT., .LE., .GT., and .GE.) on IEEE numbers provide

        compareSignaling{relation} operations; the = and /= operations (also known as .EQ. and .NE.) provide

        compareQuiet{relation} operations. Finalization of an allocatable subobject during intrinsic assignment

        has been clarified.

     • Input/output:

        The SIZE= specifier can be used with advancing input. It is no longer prohibited to open a file on more than

        one unit. The value assigned by the RECL= specifier in an INQUIRE statement has been standardized.

        The values assigned by the POS= and SIZE= specifiers in an INQUIRE statement for a unit that has

        pending asynchronous operations have been standardized. The G0.d edit descriptor can be used for list

        items of type Integer, Logical, and Character. The D, E, EN, and ES edit descriptors can have a field width

        of zero, analogous to the F edit descriptor. The exponent width e in a data edit descriptor can be zero,

        analogous to a field width of zero. Floating-point formatted input accepts hexadecimal-significand numbers

        that conform to ISO/IEC/IEEE 60559:2011. The EX edit descriptor provides hexadecimal-significand

        formatted output conforming to ISO/IEC/IEEE 60559:2011. An error condition occurs if unacceptable

        characters are presented for logical or numeric editing during execution of a formatted input statement.

     • Execution control:

        The arithmetic IF statement has been deleted. Labeled DO loops have been redundant since Fortran 90

        and are now specified to be obsolescent. The nonblock DO construct has been deleted. The locality of a

        variable used in a DO CONCURRENT construct can be explicitly specified. The stop code in a STOP or

        ERROR STOP statement can be nonconstant. Output of the stop code and exception summary from the

        STOP and ERROR STOP statements can be controlled.

     • Intrinsic procedures and modules:

        In a reference to the intrinsic function CMPLX with an actual argument of type complex, no keyword

        is needed for a KIND argument. In references to the intrinsic functions ALL, ANY, FINDLOC, IALL,

        IANY, IPARITY, MAXLOC, MAXVAL, MINLOC, MINVAL, NORM2, PARITY, PRODUCT, SUM, and

        THIS_IMAGE, the actual argument for DIM can be a present optional dummy argument. The new intrinsic

        function COSHAPE returns the coshape of a coarray. The new intrinsic function OUT_OF_RANGE tests

        whether a numeric value can be safely converted to a different type or kind. The new intrinsic subroutine

        RANDOM_INIT establishes the initial state of the pseudorandom number generator used by RANDOM_-

        NUMBER. The new intrinsic function REDUCE performs user-specified array reductions. A processor is re-

        quired to report use of a nonstandard intrinsic procedure, use of a nonstandard intrinsic module, and use of a

        nonstandard procedure from a standard intrinsic module. Integer and logical arguments to intrinsic proced-

        ures and intrinsic module procedures that were previously required to be of default kind no longer have that

                                                                             ISO/IEC DIS 1539-1:2017 (E)

cent. All standard procedures in the intrinsic module ISO_C_BINDING, other than C_F_POINTER, are

now pure. The arguments to the intrinsic function SIGN can be of different kind. Nonpolymorphic pointer

arguments to the intrinsic functions EXTENDS_TYPE_OF and SAME_TYPE_AS need not have defined

pointer association status. The effects of invoking the intrinsic procedures COMMAND_ARGUMENT_-

COUNT, GET_COMMAND, and GET_COMMAND_ARGUMENT, on images other than image one, are

no longer processor dependent. Access to error messages from the intrinsic subroutines GET_COMMAND,

GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE is provided by an optional

ERRMSG argument. The result of NORM2 for a zero-sized array argument has been clarified.

    The IMPORT statement can appear in a contained subprogram or BLOCK construct, and can restrict

    access via host association; diagnosis of violation of the IMPORT restrictions is required. The GENERIC

    statement can be used to declare generic interfaces. The number of procedure arguments is used in generic

    resolution. In a module, the default accessibility of entities accessed from another module can be controlled

    separately from the default accessibility of entities declared in the using module. An IMPLICIT NONE

    statement can require explicit declaration of the EXTERNAL attribute throughout a scoping unit and

    its contained scoping units. A defined operation need not specify INTENT (IN) for a dummy argument

    with the VALUE attribute. A defined assignment need not specify INTENT (IN) for the second dummy

    argument if it has the VALUE attribute. Procedures that are not declared with an asterisk type-param-value can

    be invoked recursively by default; the RECURSIVE keyword is advisory only. The NON_RECURSIVE

    keyword specifies that a procedure is not recursive. The ERROR STOP statement can appear in a pure

    subprogram. A dummy argument of a pure function is permitted in a variable definition context, if it has

    the VALUE attribute. A coarray dummy argument can be referenced or defined by another image.

    A dummy data object can assume its rank from its effective argument. A dummy data object can assume

    the type from its effective argument, without having the ability to perform type selection. An interoper-

    able procedure can have dummy arguments that are assumed-type and/or assumed-rank. An interoperable

    procedure can have dummy data objects that are allocatable, assumed-shape, optional, or pointers. The

    character length of a dummy data object of an interoperable procedure can be assumed. The argument

    to C_LOC can be a noninteroperable array. The FPTR argument to C_F_POINTER can be a noninter-

    operable array pointer. The argument to C_FUNLOC can be a noninteroperable procedure. The FPTR

    argument to C_F_PROCPOINTER can be a noninteroperable procedure pointer.

    Additionally to ISO/IEC TS 29113:2012, an assumed-rank dummy data object that is not associated with

    an assumed-size array can be used as the argument to the function C_SIZEOF from the intrinsic module

    ISO_C_BINDING.

    for conformance with ISO/IEC/IEEE 60559:2011:

    There is a new, optional, rounding mode IEEE_AWAY. The new type IEEE_MODES_TYPE encapsu-

    lates all floating-point modes. Features associated with subnormal numbers can be accessed with func-

    tions and types named . . . SUBNORMAL. . . (the old . . . DENORMAL. . . names remain). The new function

    IEEE_FMA performs fused multiply-add operations. The function IEEE_INT performs rounded conver-

    sions to integer type. The new functions IEEE_MAX_NUM, IEEE_MAX_NUM_MAG, IEEE_MIN_-

    NUM, and IEEE_MIN_NUM_MAG calculate maximum and minimum numeric values. The new func-

    tions IEEE_NEXT_DOWN and IEEE_NEXT_UP return the adjacent machine numbers. The new func-

    tions IEEE_QUIET_EQ, IEEE_QUIET_GE, IEEE_QUIET_GT, IEEE_QUIET_LE, IEEE_QUIET_-

    LT, and IEEE_QUIET_NE perform quiet comparisons. The new functions IEEE_SIGNALING_EQ,

    IEEE_SIGNALING_GE, IEEE_SIGNALING_GT, IEEE_SIGNALING_GE, IEEE_SIGNALING_LE,

    IEEE_SIGNALING_LT, and IEEE_SIGNALING_NE perform signaling comparisons. The decimal round-

    ing mode can be inquired and set independently of the binary rounding mode, using the RADIX argument

    to IEEE_GET_ROUNDING_MODE and IEEE_SET_ROUNDING_MODE. The new function IEEE_-

    REAL performs rounded conversions to real type. The function IEEE_REM now requires its arguments to

    have the same radix. The function IEEE_RINT now has a ROUND argument to perform specific rounding.

    The new function IEEE_SIGNBIT tests the sign bit of an IEEE number.

    The CRITICAL statement has optional ERRMSG= and STAT= specifiers. The intrinsic subroutines

  ISO/IEC DIS 1539-1:2017 (E)

        ATOMIC_DEFINE and ATOMIC_REF have an optional STAT argument. The new intrinsic subroutines

        ATOMIC_ADD, ATOMIC_AND, ATOMIC_CAS, ATOMIC_FETCH_ADD, ATOMIC_FETCH_AND,

        ATOMIC_FETCH_OR, ATOMIC_FETCH_XOR, ATOMIC_OR, and ATOMIC_XOR perform atomic

        operations. The new intrinsic functions FAILED_IMAGES and STOPPED_IMAGES return indices of im-

        ages known to have failed or stopped respectively. The new intrinsic function IMAGE_STATUS returns the

        image execution status of an image. The intrinsic subroutine MOVE_ALLOC has optional ERRMSG and

        STAT arguments. The intrinsic functions IMAGE_INDEX and NUM_IMAGES have additional forms with

        a TEAM or TEAM_NUMBER argument. The intrinsic function THIS_IMAGE has an optional TEAM

        argument. The EVENT POST and EVENT WAIT statements, the intrinsic subroutine EVENT_QUERY,

        and the type EVENT_TYPE provide an event facility for one-sided segment ordering. The CHANGE

        TEAM construct, derived type TEAM_TYPE, FORM TEAM and SYNC TEAM statements, intrinsic

        functions GET_TEAM and TEAM_NUMBER, and the TEAM= and TEAM_NUMBER= specifiers on

        image selectors, provide a team facility for a subset of the program’s images to act in concert as if it were the

        set of all images. This team facility allows an allocatable coarray to be allocated or deallocated on a sub-

        set of images. The new intrinsic subroutines CO_BROADCAST, CO_MAX, CO_MIN, CO_REDUCE,

        and CO_SUM perform collective reduction operations on the images of the current team. The concept

        of failed images, the FAIL IMAGE statement, the STAT= specifier on image selectors, and the named

        constant STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV provide support for

        fault-tolerant parallel execution.

      • Changes to features previously described by ISO/IEC TS 18508:2015:

        The CHANGE TEAM and SYNC TEAM statements, and the TEAM= specifier on image selectors, permit

        the team to be specified by an expression. The intrinsic functions FAILED_IMAGES and STOPPED_-

        IMAGES have no restriction on the kind of their result. The name of the function argument to the

        intrinsic function CO_REDUCE is OPERATION instead of OPERATOR; this argument is not required to

        be commutative. The named constant STAT_UNLOCKED_FAILED_IMAGE from the intrinsic module

        ISO_FORTRAN_ENV indicates that a lock variable was locked by an image that failed. The team number

        for the initial team can be used in image selectors, and in the intrinsic functions NUM_IMAGES and

        IMAGE_INDEX. A team variable that appears in a CHANGE TEAM statement can no longer be defined

        or become undefined during execution of the CHANGE TEAM construct. All images of the current team

        are no longer required to execute the same CHANGE TEAM statement. A variable of type TEAM_TYPE

        from the intrinsic module ISO_FORTRAN_ENV is not permitted to be a coarray. A variable of type

        TEAM_TYPE from the intrinsic module ISO_FORTRAN_ENV can have a pointer component, and a

        team variable becomes undefined if assigned a value from another image.

  which they are treated, are:

                                 High/low level concepts               Clauses 4, 5, 6

                                 Data concepts                         Clauses 7, 8, 9

                                 Computations                          Clauses 10, 16, 17

                                 Execution control                     Clause 11

                                 Input/output                          Clauses 12, 13

                                 Program units                         Clauses 14, 15

                                 Interoperability with C               Clause 18

                                 Scoping and association rules         Clause 19

                                 Processor dependencies                Annex A

                                 Deleted and obsolescent features      Annex B

                                 Extended notes                        Annex C

                                 Index                                 Index

                                                                              ISO/IEC DIS 1539-1:2017 (E)

Fortran —

Part 1:

Base language

1 Scope

  language. The purpose of this document is to promote portability, reliability, maintainability, and efficient

  execution of Fortran programs for use on a variety of computing systems.

     •  the forms that a program written in the Fortran language may take,

     •  the rules for interpreting the meaning of a program and its data,

     •  the form of the input data to be processed by such a program, and

     •  the form of the output data resulting from the use of such a program.

  rather than processors.

     •  the mechanism by which programs are transformed for use on computing systems,

     •  the operations required for setup and control of the use of programs on computing systems,

     •  the method of transcription of programs or their input or output data to or from a storage medium,

     •  the program and processor behavior when this document fails to establish an interpretation except for the

        processor detection and reporting requirements in items (2) to (10) of 4.2,

     •  the maximum number of images, or the size or complexity of a program and its data that will exceed the

        capacity of any particular computing system or the capability of a particular processor,

     •  the mechanism for determining the number of images of a program,

     •  the physical properties of an image or the relationship between images and the computational elements of

        a computing system,

     •  the physical properties of the representation of quantities and the method of rounding, approximating, or

        computing numeric values on a particular processor, except by reference to ISO/IEC/IEEE 60559:2011

        under conditions specified in Clause 17,

     •  the physical properties of input/output records, files, and units, or

     •  the physical properties and implementation of storage.

                            (Blank page)

                                         c ISO/IEC 2017 – All rights reserved


                                                                            ISO/IEC DIS 1539-1:2017 (E)

  requirements of this document. For dated references, only the edition cited applies. For undated references, the

  latest edition of the referenced document (including any amendments) applies.

  ISO/IEC 646:1991 (International Reference Version), Information technology—ISO 7-bit coded character set for

  information interchange

  ISO/IEC 9899:2011, Programming languages—C

  ISO/IEC 10646, Information technology—Universal Multiple-Octet Coded Character Set (UCS)

  ISO/IEC/IEEE 60559:2011, Information technology — Microprocessor Systems — Floating-Point arithmetic

  ⃝c ISO/IEC 2017 – All rights reserved                                                                          3

                            (Blank page)

                                         c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

  databases for use in standardization at the following addresses:

      • IEC Electropedia: available at http://www.electropedia.org/

      • ISO Online browsing platform: available at http://www.iso.org/obp

  3.1

  actual argument

  entity (R1524) that appears in a procedure reference

  3.2

  allocatable

  having the ALLOCATABLE attribute (8.5.3)

  3.3

  array

  set of scalar data, all of the same type and type parameters, whose individual elements are arranged in a

  rectangular pattern (8.5.8, 9.5)

  3.3.1

  array element

  scalar individual element of an array

  3.3.2

  array pointer

  array with the POINTER attribute (8.5.14)

  3.3.3

  array section

  array subobject designated by array-section, and which is itself an array (9.5.3.3)

  3.3.4

  assumed-shape array

  nonallocatable nonpointer dummy argument array that takes its shape from its effective argument (8.5.8.3)

  3.3.5

  assumed-size array

  dummy argument array whose size is assumed from that of its effective argument (8.5.8.5)

  3.3.6

  deferred-shape array

  allocatable array or array pointer, declared with a deferred-shape-spec-list (8.5.8.4)

  3.3.7

  explicit-shape array

  array declared with an explicit-shape-spec-list, which specifies explicit values for the bounds in each dimension of

  the array (8.5.8.2)

  3.4

  ASCII character

  character whose representation method corresponds to ISO/IEC 646:1991 (International Reference Version)

  ⃝c ISO/IEC 2017 – All rights reserved                                                                             5

                                                                                 ISO/IEC DIS 1539-1:2017 (E)

assumed-type

declared with a TYPE(*) type specifier (7.3.2)

3.10

attribute

property of an entity that determines its uses (8.1)

3.11

automatic data object

nondummy data object with a type parameter or array bound that depends on the value of a specification-expr

that is not a constant expression (8.3)

3.12

base object

⟨data-ref ⟩ object designated by the leftmost part-name (9.4.2)

3.13

binding

type-bound procedure or final subroutine (7.5.5)

3.14

binding name

name given to a specific or generic type-bound procedure in the type definition (7.5.5)

3.15

binding label

default character value specifying the name by which a global entity with the BIND attribute is known to the

companion processor (18.10.2, 18.9.2)

3.16

block

sequence of executable constructs formed by the syntactic class block and which is treated as a unit by the

executable constructs described in 11.1

3.17

bound

array bound

limit of a dimension of an array (8.5.8)

3.18

branch target statement

action-stmt, associate-stmt, end-associate-stmt, if-then-stmt, end-if-stmt, select-case-stmt, end-select-stmt, select-

rank-stmt, end-select-rank-stmt, select-type-stmt, end-select-type-stmt, do-stmt, end-do-stmt, block-stmt, end-

block-stmt, critical-stmt, end-critical-stmt, forall-construct-stmt , where-construct-stmt, end-function-stmt, end-mp-

subprogram-stmt, end-program-stmt, or end-subroutine-stmt, whose statement label appears as a label in a GO TO

statement, computed GO TO statement, alt-return-spec, END= specifier, EOR= specifier, or ERR= specifier (11.2.1)

3.19

C address

value identifying the location of a data object or procedure either defined by the companion processor or which

might be accessible to the companion processor

     NOTE 3.1

     This is the concept that ISO/IEC 9899:2011 calls the address.

3.20

C descriptor

C structure of type CFI_cdesc_t defined in the source file ISO_Fortran_binding.h (18.4, 18.5)

3.21

character context

within a character literal constant (7.4.4) or within a character string edit descriptor (13.3.2)

3.22

characteristics

⟨dummy argument⟩ being a dummy data object, dummy procedure, or an asterisk (alternate return indicator)

3.23

characteristics

⟨dummy data object⟩ properties listed in 15.3.2.2

3.24

characteristics

⟨dummy procedure or dummy procedure pointer⟩ properties listed in 15.3.2.3

3.25

characteristics

⟨function result⟩ properties listed in 15.3.3

3.26

characteristics

⟨procedure⟩ properties listed in 15.3.1

3.27

coarray

data entity that has nonzero corank (5.4.7)

3.27.1

established coarray

coarray that is accessible using an image-selector (5.4.8)

3.28

cobound

bound (limit) of a codimension (8.5.6)

3.29

codimension

dimension of the pattern formed by a set of corresponding coarrays (8.5.6)

3.30

coindexed object

data object whose designator includes an image-selector (R924, 9.6)

3.31

collating sequence

one-to-one mapping from a character set into the nonnegative integers (7.4.4.4)

3.32

common block

block of physical storage specified by a COMMON statement (8.10.2)

3.32.1

blank common

unnamed common block

8
c ISO/IEC 2017 – All rights reserved ISO/IEC DIS 1539-1:2017 (E) 3.33
companion processor
processor-dependent mechanism by which global data and procedures may be referenced or defined (5.5.7)
3.34
component
part of a derived type, or of an object of derived type, defined by a component-def-stmt (7.5.4)
3.34.1
direct component
one of the components, or one of the direct components of a nonpointer nonallocatable component (7.5.1)
3.34.2
parent component
component of an extended type whose type is that of the parent type and whose components are inheritance
associated with the inherited components of the parent type (7.5.7.2)
3.34.3
potential subobject component
nonpointer component, or potential subobject component of a nonpointer component (7.5.1)
3.34.4
subcomponent
⟨structure⟩ direct component that is a subobject of the structure (9.4.2)
3.34.5
ultimate component
component that is of intrinsic type, a pointer, or allocatable; or an ultimate component of a nonpointer nonal-
locatable component of derived type
3.35
component order
ordering of the nonparent components of a derived type that is used for intrinsic formatted input/output and
structure constructors (where component keywords are not used) (7.5.4.7)
3.36
conformable
⟨of two data entities⟩ having the same shape, or one being an array and the other being scalar
3.37
connected
relationship between a unit and a file: each is connected if and only if the unit refers to the file (12.5.4)
3.38
constant
data object that has a value and which cannot be defined, redefined, or become undefined during execution of a
program (6.2.3, 9.3)
3.38.1
literal constant
constant that does not have a name (R605, 7.4)
3.38.2
named constant
named data object with the PARAMETER attribute (8.5.13)
⃝c ISO/IEC 2017 – All rights reserved

3.39

construct entity

entity whose identifier has the scope of a construct (19.1, 19.4)

3.40

constant expression

expression satisfying the requirements specified in 10.1.12, thus ensuring that its value is constant

3.41

contiguous

⟨array⟩ having array elements in order that are not separated by other data objects, as specified in 8.5.7

3.42

contiguous

⟨multi-part data object⟩ that the parts in order are not separated by other data objects

3.43

corank

number of codimensions of a coarray (zero for objects that are not coarrays) (8.5.6)

3.44

cosubscript

(R925) scalar integer expression in an image-selector (R924)

3.45

data entity

data object, result of the evaluation of an expression, or the result of the execution of a function reference

3.46

data object

object

constant (7.1.4), variable (9), or subobject of a constant (5.4.3.2.3)

3.47

decimal symbol

character that separates the whole and fractional parts in the decimal representation of a real number in a file

(13.6)

3.48

declaration

specification of attributes for various program entities

     NOTE 3.2

     Often this involves specifying the type of a named data object or specifying the shape of a named array

     object.

default initialization

mechanism for automatically initializing pointer components to have a defined pointer association status, and

nonpointer components to have a particular value (7.5.4.6)

3.50

default-initialized

⟨subcomponent⟩ subject to a default initialization specified in the type definition for that component (7.5.4.6)

3.51

definable

capable of definition and permitted to become defined

10	⃝c ISO/IEC 2017 – All rights reserved

                                                                             ISO/IEC DIS 1539-1:2017 (E)

defined

⟨data object⟩ has a valid value

3.53

defined

⟨pointer⟩ has a pointer association status of associated or disassociated (19.5.2.2)

3.54

defined assignment

assignment defined by a procedure (10.2.1.4, 15.4.3.4.3)

3.55

defined input/output

input/output defined by a procedure and accessed via a defined-io-generic-spec (R1509, 12.6.4.8)

3.56

defined operation

operation defined by a procedure (10.1.6.1, 15.4.3.4.2)

3.57

definition

⟨data object⟩ process by which the data object becomes defined (19.6.5)

3.58

definition

⟨derived type (7.5.2), enumeration (7.6), or procedure (15.6)⟩ specification of the type, enumeration, or procedure

3.59

descendant

⟨module or submodule⟩ submodule that extends that module or submodule or that extends another descendant

thereof (14.2.3)

3.60

designator

name followed by zero or more component selectors, complex part selectors, array section selectors, array element

selectors, image selectors, and substring selectors (9.1)

3.60.1

complex part designator

designator that designates the real or imaginary part of a complex data object, independently of the other part

(9.4.4)

3.60.2

object designator

data object designator

designator for a data object

     NOTE 3.3

     An object name is a special case of an object designator.

procedure designator

designator for a procedure

⃝c ISO/IEC 2017 – All rights reserved
	11

3.61

disassociated

⟨pointer association⟩ pointer association status of not being associated with any target and not being undefined

(19.5.2.2)

3.62

disassociated

⟨pointer⟩ has a pointer association status of disassociated

3.63

dummy argument

entity whose identifier appears in a dummy argument list (R1536) in a FUNCTION, SUBROUTINE, ENTRY, or

statement function statement, or whose name can be used as an argument keyword in a reference to an intrinsic

procedure or a procedure in an intrinsic module

3.63.1

dummy data object

dummy argument that is a data object

3.63.2

dummy function

dummy procedure that is a function

3.64

effective argument

entity that is argument-associated with a dummy argument (15.5.2.3)

3.65

effective item

scalar object resulting from the application of the rules in 12.6.3 to an input/output list

3.66

elemental

independent scalar application of an action or operation to elements of an array or corresponding elements of a

set of conformable arrays and scalars, or possessing the capability of elemental operation

      NOTE 3.4

3.66.1

elemental assignment

assignment that operates elementally

3.66.2

elemental operation

operation that operates elementally

3.66.3

elemental operator

operator in an elemental operation

3.66.4

elemental procedure

elemental intrinsic procedure or procedure defined by an elemental subprogram (15.8)

12	⃝c ISO/IEC 2017 – All rights reserved

                                                                             ISO/IEC DIS 1539-1:2017 (E)

elemental reference

reference to an elemental procedure with at least one array actual argument

3.66.6

elemental subprogram

subprogram with the ELEMENTAL prefix (15.8.1)

3.67

END statement

 end-block-data-stmt, end-function-stmt, end-module-stmt, end-mp-subprogram-stmt, end-program-stmt,

3.68

explicit initialization

initialization of a data object by a specification statement (8.4, 8.6.7)

3.69

extent

number of elements in a single dimension of an array

3.70

external file

file that exists in a medium external to the program (12.3)

3.71

external unit

external input/output unit

entity that can be connected to an external file (12.5.3, 12.5.4)

3.72

file storage unit

unit of storage in a stream file or an unformatted record file (12.3.5)

3.73

final subroutine

subroutine whose name appears in a FINAL statement (7.5.6) in a type definition, and which can be automatically

invoked by the processor when an object of that type is finalized (7.5.6.2)

3.74

finalizable

⟨type⟩ has a final subroutine or a nonpointer nonallocatable component of finalizable type

3.75

finalizable

⟨nonpointer data entity⟩ of finalizable type

3.76

finalization

process of calling final subroutines when one of the events listed in 7.5.6.3 occurs

3.77

function

procedure that is invoked by an expression

3.78

function result

entity that returns the value of a function (15.6.2.2)

⃝c ISO/IEC 2017 – All rights reserved
	13

3.79

generic identifier

lexical token sequence that identifies a generic set of procedures, intrinsic operations, and/or intrinsic assignments

(15.4.3.4)

3.80

host instance

⟨internal procedure, or dummy procedure or procedure pointer associated with an internal procedure⟩ instance

of the host procedure that supplies the host environment of the internal procedure (15.6.2.4)

3.81

host scoping unit

host

scoping unit immediately surrounding another scoping unit, or the scoping unit extended by a submodule

3.82

IEEE infinity

ISO/IEC/IEEE 60559:2011 conformant infinite floating-point value

3.83

IEEE NaN

ISO/IEC/IEEE 60559:2011 conformant floating-point datum that does not represent a number

3.84

image

instance of a Fortran program (5.3.4)

3.84.1

active image

image that has not failed or stopped (5.3.6)

3.84.2

failed image

image that has not initiated termination but which has ceased to participate in program execution (5.3.6)

3.84.3

stopped image

image that has initiated normal termination (5.3.6)

3.85

image index

integer value identifying an image within a team

3.86

image control statement

statement that affects the execution ordering between images (11.6)

3.87

inclusive scope

nonblock scoping unit plus every block scoping unit whose host is that scoping unit or that is nested within such

a block scoping unit

      NOTE 3.5

                                                                     c ISO/IEC 2017 – All rights reserved


                                                                              ISO/IEC DIS 1539-1:2017 (E)

3.93

intrinsic

type, procedure, module, assignment, operator, or input/output operation defined in this document and accessible

without further definition or specification, or a procedure or module provided by a processor but not defined in

this document

3.93.1

standard intrinsic

⟨procedure or module⟩ defined in this document (16)

3.93.2

nonstandard intrinsic

⟨procedure or module⟩ provided by a processor but not defined in this document

3.94

internal file

character variable that is connected to an internal unit (12.4)

3.95

internal unit

input/output unit that is connected to an internal file (12.5.4)

3.96

ISO 10646 character

character whose representation method corresponds to UCS-4 in ISO/IEC 10646

3.97

keyword

statement keyword, argument keyword, type parameter keyword, or component keyword

3.97.1

argument keyword

word that identifies the corresponding dummy argument in an actual argument list (15.5.2.1)

3.97.2

component keyword

word that identifies a component in a structure constructor (7.5.10)

3.97.3

statement keyword

word that is part of the syntax of a statement (5.5.2)

3.97.4

type parameter keyword

word that identifies a type parameter in a type parameter list

3.98

lexical token

keyword, name, literal constant other than a complex literal constant, operator, label, delimiter, comma, =, =>,

:, ::, ;, or % (6.2)

3.99

line

sequence of zero or more characters

3.100

main program

program unit that is not a subprogram, module, submodule, or block data program unit (14.1)

16
c ISO/IEC 2017 – All rights reserved ISO/IEC DIS 1539-1:2017 (E) 3.101
masked array assignment
assignment statement in a WHERE statement or WHERE construct (10.2.3)
3.102
module
program unit containing (or accessing from other modules) definitions that are to be made accessible to other
program units (14.2)
3.103
name
identifier of a program constituent, formed according to the rules given in 6.2.2
3.104
NaN
Not a Number, a symbolic floating-point datum (ISO/IEC/IEEE 60559:2011)
3.105
operand
data value that is the subject of an operator
3.106
operator
intrinsic-operator, defined-unary-op, or defined-binary-op (R608, R1003, R1023)
3.107
passed-object dummy argument
dummy argument of a type-bound procedure or procedure pointer component that becomes associated with the
object through which the procedure is invoked (7.5.4.5)
3.108
pointer
data pointer or procedure pointer
3.108.1
data pointer
data entity with the POINTER attribute (8.5.14)
3.108.2
procedure pointer
procedure with the EXTERNAL and POINTER attributes (8.5.9, 8.5.14)
3.108.3
local procedure pointer
procedure pointer that is part of a local variable, or a named procedure pointer that is not a dummy argument
or accessed by use or host association
3.109
pointer assignment
association of a pointer with a target, by execution of a pointer assignment statement (10.2.2) or an intrinsic
assignment statement (10.2.1.2) for a derived-type object that has the pointer as a subobject
3.110
polymorphic
⟨data entity⟩ able to be of differing dynamic types during program execution (7.3.2.3)
⃝c ISO/IEC 2017 – All rights reserved
	17

3.111

preconnected

⟨file or unit⟩ connected at the beginning of execution of the program (12.5.5)

3.112

procedure

entity encapsulating an arbitrary sequence of actions that can be invoked directly during program execution

3.112.1

dummy procedure

procedure that is a dummy argument (15.2.2.3)

3.112.2

external procedure

procedure defined by an external subprogram (R503) or by means other than Fortran (15.6.3)

3.112.3

internal procedure

procedure defined by an internal subprogram (R512)

3.112.4

module procedure

procedure defined by a module subprogram, or a procedure provided by an intrinsic module (R1408)

3.112.5

pure procedure

procedure declared or defined to be pure (15.7)

3.112.6

type-bound procedure

procedure that is bound to a derived type and referenced via an object of that type (7.5.5)

3.113

processor

combination of a computing system and mechanism by which programs are transformed for use on that computing

system

3.114

processor dependent

not completely specified in this document, having methods and semantics determined by the processor

3.115

program

set of Fortran program units and entities defined by means other than Fortran that includes exactly one main

program

3.116

program unit

main program, external subprogram, module, submodule, or block data program unit (5.2.1)

3.117

rank

number of array dimensions of a data entity (zero for a scalar entity)

3.118

record

sequence of values or characters in a file (12.2)

18
c ISO/IEC 2017 – All rights reserved ISO/IEC DIS 1539-1:2017 (E) 3.119
record file
file composed of a sequence of records (12.1)
3.120
reference
data object reference, procedure reference, or module reference
3.120.1
data object reference
appearance of a data object designator (9.1) in a context requiring its value at that point during execution
3.120.2
function reference
appearance of the procedure designator for a function, or operator symbol for a defined operation, in a context
requiring execution of the function during expression evaluation (15.5.3)
3.120.3
module reference
appearance of a module name in a USE statement (14.2.2)
3.120.4
procedure reference
appearance of a procedure designator, operator symbol, or assignment symbol in a context requiring execution
of the procedure at that point during execution; or occurrence of defined input/output (13.7.6) or derived-type
finalization (7.5.6.2)
3.121
saved
having the SAVE attribute (8.5.16)
3.122
scalar
data entity that can be represented by a single value of the type and that is not an array (9.5)
3.123
scoping unit
BLOCK construct, derived-type definition, interface body, program unit, or subprogram, excluding all nested
scoping units in it
3.123.1
block scoping unit
scoping unit of a BLOCK construct
3.124
sequence
set of elements ordered by a one-to-one correspondence with the numbers 1, 2, to n
3.125
sequence structure
scalar data object of a sequence type (7.5.2.3)
3.126
sequence type
derived type with the SEQUENCE attribute (7.5.2.3)
⃝c ISO/IEC 2017 – All rights reserved
	19

3.126.1

character sequence type

sequence type with no allocatable or pointer components, and whose components are all default character or of

another character sequence type

3.126.2

numeric sequence type

sequence type with no allocatable or pointer components, and whose components are all default complex, default

integer, default logical, default real, double precision real, or of another numeric sequence type

3.127

shape

array dimensionality of a data entity, represented as a rank-one array whose size is the rank of the data entity

and whose elements are the extents of the data entity

     NOTE 3.6

     Thus the shape of a scalar data entity is an array with rank one and size zero.

simply contiguous

⟨array designator or variable⟩ satisfying the conditions specified in 9.5.4

     NOTE 3.7

     These conditions are simple ones which make it clear that the designator or variable designates a contiguous

     array.

size

⟨array⟩ total number of elements in the array

3.130

specification expression

expression satisfying the requirements specified in 10.1.11, thus being suitable for use in specifications

3.131

specific name

name that is not a generic name

3.132

standard-conforming program

program that uses only those forms and relationships described in, and has an interpretation according to, this

document

3.133

statement

sequence of one or more complete or partial lines satisfying a syntax rule that ends in -stmt (6.3)

3.133.1

executable statement

end-function-stmt, end-mp-subprogram-stmt, end-program-stmt, end-subroutine-stmt, or statement that is a mem-

ber of the syntactic class executable-construct, excluding those in the block-specification-part of a BLOCK con-

struct

3.133.2

nonexecutable statement

statement that is not an executable statement

20	⃝c ISO/IEC 2017 – All rights reserved

                                                                              ISO/IEC DIS 1539-1:2017 (E)

statement entity

entity whose identifier has the scope of a statement or part of a statement (19.1, 19.4)

3.135

statement label

label

unsigned positive number of up to five digits that refers to an individual statement (6.2.5)

3.136

storage sequence

contiguous sequence of storage units (19.5.3.2)

3.137

storage unit

character storage unit, numeric storage unit, file storage unit, or unspecified storage unit (19.5.3.2)

3.137.1

character storage unit

unit of storage that holds a default character value (19.5.3.2)

3.137.2

numeric storage unit

unit of storage that holds a default real, default integer, or default logical value (19.5.3.2)

3.137.3

unspecified storage unit

unit of storage that holds a value that is not default character, default real, double precision real, default logical,

or default complex (19.5.3.2)

3.138

stream file

file composed of a sequence of file storage units (12.1)

3.139

structure

scalar data object of derived type (7.5)

3.139.1

structure component

component of a structure

3.139.2

structure constructor

syntax (structure-constructor, 7.5.10) that specifies a structure value or creates such a value

3.140

submodule

program unit that extends a module or another submodule (14.2.3)

3.141

subobject

portion of data object that can be referenced, and if it is a variable defined, independently of any other portion

(9.4.2)

3.142

subprogram

function-subprogram (R1529) or subroutine-subprogram (R1534)

⃝c ISO/IEC 2017 – All rights reserved
	21

3.142.1

external subprogram

subprogram that is not contained in a main program, module, submodule, or another subprogram

3.142.2

internal subprogram

subprogram that is contained in a main program or another subprogram

3.142.3

module subprogram

subprogram that is contained in a module or submodule but is not an internal subprogram

3.143

subroutine

procedure invoked by a CALL statement, by defined assignment, or by some operations on derived-type entities

3.143.1

atomic subroutine

intrinsic subroutine that performs an action on its ATOM argument atomically (16.5)

3.143.2

collective subroutine

intrinsic subroutine that performs a calculation on a team of images without requiring synchronization

3.144

target

entity that is pointer associated with a pointer (19.5.2.2), entity on the right-hand-side of a pointer assignment

statement (R1033), or entity with the TARGET attribute (8.5.17)

3.145

team

ordered set of images created by execution of a FORM TEAM statement, or the initial ordered set of all images

3.145.1

current team

team specified by the most recently executed CHANGE TEAM statement of a CHANGE TEAM construct that

has not completed execution (11.1.5), or initial team if no CHANGE TEAM construct is being executed

3.145.2

initial team

team existing at the beginning of program execution, consisting of all images

3.145.3

parent team

⟨team except for initial team⟩ current team at time of execution of the FORM TEAM statement that created the

team (11.6.9)

3.145.4

team number

−1 which identifies the initial team, or positive integer that identifies a team within its parent team

3.146

transformational function

intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function

22
c ISO/IEC 2017 – All rights reserved ISO/IEC DIS 1539-1:2017 (E) 3.147
type
data type
named category of data characterized by a set of values, a syntax for denoting these values, and a set of operations
that interpret and manipulate the values (7.1)
3.147.1
abstract type
type with the ABSTRACT attribute (7.5.7.1)
3.147.2
declared type
type that a data entity is declared to have, either explicitly or implicitly (7.3.2, 10.1.9)
3.147.3
derived type
type defined by a type definition (7.5) or by an intrinsic module
3.147.4
dynamic type
type of a data entity at a particular point during execution of a program (7.3.2.3, 10.1.9)
3.147.5
extended type
type with the EXTENDS attribute (7.5.7.1)
3.147.6
extensible type
type that may be extended using the EXTENDS clause (7.5.7.1)
3.147.7
extension type
⟨of one type with respect to another⟩ is the same type or is an extended type whose parent type is an extension
type of the other type
3.147.8
intrinsic type
type defined by this document that is always accessible (7.4)
3.147.9
numeric type
one of the types integer, real, and complex
3.147.10
parent type
⟨extended type⟩ type named in the EXTENDS clause
3.147.11
type compatible
compatibility of the type of one entity with respect to another for purposes such as argument association, pointer
association, and allocation (7.3.2)
3.147.12
type parameter
value used to parameterize a type (7.2)
⃝c ISO/IEC 2017 – All rights reserved
	23

3.147.12.1

assumed type parameter

length type parameter that assumes the type parameter value from another entity

     NOTE 3.8

     The other entity is

         • the selector for an associate name,

         • the constant-expr for a named constant of type character, or

         • the effective argument for a dummy argument.

deferred type parameter

length type parameter whose value can change during execution of a program and whose type-param-value is a

colon

3.147.12.3

kind type parameter

type parameter whose value is required to be defaulted or given by a constant expression

3.147.12.4

length type parameter

type parameter whose value is permitted to be assumed, deferred, or given by a specification expression

3.147.12.5

type parameter inquiry

syntax (type-param-inquiry) that is used to inquire the value of a type parameter of a data object (9.4.5)

3.147.12.6

type parameter order

ordering of the type parameters of a type (7.5.3.2) used for derived-type specifiers (derived-type-spec, 7.5.9)

3.148

ultimate argument

nondummy entity with which a dummy argument is associated via a chain of argument associations (15.5.2.3)

3.149

undefined

⟨data object⟩ does not have a valid value

3.150

undefined

⟨pointer⟩ does not have a pointer association status of associated or disassociated (19.5.2.2)

3.151

unit

input/output unit

means, specified by an io-unit, for referring to a file (12.5.1)

3.152

unlimited polymorphic

able to have any dynamic type during program execution (7.3.2.3)

3.153

unsaved

not having the SAVE attribute (8.5.16)

24	⃝c ISO/IEC 2017 – All rights reserved

                                                                             ISO/IEC DIS 1539-1:2017 (E)

variable

data entity that can be defined and redefined during execution of a program

3.154.1

event variable

scalar variable of type EVENT_TYPE (16.10.2.10) from the intrinsic module ISO_FORTRAN_ENV

3.154.2

local variable

variable in a scoping unit that is not a dummy argument or part thereof, is not a global entity or part thereof,

and is not an entity or part of an entity that is accessible outside that scoping unit

3.154.3

lock variable

scalar variable of type LOCK_TYPE (16.10.2.19) from the intrinsic module ISO_FORTRAN_ENV

3.154.4

team variable

scalar variable of type TEAM_TYPE (16.10.2.32) from the intrinsic module ISO_FORTRAN_ENV

3.155

vector subscript

section-subscript that is an array (9.5.3.3.2)

3.156

whole array

array component or array name without further qualification (9.5.2)

⃝c ISO/IEC 2017 – All rights reserved
	25

                            (Blank page)

                                         c ISO/IEC 2017 – All rights reserved


                                                                                     ISO/IEC DIS 1539-1:2017 (E)

  rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions.

      • Characters from the Fortran character set (6.1) are interpreted literally as shown, except where otherwise

        noted.

      • Lower-case italicized letters and words (often hyphenated and abbreviated) represent general syntactic

        classes for which particular syntactic entities shall be substituted in actual statements.

        Common abbreviations used in syntactic terms are:

                                      arg       for    argument       attr   for attribute

                                      decl      for    declaration    def    for definition

                                      desc      for    descriptor     expr   for expression

                                      int       for    integer        op     for operator

                                      spec      for    specifier      stmt   for statement

      • The syntactic metasymbols used are:

                                        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

      • Each syntax rule is given a unique identifying number of the form Rsnn, where s is a one- or two-digit

        clause number and nn is a two-digit sequence number within that clause. The syntax rules are distributed

        as appropriate throughout the text, and are referenced by number as needed. Some rules in Clauses 5 and

        6 are more fully described in later clauses; in such cases, the clause number s is the number of the later

        clause where the rule is repeated.

      • The syntax rules are not a complete and accurate syntax description of Fortran, and cannot be used to

        generate a Fortran parser automatically; where a syntax rule is incomplete, it is restricted by corresponding

        constraints and text.

       NOTE 4.1

       An example of the use of the syntax rules is:

                digit-string                        is   digit [ digit ] ...

       The following are examples of forms for a digit string allowed by the above rule:

             digit

             digit digit

             digit digit digit digit

             digit digit digit digit digit digit digit digit

  ⃝c ISO/IEC 2017 – All rights reserved                                                                           27


  ISO/IEC DIS 1539-1:2017 (E)

        NOTE 4.1 (cont.)

        If particular entities are substituted for digit, actual digit strings might be:

               4

               67

               1999

               10243852

  4.1.2      Constraints

  number and nn is a two- or three-digit sequence number within that clause.

  with the syntax rule number in parentheses. A constraint that is associated with a syntax rule constitutes part of

  the definition of the syntax term defined by the rule. It thus applies in all places where the syntax term appears.

  that of a restriction stated in the text, except that a processor is required to have the capability to detect and

  report violations of constraints (4.2). In some cases, a broad requirement is stated in text and a subset of the

  same requirement is also stated as a constraint. This indicates that a standard-conforming program is required to

  adhere to the broad requirement, but that a standard-conforming processor is required only to have the capability

  of diagnosing violations of the constraint.

  4.1.3      Assumed syntax rules

  following rules are assumed.

  R401      xyz-list                       is  xyz [ , xyz ] ...

  R402      xyz-name                       is  name

  R403      scalar-xyz                     is  xyz

  C401      (R403) scalar-xyz shall be scalar.

  rule.

  4.1.4      Syntax conventions and characteristics

  end-of-line or semicolon, and may be labeled unless it forms part of another statement (such as an IF or WHERE

  statement). Conversely, everything considered to be a source form statement is given a “-stmt” ending in the

  syntax rules.

  hierarchy is described rigorously in the definition of expr (R1022).

  type declaration attribute specifications (for example, “array-spec” in R815), and in a few other cases.

  used. See, for example, “kind-selector” (R706) and “length-selector” (R722).

  28                                                                    ⃝c ISO/IEC 2017 – All rights reserved


                                                                                   ISO/IEC DIS 1539-1:2017 (E)

  4.1.5     Text conventions

  ments and attributes are identified in the text by an upper-case keyword, e.g., “END statement”. The descriptions

  of obsolescent features appear in a smaller type size.

       NOTE 4.2

       This sentence is an example of the type size used for obsolescent features.

  4.2      Conformance

  and if the program has an interpretation according to this document. A program unit (5.2.1) conforms to this

  document if it can be included in a program in a manner that allows the program to be standard conforming.

        (1)     it executes any standard-conforming program in a manner that fulfills the interpretations herein,

                subject to any limits that the processor may impose on the size and complexity of the program;

        (2) it contains the capability to detect and report the use within a submitted program unit of a form

                designated herein as obsolescent, insofar as such use can be detected by reference to the numbered

                syntax rules and constraints;

        (3) it contains the capability to detect and report the use within a submitted program unit of a form or

                relationship that is not permitted by the numbered syntax rules or constraints, including the deleted

                features described in Annex B;

        (4) it contains the capability to detect and report the use within a submitted program unit of an intrinsic

                type with a kind type parameter value not supported by the processor (7.4);

        (5) it contains the capability to detect and report the use within a submitted program unit of source

                form or characters not permitted by Clause 6;

        (6) it contains the capability to detect and report the use within a submitted program of name usage

                not consistent with the scope rules for names, labels, operators, and assignment symbols in Clause

                19;

        (7) it contains the capability to detect and report the use within a submitted program unit of a non-

                standard intrinsic procedure (including one with the same name as a standard intrinsic procedure

                but with different requirements);

        (8) it contains the capability to detect and report the use within a submitted program unit of a non-

                standard intrinsic module;

        (9) it contains the capability to detect and report the use within a submitted program unit of a procedure

                from a standard intrinsic module, if the procedure is not defined by this document or the procedure

                has different requirements from those specified by this document; and

        (10) it contains the capability to detect and report the reason for rejecting a submitted program.

  or report the use of deleted or obsolescent features, or the use of additional forms or relationships.

  do not conflict with the standard forms and relationships. However, a standard-conforming processor may allow

  additional intrinsic procedures even though this could cause a conflict with the name of a procedure in a standard-

  conforming program. If such a conflict occurs and involves the name of an external procedure, the processor is

  permitted to use the intrinsic procedure unless the name has the EXTERNAL attribute (8.5.9) where it is used.

  A standard-conforming program shall not use nonstandard intrinsic procedures or modules that have been added

  by the processor.

  document or may include standard items that are not portable, such as external procedures defined by means

  ⃝c ISO/IEC 2017 – All rights reserved                                                                           29


  ISO/IEC DIS 1539-1:2017 (E)

  other than Fortran, conformance to this document does not ensure that a program will execute consistently on

  all or any standard-conforming processors.

  They shall be provided, with methods or semantics determined by the processor.

  plexity 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.

  dependent facilities.

  4.3      Compatibility

  4.3.1     Previous Fortran standards

                      Table 4.3: Previous editions of the Fortran International Standard

                                          Official designation     Informal name

                                          ISO R 1539-1972          Fortran 66

                                          ISO 1539-1980            Fortran 77

                                          ISO/IEC 1539:1991        Fortran 90

                                          ISO/IEC 1539-1:1997      Fortran 95

                                          ISO/IEC 1539-1:2004      Fortran 2003

                                          ISO/IEC 1539-1:2010      Fortran 2008

  the previous one. Therefore, a Fortran program conforming to an older standard might have a different inter-

  pretation under a newer standard if it invokes an external procedure having the same name as one of the new

  standard intrinsic procedures, unless that procedure is specified to have the EXTERNAL attribute.

  4.3.3     Fortran 2008 compatibility

  an upward compatible extension to the preceding Fortran International Standard, ISO/IEC 1539-1:2010 (Fortran

  2008). Any standard-conforming Fortran 2008 program that does not use any deleted features, and does not use

  any feature identified in this subclause as being no longer permitted, remains standard-conforming under this

  document.

  operation is not supported for the unit specified. This document specifies that the processor-dependent negative

  integer value shall be different from the named constants IOSTAT_EOR or IOSTAT_END from the intrinsic

  module ISO_FORTRAN_ENV.

  contiguous INTENT (INOUT) dummy argument in one iteration of a DO CONCURRENT construct, without

  being previously defined in that iteration, to be defined in another iteration; this document does not permit this.

  30                                                                  ⃝c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

   of a pure subprogram or of a BLOCK construct within a pure subprogram to be volatile (provided it was not

   used); this document does not permit that.

   this document does not permit that.

   data-target; this document does not permit that.

   subobject component with declared type LOCK_TYPE; this document does not permit that.

   ment does not permit that.

   statement, provided it was scalar, nonpolymorphic, and had no deferred type parameters; this document does

   not permit that.

   4.3.4    Fortran 2003 compatibility

   (Fortran 2003). Except as identified in this subclause, any standard-conforming Fortran 2003 program remains

   standard-conforming under this document.

   document specifies that these constructors are not finalized.

   that specified by Fortran 2003.

   merely passed as an actual argument. This document requires an explicit interface for a procedure under the

   conditions listed in 15.4.2.2, regardless of whether the procedure is referenced in the scope.

   a polymorphic allocatable ultimate component, or to be finalizable by an impure final subroutine. These are not

   permitted by this document.

   permitted by this document.

   ment, even when an elemental defined assignment was in scope; this document does not permit assignment from

   a nonconformable array in this context.

   that.

   of a pure subprogram to be volatile (provided it was not used); this document does not permit that.

   4.3.5    Fortran 95 compatibility

   (Fortran 95). Except as identified in this subclause, any standard-conforming Fortran 95 program remains

   standard-conforming under this document.

   ⃝c ISO/IEC 2017 – All rights reserved                                                                         31

  document does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind.

      • Earlier Fortran standards had the concept of printing, meaning that column one of formatted output had

        special meaning for a processor-dependent (possibly empty) set of external files. This could be neither

        detected nor specified by a standard-specified means. The interpretation of the first column is not specified

        by this document.

      • This document specifies a different output format for real zero values in list-directed and namelist output.

      • If the processor distinguishes between positive and negative real zero, this document requires different

        returned values for ATAN2(Y,X) when X < 0 and Y is negative real zero and for LOG(X) and SQRT(X)

        when X is complex with X%RE < 0 and X%IM is negative real zero.

      • This document has fewer restrictions on constant expressions than Fortran 95; this might affect whether a

        variable is considered to be an automatic data object.

      • The form produced by the G edit descriptor with d equal to zero differs from that specified by Fortran 95

        for some values.

  is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard-conforming Fortran 90

  program that does not use one of the deleted features remains standard-conforming under this document.

  connection or the connection is for unformatted input/output. Fortran 90 specified YES.

  dependent. This document specifies that the second argument shall not be zero.

  document does not permit that if both of the different kinds are ASCII, ISO 10646, or default kind.

      • if the processor distinguishes between positive and negative real zero, the result value of the intrinsic function

        SIGN when the second argument is a negative real zero;

      • formatted output of negative real values (when the output value is zero);

      • whether an expression is a constant expression (thus whether a variable is considered to be an automatic

        data object);

      • the G edit descriptor with d equal to zero for some values.

  upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard-conforming Fortran 77 program

  that does not use one of the deleted features noted in Annex B.1 and that does not depend on the differences

  specified here remains standard-conforming under this document. This document restricts the behavior for some

  features that were processor dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program

  that uses one of these processor-dependent features might have a different interpretation under this document, yet

  remain a standard-conforming program. The following Fortran 77 features might have different interpretations

  in this document.

      • Fortran 77 permitted a processor to supply more precision derived from a default real constant than can

        be represented in a default real datum when the constant is used to initialize a double precision real data

        object in a DATA statement. This document does not permit a processor this option.

  32                                                                 ⃝c ISO/IEC 2017 – All rights reserved


                                                                                   ISO/IEC DIS 1539-1:2017 (E)

      • If a named variable that was not in a common block was initialized in a DATA statement and did not have

        the SAVE attribute specified, Fortran 77 left its SAVE attribute processor dependent. This document

        specifies (8.6.7) that this named variable has the SAVE attribute.

      • Fortran 77 specified that the number of characters required by the input list was to be less than or equal

        to the number of characters in the record during formatted input. This document specifies (12.6.4.5.3) that

        the input record is logically padded with blanks if there are not enough characters in the record, unless the

        PAD= specifier with the value ’NO’ is specified in an appropriate OPEN or READ statement.

      • A value of 0 for a list item in a formatted output statement will be formatted in a different form for some

        G edit descriptors. In addition, this document specifies how rounding of values will affect the output field

        form, but Fortran 77 did not address this issue. Therefore, the form produced for certain combinations

        of values and G edit descriptors might differ from that produced by some Fortran 77 processors.

      • Fortran 77 did not permit a processor to distinguish between positive and negative real zero; if the

        processor does so distinguish, the result will differ for the intrinsic function SIGN when the second argument

        is negative real zero, and formatted output of negative real zero will be different.

  4.4      Deleted and obsolescent features

  4.4.1     General

  of Fortran 90 that are not processor dependent. This document identifies two categories of outmoded features.

  The first category, deleted features, consists of features considered to have been redundant in Fortran 77 and

  largely unused in Fortran 90. Those in the second category, obsolescent features, are considered to have been

  redundant in Fortran 90 and Fortran 95, but are still frequently used.

  4.4.2     Nature of deleted features

  Fortran 77; these features were not included in Fortran 95, Fortran 2003, or Fortran 2008, and are not included

  in this document. The second group contains features for which better methods existed in Fortran 90; these

  features were included in Fortran 2008, but are not included in this document.

  4.4.3     Nature of obsolescent features

  programmers use these better methods in new programs and convert existing code to these methods.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                            33

                            (Blank page)

                                         c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

  struct, statement, and expression levels and illustrates their relationships.

       NOTE 5.1

       Constraints and other information related to the rules that do not begin with R5 appear in the appropriate

       clause.

  R501     program                     is   program-unit

                                                 [ program-unit ] ...

  R502     program-unit                is   main-program

                                       or   external-subprogram

                                       or   module

                                       or   submodule

                                       or   block-data

  R1401 main-program                   is   [ program-stmt ]

                                                 [ specification-part ]

                                                 [ execution-part ]

                                                 [ internal-subprogram-part ]

                                                 end-program-stmt

  R503     external-subprogram         is function-subprogram

                                       or subroutine-subprogram

  R1529 function-subprogram            is   function-stmt

                                                 [ specification-part ]

                                                 [ execution-part ]

                                                 [ internal-subprogram-part ]

                                                 end-function-stmt

  R1534 subroutine-subprogram          is   subroutine-stmt

                                                 [ specification-part ]

                                                 [ execution-part ]

                                                 [ internal-subprogram-part ]

                                                 end-subroutine-stmt

  R1404 module                         is   module-stmt

                                                 [ specification-part ]

                                                 [ module-subprogram-part ]

                                                 end-module-stmt

  R1416 submodule                      is   submodule-stmt

                                                 [ specification-part ]

                                                 [ module-subprogram-part ]

                                                 end-submodule-stmt

  R1420    block-data                  is   block-data-stmt

                                                 [ specification-part ]

                                                 end-block-data-stmt

  ⃝c ISO/IEC 2017 – All rights reserved                                                                        35

                                         [ import-stmt ] ...

                                         [ implicit-part ]

                                         [ declaration-construct ] ...

                                         implicit-stmt

                                 or parameter-stmt

                                 or format-stmt

                                 or entry-stmt

                                 or data-stmt

                                 or format-stmt

                                 or entry-stmt

                                 or stmt-function-stmt

                                 or enum-def

                                 or generic-stmt

                                 or interface-block

                                 or parameter-stmt

                                 or procedure-declaration-stmt

                                 or other-specification-stmt

                                 or type-declaration-stmt

                                         [ execution-part-construct ] ...

                                 or format-stmt

                                 or entry-stmt

                                 or data-stmt

                                         [ internal-subprogram ] ...

                                 or subroutine-subprogram

                                         [ module-subprogram ] ...

                                 or subroutine-subprogram

                                 or separate-module-subprogram

                                         [ specification-part ]

                                         [ execution-part ]

                                         [ internal-subprogram-part ]

                                         end-mp-subprogram-stmt

                                 or allocatable-stmt

                                 or asynchronous-stmt

                                                       ISO/IEC DIS 1539-1:2017 (E)

or codimension-stmt

or contiguous-stmt

or dimension-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

or common-stmt

or equivalence-stmt

                            or associate-construct

                            or block-construct

                            or case-construct

                            or change-team-construct

                            or critical-construct

                            or do-construct

                            or if-construct

                            or select-rank-construct

                            or select-type-construct

                            or where-construct

                            or forall-construct

  ISO/IEC DIS 1539-1:2017 (E)

                                         or  return-stmt

                                         or  rewind-stmt

                                         or  stop-stmt

                                         or  sync-all-stmt

                                         or  sync-images-stmt

                                         or  sync-memory-stmt

                                         or  sync-team-stmt

                                         or  unlock-stmt

                                         or  wait-stmt

                                         or  where-stmt

                                         or  write-stmt

                                         or  computed-goto-stmt

                                         or  forall-stmt

  5.2      Program unit concepts

  5.2.1     Program units and scoping units

  external subprogram, a module, a submodule, or a block data program unit.

  made accessible to other program units. A submodule is an extension of a module; it may contain the definitions

  of procedures declared in a module or another submodule. A block data program unit is used to specify initial values for

  data objects in named common blocks.

4 A program unit consists of a set of nonoverlapping scoping units.

        NOTE 5.2

  any number (including zero) of external procedures, and any number (including zero) of other entities defined by

  means other than Fortran. The main program shall be defined by a Fortran main-program program-unit or by

  means other than Fortran, but not both.

  5.2.3     Procedure

  computed which is then used in evaluating the expression.

  procedure pointers.

  38                                                                ⃝c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

  5.2.4    Module

  These definitions include data object declarations, type definitions, procedure definitions, and interface blocks.

  Modules are further described in Clause 14.

  5.2.5    Submodule

2 It may provide definitions (15.6) for procedures whose interfaces are declared (15.4.3.2) in an ancestor module

  or submodule. It may also contain declarations and definitions of other entities, which are accessible in its

  descendants. An entity declared in a submodule is not accessible by use association unless it is a module procedure

  whose interface is declared in the ancestor module. Submodules are further described in Clause 14.

       NOTE 5.3

       A submodule has access to entities in its parent module or submodule by host association.

  5.3     Execution concepts

  5.3.1    Statement classification

2 An executable statement is an instruction to perform or control an action. Thus, the executable statements of a

  program unit determine the behavior of the program unit.

  5.3.2    Statement order

                                Table 5.1: Requirements on statement ordering

                                     PROGRAM, FUNCTION, SUBROUTINE,

                                MODULE, SUBMODULE, or BLOCK DATA statement

                                                    USE statements

                                                 IMPORT statements

                                and       PARAMETER           type declaration statements,

                                                                specification statements,

                                                CONTAINS statement

                                                 Internal subprograms

                                                or module subprograms

                                                    END statement

  rules are illustrated in Table 5.1 and Table 5.2. Table 5.1 shows the ordering rules for statements and applies

  to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of statements that

  may be interspersed and horizontal lines delineate varieties of statements that shall not be interspersed. Internal

  or module subprograms shall follow a CONTAINS statement. Between USE and CONTAINS statements in a

  subprogram, nonexecutable statements generally precede executable statements, although the ENTRY statement,

  FORMAT statement, and DATA statement may appear among the executable statements. Table 5.2 shows which

  statements are allowed in some kinds of scoping units.

                                   Table 5.2: Statements allowed in scoping units

                                                           Kind of scoping unit

                            Main        Module or   Block     External         Module         Internal     Interface

      Statement type      program       submodule   data    subprogram      subprogram      subprogram       body

      USE                     Yes          Yes       Yes         Yes             Yes            Yes           Yes

      IMPORT                  No        Submodule    No          No              Yes            Yes           Yes

      ENTRY                   No           No        No          Yes             Yes             No            No

      FORMAT                  Yes          No        No          Yes             Yes            Yes           No

                    1

      Misc. decl.s            Yes          Yes       Yes         Yes             Yes            Yes           Yes

      DATA                    Yes          Yes       Yes         Yes             Yes            Yes           No

      Derived-type            Yes          Yes       Yes         Yes             Yes            Yes           Yes

      Interface               Yes          Yes       No          Yes             Yes            Yes           Yes

      Executable              Yes          No        No          Yes             Yes            Yes           No

      CONTAINS                Yes          Yes       No          Yes             Yes             No           No

      Statement function      Yes          No        No          Yes             Yes             Yes           No

      (1) Miscellaneous declarations are PARAMETER statements, IMPLICIT statements, type declaration

      statements, enumeration definitions, procedure declaration statements, and specification statements.

  5.3.3     The END statement

  end-program-stmt, end-function-stmt, end-subroutine-stmt, and end-mp-subprogram-stmt statements are execut-

  able, and may be branch target statements (11.2). Executing an end-program-stmt initiates normal termination.

  Executing an end-function-stmt, end-subroutine-stmt, or end-mp-subprogram-stmt is equivalent to executing a

  return-stmt with no scalar-int-expr .

  5.3.4     Program execution

  Each image has its own execution state, floating-point status (17.7), and set of data objects, input/output units,

  and procedure pointers. The image index that identifies an image is an integer value in the range one to the

  number of images in a team.

  team formed by execution of a FORM TEAM statement. The initial team has no parent; every other team has a

  unique parent team. Within its parent team, each team is identified by its team number; this is the integer value

  that was specified in the FORM TEAM statement.

  and END TEAM statements. Image indices, and thus coindexing of variable names with an image-selector, are

  relative to the current team unless a different team is specified. Initially, the current team is the initial team.

  40                                                                 ⃝c ISO/IEC 2017 – All rights reserved


                                                                               ISO/IEC DIS 1539-1:2017 (E)

        NOTE 5.4

        Fortran control constructs (11.1, 11.2) control the progress of execution in each image. Image control

        statements (11.6.1) affect the relative progress of execution between images. Coarrays (5.4.7) provide a

        mechanism for accessing data on one image from another image.

        NOTE 5.5

        A processor might allow the number of images to be chosen at compile time, link time, or run time. It might

        be the same as the number of CPUs but this is not required. Compiling for a single image might permit

        the optimizer to eliminate overhead associated with parallel execution. A program that makes assumptions

        about the number of images is unlikely to be portable.

  5.3.5      Execution sequence

  sequence, in time, of actions. Actions take place during execution of the statement that performs them (except

  when explicitly stated otherwise). Segments (11.6.2) executed by a single image are totally ordered, and segments

  executed by separate images are partially ordered by image control statements (11.6.1).

  of the main program. The execution of a main program or subprogram involves execution of the executable

  constructs within its scoping unit. When a Fortran procedure is invoked, the specification expressions within

  the specification-part of the invoked procedure, if any, are evaluated in a processor dependent order. Thereafter,

  execution proceeds to the first executable construct appearing within the scoping unit of the procedure after the

  invoked entry point. With the following exceptions, the effect of execution is as if the executable constructs are

  executed in the order in which they appear in the main program or subprogram until a STOP, ERROR STOP,

  RETURN, or END statement is executed.

      • Execution of a branching statement (11.2) changes the execution sequence. These statements explicitly

         specify a new starting place for the execution sequence.

      • DO constructs, IF constructs, SELECT CASE constructs, SELECT RANK constructs, and SELECT TYPE

         constructs contain an internal statement structure and execution of these constructs involves implicit in-

         ternal transfer of control. See Clause 11 for the detailed semantics of each of these constructs.

      • A BLOCK construct may contain specification expressions; see 11.1.4 for detailed semantics of this construct.

      • An END=, ERR=, or EOR= specifier (12.11) might result in a branch.

      • An alternate return might result in a branch.

  5.3.6      Image execution states

  ation of execution is a stopped image. An image that has ceased participating in program execution but has not

  initiated termination is a failed image. All other images are active images.

  image to fail are processor dependent.

  with the value STAT_FAILED_IMAGE (16.10.2.26). The value of a reference to a coindexed object on a failed

  image is processor dependent. Execution continues after such a reference.

  if it is not a lock variable or event variable and it might be defined or become undefined by execution of a

  statement of the segment other than an invocation of an atomic subroutine with the object as an actual argument

  corresponding to the ATOM dummy argument.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                           41


  ISO/IEC DIS 1539-1:2017 (E)

  5.3.7      Termination of execution

  occurs only when all images initiate normal termination and occurs in three steps: initiation, synchronization,

  and completion. In this case, all images synchronize execution at the second step so that no image starts the

  completion step until all images have finished the initiation step. Error termination occurs when any image

  initiates error termination. Once error termination has been initiated on an image, error termination is initiated

  on all images that have not already initiated error termination. Termination of execution of the program occurs

  when all images have terminated execution.

  Normal termination of execution of an image also may be initiated during execution of a procedure defined by a

  companion processor (ISO/IEC 9899:2011 5.1.2.2.3 and 7.22.4.4). If normal termination of execution is initiated

  within a Fortran program unit and the program incorporates procedures defined by a companion processor, the

  process of execution termination shall include the effect of executing the C exit() function (ISO/IEC 9899:2011

  7.22.4.4) during the completion step.

  elsewhere in this document. When error termination on an image has been initiated, the processor should initiate

  error termination on other images as quickly as possible.

  other than by an ERROR STOP statement supplies a processor-dependent nonzero value as the process exit

  status.

        NOTE 5.6

        As well as in the circumstances specified in this document, error termination might be initiated by means

        other than Fortran.

        NOTE 5.7

        If an image has initiated normal termination, its data remain available for possible reference or definition

        by other images that are still executing.

  5.4       Data concepts

  5.4.1      Type

  syntax for denoting these values, and the set of operations that interpret and manipulate the values. This central

  concept is described in 7.1.

  5.4.1.1    Intrinsic type

  in 7.4.

  specified type. The intrinsic type character also has a length type parameter called LEN, which determines the

  length of the character string.

  5.4.1.2    Derived type

  is defined intrinsically (10.2.1.3), but there are no intrinsic operations for structures. For each derived type, a

  42                                                                  ⃝c ISO/IEC 2017 – All rights reserved


                                                                               ISO/IEC DIS 1539-1:2017 (E)

  structure constructor is available to create values (7.5.10). In addition, objects of derived type may be used as

  procedure arguments and function results, and may appear in input/output lists. If additional operations are

  needed for a derived type, they shall be defined by procedures (10.1.6).

  5.4.2      Data value

  values of the type parameters. The values for each intrinsic type are described in 7.4. The values that objects of

  a derived type may assume are determined by the type definition, type parameter values, and the sets of values

  of its components.

  5.4.3      Data entity

  5.4.3.1    General

  Every data entity has a rank and is thus either a scalar or an array.

  5.4.3.2    Data object

  named data object may be specified explicitly (8.2) or implicitly (8.7).

  other portions.

  portions of complex objects (real and imaginary parts), and portions of structures (components). Subobjects

  are themselves data objects, but subobjects are referenced only by object designators or intrinsic functions. A

  subobject of a variable is a variable. Subobjects are described in Clause 9.

        • a named scalar                 (a scalar object);

        • a named array                  (an array object).

        • an array element               (a scalar subobject);

        • an array section               (an array subobject);

        • a complex part designator      (the real or imaginary part of a complex object);

        • a structure component          (a scalar or an array subobject);

        • a substring                    (a scalar subobject).

  undefined.

  that scoping unit or construct and in any contained scoping units and constructs.

        NOTE 5.8

        A subobject of a local variable is also a local variable.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                           43


  ISO/IEC DIS 1539-1:2017 (E)

       NOTE 5.8 (cont.)

       A local variable cannot be in COMMON or have the BIND attribute, because common blocks and variables with

       the BIND attribute are global entities.

  5.4.3.2.2   Constant

2 Named constants are defined using the PARAMETER attribute (8.5.13, 8.6.11). The syntax of literal constants

  is described in 7.4.

  5.4.3.2.3   Subobject of a constant

2 In an object designator for a subobject of a constant, the portion referenced may depend on the value of a variable.

       NOTE 5.9

       For example, given:

       CHARACTER (LEN = 10), PARAMETER :: DIGITS = ’0123456789’

       CHARACTER (LEN = 1)                      :: DIGIT

       INTEGER :: I

           ...

       DIGIT = DIGITS (I:I)

       DIGITS is a named constant and DIGITS (I:I) designates a subobject of the constant DIGITS.

1 An expression (10.1) produces a data entity when evaluated. An expression represents either a data object

  reference or a computation; it is formed from operands, operators, and parentheses. The type, type parameters,

  value, and rank of an expression result are determined by the rules in Clause 10.

  5.4.3.4   Function reference

  type, type parameters, and rank of a function result are determined by the interface of the function (15.3.3). The

  value of a function result is determined by execution of the function.

  5.4.4     Definition of objects and pointers

  by execution of an assignment or input statement. When a variable does not have a predictable value, it is

  undefined.

  When the association status of a pointer is not predictable, its pointer association status is undefined.

  pointers becomes defined and undefined.

  5.4.5     Reference

  executed.

  44                                                                 ⃝c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

  a reference to that data object or procedure unless such a reference is necessary to complete the specification of

  the actual argument.

  5.4.6     Array

  array is the total number of elements, which is equal to the product of the extents. An array may have zero

  size. The shape of an array is determined by its rank and its extent in each dimension, and is represented as

  a rank-one array whose elements are the extents. All named arrays shall be declared, and the rank of a named

  array is specified in its declaration. Except for an assumed-rank array, the rank of a named array, once declared,

  is constant; the extents may be constant or may vary during execution.

  performed elementally to produce a resultant array conformable with the array operands. If an elemental operation

  is intrinsically pure or is implemented by a pure elemental function (15.8), the element operations may be

  performed simultaneously or in any order.

  shape (7.8).

  5.4.7     Coarray

  may be a scalar or an array.

  on every other image of a team in which it is established (5.4.8).

  this pattern are the codimensions; the number of codimensions is the corank. The bounds for each codimension

  are the cobounds.

        NOTE 5.10

       If the total number of images is not a multiple of the product of the sizes of each but the rightmost of the

       codimensions, the rectangular pattern will be incomplete.

  accessed without use of cosubscripts.

  selection, or pointer component selection.

  determines the subscript order value for an array element (9.5.3.2).

        NOTE 5.11

        NOTE 5.12

2 An allocated allocatable coarray is established in the team in which it was allocated. An unallocated allocatable

  coarray is not established.

  in the team of its CHANGE TEAM construct.

  construct is established in the team in which the ASSOCIATE, SELECT RANK, or SELECT TYPE statement

  is executed.

  in the team in which the procedure was invoked. A coarray dummy argument is not established in any ancestor

  team even if the corresponding actual argument is established in one or more of them.

  5.4.9     Pointer

2 A pointer that is not associated shall not be referenced or defined.

3 If a data pointer is an array, the rank is declared, but the bounds are determined when it is associated with a

  target.

  5.4.10      Allocatable variables

  allocated as described in 9.7.1.3. It becomes unallocated as described in 9.7.3.2.

3 If an allocatable variable is an array, the rank is declared, but the bounds are determined when it is allocated. If

  an allocatable variable is a coarray, the corank is declared, but the cobounds are determined when it is allocated.

  5.4.11      Storage

  objects. However, program units that include storage association dependent features shall observe the storage

  restrictions described in 19.5.3.

  5.5      Fundamental concepts

  5.5.1     Names and designators

  dummy argument, or derived type.

  46                                                                  ⃝c ISO/IEC 2017 – All rights reserved


                                                                                 ISO/IEC DIS 1539-1:2017 (E)

  5.5.2     Statement keyword

  rules, such keywords appear literally. In descriptive text, this meaning is denoted by the term “keyword” without

  any modifier. Examples of statement keywords are IF, READ, UNIT, KIND, and INTEGER.

  5.5.3     Other keywords

  keyword= rather than their position within the list.

  may appear in an actual argument list. A type parameter keyword is the name of a type parameter in the type

  being specified, and may appear in a type parameter list. A component keyword is the name of a component in

  a structure constructor.

  R516     keyword                        is name

        NOTE 5.13

        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.

  5.5.4     Association

  the same name or different names in different scoping units.

3 Storage association (19.5.3) causes different entities to use the same storage.

4 Inheritance association (19.5.4) occurs between components of the parent component and components inherited

  by type extension.

  5.5.5     Intrinsic

  definition or specification. Intrinsic modules (16.10, 17, 18.2) may be accessed by use association.

  5.5.6     Operator

  numeric operands and the logical operators .AND., .OR., etc. with logical operands). Additional operators may

  be defined within a program (7.5.5, 15.4.3.4).

  5.5.7     Companion processors

  and defines such entities by a means other than Fortran (15.6.3), it may be the Fortran processor itself, or it may

  be another Fortran processor. If there is more than one companion processor, the means by which the Fortran

  processor selects among them are processor dependent.

  refers to the C function that defines the procedure, although the procedure need not be defined by means of the

  C programming language.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                            47

   NOTE 5.14

   A companion processor might or might not be a mechanism that conforms to the requirements of ISO/IEC

   9899:2011. If it does, 5.3.7 states that a program unit that is defined by means other than Fortran and that

   initiates normal termination is required to include the effect of executing the C exit() function.

   For example, a processor might 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.7.6.3 of ISO/IEC 9899:2011.

                                                                                ISO/IEC DIS 1539-1:2017 (E)

  character or a graphic character. The set of graphic characters is further divided into letters (6.1.2), digits (6.1.3),

  underscore (6.1.4), special characters (6.1.5), and other characters (6.1.6).

  letters, digits, and underscore define the syntax class alphanumeric-character.

  R601     alphanumeric-character         is letter

                                          or digit

                                          or underscore

  6.1.5. However, the style of any graphic is not specified.

  6.1.2     Letters

  ISO/IEC DIS 1539-1:2017 (E)

  R1018 not-op                             is   .NOT.

  R1019 and-op                             is   .AND.

  R1020 or-op                              is   .OR.

  R1021 equiv-op                           is .EQV.

                                           or .NEQV.

  R609      defined-operator               is defined-unary-op

                                           or defined-binary-op

                                           or extended-intrinsic-op

  R1003 defined-unary-op                   is   . letter [ letter ] ... .

  R1023 defined-binary-op                  is   . letter [ letter ] ... .

  R610      extended-intrinsic-op          is   intrinsic-operator

  6.2.5      Statement labels

  R611      label                          is   digit [ digit [ digit [ digit [ digit ] ] ] ]

  C603      (R611) At least one digit in a label shall be nonzero.

  be given to more than one statement in its scope. Leading zeros are not significant in distinguishing between

  statement labels. There are 99999 possible 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.

        NOTE 6.4

        For example:

        99999

        10

          010

        are all statement labels. The last two are equivalent.

  with a statement label, but the labels are used only in the following ways.

      • The label on a branch target statement (11.2) is used to identify that statement as the possible destination

         of a branch.

      • The label on a FORMAT statement (13.2.1) is used to identify that statement as the format specification

         for a data transfer statement (12.6).

      • In some forms of the DO construct (11.1.7), the terminal statement of the construct is identified by a label.

  6.2.6      Delimiters

  52                                                                       ⃝c ISO/IEC 2017 – All rights reserved


                                                                                      ISO/IEC DIS 1539-1:2017 (E)

  6.3       Source form

  6.3.1      Program units, statements, and lines

  INCLUDE lines. A line is a sequence of zero or more characters. Lines following a program unit END statement

  are not part of that program unit. A Fortran statement is a sequence of one or more complete or partial lines.

3 There are two source forms. Subclause 6.3.2 applies only to free form source. Subclause 6.3.3 applies only to fixed source

  form. Free form and fixed form shall not be mixed in the same program unit. The means for specifying the source form of a program

  unit are processor dependent.

  6.3.2      Free source form

  6.3.2.1    Free form line length

  a line. A line may contain zero characters. If a line consists entirely of characters of default kind (7.4.4), it may

  contain at most 132 characters. If a line contains any character that is not of default kind, the maximum number

  of characters allowed on the line is processor dependent.

  6.3.2.2    Blank characters in free form

  a format specification. Blanks may be inserted freely between tokens to improve readability; for example, blanks

  may occur between the tokens that form a complex literal constant. A sequence of blank characters outside of a

  character context is equivalent to a single blank character.

        NOTE 6.5

        For example, the blanks after REAL, READ, 30, and DO are required in the following:

1 The accessibility of a type name is determined as specified in 8.5.2. The accessibility of a type name does not

  affect, and is not affected by, the accessibility of its components and type-bound procedures.

  name, and thus the structure constructor (7.5.10) for the type, are accessible only within that module and its

  descendants.

        NOTE 7.16

        An example of a type with a private name is:

        TYPE, PRIVATE :: AUXILIARY

            LOGICAL :: DIAGNOSTIC

            CHARACTER (LEN = 20) :: MESSAGE

                                                                      c ISO/IEC 2017 – All rights reserved


                                                                                 ISO/IEC DIS 1539-1:2017 (E)

            be declared to be of an intrinsic type or of a sequence type, the derived type shall not have any type

            parameter, and a type-bound-procedure-part shall not appear.

  of the component definitions in a sequence type specifies a storage sequence for objects of that type. The type

  is a numeric sequence type if there are no pointer or allocatable components, and each component is default

  integer, default real, double precision real, default complex, default logical, or of numeric sequence type. The

  type is a character sequence type if there are no pointer or allocatable components, and each component is default

  character or of character sequence type.

        NOTE 7.17

        An example of a numeric sequence type is:

1 Derived-type definitions with the same type name may appear in different scoping units, in which case they might

  be independent and describe different derived types or they might describe the same type.

  entities also have the same type if they are declared with reference to different derived-type definitions that specify

  the same type name, all have the SEQUENCE attribute or all have the BIND attribute, have no components

  with PRIVATE accessibility, and have components that agree in order, name, and attributes. Otherwise, they

  are of different derived types. A data entity declared using a type with the SEQUENCE attribute or with the

  BIND attribute is not of the same type as an entity of a type that has any components that are PRIVATE.

        NOTE 7.19

        An example of declaring two entities with reference to the same derived-type definition is:

   NOTE 7.19 (cont.)

                                                                               ISO/IEC DIS 1539-1:2017 (E)

                                                type-param-decl-list

            names in the derived-type-stmt of that derived-type-def .

            a type-param-name in a type-param-def-stmt in that derived-type-def .

                                         or LEN

  integer.

4 If a type-param-decl has a scalar-int-constant-expr, the type parameter has a default value which is specified by

  the expression. If necessary, the value is converted according to the rules of intrinsic assignment (10.2.1.3) to a

  value of the same kind as the type parameter.

  kind type parameter may also be used as a primary in a constant expression (10.1.12) in the derived-type-def .

        NOTE 7.22

        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 potentially nondefault kind for d.

                 REAL (k) :: element (d, d)

                                     or proc-component-def-stmt

                                            component-decl-list

                                     or  ALLOCATABLE

                                     or  CODIMENSION lbracket coarray-spec rbracket

                                     or  CONTIGUOUS

                                     or  DIMENSION ( component-array-spec )

                                     or  POINTER

                                            [ lbracket coarray-spec rbracket ]

                                            [ * char-length ] [ component-initialization ]

                                     or deferred-shape-spec-list

        in the component-def-stmt shall specify an intrinsic type or a previously defined derived type.

        a deferred-shape-spec-list.

        the ALLOCATABLE attribute.

        the intrinsic module ISO_C_BINDING (18.2), or of type TEAM_TYPE from the intrinsic module

        ISO_FORTRAN_ENV (16.10.2).

                                                                  c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

          scalar and shall not be a coarray.

          spec shall be an explicit-shape-spec-list.

          erences to specification functions or the intrinsic functions ALLOCATED, ASSOCIATED, EXTENDS_-

          TYPE_OF, PRESENT, or SAME_TYPE_AS, every specification inquiry reference is a constant ex-

          pression, and the value does not depend on the value of a variable.

          attribute.

          sion in which there are no references to specification functions or the intrinsic functions ALLOCATED,

          ASSOCIATED, EXTENDS_TYPE_OF, PRESENT, or SAME_TYPE_AS, every specification inquiry

          reference is a constant expression, and the value does not depend on the value of a variable.

                                                proc-component-attr-spec-list :: proc-decl-list

                                          or  NOPASS

                                          or  PASS [ (arg-name) ]

                                          or  POINTER

          def-stmt.

          be specified.

          argument named arg-name.

  ponents in the component-decl-list, except that the character length parameter may be specified or overridden

  for a component by the appearance of * char-length in its entity-decl. The component-attr-spec-list in the data-

  component-def-stmt specifies the attributes whose keywords appear for the components in the component-decl-list,

  except that the DIMENSION attribute may be specified or overridden for a component by the appearance of a

  component-array-spec in its component-decl, and the CODIMENSION attribute may be specified or overridden

  for a component by the appearance of a coarray-spec in its component-decl.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                          75


  ISO/IEC DIS 1539-1:2017 (E)

  7.5.4.2    Array components

  stmt contains a DIMENSION clause. If the component-decl contains a component-array-spec, it specifies the

  array rank, and if the array is explicit shape (8.5.8.2), the array bounds; otherwise, the component-array-spec in

  the DIMENSION clause specifies the array rank, and if the array is explicit shape, the array bounds.

       NOTE 7.26

       An example of a derived type definition with an array component is:

1 A data component is a coarray if its component-decl contains a coarray-spec or its data-component-def-stmt

  contains a CODIMENSION clause. If the component-decl contains a coarray-spec it specifies the corank; otherwise,

  the coarray-spec in the CODIMENSION clause specifies the corank.

       NOTE 7.29

       An example of a derived type definition with a coarray component is:

                                                                                 ISO/IEC DIS 1539-1:2017 (E)

1 A passed-object dummy argument is a distinguished dummy argument of a procedure pointer component or

  type-bound procedure (7.5.5). It affects procedure overriding (7.5.7.3) and argument association (15.5.2.2).

  argument.

  procedure pointer component or type-bound procedure is its passed-object dummy argument.

  the procedure pointer component or named type-bound procedure.

  C761      The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy data object

            with the same declared type as the type being defined; all of its length type parameters shall be assumed;

            it shall be polymorphic (7.3.2.3) if and only if the type being defined is extensible (7.5.7). It shall not

            have the VALUE attribute.

        NOTE 7.31

        If a procedure is bound to several types as a type-bound procedure, different dummy arguments might be

        the passed-object dummy argument in different contexts.

  7.5.4.6     Default initialization for components

  associated with specific targets, and nonpointer nonallocatable components to have a particular value. Allocatable

  components are always initialized to unallocated.

  compatible with the target, they have the same rank, all nondeferred type parameters of the pointer have the

  same values as the corresponding type parameters of the target, and the target is contiguous if the pointer has

  the CONTIGUOUS attribute.

  R743      component-initialization       is = constant-expr

                                           or => null-init

                                           or => initial-data-target

  ⃝c ISO/IEC 2017 – All rights reserved                                                                             77


  ISO/IEC DIS 1539-1:2017 (E)

  R744      initial-data-target            is   designator

  C762      (R737) If component-initialization appears, a double-colon separator shall appear before the component-

            decl-list.

  C763      (R737) If component-initialization appears, every type parameter and array bound of the component

            shall be a colon or constant expression.

  C764      (R737) If => appears in component-initialization, POINTER shall appear in the component-attr-spec-

            list. If = appears in component-initialization, neither POINTER nor ALLOCATABLE shall appear in

            the component-attr-spec-list.

  C765      If initial-data-target appears in a component-initialization in a component-decl, component-name shall be

            data-pointer-initialization compatible with it.

  C766      A designator that is an initial-data-target shall designate a nonallocatable, noncoindexed variable that

            has the TARGET and SAVE attributes and does not have a vector subscript. Every subscript, sec-

            tion subscript, substring starting point, and substring ending point in designator shall be a constant

            expression.

  status of disassociated (3.61) or becomes disassociated as specified in 19.5.2.4.

  associated with the target or becomes associated with the target as specified in 19.5.2.3.

  object of the type is initially associated with the target or becomes associated with the target as specified in

  19.5.2.3.

  (19.6.3) or becomes defined as specified in 19.6.5 with the value determined from constant-expr. If necessary,

  the value is converted according to the rules of intrinsic assignment (10.2.1.3) to a value that agrees in type,

  type parameters, and shape with the component. If the component is of a type for which default initialization is

  specified for a component, the default initialization specified by constant-expr overrides the default initialization

  specified for that component. When one initialization overrides another it is as if only the overriding initialization

  were specified (see NOTE 7.33). Explicit initialization in a type declaration statement (8.2) overrides default

  initialization (see NOTE 7.32). Unlike explicit initialization, default initialization does not imply that the object

  has the SAVE attribute.

  initialization for that component, and the subcomponent is not a subobject of an object that is default-initialized

  or explicitly initialized.

  object has default initialization if it is of a type that has default initialization.

        NOTE 7.32

        It is not required that initialization be specified for each component of a derived type. For example:

                                                                           ISO/IEC DIS 1539-1:2017 (E)

The default initial value of a component of derived type can be overridden by default initialization specified

in the definition of the type. Continuing the example of NOTE 7.32:

                                                                       c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

The following example illustrates the use of an individual component access-spec to override the default

accessibility:

                                                  [ binding-private-stmt ]

                                                  [ type-bound-proc-binding ] ...

          a module.

                                         or type-bound-generic-stmt

                                         or final-procedure-stmt

                                         or PROCEDURE (interface-name), binding-attr-list :: binding-name-list

          that has an explicit interface.

          binding-name within that derived type definition.

  with a procedure name the same as the binding name.

  R751    type-bound-generic-stmt        is   GENERIC [ , access-spec ] :: generic-spec => binding-name-list

  C772    (R751) Within the specification-part of a module, each type-bound-generic-stmt shall specify, either im-

          plicitly or explicitly, the same accessibility as every other type-bound-generic-stmt with that generic-spec

          in the same derived type.

  C773    (R751) Each binding-name in binding-name-list shall be the name of a specific binding of the type.

  C774    A binding-name in a type-bound GENERIC statement shall not specify a specific binding that was

          inherited or specified previously for the same generic identifier in that derived type definition.

  C775    (R751) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object dummy

          argument (7.5.4.5).

  ⃝c ISO/IEC 2017 – All rights reserved                                                                            81


  ISO/IEC DIS 1539-1:2017 (E)

  C776     (R751) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall be as

           specified in 15.4.3.4.2.

  C777     (R751) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified in

           15.4.3.4.3.

  C778     (R751) If generic-spec is defined-io-generic-spec, the interface of each binding shall be as specified in

           12.6.4.8. The type of the dtv argument shall be type-name.

  R752     binding-attr                  is  access-spec

                                         or  DEFERRED

                                         or  NON_OVERRIDABLE

                                         or  NOPASS

                                         or  PASS [ (arg-name) ]

  C779     (R752) The same binding-attr shall not appear more than once in a given binding-attr-list.

  C780     (R749) If the interface of the binding has no dummy argument of the type being defined, NOPASS shall

           appear.

  C781     (R749) If PASS (arg-name) appears, the interface of the binding shall have a dummy argument named

           arg-name.

  C782     (R752) PASS and NOPASS shall not both appear in the same binding-attr-list.

  C783     (R752) NON_OVERRIDABLE and DEFERRED shall not both appear in the same binding-attr-list.

  C784     (R752) DEFERRED shall appear if and only if interface-name appears.

  C785     (R749) An overriding binding (7.5.7.3) shall have the DEFERRED attribute only if the binding it over-

           rides is deferred.

  C786     (R749) A binding shall not override an inherited binding (7.5.7.2) that has the NON_OVERRIDABLE

           attribute.

  procedure can have a passed-object dummy argument (7.5.4.5). A type-bound procedure with the DEFERRED

  attribute is a deferred type-bound procedure. The DEFERRED keyword shall appear only in the definition of

  an abstract type.

  specific type-bound procedures.

  subroutine. These are referred to as specific bindings, generic bindings, and final bindings respectively.

  binding-name for a specific type-bound procedure, and the generic-name for a generic binding whose generic-spec

  is generic-name. A final binding, or a generic binding whose generic-spec is not generic-name, has no binding

  name.

  interface specified by interface-name.

  additional GENERIC statement with the same generic-spec extends the generic interface.

       NOTE 7.42

       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 (19.3).

  82                                                                ⃝c ISO/IEC 2017 – All rights reserved


                                                                                 ISO/IEC DIS 1539-1:2017 (E)

  private-stmt, and public otherwise. The accessibility of a type-bound procedure may be explicitly declared by an

  access-spec; otherwise its accessibility is the default for the type definition in which it is declared.

  is accessible only within the module containing the type definition, and within its descendants.

        NOTE 7.43

        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.

        NOTE 7.44

        An example of a type and a type-bound procedure is:

1 An extended type includes all of the type parameters, all of the components, and the nonoverridden (7.5.7.3)

  type-bound procedures of its parent type. These are inherited by the extended type from the parent type. They

  ⃝c ISO/IEC 2017 – All rights reserved                                                                            85


  ISO/IEC DIS 1539-1:2017 (E)

  retain all of the attributes that they had in the parent type. Additional type parameters, components, and

  procedure bindings may be declared in the derived-type definition of the extended type.

        NOTE 7.52

        Inaccessible components and bindings of the parent type are also inherited, but they remain inaccessible in

        the extended type. Inaccessible entities occur if the type being extended is accessed via use association and

        has a private entity.

        NOTE 7.53

        An extensible derived 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.

  of the parent type. The name of this component is the parent type name. If the extended type is defined in a

  module, the parent component has the accessibility of the parent type in the module in which the parent type

  was defined. Components of the parent component are inheritance associated (19.5.4) with the corresponding

  components inherited from the parent type. An ancestor component of a type is the parent component of the

  type or an ancestor component of the parent component.

  the generic interface and shall satisfy the requirements specified in 15.4.3.4.5.

        NOTE 7.54

        A component or type parameter declared in an extended type cannot have the same name as any accessible

        component or type parameter of its parent type.

        NOTE 7.55

        Examples:

        TYPE POINT                                     ! A base type

           REAL :: X, Y

1 The component value of

      • a pointer component is its pointer association,

      • an allocatable component is its allocation status and, if it is allocated, its dynamic type and type parameters,

        bounds and value, and

      • a nonpointer nonallocatable component is its value.

  components.

  7.5.9     Derived-type specifier

  R754     derived-type-spec             is  type-name [ ( type-param-spec-list ) ]

  R755     type-param-spec               is  [ keyword = ] type-param-value

  C791     (R754) type-name shall be the name of an accessible derived type.

  C792     (R754) type-param-spec-list shall appear only if the type is parameterized.

  C793     (R754) 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.

  C794     (R755) The keyword= may be omitted from a type-param-spec only if the keyword= has been omitted

           from each preceding type-param-spec in the type-param-spec-list.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                             87


  ISO/IEC DIS 1539-1:2017 (E)

  C795     (R755) Each keyword shall be the name of a parameter of the type.

  C796     (R755) An asterisk may be used as a type-param-value in a type-param-spec only in the declaration of a

           dummy argument or associate name or in the allocation of a dummy argument.

  parameter order (7.5.3.2). If a type parameter keyword appears, the value corresponds to the type parameter

  named by the keyword. If necessary, the value is converted according to the rules of intrinsic assignment (10.2.1.3)

  to a value of the same kind as the type parameter.

  7.5.10      Construction of derived-type values

  scalar values of that derived type. The type and type parameters of a constructed value are specified by a derived

  type specifier.

  R756     structure-constructor          is  derived-type-spec ( [ component-spec-list ] )

  R757     component-spec                 is  [ keyword = ] component-data-source

  R758     component-data-source          is expr

                                          or data-target

                                          or proc-target

  C797     (R756) The derived-type-spec shall not specify an abstract type (7.5.7).

  C798     (R756) At most one component-spec shall be provided for a component.

  C799     (R756) 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.

  C7100 (R756) A component-spec shall be provided for a nonallocatable component unless it has default initializ-

           ation or is inheritance associated with a subcomponent of another component for which a component-spec

           is provided.

  C7101 (R757) The keyword= may be omitted from a component-spec only if the keyword= has been omitted

           from each preceding component-spec in the constructor.

  C7102 (R757) Each keyword shall be the name of a component of the type.

  C7103 (R756) 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.

  C7104 (R756) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list

           shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to

           that name (15.5.5.2).

  C7105 (R758) A data-target shall correspond to a data pointer component; a proc-target shall correspond to a

           procedure pointer component.

  C7106 (R758) A data-target shall have the same rank as its corresponding component.

       NOTE 7.57

       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.

  88                                                                   ⃝c ISO/IEC 2017 – All rights reserved


                                                                              ISO/IEC DIS 1539-1:2017 (E)

  in component order (7.5.4.7). If a component keyword appears, the expr is assigned to the component named

  by the keyword. For a nonpointer component, the declared type and type parameters of the component and

  expr shall conform in the same way as for a variable and expr in an intrinsic assignment statement (10.2.1.2).

  If necessary, each value of intrinsic type is converted according to the rules of intrinsic assignment (10.2.1.3) to

  a value that agrees in type and type parameters with the corresponding component of the derived type. For a

  nonpointer nonallocatable component, the shape of the expression shall conform with the shape of the component.

  ization is applied to that component. If an allocatable component has no corresponding component-data-source,

  then that component has an allocation status of unallocated.

        NOTE 7.58

        Because no parent components appear in the defined component ordering, a value for a parent component

        can be specified only with a component keyword. Examples of equivalent values using types defined in

        NOTE 7.55:

        ! 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.

5 For a pointer component, the corresponding component-data-source shall be an allowable data-target or proc-

  target for such a pointer in a pointer assignment statement (10.2.2). If the component data source is a pointer,

  the association of the component is that of the pointer; otherwise, the component is pointer associated with the

  component data source.

        NOTE 7.59

        For example, if the variable TEXT were declared (8.2) to be

                 CHARACTER, DIMENSION (1:400), TARGET :: TEXT

        and BIBLIO were declared using the derived-type definition REFERENCE in NOTE 7.30

                 TYPE (REFERENCE) :: BIBLIO

        the statement

                 BIBLIO = REFERENCE (1, 1987, 1, "This is the title of the referenced &

                                                        &paper", SYNOPSIS=TEXT)

        is valid and associates the pointer component SYNOPSIS of the object BIBLIO with the target object

        TEXT. The keyword SYNOPSIS is required because the fifth component of the type REFERENCE is a

        procedure pointer component, not a data pointer component of type character. It is not necessary to specify

        a proc-target for the procedure pointer component because it has default initialization.

  to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, or shall evaluate to

  an entity of the same rank. If the expression is a reference to the intrinsic function NULL, the corresponding

  component of the constructor has a status of unallocated.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                            89


  ISO/IEC DIS 1539-1:2017 (E)

  constructor has the same allocation status as that allocatable entity. If it is allocated, it has the same bounds;

  if a length parameter of the component is deferred, its value is the same as the corresponding parameter of the

  expression. If the component is polymorphic, it has the same dynamic type and value; otherwise, it has the value

  converted, if necessary, to the declared type of the component.

  status of allocated and the same bounds as the expression; if a length parameter of the component is deferred,

  its value is the same as the corresponding parameter of the expression. If the component is polymorphic, it has

  the same dynamic type and value; otherwise, it has the value converted, if necessary, to the declared type of the

  component.

        NOTE 7.60

        This example illustrates a derived-type constant expression using a derived type defined in NOTE 7.15:

                 PERSON (21, ’JOHN SMITH’)

        This could also be written as

                 PERSON (NAME = ’JOHN SMITH’, AGE = 21)

        NOTE 7.61

        An example constructor using the derived type GENERAL_POINT defined in NOTE 7.22 is

                 general_point(dim=3) ( [ 1., 2., 3. ] )

  7.5.11      Derived-type operations and assignment

  operations on derived-type entities. Any operation on derived-type entities or defined assignment (10.2.1.4) for

  derived-type entities shall be defined explicitly by a function or a subroutine, and a generic interface (7.5.5,

  15.4.3.2).

  7.6      Enumerations and enumerators

  specifies the enumeration and its set of enumerators of the corresponding integer kind.

  R759     enum-def                      is  enum-def-stmt

                                                 enumerator-def-stmt

                                                 [ enumerator-def-stmt ] ...

                                                 end-enum-stmt

  R760     enum-def-stmt                 is  ENUM, BIND(C)

  R761     enumerator-def-stmt           is  ENUMERATOR [ :: ] enumerator-list

  R762     enumerator                    is  named-constant [ = scalar-int-constant-expr ]

  R763     end-enum-stmt                 is  END ENUM

  C7107 (R761) If = appears in an enumerator, a double-colon separator shall appear before the enumerator-list.

  corresponding C enumeration type. The corresponding C enumeration type is the type that would be declared

  by a C enumeration specifier (6.7.2.2 of ISO/IEC 9899:2011) that specified C enumeration constants with the

  same values as those specified by the enum-def , in the same order as specified by the enum-def .

  90                                                                 ⃝c ISO/IEC 2017 – All rights reserved


                                                                                ISO/IEC DIS 1539-1:2017 (E)

  enumeration specifiers that specify the same values in the same order.

       NOTE 7.62

       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

       C enumerators might not be representable in this signed integer type. The types of any such enumerators

       will be interoperable with the type declared in the C enumeration.

       NOTE 7.63

       ISO/IEC 9899:2011 guarantees the enumeration constants fit in a C int (6.7.2.2 of ISO/IEC 9899:2011).

       Therefore, the Fortran processor can evaluate all enumerator values using the integer type with kind para-

       meter C_INT, and then determine the kind parameter of the integer type that is interoperable with the

       corresponding C enumerated type.

       NOTE 7.64

       ISO/IEC 9899:2011 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 document 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.

  defined in accordance with the rules of intrinsic assignment (10.2) with the value determined as follows.

         (1)   If scalar-int-constant-expr is specified, the value of the enumerator is the result of scalar-int-constant-

               expr.

         (2)   If scalar-int-constant-expr is not specified and the enumerator is the first enumerator in enum-def ,

               the enumerator has the value 0.

         (3)   If scalar-int-constant-expr is not specified and the enumerator is not the first enumerator in enum-

               def , its value is the result of adding 1 to the value of the enumerator that immediately precedes it

               in the enum-def .

       NOTE 7.65

       Example of an enumeration definition:

       ENUM, BIND(C)

          ENUMERATOR :: RED = 4, BLUE = 9

       NOTE 7.66

       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.

  sequence of bits. Such a constant has no type.

  R764     boz-literal-constant          is binary-constant

                                         or octal-constant

                                         or hex-constant

  R765     binary-constant               is B ’ digit [ digit ] ... ’

                                         or B " digit [ digit ] ... "

  C7108 (R765) digit shall have one of the values 0 or 1.

  R766     octal-constant                is O ’ digit [ digit ] ... ’

                                         or O " digit [ digit ] ... "

  C7109 (R766) digit shall have one of the values 0 through 7.

  R767     hex-constant                  is Z ’ hex-digit [ hex-digit ] ... ’

                                         or Z " hex-digit [ hex-digit ] ... "

  R768     hex-digit                     is   digit

                                         or   A

                                         or   B

                                         or   C

                                         or   D

                                         or   E

                                         or   F

  by their lower-case equivalents. Each digit of a boz-literal-constant represents a sequence of bits, according to

  its numerical interpretation, using the model of 16.3, with z equal to one for binary constants, three for octal

  constants or four for hexadecimal constants. A boz-literal-constant represents a sequence of bits that consists of

  the concatenation of the sequences of bits represented by its digits, in the order the digits are specified. The

  positions of bits in the sequence are numbered from right to left, with the position of the rightmost bit being zero.

  The length of a sequence of bits is the number of bits in the sequence. The processor shall allow the position

  of the leftmost nonzero bit to be at least z − 1, where z is the maximum value that could result from invoking

  the intrinsic function STORAGE_SIZE (16.9.184) with an argument that is a real or integer scalar of any kind

  supported by the processor.

  C7110 (R764) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where

           explicitly allowed in subclause 16.9 as an actual argument of an intrinsic procedure.

  7.8      Construction of array values

  DO loops.

  R769     array-constructor             is (/ ac-spec /)

                                         or lbracket ac-spec rbracket

  92                                                                  ⃝

                                                                      c ISO/IEC 2017 – All rights reserved


                                                                                  ISO/IEC DIS 1539-1:2017 (E)

  R770     ac-spec                        is type-spec ::

                                          or [type-spec ::] ac-value-list

  R771     lbracket                       is  [

  R772     rbracket                       is  ]

  R773     ac-value                       is expr

                                          or ac-implied-do

  R774     ac-implied-do                  is  ( ac-value-list , ac-implied-do-control )

  R775     ac-implied-do-control          is  [ integer-type-spec :: ] ac-do-variable = scalar-int-expr ,

                                                  scalar-int-expr [ , scalar-int-expr ]

  R776     ac-do-variable                 is  do-variable

  C7111 (R770) If type-spec is omitted, each ac-value expression in the array-constructor shall have the same

           declared type and kind type parameters.

  C7112 (R770) 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

           10.8.

  C7113 (R770) If type-spec specifies a derived type, the declared type of each ac-value expression in the array-

           constructor shall be that derived type and shall have the same kind type parameter values as specified

           by type-spec.

  C7114 (R773) An ac-value shall not be unlimited polymorphic.

  C7115 (R773) The declared type of an ac-value shall not be abstract.

  C7116 (R774) 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.

  shall have the same value; in this case, the declared type and type parameters of the array constructor are those

  of the ac-value expressions.

  expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this type and

  type parameters. Each value is converted to the type and type parameters of the array-constructor in accordance

  with the rules of intrinsic assignment (10.2.1.3).

5 The character length of an ac-value in an ac-implied-do whose iteration count is zero shall not depend on the

  value of the ac-do-variable and shall not depend on the value of an expression that is not a constant expression.

  an array expression, the values of the elements of the expression, in array element order (9.5.3.2), specify the

  corresponding sequence of elements of the array constructor. If an ac-value is an ac-implied-do, it is expanded to

  form a sequence of elements under the control of the ac-do-variable, as in the DO construct (11.1.7.4).

8 An empty sequence forms a zero-sized array.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                          93

   NOTE 7.67

   A one-dimensional array can be reshaped into any allowable array shape using the intrinsic function RE-

   SHAPE (16.9.163). 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 7.68

   Examples of array constructors containing an implied DO are:

   (/ (I, I = 1, 1075) /)

   and

   [ 3.6, (3.6 / I, I = 1, N) ]

   NOTE 7.69

   Using the type definition for PERSON in NOTE 7.15, an example of the construction of a derived-type

   array value is:

   [ PERSON (40, ’SMITH’), PERSON (20, ’JONES’) ]

   NOTE 7.70

   Using the type definition for LINE in NOTE 7.26, an example of the construction of a derived-type scalar

   value with a rank-2 array component is:

   LINE (RESHAPE ( [ 0.0, 0.0, 1.0, 2.0 ], [ 2, 2 ] ), 0.1, 1)

   The intrinsic function RESHAPE is used to construct a value that represents a solid line from (0, 0) to (1,

   2) of width 0.1 centimeters.

   NOTE 7.71

   Examples of zero-size array constructors are:

       [ INTEGER :: ]

       [ ( I, I = 1, 0) ]

   NOTE 7.72

   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.

                                                                                   ISO/IEC DIS 1539-1:2017 (E)

  uses of the object. Collectively, these properties are the attributes of the object. The declared type of a named

  data object is either specified explicitly in a type declaration statement or determined implicitly by the first letter

  of its name (8.7). All of its attributes may be specified in a type declaration statement or individually in separate

  specification statements.

  the function. The type, rank, and type parameters are the same as those of the function result.

  uses of the subroutine.

  8.2      Type declaration statement

  R801     type-declaration-stmt           is  declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl-list

  and type parameters are those specified by declaration-type-spec, except that the character length type parameter

  may be overridden for an entity by the appearance of * char-length in its entity-decl.

  R802     attr-spec                       is  access-spec

                                           or  ALLOCATABLE

                                           or  ASYNCHRONOUS

                                           or  CODIMENSION lbracket coarray-spec rbracket

                                           or  CONTIGUOUS

                                           or  DIMENSION ( array-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

  C801     (R801) The same attr-spec shall not appear more than once in a given type-declaration-stmt.

  C802     (R801) If a language-binding-spec with a NAME= specifier appears, the entity-decl-list shall consist of a

           single entity-decl.

  C803     (R801) If a language-binding-spec is specified, the entity-decl-list shall not contain any procedure names.

  ⃝c ISO/IEC 2017 – All rights reserved                                                                               95


  ISO/IEC DIS 1539-1:2017 (E)

  the DIMENSION attribute may be specified or overridden for an entity by the appearance of array-spec in its

  entity-decl, and the CODIMENSION attribute may be specified or overridden for an entity by the appearance of

  coarray-spec in its entity-decl.

  R803      entity-decl                        is  object-name [ ( array-spec ) ]

                                                       [ lbracket coarray-spec rbracket ]

                                                       [ * char-length ] [ initialization ]

                                               or function-name [ * char-length ]

  C804      (R803) If the entity is not of type character, * char-length shall not appear.

  C805      (R801) If initialization appears, a double-colon separator shall appear before the entity-decl-list.

  C806      (R801) If the PARAMETER keyword appears, initialization shall appear in each entity-decl.

  C807      (R803) An initialization shall not appear if object-name is a dummy argument, a function result, an object

            in a named common block unless the type declaration is in a block data program unit, an object in blank common, an

            allocatable variable, or an automatic data object.

  C808      (R803) The function-name shall be the name of an external function, an intrinsic function, a dummy

            function, a procedure pointer, or a statement function.

  R804      object-name                        is  name

  C809      (R804) The object-name shall be the name of a data object.

  R805      initialization                     is = constant-expr

                                               or => null-init

                                               or => initial-data-target

  R806      null-init                          is  function-reference

  C810      (R803) If => appears in initialization, the entity shall have the POINTER attribute. If = appears in

            initialization, the entity shall not have the POINTER attribute.

  C811      (R803) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it

            (7.5.4.6).

  C812      (R806) The function-reference shall be a reference to the intrinsic function NULL with no arguments.

  required; however, it is permitted.   Specifying a type for a generic intrinsic function name in a type declaration

  statement has no effect.

      • its type and type parameters shall conform as specified for intrinsic assignment (10.2.1.2);

      • if the entity has implied shape, the rank of initialization shall be the same as the rank of the entity;

      • if the entity does not have implied shape, initialization shall either be scalar or have the same shape as the

         entity.

        NOTE 8.1

        Examples of type declaration statements:

                  REAL A (10)

                  LOGICAL, DIMENSION (5, 5) :: MASK1, MASK2

                  COMPLEX :: CUBE_ROOT = (-0.5, 0.866)

                  INTEGER, PARAMETER :: SHORT = SELECTED_INT_KIND (4)

                                                                                    ISO/IEC DIS 1539-1:2017 (E)

                 INTEGER (SHORT) K             ! Range at least -9999 to 9999.

                 REAL (KIND (0.0D0)) B1

                 REAL (KIND = 2) B2

                 COMPLEX (KIND = KIND (0.0D0)) :: C

                 CHARACTER (LEN = 10, KIND = 2) TEXT2

                 CHARACTER CHAR, STRING *20

                 TYPE (PERSON) :: CHAIRMAN

                 TYPE(NODE), POINTER :: HEAD => NULL ( )

                 TYPE (humongous_matrix (k=8, d=1000)) :: MAT