IBM XL Fortran for AIX, V14.1
Language Reference
Version 14.1
SC14-7337-00


IBM XL Fortran for AIX, V14.1
Language Reference
Version 14.1
SC14-7337-00

Note
Before using this information and the product it supports, read the information in “Notices” on page 881.
First edition
This edition applies to IBM XL Fortran for AIX, V14.1 (Program 5765-J04; 5725-C74) and to all subsequent releases
and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the
level of the product.
© Copyright IBM Corporation 1996, 2012.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.

Contents
About this document . . . . . . . . xiii
Chapter 3. Intrinsic data types
. . . . 35
Who should read this document .
.
.
.
.
.
. xiii
Integer .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
How to use this document .
.
.
.
.
.
.
.
. xiii
Real .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 36
How this document is organized .
.
.
.
.
.
. xiii
Complex .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
Conventions .
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Logical .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Related information .
.
.
.
.
.
.
.
.
.
. xviii
Character .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
IBM XL Fortran information .
.
.
.
.
.
. xviii
Examples of character constants
.
.
.
.
.
. 43
Standards and specifications
.
.
.
.
.
.
. xix
Character substrings .
.
.
.
.
.
.
.
.
. 44
Other IBM information
.
.
.
.
.
.
.
.
. xx
Byte (IBM extension) .
.
.
.
.
.
.
.
.
.
. 45
Technical support .
.
.
.
.
.
.
.
.
.
.
. xx
Vector (IBM extension).
.
.
.
.
.
.
.
.
.
. 45
How to send your comments
.
.
.
.
.
.
.
. xx
Pixel (IBM extension) .
.
.
.
.
.
.
.
.
.
. 46
Unsigned (IBM extension)
.
.
.
.
.
.
.
.
. 46
Chapter 1. XL Fortran for AIX
. . . . . 1
Fortran language standards
.
.
.
.
.
.
.
.
. 1
Chapter 4. Derived types . . . . . . . 47
Fortran 2008
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Syntax of a derived type .
.
.
.
.
.
.
.
.
. 47
Fortran 2003
.
.
.
.
.
.
.
.
.
.
.
.
. 2
Derived type parameters (Fortran 2003) .
.
.
.
. 48
Fortran 95 .
.
.
.
.
.
.
.
.
.
.
.
.
. 2
Derived type components
.
.
.
.
.
.
.
.
. 49
Fortran 90 .
.
.
.
.
.
.
.
.
.
.
.
.
. 2
Allocatable components .
.
.
.
.
.
.
.
. 50
FORTRAN 77 .
.
.
.
.
.
.
.
.
.
.
.
. 2
Pointer components
.
.
.
.
.
.
.
.
.
. 51
IBM extensions
.
.
.
.
.
.
.
.
.
.
.
. 3
Procedure pointer components .
.
.
.
.
.
. 52
OpenMP API Version 3.1 .
.
.
.
.
.
.
.
.
. 3
Array components .
.
.
.
.
.
.
.
.
.
. 53
Standards documents
.
.
.
.
.
.
.
.
.
.
. 3
Default initialization for components .
.
.
.
. 53
Component order .
.
.
.
.
.
.
.
.
.
. 54
Chapter 2. XL Fortran language
Referencing components .
.
.
.
.
.
.
.
. 54
fundamentals . . . . . . . . . . . . 5
Component and procedure accessibility .
.
.
.
. 56
Sequence derived types .
.
.
.
.
.
.
.
.
. 57
Characters .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
Extensible derived types (Fortran 2003) .
.
.
.
. 57
Names .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Abstract types and deferred bindings (Fortran 2003) 58
Designators .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Derived type Values
.
.
.
.
.
.
.
.
.
.
. 59
Operators .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Type-bound procedures (Fortran 2003) .
.
.
.
. 59
Statements .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Syntax of a type-bound procedure .
.
.
.
.
. 59
Statement keywords .
.
.
.
.
.
.
.
.
.
. 7
Specific binding .
.
.
.
.
.
.
.
.
.
.
. 60
Statement labels .
.
.
.
.
.
.
.
.
.
.
. 7
Generic binding .
.
.
.
.
.
.
.
.
.
.
. 61
Delimiters .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Final binding .
.
.
.
.
.
.
.
.
.
.
.
. 63
Lines and source formats .
.
.
.
.
.
.
.
.
. 8
Procedure overriding .
.
.
.
.
.
.
.
.
. 65
Fixed source form
.
.
.
.
.
.
.
.
.
.
. 9
Finalization (Fortran 2003)
.
.
.
.
.
.
.
.
. 66
Free source form.
.
.
.
.
.
.
.
.
.
.
. 11
The finalization process .
.
.
.
.
.
.
.
. 66
IBM free source form (IBM extension)
.
.
.
. 12
When finalization occurs .
.
.
.
.
.
.
.
. 67
Conditional compilation (IBM extension)
.
.
. 13
Determining declared type for derived types .
.
. 67
Order of statements and execution sequence .
.
. 14
Structure constructor .
.
.
.
.
.
.
.
.
.
. 69
Data types.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 15
Type declaration: type parameters and specifiers
15
Determining Type .
.
.
.
.
.
.
.
.
.
. 17
Chapter 5. Array concepts . . . . . . 73
Data objects .
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Array basics .
.
.
.
.
.
.
.
.
.
.
.
.
. 73
Constants .
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Bounds of a dimension
.
.
.
.
.
.
.
.
. 73
Automatic objects .
.
.
.
.
.
.
.
.
.
. 18
Extent of a dimension .
.
.
.
.
.
.
.
.
. 74
Polymorphic entities (Fortran 2003)
.
.
.
.
. 18
Rank, shape, and size of an array .
.
.
.
.
. 74
Definition status of variables
.
.
.
.
.
.
. 19
Array declarators
.
.
.
.
.
.
.
.
.
.
.
. 74
Allocation status.
.
.
.
.
.
.
.
.
.
.
. 25
Explicit-shape arrays .
.
.
.
.
.
.
.
.
.
. 75
Storage classes for variables (IBM extension) .
. 26
Automatic arrays
.
.
.
.
.
.
.
.
.
.
. 76
Typeless literal constants .
.
.
.
.
.
.
.
.
. 28
Adjustable arrays
.
.
.
.
.
.
.
.
.
.
. 77
Hexadecimal constants
.
.
.
.
.
.
.
.
. 28
Pointee arrays (IBM extension) .
.
.
.
.
.
. 77
Octal constants .
.
.
.
.
.
.
.
.
.
.
. 29
Assumed-shape arrays.
.
.
.
.
.
.
.
.
.
. 77
Binary constants .
.
.
.
.
.
.
.
.
.
.
. 29
Implied-shape arrays (Fortran 2008) .
.
.
.
.
. 78
Hollerith constants .
.
.
.
.
.
.
.
.
.
. 30
Deferred-shape arrays .
.
.
.
.
.
.
.
.
.
. 79
Using typeless constants .
.
.
.
.
.
.
.
. 30
Allocatable arrays .
.
.
.
.
.
.
.
.
.
. 80
© Copyright IBM Corp. 1996, 2012
iii

Array pointers .
.
.
.
.
.
.
.
.
.
.
. 81
The scope of a name .
.
.
.
.
.
.
.
.
. 148
Assumed-size arrays .
.
.
.
.
.
.
.
.
.
. 82
Association .
.
.
.
.
.
.
.
.
.
.
.
.
. 152
Array elements .
.
.
.
.
.
.
.
.
.
.
.
. 83
Host association
.
.
.
.
.
.
.
.
.
.
. 152
Array sections
.
.
.
.
.
.
.
.
.
.
.
.
. 85
Use association .
.
.
.
.
.
.
.
.
.
.
. 153
Subscript triplets
.
.
.
.
.
.
.
.
.
.
. 86
Construct Association
.
.
.
.
.
.
.
.
. 154
Vector subscripts
.
.
.
.
.
.
.
.
.
.
. 88
Pointer association
.
.
.
.
.
.
.
.
.
. 154
Substring ranges.
.
.
.
.
.
.
.
.
.
.
. 88
Integer pointer association (IBM extension)
.
. 156
Array sections and structure components
.
.
. 89
Program units, procedures, and subprograms.
.
. 156
Rank and shape of array sections .
.
.
.
.
. 90
Internal procedures .
.
.
.
.
.
.
.
.
. 157
Array constructors .
.
.
.
.
.
.
.
.
.
.
. 91
Interface concepts .
.
.
.
.
.
.
.
.
.
. 158
Implied-DO list for an array constructor .
.
.
. 93
Interface blocks.
.
.
.
.
.
.
.
.
.
.
.
. 160
Contiguity (Fortran 2008) .
.
.
.
.
.
.
.
.
. 94
Generic interface blocks .
.
.
.
.
.
.
.
.
. 163
Expressions involving arrays
.
.
.
.
.
.
.
. 96
Unambiguous generic procedure references .
. 163
Extending intrinsic procedures with generic
Chapter 6. Expressions and
interface blocks .
.
.
.
.
.
.
.
.
.
.
. 165
assignment . . . . . . . . . . . . . 97
Defined operators .
.
.
.
.
.
.
.
.
.
. 165
Defined assignment .
.
.
.
.
.
.
.
.
. 167
Introduction to expressions and assignment
.
.
. 97
User-defined derived-type Input/Output
Primary
.
.
.
.
.
.
.
.
.
.
.
.
.
. 97
procedures (Fortran 2003) .
.
.
.
.
.
.
. 168
Constant expressions .
.
.
.
.
.
.
.
.
.
. 98
Abstract interface (Fortran 2003) .
.
.
.
.
.
. 170
Specification expressions .
.
.
.
.
.
.
.
.
. 99
Main program .
.
.
.
.
.
.
.
.
.
.
.
. 172
Operators and expressions .
.
.
.
.
.
.
.
. 101
Modules .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 173
Arithmetic .
.
.
.
.
.
.
.
.
.
.
.
. 101
Block data program unit.
.
.
.
.
.
.
.
.
. 175
Character.
.
.
.
.
.
.
.
.
.
.
.
.
. 104
Function and subroutine subprograms .
.
.
.
. 177
General .
.
.
.
.
.
.
.
.
.
.
.
.
. 104
Declaring procedures .
.
.
.
.
.
.
.
.
. 178
Logical
.
.
.
.
.
.
.
.
.
.
.
.
.
. 105
Procedure references .
.
.
.
.
.
.
.
.
. 179
Primary .
.
.
.
.
.
.
.
.
.
.
.
.
. 107
Intrinsic procedures .
.
.
.
.
.
.
.
.
.
. 181
Relational
.
.
.
.
.
.
.
.
.
.
.
.
. 108
Conflicts between intrinsic procedure names
Extended intrinsic and defined operations .
.
.
. 109
and other names .
.
.
.
.
.
.
.
.
.
. 182
How expressions are evaluated
.
.
.
.
.
.
. 110
Arguments .
.
.
.
.
.
.
.
.
.
.
.
.
. 182
Precedence of operators .
.
.
.
.
.
.
.
. 110
Actual argument specification .
.
.
.
.
.
. 182
Using BYTE data objects (IBM extension) .
.
. 112
Argument association
.
.
.
.
.
.
.
.
.
. 184
Intrinsic assignment .
.
.
.
.
.
.
.
.
.
. 113
%VAL and %REF (IBM extension)
.
.
.
.
. 186
Arithmetic conversion
.
.
.
.
.
.
.
.
. 115
Intent of dummy arguments .
.
.
.
.
.
. 187
WHERE construct .
.
.
.
.
.
.
.
.
.
.
. 116
Optional dummy arguments .
.
.
.
.
.
. 188
Interpreting masked array assignments .
.
.
. 118
The passed-object dummy argument
.
.
.
. 188
FORALL construct.
.
.
.
.
.
.
.
.
.
.
. 122
Restrictions on optional dummy arguments not
Interpreting the FORALL construct .
.
.
.
. 123
present
.
.
.
.
.
.
.
.
.
.
.
.
.
. 188
Data pointer assignment.
.
.
.
.
.
.
.
.
. 124
Length of character arguments
.
.
.
.
.
. 189
Procedure pointer assignment (Fortran 2003) .
.
. 128
Variables as dummy arguments .
.
.
.
.
. 190
Integer pointer assignment (IBM extension) .
.
. 129
Allocatable objects as dummy arguments
(Fortran 2003) .
.
.
.
.
.
.
.
.
.
.
. 192
Chapter 7. Execution control . . . . . 131
Pointers as dummy arguments
.
.
.
.
.
. 193
Statement blocks .
.
.
.
.
.
.
.
.
.
.
. 131
Procedures as dummy arguments
.
.
.
.
. 194
ASSOCIATE Construct (Fortran 2003) .
.
.
.
. 131
Asterisks as dummy arguments .
.
.
.
.
. 195
BLOCK construct (Fortran 2008) .
.
.
.
.
.
. 133
Resolution of procedure references .
.
.
.
.
. 196
DO construct
.
.
.
.
.
.
.
.
.
.
.
.
. 134
Rules for resolving procedure references to
The terminal statement .
.
.
.
.
.
.
.
. 135
names .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 196
DO WHILE construct.
.
.
.
.
.
.
.
.
. 138
Recursion
.
.
.
.
.
.
.
.
.
.
.
.
.
. 197
IF construct .
.
.
.
.
.
.
.
.
.
.
.
.
. 139
Pure procedures
.
.
.
.
.
.
.
.
.
.
.
. 198
CASE construct.
.
.
.
.
.
.
.
.
.
.
.
. 140
Elemental procedures.
.
.
.
.
.
.
.
.
.
. 200
SELECT TYPE construct (Fortran 2003) .
.
.
.
. 142
Associate names .
.
.
.
.
.
.
.
.
.
.
. 144
Chapter 9. XL Fortran Input/Output
203
Branching
.
.
.
.
.
.
.
.
.
.
.
.
.
. 145
Records .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 203
CONTINUE statement .
.
.
.
.
.
.
.
.
. 146
Formatted records .
.
.
.
.
.
.
.
.
.
. 203
STOP statement
.
.
.
.
.
.
.
.
.
.
.
. 146
Unformatted records .
.
.
.
.
.
.
.
.
. 204
ERROR STOP statement (Fortran 2008) .
.
.
.
. 146
Endfile records .
.
.
.
.
.
.
.
.
.
.
. 204
Files
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 204
Chapter 8. Program units and
Definition of an external file .
.
.
.
.
.
. 204
procedures . . . . . . . . . . . . 147
File access methods .
.
.
.
.
.
.
.
.
. 205
Scope .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 147
Units .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 206
iv
XL Fortran: Language Reference

Connection of a unit .
.
.
.
.
.
.
.
.
. 207
Attributes
.
.
.
.
.
.
.
.
.
.
.
.
.
. 274
Data transfer statements .
.
.
.
.
.
.
.
.
. 208
ABSTRACT (Fortran 2003) .
.
.
.
.
.
.
.
. 274
Asynchronous Input/Output .
.
.
.
.
.
. 209
ALLOCATABLE (Fortran 2003)
.
.
.
.
.
.
. 275
Advancing and nonadvancing Input/Output
210
ALLOCATE .
.
.
.
.
.
.
.
.
.
.
.
.
. 277
User-defined derived-type Input/Output
ASSIGN .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 280
procedure interfaces (Fortran 2003) .
.
.
.
. 211
ASSOCIATE (Fortran 2003) .
.
.
.
.
.
.
.
. 281
User-defined derived-type Input/Output
ASYNCHRONOUS
.
.
.
.
.
.
.
.
.
.
. 282
(Fortran 2003) .
.
.
.
.
.
.
.
.
.
.
. 211
AUTOMATIC (IBM extension).
.
.
.
.
.
.
. 283
File position before and after data transfer.
.
. 213
BACKSPACE
.
.
.
.
.
.
.
.
.
.
.
.
. 285
Conditions and IOSTAT values
.
.
.
.
.
.
. 215
BIND (Fortran 2003) .
.
.
.
.
.
.
.
.
.
. 286
End-of-record conditions
.
.
.
.
.
.
.
. 215
BLOCK (Fortran 2008) .
.
.
.
.
.
.
.
.
. 287
End-of-file conditions.
.
.
.
.
.
.
.
.
. 215
BLOCK DATA .
.
.
.
.
.
.
.
.
.
.
.
. 288
Error conditions
.
.
.
.
.
.
.
.
.
.
. 216
BYTE (IBM extension)
.
.
.
.
.
.
.
.
.
. 289
CALL .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 292
Chapter 10. Input/Output formatting
227
CASE .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 294
Format-directed formatting .
.
.
.
.
.
.
.
. 227
CHARACTER .
.
.
.
.
.
.
.
.
.
.
.
. 296
Complex editing .
.
.
.
.
.
.
.
.
.
. 227
CLASS (Fortran 2003)
.
.
.
.
.
.
.
.
.
. 300
Data edit descriptors .
.
.
.
.
.
.
.
.
. 227
CLOSE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 302
Control edit descriptors .
.
.
.
.
.
.
.
. 232
COMMON .
.
.
.
.
.
.
.
.
.
.
.
.
. 304
Character string edit descriptors .
.
.
.
.
. 233
Common association .
.
.
.
.
.
.
.
.
. 306
Effective list items (Fortran 2003) .
.
.
.
.
. 234
COMPLEX .
.
.
.
.
.
.
.
.
.
.
.
.
. 307
Interaction of Input/Output lists and format
CONTAINS .
.
.
.
.
.
.
.
.
.
.
.
.
. 311
specifications
.
.
.
.
.
.
.
.
.
.
.
. 234
CONTIGUOUS (Fortran 2008) .
.
.
.
.
.
.
. 312
Comma-separated Input/Output (IBM
CONTINUE .
.
.
.
.
.
.
.
.
.
.
.
.
. 314
extension)
.
.
.
.
.
.
.
.
.
.
.
.
. 236
CYCLE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 315
Data edit descriptors .
.
.
.
.
.
.
.
.
.
. 237
DATA .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 316
A (Character) Editing.
.
.
.
.
.
.
.
.
. 237
DEALLOCATE .
.
.
.
.
.
.
.
.
.
.
.
. 319
B (Binary) Editing .
.
.
.
.
.
.
.
.
.
. 237
Derived Type .
.
.
.
.
.
.
.
.
.
.
.
. 321
E, D, and Q (Extended Precision) Editing .
.
. 239
DIMENSION
.
.
.
.
.
.
.
.
.
.
.
.
. 323
DT Editing (Fortran 2003) .
.
.
.
.
.
.
. 240
DO .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 324
EN Editing .
.
.
.
.
.
.
.
.
.
.
.
. 241
DO WHILE .
.
.
.
.
.
.
.
.
.
.
.
.
. 325
ES Editing
.
.
.
.
.
.
.
.
.
.
.
.
. 242
DOUBLE COMPLEX (IBM extension) .
.
.
.
. 327
F (Real without Exponent) Editing .
.
.
.
. 243
DOUBLE PRECISION
.
.
.
.
.
.
.
.
.
. 330
G (General) Editing .
.
.
.
.
.
.
.
.
. 244
ELSE .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 333
H Editing
.
.
.
.
.
.
.
.
.
.
.
.
. 246
ELSE IF .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 333
I (Integer) Editing .
.
.
.
.
.
.
.
.
.
. 247
ELSEWHERE .
.
.
.
.
.
.
.
.
.
.
.
. 334
L (Logical) Editing.
.
.
.
.
.
.
.
.
.
. 248
END .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 335
O (Octal) Editing .
.
.
.
.
.
.
.
.
.
. 249
END (Construct) .
.
.
.
.
.
.
.
.
.
.
. 337
Q (Character Count) Editing (IBM extension)
250
END INTERFACE .
.
.
.
.
.
.
.
.
.
.
. 340
Z (Hexadecimal) Editing
.
.
.
.
.
.
.
. 251
END TYPE .
.
.
.
.
.
.
.
.
.
.
.
.
. 341
Control edit descriptors .
.
.
.
.
.
.
.
.
. 253
ENDFILE.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 342
/ (Slash) Editing .
.
.
.
.
.
.
.
.
.
. 253
ENTRY
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 344
: (Colon) Editing .
.
.
.
.
.
.
.
.
.
. 253
ENUM/END ENUM (Fortran 2003) .
.
.
.
.
. 347
$ (Dollar) Editing (IBM extension)
.
.
.
.
. 254
EQUIVALENCE
.
.
.
.
.
.
.
.
.
.
.
. 348
BN (Blank Null) and BZ (Blank Zero) Editing
254
ERROR STOP (Fortran 2008) .
.
.
.
.
.
.
. 350
DC and DP (Decimal) Editing (Fortran 2003)
255
EXIT .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 352
P (Scale Factor) Editing .
.
.
.
.
.
.
.
. 255
EXTERNAL .
.
.
.
.
.
.
.
.
.
.
.
.
. 354
RC, RD, RN, RP, RU, and RZ (Round) Editing
FLUSH (Fortran 2003)
.
.
.
.
.
.
.
.
.
. 355
(Fortran 2003) .
.
.
.
.
.
.
.
.
.
.
. 256
FORALL .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 357
S, SP, and SS (Sign Control) Editing .
.
.
.
. 257
Interpreting the FORALL statement .
.
.
.
. 359
T, TL, TR, and X (Positional) Editing
.
.
.
. 257
Loop parallelization .
.
.
.
.
.
.
.
.
. 359
List-directed formatting .
.
.
.
.
.
.
.
.
. 259
FORALL (construct) .
.
.
.
.
.
.
.
.
.
. 360
Value separators .
.
.
.
.
.
.
.
.
.
. 259
FORMAT .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 362
List-directed input.
.
.
.
.
.
.
.
.
.
. 259
Character format specification .
.
.
.
.
.
. 363
List-directed output .
.
.
.
.
.
.
.
.
. 260
FUNCTION .
.
.
.
.
.
.
.
.
.
.
.
.
. 364
Namelist formatting .
.
.
.
.
.
.
.
.
.
. 262
Recursion
.
.
.
.
.
.
.
.
.
.
.
.
. 367
Namelist input .
.
.
.
.
.
.
.
.
.
.
. 263
Elemental procedures.
.
.
.
.
.
.
.
.
. 367
Namelist output
.
.
.
.
.
.
.
.
.
.
. 267
GO TO (assigned) .
.
.
.
.
.
.
.
.
.
.
. 367
GO TO (computed) .
.
.
.
.
.
.
.
.
.
. 368
Chapter 11. Statements and attributes
271
GO TO (unconditional) .
.
.
.
.
.
.
.
.
. 369
IF (arithmetic) .
.
.
.
.
.
.
.
.
.
.
.
. 370
Contents
v

IF (block) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 371
Directives for Loop Optimization .
.
.
.
.
. 486
IF (logical) .
.
.
.
.
.
.
.
.
.
.
.
.
. 372
Detailed directive descriptions.
.
.
.
.
.
.
. 486
IMPLICIT
.
.
.
.
.
.
.
.
.
.
.
.
.
. 372
ALIGN
.
.
.
.
.
.
.
.
.
.
.
.
.
. 486
IMPORT (Fortran 2003) .
.
.
.
.
.
.
.
.
. 375
ASSERT .
.
.
.
.
.
.
.
.
.
.
.
.
. 487
INQUIRE.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 375
BLOCK_LOOP .
.
.
.
.
.
.
.
.
.
.
. 490
INTEGER
.
.
.
.
.
.
.
.
.
.
.
.
.
. 383
CNCALL .
.
.
.
.
.
.
.
.
.
.
.
.
. 491
INTENT .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 387
COLLAPSE .
.
.
.
.
.
.
.
.
.
.
.
. 492
INTERFACE .
.
.
.
.
.
.
.
.
.
.
.
.
. 389
EJECT .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 494
INTRINSIC .
.
.
.
.
.
.
.
.
.
.
.
.
. 391
EXECUTION_FREQUENCY (IBM extension)
494
LOGICAL
.
.
.
.
.
.
.
.
.
.
.
.
.
. 393
EXPECTED_VALUE .
.
.
.
.
.
.
.
.
. 495
MODULE
.
.
.
.
.
.
.
.
.
.
.
.
.
. 396
FUNCTRACE_XLF_CATCH
.
.
.
.
.
.
. 496
NAMELIST .
.
.
.
.
.
.
.
.
.
.
.
.
. 397
FUNCTRACE_XLF_ENTER
.
.
.
.
.
.
. 497
NULLIFY.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 398
FUNCTRACE_XLF_EXIT
.
.
.
.
.
.
.
. 497
OPEN .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 399
IGNORE_TKR (IBM extension)
.
.
.
.
.
. 498
OPTIONAL .
.
.
.
.
.
.
.
.
.
.
.
.
. 406
INCLUDE
.
.
.
.
.
.
.
.
.
.
.
.
. 499
PARAMETER .
.
.
.
.
.
.
.
.
.
.
.
. 407
INDEPENDENT .
.
.
.
.
.
.
.
.
.
. 501
PAUSE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 408
#LINE .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 504
POINTER (Fortran 90) .
.
.
.
.
.
.
.
.
. 409
LOOPID .
.
.
.
.
.
.
.
.
.
.
.
.
. 506
POINTER (integer) (IBM extension) .
.
.
.
.
. 411
MEM_DELAY .
.
.
.
.
.
.
.
.
.
.
. 507
PRINT.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 413
NEW .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 507
Implied-DO List
.
.
.
.
.
.
.
.
.
.
. 414
NOFUNCTRACE .
.
.
.
.
.
.
.
.
.
. 508
PRIVATE .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 414
NOSIMD .
.
.
.
.
.
.
.
.
.
.
.
.
. 510
PROCEDURE .
.
.
.
.
.
.
.
.
.
.
.
. 416
NOVECTOR.
.
.
.
.
.
.
.
.
.
.
.
. 510
PROCEDURE declaration (Fortran 2003) .
.
.
. 417
PERMUTATION
.
.
.
.
.
.
.
.
.
.
. 511
PROGRAM .
.
.
.
.
.
.
.
.
.
.
.
.
. 420
@PROCESS .
.
.
.
.
.
.
.
.
.
.
.
. 512
PROTECTED (Fortran 2003)
.
.
.
.
.
.
.
. 420
SNAPSHOT .
.
.
.
.
.
.
.
.
.
.
.
. 513
PUBLIC .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 422
SOURCEFORM.
.
.
.
.
.
.
.
.
.
.
. 514
READ .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 423
STREAM_UNROLL .
.
.
.
.
.
.
.
.
. 515
Implied-DO List
.
.
.
.
.
.
.
.
.
.
. 431
SUBSCRIPTORDER .
.
.
.
.
.
.
.
.
. 517
REAL .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 431
UNROLL .
.
.
.
.
.
.
.
.
.
.
.
.
. 519
RECORD (IBM extension) .
.
.
.
.
.
.
.
. 435
UNROLL_AND_FUSE .
.
.
.
.
.
.
.
. 520
RETURN .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 436
REWIND .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 438
Chapter 13. Hardware-specific
SAVE .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 439
directives . . . . . . . . . . . . . 523
SELECT CASE .
.
.
.
.
.
.
.
.
.
.
.
. 441
Cache control .
.
.
.
.
.
.
.
.
.
.
.
. 523
SELECT TYPE (Fortran 2003) .
.
.
.
.
.
.
. 442
CACHE_ZERO .
.
.
.
.
.
.
.
.
.
.
. 523
SEQUENCE .
.
.
.
.
.
.
.
.
.
.
.
.
. 443
DCBF .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 523
Statement Function
.
.
.
.
.
.
.
.
.
.
. 444
DCBFL
.
.
.
.
.
.
.
.
.
.
.
.
.
. 524
STATIC (IBM extension) .
.
.
.
.
.
.
.
.
. 445
DCBFLP .
.
.
.
.
.
.
.
.
.
.
.
.
. 524
STOP .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 447
DCBST
.
.
.
.
.
.
.
.
.
.
.
.
.
. 524
SUBROUTINE .
.
.
.
.
.
.
.
.
.
.
.
. 449
EIEIO .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 525
TARGET .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 451
ISYNC.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 525
TYPE .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 452
LIGHT_SYNC .
.
.
.
.
.
.
.
.
.
.
. 525
Type Declaration .
.
.
.
.
.
.
.
.
.
.
. 456
PREFETCH .
.
.
.
.
.
.
.
.
.
.
.
.
. 526
Type Guard (Fortran 2003) .
.
.
.
.
.
.
.
. 462
DCBTSTT
.
.
.
.
.
.
.
.
.
.
.
.
. 526
USE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 463
DCBTT
.
.
.
.
.
.
.
.
.
.
.
.
.
. 527
VALUE (Fortran 2003)
.
.
.
.
.
.
.
.
.
. 467
PARTIAL_DCBT .
.
.
.
.
.
.
.
.
.
. 527
VECTOR (IBM extension) .
.
.
.
.
.
.
.
. 468
PREFETCH_BY_LOAD .
.
.
.
.
.
.
.
. 528
VIRTUAL (IBM extension) .
.
.
.
.
.
.
.
. 468
PREFETCH_BY_STREAM .
.
.
.
.
.
.
. 528
VOLATILE .
.
.
.
.
.
.
.
.
.
.
.
.
. 469
PREFETCH_FOR_LOAD
.
.
.
.
.
.
.
. 529
WAIT (Fortran 2003) .
.
.
.
.
.
.
.
.
.
. 471
PREFETCH_FOR_STORE
.
.
.
.
.
.
.
. 529
WHERE .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 473
PROTECTED_STORE_STREAM_SET
.
.
.
. 529
WRITE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 475
PROTECTED_STREAM_COUNT .
.
.
.
.
. 530
Implied-DO List
.
.
.
.
.
.
.
.
.
.
. 481
PROTECTED_STREAM_COUNT_DEPTH .
.
. 531
PROTECTED_STREAM_GO
.
.
.
.
.
.
. 531
Chapter 12. Directives (IBM extension) 483
PROTECTED_STREAM_SET .
.
.
.
.
.
. 532
Comment and noncomment form directives .
.
. 483
PROTECTED_STREAM_STRIDE .
.
.
.
.
. 532
Comment form directives .
.
.
.
.
.
.
. 483
PROTECTED_STREAM_STOP .
.
.
.
.
.
. 533
Noncomment form directives .
.
.
.
.
.
. 485
PROTECTED_STREAM_STOP_ALL .
.
.
.
. 533
Directives and optimization
.
.
.
.
.
.
.
. 486
PROTECTED_UNLIMITED_STORE_STREAM
Assertive directives .
.
.
.
.
.
.
.
.
. 486
_SET .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 534
vi
XL Fortran: Language Reference

PROTECTED_UNLIMITED_STREAM_SET
.
. 534
CVMGx(TSOURCE, FSOURCE, MASK) (IBM
PROTECTED_UNLIMITED_STREAM_SET_GO
535
extension)
.
.
.
.
.
.
.
.
.
.
.
.
. 573
TRANSIENT_PROTECTED_STREAM_COUNT
DATE_AND_TIME(DATE, TIME, ZONE,
_DEPTH .
.
.
.
.
.
.
.
.
.
.
.
.
. 536
VALUES) .
.
.
.
.
.
.
.
.
.
.
.
.
. 574
TRANSIENT_UNLIMITED_PROTECTED
DBLE(A) .
.
.
.
.
.
.
.
.
.
.
.
.
. 576
_STREAM_DEPTH
.
.
.
.
.
.
.
.
.
. 536
DCMPLX(X, Y) (IBM extension) .
.
.
.
.
. 577
UNLIMITED_PROTECTED_STREAM_DEPTH
537
DIGITS(X)
.
.
.
.
.
.
.
.
.
.
.
.
. 577
Examples .
.
.
.
.
.
.
.
.
.
.
.
.
. 537
DIM(X, Y)
.
.
.
.
.
.
.
.
.
.
.
.
. 578
DOT_PRODUCT(VECTOR_A, VECTOR_B) .
. 579
Chapter 14. Intrinsic procedures . . . 539
DPROD(X, Y) .
.
.
.
.
.
.
.
.
.
.
. 580
Classes of intrinsic procedures.
.
.
.
.
.
.
. 539
EOSHIFT(ARRAY, SHIFT, BOUNDARY, DIM)
580
Inquiry intrinsic functions .
.
.
.
.
.
.
. 539
EPSILON(X) .
.
.
.
.
.
.
.
.
.
.
.
. 582
Elemental intrinsic procedures.
.
.
.
.
.
. 539
ERF(X) (Fortran 2008)
.
.
.
.
.
.
.
.
. 583
System inquiry intrinsic functions (IBM
ERFC(X) (Fortran 2008) .
.
.
.
.
.
.
.
. 583
extension)
.
.
.
.
.
.
.
.
.
.
.
.
. 540
ERFC_SCALED(X) (Fortran 2008).
.
.
.
.
. 584
Transformational intrinsic functions .
.
.
.
. 541
EXECUTE_COMMAND_LINE(COMMAND,
Intrinsic subroutines .
.
.
.
.
.
.
.
.
. 541
WAIT, EXITSTAT, CMDSTAT, CMDMSG)
Data representation models.
.
.
.
.
.
.
.
. 541
(Fortran 2008) .
.
.
.
.
.
.
.
.
.
.
. 585
Integer bit model .
.
.
.
.
.
.
.
.
.
. 541
EXP(X)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 586
Integer data model
.
.
.
.
.
.
.
.
.
. 542
EXPONENT(X) .
.
.
.
.
.
.
.
.
.
.
. 587
Real data model
.
.
.
.
.
.
.
.
.
.
. 543
EXTENDS_TYPE_OF(A, MOLD) (Fortran 2003)
588
Detailed descriptions of intrinsic procedures .
.
. 544
FLOOR(A, KIND) .
.
.
.
.
.
.
.
.
.
. 588
ABORT() (IBM extension) .
.
.
.
.
.
.
. 544
FRACTION(X) .
.
.
.
.
.
.
.
.
.
.
. 589
ABS(A)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 545
GAMMA(X) (Fortran 2008) .
.
.
.
.
.
.
. 590
ACHAR(I, KIND) .
.
.
.
.
.
.
.
.
.
. 545
GET_COMMAND(COMMAND, LENGTH,
ACOS(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 546
STATUS) (Fortran 2003) .
.
.
.
.
.
.
.
. 590
ACOSD(X) (IBM extension).
.
.
.
.
.
.
. 547
GET_COMMAND_ARGUMENT(NUMBER,
ACOSH(X) (Fortran 2008) .
.
.
.
.
.
.
. 548
VALUE, LENGTH, STATUS) (Fortran 2003) .
. 591
ADJUSTL(STRING) .
.
.
.
.
.
.
.
.
. 548
GET_ENVIRONMENT_VARIABLE(NAME,
ADJUSTR(STRING) .
.
.
.
.
.
.
.
.
. 549
VALUE, LENGTH, STATUS, TRIM_NAME)
AIMAG(Z), IMAG(Z).
.
.
.
.
.
.
.
.
. 549
(Fortran 2003) .
.
.
.
.
.
.
.
.
.
.
. 592
AINT(A, KIND)
.
.
.
.
.
.
.
.
.
.
. 550
GETENV(NAME, VALUE) (IBM extension)
.
. 593
ALIGNX(K,M) (IBM extension)
.
.
.
.
.
. 551
HFIX(A) (IBM extension)
.
.
.
.
.
.
.
. 594
ALL(MASK, DIM) .
.
.
.
.
.
.
.
.
.
. 551
HYPOT(X, Y) (Fortran 2008)
.
.
.
.
.
.
. 595
ALLOCATED(X) .
.
.
.
.
.
.
.
.
.
. 552
HUGE(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 595
ANINT(A, KIND) .
.
.
.
.
.
.
.
.
.
. 553
IACHAR(C, KIND)
.
.
.
.
.
.
.
.
.
. 596
ANY(MASK, DIM)
.
.
.
.
.
.
.
.
.
. 554
IAND(I, J)
.
.
.
.
.
.
.
.
.
.
.
.
. 597
ASIN(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 554
IBCLR(I, POS) .
.
.
.
.
.
.
.
.
.
.
. 597
ASIND(X) (IBM extension) .
.
.
.
.
.
.
. 555
IBITS(I, POS, LEN)
.
.
.
.
.
.
.
.
.
. 598
ASINH(X) (Fortran 2008)
.
.
.
.
.
.
.
. 556
IBSET(I, POS) .
.
.
.
.
.
.
.
.
.
.
. 599
ASSOCIATED(POINTER, TARGET) .
.
.
.
. 557
ICHAR(C, KIND) .
.
.
.
.
.
.
.
.
.
. 600
ATAN(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 558
IEOR(I, J).
.
.
.
.
.
.
.
.
.
.
.
.
. 600
ATAN(Y, X) (Fortran 2008) .
.
.
.
.
.
.
. 559
ILEN(I) (IBM extension)
.
.
.
.
.
.
.
. 601
ATAN2(Y, X)
.
.
.
.
.
.
.
.
.
.
.
. 559
IMAG(Z) (IBM extension) .
.
.
.
.
.
.
. 602
ATAN2D(Y, X) (IBM extension)
.
.
.
.
.
. 560
INDEX(STRING, SUBSTRING, BACK, KIND)
602
ATAND(X) (IBM extension).
.
.
.
.
.
.
. 561
INT(A, KIND) .
.
.
.
.
.
.
.
.
.
.
. 603
ATANH(X) (Fortran 2008) .
.
.
.
.
.
.
. 562
INT2(A) (IBM extension)
.
.
.
.
.
.
.
. 604
BTEST(I, POS) .
.
.
.
.
.
.
.
.
.
.
. 562
IOR(I, J) .
.
.
.
.
.
.
.
.
.
.
.
.
. 605
BIT_SIZE(I) .
.
.
.
.
.
.
.
.
.
.
.
. 563
IS_CONTIGUOUS(ARRAY) (Fortran 2008).
.
. 605
CEILING(A, KIND) .
.
.
.
.
.
.
.
.
. 564
IS_IOSTAT_END(I) (Fortran 2003)
.
.
.
.
. 606
CHAR(I, KIND)
.
.
.
.
.
.
.
.
.
.
. 564
IS_IOSTAT_EOR(I) (Fortran 2003).
.
.
.
.
. 607
CMPLX(X, Y, KIND) .
.
.
.
.
.
.
.
.
. 565
ISHFT(I, SHIFT)
.
.
.
.
.
.
.
.
.
.
. 607
COMMAND_ARGUMENT_COUNT() (Fortran
ISHFTC(I, SHIFT, SIZE) .
.
.
.
.
.
.
.
. 608
2003) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 566
KIND(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 609
CONJG(Z) .
.
.
.
.
.
.
.
.
.
.
.
. 567
LBOUND(ARRAY, DIM, KIND) .
.
.
.
.
. 609
COS(X)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 567
LEADZ(I) (Fortran 2008).
.
.
.
.
.
.
.
. 610
COSD(X) (IBM extension) .
.
.
.
.
.
.
. 568
LEN(STRING, KIND) .
.
.
.
.
.
.
.
.
. 611
COSH(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 569
LEN_TRIM(STRING, KIND)
.
.
.
.
.
.
. 611
COUNT(MASK, DIM, KIND) .
.
.
.
.
.
. 570
LGAMMA(X) (IBM extension) .
.
.
.
.
.
. 612
CPU_TIME(TIME) (Fortran 95)
.
.
.
.
.
. 570
LGE(STRING_A, STRING_B) .
.
.
.
.
.
. 613
CSHIFT(ARRAY, SHIFT, DIM) .
.
.
.
.
.
. 572
LGT(STRING_A, STRING_B) .
.
.
.
.
.
. 613
Contents
vii

LLE(STRING_A, STRING_B) .
.
.
.
.
.
. 614
SELECTED_INT_KIND(R) .
.
.
.
.
.
.
. 658
LLT(STRING_A, STRING_B) .
.
.
.
.
.
. 615
SELECTED_REAL_KIND(P, R, RADIX) .
.
.
. 659
LOC(X) (IBM extension) .
.
.
.
.
.
.
.
. 616
SET_EXPONENT(X,I).
.
.
.
.
.
.
.
.
. 661
LOG(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 616
SHAPE(SOURCE, KIND)
.
.
.
.
.
.
.
. 661
LOG_GAMMA(X) (Fortran 2008) .
.
.
.
.
. 617
SIGN(A, B) .
.
.
.
.
.
.
.
.
.
.
.
. 662
LOG10(X)
.
.
.
.
.
.
.
.
.
.
.
.
. 618
SIGNAL(I, PROC) (IBM extension) .
.
.
.
. 663
LOGICAL(L, KIND) .
.
.
.
.
.
.
.
.
. 619
SIN(X).
.
.
.
.
.
.
.
.
.
.
.
.
.
. 664
LSHIFT(I, SHIFT) (IBM extension)
.
.
.
.
. 619
SIND(X) (IBM extension)
.
.
.
.
.
.
.
. 665
MATMUL(MATRIX_A, MATRIX_B, MINDIM)
620
SINH(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 665
MAX(A1, A2, A3, ...) .
.
.
.
.
.
.
.
.
. 622
SIZE(ARRAY, DIM, KIND) .
.
.
.
.
.
.
. 666
MAXEXPONENT(X) .
.
.
.
.
.
.
.
.
. 623
SIZEOF(A) (IBM extension).
.
.
.
.
.
.
. 667
MAXLOC(ARRAY, DIM, MASK, KIND) or
SPACING(X)
.
.
.
.
.
.
.
.
.
.
.
. 668
MAXLOC(ARRAY, MASK, KIND)
.
.
.
.
. 624
SPREAD(SOURCE, DIM, NCOPIES).
.
.
.
. 669
MAXVAL(ARRAY, DIM, MASK) or
SQRT(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 670
MAXVAL(ARRAY, MASK) .
.
.
.
.
.
.
. 625
SRAND(SEED) (IBM extension) .
.
.
.
.
. 671
MERGE(TSOURCE, FSOURCE, MASK).
.
.
. 627
SUM(ARRAY, DIM, MASK) or SUM(ARRAY,
MIN(A1, A2, A3, ...) .
.
.
.
.
.
.
.
.
. 628
MASK)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 672
MINEXPONENT(X) .
.
.
.
.
.
.
.
.
. 628
SYSTEM(CMD, RESULT) (IBM extension) .
.
. 673
MINLOC(ARRAY, DIM, MASK, KIND) or
SYSTEM_CLOCK(COUNT, COUNT_RATE,
MINLOC(ARRAY, MASK, KIND).
.
.
.
.
. 629
COUNT_MAX) .
.
.
.
.
.
.
.
.
.
.
. 674
MINVAL(ARRAY, DIM, MASK) or
TAN(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 675
MINVAL(ARRAY, MASK) .
.
.
.
.
.
.
. 631
TAND(X) (IBM extension) .
.
.
.
.
.
.
. 676
MOD(A, P) .
.
.
.
.
.
.
.
.
.
.
.
. 632
TANH(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 676
MODULO(A, P)
.
.
.
.
.
.
.
.
.
.
. 633
TINY(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 677
MOVE_ALLOC(FROM, TO) (Fortran 2003)
.
. 634
TRAILZ(I) (Fortran 2008)
.
.
.
.
.
.
.
. 678
MVBITS(FROM, FROMPOS, LEN, TO, TOPOS)
634
TRANSFER(SOURCE, MOLD, SIZE).
.
.
.
. 678
NEAREST(X,S) .
.
.
.
.
.
.
.
.
.
.
. 635
TRANSPOSE(MATRIX) .
.
.
.
.
.
.
.
. 680
NEW_LINE(A) (Fortran 2003) .
.
.
.
.
.
. 635
TRIM(STRING) .
.
.
.
.
.
.
.
.
.
.
. 680
NINT(A, KIND)
.
.
.
.
.
.
.
.
.
.
. 636
UBOUND(ARRAY, DIM, KIND) .
.
.
.
.
. 681
NOT(I)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 637
UNPACK(VECTOR, MASK, FIELD) .
.
.
.
. 682
NULL(MOLD) .
.
.
.
.
.
.
.
.
.
.
. 638
VERIFY(STRING, SET, BACK, KIND) .
.
.
. 683
NUM_PARTHDS() (IBM extension) .
.
.
.
. 639
NUM_USRTHDS() (IBM extension) .
.
.
.
. 639
Chapter 15. Hardware-specific
NUMBER_OF_PROCESSORS(DIM) (IBM
intrinsic procedures (IBM extension) . 685
extension)
.
.
.
.
.
.
.
.
.
.
.
.
. 640
BPERMD(MASK, SOURCE)
.
.
.
.
.
.
.
. 685
PACK(ARRAY, MASK, VECTOR) .
.
.
.
.
. 640
CMPB(X,Y) .
.
.
.
.
.
.
.
.
.
.
.
.
. 686
POPCNT(I) (Fortran 2008) .
.
.
.
.
.
.
. 642
DIVDE(X,Y) .
.
.
.
.
.
.
.
.
.
.
.
.
. 686
POPPAR(I) (Fortran 2008) .
.
.
.
.
.
.
. 642
DIVWE(X,Y).
.
.
.
.
.
.
.
.
.
.
.
.
. 687
PRECISION(X) .
.
.
.
.
.
.
.
.
.
.
. 643
FCFI(I)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 687
PRESENT(A)
.
.
.
.
.
.
.
.
.
.
.
. 644
FCFID(I) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 688
PROCESSORS_SHAPE() (IBM extension) .
.
. 645
FCFUD(I).
.
.
.
.
.
.
.
.
.
.
.
.
.
. 688
PRODUCT(ARRAY, DIM, MASK) or
FCTID(X).
.
.
.
.
.
.
.
.
.
.
.
.
.
. 689
PRODUCT(ARRAY, MASK)
.
.
.
.
.
.
. 645
FCTIDZ(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 690
QCMPLX(X, Y) (IBM extension) .
.
.
.
.
. 647
FCTIW(X)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 690
QEXT(A) (IBM extension) .
.
.
.
.
.
.
. 647
FCTIWZ(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 691
RADIX(X)
.
.
.
.
.
.
.
.
.
.
.
.
. 648
FCTUDZ(X) .
.
.
.
.
.
.
.
.
.
.
.
.
. 691
RAND() (IBM extension)
.
.
.
.
.
.
.
. 648
FCTUWZ(X).
.
.
.
.
.
.
.
.
.
.
.
.
. 692
RANDOM_NUMBER(HARVEST)
.
.
.
.
. 649
FMADD(A, X, Y) .
.
.
.
.
.
.
.
.
.
.
. 692
RANDOM_SEED(SIZE, PUT, GET,
FMSUB(A, X, Y)
.
.
.
.
.
.
.
.
.
.
.
. 693
GENERATOR) .
.
.
.
.
.
.
.
.
.
.
. 650
FNABS(X)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 693
RANGE(X) .
.
.
.
.
.
.
.
.
.
.
.
. 651
FNMADD(A, X, Y)
.
.
.
.
.
.
.
.
.
.
. 694
REAL(A, KIND)
.
.
.
.
.
.
.
.
.
.
. 652
FNMSUB(A, X, Y) .
.
.
.
.
.
.
.
.
.
.
. 694
REPEAT(STRING, NCOPIES) .
.
.
.
.
.
. 653
FRE(X)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 695
RESHAPE(SOURCE, SHAPE, PAD, ORDER)
653
FRES(X) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 695
RRSPACING(X)
.
.
.
.
.
.
.
.
.
.
. 655
FRIC(A) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 696
RSHIFT(I, SHIFT) (IBM extension) .
.
.
.
. 655
FRIM(A) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 696
SAME_TYPE_AS(A,B) (Fortran 2003)
.
.
.
. 656
FRIN(A) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 697
SCALE(X,I) .
.
.
.
.
.
.
.
.
.
.
.
. 656
FRIP(A) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 697
SCAN(STRING, SET, BACK, KIND) .
.
.
.
. 657
FRIZ(A) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 698
SELECTED_CHAR_KIND(NAME) (Fortran
FRSQRTE(X).
.
.
.
.
.
.
.
.
.
.
.
.
. 698
2003) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 658
FRSQRTES(X) .
.
.
.
.
.
.
.
.
.
.
.
. 699
viii
XL Fortran: Language Reference

FSEL(X,Y,Z) .
.
.
.
.
.
.
.
.
.
.
.
.
. 699
VEC_CTS(ARG1, ARG2).
.
.
.
.
.
.
.
.
. 730
MTFSF(MASK, R) .
.
.
.
.
.
.
.
.
.
.
. 700
VEC_CTSL(ARG1, ARG2) .
.
.
.
.
.
.
.
. 731
MTFSFI(BF, I) .
.
.
.
.
.
.
.
.
.
.
.
. 700
VEC_CTU(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 731
MULHY(RA, RB) .
.
.
.
.
.
.
.
.
.
.
. 700
VEC_CTUL(ARG1, ARG2) .
.
.
.
.
.
.
.
. 732
POPCNTB(I)
.
.
.
.
.
.
.
.
.
.
.
.
. 701
VEC_CVF(ARG1) .
.
.
.
.
.
.
.
.
.
.
. 732
ROTATELI(RS, IS, SHIFT, MASK)
.
.
.
.
.
. 701
VEC_DIV(ARG1, ARG2).
.
.
.
.
.
.
.
.
. 733
ROTATELM(RS, SHIFT, MASK) .
.
.
.
.
.
. 702
VEC_DSS(ARG1) .
.
.
.
.
.
.
.
.
.
.
. 733
SETFSB0(BT)
.
.
.
.
.
.
.
.
.
.
.
.
. 703
VEC_DSSALL .
.
.
.
.
.
.
.
.
.
.
.
. 733
SETFSB1(BT)
.
.
.
.
.
.
.
.
.
.
.
.
. 703
VEC_DST(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 734
SFTI(M, Y) .
.
.
.
.
.
.
.
.
.
.
.
.
. 703
VEC_DSTST(ARG1, ARG2, ARG3) .
.
.
.
.
. 734
SWDIV(X,Y) .
.
.
.
.
.
.
.
.
.
.
.
.
. 704
VEC_DSTSTT(ARG1, ARG2, ARG3) .
.
.
.
.
. 735
SWDIV_NOCHK(X,Y)
.
.
.
.
.
.
.
.
.
. 705
VEC_DSTT(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 735
TRAP(A, B, TO)
.
.
.
.
.
.
.
.
.
.
.
. 706
VEC_EXPTE(ARG1) .
.
.
.
.
.
.
.
.
.
. 736
VEC_EXTRACT(ARG1, ARG2)
.
.
.
.
.
.
. 736
Chapter 16. Vector intrinsic
VEC_FLOOR(ARG1) .
.
.
.
.
.
.
.
.
.
. 737
procedures (IBM extension) . . . . . 707
VEC_INSERT(ARG1, ARG2, ARG3) .
.
.
.
.
. 737
VEC_LD(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 738
VEC_ABS(ARG1) .
.
.
.
.
.
.
.
.
.
.
. 707
VEC_LDE(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 738
VEC_ABSS(ARG1).
.
.
.
.
.
.
.
.
.
.
. 707
VEC_LDL(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 739
VEC_ADD(ARG1, ARG2) .
.
.
.
.
.
.
.
. 708
VEC_LOGE(ARG1)
.
.
.
.
.
.
.
.
.
.
. 740
VEC_ADDC(ARG1, ARG2) .
.
.
.
.
.
.
.
. 708
VEC_LVSL(ARG1, ARG2) .
.
.
.
.
.
.
.
. 740
VEC_ADDS(ARG1, ARG2) .
.
.
.
.
.
.
.
. 709
VEC_LVSR(ARG1, ARG2) .
.
.
.
.
.
.
.
. 741
VEC_ALL_EQ(ARG1, ARG2) .
.
.
.
.
.
.
. 709
VEC_MADD(ARG1, ARG2, ARG3) .
.
.
.
.
. 741
VEC_ALL_GE(ARG1, ARG2) .
.
.
.
.
.
.
. 710
VEC_MADDS(ARG1, ARG2, ARG3) .
.
.
.
.
. 742
VEC_ALL_GT(ARG1, ARG2) .
.
.
.
.
.
.
. 710
VEC_MAX(ARG1, ARG2) .
.
.
.
.
.
.
.
. 742
VEC_ALL_IN(ARG1, ARG2) .
.
.
.
.
.
.
. 711
VEC_MERGEH(ARG1, ARG2) .
.
.
.
.
.
.
. 743
VEC_ALL_LE(ARG1, ARG2) .
.
.
.
.
.
.
. 711
VEC_MERGEL(ARG1, ARG2) .
.
.
.
.
.
.
. 743
VEC_ALL_LT(ARG1, ARG2) .
.
.
.
.
.
.
. 712
VEC_MFVSCR .
.
.
.
.
.
.
.
.
.
.
.
. 744
VEC_ALL_NAN(ARG1) .
.
.
.
.
.
.
.
.
. 712
VEC_MIN(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 744
VEC_ALL_NE(ARG1, ARG2) .
.
.
.
.
.
.
. 713
VEC_MLADD(ARG1, ARG2, ARG3) .
.
.
.
.
. 745
VEC_ALL_NGE(ARG1, ARG2)
.
.
.
.
.
.
. 713
VEC_MRADDS(ARG1, ARG2, ARG3) .
.
.
.
. 745
VEC_ALL_NGT(ARG1, ARG2)
.
.
.
.
.
.
. 714
VEC_MSUB(ARG1, ARG2, ARG3)
.
.
.
.
.
. 746
VEC_ALL_NLE(ARG1, ARG2).
.
.
.
.
.
.
. 714
VEC_MSUM(ARG1, ARG2, ARG3) .
.
.
.
.
. 747
VEC_ALL_NLT(ARG1, ARG2).
.
.
.
.
.
.
. 715
VEC_MSUMS(ARG1, ARG2, ARG3) .
.
.
.
.
. 747
VEC_ALL_NUMERIC(ARG1) .
.
.
.
.
.
.
. 715
VEC_MTVSCR(ARG1) .
.
.
.
.
.
.
.
.
. 748
VEC_AND(ARG1, ARG2) .
.
.
.
.
.
.
.
. 716
VEC_MUL(ARG1, ARG2) .
.
.
.
.
.
.
.
. 748
VEC_ANDC(ARG1, ARG2) .
.
.
.
.
.
.
.
. 716
VEC_MULE(ARG1, ARG2) .
.
.
.
.
.
.
.
. 749
VEC_ANY_EQ(ARG1, ARG2) .
.
.
.
.
.
.
. 717
VEC_MULO(ARG1, ARG2) .
.
.
.
.
.
.
.
. 749
VEC_ANY_GE(ARG1, ARG2) .
.
.
.
.
.
.
. 717
VEC_NABS(ARG1)
.
.
.
.
.
.
.
.
.
.
. 750
VEC_ANY_GT(ARG1, ARG2) .
.
.
.
.
.
.
. 718
VEC_NEG(ARG1) .
.
.
.
.
.
.
.
.
.
.
. 750
VEC_ANY_LE(ARG1, ARG2) .
.
.
.
.
.
.
. 718
VEC_NMADD(ARG1, ARG2, ARG3)
.
.
.
.
. 751
VEC_ANY_LT(ARG1, ARG2) .
.
.
.
.
.
.
. 719
VEC_NMSUB(ARG1, ARG2, ARG3) .
.
.
.
.
. 751
VEC_ANY_NAN(ARG1)
.
.
.
.
.
.
.
.
. 719
VEC_NOR(ARG1, ARG2) .
.
.
.
.
.
.
.
. 752
VEC_ANY_NE(ARG1, ARG2) .
.
.
.
.
.
.
. 719
VEC_OR(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 752
VEC_ANY_NGE(ARG1, ARG2) .
.
.
.
.
.
. 720
VEC_PACK(ARG1, ARG2) .
.
.
.
.
.
.
.
. 753
VEC_ANY_NGT(ARG1, ARG2) .
.
.
.
.
.
. 720
VEC_PACKPX(ARG1, ARG2) .
.
.
.
.
.
.
. 753
VEC_ANY_NLE(ARG1, ARG2)
.
.
.
.
.
.
. 721
VEC_PACKS(ARG1, ARG2)
.
.
.
.
.
.
.
. 754
VEC_ANY_NLT(ARG1, ARG2)
.
.
.
.
.
.
. 721
VEC_PACKSU(ARG1, ARG2) .
.
.
.
.
.
.
. 755
VEC_ANY_NUMERIC(ARG1) .
.
.
.
.
.
.
. 722
VEC_PERM(ARG1, ARG2, ARG3)
.
.
.
.
.
. 755
VEC_ANY_OUT(ARG1, ARG2) .
.
.
.
.
.
. 722
VEC_PERMI(ARG1, ARG2, ARG3) .
.
.
.
.
. 756
VEC_AVG(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 723
VEC_PROMOTE(ARG1, ARG2) .
.
.
.
.
.
. 756
VEC_CEIL(ARG1) .
.
.
.
.
.
.
.
.
.
.
. 723
VEC_RE(ARG1)
.
.
.
.
.
.
.
.
.
.
.
. 757
VEC_CMPB(ARG1, ARG2) .
.
.
.
.
.
.
.
. 724
VEC_RL(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 757
VEC_CMPEQ(ARG1, ARG2) .
.
.
.
.
.
.
. 725
VEC_ROUND(ARG1)
.
.
.
.
.
.
.
.
.
. 758
VEC_CMPGE(ARG1, ARG2) .
.
.
.
.
.
.
. 725
VEC_ROUNDC(ARG1) .
.
.
.
.
.
.
.
.
. 758
VEC_CMPGT(ARG1, ARG2) .
.
.
.
.
.
.
. 726
VEC_ROUNDM(ARG1) .
.
.
.
.
.
.
.
.
. 759
VEC_CMPLE(ARG1, ARG2)
.
.
.
.
.
.
.
. 727
VEC_ROUNDP(ARG1) .
.
.
.
.
.
.
.
.
. 759
VEC_CMPLT(ARG1, ARG2)
.
.
.
.
.
.
.
. 727
VEC_ROUNDZ(ARG1) .
.
.
.
.
.
.
.
.
. 759
VEC_CONVERT(V, MOLD).
.
.
.
.
.
.
.
. 728
VEC_RSQRTE(ARG1).
.
.
.
.
.
.
.
.
.
. 759
VEC_CPSGN(ARG1, ARG2)
.
.
.
.
.
.
.
. 729
VEC_SEL(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 760
VEC_CTD(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 729
VEC_SL(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 760
VEC_CTF(ARG1, ARG2).
.
.
.
.
.
.
.
.
. 730
Contents
ix

VEC_SLD(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 761
INT16 (Fortran 2008) .
.
.
.
.
.
.
.
.
. 790
VEC_SLDW(ARG1, ARG2, ARG3)
.
.
.
.
.
. 761
INT32 (Fortran 2008) .
.
.
.
.
.
.
.
.
. 790
VEC_SLL(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 762
INT64 (Fortran 2008) .
.
.
.
.
.
.
.
.
. 791
VEC_SLO(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 763
INTEGER_KINDS (Fortran 2008) .
.
.
.
.
. 791
VEC_SPLAT(ARG1, ARG2) .
.
.
.
.
.
.
.
. 763
INPUT_UNIT .
.
.
.
.
.
.
.
.
.
.
. 791
VEC_SPLATS(ARG1) .
.
.
.
.
.
.
.
.
.
. 764
IOSTAT_END .
.
.
.
.
.
.
.
.
.
.
. 791
VEC_SPLAT_S8(ARG1) .
.
.
.
.
.
.
.
.
. 764
IOSTAT_EOR
.
.
.
.
.
.
.
.
.
.
.
. 792
VEC_SPLAT_S16(ARG1).
.
.
.
.
.
.
.
.
. 765
IOSTAT_INQUIRE_INTERNAL_UNIT (Fortran
VEC_SPLAT_S32(ARG1).
.
.
.
.
.
.
.
.
. 765
2008) .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 792
VEC_SPLAT_U8(ARG1) .
.
.
.
.
.
.
.
.
. 765
LOGICAL_KINDS (Fortran 2008) .
.
.
.
.
. 793
VEC_SPLAT_U16(ARG1)
.
.
.
.
.
.
.
.
. 766
NUMERIC_STORAGE_SIZE .
.
.
.
.
.
. 793
VEC_SPLAT_U32(ARG1)
.
.
.
.
.
.
.
.
. 766
OUTPUT_UNIT
.
.
.
.
.
.
.
.
.
.
. 793
VEC_SQRT(ARG1)
.
.
.
.
.
.
.
.
.
.
. 767
REAL32 (Fortran 2008) .
.
.
.
.
.
.
.
. 793
VEC_SR(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 767
REAL64 (Fortran 2008) .
.
.
.
.
.
.
.
. 794
VEC_SRA(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 768
REAL128 (Fortran 2008) .
.
.
.
.
.
.
.
. 794
VEC_SRL(ARG1, ARG2) .
.
.
.
.
.
.
.
.
. 768
REAL_KINDS (Fortran 2008) .
.
.
.
.
.
. 794
VEC_SRO(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 769
ISO_FORTRAN_ENV functions .
.
.
.
.
.
. 794
VEC_ST(ARG1, ARG2, ARG3) .
.
.
.
.
.
.
. 769
COMPILER_OPTIONS (Fortran 2008) .
.
.
. 795
VEC_STE(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 770
COMPILER_VERSION (Fortran 2008) .
.
.
. 795
VEC_STL(ARG1, ARG2, ARG3) .
.
.
.
.
.
. 771
VEC_SUB(ARG1, ARG2).
.
.
.
.
.
.
.
.
. 771
Chapter 19. Floating-point control and
VEC_SUBC(ARG1, ARG2) .
.
.
.
.
.
.
.
. 772
inquiry procedures . . . . . . . . . 797
VEC_SUBS(ARG1, ARG2) .
.
.
.
.
.
.
.
. 773
fpgets fpsets .
.
.
.
.
.
.
.
.
.
.
.
.
. 797
VEC_SUM2S(ARG1, ARG2)
.
.
.
.
.
.
.
. 773
Efficient floating-point control and inquiry
VEC_SUM4S(ARG1, ARG2)
.
.
.
.
.
.
.
. 774
procedures .
.
.
.
.
.
.
.
.
.
.
.
.
. 798
VEC_SUMS(ARG1, ARG2) .
.
.
.
.
.
.
.
. 774
xlf_fp_util floating-point procedures .
.
.
.
. 800
VEC_TRUNC(ARG1) .
.
.
.
.
.
.
.
.
.
. 775
IEEE Modules and support (Fortran 2003) .
.
.
. 804
VEC_UNPACKH(ARG1).
.
.
.
.
.
.
.
.
. 775
Compiling and exception handling .
.
.
.
. 805
VEC_UNPACKL(ARG1) .
.
.
.
.
.
.
.
.
. 776
General rules for implementing IEEE modules
805
VEC_XLD2(ARG1, ARG2) .
.
.
.
.
.
.
.
. 776
IEEE derived data types and constants .
.
.
. 805
VEC_XLDS(ARG1, ARG2) .
.
.
.
.
.
.
.
. 777
IEEE Operators .
.
.
.
.
.
.
.
.
.
.
. 807
VEC_XLW4(ARG1, ARG2) .
.
.
.
.
.
.
.
. 778
IEEE procedures .
.
.
.
.
.
.
.
.
.
. 808
VEC_XOR(ARG1, ARG2)
.
.
.
.
.
.
.
.
. 779
Rules for floating-point status .
.
.
.
.
.
. 831
VEC_XSTD2(ARG1, ARG2, ARG3) .
.
.
.
.
. 779
Examples .
.
.
.
.
.
.
.
.
.
.
.
.
. 832
VEC_XSTW4(ARG1, ARG2, ARG3) .
.
.
.
.
. 780
Chapter 20. Service and utility
Chapter 17. Language interoperability
procedures (IBM extension) . . . . . 837
features (Fortran 2003) . . . . . . . 781
General service and utility procedures .
.
.
.
. 837
Interoperability of types .
.
.
.
.
.
.
.
.
. 781
List of service and utility procedures
.
.
.
.
. 838
Intrinsic types .
.
.
.
.
.
.
.
.
.
.
. 781
alarm_(time, func) .
.
.
.
.
.
.
.
.
.
.
. 838
Derived types .
.
.
.
.
.
.
.
.
.
.
. 781
bic_(X1, X2) .
.
.
.
.
.
.
.
.
.
.
.
.
. 839
Interoperability of Variables
.
.
.
.
.
.
.
. 782
bis_(X1, X2) .
.
.
.
.
.
.
.
.
.
.
.
.
. 839
Interoperability of common blocks .
.
.
.
.
. 782
bit_(X1, X2) .
.
.
.
.
.
.
.
.
.
.
.
.
. 840
Interoperability of procedures .
.
.
.
.
.
.
. 782
clock_() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 840
The ISO_C_BINDING module .
.
.
.
.
.
.
. 783
ctime_(STR, TIME)
.
.
.
.
.
.
.
.
.
.
. 841
Constants for use as kind type parameters
.
. 783
date() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 841
Character constants .
.
.
.
.
.
.
.
.
. 785
dtime_(dtime_struct) .
.
.
.
.
.
.
.
.
.
. 841
Other constants.
.
.
.
.
.
.
.
.
.
.
. 785
etime_(etime_struct) .
.
.
.
.
.
.
.
.
.
. 842
Types .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 785
exit_(exit_status) .
.
.
.
.
.
.
.
.
.
.
. 842
Procedures .
.
.
.
.
.
.
.
.
.
.
.
. 785
fdate_(str)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 843
Binding labels .
.
.
.
.
.
.
.
.
.
.
.
. 788
fiosetup_(unit, command, argument)
.
.
.
.
. 843
flush_(lunit) .
.
.
.
.
.
.
.
.
.
.
.
.
. 844
Chapter 18. The ISO_FORTRAN_ENV
ftell_(lunit) .
.
.
.
.
.
.
.
.
.
.
.
.
. 844
intrinsic module . . . . . . . . . . 789
ftell64_(lunit)
.
.
.
.
.
.
.
.
.
.
.
.
. 845
ISO_FORTRAN_ENV constants .
.
.
.
.
.
. 789
getarg(i1,c1) .
.
.
.
.
.
.
.
.
.
.
.
.
. 845
CHARACTER_KINDS (Fortran 2008)
.
.
.
. 789
getcwd_(name) .
.
.
.
.
.
.
.
.
.
.
.
. 846
CHARACTER_STORAGE_SIZE .
.
.
.
.
. 789
getfd(lunit) .
.
.
.
.
.
.
.
.
.
.
.
.
. 846
ERROR_UNIT .
.
.
.
.
.
.
.
.
.
.
. 789
getgid_() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 847
FILE_STORAGE_SIZE
.
.
.
.
.
.
.
.
. 790
getlog_(name) .
.
.
.
.
.
.
.
.
.
.
.
. 847
INT8 (Fortran 2008) .
.
.
.
.
.
.
.
.
. 790
getpid_() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 847
x
XL Fortran: Language Reference

getuid_() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 848
usleep_(msec) .
.
.
.
.
.
.
.
.
.
.
.
. 858
global_timef() .
.
.
.
.
.
.
.
.
.
.
.
. 848
xl__trbk() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 859
gmtime_(stime, tarray) .
.
.
.
.
.
.
.
.
. 848
hostnm_(name) .
.
.
.
.
.
.
.
.
.
.
.
. 849
Chapter 21. Extensions for source
iargc() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 849
compatibility (IBM extension)
. . . . 861
idate_(idate_struct)
.
.
.
.
.
.
.
.
.
.
. 850
Record structures .
.
.
.
.
.
.
.
.
.
.
. 861
ierrno_() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 850
Declaring record structures .
.
.
.
.
.
.
. 862
irand().
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 851
Storage mapping .
.
.
.
.
.
.
.
.
.
. 864
irtc() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 851
Union and map (IBM extension) .
.
.
.
.
.
. 865
itime_(itime_struct)
.
.
.
.
.
.
.
.
.
.
. 851
jdate() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 852
lenchr_(str) .
.
.
.
.
.
.
.
.
.
.
.
.
. 852
Appendix.
. . . . . . . . . . . . 869
lnblnk_(str) .
.
.
.
.
.
.
.
.
.
.
.
.
. 852
Compatibility across standards
.
.
.
.
.
.
. 869
ltime_(stime, tarray) .
.
.
.
.
.
.
.
.
.
. 853
Fortran 90 compatibility .
.
.
.
.
.
.
.
. 870
mclock() .
.
.
.
.
.
.
.
.
.
.
.
.
.
. 853
Obsolescent features .
.
.
.
.
.
.
.
.
. 870
qsort_(array, len, isize, compar) .
.
.
.
.
.
. 854
Deleted features
.
.
.
.
.
.
.
.
.
.
. 872
qsort_down(array, len, isize)
.
.
.
.
.
.
.
. 854
ASCII and EBCDIC character sets
.
.
.
.
.
. 872
qsort_up(array, len, isize)
.
.
.
.
.
.
.
.
. 855
rtc()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 856
Notices . . . . . . . . . . . . . . 881
setrteopts(c1)
.
.
.
.
.
.
.
.
.
.
.
.
. 856
Trademarks and service marks
.
.
.
.
.
.
. 883
sleep_(sec) .
.
.
.
.
.
.
.
.
.
.
.
.
. 856
time_()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 857
Glossary . . . . . . . . . . . . . 885
timef() .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 857
timef_delta(t)
.
.
.
.
.
.
.
.
.
.
.
.
. 857
Index . . . . . . . . . . . . . . . 903
umask_(cmask) .
.
.
.
.
.
.
.
.
.
.
.
. 858
Contents
xi

xii
XL Fortran: Language Reference

About this document
This document, which is part of the XL Fortran documentation suite, describes the
syntax, semantics, and IBM® implementation of the Fortran programming language
on the AIX® operating system. Although XL Fortran implementations conform to
partial Fortran 2008, full Fortran 2003, and other specifications maintained by the
ISO standards for the Fortran programming language, they also incorporate many
extensions to the core language. These extensions have been implemented with the
aims of enhancing usability in specific operating environments, assuring
compatibility with other compilers, and supporting new hardware capabilities.
Who should read this document
This document is a reference for users who already have experience programming
in Fortran. Users new to Fortran can still use this document to find information on
the language and features unique to XL Fortran; however, it does not aim to teach
programming concepts nor to promote specific programming practices.
How to use this document
While this document covers both standard and implementation-specific features of
XL Fortran, it does not include information on the following topics, which are
covered in other documents:
v
Installation, system requirements, last-minute updates: see the XL Fortran
Installation Guide and product README.
v
Overview of XL Fortran features: see the Getting Started with XL Fortran.
v
Compiler setup, compiling and running programs, compiler options, diagnostics:
see the XL Fortran Compiler Reference.
v
Optimizing, porting, OpenMP and SMP programming: see the XL Fortran
Optimization and Programming Guide.
v
Operating system commands related to the use of the compiler: AIX Commands
Reference, Volumes 1 - 6 and the AIX information center.
v
Operating system commands related to the use of the compiler: consult your
man page help and documentation of the specific distribution.
How this document is organized
The following lists group information into sections that provide details on
particular language topics and implementations:
v
XL Fortran language elements:
– XL Fortran for AIX
– XL Fortran language fundamentals
– Intrinsic data types
– Derived types
– Arrays concepts
– Expressions and assignment
– Execution control
– Program units and procedures
– XL Fortran Input/Output
© Copyright IBM Corp. 1996, 2012
xiii

– Input/Output formatting
– Statements and attributes
– Directives (IBM extension)
– Intrinsic procedures
– Vector intrinsic procedures (IBM extension)
– Language interoperability features (Fortran 2003)
– The ISO_FORTRAN_ENV intrinsic module
– Extensions for source compatibility (IBM extension)
v
Procedures that provide hardware-related functionality, and additional features
for those already familiar with the Fortran language:
– Floating-point control and inquiry procedures
– Hardware–specific directives
– Hardware–specific intrinsic procedures (IBM extension)
– Service and utility procedures (IBM extension)
v
The appendices provide information on compatibility across standards for users
of earlier versions of Fortran, and the ASCII and EBCDIC character sets
mapping table.
Conventions
Typographical conventions
The following table explains the typographical conventions used in the IBM XL
Fortran for AIX, V14.1 information.
Table 1. Typographical conventions
Typeface
Indicates
Example
bold
Lowercase commands, executable
The compiler provides basic
names, compiler options, and
invocation commands, xlf, along with
directives.
several other compiler invocation
commands to support various Fortran
language levels and compilation
environments.
italics
Parameters or variables whose
Make sure that you update the size
actual names or values are to be
parameter if you return more than
supplied by the user. Italics are
the size requested.
also used to introduce new terms.
underlining
The default setting of a parameter
nomaf | maf
of a compiler option or directive.
monospace
Programming keywords and
To compile and optimize
library functions, compiler builtins, myprogram.f, enter: xlf myprogram.f
examples of program code,
-O3.
command strings, or user-defined
names.
UPPERCASE
Fortran programming keywords,
The ASSERT directive applies only to
bold
statements, directives, and intrinsic the DO loop immediately following
procedures. Uppercase letters may
the directive, and not to any nested
also be used to indicate the
DO loops.
minimum number of characters
required to invoke a compiler
option/suboption.
xiv
XL Fortran: Language Reference

Qualifying elements (icons and bracket separators)
In descriptions of language elements, this information uses icons and marked
bracket separators to delineate the Fortran language standard text as follows:
Table 2. Qualifying elements
Bracket
Icon
separator text
Meaning
F2008
N/A
The text describes an IBM XL Fortran implementation of
the Fortran 2008 standard.
F2008
Fortran 2003
The text describes an IBM XL Fortran implementation of
begins / ends
the Fortran 2003 standard, and it applies to all later
standards.
IBM extension
The text describes a feature that is an IBM XL Fortran
begins / ends
extension to the standard language specifications.
Note: If the information is marked with a Fortran language standard icon or
bracket separators, it applies to this specific Fortran language standard and all later
ones. If it is not marked, it applies to all Fortran language standards.
Syntax diagrams
Throughout this information, diagrams illustrate XL Fortran syntax. This section
will help you to interpret and use those diagrams.
v
Read the syntax diagrams from left to right, from top to bottom, following the
path of the line.
The
─── symbol indicates the beginning of a command, directive, or statement.
The ─── symbol indicates that the command, directive, or statement syntax is
continued on the next line.
The ─── symbol indicates that a command, directive, or statement is continued
from the previous line.
The ───
symbol indicates the end of a command, directive, or statement.
Fragments, which are diagrams of syntactical units other than complete
commands, directives, or statements, start with the │─── symbol and end with
the ───│ symbol.
IBM XL Fortran extensions are marked by a number in the syntax diagram with
an explanatory note immediately following the diagram.
Program units, procedures, constructs, interface blocks and derived-type
definitions consist of several individual statements. For such items, a box
encloses the syntax representation, and individual syntax diagrams show the
required order for the equivalent Fortran statements.
v
Required items are shown on the horizontal line (the main path):
keyword
required_argument
v
Optional items are shown below the main path:
About this document
xv

keyword
optional_argument
Note: Optional items (not in syntax diagrams) are enclosed by square brackets ([
and ]). For example, [UNIT=]u
v
If you can choose from two or more items, they are shown vertically, in a stack.
If you must choose one of the items, one item of the stack is shown on the main
path.
keyword
required_argument1
required_argument2
If choosing one of the items is optional, the entire stack is shown below the
main path.
keyword
optional_argument1
optional_argument2
v
An arrow returning to the left above the main line (a repeat arrow) indicates
that you can make more than one choice from the stacked items or repeat an
item. The separator character, if it is other than a blank, is also indicated:
,
keyword
repeatable_argument
v
The item that is the default is shown above the main path.
default_argument
keyword
alternate_argument
v
Keywords are shown in nonitalic letters and should be entered exactly as shown.
v
Variables are shown in italicized lowercase letters. They represent user-supplied
names or values. If a variable or user-specified name ends in _list, you can
provide a list of these terms separated by commas.
v
If punctuation marks, parentheses, arithmetic operators, or other such symbols
are shown, you must enter them as part of the syntax.
Sample syntax diagram
The following is an example of a syntax diagram with an interpretation:
xvi
XL Fortran: Language Reference

,
(1)
EXAMPLE
char_constant
a
e
name_list
b
c
d
Notes:
1
IBM extension
Interpret the diagram as follows:
v
Enter the keyword EXAMPLE.
v
EXAMPLE is an IBM extension.
v
Enter a value for char_constant.
v
Enter a value for a or b, but not for both.
v
Optionally, enter a value for c or d.
v
Enter at least one value for e. If you enter more than one value, you must put a
comma between each.
v
Enter the value of at least one name for name_list. If you enter more than one value,
you must put a comma between each. (The _list syntax is equivalent to the previous
syntax for e.)
How to read syntax statements
Syntax statements are read from left to right:
v
Individual required arguments are shown with no special notation.
v
When you must make a choice between a set of alternatives, they are enclosed
by { and } symbols.
v
Optional arguments are enclosed by [ and ] symbols.
v
When you can select from a group of choices, they are separated by | characters.
v
Arguments that you can repeat are followed by ellipses (...).
Example of a syntax statement
EXAMPLE char_constant {a|b}[c|d]e[,e]... name_list{name_list}...
The following list explains the syntax statement:
v
Enter the keyword EXAMPLE.
v
Enter a value for char_constant.
v
Enter a value for a or b, but not for both.
v
Optionally, enter a value for c or d.
v
Enter at least one value for e. If you enter more than one value, you must put a
comma between each.
v
Optionally, enter the value of at least one name for name_list. If you enter more
than one value, you must put a comma between each name.
Note: The same example is used in both the syntax-statement and syntax-diagram
representations.
About this document
xvii

Examples in this information
The examples in this information, except where otherwise noted, are coded in a
simple style that does not try to conserve storage, check for errors, achieve fast
performance, or demonstrate all possible methods to achieve a specific result.
The examples for installation information are labelled as either Example or Basic
example. Basic examples are intended to document a procedure as it would be
performed during a basic, or default, installation; these need little or no
modification.
Notes on the terminology used
Some of the terminology in this information is shortened as follows:
v
The term free source form format often appears as free source form.
v
The term fixed source form format often appears as fixed source form.
v
The term XL Fortran often appears as XLF.
Related information
The following sections provide related information for XL Fortran:
IBM XL Fortran information
XL Fortran provides product information in the following formats:
v
README files
README files contain late-breaking information, including changes and
corrections to the product information. README files are located by default in
the XL Fortran directory and in the root directory of the installation CD.
v
Installable man pages
Man pages are provided for the compiler invocations and all command-line
utilities provided with the product. Instructions for installing and accessing the
man pages are provided in the IBM XL Fortran for AIX, V14.1 Installation Guide.
v
Information center
The information center of searchable HTML files can be launched on a network
and accessed remotely or locally. Instructions for installing and accessing the
online information center are provided in the IBM XL Fortran for AIX, V14.1
Installation Guide.
The information center is viewable on the web at http://
publib.boulder.ibm.com/infocenter/comphelp/v121v141/index.jsp.
v
PDF documents
PDF documents are located by default in the /usr/lpp/xlf/doc/LANG/pdf/
directory, where LANG is one of en_US or ja_JP. The PDF files are also available
on the web at http://www.ibm.com/software/awdtools/fortran/xlfortran/aix/
library/.
The following files comprise the full set of XL Fortran product information:
xviii
XL Fortran: Language Reference

Table 3. XL Fortran PDF files
PDF file
Document title
name
Description
IBM XL Fortran for AIX,
install.pdf
Contains information for installing XL Fortran
V14.1 Installation Guide,
and configuring your environment for basic
GC14-7335-00
compilation and program execution.
Getting Started with IBM
getstart.pdf
Contains an introduction to the XL Fortran
XL Fortran for AIX, V14.1,
product, with information on setting up and
SC14-7334-00
configuring your environment, compiling and
linking programs, and troubleshooting
compilation errors.
IBM XL Fortran for AIX,
compiler.pdf
Contains information about the various
V14.1 Compiler Reference,
compiler options and environment variables.
SC14-7336-00
IBM XL Fortran for AIX,
langref.pdf
Contains information about the Fortran
V14.1 Language Reference,
programming language as supported by IBM,
SC14-7337-00
including language extensions for portability
and conformance to nonproprietary standards,
compiler directives and intrinsic procedures.
IBM XL Fortran for AIX,
proguide.pdf Contains information on advanced
V14.1 Optimization and
programming topics, such as application
Programming Guide,
porting, interlanguage calls, floating-point
SC14-7338-00
operations, input/output, application
optimization and parallelization, and the XL
Fortran high-performance libraries.
To read a PDF file, use the Adobe Reader. If you do not have the Adobe Reader,
you can download it (subject to license terms) from the Adobe website at
http://www.adobe.com.
More information related to XL Fortran including IBM Redbooks® publications,
white papers, tutorials, and other articles, is available on the web at:
http://www.ibm.com/software/awdtools/fortran/xlfortran/aix/library/
Standards and specifications
XL Fortran is designed to support the following standards and specifications. You
can refer to these standards for precise definitions of some of the features found in
this information.
v
American National Standard Programming Language FORTRAN, ANSI X3.9-1978.
v
American National Standard Programming Language Fortran 90, ANSI X3.198-1992.
v
ANSI/IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Std 754-1985.
v
Federal (USA) Information Processing Standards Publication Fortran, FIPS PUB 69-1.
v
Information technology - Programming languages - Fortran, ISO/IEC 1539-1:1991 (E).
(This information uses its informal name, Fortran 90.)
v
Information technology - Programming languages - Fortran - Part 1: Base language,
ISO/IEC 1539-1:1997. (This information uses its informal name, Fortran 95.)
v
Information technology - Programming languages - Fortran - Part 1: Base language,
ISO/IEC 1539-1:2004. (This information uses its informal name, Fortran 2003.)
v
Information technology - Programming languages - Fortran - Part 1: Base language,
ISO/IEC 1539-1:2010. (This information uses its informal name, Fortran 2008.)
About this document
xix

v
Military Standard Fortran DOD Supplement to ANSI X3.9-1978, MIL-STD-1753
(United States of America, Department of Defense standard). Note that XL
Fortran supports only those extensions documented in this standard that have
also been subsequently incorporated into the Fortran 90 standard.
v
OpenMP Application Program Interface Version 3.1, available at
http://www.openmp.org
Other IBM information
v
Parallel Environment for AIX: Operation and Use
v
The IBM Systems Information Center, at http://publib.boulder.ibm.com/
infocenter/systems/index.jsp?topic=/com.ibm.aix.doc/doc/base/aixparent.htm
is a resource for AIX information.
You can find the following books for your specific AIX system:
AIX Commands Reference, Volumes 1 - 6
Technical Reference: Base Operating System and Extensions, Volumes 1 & 2
AIX National Language Support Guide and Reference
AIX General Programming Concepts: Writing and Debugging Programs
AIX Assembler Language Reference
v
ESSL for AIX V5.1/ESSL for Linux on POWER V5.1 Guide and Reference available at
the Engineering and Scientific Subroutine Library (ESSL) and Parallel ESSL web
page.
Technical support
Additional technical support is available from the XL Fortran Support page at
http://www.ibm.com/software/awdtools/fortran/xlfortran/aix/support/. This
page provides a portal with search capabilities to a large selection of Technotes and
other support information.
If you cannot find what you need, you can send email to compinfo@ca.ibm.com.
For the latest information about XL Fortran, visit the product information site at
http://www.ibm.com/software/awdtools/fortran/xlfortran/aix/.
How to send your comments
Your feedback is important in helping to provide accurate and high-quality
information. If you have any comments about this information or any other XL
Fortran information, send your comments by email to compinfo@ca.ibm.com.
Be sure to include the name of the information, the part number of the
information, the version of XL Fortran, and, if applicable, the specific location of
the text you are commenting on (for example, a page number or table number).
xx
XL Fortran: Language Reference

Chapter 1. XL Fortran for AIX
The XL Fortran Language Reference is part of a documentation suite that offers
information on installing and using the XL Fortran compiler on AIX. This
document defines the syntax, semantics, and restrictions you must follow to write
valid XL Fortran programs.
Fortran (FORmula TRANslation) is a high-level programming language primarily
useful for engineering, mathematical, and scientific applications involving numeric
computations.
XL Fortran implements partial Fortran 2008, full Fortran 2003, and other language
specifications maintained by the ISO standards for the Fortran programming
language, and also incorporates many extensions to the core language. These
extensions have been implemented with the aims of enhancing usability in specific
operating environments, assuring compatibility with other compilers, and
supporting new hardware capabilities. In theory, a program that compiles correctly
on one standard-conforming compiler will compile and execute correctly under all
other conforming compilers, insofar as hardware differences permit.
The compiler detects most non-conformities to the XL Fortran language rules, but
may not detect some syntactic and semantic combinations. The compiler cannot
detect all combinations for performance reasons, or because the nonconformance is
only detectable at run time. XL Fortran programs that contain these undiagnosed
combinations are not valid, whether or not the programs run as expected.
Fortran language standards
Fortran 2008
Segments of this document contain information based on the Fortran 2008
Standard. The standard is open to continual interpretation, modification and
revision. IBM reserves the right to modify the behavior of any features of this
product to conform with future interpretations of this standard.
The Fortran standard committees respond to questions of interpretation about
aspects of Fortran. Some questions can relate to language features already
implemented in the XL Fortran compiler. Any answers given by these committees
relating to these language features can result in changes to future releases of the
XL Fortran compiler, even if these changes result in incompatibilities with previous
releases of the product.
Some of the new features in Fortran 2008 are:
v
Execution control: “STOP” on page 447, “ERROR STOP (Fortran 2008)” on page
350, and “BLOCK construct (Fortran 2008)” on page 133
v
Data types: “Implied-shape arrays (Fortran 2008)” on page 78 and Complex part
designators
v
Intrinsic procedures and modules: Chapter 18, “The ISO_FORTRAN_ENV
intrinsic module,” on page 789, “IS_CONTIGUOUS(ARRAY) (Fortran 2008)” on
page 605, “POPCNT(I) (Fortran 2008)” on page 642
v
Pointer dummy argument enhancements
© Copyright IBM Corp. 1996, 2012
1

Fortran 2003
Fortran 2003 offers many new features and feature enhancements to Fortran 95.
Some of the major new features in Fortran 2003 are:
v
Derived type enhancements
v
Object-oriented programming support: type extension, type-bound procedures,
type finalization, abstract and generic interfaces, polymorphism and PASS
attribute
v
Scoping and data manipulation enhancements: allocatable components,
VOLATILE attribute, MAX, MIN, MAXLOC, MINLOC, MAXVAL and MINVAL
intrinsics for character type
v
Input/Output enhancements: User defined derived type I/O, asynchronous
transfer including the WAIT statement
v
Subroutine enhancements: VALUE attribute, Procedure pointers, deferred
CHARACTER length
v
Support for IEEE Floating Point Standard (IEEE 1989) exceptions
v
Interoperability with the C programming language
Fortran 95
The Fortran 95 language standard is upward-compatible with the FORTRAN 77
and Fortran 90 language standards, excluding deleted features. Some of the
improvements provided by the Fortran 95 standard are:
v
Default initialization
v
ELEMENTAL procedures
v
The FORALL construct statement
v
POINTER initialization
v
PURE functions
v
Specification expressions
Fortran 90
Fortran 90 offers many new features and feature enhancements to FORTRAN 77.
The following topics outline some of the key features that Fortran 90 brings to the
FORTRAN 77 language:
v
Array enhancements
v
Control construct enhancements
v
Derived types
v
Dynamic behavior
v
Free source form
v
Modules
v
Parameterized data types
v
Procedure enhancements
v
Pointers
FORTRAN 77
FORTRAN 77 introduced new features and enhancements to FORTRAN 66, for
more information see:
v
The full American National Standard FORTRAN 77 language (referred to as
FORTRAN 77), defined in the document American National Standard
Programming Language FORTRAN, ANSI X3.9-1978.
2
XL Fortran: Language Reference

IBM extensions
An IBM extension generally modifies a rule or restriction from a given standards
implementation. In this document, IBM extensions to the Fortran 2008, Fortran
2003, Fortran 95, and Fortran 90 standards are marked as indicated in the
Conventions section under Conventions, Standards, and Documentation.
OpenMP API Version 3.1
The OpenMP API provides additional features which you can use to supplement
the existing FORTRAN 77, Fortran 90, and Fortran 95 language standards.
The OpenMP Architecture Review Board (ARB) responds to questions of
interpretation about aspects of the API. Some of these questions can relate to
interface features implemented in this version of the XL Fortran compiler. Any
answers given by this committee relating to the interface can result in changes in
future releases of the XL Fortran compiler, even if these changes result in
incompatibilities with previous releases of the product.
You can find information pertaining to the implementation of OpenMP API Version
3.1 in the following sections:
v
OpenMP environment variables in the XL Fortran Optimization and Programming
Guide
v
SMP Directives in the XL Fortran Optimization and Programming Guide
Standards documents
XL Fortran is designed according to the standards listed in the Standards
documents section. You can refer to these standards for precise definitions of some
of the features found in this document.
Chapter 1. XL Fortran for AIX
3

4
XL Fortran: Language Reference

Chapter 2. XL Fortran language fundamentals
This section describes the fundamental aspects of an XL Fortran application. Refer
to the following headings for more information:
Characters
The XL Fortran character set consists of letters, digits, and special characters:
Table 4. The XL Fortran character set
Letters
Digits
Special Characters
A
N
a
n
0
Blank
B
O
b
o
1
Tab
C
P
c
p
2
=
Equal sign
D
Q
d
q
3
+
Plus sign
E
R
e
r
4
-
Minus sign
F
S
f
s
5
*
Asterisk
G
T
g
t
6
/
Slash
H
U
h
u
7
(
Left parenthesis
I
V
i
v
8
)
Right parenthesis
J
W
j
w
9
[
Right square bracket
K
X
k
x
]
Left square bracket
L
Y
l
y
,
Comma
M
Z
m
z
.
Decimal point / period
$
Currency symbol

Apostrophe
:
Colon
!
Exclamation point
"
Double quotation mark
%
Percent sign
&
Ampersand
;
Semicolon
?
Question mark
<
Less than
>
Greater than
_
Underscore
The characters have an order known as a collating sequence, which is the
arrangement of characters that determines their sequence order for such processes
as sorting, merging, and comparing. XL Fortran uses American National Standard
Code for Information Interchange (ASCII) to determine the ordinal sequence of
characters. See “ASCII and EBCDIC character sets” on page 872 for a complete
listing of the ASCII character set.
White space refers to blanks and tabs. The significance of white space depends on
the source format. See “Lines and source formats” on page 8 for details.
A lexical token is a sequence of characters with an indivisible interpretation that
forms a building block of a program. A lexical token can be a keyword, name,
literal constant (not of type complex), operator, label, delimiter, comma, equal sign,
colon, semicolon, percent sign, ::, or =>.
© Copyright IBM Corp. 1996, 2012
5

Names
A name is a sequence of any or all of the following elements:
v
Letters (A-Z, a-z)
v
Digits (0-9)
v
Underscores (_)
v
Dollar signs ($)
The first character of a name must not be a digit.
In Fortran 2003, the maximum length of a name is 63 characters. In Fortran 90 and
Fortran 95, the maximum length of a name is 31 characters.
IBM extension
In XL Fortran, the maximum length of a name is 250 characters. Although you can
begin a name with an underscore, the AIX operating system as well as the XL
Fortran compiler and libraries use reserved names that begin with underscores.
The compiler translates all letters in a source program into lowercase unless they
are in a character context. Character context refers to characters within character
literal constants, character-string edit descriptors, and Hollerith constants.
Note: When you specify the -qmixed compiler option, the compiler does not
translate names to lowercase. For example, XL Fortran treats
ia Ia iA IA
the same by default, but treats lower and uppercase letters as distinct if you
specify -qmixed.
End of IBM extension
A name can identify entities such as:
v
A variable
v
A named constant
v
A procedure
v
A derived type
v
A construct
v
A CRITICAL construct
v
A program unit
v
A common block
v
A namelist group
Designators
A designator is a name that identifies a data object followed by zero or more
selectors such as array element selectors, array section selectors,
F2008
complex
part selectors F2008
, component selectors, and substring selectors. A subobject
designator identifies the following items:
v
An array element
v
An array section
v
A character substring
6
XL Fortran: Language Reference

v
F2008
A complex part F2008
v
A structure component
Operators
In Fortran an expression is comprised of operands and operators. For a detailed
description of Fortran operators, see “Operators and expressions” on page 101
Table 5. XL Fortran operators
Arithmetic
Logical
Character
Primary
General
Relational
Statements
A Fortran statement is a sequence of lexical tokens. Statements are used to form
program units.
The maximum length of a statement in XL Fortran is 34 000 characters.
See Statements and Attributes for more information on statements supported by
XL Fortran.
Statement keywords
A statement keyword is part of the syntax of a statement. A sequence of characters
is not reserved in all contexts. A statement keyword is interpreted as an entity
name if the keyword is used in such a context.
Statement labels
A statement label is a sequence of one to five digits, one of which must be
nonzero, that you can use to identify statements in a Fortran scoping unit. In fixed
source form, a statement label can appear anywhere in columns 1 through 5 of the
initial line of the statement. In free source form, such column restrictions do not
apply.
XL Fortran ignores all characters that appear in columns 1 through 5 on
fixed source form continuation lines.
Giving the same label to more than one statement in a scoping unit causes
ambiguity, and the compiler generates an error. White space and leading zeros are
not significant in distinguishing between statement labels. You can label any
statement, but a statement label reference can only refer to an executable statement
or a FORMAT statement. The statement making the reference and the statement
referenced must be in the same scoping unit for the reference to resolve.
Delimiters
Delimiters are pairs used to enclose syntactic lists. XL Fortran supports the
following delimiters:
v
Parentheses: (...)
v
Slashes: /.../
Chapter 2. XL Fortran language fundamentals
7

v
Array constructors: (/.../)
v
Array constructors: [...]
Lines and source formats
A line is a horizontal arrangement of characters. A column is a vertical
arrangement of characters, where each character, or each byte of a multibyte
character, in a given column shares the same horizontal line position.
Because XL Fortran measures lines in bytes, these definitions apply only
to lines containing single-byte characters. Each byte of a multibyte character
occupies one column.
The kinds of lines are:
Initial line
Is the first line of a statement.
Continuation
Continues a statement beyond its initial line.
line
Comment line
Does not affect the executable program and can be used for
documentation. The comment text continues to the end of a line.
Although comment lines can follow one another, a comment line cannot
be continued. A line of all white space or a zero-length line is a
comment line without any text. Comment text can contain any
characters allowed in a character context.
If an initial line or continuation line is not continued, or if it is
continued but not in a character context, an inline comment can be
placed on the same line, to the right of any statement label, statement
text, and continuation character that may be present. An exclamation
mark (!) begins an inline comment.
Conditional
Indicates that the line should only be compiled if recognition of
compilation line
conditional compilation lines is enabled. A conditional compilation
sentinel should appear on a conditional compilation line. For more
information, see Conditional compilation.
Debug Line
Indicates that the line is for debugging code (for fixed source form
only). In XL Fortran the letter D or X must be specified in column 1. For
more information, see Debug lines.
Directive line
Provides instructions or information to the compiler in XL Fortran. For
more information, see Comment form directives.
IBM extension
In XL Fortran source lines can be in fixed source form or free source form format.
Use the SOURCEFORM directive to mix source formats within the same program
unit. Fixed source form is the default when using the f77, fort77, xlf, xlf_r, or
xlf_r7 invocation commands. Fortran 90 free source form is the default when using
the f90, xlf90, xlf90_r, xlf90_r7, f95, xlf95, xlf95_r, xlf95_r7, f2003, xlf2003, or
xlf2003_r invocation commands.
See Compiling XL Fortran Programs in the XL Fortran Compiler Reference for details
on invocation commands.
End of IBM extension
8
XL Fortran: Language Reference

Fixed source form
A fixed source form line is a sequence of 1 to 132 characters. The default
line size is 72 characters. This is also the Fortran standard line size. You can change
the default using the -qfixed=right_margin compiler option. In XL Fortran there is
no limit to the number of continuation lines for a statement, but the statement
cannot be longer than 34 000 characters. Fortran 2003 limits the number of
continuation lines to 255, while Fortran 95 limits the number of continuation lines
to 19.
In fixed source form, columns beyond the right margin are not part of the line and
you can use these columns for identification, sequencing, or any other purpose.
Except within a character context, white space is insignificant. You can embed
white space between and within lexical tokens, without affecting the way the
compiler treats them.
Tab formatting means that there is a tab character in columns 1 through 6
of an initial line in XL Fortran, which directs the compiler to interpret the next
character as being in column 7.
Requirements for lines and for items on those lines are:
v
A comment line begins with a C, c, or an asterisk (*) in column 1, or is all white
space. Comments can also follow an exclamation mark (!), except when the
exclamation mark is in column 6 or in a character context.
v
For an initial line without tab formatting:
– Columns 1 through 5 contain either blanks, a statement label,
a D or
an X in column 1 optionally followed by a statement label.
– Column 6 contains a blank or zero.
– Columns 7 through to the right margin contain statement text, possibly
followed by other statements or by an inline comment.
v
For an initial line with tab formatting in XL Fortran:
– Columns 1 through 6 begin with either blanks, a statement label, or a D or an
X in column 1, optionally followed by a statement label. You must follow this
with a tab character.
– If you specify the -qxflag=oldtab compiler option, all columns from the
column immediately following the tab character through to the right margin
contain statement text, possibly followed by other statements and by an inline
comment.
– If you do not specify -qxflag=oldtab compiler option, all columns from
column 7, which corresponds to the character after the tab, to the right
margin contain statement text, possibly followed by other statements and by
an inline comment.
v
For a continuation line:
– Column 1 must not contain C, c, or an asterisk. Columns 1 through 5 must
not contain an exclamation mark as the leftmost nonblank character.
Column 1 can contain a D or an X which signifies a debug line in XL
Fortran. Otherwise, these columns can contain any characters allowed in a
character context; these characters are ignored.
– Column 6 must contain either a nonzero character or a nonwhite space
character. The character in column 6 is the continuation character.
Exclamation marks and semicolons are valid continuation characters.
Chapter 2. XL Fortran language fundamentals
9

– Columns 7 through to the right margin contain continued statement text,
possibly followed by other statements and an inline comment.
– Neither the END statement or a statement whose initial line appears to be a
program unit END statement can be continued.
F2008
A semicolon separates statements on a single source line, except when
appearing in a character context, in a comment, or in columns 1 through 6.
F2008
Two or more semicolon separators that are on the same line and are
themselves separated by only white space or other semicolons are considered to be
a single separator. A separator that is the last character on a line or before an inline
comment is ignored. Statements following a semicolon on the same line cannot be
labeled. Additional statements cannot follow a program unit END statement on the
same line.
Debug lines (IBM extension)
A debug line, allowed only for fixed source form, contains source code used for
debugging and is specified in XL Fortran by the letter D, or the letter X in column
1. The handling of debug lines depends on the -qdlines or the -qxlines compiler
options:
v
If you specify the -qdlines option, the compiler interprets the D in column 1 as a
blank, and handles such lines as lines of source code. If you specify -qxlines ,
the compiler interprets the X in column 1 as a blank and treats these lines as
source code.
v
If you do not specify -qdlines or -qxlines, the compiler handles such lines as
comment lines. This is the default setting.
If you continue a debugging statement on more than one line, every continuation
line must have a continuation character as well as a D or an X in column 1. If the
initial line is not a debugging line, you can designate any continuation lines as
debug lines provided that the statement is syntactically correct, whether or not you
specify the -qdlines or -qxlines compiler option.
Example of fixed source form
C Column Numbers:
C
1
2
3
4
5
6
7
C23456789012345678901234567890123456789012345678901234567890123456789012
!IBM* SOURCEFORM (FIXED)
CHARACTER CHARSTR ; LOGICAL X
! 2 statements on 1 line
DO 10 I=1,10
PRINT *,’this is the index’,I
! with an inline comment
10
CONTINUE
C
CHARSTR="THIS IS A CONTINUED
X CHARACTER STRING"
! There will be 38 blanks in the string between "CONTINUED"
! and "CHARACTER". You cannot have an inline comment on
! the initial line because it would be interpreted as part
! of CHARSTR (character context).
100 PRINT *, IERROR
! The following debug lines are compiled as source lines if
! you use -qdlines
D
IF (I.EQ.IDEBUG.AND.
D
+
J.EQ.IDEBUG)
WRITE(6,*) IERROR
D
IF (I.EQ.
D
+
IDEBUG )
D
+
WRITE(6,*) INFO
END
10
XL Fortran: Language Reference

Free source form
A free source form line can specify up to 132 characters on each line. In XL
Fortran, there is no limit to the number of continuation lines for a statement, but
the statement cannot be longer than 34 000 characters. Fortran 2003 limits the
number of continuation lines to 255, while Fortran 95 limits the number of
continuation lines to 39.
Items can begin in any column of a line, subject to the following requirements for
lines and items on those lines:
v
A comment line is a line of white space or begins with an exclamation mark that
is not in a character context.
v
An initial line can contain any of the following items, in the following sequence:
– A statement label.
– Statement text. Note that statement text is required in an initial line.
– Additional statements.
– The ampersand continuation character.
– An inline comment.
v
If you want to continue an initial line or continuation line in a non-character
context, the continuation line must start on the first noncomment line that
follows the intial line or continuation line. To define a line as a continuation line,
you must place an ampersand after the statements on the previous
non-comment line.
v
White space before and after the ampersand is optional, with the following
restrictions:
– If you also place an ampersand in the first nonblank character position of the
continuation line, the statement continues at the next character position
following the ampersand.
– If a lexical token is continued, the ampersand must immediately follow the
initial part of the token, and the remainder of the token must immediately
start after the ampersand on the continuation line.
v
A character context can be continued if the following conditions are true:
– The last character of the continued line is an ampersand and is not followed
by an inline comment. If the rightmost character of the statement text to be
continued is an ampersand, you must enter a second ampersand as a
continuation character.
– The first nonblank character of the next noncomment line is an ampersand.
F2008
A semicolon separates statements on a single source line, except when the
semicolon appears in a character context or in a comment. F2008
Two or more
separators that are on the same line and are themselves separated by only white
space or other semicolons are considered to be a single separator. A separator that
is the last character on a line or before an inline comment is ignored. Additional
statements cannot follow a program unit END statement on the same line.
White space
White space must not appear within lexical tokens, except in a character context or
in a format specification. You can freely insert white space between tokens to
improve readability, and white space must separate names, constants, and labels
from adjacent keywords, names, constants, and labels.
Certain adjacent keywords can require white space. The following table lists
keywords where white space is optional.
Chapter 2. XL Fortran language fundamentals
11

Table 6. Keywords where white space is optional
BLOCK DATA
END FILE
END SUBROUTINE
DOUBLE COMPLEX 1
END FORALL
END TYPE
DOUBLE PRECISION
END FUNCTION
END UNION
ELSE IF
END IF
END WHERE
ELSE WHERE
END INTERFACE
GO TO
END ASSOCIATE
END MAP 1
IN OUT
END BLOCK 2
END MODULE
SELECT CASE
END BLOCK DATA
END PROGRAM
SELECT TYPE 3
END DO
END SELECT
END ENUM 3
END STRUCTURE
Note:
1 IBM extension
2 Fortran 2008
3 Fortran 2003
Example of free source form
!IBM* SOURCEFORM (FREE(F90))
!
! Column Numbers:
!
1
2
3
4
5
6
7
!23456789012345678901234567890123456789012345678901234567890123456789012
DO I=1,20
PRINT *,’this statement&
& is continued’ ; IF (I.LT.5) PRINT *, I
ENDDO
EN&
&D
! A lexical token can be continued
IBM free source form (IBM extension)
An IBM free source form line or statement is a sequence of up to 34000 characters.
Items can begin in any column of a line, subject to the following requirements:
v
A comment line begins with a double quotation mark in column 1, is a line of
all white space, or is a zero-length line. A comment line must not follow a
continued line. Comments can follow an exclamation mark except in a character
context.
v
An initial line can contain any of the following items, in the following sequence:
– A statement label
– Statement text
– The minus sign continuation character
– An inline comment
v
A continuation line immediately follows a continued line and can contain any of
the following items, in the following sequence:
– Statement text
– A continuation character
– An inline comment
12
XL Fortran: Language Reference

If statement text on an initial line or continuation line is to continue, a minus sign
indicates continuation of the statement text on the next line. In a character context,
if the rightmost character of the statement text to continue is a minus sign, a
second minus sign must be entered as a continuation character.
Except within a character context, white space is insignificant. You can embed
white space between and within lexical tokens, without affecting how the compiler
treats those tokens.
Example of IBM free source form
!IBM* SOURCEFORM (FREE(IBM))
"
" Column Numbers:
"
1
2
3
4
5
6
7
"23456789012345678901234567890123456789012345678901234567890123456789012
DO I=1,10
PRINT *,’this is -
the index’,I
! There will be 14 blanks in the string
! between "is" and "the"
END DO
END
Conditional compilation (IBM extension)
You can use sentinels to mark specific lines of an XL Fortran program for
conditional compilation. This allows you to port code that contains statements that
are only valid or applicable in an SMP environment to a non-SMP environment.
Conditional compilation is not supported with IBM free source form.
Syntax for conditional compilation
cond_comp_sentinel
fortran_source_line
cond_comp_sentinel
is a conditional compilation sentinel defined by the current source form
and is either:
v
!$, C$, c$, or *$, for fixed source form, or
v
!$, for free source form
fortran_source_line
is an XL Fortran source line
Conditional compilation rules
General rules:
A valid XL Fortran source line must follow the conditional compilation sentinel.
A conditional compilation line can contain the EJECT, INCLUDE or noncomment
directives.
A conditional compilation sentinel must not contain embedded white space.
A conditional compilation sentinel must not follow a source statement or directive
on the same line.
Chapter 2. XL Fortran language fundamentals
13

If you are continuing a conditional compilation line, the conditional compilation
sentinel must appear on at least one of the continuation lines or on the initial line.
You must specify the -qcclines compiler option for conditional compilation lines to
be recognized. To disable recognition of conditional compilation lines, specify the
-qnocclines compiler option.
Trigger directives take precedence over conditional compilation sentinels. For
example, if you specify the -qdirective='$' option, then lines that start with the
trigger, such as !$, will be treated as comment directives, rather than conditional
compilation lines.
Fixed source form rules:
Conditional compilation sentinels must start in column 1.
All rules for fixed source form line length, case sensitivity, white space,
continuation, tab formatting, and columns apply.
Free source form rules:
Conditional compilation sentinels can start in any column.
All rules for free source form line length, case sensitivity, white space, and
continuation apply. When you enable recognition of conditional compilation lines,
two white spaces replace the conditional compilation sentinel.
Order of statements and execution sequence
In the Statement order table, vertical lines delineate statements that you can
intersperse, while horizontal lines delineate statements that you cannot intersperse.
The numbers in the diagram reappear later in this document to identify groups of
statements that you can specify in a particular context.
Table 7. Statement order
1 PROGRAM, FUNCTION, SUBROUTINE, MODULE, or BLOCK DATA Statement
2 USE Statements
3 IMPORT Statements
4 DATA, FORMAT, and ENTRY
5 Derived-Type Definitions, Interface Blocks, Type
Statements
Declaration Statements, Enumeration Definitions,
Procedure Declarations, Specification Statements,
IMPLICIT Statements, and PARAMETER Statements
6 Executable constructs
7 CONTAINS Statement
8 Internal Subprograms or Module Subprograms
9 END Statement
Refer to Chapter 8, “Program units and procedures,” on page 147 or Chapter 11,
“Statements and attributes,” on page 271 for more details on rules and restrictions
concerning statement order.
14
XL Fortran: Language Reference

The normal execution sequence is the processing of references to specification
functions in any order, followed by the processing of executable statements in the
order they appear in a scoping unit.
A transfer of control is an alteration of the normal execution sequence. Some
statements that you can use to control the execution sequence are:
v
Control statements like DO and IF.
v
Input/output statements like READ and WRITE that contain an END=, ERR=,
or EOR= specifier.
When you reference a procedure that is defined by a subprogram, the execution of
the program continues with any specification functions referenced in the scoping
unit of the subprogram that defines the procedure. The program resumes with the
first executable statement following the ENTRY, FUNCTION or SUBROUTINE
statement that defines the procedure. When you return from the subprogram,
execution of the program continues from the point at which the procedure was
referenced or to a statement referenced by an alternate return specifier.
In this document, any description of the sequence of events in a specific transfer of
control assumes that no event, such as an error or the execution of a STOP
statement, changes that normal sequence.
Data types
A data type consists of a name, a set of valid values, constants used as a way to
denote those values, and a set of operations to manipulate those values. The two
categories of data types are Intrinsic types and Derived types.
A derived type is a composite data type that can contain both intrinsic and derived
data types.
Intrinsic types and their operations are predefined and always accessible. The two
classes of intrinsic types are numeric and nonnumeric, with a number of types
comprising each class.
Table 8. Intrinsic Types
Numeric Intrinsic Types
Nonnumeric Intrinsic Types
Integer
Logical
Real
Character
Complex
Vector 1
Byte 1
Byte 1
Note:
1 IBM extension
Type declaration: type parameters and specifiers
This is an overview section on declaring the type of an entity. The Statements
section contains the particular syntax details and rules for derived and intrinsic
type declarations.
Chapter 2. XL Fortran language fundamentals
15

XL Fortran provides one or more representation methods for each intrinsic data
type. You can optionally specify this representation method with a kind type
parameter value, using kind_param in your type declaration statement. This value
can indicate:
v
The range for the integer data type.
v
The decimal precision and exponent range for the real data type.
v
The decimal precision and exponent range for the complex data type.
v
The representation method for the character data type.
v
The representation method for the logical data type.
The BYTE intrinsic type does not have a kind type parameter.
A length type parameter specifies the number of characters for entities of type
character.
A type specifier denotes the type of all entities declared in a type declaration
statement. The INTEGER, REAL, COMPLEX, LOGICAL, and CHARACTER type
specifiers can include a kind_selector, that specifies the kind type parameter.
For example, here are some common ways you can declare a 4-byte integer:
v
INTEGER(4)
v
INTEGER(KIND=4)
v
INTEGER, where the default integer size is set to 4 bytes.
v
F2008
TYPE(INTEGER(4)) F2008
v
F2008
TYPE(INTEGER(KIND=4)) F2008
v
F2008
TYPE(INTEGER), where the default integer size is set to 4 bytes.
F2008
This document references 4-byte integers as INTEGER(4).
See Type Declaration for detailed information about type specifiers.
Applicable intrinsic procedures
For objects of an intrinsic type, the KIND intrinsic procedure returns the kind type
parameter of its argument.
You can use the LEN intrinsic procedure to determine the length type parameter of
a character object.
The SIZEOF intrinsic function returns the size of a data object in bytes.
Type parameter inquiry
You can use a type parameter inquiry to identify the type parameter value of a
data object.
Two examples of a type parameter inquiry are:
i%kind
string%len
16
XL Fortran: Language Reference

Determining Type
Each user-defined function or named entity has a data type. The type of an entity
accessed by host or use association is determined in the host scoping unit or
accessed module, respectively. The type of a name is determined, in the following
sequence, in one of three ways:
1. Explicitly, in one of the following ways:
v
From a specified type declaration statement (see “Type Declaration” on page
456 for details).
v
For function results, from a specified type statement or its FUNCTION
statement.
2. Implicitly, from a specified IMPLICIT type statement.
3. Implicitly, by predefined convention. By default (that is, in the absence of an
IMPLICIT type statement), if the first letter of the name is I, J, K, L, M, or N, the
type is default integer. Otherwise, the type is default real.
In a given scoping unit, if a letter, dollar sign, or underscore has not been specified
in an IMPLICIT statement, the implicit type used is the same as the implicit type
used by the host scoping unit. A program unit and interface body are treated as if
they had a host with an IMPLICIT statement listing the predefined conventions.
The data type of a literal constant is determined by its form.
Data objects
A data object is a variable, constant, or subobject of a constant.
A variable can have a value and can be defined or redefined during execution of
an executable program. A variable can be:
v
A scalar variable name
v
An array variable name
v
A subobject
A subobject of a variable is a portion of a named object that you can reference or
define. A subobject can be:
v
An array element.
v
An array section
v
A character substring
v
A structure component
A subobject of a constant is a portion of a constant. The referenced portion can
depend on a variable value.
Constants
A constant has a value and cannot be defined or redefined during execution of an
executable program. A constant with a name is a named constant. You can use
either the ENUM statement or the PARAMETER attribute to provide a constant
with a name. A constant without a name is a literal constant. A literal constant can
be of intrinsic type or typeless. A typeless constant can be:
v
Hexadecimal
v
Octal
v
Binary
Chapter 2. XL Fortran language fundamentals
17

v
Hollerith
The optional kind type parameter of a literal constant can only be a digit string or
a scalar integer named constant.
A signed literal constant can have a leading plus or minus sign. All other literal
constants must be unsigned. These constants do not have a leading sign. The value
zero is neither positive nor negative. You can specify zero as signed or unsigned.
Automatic objects
An automatic object is a data object dynamically allocated within a procedure
F2008
or a BLOCK construct F2008
. This object is a local entity of a
subprogram
F2008
or a BLOCK construct F2008
and can have a nonconstant
character length, a nonconstant array bound, or both. An automatic object is not a
dummy argument.
An automatic object always has the controlled automatic storage class.
You cannot specify an automatic object in any of the following statements:
v
COMMON
v
DATA
v
EQUIVALENCE
v
NAMELIST
Also, automatic objects cannot have the AUTOMATIC, PARAMETER, SAVE, or
STATIC attributes. You cannot initialize or define an automatic object with a
constant expression in a type declaration statement, but an automatic object can
have a default initialization. An automatic object must not appear in the
specification part of a main program or module.
Polymorphic entities (Fortran 2003)
A polymorphic entity is a data entity that is able to be of differing types during
program execution. The type of a data entity at a particular point during execution
of a program is its dynamic type. The declared type of a data entity is the type
that it is declared to have, either explicitly or implicitly.
You use the CLASS type specifier to declare polymorphic objects. If the CLASS
type specifier contains a type name, the declared type of a polymorphic object is
that type.
You can use the CLASS(*) specifier to declare an unlimited polymorphic object. An
unlimited polymorphic entity is not declared to have a type. It is not considered to
have the same declared type as any other entity, including another unlimited
polymorphic entity.
A nonpolymorphic entity is type-compatible only with entities of the same type.
For a polymorphic entity, type compatibility is based on its declared type: a
polymorphic entity that is not unlimited polymorphic is type-compatible with
entities of the same type or any of its extensions. Even though an unlimited
polymorphic entity is not considered to have a declared type, it is type-compatible
with all entities.
An entity is said to be type-compatible with a type if it is type-compatible with
entities of that type. An entity is type-, kind-, and rank-compatible (TKR) with
another entity if the first entity is type-compatible with the second, the kind type
18
XL Fortran: Language Reference

parameters of the first entity have the same values as corresponding kind type
parameters of the second, and both entities have the same rank.
Only components of the declared type of a polymorphic object may be designated
by component selection.
A polymorphic allocatable object may be allocated to be of any type with which it
is type-compatible. A polymorphic pointer or dummy argument may, during
program execution, be associated with objects with which it is type-compatible.
The following table lists the dynamic type of objects.
Table 9. Dynamic type of objects
Object
Dynamic type
Allocated allocatable polymorphic object
The type with which the object was
allocated.
Associated polymorphic pointer
The dynamic type of the pointer's target.
Nonallocatable nonpointer polymorphic
The dynamic type of dummy's associated
dummy argument
actual argument.
Unallocated allocatable
The allocatable object's declared type.
Disassociated pointer
The pointer's declared type.
Entity identified by an associate name
The dynamic type of the selector with which
the object is associated.
Nonpolymorphic object
The object's declared type.
Related information
v
“CLASS (Fortran 2003)” on page 300
Definition status of variables
A variable is either defined or undefined, and its definition status can change
during program execution. A named constant has a value and cannot be defined or
redefined during program execution.
Arrays (including sections), structures, and variables of character, complex or
derived-type are objects made up of zero or more subobjects. Associations can be
established between variables and subobjects and between subobjects of different
variables.
v
An object is defined if all of its subobjects are defined. That is, each object or
subobject has a value that does not change until it becomes undefined or until it
is redefined with a different value.
v
A derived type scalar object is defined if and only if all of its nonpointer
components are defined.
v
A complex or character scalar object is defined if and only if all of its subobjects
are defined.
v
If an object is undefined, at least one of its subobjects is undefined. An
undefined object or subobject cannot provide a predictable value.
Variables are initially defined if they are specified to have initial values by DATA
statements, type declaration statements, or STATIC statements. Variables with the
BIND attribute that are initialized by means other than Fortran are also initially
Chapter 2. XL Fortran language fundamentals
19

defined. In addition, default initialization can cause a variable to be initially
defined. Zero-sized arrays and zero-length character objects are always defined.
All other variables are initially undefined.
Events causing definition
The following events will cause a variable to become defined:
1. Execution of an intrinsic assignment statement other than a masked array
assignment statement or FORALL assignment statement causes the variable
that precedes the equal sign to become defined.
Execution of a defined assignment statement may cause all or part of the
variable that precedes the equal sign to become defined.
2.
Execution of a masked array assignment statement or FORALL assignment
statement may cause some or all of the array elements in the assignment
statement to become defined.
3. As execution of an input statement proceeds, each variable that is assigned a
value from the input file becomes defined at the time that data are transferred
to it. Execution of a WRITE statement whose unit specifier identifies an
internal file causes each record that is written to become defined.
As execution of an asynchronous input statement proceeds, the variable does
not become defined until the matching WAIT statement is executed.
4. Execution of a DO statement causes the DO variable, if any, to become
defined.
5. Default initialization may cause a variable to be initially defined.
6. Beginning of execution of the action specified by an implied-DO list in an
input/output statement causes the implied-DO variable to become defined.
7. Execution of an ASSIGN statement causes the variable in the statement to
become defined with a statement label value.
8. A reference to a procedure causes the entire dummy argument data object to
become defined if the dummy argument does not have INTENT(OUT), and
the entire corresponding actual argument is defined with a value that is not a
statement label.
A reference to a procedure causes a subobject of a dummy argument that does
not have INTENT(OUT) to become defined if the corresponding subobject of
the corresponding actual argument is defined.
9. Execution of an input/output statement containing an IOSTAT= specifier
causes the specified integer variable to become defined.
10.
Execution of an input/output statement containing an IOMSG=
specifier causes the specified character variable to become defined when an
error, end-of-file or end-of-record occurs.
11. Execution of a READ statement containing a SIZE= specifier causes the
specified integer variable to become defined.
12. Execution of a READ or WRITE statement in XL Fortran containing an ID=
specifier causes the specified integer variable to become defined.
13. Execution of a WAIT statement in XL Fortran containing a DONE= specifier
causes the specified logical variable to become defined.
14. Execution of a synchronous READ or WRITE statement in XL Fortran
containing a NUM= specifier causes the specified integer variable to become
defined.
20
XL Fortran: Language Reference

Execution of an asynchronous READ or WRITE statement containing a
NUM= specifier does not cause the specified integer variable to become
defined. The integer variable is defined upon execution of the matching WAIT
statement.
15. Execution of an INQUIRE statement causes any variable that is assigned a
value during the execution of the statement to become defined if no error
condition exists.
16. When a character storage unit becomes defined, all associated character
storage units become defined.
When a numeric storage unit becomes defined, all associated numeric storage
units of the same type become defined, except that variables associated with
the variable in an ASSIGN statement become undefined when the ASSIGN
statement is executed. When an entity of type DOUBLE PRECISION becomes
defined, all totally associated entities of double precision real type become
defined.
A nonpointer scalar object of type nondefault integer, real other than default
or double precision, nondefault logical, nondefault complex, nondefault
character of any length, or nonsequence type occupies a single unspecified
storage unit that is different for each case. A pointer that is distinct from other
pointers in at least one of type, kind, and rank occupies a single unspecified
storage unit. When an unspecified storage unit becomes defined, all associated
unspecified storage units become defined.
17. When a default complex entity becomes defined, all partially associated
default real entities become defined.
18. When both parts of a default complex entity become defined as a result of
partially associated default real or default complex entities becoming defined,
the default complex entity becomes defined.
19. When all components of a numeric sequence structure or character sequence
structure become defined as a result of partially associated objects becoming
defined, the structure becomes defined.
20. Execution of an ALLOCATE or DEALLOCATE statement with a STAT=
specifier causes the variable specified by the STAT= specifier to become
defined.
21.
If an error condition occurs during the execution of an ALLOCATE
or DEALLOCATE statement that has an ERRMSG= specifier, the
errmsg-variable becomes defined.
22. Allocation of a zero-sized array causes the array to become defined.
23. Invocation of a procedure causes any automatic object of zero size in that
procedure to become defined.
24. Execution of a pointer assignment statement that associates a pointer with a
target that is defined causes the pointer to become defined.
25. Invocation of a procedure that contains a nonpointer, nonallocatable,
automatic object, causes all nonpointer default-initialized subcomponents of
the object to become defined.
26. Invocation of a procedure that contains a nonpointer nonallocatable
INTENT(OUT) dummy argument causes all nonpointer default-initialized
subcomponents of the object to become defined.
27. Allocation of an object of a derived type where a nonpointer component is
initialized by default initialization, causes the component and its subobjects to
become defined.
28. In a FORALL statement or construct used in Fortran 95, the index-name
becomes defined when the index-name value set is evaluated.
Chapter 2. XL Fortran language fundamentals
21

29.
If a THREADPRIVATE nonpointer nonallocatable variable that does
not appear in a COPYIN clause is defined on entry into the first parallel
region, each new thread's copy of the variable is defined.
30. If a THREADPRIVATE common block that does not appear in a COPYIN
clause is defined on entry into the first parallel region, each new thread's copy
of the variable is defined.
31. For THREADPRIVATE variables that are specified in a COPYIN clause, each
new thread duplicates the master thread's definition, allocation and
association status of these variables. Therefore, if the master thread's copy of a
variable is defined on entry to a parallel region, each new thread's copy of the
variable will also be defined.
32. For THREADPRIVATE common blocks that are in a COPYIN clause, each
new thread duplicates the master thread's definition, allocation and
association status of the variables in these common blocks. Therefore, if the
master thread's copy of a common block variable is defined on entry to a
parallel region, each new thread's copy of the common block variable will also
be defined.
33. When a variable is specified in a FIRSTPRIVATE clause of a PARALLEL,
PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE,
SECTIONS, or SINGLE directive, each new thread duplicates the master
thread's definition and association status of the variable. Therefore, if the
master thread's copy of a variable is defined on entry to a parallel region, each
new thread's copy of the variable will also be defined.
34. When a variable, a dummy argument, or a private variable that its
data-sharing attribute is firstprivate in a TASK region, each task duplicates the
definition of the generating task and the association of the variable. If the
generating task's copy of a variable is defined on entry to the TASK region,
each new task's copy of the variable is also defined.
35. For each variable, or variable inside a common block, specified in a
COPYPRIVATE clause, then after the execution of the code enclosed in the
SINGLE construct and before any threads in the team have left the construct,
all copies of the variable become defined as follows:
v
If the variable has the POINTER attribute, then copies of the variable in
other threads in the team have the same pointer association status as the
copy of the variable belonging to the thread that executed the code enclosed
in the SINGLE construct.
v
If the variable does not have the POINTER attribute, then copies of the
variable in other threads in the team have the same definition as the copy
of the variable belonging to the thread that executed the code enclosed in
the SINGLE construct.
36.
F2008
Successful execution of an OPEN statement containing a NEWUNIT=
specifier causes the variable specified by the NEWUNIT= specifier to become
defined. F2008
37.
F2008
For an unsaved, nonpointer, nonallocatable, local variable of a
BLOCK construct, the execution of the BLOCK statement of the construct
containing the variable causes all nonpointer, default-initialized ultimate
components of the variable to become defined. F2008
Events causing undefinition
The following events will cause a variable to become undefined:
1. When a variable of a given type becomes defined, all associated variables of
different type become undefined. However, when a variable of type default
real is partially associated with a variable of type default complex, the
22
XL Fortran: Language Reference

complex variable does not become undefined when the real variable becomes
defined and the real variable does not become undefined when the complex
variable becomes defined. When a variable of type default complex is partially
associated with another variable of type default complex, definition of one
does not cause the other to become undefined.
2. Execution of an ASSIGN statement causes the variable in the statement to
become undefined as an integer. Variables that are associated with the variable
also become undefined.
3. If the evaluation of a function may cause an argument of the function or a
variable in a module or in a common block to become defined, and if a
reference to the function appears in an expression in which the value of the
function is not needed to determine the value of the expression, the argument
or variable becomes undefined when the expression is evaluated.
4. The execution of a RETURN statement or END statement within a
subprogram causes all variables that are local to its scoping unit, or that are
local to the current instance of its scoping unit for a recursive invocation, to
become undefined, except for the following:
a. Variables with the SAVE or STATIC attribute.
b. Variables in blank common.
c. According to Fortran 90, variables in a named common block that appears
in the subprogram and appears in at least one other scoping unit that is
making either a direct or indirect reference to the subprogram.
XL
Fortran does not undefine these variables, unless they are part of a
threadlocal common block.
d. Variables accessed from the host scoping unit.
e. According to Fortran 90, variables accessed from a module that also is
referenced directly or indirectly by at least one other scoping unit that is
making either a direct or indirect reference to the subprogram.
XL
Fortran does not undefine these variables.
f. According to Fortran 90, variables in a named common block that are
initially defined and that have not been subsequently defined or redefined.
XL Fortran does not undefine these variables.
5. When an error condition or end-of-file condition occurs during execution of
an input statement, all of the variables specified by the input list or
namelist-group of the statement become undefined.
6. When an error condition, end-of-file condition, or end-of-record condition
occurs during execution of an input/output statement and the statement
contains any implied-DO lists, all of the implied-DO variables in the
statement become undefined.
7. Execution of a defined assignment statement may leave all or part of the
variable that precedes the equal sign undefined.
8. Execution of a direct access input statement that specifies a record that has not
been written previously causes all of the variables specified by the input list
of the statement to become undefined.
9. Execution of an INQUIRE statement may cause the NAME=, RECL=,
NEXTREC=, and POS= variables to become undefined.
10. When a character storage unit becomes undefined, all associated character
storage units become undefined.
When a numeric storage unit becomes undefined, all associated numeric
storage units become undefined unless the undefinition is a result of defining
an associated numeric storage unit of different type (see (1) above).
Chapter 2. XL Fortran language fundamentals
23

When an entity of double precision real type becomes undefined, all totally
associated entities of double precision real type become undefined.
When an unspecified storage unit becomes undefined, all associated
unspecified storage units become undefined.
11. A reference to a procedure causes part of a dummy argument to become
undefined if the corresponding part of the actual argument is defined with a
value that is a statement label value.
12. When an allocatable entity is deallocated, it becomes undefined. Successful
execution of an ALLOCATE statement for a nonzero-sized object for which
default initialization has not been specified causes the object to become
undefined.
13. Execution of an INQUIRE statement causes all inquiry specifier variables to
become undefined if an error condition exists, except for the variable in the
IOSTAT= or
IOMSG=
specifier, if any.
14. When a procedure is invoked:
a. An optional dummy argument that is not associated with an actual
argument is undefined.
b. A nonpointer dummy argument with INTENT(OUT) and its associated
actual argument are undefined, except for nonpointer direct components
that have default initialization.
c. A pointer dummy argument with INTENT(OUT) and its associated actual
argument have an association status of undefined.
d. A subobject of a dummy argument is undefined if the corresponding
subobject of the actual argument is undefined.
e. The function result variable is undefined, unless it was declared with the
STATIC attribute and was defined in a previous invocation.
15. When the association status of a pointer becomes undefined or disassociated,
the pointer becomes undefined.
16. When the execution of a FORALL statement or construct in Fortran 95 has
completed, the index-name becomes undefined.
17.
When execution of a RETURN or END statement causes a variable
to become undefined, any variable of type C_PTR becomes undefined if its
value is the C address of any part of the variable that becomes undefined.
18. When a variable with the TARGET attribute is deallocated, any variable of
type C_PTR becomes undefined if its value is the C address of any part of the
variable that is deallocated.
19.
When a variable is specified in either the PRIVATE or
LASTPRIVATE clause of a PARALLEL, PARALLEL DO, DO, PARALLEL
SECTIONS, PARALLEL WORKSHARE, SECTIONS or SINGLE directive,
each new thread's copy of the variable is undefined when the thread is first
created.
20. When a variable is specified in the PRIVATE clause of a TASK directive, each
private copy of the variable is undefined when the task is first generated.
21. When a variable is specified in a FIRSTPRIVATE clause of a PARALLEL,
PARALLEL DO, DO, PARALLEL SECTIONS, PARALLEL WORKSHARE,
SECTIONS, SINGLE or TASK directive, each new thread duplicates the
master thread's definition and association status of the variable. Therefore, if
the master thread's copy of a variable is undefined on entry to a parallel
region, each new thread's copy of the variable will also be undefined.
24
XL Fortran: Language Reference

22. When a variable is specified in the NEW clause of an INDEPENDENT
directive, the variable is undefined at the beginning of every iteration of the
following DO loop.
23. When a variable appears in asynchronous input, that variable becomes
undefined, and remains undefined, until the matching WAIT statement is
reached.
24. If a THREADPRIVATE common block or a THREADPRIVATE variable is
specified in a COPYIN clause, each new thread duplicates the master thread's
definition, allocation and association status of the variables. Therefore, if the
master thread's copy of a variable is undefined on entry to a parallel region,
each new thread's copy of the variable will also be undefined.
25.
If a THREADPRIVATE common block variable or a
THREADPRIVATE variable has the ALLOCATABLE attribute, the allocation
status of each copy created will be not currently allocated.
26. If a THREADPRIVATE common block variable or a THREADPRIVATE
variable has the POINTER attribute with an initial association status of
disassociated through either default or explicit initialization, each copy will
have an association status of disassociated. Otherwise the association status of
each copy is undefined.
27. If a THREADPRIVATE common block variable or a THREADPRIVATE
variable has neither the ALLOCATABLE nor the POINTER attribute and is
initially defined through default or explicit initialization, each copy has the
same definition. Otherwise, each copy is undefined.
28.
F2008
When execution of a BLOCK construct is complete:
a. An unsaved, local variable of the BLOCK construct becomes undefined.
b. A variable of type C_PTR becomes undefined if its value is the C address of
an unsaved, local variable of the BLOCK construct.
F2008
Allocation status
The allocation status of an allocatable object is one of the following during
program execution:
v
Not currently allocated, which means that the object has never been allocated, if
it is given that status by the allocation transfer procedure, or that the last
operation on it was a deallocation.
v
Currently allocated, which means that the object has been allocated by an
ALLOCATE statement, if it is allocated during assignment, or if it is given that
status by the allocation transfer procedure.
v
Undefined, which means that the object does not have the SAVE or
STATIC attribute and was currently allocated when execution of a RETURN or
END statement resulted in no executing scoping units having access to it. In XL
Fortran, undefined status is only available when you use the
-qxlf90=noautodealloc option.
If the allocation status of an allocatable object is currently allocated, the object may
be referenced and defined. An allocatable object that is not currently allocated must
not be referenced or defined. If the allocation status of an allocatable object is
undefined, the object must not be referenced, defined, allocated, or deallocated.
Chapter 2. XL Fortran language fundamentals
25

When the allocation status of an allocatable object changes, the allocation status of
any associated allocatable object changes accordingly. Allocation of an allocatable
variable establishes values for the deferred type parameters of all associated
allocatable variables.
In the Fortran standard, the allocation status of an allocatable object that is
declared in the scope of a module is processor-dependent if it does not have the
SAVE attribute and was currently allocated when execution of a RETURN or END
statement resulted in no executing scoping units referencing the module.
F2008
An unsaved, allocatable, local variable of a BLOCK construct is
deallocated when execution exits the BLOCK construct. F2008
In XL Fortran, the allocation status of such an object remains currently
allocated.
Storage classes for variables (IBM extension)
Note: This section pertains only to storage for variables. Named constants and
their subobjects have a storage class of literal.
Fundamental storage classes
All variables are ultimately represented by one of five storage classes:
Automatic
for variables in a procedure that will not be retained once the procedure
ends. Variables reside in the stack storage area.
Static
for variables that retain memory throughout the program. Variables reside
in the data storage area. Uninitialized variables reside in the bss storage
area.
Common
for common block variables. If a common block variable is initialized, the
whole block resides in the data storage area; otherwise, the whole block
resides in the bss storage area.
Controlled Automatic
for automatic objects. Variables reside in the stack storage area. XL Fortran
allocates storage on entry to the procedure and deallocates the storage
when the procedure completes.
Controlled
for allocatable objects. Variables reside in the heap storage area. You must
explicitly allocate and deallocate the storage.
Secondary storage classes
None of the following storage classes own their own storage, but are associated
with a fundamental storage class at run time.
Pointee
is dependent on the value of the corresponding integer pointer.
Reference parameter
is a dummy argument whose actual argument is passed to a procedure
using the default passing method or %REF.
Value parameter
is a dummy argument whose actual argument is passed by value to a
procedure.
26
XL Fortran: Language Reference

For details on passing methods, see “%VAL and %REF (IBM extension)” on page
186.
Storage class assignment
Variable names are assigned storage classes in one of the following ways:
1. Explicitly:
v
Dummy arguments have an explicit storage class of reference parameter or
value parameter. See “%VAL and %REF (IBM extension)” on page 186 for
more details.
v
Pointee variables have an explicit storage class of pointee.
v
Variables for which the STATIC attribute is explicitly specified have an
explicit storage class of static.
v
Variables for which the AUTOMATIC attribute is explicitly specified have an
explicit storage class of automatic.
v
Variables that appear in a COMMON block have an explicit storage class of
common.
v
Variables for which the SAVE attribute is explicitly specified have an explicit
storage class of static, unless they also appear in a COMMON statement, in
which case their storage class is common.
v
Variables that appear in a DATA statement or are initialized in a type
declaration statement have an explicit storage class of static, unless they also
appear in a COMMON statement, in which case their storage class is
common.
v
Function result variables that are of type character or derived have the
explicit storage class of reference parameter.
v
Function result variables that do not have the SAVE or STATIC attribute
have an explicit storage class of automatic.
v
Automatic objects have an explicit storage class of controlled automatic.
v
Allocatable objects have an explicit storage class of controlled.
A variable that does not satisfy any of the above, but that is equivalenced with
a variable that has an explicit storage class, inherits that explicit storage class.
A variable that does not satisfy any of the above, and is not equivalenced with
a variable that has an explicit storage class, has an explicit storage class of static
if:
v
A SAVE statement with no list exists in the scoping unit or,
v
The variable is declared in the specification part of a main program.
2. Implicitly:
If a variable does not have an explicit storage class, it can be assigned an
implicit storage class as follows:
v
Variables whose names begin with a letter, dollar sign or underscore that
appears in an IMPLICIT STATIC statement have a storage class of static.
v
Variables whose names begin with a letter, dollar sign or underscore that
appears in an IMPLICIT AUTOMATIC statement have a storage class of
automatic.
In a given scoping unit, if a letter, dollar sign or underscore has not been
specified in an IMPLICIT STATIC or IMPLICIT AUTOMATIC statement, the
implicit storage class is the same as that in the host.
Variables declared in the specification part of a module are associated with the
static storage class.
Chapter 2. XL Fortran language fundamentals
27

A variable that does not satisfy any of the above but that is equivalenced with
a variable that has an implicit storage class, inherits that implicit storage class.
3. Default:
All other variables have the default storage class:
v
Static, if you specified the -qsave=all compiler option.
v
Static, for variables of derived type that have default initialization specified,
and automatic otherwise if you specify the –qsave=defaultinit compiler
option.
v
Automatic, if you specified the -qnosave compiler option. This is the default
setting.
See -qsave option in the XL Fortran Compiler Reference for details on the
default settings with regard to the invocation commands.
Typeless literal constants
A typeless constant does not have an intrinsic type in XL Fortran. Hexadecimal,
octal, binary, and Hollerith constants can be used in any situation where intrinsic
literal constants are used, except as the length specification in a type declaration
statement (although typeless constants can be used in a type_param_value in
CHARACTER type declaration statements). The number of digits recognized in a
hexadecimal, octal, or binary constant depends on the context in which the
constant is used.
Hexadecimal constants
The form of a hexadecimal constant is:
X
'
hexadecimal_number
'
Z
"
hexadecimal_number
"
'
hexadecimal_number
'
X
"
hexadecimal_number
"
Z
Z
hexadecimal_number
hexadecimal_number
is a string composed of digits (0-9) and letters (A-F, a-f). Corresponding
uppercase and lowercase letters are equivalent.
The Znn...nn form of a hexadecimal constant can only be used as a data
initialization value delimited by slashes. If this form of a hexadecimal constant is
the same string as the name of a constant you defined previously with the
PARAMETER attribute, XL Fortran recognizes the string as the named constant.
If 2x hexadecimal digits are present, x bytes are represented.
Examples
Z’0123456789ABCDEF’
Z"FEDCBA9876543210"
Z’0123456789aBcDeF’
Z0123456789aBcDeF
! This form can only be used as an initialization value
28
XL Fortran: Language Reference

Related information
See “Using typeless constants” on page 30 for information on how XL Fortran
interprets the constant.
Octal constants
The form of an octal constant is:
O
'
octal_number
'
"
octal_number
"
'
octal_number
'
O
"
octal_number
"
octal_number
is a string composed of digits (0-7)
Because an octal digit represents 3 bits, and a data object represents a multiple of 8
bits, the octal constant may contain more bits than are needed by the data object.
For example, an INTEGER(2) data object can be represented by a 6-digit octal
constant if the leftmost digit is 0 or 1; an INTEGER(4) data object can be
represented by an 11-digit constant if the leftmost digit is 0, 1, 2, or 3; an
INTEGER(8) can be represented by a 22-digit constant if the leftmost digit is 0 or
1.
Examples
O’01234567’
"01234567"O
Related information
See “Using typeless constants” on page 30 for information on how the constant is
interpreted by XL Fortran.
Binary constants
The form of a binary constant is:
B
'
binary_number
'
"
binary_number
"
'
binary_number
'
B
"
binary_number
"
binary_number
is a string formed from the digits 0 and 1
If 8x binary digits are present, x bytes are represented.
Examples
B"10101010"
’10101010’B
Chapter 2. XL Fortran language fundamentals
29

Related information
See “Using typeless constants” for information on how XL Fortran interprets the
constant.
Hollerith constants
The form of a Hollerith constant is:
n
H
character_string
A Hollerith constant consists of a nonempty string of characters capable of
representation in the processor and preceded by nH, where n is a positive unsigned
integer constant representing the number of characters after the H. n cannot specify
a kind type parameter. The number of characters in the string may be from 1 to
255.
Note: If you specify nH and fewer than n characters are specified after the n, any
blanks that are used to extend the input line to the right margin are considered to
be part of the Hollerith constant. A Hollerith constant can be continued on a
continuation line. At least n characters must be available for the Hollerith constant.
XL Fortran also recognizes escape sequences in Hollerith constants, unless the
-qnoescape compiler option is specified. If a Hollerith constant contains an escape
sequence, n is the number of characters in the internal representation of the string,
not the number of characters in the source string. (For example, 2H\"\" represents
a Hollerith constant for two double quotation marks.)
XL Fortran provides support for multibyte characters within character constants,
Hollerith constants, H edit descriptors, character-string edit descriptors, and
comments. This support is provided through the -qmbcs option. Assignment of a
constant containing multibyte characters to a variable that is not large enough to
hold the entire string may result in truncation within a multibyte character.
Support is also provided for Unicode characters and filenames. If the environment
variable LANG is set to UNIVERSAL and the -qmbcs compiler option is specified,
the compiler can read and write Unicode characters and filenames.
See “Using typeless constants” for information on how the constant is interpreted
by XL Fortran.
Using typeless constants
The data type and length of a typeless constant are determined by the context in
which you use the typeless constant. XL Fortran does not convert the data type
and length until you use them and context is understood.
v
If you compile your program with the -qctyplss compiler option, character
constant expressions follow the rules that apply to Hollerith constants.
v
A typeless constant can assume only one of the intrinsic data types.
v
When you use a typeless constant with an arithmetic or logical unary operator,
the constant assumes a default integer type.
v
When you use a typeless constant with an arithmetic, logical, or relational binary
operator, the constant assumes the same data type as the other operand. If both
30
XL Fortran: Language Reference

operands are typeless constants, they assume a type of default integer unless
both operands of a relational operator are Hollerith constants. In this case, they
both assume a character data type.
v
When you use a typeless constant in a concatenation operation, the constant
assumes a character data type.
v
When you use a typeless constant as the expression on the right-hand side of an
assignment statement, the constant assumes the type of the variable on the
left-hand side.
v
When you use a typeless constant in a context that requires a specific data type,
the constant assumes that data type.
v
When you use a typeless constant as an initial value in a DATA statement,
STATIC statement, or type declaration statement, or as the constant value of a
named constant in a PARAMETER statement, or when the typeless constant is
to be treated as any noncharacter type of data, the following rules apply:
– If a hexadecimal, octal, or binary constant is smaller than the length expected,
XL Fortran adds zeros on the left. If it is longer, the compiler truncates on the
left.
– If a Hollerith constant is smaller than the length expected, the compiler adds
blanks on the right. If it is longer, the compiler truncates on the right.
– If a typeless constant specifies the value of a named constant with a character
data type having inherited length, the named constant has a length equal to
the number of bytes specified by the typeless constant.
v
When a typeless constant is treated as an object of type character (except when
used as an initial value in a DATA, STATIC, type declaration, or component
definition statement), the length is determined by the number of bytes
represented by the typeless constant.
v
When you use a typeless constant as part of a complex constant, the constant
assumes the data type of the other part of the complex constant. If both parts are
typeless constants, the constants assume the real data type with length sufficient
to represent both typeless constants.
v
When you use a typeless constant as an actual argument, the type of the
corresponding dummy argument must be an intrinsic data type. The dummy
argument must not be a procedure, pointer, array, object of derived type, or
alternate return specifier.
v
When you use a typeless constant as an actual argument, and:
– The procedure reference is to a generic intrinsic procedure,
– All of the arguments are typeless constants, and
– There is a specific intrinsic procedure that has the same name as the generic
procedure name,
the reference to the generic name will be resolved through the specific
procedure.
v
When you use a typeless constant as an actual argument, and:
– The procedure reference is to a generic intrinsic procedure,
– All of the arguments are typeless constants, and
– There is no specific intrinsic procedure that has the same name as the generic
procedure name,
the typeless constant is converted to default integer. If a specific intrinsic
function takes integer arguments, the reference is resolved through that specific
function. If there are no specific intrinsic functions, the reference is resolved
through the generic function.
Chapter 2. XL Fortran language fundamentals
31

v
When you use a typeless constant as an actual argument, and:
– The procedure reference is to a generic intrinsic procedure, and
– There is another argument specified that is not a typeless constant,
the typeless constant assumes the type of that argument. However, if you specify
the compiler option -qport=typlssarg, the actual argument is converted to
default integer. The selected specific intrinsic procedure is based on that type.
v
When you use a typeless constant as an actual argument, and the procedure
name is established to be generic but is not an intrinsic procedure, the generic
procedure reference must resolve to only one specific procedure. The constant
assumes the data type of the corresponding dummy argument of that specific
procedure. See Example 2.
v
When you use a typeless constant as an actual argument, and the procedure
name is established to be only specific, the constant assumes the data type of the
corresponding dummy argument.
v
When you use a typeless constant as an actual argument, and:
– The procedure name has not been established to be either generic or specific,
and
– The constant has been passed by reference,
the constant assumes the default integer size but no data type, unless it is a
Hollerith constant. The default for passing a Hollerith constant is the same as if
it were a character actual argument. However, using the compiler option
-qctyplss=arg will cause a Hollerith constant to be passed as if it were an integer
actual argument. See “Resolution of procedure references” on page 196 for more
information about establishing a procedure name to be generic or specific.
v
When you use a typeless constant as an actual argument, and:
– The procedure name has not been established to be either generic or specific,
and
– The constant has been passed by value,
the constant is passed as if it were a default integer for hexadecimal, binary, and
octal constants.
If the constant is a Hollerith constant and it is smaller than the size of a default
integer, XL Fortran adds blanks on the right. If the constant is a Hollerith
constant and it is larger than 8 bytes, XL Fortran truncates the rightmost
Hollerith characters. See “Resolution of procedure references” on page 196 for
more information about establishing a procedure name to be generic or specific.
v
When you use a typeless constant in any other context, the constant assumes the
default integer type, with the exception of Hollerith constants. Hollerith
constants assume a character data type in the following situations:
– An H edit descriptor
– A relational operation with both operands being Hollerith constants
– An input/output list
v
If a typeless constant is to be treated as a default integer but the value cannot be
represented within the value range for a default integer, the constant is
promoted to a representable kind.
v
A kind type parameter must not be replaced with a logical constant even if
-qintlog is on, nor by a character constant even if -qctyplss is on, nor can it be a
typeless constant.
32
XL Fortran: Language Reference

Examples
Example 1
INT=B’1’
! Binary constant is default integer
RL4=X’1’
! Hexadecimal constant is default real
INT=INT + O’1’
! Octal constant is default integer
RL4=INT + B’1’
! Binary constant is default integer
INT=RL4 + Z’1’
! Hexadecimal constant is default real
ARRAY(O’1’)=1.0
! Octal constant is default integer
LOGICAL(8) LOG8
LOG8=B’1’
! Binary constant is LOGICAL(8), LOG8 is .TRUE.
Example 2
INTERFACE SUB
SUBROUTINE SUB1( A )
REAL A
END SUBROUTINE
SUBROUTINE SUB2( A, B )
REAL A, B
END SUBROUTINE
SUBROUTINE SUB3( I )
INTEGER I
END SUBROUTINE
END INTERFACE
CALL SUB(’C0600000’X, ’40066666’X)
! Resolves to SUB2
CALL SUB(’00000000’X)
! Invalid - ambiguous, may
! resolve to either SUB1 or SUB3
Chapter 2. XL Fortran language fundamentals
33

34
XL Fortran: Language Reference

Chapter 3. Intrinsic data types
Intrinsic types and their operations are predefined and always accessible. The two
classes of intrinsic types are numeric and nonnumeric, with a number of types
comprising each class.
Table 10. Intrinsic Types
Numeric Intrinsic Types
Nonnumeric Intrinsic Types
Integer
Logical
Real
Character
Complex
Vector 1
Byte 1
Byte 1
Note:
1 IBM extension
XL Fortran also supports derived types, which are composite data types that can
contain both intrinsic and derived types.
Integer
IBM extension
The Range of integer values table contains the range of values that XL Fortran can
represent using the integer data type.
Table 11. Range of integer values
Kind parameter
Range of values
1
-128 through 127
2
-32 768 through 32 767
4
-2 147 483 648 through 2 147 483 647
8
-9 223 372 036 854 775 808 through 9 223 372 036 854 775 807
XL Fortran sets the default kind type parameter to 4. The kind type parameter is
equivalent to the byte size for integer values. Use the -qintsize compiler option to
change the default integer size to 2, 4, or 8 bytes. Note that the -qintsize option
similarly affects the default logical size.
End of IBM extension
The integer type specifier must include the INTEGER keyword.
The form of a signed integer literal constant is:
© Copyright IBM Corp. 1996, 2012
35

digit
+
_
kind_param
-
kind_param
is either a digit-string or a scalar-int-constant-name
A signed integer literal constant has an optional sign, followed by a string of
decimal digits containing no decimal point and expressing a whole number,
optionally followed by a kind type parameter. A signed, integer literal constant can
be positive, zero, or negative. If unsigned and nonzero, the constant is assumed to
be positive.
If kind_param is specified, the magnitude of the literal constant must be
representable within the value range permitted by that kind_param.
IBM extension
If no kind_param is specified in XL Fortran, and the magnitude of the constant
cannot be represented as a default integer, the constant is promoted to a kind in
which it can be represented.
XL Fortran represents integers internally in two's-complement notation, where the
leftmost bit is the sign of the number.
End of IBM extension
Example of integer constants
0
! has default integer size
-173_2
! 2-byte constant
9223372036854775807
! Kind type parameter is promoted to 8
Real
IBM extension
The following table shows the range of values that XL Fortran can represent with
the real data type:
Kind
Approximate Absolute Approximate Absolute Approximate Precision
Parameter
Nonzero Minimum
Maximum
(decimal digits)
4
1.175494E-38
3.402823E+38
7
8
2.225074D-308
1.797693D+308
15
16
2.225074Q-308
1.797693Q+308
31
XL Fortran sets the default kind type parameter to 4. The kind type parameter is
equivalent to the byte size for real values. Use the -qrealsize compiler option to
change the default real size to 4 or 8 bytes. Note that the -qrealsize option affects
the default complex size.
36
XL Fortran: Language Reference

XL Fortran represents REAL(4) and REAL(8) numbers internally in the ANSI/IEEE
binary floating-point format, which consists of a sign bit (s), a biased exponent (e),
and a fraction (f). The REAL(16) representation is based on the REAL(8) format.
REAL(4)
Bit no. 0....|....1....|....2....|....3.
seeeeeeeefffffffffffffffffffffff
REAL(8)
Bit no. 0....|....1....|....2....|....3....|....4....|....5....|....6...
seeeeeeeeeeeffffffffffffffffffffffffffffffffffffffffffffffffffff
REAL(16)
Bit no. 0....|....1....|....2....|....3....|....4....|....5....|....6...
seeeeeeeeeeeffffffffffffffffffffffffffffffffffffffffffffffffffff
Bit no. .|....7....|....8....|....9....|....0....|....1....|....2....|..
seeeeeeeeeeeffffffffffffffffffffffffffffffffffffffffffffffffffff
This ANSI/IEEE binary floating-point format also provides representations for
+infinity, -infinity, and NaN (not-a-number) values. A NaN can be further classified
as a quiet NaN (NaNQ) or a signaling NaN (NaNS). See Implementation details of
XL Fortran floating-point processing for details on the internal representation of
NaN values.
The definition of intrinsic RANGE is INT(MIN(LOG10(HUGE(X)), -LOG10(TINY(X)))).
For REAL(8) numbers, the HUGE intrinsic returns 0x7FEFFFFFFFFFFFFF and the
TINY intrinsic returns 0x0010000000000000. As a result, we have
INT(MIN(308.254715559916747, 307.652655568588784)), and therefore the range is
307. Note that the LOG scale is not symmetric on both ends of the exponent.
The IBM format of REAL(16) numbers is composed of two REAL(8) numbers of
different magnitudes that do not overlap. That is, the binary exponents differ by at
least the number of fraction bits in a REAL(8).
For REAL(16), the RANGE intrinsic returns the range of the numbers that have
both REAL(8) numbers normalized. Consequently, for REAL(16) numbers, the
HUGE intrinsic returns 0x7FEFFFFFFFFFFFFF7C9FFFFFFFFFFFFF and the TINY
intrinsic returns 0x03600000000000000000000000000000. As a result, we have
INT(MIN(308.25471555991674389886862819788120,
291.69806579839777816211298898803388)), where the range is 291.
308 is the lowest or highest exponent that can be represented in the REAL(8) or
REAL(16) numbers.
End of IBM extension
A real type specifier must include either the REAL keyword or the DOUBLE
PRECISION keyword. The precision of DOUBLE PRECISION values is twice that
of default real values. See “REAL” on page 431 and “DOUBLE PRECISION” on
page 330 for details on declaring entities of type real.
The forms of a real literal constant are:
v
A basic real constant optionally followed by a kind type parameter
v
A basic real constant followed by an exponent and an optional kind type
parameter
v
An integer constant (with no kind_param) followed by an exponent and an
optional kind type parameter
Chapter 3. Intrinsic data types
37

A basic real constant has, in order, an optional sign, an integer part, a decimal
point, and a fractional part. Both the integer part and fractional part are strings of
digits; you can omit either of these parts, but not both. You can write a basic real
constant with more digits than XL Fortran will use to approximate the value of the
constant. XL Fortran interprets a basic real constant as a decimal number.
The form of a real constant is:
digit
exponent
+
-
digit
.
+
exponent
-
digit
.
digit
+
exponent
-
digit
_
kind_param
exponent
E
digit_string
D
+
Q
-
kind_param
is either a digit-string or a scalar-int-constant-name
digit_string denotes a power of 10. E specifies a constant of type default real, unless
you also include a kind_param, which overrides the default type. D specifies a
constant of type default DOUBLE PRECISION.
Q specifies a constant of
type REAL(16) in XL Fortran.
If both exponent and kind_param are specified, the exponent letter must be E. If D or
Q is specified, kind_param must not be specified.
A real literal constant that is specified without an exponent and a kind type
parameter is of type default real.
Example of integer constants
38
XL Fortran: Language Reference

+0.
+5.432E02_16
!543.2 in 16-byte representation
7.E3
3.4Q-301
! Extended-precision constant
Complex
A complex type specifier must include one of the following keywords:
v
The COMPLEX keyword.
v
The DOUBLE COMPLEX keyword.
See “COMPLEX” on page 307 and “DOUBLE COMPLEX (IBM extension)” on page
327 for details on declaring entities of type complex.
IBM extension
The following table shows the corresponding values for the kind type parameter
and the length specification when the complex type specifier has the COMPLEX
keyword:
Kind Type Parameter i
Length Specification j
COMPLEX(i)
COMPLEX*j
4
8
8
16
16
32
In XL Fortran, the kind type parameter specifies the precision of each part of the
complex entity, while the length specification specifies the length of the whole
complex entity.
End of IBM extension
The kind of a complex constant is determined by the kind of the constants in the
real and imaginary parts.
The precision of DOUBLE COMPLEX values is twice that of default complex
values.
Scalar values of type complex can be formed using complex constructors. The form
of a complex constructor is:
(
expression
,
expression
)
A complex literal constant is a complex constructor where each expression is a pair
of constant expressions. Variables and expressions can be used in each part of the
complex constructor as an XL Fortran extension.
Chapter 3. Intrinsic data types
39

In Fortran 95 you are only allowed to use a single signed integer, or real literal
constant in each part of the complex constructor. In Fortran 2003, you can also use
a named constant.
F2008
In Fortran 2008, you can use complex part designators to access the real or
imaginary part of complex entities directly. The type of a complex part designator
is real and its kind and shape are those of the designator that appears to the left of
the complex part selector. A complex part selector is either %RE or %IM. %RE
selects the real part of a complex entity and %IM selects the imaginary part of a
complex entity. Here is the syntax for complex part designators where designator
has to be of type complex:
designator
%
IM
RE
Complex part designators follow the rules for real data types. In addition, you can
use complex part designators as variables in assignment statements; if x is of type
complex, x%IM=0.0 sets the imaginary part of x to zero.
F2008
If both parts of the literal constant are of type real, the kind type parameter of the
literal constant is the kind parameter of the part with the greater precision, and the
kind type parameter of the part with lower precision is converted to that of the
other part.
If both parts are of type integer, they are each converted to type default real. If one
part is of type integer and the other is of type real, the integer is converted to type
real with the precision of the real part.
See “COMPLEX” on page 307 and “DOUBLE COMPLEX (IBM extension)” on page
327 for details on declaring entities of type complex.
Each part of a complex number has the same internal representation as a real
number with the same kind type parameter.
Examples of complex constants
(3_2,-1.86)
! Integer constant 3 is converted to default real
! for constant 3.0.
(45Q6,6D45)
! The imaginary part is converted to extended
! precision 6.Q45.
(1+1,2+2)
! Use of constant expressions. Both parts are
! converted to default real.
Examples of complex part designators
COMPLEX :: x, y, z
print *, x%RE ! Prints the same value as REAL(x)
print *, y%IM ! Prints the same value as AIMAG(y)
z%IM = 0.0
! Sets the imaginary part of z to zero
40
XL Fortran: Language Reference

Logical
IBM extension
The following table shows the values that XL Fortran can represent using the
logical data type:
Kind parameter
Values
Internal (hex) Representation
1
.TRUE.
01
.FALSE.
00
2
.TRUE.
0001
.FALSE.
0000
4
.TRUE.
00000001
.FALSE.
00000000
8
.TRUE.
0000000000000001
.FALSE.
0000000000000000
Note: Any internal representation other than 1 for .TRUE. and 0 for .FALSE. is
undefined.
XL Fortran sets the default kind type parameter to 4. The kind type parameter is
equivalent to the byte size for logical values. Use the -qintsize compiler option to
change the default logical size to 2, 4, or 8 bytes. Note that the -qintsize option
similarly affects the default integer size. Use –qintlog to mix integer and logical
data entities in expressions and statements.
The -qport=clogicals option allows you to instruct the compiler to treat all nonzero
integers used in logical expressions as TRUE. In order to use the -qport=clogicals
option, you must also specify the -qintlog option.
End of IBM extension
The logical type specifier must include the LOGICAL keyword. See “LOGICAL”
on page 393 for details on declaring entities of type logical.
The form of a logical literal constant is:
.TRUE.
.FALSE.
_
kind_param
kind_param
is either a digit-string or a scalar-int-constant-name
A logical constant can have a logical value of either true or false.
You can also use the abbreviations T and F (without the periods) for
.TRUE. and .FALSE., respectively, but only in formatted input, or as initial values
Chapter 3. Intrinsic data types
41

in DATA statements, STATIC statements, or type declaration statements. A kind
type parameter cannot be specified for the abbreviated form. If T or F has been
defined as a named constant, it is treated as that named constant rather than the
logical literal constant.
Example of a logical constant
.FALSE._4
.TRUE.
Character
The character type specifier must include the CHARACTER keyword. See
“CHARACTER” on page 296 for details on declaring entities of type character.
The form of a character literal constant is:
'
character_string
'
kind_param
_
"
character_string
"
kind_param
is either a digit-string or a scalar-int-constant-name
XL Fortran supports a kind type parameter value of 1, representing the
ASCII collating sequence.
Character literal constants can be delimited by double quotation marks as well as
apostrophes.
character_string consists of any characters capable of representation in XL Fortran,
except the new-line character, because it is interpreted as the end of the source line.
The delimiting apostrophes (') or double quotation marks (") are not part of the
data represented by the constant. Blanks embedded between these delimiters are
significant.
If a string is delimited by apostrophes, you can represent an apostrophe within the
string with two consecutive apostrophes (without intervening blanks). If a string is
delimited by double quotation marks, you can represent a double quotation mark
within the string with two consecutive double quotation marks (without
intervening blanks). The two consecutive apostrophes or double quotation marks
will be treated as one character.
You can place a double quotation mark within a character literal constant delimited
by apostrophes to represent a double quotation mark, and an apostrophe character
within a character constant delimited by double quotation marks to represent a
single apostrophe.
The length of a character literal constant is the number of characters between the
delimiters, except that each pair of consecutive apostrophes or double quotation
marks counts as one character.
A zero-length character object uses no storage.
In XL Fortran each character object requires 1 byte of storage.
42
XL Fortran: Language Reference

For compatibility with C language usage, XL Fortran recognizes the following
escape sequences in character strings:
Escape
Meaning
\b
Backspace
\f
Form feed
\n
New-line
\r
New-line
\t
Tab
\0
Null
\'
Apostrophe
(does not terminate a string)
\"
Double quotation mark
(does not terminate a string)
\\
Backslash
\x
x, where x is any other character
To ensure that scalar character constant expressions in procedure references are
terminated with null characters (\0) for C compatibility, use the -qnullterm
compiler option. (See -qnullterm option in the XL Fortran Compiler Reference for
details and exceptions).
All escape sequences represent a single character.
If you do not want these escape sequences treated as a single character, specify the
-qnoescape compiler option. (See -qescape option in the XL Fortran Compiler
Reference.) The backslash will have no special significance.
The maximum length of a character literal constant depends on the maximum
number of characters allowed in a statement.
If you specify the -qctyplss compiler option, character constant
expressions are treated as if they are Hollerith constants. See “Hollerith constants”
on page 30 for information on Hollerith constants. For information on the -qctyplss
compiler option, see -qctyplss option in the XL Fortran Compiler Reference
XL Fortran supports multibyte characters within character literal constants,
Hollerith constants, H edit descriptors, character-string edit descriptors, and
comments through the -qmbcs compiler option.
Support is also provided for Unicode characters and filenames. If the environment
variable LANG is set to UNIVERSAL and the -qmbcs compiler option is specified,
the compiler can read and write Unicode characters and filenames. See the XL
Fortran Compiler Reference for more information.
Examples of character constants
Example 1:
’’
! Zero-length character constant.
Chapter 3. Intrinsic data types
43

Example 2:
1_"ABCDEFGHIJ"
! Character constant of length 10, with kind 1.
Example 3:
’\"\2\’\A567\\\\\’’
! Character constant of length 10 "2’A567\\’.
Character substrings
A character substring is a contiguous portion of a character string (called a parent
string), which is a scalar variable name, scalar constant, scalar structure
component, or array element. A character substring is identified by a substring
reference whose form is:
scalar_variable_name
(
:
)
array_element
int_expr1
int_expr2
scalar_constant
scalar_struct_comp
int_expr1 and int_expr2
specify the leftmost character position and rightmost character position,
respectively, of the substring. Each is a scalar integer expression called a
substring expression.
The length of a character substring is the result of the evaluation of MAX(int_expr2
- int_expr1 + 1,0).
If int_expr1 is less than or equal to int_expr2, their values must be such that:
v
1 ≤ int_expr1 ≤ int_expr2 ≤ length
where length is the length of the parent string. If int_expr1 is omitted, its default
value is 1. If int_expr2 is omitted, its default value is length.
FORTRAN 77 does not allow character substrings of length 0. Fortran 90
and up does allow these substrings. To perform compile-time checking on
substring bounds in accordance with FORTRAN 77 rules, use the -qnozerosize
compiler option. For Fortran 90 compliance, use -qzerosize. To perform run-time
checking on substring bounds, use both the -qcheck option and the -qzerosize (or
-qnozerosize) option. (See the XL Fortran Compiler Reference for more information.)
A substring of an array section is treated differently. See “Substring ranges” on
page 88.
Examples
CHARACTER(8) ABC, X, Y, Z
ABC = ’ABCDEFGHIJKL’(1:8)
! Substring of a constant
X = ABC(3:5)
! X = ’CDE’
Y = ABC(-1:6)
! Not allowed in either FORTRAN 77 or Fortran 90
Z = ABC(6:-1)
! Z = ’’ valid only in Fortran 90
44
XL Fortran: Language Reference

Byte (IBM extension)
The byte type specifier is the BYTE keyword in XL Fortran. See “BYTE (IBM
extension)” on page 289 for details on declaring entities of type byte.
The BYTE intrinsic data type does not have its own literal constant form. A BYTE
data object is treated as an INTEGER(1), LOGICAL(1), or CHARACTER(1) data
object, depending on how it is used.
Vector (IBM extension)
An entity you declare using the VECTOR keyword as part of a type declaration
statement is of a vector type. An entity of a vector type has the same type as
another entity if both entities are vectors that contain elements of the same type
and kind. Otherwise, the two entities are of different types. You must not include
vector objects in formatted I/O.
A vector can be any of the following types:
v
A PIXEL vector
v
An INTEGER vector with elements that have a kind type parameter of 1, 2, 4,
or 8
v
An UNSIGNED vector with elements that have a kind type parameter of 1, 2, 4,
or 8
v
A REAL vector with elements that have a kind parameter of 4 or 8
Note: A vector must only be declared if your -qarch option specifies an
architecture that supports the VMX or VSX instruction set extensions. The
INTEGER(8), UNSIGNED(8), and REAL(8) types require an architecture that
supports the VSX instruction set extensions, such as POWER7®. When you use
these types, you must specify an appropriate -qarch suboption, such as
-qarch=pwr7.
A vector is always a 16-byte entity.
v
INTEGER(1) or UNSIGNED(1) vectors contains 16 elements.
v
INTEGER(2), UNSIGNED(2), or PIXEL vectors contain 8 elements.
v
INTEGER(4), UNSIGNED(4), or REAL(4) vectors contain 4 elements.
v
INTEGER(8), UNSIGNED(8), or REAL(8) vectors contain 2 elements.
If kind type parameters are not specified for elements of INTEGER, or
UNSIGNED vectors, the elements have the default integer kind. If kind type
parameters are not specified for elements of REAL vectors, the elements have the
default real kind.
Vectors must be aligned on a 16-byte boundary. XL Fortran automatically aligns
vectors to 16 bytes, except in the following cases, where:
v
The vector is a component of a sequence type or a record structure.
v
The vector is a component of a derived type that has the BIND attribute and
you compile with the -qalign=bindc=packed or -qalign=bindc=bit_packed
options. This aligns the vector to a one-byte boundary.
v
The vector is a member of a common block.
v
The vector is storage-associated with a member of a common block that does not
have a 16-byte boundary alignment.
Chapter 3. Intrinsic data types
45

v
The vector is storage-associated with an array element that does not have a
16-byte boundary alignment.
Use the Vector Interlanguage Interoperability table to determine the corresponding XL
C/C++ vector type when passing vectors between XL C/C++ and XL Fortran.
Table 12. Vector interlanguage interoperability
XL Fortran vector type
XL C/C++ vector type
VECTOR(INTEGER(1))
vector signed char
VECTOR(INTEGER(2))
vector signed short
VECTOR(INTEGER(4))
vector signed int, vector signed long
VECTOR(INTEGER(8))
vector signed long long
VECTOR(PIXEL)
vector pixel
VECTOR(REAL(4))
vector float
VECTOR(REAL(8))
vector double
VECTOR(UNSIGNED(1))
vector unsigned char
VECTOR(UNSIGNED(2))
vector unsigned short
VECTOR(UNSIGNED(4))
vector unsigned int, vector unsigned long
VECTOR(UNSIGNED(8))
vector unsigned long long
Pixel (IBM extension)
The PIXEL keyword specifies the pixel type. A pixel is a two-byte entity that the
compiler interprets in four parts. The first part consists of one bit. The remaining
three parts consist of 5 bits each. Pixel literals are not supported. You must specify
a pixel only as part of a vector declaration.
Unsigned (IBM extension)
The UNSIGNED keyword specifies the unsigned integer type. Use the -qintsize
compiler option to change the default integer size to 2 or 4 bytes. The default kind
type parameter is 4. Unsigned integer literals are not supported. You must specify
the unsigned integer type only as part of a vector declaration.
46
XL Fortran: Language Reference

Chapter 4. Derived types
A derived type is a composite data type that can contain both intrinsic and derived
data types. You can define a derived type by using a type definition. This
definition specifies the name of the derived type and its type parameters,
components, and procedures. In Fortran 95, a type definition must have at least
one component and must not contain procedures. In Fortran 2003, a type definition
can have zero or more components, procedures and type parameters. Within a
derived type, the names of type parameters, components and procedures must be
unique, although the names can be the same as the names outside the scope of the
derived type definition.
In Fortran 2003, a derived type can be parameterized by type parameters. Each
type parameter is defined to be either a kind or a length type parameter, and can
have a default value. For details, see “Derived type parameters (Fortran 2003)” on
page 48.
The components of a derived type can be either of any intrinsic type or of a
previously defined type. These components can be both direct and ultimate.
Direct components are:
v
The components defined in that type
Ultimate components are components satisfying any one of the following three
conditions:
v
Components of intrinsic data type
v
Components with the
ALLOCATABLE
or POINTER attribute
v
The components of a derived type component without the
ALLOCATABLE
or POINTER attribute
Syntax of a derived type
DERIVED_TYPE_statement
type_param_def_block
PRIVATE
SEQUENCE
component_def_stmt_block
type_bound_procedure_block
END_TYPE_statement
DERIVED_TYPE_statement
See “Derived Type” on page 321 for syntax details.
type_param_def_block
Consists of the declarations for all the type_param_names that exist in
DERIVED_TYPE_statement. For details, see Derived type parameters.
© Copyright IBM Corp. 1996, 2012
47

PRIVATE
Specifies that default accessibility for the components of the derived type
are private. You can only specify one PRIVATE component statement for a
given derived type.
SEQUENCE
You can only specify one SEQUENCE statement. For details see
“SEQUENCE” on page 443.
component_def_stmt_block
For details, see “Derived type components” on page 49.
Fortran 2003
type_bound_procedure_block
Consists of a CONTAINS statement, followed optionally by a PRIVATE
statement, and one or more procedure binding statements. PRIVATE
specifies that the default accessibility for the derived type bindings are
private, and you can only specify one PRIVATE binding statement for a
given derived type. See “CONTAINS” on page 311 and “Type-bound
procedures (Fortran 2003)” on page 59 for detailed syntax and additional
information.
End of Fortran 2003
END_TYPE_statement
Optionally contains the same type_name as specified on the TYPE
statement. For more information see “END TYPE” on page 341.
Derived type parameters (Fortran 2003)
A derived type is parameterized if the DERIVED_TYPE_statement has any
type_param_names, or if it inherits any type parameter from its ancestor type. You
can define the type parameters for the derived type.
Syntax of a type parameter definition
INTEGER
,
KIND
::
type_param_decl_list
kind_selector
LEN
kind_selector
Specifies the kind type parameter for the integer type. See the kind_selector
section of INTEGER statement for syntax details.
type_param_decl
type_param_name
=
scalar_int_initialization_expr
48
XL Fortran: Language Reference

Each type_param_name in a type_param_decl must match one of the
type_param_name parameters listed in the DERIVED_TYPE_statement. Each
type_param_name in the DERIVED_TYPE_statement must be specified once in a
type_param_decl in the derived type definition.
A derived type parameter can be one of the following parameters.
v
It is a kind type parameter if it is declared with the KIND specifier.
v
It is a length type parameter if it is declared with the LEN specifier.
A derived type parameter can be used as a primary in a specification expression in
the derived type definition. A kind type parameter can also be used as a primary
in a constant expression in the derived type definition.
If a type_param_decl has a scalar_int_initialization_expr, the type parameter has a
default value specified by the expression.
Example
TYPE general_point (k, dim)
INTEGER, KIND :: k = selected_real_kind(6,70)
INTEGER, LEN :: dim
REAL(k) :: coordinates(dim)
END TYPE general_point
Type parameter order
Is the sequence of type parameters of a parameterized derived type. It is
used for derived type specifiers (see Type Declaration) that do not use type
parameter name keywords.
If a type is not an extended type, its type parameter order is the order of
the type parameter list in the DERIVED_TYPE_statement. The type
parameter order of an extended type consists of the type parameter order
of its parent type, followed by any additional type parameters in the order
of the type parameter list in its DERIVED_TYPE_statement.
Derived type components
The components of a derived type can be of any intrinsic type and can be of a
previously defined derived type. They can be either direct or ultimate. For more
information about direct components and ultimate components, see Chapter 4,
“Derived types,” on page 47.
A component definition statement consists of one or more type declaration
statements or procedure component declaration statements to define the
components of the derived type. For more information, see “Type Declaration” on
page 456 and “Procedure pointer components” on page 52. The type declaration
statements can specify only the DIMENSION, ALLOCATABLE, PRIVATE, PUBLIC,
and POINTER attributes. For details about declaring components of a specified
derived type, see “TYPE” on page 452 and “CLASS (Fortran 2003)” on page 300.
In addition, you can specify a default initialization for each nonallocatable
component in the definition of a derived type.
The type of a pointer component can be the same as the type containing the
component.
A component of type character or derived type can have deferred length if the
component also has the ALLOCATABLE or POINTER attribute.
Chapter 4. Derived types
49

Nonpointer, nonallocatable array components can be declared with either constant
dimension declarators or specification expressions that can involve type
parameters.
Note: You must declare pointer and allocatable array components with a
deferred_shape_spec_list array specification.
A component of a derived type must not appear as an input/output list item if
any ultimate component of the object cannot be accessed by the scoping unit of the
input/output statement,
unless a user-defined input/output procedure
processes the derived-type object.
A derived-type object must not appear
in a data transfer statement if the object has a component that is a pointer or
allocatable,
unless a user-defined input/output procedure processes the
object.
Allocatable components
Allocatable components are defined as ultimate components just as pointer
components are. This is because the value (if any) is stored separately from the rest
of the structure, and this storage does not exist (because the object is unallocated)
when the structure is created. As with ultimate pointer components, variables
containing ultimate allocatable components are forbidden from appearing directly
in input/output lists, unless the variable is processed by a user-defined derived
type input/output procedure.
As with allocatable arrays, allocatable components are forbidden from storage
association contexts. So, any variable containing an ultimate, allocatable component
cannot appear in COMMON or EQUIVALENCE. However, allocatable
components are permitted in SEQUENCE types, which allows the same type to be
defined separately in more than one scoping unit.
Deallocation of a variable containing an ultimate allocatable component
automatically deallocates all such components of the variable that are currently
allocated.
In a structure constructor for a derived type containing an allocatable component,
the expression corresponding to the allocatable component must be one of the
following:
v
A reference to the intrinsic function NULL with no argument. The allocatable
component receives the allocation status of not currently allocated.
v
A variable that is itself allocatable. The allocatable component receives the
allocation status of the variable and, if it is allocated, the value of the variable. If
the variable is an array that is allocated, the allocatable component also has the
bounds of the variable.
v
Any other expression. The allocatable component receives the allocation status of
currently allocated with the same value as the expression. If the expression is an
array, the allocatable component will have the same bounds.
For intrinsic assignment of those objects of a derived type containing an allocatable
component, the allocatable component of the variable on the left-hand-side receives
the allocation status and, if allocated, the bounds and value of the corresponding
component of the expression. This occurs as if the following sequence of steps is
carried out:
1. If the component of the variable is currently allocated, it is deallocated.
50
XL Fortran: Language Reference

2. If the corresponding component of the expression is currently allocated, the
component of the variable is allocated with the same bounds. The value of the
component of the expression is then assigned to the corresponding component
of the variable using defined assignment if the declared type of the component
has a defined assignment consistent with the component, and intrinsic
assignment for the dynamic type of that component otherwise.
An allocated ultimate allocatable component of an actual argument that is
associated with an INTENT(OUT) dummy argument is deallocated on procedure
entry so that the corresponding component of the dummy argument has an
allocation status of not currently allocated.
This ensures that any pointers that point to the previous contents of the allocatable
component of the variable become undefined.
Examples
MODULE REAL_POLYNOMIAL_MODULE
TYPE REAL_POLYNOMIAL
REAL, ALLOCATABLE :: COEFF(:)
END TYPE
INTERFACE OPERATOR(+)
MODULE PROCEDURE RP_ADD_RP, RP_ADD_R
END INTERFACE
CONTAINS
FUNCTION RP_ADD_R(P1,R)
TYPE(REAL_POLYNOMIAL) RP_ADD_R, P1
REAL R
INTENT(IN) P1,R
ALLOCATE(RP_ADD_R%COEFF(SIZE(P1%COEFF)))
RP_ADD_R%COEFF = P1%COEFF
RP_ADD_R%COEFF(1) = P1%COEFF(1) + R
END FUNCTION
FUNCTION RP_ADD_RP(P1,P2)
TYPE(REAL_POLYNOMIAL) RP_ADD_RP, P1, P2
INTENT(IN) P1, P2
INTEGER M
ALLOCATE(RP_ADD_RP%COEFF(MAX(SIZE(P1%COEFF), SIZE(P2%COEFF))))
M = MIN(SIZE(P1%COEFF), SIZE(P2%COEFF))
RP_ADD_RP%COEFF(:M) = P1%COEFF(:M) + P2%COEFF(:M)
IF (SIZE(P1%COEFF)>M) THEN
RP_ADD_RP%COEFF(M+1:) = P1%COEFF(M+1:)
ELSE IF (SIZE(P2%COEFF)>M) THEN
RP_ADD_RP%COEFF(M+1:) = P2%COEFF(M+1:)
END IF
END FUNCTION
END MODULE
PROGRAM EXAMPLE
USE REAL_POLYNOMIAL_MODULE
TYPE(REAL_POLYNOMIAL) P, Q, R
P = REAL_POLYNOMIAL((/4,2,1/)) ! Set P to (X**2+2X+4)
Q = REAL_POLYNOMIAL((/1,1/)) ! Set Q to (X+1)
R = P + Q ! Polynomial addition
PRINT *, ’Coefficients are: ’, R%COEFF
END
Pointer components
A component is a pointer if it has the POINTER attribute. A pointer component
can be a data pointer or a procedure pointer. For more information, see “Procedure
pointer components” on page 52.
Chapter 4. Derived types
51

Procedure pointer components
Syntax of a procedure pointer component
PROCEDURE
(
)
procedure_interface
::
,
procedure_component_attr_spec_list
::
procedure_entity_name
=>
null_init
procedure_interface
A declaration type specifier or the name of a procedure that has an explicit
interface.
If procedure_interface is a declaration type specifier and the type specified is
a parameterized derived type, all parameters used must be known at
compile time. Specifically, while kind type parameters and constants may
be used, length type parameters may not.
procedure_component_attr_spec_list
Attributes from the following list:
v
POINTER
v
PASS
v
NOPASS
v
access_spec
procedure_entity_name
is the name of the procedure pointer that is being declared.
null_init
is a reference to the NULL intrinsic function.
The PASS attribute defines the passed-object dummy argument of the type-bound
procedure or procedure pointer component. When NOPASS is specified the
procedure has no passed-object dummy argument.
PASS or NOPASS shall not both appear in the same
procedure_component_attr_spec_list.
If the procedure pointer component has an implicit interface or has no arguments,
NOPASS shall be specified.
If PASS(arg-name) appears, the interface shall have a dummy argument named
arg-name which is the passed-object dummy argument.
The passed-object dummy argument must not be a pointer, must not be allocatable,
and all its length type parameters must be assumed.
If neither PASS nor NOPASS is specified or PASS has no arg-name, the first
dummy argument is the passed-object dummy argument.
POINTER must be present in each procedure_component_attr_spec_list.
52
XL Fortran: Language Reference

Array components
A derived type component can have a subobject that is an array. For details, see
“Array sections” on page 85 and “Array sections and structure components” on
page 89.
Default initialization for components
You can specify default initialization for a nonpointer component using an equal
sign followed by a constant expression, or by enclosing an initial_value_list in
slashes. Enclosing an initial_value_list in slashes can apply to components in a
standard derived type declaration, or those within a record structure.
For pointer default initialization, use an arrow (=>) and then a reference to the
NULL intrinsic with no arguments.
A data object specified with default initialization in the type definition is a named
data object with these characteristics:
v
The object is of a derived type specifying default initialization for any of its
direct components.
v
The object does not have the
ALLOCATABLE
attribute.
v
The object is not a pointee.
A default initialization for a nonpointer, nonallocatable component takes
precedence over any default initialization appearing for any direct component of
the same type.
If a dummy argument with INTENT(OUT) is a derived type with default
initialization, the dummy argument must not be an assumed-size array. If you
specify that a nonpointer object has default initialization in a type definition, you
must not initialize that object with a DATA statement.
You can use a derived type data object with default initialization in a
common block as an IBM extension. The -qsave=defaultinit option causes default
initialization to imply the SAVE attribute.
Unlike explicit initialization, it is not necessary for a data object to have the SAVE
attribute for component default initialization to have an effect. You can specify
default initialization for some components of a derived type, but it is not necessary
for every component.
You can specify default initialization for a storage unit that is storage associated.
However, the objects or subobjects supplying the default initialization must be of
the same type and type parameters, and supply the same value for that storage
unit.
A direct component receives an initial value if you specify default initialization on
the corresponding component definition in the type definition, regardless of the
accessibility of that component.
For data objects that can undergo default initialization, their nonpointer
components are either initially undefined, or their corresponding default
initialization expressions define them. Their pointer components with default
initialization are initially disassociated, and all other pointer components are
initially undefined.
Chapter 4. Derived types
53

If you specify default initialization for a variable, and that variable has static
storage class, then default initialization occurs for that variable when your
application executes.
If you specify default initialization for a variable, and it is a function result, an
INTENT(OUT) dummy argument, or a local variable without the SAVE attribute,
then default initialization occurs when the procedure containing the variable's
declaration executes.
Allocation of an object of a derived type in which you specify default initialization
for a component causes the component to:
v
Become defined, if the component is a nonpointer
v
Become disassociated, if the component is a pointer.
In a subprogram with an ENTRY statement, default initialization occurs only for
the dummy arguments that appear in the argument list of the procedure name the
ENTRY statement references. If a dummy argument has the OPTIONAL attribute,
default initialization occurs only if that dummy argument is actually present.
Module data objects of derived type with default initialization must have the
SAVE attribute to be a candidate for default initialization.
Component order
Component order is the sequence of non-parent components of a derived type as
the sequence pertains to list-directed and namelist formatted input/output, and
structure constructors that do not use component keywords.
If a type is not an extended type, its component order is the order of the
declarations of the components in the derived type definition. The component
order of an
extended type
consists of the component order of its
parent type, followed by any additional components in the order of their
declarations in the extended derived type definition.
Referencing components
You can refer to a specific structure component using a component designator. A
scalar component designator has the following syntax:
scalar_struct_comp:
name
(
int_expr_list
)
separator
comp_name
(
int_expr_list
)
name
is the name of an object of derived type
comp_name
is the name of a derived type component
54
XL Fortran: Language Reference

int_expr
is a scalar integer or real expression called a subscript expression
separator
is % or
.
The structure component has the same type, type parameters, and POINTER
attribute (if any) as the right-most comp_name. It inherits any INTENT, TARGET,
and PARAMETER attributes from the parent object.
Note:
v
Each comp_name must be a component of the immediately preceding name or
comp_name.
v
The name and each comp_name, except the right-most, must be of derived type.
v
The number of subscript expressions in any int_expr_list must equal the rank of
the preceding name or comp_name.
v
If name or any comp_name is the name of an array, it must have an int_expr_list.
v
If the declared type of the rightmost comp_name is of abstract type, the
structure component must be polymorphic.
v
The rightmost comp_name must be scalar.
In namelist formatting, a separator must be a percentage sign.
If an expression has a form that could be interpreted either as a structure
component using periods as separators or as a binary operation, and an operator
with that name is accessible in the scoping unit, XL Fortran will treat the
expression as a binary operation. If that is not the interpretation you intended, you
should use the percent sign to dereference the parts, or, in free source form, insert
white space between the periods and the comp_name.
Examples
Example 1: Ambiguous use of a period as separator
MODULE MOD
STRUCTURE /S1/
STRUCTURE /S2/ BLUE
INTEGER I
END STRUCTURE
END STRUCTURE
INTERFACE OPERATOR(.BLUE.)
MODULE PROCEDURE BLUE
END INTERFACE
CONTAINS
INTEGER FUNCTION BLUE(R1, I)
RECORD /S1/ R1
INTENT(IN) :: R1
INTEGER, INTENT(IN) :: I
BLUE = R1%BLUE%I + I
END FUNCTION BLUE
END MODULE MOD
PROGRAM P
USE MOD
RECORD /S1/ R1
R1%BLUE%I = 17
I = 13
PRINT *, R1.BLUE.I ! Calls BLUE(R1,I) - prints 30
PRINT *, R1%BLUE%I ! Prints 17
END PROGRAM P
Chapter 4. Derived types
55

Example 2: Mix of separators
STRUCTURE /S1/
INTEGER I
END STRUCTURE
STRUCTURE /S2/
RECORD /S1/ C
END STRUCTURE
RECORD /S2/ R
R.C%I = 17 ! OK
R%C.I = 3 ! OK
R.C.I = 19 ! OK
END
Example 3: Percent and period work for any derived types
STRUCTURE /S/
INTEGER I, J
END STRUCTURE
TYPE DT
INTEGER I, J
END TYPE DT
RECORD /S/ R1
TYPE(DT) :: R2
R1.I = 17; R1%J = 13
R2.I = 19; R2%J = 11
END
Component and procedure accessibility
The default accessibility of a component of a derived type is PUBLIC. The
PRIVATE statement changes that default accessibility to private. You can only
specify a PRIVATE statement on a derived type definition if that definition is
within the specification part of a module.
If you define a type as PRIVATE, the following are accessible only within the
defining module:
v
The type name and any
type parameter names
for this
derived type.
v
Structure constructors for the type.
v
Any procedure that has a dummy argument or function result of the type.
You can use the PRIVATE or PUBLIC attribute on a component of the derived
type to override the default accessibility. You can only specify the PRIVATE or
PUBLIC attribute on a component if the type definition is within the specification
part of a module. If a component is private, the component name is accessible only
within the module containing the derived type definition, even if the derived type
itself is public.
Fortran 2003
The default accessibility of a procedure binding is PUBLIC. The PRIVATE
statement changes that default accessibility to private. You can use the PRIVATE or
PUBLIC attribute on a procedure binding to override the default accessibility. If
the procedure binding is private, it is accessible only within the defining module,
even if the derived type itself is public.
End of Fortran 2003
56
XL Fortran: Language Reference

Sequence derived types
By default, the order of derived type component definitions does not imply a
storage sequence. However, if you include a SEQUENCE statement, the derived
type becomes a sequence derived type. For a sequence derived type, the order of
the components specifies a storage sequence for objects of this derived type. If a
component of a sequence derived type is of a derived type, that derived type must
also be a sequence derived type.
Attention:
Using sequence derived types can lead to misaligned data, which can adversely
affect the performance of your application. Use with discretion.
Extensible derived types (Fortran 2003)
An extensible type is a nonsequence noninteroperable derived type from which
you can extend new types. You cannot use record structure syntax to define an
extensible type. You can further classify an extensible type to be one or more of the
following:
Base type
Extends only itself and no other types.
Extended type
Extends not only itself, but all types for which its parent type is an
extension.
Parent type
Provides components and procedure bindings to all types that extend from
that type. A parent type is the extensible type from which an extended
type is derived
You define an extended type with the EXTENDS attribute. The EXTENDS
attribute specification includes the name of the parent type. For more information
on specifying the EXTENDS attribute see “Derived Type” on page 321.
An extended type inherits all of the type parameters, components and
nonoverridden, nonfinal procedure bindings from its parent type.
The extended type also inherits inaccessible components and bindings from the
parent type. They remain inaccessible in the extended type. A private entity is
inaccessible if the type that you extend is accessed through use association.
A base type is not required to have any type parameters, components or bindings.
An extended type is not required to have more type parameters, components or
bindings than its parent type.
A type is not required to use any type parameters it or any parent may have
defined.
An extended type has a scalar, nonpointer, nonallocatable, parent component with
the same type and type parameters as its parent type. The name of this component
is identical to the name of the parent type, and has the same accessibility.
A type parameter or component declared in an extended type must not have the
same name as any type parameter or component of its parent type.
Chapter 4. Derived types
57

Example of an extended type
TYPE :: POINT ! A base type
REAL :: X, Y
END TYPE POINT
TYPE, EXTENDS(POINT) :: COLOR_POINT ! An extension of TYPE(POINT)
INTEGER :: COLOR
! Components X and Y, and component name
END TYPE COLOR_POINT
! POINT, inherited from parent
In the example, the type COLOR_POINT inherits the components X and Y from parent
type POINT. The components retain all of the attributes they have in the parent
type. You can declare additional components and procedure bindings in the
derived type definition of the extended type. In the example of an extensible type,
the type COLOR_POINT has one additional component, COLOR. The type POINT is a
nonsequence type that is not an extension of another type and therefore a base
type. The type COLOR_POINT is an extended type, whose parent type is POINT.
COLOR_POINT has a parent component POINT. The parent component, POINT, is a
structure with the components X and Y. Components of the parent are inheritance
associated 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 ancestor component of COLOR_POINT is
the parent component POINT.
For code example of type parameters, see the “Type Declaration” on page 456
section.
Abstract types and deferred bindings (Fortran 2003)
An abstract type is a type with the ABSTRACT attribute. A nonpolymorphic object
must not be declared with an abstract type. A polymorphic object cannot be
allocated with a dynamic abstract type.
A binding with the DEFERRED attribute is a deferred binding. A deferred binding
defers the implementation of a procedure to extensions of the type. You can specify
a deferred binding only in an abstract type definition. The dynamic type of an
object cannot be abstract. Therefore, a deferred binding cannot be invoked. An
extension of an abstract type does not have to be abstract if that extension has no
deferred bindings.
If a type definition contains or inherits a deferred binding, the ABSTRACT
attribute must appear. If ABSTRACT appears, the type must be extensible.
Example of an abstract type
TYPE, ABSTRACT :: FILE_HANDLE
CONTAINS
PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN
...
END TYPE
INTERFACE
SUBROUTINE OPEN_FILE(HANDLE)
IMPORT FILE_HANDLE
CLASS(FILE_HANDLE), INTENT(IN):: HANDLE
END SUBROUTINE OPEN_FILE
END INTERFACE
58
XL Fortran: Language Reference

Derived type Values
The set of values of a particular derived type consists of all possible sequences of
the component values of its components. The following table lists component
values of different types of components.
Table 13. Component values
Component
Component value
Pointer
Pointer association
Unallocated allocatable
Allocation status
Allocated allocatable
Allocation status, dynamic type and type
parameters, bounds and value
Nonpointer nonallocatable
Value
Type-bound procedures (Fortran 2003)
The procedure portion of a derived type definition allows you to bind specific
procedures, generic interfaces, and final subroutines to a type.
Syntax of a type-bound procedure
The syntax of the type-bound procedure portion of a derived type definition is as
follows:
CONTAINS
specific_binding
PRIVATE
generic_binding
final_binding
CONTAINS
For more information see “CONTAINS” on page 311
PRIVATE
You can only specify a PRIVATE statement if the type definition is within
the specification part of a module.
specific_binding
Binds a procedure to the type, or specifies a deferred binding in an abstract
type. See “Specific binding” on page 60
generic_binding
Defines a generic interface. See “Generic binding” on page 61
final_binding
Defines a list of final subroutines. See “Final binding” on page 63
You can identify a procedure using a binding name in the scope of the type
definition, or an operator for a generic binding. The binding name is the name of a
procedure of the type name and is referred to in the same way as a component of
a type. For a specific binding, this name is the binding_name. For a generic binding
whose generic specification is generic_name, this name is the generic_name. A final
binding, or a generic binding whose generic specification is not generic_name, has
no binding name.
Chapter 4. Derived types
59

Specific binding
Syntax of a specific_binding
The form of specific binding is:
PROCEDURE
(
interface_name
)
,
attribute_list
::
::
,
(1)
binding_name
=>
procedure_name
Notes:
1
Fortran 2008
interface_name
defines the interface for the procedure. The interface_name must be the
name of an abstract interface or of a procedure that has an explicit
interface. If you specify an interface_name, you must not specify a
procedure_name. An interface-name can appear if and only if the binding
has the DEFERRED attribute.
attribute
A binding can have one or more attributes, called binding attributes. The
same binding attribute cannot appear more than once for the same
binding. The list of binding attributes that you specify in an attribute_list
includes:
PASS
Defines the passed-object dummy argument of the procedure.
NOPASS
Indicates that the procedure has no passed-object dummy
argument. If the interface of the binding has no dummy argument
of the type being defined, use NOPASS. PASS and NOPASS can
not both be specified for the same binding.
access_spec
Is PUBLIC or PRIVATE.
NON_OVERRIDABLE
Prevents a binding from being overridden in an extended type.
You must not specify NON_OVERRIDABLE for a binding with
the DEFERRED attribute.
DEFERRED
Marks the procedure as deferred. Deferred bindings must only be
specified for derived type definitions with the ABSTRACT
attribute. A procedure with the DEFERRED binding attribute must
specify an interface_name. An overriding binding can have the
DEFERRED attribute only if the binding it overrides is deferred.
The NON_OVERRIDABLE and DEFERRED binding attributes
must not both be specified for the same procedure. See “Abstract
60
XL Fortran: Language Reference

types and deferred bindings (Fortran 2003)” on page 58 and
“Procedure overriding” on page 65 for more information.
binding_name
is the name of a binding of a type.
procedure_name
defines the interface for the procedure as well as the procedure to be
executed when the procedure is referenced. The procedure_name must be the
name of an accessible module procedure or an external procedure that has
an explicit interface. If neither =>procedure_name nor interface_name appears,
the procedure_name is the same as the binding_name. If =>procedure_name
appears, you must specify the double-colon separator and an interface_name
must not be specified.
Passed-object dummy arguments
A passed-object dummy argument applies to a type-bound procedure, or a
procedure pointer component.
v
If you specify PASS (arg-name) the interface of the procedure pointer component
or named type-bound procedure has a dummy argument with the same name as
arg-name. In this case, the passed-object dummy argument is the argument with
the given name.
v
If you do not specify PASS or NOPASS, or specify PASS without arg-name, the
first dummy argument of a procedure pointer component or type-bound
procedure is the passed-object dummy argument.
The passed-object dummy argument must be a scalar, nonpointer, nonallocatable
dummy data object with the same declared type as the type being defined. All of
its length type parameters must be assumed. The dummy argument must be
polymorphic if and only if the type being defined is extensible.
In the example of a type-bound procedure with a specific binding, the type POINT
contains a type-bound procedure with a specific binding. LENGTH is the type-bound
procedure and POINT_LENGTH is the name of a module procedure.
Example of a type-bound procedure with a specific binding
Example of a type-bound procedure with a specific binding
TYPE :: POINT
REAL :: X, Y
CONTAINS
PROCEDURE, PASS :: LENGTH => POINT_LENGTH
END TYPE POINT
...
The module-subprogram-part of the same module:
REAL FUNCTION POINT_LENGTH (A, B)
CLASS (POINT), INTENT (IN) :: A, B
POINT_LENGTH = SQRT ( (A%X - B%X)**2 + (A%Y - B%Y)**2 )
END FUNCTION POINT_LENGTH
Generic binding
Syntax of a generic_binding
The form of generic_binding is:
Chapter 4. Derived types
61

GENERIC
::
generic_spec
=>
binding_name_list
,
PRIVATE
,
PUBLIC
The generic_spec can be any of the following:
generic_name
OPERATOR(defined-operator)
The interface of each binding must be as specified in “Defined operators”
on page 165.
ASSIGNMENT(=)
The interface of each binding must be as specified in “Defined assignment”
on page 167.
dtio_generic_spec
The interface of each binding must be as specified in “User-defined
derived-type Input/Output procedure interfaces (Fortran 2003)” on page
211.
If the generic_spec is a generic_name, the generic_name cannot be the name of a
nongeneric binding of the type. The same generic_spec may be used in several
generic bindings within a single derived-type definition. In this case, every
occurrence of the same generic_spec must have the same accessibility. Each binding
name in the binding_name_list must be the name of a specific binding of the type.
When generic_spec is not a generic_name, each specific binding name in the
binding_name_list must have the passed-object dummy argument. You can only
specify one binding attribute, PRIVATE or PUBLIC. The following is an example
of a generic binding where generic_spec is ASSIGNMENT(=).
! See example of a
procedure with a specific binding for definition of COLOR_POINT
TYPE, EXTENDS(color_point) :: point_info ! An extension of TYPE(COLOR_POINT)
REAL :: color_code
CONTAINS
PROCEDURE, NOPASS:: get_color_code
PROCEDURE :: info1 => color_to_info
PROCEDURE :: point1 => point_to_info
GENERIC :: ASSIGNMENT(=) => info1, point1
END TYPE point_info
CONTAINS
ELEMENTAL SUBROUTINE color_to_info(a, b)
CLASS(point_info), INTENT(OUT) :: a
TYPE(color_point), INTENT(IN):: b
a%color_point = b
a%color_code = get_color_code(b%color)
END SUBROUTINE
ELEMENTAL SUBROUTINE point_to_info(a, b)
CLASS(point_info), INTENT(OUT) :: a
TYPE(point), INTENT(IN):: b
a%color_point = color_point(point=b, color=1)
a%color_code = get_color_code(1)
END SUBROUTINE
The following is an example of type parameters that illustrates how length
parameters should be used. As illustrated in the example, multiple procedures
must be defined for multiple kind parameter values:
62
XL Fortran: Language Reference

! Separate specific bindings may be needed for multiple possible kind parameters:
TYPE :: GRAPH (PREC,NNODES)
INTEGER, KIND :: PREC
INTEGER, LEN
:: NNODES
REAL(PREC) :: XVAL(NNODES), YVAL(NNODES)
CONTAINS
PROCEDURE, PASS :: FINDMAX_Y_4
PROCEDURE, PASS :: FINDMAX_Y_8
GENERIC :: FINDMAX_Y => FINDMAX_Y_4, FINDMAX_Y_8
END TYPE GRAPH
CONTAINS
INTEGER FUNCTION FINDMAX_Y_4(G)
CLASS(GRAPH(4,*)) :: G
FINDMAX_Y_4 = MAXLOC(G%XVAL,1)
END FUNCTION FINDMAX_Y_4
INTEGER FUNCTION FINDMAX_Y_8(G)
CLASS(GRAPH(8,*)) :: G
FINDMAX_Y_8 = MAXLOC(G%XVAL,1)
END FUNCTION FINDMAX_Y_8
Final binding
Syntax of a final_binding
A derived type is finalizable if the derived type has any final subroutines or any
nonpointer, nonallocatable component with a type that is finalizable. A nonpointer
data entity is finalizable if the type of the entity is finalizable. The form of
final_binding is:
FINAL
final_subroutine_name_list
::
FINAL
Specifies a list of final subroutines. A final subroutine can be executed
when a data entity of that type is finalized.
final_subroutine_name_list
A final_subroutine_name must be a module procedure with exactly one
dummy argument. That argument must be nonoptional and must be a
nonpointer, nonallocatable, nonpolymorphic variable of the derived type
being defined. All length type parameters are assumed; separate final
subroutines must be defined for different kind parameters. The dummy
argument cannot be INTENT(OUT). A final_subroutine_name must not be
one previously specified as a final subroutine for that type. A final
subroutine must not have a dummy argument with the same kind type
parameters and rank as the dummy argument of another final subroutine
of that type.
The following is an example of extended types with final subroutines:
Example of extended types with final subroutines
MODULE m
TYPE :: t1
REAL a,b
END TYPE
TYPE, EXTENDS(t1) :: t2
REAL, POINTER :: c(:), d(:)
Chapter 4. Derived types
63

CONTAINS
FINAL :: t2f
END TYPE
TYPE, EXTENDS(t2) :: t3 (k)
INTEGER, KIND :: k
REAL(k), POINTER :: e
CONTAINS
FINAL :: t3f4, t3f8
END TYPE
CONTAINS
SUBROUTINE t2f(x) ! Finalizer for TYPE(t2)’s extra components
TYPE(t2) :: x
print *, ’entering t2f’
IF (ASSOCIATED(x%c)) THEN
print *, ’ c allocated, cleaning up’
DEALLOCATE(x%c)
END IF
IF (ASSOCIATED(x%d)) THEN
print *, ’ d allocated, cleaning up’
DEALLOCATE(x%d)
END IF
END SUBROUTINE
SUBROUTINE t3f4(y) ! Finalizer for TYPE(t3)’s extra components, where kind is 4
TYPE(t3(4)) :: y
print *, ’entering t3f4’
IF (ASSOCIATED(y%e)) THEN
print *, ’ e (k=4) allocated, cleanup up’
DEALLOCATE(y%e)
END IF
END SUBROUTINE
SUBROUTINE t3f8(y) ! Second finalizer for TYPE(t3), with kind = 8
TYPE(t3(8)) :: y
print *, ’entering t3f8’
IF (ASSOCIATED(y%e)) THEN
print *, ’ e (k=8) allocated, cleanup up’
DEALLOCATE(y%e)
END IF
END SUBROUTINE
! If we had a type t3 with kind parameter k=16, we would probably
! want yet another finalizer with an argument of the appropriate
! type and parameters, but it does not have to be defined.
END MODULE
PROGRAM my_main
CALL calc_span
END PROGRAM
SUBROUTINE calc_span
USE m
TYPE(t1) x1
TYPE(t2) x2
TYPE(t3(4)) x3
TYPE(t3(8)) x3a
ALLOCATE(x2%c(1:5), SOURCE=[1.0, 5.0, 10.0, 15.0, 20.0])
ALLOCATE(x3%e, SOURCE=2.0)
ALLOCATE(x3a%e, SOURCE=3.0_8)
x2%c = x2%c + x3%e + x3a%e
print *, ’calcs are=’, x2%c
! Returning from this subroutine does
! nothing to x1. It is not finalizable.
! The Fortran compiler places calls to the finalizers at the
! end of a subroutine for the local variables of calc_span,
64
XL Fortran: Language Reference

! as if the following calls were being made:
! CALL t2f(x2)
! CALL t3f4(x3)
! CALL t2f(x3%t2)
! CALL t3f8(x3a)
! CALL t2f(x3a%t2)
! Note that the specific order of invocation (x2 before x3 before x3a) may vary.
END SUBROUTINE
The output of the above program is:
calcs are= 6.000000000 10.00000000 15.00000000 20.00000000 25.00000000
entering t2f
c allocated, cleaning up
entering t3f8
e (k=8) allocated, cleanup up
entering t2f
entering t3f4
e (k=4) allocated, cleanup up
entering t2f
Procedure overriding
If a nongeneric binding you specify in a type definition has the same binding
name as a binding inherited from the parent type, then the binding you specify in
the type definition overrides the binding inherited from the parent type.
The overriding binding and the overriden binding must satisfy the following
conditions:
v
Both bindings have a passed-object dummy argument or neither does.
v
If the overridden binding is pure, the overriding binding must also be pure.
v
Both bindings are elemental or neither is.
v
Both bindings must have the same number of dummy arguments.
v
Passed-object dummy arguments, if any, must correspond by name and position.
v
Dummy arguments that correspond by position must have the same names and
characteristics, except for the type of the passed-object dummy arguments.
v
Both bindings must be subroutines or functions having the same result
characteristics.
v
If the overridden binding is PUBLIC then the overriding binding cannot be
PRIVATE.
Example of procedure overriding
TYPE :: POINT
REAL :: X, Y
CONTAINS
PROCEDURE, PASS :: LENGTH => POINT_LENGTH
END TYPE POINT
TYPE, EXTENDS (POINT) :: POINT_3D
REAL :: Z
CONTAINS
PROCEDURE, PASS :: LENGTH => POINT_3D_LENGTH
END TYPE POINT_3D
...
The module-subprogram-part of the same module:
Chapter 4. Derived types
65

REAL FUNCTION POINT_LENGTH (A, B)
CLASS (POINT), INTENT (IN) :: A, B
POINT_LENGTH = SQRT ( (A%X - B%X)**2 + (A%Y - B%Y)**2 )
END FUNCTION POINT_LENGTH
REAL FUNCTION POINT_3D_LENGTH ( A, B )
CLASS (POINT_3D), INTENT (IN) :: A
CLASS (POINT), INTENT (IN) :: B
SELECT TYPE(B)
CLASS IS (POINT_3D)
POINT_3D_LENGTH = SQRT( (A%X-B%X)**2 + (A%Y-B%Y)**2 + (A%Z-B%Z)**2 )
RETURN
END SELECT
PRINT *, ’In POINT_3D_LENGTH, dynamic type of argument is incorrect.’
STOP
END FUNCTION POINT_3D
If a generic binding specified in a type definition has the same generic_spec that
does not satisfy the conditions as an inherited binding, it extends the generic
interface and must satisfy the requirements specified in “Unambiguous generic
procedure references” on page 163.
If a generic binding in a type definition has the same dtio_generic_spec as one
inherited from the parent, it extends the generic interface for the dtio_generic_spec
and must satisfy the requirements specified in “Unambiguous generic procedure
references” on page 163.
A binding of a type and a binding of an extension of that type correspond if:
v
The extension binding is the same as the type binding.
v
The extension binding overrides a corresponding binding.
v
The extension binding is an inherited corresponding binding.
Finalization (Fortran 2003)
The finalization process
Only finalizable entities are finalized. When an entity is finalized, the following
steps are carried out in sequence:
1. If the dynamic type of the entity has a final subroutine whose dummy
argument has the same kind type parameters and rank as the entity being
finalized, it is called with the entity as an actual argument. Otherwise, if there
is an elemental final subroutine whose dummy argument has the same kind
type parameters as the entity being finalized, it is called with the entity as an
actual argument. Otherwise, no subroutine is called at this point.
2. Each finalizable component that appears in the type definition is finalized. If
the entity being finalized is an array, each finalizable component of each
element of that entity is finalized separately.
3. If the entity is of extended type and the parent type is finalizable, the parent
component is finalized.
If several entities are to be finalized as a result of one of the events that triggers
finalization, these entities can be finalized in any order.
A final subroutine must not reference or define an object that has already been
finalized. If the object is not finalized, it retains its definition status and is not
undefined.
66
XL Fortran: Language Reference

When finalization occurs
Finalization occurs for the target of a pointer when the pointer is deallocated. If an
object is allocated through pointer allocation and later becomes unreachable
because all pointers to that object have had their pointer association status
changed, finalization on the object does not occur.
Finalization of an allocatable entity occurs when the entity is deallocated.
Finalization for a nonpointer, nonallocatable object that is not a dummy argument
or function result occurs immediately before the object is undefined by the
execution of a RETURN or END statement. If the object is defined in a module
and no active procedures are still referencing the module, finalization does not take
place.
Finalization of a structure constructor referenced by an executable construct occurs
after execution of the innermost executable construct containing the reference.
Finalization for a function referenced by an executable construct takes place after
execution of the innermost executable construct containing the reference.
Finalization for the result of a function referenced by a specification expression in a
scoping unit takes place before the first statement in the scoping unit executes.
Finalization of a nonpointer, nonallocatable object that is an actual argument
associated with an INTENT(OUT) dummy argument occurs when a procedure
using the argument is invoked.
Finalization of a variable in an intrinsic assignment statement takes place after
evaluation of the expression and before the definition of the variable.
F2008
Finalization for an unsaved, nonpointer, nonallocatable, local variable of a
BLOCK construct occurs immediately before execution exits the BLOCK construct.
F2008
Non-finalized entities
If program execution is terminated, either by an error, such as an allocation failure,
or by the execution of a STOP,
F2008
ERROR STOP F2008
, or END
PROGRAM statement, entities existing immediately before termination are not
finalized.
A nonpointer, nonallocatable object that has the SAVE attribute or that you specify
in the main program is never finalized as a direct consequence of the execution of
a RETURN or END statement.
Determining declared type for derived types
Two data objects have the same derived type if they are declared with reference to
the same derived-type definition.
If the data objects are in different scoping units, they can still have the same
derived type. Either the derived-type definition is accessible via host or use
association, or the data objects reference their own derived-type definitions with
the following conditions:
v
They were both declared using standard derived type declarations, both have
the same name, either both have the SEQUENCE property, or both have the
Chapter 4. Derived types
67

BIND attribute, and both have components that do not have PRIVATE
accessibility and agree in order, name and attributes; or
v
They were declared using record structure declarations that were not unnamed,
the types have the same name, have no %FILL components and have
components that agree in order and attributes, and any %FILL components
appear in the same positions in both.
A derived-type definition that has the BIND attribute or the SEQUENCE property
is not the same as a definition declared to be private or that has components that
are private.
Examples
Example 1:
PROGRAM MYPROG
TYPE NAME
! Sequence derived type
SEQUENCE
CHARACTER(20) LASTNAME
CHARACTER(10) FIRSTNAME
CHARACTER(1)
INITIAL
END TYPE NAME
TYPE (NAME) PER1
CALL MYSUB(PER1)
PER1 = NAME(’Smith’,’John’,’K’)
! Structure constructor
CALL MYPRINT(PER1)
CONTAINS
SUBROUTINE MYSUB(STUDENT)
! Internal subroutine MYSUB
TYPE (NAME) STUDENT
! NAME is accessible via host association
...
END SUBROUTINE MYSUB
END
SUBROUTINE MYPRINT(NAMES)
! External subroutine MYPRINT
TYPE NAME
! Same type as data type in MYPROG
SEQUENCE
CHARACTER(20) LASTNAME
CHARACTER(10) FIRSTNAME
CHARACTER(1)
INITIAL
END TYPE NAME
TYPE (NAME) NAMES
! NAMES and PER1 from MYPROG
PRINT *, NAMES
! have the same data type
END SUBROUTINE
Example 2:
MODULE MOD
STRUCTURE /S/
INTEGER I
INTEGER, POINTER :: P
END STRUCTURE
RECORD /S/ R
END MODULE
PROGRAM P
USE MOD, ONLY: R
STRUCTURE /S/
INTEGER J
INTEGER, POINTER :: Q
END STRUCTURE
68
XL Fortran: Language Reference

RECORD /S/ R2
R = R2 ! OK - same type name, components have same attributes and
! type (but different names)
END PROGRAM P
Structure constructor
A structure constructor allows a scalar value of derived type to be constructed
from a list of values. A structure constructor must not appear before the definition
of the referenced derived type.
derived_type_spec
(
)
component_spec_list
derived_type_spec
is used to specify a particular derived type and type parameters.
type_name
(
)
type_param_spec_list
type_name
is the name of the derived type, which must not be abstract.
type_param_spec is:
type_param_value
type_param_keyword
=
Note: The value of a type parameter for which no type_param_value has been
specified is its default value. For details, see “Derived type parameters (Fortran
2003)” on page 48.
type_param_keyword
is the name of parameter of the type.
type_param_value
must be a scalar integer expression in a structure constructor.
Note: derived_type_spec is also used in declaring data entities, procedure
interfaces and so on. In these cases, a type_param_value that is a length parameter
can be either a * or : in addition to scalar integer expression.
component_spec is:
Chapter 4. Derived types
69

expr
component_keyword
=
component_keyword
is the name of a component of the type.
expr
is an expression. Expressions are defined under Chapter 6, “Expressions
and assignment,” on page 97.
The type_name and all components of the type for which an expr appears must be
accessible in the scoping unit containing the structure constructor.
In the absence of a component keyword, each expr is assigned to the corresponding
component in component order. 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 must conform in
the same way as for a variable and expression in intrinsic assignment. If necessary,
each value of intrinsic type is converted according to the rules of intrinsic
assignment to a value that agrees in type and type parameters with the
corresponding component of derived type. For a nonpointer nonallocatable
component, the shape of the expression must conform with the shape of the
component.
If a component_spec is provided for a component, no component_spec can be
provided for any component with which it is inheritance-associated. At most one
component_spec can be provided for a component.
If a component with default initialization has no corresponding expr, then the
default initialization is applied to that component.
The component_keyword = specifier may be omitted from a component_spec only if
the component_keyword = specifier has been omitted from each preceding
component_spec in the constructor.
The type_param_keyword = specifier may be omitted from a type_param_spec only if
the type_param_keyword = specifier has been omitted from each preceding
type_param_spec in the constructor.
A component that is a pointer can be declared with the same type that it is a
component of. If a structure constructor is created for a derived type containing a
pointer, the expression corresponding to the pointer component must evaluate to
an object that would be an allowable target for such a pointer in a pointer
assignment statement.
If a component of a derived type is allocatable, the corresponding constructor
expression will either be a reference to the intrinsic function NULL() with no
arguments, an allocatable entity, or will 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 not currently allocated. If the
expression is an allocatable entity, the corresponding component of the constructor
has the same allocation status as that of allocatable entity and, if it is allocated, it
has the same bounds (if any) and value. Otherwise, the corresponding component
of the constructor has an allocation status of currently allocated, and has the same
bounds (if any) and value as the expression.
70
XL Fortran: Language Reference

If a derived type is declared using the record structure declaration and
has any %FILL component, the structure constructor for that type cannot be used.
If a derived type is accessible in a scoping unit and there is a local entity of class 1
that is not a derived type with the same name accessible in the scoping unit, the
structure constructor for that type cannot be used in that scope.
If derived_type_spec is a type name that is the same as a generic name,
component_spec_list must not be a valid actual_arg_spec_list for a function reference
that is resolvable as a generic reference.
Examples
Example 1:
MODULE PEOPLE
TYPE NAME
SEQUENCE
! Sequence derived type
CHARACTER(20) LASTNAME
CHARACTER(10) FIRSTNAME
CHARACTER(1)
INITIAL
END TYPE NAME
TYPE PERSON
! Components accessible via use
! association
INTEGER AGE
INTEGER BIRTHDATE(3)
! Array component
TYPE (NAME) FULLNAME
! Component of derived type
END TYPE PERSON
END MODULE PEOPLE
PROGRAM TEST1
USE PEOPLE
TYPE (PERSON) SMITH, JONES
SMITH = PERSON(30, (/6,30,63/), NAME(’Smith’,’John’,’K’))
! Nested structure constructors
JONES%AGE = SMITH%AGE
! Component designator
CALL TEST2
CONTAINS
SUBROUTINE TEST2
TYPE T
INTEGER EMP_NO
CHARACTER, POINTER :: EMP_NAME(:)
! Pointer component
END TYPE T
TYPE (T) EMP_REC
CHARACTER, TARGET :: NAME(10)
EMP_REC = T(24744,NAME)
! Pointer assignment occurs
END SUBROUTINE
! for EMP_REC%EMP_NAME
END PROGRAM
Example 2:
PROGRAM LOCAL_VAR
TYPE DT
INTEGER A
INTEGER :: B = 80
END TYPE
TYPE(DT) DT_VAR
! DT_VAR%B IS INITIALIZED
END PROGRAM LOCAL_VAR
Example 3:
Chapter 4. Derived types
71

MODULE MYMOD
TYPE DT
INTEGER :: A = 40
INTEGER, POINTER :: B => NULL()
END TYPE
END MODULE
PROGRAM DT_INIT
USE MYMOD
TYPE(DT), SAVE :: SAVED(8)
! SAVED%A AND SAVED%B ARE INITIALIZED
TYPE(DT) LOCAL(5)
! LOCAL%A LOCAL%B ARE INITIALIZED
END PROGRAM
Example 4:
PROGRAM NEW_LOCAL
TYPE DT
INTEGER :: A = 20
INTEGER :: B = 80
END TYPE
TYPE(DT):: DT_VAR = DT()
TYPE(DT):: DT_VAR2 = DT(B=40)
TYPE(DT):: DT_VAR3 = DT(B=10, A=50)
PRINT *, ’DT_VAR =’, DT_VAR
PRINT *, ’DT_VAR2=’, DT_VAR2
PRINT *, ’DT_VAR3=’, DT_VAR3
END PROGRAM NEW_LOCAL
! The expeceted output is :
DT_VAR = 20 80
DT_VAR2= 20 40
DT_VAR3= 50 10
72
XL Fortran: Language Reference

Chapter 5. Array concepts
An array is an ordered sequence of scalar data. All the elements of an array have
the same type and type parameters.
XL Fortran provides a set of features, commonly referred to as array language, that
allow you to manipulate arrays. This section provides background information on
arrays and array language.
Many statements in Chapter 11, “Statements and attributes,” on page 271, have
special features and rules for arrays.
This section makes frequent use of the DIMENSION attribute. See “DIMENSION”
on page 323.
A number of intrinsic functions are especially for arrays. These functions are
mainly those classified as “Transformational intrinsic functions” on page 541.
Array basics
A whole array is denoted by the name of the array.
! In this declaration, the array is given a type and dimension
REAL, DIMENSION(3) :: A
! In these expressions, each element is evaluated in each expression
PRINT *, A, A+5, COS(A)
A whole array is either a named constant or a variable.
Dimension
In standard Fortran, an array can have up to seven dimensions. In Fortran 2008, an
array can have up to fifteen dimensions.
In XL Fortran, an array can have up to twenty dimensions.
Bounds of a dimension
Each dimension in an array has an upper and lower bound, which determine the
range of values that can be used as subscripts for that dimension. The bound of a
dimension can be positive, negative, or zero.
In XL Fortran, the bound of a dimension can be positive, negative or zero
within the range -(2**31) to 2**31-1 in 32–bit mode. The 64-bit mode range for
bounds is -(2**63) to 2**63-1.
If any lower bound is greater than the corresponding upper bound, the array is a
zero-sized array, which has no elements but still has the properties of an array. The
return values for the intrinsic inquiry functions LBOUND and UBOUND for such
a dimension are one and zero, respectively.
When the bounds are specified in array declarators:
v
The lower bound is a specification expression. If it is omitted, the default value
is 1.
© Copyright IBM Corp. 1996, 2012
73

v
The upper bound is a specification expression or asterisk (*), and has no default
value.
Related information
v
“Specification expressions” on page 99
Extent of a dimension
The extent of a dimension is the number of elements in that dimension, computed
as the value of the upper bound minus the value of the lower bound, plus one.
INTEGER, DIMENSION(5) :: X
! Extent = 5
REAL :: Y(2:4,3:6)
! Extent in 1st dimension = 3
! Extent in 2nd dimension = 4
The minimum extent is zero, in a dimension where the lower bound is greater than
the upper bound.
The theoretical maximum number of elments in an array is 2**31-1
elements in 32–bit mode, or 2**63-1 elements in XL Fortran 64-bit mode. Hardware
addressing considerations make it impractical to declare any combination of data
objects with a total size in bytes that exceeds this value.
Different array declarators associated by common, equivalence, or argument
association can have different ranks and extents.
Rank, shape, and size of an array
Rank
The rank of an array is the number of dimensions it has.
INTEGER, DIMENSION (10) :: A
! Rank = 1
REAL, DIMENSION (-5:5,100) :: B
! Rank = 2
A scalar is considered to have rank zero.
Shape
The shape of an array is derived from its rank and extents. It can be represented as
a rank-one array where each element is the extent of the corresponding dimension:
INTEGER, DIMENSION (10,10) :: A
! Shape = (/ 10, 10 /)
REAL, DIMENSION (-5:4,1:10,10:19) :: B
! Shape = (/ 10, 10, 10 /)
Size
The size of an array is the total number of elements in it. The size equals to the
product of the extents of all dimensions.
INTEGER A(5)
! Size = 5
REAL B(-1:0,1:3,4)
! Size = 2 * 3 * 4 = 24
Array declarators
An array declarator declares the shape of an array.
You must declare every named array, and no scoping unit can have more than one
array declarator for the same name. An array declarator can appear in any of the
Compatible Statements and Attributes for Array Declarators table.
74
XL Fortran: Language Reference

Table 14. Compatible statements and attributes for array declarators
ALLOCATABLE 1
AUTOMATIC 2
COMMON
DIMENSION
CONTIGUOUS 3
PARAMETER
POINTER (integer) 2
POINTER
PROTECTED 1
STATIC 2
TARGET
Type Declaration
VOLATILE
Notes:
1 Fortran 2003
2 IBM extension
3 Fortran 2008
For example:
DIMENSION :: A(1:5)
! Declarator is "(1:5)"
REAL, DIMENSION(1,1:5) :: B ! Declarator is "(1,1:5)"
INTEGER C(10)
! Declarator is "(10)"
The form of an array declarator is:
(
array_spec
)
array_spec
is an array specification. It is a list of dimension declarators, each of which
establishes the lower and upper bounds of an array, or specifies that one or
both will be set at run time. Each dimension requires one dimension
declarator.
An array_spec is one of:
explicit_shape_spec_list
assumed_shape_spec_list
deferred_shape_spec_list
implied_shape_spec_list
assumed_size_spec
Each array_spec declares a different kind of array, as explained in the
following sections.
Explicit-shape arrays
Explicit-shape arrays are arrays where the bounds are explicitly specified for each
dimension.
Chapter 5. Array concepts
75

Explicit_shape_spec_list
,
upper_bound
lower_bound
:
lower_bound, upper_bound
are specification expressions
Arrays with bounds that are nonconstant expressions must be declared inside
subprograms or
F2008
BLOCK constructs F2008
. The nonconstant bounds are
determined on entry to the subprogram or
F2008
BLOCK construct F2008
. If a
lower bound is omitted, its default value is one.
The rank is the number of specified upper bounds. The shape of an explicit-shape
dummy argument can differ from that of the corresponding actual argument.
The size is determined by the specified bounds.
The size of an explicit-shape dummy argument does not need to be the same as
the size of the actual argument, but the size of the dummy argument cannot be
larger than the size of the actual argument.
Examples
INTEGER A,B,C(1:10,-5:5)
! All bounds are constant
A=8; B=3
CALL SUB1(A,B,C)
END
SUBROUTINE SUB1(X,Y,Z)
INTEGER X,Y,Z(X,Y)
! Some bounds are not constant
END SUBROUTINE
Automatic arrays
An automatic array is an explicit-shape array that is declared in a subprogram
F2008
or a BLOCK construct F2008
. It is not a dummy argument or pointee
array, and has at least one bound that is a nonconstant specification expression.
Evaluation of the bounds occurs on entry into the subprogram
F2008
or BLOCK
construct F2008
. After the bounds are determined, they remain unchanged
during execution of the subprogram
F2008
or BLOCK construct F2008
.
Example of an automatic array
INTEGER X
COMMON X
X = 10
CALL SUB1(5)
END
SUBROUTINE SUB1(Y)
INTEGER X
COMMON X
INTEGER Y
76
XL Fortran: Language Reference

REAL Z (X:20, 1:Y)
! Automatic array.
Here the bounds are made
! available through dummy arguments and common
! blocks, although Z itself is not a dummy
END SUBROUTINE
! argument.
Related information
v
For general information about automatic data objects, see “Automatic objects”
on page 18 and “Storage classes for variables (IBM extension)” on page 26.
Adjustable arrays
An adjustable array is an explicit-shape array dummy argument that has at least
one non-constant bound.
Example of an adjustable array
SUBROUTINE SUB1(X, Y)
INTEGER X, Y(X*3)
! Adjustable array.
Here the bounds depend on a
! dummy argument, and the array name is also passed in.
END SUBROUTINE
Pointee arrays (IBM extension)
Pointee arrays are explicit-shape or assumed-size arrays that can only appear in
integer POINTER statements.
The declarator for a pointee array can only contain variables if you declare the
array inside a subprogram, and any such variables must be:
v
dummy arguments
v
members of a common block
v
use associated
v
host associated
Evaluation of the bounds occurs on entry into the subprogram, and remain
constant during execution of that subprogram.
Compiling with the -qddim option option relaxes the restrictions on which
variables can appear in an array declarator. Declarators in the main program can
contain variable names, and any specified nonconstant bounds are re-evaluated
each time you reference the array, so that you can change the properties of the
pointee array by changing the values of the variables used in the bounds
expressions.
Example using -qddim to relax array declarator restrictions
@PROCESS DDIM
INTEGER PTE, N, ARRAY(10)
POINTER (P, PTE(N))
N = 5
P = LOC(ARRAY(2))
!
PRINT *, PTE
! Print elements 2 through 6 of ARRAY
N = 7
! Increase the size
PRINT *, PTE
! Print elements 2 through 8 of ARRAY
END
Assumed-shape arrays
Assumed-shape arrays are dummy argument arrays where the extent of each
dimension is taken from the associated actual arguments.
Chapter 5. Array concepts
77

Assumed_shape_spec_list
,
:
lower_bound
lower_bound
is a specification expression
Each lower bound defaults to one, or may be explicitly specified. Each upper
bound is set on entry to the subprogram to the specified lower bound (not the
lower bound of the actual argument array) plus the extent of the dimension minus
one.
The extent of any dimension is the extent of the corresponding dimension of the
associated actual argument.
The rank is the number of colons in the assumed_shape_spec_list.
The shape is assumed from the associated actual argument array.
The size is determined on entry to the subprogram where it is declared, and equals
the size of the associated argument array.
Note: Subprograms that have assumed-shape arrays as dummy arguments must
have explicit interfaces.
Examples
INTERFACE
SUBROUTINE SUB1(B)
INTEGER B(1:,:,10:)
END SUBROUTINE
END INTERFACE
INTEGER A(10,11:20,30)
CALL SUB1 (A)
END
SUBROUTINE SUB1(B)
INTEGER B(1:,:,10:)
! Inside the subroutine, B is associated with A.
! It has the same extents as A but different bounds (1:10,1:10,10:39).
END SUBROUTINE
Implied-shape arrays (Fortran 2008)
An implied-shape array is a named constant that inherits its shape from the
constant expression in its declaration.
78
XL Fortran: Language Reference

Implied_shape_spec_list
,
*
lower_bound:
lower_bound
A specification expression
The declaration of an implied-shape array contains an implied-shape specification
and a constant expression. The constant expression must be an array.
The rank is the number of implied-shape specifications in implied_shape_spec_list.
The extent of any dimension is the same as the extent of the corresponding
dimension of the constant expression.
Each lower bound is the corresponding lower bound in implied_shape_spec_list. For
dimensions whose lower bounds are not specified, the lower bounds default to
one. Each upper bound is the sum of the lower bound and extent minus one.
Examples
! Array imp1 is a rank-one array. Its upper bound is 5.
INTEGER, PARAMETER :: imp1(4:*) = [1, 2]
! Array imp2 is a rank-one array. Its upper bound is 4.
INTEGER, PARAMETER :: onetofour(4) = [1, 2, 3, 4]
INTEGER, PARAMETER, DIMENSION(*) :: imp2 = onetofour
! Array imp3 is a rank-two array. Its shape is (/2, 2/) and the upper bounds for
the two dimensions are 2 and 11.
REAL, PARAMETER :: imp3(*, 10:*) = RESHAPE([1, 2, 3, 4], [2, 2])
Related information
v
Constant expressions in the XL Fortran Language Reference
Deferred-shape arrays
Deferred-shape arrays are allocatable arrays or array pointers, where the bounds
can be defined or redefined during execution of the program.
Deferred_shape_spec_list
,
:
The extent of each dimension (and the related properties of bounds, shape, and
size) is undefined until the array is allocated or the pointer is associated with an
Chapter 5. Array concepts
79

array that is defined. Before then, no part of the array may be defined, or
referenced except as an argument to an appropriate inquiry function. At that point,
an array pointer assumes the properties of the target array, and the properties of
an allocatable array are specified in an ALLOCATE statement.
The rank is the number of colons in the deferred_shape_spec_list.
Although a deferred_shape_spec_list can appear identical to an
assumed_shape_spec_list, deferred-shape arrays and assumed-shape arrays are not
the same. A deferred-shape array must have the ALLOCATABLE or POINTER
attribute, while an assumed-shape array must be a dummy argument that does not
have the ALLOCATABLE or POINTER attribute. The bounds of a deferred-shape
array, and the actual storage associated with it, can be changed at any time by
reallocating the array or by associating the pointer with a different array, while
these properties remain the same for an assumed-shape array during the execution
of the containing subprogram.
Related information:
v
“Allocation status” on page 25
v
“Data pointer assignment” on page 124
v
“Pointer association” on page 154
v
“ALLOCATABLE (Fortran 2003)” on page 275
v
“ALLOCATED(X)” on page 552
v
“ASSOCIATED(POINTER, TARGET)” on page 557
Allocatable arrays
A deferred-shape array that has the ALLOCATABLE attribute is referred to as an
allocatable array. The bounds and shape of the array are determined when you
allocate storage using an ALLOCATE statement.
Example
The following example declares an allocatable array and determines its bounds.
INTEGER, ALLOCATABLE, DIMENSION(:, :, :) :: arr
ALLOCATE(arr(10, -4:5, 20))
! Bounds of arr are now defined (1:10, -4:5, 1:20)
DEALLOCATE(a)
ALLOCATE(arr(5, 5, 5))
! Change the bounds of arr
If you compile your program with -qinitalloc, all elements of the allocatable array
arr are initialized to zero.
80
XL Fortran: Language Reference

Migration Tip:
If you do not know the size of an array at compile time, you can avoid unnecessary
memory usage by making the array allocatable instead of declaring it with a maximum
size.
FORTRAN 77 source
INTEGER A(1000),B(1000),C(1000)
C 1000 is the maximum size
WRITE (6,*) "Enter the size of the arrays:"
READ (5,*) N
.
.
.
DO I=1,N
A(I)=B(I)+C(I)
END DO
END
Source for Fortran 90 or above:
INTEGER, ALLOCATABLE, DIMENSION(:) :: A,B,C
WRITE (6,*) "Enter the size of the arrays:"
READ (5,*) N
ALLOCATE (A(N),B(N),C(N))
.
.
.
A=B+C
END
Related information
v
“ALLOCATABLE (Fortran 2003)” on page 275
v
“ALLOCATE” on page 277
v
“DEALLOCATE” on page 319
v
The -qinitalloc option
Array pointers
An array with the POINTER attribute is referred to as an array pointer. Its bounds
and shape are determined when it is associated with a target through pointer
assignment or execution of an ALLOCATE statement.
Example
The following example declares an array pointer and determines its bounds and
storage association.
REAL, POINTER, DIMENSION(:, :) :: b
REAL, TARGET, DIMENSION(5, 10) :: c, d(10, 10)
b => c
! Bounds of b are now defined (1:5, 1:10)
b => d
! b now has different bounds and is associated with different storage
If you use the following ALLOCATE statement and compile your program with
the -qinitalloc option, all elements of the array pointer b are initialized to zero.
ALLOCATE(b(5, 5)) ! Change bounds and storage association again
Related information
v
“Pointer association” on page 154
v
“ALLOCATE” on page 277
Chapter 5. Array concepts
81

v
The -qinitalloc option
Assumed-size arrays
Assumed-size arrays are dummy argument arrays where the size is inherited from
the associated actual array, but the rank and extents may differ.
Assumed_size_spec
*
,
lower_bound
:
upper_bound
,
lower_bound
:
lower_bound, upper_bound
are specification expressions
If any bound is not constant, the array must be declared inside a subprogram and
the nonconstant bounds are determined on entry to the subprogram. If a lower
bound is omitted, its default value is 1.
The last dimension has no upper bound and is designated instead by an asterisk.
You must ensure that references to elements do not go past the end of the actual
array.
The rank equals one plus the number of upper_bound specifications in its
declaration, which may be different from the rank of the actual array it is
associated with.
The size is assumed from the actual argument that is associated with the
assumed-size array:
v
If the actual argument is a noncharacter array, the size of the assumed-size array
is that of the actual array.
v
If the actual argument is an array element from a noncharacter array, and if the
size remaining in the array beginning at this element is S, then the size of the
dummy argument array is S. Array elements are processed in array element
order.
v
If the actual argument is a character array, array element, or array element
substring, and assuming that:
A is the starting offset, in characters, into the character array
T is the total length, in characters, of the original array
S is the length, in characters, of an element in the dummy argument array
then the size of the dummy argument array is:
MAX( INT (T - A + 1) / S, 0 )
For example:
CHARACTER(10) A(10)
CHARACTER(1) B(30)
CALL SUB1(A)
! Size of dummy argument array is 10
CALL SUB1(A(4))
! Size of dummy argument array is 7
CALL SUB1(A(6)(5:10)) ! Size of dummy argument array is 4 because there
82
XL Fortran: Language Reference

! are just under 4 elements remaining in A
CALL SUB1(B(12))
! Size of dummy argument array is 1, because the
! remainder of B can hold just one CHARACTER(10)
END
! element.
SUBROUTINE SUB1(ARRAY)
CHARACTER(10) ARRAY(*)
...
END SUBROUTINE
Examples
INTEGER X(3,2)
DO I = 1,3
DO J = 1,2
X(I,J) = I * J
! The elements of X are 1, 2, 3, 2, 4, 6
END DO
END DO
PRINT *,SHAPE(X)
! The shape is (/ 3, 2 /)
PRINT *,X(1,:)
! The first row is (/ 1, 2 /)
CALL SUB1(X)
CALL SUB2(X)
END
SUBROUTINE SUB1(Y)
INTEGER Y(2,*)
! The dimensions of y are the reverse of x above
PRINT *, SIZE(Y,1)
! We can examine the size of the first dimension
! but not the last one.
PRINT *, Y(:,1)
! We can print out vectors from the first
PRINT *, Y(:,2)
! dimension, but not the last one.
END SUBROUTINE
SUBROUTINE SUB2(Y)
INTEGER Y(*)
! Y has a different rank than X above.
PRINT *, Y(6)
! We have to know (or compute) the position of
! the last element.
Nothing prevents us from
! subscripting beyond the end.
END SUBROUTINE
Note:
1. An assumed-size array cannot be used as a whole array in an executable
construct unless it is an actual argument in a subprogram reference that does
not require the shape:
! A is an assumed-size array.
PRINT *, UBOUND(A,1) ! OK - only examines upper bound of first dimension.
PRINT *, LBOUND(A)
! OK - only examines lower bound of each dimension.
! However, ’B=UBOUND(A)’ or ’A=5’ would reference the upper bound of
! the last dimension and are not allowed.
SIZE(A) and SHAPE(A) are
! also not allowed.
2. If a section of an assumed-size array has a subscript triplet as its last section
subscript, the upper bound must be specified. (Array sections and subscript
triplets are explained in a subsequent section.)
! A is a 2-dimensional assumed-size array
PRINT *, A(:, 6)
! Triplet with no upper bound is not last dimension.
PRINT *, A(1, 1:10)
! Triplet in last dimension has upper bound of 10.
PRINT *, A(5, 5:9:2)
! Triplet in last dimension has upper bound of 9.
Array elements
Array elements are the scalar data that make up an array. Each element inherits the
type, type parameters, and INTENT, PARAMETER, TARGET,
PROTECTED, ASYNCHRONOUS, and VOLATILE
attributes
from its parent array. The POINTER and ALLOCATABLE attributes are not
inherited.
Chapter 5. Array concepts
83

Syntax
You identify an array element by an array element designator, whose form is:
array_name
(
subscript_list
)
array_struct_comp
array_name
is the name of an array
array_struct_comp
is a structure component whose rightmost comp_name is an array
subscript
is a scalar integer expression
A subscript can be a scalar real expression in XL Fortran.
Rules
v
The number of subscripts must equal the number of dimensions in the array.
v
If array_struct_comp is present, each part of the structure component except the
rightmost must have rank zero (that is, must not be an array name or an array
section).
v
The value of each subscript expression must not be less than the lower bound or
greater than the upper bound for the corresponding dimension.
v
The subscript value depends on the value of each subscript expression and on
the dimensions of the array. It determines which element of the array is
identified by the array element designator.
Array element order
The elements of an array are arranged in storage in a sequence known as the array
element order, in which the subscripts change most rapidly in the first dimension,
and subsequently in the remaining dimensions.
For example, an array declared as A(2, 3, 2) has the following elements:
Position of Array Element
Array Element Order
-------------------------
-------------------
A(1,1,1)
1
A(2,1,1)
2
A(1,2,1)
3
A(2,2,1)
4
A(1,3,1)
5
A(2,3,1)
6
A(1,1,2)
7
A(2,1,2)
8
A(1,2,2)
9
A(2,2,2)
10
A(1,3,2)
11
A(2,3,2)
12
Related information
“Derived type components” on page 49
“Array sections and structure components” on page 89
84
XL Fortran: Language Reference

Array sections
An array section is a selected portion of an array. It is an array subobject that
designates a set of elements from an array, or a specified substring or derived-type
component from each of those elements. An array section is also an array.
Note: This introductory section describes the simple case, where structure
components are not involved. “Array sections and structure components” on page
89 explains the additional rules for specifying array sections that are also structure
components.
array_name
(
section_subscript_list
)
substring_range
section_subscript
designates some set of elements along a particular dimension. It can be
composed of a combination of the following:
subscript
subscript_triplet
vector_subscript
subscript
is a scalar integer expression. For details, see “Array elements” on
page 83.
A subscript can be a scalar real expression in XL Fortran.
subscript_triplet, vector_subscript
designate a sequence of subscripts in a given dimension. For
details, see “Subscript triplets” on page 86 and “Vector subscripts”
on page 88.
Notes:
v
At least one of the dimensions must be a subscript triplet or vector
subscript, so that an array section is distinct from an array element. See
Example 1.
v
F2008
An array section can contain a set of array elements that is
contiguous or not contiguous within the array. For more information, see
Contiguity. F2008
substring_range
(
:
)
int_expr1
int_expr2
int_expr1, int_expr2
are scalar integer expressions called substring expressions, defined
Chapter 5. Array concepts
85

in “Character substrings” on page 44. They specify the leftmost
and rightmost character positions, respectively, of a substring of
each element in the array section. If an optional substring_range is
present, the section must be from an array of character objects. For
details, see “Substring ranges” on page 88.
An array section is formed from the array elements specified by the sequences of
values from the individual subscripts, subscript triplets, and vector subscripts,
arranged in column-major order. See Example 2.
Examples
Example 1
INTEGER, DIMENSION(5,5,5) :: A
A(1,2,3) = 100
A(1,3,3) = 101
PRINT *, A(1,2,3)
! A single array element, 100.
PRINT *, A(1,2:2,3)
! A one-element array section, (/ 100 /)
PRINT *, A(1,2:3,3)
! A two-element array section,
! (/ 100, 101 /)
Example 2
If SECTION = A(1:3, (/5, 6, 5/), 4)
v
The sequence of numbers for the first dimension is 1, 2, 3.
v
The sequence of numbers for the second dimension is 5, 6, 5.
v
The subscript for the third dimension is the constant 4.
The section is made up of the following elements of A, in this order:
A(1,5,4)
|
|
SECTION(1,1)
A(2,5,4)
|----- First column -----|
SECTION(2,1)
A(3,5,4)
|
|
SECTION(3,1)
A(1,6,4)
|
|
SECTION(1,2)
A(2,6,4)
|----- Second column ----|
SECTION(2,2)
A(3,6,4)
|
|
SECTION(3,2)
A(1,5,4)
|
|
SECTION(1,3)
A(2,5,4)
|----- Third column -----|
SECTION(2,3)
A(3,5,4)
|
|
SECTION(3,3)
Example 3
Some other examples of array sections include:
INTEGER, DIMENSION(20,20) :: A
! These references to array sections require loops or multiple
! statements in FORTRAN 77.
PRINT *, A(1:5,1)
! Contiguous sequence of elements
PRINT *, A(1:20:2,10)
! Noncontiguous sequence of elements
PRINT *, A(:,5)
! An entire column
PRINT *, A( (/1,10,5/), (/7,3,1/) ) ! A 3x3 assortment of elements
Related information
v
“Derived type components” on page 49
Subscript triplets
A subscript triplet consists of two subscripts and a stride, and defines a sequence
of numbers corresponding to array element positions along a single dimension.
86
XL Fortran: Language Reference

:
subscript1
subscript2
:
stride
subscript1
is the subscript that designates the first value in the sequence of indices for
a dimension.
If it is omitted, the lower array bound of that dimension is used.
subscript2
is the subscript that designates the last value in the sequence of indices for
a dimension.
If it is omitted, the upper array bound of that dimension is used. It is
mandatory for the last dimension when specifying sections of an
assumed-size array.
stride
is a scalar integer expression that specifies how many subscript positions to
count to reach the next selected element.
A stride can be a scalar real expression in XL Fortran.
If the stride is omitted, it has a value of 1. The stride must have a nonzero
value:
v
A positive stride specifies a sequence of integers that begins with the
first subscript and proceeds in increments of the stride to the largest
integer that is not greater than the second subscript. If the first subscript
is greater than the second, the sequence is empty.
v
When the stride is negative, the sequence begins at the first subscript
and continues in increments specified by the stride to the smallest
integer equal to or greater than the second subscript. If the second
subscript is greater than the first, the sequence is empty.
Calculations of values in the sequence use the same steps as shown in “Executing
a DO statement” on page 136.
A subscript in a subscript triplet does not have to be within the declared bounds
for that dimension if all the values used in selecting the array elements for the
array section are within the declared bounds:
INTEGER A(9)
PRINT *, A(1:9:2)
! Count from 1 to 9 by 2s: 1, 3, 5, 7, 9.
PRINT *, A(1:10:2) ! Count from 1 to 10 by 2s: 1, 3, 5, 7, 9.
! No element past A(9) is specified.
Examples
REAL, DIMENSION(10) :: A
INTEGER, DIMENSION(10,10) :: B
CHARACTER(10) STRING(1:100)
PRINT *, A(:)
! Print all elements of array.
PRINT *, A(:5)
! Print elements 1 through 5.
PRINT *, A(3:)
! Print elements 3 through 10.
PRINT *, STRING(50:100)
! Print all characters in
! elements 50 through 100.
! The following statement is equivalent to A(2:10:2) = A(1:9:2)
A(2::2) = A(:9:2)
! LHS = A(2), A(4), A(6), A(8), A(10)
Chapter 5. Array concepts
87

! RHS = A(1), A(3), A(5), A(7), A(9)
! The statement assigns the odd-numbered
! elements to the even-numbered elements.
! The following statement is equivalent to PRINT *, B(1:4:3,1:7:6)
PRINT *, B(:4:3,:7:6)
! Print B(1,1), B(4,1), B(1,7), B(4,7)
PRINT *, A(10:1:-1)
! Print elements in reverse order.
PRINT *, A(10:1:1)
! These two are
PRINT *, A(1:10:-1)
! both zero-sized.
END
Vector subscripts
A vector subscript is an integer array expression of rank one, designating a
sequence of subscripts that correspond to the values of the elements of the
expression.
A vector subscript can be a real array expression of rank one in XL
Fortran.
The sequence does not have to be in order, and may contain duplicate values:
INTEGER A(10), B(3), C(3)
PRINT *, A( (/ 10,9,8 /) ) ! Last 3 elements in reverse order
B = A( (/ 1,2,2 /) )
! B(1) = A(1), B(2) = A(2), B(3) = A(2) also
END
An array section with a vector subscript in which two or more elements of the
vector subscript have the same value is called a many-one section. Such a section
must not:
v
Appear on the left side of the equal sign in an assignment statement
v
Be initialized through a DATA statement
v
Be used as an input item in a READ statement
Notes:
1. An array section used as an internal file must not have a vector subscript.
2. If you pass an array section with a vector subscript as an actual argument, the
associated dummy argument must not be defined or redefined.
3. An array section with a vector subscript must not be the target in a pointer
assignment statement.
4.
F2008
In XL Fortran, a nonzero-sized array section containing a vector
subscript is considered noncontiguous. For details, see Contiguity. F2008
! We can use the whole array VECTOR as a vector subscript for A and B
INTEGER, DIMENSION(3) :: VECTOR= (/ 1,3,2 /), A, B
INTEGER, DIMENSION(4) :: C = (/ 1,2,4,8 /)
A(VECTOR) = B
! A(1) = B(1), A(3) = B(2), A(2) = B(3)
A = B( (/ 3,2,1 /) )
! A(1) = B(3), A(2) = B(2), A(3) = B(1)
PRINT *, C(VECTOR(1:2))
! Prints C(1), C(3)
END
Substring ranges
For an array section with a substring range, each element in the result is the
designated character substring of the corresponding element of the array section.
The rightmost array name or component name must be of type character.
PROGRAM SUBSTRING
TYPE DERIVED
CHARACTER(10) STRING(5)
! Each structure has 5 strings of 10 chars.
88
XL Fortran: Language Reference

END TYPE DERIVED
TYPE (DERIVED) VAR, ARRAY(3,3)
! A variable and an array of derived type.
VAR%STRING(:)(1:3) = ’abc’
! Assign to chars 1-3 of elements 1-5.
VAR%STRING(3:)(4:6) = ’123’
! Assign to chars 4-6 of elements 3-5.
ARRAY(1:3,2)%STRING(3)(5:10) = ’hello’
! Assign to chars 5-10 of the third element in
! ARRAY(1,2)%STRING, ARRAY(2,2)%STRING, and
END
! ARRAY(3,2)%STRING
Array sections and structure components
Understanding how array sections and structure components interact requires a
familiarity with the syntax for “Derived type components” on page 49.
What we defined at the beginning of this section as an array section is really only
a subset of the possible array sections. An array name or array name with a
section_subscript_list can be a subobject of a structure component:
struct_sect_subobj:
object_name
(
section_subscript_list
)
%
comp_name
.
(
section_subscript_list
)
substring_range
object_name
is the name of an object of derived type
section_subscript_list, substring_range
are the same as defined under “Array sections” on page 85
comp_name
is the name of a derived-type component
% or . Separator character.
Note: The . (period) separator is an IBM extension.
Note:
1. The type of the last component determines the type of the array.
2. Only one part of the structure component may have nonzero rank. Either the
rightmost comp_name must have a section_subscript_list with nonzero rank, or
another part must have nonzero rank.
3. Any parts to the right of the part with nonzero rank must not have the
ALLOCATABLE or POINTER attributes.
Chapter 5. Array concepts
89

TYPE BUILDING_T
LOGICAL RESIDENTIAL
END TYPE BUILDING_T
TYPE STREET_T
TYPE (BUILDING_T) ADDRESS(500)
END TYPE STREET_T
TYPE CITY_T
TYPE (STREET_T) STREET(100,100)
END TYPE CITY_T
TYPE (CITY_T) PARIS
TYPE (STREET_T) S
TYPE (BUILDING_T) RESTAURANT
! LHS is not an array section, no subscript triplets or vector subscripts.
PARIS%STREET(10,20) = S
! None of the parts are array sections, but the entire construct
!
is a section because STREET has a nonzero rank and is not
!
the rightmost part.
PARIS%STREET%ADDRESS(100) = BUILDING_T(.TRUE.)
! STREET(50:100,10) is an array section, making the LHS an array section
!
with rank=1, shape=(/51/).
! ADDRESS(123) must not be an array section because only one can appear
!
in a reference to a structure component.
PARIS%STREET(50:100,10)%ADDRESS(123)%RESIDENTIAL = .TRUE.
END
Rank and shape of array sections
For an array section that is not a subobject of a structure component, the rank is
the number of subscript triplets and vector subscripts in the section_subscript_list.
The number of elements in the shape array is the same as the number of subscript
triplets and vector subscripts, and each element in the shape array is the number
of integer values in the sequence designated by the corresponding subscript triplet
or vector subscript.
For an array section that is a subobject of a structure component, the rank and
shape are the same as those of the part of the component that is an array name or
array section.
DIMENSION :: ARR1(10,20,100)
TYPE STRUCT2_T
LOGICAL SCALAR_COMPONENT
END TYPE
TYPE STRUCT_T
TYPE (STRUCT2_T), DIMENSION(10,20,100) :: SECTION
END TYPE
TYPE (STRUCT_T) STRUCT
! One triplet + one vector subscript, rank = 2.
! Triplet designates an extent of 10, vector subscript designates
!
an extent of 3, thus shape = (/ 10,3 /).
ARR1(:, (/ 1,3,4 /), 10) = 0
! One triplet, rank = 1.
! Triplet designates 5 values, thus shape = (/ 5 /).
STRUCT%SECTION(1,10,1:5)%SCALAR_COMPONENT = .TRUE.
! Here SECTION is the part of the component that is an array,
!
so rank = 3 and shape = (/ 10,20,100 /), the same as SECTION.
STRUCT%SECTION%SCALAR_COMPONENT = .TRUE.
90
XL Fortran: Language Reference

Array constructors
An array constructor is a sequence of specified scalar values. It constructs a
rank-one array whose element values are those specified in the sequence. You can
construct arrays of rank greater than one using an intrinsic function. See
“RESHAPE(SOURCE, SHAPE, PAD, ORDER)” on page 653 for details.
Syntax
(/ac_spec/)
[ ac_spec ]
where ac_spec is:
i_d_type_spec
::
,
ac_value
i_d_type_spec
::
i_d_type_spec
Is an intrinsic_type_spec or derived_type_spec. For a list of possible type
specifications, see “Type Declaration” on page 456.
You cannot use BYTE as an intrinsic_type_spec in an array constructor.
ac_value
is an expression or implied-DO list that provides values for array elements.
Rules
An i_d_type_spec specifies the type and type parameters of the array constructor.
Each ac_value expression must be compatible with intrinsic assignment to a
variable with the type and type parameters. Each value is converted to the type
parameters of the array constructor.
v
If you specify an intrinsic type, each ac_value expression in the array constructor
must be of an intrinsic type compatible with the type you specify.
v
If you specify a derived type, all ac_value expressions in the array constructor
must be of that derived type and have the same kind type parameter values as
the type you specify.
If i_d_type_spec is omitted, each ac_value expression in the array constructor must
have the same type and type parameters.
If i_d_type_spec appears without an ac_value, a zero-sized rank-one array is created.
The ac_value complies with the following rules:
v
If it is a scalar expression, its value specifies an element of the array constructor.
v
If it is an array expression, the values of the elements of the expression, in array
element order, specify the corresponding sequence of elements of the array
constructor.
v
If it is an implied-DO list, it is expanded to form an ac_value sequence under the
control of the implied_do_variable, as in the DO construct.
Chapter 5. Array concepts
91

If ac_value is a polymorphic entity, its declared type is used. Because unlimited
polymorphic entities have no declared type, you cannot use them for ac_value.
If you compile your program with -qxlf2003=dynamicacval, the dynamic
type of ac_value is used, and you can use unlimited polymorphic entities for
ac_value.
For more details about using polymorphic entities for ac_value,
see Example 2.
For more information about unlimited polymorphic entities, the declared and
dynamic types of these entities, see Polymorphic entities.
Examples
Example 1: Different array constructors
INTEGER, DIMENSION(5) :: a, b, c, d(2, 2)
CHARACTER(5), DIMENSION(3) :: color
! Assign values to all elements in a
a = (/1, 2, 3, 4, 5/)
! Assign values to some elements
a(3:5) = (/0, 1, 0/)
! Construct temporary logical mask
c = MERGE(a, b, (/T, F, T, T, F/))
! The array constructor produces a rank-one array, which
! is turned into a 2x2 array that can be assigned to d.
d = RESHAPE(SOURCE = (/1, 2, 1, 2/), SHAPE = (/2, 2/))
! Here, the constructor linearizes the elements of d in
! array-element order into a one-dimensional result.
PRINT *, a((/d/))
! Without a type_spec,each character literal must be of length 5
color = [’RED
’, ’GREEN’, ’BLUE ’]
! With a type_spec, padding and truncation of each character literal occurs
color = [CHARACTER(5) :: ’RED’, ’GREEN’, ’BLUE’]
Example 2: Polymorphic entities as ac_value
PROGRAM PolyAcValues
TYPE base
INTEGER :: i
END TYPE
TYPE, EXTENDS(base) :: child
INTEGER :: j
END TYPE
TYPE(base) :: baseType = base(3)
TYPE(child) :: childType = child(4, 6)
! Declare a polymorphic entity of base type
CLASS(base), ALLOCATABLE :: baseClass
! Declare an unlimited polymorphic entity. It has no declared type.
! Its dynamic type can be any derived type or intrinsic type
92
XL Fortran: Language Reference

CLASS(*), ALLOCATABLE :: anyClass
! Declare a deferred-shape array of unlimited polymorphic entities
CLASS(*), ALLOCATABLE :: anyClassArr(:)
! Allocate a child item to baseClass. The dynamic type of bassClass is child.
ALLOCATE(baseClass, source = childType)
! Polymorphic entities used in the array constructor
ALLOCATE(anyClassArr(2), source = [baseClass, baseClass])
! Because the compiler uses the declared type, which is base, and the result
! is "Base item: 4 4". If you specify -qxlf2003=dynamicacval, the compiler uses
! the dynamic type, which is child, and the result is "Child item: 4,6 4,6".
CALL printAny(anyClassArr, 2)
DEALLOCATE(anyClassArr)
DEALLOCATE(baseClass)
! Allocate a base item to anyClass. The dynamic type of anyClass is base.
ALLOCATE(anyClass, source = baseType)
! Unlimited polymorphic entities used in the array constructor
ALLOCATE(anyClassArr(2), source = [anyClass, anyClass])
! If you specify -qxlf2003=dynamicacval, the use of unlimited polymorphic
! entities in the array constructor is valid, and the compiler uses the
! dynamic type, which is base. The result is "Base item: 3 3"; Otherwise,
! a severe error is issued at compile time.
CALL printAny(anyClassArr, 2)
DEALLOCATE(anyClassArr)
DEALLOCATE(anyClass)
CONTAINS
SUBROUTINE printAny(printItem, len)
CLASS(*) :: printItem(len)
DO i = 1, len
SELECT TYPE (item => printItem(i))
TYPE IS (base)
PRINT *, ’Base item: ’, item
TYPE IS (child)
PRINT *, ’Child item: ’, item
END SELECT
END DO
END SUBROUTINE
END PROGRAM
Related information
v
The -qxlf2003=dynamicacval option
v
“Polymorphic entities (Fortran 2003)” on page 18
Implied-DO list for an array constructor
Implied-DO loops in array constructors help to create a regular or cyclic sequence
of values, to avoid specifying each element individually.
A zero-sized array of rank one is formed if the sequence of values generated by the
loop is empty.
Chapter 5. Array concepts
93

(
ac_value_list
,
implied_do_variable
=
expr1
,
expr2
)
,
expr3
implied_do_variable
is a named scalar integer
or real
variable.
In a nonexecutable statement, the type must be integer. You must not
reference the value of an implied_do_variable in the limit expressions expr1
or expr2. Loop processing follows the same rules as for an implied-DO in
“DATA” on page 316, and uses integer or real arithmetic depending on the
type of the implied-DO variable.
The variable has the scope of the implied-DO, and it must not have the
same name as another implied-DO variable in a containing array
constructor implied-DO:
M = 0
PRINT *, (/ (M, M=1, 10) /) ! Array constructor implied-DO
PRINT *, M
! M still 0 afterwards
PRINT *, (M, M=1, 10)
! Non-array-constructor implied-DO
PRINT *, M
! This one goes to 11
PRINT *, (/ ((M, M=1, 5), N=1, 3) /)
! The result is a 15-element, one-dimensional array.
! The inner loop cannot use N as its variable.
expr1, expr2, and expr3
are scalar integer
or real
expressions
PRINT *, (/ (I, I = 1, 3) /)
! Sequence is (1, 2, 3)
PRINT *, (/ (I, I = 1, 10, 2) /)
! Sequence is (1, 3, 5, 7, 9)
PRINT *, (/ (I, I+1, I+2, I = 1, 3) /)
! Sequence is (1, 2, 3, 2, 3, 4, 3, 4, 5)
PRINT *, (/ ( (I, I = 1, 3), J = 1, 3 ) /)
! Sequence is (1, 2, 3, 1, 2, 3, 1, 2, 3)
PRINT *, (/ ( (I, I = 1, J), J = 1, 3 ) /)
! Sequence is (1, 1, 2, 1, 2, 3)
PRINT *, (/2,3,(I, I+1, I = 5, 8)/)
! Sequence is (2, 3, 5, 6, 6, 7, 7, 8, 8, 9).
! The values in the implied-DO loop before
!
I=5 are calculated for each iteration of the loop.
Contiguity (Fortran 2008)
Contiguous objects occupy a contiguous block of memory. The use of contiguous
objects makes it easier to enable optimizations that depend on the memory layout
of the objects.
An object is contiguous if it meets one of the following requirements:
v
It is an object that has the CONTIGUOUS attribute.
v
It is a whole array that is neither an array pointer nor an assumed-shape array.
v
It is an array that is allocated by an ALLOCATE statement.
v
It is a pointer that is associated with a contiguous target.
v
It is an assumed-shape array that is argument associated with a contiguous
array.
94
XL Fortran: Language Reference

v
It is a nonzero-sized array section that meets all the following requirements:
– Its base object is contiguous.
– It does not have a vector_subscript.
– The elements of the section, in array element order, are a subset of the base
object elements that are consecutive in array element order.
– If the array is of type character and a substring_range is used, the
substring_range specifies all the characters of the parent string.
– Only its rightmost comp_name has nonzero rank.
– It is not the real or imaginary part of an array of type complex.
An object is not contiguous if it is an array subobject and meets all the following
requirements:
v
The object has two or more elements.
v
The elements of the object in array element order are not consecutive in the
elements of the base object.
v
The object is not of type character that has zero length.
v
The object is not of a derived type that only contains zero-sized arrays and
characters that have zero length.
Note: In addition to the preceding scenarios, XL Fortran determines whether the
object is contiguous, based on its own rules.
Simply contiguous
A simply contiguous array is one that the XL Fortran compiler can determine to be
contiguous at compile time.
A section_subscript_list specifies a simply contiguous array section only if it meets
all the following requirements:
v
It does not have a vector_subscript.
v
All but the last subscript_triplet is a colon.
v
The last subscript_triplet does not have a stride.
v
No subscript_triplet is preceded by a section_subscript that is a subscript.
An array subobject designator is simply contiguous only if it meets one of the
following requirements:
v
An object_name that has the CONTIGUOUS attribute
v
An object_name that is neither a pointer nor an assumed shape array
v
A structure component whose rightmost part_name is an array. The rightmost
part_name either has the CONTIGUOUS attribute or is not a pointer.
v
An array section that meets all the following requirements:
– It is not a complex part designator.
– It does not have a substring_range.
– Its rightmost comp_name has nonzero rank.
– Its rightmost part_name has the CONTIGUOUS attribute or is neither of
assumed shape nor a pointer.
– It either does not have a section_subscript_list, or has a section_subscript_list
which specifies a simply contiguous section.
Chapter 5. Array concepts
95

An array variable is simply contiguous only if it meets one of the following
requirements:
v
It is an array subobject designator that is simply contiguous.
v
It is a reference to a function that returns a pointer with the CONTIGUOUS
attribute.
Note: In addition to the preceding scenarios, XL Fortran may determine contiguity
at compile time, based on its own rules.
Related information
v
Array sections
v
CONTIGUOUS
Expressions involving arrays
Arrays can be used in the same kinds of expressions and operations as scalars.
Intrinsic operations, assignments, or elemental procedures can be applied to one or
more arrays.
For intrinsic operations, in expressions involving two or more array operands, the
arrays must have the same shape so that the corresponding elements of each array
can be assigned to or be evaluated. In a defined operation arrays can have
different shapes. Arrays with the same shape are conformable. In a context where a
conformable entity is expected, you can also use a scalar value: it is conformable
with any array, such that it is treated like an array where each array element has
the value of the scalar.
Examples
INTEGER, DIMENSION(5,5) :: A,B,C
REAL, DIMENSION(10) :: X,Y
! Here are some operations on arrays
A = B + C
! Add corresponding elements of both arrays.
A = -B
! Assign the negative of each element of B.
A = MAX(A,B,C)
! A(i,j) = MAX( A(i,j), B(i,j), C(i,j) )
X = SIN(Y)
! Calculate the sine of each element.
! These operations show how scalars are conformable with arrays
A = A + 5
! Add 5 to each element.
A = 10
! Assign 10 to each element.
A = MAX(B, C, 5)
! A(i,j) = MAX( B(i,j), C(i,j), 5 )
END
Related information
“Elemental intrinsic procedures” on page 539
“Intrinsic assignment” on page 113
“WHERE” on page 473 shows a way to assign values to some elements in an
array but not to others
“FORALL construct” on page 122
96
XL Fortran: Language Reference

Chapter 6. Expressions and assignment
Introduction to expressions and assignment
An expression is a data reference or a computation, and is formed from operands,
operators, and parentheses. An expression, when evaluated, produces a value,
which has a declared type, a dynamic type, a shape, and possibly type parameters.
An operand is either a scalar or an array. An operator is either intrinsic or defined. A
unary operation has the form:
v
operator operand
A binary operation has the form:
v
operand1 operator operand2
Any expression contained in parentheses is treated as a data entity. Parentheses can
be used to specify an explicit interpretation of an expression. They can also be
used to restrict the alternative forms of the expression, which can help control the
magnitude and accuracy of intermediate values during evaluation of the
expression. For example, the two expressions
(I*J)/K
I*(J/K)
are mathematically equivalent, but may produce different computational values as
a result of evaluation.
Primary
A primary is the simplest form of an expression. It can be one of the following:
v
A type parameter inquiry such as a%kind
v
A type parameter name
v
A data object
v
An array constructor
v
A structure constructor
v
A complex constructor
v
A function reference
v
An expression enclosed in parentheses
A primary that is a data object must not be an assumed-size array.
Examples of primaries
12.3
! Constant
’ABCDEFG’(2:3)
! Subobject of a constant
VAR
! Variable name
(/7.0,8.0/)
! Array constructor
EMP(6,’SMITH’)
! Structure constructor
SIN(X)
! Function reference
(T-1)
! Expression in parentheses
Type, parameters, and shape
The type, type parameters, and shape of a primary are determined as follows:
© Copyright IBM Corp. 1996, 2012
97

v
A data object or function reference acquires the type, type parameters, and shape
of the object or function reference, respectively. The type, parameters, and shape
of a generic function reference are determined by the type, parameters, and
ranks of its actual arguments.
v
A type parameter inquiry or type parameter name is a scalar integer with the
kind of the type parameter.
v
A structure constructor is a scalar and its type and parameters are determined
by the derived_type_spec of the structure constructor.
v
An array constructor has a shape determined by the number of constructor
expressions, and its type and parameters are determined by those of the
constructor expressions.
v
A parenthesized expression acquires the type, parameters, and shape of the
expression.
If a pointer appears as a primary in an operation in which it is associated with a
nonpointer dummy argument, the target is referenced. The type, parameters, and
shape of the primary are those of the target. If the pointer is not associated with a
target, it can appear only as an actual argument in a procedure reference whose
corresponding dummy argument is a pointer, or as the target in a pointer
assignment statement. A disassociated pointer can also appear as an actual
argument to the ASSOCIATED intrinsic inquiry function.
Given the intrinsic operation [ expr1] op expr2, the shape of the operation is the
shape of expr2 if op is unary or if expr1 is a scalar. Otherwise, its shape is that of
expr1.
The type and shape of an expression are determined by the operators and by the
types and shapes of the expression's primaries. The type of the expression can be
intrinsic or derived. An expression of intrinsic type has a kind parameter and, if it
is of type character, it also has a length parameter. An expression of derived type
can have both kind and length parameters.
Constant expressions
A constant expression is an expression in which each operation is intrinsic and
each primary is one of the following:
Note: In Fortran 2003, the constant expression is known as initialization
expression.
v
A constant or a subobject of a constant.
v
A structure constructor where each component is a constant expression.
v
An array constructor where each element and the bounds and strides of each
implied-DO are expressions whose primaries are either constant expressions or
implied-DO variables.
v
A structure constructor in which each expression corresponding to an allocatable
component is a reference to the intrinsic function NULL, and all other
expressions are constant expressions.
v
An elemental intrinsic function reference where each argument is a constant
expression.
v
A reference to the intrinsic function NULL that does not have an argument with
a type parameter that is assumed or defined by a nonconstant expression.
v
A reference to the vector intrinsic function VEC_CONVERT where each
argument is a constant expression.
98
XL Fortran: Language Reference

v
A reference to the transformational intrinsic function other than
COMMAND_ARGUMENT_COUNT and NULL where each argument is a
constant expression.
v
A reference to the transformation intrinsic function
IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE_ARITHMETIC,
where each argument is a constant expression.
v
A kind type parameter of the type being defined or of its parent type, within the
derived type definition
v
A specification inquiry where each designator or function argument is either a
constant expression, or a variable with properties that are not assumed, deferred
or defined by an expression that is not a constant expression.
v
A data-i-DO variable within a data-implied-DO.
v
An ac-DO-variable within an array constructor where each scalar-int-expr of the
corresponding acimplied-DO-control is a constant expression.
v
A constant expression enclosed in parentheses.
and where each subscript, section subscript, substring starting point, substring
ending point, and type parameter value is a constant expression.
If a constant expression includes a specification inquiry that depends on a TYPE
parameter or an array bound of an object specified in the same specification part,
the type parameter or array bound must be specified in a prior specification of the
specification part. The prior specification can be to the left of the specification
inquiry in the same statement, but must not be within the same entity declaration.
Examples
Examples of different constant expressions:
-48.9
name(’Pat’,’Doe’)
TRIM(’ABC
’)
(MOD(9,4)**3.5)
3.4**3
KIND(57438)
(/’desk’,’lamp’/)
’ab’//’cd’//’ef’
Example of an elemental intrinsic function, SIN, used in a constant expression:
integer, parameter :: foo = 42.0 * sin(0.5)
Example of a transformational intrinsic function, CSHIFT, used in a constant
expression:
integer, parameter :: a(3) = (/ 1, 2, 3 /)
integer, parameter :: a_cshifted(3) = cshift(a,2)
Specification expressions
A specification expression is an expression with limitations that you can use to
specify items such as character lengths and array bounds.
A specification expression is a scalar, integer, restricted expression.
A restricted expression is an expression in which each operation is intrinsic and each
primary is:
v
A type parameter of the derived type being defined.
Chapter 6. Expressions and assignment
99

v
A constant or a subobject of a constant.
v
A variable that is a dummy argument that has neither the OPTIONAL nor the
INTENT(OUT) attribute, or a subobject of such a variable.
v
A variable that is in a common block, or a subobject of such a variable.
v
A variable accessible by use association or host association, or a subobject of
such a variable.
v
An array constructor where each element and the bounds and strides of each
implied-DO are expressions whose primaries are either restricted expressions or
implied-DO variables.
v
A structure constructor where each component is a restricted expression.
v
A specification inquiry where each designator or function argument is either a
restricted expression or a variable with properties that are not assumed,
deferred, or defined by an expression that is not a restricted expression.
v
A reference to any remaining intrinsic functions defined in this document where
each argument is a restricted expression.
v
A reference to a system inquiry function, where any arguments are
restricted expressions.
v
Any subscript or substring expression must be a restricted expression.
v
A reference to a specification function, where any arguments are restricted
expressions.
A specification inquiry is a reference to:
v
An intrinsic inquiry function
v
A type parameter inquiry (6.4.5)
v
An IEEE inquiry function (14.10)
You can use a specification function in a specification expression. A function is a
specification function if it is a pure function that is not an intrinsic, internal or
statement function. A specification function cannot have a dummy procedure
argument.
A variable in a specification expression must have its type and type parameters, if
any, specified by a previous declaration in the same scoping unit, or by the implicit
typing rules in effect for the scoping unit, or by host or use association. If a
variable in a specification expression is typed by the implicit typing rules, its
appearance in any subsequent type declaration statement must confirm the implied
type and type parameters.
If a specification expression includes a reference to an inquiry function for a type
parameter or an array bound of an entity specified in the same specification part,
the type parameter or array bound must be specified in a prior specification of the
specification part. If a specification expression includes a reference to the value of
an element of an array specified in the same specification part, the array bounds
must be specified in a prior declaration. The prior specification can be to the left of
the inquiry function in the same statement.
Examples
LBOUND(C,2)+6
! C is an assumed-shape dummy array
ABS(I)*J
! I and J are scalar integer variables
276/NN(4)
! NN is accessible through host association
The following example shows how a user-defined pure function, fact, can be used
in the specification expression of an array-valued function result variable:
100
XL Fortran: Language Reference

MODULE MOD
CONTAINS
INTEGER PURE FUNCTION FACT(N)
INTEGER, INTENT(IN) :: N
...
END FUNCTION FACT
END MODULE MOD
PROGRAM P
PRINT *, PERMUTE(’ABCD’)
CONTAINS
FUNCTION PERMUTE(ARG)
USE MOD
CHARACTER(*), INTENT(IN) :: ARG
...
CHARACTER(LEN(ARG)) :: PERMUTE(FACT(LEN(ARG)))
...
END FUNCTION PERMUTE
END PROGRAM P
Operators and expressions
This section contains details on the XL Fortran expressions listed in the XL Fortran
Expressions table. For information on the order of evaluation precedence see, How
expressions are evaluated.
Table 15. XL Fortran expressions
Arithmetic
Logical
Character
Primary
General
Relational
Arithmetic
An arithmetic expression (arith_expr), when evaluated, produces a numeric value.
The form of arith_expr is:
arith_term
+
arith_expr
-
The form of arith_term is:
arith_factor
arith_term
/
*
The form of arith_factor is:
Chapter 6. Expressions and assignment
101

arith_primary
**
arith_factor
An arith_primary is a primary of arithmetic type.
The following table shows the available arithmetic operators and the precedence
each takes within an arithmetic expression.
Arithmetic Operator
Representation
Precedence
**
Exponentiation
First
*
Multiplication
Second
/
Division
Second
+
Addition or identity
Third
-
Subtraction or negation
Third
XL Fortran evaluates the terms from left to right when evaluating an arithmetic
expression containing two or more addition or subtraction operators. For example,
2+3+4 is evaluated as (2+3)+4, although a processor can interpret the expression in
another way if it is mathematically equivalent and respects any parentheses.
The factors are evaluated from left to right when evaluating a term containing two
or more multiplication or division operators. For example, 2*3*4 is evaluated as
(2*3)*4.
The primaries are combined from right to left when evaluating a factor containing
two or more exponentiation operators. For example, 2**3**4 is evaluated as
2**(3**4). (Again, mathematical equivalents are allowed.)
The precedence of the operators determines the order of evaluation when XL
Fortran is evaluating an arithmetic expression containing two or more operators
having different precedence. For example, in the expression -A**3, the
exponentiation operator (**) has precedence over the negation operator (-).
Therefore, the operands of the exponentiation operator are combined to form an
expression that is used as the operand of the negation operator. Thus, -A**3 is
evaluated as -(A**3).
Note that expressions containing two consecutive arithmetic operators, such as
A**-B or A*-B, are not allowed. You can use expressions such as A**(-B) and
A*(-B).
If an expression specifies the division of an integer by an integer, the result is
rounded to an integer closer to zero. For example, (-7)/3 has the value -2.
For details of exception conditions that can arise during evaluation of
floating-point expressions, see Detecting and trapping floating-point exceptions.
Examples of arithmetic expressions
Arithmetic Expression
Fully Parenthesized Equivalent
-b**2/2.0
-((b**2)/2.0)
102
XL Fortran: Language Reference

Arithmetic Expression
Fully Parenthesized Equivalent
i**j**2
i**(j**2)
a/b**2 - c
(a/(b**2)) - c
Data type of an arithmetic expression
Because the identity and negation operators operate on a single operand, the type
of the resulting value is the same as the type of the operand.
The following table indicates the resulting type when an arithmetic operator acts
on a pair of operands.
Notation: T(param), where T is the data type (I: integer, R: real, X: complex) and
param is the kind type parameter.
Table 16. Result types for binary arithmetic operators
second operand
first
operand
I(1)
I(2)
I(4)
I(8)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
I(1)
I(1)
I(2)
I(4)
I(8)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
I(2)
I(2)
I(2)
I(4)
I(8)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
I(4)
I(4)
I(4)
I(4)
I(8)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
I(8)
I(8)
I(8)
I(8)
I(8)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
R(4)
R(4)
R(4)
R(4)
R(4)
R(4)
R(8)
R(16)
X(4)
X(8)
X(16)
R(8)
R(8)
R(8)
R(8)
R(8)
R(8)
R(8)
R(16)
X(8)
X(8)
X(16)
R(16)
R(16)
R(16)
R(16)
R(16)
R(16)
R(16)
R(16)
X(16)
X(16)
X(16)
X(4)
X(4)
X(4)
X(4)
X(4)
X(4)
X(8)
X(16)
X(4)
X(8)
X(16)
X(8)
X(8)
X(8)
X(8)
X(8)
X(8)
X(8)
X(16)
X(8)
X(8)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
X(16)
Note:
1. If you do not specify -qfloat=rndsngl, XL Fortran implements REAL(4)
operations using REAL(8) internal precision. If you specify -qfloat=rndsngl, XL
Fortran implements REAL(4) operations using REAL(4) internal precision. See
Detecting and trapping floating-point exceptions in the XL Fortran Optimization
and Programming Guide for details on modifying this implementation. REAL(16)
values must only be used in round to nearest mode. The rounding mode can
only be changed at the beginning and end of a subprogram. It cannot be
changed across a subprogram call; and if it is changed within a subprogram, it
must be restored before control is returned to the calling routine.
2. XL Fortran implements integer operations using INTEGER(4) arithmetic, or
INTEGER(8) arithmetic if data items are 8 bytes in length. If the intermediate
result is used in a context requiring INTEGER(1) or INTEGER(2) data type, it
is converted as required.
INTEGER(2) I2_1, I2_2, I2_RESULT
INTEGER(4) I4
I2_1 = 32767
! Maximum I(2)
I2_2 = 32767
! Maximum I(2)
I4 = I2_1 + I2_2
PRINT *, "I4=", I4
! Prints I4=-2
I2_RESULT = I2_1 + I2_2
! Assignment to I(2) variable
I4 = I2_RESULT
! and then assigned to an I(4)
PRINT *, "I4=", I4
! Prints I4=-2
END
Chapter 6. Expressions and assignment
103

Character
A character expression, when evaluated, produces a result of type character. The
form of char_expr is:
char_primary
char_expr
//
char_primary is a primary of type character. All character primaries in the
expression must have the same kind type parameter, which is also the kind type
parameter of the result.
The only character operator is //, representing concatenation.
In a character expression containing one or more concatenation operators, the
primaries are joined to form one string whose length is equal to the sum of the
lengths of the individual primaries. For example, ’AB’//’CD’//’EF’ evaluates to
’ABCDEF’, a string 6 characters in length.
Parentheses have no effect on the value of a character expression.
A character expression can include concatenation of an operand when you declare
the length with an asterisk in parentheses. This indicates inherited length. In this
case, the actual length depends on whether you use the inherited length character
string to declare:
v
A dummy argument specified in a FUNCTION, SUBROUTINE, or ENTRY
statement. The length of the dummy argument assumes the length of the
associated actual argument on invocation.
v
A named constant. The character expression takes on the length of the constant
value.
v
The length of an external function result. The calling scoping unit must not
declare the function name with an asterisk. On invocation, the length of the
function result assumes this defined length.
Examples
CHARACTER(7)
FIRSTNAME,LASTNAME
FIRSTNAME=’Martha’
LASTNAME=’Edwards’
PRINT *, LASTNAME//’, ’//FIRSTNAME
! Output:’Edwards, Martha’
END
General
The general form of an expression (general_expr) is:
expr
general_expr
defined_binary_op
104
XL Fortran: Language Reference

defined_binary_op
is a defined binary operator. See “Extended intrinsic and defined
operations” on page 109.
expr
is one of the kinds of expressions defined below.
There are four kinds of intrinsic expressions: arithmetic, character, relational, and
logical.
Logical
A logical expression (logical_expr), when evaluated, produces a result of type
logical. The form of a logical expression is:
logical_disjunct
logical_expr
.EQV.
.NEQV.
(1)
.XOR.
Notes:
1
XL Fortran logical operator
The form of a logical_disjunct is:
logical_term
logical_disjunct
.OR.
The form of a logical_term is:
logical_factor
logical_term
.AND.
The form of a logical_factor is:
logical_primary
.NOT.
rel_expr
logical_primary is a primary of type logical.
rel_expr is a relational expression.
The logical operators are:
Chapter 6. Expressions and assignment
105

Logical Operator
Representing
Precedence
.NOT.
Logical negation
First (highest)
.AND.
Logical conjunction
Second
.OR.
Logical inclusive disjunction
Third
.XOR. 1
Logical exclusive disjunction
Fourth (lowest)
.EQV.
Logical equivalence
Fourth (lowest)
.NEQV.
Logical nonequivalence
Fourth (lowest)
Note:
1. XL Fortran logical operator.
The .XOR. operator is treated as an intrinsic operator only when the
-qxlf77=intxor compiler option is specified. (See the -qxlf77 option in the XL
Fortran Compiler Reference for details.) Otherwise, it is treated as a defined operator.
If it is treated as an intrinsic operator, it can also be extended by a generic
interface.
The precedence of the operators determines the order of evaluation when a logical
expression containing two or more operators having different precedences is
evaluated. For example, evaluation of the expression A.OR.B.AND.C is the same as
evaluation of the expression A.OR.(B.AND.C).
Value of a logical expression
Given that x1 and x2 represent logical values, use the following tables to determine
the values of logical expressions:
x1
.NOT. x1
True
False
False
True
x1
x2
.AND.
.OR.
.XOR.
.EQV.
.NEQV.
False
False
False
False
False
True
False
False
True
False
True
True
False
True
True
False
False
True
True
False
True
True
True
True
True
False
True
False
Sometimes a logical expression does not need to be completely evaluated to
determine its value. Consider the following logical expression (assume that LFCT is
a function of type logical):
A .LT. B .OR. LFCT(Z)
If A is less than B, the evaluation of the function reference is not required to
determine that this expression is true.
XL Fortran evaluates a logical expression to a LOGICAL(n) or INTEGER(n) result,
where n is the kind type parameter. The value of n depends on the kind parameter
of each operand.
106
XL Fortran: Language Reference

By default, for the unary logical operator .NOT., n will be the same as the kind
type parameter of the operand. For example, if the operand is LOGICAL(2), the
result will also be LOGICAL(2).
The following table shows the resultant type for unary operations:
OPERAND
RESULT of Unary Operation
BYTE 1
INTEGER(1) 1
LOGICAL(1)
LOGICAL(1)
LOGICAL(2)
LOGICAL(2)
LOGICAL(4)
LOGICAL(4)
LOGICAL(8)
LOGICAL(8)
Typeless 1
Default integer 1
Note:
1. IBM Extension
If the operands are of the same length, n will be that length.
For binary logical operations with operands that have different kind type
parameters, the kind type parameter of the expression is the same as the larger
length of the two operands. For example, if one operand is LOGICAL(4) and the
other LOGICAL(2), the result will be LOGICAL(4).
The following table shows the resultant type for binary operations:
Table 17. Result Types for binary logical expressions
second operand
first
operand
*BYTE
LOGICAL(1)
LOGICAL(2)
LOGICAL(4)
LOGICAL(8)
*Typeless
*BYTE
*INTEGER(1)
*LOGICAL(1)
*LOGICAL(2)
*LOGICAL(4)
*LOGICAL(8)
*INTEGER(1)
LOGICAL(1)
LOGICAL(1)
LOGICAL(1)
LOGICAL(2)
LOGICAL(4)
LOGICAL(8)
LOGICAL(1)
LOGICAL(2)
LOGICAL(2)
LOGICAL(2)
LOGICAL(2)
LOGICAL(4)
LOGICAL(8)
LOGICAL(2)
LOGICAL(4)
LOGICAL(4)
LOGICAL(4)
LOGICAL(4)
LOGICAL(4)
LOGICAL(8)
LOGICAL(4)
LOGICAL(8)
LOGICAL(8)
LOGICAL(8)
LOGICAL(8)
LOGICAL(8)
LOGICAL(8)
LOGICAL(8)
*Typeless
*INTEGER(1)
*LOGICAL(1)
*LOGICAL(2)
*LOGICAL(4)
*LOGICAL(8)
*Default
Integer
Note: * Resultant types for binary logical expressions in XL Fortran
If the expression result is to be treated as a default integer but the value cannot be
represented within the value range for a default integer, the constant is promoted
to a representable kind.
Primary
The form of a primary expression is:
Chapter 6. Expressions and assignment
107

primary
defined_unary_op
defined_unary_op
is a defined unary operator. See “Extended intrinsic and defined
operations” on page 109.
Relational
A relational expression (rel_expr), when evaluated, produces a result of type logical,
and can appear wherever a logical expression can appear. It can be an arithmetic
relational expression or a character relational expression.
Arithmetic relational expressions
An arithmetic relational expression compares the values of two arithmetic
expressions. Its form is:
arith_expr1
relational_operator
arith_expr2
arith_expr1 and arith_expr2
are each an arithmetic expression. Complex expressions can only be
specified if relational_operator is .EQ., .NE., <>, ==, or /=.
relational_operator
is any of:
Relational Operator
Representing
.LT. or <
Less than
.LE. or <=
Less than or equal to
.EQ. or ==
Equal to
.NE. or *<> or /=
Not equal to
.GT. or >
Greater than
.GE. or >=
Greater than or equal to
Note: * XL Fortran relational operator.
An arithmetic relational expression is interpreted as having the logical value
.true. if the values of the operands satisfy the relation specified by the operator. If
the operands do not satisfy the specified relation, the expression has the logical
value .false..
If the types or kind type parameters of the expressions differ, their values are
converted to the type and kind type parameter of the expression (arith_expr1 +
arith_expr2) before evaluation.
Examples
IF (NODAYS .GT. 365) YEARTYPE = ’leapyear’
108
XL Fortran: Language Reference

Character relational expressions
A character relational expression compares the values of two character expressions.
Its form is:
char_expr1
relational_operator
char_expr2
char_expr1 and char_expr2
are each character expressions
relational_operator
is any of the relational operators described in “Arithmetic relational
expressions” on page 108.
For all relational operators, the collating sequence is used to interpret a character
relational expression. The character expression whose value is lower in the
collating sequence is less than the other expression. The character expressions are
evaluated one character at a time from left to right. You can also use the intrinsic
functions (LGE, LLT, and LLT) to compare character strings in the order specified
by the ASCII collating sequence. For all relational operators, if the operands are of
unequal length, the shorter is extended on the right with blanks. If both char_expr1
and char_expr2 are of zero length, they are evaluated as equal.
Even if char_expr1 and char_expr2 are multibyte characters (MBCS) in XL
Fortran, the ASCII collating sequence is still used.
Examples
IF (CHARIN .GT. ’0’ .AND. CHARIN .LE. ’9’) CHAR_TYPE = ’digit’
Extended intrinsic and defined operations
A defined operation is either a defined unary operation or a defined binary
operation. It is defined by a function and a generic interface (see “Interface blocks”
on page 160 and “Type-bound procedures (Fortran 2003)” on page 59). A defined
operation is not an intrinsic operation, although an intrinsic operator can be
extended in a defined operation. For example, to add two objects of derived type,
you can extend the meaning of the intrinsic binary operator for addition (+). If an
extended intrinsic operator has typeless operands, the operation is evaluated
intrinsically.
The operand of a unary intrinsic operation that is extended must not have a type
that is required by the intrinsic operator. Either or both of the operands of a binary
intrinsic operator that is extended must not have the types or ranks that are
required by the intrinsic operator.
The defined operator of a defined operation must be defined in a generic interface.
A defined operator is an extended intrinsic operator or has the form:
Chapter 6. Expressions and assignment
109

.
letter
.
(1)
_
(2)
$
Notes:
1
XL Fortran defined operator
2
XL Fortran defined operator
In Fortran 90 and Fortran 95, a defined operator must not contain more than 31
letters, and must not be the same as any intrinsic operator or logical literal
constant. In Fortran 2003 the letter limit for a defined operator is 63.
See “Generic interface blocks” on page 163 for details on defining and extending
operators in an interface block. See “Type-bound procedures (Fortran 2003)” on
page 59 for details on defining and extending operators that are bound to a
derived type.
How expressions are evaluated
Precedence of operators
An expression can contain more than one kind of operator. When it does, the
expression is evaluated from left to right, according to the following precedence
among operators:
1. Defined unary
2. Arithmetic
3. Character
4. Relational
5. Logical
6. Defined binary
For example, the logical expression:
L .OR. A + B .GE. C
where L is of type logical, and A, B, and C are of type real, is evaluated the same as
the logical expression below:
L .OR. ((A + B) .GE. C)
An extended intrinsic operator maintains its precedence. That is, the operator does
not have the precedence of a defined unary operator or a defined binary operator.
Summary of interpretation rules
Primaries that contain operators are combined in the following order:
1. Use of parentheses
2. Precedence of the operators
3. Right-to-left interpretation of exponentiations in a factor
110
XL Fortran: Language Reference

4. Left-to-right interpretation of multiplications and divisions in a term
5. Left-to-right interpretation of additions and subtractions in an arithmetic
expression
6. Left-to-right interpretation of concatenations in a character expression
7. Left-to-right interpretation of conjunctions in a logical term
8. Left-to-right interpretation of disjunctions in a logical disjunct
9. Left-to-right interpretation of logical equivalences in a logical expression
Evaluation of expressions
Arithmetic, character, relational, and logical expressions are evaluated according to
the following rules:
v
A variable or function must be defined at the time it is used. You must define an
integer operand with an integer value, not a statement label value. All
referenced characters in a character data object or referenced array elements in
an array or array section must be defined at the time the reference is made. All
components of a structure must be defined when a structure is referenced. A
pointer must be associated with a defined target.
Execution of an array element reference, array section reference, and substring
reference requires the evaluation of its subscript, section subscript and substring
expressions. Evaluation of any array element subscript, section subscript,
substring expression, or the bounds and stride of any array constructor
implied-DO does not affect, nor is it affected by, the type of the containing
expression. See “Expressions involving arrays” on page 96. You cannot use any
constant integer operation or floating-point operation whose result is not
mathematically defined in an executable program. If such expressions are
nonconstant and are executed, they are detected at run time. (Examples are
dividing by zero and raising a zero-valued primary to a zero-valued or
negative-valued power.) As well, you cannot raise a negative-valued primary of
type real to a real power.
v
The invocation of a function in a statement must not affect, or be affected by, the
evaluation of any other entity within the statement in which the function
reference appears. When the value of an expression is true, invocation of a
function reference in the expression of a logical IF statement or a WHERE
statement can affect entities in the statement that is executed. If a function
reference causes definition or undefinition of an actual argument of the function,
that argument or any associated entities must not appear elsewhere in the same
statement. For example, you cannot use the statements:
A(I) = FUNC1(I)
Y = FUNC2(X) + X
if the reference to FUNC1 defines I or the reference to FUNC2 defines X.
The data type of an expression in which a function reference appears does not
affect, nor is it affected by, the evaluation of the actual arguments of the
function.
v
An argument to a statement function reference must not be altered by evaluating
that reference.
Several compiler options affect the data type of the final result:
v
When you use the -qintlog compiler option, you can mix integer and logical
values in expressions and statements. The data type and kind type parameter of
the result depends on the operands and the operator involved. In general:
– For unary logical operators (.NOT.) and arithmetic unary operators (+,-):
Chapter 6. Expressions and assignment
111

Data Type of OPERAND
Data Type of RESULT of Unary Operation
BYTE
INTEGER(1)
INTEGER(n)
INTEGER(n)
LOGICAL(n)
LOGICAL(n)
Typeless
Default integer
where n represents the kind type parameter. n must not be replaced with a
logical constant even if -qintlog is on, nor by a character constant even if
-qctyplss is on, nor can it be a typeless constant. In the case of INTEGER and
LOGICAL data types, the length of the result is the same as the kind type
parameter of the operand.
– For binary logical operators (.AND., .OR., .XOR., .EQV., .NEQV.) and
arithmetic binary operators (**, *, /, +, -), the following table summarizes
what data type the result has:
second operand
first
operand
BYTE
INTEGER(y)
LOGICAL(y)
Typeless
BYTE
INTEGER(1)
INTEGER(y)
LOGICAL(y)
INTEGER(1)
INTEGER(x)
INTEGER(x)
INTEGER(z)
INTEGER(z)
INTEGER(x)
LOGICAL(x)
LOGICAL(x)
INTEGER(z)
LOGICAL(z)
LOGICAL(x)
Typeless
INTEGER(1)
INTEGER(y)
LOGICAL(y)
Default integer
Note: z is the kind type parameter of the result such that z is equal to the
greater of x and y. For example, a logical expression with a LOGICAL(4)
operand and an INTEGER(2) operand has a result of INTEGER(4).
For binary logical operators (.AND., .OR., .XOR., .EQV., .NEQV.), the result
of a logical operation between an integer operand and a logical operand or
between two integer operands will be integer. The kind type parameter of the
result will be the same as the larger kind parameter of the two operands. If
the operands have the same kind parameter, the result has the same kind
parameter.
v
When you use the -qlog4 compiler option and the default integer size is
INTEGER(4), logical results of logical operations will have type LOGICAL(4),
instead of LOGICAL(n) as specified in the table above. If you specify the -qlog4
option and the default integer size is not INTEGER(4), the results will be as
specified in the table above.
v
When you specify the -qctyplss option compiler option, XL Fortran treats
character constant expressions as Hollerith constants. If one or both operands are
character constant expressions, the data type and the length of the result are the
same as if the character constant expressions were Hollerith constants. See the
"Typeless" rows in the previous tables for the data type and length of the result.
See Summary of compiler options by functional category and Detailed descriptions of the
XL Fortran compiler options in the XL Fortran Compiler Reference for information
about compiler options.
Using BYTE data objects (IBM extension)
Data objects of type BYTE can be used wherever a LOGICAL(1), CHARACTER(1),
or INTEGER(1) data object can be used.
112
XL Fortran: Language Reference

The data types of BYTE data objects are determined by the context in which you
use them. XL Fortran does not convert them before use. For example, the type of a
named constant is determined by use, not by the initial value assigned to it.
v
When you use a BYTE data object as an operand of an arithmetic, logical, or
relational binary operator, the data object assumes:
– An INTEGER(1) data type if the other operand is arithmetic, BYTE, or a
typeless constant
– A LOGICAL(1) data type if the other operand is logical
– A CHARACTER(1) data type if the other operand is character
v
When you use a BYTE data object as an operand of the concatenation operator,
the data object assumes a CHARACTER(1) data type.
v
When you use a BYTE data object as an actual argument to a procedure with an
explicit interface, the data object assumes the type of the corresponding dummy
argument:
INTEGER(1) for an INTEGER(1) dummy argument
LOGICAL(1) for a LOGICAL(1) dummy argument
CHARACTER(1) for a CHARACTER(1) dummy argument
v
When you use a BYTE data object as an actual argument passed by reference to
an external subprogram with an implicit interface, the data object assumes a
length of 1 byte and no data type.
v
When you use a BYTE data object as an actual argument passed by value
(VALUE attribute), the data object assumes an INTEGER(1) data type.
v
When you use a BYTE data object in a context that requires a specific data type,
which is arithmetic, logical, or character, the data object assumes an
INTEGER(1), LOGICAL(1), or CHARACTER(1) data type, respectively.
v
A pointer of type BYTE cannot be associated with a target of type character, nor
can a pointer of type character be associated with a target of type BYTE.
v
When you use a BYTE data object in any other context, the data object assumes
an INTEGER(1) data type.
Intrinsic assignment
Assignment statements are executable statements that define or redefine variables
based on the result of expression evaluation.
A defined assignment is not intrinsic, and is defined by a subroutine and an
interface. See “Defined assignment” on page 167.
The general form of an intrinsic assignment is:
variable
=
expression
The shapes of variable and expression must conform unless variable is an
allocatable array. If variable is an allocatable array, and -qxlf2003=autorealloc has
been specified, then variable and expression must not be arrays of different ranks.
variable must be an array if expression is an array (see “Expressions involving
arrays” on page 96). If expression is a scalar and variable is an array, expression is
treated as an array of the same shape as variable, with every array element having
Chapter 6. Expressions and assignment
113

the same value as the scalar value of expression. variable must not be a many-one
array section (see “Vector subscripts” on page 88 for details), and neither variable
nor expression can be an assumed-size array. The types of variable and expression
must conform as follows:
Type of variable
Type of expression
Numeric
Numeric
Logical
Logical
Character
Character
Derived type
Derived type (same as variable)
In numeric assignment statements, variable and expression can specify different
numeric types and different kind type parameters. For logical assignment
statements, the kind type parameters can differ. For character assignment
statements, the length type parameters can differ.
If the length of a character variable is greater than the length of a character
expression, the character expression is extended on the right with blanks until the
lengths are equal. If the length of the character variable is less than the character
expression, the character expression is truncated on the right to match the length of
the character variable.
If variable is a pointer, it must be associated with a definable target that has type,
type parameters and shape that conform with those of expression. The value of
expression is then assigned to the target associated with variable.
Both variable and expression can contain references to any portion of variable.
If variable is an allocated allocatable variable, it is deallocated if expression
is an array of different shape or any of the corresponding length type parameter
values of variable and expression differ. If variable is or becomes an unallocated
allocatable variable, then it is allocated with each deferred type parameter equal to
the corresponding type parameters of expression, with the shape of expression, and
with each lower bound equal to the corresponding element of LBOUND(expression)
Specify -qxlf2003=autorealloc for reallocation support. See the
-qxlf2003=autorealloc option option in the XL Fortran Compiler Reference for more
information
An assignment statement causes the evaluation of expression and all expressions
within variable before assignment, the possible conversion of expression to the type
and type parameters of variable, and the definition of variable with the resulting
value. No value is assigned to variable if it is a zero-length character object or a
zero-sized array.
A derived-type assignment statement is an intrinsic assignment statement if there
is no accessible defined assignment for objects of this derived type. The derived
type expression must be of the same declared type as the variable. Each kind type
parameter of the variable must have the same value as the corresponding kind of
expression. Each length type parameter of the variable must have the same value
as the corresponding type parameter of expression unless the variable is
allocatable, and its corresponding type parameter is deferred. See “Determining
declared type for derived types” on page 67 for the rules that determine when two
structures are of the same derived type. Assignment is performed as if each
114
XL Fortran: Language Reference

component of the expression is assigned to the corresponding component of the
variable. Pointer assignment is executed for pointer components, defined
assignment is performed for each nonpointer nonallocatable component of a type
that has a defined assignment consistent with the component, and intrinsic
assignment is performed for each other nonpointer nonallocatable component. For
an allocatable component the following sequence of operations is applied:
1. If the component of variable is currently allocated, it is deallocated.
2. If the component of expression is currently allocated, the corresponding
component of variable is allocated with the same type and type parameters as
the component of expression. If it is an array, it is allocated with the same
bounds.
3. The value of the component of expression is then assigned to the corresponding
component of variable using:
v
Defined assignment if the declared type of the component has a defined
assignment consistent with the component.
v
Intrinsic assignment for the dynamic type of that component otherwise.
When variable is a subobject, the assignment does not affect the definition status or
value of other parts of the object.
Arithmetic conversion
For numeric intrinsic assignment, the value of expression may be converted to the
type and kind type parameter of variable, as specified in the following table:
Type of variable
Value Assigned
Integer
INT(expression,KIND=KIND(variable))
Real
REAL(expression,KIND=KIND(variable))
Complex
CMPLX(expression,KIND=KIND(variable))
Note: Arithmetic integer operations for INTEGER(8) data items, including
intermediate results, are performed using INTEGER(8) arithmetic in both 32-bit
and 64-bit mode. Arithmetic integer operations for INTEGER(1), INTEGER(2), and
INTEGER(4) data objects, including intermediate results, are performed using
INTEGER(4) arithmetic in 32-bit mode and INTEGER(8) arithmetic in 64-bit mode.
If an intermediate result is used in a context requiring a smaller integer size, it is
converted as required.
Character assignment
Only as much of the character expression as is necessary to define the character
variable needs to be evaluated. For example:
CHARACTER SCOTT*4, DICK*8
SCOTT = DICK
This assignment of DICK to SCOTT requires only that you have previously defined
the substring DICK(1:4). You do not have to previously define the rest of DICK
(DICK(5:8)).
BYTE assignment
If expression is of an arithmetic type, arithmetic assignment is used.
Similarly, if expression is of type character, character assignment is used, and if
Chapter 6. Expressions and assignment
115

expression is of type logical, logical assignment is used. If the expression on the
right is of type BYTE, arithmetic assignment is used.
Examples
INTEGER I(10)
LOGICAL INSIDE
REAL R,RMIN,RMAX
REAL :: A=2.3,B=4.5,C=6.7
TYPE PERSON
INTEGER(4) P_AGE
CHARACTER(20) P_NAME
END TYPE
TYPE (PERSON) EMP1, EMP2
CHARACTER(10) :: CH = ’ABCDEFGHIJ’
I = 5
! All elements of I assigned value of 5
RMIN = 28.5 ; RMAX = 29.5
R = (-B + SQRT(B**2 - 4.0*A*C))/(2.0*A)
INSIDE = (R .GE. RMIN) .AND. (R .LE. RMAX)
CH(2:4) = CH(3:5)
! CH is now ’ACDEEFGHIJ’
EMP1 = PERSON(45, ’Frank Jones’)
EMP2 = EMP1
! EMP2%P_AGE is assigned EMP1%P_AGE using arithmetic assignment
! EMP2%P_NAME is assigned EMP1%P_NAME using character assignment
END
WHERE construct
The WHERE construct masks the evaluation of expressions and assignments of
values in array assignment statements. It does this according to the value of a
logical array expression.
WHERE_construct_statement
where_body_construct
masked_ELSEWHERE_block
ELSEWHERE_block
END_WHERE_statement
WHERE_construct_statement
See “WHERE” on page 473 for syntax details.
where_body_construct
116
XL Fortran: Language Reference

where_assignment_statement
WHERE_statement
WHERE_construct
where_assignment_statement
Is an assignment_statement.
masked_ELSEWHERE_block
masked_ELSEWHERE_statement
where_body_construct
masked_ELSEWHERE_statement
Is an ELSEWHERE statement that specifies a mask_expr. See
“ELSEWHERE” on page 334 for syntax details.
ELSEWHERE_block
ELSEWHERE_statement
where_body_construct
ELSEWHERE_statement
Is an ELSEWHERE statement that does not specify a mask_expr. See
“ELSEWHERE” on page 334 for syntax details.
END_WHERE_statement
See “END (Construct)” on page 337 for syntax details.
Rules:
v
mask_expr is a logical array expression.
v
In each where_assignment_statement, the mask_expr and the variable being defined
must be arrays of the same shape.
v
A statement that is part of a where_body_construct must not be a branch target
statement. Also, ELSEWHERE, masked ELSEWHERE, and END WHERE
statements must not be branch target statements.
v
A where_assignment_statement that is a defined assignment must be an elemental
defined assignment.
v
The mask_expr on the WHERE construct statement and all corresponding masked
ELSEWHERE statements must have the same shape. The mask_expr on a nested
WHERE statement or nested WHERE construct statement must have the same
shape as the mask_expr on the WHERE construct statement of the construct in
which it is nested.
v
If a construct name appears on a WHERE construct statement, it must also
appear on the corresponding END WHERE statement. A construct name is
optional on the masked ELSEWHERE and ELSEWHERE statements in the
WHERE construct.
Chapter 6. Expressions and assignment
117

Interpreting masked array assignments
To understand how to interpret masked array assignments, you need to
understand the concepts of a control mask (mc) and a pending control mask (mp):
v
The mc is an array of type logical whose value determines which elements of an
array in a where_assignment_statement will be defined. This value is determined
by the execution of one of the following:
– a WHERE statement
– a WHERE construct statement
– an ELSEWHERE statement
– a masked ELSEWHERE statement
– an END WHERE statement
The value of mc is cumulative; the compiler determines the value using the mask
expressions of surrounding WHERE statements and the current mask
expression. Subsequent changes to the value of entities in a mask_expr have no
effect on the value of mc. The compiler evaluates the mask_expr only once for
each WHERE statement, WHERE construct statement, or masked ELSEWHERE
statement.
v
The mp is a logical array that provides information to the next masked
assignment statement at the same nesting level on the array elements not
defined by the current WHERE statement, WHERE construct statement, or
masked ELSEWHERE statement.
The following describes how the compiler interprets statements in a WHERE,
WHERE construct, masked ELSEWHERE, ELSEWHERE, or END WHERE
statement. It describes the effect on mc and mp and any further behavior of the
statements, in order of occurrence.
v
WHERE statement
– If the WHERE statement is nested in a WHERE construct, the following
occurs:
1. mc becomes mc .AND. mask_expr.
2. After the compiler executes the WHERE statement, mc has the value it had
prior to the execution of the WHERE statement.
– Otherwise, mc becomes the mask_expr.
v
WHERE construct
– If the WHERE construct is nested in another WHERE construct, the following
occurs:
1. mp becomes mc .AND. (.NOT. mask_expr).
2. mc becomes mc .AND. mask_expr.
– Otherwise:
1. The compiler evaluates the mask_expr, and assigns mc the value of that
mask_expr.
2. mp becomes .NOT. mask_expr.
v
Masked ELSEWHERE statement
The following occurs:
1. mc becomes mp.
2. mp becomes mc .AND. (.NOT. mask_expr).
3. mc becomes mc .AND. mask_expr.
v
ELSEWHERE statement
118
XL Fortran: Language Reference

The following occurs:
1. mc becomes mp. No new mp value is established.
v
END WHERE statement
After the compiler executes an END WHERE statement, mc and mp have the
values they had prior to the execution of the corresponding WHERE construct
statement.
v
where_assignment_statement
The compiler assigns the values of the expr that correspond to the true values of
mc to the corresponding elements of the variable.
If a non-elemental function reference occurs in the expr or variable of a
where_assignment_statement or in a mask_expr, the compiler evaluates the function
without any masked control; that is, it fully evaluates all of the function's
argument expressions and then it fully evaluates the function. If the result is an
array and the reference is not within the argument list of a non-elemental function,
the compiler selects elements corresponding to true values in mc for use in
evaluating the expr, variable, or mask_expr.
If an elemental intrinsic operation or function reference occurs in the expr or
variable of a where_assignment_statement or in a mask_expr, and is not within the
argument list of a non-elemental function reference, the compiler performs the
operation or evaluates the function only for the elements corresponding to true
values in mc.
If an array constructor appears in a where_assignment_statement or in a mask_expr,
the compiler evaluates the array constructor without any masked control and then
executes the where_assignment_statement or evaluates the mask_expr.
The execution of a function reference in the mask_expr of a WHERE statement is
allowed to affect entities in the where_assignment_statement. Execution of an END
WHERE has no effect.
The following example shows how control masks are updated. In this example,
mask1, mask2, mask3, and mask4 are conformable logical arrays, mc is the control
mask, and mp is the pending control mask. The compiler evaluates each mask
expression once.
Sample code (with statement numbers shown in the comments):
WHERE (mask1)
! W1
WHERE (mask2)
! W2
...
! W3
ELSEWHERE (mask3)
! W4
...
! W5
END WHERE
! W6
ELSEWHERE (mask4)
! W7
...
! W8
ELSEWHERE
! W9
...
! W10
END WHERE
! W11
The compiler sets control and pending control masks as it executes each statement,
as shown below:
Statement W1
mc = mask1
mp = .NOT. mask1
Chapter 6. Expressions and assignment
119

Statement W2
mp = mask1 .AND. (.NOT. mask2)
mc = mask1 .AND. mask2
Statement W4
m = mask1 .AND. (.NOT. mask2)
c
m
= mask1 .AND. (.NOT. mask2)
p
.AND. (.NOT. mask3)
m = mask1 .AND. (.NOT. mask2)
c
.AND. mask3
Statement W6
m = mask1
c
m
= .NOT. mask1
p
Statement W7
m = .NOT. mask1
c
m
= (.NOT. mask1) .AND. (.NOT.
p
mask4)
m = (.NOT. mask1) .AND. mask4
c
Statement W9
m = (.NOT. mask1) .AND. (.NOT.
c
mask4)
Statement W11
m = 0
c
m
= 0
p
The compiler uses the values of the control masks set by statements W2, W4, W7,
and W9 when it executes the respective where_assignment_statements W3, W5, W8,
and W10.
Migration Tip:
Simplify logical evaluation of arrays
FORTRAN 77 source:
INTEGER A(10,10),B(10,10)
.
.
.
DO I=1,10
DO J=1,10
IF (A(I,J).LT.B(I,J)) A(I,J)=B(I,J)
END DO
END DO
END
Fortran 90 or Fortran 95 source:
INTEGER A(10,10),B(10,10)
.
.
.
WHERE (A.LT.B) A=B
END
Examples
REAL, DIMENSION(10) :: A,B,C,D
WHERE (A>0.0)
A = LOG(A)
! Only the positive elements of A
!
are used in the LOG calculation.
B = A
! The mask uses the original array A
120
XL Fortran: Language Reference

!
instead of the new array A.
C = A / SUM(LOG(A)) ! A is evaluated by LOG, but
!
the resulting array is an
!
argument to a non-elemental
!
function. All elements in A will
!
be used in evaluating SUM.
END WHERE
WHERE (D>0.0)
C = CSHIFT(A, 1)
! CSHIFT applies to all elements in array A,
! and the array element values of D determine
! which CSHIFT expression determines the
! corresponding element values of C.
ELSEWHERE
C = CSHIFT(A, 2)
END WHERE
END
The following example shows an array constructor in a WHERE construct
statement and in a masked ELSEWHERE mask_expr:
CALL SUB((/ 0, -4, 3, 6, 11, -2, 7, 14 /))
CONTAINS
SUBROUTINE SUB(ARR)
INTEGER ARR(:)
INTEGER N
N = SIZE(ARR)
! Data in array ARR at this point:
!
! A = | 0 -4 3 6 11 -2 7 14 |
WHERE (ARR < 0)
ARR = 0
ELSEWHERE (ARR < ARR((/(N-I, I=0, N-1)/)))
ARR = 2
END WHERE
! Data in array ARR at this point:
!
! A = | 2 0 3 2 11 0 7 14 |
END SUBROUTINE
END
The following example shows a nested WHERE construct statement and masked
ELSEWHERE statement with a where_construct_name:
INTEGER :: A(10, 10), B(10, 10)
...
OUTERWHERE: WHERE (A < 10)
INNERWHERE: WHERE (A < 0)
B = 0
ELSEWHERE (A < 5) INNERWHERE
B = 5
ELSEWHERE INNERWHERE
B = 10
END WHERE INNERWHERE
ELSEWHERE OUTERWHERE
B = A
END WHERE OUTERWHERE
...
Chapter 6. Expressions and assignment
121

FORALL construct
The FORALL construct performs assignment to groups of subobjects, especially
array elements.
Unlike the WHERE construct, FORALL performs assignment to array elements,
array sections, and substrings. Also, each assignment within a FORALL construct
need not be conformable with the previous one. The FORALL construct can
contain nested FORALL statements, FORALL constructs, WHERE statements, and
WHERE constructs.
-qxlf2003=autorealloc does not apply to FORALL constructs. No reallocation of
allocatable variables occurs during assignment statements inside a FORALL
construct.
The INDEPENDENT directive specifies that the left and right sides of the
assignments inside a FORALL construct do not overlap.
FORALL_construct_statement
forall_body
END_FORALL_statement
FORALL_construct_statement
See “FORALL (construct)” on page 360 for syntax details.
END_FORALL_statement
See “END (Construct)” on page 337 for syntax details.
forall_body
is one or more of the following statements or constructs:
forall_assignment
WHERE statement (see “WHERE” on page 473)
WHERE construct (see “WHERE construct” on page 116)
FORALL statement (see “FORALL” on page 357)
FORALL construct
forall_assignment
is either assignment_statement or pointer_assignment_statement
Any procedures that are referenced in a forall_body, including one referenced by a
defined operation, defined assignment, or finalization must be pure.
If a FORALL statement or construct is nested within a FORALL construct, the
inner FORALL statement or construct cannot redefine any index_name used in the
outer FORALL construct.
Although no atomic object can be assigned to, or have its association status
changed in the same statement more than once, different assignment statements
122
XL Fortran: Language Reference

within the same FORALL construct can redefine or reassociate an atomic object.
Also, each WHERE statement and assignment statement within a WHERE
construct must follow these restrictions.
If a FORALL_construct_name is specified, it must appear in both the FORALL
statement and the END FORALL statement. Neither the END FORALL statement
nor any statement within the FORALL construct can be a branch target statement.
Interpreting the FORALL construct
1. From the FORALL Construct statement, evaluate the subscript and stride
expressions for each forall_triplet_spec in any order. All possible pairings of
index_name values form the set of combinations. For example, given the
statement:
FORALL (I=1:3,J=4:5)
The set of combinations of I and J is:
{(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)}
The -1 and -qnozerosize compiler options do not affect this step.
2. Evaluate the scalar_mask_expr (from the FORALL Construct statement) for the
set of combinations, in any order, producing a set of active combinations (those
that evaluated to .TRUE.). For example, if the mask (I+J.NE.6) is applied to the
above set, the set of active combinations is:
{(1,4),(2,5),(3,4),(3,5)}
3. Execute each forall_body statement or construct in order of appearance. For the
set of active combinations, each statement or construct is executed completely
as follows:
assignment_statement
Evaluate, in any order, all values in the right-hand side expression and
all subscripts, strides, and substring bounds in the left-hand side
variable for all active combinations of index_name values.
Assign, in any order, the computed expression values to the
corresponding variable entities for all active combinations of index_name
values. In a forall_assignment if variable is allocatable,
-qxlf2003=autorealloc will not cause variable to be deallocated and/or
allocated.
INTEGER, DIMENSION(50) :: A,B,C
INTEGER :: X,I=2,J=49
FORALL (X=I:J)
A(X)=B(X)+C(X)
C(X)=B(X)-A(X) ! All these assignments are performed after the
! assignments in the preceding statement
END FORALL
END
pointer_assignment_statement
Determine, in any order, what will be the targets of the pointer
assignment, and evaluate all subscripts, strides, and substring bounds
in the pointer for all active combinations of index_name values. If a
target is not a pointer, determination of the target does not include
evaluation of its value. Pointer assignment never requires the value of
the righthand side to be determined.
Associate, in any order, all targets with the corresponding pointer
entities for all active combinations of index_name values.
Chapter 6. Expressions and assignment
123

WHERE statement or construct
Evaluate, in any order, the control mask and pending control mask for
each WHERE statement, WHERE construct statement, ELSEWHERE
statement, or masked ELSEWHERE statement each active combination
of index_name values, producing a refined set of active combinations for
that statement, as described in “Interpreting masked array
assignments” on page 118. For each active combination, the compiler
executes the assignment(s) of the WHERE statement, WHERE construct
statement, or masked ELSEWHERE statement for those values of the
control mask that are true for that active combination. The compiler
executes each statement in a WHERE construct in order, as described
previously.
INTEGER I(100,10), J(100), X
FORALL (X=1:100, J(X)>0)
WHERE (I(X,:)<0)
I(X,:)=0
! Assigns 0 to an element of I along row X
! only if element value is less than 0 and value
! of element in corresponding column of J is
ELSEWHERE
! greater than 0.
I(X,:)=1
END WHERE
END FORALL
END
FORALL statement or construct
Evaluate, in any order, the subscript and stride expressions in the
forall_triplet_spec_list for the active combinations of the outer FORALL
statement or construct. The valid combinations are the Cartesian
product of combination sets of the inner and outer FORALL constructs.
The scalar_mask_expr determines the active combinations for the inner
FORALL construct. Statements and constructs for these active
combinations are executed.
! Same as FORALL (I=1:100,J=1:100,I.NE.J) A(I,J)=A(J,I)
INTEGER A(100,100)
OUTER: FORALL (I=1:100)
INNER: FORALL (J=1:100,I.NE.J)
A(I,J)=A(J,I)
END FORALL INNER
END FORALL OUTER
END
Data pointer assignment
Pointer assignment statement causes a pointer to become associated with a target
or causes the pointer's association status to become disassociated or undefined.
124
XL Fortran: Language Reference

data_pointer_object
=>
target
(1)
(bounds_spec_list)
(2)
(bounds_remapping_list)
Notes:
1
Fortran 2003
2
Fortran 2003
data_pointer_object
must have the POINTER attribute.
target
is a variable or expression. If it is a variable, it must have the TARGET
attribute (or be a subobject of such an object) or the POINTER attribute. If
it is an expression, it must yield a value that has the POINTER attribute.
If target is not unlimited polymorphic, data_pointer_object must be type
compatible with it and the corresponding kind type parameters must be
equal. If target is unlimited polymorphic, data_pointer_object must be
unlimited polymorphic, of sequence derived type, or of a type with the
BIND attribute.
bounds_spec
lower_bound
:
lower_bound
is a scalar integer expression.
bounds_remapping
lower_bound : upper_bound
lower_bound
is a scalar integer expression.
upper_bound
is a scalar integer expression.
A target must not be an array section with a vector subscript, or a whole
assumed-size array.
The size, bounds, and shape of the target of a disassociated array pointer are
undefined. No part of such an array can be defined or referenced, although the
Chapter 6. Expressions and assignment
125

array can be the argument of an intrinsic inquiry function that is inquiring about
association status, argument presence, or a property of the type or type
parameters.
A pointer of type byte can only be associated with a target of type byte,
INTEGER(1), or LOGICAL(1).
F2008
If a data_pointer_object is an array with the CONTIGUOUS attribute, the
target must be contiguous. F2008
If target is a disassociated pointer, all nondeferred type parameters of the declared
type of data_pointer_object that correspond to nondeferred type parameters of target
shall have the same values as the corresponding type parameters of target.
Otherwise, all nondeferred type parameters of the declared type of
data_pointer_object must have the same values as the corresponding type
parameters of target.
If data_pointer_object has nondeferred type parameters that correspond to deferred
type parameters of target, target must not be a pointer with undefined association
status.
If the data_pointer_object is not polymorphic and the target is polymorphic with
dynamic type that differs from its declared type, the assignment target is the
ancestor component of target that has the type of data_pointer_object. Otherwise, the
assignment target is target.
If data_pointer_object is polymorphic, it assumes the dynamic type of target. If
data_pointer_object is of sequence derived type or a type with the BIND attribute,
the dynamic type of target must be that type.
If you specify bounds_spec_list, the number of bounds in the list must be equal to
the rank of data_pointer_object.
If you specify either a bounds_spec_list or a bounds_remapping_list, you must not use
a SUBSCRIPTORDER directive on the pointer
If you specify a bounds_remapping_list:
v
F2008
The target must be simply contiguous or of rank one. F2008
v
The target must not be a diassociated or undefined pointer, and the size of the
target must not be less than the size of the data_pointer_object.
v
The number of bounds_remappings in the list must be equal to the rank of
data_pointer_object.
v
The lower bound of each dimension of the data_pointer_object becomes equal to
the lower_bound you specify in the corresponding bounds_remapping.
v
The upper bound of each dimension of the data_pointer_object becomes equal to
the upper_bound you specify in the corresponding bounds_remapping.
v
The extent of each dimension of the data_pointer_object is equal to the upper
bound of that dimension, minus the lower bound of that dimension, plus 1.
v
The elements of the target of data-pointer-object, in array element order, are the
first SIZE (data-pointer-object) elements of the target, after any
SUBSCRIPTORDER directives affect the target.
126
XL Fortran: Language Reference

If you specify a bounds_spec_list:
v
The number of bounds_spec shall equal the rank of data_pointer_object.
v
If you specify a bounds_spec_list, then the lower_bound of each dimension of the
data_pointer_object becomes equal to the lower_bound in the corresponding
bounds_spec.
v
The extent of each dimension of the data_pointer_object is equal to the extent of
the corresponding dimension of the target.
v
The upper bound of each dimension of the data_pointer_object is equal to the lower
bound of that dimension, plus the extent of that dimension, minus 1.
If neither bounds_remapping_list nor bounds_spec_list are specified:
During pointer assignment of an array pointer, the lower bound of each dimension
is the result of the LBOUND intrinsic function applied to the corresponding
dimension of the target. For an array section or array expression that is not a
whole array or a structure component, the lower bound is 1. The upper bound of
each dimension is the result of the UBOUND intrinsic function applied to the
corresponding dimension of the target.
Any previous association between a data_pointer_object and a target is broken. If
target is not a pointer, data_pointer_object becomes associated with target. If target is
itself an associated pointer, data_pointer_object is associated with the target of target.
If target is a pointer with an association status of disassociated or undefined,
data_pointer_object acquires the same status. If target of a pointer assignment is an
allocatable object, it must be allocated.
Pointer assignment for a pointer structure component can also occur via execution
of a derived-type intrinsic assignment statement or a defined assignment
statement.
Examples
REAL, DIMENSION(10) :: A,B,C,D
WHERE (A>0.0)
A = LOG(A)
! Only the positive elements of A
!
are used in the LOG calculation.
B = A
! The mask uses the original array A
!
instead of the new array A.
C = A / SUM(LOG(A)) ! A is evaluated by LOG, but
!
the resulting array is an
!
argument to a non-elemental
!
function. All elements in A will
!
be used in evaluating SUM.
END WHERE
WHERE (D>0.0)
C = CSHIFT(A, 1)
! CSHIFT applies to all elements in array A,
! and the array element values of D determine
! which CSHIFT expression determines the
! corresponding element values of C.
ELSEWHERE
C = CSHIFT(A, 2)
END WHERE
END
The following example shows an array constructor in a WHERE construct
statement and in a masked ELSEWHERE mask_expr:
Chapter 6. Expressions and assignment
127

CALL SUB((/ 0, -4, 3, 6, 11, -2, 7, 14 /))
CONTAINS
SUBROUTINE SUB(ARR)
INTEGER ARR(:)
INTEGER N
N = SIZE(ARR)
! Data in array ARR at this point:
!
! A = | 0 -4 3 6 11 -2 7 14 |
WHERE (ARR < 0)
ARR = 0
ELSEWHERE (ARR < ARR((/(N-I, I=0, N-1)/)))
ARR = 2
END WHERE
! Data in array ARR at this point:
!
! A = | 2 0 3 2 11 0 7 14 |
END SUBROUTINE
END
The following example shows a nested WHERE construct statement and masked
ELSEWHERE statement with a where_construct_name:
INTEGER :: A(10, 10), B(10, 10)
...
OUTERWHERE: WHERE (A < 10)
INNERWHERE: WHERE (A < 0)
B = 0
ELSEWHERE (A < 5) INNERWHERE
B = 5
ELSEWHERE INNERWHERE
B = 10
END WHERE INNERWHERE
ELSEWHERE OUTERWHERE
B = A
END WHERE OUTERWHERE
...
Related information
v
See “ALLOCATE” on page 277 for an alternative form of associating a pointer
with a target.
v
F2008
Contiguity F2008
Procedure pointer assignment (Fortran 2003)
The procedure pointer assignment statement causes a procedure pointer to become
associated with a target or causes the procedure pointer's association status to
become disassociated or undefined.
proc_pointer_object
=>
proc_target
proc_target
is an expression or a procedure name. If proc_target is an expression, it
must be a function that returns a procedure pointer. If proc_target is a
128
XL Fortran: Language Reference

procedure name, it must be the name of an external procedure, a module
procedure, a dummy procedure, an intrinsic procedure that can be passed
as an actual argument, or another procedure pointer.
F2008
proc_target
can also be the name of an internal procedure. F2008
proc_target must
not be an elemental procedure.
proc_pointer_object
is a procedure pointer.
If proc_target is not a procedure pointer, proc_pointer_object becomes associated with
proc_target. If proc_target is a procedure pointer and is associated with a procedure,
proc_pointer_object becomes associated with the same procedure. If proc_target is a
pointer with an association status of disassociated or undefined, proc_pointer_object
acquires the same status.
If the proc_pointer_object has an explicit interface, its characteristics must be the
same as proc_target except that proc_target can be pure even if proc_pointer_object is
not. If the characteristics of proc_pointer_object or proc_target are such that an
explicit interface is required, both proc_pointer_object and proc_target must have an
explicit interface.
If proc_pointer_object has an implicit interface and is explicitly typed or referenced
as a function, proc_target must be a function. If proc_pointer_object has an implicit
interface and is referenced as a subroutine, proc_target must be a subroutine.
If proc_target and proc_pointer_object are functions, they must have the same type;
corresponding type parameters must either be both deferred or have the same
value.
If proc_target is a specific procedure name that is also a generic name, only the
specific procedure is associated with proc_pointer_object.
Related information::
v
“PROCEDURE declaration (Fortran 2003)” on page 417
Integer pointer assignment (IBM extension)
Integer pointer variables can be:
v
Used in integer expressions
v
Assigned values as absolute addresses
v
Assigned the address of a variable using the LOC intrinsic function. (Objects of
derived type and structure components must be of sequence-derived type when
used with the LOC intrinsic function.)
Note: The XL Fortran compiler does not use the size of an object as a multiplier
in an arithmetic expression where an integer pointer is an operand.
Examples
INTEGER INT_TEMPLATE
POINTER (P,INT_TEMPLATE)
INTEGER MY_ARRAY(10)
DATA MY_ARRAY/1,2,3,4,5,6,7,8,9,10/
INTEGER, PARAMETER :: WORDSIZE=4
P = LOC(MY_ARRAY)
PRINT *, INT_TEMPLATE
! Prints ’1’
P = P + 4;
! Add 4 to reach next element
Chapter 6. Expressions and assignment
129

!
because arithmetic is byte-based
PRINT *, INT_TEMPLATE
! Prints ’2’
P = LOC(MY_ARRAY)
DO I = 1,10
PRINT *,INT_TEMPLATE
P = P + WORDSIZE
! Parameterized arithmetic is suggested
END DO
END
130
XL Fortran: Language Reference

Chapter 7. Execution control
You can control the execution of a program sequence using constructs. Constructs
contain statement blocks and other executable statements that can alter the normal
execution sequence. This section contains detailed descriptions of the following
constructs:
v
ASSOCIATE
v
F2008
BLOCK F2008
v
DO
v
DO WHILE
v
IF
v
SELECT CASE
v
SELECT TYPE
Detailed syntax diagrams for the constructs in this section can be found by
following the links to the associated statements.
For nesting to occur, a construct must be wholly contained within another
construct. If a statement specifies a construct name, it applies to that construct. If
the statement does not specify a construct name, the statement applies to the
innermost construct in which it appears.
In addition to constructs, XL Fortran provides branching as a method for
transferring control from one statement to another statement in the same scoping
unit.
Statement blocks
A statement block consists of a sequence of zero or more executable statements,
executable constructs, FORMAT statements, or DATA statements embedded in
another executable construct and are treated as a single unit.
In the same program, you can not transfer control from outside the statement block
to within the statement block. You can transfer control within the statement block,
or from within the statement block to outside the block. For example, you can have
a GO TO statement branching to a label that is within a statement block. You
cannot branch into a statement block from a GO TO statement outside the
statement block.
ASSOCIATE Construct (Fortran 2003)
The ASSOCIATE construct creates an association between an identifier and a
variable, or the value of an expression, during the execution of that construct. The
identifier you specify in an ASSOCIATE construct becomes an associating entity.
You can create multiple associating entities inside a single ASSOCIATE construct.
© Copyright IBM Corp. 1996, 2012
131

Syntax
ASSOCIATE_statement
ASSOCIATE_statement_block
END_ASSOCIATE_statement
ASSOCIATE_statement
See “ASSOCIATE (Fortran 2003)” on page 281 for syntax details
END_ASSOCIATE_statement
See “END (Construct)” on page 337 for syntax details
Execution of an ASSOCIATE construct causes execution of an
ASSOCIATE_statement followed by the ASSOCIATE_statement_block. During
execution of that block, the construct creates an association with an identifier and
the corresponding selector. The associating entity assumes the declared type and
type parameters of the selector. The name of the associating entity is an associate
name. For further information on associate names, see “Associate names” on page
144.
Examples
The following example uses the ASSOCIATE construct as a shorthand for a
complex expression and renames an existing variable, MYREAL. After the end of
the ASSOCIATE construct, any change within the construct to the value of the
associating entity that associates with MYREAL is reflected.
PROGRAM ASSOCIATE_EXAMPLE
REAL :: MYREAL, X, Y, THETA, A
X = 0.42
Y = 0.35
MYREAL = 9.1
THETA = 1.5
A = 0.4
ASSOCIATE ( Z => EXP(-(X**2+Y**2)) * COS(THETA), V => MYREAL)
PRINT *, A+Z, A-Z, V
V = V * 4.6
END ASSOCIATE
PRINT *, MYREAL
END PROGRAM ASSOCIATE_EXAMPLE
The expected output is.
0.4524610937 0.3475389183 9.100000381
41.86000061
132
XL Fortran: Language Reference

BLOCK construct (Fortran 2008)
The BLOCK construct defines an executable block that can contain declarations.
Syntax
BLOCK_statement
specification_part
statement_block
END_BLOCK_statement
BLOCK_statement
See “BLOCK (Fortran 2008)” on page 287 for syntax details.
END_BLOCK_statement
See “END (Construct)” on page 337 for syntax details.
To terminate execution of a BLOCK construct, you can use an EXIT statement. To
branch out of a BLOCK construct, you can use a GOTO (unconditional) statement.
A local variable of a BLOCK construct within a pure subprogram cannot have the
SAVE attribute.
COMMON, EQUIVALENCE, IMPLICIT, INTENT, NAMELIST, OPTIONAL,
statement function, and VALUE statements are not allowed in the specification
part of the BLOCK construct.
A common block name cannot be specified in a saved entity list in the BLOCK
construct.
You can transfer control within a BLOCK construct, or from inside to outside of a
BLOCK construct. You can transfer control from outside to inside of a BLOCK
construct only when the control is returned from a procedure call inside the
BLOCK construct.
Examples
Example 1: The following example shows that a BLOCK construct can be specified
with an optional name and nested within another BLOCK construct.
PROGRAM foo
INTEGER :: a
add1 : BLOCK
INTEGER :: res1
res1 = a + 1
! The BLOCK statement has no BLOCK_construct_name
Chapter 7. Execution control
133

BLOCK
INTEGER :: res2
res2 = res1 + 1
END BLOCK
! The END BLOCK statement must have the same BLOCK construct name ’add1’
END BLOCK add1
END PROGRAM foo
Example 2: You cannot transfer control from outside a BLOCK construct to inside
the BLOCK construct, except for the return from a procedure call inside the
construct. For example:
PROGRAM main
INTEGER :: a
a = 5
BLOCK
INTEGER :: b
b = a + 2
! Program control is returned from a procedure call inside the BLOCK construct
CALL Sub(b)
END BLOCK
END PROGRAM main
SUBROUTINE Sub(B)
INTEGER :: b
b = b * b
PRINT *, b
END SUBROUTINE Sub
Example 3: The following example shows how an unconditional GOTO statement
is used to exit a BLOCK construct.
PROGRAM foo
BLOCK
INTEGER :: i
i = 1
! Before the BLOCK construct is exited, local pointers are
! nullified, local allocatables are deallocated, and local
! finalizable objects are finalized.
GOTO 10
i = i + 1
END BLOCK
10
PRINT *, i
END PROGRAM foo
Related information
v
“BLOCK (Fortran 2008)” on page 287
v
“SAVE” on page 439
v
“Pure procedures” on page 198
v
“EXIT” on page 352
v
“GO TO (unconditional)” on page 369
DO construct
The DO construct specifies the repeated execution of a statement block. Such a
repeated block is called a loop.
The iteration count of a loop can be determined at the beginning of execution of
the DO construct, unless it is infinite.
134
XL Fortran: Language Reference

You can curtail a specific iteration with the CYCLE statement, and the EXIT
statement terminates the loop.
DO_statement
statement_block
END_DO_statement
terminal_statement
DO_statement
See “DO” on page 324 for syntax details
END_DO_statement
See “END (Construct)” on page 337 for syntax details
terminal_statement
is a statement that terminates the DO construct. See below.
If you specify a DO construct name on the DO statement, you must terminate the
construct with an END DO statement with the same construct name. Conversely, if
you do not specify a DO construct name on the DO statement, and you terminate
the DO construct with an END DO statement, you must not have a DO construct
name on the END DO statement.
The terminal statement
The terminal statement must follow the DO statement and must be executable. See
Chapter 11, “Statements and attributes,” on page 271 for a listing of statements that
can be used as the terminal statement. If the terminal statement of a DO construct
is a logical IF statement, it can contain any executable statement compatible with
the restrictions on a logical IF statement.
If you specify a statement label in the DO statement, you must terminate the DO
construct with a statement that is labeled with that statement label.
A labeled DO statement must be terminated with an END DO statement that has
a matching statement label. A DO statement with no label must be terminated with
an unlabeled END DO statement.
Nested, labeled DO and DO WHILE constructs can share the same terminal
statement if the terminal statement is labeled, and if it is not an END DO
statement.
Range of a DO construct
The range of a DO construct consists of all the executable statements following the
DO statement, up to and including the terminal statement. In addition to the rules
governing the range of constructs, you can only transfer control to a shared
terminal statement from the innermost sharing DO construct.
Chapter 7. Execution control
135

Active and inactive DO constructs
A DO construct is either active or inactive. Initially inactive, a DO construct
becomes active only when its DO statement is executed. Once active, the DO
construct becomes inactive only when:
v
Its iteration count becomes zero.
v
A RETURN statement occurs within the range of the DO construct.
v
Control is transferred to a statement outside the range of the DO construct.
v
A subroutine invoked from within the DO construct returns, through an
alternate return specifier, to a statement that is outside the range of the DO
construct.
v
An EXIT statement that belongs to the DO construct executes.
v
An EXIT statement or a CYCLE statement that is within the range of the DO
construct, but belongs to an outer DO or DO WHILE construct, executes.
v
A STOP statement executes or the program stops for any other reason.
When a DO construct becomes inactive, the DO variable retains the last value
assigned to it.
Executing a DO statement
An infinite DO does not have an iteration count limit or a termination condition.
If the loop is not an infinite DO, the DO statement includes an initial parameter, a
terminal parameter, and an optional increment.
1. The initial parameter, m1, the terminal parameter, m2, and the increment, m3, are
established by evaluating the DO statement expressions (a_expr1, a_expr2, and
a_expr3, respectively). Evaluation includes, if necessary, conversion to the type
of the DO variable according to the rules for arithmetic conversion. (See
“Arithmetic conversion” on page 115.) If you do not specify a_expr3, m3 has a
value of 1. m3 must not have a value of zero.
2. The DO variable becomes defined with the value of the initial parameter (m1).
3. The iteration count is determined by the expression:
MAX (INT ( (m - m + m ) / m ), 0)
2
1
3
3
Note that the iteration count is 0 whenever:
m > m and m > 0, or
1
2
3
m < m and m < 0
1
2
3
The iteration count cannot be calculated if the DO variable is missing. This is
referred to as an infinite DO construct.
The iteration count cannot exceed 2**31 - 1 for integer variables of kind 1,
2, or 4, and cannot exceed 2**63 - 1 for integer variables of kind 8. The count
becomes undefined if an overflow or underflow situation arises during the
calculation.
At the completion of the DO statement, loop control processing begins.
Loop control processing
Loop control processing determines if further execution of the range of the DO
construct is required. The iteration count is tested. If the count is not zero, the first
statement in the range of the DO construct begins execution. If the iteration count
is zero, the DO construct becomes inactive. If, as a result, all of the DO constructs
sharing the terminal statement of this DO construct are inactive, normal execution
136
XL Fortran: Language Reference

continues with the execution of the next executable statement following the
terminal statement. However, if some of the DO constructs sharing the terminal
statement are active, execution continues with incrementation processing of the
innermost active DO construct.
DO execution range
The range of a DO construct includes all statements within the statement block.
These statements execute until reaching the terminal statement. A DO variable
must not become redefined or undefined during execution of the range of a DO
construct, and only becomes redefined through incremental processing.
Terminal statement execution
Execution of the terminal statement occurs as a result of the normal execution
sequence, or as a result of transfer of control, subject to the restriction that you
cannot transfer control into the range of a DO construct from outside the range.
Unless execution of the terminal statement results in a transfer of control,
execution continues with incrementation processing.
Incrementation processing
1. The DO variable, the iteration count, and the increment of the active DO
construct whose DO statement was most recently executed, are selected for
processing.
2. The value of the DO variable is increased by the value of m3.
3. The iteration count is decreased by 1.
4. Execution continues with loop control processing of the same DO construct
whose iteration count was decremented.
Migration Tip:
v
Use EXIT, CYCLE, and infinite DO statements instead of a GOTO statement.
FORTRAN 77 source
I = 0
J = 0
20
CONTINUE
I = I + 1
J = J + 1
PRINT *, I
IF (I.GT.4) GOTO 10
! Exiting loop
IF (J.GT.3) GOTO 20
! Iterate loop immediately
I = I + 2
GOTO 20
10
CONTINUE
END
Fortran 90/95/2003 source:
I = 0 ; J = 0
DO
I = I + 1
J = J + 1
PRINT *, I
IF (I.GT.4) EXIT
IF (J.GT.3) CYCLE
I = I + 2
END DO
END
Chapter 7. Execution control
137

Examples
INTEGER :: SUM=0
OUTER: DO
INNER: DO
READ (5,*) J
IF (J.LE.I) THEN
PRINT *, ’VALUE MUST BE GREATER THAN ’, I
CYCLE INNER
END IF
SUM=SUM+J
IF (SUM.GT.500) EXIT OUTER
IF (SUM.GT.100) EXIT INNER
END DO INNER
SUM=SUM+I
I=I+10
END DO OUTER
PRINT *, ’SUM =’,SUM
END
DO WHILE construct
The DO WHILE construct specifies the repeated execution of a statement block for
as long as the scalar logical expression specified in the DO WHILE statement is
true. You can curtail a specific iteration with the CYCLE statement, and the EXIT
statement terminates the loop.
DO_WHILE_statement
statement_block
END_DO_statement
terminal_statement
DO_WHILE_statement
See “DO WHILE” on page 325 for syntax details
END_DO_statement
See “END (Construct)” on page 337 for syntax details
terminal_stmt
is a statement that terminates the DO WHILE construct. See “The terminal
statement” on page 135 for details.
The rules applicable to the DO construct names and ranges, active and inactive
DO constructs, and terminal statements also apply to the DO WHILE construct.
Examples
I=10
TWO_DIGIT: DO WHILE ((I.GE.10).AND.(I.LE.99))
J=J+I
READ (5,*) I
END DO TWO_DIGIT
END
138
XL Fortran: Language Reference

IF construct
The IF construct selects no more than one of its statement blocks for execution.
Block_IF_statement
statement_block
ELSE_IF_block
ELSE_block
END_IF_statement
Block_IF_statement
See “IF (block)” on page 371 for syntax details.
END_IF_statement
See “END (Construct)” on page 337 for syntax details.
ELSE_IF_block
ELSE_IF_statement
statement_block
ELSE_IF_statement
See “ELSE IF” on page 333 for syntax details.
ELSE_block
ELSE_statement
statement_block
ELSE_statement
See “ELSE” on page 333 for syntax details.
Chapter 7. Execution control
139

The scalar logical expressions in an IF construct (that is, the block IF and ELSE IF
statements) are evaluated in the order of their appearance until a true value, an
ELSE statement, or an END IF statement is found:
v
If a true value or an ELSE statement is found, the statement block immediately
following executes, and the IF construct is complete. The scalar logical
expressions in any remaining ELSE IF statements or ELSE statements of the IF
construct are not evaluated.
v
If an END IF statement is found, no statement blocks execute, and the IF
construct is complete.
If the IF construct name is specified, it must appear on the IF statement and END
IF statement, and optionally on any ELSE IF or ELSE statements.
Examples
! Get a record (containing a command) from the terminal
DO
WHICHC: IF (CMD .EQ. ’RETRY’) THEN
! named IF construct
IF (LIMIT .GT. FIVE) THEN
! nested IF construct
!
Print retry limit exceeded
CALL STOP
ELSE
CALL RETRY
END IF
ELSE IF (CMD .EQ. ’STOP’) THEN WHICHC
! ELSE IF blocks
CALL STOP
ELSE IF (CMD .EQ. ’ABORT’) THEN
CALL ABORT
ELSE WHICHC
! ELSE block
!
Print unrecognized command
END IF WHICHC
END DO
END
CASE construct
The CASE construct has a concise syntax for selecting, at most, one of a number of
statement blocks for execution. The case selector of each CASE statement is
compared to the expression of the SELECT CASE statement.
SELECT_CASE_statement
CASE_statement_block
END_SELECT_statement
SELECT_CASE_statement
defines the case expression that is to be evaluated. See “SELECT CASE” on
page 441 for syntax details.
140
XL Fortran: Language Reference

END_SELECT_statement
terminates the CASE construct. See “END (Construct)” on page 337 for
syntax details.
CASE_statement_block
CASE_statement
statement_block
CASE_statement
defines the case selector, which is a value, set of values, or default case, for
which the subsequent statement block is executed. See “CASE” on page
294 for syntax details.
In the construct, each case value must be of the same type as the case expression.
The CASE construct executes as follows:
1. The case expression is evaluated. The resulting value is the case index.
2. The case index is compared to the case_selector of each CASE statement.
3. If a match occurs, the statement block associated with that CASE statement is
executed. No statement block is executed if no match occurs. (See “CASE” on
page 294.)
4. Execution of the construct is complete and control is transferred to the
statement after the END SELECT statement.
A CASE construct contains zero or more CASE statements that can each specify a
value range, although the value ranges specified by the CASE statements cannot
overlap.
A default case_selector can be specified by one of the CASE statements. A default
CASE_statement_block can appear anywhere in the CASE construct; it can appear at
the beginning or end, or among the other blocks.
If a construct name is specified, it must appear on the SELECT CASE statement
and END SELECT statement, and optionally on any CASE statements.
You can only branch to the END SELECT statement from within the CASE
construct. A CASE statement cannot be a branch target.
Chapter 7. Execution control
141

Migration Tip:
Use CASE in place of block IFs.
FORTRAN 77 source
IF (I .EQ.3) THEN
CALL SUBA()
ELSE IF (I.EQ. 5) THEN
CALL SUBB()
ELSE IF (I .EQ. 6) THEN
CALL SUBC()
ELSE
CALL OTHERSUB()
ENDIF
END
Fortran 90/95/2003 source:
SELECTCASE(I)
CASE(3)
CALL SUBA()
CASE(5)
CALL SUBB()
CASE(6)
CALL SUBC()
CASE DEFAULT
CALL OTHERSUB()
END SELECT
END
Examples
ZERO: SELECT CASE(N)
CASE DEFAULT ZERO
OTHER: SELECT CASE(N) ! start of CASE construct OTHER
CASE(:-1)
SIGNUM = -1
! this statement executed when n≤-1
CASE(1:) OTHER
SIGNUM = 1
END SELECT OTHER
! end of CASE construct OTHER
CASE (0)
SIGNUM = 0
END SELECT ZERO
END
SELECT TYPE construct (Fortran 2003)
The SELECT TYPE construct selects, at most, one of its constituent blocks for
execution. The selection is based on the dynamic type of an expression. A name is
associated with the expression, in the same way as for the ASSOCIATE construct.
142
XL Fortran: Language Reference

SELECT_TYPE_statement
type_guard_statement_block
END_SELECT_statement
SELECT_TYPE_statement
defines the selector expression that is to be evaluated and optionally
associates a name (an associate name) with the selector expression. If you
do not specify an associate name in the SELECT_TYPE_statement, the
selector expression must be a named variable. The name of this variable
becomes the associate name. Execution of a SELECT TYPE construct
whose selector is not a variable causes the selector expression to be
evaluated. See “SELECT TYPE (Fortran 2003)” on page 442 for syntax
details.
type_guard_statement_block
type_guard_statement
statement_block
type_guard_statement
The dynamic type of the selector expression is compared to the type
specified in the type_guard_statement. If the rules for type comparison
succeed for a particular type_guard_statement the subsequent statement
block is executed. A type guard statement cannot be a branch target
statement. It is permissible to branch to an end-select-type-stmt only from
within its SELECT TYPE construct. See “Type Guard (Fortran 2003)” on
page 462 for syntax details. The other attributes of the associating entity
are described in “Associate names” on page 144.
END_SELECT_statement
terminates the SELECT TYPE construct. See “END (Construct)” on page
337 for syntax details.
The block to be executed is selected as follows:
1. If a TYPE IS type guard statement matches the selector, the block following
that statement is executed. A TYPE IS type guard statement matches the
selector if the dynamic type and kind type parameter values of the selector are
the same as those specified by the statement.
2. Otherwise, if exactly one CLASS IS type guard statement matches the selector,
the block following that statement is executed.A CLASS IS type guard
statement matches the selector if the dynamic type of the selector is an
extension of the type specified by the statement, and the kind type parameter
Chapter 7. Execution control
143

values specified by the statement are the same as the corresponding type
parameter values of the dynamic type of the selector.
3. Otherwise, if several CLASS IS type guard statements match the selector, one
of these statements must specify a type that is an extension of all the types
specified in the others; the block following that statement is executed.
4. Otherwise, if there is a CLASS DEFAULT type guard statement, the block
following that statement is executed.
Within the block following a TYPE IS type guard statement, the associating entity
is not polymorphic, has the type named in the type guard statement, and has the
type parameters of the selector.
Within the block following a CLASS IS type guard statement, the associating
entity is polymorphic and has the declared type named in the type guard
statement. The type parameters of the associating entity are those of the type
specified in the CLASS IS type guard statement.
Within the block following a CLASS DEFAULT type guard statement, the
associating entity is polymorphic and has the same declared type as the selector.
The type parameters of the associating entity are those of the declared type of the
selector.
Examples
TYPE :: POINT
REAL :: X, Y
END TYPE POINT
TYPE, EXTENDS(POINT) :: POINT_3D
REAL :: Z
END TYPE POINT_3D
TYPE, EXTENDS(POINT) :: COLOR_POINT
INTEGER :: COLOR
END TYPE COLOR_POINT
TYPE(POINT), TARGET :: P
TYPE(POINT_3D), TARGET :: P3
TYPE(COLOR_POINT), TARGET :: C
CLASS(POINT), POINTER :: P_OR_C
P_OR_C => C
SELECT TYPE ( A => P_OR_C )
CLASS IS ( POINT )
! "CLASS ( POINT ) :: A" implied here
PRINT *, A%X, A%Y ! This block gets executed
TYPE IS ( POINT_3D )
! "TYPE ( POINT_3D ) :: A" implied here
PRINT *, A%X, A%Y, A%Z
END SELECT
Associate names
Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the
same rank as its associated selector. The lower bound of each dimension is the
result of the intrinsic function LBOUND applied to the corresponding dimension
of selector. The upper bound of each dimension is one less than the sum of the
lower bound and the extent.
144
XL Fortran: Language Reference

The associating entity has the ASYNCHRONOUS, INTENT, or VOLATILE
attribute if the selector is a variable with the same attribute. The associating entity
has the TARGET attribute if the selector has the TARGET or POINTER attribute.
If the associating entity is polymorphic, it assumes the dynamic type and type
parameter values of the selector. If the selector has the OPTIONAL attribute, then
it must be present.
F2008
If the selector is contiguous, then the associating entity
is contiguous. F2008
If the selector is not permitted to appear in a variable definition context or is an
array with a vector subscript, the associate name must not appear in a variable
definition context.
Related information
v
F2008
Contiguity F2008
Branching
You can also alter the normal execution sequence by branching. A branch transfers
control from one statement to a labeled branch target statement in the same
scoping unit. A branch target statement can be any executable statement except a
CASE, ELSE, ELSE IF, or type guard statement.
The following statements can be used for branching:
v
Assigned GO TO
transfers program control to an executable statement, whose statement label is
designated in an ASSIGN statement. See “GO TO (assigned)” on page 367 for
syntax details.
v
Computed GO TO
transfers control to possibly one of several executable statements. See “GO TO
(computed)” on page 368 for syntax details.
v
Unconditional GO TO
transfers control to a specified executable statement. See “GO TO
(unconditional)” on page 369 for syntax details.
v
Arithmetic IF
transfers control to one of three executable statements, depending on the
evaluation of an arithmetic expression. See “IF (arithmetic)” on page 370 for
syntax details.
The following input/output specifiers can also be used for branching:
v
the END= end-of-file specifier
transfers control to a specified executable statement if an endfile record is
encountered (and no error occurs) in a READ statement.
v
the ERR= error specifier
transfers control to a specified executable statement in the case of an error. You
can specify this specifier in the BACKSPACE, ENDFILE, REWIND, CLOSE,
OPEN, READ, WRITE, and INQUIRE statements.
v
the EOR= end-of-record specifier
transfers control to a specified executable statement if an end-of-record condition
is encountered (and no error occurs) in a READ statement.
Chapter 7. Execution control
145

CONTINUE statement
Execution of a CONTINUE statement has no effect. For more information refer to
“CONTINUE” on page 314.
STOP statement
Execution of a STOP statement causes normal termination of execution of the
program. For more information, see “STOP” on page 447.
ERROR STOP statement (Fortran 2008)
Execution of an ERROR STOP statement causes error termination of execution of
the program. For more information, see ERROR STOP.
146
XL Fortran: Language Reference

Chapter 8. Program units and procedures
Scope
A program unit consists of a set of nonoverlapping scoping units. A scoping unit is
that portion of a program unit that has its own scope boundaries. It is one of the
following:
v
A derived-type definition.
v
F2008
A BLOCK construct (not including any nested BLOCK constructs,
derived-type definitions, and interface bodies within it). F2008
v
A procedure interface body (not including any derived-type definitions and
interface bodies within it).
v
A program unit, module subprogram, or internal subprogram (not including
derived-type definitions,
F2008
BLOCK constructs F2008
, interface bodies,
module subprograms, and internal subprograms within it).
A host scoping unit is the scoping unit that immediately surrounds another
scoping unit. For example, in the following diagram, the host scoping unit of the
internal function C is the scoping unit of the main program A. Host association is
the method by which an internal subprogram, module subprogram, or
derived-type definition accesses names from its host.
Using the IMPORT
statement, an interface body can also access names from its host.
PROGRAM A
INTEGER A1
CONTAINS
SUBROUTINE B
scope of
REAL B1
variable B1
scope of
END SUBROUTINE B
variable A1
(not including
scope of B1
FUNCTION C ( )
scope of
and C1)
REAL C1
variable C1
END FUNCTION C
END PROGRAM A
Entities that have scope are:
v
A name (see below)
v
A label (local entity)
v
An external input/output unit number (global entity)
v
An operator symbol. Intrinsic operators are global entities, while defined
operators are local entities.
v
An assignment symbol (global entity)
If the scope is an executable program, the entity is called a global entity. If the
scope is a scoping unit, the entity is called a local entity. If the scope is a statement
or part of a statement, the entity is called a statement entity. If the scope is a
construct, the entity is called a construct entity.
© Copyright IBM Corp. 1996, 2012
147

The scope of a name
Global entity
Global entities are:
v
Program units
v
External procedures
v
Common blocks
v
CRITICAL lock_names
v
Entities that have binding labels.
If a name identifies a global entity,
it cannot be the same as any binding
label in the same executable program,
and it cannot be used to identify
any other global entity in the same executable program unless that entity is an
intrinsic module.
See Conventions for XL Fortran external names in the XL Fortran Optimization and
Programming Guide for details on restrictions on names of global entities.
Local entity
Entities of the following classes are local entities of the scoping unit in which they
are defined:
1. Named variables that are not statement entities, module procedures, named
constants, derived-type definitions, construct names, generic identifiers,
statement functions, internal subprograms, dummy procedures, intrinsic
procedures, or namelist group names.
2. Type parameters, components and bindings of a derived type definition where
each derived type definition has its own class.
A derived type parameter name, including all that are inherited from its parent
type, has the same scope as the derived type being defined.
A component name has the same scope as the type of which it is a component.
You can specify a name within a component designator of a structure of that
type, or as a component keyword in a structure constructor for that type.
A binding name of a procedure has the same scope as the type. It can appear
only as the binding-name in a procedure reference. A generic binding for which
the generic-spec is not a generic-name has a scope that consists of all scoping
units in which an entity of that type is accessible
If the derived type is defined in a module and contains the PRIVATE
statement, the type and its components are accessible in any of the defining
module's subprograms by host association. If the accessing scoping unit
accesses this type by use association, that scoping unit, and any scoping unit
that accesses the entities of that scoping unit by host association can access the
derived-type definition, and only those components with the PUBLIC attribute.
3. Argument keywords (in a separate class for each procedure with an explicit
interface).
A dummy argument name in an internal procedure, module procedure, or
procedure interface block has a scope as an argument keyword of the scoping
unit of its host. As an argument keyword, it may appear only in a procedure
reference for the procedure of which it is a dummy argument. If the procedure
or procedure interface block is accessible in another scoping unit by use
association or host association, the argument keyword is accessible for
procedure references for that procedure in that scoping unit.
148
XL Fortran: Language Reference

In a scoping unit, a name that identifies a local entity of one class may be used to
identify a local entity of another class. Such a name must not be used to identify
another local entity of the same class, except in the case of generic names. A name
that identifies a global entity in a scoping unit cannot be used to identify a local
entity of class 1 in that scoping unit, except for a common block name or the name
of an external function. Components and bindings of a record structure are local
entities of class 2. A separate class exists for each type.
A name declared to be a derived type can have the same name as another
local entity of class 1 of that scoping unit that is not a derived-type. In this case,
the structure constructor for that type is not available in that scope. Similarly, a
local entity of class 1 is accessible through host association or use association, even
if there is another local entity of class 1 accessible in that scope, if:
v
one of the two entities is a derived type and the other is not; and
v
in the case of host association, the derived type is accessible via host association.
For example, given a module M, a program unit P, and an internal subprogram
or module subprogram S nested in P, if you have an entity named T1 declared
in M that is accessed by use association in P (or in S), you can declare another
entity in P (or in S, respectively) with the same name T1, so long as one of the
two is a derived type. If you have an entity named T2 accessible in P, and an
entity named T2 declared in S, then the T2 accessible in P is accessible in S if the
T2 in P is a derived type. If the T2 in P was not a derived type, it would not be
accessible in S if S declared another T2 (of derived type or not).
The structure constructor for that type will not be available in that scope. A local
entity of class 1 in a scope that has the same name as a derived type accessible in
that scope must be explicitly declared in a declaration statement in that scope.
If two local entities of class 1, one of which is a derived type, are accessible in a
scoping unit, any PUBLIC or PRIVATE statement that specifies the name of the
entities applies to both entities. If the name of the entities is specified in a
VOLATILE statement, the entity or entities declared in that scope have the volatile
attribute. If the two entities are public entities of a module, any rename on a USE
statement that references the module and specifies the names of the entities as the
use_name applies to both entities.
A common block name in a scoping unit can be the name of any local entity other
than a named constant or intrinsic procedure. The name is recognized as the
common block entity only when the name is delimited by slashes in a BIND,
COMMON, VOLATILE, or SAVE statement. If it is not, the name identifies the
local entity. An intrinsic procedure name can be the name of a common block in a
scoping unit that does not reference the intrinsic procedure. In this case, the
intrinsic procedure name is not accessible.
An external function name can also be the function result name. This is the only
way that an external function name can also be a local entity.
If a scoping unit contains a local entity of class 1 with the same name as an
intrinsic procedure, the intrinsic procedure is not accessible in that scoping unit.
An interface block generic name can be the same as any of the procedure names in
the interface block, or the same as any accessible generic name. It can be the same
as any generic intrinsic procedure. See “Resolution of procedure references” on
page 196 for details.
Chapter 8. Program units and procedures
149

Statement and construct entities
Statement entities: The following items are statement entities:
v
Name of a statement function dummy argument.
SCOPE: Scope of the statement in which it appears.
v
Name of a variable that appears as the DO variable of an implied-DO in a
DATA statement or array constructor.
SCOPE: Scope of the implied-DO list.
Except for a common block name or scalar variable name, the name of a global
entity or local entity of class 1 that is accessible in the scoping unit of a statement
or construct must not be the name of a statement or construct entity of that
statement or construct. Within the scope of a statement or construct entity, another
statement or construct entity must not have the same name.
The name of a variable that appears as a dummy argument in a statement function
statement has a scope of the statement in which it appears. It has the type and
type parameters that it would have if it were the name of a variable in the scoping
unit that includes the statement function.
If the name of a global or local entity accessible in the scoping unit of a statement
or construct is the same as the name of a statement or construct entity in that
statement or construct, the name is interpreted within the scope of the statement or
construct entity as that of the statement or construct entity. Elsewhere in the
scoping unit, including parts of the statement or construct outside the scope of the
statement or construct entity, the name is interpreted as that of the global or local
entity.
If a statement or construct entity has the same name as an accessible name that
denotes a variable, constant, or function, the statement or construct entity has the
same type and type parameters as the variable, constant or function. Otherwise,
the type of the statement or construct entity is determined through the implicit
typing rules in effect. If the statement entity is the DO variable of an implied-DO
in a DATA statement, the variable cannot have the same name as an accessible
named constant.
Statement and construct entity: The following is a statement and/or construct
entity:
v
Name of a variable that appears as an index_name in a FORALL statement or
FORALL construct.
– SCOPE: Scope of the FORALL statement or construct.
The only attributes held by the FORALL statement or construct entity are the type
and type parameters that it would have if it were the name of a variable in the
scoping unit that includes the FORALL. It is type integer.
Except for a common block name or a scalar variable name, a name that identifies
a global entity or a local entity of class 1, accessible in the scoping unit of a
FORALL statement or construct, must not be the same as the index_name. Within
the scope of a FORALL construct, a nested FORALL statement or FORALL
construct must not have the same index_name.
If the name of a global or local entity accessible in the scoping unit of a FORALL
statement or construct is the same as the index_name, the name is interpreted
150
XL Fortran: Language Reference

within the scope of the FORALL statement or construct as that of the index_name.
Elsewhere in the scoping unit, the name is interpreted as that of the global or local
entity.
Construct entity (Fortran 2003): The following is a construct entity:
v
The associate name of an ASSOCIATE construct.
– SCOPE: Scope of the block of the ASSOCIATE construct.
v
The associate name of a SELECT TYPE construct.
– SCOPE: (Separate) Scope of each block of the SELECT TYPE construct.
F2008
v
An entity that is explicitly declared in the specification part of a BLOCK
construct, other than only in ASYNCHRONOUS and VOLATILE statements.
– SCOPE: Scope of the BLOCK construct.
F2008
If the name of a global or local entity accessible in the scoping unit of an
ASSOCIATE or SELECT TYPE construct is the same as an associate name, the
name is interpreted within the blocks of an ASSOCIATE or SELECT TYPE
construct as that of the associate name. Elsewhere in the scoping unit, the name is
interpreted as the global and local entities.
Examples
F2008
Example 1: In the following example, the ASYNCHRONOUS statement does not
define a new variable a. It merely gives variable a, defined in the outer scope, the
ASYNCHRONOUS attribute for the duration of the BLOCK construct scope.
PROGRAM foo
INTEGER :: a
BLOCK
! This a is the same as the a declared outside the BLOCK construct.
! It merely gives variable a, defined in the outer scope, the ASYNCHRONOUS
! attribute for the duration of the BLOCK construct scope.
ASYNCHRONOUS :: a
END BLOCK
END PROGRAM foo
Example 2: In the following example, variable a is a construct entity for the
BLOCK construct, because there is no a declared outside the BLOCK construct.
PROGRAM foo
BLOCK
! This a is a local entity since there is no a in the outer scope.
INTEGER, ASYNCHRONOUS :: a
END BLOCK
END PROGRAM foo
F2008
Chapter 8. Program units and procedures
151

Association
Association exists if the same data can be identified with different names in the
same scoping unit, or if the same data can be accessed in different scoping units of
the same executable program. See “Argument association” on page 184 for
information on argument association in procedures and functions.
Host association
Host association allows an internal subprogram, module subprogram, interface
body, or derived-type definition to access named entities that exist in its host. In
interface bodies, entities cannot be accessed by host association unless they are
made accessible by an IMPORT statement Accessed entities have the same
attributes and are known by the same name as they are in the host.
A name that is specified with the EXTERNAL attribute is a global name. Any
entity in the host scoping unit that has this name as its nongeneric name is
inaccessible by that name and by host association.
The following list of entities are local within a scoping unit when declared or
initialized in that scoping unit:
v
A variable name in a COMMON statement or initialized in a DATA statement
v
An array name in a DIMENSION statement
v
A name of a derived type
v
An object name in a type declaration, EQUIVALENCE, POINTER,
ALLOCATABLE, SAVE, TARGET, AUTOMATIC, integer POINTER, STATIC,
or VOLATILE statement
Note: VOLATILE is controlled by compiler option -qxlf2003. For more
information see the XL Fortran Compiler Reference.
v
A named constant in a PARAMETER statement
v
A namelist group name in a NAMELIST statement
v
A generic interface name or a defined operator
v
An intrinsic procedure name in an INTRINSIC statement
v
A function name in a FUNCTION statement, statement function statement, or
type declaration statement
v
A result name in a FUNCTION statement or an ENTRY statement
v
A subroutine name in a SUBROUTINE statement
v
An entry name in an ENTRY statement
v
A dummy argument name in a FUNCTION, SUBROUTINE, ENTRY, or
statement function statement
v
The name of a named construct
v
The name of an entity declared by an interface body or PROCEDURE
declaration statement
Entities in the host scoping unit that have the same name as a local entity are not
accessible by host association.
A local entity must not be referenced or defined before the DATA statement when:
1. An entity is local to a scoping unit only because it is initialized in a DATA
statement, and
2. An entity in the host has the same name as this local entity.
152
XL Fortran: Language Reference

If a derived-type name of a host is inaccessible, structures of that type or
subobjects of such structures are still accessible.
If a subprogram gains access to a pointer (or integer pointer) by host association,
the pointer association that exists at the time the subprogram is invoked remains
current within the subprogram. This pointer association can be changed within the
subprogram. The pointer association remains current when the procedure finishes
executing, except when this causes the pointer to become undefined, in which case
the association status of the host-associated pointer becomes undefined. For more
information on events that cause definition and undefinition of variables, see
“Definition status of variables” on page 19.
The host scoping unit of an internal or module subprogram can contain the same
use-associated entities.
Host associated entities are known by the same name and have the same attributes
as in the host, except that an accessed entity may have the VOLATILE or
ASYNCHRONOUS attribute even if the host entity does not. In an internal or
module procedure, if a variable that is accessible via host association is specified in
an ASYNCHRONOUS or VOLATILE statement, that host variable is given the
ASYNCHRONOUS or VOLATILE attribute in the local scope.
Note: VOLATILE is controlled by compiler option -qxlf2003.
Examples
SUBROUTINE MYSUB
TYPE DATES
! Define DATES
INTEGER START
INTEGER END
END TYPE DATES
CONTAINS
INTEGER FUNCTION MYFUNC(PNAME)
TYPE PLANTS
TYPE (DATES) LIFESPAN
! Host association of DATES
CHARACTER(10) SPECIES
INTEGER PHOTOPER
END TYPE PLANTS
END FUNCTION MYFUNC
END SUBROUTINE MYSUB
Related information
v
XL Fortran Compiler Reference
.
Use association
Use association occurs when a scoping unit accesses the entities of a module with
the USE statement. Use-associated entities can be renamed for use in the local
scoping unit. The association is in effect for the duration of the executable
program. See “USE” on page 463 for details.
MODULE M
CONTAINS
SUBROUTINE PRINTCHAR(X)
CHARACTER(20) X
Chapter 8. Program units and procedures
153

PRINT *, X
END SUBROUTINE
END MODULE
PROGRAM MAIN
USE M
! Accesses public entities of module M
CHARACTER(20) :: NAME=’George’
CALL PRINTCHAR(NAME)
! Calls PRINTCHAR from module M
END
Fortran 2003
A USE associated entity may have the ASYNCHRONOUS or VOLATILE attribute
in the local scoping unit even if the associated module entity does not.
Note: VOLATILE is controlled by compiler option -qxlf2003. For more
information: XL Fortran Compiler Reference.
End of Fortran 2003
Construct Association
Fortran 2003
Construct association establishes an association between each selector and the
corresponding associate name of the construct. Each associate name remains
associated with the corresponding selector throughout the execution of the
executed block. Within the block, each selector is known by and may be accessed
by the corresponding associate name. Construct termination terminates the
association as well. See the ASSOCIATE and SELECT TYPE constructs for more
information.
End of Fortran 2003
Pointer association
A target that is associated with a pointer can be referenced by a reference to the
pointer. This is called pointer association.
A pointer always has an association status:
Associated
v
The ALLOCATE statement successfully allocates the pointer, which has
not been subsequently disassociated or undefined.
ALLOCATE (P(3))
v
The pointer is pointer-assigned to a target that is currently associated or
has the TARGET attribute and, if allocatable, is currently allocated.
P => T
Disassociated
v
The pointer is nullified by a NULLIFY statement or by the -qinit=f90ptr
option. See -qinit in the XL Fortran Compiler Reference.
NULLIFY (P)
v
The pointer is an ultimate component of an object with default
initialization specified for the component and:
– a procedure is invoked with this object as an actual argument
corresponding to a nonpointer, nonallocatable dummy argument with
INTENT(OUT),
154
XL Fortran: Language Reference

– a procedure with the object as an unsaved nonpointer, nonallocatable
local object that is not accessed by use or host association is invoked,

this object is allocated, or

F2008
execution enters a BLOCK construct, and the object is an
unsaved, nonpointer, nonallocatable, local variable of the BLOCK
construct,
TYPE DT
INTEGER, POINTER :: POINT => NULL()
END TYPE
BLOCK
TYPE(DT) DT1
! DT1%POINT becomes disassociated here
END BLOCK
F2008
v
The pointer is successfully deallocated.
DEALLOCATE (P)
v
The pointer is pointer-assigned to a disassociated pointer.
NULLIFY (Q); P => Q
Undefined
v
Initially (unless the -qinit=f90ptr option is specified)
v
The pointer is an ultimate component of an object, default
initialization is not specified for the component, and a procedure is
invoked with this object as an actual argument corresponding to a
dummy argument with INTENT(OUT), or a procedure is invoked with
the pointer as an actual argument corresponding to a pointer dummy
argument with INTENT(OUT).
v
If it is pointer-assigned to a pointer whose association status is
undefined.
v
If its target was deallocated other than through the pointer.
POINTER P(:), Q(:)
ALLOCATE (P(3))
Q => P
DEALLOCATE (Q)
! Deallocate target of P through Q.
! P is now undefined.
END
v
If the execution of a RETURN or END statement causes the pointer's
target to become undefined.
v
After the execution of a RETURN or END statement in a procedure
where the pointer was declared or accessed, except for objects described
in item 4 under “Events causing undefinition” on page 22.
v
F2008
The target of the pointer becomes undefined when execution
exits a BLOCK construct.
INTEGER, POINTER :: POINT
BLOCK
INTEGER, TARGET :: TARG = 2
POINT => TARG
END BLOCK
! point becomes undefined here
F2008
v
F2008
The pointer is an unsaved, local pointer of a BLOCK construct,
and the execution of the BLOCK construct is complete. F2008
Chapter 8. Program units and procedures
155

Definition status and association status
The definition status of a pointer is that of its target. If a pointer is associated with
a definable target, the definition status of the pointer can be defined or undefined
according to the rules for a variable.
If the association status of a pointer is disassociated or undefined, the pointer must
not be referenced or deallocated. Whatever its association status, a pointer can
always be nullified, allocated or pointer-assigned. When it is allocated, its
definition status is undefined. When it is pointer-assigned, its association and
definition status are determined by its target. So, if a pointer becomes associated
with a target that is defined, the pointer becomes defined.
Integer pointer association (IBM extension)
An integer pointer that is associated with a data object can be used to reference the
data object. This is called integer pointer association.
Integer pointer association can only occur in the following situations:
v
An integer pointer is assigned the address of a variable:
POINTER (P,A)
P=LOC(B)
! A and B become associated
v
Multiple pointees are declared with the same integer pointer:
POINTER (P,A), (P,B)
! A and B are associated
v
Multiple integer pointers are assigned the address of the same variable or the
address of other variables that are storage associated:
POINTER (P,A), (Q,B)
P=LOC(C)
Q=LOC(C)
! A, B, and C become associated
v
An integer pointer variable that appears as a dummy argument is assigned the
address of another dummy argument or member of a common block:
POINTER (P,A)
.
.
CALL SUB (P,B)
.
.
SUBROUTINE SUB (P,X)
POINTER (P,Y)
P=LOC(X)
! Main program variables A
!
and B become associated.
Program units, procedures, and subprograms
A program unit is a sequence of one or more lines, organized as statements,
comments, and directives. Specifically, a program unit can be:
v
The main program
v
A module
v
A block data program unit
v
An external function subprogram
v
An external subroutine subprogram
An executable program is a collection of program units consisting of one main
program and any number of external subprograms, modules, and block data
program units.
156
XL Fortran: Language Reference

A subprogram can be invoked by a main program or by another subprogram to
perform a particular activity. When a procedure is invoked, the referenced
subprogram is executed.
An external or module subprogram can contain multiple ENTRY statements. The
subprogram defines a procedure for the SUBROUTINE or FUNCTION statement,
as well as one procedure for each ENTRY statement.
An external procedure is defined either by an external subprogram or by a
program unit in a programming language other than Fortran.
Main programs, external procedures, block data program units, common blocks,
entities with binding labels, and modules are global entities. Internal and module
procedures are local entities.
Internal procedures
External subprograms, module subprograms, and main programs can have internal
subprograms, whether the internal subprograms are functions or subroutines, as
long as the internal subprograms follow the CONTAINS statement.
An internal procedure is defined by an internal subprogram. Internal subprograms
cannot appear in other internal subprograms. A module procedure is defined by a
module subprogram or an entry in a module subprogram. Internal procedures and
module procedures are the same as external procedures except that:
v
The name of the internal procedure or module procedure is not a global entity
v
An internal subprogram must not contain an ENTRY statement
v
The internal procedure name must not be an argument associated with a
dummy procedure
v
The internal subprogram or module subprogram has access to host entities by
host association
v
The BIND attribute is not allowed on an internal procedure
Chapter 8. Program units and procedures
157

Migration Tip:
Turn your external procedures into internal subprograms or put them into modules. The
explicit interface provides type checking.
FORTRAN 77 source
PROGRAM MAIN
INTEGER A
A=58
CALL SUB(A)
! A must be passed
END
SUBROUTINE SUB(A)
INTEGER A,B,C
! A must be redeclared
C=A+B
END
Fortran 90/95/2003 source:
PROGRAM MAIN
INTEGER :: A=58
CALL SUB
CONTAINS
SUBROUTINE SUB
INTEGER B,C
C=A+B
! A is accessible by host association
END SUBROUTINE
END
Interface concepts
The interface of a procedure determines the form of the procedure reference. The
interface consists of:
v
The characteristics of the procedure
v
The name of the procedure
v
The name and characteristics of each dummy argument
v
The generic identifiers of the procedure, if any
The characteristics of a procedure:
v
Distinguishing the procedure as a subroutine or a function
v
Distinguishing each dummy argument either as a data object, dummy
procedure, or alternate return specifier
The characteristics of a dummy data object are its declared type, type parameters
(if any), shape, intent, whether it is optional, allocatable,
polymorphic,
a pointer, a target, or has the
VALUE
or
F2008
CONTIGUOUS F2008
attribute. Any dependence on other objects for
type parameter or array bound determination is a characteristic. If a shape, size,
or character length is assumed or deferred, it is a characteristic.
The characteristics of a dummy procedure are the explicitness of its interface, its
procedure characteristics (if the interface is explicit), and whether it is optional.
v
If the procedure is a function, it specifies the characteristics of the result value,
specifically:
– Declared type
– Any type parameters
– Rank
158
XL Fortran: Language Reference

– Whether the result value is a pointer
– Whether the result value is a procedure pointer
– Whether the result value is allocatable.

Whether the result value is polymorphic

F2008
Whether the result value is contiguous. F2008
For nonpointer, nonallocatable array results, its shape is a characteristic. Any
dependence on other objects for type parameters or array bound determination
is a characteristic. If the length of a character object is assumed, this is a
characteristic. If type parameters of a function result are deferred, which
parameters are deferred is a characteristic.
v
Determine whether the procedure is PURE or ELEMENTAL.
v
Determine if the procedure has the BIND attribute.
If a procedure is accessible in a scoping unit, it has an interface that is either
explicit or implicit in that scoping unit. The rules are:
Entity
Interface
Dummy procedure
Explicit in a scoping unit if an interface block exists or
is accessible, or if an explicit interface is specified by a
PROCEDURE declaration statement. Implicit in all
other cases.
External subprogram
Explicit in a scoping unit other than its own if an
interface block exists or is accessible, or if an explicit
interface is specified by a PROCEDURE declaration
statement. Implicit in all other cases.
Recursive procedure with a result Explicit in the subprogram's own scoping unit.
clause
Module procedure
Always explicit.
Internal procedure
Always explicit.
Generic procedure
Always explicit.
Intrinsic procedure
Always explicit.
Statement function
Always implicit.
Internal subprograms cannot appear in an interface block or in a PROCEDURE
declaration statement.
A procedure must not have more than one accessible interface in a scoping unit.
The interface of a statement function cannot be specified in an interface block or in
a PROCEDURE declaration statement.
Explicit interface
A procedure must have an explicit interface in any of the following cases:
1. A reference to the procedure appears
v
with an argument keyword
v
as a defined assignment (for subroutines only)
v
in an expression as a defined operator (for functions only)
v
as a reference by its generic name
v
in a context that requires it to be pure
2. The procedure has
Chapter 8. Program units and procedures
159

v
a dummy argument that has the
ALLOCATABLE,
OPTIONAL, POINTER, TARGET or
VALUE
attributes
v
a dummy argument that is polymorphic
v
an array-valued result (for functions only)
v
a result whose length type parameter is neither assumed nor constant (for
character functions only)
v
a pointer or allocatable result (for functions only)
v
a dummy argument that is an assumed-shape array
3. The procedure is elemental.
4.
The procedure has the BIND attribute.
Implicit interface
A procedure has an implicit interface if its interface is not fully known; that is, it
has no explicit interface.
Interface blocks
The interface block allows you to specify an explicit interface for external and
dummy procedures. You can also use an interface block to define generic
identifiers. An interface body in an interface block contains the explicit specific
interface for an existing external procedure or dummy procedure. You can also
specify the interface for a procedure using a procedure statement.
INTERFACE_statement
FUNCTION_interface_body
SUBROUTINE_interface_body
PROCEDURE_statement
END_INTERFACE_statement
INTERFACE_statement
See “INTERFACE” on page 389 for syntax details
END_INTERFACE_statement
See “END INTERFACE” on page 340 for syntax details
PROCEDURE_statement
See “PROCEDURE” on page 416 for syntax details
FUNCTION_interface_body
160
XL Fortran: Language Reference

FUNCTION_statement
specification_part
end_function_statement
SUBROUTINE_interface_body
SUBROUTINE_statement
specification_part
end_subroutine_statement
FUNCTION_statement, SUBROUTINE_statement
For syntax details, see “FUNCTION” on page 364 and “SUBROUTINE” on
page 449.
specification_part
is a sequence of statements from the statement groups numbered 2 , 3
and 5 in “Order of statements and execution sequence” on page 14.
end_function_statement, end_subroutine_statement
For syntax details of both statements, see “END” on page 335.
In an interface body or with a procedure declaration statement, you specify all the
characteristics of the procedure or abstract interface. See “Interface concepts” on
page 158. The characteristics must be consistent with those specified in the
subprogram definition, except that:
1. dummy argument names may be different.
2. you do not have to indicate that a procedure is pure, even if the subprogram
that defines it is pure.
3. you can associate a pure actual argument with a dummy procedure that is not
pure.
4. when you associate an intrinsic elemental procedure with a dummy procedure,
the dummy procedure does not have to be elemental.
The specification_part of an interface body can contain statements that specify
attributes or define values for data objects that do not determine characteristics of
the procedure. Such specification statements have no effect on the interface.
Interface blocks do not specify the characteristics of module procedures, whose
characteristics are defined in the module subprogram definitions.
Chapter 8. Program units and procedures
161

An interface body cannot contain ENTRY statements, DATA statements, FORMAT
statements, statement function statements, or executable statements. You can
specify an entry interface by using the entry name as the procedure name in an
interface body.
An interface body does not access named entities by host association unless you
specify the
IMPORT
statement. It is treated as if it had a host
with the default implicit rules. See “Determining Type” on page 17 for a discussion
of the implicit rules.
An interface block can be abstract, generic or specific. A generic interface block
must specify a generic specification in the INTERFACE statement, while an
abstract or specific interface block must not specify such a generic specification.
See “INTERFACE” on page 389 for details.
The interface bodies within an abstract or specific interface block can contain
interfaces for both subroutines and functions.
A generic name specifies a single name to reference all of the procedures in the
interface block. At most, one specific procedure is invoked each time there is a
procedure reference with a generic name.
The PROCEDURE statement is allowed only if the interface block has a generic
specification and is contained in a scoping unit where each procedure name is
accessible.
A procedure name used in a PROCEDURE statement must not have been
previously specified in any MODULE PROCEDURE statement in any accessible
interface block with the same generic identifier.
For an interface to a non-Fortran subprogram, the dummy argument list
in the FUNCTION or SUBROUTINE statement can explicitly specify the passing
method. See “Dummy arguments” on page 183 for details.
Examples
MODULE M
CONTAINS
SUBROUTINE S1(IARG)
IARG = 1
END SUBROUTINE S1
SUBROUTINE S2(RARG)
RARG = 1.1
END SUBROUTINE S2
SUBROUTINE S3(LARG)
LOGICAL LARG
LARG = .TRUE.
END SUBROUTINE S3
END
USE M
INTERFACE SS
SUBROUTINE SS1(IARG,JARG)
END SUBROUTINE
MODULE PROCEDURE S1,S2,S3
END INTERFACE
CALL SS(II)
! Calls subroutine S1 from M
CALL SS(I,J)
! Calls subroutine SS1
END
162
XL Fortran: Language Reference

SUBROUTINE SS1(IARG,JARG)
IARG = 2
JARG = 3
END SUBROUTINE
You can always reference a procedure through its specific interface. If a generic
interface exists for a procedure, the procedure can also be referenced through the
generic interface.
Within an interface body, if a dummy argument is intended to be a dummy
procedure, it must have the EXTERNAL attribute or there must be an interface for
the dummy argument.
Generic interface blocks
In an INTERFACE statement, a generic interface block must specify one of the
following:
v
a generic name
v
defined operator
v
defined assignment
v
a derived-type input/output generic specification
The generic name is a single name with which to reference all of the procedures
specified in the interface block. It can be the same as any accessible generic name,
or any of the procedure names in the interface block.
If two or more generic interfaces that are accessible in a scoping unit have the
same local name, they are interpreted as a single generic interface.
Unambiguous generic procedure references
When making a reference to a generic procedure, only one specific procedure is
invoked. This section includes rules that ensure a generic reference is
unambiguous.
If two procedures in the same scoping unit both define assignment or both have
the same defined operator and the same number of arguments, you must specify a
dummy argument that corresponds by position in the argument list to a dummy
argument of the other that is distinguishable from it.
Two dummy
arguments are distinguishable if neither is a subroutine and neither is
TKR-compatible with the other.
Within a scoping unit, if two procedures have the same dtio_generic_spec, their dtv
arguments must be type-incompatible or have different kind type parameters. (For
information on dtio_generic_spec specifications and the dtv argument, see
“User-defined derived-type Input/Output procedure interfaces (Fortran 2003)” on
page 211).
Within a scoping unit, two procedures that have the same generic name must both
be subroutines or both be functions. They must also adhere to the following
conditions:
1. One of the procedures contains a non-passed-object dummy argument such that
the number of dummy arguments in one procedure that are nonoptional, not
passed-object, and with which the dummy argument is TKR-compatible,
possibly including the dummy argument itself, exceeds the number of
Chapter 8. Program units and procedures
163

non-passed-object dummy arguments, both optional and nonoptional, in the
other procedure that are not distinguishable from the dummy argument.
2. Both procedures have passed-object dummy arguments, which are
distinguishable.
3. At least one of the procedures has both:
a. a nonoptional non-passed-object dummy argument at an effective position
such that either the other procedure has no dummy argument at that
effective position or the dummy argument at that position is distinguishable
from it
b. a nonoptional non-passed-object dummy argument whose name is such that
either the other procedure has no dummy argument with that name or the
dummy argument with that name is distinguishable from it.
The dummy argument that disambiguates by position must either be the same as,
or occur earlier in the argument list than, the one that disambiguates by name.
The effective position of a dummy argument is its position in the argument list
after any passed-object dummy argument has been removed.
When an interface block extends an intrinsic procedure, the rules in this section
apply as if the intrinsic procedure consists of a collection of specific procedures,
one procedure for each allowed set of arguments.
IBM extension
Note:
1. Dummy arguments of type BYTE are considered to have the same type as
corresponding 1-byte dummy arguments of type INTEGER(1), LOGICAL(1),
and character.
2. When the -qintlog compiler option is specified, dummy arguments of type
integer and logical are considered to have the same type as corresponding
dummy arguments of type integer and logical with the same kind type
parameter.
3. If the dummy argument is only declared with the EXTERNAL attribute within
an interface body, the dummy argument must be the only dummy argument
corresponding by position to a procedure, and it must be the only dummy
argument corresponding by argument keyword to a procedure.
End of IBM extension
Examples
PROGRAM MAIN
INTERFACE A
FUNCTION AI(X)
INTEGER AI, X
END FUNCTION AI
END INTERFACE
INTERFACE A
FUNCTION AR(X)
REAL AR, X
END FUNCTION AR
END INTERFACE
INTERFACE FUNC
FUNCTION FUNC1(I, EXT)
! Here, EXT is a procedure
INTEGER I
EXTERNAL EXT
164
XL Fortran: Language Reference

END FUNCTION FUNC1
FUNCTION FUNC2(EXT, I)
INTEGER I
REAL EXT
! Here, EXT is a variable
END FUNCTION FUNC2
END INTERFACE
EXTERNAL MYFUNC
IRESULT=A(INTVAL)
! Call to function AI
RRESULT=A(REALVAL)
! Call to function AR
RESULT=FUNC(1,MYFUNC)
! Call to function FUNC1
END PROGRAM MAIN
Extending intrinsic procedures with generic interface blocks
A generic intrinsic procedure can be extended or redefined. An extended intrinsic
procedure supplements the existing specific intrinsic procedures. A redefined
intrinsic procedure replaces an existing specific intrinsic procedure.
When a generic name is the same as a generic intrinsic procedure name and the
name has the INTRINSIC attribute (or appears in an intrinsic context), the generic
interface extends the generic intrinsic procedure.
When a generic name is the same as a generic intrinsic procedure name and the
name does not have the INTRINSIC attribute (nor appears in an intrinsic context),
the generic interface can redefine the generic intrinsic procedure.
A generic interface name cannot be the same as a specific intrinsic procedure name
if the name has the INTRINSIC attribute (or appears in an intrinsic context).
Examples
PROGRAM MAIN
INTRINSIC MAX
INTERFACE MAX
! Extension to intrinsic MAX
FUNCTION MAXCHAR(STRING)
CHARACTER(50) STRING
END FUNCTION MAXCHAR
END INTERFACE
INTERFACE ABS
! Redefines generic ABS as
FUNCTION MYABS(ARG)
!
ABS does not appear in
REAL(8) MYABS, ARG
!
an INTRINSIC statement
END FUNCTION MYABS
END INTERFACE
REAL(8) DARG, DANS
REAL(4) RANS
INTEGER IANS,IARG
CHARACTER(50) NAME
DANS = ABS(DARG)
! Calls external MYABS
IANS = ABS(IARG)
! Calls intrinsic IABS
DANS = DABS(DARG)
! Calls intrinsic DABS
IANS = MAX(NAME)
! Calls external MAXCHAR
RANS = MAX(1.0,2.0)
! Calls intrinsic AMAX1
END PROGRAM MAIN
Defined operators
A defined operator is a user-defined unary or binary operator, or an extended
intrinsic operator (see “Extended intrinsic and defined operations” on page 109). It
must be defined by both a function and a generic interface block.
1. To define the unary operation op x₁:
a. A function or entry must exist that specifies exactly one dummy argument,
d₁.
b.
Either:
Chapter 8. Program units and procedures
165

1) the generic_spec in an INTERFACE statement specifies OPERATOR
(op), or
2) there is a generic binding in the declared type of x1 with a generic_spec
of OPERATOR(op) and there is a corresponding binding to the
function in the dynamic type of x1.
c. The dynamic type of x₁ is compatible with the type of the dummy
argument d₁.
d. The type parameters, if any, of x₁ must match those of d₁.
e. Either
v
The function is ELEMENTAL, or
v
The rank of x₁, and its shape, if it is an array, match those of d₁
2. To define the binary operation x₁ op x₂:
a. The function is specified with a FUNCTION or ENTRY statement that
specifies two dummy arguments, d₁ and d₂.
b.
Either:
1) the generic_spec in an INTERFACE block specifies OPERATOR (op), or
2) there is a generic binding in the declared type of x1 or x2 with a
generic_spec of OPERATOR(op) and there is a corresponding binding to
the function in the dynamic type of x1 or x2, respectively.
c. The dynamic types of x₁ and x₂ are compatible with the types of the
dummy arguments d₁ and d₂, respectively.
d. The type parameters, if any, of x₁ and x₂ match those of d₁ and d₂,
respectively.
e. Either:
v
The function is ELEMENTAL and x₁ and x₂ are conformable or,
v
The ranks of x₁ and x₂ and their shapes, if either or both are arrays,
match those of d₁ and d₂, respectively.
3. If op is an intrinsic operator, the types or ranks of either x₁ or x₂ are not those
required for an intrinsic operation.
4. The generic_spec must not specify OPERATOR for functions with no
arguments or for functions with more than two arguments.
5. Each argument must be nonoptional.
6. The arguments must be specified with INTENT(IN).
7. Each function specified in the interface cannot have a result of assumed
character length.
8. If the operator specified is an intrinsic operator, the number of function
arguments must be consistent with the intrinsic uses of that operator.
9. A given defined operator can, as with generic names, apply to more than one
function, in which case it is generic just like generic procedure names. For
intrinsic operator symbols, the generic properties include the intrinsic
operations they represent.
10.
The following rules apply only to extended intrinsic operations:
a. The type of one of the arguments can only be of type BYTE when the type
of the other argument is of derived type.
b. When the -qintlog compiler option has been specified for non-character
operations, and d₁ is numeric or logical, then d₂ must not be numeric or
logical.
c. When the -qctyplss compiler option has been specified for non-character
operations, if x₁ is numeric or logical and x₂ is a character constant, the
intrinsic operation is performed.
166
XL Fortran: Language Reference

Examples
INTERFACE OPERATOR (.DETERMINANT.)
FUNCTION IDETERMINANT (ARRAY)
INTEGER, INTENT(IN), DIMENSION (:,:) :: ARRAY
INTEGER IDETERMINANT
END FUNCTION
END INTERFACE
END
Defined assignment
A defined assignment is treated as a reference to a subroutine, with the left-hand
side as the first argument and the right-hand side enclosed in parentheses as the
second argument.
1. To define the defined assignment x₁ = x₂:
a. The subroutine is specified with a SUBROUTINE or ENTRY statement that
specifies two dummy arguments, d₁ and d₂.
b.
Either:
1) the generic_spec of an interface block specifies ASSIGNMENT (=), or
2) there is a generic binding in the declared type of x1 or x2 with a
generic_spec of ASSIGNMENT(=) and there is a corresponding binding
to the subroutine in the dynamic type of x1 or x2, respectively.
c. The dynamic types of x₁ and x₂ are compatible with the types of dummy
arguments d₁ and d₂, respectively.
d. The type parameters, if any, of x₁ and x₂ match those of d₁ and d₂,
respectively.
e. Either:
v
The subroutine is ELEMENTAL and either x₁ and x₂ have the same
shape, x₂ is scalar, or
v
The ranks of x₁ and x₂, and their shapes, if either or both are arrays,
match those of d₁ and d₂, respectively.
2. ASSIGNMENT must only be used for subroutines with exactly two arguments.
3. Each argument must be nonoptional.
4. The first argument must have INTENT(OUT) or INTENT(INOUT), and the
second argument must have INTENT(IN).
5. The types of the arguments must not be both numeric, both logical, or both
character with the same kind parameter.
The type of one of the arguments can only be of type BYTE when the
type of the other argument is of derived type.
When the -qintlog compiler option has been specified, and d₁ is numeric or
logical, then d₂ must not be numeric or logical.
When the -qctyplss compiler option has been specified, if x₁ is numeric or
logical and x₂ is a character constant, intrinsic assignment is performed.
6. The ASSIGNMENT generic specification specifies that the assignment
operation is extended or redefined if both sides of the equal sign are of the
same derived type.
Chapter 8. Program units and procedures
167

Examples
INTERFACE ASSIGNMENT(=)
SUBROUTINE BIT_TO_NUMERIC (N,B)
INTEGER, INTENT(OUT) :: N
LOGICAL, INTENT(IN), DIMENSION(:) :: B
END SUBROUTINE
END INTERFACE
User-defined derived-type Input/Output procedures (Fortran
2003)
User-defined derived-type input/output procedures allow a program to override
the default handling of derived-type objects and values in data transfer
input/output statements.
There are four interfaces, one for each of the following I/O operations:
v
formatted input
v
formatted output
v
unformatted input
v
unformatted output
The four interfaces use a dtv type specification, or dtv_type_spec. The syntax for the
dtv_type_spec is as follows:
TYPE
(
derived_type_spec
)
CLASS
If derived_type_spec specifies an extensible type, use the CLASS keyword;
otherwise, use the TYPE keyword.
All length type parameters of derived_type_spec must be assumed.
The following table shows the required characteristics of the user-defined
procedures for each of the four dtio_generic_spec specifications of the interface block
or generic binding:
Table 18. Interfaces for user-defined derived-type input/output procedures
dtio_generic_spec
Interface
READ (FORMATTED)
SUBROUTINE my_read_routine_formatted &
(dtv, unit, iotype, v_list, iostat, iomsg)
INTEGER, INTENT(IN) :: unit ! unit number
! the derived-type value/variable
dtv_type_spec, INTENT(INOUT) :: dtv
! the edit descriptor string
CHARACTER (LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
END SUBROUTINE
168
XL Fortran: Language Reference

Table 18. Interfaces for user-defined derived-type input/output procedures (continued)
dtio_generic_spec
Interface
READ (UNFORMATTED)
SUBROUTINE my_read_routine_unformatted &
(dtv, unit, iostat, iomsg)
INTEGER, INTENT(IN) :: unit
! the derived-type value/variable
dtv_type_spec, INTENT(INOUT) :: dtv
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
END SUBROUTINE
WRITE (FORMATTED)
SUBROUTINE my_write_routine_formatted &
(dtv, unit, iotype, v_list, iostat, iomsg)
INTEGER, INTENT(IN) :: unit
! the derived-type value/variable
dtv_type_spec, INTENT(IN) :: dtv
! the edit descriptor string
CHARACTER (LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
END SUBROUTINE
WRITE (UNFORMATTED)
SUBROUTINE my_write_routine_unformatted &
(dtv, unit, iostat, iomsg)
INTEGER, INTENT(IN) :: unit
! the derived-type value/variable
dtv_type_spec, INTENT(IN) :: dtv
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
END SUBROUTINE
Note: The actual specific procedure names (the my ... routine ... procedure
names above) are not significant. In the discussion here and elsewhere, the dummy
arguments in these interfaces are referred by the names given above; the names
are, however, arbitrary.
The following are the characteristics of the arguments:
dtv
If the parent data transfer statement is a READ statement, dtv is the
argument associated with the effective list item that caused the
user-defined derived-type input procedure to be invoked, as if the effective
list item were an actual argument in this procedure reference. If the parent
data transfer statement is a WRITE or PRINT statement, dtv contains the
effective list item.
unit
When you invoke a user-defined derived-type input/output procedure,
unit has a value as follows:
v
If the parent data transfer statement uses a file-unit-number, the value is
that of the file-unit-number.
v
If the parent data transfer statement is a WRITE statement with an
asterisk unit or a PRINT statement, the value is the same as that of the
OUTPUT_UNIT named constant of the ISO_FORTRAN_ENV intrinsic
module.
v
If the parent data transfer statement is a READ statement with an
asterisk unit or a READ statement without an io-control-spec-list, the
value is the same as that of the INPUT_UNIT named constant of the
ISO_FORTRAN_ENV intrinsic module.
Chapter 8. Program units and procedures
169

v
Otherwise the parent data transfer statement must access an internal file.
In this case the value is negative.
iotype
For formatted data transfer, iotype has a value as follows:
v
"LISTDIRECTED" if the parent data transfer statement specified list
directed formatting
v
"NAMELIST" if the parent data transfer statement specified namelist
formatting
v
"DT" concatenated with the char-literal-constant, if any, of the edit
descriptor, if the parent data transfer statement contained a format
specification and the list item's corresponding edit descriptor was a DT
edit descriptor.
v_list
For formatted data transfer, v_list has values as follows:
v
If the v-list of the edit descriptor appears in the parent data transfer
statement, v_list contains the values specified in v-list, with the same
number of elements, in the same order.
v
If there is no v-list in the edit descriptor or if the data transfer statement
specifies list-directed or namelist formatting, v_ list is a zero-sized array.
iostat
is used to report whether an error, end-of-record, or end-of-file condition
occurs. Values are assigned to iostat as follows:
v
If an error condition occurs, the value is positive.
v
If an end-of-file condition occurs, the value is that of the named constant
IOSTAT_END.
v
If an end-of-record condition occurs, the value is that of the named
constant IOSTAT_EOR.
v
Otherwise, the value is zero.
iomsg
If the iostat argument returns a nonzero value, the procedure returns an
explanatory message in iomsg. Otherwise, the procedure does not change
the value of the iomsg argument.
Abstract interface (Fortran 2003)
An abstract interface allows you to specify procedure characteristics and dummy
argument names without declaring a procedure with those characteristics. You can
use an abstract interface to declare interfaces for procedures and deferred bindings.
The procedure names defined in an abstract interface block do not have an
EXTERNAL attribute.
170
XL Fortran: Language Reference

ABSTRACT_INTERFACE_statement
FUNCTION_interface_body
SUBROUTINE_interface_body
PROCEDURE_statement
END_ABSTRACT_INTERFACE_statement
ABSTRACT_INTERFACE_statement
See “ABSTRACT (Fortran 2003)” on page 274 for syntax details
FUNCTION_interface_body
See “Interface blocks” on page 160 for syntax details
SUBROUTINE_interface_body
See “Interface blocks” on page 160 for syntax details
PROCEDURE_statement
See “PROCEDURE” on page 416 for syntax details
END_ABSTRACT_INTERFACE_statement
See “END INTERFACE” on page 340 for syntax details
Examples
MODULE M
ABSTRACT INTERFACE
SUBROUTINE SUB(X,Y)
INTEGER ,INTENT(IN)::X
INTEGER ,INTENT(IN)::Y
END SUBROUTINE
END INTERFACE
END MODULE
PROGRAM MAIN
USE M
PROCEDURE (SUB) SUB1
PROCEDURE (SUB), POINTER::P
P=>SUB1
CALL P(5,10)
END PROGRAM
SUBROUTINE SUB1 (X,Y)
INTEGER ,INTENT(IN)::X
INTEGER ,INTENT(IN)::Y
PRINT*, "The sum of X and Y is: ", X + Y
END SUBROUTINE
Related information
For more information see:
v
PROCEDURE declaration “PROCEDURE declaration (Fortran 2003)” on page
417
v
external procedures “Program units, procedures, and subprograms” on page 156
Chapter 8. Program units and procedures
171

v
dummy procedures “Procedures as dummy arguments” on page 194
v
module procedures “Modules” on page 173
Main program
A main program is the program unit that receives control from the system when
the executable program is invoked at run time.
PROGRAM_statement
specification_part
execution_part
internal_subprogram_part
END_PROGRAM_statement
PROGRAM_statement
See “PROGRAM” on page 420 for syntax details
specification_part
is a sequence of statements from the statement groups numbered 2 , 4 ,
and 5 in “Order of statements and execution sequence” on page 14
execution_part
is a sequence of statements from the statement groups numbered 4 and
6 in “Order of statements and execution sequence” on page 14, and
which must begin with a statement from statement group 6
internal_subprogram_part
See “Internal procedures” on page 157 for details
END_PROGRAM_statement
See “END” on page 335 for syntax details
A main program cannot contain an ENTRY statement, nor can it specify an
automatic object.
A RETURN statement can appear in a main program. The execution of a
RETURN statement has the same effect as the execution of an END statement.
172
XL Fortran: Language Reference

Modules
A module contains specifications and definitions that can be accessed from other
program units. These definitions include data object definitions, namelist groups,
derived-type definitions, procedure interface blocks and procedure definitions.
There are two types of modules, intrinsic and nonintrinsic. XL Fortran
provides intrinsic modules, while nonintrinsic modules are user-defined.
An intrinsic module can have the same name as other global entities, such as
program units, common blocks, external procedures, critical sections, or binding
labels of global entities. A scoping unit must not access both an intrinsic module
and a non-intrinsic module with the same name.
Modules define global data, which, like COMMON data, is shared across
threads and is therefore thread-unsafe. To make an application thread-safe, you
must declare the global data as THREADPRIVATE or THREADLOCAL. See
“COMMON” on page 304, THREADLOCAL, and THREADPRIVATE in the XL
Fortran Optimization and Programming Guide for more information.
MODULE_statement
specification_part
module_subprogram_part
END_MODULE_statement
MODULE_statement
See “MODULE” on page 396 for syntax details
specification_part
is a sequence of statements from the statement groups numbered 2 , 4 ,
and 5 in “Order of statements and execution sequence” on page 14
module_subprogram_part:
CONTAINS_statement
module_subprogram
CONTAINS_statement
See “CONTAINS” on page 311 for syntax details
Chapter 8. Program units and procedures
173

END_MODULE_statement
See “END” on page 335 for syntax details
A module subprogram is contained in a module but is not an internal subprogram.
Module subprograms must follow a CONTAINS statement, and can contain
internal procedures. A module procedure is defined by a module subprogram or
an entry in a module subprogram.
Executable statements within a module can only be specified in module
subprograms.
The declaration of a module function name of type character cannot have an
asterisk as a length specification.
specification_part cannot contain statement function statements, ENTRY statements,
or FORMAT statements, although these statements can appear in the specification
part of a module subprogram.
Automatic objects and objects with the AUTOMATIC attribute cannot appear in
the scope of a module.
An accessible module procedure can be invoked by another subprogram in the
module or by any scoping unit outside the module through use association (that is,
by using the USE statement). See “USE” on page 463 for details.
IBM extension
Integer pointers cannot appear in specification_part if the pointee specifies a
dimension declarator with nonconstant bounds.
All objects in the scope of a module retain their association status, allocation status,
definition status, and value when any procedure that accesses the module through
use association executes a RETURN or END statement. See point 4 under “Events
causing undefinition” on page 22 for more information.
End of IBM extension
A module is a host to any module procedures, interface blocks, or derived-type
definitions it contains, which can access entities in the scope of the module
through host association.
A module procedure can be used as an actual argument associated with a dummy
procedure argument.
The name of a module procedure is local to the scope of the module and cannot be
the same as the name of any entity in the module, except for a common block
name.
174
XL Fortran: Language Reference

Migration Tips:
v
Eliminate common blocks and INCLUDE directives
v
Use modules to hold global data and procedures to ensure consistency of definitions
FORTRAN 77 source:
COMMON /BLOCK/A, B, C, NAME, NUMBER
REAL A, B, C
A = 3
CALL CALLUP(D)
PRINT *, NAME, NUMBER
END
SUBROUTINE CALLUP (PARM)
COMMON /BLOCK/A, B, C, NAME, NUMBER
REAL A, B, C
...
NAME = 3
NUMBER = 4
END
Fortran 90/95/2003 source:
MODULE FUNCS
REAL A, B, C
! Common block no longer needed
INTEGER NAME, NUMBER
! Global data
CONTAINS
SUBROUTINE CALLUP (PARM)
...
NAME = 3
NUMBER = 4
END SUBROUTINE
END MODULE FUNCS
PROGRAM MAIN
USE FUNCS
A = 3
CALL CALLUP(D)
PRINT *, NAME, NUMBER
END
Examples
MODULE M
INTEGER SOME_DATA
CONTAINS
SUBROUTINE SUB()
! Module subprogram
INTEGER STMTFNC
STMTFNC(I) = I + 1
SOME_DATA = STMTFNC(5) + INNER(3)
CONTAINS
INTEGER FUNCTION INNER(IARG)
! Internal subprogram
INNER = IARG * 2
END FUNCTION
END SUBROUTINE SUB
END MODULE
PROGRAM MAIN
USE M
! Main program accesses
CALL SUB()
!
module M
END PROGRAM
Block data program unit
A block data program unit provides initial values for objects in named common
blocks.
Chapter 8. Program units and procedures
175

BLOCK_DATA_statement
specification_part
END_BLOCK_DATA_statement
BLOCK_DATA_statement
See “BLOCK DATA” on page 288 for syntax details
specification_part
is a sequence of statements from the statement groups numbered 2 , 4 ,
and 5 in “Order of statements and execution sequence” on page 14
END_BLOCK_DATA_statement
See “END” on page 335 for syntax details
In specification_part, you can specify type declaration,USE, IMPLICIT, COMMON,
DATA, EQUIVALENCE, and integer pointer statements, derived-type definitions,
and the allowable attribute specification statements. The only attributes that can be
specified are:
BIND
, DIMENSION, INTRINSIC, PARAMETER,
POINTER, SAVE, TARGET, and
ASYNCHRONOUS
.
A type declaration statement in a block data specification-part must not contain
ALLOCATABLE or EXTERNAL attribute specifiers.
You can have more than one block data program unit in an executable program,
but only one can be unnamed. You can also initialize multiple named common
blocks in a block data program unit.
Restrictions on common blocks in block data program units are:
v
All items in a named common block must appear in the COMMON statement,
even if they are not all initialized.
v
The same named common block must not be referenced in two different block
data program units.
v
Only nonpointer objects in named common blocks can be initialized in block
data program units.
v
Objects in blank common blocks cannot be initialized.
Examples
PROGRAM MAIN
COMMON /L3/ C, X(10)
COMMON /L4/ Y(5)
END PROGRAM
BLOCK DATA BDATA
COMMON /L3/ C, X(10)
DATA C, X /1.0, 10*2.0/
! Initializing common block L3
END BLOCK DATA
BLOCK DATA
! An unnamed block data program unit
PARAMETER (Z=10)
176
XL Fortran: Language Reference

DIMENSION Y(5)
COMMON /L4/ Y
DATA Y /5*Z/
END BLOCK DATA
Function and subroutine subprograms
A subprogram is either a function or a subroutine, and is either an internal,
external, or module subprogram. You can also specify a function in a statement
function statement. An external subprogram is a program unit.
subprogram_statement
specification_part
execution_part
internal_subprogram_part
end_subprogram_statement
subprogram_statement
See “FUNCTION” on page 364 or “SUBROUTINE” on page 449 for syntax
details
specification_part
is a sequence of statements from the statement groups numbered 2 , 4
and 5 in “Order of statements and execution sequence” on page 14
execution_part
is a sequence of statements from the statement groups numbered 4 and
6 in “Order of statements and execution sequence” on page 14, and
which must begin with a statement from statement group 6
internal_subprogram_part
See “Internal procedures” on page 157 for details
end_subprogram_statement
See “END” on page 335 for syntax details on the END statement for
functions and subroutines
An internal subprogram is declared after the CONTAINS statement in the main
program, a module subprogram, or an external subprogram, but before the END
statement of the host program. The name of an internal subprogram must not be
defined in the specification section in the host scoping unit.
Chapter 8. Program units and procedures
177

An external procedure has global scope with respect to the executable program. In
the calling program unit, you can specify the interface to an external procedure in
an interface block or you can define the external procedure name with the
EXTERNAL attribute.
A subprogram can contain any statement except PROGRAM, BLOCK DATA and
MODULE statements. An internal subprogram cannot contain an ENTRY
statement or an internal subprogram.
Declaring procedures
An EXTERNAL statement, PROCEDURE declaration statement, or a procedure
component definition statement can be used to declare a procedure.
An EXTERNAL statement declares external procedures and dummy procedures.
See “EXTERNAL” on page 354.
A PROCEDURE declaration statement declares procedure pointers, dummy
procedures, and external procedures. For further information on the PROCEDURE
declaration statement, see “PROCEDURE declaration (Fortran 2003)” on page 417.
A procedure component definition statement declares procedure pointer
components of a derived type definition. See “Procedure pointer components” on
page 52.
Procedure pointers (Fortran 2003)
A procedure pointer is a procedure that has the EXTERNAL and POINTER
attribute. A derived type component which has been declared with the
PROCEDURE statement can be a procedure pointer.
A procedure pointer points at a procedure rather than a data object. A procedure
pointer can be associated in the same way as a dummy procedure with an external
procedure, a module procedure, an intrinsic procedure, or a dummy procedure
that is not a procedure pointer.
F2008
A procedure pointer can also be associated
with an internal procedure. However, an internal procedure cannot be invoked
using a procedure pointer after the host instance of the internal procedure
completes its execution.
F2008
Procedure pointers can have both an explicit and
implicit interface, can be structure components and can be associated using
procedure pointer assignment.
A dummy procedure with the pointer attribute is a dummy procedure pointer and
its associated actual argument is a procedure pointer.
A procedure pointer shall be storage associated only with another procedure
pointer; either both interfaces shall be explicit (the characteristics are the same) or
both interfaces shall be implicit (both interfaces will be functions or subroutines
with the same type and type parameters).
Although both type-bound procedures and procedure pointer components are
invoked through an object , the type-bound procedure which is executed depends
upon the type of the invoking object whereas procedure pointer components
depend upon the value. The PASS attribute defines the passed-object dummy
argument of the procedure pointer component
Examples
PROCEDURE(PROC), POINTER :: PTR
178
XL Fortran: Language Reference

Procedure references
There are two types of procedure references:
v
A subroutine is invoked by any of the following:
– execution of a CALL statement
– execution of a defined assignment statement

user-defined derived-type input/output

execution of finalization
v
A function is invoked during evaluation of a function reference or defined
operation.
Function reference
A function reference is used as a primary in an expression:
(1)
data_ref
separator
binding_name
(2)
procedure_component_ref
function_name
(
)
actual_argument_spec_list
Notes:
1
Fortran 2003
2
Fortran 2003
Executing a function reference results in the following order of events:
1. Actual arguments that are expressions are evaluated.
2. Actual arguments are associated with their corresponding dummy arguments.
3. Control transfers to the specified function.
4. The function is executed.
5. The value (or status or target, for pointer functions) of the function result
variable is available to the referencing expression.
Fortran 2003
If the binding_name in a function reference is that of a specific function, the
function referenced is the one identified by the binding with that name in the
dynamic type of the data-ref.
If the binding_name in a function reference is that of a generic procedure, the
generic binding with that name in the declared type of the data-ref is used to select
a specific binding:
1. If the reference is consistent with one of the specific bindings of that generic
binding, that specific binding is selected.
2. Otherwise, if the reference is consistent with an elemental reference to one of
the specific bindings of that generic binding, that specific binding is selected.
Chapter 8. Program units and procedures
179

The reference is to the procedure identified by the binding with the same name as
the selected specific binding, in the dynamic type of the data-ref.
End of Fortran 2003
Execution of a function reference must not alter the value of any other data item
within the statement in which the function reference appears. Invocation of a
function reference in the logical expression of a logical IF statement or WHERE
statement can affect entities in the statement that is executed when the value of the
expression is true.
IBM extension
The argument list built-in functions %VAL and %REF are supplied to aid
interlanguage calls by allowing arguments to be passed by value and by reference,
respectively. They can be specified in non-Fortran procedure references and in a
subprogram statement in an interface body. (See “%VAL and %REF (IBM
extension)” on page 186.) See Statement Function and Recursion examples of
function references.
End of IBM extension
On entry to an allocatable function, the allocation status of the result variable
becomes not currently allocated
The function result variable may be allocated and deallocated any number of times
during the execution of the function. However, it shall be currently allocated and
have a defined value on exit from the function. Automatic deallocation of the
result variable does not occur immediately on exit from the function, but instead
occurs after execution of the statement in which the function reference occurs.
Examples of subprograms and procedure references
MODULE QUAD_MOD
TYPE QUAD_TYPE
REAL:: a, b, c
CONTAINS
PROCEDURE Q2
END TYPE
INTERFACE
SUBROUTINE Q2(T,QUAD) ! External subroutine
IMPORT QUAD_TYPE
CLASS(QUAD_TYPE) T
REAL QUAD
END SUBROUTINE
END INTERFACE
END MODULE
PROGRAM MAIN
USE QUAD_MOD
REAL QUAD,X2,X1,X0,A,C3
TYPE(QUAD_TYPE) QT
QUAD=0; A=X1*X2
X2 = 2.0
X1 = SIN(4.5) ! Reference to intrinsic function
X0 = 1.0
QT = QUAD_TYPE(X2, X1, X0)
CALL Q(X2,X1,X0,QUAD) ! Reference to external subroutine
CALL QT%Q2(QUAD) ! Reference to a
subroutine
C3 = CUBE() ! Reference to internal function
CONTAINS
REAL FUNCTION CUBE() ! Internal function
180
XL Fortran: Language Reference

CUBE = A**3
END FUNCTION CUBE
END
SUBROUTINE Q(A,B,C,QUAD) ! External subroutine
REAL A,B,C,QUAD
QUAD = (-B + SQRT(B**2-4*A*C)) / (2*A)
END SUBROUTINE Q
SUBROUTINE Q2(T,QUAD) ! External subroutine
USE QUAD_MOD
TYPE(QUAD_TYPE) T
REAL QUAD
QUAD = (-T%B + SQRT(T%B**2-4*T%A*T%C)) / (2*T%A)
END SUBROUTINE Q2
Examples of allocatable function results
FUNCTION INQUIRE_FILES_OPEN() RESULT(OPENED_STATUS)
LOGICAL,ALLOCATABLE :: OPENED_STATUS(:)
INTEGER I,J
LOGICAL TEST
DO I=1000,0,–1
INQUIRE(UNIT=I,OPENED=TEST,ERR=100)
IF (TEST) EXIT
100 CONTINUE
END DO
ALLOCATE(OPENED_STATUS(0:I))
DO J=0,I
INQUIRE(UNIT=J,OPENED=OPENED_STATUS(J))
END DO
END FUNCTION INQUIRE_FILES_OPEN
Intrinsic procedures
An intrinsic procedure is a procedure already defined by XL Fortran. See
Chapter 14, “Intrinsic procedures,” on page 539 for details.
You can reference some intrinsic procedures by a generic name, some by a specific
name, and some by both:
A generic intrinsic function
does not require a specific argument type and usually produces a result of
the same type as that of the argument, with some exceptions. Generic
names simplify references to intrinsic procedures because the same
procedure name can be used with more than one type of argument; the
type and kind type parameter of the arguments determine which specific
function is used.
A specific intrinsic function
requires a specific argument type and produces a result of a specific type.
A specific intrinsic function name can be passed as an actual argument. If a
specific intrinsic function has the same name as a generic intrinsic function,
the specific name is referenced. All references to a dummy procedure that
are associated with a specific intrinsic procedure must use arguments that
are consistent with the interface of the intrinsic procedure. Specific intrinsic
functions may be procedure pointer targets.
Whether or not you can pass the name of an intrinsic procedure as an argument
depends on the procedure. You can use the specific name of an intrinsic procedure
that has been specified with the INTRINSIC attribute as an actual argument in a
procedure reference.
v
An IMPLICIT statement does not change the type of an intrinsic function.
Chapter 8. Program units and procedures
181

v
If an intrinsic name is specified with the INTRINSIC attribute, the name is
always recognized as an intrinsic procedure.
Conflicts between intrinsic procedure names and other names
When you declare a data object with the same name as an intrinsic procedure, the
intrinsic procedure is inaccessible.
A generic interface block can extend or redefine a generic intrinsic function, as
described in “Interface blocks” on page 160. If the function already has the
INTRINSIC attribute, it is extended; otherwise, it can be redefined.
Arguments
Actual argument specification
argument
arg_keyword
=
(1)
%VAL
(
argument
)
(2)
%REF
(
argument
)
Notes:
1
IBM Extension
2
IBM Extension
arg_keyword
is a dummy argument name in the explicit interface of the procedure being
invoked
argument
is an actual argument
%VAL, %REF
specifies the passing method. See “%VAL and %REF (IBM extension)” on
page 186 for more information.
An actual argument appears in the argument list of a procedure reference. The
following actual arguments are valid in procedure references:
v
An expression
v
A variable
v
A procedure name
v
An alternate return specifier (if the actual argument is in a CALL statement),
having the form *stmt_label, where stmt_label is the statement label of a branch
target statement in the same scoping unit as the CALL statement.
An actual argument specified in a statement function reference must be a scalar
object.
In Fortran 2003, a procedure name cannot be the name of an internal procedure,
statement function, or the generic name of a procedure, unless it is also a specific
name.
F2008
However, Fortran 2008 permits the name of an internal procedure.
F2008
182
XL Fortran: Language Reference

The rules and restrictions for referencing a procedure described in “Procedure
references” on page 179. You cannot use a non-intrinsic elemental procedure as an
actual argument in Fortran 95.
Argument keywords
Argument keywords allow you to specify actual arguments in a different order
than the dummy arguments. With argument keywords, any actual arguments that
correspond to optional dummy arguments can be omitted; that is, dummy
arguments that merely serve as placeholders are not necessary.
Each argument keyword must be the name of a dummy argument in the explicit
interface of the procedure being referenced. An argument keyword must not
appear in an argument list of a procedure that has an implicit interface.
In the argument list, if an actual argument is specified with an argument keyword,
the subsequent actual arguments in the list must also be specified with argument
keywords.
An argument keyword cannot be specified for label parameters. Label parameters
must appear before referencing the argument keywords in that procedure
reference.
Examples
INTEGER MYARRAY(1:10)
INTERFACE
SUBROUTINE SORT(ARRAY, DESCENDING, ARRAY_SIZE)
INTEGER ARRAY_SIZE, ARRAY(ARRAY_SIZE)
LOGICAL, OPTIONAL :: DESCENDING
END SUBROUTINE
END INTERFACE
CALL SORT(MYARRAY, ARRAY_SIZE=10)
! No actual argument corresponds to the
! optional dummy argument DESCENDING
END
SUBROUTINE SORT(ARRAY, DESCENDING, ARRAY_SIZE)
INTEGER ARRAY_SIZE, ARRAY(ARRAY_SIZE)
LOGICAL, OPTIONAL :: DESCENDING
IF (PRESENT(DESCENDING)) THEN
.
.
.
END SUBROUTINE
Dummy arguments
dummy_arg_name
(1)
%VAL
(
dummy_arg_name
)
*
(2)
%REF
(
dummy_arg_name
)
*
Notes:
1
IBM Extension
2
IBM Extension
Chapter 8. Program units and procedures
183

A dummy argument is specified in a Statement Function statement, FUNCTION
statement, SUBROUTINE statement, or ENTRY statement. Dummy arguments in
statement functions, function subprograms, interface bodies, and subroutine
subprograms indicate the types of actual arguments and whether each argument is
a scalar value, array, procedure, or statement label. A dummy argument in an
external, module, or internal subprogram definition, or in an interface body, is
classified as one of the following:
v
A variable name
v
A procedure name
v
An asterisk (in subroutines only, to indicate an alternate return point)
IBM extension
%VAL or %REF can only be specified for a dummy argument in a FUNCTION or
SUBROUTINE statement in an interface block. The interface must be for a
non-Fortran procedure interface. If %VAL or %REF appears in an interface block
for an external procedure, this passing method is implied for each reference to that
procedure. If an actual argument in an external procedure reference specifies
%VAL or %REF, the same passing method must be specified in the interface block
for the corresponding dummy argument. See “%VAL and %REF (IBM extension)”
on page 186 for more details.
End of IBM extension
A dummy argument in a statement function definition is classified as a variable
name.
A given name can appear only once in a dummy argument list.
The name of a variable that appears as a dummy argument in a statement function
statement has a scope of the statement in which it appears. It has the type that it
would have if it were the name of a variable in the scoping unit that includes the
statement function. It cannot have the same name as an accessible array.
Argument association
Actual arguments are associated with dummy arguments when a function or
subroutine is referenced. In a procedure reference, the actual argument list
identifies the correspondence between the actual arguments provided in the list
and the dummy arguments of the subprogram.
Fortran 2003
The reduced dummy argument list is the full dummy argument list or, if there is a
passed-object dummy argument, the dummy argument list with the passed object
dummy argument omitted. When there is no argument keyword, an actual
argument is associated with the dummy argument that occupies the corresponding
position in the reduced dummy argument list. The first actual argument becomes
associated with the first dummy argument in the reduced list, the second actual
argument with the second dummy argument, continuing until reaching the end of
the list. Each actual argument must be associated with a dummy argument.
End of Fortran 2003
184
XL Fortran: Language Reference

When a keyword is present, the actual argument is associated with the dummy
argument whose name is the same as the argument keyword. In the scoping unit
that contains the procedure reference, the names of the dummy arguments must
exist in an accessible explicit interface.
Argument association within a subprogram terminates upon execution of a
RETURN or END statement in the subprogram. There is no retention of argument
association between one reference of a subprogram and the next reference of the
subprogram, unless you specify -qxlf77=persistent and the subprogram contains at
least one entry procedure.
If associated with a null argument in a procedure reference, the corresponding
dummy argument is undefined and undefinable.
IBM extension
Except when %VAL or the VALUE attribute is used, the subprogram reserves no
storage for the dummy argument. It uses the corresponding actual argument for
calculations. Therefore, the value of the actual argument changes when the dummy
argument changes. If the corresponding actual argument is an expression or an
array section with vector subscripts, the calling procedure reserves storage for the
actual argument, and the subprogram must not define, redefine, or undefine the
dummy argument.
If the actual argument is specified with %VAL, or the corresponding dummy
argument has the VALUE attribute, the subprogram does not have access to the
storage area of the actual argument.
End of IBM extension
Actual arguments must agree in type and type parameters with their
corresponding dummy arguments (and in shape if the dummy arguments are
pointers or assumed-shape), except for two cases: a subroutine name has no type
and must be associated with a dummy procedure name that is a subroutine, and
an alternate return specifier has no type and must be associated with an asterisk.
Argument association can be carried through more than one level of procedure
reference.
If a subprogram reference causes a dummy argument in the referenced
subprogram to become associated with another dummy argument in the referenced
subprogram, neither dummy argument can become defined, redefined, or
undefined during that subprogram. For example, if a subroutine definition is:
SUBROUTINE XYZ (A,B)
and it is referenced by:
CALL XYZ (C,C)
the dummy arguments A and B each become associated with the same actual
argument C and, therefore, with each other. Neither A nor B can be defined,
redefined, or undefined during the execution of subroutine XYZ or by any
procedures referenced by XYZ.
If a dummy argument becomes associated with an entity in a common block or an
entity accessible through use or host association, the value of the entity must only
be altered through the use of the dummy argument name, while the entity is
Chapter 8. Program units and procedures
185

associated with the dummy argument. If any part of a data object is defined
through a dummy argument, the data object can be referenced only through that
dummy argument, either before or after the definition occurs. These restrictions
also apply to pointer targets.
If you have programs that do not conform to these restrictions, using the
compiler option -qalias=nostd may be appropriate. See the -qalias option in the
XL Fortran Compiler Reference for details.
%VAL and %REF (IBM extension)
To call subprograms written in languages other than Fortran (for example,
user-written C programs, or AIX operating system routines), the actual arguments
may need to be passed by a method different from the default method used by XL
Fortran. The default method passes the address of the actual argument and, if it is
of type character, the length. (Use the -qnullterm compiler option to ensure that
scalar character constant expressions are passed with terminating null strings. See
-qnullterm option in the XL Fortran Compiler Reference for details.)
The default passing method can be changed by using the %VAL and %REF
built-in functions in the argument list of a CALL statement or function reference,
or with the dummy arguments in interface bodies. These built-in functions specify
the way an actual argument is passed to the external subprogram.
%VAL and %REF built-in functions cannot be used in the argument lists of Fortran
procedure references, nor can they be used with alternate return specifiers.
The argument list built-in functions are:
%VAL This built-in function can be used with actual arguments that are
CHARACTER(1), logical, integer, real, complex expressions, or sequence
derived type. Objects of derived type cannot contain character structure
components whose lengths are greater than 1 byte, or arrays.
%VAL cannot be used with actual arguments that are arrays, derived types
with allocatable components, procedure names, or character expressions of
length greater than 1 byte.
%VAL causes the actual argument to be passed as 32-bit or 64-bit
intermediate values. If the actual argument is of type real or complex, it is
passed as one or more 64-bit intermediate values. If the actual argument is
of integer, logical, or sequence derived type, it is passed as one or more
32-bit intermediate values. An integer actual argument shorter than 32 bits
is sign-extended to a 32-bit value, while a logical actual argument shorter
than 32 bits is padded with zeros to a 32-bit value.
Byte named constants and variables are passed as if they were
INTEGER(1). If the actual argument is a CHARACTER(1), it is padded on
the left with zeros to a 32-bit value, regardless of whether the -qctyplss
compiler option is specified.
%REF This built-in function causes the actual argument to be passed by reference;
that is, only the address of the actual argument is passed. Unlike the
default passing method, %REF does not pass the length of a character
argument. If such a character argument is being passed to a C routine, the
string must be terminated with a null character (for example, using the
-qnullterm option) so that the C routine can determine the length of the
string.
186
XL Fortran: Language Reference

Examples
EXTERNAL FUNC
CALL RIGHT2(%REF(FUNC))
! procedure name passed by reference
REAL XVAR
CALL RIGHT3(%VAL(XVAR))
! real argument passed by value
IVARB=6
CALL TPROG(%VAL(IVARB))
! integer argument passed by value
See “VALUE (Fortran 2003)” on page 467 for a standard-conforming alternative to
%VAL.
See Interlanguage calls in theXL Fortran Optimization and Programming Guide for
more information.
Intent of dummy arguments
With the INTENT attribute, you can explicitly specify the intended use of a
dummy argument. Use of this attribute may improve optimization of the
program's calling procedure when an explicit interface exists. Also, the explicitness
of argument intent may provide more opportunities for error checking. See
“INTENT” on page 387 for syntax details.
IBM extension
The following table outlines passing method of XL Fortran for internal procedures
(not including assumed-shape, pointer, or allocatable dummy arguments):
Table 19. Passing method and intent
Argument Type
Intent(IN)
Intent(OUT)
Intent(INOUT)
No Intent
Non-CHARACTER
VALUE
default
default
default
Scalar
CHARACTER*1
VALUE
REFERENCE
REFERENCE
REFERENCE
Scalar
CHARACTER*n
REFERENCE
REFERENCE
REFERENCE
REFERENCE
Scalar
CHARACTER*(*)
default
default
default
default
Scalar
Derived Type 1
VALUE
default
default
default
Scalar
Derived Type 2
default
default
default
default
Scalar
Non-CHARACTER
default
default
default
default
Array
CHARACTER*1
REFERENCE
REFERENCE
REFERENCE
REFERENCE
Array
CHARACTER*n
REFERENCE
REFERENCE
REFERENCE
REFERENCE
Array
CHARACTER*(*)
default
default
default
default
Array
Derived Type 3
default
default
default
default
Array
Chapter 8. Program units and procedures
187

End of IBM extension
Optional dummy arguments
The OPTIONAL attribute specifies that a dummy argument need not be associated
with an actual argument in a reference to a procedure. Some advantages of the
OPTIONAL attribute include:
v
The use of optional dummy arguments to override default behavior. For an
example, see “Argument keywords” on page 183.
v
Additional flexibility in procedure references. For example, a procedure could
include optional arguments for error handlers or return codes, but you can select
which procedure references would supply the corresponding actual arguments.
See “OPTIONAL” on page 406 for details about syntax and rules.
The passed-object dummy argument
Fortran 2003
In a reference to a procedure that has a passed-object dummy argument, the
data_ref of the function reference or call statement is associated, as an actual
argument, with the passed object dummy argument. See “Passed-object dummy
arguments” on page 61
End of Fortran 2003
Restrictions on optional dummy arguments not present
A dummy argument is present in an instance of a subprogram if it is associated
with an actual argument that is not a dummy argument itself, or if it is associated
with a dummy argument that is either nonoptional or present in the invoking
subprogram. A dummy argument that is not optional must be present.
A dummy argument or an entity that is host associated with a dummy argument is
absent under one of these conditions:
v
It does not correspond to an actual argument.
v
It corresponds to an actual argument that is not present.
F2008
When the -qxlf2008=checkpresence option is in effect, a dummy argument
or an entity that is host associated with a dummy argument is also absent under
one of these conditions:
v
It does not have the ALLOCATABLE attribute, and corresponds to an actual
argument that has the ALLOCATABLE attribute but is not allocated.
v
It does not have the POINTER attribute, and corresponds to an actual argument
that has the POINTER attribute but is not associated.
Exceptions:
1. A data object of derived type with no array components or CHARACTER*n components, where n > 1.
2. A data object of derived type with array components or CHARACTER*n components, where n > 1.
3. A data object of derived-type with components of any type, size and rank.
188
XL Fortran: Language Reference

The -qxlf2008=checkpresence option does not affect argument presence under any
of these conditions:
v
A procedure pointer actual argument is supplied to an optional dummy
procedure argument.
v
A pointer or allocatable actual argument is supplied to an optional argument of
an intrinsic procedure.
v
A pointer or allocatable actual argument is supplied to an optional dummy
argument of an elemental procedure.
F2008
An optional dummy argument that is not present must conform to the following
rules:
v
If it is a dummy data object, it must not be referenced or defined. If the dummy
data object is of a type for which default initialization can be specified, the
initialization has no effect.
v
It must not be used as the data_target or proc_target of a pointer assignment
v
If it is a procedure or procedure pointer, it must not be invoked.
v
It must not be supplied as an actual argument that corresponds to a nonoptional
dummy argument, except as the argument of the PRESENT intrinsic function.
v
A subobject of an optional dummy argument that is not present must not be
supplied as an actual argument that corresponds to an optional dummy
argument.
v
If the optional dummy argument that is not present is an array, it must not be
supplied as an actual argument to an elemental procedure unless an array of the
same rank is supplied as an actual argument that corresponds to a nonoptional
dummy argument of that elemental procedure.
v
If the optional dummy argument that is not present is a pointer, it must not be
allocated, deallocated, nullified, pointer-assigned or supplied as an actual
argument that corresponds to a nonpointer dummy argument, except as the
argument of the PRESENT intrinsic function.
v
If the optional dummy argument that is not present is allocatable, it must not be
allocated, deallocated, or supplied as an actual argument corresponding to a
nonallocatable dummy argument other than as the argument of the PRESENT
intrinsic function.
v
If it has length type parameters, they must not be the subject of an inquiry.
v
An optional dummy argument that is not present must not be used as
the selector in an ASSOCIATE or SELECT TYPE construct.
Length of character arguments
If the length of a character dummy argument is a nonconstant specification
expression or is a colon, the object is a dummy argument with a run-time length. A
character dummy argument with a colon length is a deferred length character
dummy argument. If an object that is not a dummy argument has a run-time
length and is not deferred length, it is an automatic object. See “Automatic objects”
on page 18 for details.
If a dummy argument has a length specifier of an asterisk in parentheses, the
length of the dummy argument is “inherited” from the actual argument. The
length is inherited because it is specified outside the program unit containing the
dummy argument. If the associated actual argument is an array name, the length
Chapter 8. Program units and procedures
189

inherited by the dummy argument is the length of an array element in the
associated actual argument array. %REF cannot be specified for a character dummy
argument with inherited length.
Variables as dummy arguments
If a dummy argument is neither allocatable nor a pointer, it must be
type-compatible with the associated actual argument. If a dummy argument is
allocatable or a pointer, the associated actual argument is polymorphic only if the
dummy argument is polymorphic, and the declared type of the actual argument is
the same as the declared type of the dummy argument.
If the actual argument is scalar, the corresponding dummy argument must be
scalar, unless the actual argument
is of type default character, of type
character with the C character kind,
or is an element or substring of an
element of an array that is not an assumed-shape or pointer array. If the actual
argument is allocatable, the corresponding dummy argument must also be
allocatable. If the procedure is referenced by a generic name or as a defined
operator or defined assignment, the ranks of the actual arguments and
corresponding dummy arguments must agree. A scalar dummy argument can be
associated only with a scalar actual argument.
If the procedure is nonelemental and is referenced by a generic name or
as defined operator or defined assignment, the ranks of the actual arguments and
corresponding dummy arguments must agree.
The following apply to dummy arguments used in elemental subprograms:
v
All dummy arguments must be scalar, and cannot have the
ALLOCATABLE or
POINTER attribute.
v
A dummy argument, or a suboject thereof, cannot be used in a specification
expression, except if it is used as an argument to the BIT_SIZE, KIND, or LEN
intrinsic functions, or as an argument to one of the numeric inquiry intrinsic
functions, see Chapter 14, “Intrinsic procedures,” on page 539.
v
A dummy argument cannot be an asterisk.
v
A dummy argument cannot be a dummy procedure.
If a scalar dummy argument is of type character, its length must be less
than or equal to the length of the actual argument. The dummy argument is
associated with the leftmost characters of the actual argument. If the character
dummy argument is an array, the length restriction applies to the entire array
rather than each array element. That is, the lengths of associated array elements
can vary, although the whole dummy argument array cannot be longer than the
whole actual argument array.
If the dummy argument is an assumed-shape array,
the rank of the actual
argument must be the same as the rank of the dummy argument;
the
actual argument must not be an assumed-size array or a scalar, including a
designator for an array element or an array element substring.
If the dummy argument is an explicit-shape or assumed-size array, and if the
actual argument is a noncharacter array, the size of the dummy argument must not
exceed the size of the actual argument array. Each actual array element is
associated with the corresponding dummy array element. If the actual argument is
a noncharacter array element with a subscript value of as, the size of the dummy
argument array must not exceed the size of the actual argument array + 1 - as.
190
XL Fortran: Language Reference

The dummy argument array element with a subscript value of ds becomes
associated with the actual argument array element that has a subscript value of as
+ ds - 1.
If an actual argument is a character array, character array element, or character
substring, and begins at a character storage unit acu of an array, character storage
unit dcu of an associated dummy argument array becomes associated with
character storage unit acu+dcu-1 of the actual array argument.
You can define a dummy argument that is a variable name within a subprogram if
the associated actual argument is a variable. You must not redefine a dummy
argument that is a variable name within a subprogram if the associated actual
argument is not definable.
If the actual argument is an array section with a vector subscript, the associated
dummy argument cannot be defined and must not have the INTENT(OUT),
INTENT(INOUT), VOLATILE, or
ASYNCHRONOUS
attribute.
If an actual argument is an array section or an assumed-shape array, and the
corresponding dummy argument has either the VOLATILE or
ASYNCHRONOUS
attribute, that dummy argument must be an
assumed-shape array.
If an actual argument is an nonpointer array with the VOLATILE or
ASYNCHRONOUS
attribute
F2008
but is not simply
contiguous,
F2008
and the corresponding dummy argument has either the
VOLATILE or
ASYNCHRONOUS
attribute, that dummy
argument must be an assumed-shape array
F2008
without the CONTIGUOUS
attribute. F2008
If an actual argument is an array pointer with the VOLATILE or
ASYNCHRONOUS
attribute
F2008
but without the
CONTIGUOUS attribute F2008
, and the corresponding dummy argument has
either the VOLATILE or
ASYNCHRONOUS
attribute, that
dummy argument must be an array pointer or an assumed-shape array
F2008
without the CONTIGUOUS attribute. F2008
F2008
If the dummy argument is a pointer with the CONTIGUOUS attribute,
the corresponding actual argument must be simply contiguous. F2008
Except in references to intrinsic inquiry functions,
if a nonpointer
dummy argument is associated with a pointer actual argument, the actual
argument must be currently associated with a target, to which the dummy
argument becomes argument associated. Any restrictions on the passing method
apply to the target of the actual argument.
Except in references to intrinsic inquiry functions, if the dummy argument is not
allocatable and the actual argument is allocatable, the actual argument must be
allocated.
If the dummy argument has the VALUE attribute it becomes associated with a
definable anonymous data object whose initial value is that of the actual argument.
Subsequent changes to the value or definition status of the dummy argument do
not affect the actual argument.
Chapter 8. Program units and procedures
191

If the dummy argument is neither a target nor a pointer, any pointers associated
with the actual argument do not become associated with the corresponding
dummy argument on invocation of the procedure.
If both the dummy and actual arguments are targets (with the TARGET attribute),
in the following table, when all the conditions listed on the left apply, the
associations listed on the right occur:
Conditions for dummy and actual arguments
that are both targets
Associations
1. The dummy argument does not have the
1. Any pointers associated with the
VALUE attribute. 1
actual argument become associated
2. The actual argument is simply contiguous or
with the corresponding dummy
the dummy argument is a scalar or an
argument on invocation of the
assumed-shape array that does not have the
procedure.
CONTIGUOUS attribute. 2
2. When execution of the procedure
3. The actual argument is not a coindexed
completes, any pointers associated
object or an array section with a vector
with the dummy argument remain
subscript.
associated with the actual argument.
1. The dummy argument is an explicit-shape
1. Whether any pointers associated with
array, an assumed-shape array with the
the actual argument become
CONTIGUOUS attribute 2 , or an
associated with the corresponding
assumed-size array.
dummy argument on invocation of
2. The actual argument is not simply
the procedure is processor
contiguous. 2
dependent.
3. The actual argument is not an array section
2. When execution of the procedure
with a vector subscript.
completes, whether any pointers
associated with the dummy
argument remain associated with the
actual argument is processor
dependent.
Notes:
1 Fortran 2003
2 Fortran 2008
If the dummy argument is a target and the corresponding actual argument is not a
target or is an array section with a vector subscript, any pointers associated with
the dummy argument become undefined when execution of the procedure
completes.
If the dummy argument has the TARGET attribute and the VALUE
attribute, any pointers associated with the dummy argument become undefined
when execution of the procedure completes.
Allocatable objects as dummy arguments (Fortran 2003)
An allocatable dummy argument can only be associated with an actual argument
which is also allocatable. If the allocatable dummy argument is an array, the
associated actual argument must also be an array of the same rank. The
nondeferred type parameters of the actual argument must agree with those of the
dummy argument.
192
XL Fortran: Language Reference

An actual argument associated with a dummy argument that is allocatable must
have deferred the same type parameters as the dummy argument.
On procedure entry, the allocation status of an allocatable dummy argument
becomes that of the associated actual argument. If the dummy argument is
INTENT(OUT) and the associated actual argument is currently allocated, the
actual argument is deallocated on procedure invocation so that the dummy
argument has an allocation status of not currently allocated. If the dummy
argument is not INTENT(OUT) and the actual argument is currently allocated, the
value of the dummy argument is that of the associated actual argument.
While the procedure is active, an allocatable dummy argument that does not have
INTENT(IN) may be allocated, deallocated, defined, or become undefined. No
reference to the associated actual argument is permitted via another alias if any of
these events occur.
On exit from the routine, the actual argument has the allocation status of the
allocatable dummy argument (there is no change, of course, if the allocatable
dummy argument has INTENT(IN)). The usual rules apply for propagation of the
value from the dummy argument to the actual argument.
Automatic deallocation of the allocatable dummy argument does not occur as a
result of execution of a RETURN or END statement in the procedure of which it is
a dummy argument.
Note: An allocatable dummy argument that has the INTENT(IN) attribute must
not have its allocation status altered within the called procedure. The main
difference between such a dummy argument and a normal dummy argument is
that it might be unallocated on entry (and throughout execution of the procedure).
Examples
SUBROUTINE LOAD(ARRAY, FILE)
REAL, ALLOCATABLE, INTENT(OUT) :: ARRAY(:, :, :)
CHARACTER(LEN=*), INTENT(IN) :: FILE
INTEGER UNIT, N1, N2, N3
INTEGER, EXTERNAL :: GET_LUN
UNIT = GET_LUN() ! Returns an unused unit number
OPEN(UNIT, FILE=FILE, FORM=’UNFORMATTED’)
READ(UNIT) N1, N2, N3
ALLOCATE(ARRAY(N1, N2, N3))
READ(UNIT) ARRAY
CLOSE(UNIT)
END SUBROUTINE LOAD
Pointers as dummy arguments
The following requirements apply to actual arguments that correspond to dummy
data pointers:
v
If a dummy argument is a pointer, the actual argument must be a pointer
F2008
unless the dummy argument has the INTENT(IN) attribute and the
actual argument has the TARGET attribute. F2008
The type, nondeferred type
parameters, and rank of a dummy argument must match those of the
corresponding actual argument.
v
F2008
An actual argument associated with a dummy argument that is a
pointer and has the CONTIGUOUS attribute must be simply contiguous.
F2008
Chapter 8. Program units and procedures
193

v
An actual argument associated with a dummy argument that is a pointer must
have deferred the same type parameters as the dummy argument.
v
The actual argument reference is to the pointer itself, not to its target. When the
procedure is invoked:
– The dummy argument acquires the pointer association status of the actual
argument.
– If the actual argument is associated, the dummy argument is associated with
the same target.
The association status can change during execution of the procedure. When the
procedure finishes executing, the dummy argument's association status becomes
undefined, if it is associated.
The passing method must be by reference; that is, %VAL must not be
specified for the pointer actual argument.
Related information
v
F2008
Contiguity F2008
Procedures as dummy arguments
A dummy argument that is identified as a procedure
or a procedure
pointer
is called a dummy procedure or
dummy procedure
pointer,
respectively.
If a dummy argument is a dummy procedure without the POINTER
attribute, the associated actual argument must be the specific name of an external
procedure, module procedure, dummy procedure, or intrinsic procedure whose
name can be passed as an argument, an associated procedure pointer, or a
reference to a function that returns an associated procedure pointer. If the specific
name is also a generic name, only the specific procedure is associated with the
dummy argument.
If a dummy argument is a procedure pointer, the associated actual argument must
be a procedure pointer, a reference to a function that returns a procedure pointer,
or a reference to the NULL intrinsic function.
If an external procedure name or a dummy procedure name is used as an actual
argument, its interface must be explicit or it must be explicitly declared with the
EXTERNAL attribute.
If the interface of the dummy argument is explicit, the characteristics must be the
same for the associated actual argument and the corresponding dummy argument,
except that a pure actual argument may be associated with a dummy argument
that is not pure.
If the interface of the dummy argument is implicit and either the name of the
dummy argument is explicitly typed or it is referenced as a function, the dummy
argument must not be referenced as a subroutine and the actual argument must be
a function,
function procedure pointer
, or dummy procedure.
If the interface of the dummy argument is implicit and a reference to it appears as
a subroutine reference, the actual argument must be a subroutine,
subroutine procedure pointer
, or dummy procedure.
194
XL Fortran: Language Reference

Internal subprograms cannot be associated with a dummy procedure argument.
You cannot use a non-intrinsic elemental procedure as an actual argument in
Fortran 95.
Examples of procedures as dummy arguments
PROGRAM MYPROG
INTERFACE
SUBROUTINE SUB (ARG1)
EXTERNAL ARG1
INTEGER ARG1
END SUBROUTINE SUB
END INTERFACE
EXTERNAL IFUNC, RFUNC
REAL RFUNC
CALL SUB (IFUNC)
! Valid reference
CALL SUB (RFUNC)
! Invalid reference
!
! The first reference to SUB is valid because IFUNC becomes an
! implicitly declared integer, which then matches the explicit
! interface. The second reference is invalid because RFUNC is
! explicitly declared real, which does not match the explicit
! interface.
END PROGRAM
SUBROUTINE ROOTS
EXTERNAL NEG
X = QUAD(A,B,C,NEG)
RETURN
END
FUNCTION QUAD(A,B,C,FUNCT)
INTEGER FUNCT
VAL = FUNCT(A,B,C)
RETURN
END
FUNCTION NEG(A,B,C)
RETURN
END
Related information
v
See Chapter 14, “Intrinsic procedures,” on page 539 for details on which intrinsic
procedures can be passed as actual arguments.
v
See “Procedure references” on page 179 for the rules and restrictions for
referencing a procedure.
Asterisks as dummy arguments
A dummy argument that is an asterisk can only appear in the dummy argument
list of a SUBROUTINE statement or an ENTRY statement in a subroutine
subprogram. The corresponding actual argument must be an alternate return
specifier, which indicates the statement label of a branch target statement in the
same scope as the CALL statement, to which control is returned.
Examples
CALL SUB(*10)
STOP
! STOP is never executed
10 PRINT *, ’RETURN 1’
CONTAINS
SUBROUTINE SUB(*)
...
RETURN 1
! Control returns to statement with label 10
END SUBROUTINE
END
Chapter 8. Program units and procedures
195

Resolution of procedure references
The subprogram name in a procedure reference is either established to be generic,
established to be only specific, or not established.
A subprogram name is established to be generic in a scoping unit if one or more of
the following is true:
v
The scoping unit has an interface block with that name.
v
The name of the subprogram is the same as the name of a generic intrinsic
procedure that is specified in the scoping unit with the INTRINSIC attribute.
v
The scoping unit accesses the generic name from a module through use
association.
v
There are no declarations of the subprogram name in the scoping unit, but the
name is established to be generic in the host scoping unit.
A subprogram name is established to be only specific in a scoping unit when it has
not been established to be generic and one of the following is true:
v
An interface body in the scoping unit has the same name.
v
There is a statement function, module procedure, or an internal subprogram in
the scoping unit that has the same name.
v
The name of the subprogram is the same as the name of a specific intrinsic
procedure that is specified with the INTRINSIC attribute in the scoping unit.
v
The scoping unit contains an EXTERNAL statement with the subprogram name.
v
The scoping unit accesses the specific name from a module through use
association.
v
There are no declarations of the subprogram name in the scoping unit, but the
name is established to be specific in the host scoping unit.
If a subprogram name is not established to be either generic nor specific, it is not
established.
Rules for resolving procedure references to names
The following rules are used to resolve a procedure reference to a name established
to be generic:
1. If there is an interface block with that name in the scoping unit or accessible
through use association, and the reference is consistent with a non-elemental
reference to one of the specific interfaces of that interface block, the reference is
to the specific procedure associated with the specific interface.
2. If rule 1 does not apply, there is an interface block with that name in the
scoping unit or accessible through use association, and the reference is
consistent with an elemental reference to one of the specific interfaces of that
interface block, the reference is to the specific elemental procedure associated
with the specific interface.
3. If neither Rule 1 nor Rule 2 applies, the reference is to an intrinsic procedure if
the procedure name in the scoping unit is specified with the INTRINSIC
attribute or accesses a module entity whose name is specified with the
INTRINSIC attribute, and the reference is consistent with the interface of that
intrinsic procedure.
4. If Rule 1, Rule 2 and Rule 3 do not apply, but the name is established to be
generic in the host scoping unit, the name is resolved by applying the rules to
196
XL Fortran: Language Reference

the host scoping unit. For this rule to apply, there must be agreement between
the host scoping unit and the scoping unit of which the name is either a
function or a subroutine.
The following rules are used to resolve a procedure reference to a name established
to be only specific:
1. If the scoping unit is a subprogram, and it contains either an interface body
with that name or the name has the EXTERNAL attribute, and if the name is a
dummy argument of that subprogram, the dummy argument is a dummy
procedure. The reference is to that dummy procedure.
2. If Rule 1 does not apply, and the scoping unit contains either an interface body
with that name or the name has the EXTERNAL attribute, the reference is to an
external subprogram.
3. In the scoping unit, if a statement function or internal subprogram has that
name, the reference is to that procedure.
4. In the scoping unit, if the name has the INTRINSIC attribute, the reference is
to the intrinsic procedure with that name.
5. The scoping unit contains a reference to a name that is the name of a module
procedure that is accessed through use association. Because of possible
renaming in the USE statement, the name of the reference may differ from the
original procedure name.
6. If none of these rules apply, the reference is resolved by applying these rules to
the host scoping unit.
The following rules are used to resolve a procedure reference to a name that is not
established:
1. If the scoping unit is a subprogram and if the name is the name of a dummy
argument of that subprogram, the dummy argument is a dummy procedure.
The reference is to that dummy procedure.
2. If Rule 1 does not apply, and the name is the name of an intrinsic procedure,
the reference is to that intrinsic procedure. For this rule to apply, there must be
agreement between the intrinsic procedure definition and the reference that the
name is either a function or subroutine.
3. If neither Rule 1 nor 2 applies, the reference is to the external procedure with
that name.
Recursion
A procedure that can reference itself, directly or indirectly, is called a recursive
procedure. Such a procedure can reference itself indefinitely until a specific
condition is met. For example, you can determine the factorial of the positive
integer N as follows:
INTEGER N, RESULT
READ (5,*) N
IF (N.GE.0) THEN
RESULT = FACTORIAL(N)
END IF
CONTAINS
RECURSIVE FUNCTION FACTORIAL (N) RESULT (RES)
INTEGER RES
IF (N.EQ.0) THEN
RES = 1
ELSE
Chapter 8. Program units and procedures
197

RES = N * FACTORIAL(N-1)
END IF
END FUNCTION FACTORIAL
END
For details on syntax and rules, see “FUNCTION” on page 364, “SUBROUTINE”
on page 449, or “ENTRY” on page 344.
You can also call external procedures recursively when you specify the
-qrecur compiler option, although XL Fortran disregards this option if the
procedure specifies either the RECURSIVE or RESULT keyword.
Pure procedures
Pure procedures are free of side effects and are particularly useful in FORALL
statements and constructs, which by design require that all referenced procedures
be free of side effects.
A procedure must be pure in the following contexts:
v
An internal procedure of a pure procedure
v
A procedure referenced in the scalar_mask_expr or body of a FORALL statement
or construct, including one referenced by a defined operator, defined
assignment, or finalization
v
A procedure referenced in a pure procedure
v
A procedure actual argument to a pure procedure
Intrinsic functions (except RAND, an XL Fortran extension) and the
MOVE_ALLOC and MVBITS subroutines are always pure. They do not need to
be explicitly declared to be pure. A statement function is pure if and only if all
functions that it references are pure.
The specification_part of a pure function must specify that all dummy arguments
have an INTENT(IN), except procedure arguments, arguments with the POINTER
attribute,
F2008
and arguments with the VALUE attribute F2008
. The
specification_part of a pure subroutine must specify the intents of all dummy
arguments, except for procedure arguments, asterisks, arguments that have the
POINTER attribute,
F2008
and arguments that have the VALUE attribute
F2008
. Any interface body for such pure procedures must similarly specify the
intents of its dummy arguments.
The execution_part and internal_subprogram_part of a pure procedure cannot refer to
a dummy argument with an INTENT(IN), a global variable (or any object that is
storage associated with one), or any subobject thereof, in contexts that may cause
its value to change: that is, in contexts that produce side effects. The execution_part
and internal_subprogram_part of a pure function must not use a dummy argument,
a global variable, or an object that is associated with a global variable, or a
subobject thereof, in the following contexts:
v
As variable in an assignment statement, or as expression in an assignment
statement if variable is of a derived type that has a pointer component at any
level
v
As pointer_object or target in a pointer assignment statement
v
As a DO or implied-DO variable
v
As an input_item in a READ statement
v
As an internal file identifier in a WRITE statement
198
XL Fortran: Language Reference

v
As an IOSTAT=, SIZE= or IOMSG= specifier variable in an input/output
statement
v
As a variable in an ALLOCATE, DEALLOCATE, NULLIFY, or ASSIGN
statement
v
As an actual argument that is associated with a dummy argument with the
POINTER attribute or with an intent of OUT or INOUT
v
As the argument to LOC
v
As a STAT= or ERRMSG= specifier
v
As a variable in a NAMELIST which appears in a READ statement
v
A variable that is the selector in a SELECT TYPE or ASSOCIATE construct if
the associate name of that construct appears in a variable definition context.
A pure procedure must not specify that any entity is VOLATILE. In addition, it
must not contain any references to data that is VOLATILE, that would otherwise
be accessible through use- or host-association. This includes references to data
which occur through NAMELIST I/O.
F2008
A local variable of a pure subprogram or a local variable of a BLOCK
construct within a pure subprogram cannot have the SAVE attribute. F2008
Only internal I/O is permitted in pure procedures. Therefore, the unit identifier of
an I/O statement cannot be an asterisk (*) or refer to an external unit. The I/O
statements are as follows:
v
BACKSPACE
v
CLOSE
v
ENDFILE
v
FLUSH
v
INQUIRE
v
OPEN
v
PRINT
v
READ
v
REWIND
v
WAIT
v
WRITE
The PAUSE, STOP, and
F2008
ERROR STOP F2008
statements are not
permitted in pure procedures.
There are two differences between pure functions and pure subroutines:
1. Subroutine nonpointer dummy data objects may have any intent, while
function nonpointer dummy data objects must be INTENT(IN).
2. Subroutine dummy data objects with the POINTER attribute can change
association status and/or definition status
If a procedure is not defined as pure, it must not be declared pure in an interface
body. However, the converse is not true: if a procedure is defined as pure, it does
not need to be declared pure in an interface body. Of course, if an interface body
does not declare that a procedure is pure, that procedure (when referenced through
that explicit interface) cannot be used as a reference where only pure procedure
references are permitted (for example, in a FORALL statement).
Chapter 8. Program units and procedures
199

Examples
PROGRAM ADD
INTEGER ARRAY(20,256)
INTERFACE
! Interface required for
PURE FUNCTION PLUS_X(ARRAY)
!
a pure procedure
INTEGER, INTENT(IN) :: ARRAY(:)
INTEGER :: PLUS_X(SIZE(ARRAY))
END FUNCTION
END INTERFACE
INTEGER :: X
X = ABS(-4)
! Intrinsic function
!
is always pure
FORALL (I=1:20, I /= 10)
ARRAY(I,:) = I + PLUS_X(ARRAY(I,:))
! Procedure references in
!
FORALL must be pure
END FORALL
END PROGRAM
PURE FUNCTION PLUS_X(ARRAY)
INTEGER, INTENT(IN) :: ARRAY(:)
INTEGER :: PLUS_X(SIZE(ARRAY)),X
INTERFACE
PURE SUBROUTINE PLUS_Y(ARRAY)
INTEGER, INTENT(INOUT) :: ARRAY(:)
END SUBROUTINE
END INTERFACE
X=8
PLUS_X = ARRAY+X
CALL PLUS_Y(PLUS_X)
END FUNCTION
PURE SUBROUTINE PLUS_Y(ARRAY)
INTEGER, INTENT(INOUT) :: ARRAY(:)
! Intent must be specified
INTEGER :: Y
Y=6
ARRAY = ARRAY+Y
END SUBROUTINE
Elemental procedures
An elemental subprogram definition must have the ELEMENTAL prefix specifier.
If the ELEMENTAL prefix specifier is used, the RECURSIVE specifier cannot be
used.
You cannot use the -qrecur option when specifying elemental procedures.
An elemental subprogram is a pure subprogram. However, pure subprograms are
not necessarily elemental subprograms. For elemental subprograms, it is not
necessary to specify both the ELEMENTAL prefix specifier and the PURE prefix
specifier; the PURE prefix specifier is implied by the presence of the ELEMENTAL
prefix specifier. A standard conforming subprogram definition or interface body
can have both the PURE and ELEMENTAL prefix specifiers.
Elemental procedures, subprograms, and user-defined elemental procedures must
conform to the following rules:
v
The result of an elemental function must be a scalar, and must not have the
ALLOCATABLE or
POINTER attribute.
v
The following apply to dummy arguments used in elemental subprograms:
– All dummy arguments must be scalar, and must not have the
ALLOCATABLE or
POINTER attribute.
200
XL Fortran: Language Reference

– A dummy argument, or a subobject thereof, cannot be used in a specification
expression, except if it is used as an argument to the BIT_SIZE, KIND, or
LEN intrinsic functions, or as an argument to one of the numeric inquiry
intrinsic functions, see Chapter 14, “Intrinsic procedures,” on page 539.
– A dummy argument cannot be an asterisk.
– A dummy argument cannot be a dummy procedure.
v
Elemental subprograms must follow all of the rules that apply to pure
subprograms, defined in “Pure procedures” on page 198.
v
Elemental subprograms can have ENTRY statements, but the ENTRY statement
cannot have the ELEMENTAL prefix. The procedure defined by the ENTRY
statement is elemental if the ELEMENTAL prefix is specified in the
SUBROUTINE or FUNCTION statement.
v
Elemental procedures can be used as defined operators in elemental expressions,
but they must follow the rules for elemental expressions as described in
“Operators and expressions” on page 101.
A reference to an elemental procedure is elemental only if:
v
The reference is to an elemental function, one or more of the actual arguments is
an array, and all array actual arguments have the same shape; or
v
The reference is to an elemental subroutine, and all actual arguments that
correspond to the INTENT(OUT) and INTENT(INOUT) dummy arguments are
arrays that have the same shape. The remaining actual arguments are
conformable with them.
A reference to an elemental subprogram is not elemental if all of its arguments are
scalar.
The actual arguments in a reference to an elemental procedure can be either of the
following:
v
All scalar. For elemental functions, if the arguments are all scalar, the result is
scalar.
v
One or more array-valued. The following rules apply if one or more of the
arguments is array-valued:
– For elemental functions, the shape of the result is the same as the shape of the
array actual argument with the greatest rank. If more than one argument
appears then all actual arguments must be conformable.
– For elemental subroutines, all actual arguments associated with
INTENT(OUT) and INTENT(INOUT) dummy arguments must be arrays of
the same shape, and the remaining actual arguments must be conformable
with them.
For elemental references, the resulting values of the elements are the same as
would be obtained if the subroutine or function had been applied separately in any
order to the corresponding elements of each array actual argument.
If the intrinsic subroutine MVBITS is used, the arguments that correspond to the
TO and FROM dummy arguments may be the same variable. Apart from this, the
actual arguments in a reference to an elemental subroutine or elemental function
must satisfy the restrictions described in “Argument association” on page 184.
Special rules apply to generic procedures that have an elemental specific
procedure. See “Rules for resolving procedure references to names” on page 196
Chapter 8. Program units and procedures
201

Examples
! Example of an elemental function
PROGRAM P
INTERFACE
ELEMENTAL REAL FUNCTION LOGN(X,N)
REAL, INTENT(IN) :: X
INTEGER, INTENT(IN) :: N
END FUNCTION LOGN
END INTERFACE
REAL RES(100), VAL(100,100)
...
DO I=1,100
RES(I) = MAXVAL( LOGN(VAL(I,:),2) )
END DO
...
END PROGRAM P
Example 2:
! Elemental procedure declared with a generic interface
INTERFACE RAND
ELEMENTAL FUNCTION SCALAR_RAND(x)
REAL, INTENT(IN) :: X
END FUNCTION SCALAR_RAND
FUNCTION VECTOR_RANDOM(x)
REAL X(:)
REAL VECTOR_RANDOM(SIZE(x))
END FUNCTION VECTOR_RANDOM
END INTERFACE RAND
REAL A(10,10), AA(10,10)
! The actual argument AA is a two-dimensional array. The procedure
! taking AA as an argument is not declared in the interface block.
! The specific procedure SCALAR_RAND is then called.
A = RAND(AA)
! The actual argument is a one-dimensional array section. The procedure
! taking a one-dimensional array as an argument is declared in the
! interface block. The specific procedure VECTOR_RANDOM is then called.
! This is a non-elemental reference since VECTOR_RANDOM is not elemental.
A(:,1) = RAND(AA(6:10,2))
END
202
XL Fortran: Language Reference

Chapter 9. XL Fortran Input/Output
XL Fortran supports both synchronous and asynchronous input/output (I/O).
Synchronous I/O halts an executing application until I/O operations complete.
Asynchronous I/O allows an application to continue processing while I/O
operations occur in the background. Both I/O types support the following file
access methods:
v
Sequential access
v
Direct access
v
Stream access
Each method of access offers benefits and limitations based on the I/O concepts of,
Records, Files and Units.
This section also provides explanations of the IOSTAT= specifier codes that can
result when using XL Fortran I/O statements.
Records
A record contains a sequence of characters or values. XL Fortran supports three
record types:
v
formatted
v
unformatted
v
endfile
Formatted records
A formatted record consists of a sequence of ASCII characters that can print in a
readable format. Reading a formatted record converts the data values from
readable characters into an internal representation. Writing a formatted record
converts the data from the internal representation into characters.
IBM extension
When printing a file with formatted records using the AIX asa command, the first
character of each record determines vertical spacing and does not print. See
Printing Output Files with Fortran ASA Carriage Controls (asa) in the XL Fortran
Compiler Reference for details. The remaining characters of the record begin printing
at the left margin. You can specify vertical spacing in a format specification as
literal data according to the following table:
First Character of Record
Vertical Spacing Before Printing
Blank
One line
0
Two lines
1
To first line of next page
+
No advance
An error occurs if you use any other character as the first character of the print
record. If the print record contains no characters, spacing advances by one line and
a blank line prints. Displaying records on a terminal also uses the first character of
the record, but only the characters blank, 0, and + produce the spacing shown. You
© Copyright IBM Corp. 1996, 2012
203

must use AIX asa to display these print codes on a terminal. See Printing Output
Files with Fortran ASA Carriage Controls (asa) in the XL Fortran Compiler Reference for
details.
End of IBM extension
Unformatted records
An unformatted record contains a sequence of values in an internal representation
that can contain both character and noncharacter data. An unformatted record can
also contain no data. Reading or writing an unformatted record does not convert
any data the record contains from the internal representation.
Endfile records
If it exists, an endfile record is the last record of a file. It has no length. It can be
written explicitly by an ENDFILE statement. It can be written implicitly to a file
connected for sequential access when the last data transfer statement was a WRITE
statement, no intervening file positioning statement referring to the file has been
executed, and the following is true:
v
A REWIND or BACKSPACE statement references the unit to which the file is
connected; or
v
The file is closed, either explicitly by a CLOSE statement, implicitly by a
program termination not caused by an error condition, or implicitly by another
OPEN statement for the same unit.
Files
A file is an internal or external sequence of records or file storage units. You
determine the file access method when connecting a file to a unit. You can access
an external file using three methods:
v
Sequential access
v
Direct access
v
Stream access
You can only access an internal file sequentially.
Definition of an external file
You must associate an external file with an I/O device such as a disk, or terminal.
An external file exists for a program when a program creates that file, or the file is
available to that program for reading and writing. Deleting an external file ends
the existence of that file. An external file can exist and contain no records.
To specify an external file by a file name, you must designate a valid
operating system file name. Each file name can contain a maximum of 255
characters. If you specify a full path name, it can contain a maximum of 1023
characters.
The preceding I/O statement determines the position of an external file. You can
position an external file to:
v
The initial point, which is the position immediately before the first record, or the
first file storage unit.
v
The terminal point, which is the position immediately after the last record, or
the last file storage unit.
204
XL Fortran: Language Reference

v
The current record, when the file position is within a record. Otherwise, there is
no current record.
v
The preceding record, which is the record immediately before the current record.
If there is no current record, the preceding record is the record immediately
before the current file position. A preceding record does not exist when the file
position is at its initial point or within the first record of the file.
v
The next record, which is the record immediately after the current record. If
there is no current record, the next record is the record immediately after the
current position. The next record does not exist when the file position is at the
terminal point or within the last record of the file.
An external file can also have indeterminate position after an error.
File access methods
Sequential access
Using sequential access, records in a file are read or written based on the logical
order of records in that file. Sequential access supports both internal and external
files.
External files: A file connected for sequential access contains records in the order
they were written. The records must be either all formatted or all unformatted; the
last record of the file must be an endfile record. The records must not be read or
written by direct
or stream access
I/O statements during the
time the file is connected for sequential access.
Internal files: An internal file is a character variable that is not an array section
with a vector subscript. You do not need to create internal files. They always exist,
and are available to the application.
If an internal file is a scalar character variable, the file consists of one record with a
length equal to that of the scalar variable. If an internal file is a character array,
each element of the array is a record of the file, with each record having the same
length.
An internal file must contain only formatted records. READ and WRITE are the
only statements that can specify an internal file. If a WRITE statement writes less
than an entire record, blanks fill the remainder of that record.
An internal file is positioned at the beginning of the first record prior to
data transfer, except for child data transfer statements. This record becomes the
current record.
Direct access
Using direct access, the records of an external file can be read or written in any
order. The records must be either all formatted or all unformatted. The records
must not be read or written using sequential or stream access, list-directed or
namelist formatting, or a nonadvancing input/output statement. If the file was
previously connected for sequential access, the last record of the file is an endfile
record. The endfile record is not considered a part of the file connected for direct
access.
Each record in a file connected for direct access has a record number that identifies
its order in the file. The record number is an integer value that must be specified
when the record is read or written. Records are numbered sequentially. The first
Chapter 9. XL Fortran Input/Output
205

record is number 1. Records need not be read or written in the order of their
record numbers. For example, records 9, 5, and 11 can be written in that order
without writing the intermediate records.
All records in a file connected for direct access must have the same length, which
is specified in the OPEN statement when the file is connected.
Records in a file connected for direct access cannot be deleted, but they can be
rewritten with a new value. A record cannot be read unless it has first been
written.
Stream access (Fortran 2003)
You can connect external files for stream access as either formatted or unformatted.
Both forms use external stream files composed of one byte file storage units. While
a file connected for unformatted stream access has only a stream structure, files
connected for formatted stream access have both a record and a stream structure.
These dual structure files have the following characteristics:
v
Some file storage units represent record markers.
v
The record structure is inferred from the record markers stored in the file.
v
There is no theoretical limit on record length.
v
Writing an empty record without a record marker has no effect.
v
If there is no record marker at the end of a file, the final record is incomplete but
not empty.
v
The endfile record in a file previously connected for sequential access is not
considered part of the file when you connect that file for stream access.
The first file storage unit of a file connected for formatted stream access has a
position of 1. The position of each subsequent storage unit is greater than the
storage unit immediately before it. The positions of successive storage units are not
always consecutive and positionable files need not be read or written to in order of
position. To determine the position of a file storage unit connected for formatted
stream access, use the POS= specifier of the INQUIRE statement. If the file can be
positioned, you can use the value obtained using the INQUIRE statement to
position that file. You read from the file while connected to the file, as long as the
storage unit has been written to since file creation and that the connection permits
a READ statement. File storage units of a file connected for formatted stream
access can only be read or written by formatted stream access input/output
statements.
The first file storage unit of a file connected for unformatted stream access has a
position of 1. The position value of successive storage units is incrementally one
greater than the storage unit it follows. Positionable files need not be read or
written to in order of position. Any storage unit can be read from the file while
connected to the file, if the storage unit has been written to since file creation and
that the connection permits a READ statement. File storage units of a file
connected for unformatted stream access can only be read or written by stream
access input/output statements.
Units
A unit is a means of referring to a file. Programs refer to files by the unit numbers
indicated by unit specifiers in input/output statements. See [UNIT=] for the form
of a unit specifier.
206
XL Fortran: Language Reference

Connection of a unit
A connection refers to the association between a file and a unit. A connection must
occur before the records of a file can be read or written.
There are three ways to connect a file to a unit:
v
Preconnection
v
Implicit connection
v
Explicit connection, using the OPEN statement
Preconnection
Preconnection occurs when the program begins executing. You can specify
preconnection in I/O statements without the prior execution of an OPEN
statement. Three units are preconnected for formatted sequential access to the
standard error, input, and output devices.
You can refer to these units in
input/output statements using the ERROR_UNIT, INPUT_UNIT, and
OUTPUT_UNIT constants from the ISO_FORTRAN_ENV module.
IBM extension
You can also refer to these units directly using the following values:
v
Unit 0 for the standard error device
v
Unit 5 for the standard input device
v
Unit 6 for the standard output device
The preconnected units use the default specifier values for the OPEN statement
with the following exceptions:
v
STATUS='OLD'
v
ACTION='READWRITE'
v
FORM='FORMATTED'
End of IBM extension
Implicit connection (IBM extension)
Implicit connection occurs when a sequential statement that is; ENDFILE, PRINT,
READ, REWIND, or WRITE executes on a unit not already connected to an
external file. The executing statement connects that unit to a file with a
predetermined name. By default, this connection is unit n to file fort.n. You do not
need to create the file before implicit connection. To implicitly connect to a
different file name, refer to the UNIT_VARS run-time option under Setting runtime
options in the XL Fortran Compiler Reference.
You can not specify unit 0 for implicit connection.
You can only connect a preconnected unit implicitly if you terminate the
connection between the unit and the external file. In the next example a
preconnected unit closes before implicit connection takes place.
Sample Implicit Connection
PROGRAM TRYME
WRITE ( 6, 10 ) "Hello1"
! "Hello1" written to standard output
CLOSE ( 6 )
WRITE ( 6, 10 ) "Hello2"
! "Hello2" written to fort.6
10
FORMAT (A)
END
Chapter 9. XL Fortran Input/Output
207

A unit with an implicit connection uses the default specifier values of the OPEN
statement, except for the FORM= and ASYNCH= specifiers. The first data transfer
statement determines the values for FORM= and ASYNCH=.
If the first I/O statement uses format-directed, list-directed, or namelist formatting,
the value of the FORM= specifier is set to FORMATTED. An unformatted I/O
statement sets the specifier to UNFORMATTED.
If the first I/O statement is asynchronous, the value of the ASYNCH= specifier is
set to YES. A synchronous I/O statement sets the specifier to NO.
Disconnection
The CLOSE statement disconnects a file from a unit. You can connect the file again
within the same program to the same unit or to a different unit. You can connect
the unit again within the same program to the same file or a different file.
v
You can not close unit 0
v
You can not reconnect unit 5 to standard input after the unit closes
v
You can not reconnect unit 6 to standard output after the unit closes
Data transfer statements
The READ statement obtains data from an external or internal file and transfers
the data to internal storage. If you specify an input list, values transfer from the
file to the data items you specify.
The WRITE statement transfers data from internal storage into an external or
internal file.
The PRINT statement transfers data from internal storage into an external file.
Specifying the –qport=typestmt compiler option enables the TYPE statement which
supports functionality identical to PRINT. If you specify an output list and format
specification, values transfer to the file from the data items you specify. If you do
not specify an output list, the PRINT statement transfers a blank record to the
output device unless the FORMAT statement it refers to contains, as the first
specification, a character string edit descriptor or a slash edit descriptor. In this
case, the records these specifications indicate transfer to the output device.
Execution of a WRITE or PRINT statement for a file that does not exist creates
that file, unless an error occurs.
If an input/output item is a pointer, data is transferred between the file and the
associated target.
If an input or output item is polymorphic, or is a derived type with a
pointer or an allocatable component, it must be processed by a user-defined
derived-type input/output procedure.
During advancing input from a file with a PAD= specifier that has the value NO,
the input list and format specification must not require more characters from the
record than that record contains. If the PAD= specifier has the value YES, blank
characters are supplied if the input list and format specification require more
characters from the record than the record contains.
208
XL Fortran: Language Reference

If you want to pad files connected for sequential access, specify the
-qxlf77=noblankpad compiler option. This compiler option also sets the default
value for the PAD= specifier to NO for direct and stream files and YES for
sequential files.
During nonadvancing input from a file with a PAD= specifier that has the value
NO, an end-of-record condition occurs if the input list and format specification
require more characters from the record than the record contains. If the PAD=
specifier has the value YES, an end-of-record condition occurs and blank characters
are supplied if an input item and its corresponding data edit descriptor require
more characters from the record than the record contains. If the record is the last
record of a stream file, an end-of-file condition occurs.
Asynchronous Input/Output
You can specify asynchronous READ and WRITE data transfer statements to
initiate asynchronous data transfer. Execution continues after the asynchronous I/O
statement, without waiting for the data transfer to complete.
Executing a matching WAIT statement with the same ID= value that was returned
to the ID= variable in the data transfer statement detects that the data transfer
statement is complete, or waits for that data transfer statement to complete.
The data transfer of an I/O item in an asynchronous I/O statement can complete:
v
During the execution of the asynchronous data transfer statement
v
At any time before the execution of the matching WAIT statement
v
During the matching WAIT statement
For information on situations where data transfer must complete during the
asynchronous data transfer statement, see Implementation details of XL Fortran
Input/Output in the XL Fortran Optimization and Programming Guide.
If an error occurs during the execution of an asynchronous data transfer statement,
the variable associated with the ID= specifier remains undefined. The IOSTAT=
specifier indicates the status of the I/O operation and control is transferred to the
statement specified by the ERR= specifier.
You must not reference, define, or undefine variables or items associated with a
variable appearing in an I/O list for an asynchronous data transfer statement, until
the execution of the matching WAIT statement.
Any deallocation of allocatable objects and pointers and changing association
status of pointers are disallowed between an asynchronous data transfer statement
and the matching WAIT statement.
Multiple outstanding data transfer operations on the same unit can be
both READ and WRITE. A WAIT statement will perform a wait operation for all
pending data transfers for the specified unit if the ID= specifier is omitted.
In the case of direct access, an asynchronous WRITE statement must not specify
both the same unit and record number as any asynchronous WRITE statement for
which the matching WAIT statement has not been executed.
For stream
access, an asynchronous WRITE statement must not specify either the same unit
and location within a file as any asynchronous WRITE statement for which the
matching WAIT statement has not been executed.
Chapter 9. XL Fortran Input/Output
209

In the portion of the program that executes between the asynchronous data
transfer statement and the matching WAIT statement, you must not reference,
define, or undefine variables or items associated with the integer_variable in the
NUM= specifier of that data transfer statement.
Using Asynchronous I/O
SUBROUTINE COMPARE(ISTART, IEND, ISIZE, A)
INTEGER, DIMENSION(ISIZE) :: A
INTEGER I, ISTART, IEND, ISIZE
DO I = ISTART, IEND
IF (A (I) /= I) THEN
PRINT *, "Expected ", I, ", got ", A(I)
END IF
END DO
END SUBROUTINE COMPARE
PROGRAM SAMPLE
INTEGER, PARAMETER :: ISIZE = 1000000
INTEGER, PARAMETER :: SECT1 = (ISIZE/2) - 1, SECT2 = ISIZE - 1
INTEGER, DIMENSION(ISIZE), STATIC :: A
INTEGER IDVAR
OPEN(10, STATUS="OLD", ACCESS="DIRECT", ASYNCH="YES", RECL=(ISIZE/2)*4)
A = 0
! Reads in the first part of the array.
READ(10, REC=1) A(1:SECT1)
! Starts asynchronous read of the second part of the array.
READ(10,ID=IDVAR, REC=2) A(SECT1+1:SECT2)
! While the second asynchronous read is being performed,
! do some processing here.
CALL COMPARE(1, SECT1, ISIZE, A)
WAIT(ID=IDVAR)
CALL COMPARE(SECT1+1, SECT2, ISIZE, A)
END
Advancing and nonadvancing Input/Output
Advancing I/O positions the file after the last record that is read or written, unless
an error condition occurs.
Nonadvancing I/O can position the file at a character position within the current
record, or a subsequent record. With nonadvancing I/O, you can READ or WRITE
a record of the file by a sequence of I/O statements that each access a portion of
the record. You can also read variable-length records and about the length of the
records.
Nonadvancing I/O
! Reads digits using nonadvancing input
INTEGER COUNT
CHARACTER(1) DIGIT
OPEN (7)
DO
READ (7,FMT="(A1)",ADVANCE="NO",EOR=100) DIGIT
COUNT = COUNT + 1
210
XL Fortran: Language Reference

IF ((ICHAR(DIGIT).LT.ICHAR(’0’)).OR.(ICHAR(DIGIT).GT.ICHAR(’9’))) THEN
PRINT *,"Invalid character ", DIGIT, " at record position ",COUNT
STOP
END IF
END DO
100 PRINT *,"Number of digits in record = ", COUNT
END
! When the contents of fort.7 is ’1234\n’, the output is:
!
Number of digits in record =
4
User-defined derived-type Input/Output procedure interfaces
(Fortran 2003)
User-defined derived-type input/output procedures allow a program to override
the default handling of derived-type objects and values in data transfer
input/output statements.
A user-defined derived-type input/output procedure is a procedure accessible by a
dtio_generic_spec. A particular user-defined derived-type input/output procedure is
selected based on the existence of one of the following:
1. A suitable generic interface with both:
a. a dtio_generic_spec that is appropriate to the direction (read or write) and
form (formatted or unformatted) of the data transfer, and
b. a specific interface whose dtv argument is compatible with the effective
item. For more information on dtv see “User-defined derived-type
Input/Output procedures (Fortran 2003)” on page 168.
2. A suitable generic binding for the declared type of the effective item.
If a derived-type input/output procedure is selected as specified above, it is called
for any appropriate data transfer input/output statements executed in that scoping
unit. The procedure controls the actual data transfer operations for the
derived-type input/output list item.
A data transfer statement that includes a derived-type input/output list item and
that causes a user-defined derived-type input/output procedure to be invoked is
called a parent data transfer statement. A data transfer statement that is executed
while a parent data transfer statement is being processed, and that specifies the
unit passed into a user-defined derived-type input/output procedure, is called a
child data transfer statement.
A child data transfer statement is processed differently from a nonchild data
transfer statement in the following ways:
v
Executing a child data transfer statement does not position the file prior to data
transfer.
v
An unformatted child data transfer statement does not position the file after
data transfer is complete.
User-defined derived-type Input/Output (Fortran 2003)
For a particular derived type and a particular set of kind type parameter values,
there are four possible user-defined derived-type input/output procedures: one
each for formatted input, formatted output, unformatted input, and unformatted
output. You do not need to supply all four procedures. You can specify the
Chapter 9. XL Fortran Input/Output
211

procedures to be used for derived-type input/output by interface blocks or by
generic bindings, with a dtio_generic_spec (the values for dtio_generic_spec are given
in Table 18 on page 168).
While a parent data transfer statement is active, the following rules apply:
v
When a parent READ statement is active, an input/output statement does not
read from any external unit other than the one specified by the dummy
argument unit and does not write to any external unit.
v
When a parent WRITE or PRINT statement is active, an input/output statement
does not write to any external unit other than the one specified by the dummy
argument unit and does not read from any external unit.
v
A data transfer statement that specifies an internal file is permitted.
v
OPEN, CLOSE, BACKSPACE, ENDFILE, and REWIND statements are not
executed.
v
The user-defined procedure, and any procedures that it invokes, cannot define or
undefine any storage location referenced by any input/output list item, the
corresponding format, or any specifier in any active parent data transfer
statement, except through the dtv argument.
The following are additional rules for user-defined derived-type input/output
procedure data transfer statements:
v
The procedure may use a FORMAT with a DT edit descriptor for handling a
component of the derived type that is itself of a derived type. A child data
transfer statement that is a list-directed or namelist input/output statement may
contain a list item of derived type.
v
Because a child data transfer statement does not position the file prior to data
transfer, it starts transferring data from where the file was positioned by the
parent data transfer statement's most recently processed effective list item or
record positioning edit descriptor. This is not necessarily at the beginning of a
record.
v
A record positioning edit descriptor, such as TL and TR, used on unit by a child
data transfer statement, does not cause the record to be positioned before its
position at the time the procedure was invoked.
v
Parent and child data transfer statements cannot be asynchronous.
v
A child data transfer statement must not specify the ID=, POS=, or REC=
specifiers in an input/output control list.
Examples
Example 1:
! Example of an elemental function
PROGRAM P
INTERFACE
ELEMENTAL REAL FUNCTION LOGN(X,N)
REAL, INTENT(IN) :: X
INTEGER, INTENT(IN) :: N
END FUNCTION LOGN
END INTERFACE
REAL RES(100), VAL(100,100)
...
DO I=1,100
RES(I) = MAXVAL( LOGN(VAL(I,:),2) )
END DO
...
END PROGRAM P
212
XL Fortran: Language Reference

Example 2:
! Elemental procedure declared with a generic interface
INTERFACE RAND
ELEMENTAL FUNCTION SCALAR_RAND(x)
REAL, INTENT(IN) :: X
END FUNCTION SCALAR_RAND
FUNCTION VECTOR_RANDOM(x)
REAL X(:)
REAL VECTOR_RANDOM(SIZE(x))
END FUNCTION VECTOR_RANDOM
END INTERFACE RAND
REAL A(10,10), AA(10,10)
! The actual argument AA is a two-dimensional array. The procedure
! taking AA as an argument is not declared in the interface block.
! The specific procedure SCALAR_RAND is then called.
A = RAND(AA)
! The actual argument is a one-dimensional array section. The procedure
! taking a one-dimensional array as an argument is declared in the
! interface block. The specific procedure VECTOR_RANDOM is then called.
! This is a non-elemental reference since VECTOR_RANDOM is not elemental.
A(:,1) = RAND(AA(6:10,2))
END
File position before and after data transfer
For an explicit connection using an OPEN statement for sequential or stream I/O
that specifies the POSITION= specifier, you can position the file explicitly at the
beginning, at the end, where the position is on opening.
If the OPEN statement does not specify the POSITION= specifier:
v
If the STATUS= specifier has the value NEW or SCRATCH, the file position is
at the beginning.
IBM extension
v
If you specify STATUS='OLD' with the -qposition=appendold compiler option,
and the next operation that changes the file position is a WRITE statement, then
the file position is at the end. If these conditions are not met, the file position is
at the beginning.
v
If you specify STATUS='UNKNOWN' with the -qposition=appendunknown
compiler option, and the next operation is a WRITE statement, then the file
position is at the end. If these conditions are not met, the file position is at the
beginning.
After an implicit OPEN, the file position is at the beginning:
v
If the first I/O operation on the file is READ, the application reads the first
record of the file.
v
If the first I/O operation on the file is WRITE or PRINT, the application deletes
the contents of the file and writes at the first record.
End of IBM extension
Chapter 9. XL Fortran Input/Output
213

You can use a REWIND statement to position a file at the beginning. The
preconnected units 0, 5 and 6 are positioned as they come from the parent process
of the application.
The positioning of a file prior to data transfer depends on the method of access:
v
Sequential access for an external file:
– For advancing input, the file position is at the beginning of the next record.
This record becomes the current record.
– Advancing output creates a new record and becomes the last record of the
file.
v
Sequential access for an internal file:
– File position is at the beginning of the first record of the file. This record
becomes the current record.
v
Direct access:
– File position is at the beginning of the record that the REC= specifier
indicates. This record becomes the current record.
v
Stream access:
– File position is immediately before the file storage unit the POS= specifier
indicates. If there is no POS= specifier, the file position remains unchanged.
File positioning for a child data transfer statement is processed differently
from a nonchild data transfer statement in the following ways:
v
Executing a child data transfer statement does not position the file prior to data
transfer.
v
An unformatted child data transfer statement does not position the file after
data transfer is complete.
After advancing I/O data transfer, the file position is:
v
Beyond the endfile record if an end-of-file condition exists as a result of reading
an endfile record.
v
Beyond the last record read or written if no error or end-of-file condition exists.
That last record becomes the preceding record. A record written on a file
connected for sequential or formatted stream access becomes the last record of
the file.
After nonadvancing input the file position:
v
If no error condition or end-of-file condition occurs, but an end-of-record
condition occurs, the file position is immediately after the record read.
v
If no error condition, end-of-file condition or end-of-record condition occurs in a
nonadvancing input statement, the file position does not change.
v
If no error condition occurs in a nonadvancing output statement, the file
position does not change.
v
In all other cases, the file position is immediately after the record read or written
and that record becomes the preceding record.
If the file position is beyond the endfile record, a READ, WRITE, PRINT, or
ENDFILE statement can not execute if the compiler option -qxlf77=softeof is not
set. A BACKSPACE or REWIND statement can be used to reposition the file.
214
XL Fortran: Language Reference

Use the -qxlf77=softeof option to be able to read and write past the
end-of-file.
For formatted stream output with no errors, the terminal point of the file
is set to the highest-numbered position to which data was transferred by the
statement. For unformatted stream output with no errors, the file position is
unchanged. If the file position exceeds the previous terminal point of the file, the
terminal point is set to the file position. Use the POS= specifier with an empty
output list to extend the terminal point of the file without writing data. After data
transfer, if an error occurs, the file position is indeterminate.
Conditions and IOSTAT values
An IOSTAT value is a value assigned to the variable for the IOSTAT= specifier if
end-of-file condition, end-of-record condition or an error condition occurs during
an input/output statement. The IOSTAT= specifier reports the following types of
error conditions. If the input or output statement is successful, the IOSTAT value
is 0.
v
Catastrophic
v
Severe
v
Recoverable
v
Conversion
v
Language
End-of-record conditions
When an application encounters an end-of-record condition with the IOSTAT=
specifier, it sets the value of the variable specified by the IOSTAT= specifier to -4
and branches to the EOR= label if that label is present. If the IOSTAT= and EOR=
specifiers are not present on the I/O statement when an application encounters an
end-of-record condition, the application stops.
Table 20. IOSTAT values for end-of-record conditions
IOSTAT Value
End-of-Record Condition Description
-4
End of record encountered on a nonadvancing, format-directed READ
of an internal or external file.
End-of-file conditions
An end-of-file condition can occur in the following instances:
v
At the beginning of the execution of an input statement.
v
During execution of a formatted input statement that requires more than one
record through the interaction of the input list and the format.
v
During execution of a stream input statement.
v
When encountering an endfile record while reading of a file connected for
sequential access.
v
When attempting to read a record beyond the end of an internal file.
For stream access, an end-of-file condition occurs when you attempt to
read beyond the end of a file. An end-of-file condition also occurs if you attempt to
read beyond the last record of a stream file connected for formatted access.
Chapter 9. XL Fortran Input/Output
215

An end-of-file condition causes IOSTAT= to be set to one of the values defined
below and branches to the END= label if these specifiers are present on the input
statement. If the IOSTAT= and END= specifiers are not present on the input
statement when an end-of-file condition is encountered, the program stops.
Table 21. IOSTAT values for end-of-file conditions
IOSTAT Value
End-of-File Condition Description
-1
End of file encountered on sequential or
stream READ of an external file, or END= is
specified on a direct access read and the
record is nonexistent.
-1 1
End of file encountered on READ of an
internal file.
-2
End of file encountered on READ of an
internal file.
Note:
1 Fortran 2003. See the IOSTAT_END run-time option for more information.
Error conditions
Catastrophic errors
Catastrophic errors are system-level errors encountered within the run-time system
that prevent further execution of the program. When a catastrophic error occurs, a
short (non-translated) message is written to unit 0, followed by a call to the C
library routine abort(). A core dump can result, depending on how you configure
your execution environment.
Severe errors
A severe error cannot be recovered from, even if the ERR_RECOVERY run-time
option has been specified with the value YES. A severe error causes the IOSTAT=
specifier to be set to one of the values defined below and the ERR= label to be
branched to if these specifiers are present on the input/output statement. If the
IOSTAT= and ERR= specifiers are not present on the input/output statement
when a severe error condition is encountered, the program stops.
Table 22. IOSTAT Values for severe error conditions
IOSTAT Value
Error Description
1
END= is not specified on a direct access
READ and the record is nonexistent.
2
End of file encountered on WRITE of an
internal file.
6
File cannot be found and STATUS='OLD' is
specified on an OPEN statement.
10
Read error on direct file.
11
Write error on direct file.
12
Read error on sequential or stream file.
13
Write error on sequential or stream file.
14
Error opening file.
15
Permanent I/O error encountered on file.
37
Dynamic memory allocation failure - out of
memory.
216
XL Fortran: Language Reference

Table 22. IOSTAT Values for severe error conditions (continued)
IOSTAT Value
Error Description
38
REWIND error.
39
ENDFILE error.
40
BACKSPACE error.
107
File exists and STATUS='NEW' was specified
on an OPEN statement.
119
BACKSPACE statement attempted on unit
connected to a tape device.
122
Incomplete record encountered during direct
access READ.
130
ACTION='READWRITE' specified on an
OPEN statement to connect a pipe.
135
The user program is making calls to an
unsupported version of the XL Fortran
run-time environment.
139
I/O operation not permitted on the unit
because the file was not opened with an
appropriate value for the ACTION=
specifier.
142
CLOSE error.
144
error.
152
ACCESS='DIRECT' is specified on an OPEN
statement for a file that can only be accessed
sequentially.
153
POSITION='REWIND' or
POSITION='APPEND' is specified on an
OPEN statement and the file is a pipe.
156
Invalid value for RECL= specifier on an
OPEN statement.
159
External file input could not be flushed
because the associated device is not
seekable.
165
The record number of the next record that
can be read or written is out of the range of
the variable specified with the NEXTREC=
specifier of the INQUIRE statement.
169
The asynchronous I/O statement cannot be
completed because the unit is connected for
synchronous I/O only.
172
The connection failed because the file does
not allow asynchronous I/O.
173
An asynchronous READ statement was
executed while asynchronous WRITE
statements were pending for the same unit,
or an asynchronous WRITE statement was
executed while asynchronous READ
statements were pending for the same unit.
174
The synchronous I/O statement cannot be
completed because an earlier asynchronous
I/O statement has not been completed.
Chapter 9. XL Fortran Input/Output
217

Table 22. IOSTAT Values for severe error conditions (continued)
IOSTAT Value
Error Description
175
The WAIT statement cannot be completed
because the value of the ID= specifier is
invalid.
176
The WAIT statement cannot be completed
because the corresponding asynchronous
I/O statement is in a different scoping unit.
178
The asynchronous direct WRITE statement
for a record is not permitted because an
earlier asynchronous direct WRITE
statement for the same record has not been
completed.
179
The I/O operation cannot be performed on
the unit because there are still incomplete
asynchronous I/O operations on the unit.
181
A file cannot be connected to a unit because
multiple connections are allowed for
synchronous I/O only.
182
Invalid value for UWIDTH= option. It must
be set to either 32 or 64.
183
The maximum record length for the unit is
out of the range of the scalar variable
specified with the RECL= specifier in the
INQUIRE statement.
184
The number of bytes of data transmitted is
out of the range of the scalar variable
specified with the SIZE= or NUM= specifier
in the I/O statement.
185
A file cannot be connected to two units with
different UWIDTH values.
186
Unit numbers must be between 0 and
2,147,483,647.
192
The value of the file position is out of the
range of the scalar variable specified with
the POS= specifier in the INQUIRE
statement.
193
The value of the file size is out of the range
of the scalar variable specified with the
SIZE= specifier in the INQUIRE statement.
200
FLUSH error.
201
The unit specified in the FLUSH statement
is connected to a non-seekable file.
Recoverable errors
A recoverable error is an error that can be recovered from. A recoverable error
causes the IOSTAT= specifier to be set to one of the values defined below and the
ERR= label to be branched to if these specifiers are present on the input/output
statement. If the IOSTAT= and ERR= specifiers are not present on the
input/output statement and the ERR_RECOVERY run-time option is set to YES,
218
XL Fortran: Language Reference

recovery action occurs and the program continues. If the IOSTAT= and ERR=
specifiers are not present on the input/output statement and the ERR_RECOVERY
option is set to NO, the program stops.
Table 23. IOSTAT values for recoverable error conditions
IOSTAT Value
Error Description
16
Value of REC= specifier invalid on direct
I/O.
17
I/O statement not allowed on direct file.
18
Direct I/O statement on an unconnected
unit.
19
Unformatted I/O attempted on formatted
file.
20
Formatted I/O attempted on unformatted
file.
21
Sequential or stream I/O attempted on
direct file.
22
Direct I/O attempted on sequential or
stream file.
23
Attempt to connect a file that is already
connected to another unit.
24
OPEN specifiers do not match the connected
file's attributes.
25
RECL= specifier omitted on an OPEN
statement for a direct file.
26
RECL= specifier on an OPEN statement is
negative.
27
ACCESS= specifier on an OPEN statement is
invalid.
28
FORM= specifier on an OPEN statement is
invalid.
29
STATUS= specifier on an OPEN statement is
invalid.
30
BLANK= specifier on an OPEN statement is
invalid.
31
FILE= specifier on an OPEN or INQUIRE
statement is invalid.
32
STATUS='SCRATCH' and FILE= specifier
specified on same OPEN statement.
33
STATUS='KEEP' specified on CLOSE
statement when file was opened with
STATUS='SCRATCH'.
34
Value of STATUS= specifier on CLOSE
statement is invalid.
36
Invalid unit number specified in an I/O
statement.
47
A namelist input item was specified with
one or more components of nonzero rank.
48
A namelist input item specified a zero-sized
array.
Chapter 9. XL Fortran Input/Output
219

Table 23. IOSTAT values for recoverable error conditions (continued)
IOSTAT Value
Error Description
58
Format specification error.
93
I/O statement not allowed on error unit
(unit 0).
110
Illegal edit descriptor used with a data item
in formatted I/O.
120
The NLWIDTH setting exceeds the length of
a record.
125
BLANK= specifier given on an OPEN
statement for an unformatted file.
127
POSITION= specifier given on an OPEN
statement for a direct file.
128
POSITION= specifier value on an OPEN
statement is invalid.
129
ACTION= specifier value on an OPEN
statement is invalid.
131
DELIM= specifier given on an OPEN
statement for an unformatted file.
132
DELIM= specifier value on an OPEN
statement is invalid.
133
PAD= specifier given on an OPEN statement
for an unformatted file.
134
PAD= specifier value on an OPEN statement
is invalid.
136
ADVANCE= specifier value on a READ
statement is invalid.
137
ADVANCE='NO' is not specified when
SIZE= is specified on a READ statement.
138
ADVANCE='NO' is not specified when
EOR= is specified on a READ statement.
145
READ or WRITE attempted when file is
positioned after the endfile record.
163
Multiple connections to a file located on a
non-random access device are not allowed.
164
Multiple connections with ACTION='WRITE'
or ACTION='READWRITE' are not allowed.
170
ASYNCH= specifier value on an OPEN
statement is invalid.
171
ASYNCH= specifier given on an OPEN
statement is invalid because the FORM=
specifier is set to FORMATTED.
177
The unit was closed while there were still
incomplete asynchronous I/O operations.
191
The RECL= specifier is specified on an
OPEN statement that has
ACCESS='STREAM'.
194
The BACKSPACE statement specifies a unit
connected for unformatted stream I/O.
220
XL Fortran: Language Reference

Table 23. IOSTAT values for recoverable error conditions (continued)
IOSTAT Value
Error Description
195
POS= specifier on an I/O statement is less
than one.
196 1
The stream I/O statement cannot be
performed on the unit because the unit is
not connected for stream access.
197
POS= specifier on an I/O statement for a
unit connected to a non-seekable file.
198
Stream I/O statement on an unconnected
unit.
202 1
The ID=, POS=, or REC= specifier is not
allowed in a child READ or WRITE
statement.
203 1
The child READ or WRITE statement
specified a unit number which does not
match the unit number of the parent
statement.
204 1
The child READ or WRITE statement is not
allowed because the parent statement is not
a READ or WRITE statement.
205
The user-defined derived type I/O
procedure set the IOSTAT variable, but the
parent statement did not specify IOSTAT=.
209
The BLANK= specifier in the READ
statement has an illegal value.
210
A specifier in the READ statement has an
illegal value.
211
The DELIM= specifier in the WRITE
statement has an illegal value.
212 1
The data item in the formatted READ or
WRITE statement must be processed by a
DT edit descriptor. The READ or WRITE
statement is ignored.
213
The NAMELIST item name encountered by
the NAMELIST READ statement was not
followed by an equals ('=')
214
The DELIM= specifier in the internal WRITE
statement has an illegal value.
215
SIGN= specifier value on a WRITE
statement is invalid for the external file.
216
SIGN= specifier value on a WRITE
statement is invalid for the internal file.
217
SIGN= specifier given on an OPEN
statement for an unformatted file.
218
SIGN= specifier value on an OPEN
statement is invalid.
219
DECIMAL= specifier value is invalid for
external file.
220
DECIMAL= specifier value is invalid for
internal file.
Chapter 9. XL Fortran Input/Output
221

Table 23. IOSTAT values for recoverable error conditions (continued)
IOSTAT Value
Error Description
221
DECIMAL= specifier is used in an
unformatted I/O statement.
222
The ROUND= specifier was specified in an
OPEN statement with
FORM='UNFORMATTED'
223
The ROUND= specifier in the I/O statement
has an illegal value.
224
There is no outstanding asynchronous data
transfer specified by the ID= specifier.
225
A specifier in the OPEN statement has an
illegal value.
226
There is no outstanding asynchronous data
transfer specified.
227
Asynchronous data transfer error is not
associated with the specified unit.
228
The UFMT_LITTLEENDIAN option was
specified for a unit connected for formatted
I/O.
229
The v-list of the DT edit descriptor contains
an unexpected character.
230
The v-list of the DT edit descriptor contains
an unexpected non-printable character.
231
Asynchronous data transfer error is not
associated with the specified file.
232
OpenMP thread number is not available.
233
BACKSPACE performed on a unit that does
not have read access.
235
ENCODING= specifier is used in OPEN
statement for an unformatted file.
236
ENCODING= specifier has incorrect value in
the OPEN statement.
240 2
NEWUNIT= specifer in an OPEN statement
is missing FILE= or STATUS= with value
'SCRATCH'.
Note:
1. Fortran 2003
2. Fortran 2008
Conversion errors
A conversion error occurs as a result of invalid data or the incorrect length of data
in a data transfer statement. A conversion error causes the IOSTAT= specifier to be
set to one of the values defined below and the ERR= label to be branched to if
these specifiers are present on the input/output statement and the CNVERR
option is set to YES. If the IOSTAT= and ERR= specifiers are not present on the
input/output statement, both the CNVERR option and the ERR_RECOVERY
option are set to YES, recovery action is performed and the program continues. If
the IOSTAT= and ERR= specifiers are not present on the input/output statement,
222
XL Fortran: Language Reference

the CNVERR option is set to YES, the ERR_RECOVERY option is set to NO, and
the program stops. If CNVERR is set to NO, the ERR= label is never branched to
but the IOSTAT= specifier may be set, as indicated below.
Table 24. IOSTAT values for conversion error conditions
IOSTAT
IOSTAT set if
Value
Error Description
CNVERR=NO
3
End of record encountered on an unformatted file.
no
4
End of record encountered on a formatted external file
no
using advancing I/O.
5
End of record encountered on an internal file.
no
7
Incorrect format of list-directed input found in an external
yes
file.
8
Incorrect format of list-directed input found in an internal
yes
file.
9
List-directed or NAMELIST data item too long for the
yes
internal file.
41
Valid logical input not found in external file.
no
42
Valid logical input not found in internal file.
no
43
Complex value expected using list-directed or NAMELIST
no
input in external file but not found.
44
Complex value expected using list-directed or NAMELIST
no
input in internal file but not found.
45
NAMELIST item name specified with unknown or invalid
no
derived-type component name in NAMELIST input.
46
NAMELIST item name specified with an invalid substring
no
range in NAMELIST input.
49
List-directed or namelist input contained an invalid
no
delimited character string.
56
Invalid digit found in input for B, O or Z format edit
no
descriptors.
84
NAMELIST group header not found in external file.
yes
85
NAMELIST group header not found in internal file.
yes
86
Invalid NAMELIST input value found in external file.
no
87
Invalid NAMELIST input value found in internal file.
no
88
Invalid name found in NAMELIST input.
no
90
Invalid character in NAMELIST group or item name in
no
input.
91
Invalid NAMELIST input syntax.
no
92
Invalid subscript list for NAMELIST item in input.
no
94
Invalid repeat specifier for list-directed or NAMELIST
no
input in external file.
95
Invalid repeat specifier for list-directed or NAMELIST
no
input in internal file.
96
Integer overflow in input.
no
97
Invalid decimal digit found in input.
no
98
Input too long for B, O or Z format edit descriptors.
no
Chapter 9. XL Fortran Input/Output
223

Table 24. IOSTAT values for conversion error conditions (continued)
IOSTAT
IOSTAT set if
Value
Error Description
CNVERR=NO
121
Output length of NAMELIST item name or NAMELIST
yes
group name is longer than the maximum record length or
the output width specified by the NLWIDTH option.
Fortran 90, 95, 2003, and 2008 standard language errors
Fortran 90 standard language errors
A Fortran 90 language error results from the use of XL Fortran extensions to the
Fortran 90 language that cannot be detected at compile time. A Fortran 90
language error is considered a severe error when the LANGLVL run-time option
has been specified with the value 90STD and the ERR_RECOVERY run-time
option has either not been set or is set to NO. If both LANGLVL=90STD and
ERR_RECOVERY=YES have been specified, the error is considered a recoverable
error. If LANGLVL= EXTENDED is specified, the error condition is not considered
an error.
Fortran 95 standard language errors
A Fortran 95 language error results from the use of XL Fortran extensions to the
Fortran 95 language that cannot be detected at compile time. A Fortran 95
language error is considered a severe error when the LANGLVL run-time option
has been specified with the value 95STD and the ERR_RECOVERY run-time
option has either not been set or is set to NO. If both LANGLVL=95STD and
ERR_RECOVERY=YES have been specified, the error is considered a recoverable
error. If LANGLVL=EXTENDED is specified, the error condition is not considered
an error.
Fortran 2003 standard language errors
A Fortran 2003 Standard language error results from the use of XL Fortran
extensions to the Fortran 2003 language standard that cannot be detected at
compile time. A Fortran 2003 language error is considered a severe error when the
LANGLVL run-time option has been specified with the value 2003STD and the
ERR_RECOVERY run-time option has either not been set or is set to NO. If both
LANGLVL=2003STD and ERR_RECOVERY=YES have been specified, the error is
considered a recoverable error. If LANGLVL=EXTENDED is specified, the error
condition is not considered an error.
Fortran 2008 standard language errors
A Fortran 2008 Standard language error results from the use of XL Fortran
extensions to the Fortran 2008 language standard that cannot be detected at
compile time. A Fortran 2008 language error is considered a severe error when the
LANGLVL run-time option has been specified with the value 2008STD and the
ERR_RECOVERY run-time option has either not been set or is set to NO. If both
LANGLVL=2008STD and ERR_RECOVERY=YES have been specified, the error is
considered a recoverable error. If LANGLVL=EXTENDED is specified, the error
condition is not considered an error.
224
XL Fortran: Language Reference

Table 25. IOSTAT Values for Fortran 90, 95, 2003, and 2008 Standard Language Error
Conditions
IOSTAT Value
Error Description
53
Mismatched edit descriptor and item type in
formatted I/O.
58
Format specification error.
140
Unit is not connected when the I/O
statement is attempted. Only for READ,
WRITE, PRINT, REWIND, and ENDFILE.
141
Two ENDFILE statements without an
intervening REWIND or BACKSPACE on
the unit.
151
The FILE= specifier is missing and the
STATUS= specifier does not have a value of
'SCRATCH' on an OPEN statement.
187
NAMELIST comments are not allowed by
the Fortran 90 standard.
199
STREAM is not a valid value for the
ACCESS= specifier on an OPEN statement
in Fortran 90 or Fortran 95.
Chapter 9. XL Fortran Input/Output
225

226
XL Fortran: Language Reference

Chapter 10. Input/Output formatting
Formatted READ, WRITE and PRINT data transfer statements use formatting
information to direct the conversion between internal data representations and
character representations in a formatted record. You can control the conversion
process, called editing, by using a formatting type. The Formatting and Access Types
table details the access types that support each formatting type.
Table 26. Formatting and access types
Formatting Type
Access Types
Format-directed
sequential, direct, and stream
List-directed
sequential and stream
Namelist
sequential and stream
Editing occurs on all fields in a record. A field is the part of a record that is read
on input or written on output when format control processes a data or character
string edit descriptor. The field width is the size of that field in characters.
Format-directed formatting
Format-directed formatting allows you to control editing using edit descriptors in a
format specification. Specify a format specification in a FORMAT statement or as
the value of a character array or character expression in a data transfer statement.
Edit descriptors allow you to control editing in the following ways:
v
Data edit descriptors allow you to specify editing by data type
v
Control edit descriptors focus on the editing process
v
Character string edit descriptors control string outputs
Complex editing
To edit complex values, you must specify complex editing by using a pair of data
edit descriptors. A complex value is a pair of separate real components. When
specifying complex editing, the first edit descriptor applies to the real part of the
number. The second edit descriptor applies to the imaginary part of the number.
You can specify different edit descriptors for a complex editing pair and use one or
more control edit descriptors between the edit descriptors in that pair. You must
not specify data edit descriptors between the edit descriptors in that pair.
Data edit descriptors
Data edit descriptors allow you to specify editing by data type. You can use them
to edit character, numeric, logical, and derived type data. The Data Edit Descriptors
table contains a complete list of all character, character string, numeric, logical, and
derived type edit descriptors. Numeric data refers to integer, real, and complex
values.
© Copyright IBM Corp. 1996, 2012
227

Table 27. Data edit descriptors
Forms
Use
Edits character values
A
Aw
Edits binary values
Bw
Bw.m
Edits an item of derived type. You can use a procedure
DT •
instead of the default input/output formatting of an item
DTchar-literal-constant
of derived type.
DT(v-list)
DTchar-literal-constant(v-list)
Edits real and complex numbers with exponents
Ew.d
Ew.dEe
Ew.dDe *
Ew.dQe *
Dw.d
ENw.d
ENw.dEe
ESw.d
ESw.dEe
Qw.d *
Fw.d
Edits real and complex numbers without exponents
Edits data fields of any intrinsic type, with the output
Gw.d
format adapting to the type of the data and, if the data is
Gw.dEe
of type real, the magnitude of the data
Gw.dDe *
Gw.dQe *
Edits integer numbers
Iw
Iw.m
Lw
Edits logical values
Edits octal values
Ow
Ow.m
Q *
Returns the count of characters remaining in an input
record *
Edits hexadecimal values
Zw
Zw.m
where:
char-literal-constant
Specifies a character literal constant in a DT edit descriptor that must not
have a kind parameter.
v
Fortran 2003
*
Specifies an IBM extension.
d
Specifies the number of digits to the right of the decimal point.
228
XL Fortran: Language Reference

e
Specifies the number of digits in the exponent field.
m
Specifies the number of digits to print.
n
Specifies the number of characters in a literal field. Blanks are included in
character count.
v-list
A comma-separated list of integer literal constants that have the same kind
parameter.
w
Specifies the width of a field including all blanks as a positive value.
If you specify the B, F, I, O, or Z, edit descriptors on output, the value of
w can be zero.
Rules for Data Edit Descriptor and Modifiers
You must not specify kind type parameters.
Edit descriptor modifiers must be unsigned integer literal constants.
IBM extension
For the w, m, d, and e modifiers, you must enclose a scalar integer expression in
angle brackets (< and >). See “Variable format expressions (IBM extension)” on
page 363 for details.
Note:
There are two types of Q data edit descriptor:
extended precision Q
is the Q edit descriptor with theQw.d syntax
character count Q
is the Q edit descriptor with the Q syntax
End of IBM extension
Rules for numeric edit descriptors on input
Leading blanks are not significant. You can control the interpretation of other
blanks using the BLANK= specifier in the OPEN or READ statements and the BN
and BZ edit descriptors. A field of all blanks is treated as zero.
Plus signs are optional, though you must not specify plus signs for the B, O, and Z
edit descriptors.
In F, E, EN, ES, D, G, and extended precision Q editing, a decimal point appearing
in the input field overrides the portion of an edit descriptor that specifies the
decimal point location. The field can contain more digits than can be represented
internally.
Input of IEEE Exceptional Values
For real and complex editing, XL Fortran can now input IEEE exceptional values.
The Fortran 2003 standard specifies a set of values for IEEE NaN (Not-a-Number)
and IEEE infinity which XL Fortran now supports, along with another set of IEEE
NaN values that are unique to XL Fortran. Input of IEEE exceptional values under
real and complex editing are governed by the field width of the real or complex
Chapter 10. Input/Output formatting
229

edit descriptor. IEEE exceptional values are case insensitive during input. The F, E,
EN, ES, D, G, and Q edit descriptors support the input of IEEE exceptional values.
The Fortran 2003 standard allows the following values for IEEE infinity: 'INF',
'+INF', '-INF', 'INFINITY', '+INFINITY', or '-INFINITY'. These values can be
preceded and followed by blanks.
The Fortran 2003 standard allows the following values for IEEE NaN: 'NAN',
'+NAN', or '-NAN'. The sign that precedes 'NAN' will not have any significant
meaning in XL Fortran. These values can also be preceded and followed by blanks.
IEEE NaN can also be directly followed by zero or more characters in parentheses.
The parentheses are used to indicate a quiet or signaling NaN. If only 'NAN' or
'NAN()' is specified it is interpreted as a quiet NaN. 'NAN(Q)' will be interpreted
as a quiet NaN, and 'NAN(S)' as a signaling NaN. Any other alphanumeric
characters specified inside the parentheses will have no significant meaning and
will be interpreted as a quiet NaN by default.
As an IBM extension, XL Fortran allows the following values for IEEE NaN:
'NANQ' or 'NANS'. These exceptional values are case insensitive. 'NANQ' will be
interpreted as a quiet NaN and 'NANS' as a signaling NaN. This form of IEEE
NaN will only be allowed when the runtime option 'langlvl' is set to 'extended'.
Rules for numeric data edit descriptors on output
Characters are right-justified in the field.
When the number of characters in a field is less than the field width, leading
blanks fill the remaining field space.
When the number of characters in a field is greater than the field width, or if an
exponent exceeds its specified width, asterisks fill the entire field space.
A minus sign prefixes a negative value. A positive or zero value does not receive a
plus sign prefix on output, unless you specify the S, SP, or SS edit descriptors.
If you specify the -qxlf90 compiler option the E, D, Q(Extended Precision), F, EN,
ES and G(General Editing) edit descriptors output a negative value differently
depending on the signedzero suboption.
v
If you specify the signedzero suboption, the output field contains a minus sign
for a negative value, even if that value is negative zero. This behavior conforms
to the Fortran 95, Fortran 2003, and Fortran 2008 standards.
XL Fortran does not evaluate a REAL(16) internal value of zero as a
negative zero.
v
If you specify the nosignedzero suboption, a minus sign is not written to the
output field for a value of zero, even if the internal value is negative.
The EN and ES edit descriptors output a minus sign when the value is negative
for the signedzero and nosignedzero suboptions.
Output of IEEE Exceptional Values
XL Fortran supports output of IEEE exceptional values for real and complex
editing. Output of IEEE exceptional values can be Fortran 2003 standard compliant
or compatible with previous releases of XL Fortran. A new compiler option and
runtime option control the output of IEEE exceptional values. The
-qxlf2003=oldnaninf compiler option will output IEEE exceptional values like
230
XL Fortran: Language Reference

previous releases of XL Fortran; whereas, -qxlf2003=nooldnaninf will output IEEE
exceptional values in accordance with the Fortran standard. In addition to the
compiler option, a new runtime option, naninfoutput, can force the output of IEEE
exceptional values to be Fortran 2003 standard compliant or compliant to the
previous releases of XL Fortran. For more information on the naninfoutput
runtime option see: Running XL Fortran programs section of the XL Fortran
Compiler Reference. The F, E, EN, ES, D, G, and Q edit descriptors support the
output of IEEE exceptional values.
Output of IEEE exceptional values under real and complex editing are governed by
the field width of the real or complex edit descriptor. IEEE exceptional values are
case sensitive during output.
Fortran 2003 Standard Output
IEEE infinity is output as 'Inf'. It can be preceded by as many blanks as necessary
to be right justified. If the internal value is positive infinity, it can also be directly
preceded by an optional plus sign if the field width allows for it. If the field width
is less than three, asterisks are output instead. However, if the SIGN= specifier has
a value of 'PLUS' or the 'sp' descriptor is used, then the plus sign is mandatory
and the minimum field width is 4. If the internal value is negative infinity, it must
be preceded by a negative sign. The minimum field width is 4. If the field width is
less than four, asterisks are output instead.
IEEE Nan is output as 'NaN'. It can be preceded by as many blanks as necessary to
be right justified. If the field width is greater than or equal to five, the standard
allows for zero or more alphanumeric characters in parentheses to optionally
follow the 'NaN'. XL Fortran will output 'NaN(Q)' for a quiet NaN and 'NaN(S)'
for a signaling NaN if the field width is greater than five, otherwise only a 'NaN'
is output. If the field width is less than three, asterisks are output instead.
Previous XL Fortran Output
IEEE infinity is output as 'INF'. It can be preceded by as many blanks as necessary
to be right justified. If the field width is less than three, asterisks are output
instead.
IEEE NaN is output as 'NaNQ' for a quiet NaN and 'NaNS' for a signaling NaN. It
can also be directly preceded by an optional sign. It can be preceded by as many
blanks as necessary to be right justified. If the field width is less than four,
asterisks are output instead.
Rules for derived type edit descriptors (Fortran 2003)
The DT edit descriptor allows you to provide a procedure instead of the default
input/output formatting for processing a list item of derived type. If you specify
the optional char-literal-constant, the character value DT is concatenated to the
char-literal-constant and passed to your user-defined derived-type input/output
procedure as the iotype argument.
The values in the v-list of the DT edit descriptor are passed to the derived-type
input/output procedure you define as the v_list array argument.
If a derived type variable or value corresponds to the DT edit descriptor, there
must be an accessible interface to a derived type input/output procedure for that
derived type.
Chapter 10. Input/Output formatting
231

You must not specify a DT edit descriptor as a non-derived type list item.
Control edit descriptors
Table 28. Control edit descriptors
Forms
Use
Specifies the end of data transfer on the current record
/
r /
:
Specifies the end of format control if there are no more items in the
input/output list
$ *
Suppresses end-of-record in output *
BN
Ignores nonleading blanks in numeric input fields
BZ
Interprets nonleading blanks in numeric input fields as zeros
DC v
Specifies decimal comma as the decimal edit mode.
DP v
Specifies decimal point as the decimal edit mode.
kP
Specifies a scale factor for real and complex items.
RU v
Specifies the UP rounding mode.
RC v
Specifies the COMPATIBLE rounding mode.
RD v
Specifies the DOWN rounding mode.
RN v
Specifies the NEAREST rounding mode.
RP v
Specifies the PROCESSOR_DEFINED rounding mode.
RZ v
Specifies the ZERO rounding mode.
Specifies that plus signs are not to be written
S
SS
SP
Specifies that plus signs are to be written
Tc
Specifies the absolute position in a record from which, or to which,
the next character is transferred
TLc
Specifies the relative position (backward from the current position
in a record) from which, or to which, the next character is
transferred
Specifies the relative position (forward from the current position in
TRc
a record) from which, or to which, the next character is transferred
oX
where:
v
Fortran 2003
*
specifies an IBM extension.
r
is a repeat specifier. It is an unsigned, positive, integer literal constant.
k
specifies the scale factor to be used. It is an optionally signed, integer
literal constant.
c
specifies the character position in a record. It is an unsigned, nonzero,
integer literal constant.
o
is the relative character position in a record. It is an unsigned, nonzero,
integer literal constant.
232
XL Fortran: Language Reference

Rules for Control Edit Descriptors and Modifiers
You must not specify kind type parameters.
r, k, c, and o can also be expressed as an arithmetic expression enclosed
by angle brackets that evaluates into an integer value.
Character string edit descriptors
Character string edit descriptors allow you to edit character data.
Forms
Use
Page
nHstr
Outputs a character string (str)
“H Editing” on
page 246
Outputs a character string (str)
“Apostrophe/
'str'
Double quotation
"str"
mark editing”
n
is the number of characters in a literal field. It is an unsigned, positive,
integer literal constant. Blanks are included in character count. A kind type
parameter cannot be specified.
Apostrophe/Double quotation mark editing
Purpose
The apostrophe/double quotation mark edit descriptor specifies a character literal
constant in an output format specification.
Syntax
v
character string
v
"character string"
Rules
The width of the output field is the length of the character literal constant. See
“Character” on page 42 for additional information on character literal constants.
IBM extension
Note:
1. A backslash is recognized, by default, as an escape sequence, and as a
backslash character when the -qnoescape compiler option is specified. See
escape sequences for more information.
2. XL Fortran provides support for multibyte characters within character
constants, Hollerith constants, character-string edit descriptors, and comments.
This support is provided through the -qmbcs option. Assignment of a constant
containing multibyte characters to a variable that is not large enough to hold
the entire string may result in truncation within a multibyte character.
3. Support is also provided for Unicode characters and filenames. If the
environment variable LANG is set to UNIVERSAL and the -qmbcs compiler
option is specified, the compiler can read and write Unicode characters and
filenames.
End of IBM extension
Chapter 10. Input/Output formatting
233

Examples
ITIME=8
WRITE(*,5) ITIME
5
FORMAT(’The value is -- ’,I2) ! The value is -- 8
WRITE(*,10) ITIME
10
FORMAT(I2,’o’’clock’) ! 8o’clock
WRITE(*,’(I2,7Ho’’clock)’) ITIME ! 8o’clock
WRITE(*,15) ITIME
15
FORMAT("The value is -- ",I2) ! The value is -- 8
WRITE(*,20) ITIME
20
FORMAT(I2,"o’clock") ! 8o’clock
WRITE(*,’(I2,"o’’clock")’) ITIME ! 8o’clock
Effective list items (Fortran 2003)
This section discusses the rules for expanding a data transfer statement's array and
derived-type input/output list items. The scalar objects that result from the
application of these rules are called effective items. Zero-sized arrays and
implied-DO lists with an iteration count of zero do not contribute to the effective
list items. A scalar character item of zero length is an effective list item.
The following rules are re-applied to each expanded list item until none of the
rules applies.
1. If an array appears as an input/output list item, it is treated as if the elements,
if any, were specified in array element order.
2. If a list item of derived type in an unformatted input/output statement is not
processed by a user-defined derived-type input/output procedure, and if any
subobject of that list item would be processed by a user-defined derived-type
input/output procedure, the list item is treated as if all of the components of
the object were specified in the list in component order. Those components are
accessible in the scoping unit containing the input/output statement, and they
must not be pointers or allocatable.
3. An effective input/output list item of derived type in an unformatted
input/output statement is treated as a single value in a processor-dependent
form, unless the list item or a subobject of a list item is processed by a
user-defined derived-type input/output procedure.
4. If a list item of derived type in a formatted input/output statement is not
processed by a user-defined derived-type input/output procedure, that list item
is treated as if all of the components of the list item were specified in the list in
component order. Those components are accessible in the scoping unit
containing the input/output statement, and they must not be pointers or
allocatable.
5. If a derived-type list item is not treated as a list of its individual components,
its ultimate components cannot have the POINTER or ALLOCATABLE
attribute, unless the list item is processed by a user-defined derived-type
input/output procedure.
Interaction of Input/Output lists and format specifications
Beginning format-directed formatting initiates format control. Each action of format
control depends on the next edit descriptor in the format specification, and on the
next effective item in the input/output list, if one exists.
If an input/output list specifies at least one effective item, at least one data edit
descriptor must exist in the format specification. Note that an empty format
specification (parentheses only) can be used only if there are no effective items in
the input/output list or if each item is a zero-sized array or an implied-DO list
234
XL Fortran: Language Reference

with an iteration count of zero. If this is the case and advancing input/output is in
effect, one input record is skipped, or one output record containing no characters is
written. For nonadvancing input/output, the file position is left unchanged.
A format specification is interpreted from left to right, except when a repeat
specification (r) is present. A format item that is preceded by a repeat specification
is processed as a list of r format specifications or edit descriptors identical to the
format specification or edit descriptor without the repeat specification.
One effective item specified by the input/output list corresponds to each data edit
descriptor. An effective list item of complex type requires the interpretation of two
F, E, EN, ES, D, G, or extended precision Q edit descriptors. No item specified by
the input/output list corresponds to a control edit descriptor or character string
edit descriptor. Format control communicates information directly with the record.
Format control operates as follows:
1. If a data edit descriptor is encountered, format control processes an effective
input/output list item, if there is one, or terminates the input/output command
if the list is empty. If the effective list item processed is of type complex, any
two edit descriptors are processed.
2. The colon edit descriptor terminates format control if no more effective items
are in the input/output list. If more effective items are in the input/output list
when the colon is encountered, it is ignored.
3. If the end of the format specification is reached, format control terminates if the
entire effective input/output list has been processed, or control reverts to the
beginning of the format item terminated by the last preceding right parenthesis.
The following items apply when the latter occurs:
v
The reused portion of the format specification must contain at least one data
edit descriptor.
v
If reversion is to a parenthesis that is preceded by a repeat specification, the
repeat specification is reused.
v
Reversion, of itself, has no effect on the scale factor, on the S, SP, or SS edit
descriptors, or on the BN or BZ edit descriptors.
v
If format control reverts, the file is positioned in a manner identical to the
way it is positioned when a slash edit descriptor is processed.
During a read operation, any unprocessed characters of the record are
skipped whenever the next record is read. A comma or semicolon can be used as a
value separator for noncharacter data in an input record processed under
format-directed formatting. The value separator will override the format width
specifications when it appears before the end of the field width. For example, the
format (I10,F20.10,I4) will read the following record correctly:
-345, .05E-3, 12
It is important to consider the maximum size record allowed on the input/output
medium when defining a Fortran record by a FORMAT statement. For example, if
a Fortran record is to be printed, the record should not be longer than the printer's
line length.
Chapter 10. Input/Output formatting
235

Comma-separated Input/Output (IBM extension)
When reading floating-point data using format-directed input/output, a comma
that appears in the input terminates the field. This can be useful for reading files
containing comma-separated values.
For example, the following program reads two reals using the E edit descriptor. It
requires that the field width be 16 characters. The program attempts to read the
remaining characters in the record as a character string.
> cat read.f
real a,b
character*10 c
open(11, access=’sequential’, form=’formatted’)
read(11, ’(2e16.10, A)’) a,b,c
print *, a
print *, b
print *, c
end
If the floating-point fields are 16 characters wide, as the format specifies, the
program executes correctly. (0.4000000000E+02 is 16 characters long.)
> cat fort.11
0.4000000000E+020.3000000000E+02hello
> a.out
40.00000000
30.00000000
hello
But if the floating-point input contains less than 16 characters, errors occur because
parts of the next field are read. (0.400000E+02 is 12 characters long.)
> cat fort.11
0.400000E+020.3000000E+02hello
> a.out
1525-097 A READ statement using decimal base input found the invalid digit
’.’ in the input file.
The program will recover by assuming a zero in its place.
1525-097 A READ statement using decimal base input found the invalid digit
’h’ in the input file.
The program will recover by assuming a zero in its place.
1525-097 A READ statement using decimal base input found the invalid digit
’e’ in the input file.
The program will recover by assuming a zero in its place.
1525-097 A READ statement using decimal base input found the invalid digit
’l’ in the input file.
The program will recover by assuming a zero in its place.
1525-097 A READ statement using decimal base input found the invalid digit
’l’ in the input file.
The program will recover by assuming a zero in its place.
1525-097 A READ statement using decimal base input found the invalid digit
’o’ in the input file.
The program will recover by assuming a zero in its place.
INF
0.0000000000E+00
If you use commas to terminate the fields, the floating-point values are read
correctly. (0.400000E+02 is 12 characters long, but the fields are separated by
commas.)
236
XL Fortran: Language Reference

> cat fort.11
0.400000E+02,0.3000000E+02,hello
> a.out
40.00000000
30.00000000
hello
If decimal comma mode is in effect, a semicolon acts as a value separator instead
of a comma.
Data edit descriptors
In the examples of data edit descriptors, a lowercase b in the Output column
indicates that a blank appears at that position.
A (Character) Editing
Purpose
The A edit descriptor directs the editing of character values. It can correspond to
an input/output list item of type character or any other type. The kind type
parameter of all characters transferred and converted is implied by the
corresponding list item.
Syntax
v
A
v
Aw
Rules
On input, if w is greater than or equal to the length (call it len) of the input list
item, the rightmost len characters are taken from the input field. If the specified
field width is less than len, the w characters are left-justified, with ( len - w )
trailing blanks added.
On output, if w is greater than len, the output field consists of ( w - len ) blanks
followed by the len characters from the internal representation. If w is less than or
equal to len, the output field consists of the leftmost w characters from the internal
representation.
If w is not specified, the width of the character field is the length of the
corresponding input/output list item.
During formatted stream access, character output is split across more than
one record if it contains newline characters.
B (Binary) Editing
Purpose
The B edit descriptor directs editing between values of any type in internal form
and their binary representation. (A binary digit is either 0 or 1.)
Syntax
v
Bw
v
Bw.m
Chapter 10. Input/Output formatting
237

Rules
On input, w binary digits are edited and form the internal representation for the
value of the input list item. The binary digits in the input field correspond to the
rightmost binary digits of the internal representation of the value assigned to the
input list item. m has no effect on input.
On input, w must be greater than zero.
On output, w can be zero. If w is zero, the output field consists of the least number
of characters required to represent the output value.
The output field for Bw consists of zero or more leading blanks followed by the
internal value in a form identical to the binary digits without leading zeros. Note
that a binary constant always consists of at least one digit.
The output field for Bw.m is the same as for Bw, except that the digit string
consists of at least m digits. If necessary, the digit string is padded with leading
zeros. The value of m must not exceed the value of w unless w is zero. If m is zero
and the value of the internal data is zero, the output field consists of only blank
characters, regardless of the sign control in effect.
If m is zero, w is positive and the value of the internal datum is zero, the output
field consists of w blank characters. If both w and m are zero, and the value of the
internal datum is zero, the output field consists of only one blank character.
If the nooldboz suboption of the -qxlf77 compiler option is specified (the default),
asterisks are printed when the output field width is not sufficient to contain the
entire output. On input, the BLANK= specifier and the BN and BZ edit descriptors
affect the B edit descriptor.
If the oldboz suboption of the -qxlf77 compiler option is specified, the
following occurs on output:
v
Bw is treated as Bw.m, with m assuming the value that is the minimum of w and
the number of digits required to represent the maximum possible value of the
data item.
v
The output consists of blanks followed by at least m digits. These are the
rightmost digits of the number, zero-filled if necessary, until there are m digits. If
the number is too large to fit into the output field, only the rightmost m digits
are output.
If w is zero, the oldboz suboption will be ignored.
With the oldboz suboption, the BLANK= specifier and the BN and BZ edit
descriptors do not affect the B edit descriptor.
Examples
Example 1: Examples of B editing on input
Input
Format
Value
111
B3
7
110
B3
6
Example 2: Examples of B editing on output
238
XL Fortran: Language Reference

Value
Format
Output
Output
(with -qxlf77=oldboz)
(with -qxlf77=nooldboz)
7
B3
111
111
6
B5
00110
bb110
17
B6.5
b10001
b10001
17
B4.2
0001
****
22
B6.5
b10110
b10110
22
B4.2
0110
****
0
B5.0
bbbbb
bbbbb
2
B0
10
10
E, D, and Q (Extended Precision) Editing
Purpose
The E, D, and extended precision Q edit descriptors direct editing between real
and complex numbers in internal form and their character representations with
exponents. An E, D, or extended precision Q edit descriptor can correspond to an
input/output list item of type real, to either part (real or imaginary) of an
input/output list item of type complex,
or to any other type in XL
Fortran, as long as the length is at least 4 bytes.
Syntax
v
Ew.d
v
Ew.d Ee
v
Dw.d
v
Ew.d De
v
Ew.d Qe
v
Qw.d
Rules
The form of the input field is the same as for F editing. e has no effect on input.
The form of the output field for a scale factor of 0 is:
.
digit_string
decimal_exponent
+
0
-
digit_string
is a digit string whose length is the d most significant digits of the value
after rounding.
decimal_exponent
is a decimal exponent of one of the following forms (z is a digit):
Absolute Value of Exponent (with scale
Edit Descriptor
factor of 0)
Form of Exponent
Ew.d
|decimal_exponent| ≤ 99
E±z z
1 2
Ew.d
99<|decimal_exponent| ≤ 309
±z z z
1 2 3
Ew.dEe
|decimal_exponent| ≤ (10e)-1
E±z z ...z
1 2
e
Chapter 10. Input/Output formatting
239

Absolute Value of Exponent (with scale
Edit Descriptor
factor of 0)
Form of Exponent
Ew.dDe *
|decimal_exponent| ≤ (10e)-1 *
D±z z ...z *
1 2
e
Ew.dQe *
|decimal_exponent| ≤ (10e)-1 *
Q±z z ...z *
1 2
e
Dw.d
|decimal_exponent| ≤ 99
D±z z
1 2
Dw.d
99<|decimal_exponent| ≤ 309
±z z z
1 2 3
Qw.d *
|decimal_exponent| ≤ 99 *
Q±z z *
1 2
Qw.d *
99<|decimal_exponent| ≤ 309 *
±z z z *
1 2 3
Note: * IBM Extensions
The scale factor k (see “P (Scale Factor) Editing” on page 255) controls decimal
normalization. If -d<k≤0, the output field contains |k| leading zeros and d - |k|
significant digits after the decimal symbol. If 0<k<d+2, the output field contains k
significant digits to the left of the decimal symbol and d-k+1 significant digits to
the right of the decimal symbol. You cannot use other values of k.
For general information about numeric editing on input, see “Rules for numeric
edit descriptors on input” on page 229.
For more information regarding numeric editing on output, see “Rules for numeric
data edit descriptors on output” on page 230.
Examples
Example 1: Examples of E, D, and extended precision Q editing on input
(Assume BN editing is in effect for blank interpretation.)
Input
Format
Value
12.34
E8.4
12.34
.1234E2
E8.4
12.34
2.E10
E12.6E1
2.E10
Example 2: Examples of E, D, and extended precision Q editing on output
Value
Format
Output
Output
(with -qxlf77=noleadzero)
(with -qxlf77=leadzero)
1234.56
E10.3
bb.123E+04
b0.123E+04
1234.56
D10.3
bb.123D+04
b0.123D+04
DT Editing (Fortran 2003)
Purpose
The DT edit descriptor allows you to specify that a user-defined procedure is
called instead of the default input/output formatting for processing an
input/output list item of derived type
Syntax
v
DT
v
DTchar-literal-constant
v
DT( v-list )
v
DTchar-literal-constant( v-list )
240
XL Fortran: Language Reference

Rules
The iotype dummy argument passed to the user-defined input/output procedure
contains the text from the char-literal-constant, prefixed with DT. If you do not
include a char-literal-constant, the iotype argument contains only DT.
The v-list is passed to the user-defined input/output procedure in the v_list integer
array dummy argument. If you do not include a v-list, the v_list dummy argument
is a zero-sized array.
When you use the DT edit descriptor, the corresponding derived type
input/output list item must be associated with an appropriate user-defined
derived type input/output procedure.
EN Editing
Purpose
The EN edit descriptor produces an output field in the form of a real number in
engineering notation such that the decimal exponent is divisible by 3 and the
absolute value of the significand is greater than or equal to 1 and less than 1000,
except when the output value is zero. The scale factor has no effect on output.
The EN edit descriptor can correspond to an input/output list item of type real, to
either part (real or imaginary) of an input/output list item of type complex,
or to any other type in XL Fortran, as long as the length is at least 4
bytes.
Syntax
v
ENw.d
v
ENw.dEe
Rules
The form and interpretation of the input field is the same as for F editing.
The form of the output field is:
.
digit_string
exp
+
yyy
-
yyy
are the 1 to 3 decimal digits representative of the most significant digits of
the value of the datum after rounding (yyy is an integer such that 1 ≤ yyy <
1000 or, if the output value is zero, yyy = 0).
digit_string
are the d next most significant digits of the value of the datum after
rounding.
exp
is a decimal exponent, divisible by 3, of one of the following forms (z is a
digit):
Chapter 10. Input/Output formatting
241

Edit Descriptor
Absolute Value of Exponent Form of Exponent
ENw.d
|exp| ≤ 99
z z
1 2
ENw.d
99 < |exp| ≤ 309
±z z z
1 2 3
ENw.dEe
|exp| ≤ 10e-1
z ... z
1
e
For general information about numeric editing on input, see “Rules for numeric
edit descriptors on input” on page 229.
For more information regarding numeric editing on output, see “Rules for numeric
data edit descriptors on output” on page 230.
Examples
Value
Format
Output
3.14159
EN12.5
b3.14159E+00
1.41425D+5
EN15.5E4
141.42500E+0003
3.14159D-12
EN15.5E1
***************
(with -qxlf90=signedzero)
(with -qxlf90=nosignedzero)
-0.001
EN9.2
-1.00E-03
-1.00E-03
ES Editing
Purpose
The ES edit descriptor produces an output field in the form of a real number in
scientific notation such that the absolute value of the significand is greater than or
equal to 1 and less than 10, except when the output value is zero. The scale factor
has no effect on output.
The ES edit descriptor can correspond to an input/output list item of type real, to
either part (real or imaginary) of an input/output list item of type complex,
or to any other type in XL Fortran, as long as the length is at least 4
bytes.
Syntax
v
ESw.d
v
ESw.dEe
Rules
The form and interpretation of the input field is the same as for F editing.
The form of the output field is:
.
digit_string
exp
+
y
-
y
is a decimal digit representative of the most significant digit of the value of
the datum after rounding.
242
XL Fortran: Language Reference

digit_string
are the d next most significant digits of the value of the datum after
rounding.
exp
is a decimal exponent having one of the following forms (z is a digit):
Edit Descriptor
Absolute Value of Exponent Form of Exponent
ESw.d
|exp| ≤ 99
z z
1 2
ESw.d
99 < |exp| ≤ 309
±z z z
1 2 3
ESw.dEe
|exp| ≤ 10e-1
z ... z
1
e
For general information about numeric editing on input, see “Rules for numeric
edit descriptors on input” on page 229.
For more information regarding numeric editing on output, see “Rules for numeric
data edit descriptors on output” on page 230.
Examples
Value
Format
Output
31415.9
ES12.5
b3.14159E+04
14142.5D+3
ES15.5E4
bb1.41425E+0007
31415.9D-22
ES15.5E1
***************
(with -qxlf90=signedzero)
(with -qxlf90=nosignedzero)
-0.001
ES9.2
-1.00E-03
-1.00E-03
F (Real without Exponent) Editing
Purpose
The F edit descriptor directs editing between real and complex numbers in internal
form and their character representations without exponents.
The F edit descriptor can correspond to an input/output list item of type real, to
either part (real or imaginary) of an input/output list item of type complex,
or to any other type in XL Fortran, as long as the length is at least 4
bytes.
Syntax
v
Fw.d
Rules
The input field for the F edit descriptor consists of, in order:
1. An optional sign.
2. A string of digits optionally containing a decimal symbol. If the decimal symbol
is present, it overrides the d specified in the edit descriptor. If the decimal
symbol is omitted, the rightmost d digits of the string are interpreted as
following the decimal symbol, and leading blanks are converted to zeros if
necessary.
3. Optionally, an exponent, having one of the following forms:
v
A signed digit string
v
E, D, or Q followed by zero or more blanks and by an optionally signed
digit string. E, D, and Q are processed identically.
Chapter 10. Input/Output formatting
243

The output field for the F edit descriptor consists of, in order:
1. Blanks, if necessary.
2. A minus sign if the internal value is negative, or an optional plus sign if the
internal value is zero or positive.
3. A string of digits that contains a decimal symbol and represents the magnitude
of the internal value, as modified by the scale factor in effect and rounded to d
fractional digits. See “P (Scale Factor) Editing” on page 255 for more
information.
On input, w must be greater than zero.
In Fortran 95 on output, w can be zero. If w is zero, the output field consists of the
least number of characters required to represent the output value.
For general information about numeric editing on input, see “Rules for numeric
edit descriptors on input” on page 229.
For more information regarding numeric editing on output, see “Rules for numeric
data edit descriptors on output” on page 230.
Examples
Example 1: Examples of F editing on input
(Assume BN editing is in effect for blank interpretation.)
Input
Format
Value
-100
F6.2
-1.0
2.9
F6.2
2.9
4.E+2
F6.2
400.0
Example 2: Examples of F editing on output
Value
Format
Output
Output
(with -qxlf77=noleadzero)
(with -qxlf77=leadzero)
+1.2
F8.4
bb1.2000
bb1.2000
.12345
F8.3
bbbb.123
bbbb0.123
-12.34
F6.2
-12.34
-12.34
-12.34
F0.2
-12.34
-12.34
(with -qxlf90=signedzero)
(with -qxlf90=nosignedzero)
-0.001
F5.2
-0.00
b0.00
G (General) Editing
Purpose
The G edit descriptor can correspond to an input/output list item of any type.
Editing of integer data follows the rules of the I edit descriptor; editing of real and
complex data follows the rules of the E or F edit descriptors (depending on the
magnitude of the value); editing of logical data follows the rules of the L edit
descriptor; and editing of character data follows the rules of the A edit descriptor.
Syntax
v
Gw.d
v
Gw.dEe
v
Gw.dDe
v
Gw.dQe
244
XL Fortran: Language Reference

Rules
For general information about numeric editing on input, see “Rules for numeric
edit descriptors on input” on page 229.
For more information regarding numeric editing on output, see “Rules for numeric
data edit descriptors on output” on page 230.
Examples
Value
Format
Output
Output
(with -qxlf77=gedit77)
(with -qxlf77=nogedit77)
0.0
G10.2
bb0.00E+00
bbb0.0
0.0995
G10.2
bb0.10E+00
bb0.10
99.5
G10.2
bb100.
bb0.10E+03
Generalized real and complex editing
If the nogedit77 suboption (the default) of the -qxlf77 option is specified, the
method of representation in the output field depends on the magnitude of the
datum being edited. Let N be the magnitude of the internal datum. If
0 < N < 0.1-0.5×10 -d-1 or N ≥ 10 d-0.5 or N is 0 and d is 0, Gw.d output editing is
the same as kPE w.d output editing and Gw.dEe output editing is the same as
kPEw.dEe output editing, where kP refers to the scale factor ( “P (Scale Factor)
Editing” on page 255) currently in effect. If 0.1-0.5×10-d-1 ≤ N < 10d-0.5 or N is
identically 0 and d is not zero, the scale factor has no effect, and the value of N
determines the editing as follows:
Magnitude of Datum
Equivalent Conversion
N = 0
F(w-n).(d-1),n('b')
(d must not be 0)
0.1-0.5×10-d-1 ≤ N < 1-0.5×10-d
F(w-n).d,n('b')
1-0.5×10-d ≤ N < 10-0.5×10-d+1
F(w-n).(d-1),n('b')
10-0.5×10-d+1
F(w-n).(d-2),n('b')
N < 100-0.5×10-d+2
...
...
10d-2-0.5×10-2 ≤ N < 10d-1-0.5×10-1
F(w-n).1,n('b')
10d-1-0.5×10-1 ≤ N < 10d-0.5
F(w-n).0,n('b')
where b is a blank. n is 4 for Gw.d and e+2 for Gw.dEe. The value of w-n must also
be positive.
Note that the scale factor has no effect unless the magnitude of the datum to be
edited is outside the range that permits effective use of F editing.
Chapter 10. Input/Output formatting
245

If 0 < N < 0.1-0.5×10-d-1, N ≥ 10d-0.5, or N is 0 and d is 0, Gw.dDe
output editing is the same as kPEw.dDe output editing and Gw.dQe output editing
is the same as kPEw.dQe output editing.
On output, if the gedit77 suboption of the -qxlf77 compiler option is specified, the
number is converted using either E or F editing, depending on the number. The
field is padded with blanks on the right as necessary. Letting N be the magnitude
of the number, editing is as follows:
v
If N<0.1 or N≥10d:
Gw.d editing is the same as Ew.d editing
Gw.dEe editing is the same as Ew.dEe editing.
v
If N≥0.1 and N<10d:
Magnitude of Datum
Equivalent Conversion
0.1 ≤ N < 1
F(w-n).d, n('b')
1 ≤ N < 10
F(w-n).(d-1), n('b')
.
.
.
.
10d-2 ≤ N < 10d-1
F(w-n).1, n('b')
10d-1 ≤ N < 10d
F(w-n).0, n('b')
Note: While FORTRAN 77 does not address how rounding of values affects the
output field form, Fortran 90 does. Therefore, using -qxlf77=gedit77 may produce
a different output form than -qxlf77=nogedit77 for certain combinations of values
and G edit descriptors.
H Editing
Purpose
The H edit descriptor specifies a character string (str) and its length (n) in an
output format specification. The string can consist of any of the characters allowed
in a character literal constant.
Syntax
v
nH str
Rules
If an H edit descriptor occurs within a character literal constant, the constant
delimiter character (for example, apostrophe) can be represented within str if two
such characters are consecutive. Otherwise, another delimiter must be used.
The H edit descriptor must not be used on input.
Note:
1. A backslash is recognized as an escape character by default, and as a backslash
character when the -qnoescape compiler option is specified. See escape
sequences for more information.
2. XL Fortran provides support for multibyte characters within character
constants, Hollerith constants, character-string edit descriptors, and comments.
This support is provided through the -qmbcs option. Assignment of a constant
246
XL Fortran: Language Reference

containing multibyte characters to a variable that is not large enough to hold
the entire string may result in truncation within a multibyte character.
3. Support is also provided for Unicode characters and filenames. If the
environment variable LANG is set to UNIVERSAL and the -qmbcs compiler
option is specified, the compiler can read and write Unicode characters and
filenames.
4. Fortran 95 does not include the H edit descriptor, although it was part of both
FORTRAN 77 and Fortran 90. See page “Deleted features” on page 872 for
more information.
Examples
50
FORMAT(16HThe value is -- ,I2)
10
FORMAT(I2,7Ho’clock)
WRITE(*,’(I2,7Ho’’clock)’) ITIME
I (Integer) Editing
Purpose
The I edit descriptor directs editing between integers in internal form and
character representations of integers. The corresponding input/output list item can
be of type integer
or any other type in XL Fortran.
Syntax
v
Iw
v
Iw.m
Rules
w includes the optional sign.
m must have a value that is less than or equal to w, unless w is zero in Fortran 95.
The input field for the I edit descriptor must be an optionally signed digit string,
unless it is all blanks. If it is all blanks, the input field is considered to be zeros.
m is useful on output only. It has no effect on input.
On input, w must be greater than zero.
On output, w can be zero. If w is zero, the output field consists of the least number
of characters required to represent the output value.
The output field for the I edit descriptor consists of, in order:
1. Zero or more leading blanks
2. A minus sign, if the internal value is negative, or an optional plus sign, if the
internal value is zero or positive
3. The magnitude in the form of:
v
A digit string without leading zeros if m is not specified
v
A digit string of at least m digits if m is specified and, if necessary, with
leading zeros. If the internal value and m are both zero, blanks are written.
For additional information about numeric editing, see editing.
Chapter 10. Input/Output formatting
247

If m is zero, w is positive and the value of the internal datum is zero, the output
field consists of w blank characters. If both w and m are zero and the value of the
internal datum is zero, the output field consists of only one blank character.
Examples
Example 1: Examples of I editing on input
(Assume BN editing is in effect for blank interpretation.)
Input
Format
Value
-123
I6
-123
123456
I7.5
123456
1234
I4
1234
Example 2: Examples of I editing on output
Value
Format
Output
-12
I7.6
-000012
12345
I5
12345
0
I6.0
bbbbbb
0
I0.0
b
2
I0
2
L (Logical) Editing
Purpose
The L edit descriptor directs editing between logical values in internal form and
their character representations. The L edit descriptor can correspond to an
input/output list item of type logical,
or any other type in XL Fortran.
Syntax
v
Lw
Rules
The input field consists of optional blanks, followed by an optional decimal
symbol, followed by a T for true or an F for false. w includes blanks. Any
characters following the T or F are accepted on input but are ignored; therefore, the
strings .TRUE. and .FALSE. are acceptable input forms.
The output field consists of T or F preceded by ( w - 1 ) blanks.
Examples
Example 1: Examples of L editing on input
Input
Format
Value
T
L4
true
.FALSE.
L7
false
Example 2: Examples of L editing on output
Value
Format
Output
TRUE
L4
bbbT
FALSE
L1
F
248
XL Fortran: Language Reference

O (Octal) Editing
Purpose
The O edit descriptor directs editing between values of any type in internal form
and their octal representation. (An octal digit is one of 0-7.)
Syntax
v
Ow
v
Ow.m
Rules
w includes blanks.
On input, w octal digits are edited and form the internal representation for the
value of the input list item. The octal digits in the input field correspond to the
rightmost octal digits of the internal representation of the value assigned to the
input list item. m has no effect on input.
On input, w must be greater than zero.
On output, w can be zero. If w is zero, the output field consists of the least number
of characters required to represent the output value.
The output field for Ow consists of zero or more leading blanks followed by the
internal value in a form identical to the octal digits without leading zeros. Note
that an octal constant always consists of at least one digit.
The output field for Ow.m is the same as for Ow, except that the digit string
consists of at least m digits. If necessary, the digit string is padded with leading
zeros. The value of m must not exceed the value of w, unless w is zero. If m is zero
and the value of the internal datum is zero, the output field consists of only blank
characters, regardless of the sign control in effect.
If the nooldboz suboption of the -qxlf77 compiler option is specified (the default),
asterisks are printed when the output field width is not sufficient to contain the
entire output. On input, the BLANK= specifier and the BN and BZ edit descriptors
affect the O edit descriptor.
IBM extension
If the oldboz suboption of the -qxlf77 compiler option is specified, the following
occurs on output:
v
Ow is treated as Ow.m, with m assuming the value that is the minimum of w
and the number of digits required to represent the maximum possible value of
the data item.
v
The output consists of blanks followed by at least m digits. These are the
rightmost digits of the number, zero-filled if necessary, until there are m digits. If
the number is too large to fit into the output field, only the rightmost m digits
are output.
If w is zero, the oldboz suboption will be ignored.
Chapter 10. Input/Output formatting
249

With the oldboz suboption, the BLANK= specifier and the BN and BZ edit
descriptors do not affect the O edit descriptor.
End of IBM extension
If m is zero, w is positive and the value of the internal datum is zero, the output
field consists of w blank characters. If both w and m are zero and the value of the
internal datum is zero, the output field consists of only one blank character.
Examples
Example 1: Examples of O editing on input
Input
Format
Value
123
O3
83
120
O3
80
Example 2: Examples of O editing on output
Value
Format
Output
Output
(with -qxlf77=oldboz)
(with -qxlf77=nooldboz)
80
O5
00120
bb120
83
O2
23
**
0
O5.0
bbbbb
bbbbb
0
O0.0
b
b
80
O0
120
120
Q (Character Count) Editing (IBM extension)
Purpose
The character count Q edit descriptor returns the number of characters remaining
in an input record. The result can be used to control the rest of the input.
Syntax
v
Q
Rules
There also exists the extended precision Q edit descriptor. By default, XL Fortran
only recognizes the extended precision Q edit descriptor described earlier. See “E,
D, and Q (Extended Precision) Editing” on page 239 for more information. To
enable both Q edit descriptors, you must specify the -qqcount compiler option.
When you specify the -qqcount compiler option, the compiler will distinguish
between the two Q edit descriptors by the way the Q edit descriptor is used. If
only a solitary Q is found, the compiler will interpret it as the character count Q
edit descriptor. If Qw. or Qw.d is encountered, XL Fortran will interpret it as the
extended precision Q edit descriptor. You should use correct format specifications
with the proper separators to ensure that XL Fortran correctly interprets which Q
edit descriptor you specified.
The value returned as a result of the character count Q edit descriptor depends on
the length of the input record and on the current character position in that record.
The value is returned into a scalar integer variable on the READ statement whose
position corresponds to the position of the character count Q edit descriptor in the
FORMAT statement.
250
XL Fortran: Language Reference

The character count Q edit descriptor can read records of the following file types
and access modes:
v
Formatted sequential external files. A record of this file type is terminated by a
new-line character. Records in the same file have different lengths.
v
Formatted sequential internal nonarray files. The record length is the length of
the scalar character variable.
v
Formatted sequential internal array files. The record length is the length of an
element in the character array.
v
Formatted direct external files. The record length is the length specified by the
RECL= specifier in the OPEN statement.
v
Formatted stream external files. A record of this file type is terminated by a
new-line character. Records in the same file have different lengths.
In an output operation, the character count Q edit descriptor is ignored. The
corresponding output item is skipped.
Examples
@PROCESS QCOUNT
CHARACTER(50) BUF
INTEGER(4) NBYTES
CHARACTER(60) STRING
...
BUF = ’This string is 29 bytes long.’
READ( BUF, FMT=’(Q)’ ) NBYTES
WRITE( *,* ) NBYTES
! NBYTES equals 50 because the buffer BUF is 50 bytes long.
READ(*,20) NBYTES, STRING
20
FORMAT(Q,A)
! NBYTES will equal the number of characters entered by the user.
END
Z (Hexadecimal) Editing
Purpose
The Z edit descriptor directs editing between values of any type in internal form
and their hexadecimal representation. (A hexadecimal digit is one of 0-9, A-F, or
a-f.)
Syntax
v
Zw
v
Zw.m
Rules
On input, w hexadecimal digits are edited and form the internal representation for
the value of the input list item. The hexadecimal digits in the input field
correspond to the rightmost hexadecimal digits of the internal representation of the
value assigned to the input list item. m has no effect on input.
On output, w can be zero. If w is zero, the output field consists of the least number
of characters required to represent the output value.
The output field for Zw consists of zero or more leading blanks followed by the
internal value in a form identical to the hexadecimal digits without leading zeros.
Note that a hexadecimal constant always consists of at least one digit.
Chapter 10. Input/Output formatting
251

The output field for Zw.m is the same as for Zw, except that the digit string
consists of at least m digits. If necessary, the digit string is padded with leading
zeros. The value of m must not exceed the value of w, unless w is zero. If m is zero
and the value of the internal datum is zero, the output field consists of only blank
characters, regardless of the sign control in effect.
If m is zero, w is positive and the value of the internal datum is zero, the output
field consists of w blank characters.
If both w and m are zero and the value of the internal datum is zero, the output
field consists of only one blank character.
If the nooldboz suboption of the -qxlf77 compiler option is specified (the default),
asterisks are printed when the output field width is not sufficient to contain the
entire output. On input, the BLANK= specifier and the BN and BZ edit descriptors
affect the Z edit descriptor.
IBM extension
If the oldboz suboption of the -qxlf77 compiler option is specified, the following
occurs on output:
v
Zw is treated as Zw.m, with m assuming the value that is the minimum of w and
the number of digits required to represent the maximum possible value of the
data item.
v
The output consists of blanks followed by at least m digits. These are the
rightmost digits of the number, zero-filled if necessary, until there are m digits. If
the number is too large to fit into the output field, only the rightmost m digits
are output.
If w is zero, the oldboz suboption will be ignored.
With the oldboz suboption, the BLANK= specifier and the BN and BZ edit
descriptors do not affect the Z edit descriptor.
End of IBM extension
Examples
Example 1: Examples of Z editing on input
Input
Format
Value
0C
Z2
12
7FFF
Z4
32767
Example 2: Examples of Z editing on output
Value
Format
Output
Output
(with -qxlf77=oldboz)
(with -qxlf77=nooldboz)
-1
Z2
FF
**
12
Z4
000C
bbbC
12
Z0
C
C
0
Z5.0
bbbbb
bbbbb
0
Z0.0
b
b
252
XL Fortran: Language Reference

Control edit descriptors
/ (Slash) Editing
Purpose
The slash edit descriptor indicates the end of data transfer on the current record.
The repeat specifier (r) has a default value of 1.
Syntax
v
/
v
r/
Rules
When you connect a file for input using sequential access, each slash edit
descriptor positions the file at the beginning of the next record.
When you connect a file for output using sequential access, each slash edit
descriptor creates a new record and positions the file to write at the start of the
new record.
When you connect a file for input or output using direct access, each slash edit
descriptor increases the record number by one, and positions the file at the
beginning of the record that has that record number.
Fortran 2003
When you connect a file for input using stream access, each slash edit descriptor
positions the file at the beginning of the next record, skipping the remaining
portion of the current record. On output to a file connected for stream access, a
newly created empty record follows the current record. The new record becomes
both the current and last record of the file, with the file position coming at the
beginning of the new record.
End of Fortran 2003
Examples
500
FORMAT(F6.2 / 2F6.2)
100
FORMAT(3/)
: (Colon) Editing
Purpose
The colon edit descriptor terminates format control if no more items are in the
input/output list. If more items are in the input/output list when the colon is
encountered, it is ignored.
Syntax
v
:
Rules
See “Interaction of Input/Output lists and format specifications” on page 234 for
more information.
Chapter 10. Input/Output formatting
253

Examples
10
FORMAT(3(:’Array Value’,F10.5)/)
$ (Dollar) Editing (IBM extension)
Purpose
The dollar edit descriptor inhibits an end-of-record for a sequential or formatted
stream WRITE statement.
Syntax
v
$
Rules
Usually, when the end of a format specification is reached, data transmission of the
current record ceases and the file is positioned so that the next input/output
operation processes a new record. But, if a dollar sign occurs in the format
specification, the automatic end-of-record action is suppressed. Subsequent
input/output statements can continue writing to the same record.
Examples
A common use for dollar sign editing is to prompt for a response and read the
answer from the same line.
WRITE(*,FMT=’($,A)’)’Enter your age

READ(*,FMT=’(BN,I3)’)IAGE
WRITE(*,FMT=1000)
1000
FORMAT(’Enter your height:
’,$)
READ(*,FMT=’(F6.2)’)HEIGHT
BN (Blank Null) and BZ (Blank Zero) Editing
Purpose
The BN and BZ edit descriptors control the interpretation of nonleading blanks by
subsequently processed I, F, E, EN, ES, D, G, B, O, Z, and extended precision Q
edit descriptors. BN and BZ have effect only on input.
Syntax
v
BN
v
BZ
Rules
BN specifies that blanks in numeric input fields are to be ignored, and remaining
characters are to be interpreted as though they were right-justified. A field of all
blanks has a value of zero.
BZ specifies that nonleading blanks in numeric input fields are to be interpreted as
zeros.
The initial setting for blank interpretation is determined by the BLANK= specifier
of the OPEN statement. (See “OPEN” on page 399.) The initial setting is
determined as follows:
254
XL Fortran: Language Reference

v
If BLANK= is not specified, blank interpretation is the same as if BN editing
were specified.
v
If BLANK= is specified, blank interpretation is the same as if BN editing were
specified when the specifier value is NULL, or the same as if BZ editing were
specified when the specifier value is ZERO.
The initial setting for blank interpretation takes effect at the start of a formatted
READ statement and stays in effect until a BN or BZ edit descriptor is
encountered or until format control finishes. Whenever a BN or BZ edit descriptor
is encountered, the new setting stays in effect until another BN or BZ edit
descriptor is encountered, or until format control terminates.
If you specify the oldboz suboption of the –qxlf77 compiler option, the
BN and BZ edit descriptors do not affect data input edited with the B, O, or Z edit
descriptors. Blanks are interpreted as zeros.
DC and DP (Decimal) Editing (Fortran 2003)
Purpose
Decimal edit descriptors, DC and DP change the decimal edit mode to decimal
comma and decimal point respectively.
Syntax
v
DC
v
DP
Rules
The decimal edit descriptors are used to control the representation of the decimal
symbol in formatted input and output. The decimal comma or decimal point mode
is in effect when the corresponding edit descriptor is encountered. They continue
to be in effect until another DC or DP edit descriptor is encountered or until the
end of the current I/O statement is reached.
Examples
program main
real :: pi=3.14
print ’(t2, dp, f4.2)’, pi
print ’(t2, dc, f4.2)’, pi
end program
Output
3.14
3,14
P (Scale Factor) Editing
Purpose
The scale factor, k, applies to all subsequently processed F, E, EN, ES, D, G, and
extended precision Q edit descriptors until another scale factor is encountered or
until format control terminates. The value of k is zero at the beginning of each
input/output statement. It is an optionally signed integer value representing a
power of ten.
Chapter 10. Input/Output formatting
255

Syntax
v
kP
Rules
On input, when an input field using an F, E, EN, ES, D, G, or extended precision
Q edit descriptor contains an exponent, the scale factor is ignored. Otherwise, the
internal value equals the external value multiplied by 10(-k).
On output:
v
In F editing, the external value equals the internal value multiplied by 10k.
v
In E, D, and extended precision Q editing, the external decimal field is
multiplied by 10k. The exponent is then reduced by k.
v
In G editing, fields are not affected by the scale factor unless they are outside
the range that can use F editing. If the use of E editing is required, the scale
factor has the same effect as with E output editing.
v
In EN and ES editing, the scale factor has no effect.
Examples
Example 1: Examples of P editing on input
Input
Format
Value
98.765
3P,F8.6
.98765E-1
98.765
-3P,F8.6
98765.
.98765E+2
3P,F10.5
.98765E+2
Example 2: Examples of P editing on output
Value
Format
Output
Output
(with -qxlf77=noleadzero)
(with -qxlf77=leadzero)
5.67
-3P,F7.2
bbbb.01
bbb0.01
12.34
-2P,F6.4
b.1234
0.1234
12.34
2P,E10.3
b12.34E+00
b12.34E+00
RC, RD, RN, RP, RU, and RZ (Round) Editing (Fortran 2003)
Purpose
Round edit descriptors are used in a Format statement and are one of RC, RD,
RN, RP, RU, and RZ, which correspond to the COMPATIBLE, DOWN,
NEAREST, PROCESSOR_DEFINED, UP, and ZERO rounding modes
respectively. The round edit descriptors temporarily change the connections
rounding mode in formatted I/O. The round edit descriptors only affect D, E, ES,
EN, F and G editing.
Syntax
v
RC
v
RD
v
RN
v
RU
v
RZ
256
XL Fortran: Language Reference

Rules
The round edit descriptors help specify how decimal numbers are converted to an
internal representation (i.e. in binary) from a character representation and vice
versa during formatted input and output.
Examples
program main
real :: i
100 format (f10.7, ru )
open(UNIT=2,file =’temp.txt’, form=’formatted’, round=’compatible’ )
read(UNIT=2, 100) i
print ’(f10.7 , ru)’ i
end program
Input - temp.txt
3.1415926
Output - temp.txt
3.1415928
S, SP, and SS (Sign Control) Editing
Purpose
The S, SP, and SS edit descriptors control the output of plus signs by all
subsequently processed I, F, E, EN, ES, D, G, and extended precision Q edit
descriptors until another S, SP, or SS edit descriptor is encountered or until format
control terminates.
The sign control edit descriptors can temporarily overwrite the SIGN mode set by
the SIGN=specifier for the connection. The S, SP, and SS edit descriptors set the
sign mode corresponding to the SIGN=specifier values default, PLUS and
SUPPRESS, respectively.
Syntax
v
S
v
SP
v
SS
Rules
S and SS specify that plus signs are not to be written. (They produce identical
results.) SP specifies that plus signs are to be written.
Examples
Value
Format
Output
12.3456
S,F8.4
b12.3456
12.3456
SS,F8.4
b12.3456
12.3456
SP,F8.4
+12.3456
T, TL, TR, and X (Positional) Editing
Purpose
The T, TL, TR, and X edit descriptors specify the position where the transfer of the
next character to or from a record starts.
Chapter 10. Input/Output formatting
257

Syntax
v
Tc
v
TLc
v
TRc
v
oX
Rules
The T and TL edit descriptors use the left tab limit for file positioning.
Immediately before the non-child data transfer the definition of the left tab limit is
the character position of the current record or the current position of the stream
file. The T, TL, TR, and X specify the character position as follows:
v
For Tc, the cth character position of the record, relative to the left tab limit.
v
For TLc, c characters backward from the current position unless c is greater than
the difference between the current character position and the left tab limit. Then,
transmission of the next character to or from the record occurs at the left tab
limit.
v
For TRc, c characters forward from the current position.
v
For oX, o characters forward from the current position.
The TR and X edit descriptors give identical results.
On input, a TR or X edit descriptor can specify a position beyond the last
character of the record if no characters are transferred from that position.
On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to
be transferred. If characters are transferred to positions at or after the position
specified by the edit descriptor, positions skipped and previously unfilled are filled
with blanks. The result is the same as if the entire record were initially filled with
blanks.
On output, a T, TL, TR, or X edit descriptor can result in repositioning so that
subsequent editing with other edit descriptors causes character replacement.
IBM extension
The X edit descriptor can be specified without a character position. It is treated as
1X. When the source file is compiled with -qlanglvl=90std or -qlanglvl=95std, this
extension is disabled in all compile-time format specifications, and the form of oX
is enforced. To disable this extension in run-time formats, the following run-time
option must be set:
XLFRTEOPTS="langlvl=90std" or "langlvl=95std" ; export XLFRTEOPTS
End of IBM extension
Examples
Example 1: Examples of T, TL, and X editing on input
150
FORMAT(I4,T30,I4)
200
FORMAT(F6.2,5X,5(I4,TL4))
Example 2: Examples of T, TL, TR, and X editing on output
258
XL Fortran: Language Reference

50
FORMAT(’Column 1’,5X,’Column 14’,TR2,’Column 25’)
100
FORMAT(’aaaaa’,TL2,’bbbbb’,5X,’ccccc’,T10,’ddddd’)
List-directed formatting
List-directed formatting allows you to control the editing process using the lengths
and types of data that is read or written. You can only use list-directed formatting
with sequential or stream access.
Use the asterisk format identifier to specify list-directed formatting. For example:
REAL TOTAL1, TOTAL2
PRINT *, TOTAL1, TOTAL2
Value separators
If you specify list-directed formatting for a formatted record, that record consists of
a sequence of values and value separators.
where:
value
is a constant or null.
value separator
is a comma, slash, semicolon or set of adjacent blanks that occur between
values in a record. You can specify one or more blanks before and after a
comma or slash. If decimal comma mode is in effect, a semicolon replaces
a comma as a value separator.
null
is one of the following:
v
Two successive commas, with zero or more intervening blanks.
v
A comma followed by a slash, with zero or more intervening blanks.
v
An initial comma in the record, preceded by zero or more blanks.
A null value has no effect on the definition status of the corresponding
input list item.
List-directed input
Effective input list items in a list-directed READ statement are defined by
corresponding values in a formatted record. The syntax of each value must agree
with the type of the corresponding effective input list item.
Table 29. List-directed input
Syntax
Type
c
A literal constant of intrinsic type, or a non-delimited character
constant.
r *
r is an unsigned, nonzero, integer literal constant. r * indicates r
successive appearances of the null value.
r * c
Indicates r successive appearances of the constant.
Rules for list-directed input
You must not specify a kind type parameter for c or r.
List-directed formatting interprets two or more consecutive blanks as a single
blank, unless the blanks are within a character value.
Chapter 10. Input/Output formatting
259

The constant c will have the same kind type parameter as the corresponding list
item.
Use the -qintlog compiler option to specify integer or logical values for
input items of either integer or logical type.
List-directed formatting interprets an object of derived type that occurs in an input
list as if all structure components occur in the same order as in the derived type
definition. The ultimate components of the derived type must not have the pointer
or allocatable
attribute.
A slash indicates the end of the input list and terminates list-directed formatting.
Additional input list items after the slash evaluate as null values. If a slash is
encountered by a child READ statement, it indicates the end of the input list for
that particular child READ statement only. Any other input in the record following
the slash is ignored. The slash has no effect on other child READ statements in the
user-defined derived type I/O procedure or the parent READ statement.
Continuing a character value
A character value that meets the following conditions can continue in as many
records as necessary:
v
The next item or ultimate component of a derived type is of type character.
v
The character constant does not contain the value separators blank, comma, or
slash
v
The character constant does not cross a record boundary.
v
The first non-blank character is not a quotation mark or apostrophe.
v
The leading characters are non numeric and followed by an asterisk.
v
The character constant contains at least one character.
Delimiting apostrophes or quotation marks are not necessary to continue a
character value across multiple records. If you omit delimiting characters, the first
blank, comma, slash, or end-of-record terminates the character constant.
If you do not specify delimiting apostrophes or quotation marks, apostrophes and
double quotation marks in the character value are not doubled.
End-of-record and list-directed input
In list-directed input an end-of-record has the same effect as a blank separator,
unless the blank is within a character literal constant or complex literal constant.
An end-of record does not insert a blank or any other character in a character
value. An end-of-record must not occur between a doubled apostrophe in an
apostrophe-delimited character sequence, or between a doubled quote in a
quote-delimited character sequence
List-directed output
List-directed PRINT and WRITE statements output values in an order identical to
the output list. Values are written in a form valid for the data type of each output
list item.
Types of list-directed output
Table 30. List-directed output
Data Type
Form of Output
Arrays
Column-major order
260
XL Fortran: Language Reference

Table 30. List-directed output (continued)
Character
Depends on DELIM= specifier and file type,
see Character Output.
Complex
Enclosed in parentheses with a comma
separating the real and imaginary parts.
Uses E or F editing.
Derived Types
User-defined derived-type I/O procedure.
Integer
Uses I editing.
Logical
T for a true value
F for a false value
Real
Uses E or F editing.
List-directed character output
The output of character constants can change depending on the DELIM= specifier
on the OPEN or READ statements.
Character constants output to a file opened without a DELIM= specifier, or a file
opened with a DELIM= specifier with a value of NONE, output as follows:
v
Values are not delimited by apostrophes or quotation marks.
v
Value separators do not occur between values. Value separators will be emitted
around the output of format-directed child I/O statements that have a
list-directed parent statement.
v
Each internal apostrophe or double quotation mark outputs as one apostrophe
or double quotation mark.
v
The processor inserts a blank character for carriage control at the beginning of
any record that continues a character constant from the preceding record.
Note: Non-delimited character data can not always be read back correctly using
list-directed input. Use with discretion.
Double quotation marks delimit character constants in a file opened with a
DELIM= specifier with a value of QUOTE. A value separator follows the delimiter.
Each internal quote outputs as two contiguous double quotation marks.
Apostrophes delimit character constants in a file opened with a DELIM= specifier
with a value of APOSTROPHE A value separator follows the delimiter. Each
internal apostrophe outputs as two contiguous apostrophes.
Rules for list-directed output
Each output record begins with a blank character that provides carriage control
when that record outputs.
The end-of-record must not occur within a constant that is not character or
complex.
In a complex constant, the end of a record can occur between the comma and the
imaginary part of the constant only if the constant is as long or longer than a
record. The only embedded blanks that can occur within a complex constant are
one blank between the comma and the end of a record, and one blank at the
beginning of the next record.
Blanks must not occur within a constant that is not character or complex.
Chapter 10. Input/Output formatting
261

Null values are not output.
Slashes you specify as value separators are not output.
IBM extension
For output that does not involve a user-defined derived-type I/O procedure, the
Width of a Written Field table contains the width of the written field for any data
type and length. The size of the record is the sum of the field widths plus one byte
to separate each non-character field.
Table 31. Width of a written field
Precision/IEEE
Length
Maximum Field Width Fraction (decimal
(decimal
Data Type
(bytes)
(characters)
digits)
digits)
integer
1
4
n/a
n/a
2
6
n/a
n/a
4
11
n/a
n/a
8
20
n/a
n/a
real
4
17
10
7
8
26
18
15
16
43
35
31
complex
8
37
10
7
16
55
18
15
32
89
35
31
logical
1
1
n/a
n/a
2
1
n/a
n/a
4
1
n/a
n/a
8
1
n/a
n/a
character
n
n
n/a
n/a
End of IBM extension
Namelist formatting
Namelist formatting allows you to use the NAME= specifier as part of the
NAMELIST statement to assign a name to a collection of variables. This name
represents the entire collection of variables for input and output. You can also use
namelist formatting to include namelist comments with input, making the data
more user accessible.
v
In Fortran 90 and Fortran 95, you can only use namelist formatting with
sequential access.
v
The Fortran 2003 Standard allows you to use namelist formatting with sequential
and stream access.
v
The Fortran 2003 Standard allows you to use namelist formatting with internal
files.
262
XL Fortran: Language Reference

Namelist input
The form of namelist input is:
1. Optional blanks and namelist comments.
2. The ampersand character, followed immediately by the namelist group name
specified in the NAMELIST statement.
3. One or more blanks.
4. A sequence of zero or more name-value subsequences, separated by value
separators.
5. A slash to terminate the namelist input.
Blanks at the beginning of an input record that continues a delimited character
constant are considered part of the constant.
If you specify the NAMELIST=OLD run-time option, the form of input
for a NAMELIST statement is:
1. Optional blanks
2. An ampersand or dollar sign, followed immediately by the namelist group
name specified in the NAMELIST statement.
3. One or more blanks.
4. A sequence of zero or more name-value subsequences separated by a single
comma. You can insert a comma after the last name-value subsequence.
5. &END or $END to terminate the namelist input.
The first character of each input record must be a blank, including those records
that continue a delimited character constant.
Namelist comments
In Fortran 95 and higher, you can use comments in namelists.
You must not specify comments in stream input.
If you specify the NAMELIST=NEW run-time option:
v
If you specify an exclamation point after a value separator that is not a slash, or
in the first non-blank position of a namelist input record, you initiate a
comment. You can not initiate comments inside character literal constants.
v
The comment extends to the end of the input record, and can contain any
character in the XL Fortran character set.
v
The comment is ignored.
v
A slash within a namelist comment does not terminate execution of that namelist
input statement.
If you specify the NAMELIST=OLD run-time option:
v
If you specify an exclamation point after a single comma or in the first
non-blank position of a namelist input record that is not the first character of
that record, you initiate a comment. You must not initiate a namelist comment
within a character literal constant.
v
The comment extends to the end of the input record, and can contain any
character in the XL Fortran character set.
v
The comment is ignored.
Chapter 10. Input/Output formatting
263

v
An &END or $END within a namelist comment does not terminate execution of the
namelist input statement.
Name-value subsequence
The form of a name-value subsequence in an input record is:
name
=
constant_list
name
is a variable
constant
has the following forms:
literal_constant
r
*
r
is an unsigned, nonzero, scalar, integer literal constant specifying
the number of times the literal_constant occurs. You must not
specify a kind type parameter for r.
literal_constant
is a scalar literal constant of intrinsic type, or null value. You must
not specify a kind type parameter for the constant. The constant
evaluates with the same kind type parameter as the corresponding
list item.
You must specify delimiting apostrophes or quotation marks if
literal_constant is of type character.
You can specify T or F if literal_constant is of type logical.
Rules for namelist input
Any subscripts, strides, and substring range expressions that qualify name must be
integer literal constants with no kind type parameter.
If name is not an array or an object of derived type, constant_list must contain a
single constant.
Variable names you specify in the input file must appear in the variable_name_list of
a NAMELIST statement. Variables can appear in any order.
If a name that you specify in an EQUIVALENCE statement shares storage with
name, you must not substitute for that name in the variable_name_list.
You can use one or more optional blanks before or after name, but name must not
contain embedded blanks.
In each name-value subsequence, the name must be the name of a namelist group
item with an optional qualification. The name with the optional qualification must
not be a:
v
zero-sized array.
264
XL Fortran: Language Reference

v
zero-sized array section.
v
zero-length character string.
If you specify the optional qualification, it must not contain a vector subscript.
If name is an array, array section without vector subscripts, or a structure, name
expands where applicable into a sequence of scalar list items of intrinsic data type
according to the rules outlined in “Effective list items (Fortran 2003)” on page 234.
If name is an array or structure, the number of constants in constant_list must be
less than or equal to the number of items specified by the expansion of name. If the
number of constants is less than the number of items, the remaining items retain
their former values.
You can specify a null value using:
v
The r* form that indicates r successive appearances of the null value.
v
Blanks between two consecutive value separators following an equal sign.
v
Zero or more blanks preceding the first value separator and following an equal
sign.
v
Two consecutive non-blank value separators.
A null value has no effect on the definition status of the corresponding input list
item. If the namelist group object list item is defined, it retains its previous value;
if it is undefined, it remains undefined.
If decimal comma mode is in effect, a semicolon acts as a value separator instead
of a comma.
You must not use a null value as the real or imaginary part of a complex constant.
A single null value can represent an entire complex constant.
The end of a record following a value separator, with or without intervening
blanks, does not specify a null value.
IBM extension
When you set the LANGLVL=EXTENDED run-time option, XL Fortran allows you
to specify multiple input values in conjunction with a single array element. XL
Fortran assigns the values to successive elements of that array, in array element
order. The array element must not specify subobject designators.
Consider the following example, which declares array A as follows:
INTEGER A(100)
NAMELIST /FOO/ A
READ (5, FOO)
Unit 5 contains the following input:
&FOO
A(3) = 2, 10, 15, 16
/
During execution of the READ statement, XL Fortran assigns the following values:
v
2 to A(3)
v
10 to A(4)
v
15 to A(5)
Chapter 10. Input/Output formatting
265

v
16 to A(6)
If you specify multiple values in conjunction with a single array element, any
logical constant must be specified with a leading period, for example, .T.
If you use the NAMELIST=OLD option at run time, the BLANK= specifier in the
OPEN or READ statements determines how XL Fortran interprets embedded and
trailing blanks between non-character constants.
If you specify the -qmixed compiler option, the namelist group name and list item
names are case-sensitive.
End of IBM extension
A slash appearing as a value separator terminates the input statement after
assignment of the previous value. Any additional items in the namelist group
object receive null values
Example of namelist input data
File NMLEXP contains the following data before execution of the READ statement.
Character position:
1
2
3
1...+....0....+....0....+....0
File contents:
&NAME1
I=5,
SMITH%P_AGE=27
/
NMLEXP contains four data records. The program contains the following:
TYPE PERSON
INTEGER P_AGE
CHARACTER(20) P_NAME
END TYPE PERSON
TYPE(PERSON) SMITH
NAMELIST /NAME1/ I,J,K,SMITH
I=1
J=2
K=3
SMITH=PERSON(20,’John Smith’)
OPEN(7,FILE=’NMLEXP’)
READ(7,NML=NAME1)
! Only the value of I and P_AGE in SMITH are
! altered (I = 5, SMITH%P_AGE = 27).
! J, K and P_NAME in SMITH remain the same.
END
Note: In the previous example, data items appear in separate data records. The
next example is a file with the same data items in one data record:
Character position:
1
2
3
4
1...+....0....+....0....+....0....+....0
File contents:
&NAME1 I= 5, SMITH%P_AGE=40 /
266
XL Fortran: Language Reference

An example of a NAMELIST comment when you specify NAMELIST=NEW. The
comment appears after the value separator space.
&TODAY I=12345
! This is a comment. /
X(1)=12345, X(3:4)=2*1.5, I=6,
P="!ISN’T_BOB’S", Z=(123,0)/
An example of a NAMELIST comment when you specify
NAMELIST=OLD. The comment appears after the value separator space.
&TODAY I=12345,
! This is a comment.
X(1)=12345, X(3:4)=2*1.5, I=6,
P="!ISN’T_BOB’S", Z=(123,0) &END
Namelist output
The WRITE statement outputs data from the variable_name_list in a NAMELIST
statement according to data type. This data can be read using namelist input
except for non-delimited character data.
You must not specify a single long character variable for namelist output.
Each output record that is not continuing a delimited character constant from a
previous record begins with a blank character that provides carriage control.
The output data fields become large enough to contain all significant digits, as
shown in the Width of a Written Field table.
The values of a complete array output in column-major order.
If the length of an array element is not sufficient to hold the data, you must
specify an array with more than three elements.
A WRITE statement with a variable_name_list produces a minimum of
three output records:
v
One record containing the namelist name.
v
One or more records containing the output data items.
v
One record containing a slash to terminate output.
To output namelist data to an internal file, the file must be a character array
containing at least three elements. If you use the WRITE statement to transfer data
to an internal file, the character array can require more than three elements.
You can delimit character data using the DELIM= specifier on the OPEN or READ
statements.
Namelist character output
The output of character constants can change depending on the DELIM= specifier
on the OPEN or READ statements.
For character constants in a file opened without a DELIM= specifier, or with a
DELIM=NONE:
v
Values are non-delimited by apostrophes or quotation marks.
v
Value separators do not occur between values.
Chapter 10. Input/Output formatting
267

v
Each internal apostrophe or double quotation mark outputs as one apostrophe
or quotation mark.
v
XL Fortran inserts a blank character for carriage control at the beginning of any
record that continues a character constant from the preceding record.
Nondelimited character data that has been written must not be read as character
data.
Double quotation marks delimit character constants in a file opened with
DELIM=QUOTE, with a value separator preceding and following each constant.
Each internal quote outputs as two contiguous quotation marks.
Apostrophes delimit character constants in a file opened with
DELIM=APOSTROPHE with a value separator preceding and following each
constant. Each internal apostrophe outputs as two contiguous apostrophes.
Rules for namelist output
You must not specify a single character variable to output namelist data to an
internal file, even if it is large enough to hold all of the data.
If you do not specify the NAMELIST run-time option, or you specify
NAMELIST=NEW, the namelist group name and namelist item names output in
uppercase.
IBM extension
If you specify NAMELIST=OLD at run-time:
v
The namelist group name and namelist item names output in lower case.
v
An &END terminates the output record.
If you specify NAMELIST=OLD at run-time and do not use the DELIM= specifier
on an OPEN or READ statement:
v
Apostrophes delimit character data
v
Apostrophes delimit non-delimited character strings. A comma separator occurs
between each character string.
v
If a record starts with the continuation of a character string from the previous
record, blanks are not added to the beginning of that record.
If you use the -qmixed compiler option, the namelist group name is case sensitive,
regardless of the value of the NAMELIST run-time option.
To restrict namelist output records to a given width, use the RECL= specifier on
the OPEN statement, or the NLWIDTH run-time option.
By default all output items for external files appear in a single output record. To
have the record output on separate lines, use the RECL= specifier on the OPEN
statement, or the NLWIDTH run-time option.
If decimal comma mode is in effect, a semicolon acts as a value separator instead
of a comma.
End of IBM extension
268
XL Fortran: Language Reference

Example of namelist output data
TYPE PERSON
INTEGER P_AGE
CHARACTER(20) P_NAME
END TYPE PERSON
TYPE(PERSON) SMITH
NAMELIST /NL1/ I,J,C,SMITH
CHARACTER(5) :: C=’BACON’
INTEGER I,J
I=12046
J=12047
SMITH=PERSON(20,’John Smith’)
WRITE(6,NL1)
END
After execution of the WRITE statement with NAMELIST=NEW, the output data
is:
1
2
3
4
1...+....0....+....0....+....0....+....0
&NL1
I=12046, J=12047, C=BACON, SMITH=20, John Smith
/
After execution of the WRITE statement with NAMELIST=OLD, the
output data is:
1
2
3
4
1...+....0....+....0....+....0....+....0
&nl1
i=12046, j=12047, c=’BACON’, smith=20, ’John Smith

&end
Chapter 10. Input/Output formatting
269

270
XL Fortran: Language Reference

Chapter 11. Statements and attributes
This section provides an alphabetical reference to all XL Fortran statements. The
section for each statement is organized to help you readily access the syntax and
rules, and points to the structure and uses of the statement.
The following table lists the statements, and shows which ones are executable,
which ones are specification_part statements, and which ones can be used as the
terminal statement of a DO or DO WHILE construct. The executable statements,
specification statements, and terminal statements are marked with "'".
Table 32. Statements table
Executable
Specification
Terminal
Statement Name
Statement
Statement
Statement
ABSTRACT 1
'
ALLOCATABLE 1
'
ALLOCATE
'
'
ASSIGN
'
ASSOCIATE 1
'
ASYNCHRONOUS 2 4
'
AUTOMATIC 2
'
BACKSPACE 4
'
'
BIND 1
'
BLOCK 3
BLOCK DATA
BYTE 2
'
CALL
'
'
CASE
'
CHARACTER
'
CLASS 1
'
CLOSE 4
'
'
COMMON
'
COMPLEX
'
CONTAINS
CONTIGUOUS 3
'
CONTINUE
'
'
CYCLE
'
DATA
'
DEALLOCATE
'
'
Derived Type
DIMENSION
'
DO
'
DO WHILE
'
© Copyright IBM Corp. 1996, 2012
271

Table 32. Statements table (continued)
Executable
Specification
Terminal
Statement Name
Statement
Statement
Statement
DOUBLE COMPLEX 2
'
DOUBLE PRECISION
'
ELSE
'
ELSE IF
'
ELSEWHERE
'
END
'
END ASSOCIATE 1
'
END BLOCK DATA
END DO
'
'
END ENUM 1
'
END IF
'
END FORALL
'
END FUNCTION
'
END INTERFACE
'
END MAP 2
'
END MODULE
END PROGRAM
'
END SELECT
'
END SUBROUTINE
'
END STRUCTURE 2
'
END TYPE
'
END UNION 2
'
END WHERE
'
ENDFILE
'
'
ENTRY
'
ENUM 1
'
ENUMERATOR 1
'
EQUIVALENCE
'
ERROR STOP 3
'
EXIT
'
EXTERNAL
'
FLUSH 1 4
'
'
FORALL
'
'
FORMAT 4
'
FUNCTION
GO TO (Assigned)
'
GO TO (Computed)
'
'
GO TO (Unconditional)
'
IF (Arithmetic)
'
272
XL Fortran: Language Reference

Table 32. Statements table (continued)
Executable
Specification
Terminal
Statement Name
Statement
Statement
Statement
IF (Block)
'
IF (Logical)
'
'
IMPLICIT
'
IMPORT 1
'
INQUIRE 4
'
'
INTEGER
'
INTENT
'
INTERFACE
'
INTRINSIC
'
LOGICAL
'
MAP 2
'
MODULE
MODULE PROCEDURE
'
NAMELIST 4
'
NULLIFY
'
'
OPEN
'
'
OPTIONAL
'
PARAMETER
'
PAUSE
'
'
POINTER (Fortran 90)
'
POINTER (integer) 2
'
PRINT 4
'
'
PRIVATE
'
PROCEDURE 1
'
PROGRAM
PROTECTED 1
'
PUBLIC
'
READ 4
'
'
REAL
'
RECORD 2
'
RETURN
'
REWIND 4
'
'
SAVE
'
SELECT CASE
'
SELECT TYPE 1
'
SEQUENCE
'
Statement Function
'
STATIC 2
'
STOP
'
Chapter 11. Statements and attributes
273

Table 32. Statements table (continued)
Executable
Specification
Terminal
Statement Name
Statement
Statement
Statement
SUBROUTINE
STRUCTURE 2
'
TARGET
'
TYPE
'
Type Declaration
'
Type Guard 1
'
UNION 2
'
USE
'
VALUE 1
'
VECTOR 2
'
VIRTUAL 2
'
VOLATILE
'
WAIT 1 4
'
'
WHERE
'
'
WRITE 4
'
'
Notes:
1 Fortran 2003
2 IBM extension
3 Fortran 2008
4 PPU only
Assignment and pointer assignment statements are discussed in Chapter 6,
“Expressions and assignment,” on page 97. Both statements are executable and can
serve as terminal statements.
Attributes
Each attribute has a corresponding attribute specification statement, and the syntax
diagram provided for the attribute illustrates this form. An entity can also acquire
this attribute from a type declaration statement or, in some cases, through a default
setting. For example, entity A, said to have the PRIVATE attribute, could have
acquired the attribute in any of the following ways:
REAL, PRIVATE :: A
! Type declaration statement
PRIVATE :: A
! Attribute specification statement
MODULE X
PRIVATE
! Default setting
REAL :: A
END MODULE
ABSTRACT (Fortran 2003)
Purpose
The ABSTRACT INTERFACE statement is the first statement of an abstract
interface block, which can specify procedure characteristics and dummy argument
names without declaring a procedure with those characteristics.
274
XL Fortran: Language Reference

Syntax
ABSTRACT INTERFACE
Rules
If the interface statement is ABSTRACT INTERFACE, then the function_name in
the function statement or the subroutine-name in the subroutine statement shall not
be the same as a keyword that specifies an intrinsic type.
As an ABSTRACT INTERFACE cannot have a generic specification, a
PROCEDURE statement is not allowed in the ABSTRACT INTERFACE block.
A proc-language-binding-spec with a NAME= specifier shall not be specified in the
function or subroutine statement of an abstract interface body.
Examples
ABSTRACT INTERFACE can be used to declare the interface for deferred
bindings.
ABSTRACT INTERFACE
REAL FUNCTION PROC(A, B, C)
REAL, INTENT (IN) :: A, B, C
END FUNCTION
END INTERFACE
! P is declared to be a procedure pointer that is
! initially null with the same interfaceas procedure PROC.
PROCEDURE (PROC),POINTER:: P => NULL()
Procedure pointer P can point to any external procedure or module procedure if it
has the same interface as PROC.
Related information
v
“Abstract interface (Fortran 2003)” on page 170
v
“INTERFACE” on page 389
ALLOCATABLE (Fortran 2003)
Purpose
The ALLOCATABLE attribute allows you to declare an allocatable object. You can
dynamically allocate the storage space of these objects by executing an ALLOCATE
statement or by a derived-type assignment statement. If the object is an array, it is
a deferred-shape array.
Syntax
Chapter 11. Statements and attributes
275

ALLOCATABLE
::
,
object_name
(
deferred_shape_spec_list
)
object_name
The name of an allocatable object.
deferred_shape_spec
A colon, where each colon represents a dimension.
Rules
The object must not be a pointee.
If the object is an array specified elsewhere in the scoping unit with the
DIMENSION attribute, the array specification must be a deferred_shape_spec.
You can initialize an allocatable object after the storage space is allocated. If you
compile your program with -qinitalloc, all uninitialized allocated objects are
initialized.
Table 33. Attributes compatible with the ALLOCATABLE attribute
ASYNCHRONOUS
OPTIONAL
SAVE
AUTOMATIC 2
PRIVATE
STATIC 2
DIMENSION
PROTECTED 1
TARGET
INTENT
PUBLIC
VOLATILE
Note:
1 Fortran 2003
2 IBM extension
Examples
! Two-dimensional array a declared but no space yet allocated
REAL, ALLOCATABLE :: a(:, :)
READ (5, *) i, j
ALLOCATE(a(i, j))
Related information
v
“Allocatable arrays” on page 80
v
“ALLOCATED(X)” on page 552
v
“ALLOCATE” on page 277
v
“DEALLOCATE” on page 319
v
“Allocation status” on page 25
v
“Deferred-shape arrays” on page 79
v
“Allocatable objects as dummy arguments (Fortran 2003)” on page 192
v
“Allocatable components” on page 50
276
XL Fortran: Language Reference

v
The -qinitalloc option
ALLOCATE
Purpose
The ALLOCATE statement dynamically provides storage for pointer targets and
allocatable objects.
Syntax
ALLOCATE
(
allocation_list
(1)
,
STAT
=
stat_variable
i_d_type_spec
::
)
(2)
(3)
(4)
,
ERRMSG
=
errmsg_variable
,
SOURCE
=
source_expr
,
MOLD
=
source_expr
Notes:
1
Fortran 2003
2
Fortran 2003
3
Fortran 2003
4
Fortran 2008
stat_variable
A scalar integer variable.
errmsg_variable (Fortran 2003)
A scalar character variable.
source_expr (Fortran 2003)
An expression which is scalar or has the same rank as allocate_object.
i_d_type_spec (Fortran 2003)
Is an intrinsic_type_spec or derived_type_spec. See “Type Declaration” on
page 456 for a list of possible type specifications.
allocation_list
allocate_object
,
(
upper_bound
)
lower_bound
:
allocate_object
A variable name or structure component that must be a data pointer or an
allocatable object.
lower_bound, upper_bound
are each scalar integer expressions.
Chapter 11. Statements and attributes
277

Rules
Execution of an ALLOCATE statement for a pointer causes the pointer to become
associated with the target allocated. For an allocatable object, the object becomes
definable.
The number of dimensions specified (that is, the number of upper bounds in
allocation) must be equal to the rank of allocate_object,
F2008
unless you specify
SOURCE= or MOLD= F2008
. When an ALLOCATE statement is executed for
an array, the values of the bounds are determined at that time. Subsequent
redefinition or undefinition of any entities in the bound expressions does not affect
the array specification. Any lower bound, if omitted, is assigned a default value of
1. If any lower bound value exceeds the corresponding upper bound value, that
dimension has an extent of 0 and allocate_object is zero-sized.
If you allocate a polymorphic allocate_object using i_d_type_spec, allocation
of the object occurs with the dynamic type and type parameters you specify. If you
specify source_expr, the polymorphic allocate_object has the same dynamic type and
type parameters as the source_expr. Otherwise the allocation_object has the same
dynamic type as the declared type.
If any allocate_object is unlimited polymorphic or has deferred type parameters,
either i_d_type_spec or SOURCE= must appear. If an i_d_type_spec appears, it must
specify a type with which each allocate_object is type-compatible. If SOURCE=
appears, i_d_type_spec must not appear, and allocation_list can only contain one
allocate_object, which must be type-compatible with source_expr.
Any allocate_object or a specified bound of an allocate_object must not depend on the
value of stat_variable or errmsg_variable, or on the value, bounds, length type
parameters, allocation status, or association status of any allocate_object in the same
ALLOCATE statement
stat_variable,source_expr, and errmsg_variable must not be allocated within the
ALLOCATE statement in which they appear. They also must not depend on the
value, bounds, length type parameters, allocation status, or association status of
any allocate_object in the same ALLOCATE statement.
F2008
When you use an ALLOCATE statement without specifying the bounds for an
array, the bounds of source_expr in the SOURCE= or MOLD= specifier determine
the bounds of the array. Subsequent changes to the bounds of source_expr do not
affect the array bounds.
Note: In the same ALLOCATE statement, you can specify only one of SOURCE=
or MOLD=.
The MOLD= specifier works almost in the same way as SOURCE=. If you specify
MOLD= and source_expr is a variable, its value need not be defined. In addition,
MOLD= does not copy the value of source_expr to the variable to be allocated.
F2008
If the STAT= specifier is not present and an error condition occurs during
execution of the statement, the program terminates. If the STAT= specifier is
present, the stat_variable is assigned one of the following values:
278
XL Fortran: Language Reference

Stat value
Error condition
0
No error
1
Error in system routine attempting to do
allocation
2
An invalid data object has been specified for
allocation
3
Both error conditions 1 and 2 have occurred
If an error condition occurs during execution of the ALLOCATE
statement and the ERRMSG=specifier is present, an explanatory message is assigned
to errmsg_variable. If no such condition occurs, the value of errmsg_variable is not
changed.
Allocating an allocatable object that is already allocated causes an error condition
in the ALLOCATE statement.
Pointer allocation creates an object that has the TARGET attribute. Additional
pointers can be associated with this target (or a subobject of it) through pointer
assignment. If you reallocate a pointer that is already associated with a target:
v
A new target is created and the pointer becomes associated with this target.
v
Any previous association with the pointer is broken.
v
Any previous target that had been created by allocation and is not associated
with any other pointers becomes inaccessible.
When an object of derived type is created by an ALLOCATE statement, any
allocatable ultimate components have an allocation status of not currently
allocated.
Use the ALLOCATED intrinsic function to determine if an allocatable object is
currently allocated. Use the ASSOCIATED intrinsic function to determine the
association status of a pointer or whether a pointer is currently associated with a
specified target.
Examples
CHARACTER, POINTER :: P(:,:)
CHARACTER, TARGET :: C(4,4)
INTEGER, ALLOCATABLE, DIMENSION(:) :: A
P => C
N = 2; M = N
ALLOCATE (P(N,M),STAT=I)
! P is no longer associated with C
N = 3
! Target array for P maintains 2X2 shape
IF (.NOT.ALLOCATED(A)) ALLOCATE (A(N**2))
END
The following example uses the MOLD= specifier in an ALLOCATE statement in
which the bounds are determined by reference to another object:
INTEGER, ALLOCATABLE :: NEW(:)
INTEGER, POINTER :: OLD(:)
ALLOCATE(OLD(4))
ALLOCATE (NEW, MOLD=OLD) ! Allocate NEW with the bounds of OLD
END
Chapter 11. Statements and attributes
279

Related information
v
“ALLOCATABLE (Fortran 2003)” on page 275
v
“DEALLOCATE” on page 319
v
“Allocation status” on page 25
v
“Pointer association” on page 154
v
“Deferred-shape arrays” on page 79
v
“ALLOCATED(X)” on page 552
v
“ASSOCIATED(POINTER, TARGET)” on page 557
v
“Allocatable objects as dummy arguments (Fortran 2003)” on page 192
v
“Allocatable components” on page 50
ASSIGN
Purpose
The ASSIGN statement assigns a statement label to an integer variable.
Syntax
ASSIGN
stmt_label
TO
variable_name
stmt_label
specifies the statement label of an executable statement or a FORMAT
statement in the scoping unit containing the ASSIGN statement
variable_name
is the name of a scalar INTEGER(4) or INTEGER(8) variable
Rules
A statement containing the designated statement label must appear in the same
scoping unit as the ASSIGN statement.
v
If the statement containing the statement label is an executable statement, you
can use the label name in an assigned GO TO statement that is in the same
scoping unit.
v
If the statement containing the statement label is a FORMAT statement, you can
use the label name as the format specifier in a READ, WRITE, or PRINT
statement that is in the same scoping unit.
You can redefine an integer variable defined with a statement label value with the
same or different statement label value or an integer value. However, you must
define the variable with a statement label value before you reference it in an
assigned GO TO statement or as a format identifier in an input/output statement.
The value of variable_name is not the integer constant represented by the label itself,
and you cannot use it as such.
The ASSIGN statement has been deleted from Fortran 95 and higher.
280
XL Fortran: Language Reference

Examples
ASSIGN 30 TO LABEL
NUM = 40
GO TO LABEL
NUM = 50
! This statement is not executed
30
ASSIGN 1000 TO IFMT
PRINT IFMT, NUM
! IFMT is the format specifier
1000
FORMAT(1X,I4)
END
Related information
v
“Statement labels” on page 7
v
“GO TO (assigned)” on page 367
v
“Deleted features” on page 872
ASSOCIATE (Fortran 2003)
Purpose
An ASSOCIATE statement is the first statement in an ASSOCIATE construct. It
establishes an association between each identifier and either a variable or the value
of an expression.
Syntax
,
ASSOCIATE
(
associate_name
=>
selector
)
associate_construct_name
:
associate_construct_name
is a name that identifies the ASSOCIATE construct
associate_name
is an identifier that once associated with the selector, becomes an
associating entity.
selector is a variable or expression that once associated becomes the associated
entity.
Rules
If the selector is an expression or a variable with a vector subscript, the
associate_name is assigned the value of the expression or variable. That associating
entity must not become redefined or undefined.
If the selector is a variable without a vector subscript, the associate_name is
associated with the data object specified by the selector. Whenever the value of the
associate_name (or the associating entity identified by the associate_name) changes,
the value of the variable changes with it.
If the selector has the ALLOCATABLE attribute, the associating entity does not
have the ALLOCATABLE attribute. If the selector has the POINTER attribute, then
the associating entity has the TARGET attribute. If the selector has the TARGET,
VOLATILE, or
ASYNCHRONOUS
attribute, the associating
entity that is a variable has those attributes.
Chapter 11. Statements and attributes
281

If the selector has the OPTIONAL attribute, it must be present.
An associating entity has the same type, type parameters, and rank as the selector.
If the selector is polymorphic, the associating entity is polymorphic. If the selector is
an array, the associating entity is an array with a lower bound for each dimension
equal to the value of the intrinsic LBOUND(selector). The upper bound for each
dimension is equal to the lower bound plus the extent minus 1.
An associate_name must be unique within an ASSOCIATE construct.
If the associate_construct_name appears on an ASSOCIATE construct statement, it
must also appear on the corresponding END ASSOCIATE statement.
An ASSOCIATE construct statement must not appear within the dynamic or
lexical extent of a .
Examples
test_equiv: ASSOCIATE (a1 => 2, a2 => 40, a3 => 80)
IF ((a1 * a2) .eq. a3) THEN
PRINT *, "a3 = (a1 * a2)"
END IF
END ASSOCIATE test_equiv
END
Related information
“The scope of a name” on page 148
ASYNCHRONOUS
Purpose
The ASYNCHRONOUS statement specifies which variables may be associated
with a pending I/O storage sequence while the scoping unit is in action.
Syntax
ASYNCHRONOUS
::
ioitem_list
ioitem
is a variable name
Rules
The ASYNCHRONOUS attribute may be assigned implicitly by using a variable in
an ASYNCHRONOUS I/O statement.
An object may have the ASYNCHRONOUS attribute in a particular scoping unit
without having it in other scoping units.
If an object has the ASYNCHRONOUS attribute, then all of its subobjects have the
ASYNCHRONOUS attribute.
282
XL Fortran: Language Reference

An entity may have the ASYNCHRONOUS or VOLATILE attribute in the local
scoping unit even if the associated module entity does not.
An accessed entity may have the ASYNCHRONOUS or VOLATILE attribute even
if the host entity does not.
An associating entity has the ASYNCHRONOUS attribute if and only if the
selector is a variable and has the ASYNCHRONOUS attribute.
Examples
MODULE MOD
INTEGER :: IOITEM
END MODULE
PROGRAM MAIN
CALL SUB1()
CALL SUB2()
END PROGRAM
SUBROUTINE SUB1() ! OPTIMIZATION MAY NOT BE PERFORMED
USE MOD
ASYNCHRONOUS :: IOITEM
....
END SUBROUTINE
SUBROUTINE SUB2() ! OPTIMIZATION MAY BE PERFORMED
USE MOD
.....
END SUBROUTINE
! OPTIMIZATION IS NOT POSSIBLE IN SUB2()IF MODULE MOD IS REWRITTEN AS FOLLOWS:
MODULE MOD
INTEGER, ASYNCHRONOUS :: IOITEM
END MODULE
Related information
v
“Asynchronous Input/Output” on page 209
v
“OPEN” on page 399
v
“CLOSE” on page 302
v
“INQUIRE” on page 375
v
“READ” on page 423
v
“WAIT (Fortran 2003)” on page 471
v
“WRITE” on page 475
AUTOMATIC (IBM extension)
Purpose
The AUTOMATIC attribute specifies that a variable has a storage class of
automatic; that is, the variable is not defined once the procedure ends.
Syntax
Chapter 11. Statements and attributes
283

AUTOMATIC
automatic_list
::
automatic
is a variable name or an array declarator with an explicit-shape
specification list or a deferred-shape specification list
Rules
If automatic is a function result it must not be of type character or of derived type.
Function results that are pointers or arrays, dummy arguments, statement
functions, automatic objects, or pointees must not have the AUTOMATIC
attribute. A variable with the AUTOMATIC attribute cannot be defined in the
scoping unit of a module. A variable that is explicitly declared with the
AUTOMATIC attribute cannot be a common block item.
A variable must not have the AUTOMATIC attribute specified more than once in
the same scoping unit.
Any variable declared as AUTOMATIC within the scope of a thread's work will be
local to that thread.
A variable with the AUTOMATIC attribute cannot be initialized by a DATA
statement or a type declaration statement.
If automatic is a pointer, the AUTOMATIC attribute applies to the pointer itself,
not to any target that is (or may become) associated with the pointer.
Note: An object with the AUTOMATIC attribute should not be confused with an
automatic object. See “Automatic objects” on page 18.
Table 34. Attributes compatible with the AUTOMATIC attribute
ALLOCATABLE 1
CONTIGUOUS 2
VOLATILE
ASYNCHRONOUS
POINTER
DIMENSION
TARGET
Note:
1 Fortran 2003
2 Fortran 2008
Examples
CALL SUB
CONTAINS
SUBROUTINE SUB
INTEGER, AUTOMATIC :: VAR
VAR = 12
END SUBROUTINE
! VAR becomes undefined
END
Related information
v
“Storage classes for variables (IBM extension)” on page 26
v
-qinitauto option in the XL Fortran Compiler Reference
284
XL Fortran: Language Reference

BACKSPACE
Purpose
The BACKSPACE statement positions an external file connected for sequential
access
or formatted stream access.
Execution of a BACKSPACE statement performs a wait operation for any
pending asynchronous data transfer operations for the specified unit.
Syntax
BACKSPACE
u
(
position_list
)
u
is an external unit identifier. The value of u must not be an asterisk or a
Hollerith constant.
position_list
is a list that must contain one unit specifier ([UNIT=]u) and can also
contain one of each of the other valid specifiers:
[UNIT=] u
is a unit specifier in which u must be an external unit identifier whose
value is not an asterisk. An external unit identifier refers to an external file
that is represented by an integer expression. The integer expression has
one of the following values:
v
A value in the range 1 through 2147483647
v
F2008
A NEWUNIT value F2008
If the optional characters UNIT= are omitted, u must be the first item in
position_list.
ERR= stmt_label
is an error specifier that specifies the statement label of an executable
statement in the same scoping unit to which control is to transfer in the
case of an error. Coding the ERR= specifier suppresses error messages.
IOMSG= iomsg_variable (Fortran 2003)
is an input/output status specifier that specifies the message returned by
the input/output operation. iomsg_variable is a scalar default character
variable. It must not be a use-associated nonpointer protected variable.
When the input/output statement containing this specifier finishes
execution, iomsg_variable is defined as follows:
v
If an error, end-of-file, or end-of-record condition occurs, the variable is
assigned an explanatory message as if by assignment.
v
If no such condition occurs, the value of the variable is unchanged.
IOSTAT= ios
is an input/output status specifier that specifies the status of the
input/output operation. ios is an variable. When the BACKSPACE
statement finishes executing, ios is defined with:
v
A zero value if no error condition occurs
v
A positive value if an error occurs.
Chapter 11. Statements and attributes
285

Rules
After the execution of a BACKSPACE statement, the file position is before the
current record if a current record exists. If there is no current record, the file
position is before the preceding record. If the file is at its initial point, file position
remains unchanged.
You cannot backspace over records that were written using list-directed or namelist
formatting.
For sequential access, if the preceding record is the endfile record, the file is
positioned before the endfile record.
If the ERR= and IOSTAT= specifiers are set and an error is encountered, transfer is
made to the statement specified by the ERR= specifier and a positive integer value
is assigned to ios.
IBM extension
If IOSTAT= and ERR= are not specified,
v
The program stops if a severe error is encountered.
v
The program continues to the next statement if a recoverable error is
encountered and the ERR_RECOVERY run-time option is set to YES. If the
option is set to NO, the program stops.
End of IBM extension
Examples
BACKSPACE 15
BACKSPACE (UNIT=15,ERR=99)
...
99 PRINT *, "Unable to backspace file."
END
Related information
v
“Conditions and IOSTAT values” on page 215
v
Chapter 9, “XL Fortran Input/Output,” on page 203
v
Setting Run-Time Options in the XL Fortran Compiler Reference
BIND (Fortran 2003)
Purpose
The BIND attribute declares that a Fortran variable or common block is
interoperable with the C programming language.
Syntax
286
XL Fortran: Language Reference

,
BIND
(
C
)
variable_name
,
NAME
=
binding_label
::
common_block_name
binding_label
is a scalar character constant expression
Rules
This attribute specifies that a Fortran variable or common block is interoperable
with a C entity with external linkage. Refer to “Interoperability of Variables” on
page 782 and “Interoperability of common blocks” on page 782 for details.
If the NAME= specifier appears in a BIND statement, then only one variable_name
or common_block_name can appear.
If a BIND statement specifies a common block, then each variable of that common
block must be of interoperable type and type parameters, and must not have the
POINTER or ALLOCATABLE attribute.
Table 35. Attributes compatible with the BIND attribute
ASYNCHRONOUS
SAVE
DIMENSION
STATIC 2
PRIVATE
TARGET
PROTECTED 1
VOLATILE
PUBLIC
Note:
1 Fortran 2003
2 IBM extension
Related information
v
Chapter 17, “Language interoperability features (Fortran 2003),” on page 781
v
“Interoperability of Variables” on page 782
v
“Interoperability of common blocks” on page 782
v
“ENTRY” on page 344
v
“FUNCTION” on page 364
v
“PROCEDURE declaration (Fortran 2003)” on page 417
v
“SUBROUTINE” on page 449
v
“Derived Type” on page 321
v
–qbindcextname
BLOCK (Fortran 2008)
Purpose
The BLOCK statement declares a named or an unnamed BLOCK construct. It is
the first statement of the BLOCK construct.
Syntax
Chapter 11. Statements and attributes
287

BLOCK
BLOCK_construct_name
:
BLOCK_construct_name
is a name that identifies the BLOCK construct.
Rules
If you specify a BLOCK_construct_name in a BLOCK statement, you must specify
the same name in the corresponding END BLOCK statement.
Example
In the following example, the BLOCK statement declares an unnamed BLOCK
construct:
SUBROUTINE swap(i, j)
INTEGER :: i, j
IF (i < j)
! The BLOCK statement has no BLOCK_construct_name. The corrsponding END BLOCK
! statement cannot have a BLOCK_construct_name either.
BLOCK
INTEGER :: temp
temp = i
i = j
j = temp
END BLOCK
END IF
END SUBROUTINE swap
Related information
v
“BLOCK construct (Fortran 2008)” on page 133
v
“END (Construct)” on page 337
BLOCK DATA
Purpose
A BLOCK DATA statement is the first statement in a block data program unit,
which provides initial values for variables in named common blocks.
Syntax
BLOCK DATA
block_data_name
block_data_name
is the name of a block data program unit
288
XL Fortran: Language Reference

Rules
You can have more than one block data program unit in an executable program,
but only one can be unnamed.
The name of the block data program unit, if given, must not be the same as an
external subprogram, entry, main program, module, or common block in the
executable program. It also must not be the same as a local entity in this program
unit.
Examples
BLOCK DATA ABC
PARAMETER (I=10)
DIMENSION Y(5)
COMMON /L4/ Y
DATA Y /5*I/
END BLOCK DATA ABC
Related information
v
“Block data program unit” on page 175
v
“END” on page 335 for details on the END BLOCK DATA statement
BYTE (IBM extension)
Purpose
The BYTE type declaration statement specifies the attributes of objects and
functions of type byte. Each scalar object has a length of 1. Initial values can be
assigned to objects.
Syntax
BYTE
entity_decl_list
::
,
attr_spec_list
::
where:
attr_spec
is any of the following:
ALLOCATABLE 1
INTRINSIC
PUBLIC
ASYNCHRONOUS
OPTIONAL
SAVE
AUTOMATIC 2
PARAMETER
STATIC 2
BIND 1
POINTER
TARGET
DIMENSION (array_spec)
PRIVATE
VALUE 1
EXTERNAL
PROTECTED 1
VOLATILE
INTENT (intent_spec)
Note:
1 Fortran 2003
2 IBM extension
Chapter 11. Statements and attributes
289

attr_spec
For detailed information on rules about a particular attribute, refer to the
statement of