OpenMP API Specification 5 1

OpenMP
Application Programming
Interface
Version 5.1 November 2020
c
Copyright 1997-2020 OpenMP Architecture Review Board.
Permission to copy without fee all or part of this material is granted, provided the OpenMP
Architecture Review Board copyright notice and the title of this document appear. Notice is
given that copying is by permission of the OpenMP Architecture Review Board.
This page intentionally left blank in published version.
Contents
1 Overview of the OpenMP API 1

1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Threading Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 OpenMP Language Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Loop Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Synchronization Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.5 Tasking Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.6 Data Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.7 Implementation Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.8 Tool Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.1 Structure of the OpenMP Memory Model . . . . . . . . . . . . . . . . . . . 25
1.4.2 Device Data Environments . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.4 The Flush Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.5 Flush Synchronization and Happens Before . . . . . . . . . . . . . . . . . . 29
1.4.6 OpenMP Memory Consistency . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5 Tool Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.5.1 OMPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.5.2 OMPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6 OpenMP Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.8 Organization of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
i
2 Directives 37
2.1 Directive Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.1 Fixed Source Form Directives . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1.2 Free Source Form Directives . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1.3 Stand-Alone Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1.4 Array Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1.5 Array Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.1.6 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2 Conditional Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2.1 Fixed Source Form Conditional Compilation Sentinels . . . . . . . . . . . . 52
2.2.2 Free Source Form Conditional Compilation Sentinel . . . . . . . . . . . . . 53
2.3 Variant Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.1 OpenMP Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.2 Context Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.3 Matching and Scoring Context Selectors . . . . . . . . . . . . . . . . . . . 59
2.3.4 Metadirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3.5 Declare Variant Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.3.6 dispatch Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.4 Internal Control Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.4.1 ICV Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.4.2 ICV Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.4.3 Modifying and Retrieving ICV Values . . . . . . . . . . . . . . . . . . . . 77
2.4.4 How ICVs are Scoped . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.4.4.1 How the Per-Data Environment ICVs Work . . . . . . . . . . . . . . . 81
2.4.5 ICV Override Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.5 Informational and Utility Directives . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.5.1 requires Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.5.2 Assume Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.5.3 nothing Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.5.4 error Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.6 parallel Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.6.1 Determining the Number of Threads for a parallel Region . . . . . . . . 96
2.6.2 Controlling OpenMP Thread Affinity . . . . . . . . . . . . . . . . . . . . . 98
ii OpenMP API – Version 5.1 November 2020

2.7 teams Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
2.8 masked Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.9 scope Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.10 Worksharing Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.10.1 sections Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.10.2 single Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.10.3 workshare Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.11 Loop-Related Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.11.1 Canonical Loop Nest Form . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.11.2 Consistent Loop Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.11.3 order Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.11.4 Worksharing-Loop Construct . . . . . . . . . . . . . . . . . . . . . . . . . 126
2.11.4.1 Determining the Schedule of a Worksharing-Loop . . . . . . . . . . . . 133
2.11.5 SIMD Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
2.11.5.1 simd Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
2.11.5.2 Worksharing-Loop SIMD Construct . . . . . . . . . . . . . . . . . . . 138
2.11.5.3 declare simd Directive . . . . . . . . . . . . . . . . . . . . . . . . 140
2.11.6 distribute Loop Constructs . . . . . . . . . . . . . . . . . . . . . . . . 143
2.11.6.1 distribute Construct . . . . . . . . . . . . . . . . . . . . . . . . . 143
2.11.6.2 distribute simd Construct . . . . . . . . . . . . . . . . . . . . . . 147
2.11.6.3 Distribute Parallel Worksharing-Loop Construct . . . . . . . . . . . . . 148
2.11.6.4 Distribute Parallel Worksharing-Loop SIMD Construct . . . . . . . . . 149
2.11.7 loop Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
2.11.8 scan Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.11.9 Loop Transformation Constructs . . . . . . . . . . . . . . . . . . . . . . . 157
2.11.9.1 tile Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
2.11.9.2 unroll Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
2.12 Tasking Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
2.12.1 task Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
2.12.2 taskloop Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
2.12.3 taskloop simd Construct . . . . . . . . . . . . . . . . . . . . . . . . . 171
2.12.4 taskyield Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
2.12.5 Initial Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Contents iii
2.12.6 Task Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
2.13 Memory Management Directives . . . . . . . . . . . . . . . . . . . . . . . . . . 177
2.13.1 Memory Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
2.13.2 Memory Allocators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
2.13.3 allocate Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
2.13.4 allocate Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
2.14 Device Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
2.14.1 Device Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
2.14.2 target data Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
2.14.3 target enter data Construct . . . . . . . . . . . . . . . . . . . . . . . 191
2.14.4 target exit data Construct . . . . . . . . . . . . . . . . . . . . . . . 193
2.14.5 target Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
2.14.6 target update Construct . . . . . . . . . . . . . . . . . . . . . . . . . 205
2.14.7 Declare Target Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
2.15 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
2.15.1 interop Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
2.15.2 Interoperability Requirement Set . . . . . . . . . . . . . . . . . . . . . . . 220
2.16 Combined Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
2.16.1 Parallel Worksharing-Loop Construct . . . . . . . . . . . . . . . . . . . . . 221
2.16.2 parallel loop Construct . . . . . . . . . . . . . . . . . . . . . . . . . 222
2.16.3 parallel sections Construct . . . . . . . . . . . . . . . . . . . . . . 223
2.16.4 parallel workshare Construct . . . . . . . . . . . . . . . . . . . . . 224
2.16.5 Parallel Worksharing-Loop SIMD Construct . . . . . . . . . . . . . . . . . 225
2.16.6 parallel masked Construct . . . . . . . . . . . . . . . . . . . . . . . . 226
2.16.7 masked taskloop Construct . . . . . . . . . . . . . . . . . . . . . . . . 228
2.16.8 masked taskloop simd Construct . . . . . . . . . . . . . . . . . . . . 229
2.16.9 parallel masked taskloop Construct . . . . . . . . . . . . . . . . . 230
2.16.10 parallel masked taskloop simd Construct . . . . . . . . . . . . . . 231
2.16.11 teams distribute Construct . . . . . . . . . . . . . . . . . . . . . . . 233
2.16.12 teams distribute simd Construct . . . . . . . . . . . . . . . . . . . 234
2.16.13 Teams Distribute Parallel Worksharing-Loop Construct . . . . . . . . . . . 235
2.16.14 Teams Distribute Parallel Worksharing-Loop SIMD Construct . . . . . . . . 236
2.16.15 teams loop Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
iv OpenMP API – Version 5.1 November 2020

2.16.16 target parallel Construct . . . . . . . . . . . . . . . . . . . . . . . . 238
2.16.17 Target Parallel Worksharing-Loop Construct . . . . . . . . . . . . . . . . . 239
2.16.18 Target Parallel Worksharing-Loop SIMD Construct . . . . . . . . . . . . . 241
2.16.19 target parallel loop Construct . . . . . . . . . . . . . . . . . . . . 242
2.16.20 target simd Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
2.16.21 target teams Construct . . . . . . . . . . . . . . . . . . . . . . . . . . 245
2.16.22 target teams distribute Construct . . . . . . . . . . . . . . . . . . 246
2.16.23 target teams distribute simd Construct . . . . . . . . . . . . . . 247
2.16.24 target teams loop Construct . . . . . . . . . . . . . . . . . . . . . . . 248
2.16.25 Target Teams Distribute Parallel Worksharing-Loop Construct . . . . . . . . 249
2.16.26 Target Teams Distribute Parallel Worksharing-Loop SIMD Construct . . . . 251
2.17 Clauses on Combined and Composite Constructs . . . . . . . . . . . . . . . . . . 252
2.18 if Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
2.19 Synchronization Constructs and Clauses . . . . . . . . . . . . . . . . . . . . . . 255
2.19.1 critical Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
2.19.2 barrier Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.19.3 Implicit Barriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
2.19.4 Implementation-Specific Barriers . . . . . . . . . . . . . . . . . . . . . . . 261
2.19.5 taskwait Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
2.19.6 taskgroup Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
2.19.7 atomic Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
2.19.8 flush Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
2.19.8.1 Implicit Flushes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
2.19.9 ordered Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
2.19.10 Depend Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
2.19.10.1 depobj Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
2.19.11 depend Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
2.19.12 Synchronization Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
2.20 Cancellation Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
2.20.1 cancel Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
2.20.2 cancellation point Construct . . . . . . . . . . . . . . . . . . . . . 300
Contents v
2.21 Data Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
2.21.1 Data-Sharing Attribute Rules . . . . . . . . . . . . . . . . . . . . . . . . . 302
2.21.1.1 Variables Referenced in a Construct . . . . . . . . . . . . . . . . . . . 302
2.21.1.2 Variables Referenced in a Region but not in a Construct . . . . . . . . . 306
2.21.2 threadprivate Directive . . . . . . . . . . . . . . . . . . . . . . . . . 307
2.21.3 List Item Privatization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
2.21.4 Data-Sharing Attribute Clauses . . . . . . . . . . . . . . . . . . . . . . . . 315
2.21.4.1 default Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
2.21.4.2 shared Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
2.21.4.3 private Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
2.21.4.4 firstprivate Clause . . . . . . . . . . . . . . . . . . . . . . . . . 318
2.21.4.5 lastprivate Clause . . . . . . . . . . . . . . . . . . . . . . . . . . 321
2.21.4.6 linear Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
2.21.5 Reduction Clauses and Directives . . . . . . . . . . . . . . . . . . . . . . . 325
2.21.5.1 Properties Common to All Reduction Clauses . . . . . . . . . . . . . . 326
2.21.5.2 Reduction Scoping Clauses . . . . . . . . . . . . . . . . . . . . . . . . 331
2.21.5.3 Reduction Participating Clauses . . . . . . . . . . . . . . . . . . . . . 332
2.21.5.4 reduction Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
2.21.5.5 task_reduction Clause . . . . . . . . . . . . . . . . . . . . . . . 335
2.21.5.6 in_reduction Clause . . . . . . . . . . . . . . . . . . . . . . . . . 335
2.21.5.7 declare reduction Directive . . . . . . . . . . . . . . . . . . . . 336
2.21.6 Data Copying Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
2.21.6.1 copyin Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
2.21.6.2 copyprivate Clause . . . . . . . . . . . . . . . . . . . . . . . . . . 343
2.21.7 Data-Mapping Attribute Rules, Clauses, and Directives . . . . . . . . . . . 345
2.21.7.1 map Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
2.21.7.2 Pointer Initialization for Device Data Environments . . . . . . . . . . . 356
2.21.7.3 defaultmap Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
2.21.7.4 declare mapper Directive . . . . . . . . . . . . . . . . . . . . . . . 358
2.22 Nesting of Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
3 Runtime Library Routines 365

3.1 Runtime Library Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
vi OpenMP API – Version 5.1 November 2020

3.2 Thread Team Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
3.2.1 omp_set_num_threads . . . . . . . . . . . . . . . . . . . . . . . . . . 368
3.2.2 omp_get_num_threads . . . . . . . . . . . . . . . . . . . . . . . . . . 369
3.2.3 omp_get_max_threads . . . . . . . . . . . . . . . . . . . . . . . . . . 370
3.2.4 omp_get_thread_num . . . . . . . . . . . . . . . . . . . . . . . . . . 371
3.2.5 omp_in_parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
3.2.6 omp_set_dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
3.2.7 omp_get_dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
3.2.8 omp_get_cancellation . . . . . . . . . . . . . . . . . . . . . . . . . 374
3.2.9 omp_set_nested (Deprecated) . . . . . . . . . . . . . . . . . . . . . . 375
3.2.10 omp_get_nested (Deprecated) . . . . . . . . . . . . . . . . . . . . . . 376
3.2.11 omp_set_schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
3.2.12 omp_get_schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
3.2.13 omp_get_thread_limit . . . . . . . . . . . . . . . . . . . . . . . . . 380
3.2.14 omp_get_supported_active_levels . . . . . . . . . . . . . . . . 380
3.2.15 omp_set_max_active_levels . . . . . . . . . . . . . . . . . . . . . 381
3.2.16 omp_get_max_active_levels . . . . . . . . . . . . . . . . . . . . . 382
3.2.17 omp_get_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
3.2.18 omp_get_ancestor_thread_num . . . . . . . . . . . . . . . . . . . 384
3.2.19 omp_get_team_size . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
3.2.20 omp_get_active_level . . . . . . . . . . . . . . . . . . . . . . . . . 385
3.3 Thread Affinity Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
3.3.1 omp_get_proc_bind . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
3.3.2 omp_get_num_places . . . . . . . . . . . . . . . . . . . . . . . . . . 388
3.3.3 omp_get_place_num_procs . . . . . . . . . . . . . . . . . . . . . . 389
3.3.4 omp_get_place_proc_ids . . . . . . . . . . . . . . . . . . . . . . . 389
3.3.5 omp_get_place_num . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
3.3.6 omp_get_partition_num_places . . . . . . . . . . . . . . . . . . 391
3.3.7 omp_get_partition_place_nums . . . . . . . . . . . . . . . . . . 392
3.3.8 omp_set_affinity_format . . . . . . . . . . . . . . . . . . . . . . 393
3.3.9 omp_get_affinity_format . . . . . . . . . . . . . . . . . . . . . . 394
3.3.10 omp_display_affinity . . . . . . . . . . . . . . . . . . . . . . . . . 395
3.3.11 omp_capture_affinity . . . . . . . . . . . . . . . . . . . . . . . . . 396
Contents vii
3.4 Teams Region Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
3.4.1 omp_get_num_teams . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
3.4.2 omp_get_team_num . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
3.4.3 omp_set_num_teams . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
3.4.4 omp_get_max_teams . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
3.4.5 omp_set_teams_thread_limit . . . . . . . . . . . . . . . . . . . . 400
3.4.6 omp_get_teams_thread_limit . . . . . . . . . . . . . . . . . . . . 401
3.5 Tasking Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
3.5.1 omp_get_max_task_priority . . . . . . . . . . . . . . . . . . . . . 402
3.5.2 omp_in_final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
3.6 Resource Relinquishing Routines . . . . . . . . . . . . . . . . . . . . . . . . . . 404
3.6.1 omp_pause_resource . . . . . . . . . . . . . . . . . . . . . . . . . . 404
3.6.2 omp_pause_resource_all . . . . . . . . . . . . . . . . . . . . . . . 406
3.7 Device Information Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
3.7.1 omp_get_num_procs . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
3.7.2 omp_set_default_device . . . . . . . . . . . . . . . . . . . . . . . 408
3.7.3 omp_get_default_device . . . . . . . . . . . . . . . . . . . . . . . 408
3.7.4 omp_get_num_devices . . . . . . . . . . . . . . . . . . . . . . . . . . 409
3.7.5 omp_get_device_num . . . . . . . . . . . . . . . . . . . . . . . . . . 410
3.7.6 omp_is_initial_device . . . . . . . . . . . . . . . . . . . . . . . . 411
3.7.7 omp_get_initial_device . . . . . . . . . . . . . . . . . . . . . . . 411
3.8 Device Memory Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
3.8.1 omp_target_alloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
3.8.2 omp_target_free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
3.8.3 omp_target_is_present . . . . . . . . . . . . . . . . . . . . . . . . 416
3.8.4 omp_target_is_accessible . . . . . . . . . . . . . . . . . . . . . . 417
3.8.5 omp_target_memcpy . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
3.8.6 omp_target_memcpy_rect . . . . . . . . . . . . . . . . . . . . . . . 419
3.8.7 omp_target_memcpy_async . . . . . . . . . . . . . . . . . . . . . . 422
3.8.8 omp_target_memcpy_rect_async . . . . . . . . . . . . . . . . . . 424
3.8.9 omp_target_associate_ptr . . . . . . . . . . . . . . . . . . . . . . 426
3.8.10 omp_target_disassociate_ptr . . . . . . . . . . . . . . . . . . . 429
3.8.11 omp_get_mapped_ptr . . . . . . . . . . . . . . . . . . . . . . . . . . 430
viii OpenMP API – Version 5.1 November 2020

3.9 Lock Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
3.9.1 omp_init_lock and omp_init_nest_lock . . . . . . . . . . . . . 434
3.9.2 omp_init_lock_with_hint and
omp_init_nest_lock_with_hint . . . . . . . . . . . . . . . . . . 435
3.9.3 omp_destroy_lock and omp_destroy_nest_lock . . . . . . . . . 436
3.9.4 omp_set_lock and omp_set_nest_lock . . . . . . . . . . . . . . . 437
3.9.5 omp_unset_lock and omp_unset_nest_lock . . . . . . . . . . . . 439
3.9.6 omp_test_lock and omp_test_nest_lock . . . . . . . . . . . . . 440
3.10 Timing Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
3.10.1 omp_get_wtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
3.10.2 omp_get_wtick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
3.11 Event Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
3.11.1 omp_fulfill_event . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
3.12 Interoperability Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
3.12.1 omp_get_num_interop_properties . . . . . . . . . . . . . . . . . 446
3.12.2 omp_get_interop_int . . . . . . . . . . . . . . . . . . . . . . . . . . 446
3.12.3 omp_get_interop_ptr . . . . . . . . . . . . . . . . . . . . . . . . . . 447
3.12.4 omp_get_interop_str . . . . . . . . . . . . . . . . . . . . . . . . . . 448
3.12.5 omp_get_interop_name . . . . . . . . . . . . . . . . . . . . . . . . . 449
3.12.6 omp_get_interop_type_desc . . . . . . . . . . . . . . . . . . . . . 450
3.12.7 omp_get_interop_rc_desc . . . . . . . . . . . . . . . . . . . . . . 450
3.13 Memory Management Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
3.13.1 Memory Management Types . . . . . . . . . . . . . . . . . . . . . . . . . 451
3.13.2 omp_init_allocator . . . . . . . . . . . . . . . . . . . . . . . . . . 454
3.13.3 omp_destroy_allocator . . . . . . . . . . . . . . . . . . . . . . . . 455
3.13.4 omp_set_default_allocator . . . . . . . . . . . . . . . . . . . . . 456
3.13.5 omp_get_default_allocator . . . . . . . . . . . . . . . . . . . . . 457
3.13.6 omp_alloc and omp_aligned_alloc . . . . . . . . . . . . . . . . . 458
3.13.7 omp_free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
3.13.8 omp_calloc and omp_aligned_calloc . . . . . . . . . . . . . . . . 461
3.13.9 omp_realloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
3.14 Tool Control Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
3.15 Environment Display Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Contents ix
4 OMPT Interface 471
4.1 OMPT Interfaces Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
4.2 Activating a First-Party Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
4.2.1 ompt_start_tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
4.2.2 Determining Whether a First-Party Tool Should be Initialized . . . . . . . . 473
4.2.3 Initializing a First-Party Tool . . . . . . . . . . . . . . . . . . . . . . . . . 474
4.2.3.1 Binding Entry Points in the OMPT Callback Interface . . . . . . . . . . 475
4.2.4 Monitoring Activity on the Host with OMPT . . . . . . . . . . . . . . . . . 476
4.2.5 Tracing Activity on Target Devices with OMPT . . . . . . . . . . . . . . . 478
4.3 Finalizing a First-Party Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
4.4 OMPT Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
4.4.1 Tool Initialization and Finalization . . . . . . . . . . . . . . . . . . . . . . 485
4.4.2 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
4.4.3 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
4.4.3.1 Record Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
4.4.3.2 Native Record Kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
4.4.3.3 Native Record Abstract Type . . . . . . . . . . . . . . . . . . . . . . . 487
4.4.3.4 Record Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
4.4.4 Miscellaneous Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . 489
4.4.4.1 ompt_callback_t . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
4.4.4.2 ompt_set_result_t . . . . . . . . . . . . . . . . . . . . . . . . . 490
4.4.4.3 ompt_id_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
4.4.4.4 ompt_data_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
4.4.4.5 ompt_device_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
4.4.4.6 ompt_device_time_t . . . . . . . . . . . . . . . . . . . . . . . . 492
4.4.4.7 ompt_buffer_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
4.4.4.8 ompt_buffer_cursor_t . . . . . . . . . . . . . . . . . . . . . . . 493
4.4.4.9 ompt_dependence_t . . . . . . . . . . . . . . . . . . . . . . . . . 493
4.4.4.10 ompt_thread_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
4.4.4.11 ompt_scope_endpoint_t . . . . . . . . . . . . . . . . . . . . . . 494
4.4.4.12 ompt_dispatch_t . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
4.4.4.13 ompt_sync_region_t . . . . . . . . . . . . . . . . . . . . . . . . 495
4.4.4.14 ompt_target_data_op_t . . . . . . . . . . . . . . . . . . . . . . 496
x OpenMP API – Version 5.1 November 2020

4.4.4.15 ompt_work_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
4.4.4.16 ompt_mutex_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
4.4.4.17 ompt_native_mon_flag_t . . . . . . . . . . . . . . . . . . . . . 497
4.4.4.18 ompt_task_flag_t . . . . . . . . . . . . . . . . . . . . . . . . . . 498
4.4.4.19 ompt_task_status_t . . . . . . . . . . . . . . . . . . . . . . . . 498
4.4.4.20 ompt_target_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
4.4.4.21 ompt_parallel_flag_t . . . . . . . . . . . . . . . . . . . . . . . 500
4.4.4.22 ompt_target_map_flag_t . . . . . . . . . . . . . . . . . . . . . 501
4.4.4.23 ompt_dependence_type_t . . . . . . . . . . . . . . . . . . . . . 501
4.4.4.24 ompt_severity_t . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
4.4.4.25 ompt_cancel_flag_t . . . . . . . . . . . . . . . . . . . . . . . . 502
4.4.4.26 ompt_hwid_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
4.4.4.27 ompt_state_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
4.4.4.28 ompt_frame_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
4.4.4.29 ompt_frame_flag_t . . . . . . . . . . . . . . . . . . . . . . . . . 506
4.4.4.30 ompt_wait_id_t . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
4.5 OMPT Tool Callback Signatures and Trace Records . . . . . . . . . . . . . . . . 508
4.5.1 Initialization and Finalization Callback Signature . . . . . . . . . . . . . . . 508
4.5.1.1 ompt_initialize_t . . . . . . . . . . . . . . . . . . . . . . . . . 508
4.5.1.2 ompt_finalize_t . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
4.5.2 Event Callback Signatures and Trace Records . . . . . . . . . . . . . . . . . 510
4.5.2.1 ompt_callback_thread_begin_t . . . . . . . . . . . . . . . . 510
4.5.2.2 ompt_callback_thread_end_t . . . . . . . . . . . . . . . . . . 511
4.5.2.3 ompt_callback_parallel_begin_t . . . . . . . . . . . . . . . 511
4.5.2.4 ompt_callback_parallel_end_t . . . . . . . . . . . . . . . . 513
4.5.2.5 ompt_callback_work_t . . . . . . . . . . . . . . . . . . . . . . . 514
4.5.2.6 ompt_callback_dispatch_t . . . . . . . . . . . . . . . . . . . 515
4.5.2.7 ompt_callback_task_create_t . . . . . . . . . . . . . . . . . 517
4.5.2.8 ompt_callback_dependences_t . . . . . . . . . . . . . . . . . 518
4.5.2.9 ompt_callback_task_dependence_t . . . . . . . . . . . . . . 519
4.5.2.10 ompt_callback_task_schedule_t . . . . . . . . . . . . . . . 520
4.5.2.11 ompt_callback_implicit_task_t . . . . . . . . . . . . . . . 521
4.5.2.12 ompt_callback_masked_t . . . . . . . . . . . . . . . . . . . . . 522
Contents xi
4.5.2.13 ompt_callback_sync_region_t . . . . . . . . . . . . . . . . . 523
4.5.2.14 ompt_callback_mutex_acquire_t . . . . . . . . . . . . . . . 525
4.5.2.15 ompt_callback_mutex_t . . . . . . . . . . . . . . . . . . . . . . 526
4.5.2.16 ompt_callback_nest_lock_t . . . . . . . . . . . . . . . . . . . 527
4.5.2.17 ompt_callback_flush_t . . . . . . . . . . . . . . . . . . . . . . 528
4.5.2.18 ompt_callback_cancel_t . . . . . . . . . . . . . . . . . . . . . 529
4.5.2.19 ompt_callback_device_initialize_t . . . . . . . . . . . . 530
4.5.2.20 ompt_callback_device_finalize_t . . . . . . . . . . . . . . 531
4.5.2.21 ompt_callback_device_load_t . . . . . . . . . . . . . . . . . 532
4.5.2.22 ompt_callback_device_unload_t . . . . . . . . . . . . . . . 533
4.5.2.23 ompt_callback_buffer_request_t . . . . . . . . . . . . . . . 533
4.5.2.24 ompt_callback_buffer_complete_t . . . . . . . . . . . . . . 534
4.5.2.25 ompt_callback_target_data_op_emi_t and
ompt_callback_target_data_op_t . . . . . . . . . . . . . . . 535
4.5.2.26 ompt_callback_target_emi_t and
ompt_callback_target_t . . . . . . . . . . . . . . . . . . . . . 538
4.5.2.27 ompt_callback_target_map_emi_t and
ompt_callback_target_map_t . . . . . . . . . . . . . . . . . . 540
4.5.2.28 ompt_callback_target_submit_emi_t and
ompt_callback_target_submit_t . . . . . . . . . . . . . . . 542
4.5.2.29 ompt_callback_control_tool_t . . . . . . . . . . . . . . . . 544
4.5.2.30 ompt_callback_error_t . . . . . . . . . . . . . . . . . . . . . . 545
4.6 OMPT Runtime Entry Points for Tools . . . . . . . . . . . . . . . . . . . . . . . 546
4.6.1 Entry Points in the OMPT Callback Interface . . . . . . . . . . . . . . . . . 547
4.6.1.1 ompt_enumerate_states_t . . . . . . . . . . . . . . . . . . . . 547
4.6.1.2 ompt_enumerate_mutex_impls_t . . . . . . . . . . . . . . . . 548
4.6.1.3 ompt_set_callback_t . . . . . . . . . . . . . . . . . . . . . . . 549
4.6.1.4 ompt_get_callback_t . . . . . . . . . . . . . . . . . . . . . . . 550
4.6.1.5 ompt_get_thread_data_t . . . . . . . . . . . . . . . . . . . . . 551
4.6.1.6 ompt_get_num_procs_t . . . . . . . . . . . . . . . . . . . . . . . 552
4.6.1.7 ompt_get_num_places_t . . . . . . . . . . . . . . . . . . . . . . 552
4.6.1.8 ompt_get_place_proc_ids_t . . . . . . . . . . . . . . . . . . . 553
4.6.1.9 ompt_get_place_num_t . . . . . . . . . . . . . . . . . . . . . . . 554
xii OpenMP API – Version 5.1 November 2020

4.6.1.10 ompt_get_partition_place_nums_t . . . . . . . . . . . . . . 554
4.6.1.11 ompt_get_proc_id_t . . . . . . . . . . . . . . . . . . . . . . . . 555
4.6.1.12 ompt_get_state_t . . . . . . . . . . . . . . . . . . . . . . . . . . 555
4.6.1.13 ompt_get_parallel_info_t . . . . . . . . . . . . . . . . . . . 556
4.6.1.14 ompt_get_task_info_t . . . . . . . . . . . . . . . . . . . . . . . 558
4.6.1.15 ompt_get_task_memory_t . . . . . . . . . . . . . . . . . . . . . 560
4.6.1.16 ompt_get_target_info_t . . . . . . . . . . . . . . . . . . . . . 561
4.6.1.17 ompt_get_num_devices_t . . . . . . . . . . . . . . . . . . . . . 562
4.6.1.18 ompt_get_unique_id_t . . . . . . . . . . . . . . . . . . . . . . . 562
4.6.1.19 ompt_finalize_tool_t . . . . . . . . . . . . . . . . . . . . . . . 563
4.6.2 Entry Points in the OMPT Device Tracing Interface . . . . . . . . . . . . . 563
4.6.2.1 ompt_get_device_num_procs_t . . . . . . . . . . . . . . . . . 563
4.6.2.2 ompt_get_device_time_t . . . . . . . . . . . . . . . . . . . . . 564
4.6.2.3 ompt_translate_time_t . . . . . . . . . . . . . . . . . . . . . . 565
4.6.2.4 ompt_set_trace_ompt_t . . . . . . . . . . . . . . . . . . . . . . 566
4.6.2.5 ompt_set_trace_native_t . . . . . . . . . . . . . . . . . . . . 567
4.6.2.6 ompt_start_trace_t . . . . . . . . . . . . . . . . . . . . . . . . 568
4.6.2.7 ompt_pause_trace_t . . . . . . . . . . . . . . . . . . . . . . . . 568
4.6.2.8 ompt_flush_trace_t . . . . . . . . . . . . . . . . . . . . . . . . 569
4.6.2.9 ompt_stop_trace_t . . . . . . . . . . . . . . . . . . . . . . . . . 570
4.6.2.10 ompt_advance_buffer_cursor_t . . . . . . . . . . . . . . . . 570
4.6.2.11 ompt_get_record_type_t . . . . . . . . . . . . . . . . . . . . . 571
4.6.2.12 ompt_get_record_ompt_t . . . . . . . . . . . . . . . . . . . . . 572
4.6.2.13 ompt_get_record_native_t . . . . . . . . . . . . . . . . . . . 573
4.6.2.14 ompt_get_record_abstract_t . . . . . . . . . . . . . . . . . . 574
4.6.3 Lookup Entry Points: ompt_function_lookup_t . . . . . . . . . . . 574
5 OMPD Interface 577

5.1 OMPD Interfaces Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
5.2 Activating a Third-Party Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
5.2.1 Enabling Runtime Support for OMPD . . . . . . . . . . . . . . . . . . . . . 578
5.2.2 ompd_dll_locations . . . . . . . . . . . . . . . . . . . . . . . . . . 578
5.2.3 ompd_dll_locations_valid . . . . . . . . . . . . . . . . . . . . . . 579
Contents xiii
5.3 OMPD Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
5.3.1 Size Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
5.3.2 Wait ID Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
5.3.3 Basic Value Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
5.3.4 Address Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
5.3.5 Frame Information Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
5.3.6 System Device Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
5.3.7 Native Thread Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
5.3.8 OMPD Handle Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
5.3.9 OMPD Scope Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
5.3.10 ICV ID Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
5.3.11 Tool Context Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
5.3.12 Return Code Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
5.3.13 Primitive Type Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
5.4 OMPD Third-Party Tool Callback Interface . . . . . . . . . . . . . . . . . . . . . 587
5.4.1 Memory Management of OMPD Library . . . . . . . . . . . . . . . . . . . 588
5.4.1.1 ompd_callback_memory_alloc_fn_t . . . . . . . . . . . . . . 588
5.4.1.2 ompd_callback_memory_free_fn_t . . . . . . . . . . . . . . . 589
5.4.2 Context Management and Navigation . . . . . . . . . . . . . . . . . . . . . 590
5.4.2.1 ompd_callback_get_thread_context_for_thread_id
_fn_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
5.4.2.2 ompd_callback_sizeof_fn_t . . . . . . . . . . . . . . . . . . . 591
5.4.3 Accessing Memory in the OpenMP Program or Runtime . . . . . . . . . . . 592
5.4.3.1 ompd_callback_symbol_addr_fn_t . . . . . . . . . . . . . . . 592
5.4.3.2 ompd_callback_memory_read_fn_t . . . . . . . . . . . . . . . 594
5.4.3.3 ompd_callback_memory_write_fn_t . . . . . . . . . . . . . . 595
5.4.4 Data Format Conversion: ompd_callback_device_host_fn_t . . . 596
5.4.5 ompd_callback_print_string_fn_t . . . . . . . . . . . . . . . . 598
5.4.6 The Callback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
5.5 OMPD Tool Interface Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
5.5.1 Per OMPD Library Initialization and Finalization . . . . . . . . . . . . . . 600
5.5.1.1 ompd_initialize . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
5.5.1.2 ompd_get_api_version . . . . . . . . . . . . . . . . . . . . . . . 602
xiv OpenMP API – Version 5.1 November 2020

5.5.1.3 ompd_get_version_string . . . . . . . . . . . . . . . . . . . . 602
5.5.1.4 ompd_finalize . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
5.5.2 Per OpenMP Process Initialization and Finalization . . . . . . . . . . . . . 604
5.5.2.1 ompd_process_initialize . . . . . . . . . . . . . . . . . . . . 604
5.5.2.2 ompd_device_initialize . . . . . . . . . . . . . . . . . . . . . 605
5.5.2.3 ompd_rel_address_space_handle . . . . . . . . . . . . . . . 606
5.5.3 Thread and Signal Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
5.5.4 Address Space Information . . . . . . . . . . . . . . . . . . . . . . . . . . 607
5.5.4.1 ompd_get_omp_version . . . . . . . . . . . . . . . . . . . . . . . 607
5.5.4.2 ompd_get_omp_version_string . . . . . . . . . . . . . . . . . 608
5.5.5 Thread Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
5.5.5.1 ompd_get_thread_in_parallel . . . . . . . . . . . . . . . . . 609
5.5.5.2 ompd_get_thread_handle . . . . . . . . . . . . . . . . . . . . . 610
5.5.5.3 ompd_rel_thread_handle . . . . . . . . . . . . . . . . . . . . . 611
5.5.5.4 ompd_thread_handle_compare . . . . . . . . . . . . . . . . . . 611
5.5.5.5 ompd_get_thread_id . . . . . . . . . . . . . . . . . . . . . . . . 612
5.5.6 Parallel Region Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
5.5.6.1 ompd_get_curr_parallel_handle . . . . . . . . . . . . . . . 613
5.5.6.2 ompd_get_enclosing_parallel_handle . . . . . . . . . . . 614
5.5.6.3 ompd_get_task_parallel_handle . . . . . . . . . . . . . . . 615
5.5.6.4 ompd_rel_parallel_handle . . . . . . . . . . . . . . . . . . . 616
5.5.6.5 ompd_parallel_handle_compare . . . . . . . . . . . . . . . . 616
5.5.7 Task Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
5.5.7.1 ompd_get_curr_task_handle . . . . . . . . . . . . . . . . . . . 617
5.5.7.2 ompd_get_generating_task_handle . . . . . . . . . . . . . . 618
5.5.7.3 ompd_get_scheduling_task_handle . . . . . . . . . . . . . . 619
5.5.7.4 ompd_get_task_in_parallel . . . . . . . . . . . . . . . . . . . 620
5.5.7.5 ompd_rel_task_handle . . . . . . . . . . . . . . . . . . . . . . . 621
5.5.7.6 ompd_task_handle_compare . . . . . . . . . . . . . . . . . . . 622
5.5.7.7 ompd_get_task_function . . . . . . . . . . . . . . . . . . . . . 622
5.5.7.8 ompd_get_task_frame . . . . . . . . . . . . . . . . . . . . . . . 623
5.5.7.9 ompd_enumerate_states . . . . . . . . . . . . . . . . . . . . . . 624
5.5.7.10 ompd_get_state . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Contents xv
5.5.8 Display Control Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
5.5.8.1 ompd_get_display_control_vars . . . . . . . . . . . . . . . 626
5.5.8.2 ompd_rel_display_control_vars . . . . . . . . . . . . . . . 627
5.5.9 Accessing Scope-Specific Information . . . . . . . . . . . . . . . . . . . . 628
5.5.9.1 ompd_enumerate_icvs . . . . . . . . . . . . . . . . . . . . . . . 628
5.5.9.2 ompd_get_icv_from_scope . . . . . . . . . . . . . . . . . . . . 629
5.5.9.3 ompd_get_icv_string_from_scope . . . . . . . . . . . . . . . 630
5.5.9.4 ompd_get_tool_data . . . . . . . . . . . . . . . . . . . . . . . . 631
5.6 Runtime Entry Points for OMPD . . . . . . . . . . . . . . . . . . . . . . . . . . 632
5.6.1 Beginning Parallel Regions . . . . . . . . . . . . . . . . . . . . . . . . . . 633
5.6.2 Ending Parallel Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
5.6.3 Beginning Task Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
5.6.4 Ending Task Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
5.6.5 Beginning OpenMP Threads . . . . . . . . . . . . . . . . . . . . . . . . . . 635
5.6.6 Ending OpenMP Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
5.6.7 Initializing OpenMP Devices . . . . . . . . . . . . . . . . . . . . . . . . . 636
5.6.8 Finalizing OpenMP Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 636
6 Environment Variables 639

6.1 OMP_SCHEDULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
6.2 OMP_NUM_THREADS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
6.3 OMP_DYNAMIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
6.4 OMP_PROC_BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
6.5 OMP_PLACES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
6.6 OMP_STACKSIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
6.7 OMP_WAIT_POLICY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
6.8 OMP_MAX_ACTIVE_LEVELS . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
6.9 OMP_NESTED (Deprecated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
6.10 OMP_THREAD_LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
6.11 OMP_CANCELLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
6.12 OMP_DISPLAY_ENV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
6.13 OMP_DISPLAY_AFFINITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
6.14 OMP_AFFINITY_FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
6.15 OMP_DEFAULT_DEVICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
xvi OpenMP API – Version 5.1 November 2020

6.16 OMP_MAX_TASK_PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
6.17 OMP_TARGET_OFFLOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
6.18 OMP_TOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
6.19 OMP_TOOL_LIBRARIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
6.20 OMP_TOOL_VERBOSE_INIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
6.21 OMP_DEBUG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
6.22 OMP_ALLOCATOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
6.23 OMP_NUM_TEAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
6.24 OMP_TEAMS_THREAD_LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . 657
A OpenMP Implementation-Defined Behaviors 659
B Features History 667

B.1 Deprecated Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
B.2 Version 5.0 to 5.1 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Index 681
Contents xvii
List of Figures
2.1 Determining the schedule for a Worksharing-Loop . . . . . . . . . . . . . . . . 134
4.1 First-Party Tool Activation Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . 473
xviii
List of Tables
2.1 ICV Initial Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.2 Ways to Modify and to Retrieve ICV Values . . . . . . . . . . . . . . . . . . . . . 77
2.3 Scopes of ICVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.4 ICV Override Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.5 schedule Clause kind Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.6 schedule Clause modifier Values . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.7 ompt_callback_task_create Callback Flags Evaluation . . . . . . . . . . 165
2.8 Predefined Memory Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
2.9 Allocator Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
2.10 Predefined Allocators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
2.11 Implicitly Declared C/C++ reduction-identifiers . . . . . . . . . . . . . . . . . . . 326
2.12 Implicitly Declared Fortran reduction-identifiers . . . . . . . . . . . . . . . . . . . 327
2.13 Map-Type Decay of Map Type Combinations . . . . . . . . . . . . . . . . . . . . 360
3.1 Required Values of the omp_interop_property_t enum Type . . . . . . . . 445

3.2 Required Values for the omp_interop_rc_t enum Type . . . . . . . . . . . . 446
3.3 Standard Tool Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 466
4.1 OMPT Callback Interface Runtime Entry Point Names and Their Type Signatures . 477
4.2 Callbacks for which ompt_set_callback Must Return ompt_set_always 479
4.3 Callbacks for which ompt_set_callback May Return Any Non-Error Code . . 480
4.4 OMPT Tracing Interface Runtime Entry Point Names and Their Type Signatures . . 482
5.1 Mapping of Scope Type and OMPD Handles . . . . . . . . . . . . . . . . . . . . 584
6.1 Predefined Abstract Names for OMP_PLACES . . . . . . . . . . . . . . . . . . . . 644

6.2 Available Field Types for Formatting OpenMP Thread Affinity Information . . . . 651
xix
This page intentionally left blank
1 1 Overview of the OpenMP API
2 The collection of compiler directives, library routines, and environment variables that this
3 document describes collectively define the specification of the OpenMP Application Program
4 Interface (OpenMP API) for parallelism in C, C++ and Fortran programs.
5 This specification provides a model for parallel programming that is portable across architectures
6 from different vendors. Compilers from numerous vendors support the OpenMP API. More
7 information about the OpenMP API can be found at the following web site
8 http://www.openmp.org
9 The directives, library routines, environment variables, and tool support that this document defines
10 allow users to create, to manage, to debug and to analyze parallel programs while permitting
11 portability. The directives extend the C, C++ and Fortran base languages with single program
12 multiple data (SPMD) constructs, tasking constructs, device constructs, worksharing constructs,
13 and synchronization constructs, and they provide support for sharing, mapping and privatizing data.
14 The functionality to control the runtime environment is provided by library routines and
15 environment variables. Compilers that support the OpenMP API often include command line
16 options to enable or to disable interpretation of some or all OpenMP directives.
17 1.1 Scope
18 The OpenMP API covers only user-directed parallelization, wherein the programmer explicitly
19 specifies the actions to be taken by the compiler and runtime system in order to execute the program
20 in parallel. OpenMP-compliant implementations are not required to check for data dependences,
21 data conflicts, race conditions, or deadlocks. Compliant implementations also are not required to
22 check for any code sequences that cause a program to be classified as non-conforming. Application
23 developers are responsible for correctly using the OpenMP API to produce a conforming program.
24 The OpenMP API does not cover compiler-generated automatic parallelization.
1
1 1.2 Glossary
2 1.2.1 Threading Concepts
3 thread An execution entity with a stack and associated threadprivate memory.

4 OpenMP thread A thread that is managed by the OpenMP implementation.
5 thread number A number that the OpenMP implementation assigns to an OpenMP thread. For
6 threads within the same team, zero identifies the primary thread and consecutive
7 numbers identify the other threads of this team.
8 idle thread An OpenMP thread that is not currently part of any parallel region.
9 thread-safe routine A routine that performs the intended function even when executed concurrently (by
10 more than one thread).
11 processor Implementation-defined hardware unit on which one or more OpenMP threads can
12 execute.
13 device An implementation-defined logical execution engine.
14 COMMENT: A device could have one or more processors.
15 host device The device on which the OpenMP program begins execution.
16 target device A device with respect to which the current device performs an operation, as specified
17 by a device construct or an OpenMP device memory routine.
18 parent device For a given target region, the device on which the corresponding target
19 construct was encountered.
20 1.2.2 OpenMP Language Terminology
21 base language A programming language that serves as the foundation of the OpenMP specification.
22 COMMENT: See Section 1.7 for a listing of current base languages for
23 the OpenMP API.
24 base program A program written in a base language.
25 preprocessed code For C/C++, a sequence of preprocessing tokens that result from the first six phases of
26 translation, as defined by the base language.
27 program order An ordering of operations performed by the same thread as determined by the
28 execution sequence of operations specified by the base language.
2 OpenMP API – Version 5.1 November 2020

1 COMMENT: For versions of C and C++ that include base language
2 support for threading, program order corresponds to the sequenced before
3 relation between operations performed by the same thread.
4 structured block For C/C++, an executable statement, possibly compound, with a single entry at the
5 top and a single exit at the bottom, or an OpenMP construct.
6 For Fortran, a strictly structured block, or a loosely structured block.
7 structured block A structured block, or, for C/C++, a sequence of two or more executable statements
8 sequence that together have a single entry at the top and a single exit at the bottom.
9 strictly structured A single Fortran BLOCK construct, with a single entry at the top and a single exit at
10 block the bottom.
11 loosely structured A block of executable constructs, where the first executable construct is not a Fortran
12 block BLOCK construct, with a single entry at the top and a single exit at the bottom, or an
13 OpenMP construct.
14 COMMENT: In Fortran code, when a strictly structured block appears
15 within an OpenMP construct, that OpenMP construct does not usually
16 require a paired end directive to define the range of the OpenMP
17 construct, while an OpenMP construct that contains a loosely structured
18 block relies on the paired end directive to define the range of the
19 OpenMP construct.
20 compilation unit For C/C++, a translation unit.
21 For Fortran, a program unit.
22 enclosing context For C/C++, the innermost scope enclosing an OpenMP directive.
23 For Fortran, the innermost scoping unit enclosing an OpenMP directive.
24 directive A base language mechanism to specify OpenMP program behavior.
25 COMMENT: See Section 2.1 for a description of OpenMP directive
26 syntax in each base language.
27 white space A non-empty sequence of space and/or horizontal tab characters.
28 OpenMP program A program that consists of a base program that is annotated with OpenMP directives
29 or that calls OpenMP API runtime library routines.
30 conforming program An OpenMP program that follows all rules and restrictions of the OpenMP
31 specification.
32 implementation code Implicit code that is introduced by the OpenMP implementation.
33 metadirective A directive that conditionally resolves to another directive.
CHAPTER 1. OVERVIEW OF THE OPENMP API 3

1 declarative directive An OpenMP directive that may only be placed in a declarative context and results in
2 one or more declarations only; it is not associated with the immediate execution of
3 any user code or implementation code. For C++, if a declarative directive applies to a
4 function declaration or definition and it is specified with one or more C++ attribute
5 specifiers, the specified attributes must be applied to the function as permitted by the
6 base language. For Fortran, a declarative directive must appear after any USE,
7 IMPORT, and IMPLICIT statements in a declarative context.
8 executable directive An OpenMP directive that appears in an executable context and results in
9 implementation code and/or prescribes the manner in which associated user code
10 must execute.
11 informational directive An OpenMP directive that is neither declarative nor executable, but otherwise
12 conveys user code properties to the compiler.
13 utility directive An OpenMP directive that is neither declarative nor executable, but otherwise
14 facilitates interactions with the compiler and/or supports code readability.
15 stand-alone directive An OpenMP executable directive that has no associated user code, but may produce
16 implementation code resulting from clauses in the directive.
17 construct An OpenMP executable directive (and for Fortran, the paired end directive, if any)
18 and the associated statement, loop nest or structured block, if any, not including the
19 code in any called routines. That is, the lexical extent of an executable directive.
20 combined construct A construct that is a shortcut for specifying one construct immediately nested inside
21 another construct. A combined construct is semantically identical to that of explicitly
22 specifying the first construct containing one instance of the second construct and no
23 other statements.
24 composite construct A construct that is composed of two constructs but does not have identical semantics
25 to specifying one of the constructs immediately nested inside the other. A composite
26 construct either adds semantics not included in the constructs from which it is
27 composed or provides an effective nesting of the one construct inside the other that
28 would otherwise be non-conforming.
29 constituent construct For a given combined or composite construct, a construct from which it, or any one
30 of its constituent constructs, is composed.
31 COMMENT: The constituent constructs of a
32 target teams distribute parallel for simd construct are the
33 following constructs: target,
34 teams distribute parallel for simd, teams,
35 distribute parallel for simd, distribute,
36 parallel for simd, parallel, for simd, for, and simd.

1 leaf construct For a given combined or composite construct, a constituent construct that is not itself
2 a combined or composite construct.
3 COMMENT: The leaf constructs of a
4 target teams distribute parallel for simd construct are the
5 following constructs: target, teams, distribute, parallel,
6 for, and simd.
7 combined target A combined construct that is composed of a target construct along with another
8 construct construct.
9 region All code encountered during a specific instance of the execution of a given construct,
10 structured block sequence or OpenMP library routine. A region includes any code in
11 called routines as well as any implementation code. The generation of a task at the
12 point where a task generating construct is encountered is a part of the region of the
13 encountering thread. However, an explicit task region that corresponds to a task
14 generating construct is not part of the region of the encountering thread unless it is
15 an included task region. The point where a target or teams directive is
16 encountered is a part of the region of the encountering thread, but the region that
17 corresponds to the target or teams directive is not.
18 COMMENTS:
19 A region may also be thought of as the dynamic or runtime extent of a
20 construct or of an OpenMP library routine.
21 During the execution of an OpenMP program, a construct may give rise to
22 many regions.
23 active parallel region A parallel region that is executed by a team consisting of more than one thread.
24 inactive parallel region A parallel region that is executed by a team of only one thread.
25 active target region A target region that is executed on a device other than the device that encountered
26 the target construct.
27 inactive target region A target region that is executed on the same device that encountered the target
28 construct.
29 sequential part All code encountered during the execution of an initial task region that is not part of
30 a parallel region corresponding to a parallel construct or a task region
31 corresponding to a task construct.
32 COMMENTS:
33 A sequential part is enclosed by an implicit parallel region.

1 Executable statements in called routines may be in both a sequential part
2 and any number of explicit parallel regions at different points in the
3 program execution.
4 primary thread An OpenMP thread that has thread number 0. A primary thread may be an initial
5 thread or the thread that encounters a parallel construct, creates a team,
6 generates a set of implicit tasks, and then executes one of those tasks as thread
7 number 0.
8 parent thread The thread that encountered the parallel construct and generated a parallel
9 region is the parent thread of each of the threads in the team of that parallel
10 region. The primary thread of a parallel region is the same thread as its parent
11 thread with respect to any resources associated with an OpenMP thread.
12 child thread When a thread encounters a parallel construct, each of the threads in the
13 generated parallel region’s team are child threads of the encountering thread.
14 The target or teams region’s initial thread is not a child thread of the thread that
15 encountered the target or teams construct.
16 ancestor thread For a given thread, its parent thread or one of its parent thread’s ancestor threads.
17 descendent thread For a given thread, one of its child threads or one of its child threads’ descendent
18 threads.
19 team A set of one or more threads participating in the execution of a parallel region.
20 COMMENTS:
21 For an active parallel region, the team comprises the primary thread and
22 at least one additional thread.
23 For an inactive parallel region, the team comprises only the primary
24 thread.
25 league The set of teams created by a teams construct.
26 contention group An initial thread and its descendent threads.
27 implicit parallel region An inactive parallel region that is not generated from a parallel construct.
28 Implicit parallel regions surround the whole OpenMP program, all target regions,
29 and all teams regions.
30 initial thread The thread that executes an implicit parallel region.
31 initial team The team that comprises an initial thread executing an implicit parallel region.
32 nested construct A construct (lexically) enclosed by another construct.
33 closely nested construct A construct nested inside another construct with no other construct nested between
34 them.

1 explicit region A region that corresponds to either a construct of the same name or a library routine
2 call that explicitly appears in the program.
3 nested region A region (dynamically) enclosed by another region. That is, a region generated from
4 the execution of another region or one of its nested regions.
5 COMMENT: Some nestings are conforming and some are not. See
6 Section 2.22 for the restrictions on nesting.
7 closely nested region A region nested inside another region with no parallel region nested between
8 them.
9 strictly nested region A region nested inside another region with no other explicit region nested between
10 them.
11 all threads All OpenMP threads participating in the OpenMP program.
12 current team All threads in the team executing the innermost enclosing parallel region.
13 encountering thread For a given region, the thread that encounters the corresponding construct.
14 all tasks All tasks participating in the OpenMP program.
15 current team tasks All tasks encountered by the corresponding team. The implicit tasks constituting the
16 parallel region and any descendent tasks encountered during the execution of
17 these implicit tasks are included in this set of tasks.
18 generating task For a given region, the task for which execution by a thread generated the region.
19 binding thread set The set of threads that are affected by, or provide the context for, the execution of a
20 region.
21 The binding thread set for a given region can be all threads on a specified set of
22 devices, all threads in a contention group, all primary threads executing an enclosing
23 teams region, the current team, or the encountering thread.
24 COMMENT: The binding thread set for a particular region is described in
25 its corresponding subsection of this specification.
26 binding task set The set of tasks that are affected by, or provide the context for, the execution of a
27 region.
28 The binding task set for a given region can be all tasks, the current team tasks, all
29 tasks of the current team that are generated in the region, the binding implicit task, or
30 the generating task.
31 COMMENT: The binding task set for a particular region (if applicable) is
32 described in its corresponding subsection of this specification.

1 binding region The enclosing region that determines the execution context and limits the scope of
2 the effects of the bound region is called the binding region.
3 Binding region is not defined for regions for which the binding thread set is all
4 threads or the encountering thread, nor is it defined for regions for which the binding
5 task set is all tasks.
6 orphaned construct A construct that gives rise to a region for which the binding thread set is the current
7 team, but is not nested within another construct that gives rise to the binding region.
8 worksharing construct A construct that divides the work within its structured block into partitions, each of
9 which is executed exactly once by one of the threads in the team executing the
10 construct.
11 device construct An OpenMP construct that accepts the device clause.
12 device routine A function (for C/C++ and Fortran) or subroutine (for Fortran) that can be executed
13 on a target device, as part of a target region.
14 foreign runtime A runtime environment that exists outside the OpenMP runtime with which the
15 environment OpenMP implementation may interoperate.
16 foreign execution A context that is instantiated from a foreign runtime environment in order to facilitate
17 context execution on a given device.
18 foreign task A unit of work executed in a foreign execution context.
19 indirect device An indirect call to the device version of a procedure on a device other than the host
20 invocation device, through a function pointer (C/C++), a pointer to a member function (C++) or
21 a procedure pointer (Fortran) that refers to the host version of the procedure.
22 place An unordered set of processors on a device.
23 place list The ordered list that describes all OpenMP places available to the execution
24 environment.
25 place partition An ordered list that corresponds to a contiguous interval in the OpenMP place list. It
26 describes the places currently available to the execution environment for a given
27 parallel region.
28 place number A number that uniquely identifies a place in the place list, with zero identifying the
29 first place in the place list, and each consecutive whole number identifying the next
30 place in the place list.
31 thread affinity A binding of threads to places within the current place partition.
32 SIMD instruction A single machine instruction that can operate on multiple data elements.
33 SIMD lane A software or hardware mechanism capable of processing one data element from a
34 SIMD instruction.

1 SIMD chunk A set of iterations executed concurrently, each by a SIMD lane, by a single thread by
2 means of SIMD instructions.
3 memory A storage resource to store and to retrieve variables accessible by OpenMP threads.
4 memory space A representation of storage resources from which memory can be allocated or
5 deallocated. More than one memory space may exist.
6 memory allocator An OpenMP object that fulfills requests to allocate and to deallocate memory for
7 program variables from the storage resources of its associated memory space.
8 handle An opaque reference that uniquely identifies an abstraction.
9 1.2.3 Loop Terminology
10 canonical loop nest A loop nest that complies with the rules and restrictions defined in Section 2.11.1.
11 loop-associated An OpenMP executable directive for which the associated user code must be a
12 directive canonical loop nest.
13 associated loop A loop from a canonical loop nest that is controlled by a given loop-associated
14 directive.
15 loop nest depth For a canonical loop nest, the maximal number of loops, including the outermost
16 loop, that can be associated with a loop-associated directive.
17 logical iteration space For a loop-associated directive, the sequence 0,. . . ,N − 1 where N is the number of
18 iterations of the loops associated with the directive. The logical numbering denotes
19 the sequence in which the iterations would be executed if the set of associated loops
20 were executed sequentially.
21 logical iteration An iteration from the associated loops of a loop-associated directive, designated by a
22 logical number from the logical iteration space of the associated loops.
23 logical iteration vector For a loop-associated directive with n associated nested loops, the set of n-tuples
24 space (i1 , . . . , in ). For the k th associated loop, from outermost to innermost, ik is its
25 logical iteration number as if it was the only associated loop.
26 logical iteration vector An iteration from the associated nested loops of a loop-associated directive, where n
27 is the number of associated loops, designated by an n-tuple from the logical iteration
28 vector space of the associated loops.
29 lexicographic order The total order of two logical iteration vectors ωa = (i1 , . . . , in ) and
30 ωb = (j1 , . . . , jn ), denoted by ωa ≤lex ωb , where either ωa = ωb or
31 ∃m ∈ {1, . . . , n} such that im < jm and ik = jk for all k ∈ {1, . . . , m − 1}.

1 product order The partial order of two logical iteration vectors ωa = (i1 , . . . , in ) and
2 ωb = (j1 , . . . , jn ), denoted by ωa ≤product ωb , where ik ≤ jk for all k ∈ {1, . . . , n}.
3 loop transformation A construct that is replaced by the loops that result from applying the transformation
4 construct as defined by its directive to its associated loops.
5 generated loop A loop that is generated by a loop transformation construct and is one of the
6 resulting loops that replace the construct.
7 SIMD loop A loop that includes at least one SIMD chunk.
8 non-rectangular loop For a loop nest, a loop for which a loop bound references the iteration variable of a
9 surrounding loop in the loop nest.
10 perfectly nested loop A loop that has no intervening code between it and the body of its surrounding loop.
11 The outermost loop of a loop nest is always perfectly nested.
12 doacross loop nest A loop nest, consisting of loops that may be associated with the same
13 loop-associated directive, that has cross-iteration dependences. An iteration is
14 dependent on one or more lexicographically earlier iterations.
15 COMMENT: The ordered clause parameter on a worksharing-loop
16 directive identifies the loops associated with the doacross loop nest.
17 1.2.4 Synchronization Terminology
18 barrier A point in the execution of a program encountered by a team of threads, beyond

19 which no thread in the team may execute until all threads in the team have reached
20 the barrier and all explicit tasks generated by the team have executed to completion.
21 If cancellation has been requested, threads may proceed to the end of the canceled
22 region even if some threads in the team have not reached the barrier.
23 cancellation An action that cancels (that is, aborts) an OpenMP region and causes executing
24 implicit or explicit tasks to proceed to the end of the canceled region.
25 cancellation point A point at which implicit and explicit tasks check if cancellation has been requested.
26 If cancellation has been observed, they perform the cancellation.
27 flush An operation that a thread performs to enforce consistency between its view and
28 other threads’ view of memory.
29 device-set The set of devices for which a flush operation may enforce memory consistency.
30 flush property Properties that determine the manner in which a flush operation enforces memory
31 consistency. These properties are:

1 • strong: flushes a set of variables from the current thread’s temporary view of the
2 memory to the memory;
3 • release: orders memory operations that precede the flush before memory
4 operations performed by a different thread with which it synchronizes;
5 • acquire: orders memory operations that follow the flush after memory operations
6 performed by a different thread that synchronizes with it.
7 COMMENT: Any flush operation has one or more flush properties.
8 strong flush A flush operation that has the strong flush property.
9 release flush A flush operation that has the release flush property.
10 acquire flush A flush operation that has the acquire flush property.
11 atomic operation An operation that is specified by an atomic construct or is implicitly performed by
12 the OpenMP implementation and that atomically accesses and/or modifies a specific
13 storage location.
14 atomic read An atomic operation that is specified by an atomic construct on which the read
15 clause is present.
16 atomic write An atomic operation that is specified by an atomic construct on which the write
17 clause is present.
18 atomic update An atomic operation that is specified by an atomic construct on which the
19 update clause is present.
20 atomic captured An atomic update operation that is specified by an atomic construct on which the
21 update capture clause is present.
22 atomic conditional An atomic update operation that is specified by an atomic construct on which the
23 update compare clause is present.
24 read-modify-write An atomic operation that reads and writes to a given storage location.
25 COMMENT: Any atomic update is a read-modify-write operation.
26 sequentially consistent An atomic construct for which the seq_cst clause is specified.
atomic construct
27 non-sequentially An atomic construct for which the seq_cst clause is not specified
consistent atomic
construct
28 sequentially consistent An atomic operation that is specified by a sequentially consistent atomic construct.
atomic operation

1 1.2.5 Tasking Terminology
2 task A specific instance of executable code and its data environment that the OpenMP
3 implementation can schedule for execution by threads.
4 task region A region consisting of all code encountered during the execution of a task.
5 COMMENT: A parallel region consists of one or more implicit task
6 regions.
7 implicit task A task generated by an implicit parallel region or generated when a parallel
8 construct is encountered during execution.
9 binding implicit task The implicit task of the current thread team assigned to the encountering thread.
10 explicit task A task that is not an implicit task.
11 initial task An implicit task associated with an implicit parallel region.
12 current task For a given thread, the task corresponding to the task region in which it is executing.
13 encountering task For a given region, the current task of the encountering thread.
14 child task A task is a child task of its generating task region. A child task region is not part of
15 its generating task region.
16 sibling tasks Tasks that are child tasks of the same task region.
17 descendent task A task that is the child task of a task region or of one of its descendent task regions.
18 task completion A condition that is satisfied when a thread reaches the end of the executable code that
19 is associated with the task and any allow-completion event that is created for the task
20 has been fulfilled.
21 COMMENT: Completion of the initial task that is generated when the
22 program begins occurs at program exit.
23 task scheduling point A point during the execution of the current task region at which it can be suspended
24 to be resumed later; or the point of task completion, after which the executing thread
25 may switch to a different task region.
26 task switching The act of a thread switching from the execution of one task to another task.
27 tied task A task that, when its task region is suspended, can be resumed only by the same
28 thread that was executing it before suspension. That is, the task is tied to that thread.
29 untied task A task that, when its task region is suspended, can be resumed by any thread in the
30 team. That is, the task is not tied to any thread.

1 undeferred task A task for which execution is not deferred with respect to its generating task region.
2 That is, its generating task region is suspended until execution of the structured block
3 associated with the undeferred task is completed.
4 included task A task for which execution is sequentially included in the generating task region.
5 That is, an included task is undeferred and executed by the encountering thread.
6 merged task A task for which the data environment, inclusive of ICVs, is the same as that of its
7 generating task region.
8 mergeable task A task that may be a merged task if it is an undeferred task or an included task.
9 final task A task that forces all of its child tasks to become final and included tasks.
10 task dependence An ordering relation between two sibling tasks: the dependent task and a previously
11 generated predecessor task. The task dependence is fulfilled when the predecessor
12 task has completed.
13 dependent task A task that because of a task dependence cannot be executed until its predecessor
14 tasks have completed.
15 mutually exclusive Tasks that may be executed in any order, but not at the same time.
tasks
16 predecessor task A task that must complete before its dependent tasks can be executed.
17 task synchronization A taskwait, taskgroup, or a barrier construct.
construct
18 task generating A construct that generates one or more explicit tasks that are child tasks of the
19 construct encountering task.
20 target task A mergeable and untied task that is generated by a device construct or a call to a
21 device memory routine and that coordinates activity between the current device and
22 the target device.
23 taskgroup set A set of tasks that are logically grouped by a taskgroup region.

1 1.2.6 Data Terminology
2 variable A named data storage block, for which the value can be defined and redefined during
3 the execution of a program.
4 COMMENT: An array element or structure element is a variable that is
5 part of another variable.
6 scalar variable For C/C++, a scalar variable, as defined by the base language.
7 For Fortran, a scalar variable with intrinsic type, as defined by the base language,
8 excluding character type.
9 aggregate variable A variable, such as an array or structure, composed of other variables.
10 array section A designated subset of the elements of an array that is specified using a subscript
11 notation that can select more than one element.
12 array item An array, an array section, or an array element.
13 shape-operator For C/C++, an array shaping operator that reinterprets a pointer expression as an
14 array with one or more specified dimensions.
15 implicit array For C/C++, the set of array elements of non-array type T that may be accessed by
16 applying a sequence of [] operators to a given pointer that is either a pointer to type T
17 or a pointer to a multidimensional array of elements of type T.
18 For Fortran, the set of array elements for a given array pointer.
19 COMMENT: For C/C++, the implicit array for pointer p with type T
20 (*)[10] consists of all accessible elements p[i][j], for all i and j=0,1,...,9.
21 base pointer For C/C++, an lvalue pointer expression that is used by a given lvalue expression or
22 array section to refer indirectly to its storage, where the lvalue expression or array
23 section is part of the implicit array for that lvalue pointer expression.
24 For Fortran, a data pointer that appears last in the designator for a given variable or
25 array section, where the variable or array section is part of the pointer target for that
26 data pointer.
27 COMMENT: For the array section
28 (*p0).x0[k1].p1->p2[k2].x1[k3].x2[4][0:n], where identifiers pi have a
29 pointer type declaration and identifiers xi have an array type declaration,
30 the base pointer is: (*p0).x0[k1].p1->p2.
31 named pointer For C/C++, the base pointer of a given lvalue expression or array section, or the base
32 pointer of one of its named pointers.
33 For Fortran, the base pointer of a given variable or array section, or the base pointer
34 of one of its named pointers.

4 the named pointers are: p0, (*p0).x0[k1].p1, and (*p0).x0[k1].p1->p2.
5 containing array For C/C++, a non-subscripted array (a containing array) that appears in a given
6 lvalue expression or array section, where the lvalue expression or array section is part
7 of that containing array.
8 For Fortran, an array (a containing array) without the POINTER attribute and
9 without a subscript list that appears in the designator of a given variable or array
10 section, where the variable or array section is part of that containing array.
14 the containing arrays are: (*p0).x0[k1].p1->p2[k2].x1 and
15 (*p0).x0[k1].p1->p2[k2].x1[k3].x2.
16 base array For C/C++, a containing array of a given lvalue expression or array section that does
17 not appear in the expression of any of its other containing arrays.
18 For Fortran, a containing array of a given variable or array section that does not
19 appear in the designator of any of its other containing arrays.
23 the base array is: (*p0).x0[k1].p1->p2[k2].x1[k3].x2.
24 named array For C/C++, a containing array of a given lvalue expression or array section, or a
25 containing array of one of its named pointers.
26 For Fortran, a containing array of a given variable or array section, or a containing
27 array of one of its named pointers.
31 the named arrays are: (*p0).x0, (*p0).x0[k1].p1->p2[k2].x1, and
32 (*p0).x0[k1].p1->p2[k2].x1[k3].x2.
33 base expression The base array of a given array section or array element, if it exists; otherwise, the
34 base pointer of the array section or array element.
38 the base expression is: (*p0).x0[k1].p1->p2[k2].x1[k3].x2.

1 More examples for C/C++:
2 • The base expression for x[i] and for x[i:n] is x, if x is an array or pointer.
3 • The base expression for x[5][i] and for x[5][i:n] is x, if x is a pointer to
4 an array or x is 2-dimensional array.
5 • The base expression for y[5][i] and for y[5][i:n] is y[5], if y is an array
6 of pointers or y is a pointer to a pointer.
7 Examples for Fortran:
8 • The base expression for x(i) and for x(i:j) is x.
9 attached pointer A pointer variable in a device data environment to which the effect of a map clause
10 assigns the address of an object, minus some offset, that is created in the device data
11 environment. The pointer is an attached pointer for the remainder of its lifetime in
12 the device data environment.
13 simply contiguous An array section that statically can be determined to have contiguous storage or that,
14 array section in Fortran, has the CONTIGUOUS attribute.
15 structure A structure is a variable that contains one or more variables.

16 For C/C++: Implemented using struct types.
17 For C++: Implemented using class types.
18 For Fortran: Implemented using derived types.
19 string literal For C/C++, a string literal.
20 For Fortran, a character literal constant.
21 private variable With respect to a given set of task regions or SIMD lanes that bind to the same
22 parallel region, a variable for which the name provides access to a different
23 block of storage for each task region or SIMD lane.
24 A variable that is part of another variable (as an array or structure element) cannot be
25 made private independently of other components. If a variable is privatized, its
26 components are also private.
27 shared variable With respect to a given set of task regions that bind to the same parallel region, a
28 variable for which the name provides access to the same block of storage for each
29 task region.
31 shared independently of the other components, except for static data members of
32 C++ classes.

1 threadprivate variable A variable that is replicated, one instance per thread, by the OpenMP
2 implementation. Its name then provides access to a different block of storage for each
3 thread.
5 made threadprivate independently of the other components, except for static data
6 members of C++ classes. If a variable is made threadprivate, its components are also
7 threadprivate.
8 threadprivate memory The set of threadprivate variables associated with each thread.
9 data environment The variables associated with the execution of a given region.
10 device data The initial data environment associated with a device.
environment
11 device address An address of an object that may be referenced on a target device.
12 device pointer An implementation defined handle that refers to a device address.
13 mapped variable An original variable in a data environment with a corresponding variable in a device
14 data environment.
15 COMMENT: The original and corresponding variables may share storage.
16 mapper An operation that defines how variables of given type are to be mapped or updated
17 with respect to a device data environment.
18 user-defined mapper A mapper that is defined by a declare mapper directive.
19 map-type decay The process that determines the final map types of the map operations that result
20 from mapping a variable with a user-defined mapper.
21 mappable type A type that is valid for a mapped variable. If a type is composed from other types
22 (such as the type of an array or structure element) and any of the other types are not
23 mappable then the type is not mappable.
24 COMMENT: Pointer types are mappable but the memory block to which
25 the pointer refers is not mapped.
26 For C, the type must be a complete type.
27 For C++, the type must be a complete type.
28 In addition, for class types:
29 • All member functions accessed in any target region must appear in a declare
30 target directive.
31 For Fortran, no restrictions on the type except that for derived types:

1 • All type-bound procedures accessed in any target region must appear in a
2 declare target directive.
3 defined For variables, the property of having a valid value.
4 For C, for the contents of variables, the property of having a valid value.
5 For C++, for the contents of variables of POD (plain old data) type, the property of
6 having a valid value.
7 For variables of non-POD class type, the property of having been constructed but not
8 subsequently destructed.
9 For Fortran, for the contents of variables, the property of having a valid value. For
10 the allocation or association status of variables, the property of having a valid status.
11 COMMENT: Programs that rely upon variables that are not defined are
12 non-conforming programs.
13 class type For C++, variables declared with one of the class, struct, or union keywords.
14 static storage duration For C/C++, the lifetime of an object with static storage duration, as defined by the
15 base language.
16 For Fortran, the lifetime of a variable with a SAVE attribute, implicit or explicit, a
17 common block object or a variable declared in a module.
18 1.2.7 Implementation Terminology
19 supported active levels An implementation-defined maximum number of active parallel regions that may
20 of parallelism enclose any region of code in the program.
21 OpenMP API support Support of at least one active level of parallelism.
22 nested parallelism Support of more than one active level of parallelism.

support
23 internal control A conceptual variable that specifies runtime behavior of a set of threads or tasks in
24 variable an OpenMP program.
25 COMMENT: The acronym ICV is used interchangeably with the term
26 internal control variable in the remainder of this specification.
27 OpenMP Additional A document that exists outside of the OpenMP specification and defines additional
28 Definitions document values that may be used in a conforming program. The OpenMP Additional
29 Definitions document is available at http://www.openmp.org/.

1 compliant An implementation of the OpenMP specification that compiles and executes any
2 implementation conforming program as defined by the specification.
3 COMMENT: A compliant implementation may exhibit unspecified
4 behavior when compiling or executing a non-conforming program.
5 unspecified behavior A behavior or result that is not specified by the OpenMP specification or not known
6 prior to the compilation or execution of an OpenMP program.
7 Such unspecified behavior may result from:
8 • Issues documented by the OpenMP specification as having unspecified behavior.
9 • A non-conforming program.
10 • A conforming program exhibiting an implementation-defined behavior.
11 implementation defined Behavior that must be documented by the implementation, and is allowed to vary
12 among different compliant implementations. An implementation is allowed to define
13 this behavior as unspecified.
14 COMMENT: All features that have implementation-defined behavior are
15 documented in Appendix A.
16 deprecated For a construct, clause, or other feature, the property that it is normative in the
17 current specification but is considered obsolescent and will be removed in the future.
18 1.2.8 Tool Terminology
19 tool Code that can observe and/or modify the execution of an application.
20 first-party tool A tool that executes in the address space of the program that it is monitoring.
21 third-party tool A tool that executes as a separate process from the process that it is monitoring and
22 potentially controlling.
23 activated tool A first-party tool that successfully completed its initialization.
24 event A point of interest in the execution of a thread.
25 native thread A thread defined by an underlying thread implementation.
26 tool callback A function that a tool provides to an OpenMP implementation to invoke when an
27 associated event occurs.
28 registering a callback Providing a tool callback to an OpenMP implementation.

1 dispatching a callback Processing a callback when an associated event occurs in a manner consistent with
2 at an event the return code provided when a first-party tool registered the callback.
3 thread state An enumeration type that describes the current OpenMP activity of a thread. A
4 thread can be in only one state at any time.
5 wait identifier A unique opaque handle associated with each data object (for example, a lock) that
6 the OpenMP runtime uses to enforce mutual exclusion and potentially to cause a
7 thread to wait actively or passively.
8 frame A storage area on a thread’s stack associated with a procedure invocation. A frame
9 includes space for one or more saved registers and often also includes space for saved
10 arguments, local variables, and padding for alignment.
11 canonical frame An address associated with a procedure frame on a call stack that was the value of the
12 address stack pointer immediately prior to calling the procedure for which the frame
13 represents the invocation.
14 runtime entry point A function interface provided by an OpenMP runtime for use by a tool. A runtime
15 entry point is typically not associated with a global function symbol.
16 trace record A data structure in which to store information associated with an occurrence of an
17 event.
18 native trace record A trace record for an OpenMP device that is in a device-specific format.
19 signal A software interrupt delivered to a thread.
20 signal handler A function called asynchronously when a signal is delivered to a thread.
21 async signal safe The guarantee that interruption by signal delivery will not interfere with a set of
22 operations. An async signal safe runtime entry point is safe to call from a signal
23 handler.
24 code block A contiguous region of memory that contains code of an OpenMP program to be
25 executed on a device.
26 OMPT An interface that helps a first-party tool monitor the execution of an OpenMP
27 program.
28 OMPT interface state A state that indicates the permitted interactions between a first-party tool and the
29 OpenMP implementation.
30 OMPT active An OMPT interface state in which the OpenMP implementation is prepared to accept
31 runtime calls from a first party tool and will dispatch any registered callbacks and in
32 which a first-party tool can invoke runtime entry points if not otherwise restricted.

1 OMPT pending An OMPT interface state in which the OpenMP implementation can only call
2 functions to initialize a first party tool and in which a first-party tool cannot invoke
3 runtime entry points.
4 OMPT inactive An OMPT interface state in which the OpenMP implementation will not make any
5 callbacks and in which a first-party tool cannot invoke runtime entry points.
6 OMPD An interface that helps a third-party tool inspect the OpenMP state of a program that
7 has begun execution.
8 OMPD library A dynamically loadable library that implements the OMPD interface.
9 image file An executable or shared library.
10 address space A collection of logical, virtual, or physical memory address ranges that contain code,
11 stack, and/or data. Address ranges within an address space need not be contiguous.
12 An address space consists of one or more segments.
13 segment A portion of an address space associated with a set of address ranges.
14 OpenMP architecture The architecture on which an OpenMP region executes.
15 tool architecture The architecture on which an OMPD tool executes.
16 OpenMP process A collection of one or more threads and address spaces. A process may contain
17 threads and address spaces for multiple OpenMP architectures. At least one thread
18 in an OpenMP process is an OpenMP thread. A process may be live or a core file.
19 address space handle A handle that refers to an address space within an OpenMP process.
20 thread handle A handle that refers to an OpenMP thread.
21 parallel handle A handle that refers to an OpenMP parallel region.
22 task handle A handle that refers to an OpenMP task region.
23 descendent handle An output handle that is returned from the OMPD library in a function that accepts
24 an input handle: the output handle is a descendent of the input handle.
25 ancestor handle An input handle that is passed to the OMPD library in a function that returns an
26 output handle: the input handle is an ancestor of the output handle. For a given
27 handle, the ancestors of the handle are also the ancestors of the handle’s descendent.
28 COMMENT: A tool cannot use a handle in an OMPD call if any ancestor
29 of the handle has been released, except for OMPD calls that release it.

1 tool context An opaque reference provided by a tool to an OMPD library. A tool context uniquely
2 identifies an abstraction.
3 address space context A tool context that refers to an address space within a process.
4 thread context A tool context that refers to a native thread.
5 native thread identifier An identifier for a native thread defined by a thread implementation.
6 1.3 Execution Model

7 The OpenMP API uses the fork-join model of parallel execution. Multiple threads of execution
8 perform tasks defined implicitly or explicitly by OpenMP directives. The OpenMP API is intended
9 to support programs that will execute correctly both as parallel programs (multiple threads of
10 execution and a full OpenMP support library) and as sequential programs (directives ignored and a
11 simple OpenMP stubs library). However, a conforming OpenMP program may execute correctly as
12 a parallel program but not as a sequential program, or may produce different results when executed
13 as a parallel program compared to when it is executed as a sequential program. Further, using
14 different numbers of threads may result in different numeric results because of changes in the
15 association of numeric operations. For example, a serial addition reduction may have a different
16 pattern of addition associations than a parallel reduction. These different associations may change
17 the results of floating-point addition.
18 An OpenMP program begins as a single thread of execution, called an initial thread. An initial
19 thread executes sequentially, as if the code encountered is part of an implicit task region, called an
20 initial task region, that is generated by the implicit parallel region surrounding the whole program.
21 The thread that executes the implicit parallel region that surrounds the whole program executes on
22 the host device. An implementation may support other devices besides the host device. If
23 supported, these devices are available to the host device for offloading code and data. Each device
24 has its own threads that are distinct from threads that execute on another device. Threads cannot
25 migrate from one device to another device. Each device is identified by a device number. The
26 device number for the host device is the value of the total number of non-host devices, while each
27 non-host device has a unique device number that is greater than or equal to zero and less than the
28 device number for the host device.
29 When a target construct is encountered, a new target task is generated. The target task region
30 encloses the target region. The target task is complete after the execution of the target region
31 is complete.
32 When a target task executes, the enclosed target region is executed by an initial thread. The
33 initial thread executes sequentially, as if the target region is part of an initial task region that is
34 generated by an implicit parallel region. The initial thread may execute on the requested target

1 device, if it is available and supported. If the target device does not exist or the implementation
2 does not support it, all target regions associated with that device execute on the host device.
3 The implementation must ensure that the target region executes as if it were executed in the data
4 environment of the target device unless an if clause is present and the if clause expression
5 evaluates to false.
6 The teams construct creates a league of teams, where each team is an initial team that comprises
7 an initial thread that executes the teams region. Each initial thread executes sequentially, as if the
8 code encountered is part of an initial task region that is generated by an implicit parallel region
9 associated with each team. Whether the initial threads concurrently execute the teams region is
10 unspecified, and a program that relies on their concurrent execution for the purposes of
11 synchronization may deadlock.
12 If a construct creates a data environment, the data environment is created at the time the construct is
13 encountered. The description of a construct defines whether it creates a data environment.
14 When any thread encounters a parallel construct, the thread creates a team of itself and zero or
15 more additional threads and becomes the primary thread of the new team. A set of implicit tasks,
16 one per thread, is generated. The code for each task is defined by the code inside the parallel
17 construct. Each task is assigned to a different thread in the team and becomes tied; that is, it is
18 always executed by the thread to which it is initially assigned. The task region of the task being
19 executed by the encountering thread is suspended, and each member of the new team executes its
20 implicit task. An implicit barrier occurs at the end of the parallel region. Only the primary
21 thread resumes execution beyond the end of the parallel construct, resuming the task region
22 that was suspended upon encountering the parallel construct. Any number of parallel
23 constructs can be specified in a single program.
24 parallel regions may be arbitrarily nested inside each other. If nested parallelism is disabled, or
25 is not supported by the OpenMP implementation, then the new team that is created by a thread that
26 encounters a parallel construct inside a parallel region will consist only of the
27 encountering thread. However, if nested parallelism is supported and enabled, then the new team
28 can consist of more than one thread. A parallel construct may include a proc_bind clause to
29 specify the places to use for the threads in the team within the parallel region.
30 When any team encounters a worksharing construct, the work inside the construct is divided among
31 the members of the team, and executed cooperatively instead of being executed by every thread. An
32 implicit barrier occurs at the end of any region that corresponds to a worksharing construct for
33 which the nowait clause is not specified. Redundant execution of code by every thread in the
34 team resumes after the end of the worksharing construct.
35 When any thread encounters a task generating construct, one or more explicit tasks are generated.
36 Execution of explicitly generated tasks is assigned to one of the threads in the current team, subject
37 to the thread’s availability to execute work. Thus, execution of the new task could be immediate, or
38 deferred until later according to task scheduling constraints and thread availability. Threads are
39 allowed to suspend the current task region at a task scheduling point in order to execute a different
40 task. If the suspended task region is for a tied task, the initially assigned thread later resumes

1 execution of the suspended task region. If the suspended task region is for an untied task, then any
2 thread may resume its execution. Completion of all explicit tasks bound to a given parallel region is
3 guaranteed before the primary thread leaves the implicit barrier at the end of the region.
4 Completion of a subset of all explicit tasks bound to a given parallel region may be specified
5 through the use of task synchronization constructs. Completion of all explicit tasks bound to the
6 implicit parallel region is guaranteed by the time the program exits.
7 When any thread encounters a simd construct, the iterations of the loop associated with the
8 construct may be executed concurrently using the SIMD lanes that are available to the thread.
9 When a loop construct is encountered, the iterations of the loop associated with the construct are
10 executed in the context of its encountering threads, as determined according to its binding region. If
11 the loop region binds to a teams region, the region is encountered by the set of primary threads
12 that execute the teams region. If the loop region binds to a parallel region, the region is
13 encountered by the team of threads that execute the parallel region. Otherwise, the region is
14 encountered by a single thread.
15 If the loop region binds to a teams region, the encountering threads may continue execution
16 after the loop region without waiting for all iterations to complete; the iterations are guaranteed to
17 complete before the end of the teams region. Otherwise, all iterations must complete before the
18 encountering threads continue execution after the loop region. All threads that encounter the
19 loop construct may participate in the execution of the iterations. Only one of these threads may
20 execute any given iteration.
21 The cancel construct can alter the previously described flow of execution in an OpenMP region.
22 The effect of the cancel construct depends on its construct-type-clause. If a task encounters a
23 cancel construct with a taskgroup construct-type-clause, then the task activates cancellation
24 and continues execution at the end of its task region, which implies completion of that task. Any
25 other task in that taskgroup that has begun executing completes execution unless it encounters a
26 cancellation point construct, in which case it continues execution at the end of its task
27 region, which implies its completion. Other tasks in that taskgroup region that have not begun
28 execution are aborted, which implies their completion.
29 For all other construct-type-clause values, if a thread encounters a cancel construct, it activates
30 cancellation of the innermost enclosing region of the type specified and the thread continues
31 execution at the end of that region. Threads check if cancellation has been activated for their region
32 at cancellation points and, if so, also resume execution at the end of the canceled region.
33 If cancellation has been activated, regardless of construct-type-clause, threads that are waiting
34 inside a barrier other than an implicit barrier at the end of the canceled region exit the barrier and
35 resume execution at the end of the canceled region. This action can occur before the other threads
36 reach that barrier.
37 Synchronization constructs and library routines are available in the OpenMP API to coordinate
38 tasks and data access in parallel regions. In addition, library routines and environment
39 variables are available to control or to query the runtime environment of OpenMP programs.

1 The OpenMP specification makes no guarantee that input or output to the same file is synchronous
2 when executed in parallel. In this case, the programmer is responsible for synchronizing input and
3 output processing with the assistance of OpenMP synchronization constructs or library routines.
4 For the case where each thread accesses a different file, the programmer does not need to
5 synchronize access.
6 All concurrency semantics defined by the base language with respect to threads of execution apply
7 to OpenMP threads, unless specified otherwise.
8 1.4 Memory Model

9 1.4.1 Structure of the OpenMP Memory Model
10 The OpenMP API provides a relaxed-consistency, shared-memory model. All OpenMP threads
11 have access to a place to store and to retrieve variables, called the memory. A given storage location
12 in the memory may be associated with one or more devices, such that only threads on associated
13 devices have access to it. In addition, each thread is allowed to have its own temporary view of the
14 memory. The temporary view of memory for each thread is not a required part of the OpenMP
15 memory model, but can represent any kind of intervening structure, such as machine registers,
16 cache, or other local storage, between the thread and the memory. The temporary view of memory
17 allows the thread to cache variables and thereby to avoid going to memory for every reference to a
18 variable. Each thread also has access to another type of memory that must not be accessed by other
19 threads, called threadprivate memory.
20 A directive that accepts data-sharing attribute clauses determines two kinds of access to variables
21 used in the directive’s associated structured block: shared and private. Each variable referenced in
22 the structured block has an original variable, which is the variable by the same name that exists in
23 the program immediately outside the construct. Each reference to a shared variable in the structured
24 block becomes a reference to the original variable. For each private variable referenced in the
25 structured block, a new version of the original variable (of the same type and size) is created in
26 memory for each task or SIMD lane that contains code associated with the directive. Creation of
27 the new version does not alter the value of the original variable. However, the impact of attempts to
28 access the original variable from within the region corresponding to the directive is unspecified; see
29 Section 2.21.4.3 for additional details. References to a private variable in the structured block refer
30 to the private version of the original variable for the current task or SIMD lane. The relationship
31 between the value of the original variable and the initial or final value of the private version
32 depends on the exact clause that specifies it. Details of this issue, as well as other issues with
33 privatization, are provided in Section 2.21.
34 The minimum size at which a memory update may also read and write back adjacent variables that
35 are part of another variable (as array or structure elements) is implementation defined but is no
36 larger than the base language requires.
37 A single access to a variable may be implemented with multiple load or store instructions and, thus,
38 is not guaranteed to be atomic with respect to other accesses to the same variable. Accesses to

1 variables smaller than the implementation defined minimum size or to C or C++ bit-fields may be
2 implemented by reading, modifying, and rewriting a larger unit of memory, and may thus interfere
3 with updates of variables or fields in the same unit of memory.
4 Two memory operations are considered unordered if the order in which they must complete, as seen
5 by their affected threads, is not specified by the memory consistency guarantees listed in
6 Section 1.4.6. If multiple threads write to the same memory unit (defined consistently with the
7 above access considerations) then a data race occurs if the writes are unordered. Similarly, if at
8 least one thread reads from a memory unit and at least one thread writes to that same memory unit
9 then a data race occurs if the read and write are unordered. If a data race occurs then the result of
10 the program is unspecified.
11 A private variable in a task region that subsequently generates an inner nested parallel region is
12 permitted to be made shared for implicit tasks in the inner parallel region. A private variable in
13 a task region can also be shared by an explicit task region generated during its execution. However,
14 the programmer must use synchronization that ensures that the lifetime of the variable does not end
15 before completion of the explicit task region sharing it. Any other access by one task to the private
16 variables of another task results in unspecified behavior.
17 A storage location in memory that is associated with a given device has a device address that may
18 be dereferenced by a thread executing on that device, but it may not be generally accessible from
19 other devices. A different device may obtain a device pointer that refers to this device address. The
20 manner in which a program can obtain the referenced device address from a device pointer, outside
21 of mechanisms specified by OpenMP, is implementation defined.
22 1.4.2 Device Data Environments

23 When an OpenMP program begins, an implicit target data region for each device surrounds
24 the whole program. Each device has a device data environment that is defined by its implicit
25 target data region. Any declare target directives and directives that accept data-mapping
26 attribute clauses determine how an original variable in a data environment is mapped to a
27 corresponding variable in a device data environment.
28 When an original variable is mapped to a device data environment and a corresponding variable is
29 not present in the device data environment, a new corresponding variable (of the same type and size
30 as the original variable) is created in the device data environment. Conversely, the original variable
31 becomes the new variable’s corresponding variable in the device data environment of the device
32 that performs a mapping operation.
33 The corresponding variable in the device data environment may share storage with the original
34 variable. Writes to the corresponding variable may alter the value of the original variable. The
35 impact of this possibility on memory consistency is discussed in Section 1.4.6. When a task
36 executes in the context of a device data environment, references to the original variable refer to the
37 corresponding variable in the device data environment. If an original variable is not currently
38 mapped and a corresponding variable does not exist in the device data environment then accesses to

1 the original variable result in unspecified behavior unless the unified_shared_memory
2 clause is specified on a requires directive for the compilation unit.
3 The relationship between the value of the original variable and the initial or final value of the
4 corresponding variable depends on the map-type. Details of this issue, as well as other issues with
5 mapping a variable, are provided in Section 2.21.7.1.
6 The original variable in a data environment and a corresponding variable in a device data
7 environment may share storage. Without intervening synchronization data races can occur.
8 If a variable has a corresponding variable with which it does not share storage, a write to a storage
9 location designated by the variable causes the value at the corresponding storage location to
10 become undefined.
11 1.4.3 Memory Management

12 The host device, and other devices that an implementation may support, have attached storage
13 resources where program variables are stored. These resources can have different traits. A memory
14 space in an OpenMP program represents a set of these storage resources. Memory spaces are
15 defined according to a set of traits, and a single resource may be exposed as multiple memory
16 spaces with different traits or may be part of multiple memory spaces. In any device, at least one
17 memory space is guaranteed to exist.
18 An OpenMP program can use a memory allocator to allocate memory in which to store variables.
19 This memory will be allocated from the storage resources of the memory space associated with the
20 memory allocator. Memory allocators are also used to deallocate previously allocated memory.
21 When an OpenMP memory allocator is not used to allocate memory, OpenMP does not prescribe
22 the storage resource for the allocation; the memory for the variables may be allocated in any storage
23 resource.
24 1.4.4 The Flush Operation

25 The memory model has relaxed-consistency because a thread’s temporary view of memory is not
26 required to be consistent with memory at all times. A value written to a variable can remain in the
27 thread’s temporary view until it is forced to memory at a later time. Likewise, a read from a
28 variable may retrieve the value from the thread’s temporary view, unless it is forced to read from
29 memory. OpenMP flush operations are used to enforce consistency between a thread’s temporary
30 view of memory and memory, or between multiple threads’ view of memory.
31 A flush operation has an associated device-set that constrains the threads with which it enforces
32 memory consistency. Consistency is only guaranteed to be enforced between the view of memory
33 of its thread and the view of memory of other threads executing on devices in its device-set. Unless
34 otherwise stated, the device-set of a flush operation only includes the current device.
35 If a flush operation is a strong flush, it enforces consistency between a thread’s temporary view and
36 memory. A strong flush operation is applied to a set of variables called the flush-set. A strong flush

1 restricts reordering of memory operations that an implementation might otherwise do.
2 Implementations must not reorder the code for a memory operation for a given variable, or the code
3 for a flush operation for the variable, with respect to a strong flush operation that refers to the same
4 variable.
5 If a thread has performed a write to its temporary view of a shared variable since its last strong flush
6 of that variable, then when it executes another strong flush of the variable, the strong flush does not
7 complete until the value of the variable has been written to the variable in memory. If a thread
8 performs multiple writes to the same variable between two strong flushes of that variable, the strong
9 flush ensures that the value of the last write is written to the variable in memory. A strong flush of a
10 variable executed by a thread also causes its temporary view of the variable to be discarded, so that
11 if its next memory operation for that variable is a read, then the thread will read from memory and
12 capture the value in its temporary view. When a thread executes a strong flush, no later memory
13 operation by that thread for a variable involved in that strong flush is allowed to start until the strong
14 flush completes. The completion of a strong flush executed by a thread is defined as the point at
15 which all writes to the flush-set performed by the thread before the strong flush are visible in
16 memory to all other threads, and at which that thread’s temporary view of the flush-set is discarded.
17 A strong flush operation provides a guarantee of consistency between a thread’s temporary view
18 and memory. Therefore, a strong flush can be used to guarantee that a value written to a variable by
19 one thread may be read by a second thread. To accomplish this, the programmer must ensure that
20 the second thread has not written to the variable since its last strong flush of the variable, and that
21 the following sequence of events are completed in this specific order:
22 1. The value is written to the variable by the first thread;
23 2. The variable is flushed, with a strong flush, by the first thread;
24 3. The variable is flushed, with a strong flush, by the second thread; and
25 4. The value is read from the variable by the second thread.
26 If a flush operation is a release flush or acquire flush, it can enforce consistency between the views
27 of memory of two synchronizing threads. A release flush guarantees that any prior operation that
28 writes or reads a shared variable will appear to be completed before any operation that writes or
29 reads the same shared variable and follows an acquire flush with which the release flush
30 synchronizes (see Section 1.4.5 for more details on flush synchronization). A release flush will
31 propagate the values of all shared variables in its temporary view to memory prior to the thread
32 performing any subsequent atomic operation that may establish a synchronization. An acquire flush
33 will discard any value of a shared variable in its temporary view to which the thread has not written
34 since last performing a release flush, and it will load any value of a shared variable propagated by a
35 release flush that synchronizes with it into its temporary view so that it may be subsequently read.
36 Therefore, release and acquire flushes may also be used to guarantee that a value written to a
37 variable by one thread may be read by a second thread. To accomplish this, the programmer must
38 ensure that the second thread has not written to the variable since its last acquire flush, and that the
39 following sequence of events happen in this specific order:

1 1. The value is written to the variable by the first thread;
2 2. The first thread performs a release flush;
3 3. The second thread performs an acquire flush; and
4 4. The value is read from the variable by the second thread.
5
6 Note – OpenMP synchronization operations, described in Section 2.19 and in Section 3.9, are
7 recommended for enforcing this order. Synchronization through variables is possible but is not
8 recommended because the proper timing of flushes is difficult.
9
10 The flush properties that define whether a flush operation is a strong flush, a release flush, or an
11 acquire flush are not mutually disjoint. A flush operation may be a strong flush and a release flush;
12 it may be a strong flush and an acquire flush; it may be a release flush and an acquire flush; or it
13 may be all three.
14 1.4.5 Flush Synchronization and Happens Before

15 OpenMP supports thread synchronization with the use of release flushes and acquire flushes. For
16 any such synchronization, a release flush is the source of the synchronization and an acquire flush is
17 the sink of the synchronization, such that the release flush synchronizes with the acquire flush.
18 A release flush has one or more associated release sequences that define the set of modifications
19 that may be used to establish a synchronization. A release sequence starts with an atomic operation
20 that follows the release flush and modifies a shared variable and additionally includes any
21 read-modify-write atomic operations that read a value taken from some modification in the release
22 sequence. The following rules determine the atomic operation that starts an associated release
23 sequence.
24 • If a release flush is performed on entry to an atomic operation, that atomic operation starts its
25 release sequence.
26 • If a release flush is performed in an implicit flush region, an atomic operation that is provided
27 by the implementation and that modifies an internal synchronization variable starts its release
28 sequence.
29 • If a release flush is performed by an explicit flush region, any atomic operation that modifies a
30 shared variable and follows the flush region in its thread’s program order starts an associated
31 release sequence.
32 An acquire flush is associated with one or more prior atomic operations that read a shared variable
33 and that may be used to establish a synchronization. The following rules determine the associated
34 atomic operation that may establish a synchronization.

1 • If an acquire flush is performed on exit from an atomic operation, that atomic operation is its
2 associated atomic operation.
3 • If an acquire flush is performed in an implicit flush region, an atomic operation that is
4 provided by the implementation and that reads an internal synchronization variable is its
5 associated atomic operation.
6 • If an acquire flush is performed by an explicit flush region, any atomic operation that reads a
7 shared variable and precedes the flush region in its thread’s program order is an associated
8 atomic operation.
9 A release flush synchronizes with an acquire flush if the following conditions are satisfied:
10 • An atomic operation associated with the acquire flush reads a value written by a modification
11 from a release sequence associated with the release flush; and
12 • The device on which each flush is performed is in both of their respective device-sets.
13 An operation X simply happens before an operation Y if any of the following conditions are
14 satisfied:
15 1. X and Y are performed by the same thread, and X precedes Y in the thread’s program order;
16 2. X synchronizes with Y according to the flush synchronization conditions explained above or
17 according to the base language’s definition of synchronizes with, if such a definition exists; or
18 3. Another operation, Z, exists such that X simply happens before Z and Z simply happens before Y.
19 An operation X happens before an operation Y if any of the following conditions are satisfied:
20 1. X happens before Y according to the base language’s definition of happens before, if such a
21 definition exists; or
22 2. X simply happens before Y.
23 A variable with an initial value is treated as if the value is stored to the variable by an operation that
24 happens before all operations that access or modify the variable in the program.
25 1.4.6 OpenMP Memory Consistency

26 The following rules guarantee an observable completion order for a given pair of memory
27 operations in race-free programs, as seen by all affected threads. If both memory operations are
28 strong flushes, the affected threads are all threads on devices in both of their respective device-sets.
29 If exactly one of the memory operations is a strong flush, the affected threads are all threads on
30 devices in its device-set. Otherwise, the affected threads are all threads.
31 • If two operations performed by different threads are sequentially consistent atomic operations or
32 they are strong flushes that flush the same variable, then they must be completed as if in some
33 sequential order, seen by all affected threads.

1 • If two operations performed by the same thread are sequentially consistent atomic operations or
2 they access, modify, or, with a strong flush, flush the same variable, then they must be completed
3 as if in that thread’s program order, as seen by all affected threads.
4 • If two operations are performed by different threads and one happens before the other, then they
5 must be completed as if in that happens before order, as seen by all affected threads, if:
6 – both operations access or modify the same variable;
7 – both operations are strong flushes that flush the same variable; or
8 – both operations are sequentially consistent atomic operations.
9 • Any two atomic memory operations from different atomic regions must be completed as if in
10 the same order as the strong flushes implied in their respective regions, as seen by all affected
11 threads.
12 The flush operation can be specified using the flush directive, and is also implied at various
13 locations in an OpenMP program: see Section 2.19.8 for details.
14
15 Note – Since flush operations by themselves cannot prevent data races, explicit flush operations are
16 only useful in combination with non-sequentially consistent atomic directives.
17
18 OpenMP programs that:

19 • Do not use non-sequentially consistent atomic directives;
20 • Do not rely on the accuracy of a false result from omp_test_lock and
21 omp_test_nest_lock; and
22 • Correctly avoid data races as required in Section 1.4.1,
23 behave as though operations on shared variables were simply interleaved in an order consistent with
24 the order in which they are performed by each thread. The relaxed consistency model is invisible
25 for such programs, and any explicit flush operations in such programs are redundant.
26 1.5 Tool Interfaces

27 The OpenMP API includes two tool interfaces, OMPT and OMPD, to enable development of
28 high-quality, portable, tools that support monitoring, performance, or correctness analysis and
29 debugging of OpenMP programs developed using any implementation of the OpenMP API.
30 An implementation of the OpenMP API may differ from the abstract execution model described by
31 its specification. The ability of tools that use the OMPT or OMPD interfaces to observe such
32 differences does not constrain implementations of the OpenMP API in any way.

1 1.5.1 OMPT
2 The OMPT interface, which is intended for first-party tools, provides the following:
3 • A mechanism to initialize a first-party tool;
4 • Routines that enable a tool to determine the capabilities of an OpenMP implementation;
5 • Routines that enable a tool to examine OpenMP state information associated with a thread;
6 • Mechanisms that enable a tool to map implementation-level calling contexts back to their
7 source-level representations;
8 • A callback interface that enables a tool to receive notification of OpenMP events;
9 • A tracing interface that enables a tool to trace activity on OpenMP target devices; and
10 • A runtime library routine that an application can use to control a tool.
11 OpenMP implementations may differ with respect to the thread states that they support, the mutual
12 exclusion implementations that they employ, and the OpenMP events for which tool callbacks are
13 invoked. For some OpenMP events, OpenMP implementations must guarantee that a registered
14 callback will be invoked for each occurrence of the event. For other OpenMP events, OpenMP
15 implementations are permitted to invoke a registered callback for some or no occurrences of the
16 event; for such OpenMP events, however, OpenMP implementations are encouraged to invoke tool
17 callbacks on as many occurrences of the event as is practical. Section 4.2.4 specifies the subset of
18 OMPT callbacks that an OpenMP implementation must support for a minimal implementation of
19 the OMPT interface.
20 With the exception of the omp_control_tool runtime library routine for tool control, all other
21 routines in the OMPT interface are intended for use only by tools and are not visible to
22 applications. For that reason, a Fortran binding is provided only for omp_control_tool; all
23 other OMPT functionality is described with C syntax only.
24 1.5.2 OMPD
25 The OMPD interface is intended for third-party tools, which run as separate processes. An
26 OpenMP implementation must provide an OMPD library that can be dynamically loaded and used
27 by a third-party tool. A third-party tool, such as a debugger, uses the OMPD library to access
28 OpenMP state of a program that has begun execution. OMPD defines the following:
29 • An interface that an OMPD library exports, which a tool can use to access OpenMP state of a
30 program that has begun execution;
31 • A callback interface that a tool provides to the OMPD library so that the library can use it to
32 access the OpenMP state of a program that has begun execution; and

1 • A small number of symbols that must be defined by an OpenMP implementation to help the tool
2 find the correct OMPD library to use for that OpenMP implementation and to facilitate
3 notification of events.
4 Section 5 describes OMPD in detail.
5 1.6 OpenMP Compliance

6 The OpenMP API defines constructs that operate in the context of the base language that is
7 supported by an implementation. If the implementation of the base language does not support a
8 language construct that appears in this document, a compliant OpenMP implementation is not
9 required to support it, with the exception that for Fortran, the implementation must allow case
10 insensitivity for directive and API routines names, and must allow identifiers of more than six
11 characters. An implementation of the OpenMP API is compliant if and only if it compiles and
12 executes all other conforming programs, and supports the tool interface, according to the syntax and
13 semantics laid out in Chapters 1, 2, 3, 4 and 5. Appendices A and B as well as sections designated
14 as Notes (see Section 1.8) are for information purposes only and are not part of the specification.
15 All library, intrinsic and built-in routines provided by the base language must be thread-safe in a
16 compliant implementation. In addition, the implementation of the base language must also be
17 thread-safe. For example, ALLOCATE and DEALLOCATE statements must be thread-safe in
18 Fortran. Unsynchronized concurrent use of such routines by different threads must produce correct
19 results (although not necessarily the same as serial execution results, as in the case of random
20 number generation routines).
21 Starting with Fortran 90, variables with explicit initialization have the SAVE attribute implicitly.
22 This is not the case in Fortran 77. However, a compliant OpenMP Fortran implementation must
23 give such a variable the SAVE attribute, regardless of the underlying base language version.
24 Appendix A lists certain aspects of the OpenMP API that are implementation defined. A compliant
25 implementation must define and document its behavior for each of the items in Appendix A.
26 1.7 Normative References

27 • ISO/IEC 9899:1990, Information Technology - Programming Languages - C.
28 This OpenMP API specification refers to ISO/IEC 9899:1990 as C90.

3 • ISO/IEC 14882:1998, Information Technology - Programming Languages - C++.
4 This OpenMP API specification refers to ISO/IEC 14882:1998 as C++98.
13 • ISO/IEC 1539:1980, Information Technology - Programming Languages - Fortran.
14 This OpenMP API specification refers to ISO/IEC 1539:1980 as Fortran 77.
15 • ISO/IEC 1539:1991, Information Technology - Programming Languages - Fortran.
16 This OpenMP API specification refers to ISO/IEC 1539:1991 as Fortran 90.
17 • ISO/IEC 1539-1:1997, Information Technology - Programming Languages - Fortran.
18 This OpenMP API specification refers to ISO/IEC 1539-1:1997 as Fortran 95.
24 This OpenMP API specification refers to ISO/IEC 1539-1:2018 as Fortran 2018. While future
25 versions of the OpenMP specification are expected to address the following features, currently
26 their use may result in unspecified behavior.
27 – Declared type of a polymorphic allocatable component in structure constructor
28 – SELECT RANK construct
29 – IEEE comparison predicate in intrinsic relational operators
30 – Finalization of an allocatable subobject in intrinsic assignment

1 – Locality of variables in a DO CONCURRENT construct
2 – IMPORT statement extensions
3 – Assumed-rank dummy argument
4 – Assumed-type dummy argument
5 – Interoperable procedure enhancements
6 – ASYNCHRONOUS attribute enhancement
7 Where this OpenMP API specification refers to C, C++ or Fortran, reference is made to the base
8 language supported by the implementation.
9 1.8 Organization of this Document

10 The remainder of this document is structured as follows:
11 • Chapter 2 “Directives”
12 • Chapter 3 “Runtime Library Routines”
13 • Chapter 4 “OMPT Interface”
14 • Chapter 5 “OMPD Interface”
15 • Chapter 6 “Environment Variables”
16 • Appendix A “OpenMP Implementation-Defined Behaviors”
17 • Appendix B “Features History”
18 Some sections of this document only apply to programs written in a certain base language. Text that
19 applies only to programs for which the base language is C or C++ is shown as follows:
C / C++
20 C/C++ specific text...
C / C++
21 Text that applies only to programs for which the base language is C only is shown as follows:
C
22 C specific text...
C
23 Text that applies only to programs for which the base language is C++ only is shown as follows:
C++
24 C++ specific text...
C++

1 Text that applies only to programs for which the base language is Fortran is shown as follows:
Fortran
2 Fortran specific text...
Fortran
3 Where an entire page consists of base language specific text, a marker is shown at the top of the
4 page. For Fortran-specific text, the marker is:
Fortran (cont.)
5 For C/C++-specific text, the marker is:
C/C++ (cont.)
6 Some text is for information only, and is not part of the normative specification. Such text is
7 designated as a note or comment, like this:
8
9 Note – Non-normative text...

10
11 COMMENT: Non-normative text...

1 2 Directives
2 This chapter describes the syntax and behavior of OpenMP directives.
C
3 OpenMP directives are specified with the #pragma mechanism provided by the C standard.
C
C++
4 OpenMP directives are specified with attribute specifiers or the #pragma mechanism provided by
5 the C++ standard.
C++
Fortran
6 OpenMP directives are specified with stylized comments that are identified by unique sentinels.
7 Also, a stylized comment form is available for conditional compilation.
8 If a directive appears in the declarative part of a module then the behavior is as if that directive
9 appears after any references to that module.
Fortran
10 Compilers can therefore ignore OpenMP directives and conditionally compiled code if support of
11 the OpenMP API is not provided or enabled. A compliant implementation must provide an option
12 or interface that ensures that underlying support of all OpenMP directives and OpenMP conditional
13 compilation mechanisms is enabled. In the remainder of this document, the phrase OpenMP
14 compilation is used to mean a compilation with these OpenMP features enabled.
C / C++
15 This chapter uses NULL as a generic term for a null pointer constant, true as a generic term for a
16 non-zero integer value and false as a generic term for an integer value of zero.
C / C++
Fortran
17 This chapter uses NULL as a generic term for the named constant C_NULL_PTR, true as a generic
18 term for a logical value of .TRUE. and false as a generic term for a logical value of .FALSE..
Fortran
CHAPTER 2. DIRECTIVES 37
1 Restrictions
2 The following restrictions apply to OpenMP directives:
C / C++
C
3 • A declarative directive may not be used in place of a substatement in a selection statement, in
4 place of the loop body in an iteration statement, or in place of the statement that follows a label.
C
C++
5 • A declarative directive may not be used in place of a substatement in a selection statement or
6 iteration statement, or in place of the statement that follows a label.
C++
C / C++
Fortran
7 • OpenMP directives, except simd and declarative directives, may not appear in pure procedures.
8 • OpenMP directives may not appear in the WHERE, FORALL or DO CONCURRENT constructs.
Fortran
9 2.1 Directive Format

C / C++
10 OpenMP directives for C/C++ may be specified with #pragma directives as follows:
11 #pragma omp directive-name [[,] clause[ [,] clause] ... ] new-line
12 Where directive-name is the name of the directive and, when specified in the syntax of the directive,
13 any directive-level arguments enclosed in parentheses.
14
15 Note – In the following example, depobj(o) is the directive-name:
16 #pragma omp depobj(o) depend(inout: d)
17
18 Each #pragma directive starts with #pragma omp. The remainder of the directive follows the
19 conventions of the C and C++ standards for compiler directives. In particular, white space can be
20 used before and after the #, and sometimes white space must be used to separate the words in a
21 directive. Preprocessing tokens following #pragma omp are subject to macro replacement.
22 Some OpenMP directives may be composed of consecutive #pragma directives if specified in
23 their syntax.
C / C++

C++
1 In C++11 and higher, all OpenMP directives may be specified with C++ attribute specifiers as
2 follows:
3 [[ omp :: directive( directive-name[[,] clause[[,] clause]... ] ) ]]
4 or
5 [[ using omp : directive( directive-name[[,] clause[[,] clause]... ] ) ]]
6 The above two forms are interchangeable for any OpenMP directive. Some OpenMP directives may
7 be composed of consecutive attribute specifiers if specified in their syntax. Any two consecutive
8 attribute specifiers may be reordered or expressed as a single attribute specifier, as permitted by the
9 base language, without changing the behavior of the OpenMP directive.
10 Some directives may have additional forms that use the attribute syntax.
11 Multiple attributes on the same statement are allowed. A directive that uses the attribute syntax
12 cannot be applied to the same statement as a directive that uses the pragma syntax. For any
13 directive that has a paired end directive, including those with a begin and end pair, both directives
14 must use either the attribute syntax or the pragma syntax. Attribute directives that apply to the same
15 statement are unordered. An ordering can be imposed with the sequence attribute, which is
16 specified as follows:
17 [[ omp :: sequence( [omp::]directive-attr [, [omp::]directive-attr]... ) ]]
18 where directive-attr is any attribute in the omp namespace, optionally specified with a omp::
19 namespace qualifier, which may be another sequence attribute.
20 The application of multiple attributes in a sequence attribute is ordered as if each directive had
21 been written as a #pragma directive on subsequent lines.
22
23 Note – This is an example of the expected transformation:

24 [[ omp::sequence(directive(parallel), directive(for)) ]]
25 for(...) {}
26 // becomes
27 #pragma omp parallel
28 #pragma omp for
29 for(...) {}
30
C++
C / C++
1 Directives are case-sensitive.
2 Each of the expressions used in the OpenMP syntax inside of the clauses must be a valid
3 assignment-expression of the base language unless otherwise specified.
C / C++
C++
4 Directives may not appear in constexpr functions or in constant expressions.
C++
Fortran
5 OpenMP directives for Fortran are specified as follows:
6 sentinel directive-name [clause[ [,] clause]...]
7 All OpenMP compiler directives must begin with a directive sentinel. The format of a sentinel
8 differs between fixed form and free form source files, as described in Section 2.1.1 and
9 Section 2.1.2.
10 Directives are case insensitive. Directives cannot be embedded within continued statements, and
11 statements cannot be embedded within directives.
12 Each of the expressions used in the OpenMP syntax inside of the clauses must be a valid expression
13 of the base language unless otherwise specified.
14 In order to simplify the presentation, free form is used for the syntax of OpenMP directives for
15 Fortran in the remainder of this document, except as noted.
Fortran
16 A directive may be categorized as one of the following: a metadirective, a declarative directive, an
17 executable directive, an informational directive, or a utility directive.
18 Only one directive-name can be specified per directive (note that this includes combined directives,
19 see Section 2.16). The order in which clauses appear on directives is not significant. Clauses on
20 directives may be repeated as needed, subject to the restrictions listed in the description of each
21 clause or the directives on which they can appear.
22 Some clauses accept a list, an extended-list, or a locator-list. A list consists of a comma-separated
23 collection of one or more list items. An extended-list consists of a comma-separated collection of
24 one or more extended list items. A locator-list consists of a comma-separated collection of one or
25 more locator list items.
C / C++
26 A list item is a variable or an array section. An extended list item is a list item or a function name. A
27 locator list item is any lvalue expression including variables, an array section, or a reserved locator.
C / C++

Fortran
1 A list item is a variable that is not coindexed, an array section that is not coindexed, a named
2 constant, an associate name that may appear in a variable definition context, or a common block
3 name (enclosed in slashes). An extended list item is a list item or a procedure name. A locator list
4 item is a list item, or a reserved locator.
5 A named constant as a list item can appear only in clauses where it is explicitly allowed.
6 When a named common block appears in a list, it has the same meaning and restrictions as if every
7 explicit member of the common block appeared in the list. An explicit member of a common block
8 is a variable that is named in a COMMON statement that specifies the common block name and is
9 declared in the same scoping unit in which the clause appears. Named common blocks do not
10 include the blank common block.
11 Although variables in common blocks can be accessed by use association or host association,
12 common block names cannot. As a result, a common block name specified in a data-sharing
13 attribute, a data copying, or a data-mapping attribute clause must be declared to be a common block
14 in the same scoping unit in which the clause appears.
15 If a list item that appears in a directive or clause is an optional dummy argument that is not present,
16 the directive or clause for that list item is ignored.
17 If the variable referenced inside a construct is an optional dummy argument that is not present, any
18 explicitly determined, implicitly determined, or predetermined data-sharing and data-mapping
19 attribute rules for that variable are ignored. Otherwise, if the variable is an optional dummy
20 argument that is present, it is present inside the construct.
Fortran
21 For all base languages, a list item, an extended list item, or a locator list item is subject to the
22 restrictions specified in Section 2.1.5 and in each of the sections that describe clauses and directives
23 for which the list, the extended-list, or the locator-list appears.
24 Some clauses and directives accept the use of reserved locators as special identifiers that represent
25 system storage not necessarily bound to any base language storage item. Reserved locators may
26 only appear in clauses and directives where they are explicitly allowed and may not otherwise be
27 referenced in the program. The list of reserved locators is:
28 omp_all_memory
29 The reserved locator omp_all_memory is a reserved identifier that denotes a list item treated as
30 having storage that corresponds to the storage of all other objects in memory.
31 Some directives have an associated structured block or a structured block sequence.
C / C++
1 A structured block sequence that consists of more than one statement may appear only for
2 executable directives that explicitly allow it. The corresponding compound statement obtained by
3 enclosing the sequence in { and } must be a structured block and the structured block sequence
4 then should be considered to be a structured block with all of its restrictions.
C / C++
5 A structured block:
6 • may contain infinite loops where the point of exit is never reached;
7 • may halt due to an IEEE exception;
C / C++
8 • may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
9 _Noreturn specifier (in C) or a noreturn attribute (in C/C++);
10 • may be an expression statement, iteration statement, selection statement, or try block, provided
11 that the corresponding compound statement obtained by enclosing it in { and } would be a
12 structured block; and
C / C++
Fortran
13 • may contain STOP or ERROR STOP statements.
Fortran
14 Restrictions
15 Restrictions to structured blocks are as follows:
16 • Entry to a structured block must not be the result of a branch.
17 • The point of exit cannot be a branch out of the structured block.
C / C++
18 • The point of entry to a structured block must not be a call to setjmp.
19 • longjmp must not violate the entry/exit criteria.
C / C++
C++
20 • throw must not violate the entry/exit criteria.
21 • co_await, co_yield and co_return must not violate the entry/exit criteria.
C++

Fortran
1 • When a BLOCK construct appears in a structured block, that BLOCK construct must not contain
2 any ASYNCHRONOUS or VOLATILE statements, nor any specification statements that include
3 the ASYNCHRONOUS or VOLATILE attributes.
4 Restrictions on explicit OpenMP regions (that arise from executable directives) are as follows:
5 • If more than one image is executing the program, any image control statement, ERROR STOP
6 statement, FAIL IMAGE statement, collective subroutine call or access to a coindexed object that
7 appears in an explicit OpenMP region will result in unspecified behavior.
8 2.1.1 Fixed Source Form Directives

9 The following sentinels are recognized in fixed form source files:
10 !$omp | c$omp | *$omp
11 Sentinels must start in column 1 and appear as a single word with no intervening characters.
12 Fortran fixed form line length, white space, continuation, and column rules apply to the directive
13 line. Initial directive lines must have a space or a zero in column 6, and continuation directive lines
14 must have a character other than a space or a zero in column 6.
15 Comments may appear on the same line as a directive. The exclamation point initiates a comment
16 when it appears after column 6. The comment extends to the end of the source line and is ignored.
17 If the first non-blank character after the directive sentinel of an initial or continuation directive line
18 is an exclamation point, the line is ignored.
19
20 Note – In the following example, the three formats for specifying the directive are equivalent (the
21 first line represents the position of the first 9 columns):
22 c23456789
23 !$omp parallel do shared(a,b,c)
24
25 c$omp parallel do
26 c$omp+shared(a,b,c)
27
28 c$omp paralleldoshared(a,b,c)
29
1 2.1.2 Free Source Form Directives
2 The following sentinel is recognized in free form source files:
3 !$omp
4 The sentinel can appear in any column as long as it is preceded only by white space. It must appear
5 as a single word with no intervening white space. Fortran free form line length, white space, and
6 continuation rules apply to the directive line. Initial directive lines must have a space after the
7 sentinel. Continued directive lines must have an ampersand (&) as the last non-blank character on
8 the line, prior to any comment placed inside the directive. Continuation directive lines can have an
9 ampersand after the directive sentinel with optional white space before and after the ampersand.
10 Comments may appear on the same line as a directive. The exclamation point (!) initiates a
11 comment. The comment extends to the end of the source line and is ignored. If the first non-blank
12 character after the directive sentinel is an exclamation point, the line is ignored.
13 One or more blanks or horizontal tabs are optional to separate adjacent keywords in
14 directive-names unless otherwise specified.
15
16 Note – In the following example the three formats for specifying the directive are equivalent (the
17 first line represents the position of the first 9 columns):
18 !23456789
19 !$omp parallel do &
20 !$omp shared(a,b,c)
21
22 !$omp parallel &
23 !$omp&do shared(a,b,c)
24
25 !$omp paralleldo shared(a,b,c)
26
27
Fortran

1 2.1.3 Stand-Alone Directives
2 Summary
3 Stand-alone directives are executable directives that have no associated user code.
4 Description
5 Stand-alone directives do not have any associated executable user code. Instead, they represent
6 executable statements that typically do not have succinct equivalent statements in the base language.
7 Some restrictions limit the placement of a stand-alone directive within a program. A stand-alone
8 directive may be placed only at a point where a base language executable statement is allowed.
C / C++
9 Restrictions
10 Restrictions to stand-alone directives are as follows:
C
11 • A stand-alone directive may not be used in place of a substatement in a selection statement, in
12 place of the loop body in an iteration statement, or in place of the statement that follows a label.
C
C++
13 • A stand-alone directive may not be used in place of a substatement in a selection statement or
14 iteration statement, or in place of the statement that follows a label.
C++
15 2.1.4 Array Shaping

16 If an expression has a type of pointer to T, then a shape-operator can be used to specify the extent of
17 that pointer. In other words, the shape-operator is used to reinterpret, as an n-dimensional array, the
18 region of memory to which that expression points.
19 Formally, the syntax of the shape-operator is as follows:
20 shaped-expression := ([s1 ][s2 ]...[sn ])cast-expression
21 The result of applying the shape-operator to an expression is an lvalue expression with an

22 n-dimensional array type with dimensions s1 × s2 . . . × sn and element type T.
23 The precedence of the shape-operator is the same as a type cast.
24 Each si is an integral type expression that must evaluate to a positive integer.
1 Restrictions
2 Restrictions to the shape-operator are as follows:
3 • The type T must be a complete type.
4 • The shape-operator can appear only in clauses for which it is explicitly allowed.
5 • The result of a shape-operator must be a named array of a list item.
6 • The type of the expression upon which a shape-operator is applied must be a pointer type.
C++
7 • If the type T is a reference to a type T’, then the type will be considered to be T’ for all purposes
8 of the designated array.
C++
C / C++
9 2.1.5 Array Sections

10 An array section designates a subset of the elements in an array.
C / C++
11 To specify an array section in an OpenMP construct, array subscript expressions are extended with
12 the following syntax:
13 [ lower-bound : length : stride] or
14 [ lower-bound : length : ] or
15 [ lower-bound : length ] or
16 [ lower-bound : : stride] or
17 [ lower-bound : : ] or
18 [ lower-bound : ] or
19 [ : length : stride] or
20 [ : length : ] or
21 [ : length ] or
22 [ : : stride]
23 [::]
24 [:]

C/C++ (cont.)
1 The array section must be a subset of the original array.

2 Array sections are allowed on multidimensional arrays. Base language array subscript expressions
3 can be used to specify length-one dimensions of multidimensional array sections.
4 Each of the lower-bound, length, and stride expressions if specified must be an integral type
5 expression of the base language. When evaluated they represent a set of integer values as follows:
6 { lower-bound, lower-bound + stride, lower-bound + 2 * stride,... , lower-bound + ((length - 1) *
7 stride) }
8 The length must evaluate to a non-negative integer.
9 The stride must evaluate to a positive integer.
10 When the size of the array dimension is not known, the length must be specified explicitly.
11 When the stride is absent it defaults to 1.
12 When the length is absent it defaults to d(size − lower-bound)/stridee
e, where size is the size of the
13 array dimension.
14 When the lower-bound is absent it defaults to 0.
15 The precedence of a subscript operator that uses the array section syntax is the same as the
16 precedence of a subscript operator that does not use the array section syntax.
17
18 Note – The following are examples of array sections:

19 a[0:6]
20 a[0:6:1]
21 a[1:10]
22 a[1:]
23 a[:10:2]
24 b[10][:][:]
25 b[10][:][:0]
26 c[42][0:6][:]
27 c[42][0:6:2][:]
28 c[1:10][42][0:6]
29 S.c[:100]
30 p->y[:10]
31 this->a[:N]
32 (p+10)[:N]
1 Assume a is declared to be a 1-dimensional array with dimension size 11. The first two examples
2 are equivalent, and the third and fourth examples are equivalent. The fifth example specifies a stride
3 of 2 and therefore is not contiguous.
4 Assume b is declared to be a pointer to a 2-dimensional array with dimension sizes 10 and 10. The
5 sixth example refers to all elements of the 2-dimensional array given by b[10]. The seventh
6 example is a zero-length array section.
7 Assume c is declared to be a 3-dimensional array with dimension sizes 50, 50, and 50. The eighth
8 example is contiguous, while the ninth and tenth examples are not contiguous.
9 The final four examples show array sections that are formed from more general base expressions.
10 The following are examples that are non-conforming array sections:
11 s[:10].x
12 p[:10]->y
13 *(xp[:10])
14 For all three examples, a base language operator is applied in an undefined manner to an array
15 section. The only operator that may be applied to an array section is a subscript operator for which
16 the array section appears as the postfix expression.
17
18
C / C++
Fortran
19 Fortran has built-in support for array sections although some restrictions apply to their use in
20 OpenMP directives, as enumerated in the following section.
Fortran
21 Restrictions
22 Restrictions to array sections are as follows:
23 • An array section can appear only in clauses for which it is explicitly allowed.
24 • A stride expression may not be specified unless otherwise stated.
C / C++
25 • An element of an array section with a non-zero size must have a complete type.
26 • The base expression of an array section must have an array or pointer type.
27 • If a consecutive sequence of array subscript expressions appears in an array section, and the first
28 subscript expression in the sequence uses the extended array section syntax defined in this
29 section, then only the last subscript expression in the sequence may select array elements that
30 have a pointer type.
C / C++

C++
1 • If the type of the base expression of an array section is a reference to a type T, then the type will
2 be considered to be T for all purposes of the array section.
3 • An array section cannot be used in an overloaded [] operator.
C++
Fortran
4 • If a stride expression is specified, it must be positive.
5 • The upper bound for the last dimension of an assumed-size dummy array must be specified.
6 • If a list item is an array section with vector subscripts, the first array element must be the lowest
7 in the array element order of the array section.
8 • If a list item is an array section, the last part-ref of the list item must have a section subscript list.
Fortran
9 2.1.6 Iterators
10 Iterators are identifiers that expand to multiple values in the clause on which they appear.
11 The syntax of the iterator modifier is as follows:
12 iterator(iterators-definition)
13 where iterators-definition is one of the following:

14 iterator-specifier [, iterators-definition ]
15 where iterator-specifier is one of the following:

16 [ iterator-type ] identifier = range-specification
17 where:
18 • identifier is a base language identifier.
C / C++
19 • iterator-type is a type name.
C / C++
Fortran
20 • iterator-type is a type specifier.
Fortran
21 • range-specification is of the form begin:end[:step], where begin and end are expressions for
22 which their types can be converted to iterator-type and step is an integral expression.
C / C++
1 In an iterator-specifier, if the iterator-type is not specified then that iterator is of int type.
C / C++
Fortran
2 In an iterator-specifier, if the iterator-type is not specified then that iterator has default integer type.
Fortran
3 In a range-specification, if the step is not specified its value is implicitly defined to be 1.
4 An iterator only exists in the context of the clause in which it appears. An iterator also hides all
5 accessible symbols with the same name in the context of the clause.
6 The use of a variable in an expression that appears in the range-specification causes an implicit
7 reference to the variable in all enclosing constructs.
C / C++
8 The values of the iterator are the set of values i0 , . . . , iN −1 where:
9 • i0 = (iterator-type) begin,
10 • ij = (iterator-type) (ij−1 + step), where j ≥ 1 and
11 • if step > 0,
12 – i0 < (iterator-type) end,
13 – iN −1 < (iterator-type) end, and
14 – (iterator-type) (iN −1 + step) ≥ (iterator-type) end;
15 • if step < 0,
16 – i0 > (iterator-type) end,
17 – iN −1 > (iterator-type) end, and
18 – (iterator-type) (iN −1 + step) ≤ (iterator-type) end.
C / C++
Fortran
19 The values of the iterator are the set of values i1 , . . . , iN where:
20 • i1 = begin,
21 • ij = ij−1 + step, where j ≥ 2 and
22 • if step > 0,
23 – i1 ≤ end,
24 – iN ≤ end, and

1 – iN + step > end;
2 • if step < 0,
3 – i1 ≥ end,
4 – iN ≥ end, and
5 – iN + step < end.
Fortran
6 The set of values will be empty if no possible value complies with the conditions above.
7 For those clauses that contain expressions that contain iterator identifiers, the effect is as if the list
8 item is instantiated within the clause for each value of the iterator in the set defined above,
9 substituting each occurrence of the iterator identifier in the expression with the iterator value. If the
10 set of values of the iterator is empty then the effect is as if the clause was not specified.
11 The behavior is unspecified if ij + step cannot be represented in iterator-type in any of the
12 ij + step computations for any 0 ≤ j < N in C/C++ or 0 < j ≤ N in Fortran.
13 Restrictions
14 Restrictions to iterators are as follows:
15 • An expression that contains an iterator identifier can only appear in clauses that explicitly allow
16 expressions that contain iterators.
17 • The iterator-type must not declare a new type.
C / C++
18 • The iterator-type must be an integral or pointer type.
19 • The iterator-type must not be const qualified.
C / C++
Fortran
20 • The iterator-type must be an integer type.
Fortran
21 • If the step expression of a range-specification equals zero, the behavior is unspecified.
22 • Each iterator identifier can only be defined once in an iterators-definition.
23 • Iterators cannot appear in the range-specification.
1 2.2 Conditional Compilation
2 In implementations that support a preprocessor, the _OPENMP macro name is defined to have the
3 decimal value yyyymm where yyyy and mm are the year and month designations of the version of
4 the OpenMP API that the implementation supports.
5 If a #define or a #undef preprocessing directive in user code defines or undefines the
6 _OPENMP macro name, the behavior is unspecified.
Fortran
7 The OpenMP API requires Fortran lines to be compiled conditionally, as described in the following
8 sections.
9 2.2.1 Fixed Source Form Conditional Compilation Sentinels

10 The following conditional compilation sentinels are recognized in fixed form source files:
11 !$ | *$ | c$
12 To enable conditional compilation, a line with a conditional compilation sentinel must satisfy the
13 following criteria:
14 • The sentinel must start in column 1 and appear as a single word with no intervening white space;
15 • After the sentinel is replaced with two spaces, initial lines must have a space or zero in column 6
16 and only white space and numbers in columns 1 through 5;
17 • After the sentinel is replaced with two spaces, continuation lines must have a character other than
18 a space or zero in column 6 and only white space in columns 1 through 5.
19 If these criteria are met, the sentinel is replaced by two spaces. If these criteria are not met, the line
20 is left unchanged.
21
22 Note – In the following example, the two forms for specifying conditional compilation in fixed
23 source form are equivalent (the first line represents the position of the first 9 columns):
24 c23456789
25 !$ 10 iam = omp_get_thread_num() +
26 !$ & index
27
28 #ifdef _OPENMP
29 10 iam = omp_get_thread_num() +
30 & index
31 #endif
32

1 2.2.2 Free Source Form Conditional Compilation Sentinel
2 The following conditional compilation sentinel is recognized in free form source files:
3 !$
4 To enable conditional compilation, a line with a conditional compilation sentinel must satisfy the
5 following criteria:
6 • The sentinel can appear in any column but must be preceded only by white space;
7 • The sentinel must appear as a single word with no intervening white space;
8 • Initial lines must have a space after the sentinel;
9 • Continued lines must have an ampersand as the last non-blank character on the line, prior to any
10 comment appearing on the conditionally compiled line.
11 Continuation lines can have an ampersand after the sentinel, with optional white space before and
12 after the ampersand. If these criteria are met, the sentinel is replaced by two spaces. If these criteria
13 are not met, the line is left unchanged.
14
15 Note – In the following example, the two forms for specifying conditional compilation in free
16 source form are equivalent (the first line represents the position of the first 9 columns):
17 c23456789
18 !$ iam = omp_get_thread_num() + &
19 !$& index
20
21 #ifdef _OPENMP
22 iam = omp_get_thread_num() + &
23 index
24 #endif
25
26
Fortran
27 2.3 Variant Directives

28 2.3.1 OpenMP Context
29 At any point in a program, an OpenMP context exists that defines traits that describe the active
30 OpenMP constructs, the execution devices, functionality supported by the implementation and
31 available dynamic values. The traits are grouped into trait sets. The following trait sets exist:
32 construct, device, target_device, implementation and dynamic. Traits are categorized as name-list
1 traits, clause-list traits, non-property traits and extension traits. This categorization determines the
2 syntax that is used to match the trait, as defined in Section 2.3.2.
3 The construct set is composed of the directive names, each being a trait, of all enclosing constructs
4 at that point in the program up to a target construct. Combined and composite constructs are
5 added to the set as distinct constructs in the same nesting order specified by the original construct.
6 Whether the dispatch construct is added to the construct set is implementation defined. If it is
7 added, it will only be added for the target-call of the associated code. The set is ordered by nesting
8 level in ascending order. Specifically, the ordering of the set of constructs is c1 , . . . , cN , where c1 is
9 the construct at the outermost nesting level and cN is the construct at the innermost nesting level. In
10 addition, if the point in the program is not enclosed by a target construct, the following rules are
11 applied in order:
12 1. For procedures with a declare simd directive, the simd trait is added to the beginning of the
13 set as c1 for any generated SIMD versions so the total size of the set is increased by 1.
14 2. For procedures that are determined to be function variants by a declare variant directive, the
15 selectors c1 , . . . , cM of the construct selector set are added in the same order to the
16 beginning of the set as c1 , . . . , cM so the total size of the set is increased by M .
17 3. For device routines, the target trait is added to the beginning of the set as c1 for any versions of
18 the procedure that are generated for target regions so the total size of the set is increased by 1.
19 The simd trait is a clause-list trait that is defined with properties that match the clauses accepted by
20 the declare simd directive with the same name and semantics. The simd trait defines at least the
21 simdlen property and one of the inbranch or notinbranch properties. Traits in the construct set
22 other than simd are non-property traits.
23 The device set includes traits that define the characteristics of the device being targeted by the
24 compiler at that point in the program. For each target device that the implementation supports, a
25 target_device set exists that defines the characteristics of that device. At least the following traits
26 must be defined for the device and all target_device sets:
27 • The kind(kind-name-list) trait specifies the general kind of the device. The following kind-name
28 values are defined:
29 – host, which specifies that the device is the host device;
30 – nohost, which specifies that the devices is not the host device; and
31 – the values defined in the OpenMP Additional Definitions document.
32 • The isa(isa-name-list) trait specifies the Instruction Set Architectures supported by the device.
33 The accepted isa-name values are implementation defined.
34 • The arch(arch-name-list) trait specifies the architectures supported by the device. The accepted
35 arch-name values are implementation defined.
36 The kind, isa and arch traits in the device and target_device sets are name-list traits.

1 Additionally, the target_device set defines the following trait:
2 • The device_num trait specifies the device number of the device.
3 The implementation set includes traits that describe the functionality supported by the OpenMP
4 implementation at that point in the program. At least the following traits can be defined:
5 • The vendor(vendor-name-list) trait, which specifies the vendor identifiers of the implementation.
6 OpenMP defined values for vendor-name are defined in the OpenMP Additional Definitions
7 document.
8 • The extension(extension-name-list) trait, which specifies vendor specific extensions to the
9 OpenMP specification. The accepted extension-name values are implementation defined.
10 • A trait with a name that is identical to the name of any clause that was supplied to the requires
11 directive prior to the program point. Such traits other than the atomic_default_mem_order trait
12 are non-property traits. The presence of these traits has been deprecated.
13 • A requires(requires-clause-list) trait, which is a clause-list trait for which the properties are the
14 clauses that have been supplied to the requires directive prior to the program point as well as
15 implementation defined implicit requirements.
16 The vendor and extension traits in the implementation set are name-list traits.
17 Implementations can define additional traits in the device, target_device and implementation sets;
18 these traits are extension traits.
19 The dynamic trait set includes traits that define the dynamic properties of a program at a point in its
20 execution. The data state trait in the dynamic trait set refers to the complete data state of the
21 program that may be accessed at runtime.
22 2.3.2 Context Selectors

23 Context selectors are used to define the properties that can match an OpenMP context. OpenMP
24 defines different sets of selectors, each containing different selectors.
25 The syntax for a context selector is context-selector-specification as described in the following
26 grammar:
27 context-selector-specification:
28 trait-set-selector[,trait-set-selector[,...]]
29
30 trait-set-selector:
31 trait-set-selector-name={trait-selector[, trait-selector[, ...]]}
32
33 trait-selector:
34 trait-selector-name[([trait-score: ] trait-property[, trait-property[, ...]])]
35
36 trait-property:
1 trait-property-name
2 or
3 trait-property-clause
4 or
5 trait-property-expression
6 or
7 trait-property-extension
8
9 trait-property-clause:
10 clause
11
12 trait-property-name:
13 identifier
14 or
15 string-literal
16
17 trait-property-expression
18 scalar-expression (for C/C++)
19 or
20 scalar-logical-expression (for Fortran)
21 or
22 scalar-integer-expression (for Fortran)
23
24 trait-score:
25 score(score-expression)
26
27 trait-property-extension:
28 trait-property-name
29 or
30 identifier(trait-property-extension[, trait-property-extension[, ...]])
31 or
32 constant integer expression
33 For trait selectors that correspond to name-list traits, each trait-property should be
34 trait-property-name and for any value that is a valid identifier both the identifier and the
35 corresponding string literal (for C/C++) and the corresponding char-literal-constant (for Fortran)
36 representation are considered representations of the same value.
37 For trait selectors that correspond to clause-list traits, each trait-property should be
38 trait-property-clause. The syntax is the same as for the matching OpenMP clause.
39 The construct selector set defines the construct traits that should be active in the OpenMP
40 context. The following selectors can be defined in the construct set: target; teams;
41 parallel; for (in C/C++); do (in Fortran); simd and dispatch. Each trait-property of the
42 simd selector is a trait-property-clause. The syntax is the same as for a valid clause of the

1 declare simd directive and the restrictions on the clauses from that directive apply. The
2 construct selector is an ordered list c1 , . . . , cN .
3 The device and implementation selector sets define the traits that should be active in the
4 corresponding trait set of the OpenMP context. The target_device selector set defines the
5 traits that should be active in the target_device trait set for the device that the specified
6 device_num selector identifies. The same traits that are defined in the corresponding traits sets
7 can be used as selectors with the same properties. The kind selector of the device and
8 target_device selector sets can also specify the value any, which is as if no kind selector
9 was specified. If a device_num selector does not appear in the target_device selector set
10 then a device_num selector that specifies the value of the default-device-var ICV is implied. For
11 the device_num selector of the target_device selector set, a single
12 trait-property-expression must be specified. For the atomic_default_mem_order selector of
13 the implementation set, a single trait-property must be specified as an identifier equal to one
14 of the valid arguments to the atomic_default_mem_order clause on the requires
15 directive. For the requires selector of the implementation set, each trait-property is a
16 trait-property-clause. The syntax is the same as for a valid clause of the requires directive and
17 the restrictions on the clauses from that directive apply.
18 The user selector set defines the condition selector that provides additional user-defined
19 conditions.
20 The condition selector contains a single trait-property-expression that must evaluate to true for
21 the selector to be true.
22 Any non-constant expression that is evaluated to determine the suitability of a variant is evaluated
23 according to the data state trait in the dynamic trait set of the OpenMP context.
24 The user selector set is dynamic if the condition selector is present and the expression in the
25 condition selector is not a constant expression; otherwise, it is static.
26 All parts of a context selector define the static part of the context selector except the following
27 parts, which define the dynamic part of a context selector:
28 • Its user selector set if it is dynamic; and
29 • Its target_device selector set.
30 For the match clause of a declare variant directive, any argument of the base function that
31 is referenced in an expression that appears in the context selector is treated as a reference to the
32 expression that is passed into that argument at the call to the base function. Otherwise, a variable or
33 procedure reference in an expression that appears in a context selector is a reference to the variable
34 or procedure of that name that is visible at the location of the directive on which the selector
35 appears.
C++
1 Each occurrence of the this pointer in an expression in a context selector that appears in the
2 match clause of a declare variant directive is treated as an expression that is the address of
3 the object on which the associated base function is invoked.
C++
4 Implementations can allow further selectors to be specified. Each specified trait-property for these
5 implementation-defined selectors should be trait-property-extension. Implementations can ignore
6 specified selectors that are not those described in this section.
7 Restrictions
8 Restrictions to context selectors are as follows:
9 • Each trait-property can only be specified once in a trait-selector other than the construct
10 selector set.
11 • Each trait-set-selector-name can only be specified once.
12 • Each trait-selector-name can only be specified once.
13 • A trait-score cannot be specified in traits from the construct, device or
14 target_device trait-selector-sets.
15 • A score-expression must be a non-negative constant integer expression.
16 • The expression of a device_num trait must evaluate to a non-negative integer value that is less
17 than or equal to the value of omp_get_num_devices().
18 • A variable or procedure that is referenced in an expression that appears in a context selector must
19 be visible at the location of the directive on which the selector appears unless the directive is a
20 declare variant directive and the variable is an argument of the associated base function.
21 • If trait-property any is specified in the kind trait-selector of the device or
22 target_device selector set, no other trait-property may be specified in the same selector.
23 • For a trait-selector that corresponds to a name-list trait, at least one trait-property must be
24 specified.
25 • For a trait-selector that corresponds to a non-property trait, no trait-property may be specified.
26 • For the requires selector of the implementation selector set, at least one trait-property
27 must be specified.

1 2.3.3 Matching and Scoring Context Selectors
2 A given context selector is compatible with a given OpenMP context if the following conditions are
3 satisfied:
4 • All selectors in the user set of the context selector are true;
5 • All traits and trait properties that are defined by selectors in the target_device set of the
6 context selector are active in the target_device trait set for the device that is identified by the
7 device_num selector;
8 • All traits and trait properties that are defined by selectors in the construct, device and
9 implementation sets of the context selector are active in the corresponding trait sets of the
10 OpenMP context;
11 • For each selector in the context selector, its properties are a subset of the properties of the
12 corresponding trait of the OpenMP context;
13 • Selectors in the construct set of the context selector appear in the same relative order as their
14 corresponding traits in the construct trait set of the OpenMP context; and
15 • No specified implementation-defined selector is ignored by the implementation.
16 Some properties of the simd selector have special rules to match the properties of the simd trait:
17 • The simdlen(N) property of the selector matches the simdlen(M) trait of the OpenMP context
18 if M %N equals zero; and
19 • The aligned(list:N) property of the selector matches the aligned(list:M) trait of the OpenMP
20 context if N %M equals zero.
21 Among compatible context selectors, a score is computed using the following algorithm:
22 1. Each trait selector for which the corresponding trait appears in the construct trait set in the
23 OpenMP context is given the value 2p−1 where p is the position of the corresponding trait, cp , in
24 the context construct trait set; if the traits that correspond to the construct selector set
25 appear multiple times in the OpenMP context, the highest valued subset of context traits that
26 contains all selectors in the same order are used;
27 2. The kind, arch, and isa selectors, if specified, are given the values 2l , 2l+1 and 2l+2 ,
28 respectively, where l is the number of traits in the construct set;
29 3. Trait selectors for which a trait-score is specified are given the value specified by the trait-score
30 score-expression;
31 4. The values given to any additional selectors allowed by the implementation are implementation
32 defined;
33 5. Other selectors are given a value of zero; and
34 6. A context selector that is a strict subset of another context selector has a score of zero. For other
35 context selectors, the final score is the sum of the values of all specified selectors plus 1.
1 2.3.4 Metadirectives
2 Summary
3 A metadirective is a directive that can specify multiple directive variants of which one may be
4 conditionally selected to replace the metadirective based on the enclosing OpenMP context.
5 Syntax
C / C++
6 The syntax of a metadirective is as follows:
7 #pragma omp metadirective [clause[ [,] clause] ... ] new-line
8 or
9 #pragma omp begin metadirective [clause[ [,] clause] ... ] new-line
10 stmt(s)
11 #pragma omp end metadirective
12 where clause is one of the following:

13 when(context-selector-specification: [directive-variant])
14 default([directive-variant])
C / C++
Fortran
15 The syntax of a metadirective is as follows:
16 !$omp metadirective [clause[ [,] clause] ... ]
17 or
18 !$omp begin metadirective [clause[ [,] clause] ... ]
19 stmt(s)
20 !$omp end metadirective

22 when(context-selector-specification: [directive-variant])
23 default([directive-variant])
Fortran
24 In the when clause, context-selector-specification specifies a context selector (see Section 2.3.2).
25 In the when and default clauses, directive-variant has the following form and specifies a
26 directive variant that specifies an OpenMP directive with clauses that apply to it.
27 directive-name [clause[ [,] clause] ... ]

1 Description
2 A metadirective is replaced by a nothing directive or one of the directive variants specified by
3 the when clauses or the default clause.
4 If no default clause is specified the effect is as if a default clause without an associated
5 directive variant was specified.
6 The default clause is treated as a when clause with the specified directive variant, if any, and an
7 always compatible static context selector that has a score lower than the scores associated with any
8 other clause.
9 If a when clause does not explicitly specify a directive variant it implicitly specifies a nothing
10 directive as the directive variant.
11 The OpenMP context for a given metadirective is defined according to Section 2.3.1.
12 The directive variant specified by a when clause is a candidate to replace the metadirective if the
13 static part of the corresponding context selector is compatible with the OpenMP context according
14 to the matching rules defined in Section 2.3.3.
15 Replacement candidates are ordered according to the following rules in decreasing precedence:
16 • A candidate is before another one if the score associated with the context selector of the
17 corresponding when clause is higher.
18 • A candidate that was explicitly specified is before one that was implicitly specified.
19 • Candidates are ordered according to the order in which they lexically appear on the metadirective.
20 The list of dynamic replacement candidates is the prefix of the sorted list of replacement candidates
21 up to and including the first candidate for which the corresponding when clause has a static context
22 selector.
23 The first dynamic replacement candidate for which the corresponding when clause has a
24 compatible context selector, according to the matching rules defined in Section 2.3.3, replaces the
25 metadirective.
26 Expressions that appear in the context selector of a when clause are evaluated if no prior dynamic
27 replacement candidate has a compatible context selector, and the number of times each expression
28 is evaluated is implementation defined. All variables referenced by these expressions are
29 considered to be referenced by the metadirective.
30 A directive variant that is associated with a when clause may only affect the program if the
31 directive variant is a dynamic replacement candidate.
32 The begin metadirective directive behaves identically to the metadirective directive,
33 except that the directive syntax for the specified directive variants other than the nothing
34 directive must accept a paired end directive. For any directive variant that is selected to replace the
35 begin metadirective directive, the end metadirective directive will be implicitly
36 replaced by its paired end directive to demarcate the statements that are affected by or are
1 associated with the directive variant. If the nothing directive is selected to replace the
2 begin metadirective directive, its paired end metadirective directive is ignored.
3 Restrictions
4 Restrictions to metadirectives are as follows:
5 • The directive variant appearing in a when or default clause must not specify a
6 metadirective, begin metadirective, or end metadirective directive.
C / C++
7 • The directive variant that appears in a when or default clause must not specify a
8 begin declare variant or end declare variant.
C / C++
9 • The context selector that appears in a when clause must not specify any properties for the simd
10 selector.
11 • Replacement of the metadirective with the directive variant associated with any of the dynamic
12 replacement candidates must result in a conforming OpenMP program.
13 • Insertion of user code at the location of a metadirective must be allowed if the first dynamic
14 replacement candidate does not have a static context selector.
15 • All items must be executable directives if the first dynamic replacement candidate does not have
16 a static context selector.
17 • Any directive variant that is specified by a when or default clause on a
18 begin metadirective directive must be an OpenMP directive that has a paired
19 end directive or must be the nothing directive, and the begin metadirective directive
20 must have a paired end metadirective directive.
21 • The default clause may appear at most once on a metadirective.

1 2.3.5 Declare Variant Directive
2 Summary
3 The declare variant directive declares a specialized variant of a base function and specifies the
4 context in which that specialized variant is used. The declare variant directive is a declarative
5 directive.
6 Syntax
C / C++
7 The syntax of the declare variant directive is as follows:
8 #pragma omp declare variant(variant-func-id) clause [[[,] clause] ... ] new-line
9 [#pragma omp declare variant(variant-func-id) clause [[[,] clause] ... ] new-line
10 [ ... ]]
11 function definition or declaration
12 or
13 #pragma omp begin declare variant clause new-line
14 declaration-definition-seq
15 #pragma omp end declare variant new-line

17 match(context-selector-specification)
18 adjust_args(adjust-op:argument-list)
19 append_args(append-op[[,append-op]...])
20 where adjust-op is one of the following:

21 nothing
22 need_device_ptr
23 where append-op is one of the following:

24 interop(interop-type[[,interop-type]...])
25 and where variant-func-id is the name of a function variant that is either a base language identifier
26 or, for C++, a template-id.
C / C++
Fortran
1 The syntax of the declare variant directive is as follows:
2 !$omp declare variant([base-proc-name:]variant-proc-name) clause [[[,] clause] ...
3 ]

5 match(context-selector-specification)
6 adjust_args(adjust-op:argument-list)
7 append_args(append-op[[,append-op]...])
8 where adjust-op is one of the following:

9 nothing
10 need_device_ptr
11 where append-op is one of the following:

12 interop(interop-type[[,interop-type]...])
13 and where variant-proc-name is the name of a function variant that is a base language identifier.
Fortran
14 Description
15 The declare variant directive declares a base function to have the specified function variant. The
16 context selector in the match clause is associated with the variant.
C / C++
17 The begin declare variant directive associates the context selector in the match clause
18 with each function definition in declaration-definition-seq.
19 For the purpose of call resolution, each function definition that appears between a
20 begin declare variant directive and its paired end declare variant directive is a
21 function variant for an assumed base function, with the same name and a compatible prototype, that
22 is declared elsewhere without an associated declare variant directive.
23 If a declare variant directive appears between a begin declare variant directive and its
24 paired end declare variant directive the effective context selectors of the outer directive are
25 appended to the context selector of the inner directive to form the effective context selector of the
26 inner directive. If a trait-set-selector is present on both directives, the trait-selector list of the outer
27 directive is appended to the trait-selector list of the inner directive after equivalent trait-selectors
28 have been removed from the outer list. Restrictions that apply to explicitly specified context
29 selectors also apply to effective context selectors constructed through this process.
30 The symbol name of a function definition that appears between a begin declare variant
31 directive and its paired end declare variant directive shall be determined through the base

1 language rules after the name of the function has been augmented with a string that shall be
2 determined according to the effective context selector of the begin declare variant
3 directive. The symbol names of two definitions of a function shall be equal if and only if their
4 effective context selectors are equivalent.
5 If the context selector of a begin declare variant directive contains traits in the device or
6 implementation set that are known never to be compatible with an OpenMP context during the
7 current compilation, the preprocessed code that follows the begin declare variant directive
8 up to the matching end declare variant directive shall be elided.
C / C++
9 The OpenMP context for a direct call to a given base function is defined according to Section 2.3.1.
10 If a declare variant directive for the base function is visible at the call site and the static part of the
11 context selector that is associated with the declared function variant is compatible with the
12 OpenMP context of the call according to the matching rules defined in Section 2.3.3 then the
13 variant is a replacement candidate to be called instead of the base function. Replacement
14 candidates are ordered in decreasing order of the score associated with the context selector. If two
15 replacement candidates have the same score then their order is implementation defined.
16 The list of dynamic replacement candidates is the prefix of the sorted list of replacement candidates
17 up to and including the first candidate for which the corresponding context selector is static.
18 The first dynamic replacement candidate for which the corresponding context selector is
19 compatible, according to the matching rules defined in Section 2.3.3, is called instead of the base
20 function. If no compatible candidate exists then the base function is called.
21 Expressions that appear in the context selector of a match clause are evaluated if no prior dynamic
22 replacement candidate has a compatible context selector, and the number of times each expression
23 is evaluated is implementation defined. All variables referenced by these expressions are
24 considered to be referenced at the call site.
C++
25 For calls to constexpr base functions that are evaluated in constant expressions, whether any
26 variant replacement occurs is implementation defined.
C++
27 For indirect function calls that can be determined to call a particular base function, whether any
28 variant replacement occurs is unspecified.
29 For each adjust_args clause that is present on the selected variant the adjustment operation
30 specified by adjust-op will be applied to each of the arguments specified in the clause before being
31 passed to the selected variant.
32 If the adjust-op modifier is need_device_ptr, the arguments are converted to corresponding
33 device pointers of the default device. If an argument has the is_device_ptr property in its
34 interoperability requirement set then the argument will be passed as is. Otherwise, the argument
35 will be converted in the same manner that a use_device_ptr clause on a target data
1 construct converts its pointer list items into device pointers. If the argument cannot be converted
2 into a device pointer then the NULL value will be passed as the argument.
3 If the adjust-op modifier is nothing, the argument is passed to the selected variant without being
4 modified.
5 If an append_args clause is present on the matching directive then additional arguments are
6 passed in the call. The arguments are constructed according to any specified append-op modifiers
7 and are passed in the same order in which they are specified in the append_args clause.
C / C++
8 The interop operation constructs an argument of type omp_interop_t from the
9 interoperability requirement set of the encountering task.
C / C++
Fortran
10 The interop operation constructs an argument of type omp_interop_kind from the
11 interoperability requirement set of the encountering task.
Fortran
12 The argument is constructed as if an interop construct with an init clause of interop-types was
13 specified. If the interoperability requirement set contains one or more properties that could be used
14 as clauses for an interop construct of the interop-type type, the behavior is as if the
15 corresponding clauses would also be part of the aforementioned interop construct and those
16 properties will be removed from the interoperability requirement set.
17 This argument is destroyed after the call to the selected variant returns, as if an interop construct
18 with a destroy clause was used with the same clauses that were used to initialize the argument.
19 Any differences that the specific OpenMP context requires in the prototype of the variant from the
20 base function prototype are implementation defined.
C
21 For the declare variant directive, any expressions in the match clause are interpreted as if
22 they appeared in the scope of arguments of the base function.
C
23 Different declare variant directives may be specified for different declarations of the same base
24 function.
C++
25 The function variant is determined by base language standard name lookup rules ([basic.lookup])
26 of variant-func-id using the argument types at the call site after implementation-defined changes
27 have been made according to the OpenMP context.
28 For the declare variant directive, the variant-func-id and any expressions in the match
29 clause are interpreted as if they appeared at the scope of the trailing return type of the base
30 function.
C++

C / C++
1 For the begin declare variant directive, any expressions in the match clause are
2 interpreted at the location of the directive.
C / C++
Fortran
3 The procedure to which base-proc-name refers is resolved at the location of the directive according
4 to the establishment rules for procedure names in the base language.
Fortran
5 Restrictions
6 Restrictions to the declare variant directive are as follows:
7 • Calling functions that a declare variant directive determined to be a function variant directly in
8 an OpenMP context that is different from the one that the construct selector set of the context
9 selector specifies is non-conforming.
10 • If a function is determined to be a function variant through more than one declare variant
11 directive then the construct selector set of their context selectors must be the same.
12 • A function determined to be a function variant may not be specified as a base function in another
13 declare variant directive.
14 • All variables that are referenced in an expression that appears in the context selector of a match
15 clause must be accessible at a call site to the base function according to the base language rules.
16 • At most one match clause can appear on a declare variant directive.
17 • At most one append_args clause can appear on a declare variant directive.
18 • Each argument can only appear in a single adjust_args clause for each declare variant
19 directive.
20 • An adjust_args clause or append_args clause can only be specified if the dispatch
21 selector of the construct selector set appears in the match clause.
C / C++
22 • The type of the function variant must be compatible with the type of the base function after the
23 implementation-defined transformation for its OpenMP context.
24 • Only the match clause can appear on a begin declare variant directive.
25 • The match clause of a begin declare variant directive may not contain a simd
26 trait-selector-name.
27 • Matching pairs of begin declare variant and end declare variant directives shall
28 either encompass disjoint source ranges or they shall be perfectly nested.
C / C++
C++
1 • The declare variant directive cannot be specified for a virtual, defaulted or deleted function.
2 • The declare variant directive cannot be specified for a constructor or destructor.
3 • The declare variant directive cannot be specified for an immediate function.
4 • The function that a declare variant directive determined to be a function variant may not be an
5 immediate function.
6 • A match clause that appears on a begin declare target directive must not contain a
7 dynamic context selector that references the this pointer.
8 • If an expression in the context selector that appears in a match clause references the this
9 pointer, the base function must be a non-static member function.
C++
Fortran
10 • base-proc-name must not be a generic name, an entry name, the name of a procedure pointer, a
11 dummy procedure or a statement function.
12 • If base-proc-name is omitted then the declare variant directive must appear in an interface
13 block or the specification part of a procedure.
14 • Any declare variant directive must appear in the specification part of a subroutine
15 subprogram, function subprogram, or interface body to which it applies.
16 • If the directive is specified for a procedure that is declared via a procedure declaration statement,
17 the base-proc-name must be specified.
18 • The procedure base-proc-name must have an accessible explicit interface at the location of the
19 directive.
20 • Each argument that appears in a need_device_ptr adjust-op must be of type C_PTR in the
21 dummy argument declaration.
Fortran
22 Cross References
23 • OpenMP Context Specification, see Section 2.3.1.
24 • Context Selectors, see Section 2.3.2.

1 2.3.6 dispatch Construct
2 Summary
3 The dispatch construct controls whether variant substitution occurs for a given call.
4 Syntax
C / C++
5 The syntax of the dispatch construct is as follows:
6 #pragma omp dispatch [clause[ [,] clause] ... ] new-line
7 expression-stmt
8 where expression-stmt is an expression statement with one of the following forms:

9 expression = target-call ( [expression-list] );
10 target-call ( [expression-list] );
11 and where clause is one of the following:

12 device(integer-expression)
13 depend([depend-modifier,] dependence-type : locator-list)
14 nowait
15 novariants(scalar-expression)
16 nocontext(scalar-expression)
17 is_device_ptr(list)
C / C++
Fortran
18 The syntax of the dispatch construct is as follows:
19 !$omp dispatch [clause[ [,] clause] ... ]
20 stmt
21 where stmt is an expression statement with one of the following forms:

22 expression = target-call ( [arguments] )
23 CALL target-call [ ( [arguments] )]
1 and where clause is one of the following:
2 device(scalar-integer-expression)
4 nowait
5 novariants(scalar-logical-expression)
6 nocontext(scalar-logical-expression)
Fortran
8 Binding
9 The binding task set for a dispatch region is the generating task. The dispatch region binds
10 to the region of the generating task.
11 Description
12 When a novariants clause is present on the dispatch construct, and the novariants
13 clause expression evaluates to true, no function variant will be selected for the target-call even if
14 one would be selected normally. The use of a variable in a novariants clause expression of a
15 dispatch construct causes an implicit reference to the variable in all enclosing constructs.
16 The novariants clause expression is evaluated in the enclosing context.
17 When a nocontext clause is present on the dispatch construct, and the nocontext clause
18 expression evaluates to true, the dispatch construct is not added to the construct set of the
19 OpenMP context. The use of a variable in a nocontext clause expression of a dispatch
20 construct causes an implicit reference to the variable in all enclosing constructs.
21 The nocontext clause expression is evaluated in the enclosing context.
22 The is_device_ptr clause indicates that its list items are device pointers. For each list item
23 specified in the clause, an is_device_ptr property for that list item is added to the
24 interoperability requirement set. Support for device pointers created outside of OpenMP,
25 specifically outside of any OpenMP mechanism that returns a device pointer, is implementation
26 defined.
27 If one or more depend clauses are present on the dispatch construct, they are added as depend
28 properties of the interoperability requirement set. If a nowait clause is present on the dispatch
29 construct the nowait property is added to the interoperability requirement set.
30 This construct creates an explicit task, as if the task construct was used, that surrounds the
31 associated code. Properties added to the interoperability requirement set can be removed by the
32 effect of other directives (see Section 2.15.2) before the task is created. If the interoperability
33 requirement set contains one or more depend properties, the behavior is as if those properties were
34 applied to the task construct as depend clauses. If the interoperability requirement set does not
35 contain the nowait property then the task will also be an included task.

1 If the device clause is present, the value of the default-device-var ICV of the generated task is set
2 to the value of the expression in the clause.
3 Restrictions
4 Restrictions to the dispatch construct are as follows:
5 • At most one novariants clause can appear on a dispatch directive.
6 • At most one nocontext clause can appear on a dispatch directive.
7 • At most one nowait clause can appear on a dispatch directive.
8 • A list item that appears in an is_device_ptr clause must be a valid device pointer for the
9 device data environment.
C++
10 • The target-call expression can only be a direct call.
C++
Fortran
11 • target-call must be a procedure name.
12 • target-call must not be a procedure pointer.
13 • A list item that appears in an is_device_ptr clause must be of type C_PTR.
Fortran
14 Cross References
15 • declare variant directive, see Section 2.3.5.
16 • Interoperability requirement set, see Section 2.15.2.
17 2.4 Internal Control Variables

18 An OpenMP implementation must act as if internal control variables (ICVs) control the behavior of
19 an OpenMP program. These ICVs store information such as the number of threads to use for future
20 parallel regions, the schedule to use for worksharing loops and whether nested parallelism is
21 enabled or not. The ICVs are given values at various times (described below) during the execution
22 of the program. They are initialized by the implementation itself and may be given values through
23 OpenMP environment variables and through calls to OpenMP API routines. The program can
24 retrieve the values of these ICVs only through OpenMP API routines.
25 For purposes of exposition, this document refers to the ICVs by certain names, but an
26 implementation is not required to use these names or to offer any way to access the variables other
27 than through the ways shown in Section 2.4.2.
1 2.4.1 ICV Descriptions
2 The following ICVs store values that affect the operation of parallel regions.
3 • dyn-var - controls whether dynamic adjustment of the number of threads is enabled for
4 encountered parallel regions. One copy of this ICV exists per data environment.
5 • nthreads-var - controls the number of threads requested for encountered parallel regions.
6 One copy of this ICV exists per data environment.
7 • thread-limit-var - controls the maximum number of threads that participate in the contention
8 group. One copy of this ICV exists per data environment.
9 • max-active-levels-var - controls the maximum number of nested active parallel regions
10 when the innermost parallel region is generated by a given task. One copy of this ICV exists
11 per data environment.
12 • place-partition-var - controls the place partition available to the execution environment for
13 encountered parallel regions. One copy of this ICV exists per implicit task.
14 • active-levels-var - the number of nested active parallel regions that enclose a given task such
15 that all of the parallel regions are enclosed by the outermost initial task region on the device
16 on which the task executes. One copy of this ICV exists per data environment.
17 • levels-var - the number of nested parallel regions that enclose a given task such that all of
18 the parallel regions are enclosed by the outermost initial task region on the device on which
19 the task executes. One copy of this ICV exists per data environment.
20 • bind-var - controls the binding of OpenMP threads to places. When binding is requested, the
21 variable indicates that the execution environment is advised not to move threads between places.
22 The variable can also provide default thread affinity policies. One copy of this ICV exists per
23 data environment.
24 The following ICVs store values that affect the operation of worksharing-loop regions.
25 • run-sched-var - controls the schedule that is used for worksharing-loop regions when the
26 runtime schedule kind is specified. One copy of this ICV exists per data environment.
27 • def-sched-var - controls the implementation defined default scheduling of worksharing-loop
28 regions. One copy of this ICV exists per device.
29 The following ICVs store values that affect program execution.
30 • stacksize-var - controls the stack size for threads that the OpenMP implementation creates. One
31 copy of this ICV exists per device.
32 • wait-policy-var - controls the desired behavior of waiting threads. One copy of this ICV exists
33 per device.
34 • display-affinity-var - controls whether to display thread affinity. One copy of this ICV exists for
35 the whole program.

1 • affinity-format-var - controls the thread affinity format when displaying thread affinity. One copy
2 of this ICV exists per device.
3 • cancel-var - controls the desired behavior of the cancel construct and cancellation points. One
4 copy of this ICV exists for the whole program.
5 • default-device-var - controls the default target device. One copy of this ICV exists per data
6 environment.
7 • target-offload-var - controls the offloading behavior. One copy of this ICV exists for the whole
8 program.
9 • max-task-priority-var - controls the maximum priority value that can be specified in the
10 priority clause of the task construct. One copy of this ICV exists for the whole program.
11 The following ICVs store values that affect the operation of the OMPT tool interface.
12 • tool-var - controls whether an OpenMP implementation will try to register a tool. One copy of
13 this ICV exists for the whole program.
14 • tool-libraries-var - specifies a list of absolute paths to tool libraries for OpenMP devices. One
15 copy of this ICV exists for the whole program.
16 • tool-verbose-init-var - controls whether an OpenMP implementation will verbosely log the
17 registration of a tool. One copy of this ICV exists for the whole program.
18 The following ICVs store values that affect the operation of the OMPD tool interface.
19 • debug-var - controls whether an OpenMP implementation will collect information that an
20 OMPD library can access to satisfy requests from a tool. One copy of this ICV exists for the
21 whole program.
22 The following ICVs store values that may be queried by interface routines.
23 • num-procs-var - the number of processors that are available to the device. One copy of this ICV
24 exists per device.
25 • thread-num-var - the thread number of an implicit task within its binding team. One copy of this
26 ICV exists per data environment.
27 • final-task-var - whether a given task is a final task. One copy of this ICV exists per data
28 environment.
29 • implicit-task-var - whether a given task is an implicit task. One copy of this ICV exists per data
30 environment.
31 • team-size-var - the size of the current team. One copy of this ICV exists per data environment.
32 The following ICV stores values that affect default memory allocation.
1 • def-allocator-var - controls the memory allocator to be used by memory allocation routines,
2 directives and clauses when a memory allocator is not specified by the user. One copy of this
3 ICV exists per implicit task.
4 The following ICVs store values that affect the operation of teams regions.
5 • nteams-var - controls the number of teams requested for encountered teams regions. One copy
6 of this ICV exists per device.
7 • teams-thread-limit-var - controls the maximum number of threads that participate in each
8 contention group created by a teams construct. One copy of this ICV exists per device.
9 2.4.2 ICV Initialization

10 Table 2.1 shows the ICVs, associated environment variables, and initial values.
TABLE 2.1: ICV Initial Values
ICV Environment Variable Initial value
dyn-var OMP_DYNAMIC See description below

nthreads-var OMP_NUM_THREADS Implementation defined
run-sched-var OMP_SCHEDULE Implementation defined
def-sched-var (none) Implementation defined
bind-var OMP_PROC_BIND Implementation defined
stacksize-var OMP_STACKSIZE Implementation defined
wait-policy-var OMP_WAIT_POLICY Implementation defined
thread-limit-var OMP_THREAD_LIMIT Implementation defined
max-active-levels-var OMP_MAX_ACTIVE_LEVELS, Implementation defined
OMP_NESTED,
OMP_NUM_THREADS,
OMP_PROC_BIND
active-levels-var (none) zero
levels-var (none) zero
place-partition-var OMP_PLACES Implementation defined
table continued on next page

table continued from previous page
ICV Environment Variable Initial value
cancel-var OMP_CANCELLATION false

display-affinity-var OMP_DISPLAY_AFFINITY false
affinity-format-var OMP_AFFINITY_FORMAT Implementation defined
default-device-var OMP_DEFAULT_DEVICE Implementation defined
target-offload-var OMP_TARGET_OFFLOAD DEFAULT
max-task-priority-var OMP_MAX_TASK_PRIORITY zero
tool-var OMP_TOOL enabled
tool-libraries-var OMP_TOOL_LIBRARIES empty string
tool-verbose-init-var OMP_TOOL_VERBOSE_INIT disabled
debug-var OMP_DEBUG disabled
num-procs-var (none) Implementation defined
thread-num-var (none) zero
final-task-var (none) false
implicit-task-var (none) true
team-size-var (none) one
def-allocator-var OMP_ALLOCATOR Implementation defined
nteams-var OMP_NUM_TEAMS zero
teams-thread-limit-var OMP_TEAMS_THREAD_LIMIT zero
1 Each ICV that does not have global scope (see Table 2.3) has a set of device-specific environment
2 variables that extend the variables defined in Table 2.1 with the following syntax:
3 <ENVIRONMENT VARIABLE>_DEV[_<device>]
4 where <ENVIRONMENT VARIABLE> is one of the variables from Table 2.1 and <device> is the
5 device number as specified in the device clause (see Section 2.14).
6 Description
7 • Each device has its own ICVs.
8 • The initial value of dyn-var is implementation defined if the implementation supports dynamic
9 adjustment of the number of threads; otherwise, the initial value is false.
1 • The value of the nthreads-var ICV is a list.
2 • The value of the bind-var ICV is a list.
3 The host and non-host device ICVs are initialized before any OpenMP API construct or OpenMP
4 API routine executes. After the initial values are assigned, the values of any OpenMP environment
5 variables that were set by the user are read and the associated ICVs are modified accordingly. If no
6 <device> number is specified on the device-specific environment variable then the value is applied
7 to all non-host devices.
8 Cross References
9 • OMP_SCHEDULE environment variable, see Section 6.1.
10 • OMP_NUM_THREADS environment variable, see Section 6.2.
11 • OMP_DYNAMIC environment variable, see Section 6.3.
12 • OMP_PROC_BIND environment variable, see Section 6.4.
13 • OMP_PLACES environment variable, see Section 6.5.
14 • OMP_STACKSIZE environment variable, see Section 6.6.
15 • OMP_WAIT_POLICY environment variable, see Section 6.7.
16 • OMP_MAX_ACTIVE_LEVELS environment variable, see Section 6.8.
17 • OMP_NESTED environment variable, see Section 6.9.
18 • OMP_THREAD_LIMIT environment variable, see Section 6.10.
19 • OMP_CANCELLATION environment variable, see Section 6.11.
20 • OMP_DISPLAY_AFFINITY environment variable, see Section 6.13.
21 • OMP_AFFINITY_FORMAT environment variable, see Section 6.14.
22 • OMP_DEFAULT_DEVICE environment variable, see Section 6.15.
23 • OMP_MAX_TASK_PRIORITY environment variable, see Section 6.16.
24 • OMP_TARGET_OFFLOAD environment variable, see Section 6.17.
25 • OMP_TOOL environment variable, see Section 6.18.
26 • OMP_TOOL_LIBRARIES environment variable, see Section 6.19.
27 • OMP_DEBUG environment variable, see Section 6.21.
28 • OMP_ALLOCATOR environment variable, see Section 6.22.
29 • OMP_NUM_TEAMS environment variable, see Section 6.23.
30 • OMP_TEAMS_THREAD_LIMIT environment variable, see Section 6.24.

1 2.4.3 Modifying and Retrieving ICV Values
2 Table 2.2 shows the method for modifying and retrieving the values of ICVs through OpenMP API
3 routines. If an ICV is not listed in this table, no OpenMP API routine modifies or retrieves this ICV.
TABLE 2.2: Ways to Modify and to Retrieve ICV Values
ICV Ways to Modify Value Ways to Retrieve Value
dyn-var omp_set_dynamic omp_get_dynamic

nthreads-var omp_set_num_threads omp_get_max_threads
run-sched-var omp_set_schedule omp_get_schedule
bind-var (none) omp_get_proc_bind
thread-limit-var target construct, teams construct omp_get_thread_limit
max-active-levels-var omp_set_max_active_levels, omp_get_max_active_levels
omp_set_nested
active-levels-var (none) omp_get_active_level
levels-var (none) omp_get_level
place-partition-var (none) See description below
cancel-var (none) omp_get_cancellation
affinity-format-var omp_set_affinity_format omp_get_affinity_format
default-device-var omp_set_default_device omp_get_default_device
max-task-priority-var (none) omp_get_max_task_priority
num-procs-var (none) omp_get_num_procs
thread-num-var (none) omp_get_thread_num
final-task-var (none) omp_in_final
team-size-var (none) omp_get_num_threads
def-allocator-var omp_set_default_allocator omp_get_default_allocator
nteams-var omp_set_num_teams omp_get_max_teams
teams-thread-limit-var omp_set_teams_thread_limit omp_get_teams_thread_limit
4 Description
5 • The value of the nthreads-var ICV is a list. The runtime call omp_set_num_threads sets
6 the value of the first element of this list, and omp_get_max_threads retrieves the value of
7 the first element of this list.
1 • The value of the bind-var ICV is a list. The runtime call omp_get_proc_bind retrieves the
2 value of the first element of this list.
3 • Detailed values in the place-partition-var ICV are retrieved using the runtime calls
4 omp_get_partition_num_places, omp_get_partition_place_nums,
5 omp_get_place_num_procs, and omp_get_place_proc_ids.
6 Cross References
7 • thread_limit clause of the teams construct, see Section 2.7.
8 • thread_limit clause of the target construct, see Section 2.14.5.
9 • omp_set_num_threads routine, see Section 3.2.1.
10 • omp_get_num_threads routine, see Section 3.2.2.
11 • omp_get_max_threads routine, see Section 3.2.3.
12 • omp_get_thread_num routine, see Section 3.2.4.
13 • omp_set_dynamic routine, see Section 3.2.6.
14 • omp_get_dynamic routine, see Section 3.2.7.
15 • omp_get_cancellation routine, see Section 3.2.8.
16 • omp_set_nested routine, see Section 3.2.9.
17 • omp_set_schedule routine, see Section 3.2.11.
18 • omp_get_schedule routine, see Section 3.2.12.
19 • omp_get_thread_limit routine, see Section 3.2.13.
20 • omp_get_supported_active_levels, see Section 3.2.14.
21 • omp_set_max_active_levels routine, see Section 3.2.15.
22 • omp_get_max_active_levels routine, see Section 3.2.16.
23 • omp_get_level routine, see Section 3.2.17.
24 • omp_get_active_level routine, see Section 3.2.20.
25 • omp_get_proc_bind routine, see Section 3.3.1.
26 • omp_get_place_num_procs routine, see Section 3.3.3.
27 • omp_get_place_proc_ids routine, see Section 3.3.4.
28 • omp_get_partition_num_places routine, see Section 3.3.6.
29 • omp_get_partition_place_nums routine, see Section 3.3.7.
30 • omp_set_affinity_format routine, see Section 3.3.8.

1 • omp_get_affinity_format routine, see Section 3.3.9.
2 • omp_set_num_teams routine, see Section 3.4.3.
3 • omp_get_max_teams routine, see Section 3.4.4.
4 • omp_set_teams_thread_limit routine, see Section 3.4.5.
5 • omp_get_teams_thread_limit routine, see Section 3.4.6.
6 • omp_get_max_task_priority routine, see Section 3.5.1.
7 • omp_in_final routine, see Section 3.5.2.
8 • omp_get_num_procs routine, see Section 3.7.1.
9 • omp_set_default_device routine, see Section 3.7.2.
10 • omp_get_default_device routine, see Section 3.7.3.
11 • omp_set_default_allocator routine, see Section 3.13.4.
12 • omp_get_default_allocator routine, see Section 3.13.5.
13 2.4.4 How ICVs are Scoped

14 Table 2.3 shows the ICVs and their scope.
TABLE 2.3: Scopes of ICVs
ICV Scope
dyn-var data environment

nthreads-var data environment
run-sched-var data environment
def-sched-var device
bind-var data environment
stacksize-var device
wait-policy-var device
thread-limit-var data environment
max-active-levels-var data environment
ICV Scope
active-levels-var data environment

levels-var data environment
place-partition-var implicit task
cancel-var global
display-affinity-var global
affinity-format-var device
default-device-var data environment
target-offload-var global
max-task-priority-var global
tool-var global
tool-libraries-var global
tool-verbose-init-var global
debug-var global
num-procs-var device
thread-num-var implicit task
final-task-var data environment
implicit-task-var data environment
team-size-var team
def-allocator-var implicit task
nteams-var device
teams-thread-limit-var device
1 Description
2 • One copy of each ICV with device scope exists per device.
3 • Each data environment has its own copies of ICVs with data environment scope.
4 • Each implicit task has its own copy of ICVs with implicit task scope.
5 Calls to OpenMP API routines retrieve or modify data environment scoped ICVs in the data
6 environment of their binding tasks.

1 2.4.4.1 How the Per-Data Environment ICVs Work
2 When a task construct, a parallel construct or a teams construct is encountered, each
3 generated task inherits the values of the data environment scoped ICVs from each generating task’s
4 ICV values.
5 When a parallel construct is encountered, the value of each ICV with implicit task scope is
6 inherited from the implicit binding task of the generating task unless otherwise specified.
7 When a task construct is encountered, the generated task inherits the value of nthreads-var from
8 the generating task’s nthreads-var value. When a parallel construct is encountered, and the
9 generating task’s nthreads-var list contains a single element, the generated implicit tasks inherit
10 that list as the value of nthreads-var. When a parallel construct is encountered, and the
11 generating task’s nthreads-var list contains multiple elements, the generated implicit tasks inherit
12 the value of nthreads-var as the list obtained by deletion of the first element from the generating
13 task’s nthreads-var value. The bind-var ICV is handled in the same way as the nthreads-var ICV.
14 When a target task executes an active target region, the generated initial task uses the values of
15 the data environment scoped ICVs from the device data environment ICV values of the device that
16 will execute the region.
17 When a target task executes an inactive target region, the generated initial task uses the values
18 of the data environment scoped ICVs from the data environment of the task that encountered the
19 target construct.
20 If a target construct with a thread_limit clause is encountered, the thread-limit-var ICV
21 from the data environment of the generated initial task is instead set to an implementation defined
22 value between one and the value specified in the clause.
23 If a target construct with no thread_limit clause is encountered, the thread-limit-var ICV
24 from the data environment of the generated initial task is set to an implementation defined value
25 that is greater than zero.
26 If a teams construct with a thread_limit clause is encountered, the thread-limit-var ICV
27 from the data environment of the initial task for each team is instead set to an implementation
28 defined value between one and the value specified in the clause.
29 If a teams construct with no thread_limit clause is encountered, the thread-limit-var ICV
30 from the data environment of the initial task of each team is set to an implementation defined value
31 that is greater than zero and does not exceed teams-thread-limit-var, if teams-thread-limit-var is
32 greater than zero.
33 When encountering a worksharing-loop region for which the runtime schedule kind is specified,
34 all implicit task regions that constitute the binding parallel region must have the same value for
35 run-sched-var in their data environments. Otherwise, the behavior is unspecified.
1 2.4.5 ICV Override Relationships
2 Table 2.4 shows the override relationships among construct clauses and ICVs. The table only lists
3 ICVs that can be overwritten by a clause.
TABLE 2.4: ICV Override Relationships
ICV construct clause, if used
nthreads-var num_threads
run-sched-var schedule
def-sched-var schedule
bind-var proc_bind
def-allocator-var allocator
nteams-var num_teams
teams-thread-limit-var thread_limit
4 Description
5 • The num_threads clause overrides the value of the first element of the nthreads-var ICV.
6 • If a schedule clause specifies a modifier then that modifier overrides any modifier that is
7 specified in the run-sched-var ICV.
8 • If bind-var is not set to false then the proc_bind clause overrides the value of the first element
9 of the bind-var ICV; otherwise, the proc_bind clause has no effect.
10 Cross References
11 • parallel construct, see Section 2.6.
12 • proc_bind clause, Section 2.6.
13 • num_threads clause, see Section 2.6.1.
14 • num_teams clause, see Section 2.7.
15 • thread_limit clause, see Section 2.7.
16 • Worksharing-loop construct, see Section 2.11.4.
17 • schedule clause, see Section 2.11.4.1.

1 2.5 Informational and Utility Directives
2 This section covers all directives that may function as an informational directive or a utility
3 directive in an OpenMP program.
4 2.5.1 requires Directive

5 Summary
6 The requires directive specifies the features that an implementation must provide in order for the
7 code to compile and to execute correctly. The requires directive is an informational directive.
8 Syntax
C / C++
9 The syntax of the requires directive is as follows:
10 #pragma omp requires clause[ [ [,] clause] ... ] new-line
11 where clause is either a clause of the form ext_implementation-defined-requirement for an

12 implementation defined requirement clause or one of the requirement clauses listed below:
13 reverse_offload
14 unified_address
15 unified_shared_memory
16 atomic_default_mem_order(seq_cst | acq_rel | relaxed)
17 dynamic_allocators
C / C++
Fortran
18 The syntax of the requires directive is as follows:
19 !$omp requires clause[ [ [,] clause] ... ]
20 where clause is either a clause of the form ext_implementation-defined-requirement for an

21 implementation defined requirement clause or one of the requirement clauses listed below:
22 reverse_offload
23 unified_address
24 unified_shared_memory
25 atomic_default_mem_order(seq_cst | acq_rel | relaxed)
26 dynamic_allocators
Fortran
1 Description
2 The requires directive specifies features that an implementation must support for correct
3 execution. The behavior that a requirement clause specifies may override the normal behavior
4 specified elsewhere in this document. Whether an implementation supports the feature that a given
5 requirement clause specifies is implementation defined.
6 The requires directive specifies requirements for the execution of all code in the current
7 compilation unit.
8
9 Note – Use of this directive makes your code less portable. Users should be aware that not all
10 devices or implementations support all requirements.
11
12 When the reverse_offload clause appears on a requires directive, the implementation

13 guarantees that a target region, for which the target construct specifies a device clause in
14 which the ancestor modifier appears, can execute on the parent device of an enclosing target
15 region.
16 When the unified_address clause appears on a requires directive, the implementation
17 guarantees that all devices accessible through OpenMP API routines and directives use a unified
18 address space. In this address space, a pointer will always refer to the same location in memory
19 from all devices accessible through OpenMP. Any OpenMP mechanism that returns a device
20 pointer is guaranteed to return a device address that supports pointer arithmetic, and the
21 is_device_ptr clause is not necessary to obtain device addresses from device pointers for use
22 inside target regions. Host pointers may be passed as device pointer arguments to device
23 memory routines and device pointers may be passed as host pointer arguments to device memory
24 routines. Non-host devices may still have discrete memories and dereferencing a device pointer on
25 the host device or a host pointer on a non-host device remains unspecified behavior.
C / C++
26 When the unified_address clause appears on a requires directive, the base pointer of a
27 zero-length array section that is mapped on a target construct and for which a matching mapped
28 list item cannot be found is not initialized to NULL but instead retains its original value.
C / C++
29 Memory local to a specific execution context may be exempt from the unified_address
30 requirement, following the restrictions of locality to a given execution context, thread or contention
31 group.
32 The unified_shared_memory clause implies the unified_address requirement,
33 inheriting all of its behaviors. Additionally, storage locations in memory are accessible to threads
34 on all available devices that are supported by the implementation, except for memory that is local to
35 a specific execution context as defined in the description of unified_address above. Every
36 device address that refers to storage allocated through OpenMP device memory routines is a valid
37 host pointer that may be dereferenced.

1 The unified_shared_memory clause makes the map clause optional on target constructs
2 and the declare target directive optional for variables with static storage duration that are accessed
3 inside functions to which a declare target directive is applied. Scalar variables are still firstprivate
4 by default when referenced inside target constructs. Values stored into memory by one device
5 may not be visible to another device until those two devices synchronize with each other or both
6 devices synchronize with the host.
7 The atomic_default_mem_order clause specifies the default memory ordering behavior for
8 atomic constructs that must be provided by an implementation. Its parameter appears as a clause
9 on any atomic construct that does not already specify a memory order clause.
10 The dynamic_allocators clause removes certain restrictions on the use of memory allocators
11 in target regions. It makes the uses_allocators clause optional on target constructs for
12 the purpose of using allocators in the corresponding target regions. It allows calls to the
13 omp_init_allocator and omp_destroy_allocator API routines in target regions.
14 Finally, it allows default allocators to be used by allocate directives, allocate clauses, and
15 omp_alloc API routines in target regions.
16 Implementers are allowed to include additional implementation-defined requirement clauses. All
17 implementation defined requirements should begin with ext_. Requirement names that do not
18 start with ext_ are reserved.
19 The clauses of a requires directive are added to the requires trait in the OpenMP context for all
20 program points that follow the directive.
21 Restrictions
22 The restrictions to the requires directive are as follows:
23 • Each of the clauses can appear at most once on the directive.
24 • All atomic_default_mem_order clauses that appear on a requires directive in the
25 same compilation unit must specify the same parameter.
26 • A requires directive with a unified_address, unified_shared_memory, or
27 reverse_offload clause must appear lexically before any device constructs or device
28 routines.
29 • A requires directive may not appear lexically after a context selector in which any clause of
30 the requires directive is used.
31 • A requires directive with any of the following clauses must appear in all compilation units of
32 a program that contain device constructs or device routines or in none of them:
33 – reverse_offload
34 – unified_address
35 – unified_shared_memory
1 • The requires directive with atomic_default_mem_order clause may not appear
2 lexically after any atomic construct on which memory-order-clause is not specified.
C
3 • The requires directive may only appear at file scope.
C
C++
4 • The requires directive may only appear at file or namespace scope.
C++
Fortran
5 • The requires directive must appear in the specification part of a program unit, after any USE
6 statement, any IMPORT statement, and any IMPLICIT statement, unless the directive appears
7 by referencing a module and each clause already appeared with the same parameters in the
8 specification part of the program unit.
Fortran
9 2.5.2 Assume Directive

10 Summary
11 The assume directive provides invariants to the implementation that may be used for optimization
12 purposes. If the invariants do not hold at runtime, the behavior is unspecified. The assume directive
13 is an informational directive.
14 Syntax
C / C++
15 The syntax of the assume directive is as follows:
16 #pragma omp assumes clause[ [ [,] clause] ... ] new-line
17 or
18 #pragma omp begin assumes clause[ [ [,] clause] ... ] new-line
20 #pragma omp end assumes new-line
21 or
22 #pragma omp assume clause[ [ [,] clause] ... ] new-line
23 structured-block
24 where clause is either assumption-clause or a clause of the form

25 ext_implementation-defined-assumption for an implementation-defined assumption clause, and
26 where assumption-clause is one of the following:

1 absent(directive-name [[, directive-name]...])
2 contains(directive-name [[, directive-name]...])
3 holds(scalar-expression)
4 no_openmp
5 no_openmp_routines
6 no_parallelism
C / C++
Fortran
7 The syntax of the assume directive is as follows:
8 !$omp assumes clause[ [ [,] clause] ... ]
9 or
10 !$omp assume clause[ [ [,] clause] ... ]
11 loosely-structured-block
12 !$omp end assume
13 or
14 !$omp assume clause[ [ [,] clause] ... ]
15 strictly-structured-block
16 [!$omp end assume]
17 where clause is either assumption-clause or a clause of the form

18 ext_implementation-defined-assumption for an implementation-defined assumption clause,
19 where assumption-clause is one of the following:
20 absent(directive-name [[, directive-name]...])
21 contains(directive-name [[, directive-name]...])
22 holds(scalar-logical-expression)
23 no_openmp
24 no_openmp_routines
25 no_parallelism
Fortran
1 Description
2 The assume directive gives the implementation additional information about the expected
3 properties of the program that can optionally be used to optimize the implementation. An
4 implementation may ignore this information without altering the behavior of the program.
5 The scope of the assumes directive is the code executed and reached from the current compilation
6 unit. The scope of the assume directive is the code executed in the corresponding region or in any
7 region that is nested in the corresponding region.
C / C++
8 The scope of the begin assumes directive is the code that is executed and reached from any of
9 the declared functions in declaration-definition-seq.
C / C++
10 The absent and contains clauses accept a list of one or more directive names that may match
11 a construct that is encountered within the scope of the directive. An encountered construct matches
12 the directive name if it has the same name as one of the specified directive names or if it is a
13 combined or composite construct for which a constituent construct has the same name as one of the
14 specified directive names.
15 When the absent clause appears on an assume directive, the application guarantees that no
16 constructs that match a listed directive name are encountered in the scope of the assume directive.
17 When the contains clause appears on an assume directive, the application provides a hint that
18 constructs that match the listed directive names are likely to be encountered in the scope of the
19 assume directive.
20 When the holds clause appears on an assume directive, the application guarantees that the listed
21 expression evaluates to true in the scope of the directive. The effect of the clause does not include
22 an evaluation of the expression that is observable.
23 The no_openmp clause guarantees that no OpenMP related code is executed in the scope of the
24 directive.
25 The no_openmp_routines clause guarantees that no explicit OpenMP runtime library calls are
26 executed in the scope of the directive.
27 The no_parallelism clause guarantees that no OpenMP tasks (explicit or implicit) will be
28 generated and that no SIMD constructs will be executed in the scope of the directive.
29 Implementers are allowed to include additional implementation-defined assumption clauses. All
30 implementation-defined assumptions should begin with ext_. Assumption names that do not start
31 with ext_ are reserved.

1 Restrictions
2 The restrictions to the assume directive are as follows:
3 • Each clause except the absent, contains or holds clause can appear at most once on the
4 directive.
5 • Each directive-name listed in the clauses can appear at most once on the directive.
6 • A directive-name that appears in an absent or contains clause may not be a combined or
7 composite directive name.
8 • A directive-name that appears in an absent or contains clause may not be a directive that is
9 not associated with the execution of user or implementation code, i.e., a nothing directive, a
10 declarative directive, a metadirective, or a loop transformation directive.
C
11 • The assumes directive may only appear at file scope.
C
C++
12 • The assumes directive may only appear at file or namespace scope.
C++
Fortran
13 • The assumes directive may only appear in the specification part of a module or subprogram,
14 after any USE statement, any IMPORT statement, and any IMPLICIT statement.
Fortran
15 2.5.3 nothing Directive

16 Summary
17 The nothing directive has no effect. It can be used in a metadirective and other contexts to
18 indicate explicitly that the intent is to have no effect on the execution of the OpenMP program. The
19 nothing directive is a utility directive.
20 Syntax
C / C++
21 The syntax of the nothing directive is as follows:
22 #pragma omp nothing new-line
C / C++
Fortran
23 The syntax of the nothing directive is as follows:
24 !$omp nothing
Fortran
1 Description
2 The nothing directive has no effect on the execution of the OpenMP program.
3 Cross References
4 • Metadirectives, see Section 2.3.4.
5 2.5.4 error Directive

6 Summary
7 The error directive instructs the compiler or runtime to display a message and to perform an error
8 action. The error directive is a utility directive unless the at clause is specified with the
9 execution value, in which case the error directive is a stand-alone directive.
10 Syntax
C / C++
11 The syntax of the error directive is as follows:
12 #pragma omp error [clause[ [,] clause] ... ] new-line

14 at(compilation | execution)
15 severity(fatal | warning)
16 message(msg-string)
17 where msg-string is a string of const char * type.

C / C++
Fortran
18 The syntax of the error directive is as follows:
19 !$omp error [clause[ [,] clause] ... ]

21 at(compilation | execution)
22 severity(fatal | warning)
23 message(msg-string)
24 where msg-string is a character string of character(len=*) type

Fortran

1 Description
2 The error directive performs an error action. The error action includes the display of an
3 implementation defined message. The severity clause determines whether the error action
4 includes anything other than the message display.
5 The at clause determines when the implementation performs the error action. When the at clause
6 specifies compilation, the error action is performed during compilation if the error directive
7 appears in a declarative context or in an executable context that is reachable at runtime. When the
8 at clause specifies compilation and the error directive appears in an executable context that
9 is not reachable at runtime, the error action may or may not be performed. When the at clause
10 specifies execution, the error action is performed during program execution when a thread
11 encounters the directive. If the at clause is not specified then the error directive behaves as if the
12 at clause specifies compilation.
13 The severity clause determines the action that the implementation performs. When the
14 severity clause specifies warning, the implementation takes no action besides displaying the
15 message. When the severity clause specifies fatal and the at clause specifies compile
16 then the message is displayed and compilation of the current compilation unit is aborted. When the
17 severity clause specifies fatal and the at clause specifies execution then the message is
18 displayed and program execution is aborted. If no severity clause is specified then the error
19 directive behaves as if the severity clause specifies fatal.
20 If the message clause is specified then msg-string is included in the implementation defined
21 message.
22 Execution Model Events

23 The runtime-error event occurs when a thread encounters an error directive for which the at
24 clause specifies execution.
25 Tool Callbacks
26 A thread dispatches a registered ompt_callback_error callback for each occurrence of a
27 runtime-error event in the context of the encountering task. This callback has the type signature
28 ompt_callback_error_t.
29 Restrictions
30 Restrictions to the error directive are as follows:
31 • At most one at clause can appear on the directive.
32 • At most one severity clause can appear on the directive.
33 • At most one message clause can appear on the directive.
34 Cross References
35 • Stand-alone directives, see Section 2.1.3.
36 • ompt_callback_error_t, see Section 4.5.2.30.
1 2.6 parallel Construct
2 Summary
3 The parallel construct creates a team of OpenMP threads that execute the region.
4 Syntax
C / C++
5 The syntax of the parallel construct is as follows:
6 #pragma omp parallel [clause[ [,] clause] ... ] new-line
7 structured-block

9 if([ parallel :] scalar-expression)
10 num_threads(integer-expression)
11 default(data-sharing-attribute)
12 private(list)
13 firstprivate(list)
14 shared(list)
15 copyin(list)
16 reduction([reduction-modifier ,] reduction-identifier : list)
17 proc_bind(affinity-policy)
18 allocate([allocator :] list)
19 where affinity-policy is one of the following:

20 primary
21 master [deprecated]
22 close
23 spread
C / C++
Fortran
24 The syntax of the parallel construct is as follows:
25 !$omp parallel [clause[ [,] clause] ... ]
27 !$omp end parallel

1 or
2 !$omp parallel [clause[ [,] clause] ... ]
4 [!$omp end parallel]

6 if([ parallel :] scalar-logical-expression)
7 num_threads(scalar-integer-expression)
9 private(list)
11 shared(list)
12 copyin(list)
14 proc_bind(affinity-policy)
16 where affinity-policy is one of the following:

17 primary
18 master [deprecated]
19 close
20 spread
Fortran
21 Binding
22 The binding thread set for a parallel region is the encountering thread. The encountering thread
23 becomes the primary thread of the new team.
24 Description
25 When a thread encounters a parallel construct, a team of threads is created to execute the
26 parallel region (see Section 2.6.1 for more information about how the number of threads in the
27 team is determined, including the evaluation of the if and num_threads clauses). The thread
28 that encountered the parallel construct becomes the primary thread of the new team, with a
29 thread number of zero for the duration of the new parallel region. All threads in the new team,
30 including the primary thread, execute the region. Once the team is created, the number of threads in
31 the team remains constant for the duration of that parallel region.
1 The optional proc_bind clause, described in Section 2.6.2, specifies the mapping of OpenMP
2 threads to places within the current place partition, that is, within the places listed in the
3 place-partition-var ICV for the implicit task of the encountering thread.
4 Within a parallel region, thread numbers uniquely identify each thread. Thread numbers are
5 consecutive whole numbers ranging from zero for the primary thread up to one less than the
6 number of threads in the team. A thread may obtain its own thread number by a call to the
7 omp_get_thread_num library routine.
8 A set of implicit tasks, equal in number to the number of threads in the team, is generated by the
9 encountering thread. The structured block of the parallel construct determines the code that
10 will be executed in each implicit task. Each task is assigned to a different thread in the team and
11 becomes tied. The task region of the task that the encountering thread is executing is suspended and
12 each thread in the team executes its implicit task. Each thread can execute a path of statements that
13 is different from that of the other threads.
14 The implementation may cause any thread to suspend execution of its implicit task at a task
15 scheduling point, and to switch to execution of any explicit task generated by any of the threads in
16 the team, before eventually resuming execution of the implicit task (for more details see
17 Section 2.12).
18 An implicit barrier occurs at the end of a parallel region. After the end of a parallel region,
19 only the primary thread of the team resumes execution of the enclosing task region.
20 If a thread in a team that is executing a parallel region encounters another parallel
21 directive, it creates a new team, according to the rules in Section 2.6.1, and it becomes the primary
22 thread of that new team.
23 If execution of a thread terminates while inside a parallel region, execution of all threads in all
24 teams terminates. The order of termination of threads is unspecified. All work done by a team prior
25 to any barrier that the team has passed in the program is guaranteed to be complete. The amount of
26 work done by each thread after the last barrier that it passed and before it terminates is unspecified.

28 The parallel-begin event occurs in a thread that encounters a parallel construct before any
29 implicit task is created for the corresponding parallel region.
30 Upon creation of each implicit task, an implicit-task-begin event occurs in the thread that executes
31 the implicit task after the implicit task is fully initialized but before the thread begins to execute the
32 structured block of the parallel construct.
33 If the parallel region creates a native thread, a native-thread-begin event occurs as the first
34 event in the context of the new thread prior to the implicit-task-begin event.
35 Events associated with implicit barriers occur at the end of a parallel region. Section 2.19.3
36 describes events associated with implicit barriers.
37 When a thread finishes an implicit task, an implicit-task-end event occurs in the thread after events
38 associated with implicit barrier synchronization in the implicit task.

1 The parallel-end event occurs in the thread that encounters the parallel construct after the
2 thread executes its implicit-task-end event but before the thread resumes execution of the
3 encountering task.
4 If a native thread is destroyed at the end of a parallel region, a native-thread-end event occurs
5 in the thread as the last event prior to destruction of the thread.
6 Tool Callbacks
7 A thread dispatches a registered ompt_callback_parallel_begin callback for each
8 occurrence of a parallel-begin event in that thread. The callback occurs in the task that encounters
9 the parallel construct. This callback has the type signature
10 ompt_callback_parallel_begin_t. In the dispatched callback,
11 (flags & ompt_parallel_team) evaluates to true.
12 A thread dispatches a registered ompt_callback_implicit_task callback with
13 ompt_scope_begin as its endpoint argument for each occurrence of an implicit-task-begin
14 event in that thread. Similarly, a thread dispatches a registered
15 ompt_callback_implicit_task callback with ompt_scope_end as its endpoint
16 argument for each occurrence of an implicit-task-end event in that thread. The callbacks occur in
17 the context of the implicit task and have type signature ompt_callback_implicit_task_t.
18 In the dispatched callback, (flags & ompt_task_implicit) evaluates to true.
19 A thread dispatches a registered ompt_callback_parallel_end callback for each
20 occurrence of a parallel-end event in that thread. The callback occurs in the task that encounters
21 the parallel construct. This callback has the type signature
22 ompt_callback_parallel_end_t.
23 A thread dispatches a registered ompt_callback_thread_begin callback for the
24 native-thread-begin event in that thread. The callback occurs in the context of the thread. The
25 callback has type signature ompt_callback_thread_begin_t.
26 A thread dispatches a registered ompt_callback_thread_end callback for the
27 native-thread-end event in that thread. The callback occurs in the context of the thread. The
28 callback has type signature ompt_callback_thread_end_t.
29 Restrictions
30 Restrictions to the parallel construct are as follows:
31 • A program must not depend on any ordering of the evaluations of the clauses of the parallel
32 directive, or on any side effects of the evaluations of the clauses.
33 • At most one if clause can appear on the directive.
34 • At most one proc_bind clause can appear on the directive.
35 • At most one num_threads clause can appear on the directive. The num_threads
36 expression must evaluate to a positive integer value.
C++
1 • A throw executed inside a parallel region must cause execution to resume within the same
2 parallel region, and the same thread that threw the exception must catch it.
C++
3 Cross References
4 • OpenMP execution model, see Section 1.3.
5 • num_threads clause, see Section 2.6.
6 • proc_bind clause, see Section 2.6.2.
7 • allocate clause, see Section 2.13.4.
8 • if clause, see Section 2.18.
9 • default, shared, private, firstprivate, and reduction clauses, see
10 Section 2.21.4.
11 • copyin clause, see Section 2.21.6.
13 • ompt_scope_begin and ompt_scope_end, see Section 4.4.4.11.
14 • ompt_callback_thread_begin_t, see Section 4.5.2.1.
15 • ompt_callback_thread_end_t, see Section 4.5.2.2.
16 • ompt_callback_parallel_begin_t, see Section 4.5.2.3.
17 • ompt_callback_parallel_end_t, see Section 4.5.2.4.
18 • ompt_callback_implicit_task_t, see Section 4.5.2.11.
19 2.6.1 Determining the Number of Threads for a parallel

20 Region
21 When execution encounters a parallel directive, the value of the if clause or num_threads
22 clause (if any) on the directive, the current parallel context, and the values of the nthreads-var,
23 dyn-var, thread-limit-var, and max-active-levels-var ICVs are used to determine the number of
24 threads to use in the region.
25 Using a variable in an if or num_threads clause expression of a parallel construct causes
26 an implicit reference to the variable in all enclosing constructs. The if clause expression and the
27 num_threads clause expression are evaluated in the context outside of the parallel construct,
28 and no ordering of those evaluations is specified. In what order or how many times any side effects
29 of the evaluation of the num_threads or if clause expressions occur is also unspecified.

1 When a thread encounters a parallel construct, the number of threads is determined according
2 to Algorithm 2.1.
3
4
5
Algorithm 2.1
6 let ThreadsBusy be the number of OpenMP threads currently executing in this contention group;
7 if an if clause exists
8 then let IfClauseValue be the value of the if clause expression;
9 else let IfClauseValue = true;
10 if a num_threads clause exists
11 then let ThreadsRequested be the value of the num_threads clause expression;
12 else let ThreadsRequested = value of the first element of nthreads-var;
13 let ThreadsAvailable = (thread-limit-var - ThreadsBusy + 1);
14 if (IfClauseValue = false)
15 then number of threads = 1;
16 else if (active-levels-var ≥ max-active-levels-var)
17 then number of threads = 1;
18 else if (dyn-var = true) and (ThreadsRequested ≤ ThreadsAvailable)
19 then 1 ≤ number of threads ≤ ThreadsRequested;
20 else if (dyn-var = true) and (ThreadsRequested > ThreadsAvailable)
21 then 1 ≤ number of threads ≤ ThreadsAvailable;
22 else if (dyn-var = false) and (ThreadsRequested ≤ ThreadsAvailable)
23 then number of threads = ThreadsRequested;
24 else if (dyn-var = false) and (ThreadsRequested > ThreadsAvailable)
25 then behavior is implementation defined;
26
27
1
2 Note – Since the initial value of the dyn-var ICV is implementation defined, programs that depend
3 on a specific number of threads for correct execution should explicitly disable dynamic adjustment
4 of the number of threads.
5
6 Cross References
7 • nthreads-var, dyn-var, thread-limit-var, and max-active-levels-var ICVs, see Section 2.4.
11 2.6.2 Controlling OpenMP Thread Affinity

12 When a thread encounters a parallel directive without a proc_bind clause, the bind-var ICV
13 is used to determine the policy for assigning OpenMP threads to places within the current place
14 partition, that is, within the places listed in the place-partition-var ICV for the implicit task of the
15 encountering thread. If the parallel directive has a proc_bind clause then the binding policy
16 specified by the proc_bind clause overrides the policy specified by the first element of the
17 bind-var ICV. Once a thread in the team is assigned to a place, the OpenMP implementation should
18 not move it to another place.
19 The primary thread affinity policy instructs the execution environment to assign every thread in
20 the team to the same place as the primary thread. The place partition is not changed by this policy,
21 and each implicit task inherits the place-partition-var ICV of the parent implicit task. The master
22 thread-affinity policy, which has been deprecated, has identical semantics to the primary thread
23 affinity policy.
24 The close thread affinity policy instructs the execution environment to assign the threads in the
25 team to places close to the place of the parent thread. The place partition is not changed by this
26 policy, and each implicit task inherits the place-partition-var ICV of the parent implicit task. If T
27 is the number of threads in the team, and P is the number of places in the parent’s place partition,
28 then the assignment of threads in the team to places is as follows:
29 • T ≤ P : The primary thread executes on the place of the parent thread. The thread with the next
30 smallest thread number executes on the next place in the place partition, and so on, with wrap
31 around with respect to the place partition of the primary thread.
32 • T > P : Each place p will contain Sp threads with consecutive thread numbers where
33 bT /P c ≤ Sp ≤ dT /P e. The first S0 threads (including the primary thread) are assigned to the
34 place of the parent thread. The next S1 threads are assigned to the next place in the place
35 partition, and so on, with wrap around with respect to the place partition of the primary thread.

1 When P does not divide T evenly, the exact number of threads in a particular place is
2 implementation defined.
3 The purpose of the spread thread affinity policy is to create a sparse distribution for a team of T
4 threads among the P places of the parent’s place partition. A sparse distribution is achieved by first
5 subdividing the parent partition into T subpartitions if T ≤ P , or P subpartitions if T > P . Then
6 one thread (T ≤ P ) or a set of threads (T > P ) is assigned to each subpartition. The
7 place-partition-var ICV of each implicit task is set to its subpartition. The subpartitioning is not
8 only a mechanism for achieving a sparse distribution, it also defines a subset of places for a thread
9 to use when creating a nested parallel region. The assignment of threads to places is as follows:
10 • T ≤ P : The parent thread’s place partition is split into T subpartitions, where each subpartition
11 contains bP/T c or dP/T e consecutive places. A single thread is assigned to each subpartition.
12 The primary thread executes on the place of the parent thread and is assigned to the subpartition
13 that includes that place. The thread with the next smallest thread number is assigned to the first
14 place in the next subpartition, and so on, with wrap around with respect to the original place
15 partition of the primary thread.
16 • T > P : The parent thread’s place partition is split into P subpartitions, each consisting of a
17 single place. Each subpartition is assigned Sp threads with consecutive thread numbers, where
18 bT /P c ≤ Sp ≤ dT /P e. The first S0 threads (including the primary thread) are assigned to the
19 subpartition that contains the place of the parent thread. The next S1 threads are assigned to the
20 next subpartition, and so on, with wrap around with respect to the original place partition of the
21 primary thread. When P does not divide T evenly, the exact number of threads in a particular
22 subpartition is implementation defined.
23 The determination of whether the affinity request can be fulfilled is implementation defined. If the
24 affinity request cannot be fulfilled, then the affinity of threads in the team is implementation defined.
25
26 Note – Wrap around is needed if the end of a place partition is reached before all thread
27 assignments are done. For example, wrap around may be needed in the case of close and T ≤ P ,
28 if the primary thread is assigned to a place other than the first place in the place partition. In this
29 case, thread 1 is assigned to the place after the place of the primary thread, thread 2 is assigned to
30 the place after that, and so on. The end of the place partition may be reached before all threads are
31 assigned. In this case, assignment of threads is resumed with the first place in the place partition.
32
33
1 2.7 teams Construct
2 Summary
3 The teams construct creates a league of initial teams and the initial thread in each team executes
4 the region.
5 Syntax
C / C++
6 The syntax of the teams construct is as follows:
7 #pragma omp teams [clause[ [,] clause] ... ] new-line
8 structured-block

10 num_teams([lower-bound:]upper-bound)
11 thread_limit(integer-expression)
13 private(list)
15 shared(list)
16 reduction([default ,] reduction-identifier : list)
18 and where lower-bound and upper-bound are scalar integer expressions.

C / C++
Fortran
19 The syntax of the teams construct is as follows:
20 !$omp teams [clause[ [,] clause] ... ]
22 !$omp end teams
23 or
24 !$omp teams [clause[ [,] clause] ... ]
26 [!$omp end teams]

2 num_teams([lower-bound:]upper-bound)
3 thread_limit(scalar-integer-expression)
5 private(list)
7 shared(list)
8 reduction([default ,] reduction-identifier : list)
10 and where lower-bound and upper-bound are scalar integer expressions.

Fortran
11 Binding
12 The binding thread set for a teams region is the encountering thread.
13 Description
14 When a thread encounters a teams construct, a league of teams is created. Each team is an initial
15 team, and the initial thread in each team executes the teams region.
16 If the num_teams clause is present, lower-bound is the specified lower bound and upper-bound is
17 the specified upper bound on the number of teams requested. If a lower bound is not specified, the
18 lower bound is set to the specified upper bound. The number of teams created is implementation
19 defined, but it will be greater than or equal to the lower bound and less than or equal to the upper
20 bound.
21 If the num_teams clause is not specified and the value of the nteams-var ICV is greater than zero,
22 the number of teams created is less or equal to the value of the nteams-var ICV. Otherwise, the
23 number of teams created is implementation defined, but it will be greater than or equal to 1.
24 A thread may obtain the number of teams created by the construct with a call to the
25 omp_get_num_teams routine.
26 If a thread_limit clause is not present on the teams construct, but the construct is closely
27 nested inside a target construct on which the thread_limit clause is specified, the behavior
28 is as if that thread_limit clause is also specified for the teams construct.
29 As described in Section 2.4.4.1, the teams construct limits the number of threads that may
30 participate in a contention group initiated by each team by setting the value of the thread-limit-var
31 ICV for the initial task to an implementation defined value greater than zero. If the
32 thread_limit clause is specified, the number of threads will be less than or equal to the value
33 specified in the clause. Otherwise, if the teams-thread-limit-var ICV is greater than zero, the
34 number of threads will be less than or equal to that value.

1 On a combined or composite construct that includes target and teams constructs, the
2 expressions in num_teams and thread_limit clauses are evaluated on the host device on
3 entry to the target construct.
4 Once the teams are created, the number of initial teams remains constant for the duration of the
5 teams region.
6 Within a teams region, initial team numbers uniquely identify each initial team. Initial team
7 numbers are consecutive whole numbers ranging from zero to one less than the number of initial
8 teams. A thread may obtain its own initial team number by a call to the omp_get_team_num
9 library routine.
10 The place list, given by the place-partition-var ICV of the encountering thread, is split into
11 subpartitions in an implementation-defined manner, and each team is assigned to a subpartition by
12 setting the place-partition-var of its initial thread to the subpartition.
13 The teams construct sets the default-device-var ICV for each initial thread to an
14 implementation-defined value.
15 After the teams have completed execution of the teams region, the encountering task resumes
16 execution of the enclosing task region.

18 The teams-begin event occurs in a thread that encounters a teams construct before any initial task
19 is created for the corresponding teams region.
20 Upon creation of each initial task, an initial-task-begin event occurs in the thread that executes the
21 initial task after the initial task is fully initialized but before the thread begins to execute the
22 structured block of the teams construct.
23 If the teams region creates a native thread, a native-thread-begin event occurs as the first event in
24 the context of the new thread prior to the initial-task-begin event.
25 When a thread finishes an initial task, an initial-task-end event occurs in the thread.
26 The teams-end event occurs in the thread that encounters the teams construct after the thread
27 executes its initial-task-end event but before it resumes execution of the encountering task.
28 If a native thread is destroyed at the end of a teams region, a native-thread-end event occurs in the
29 thread as the last event prior to destruction of the thread.
30 Tool Callbacks
31 A thread dispatches a registered ompt_callback_parallel_begin callback for each
32 occurrence of a teams-begin event in that thread. The callback occurs in the task that encounters the
33 teams construct. This callback has the type signature
34 ompt_callback_parallel_begin_t. In the dispatched callback,
35 (flags & ompt_parallel_league) evaluates to true.

2 ompt_scope_begin as its endpoint argument for each occurrence of an initial-task-begin in
3 that thread. Similarly, a thread dispatches a registered ompt_callback_implicit_task
4 callback with ompt_scope_end as its endpoint argument for each occurrence of an
5 initial-task-end event in that thread. The callbacks occur in the context of the initial task and have
6 type signature ompt_callback_implicit_task_t. In the dispatched callback,
7 (flags & ompt_task_initial) evaluates to true.
8 A thread dispatches a registered ompt_callback_parallel_end callback for each
9 occurrence of a teams-end event in that thread. The callback occurs in the task that encounters the
10 teams construct. This callback has the type signature ompt_callback_parallel_end_t.
12 native-thread-begin event in that thread. The callback occurs in the context of the thread. The
13 callback has type signature ompt_callback_thread_begin_t.
15 native-thread-end event in that thread. The callback occurs in the context of the thread. The
16 callback has type signature ompt_callback_thread_end_t.
17 Restrictions
18 Restrictions to the teams construct are as follows:
19 • A program that branches into or out of a teams region is non-conforming.
20 • A program must not depend on any ordering of the evaluations of the clauses of the teams
21 directive, or on any side effects of the evaluation of the clauses.
22 • At most one thread_limit clause can appear on the directive. The thread_limit
23 expression must evaluate to a positive integer value.
24 • At most one num_teams clause can appear on the directive. The lower-bound and upper-bound
25 specified in the num_teams clause must evaluate to positive integer values.
26 • A teams region must be strictly nested within the implicit parallel region that surrounds the
27 whole OpenMP program or a target region. If a teams region is nested inside a target
28 region, the corresponding target construct must not contain any statements, declarations or
29 directives outside of the corresponding teams construct.
30 • distribute, distribute simd, distribute parallel worksharing-loop, distribute parallel
31 worksharing-loop SIMD, parallel regions, including any parallel regions arising from
32 combined constructs, omp_get_num_teams() regions, and omp_get_team_num()
33 regions are the only OpenMP regions that may be strictly nested inside the teams region.

1 Cross References
3 • distribute construct, see Section 2.11.6.1.
4 • distribute simd construct, see Section 2.11.6.2.
6 • target construct, see Section 2.14.5.
7 • Data-sharing attribute clauses, see Section 2.21.4.
8 • omp_get_num_teams routine, see Section 3.4.1.
9 • omp_get_team_num routine, see Section 3.4.2.
15 2.8 masked Construct

16 Summary
17 The masked construct specifies a structured block that is executed by a subset of the threads of the
18 current team.
19 Syntax
C / C++
20 The syntax of the masked construct is as follows:
21 #pragma omp masked [ filter(integer-expression) ] new-line
22 structured-block
C / C++
Fortran
23 The syntax of the masked construct is as follows:
24 !$omp masked [ filter(scalar-integer-expression) ]
26 !$omp end masked

1 or
2 !$omp masked [ filter(scalar-integer-expression) ]
4 [!$omp end masked]
Fortran
5 The master construct, which has been deprecated, has the same syntax as the masked construct
6 other than the use of master as the directive name and that the filter clause may not be
7 specified for the master construct.
8 Binding
9 The binding thread set for a masked region is the current team. A masked region binds to the
10 innermost enclosing parallel region.
11 Description
12 Only the threads of the team that executes the binding parallel region that the filter clause
13 selects participate in the execution of the structured block of a masked region. Other threads in the
14 team do not execute the associated structured block. No implied barrier occurs either on entry to, or
15 exit from, the masked construct.
16 If a filter clause is present on the construct and the parameter specifies the thread number of the
17 current thread in the current team then the current thread executes the associated structured block.
18 If the filter clause is not present, the construct behaves as if the parameter is a constant integer
19 expression that evaluates to zero, so that only the primary thread executes the associated structured
20 block. The use of a variable in a filter clause expression causes an implicit reference to the
21 variable in all enclosing constructs. The result of evaluating the parameter of the filter clause
22 may vary across threads.
23 If more than one thread in the team executes the structured block of a masked region, the
24 structured block must include any synchronization required to ensure that data races do not occur.
25 The master construct, which has been deprecated, has identical semantics to the masked
26 construct with no filter clause present.

28 The masked-begin event occurs in any thread of a team that executes the masked region on entry
29 to the region.
30 The masked-end event occurs in any thread of a team that executes the masked region on exit from
31 the region.

1 Tool Callbacks
2 A thread dispatches a registered ompt_callback_masked callback with
3 ompt_scope_begin as its endpoint argument for each occurrence of a masked-begin event in
4 that thread. Similarly, a thread dispatches a registered ompt_callback_masked callback with
5 ompt_scope_end as its endpoint argument for each occurrence of a masked-end event in that
6 thread. These callbacks occur in the context of the task executed by the current thread and have the
7 type signature ompt_callback_masked_t.
8 Restrictions
9 Restrictions to the masked construct are as follows:
C++
10 • A throw executed inside a masked region must cause execution to resume within the same
11 masked region, and the same thread that threw the exception must catch it.
C++
12 Cross References
15 • ompt_callback_masked_t, see Section 4.5.2.12.
16 2.9 scope Construct

17 Summary
18 The scope construct defines a structured block that is executed by all threads in a team but where
19 additional OpenMP operations can be specified.
20 Syntax
C / C++
21 The syntax of the scope construct is as follows:
22 #pragma omp scope [clause[ [,] clause] ... ] new-line
23 structured-block

25 private(list)
27 nowait
C / C++

Fortran
1 The syntax of the scope construct is as follows:
2 !$omp scope [clause[ [,] clause] ... ]
4 !$omp end scope [nowait]
5 or
6 !$omp scope [clause[ [,] clause] ... ]
8 [!$omp end scope [nowait]]

10 private(list)
Fortran
12 Binding
13 The binding thread set for a scope region is the current team. A scope region binds to the
14 innermost enclosing parallel region. Only the threads of the team that executes the binding parallel
15 region participate in the execution of the structured block and the implied barrier of the scope
16 region if the barrier is not eliminated by a nowait clause.
17 Description
18 All encountering threads will execute the structured block associated with the scope construct.
19 An implicit barrier occurs at the end of a scope region if the nowait clause is not specified.

21 The scope-begin event occurs after an implicit task encounters a scope construct but before the
22 task starts to execute the structured block of the scope region.
23 The scope-end event occurs after an implicit task finishes execution of a scope region but before it
24 resumes execution of the enclosing region.
25 Tool Callbacks
26 A thread dispatches a registered ompt_callback_work callback with ompt_scope_begin
27 as its endpoint argument and ompt_work_scope as its wstype argument for each occurrence of a
28 scope-begin event in that thread. Similarly, a thread dispatches a registered
29 ompt_callback_work callback with ompt_scope_end as its endpoint argument and
30 ompt_work_scope as its wstype argument for each occurrence of a scope-end event in that
31 thread. The callbacks occur in the context of the implicit task. The callbacks have type signature
32 ompt_callback_work_t.

1 Restrictions
2 Restrictions to the scope construct are as follows:
3 • Each scope region must be encountered by all threads in a team or by none at all, unless
4 cancellation has been requested for the innermost enclosing parallel region.
5 • The sequence of worksharing regions, scope regions and barrier regions encountered must
6 be the same for every thread in a team.
7 • At most one nowait clause can appear on a scope construct.
C++
8 • A throw executed inside a scope region must cause execution to resume within the same
9 scope region, and the same thread that threw the exception must catch it.
C++
10 Cross References
11 • reduction clause, see Section 2.21.4.
13 • ompt_work_scope, see Section 4.4.4.15.
14 • ompt_callback_work_t, see Section 4.5.2.5.
15 2.10 Worksharing Constructs

16 A worksharing construct distributes the execution of the corresponding region among the members
17 of the team that encounters it. Threads execute portions of the region in the context of the implicit
18 tasks that each one is executing. If the team consists of only one thread then the worksharing region
19 is not executed in parallel.
20 A worksharing region has no barrier on entry; however, an implied barrier exists at the end of the
21 worksharing region, unless a nowait clause is specified. If a nowait clause is present, an
22 implementation may omit the barrier at the end of the worksharing region. In this case, threads that
23 finish early may proceed straight to the instructions that follow the worksharing region without
24 waiting for the other members of the team to finish the worksharing region, and without performing
25 a flush operation.
26 The OpenMP API defines the worksharing constructs that are described in this section as well as
27 the worksharing-loop construct, which is described in Section 2.11.4.

1 Restrictions
2 The following restrictions apply to worksharing constructs:
3 • Each worksharing region must be encountered by all threads in a team or by none at all, unless
5 • The sequence of worksharing regions, scope regions and barrier regions encountered must
6 be the same for every thread in a team.
7 2.10.1 sections Construct

8 Summary
9 The sections construct is a non-iterative worksharing construct that contains a set of structured
10 blocks that are to be distributed among and executed by the threads in a team. Each structured
11 block is executed once by one of the threads in the team in the context of its implicit task.
12 Syntax
C / C++
13 The syntax of the sections construct is as follows:
14 #pragma omp sections [clause[ [,] clause] ... ] new-line
15 {
16 [#pragma omp section new-line]
17 structured-block-sequence
18 [#pragma omp section new-line
19 structured-block-sequence]
20 ...
21 }

23 private(list)
25 lastprivate([ lastprivate-modifier:] list)
28 nowait
C / C++

Fortran
1 The syntax of the sections construct is as follows:
2 !$omp sections [clause[ [,] clause] ... ]
3 [!$omp section]
5 [!$omp section
7 ...
8 !$omp end sections [nowait]

10 private(list)
Fortran
15 Binding
16 The binding thread set for a sections region is the current team. A sections region binds to
17 the innermost enclosing parallel region. Only the threads of the team that executes the binding
18 parallel region participate in the execution of the structured block sequences and the implied
19 barrier of the sections region if the barrier is not eliminated by a nowait clause.
20 Description
21 Each structured block sequence in the sections construct is preceded by a section directive
22 except possibly the first sequence, for which a preceding section directive is optional.
23 The method of scheduling the structured block sequences among the threads in the team is
25 An implicit barrier occurs at the end of a sections region if the nowait clause is not specified.

27 The section-begin event occurs after an implicit task encounters a sections construct but before
28 the task executes any structured block sequences of the sections region.
29 The sections-end event occurs after an implicit task finishes execution of a sections region but
30 before it resumes execution of the enclosing context.
31 The section-begin event occurs before an implicit task starts to execute a structured block sequence
32 in the sections construct for each of those structured block sequences that the task executes.

1 Tool Callbacks
3 as its endpoint argument and ompt_work_sections as its wstype argument for each
4 occurrence of a section-begin event in that thread. Similarly, a thread dispatches a registered
6 ompt_work_sections as its wstype argument for each occurrence of a sections-end event in
7 that thread. The callbacks occur in the context of the implicit task. The callbacks have type
8 signature ompt_callback_work_t.
9 A thread dispatches a registered ompt_callback_dispatch callback for each occurrence of a
10 section-begin event in that thread. The callback occurs in the context of the implicit task. The
11 callback has type signature ompt_callback_dispatch_t.
12 Restrictions
13 Restrictions to the sections construct are as follows:
14 • Orphaned section directives are prohibited. That is, the section directives must appear
15 within the sections construct and must not be encountered elsewhere in the sections
16 region.
17 • The code enclosed in a sections construct must be a structured block sequence.
18 • Only a single nowait clause can appear on a sections directive.
C++
19 • A throw executed inside a sections region must cause execution to resume within the same
20 section of the sections region, and the same thread that threw the exception must catch it.
C++
21 Cross References
23 • private, firstprivate, lastprivate, and reduction clauses, see Section 2.21.4.
25 • ompt_work_sections, see Section 4.4.4.15.
27 • ompt_callback_dispatch_t, see Section 4.5.2.6.

1 2.10.2 single Construct
2 Summary
3 The single construct specifies that the associated structured block is executed by only one of the
4 threads in the team (not necessarily the primary thread), in the context of its implicit task. The
5 other threads in the team, which do not execute the block, wait at an implicit barrier at the end of a
6 single region unless a nowait clause is specified.
7 Syntax
C / C++
8 The syntax of the single construct is as follows:
9 #pragma omp single [clause[ [,] clause] ... ] new-line
10 structured-block

12 private(list)
14 copyprivate(list)
16 nowait
C / C++
Fortran
17 The syntax of the single construct is as follows:
18 !$omp single [clause[ [,] clause] ... ]
20 !$omp end single [end_clause[ [,] end_clause] ... ]
21 or
22 !$omp single [clause[ [,] clause] ... ]
24 [!$omp end single [end_clause[ [,] end_clause] ... ]]

26 private(list)

1 and end_clause is one of the following:
2 copyprivate(list)
3 nowait
Fortran
4 Binding
5 The binding thread set for a single region is the current team. A single region binds to the
6 innermost enclosing parallel region. Only the threads of the team that executes the binding
7 parallel region participate in the execution of the structured block and the implied barrier of the
8 single region if the barrier is not eliminated by a nowait clause.
9 Description
10 Only one of the encountering threads will execute the structured block associated with the single
11 construct. The method of choosing a thread to execute the structured block each time the team
12 encounters the construct is implementation defined. An implicit barrier occurs at the end of a
13 single region if the nowait clause is not specified.

15 The single-begin event occurs after an implicit task encounters a single construct but before the
16 task starts to execute the structured block of the single region.
17 The single-end event occurs after an implicit task finishes execution of a single region but before
18 it resumes execution of the enclosing region.
19 Tool Callbacks
21 as its endpoint argument for each occurrence of a single-begin event in that thread. Similarly, a
22 thread dispatches a registered ompt_callback_work callback with ompt_scope_end as its
23 endpoint argument for each occurrence of a single-end event in that thread. For each of these
24 callbacks, the wstype argument is ompt_work_single_executor if the thread executes the
25 structured block associated with the single region; otherwise, the wstype argument is
26 ompt_work_single_other. The callback has type signature ompt_callback_work_t.
27 Restrictions
28 Restrictions to the single construct are as follows:
29 • The copyprivate clause must not be used with the nowait clause.
30 • At most one nowait clause can appear on a single construct.
C++
31 • A throw executed inside a single region must cause execution to resume within the same
32 single region, and the same thread that threw the exception must catch it.
C++

1 Cross References
3 • private and firstprivate clauses, see Section 2.21.4.
4 • copyprivate clause, see Section 2.21.6.2.
6 • ompt_work_single_executor and ompt_work_single_other, see
7 Section 4.4.4.15.
8 • ompt_callback_work_t, Section 4.5.2.5.
Fortran
9 2.10.3 workshare Construct

10 Summary
11 The workshare construct divides the execution of the enclosed structured block into separate
12 units of work, and causes the threads of the team to share the work such that each unit is executed
13 only once by one thread, in the context of its implicit task.
14 Syntax
15 The syntax of the workshare construct is as follows:
16 !$omp workshare
18 !$omp end workshare [nowait]
19 or
20 !$omp workshare
22 [!$omp end workshare [nowait]]
23 Binding
24 The binding thread set for a workshare region is the current team. A workshare region binds
25 to the innermost enclosing parallel region. Only the threads of the team that executes the
26 binding parallel region participate in the execution of the units of work and the implied barrier
27 of the workshare region if the barrier is not eliminated by a nowait clause.

Fortran (cont.)
1 Description
2 An implicit barrier occurs at the end of a workshare region if a nowait clause is not specified.
3 An implementation of the workshare construct must insert any synchronization that is required
4 to maintain standard Fortran semantics. For example, the effects of one statement within the
5 structured block must appear to occur before the execution of succeeding statements, and the
6 evaluation of the right hand side of an assignment must appear to complete prior to the effects of
7 assigning to the left hand side.
8 The statements in the workshare construct are divided into units of work as follows:
9 • For array expressions within each statement, including transformational array intrinsic functions
10 that compute scalar values from arrays:
11 – Evaluation of each element of the array expression, including any references to elemental
12 functions, is a unit of work.
13 – Evaluation of transformational array intrinsic functions may be freely subdivided into any
14 number of units of work.
15 • For an array assignment statement, the assignment of each element is a unit of work.
16 • For a scalar assignment statement, the assignment operation is a unit of work.
17 • For a WHERE statement or construct, the evaluation of the mask expression and the masked
18 assignments are each a unit of work.
19 • For a FORALL statement or construct, the evaluation of the mask expression, expressions
20 occurring in the specification of the iteration space, and the masked assignments are each a unit
21 of work.
22 • For an atomic construct, the atomic operation on the storage location designated as x is a unit
23 of work.
24 • For a critical construct, the construct is a single unit of work.
25 • For a parallel construct, the construct is a unit of work with respect to the workshare
26 construct. The statements contained in the parallel construct are executed by a new thread
27 team.
28 • If none of the rules above apply to a portion of a statement in the structured block, then that
29 portion is a unit of work.
30 The transformational array intrinsic functions are MATMUL, DOT_PRODUCT, SUM, PRODUCT,
31 MAXVAL, MINVAL, COUNT, ANY, ALL, SPREAD, PACK, UNPACK, RESHAPE, TRANSPOSE,
32 EOSHIFT, CSHIFT, MINLOC, and MAXLOC.
33 It is unspecified how the units of work are assigned to the threads that execute a workshare
34 region.

Fortran (cont.)
1 If an array expression in the block references the value, association status, or allocation status of
2 private variables, the value of the expression is undefined, unless the same value would be
3 computed by every thread.
4 If an array assignment, a scalar assignment, a masked array assignment, or a FORALL assignment
5 assigns to a private variable in the block, the result is unspecified.
6 The workshare directive causes the sharing of work to occur only in the workshare construct,
7 and not in the remainder of the workshare region.

9 The workshare-begin event occurs after an implicit task encounters a workshare construct but
10 before the task starts to execute the structured block of the workshare region.
11 The workshare-end event occurs after an implicit task finishes execution of a workshare region
12 but before it resumes execution of the enclosing context.
13 Tool Callbacks
15 as its endpoint argument and ompt_work_workshare as its wstype argument for each
16 occurrence of a workshare-begin event in that thread. Similarly, a thread dispatches a registered
18 ompt_work_workshare as its wstype argument for each occurrence of a workshare-end event
19 in that thread. The callbacks occur in the context of the implicit task. The callbacks have type
21 Restrictions
22 Restrictions to the workshare construct are as follows:
23 • The only OpenMP constructs that may be closely nested inside a workshare construct are the
24 atomic, critical, and parallel constructs.
25 • Base language statements that are encountered inside a workshare construct but that are not
26 enclosed within a parallel construct that is nested inside the workshare construct must
27 consist of only the following:
28 – array assignments
29 – scalar assignments
30 – FORALL statements
31 – FORALL constructs
32 – WHERE statements
33 – WHERE constructs

1 • All array assignments, scalar assignments, and masked array assignments that are encountered
2 inside a workshare construct but are not nested inside a parallel construct that is nested
3 inside the workshare construct must be intrinsic assignments.
4 • The construct must not contain any user-defined function calls unless the function is
5 ELEMENTAL or the function call is contained inside a parallel construct that is nested inside
6 the workshare construct.
7 Cross References
9 • critical construct, see Section 2.19.1.
10 • atomic construct, see Section 2.19.7.
12 • ompt_work_workshare, see Section 4.4.4.15.
Fortran
14 2.11 Loop-Related Directives

15 2.11.1 Canonical Loop Nest Form
16 A loop nest has canonical loop nest form if it conforms to loop-nest in the following grammar:
17 Symbol Meaning
18 loop-nest One of the following:

C / C++
19 for (init-expr; test-expr; incr-expr)
20 loop-body
C / C++
21 or
C++
22 for (range-decl: range-expr)
23 loop-body
24 A range-based for loop is equivalent to a regular for loop using iterators, as

25 defined in the base language. A range-based for loop has no iteration variable.
C++

Symbol Meaning
1 or
Fortran
2 DO [ label ] var = lb , ub [ , incr ]
3 [intervening-code]
4 loop-body
6 [ label ] END DO
7 If the loop-nest is a nonblock-do-construct, it is treated as a block-do-construct for

8 each DO construct.
9 The value of incr is the increment of the loop. If not specified, its value is assumed to
10 be 1.
Fortran
11 or
12 loop-transformation-construct
13 or
14 generated-canonical-loop
15 loop-body One of the following:

16 loop-nest
17 or
C / C++
18 {
20 loop-body
22 }
C / C++

Symbol Meaning
1 or
Fortran
2 BLOCK
4 loop-body
6 END BLOCK
Fortran
7 or if none of the previous productions match
8 final-loop-body
9 loop-transformation- A loop transformation construct.

construct
10 generated-canonical- A generated loop from a loop transformation construct that has canonical loop nest
11 loop form and for which the loop body matches loop-body.
12 intervening-code A structured block sequence that does not contain OpenMP directives or calls to the
13 OpenMP runtime API in its corresponding region, referred to as intervening code. If
14 intervening code is present, then a loop at the same depth within the loop nest is not a
15 perfectly nested loop.
C / C++
16 It must not contain iteration statements, continue statements or break statements
17 that apply to the enclosing loop.
C / C++
Fortran
18 It must not contain loops, array expressions, CYCLE statements or EXIT statements.
Fortran
19 final-loop-body A structured block that terminates the scope of loops in the loop nest. If the loop nest
20 is associated with a loop-associated directive, loops in this structured block cannot be
21 associated with that directive.

Symbol Meaning
C / C++
1 init-expr One of the following:
2 var = lb
3 integer-type var = lb
C
4 pointer-type var = lb
C
C++
5 random-access-iterator-type var = lb
C++
6 test-expr One of the following:

7 var relational-op ub
8 ub relational-op var
9 relational-op One of the following:

10 <
11 <=
12 >
13 >=
14 !=
15 incr-expr One of the following:

16 ++var
17 var++
18 - - var
19 var - -
20 var += incr
21 var - = incr
22 var = var + incr
23 var = incr + var
24 var = var - incr
25 The value of incr, respectively 1 and -1 for the increment and decrement operators, is
26 the increment of the loop.
C / C++

Symbol Meaning
1 var One of the following:

C / C++
2 A variable of a signed or unsigned integer type.
3 C / C++
C
4 A variable of a pointer type.
5 C
C++
6 A variable of a random access iterator type.
7 C++
Fortran
8 A variable of integer type.
Fortran
9 var is the iteration variable of the loop. It must not be modified during the execution
10 of intervening-code or loop-body in the loop.
11 lb, ub One of the following:

12 Expressions of a type compatible with the type of var that are loop invariant with
13 respect to the outermost loop.
14 or
15 One of the following:
16 var-outer
17 var-outer + a2
18 a2 + var-outer
19 var-outer - a2
20 where var-outer is of a type compatible with the type of var.
21 or
22 If var is of an integer type, one of the following:
23 a2 - var-outer
24 a1 * var-outer
25 a1 * var-outer + a2
26 a2 + a1 * var-outer

Symbol Meaning
1 a1 * var-outer - a2
2 a2 - a1 * var-outer
3 var-outer * a1
4 var-outer * a1 + a2
5 a2 + var-outer * a1
6 var-outer * a1 - a2
7 a2 - var-outer * a1
8 where var-outer is of an integer type.
9 lb and ub are loop bounds. A loop for which lb or ub refers to var-outer is a
10 non-rectangular loop. If var is of an integer type, var-outer must be of an integer
11 type with the same signedness and bit precision as the type of var.
12 The coefficient in a loop bound is 0 if the bound does not refer to var-outer. If a loop
13 bound matches a form in which a1 appears, the coefficient is -a1 if the product of
14 var-outer and a1 is subtracted from a2, and otherwise the coefficient is a1. For other
15 matched forms where a1 does not appear, the coefficient is −1 if var-outer is
16 subtracted from a2, and otherwise the coefficient is 1.
17 a1, a2, incr Integer expressions that are loop invariant with respect to the outermost loop of the
18 loop nest.
19 If the loop is associated with a loop-associated directive, the expressions are
20 evaluated before the construct formed from that directive.
21 var-outer The loop iteration variable of a surrounding loop in the loop nest.
C++
22 range-decl A declaration of a variable as defined by the base language for range-based for
23 loops.
24 range-expr An expression that is valid as defined by the base language for range-based for
25 loops. It must be invariant with respect to the outermost loop of the loop nest and the
26 iterator derived from it must be a random access iterator.
C++

1 A loop transformation construct that appears inside a loop nest is replaced according to its
2 semantics before any loop can be associated with a loop-associated directive that is applied to the
3 loop nest. The depth of the loop nest is determined according to the loops in the loop nest, after any
4 such replacements have taken place. A loop counts towards the depth of the loop nest if it is a base
5 language loop statement or generated loop and it matches loop-nest while applying the production
6 rules for canonical loop nest form to the loop nest.
7 A loop-associated directive controls some number of the outermost loops of an associated loop
8 nest, called the associated loops, in accordance with its specified clauses. The canonical loop nest
9 form allows the iteration count of all associated loops to be computed before executing the
10 outermost loop.
11 For any associated loop, the iteration count is computed as follows:
C / C++
12 • If var has a signed integer type and the var operand of test-expr after usual arithmetic
13 conversions has an unsigned integer type then the loop iteration count is computed from lb,
14 test-expr and incr using an unsigned integer type corresponding to the type of var.
15 • Otherwise, if var has an integer type then the loop iteration count is computed from lb, test-expr
16 and incr using the type of var.
C / C++
C
17 • If var has a pointer type then the loop iteration count is computed from lb, test-expr and incr
18 using the type ptrdiff_t.
C
C++
19 • If var has a random access iterator type then the loop iteration count is computed from lb,
20 test-expr and incr using the type
21 std::iterator_traits<random-access-iterator-type>::difference_type.
22 • For range-based for loops, the loop iteration count is computed from range-expr using the type
23 std::iterator_traits<random-access-iterator-type>::difference_type where
24 random-access-iterator-type is the iterator type derived from range-expr.
C++
Fortran
25 • The loop iteration count is computed from lb, ub and incr using the type of var.
Fortran

1 The behavior is unspecified if any intermediate result required to compute the iteration count
2 cannot be represented in the type determined above.
3 No synchronization is implied during the evaluation of the lb, ub, incr or range-expr expressions.
4 Whether, in what order, or how many times any side effects within the lb, ub, incr, or range-expr
5 expressions occur is unspecified.
6 The iterations of some number of associated loops can be collapsed into one larger iteration space
7 that is called the logical iteration space. The particular integer type used to compute the iteration
8 count for the collapsed loop is implementation defined.
9 For directives that result in the execution of a collapsed logical iteration space, the number of times
10 that any intervening code between any two loops of the same logical iteration space will be
11 executed is unspecified but will be the same for all intervening code at the same depth, at least once
12 per iteration of the loop enclosing the intervening code and at most once per logical iteration. If the
13 iteration count of any loop is zero and that loop does not enclose the intervening code, the behavior
14 is unspecified.
15 Restrictions
16 Restrictions to canonical loop nests are as follows:
C / C++
17 • If test-expr is of the form var relational-op b and relational-op is < or <= then incr-expr must
18 cause var to increase on each iteration of the loop. If test-expr is of the form var relational-op b
19 and relational-op is > or >= then incr-expr must cause var to decrease on each iteration of the
20 loop. Increase and decrease are using the order induced by relational-op.
21 • If test-expr is of the form ub relational-op var and relational-op is < or <= then incr-expr must
22 cause var to decrease on each iteration of the loop. If test-expr is of the form ub relational-op
23 var and relational-op is > or >= then incr-expr must cause var to increase on each iteration of the
24 loop. Increase and decrease are using the order induced by relational-op.
25 • If relational-op is != then incr-expr must cause var to always increase by 1 or always decrease
26 by 1 and the increment must be a constant expression.
27 • final-loop-body must not contain any break statement that would cause the termination of the
28 innermost loop.
C / C++
Fortran
29 • final-loop-body must not contain any EXIT statement that would cause the termination of the
30 innermost loop.
Fortran

1 • A loop-nest must also be a structured block.
2 • For a non-rectangular loop, if var-outer is referenced in lb and ub then they must both refer to the
3 same iteration variable.
4 • For a non-rectangular loop, let a1lb and a1ub be the respective coefficients in lb and ub, incrinner
5 the increment of the non-rectangular loop and incrouter the increment of the loop referenced by
6 var-outer. incrinner (a1ub − a1lb ) must be a multiple of incrouter .
7 • The loop iteration variable may not appear in a threadprivate directive.
8 Cross References
9 • Loop transformation constructs, see Section 2.11.9.
10 • threadprivate directive, see Section 2.21.2.
11 2.11.2 Consistent Loop Schedules

12 For constructs formed from loop-associated directives that have consistent schedules, the
13 implementation will guarantee that memory effects of a logical iteration in the first loop nest
14 happen before the execution of the same logical iteration in the second loop nest.
15 Two constructs formed from loop-associated directives have consistent schedules if all of the
16 following conditions hold:
17 • The constructs are formed from directives with the same directive name;
18 • The regions that correspond to the two constructs have the same binding region;
19 • The constructs have the same reproducible schedule;
20 • The associated loop nests have identical logical iteration vector spaces; and
21 • The associated loop nests are either both rectangular or both non-rectangular.
22 2.11.3 order Clause

23 Summary
24 The order clause specifies an expected order of execution for the iterations of the associated loops
25 of a loop-associated directive.
26 Syntax
27 The syntax of the order clause is as follows:
28 order([ order-modifier :]concurrent)

1 where order-modifier is one of the following:
2 reproducible
3 unconstrained
4 Description
5 The order clause specifies an expected order of execution for the iterations of the associated loops
6 of a loop-associated directive. The specified order must be concurrent.
7 The order clause is part of the schedule specification for the purpose of determining its
8 consistency with other schedules (see Section 2.11.2).
9 If the order clause specifies concurrent, the logical iterations of the associated loops may
10 execute in any order, including concurrently.
11 If order-modifier is not unconstrained, the behavior is as if the reproducible modifier is
12 present.
13 The specified schedule is reproducible if the reproducible modifier is present.
14 Restrictions
15 Restrictions to the order clause are as follows:
16 • The only constructs that may be encountered inside a region that corresponds to a construct with
17 an order clause that specifies concurrent are the loop construct, the parallel
18 construct, the simd construct, and combined constructs for which the first construct is a
19 parallel construct.
20 • A region that corresponds to a construct with an order clause that specifies concurrent may
21 not contain calls to procedures that contain OpenMP directives.
23 not contain calls to the OpenMP Runtime API.
24 • If a threadprivate variable is referenced inside a region that corresponds to a construct with an
25 order clause that specifies concurrent, the behavior is unspecified.
26 • At most one order clause may appear on a construct.
27 2.11.4 Worksharing-Loop Construct

28 Summary
29 The worksharing-loop construct specifies that the iterations of one or more associated loops will be
30 executed in parallel by threads in the team in the context of their implicit tasks. The iterations are
31 distributed across threads that already exist in the team that is executing the parallel region to
32 which the worksharing-loop region binds.

1 Syntax
C / C++
2 The syntax of the worksharing-loop construct is as follows:
3 #pragma omp for [clause[ [,] clause] ... ] new-line
4 loop-nest
5 where loop-nest is a canonical loop nest and clause is one of the following:
6 private(list)
8 lastprivate([lastprivate-modifier:]list)
9 linear(list[:linear-step])
10 reduction([reduction-modifier,]reduction-identifier:list)
11 schedule([modifier [, modifier]:]kind[, chunk_size])
12 collapse(n)
13 ordered[(n)]
14 nowait
15 allocate([allocator:]list)
16 order([order-modifier:]concurrent)
C / C++
Fortran
17 The syntax of the worksharing-loop construct is as follows:
18 !$omp do [clause[ [,] clause] ... ]
19 loop-nest
20 [!$omp end do [nowait]]
22 private(list)
24 lastprivate([lastprivate-modifier:]list)
25 linear(list[:linear-step])
26 reduction([reduction-modifier,]reduction-identifier:list)
27 schedule([modifier [, modifier]:]kind[, chunk_size])
28 collapse(n)

1 ordered[(n)]
2 allocate([allocator:]list)
3 order([order-modifier:]concurrent)
4 If an end do directive is not specified, an end do directive is assumed at the end of the do-loops.
Fortran
5 Binding
6 The binding thread set for a worksharing-loop region is the current team. A worksharing-loop
7 region binds to the innermost enclosing parallel region. Only the threads of the team executing
8 the binding parallel region participate in the execution of the loop iterations and the implied
9 barrier of the worksharing-loop region when that barrier is not eliminated by a nowait clause.
10 Description
11 An implicit barrier occurs at the end of a worksharing-loop region if a nowait clause is not
12 specified.
13 The collapse and ordered clauses may be used to specify the number of loops from the loop
14 nest that are associated with the worksharing-loop construct. If specified, their parameters must be
15 constant positive integer expressions.
16 The collapse clause specifies the number of loops that are collapsed into a logical iteration
17 space that is then divided according to the schedule clause. If the collapse clause is omitted,
18 the behavior is as if a collapse clause with a parameter value of one was specified.
19 If the ordered clause is specified with parameter n then the n outer loops from the associated
20 loop nest form a doacross loop nest. The parameter of the ordered clause does not affect how the
21 logical iteration space is divided.
22 At the beginning of each logical iteration, the loop iteration variable or the variable declared by
23 range-decl of each associated loop has the value that it would have if the set of the associated loops
24 was executed sequentially. The schedule clause specifies how iterations of these associated
25 loops are divided into contiguous non-empty subsets, called chunks, and how these chunks are
26 distributed among threads of the team. Each thread executes its assigned chunks in the context of
27 its implicit task. The iterations of a given chunk are executed in sequential order by the assigned
28 thread. The chunk_size expression is evaluated using the original list items of any variables that are
29 made private in the worksharing-loop construct. Whether, in what order, or how many times, any
30 side effects of the evaluation of this expression occur is unspecified. The use of a variable in a
31 schedule clause expression of a worksharing-loop construct causes an implicit reference to the
32 variable in all enclosing constructs.
33 See Section 2.11.4.1 for details of how the schedule for a worksharing-loop region is determined.
34 The schedule kind can be one of those specified in Table 2.5.

1 The schedule modifier can be one of those specified in Table 2.6. If the static schedule kind is
2 specified or if the ordered clause is specified, and if the nonmonotonic modifier is not
3 specified, the effect is as if the monotonic modifier is specified. Otherwise, unless the
4 monotonic modifier is specified, the effect is as if the nonmonotonic modifier is specified. If
5 a schedule clause specifies a modifier then that modifier overrides any modifier that is specified
6 in the run-sched-var ICV.
7 If an order clause is present then the semantics are as described in Section 2.11.3.
8 The schedule is reproducible if one of the following conditions is true:
9 • The order clause is present and uses the reproducible modifier; or
10 • The schedule clause is specified with static as the kind parameter and the simd modifier
11 is not present.
12 Programs can only depend on which thread executes a particular iteration if the schedule is
13 reproducible. Schedule reproducibility is also used for determining its consistency with other
14 schedules (see Section 2.11.2).
TABLE 2.5: schedule Clause kind Values
static When kind is static, iterations are divided into chunks of size chunk_size,
and the chunks are assigned to the threads in the team in a round-robin
fashion in the order of the thread number. Each chunk contains chunk_size
iterations, except for the chunk that contains the sequentially last iteration,
which may have fewer iterations.
When no chunk_size is specified, the iteration space is divided into chunks
that are approximately equal in size, and at most one chunk is distributed to
each thread. The size of the chunks is unspecified in this case.
dynamic When kind is dynamic, the iterations are distributed to threads in the team
in chunks. Each thread executes a chunk of iterations, then requests another
chunk, until no chunks remain to be distributed.
Each chunk contains chunk_size iterations, except for the chunk that contains
the sequentially last iteration, which may have fewer iterations.
When no chunk_size is specified, it defaults to 1.
guided When kind is guided, the iterations are assigned to threads in the team in
chunks. Each thread executes a chunk of iterations, then requests another
chunk, until no chunks remain to be assigned.

For a chunk_size of 1, the size of each chunk is proportional to the number

of unassigned iterations divided by the number of threads in the team,
decreasing to 1. For a chunk_size with value k (greater than 1), the size
of each chunk is determined in the same way, with the restriction that
the chunks do not contain fewer than k iterations (except for the chunk
that contains the sequentially last iteration, which may have fewer than k
iterations).
When no chunk_size is specified, it defaults to 1.
auto When kind is auto, the decision regarding scheduling is delegated to the
compiler and/or runtime system. The programmer gives the implementation
the freedom to choose any possible mapping of iterations to threads in the
team.
runtime When kind is runtime, the decision regarding scheduling is deferred until
run time, and the schedule and chunk size are taken from the run-sched-var
ICV. If the ICV is set to auto, the schedule is implementation defined.
2 Note – For a team of p threads and a loop of n iterations, let dn/pe

e be the integer q that satisfies
3 n = p ∗ q − r, with 0 <= r < p. One compliant implementation of the static schedule (with no
4 specified chunk_size) would behave as though chunk_size had been specified with value q. Another
5 compliant implementation would assign q iterations to the first p − r threads, and q − 1 iterations to
6 the remaining r threads. This illustrates why a conforming program must not rely on the details of a
7 particular implementation.
8 A compliant implementation of the guided schedule with a chunk_size value of k would assign
9 q = dn/pe e iterations to the first available thread and set n to the larger of n − q and p ∗ k. It would
10 then repeat this process until q is greater than or equal to the number of remaining iterations, at
11 which time the remaining iterations form the final chunk. Another compliant implementation could
12 use the same method, except with q = dn/(2p)e e, and set n to the larger of n − q and 2 ∗ p ∗ k.
13

TABLE 2.6: schedule Clause modifier Values
monotonic When the monotonic modifier is specified then each thread executes
the chunks that it is assigned in increasing logical iteration order.
nonmonotonic When the nonmonotonic modifier is specified then chunks are
assigned to threads in any order and the behavior of an application that
depends on any execution order of the chunks is unspecified.
simd When the simd modifier is specified and the loop is associated with
a SIMD construct, the chunk_size for all chunks except the first and
last chunks is new_chunk_size = dchunk_size/simd_widthe e∗
simd_width where simd_width is an implementation-defined value.
The first chunk will have at least new_chunk_size iterations except if
it is also the last chunk. The last chunk may have fewer iterations than
new_chunk_size. If the simd modifier is specified and the loop is not
associated with a SIMD construct, the modifier is ignored.

2 The ws-loop-begin event occurs after an implicit task encounters a worksharing-loop construct but
3 before the task starts execution of the structured block of the worksharing-loop region.
4 The ws-loop-end event occurs after a worksharing-loop region finishes execution but before
5 resuming execution of the encountering task.
6 The ws-loop-iteration-begin event occurs once for each iteration of a worksharing-loop before the
7 iteration is executed by an implicit task.
8 Tool Callbacks
10 as its endpoint argument and work_loop as its wstype argument for each occurrence of a
11 ws-loop-begin event in that thread. Similarly, a thread dispatches a registered
13 work_loop as its wstype argument for each occurrence of a ws-loop-end event in that thread. The
14 callbacks occur in the context of the implicit task. The callbacks have type signature
15 ompt_callback_work_t.
17 ws-loop-iteration-begin event in that thread. The callback occurs in the context of the implicit task.
18 The callback has type signature ompt_callback_dispatch_t.

1 Restrictions
2 Restrictions to the worksharing-loop construct are as follows:
3 • If the ordered clause with a parameter is present, all associated loops must be perfectly nested.
4 • If a reduction clause with the inscan modifier is specified, neither the ordered nor
5 schedule clause may appear on the worksharing-loop directive.
6 • The values of the loop control expressions of the loops associated with the worksharing-loop
7 construct must be the same for all threads in the team.
8 • At most one schedule clause can appear on a worksharing-loop directive.
9 • If the schedule or ordered clause is present then none of the associated loops may be
10 non-rectangular loops.
11 • The ordered clause must not appear on the worksharing-loop directive if the associated loops
12 include the generated loops of a tile directive.
13 • At most one collapse clause can appear on a worksharing-loop directive.
14 • chunk_size must be a loop invariant integer expression with a positive value.
15 • The value of the chunk_size expression must be the same for all threads in the team.
16 • The value of the run-sched-var ICV must be the same for all threads in the team.
17 • When schedule(runtime) or schedule(auto) is specified, chunk_size must not be
18 specified.
19 • A modifier may not be specified on a linear clause.
20 • At most one ordered clause can appear on a worksharing-loop directive.
21 • The ordered clause must be present on the worksharing-loop construct if any ordered
22 region ever binds to a worksharing-loop region arising from the worksharing-loop construct.
23 • The nonmonotonic modifier cannot be specified if an ordered clause is specified.
24 • Each schedule clause modifier may be specified at most once on the same schedule clause.
25 • Either the monotonic modifier or the nonmonotonic modifier can be specified but not both.
26 • If both the collapse and ordered clause with a parameter are specified, the parameter of the
27 ordered clause must be greater than or equal to the parameter of the collapse clause.
28 • The values of the parameters specified by the collapse and ordered clauses must not
29 exceed the depth of the associated loop nest.
30 • A linear clause or an ordered clause with a parameter can be specified on a
31 worksharing-loop directive but not both.

C / C++
1 • At most one nowait clause can appear on a for directive.
C / C++
C++
2 • If an ordered clause with a parameter is specified, none of the associated loops may be a
3 range-based for loop.
C++
4 Cross References
5 • Canonical loop nest form, see Section 2.11.1.
6 • order clause, see Section 2.11.3.
7 • tile construct, see Section 2.11.9.1.
8 • ordered construct, see Section 2.19.9.
9 • depend clause, see Section 2.19.11.
12 • ompt_work_loop, see Section 4.4.4.15.
15 2.11.4.1 Determining the Schedule of a Worksharing-Loop

16 When execution encounters a worksharing-loop directive, the schedule clause (if any) on the
17 directive, and the run-sched-var and def-sched-var ICVs are used to determine how loop iterations
18 are assigned to threads. See Section 2.4 for details of how the values of the ICVs are determined. If
19 the worksharing-loop directive does not have a schedule clause then the current value of the
20 def-sched-var ICV determines the schedule. If the worksharing-loop directive has a schedule
21 clause that specifies the runtime schedule kind then the current value of the run-sched-var ICV
22 determines the schedule. Otherwise, the value of the schedule clause determines the schedule.
23 Figure 2.1 describes how the schedule for a worksharing-loop is determined.
24 Cross References
25 • ICVs, see Section 2.4.

START
schedule No
clause present? Use def-sched-var schedule kind
Yes
schedule No
kind value is Use schedule kind specified in
runtime? schedule clause
Yes
Use run-sched-var schedule kind
F IGURE 2.1: Determining the schedule for a Worksharing-Loop
1 2.11.5 SIMD Directives

2 2.11.5.1 simd Construct
3 Summary
4 The simd construct can be applied to a loop to indicate that the loop can be transformed into a
5 SIMD loop (that is, multiple iterations of the loop can be executed concurrently by using SIMD
6 instructions).
7 Syntax
C / C++
8 The syntax of the simd construct is as follows:
9 #pragma omp simd [clause[ [,] clause] ... ] new-line
10 loop-nest

2 if([ simd :] scalar-expression)
3 safelen(length)
4 simdlen(length)
5 linear(list[ : linear-step])
6 aligned(list[ : alignment])
7 nontemporal(list)
8 private(list)
10 reduction([ reduction-modifier,]reduction-identifier : list)
11 collapse(n)
C / C++
Fortran
13 The syntax of the simd construct is as follows:
14 !$omp simd [clause[ [,] clause] ... ]
15 loop-nest
16 [!$omp end simd]
18 if([ simd :] scalar-logical-expression)
19 safelen(length)
20 simdlen(length)
21 linear(list[ : linear-step])
22 aligned(list[ : alignment])
23 nontemporal(list)
24 private(list)
27 collapse(n)
29 If an end simd directive is not specified, an end simd directive is assumed at the end of the
30 do-loops.
Fortran

1 Binding
2 A simd region binds to the current task region. The binding thread set of the simd region is the
3 current team.
4 Description
5 The simd construct enables the execution of multiple iterations of the associated loops
6 concurrently by using SIMD instructions.
7 The collapse clause may be used to specify how many loops are associated with the simd
8 construct. The collapse clause specifies the number of loops that are collapsed into a logical
9 iteration space that is then executed with SIMD instructions. The parameter of the collapse
10 clause must be a constant positive integer expression. If the collapse clause is omitted, the
11 behavior is as if a collapse clause with a parameter value of one was specified.
14 was executed sequentially. The number of iterations that are executed concurrently at any given
15 time is implementation defined. Each concurrent iteration will be executed by a different SIMD
16 lane. Each set of concurrent iterations is a SIMD chunk. Lexical forward dependences in the
17 iterations of the original loop must be preserved within each SIMD chunk, unless an order clause
18 that specifies concurrent is present.
19 The safelen clause specifies that no two concurrent iterations within a SIMD chunk can have a
20 distance in the logical iteration space that is greater than or equal to the value given in the clause.
21 The parameter of the safelen clause must be a constant positive integer expression. The
22 simdlen clause specifies the preferred number of iterations to be executed concurrently, unless an
23 if clause is present and evaluates to false, in which case the preferred number of iterations to be
24 executed concurrently is one. The parameter of the simdlen clause must be a constant positive
25 integer expression.
C / C++
27 The aligned clause declares that the object to which each list item points is aligned to the
28 number of bytes expressed in the optional parameter of the aligned clause.
C / C++
Fortran
29 The aligned clause declares that the location of each list item is aligned to the number of bytes
30 expressed in the optional parameter of the aligned clause.
Fortran
31 The optional parameter of the aligned clause, alignment, must be a constant positive integer
32 expression. If no optional parameter is specified, implementation-defined default alignments for
33 SIMD instructions on the target platforms are assumed.
34 The nontemporal clause specifies that accesses to the storage locations to which the list items
35 refer have low temporal locality across the iterations in which those storage locations are accessed.

1 Restrictions
2 Restrictions to the simd construct are as follows:
3 • At most one collapse clause can appear on a simd directive.
4 • A list-item cannot appear in more than one aligned clause.
5 • A list-item cannot appear in more than one nontemporal clause.
6 • At most one safelen clause can appear on a simd directive.
7 • At most one simdlen clause can appear on a simd directive.
8 • At most one if clause can appear on a simd directive.
9 • If both simdlen and safelen clauses are specified, the value of the simdlen parameter
10 must be less than or equal to the value of the safelen parameter.
11 • A modifier may not be specified on a linear clause.
12 • The only OpenMP constructs that can be encountered during execution of a simd region are the
13 atomic construct, the loop construct, the simd construct, and the ordered construct with
14 the simd clause.
15 • If an order clause that specifies concurrent appears on a simd directive, the safelen
16 clause may not also appear.
C / C++
17 • The simd region cannot contain calls to the longjmp or setjmp functions.
C / C++
C
18 • The type of list items appearing in the aligned clause must be array or pointer.
C
C++
19 • The type of list items appearing in the aligned clause must be array, pointer, reference to
20 array, or reference to pointer.
21 • No exception can be raised in the simd region.
22 • The only random access iterator types that are allowed for the associated loops are pointer types.
C++

Fortran
1 • If a list item on the aligned clause has the ALLOCATABLE attribute, the allocation status must
2 be allocated.
3 • If a list item on the aligned clause has the POINTER attribute, the association status must be
4 associated.
5 • If the type of a list item on the aligned clause is either C_PTR or Cray pointer, the list item
6 must be defined. Cray pointer support has been deprecated.
Fortran
7 Cross References
12 2.11.5.2 Worksharing-Loop SIMD Construct

13 Summary
14 The worksharing-loop SIMD construct specifies that the iterations of one or more associated loops
15 will be distributed across threads that already exist in the team and that the iterations executed by
16 each thread can also be executed concurrently using SIMD instructions. The worksharing-loop
17 SIMD construct is a composite construct.
18 Syntax
C / C++
19 The syntax of the worksharing-loop SIMD construct is as follows:
20 #pragma omp for simd [clause[ [,] clause] ... ] new-line
21 loop-nest
22 where loop-nest is a canonical loop nest and clause can be any of the clauses accepted by the for
23 or simd directives with identical meanings and restrictions.
C / C++

Fortran
1 The syntax of the worksharing-loop SIMD construct is as follows:
2 !$omp do simd [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end do simd [nowait] ]
5 where loop-nest is a canonical loop nest and clause can be any of the clauses accepted by the simd
6 or do directives, with identical meanings and restrictions.
7 If an end do simd directive is not specified, an end do simd directive is assumed at the end of
8 the do-loops.
Fortran
9 Description
10 The worksharing-loop SIMD construct will first distribute the logical iterations of the associated
11 loops across the implicit tasks of the parallel region in a manner consistent with any clauses that
12 apply to the worksharing-loop construct. Each resulting chunk of iterations will then be converted
13 to a SIMD loop in a manner consistent with any clauses that apply to the simd construct.

15 This composite construct generates the same events as the worksharing-loop construct.
16 Tool Callbacks
17 This composite construct dispatches the same callbacks as the worksharing-loop construct.
18 Restrictions
19 All restrictions to the worksharing-loop construct and the simd construct apply to the
20 worksharing-loop SIMD construct. In addition, the following restrictions apply:
21 • No ordered clause with a parameter can be specified.
22 • A list item may appear in a linear or firstprivate clause, but not in both.
23 Cross References
26 • simd construct, see Section 2.11.5.1.

1 2.11.5.3 declare simd Directive
2 Summary
3 The declare simd directive can be applied to a function (C, C++, and Fortran) or a subroutine
4 (Fortran) to enable the creation of one or more versions that can process multiple arguments using
5 SIMD instructions from a single invocation in a SIMD loop. The declare simd directive is a
6 declarative directive. Multiple declare simd directives may be specified for a function (C, C++,
7 and Fortran) or subroutine (Fortran).
8 Syntax
C / C++
9 The syntax of the declare simd directive is as follows:
10 #pragma omp declare simd [clause[ [,] clause] ... ] new-line
11 [#pragma omp declare simd [clause[ [,] clause] ... ] new-line]
12 [ ... ]
13 function definition or declaration

15 simdlen(length)
16 linear(linear-list[ : linear-step])
17 aligned(argument-list[ : alignment])
18 uniform(argument-list)
19 inbranch
20 notinbranch
C / C++
Fortran
21 The syntax of the declare simd directive is as follows:
22 !$omp declare simd [(proc-name)] [clause[ [,] clause] ... ]

24 simdlen(length)
26 aligned(argument-list[ : alignment])
27 uniform(argument-list)
28 inbranch
29 notinbranch
Fortran

1 Description
C / C++
2 The use of one or more declare simd directives on a function declaration or definition enables
3 the creation of corresponding SIMD versions of the associated function that can be used to process
4 multiple arguments from a single invocation in a SIMD loop concurrently.
5 The expressions appearing in the clauses of each directive are evaluated in the scope of the
6 arguments of the function declaration or definition.
C / C++
Fortran
7 The use of one or more declare simd directives in a subroutine or function enables the creation
8 of corresponding SIMD versions of the subroutine or function that can be used to process multiple
9 arguments from a single invocation in a SIMD loop concurrently.
Fortran
10 If a SIMD version is created, the number of concurrent arguments for the function is determined by
11 the simdlen clause. If the simdlen clause is used, its value corresponds to the number of
12 concurrent arguments of the function. The parameter of the simdlen clause must be a constant
13 positive integer expression. Otherwise, the number of concurrent arguments for the function is
C++
15 The special this pointer can be used as if it was one of the arguments to the function in any of the
16 linear, aligned, or uniform clauses.
C++
17 The uniform clause declares one or more arguments to have an invariant value for all concurrent
18 invocations of the function in the execution of a single SIMD loop.
C / C++
19 The aligned clause declares that the object to which each list item points is aligned to the
20 number of bytes expressed in the optional parameter of the aligned clause.
C / C++
Fortran
21 The aligned clause declares that the target of each list item is aligned to the number of bytes
22 expressed in the optional parameter of the aligned clause.
Fortran

1 The optional parameter of the aligned clause, alignment, must be a constant positive integer
2 expression. If no optional parameter is specified, implementation-defined default alignments for
3 SIMD instructions on the target platforms are assumed.
4 The inbranch clause specifies that the SIMD version of the function will always be called from
5 inside a conditional statement of a SIMD loop. The notinbranch clause specifies that the SIMD
6 version of the function will never be called from inside a conditional statement of a SIMD loop. If
7 neither clause is specified, then the SIMD version of the function may or may not be called from
8 inside a conditional statement of a SIMD loop.
9 Restrictions
10 Restrictions to the declare simd directive are as follows:
11 • Each argument can appear in at most one uniform or linear clause.
12 • At most one simdlen clause can appear in a declare simd directive.
13 • Either inbranch or notinbranch may be specified, but not both.
14 • When a linear-step expression is specified in a linear clause it must be either a constant integer
15 expression or an integer-typed parameter that is specified in a uniform clause on the directive.
16 • The function or subroutine body must be a structured block.
17 • The execution of the function or subroutine, when called from a SIMD loop, cannot result in the
18 execution of an OpenMP construct except for an ordered construct with the simd clause or an
19 atomic construct.
20 • The execution of the function or subroutine cannot have any side effects that would alter its
21 execution for concurrent iterations of a SIMD chunk.
22 • A program that branches into or out of the function is non-conforming.
C / C++
23 • If the function has any declarations, then the declare simd directive for any declaration that
24 has one must be equivalent to the one specified for the definition. Otherwise, the result is
25 unspecified.
26 • The function cannot contain calls to the longjmp or setjmp functions.
C / C++
C
27 • The type of list items appearing in the aligned clause must be array or pointer.
C

C++
1 • The function cannot contain any calls to throw.
2 • The type of list items appearing in the aligned clause must be array, pointer, reference to
3 array, or reference to pointer.
C++
Fortran
4 • proc-name must not be a generic name, procedure pointer, or entry name.
5 • If proc-name is omitted, the declare simd directive must appear in the specification part of a
6 subroutine subprogram or a function subprogram for which creation of the SIMD versions is
7 enabled.
8 • Any declare simd directive must appear in the specification part of a subroutine subprogram,
9 function subprogram, or interface body to which it applies.
10 • If a declare simd directive is specified in an interface block for a procedure, it must match a
11 declare simd directive in the definition of the procedure.
12 • If a procedure is declared via a procedure declaration statement, the procedure proc-name should
13 appear in the same specification.
14 • If a declare simd directive is specified for a procedure name with explicit interface and a
15 declare simd directive is also specified for the definition of the procedure then the two
16 declare simd directives must match. Otherwise the result is unspecified.
17 • Procedure pointers may not be used to access versions created by the declare simd directive.
18 • The type of list items appearing in the aligned clause must be C_PTR or Cray pointer, or the
19 list item must have the POINTER or ALLOCATABLE attribute. Cray pointer support has been
20 deprecated.
Fortran
21 Cross References
22 • linear clause, see Section 2.21.4.6.
23 • reduction clause, see Section 2.21.5.4.
24 2.11.6 distribute Loop Constructs

25 2.11.6.1 distribute Construct
26 Summary
27 The distribute construct specifies that the iterations of one or more loops will be executed by
28 the initial teams in the context of their implicit tasks. The iterations are distributed across the initial
29 threads of all initial teams that execute the teams region to which the distribute region binds.

1 Syntax
C / C++
2 The syntax of the distribute construct is as follows:
3 #pragma omp distribute [clause[ [,] clause] ... ] new-line
4 loop-nest
6 private(list)
8 lastprivate(list)
9 collapse(n)
10 dist_schedule(kind[, chunk_size])
11 allocate([allocator :]list)
C / C++
Fortran
13 The syntax of the distribute construct is as follows:
14 !$omp distribute [clause[ [,] clause] ... ]
15 loop-nest
16 [!$omp end distribute]
18 private(list)
20 lastprivate(list)
21 collapse(n)
22 dist_schedule(kind[, chunk_size])
23 allocate([allocator :]list)
25 If an end distribute directive is not specified, an end distribute directive is assumed at

26 the end of the do-loops.
Fortran

1 Binding
2 The binding thread set for a distribute region is the set of initial threads executing an
3 enclosing teams region. A distribute region binds to this teams region.
4 Description
5 The distribute construct is associated with a loop nest consisting of one or more loops that
6 follow the directive.
7 The collapse clause may be used to specify how many loops are associated with the
8 distribute construct. The parameter of the collapse clause must be a constant positive
9 integer expression. If the collapse clause is omitted, the behavior is as if a collapse clause
10 with a parameter value of one was specified.
11 No implicit barrier occurs at the end of a distribute region. To avoid data races the original list
12 items that are modified due to lastprivate or linear clauses should not be accessed between
13 the end of the distribute construct and the end of the teams region to which the
14 distribute binds.
17 was executed sequentially.
18 If the dist_schedule clause is specified, kind must be static. If specified, iterations are
19 divided into chunks of size chunk_size. These chunks are assigned to the initial teams of the league
20 in a round-robin fashion in the order of the initial team number. When chunk_size is not specified,
21 the iteration space is divided into chunks that are approximately equal in size, and at most one
22 chunk is distributed to each initial team of the league.
23 When dist_schedule clause is not specified, the schedule is implementation defined.
25 The schedule is reproducible if one of the following conditions is true:
26 • The order clause is present and uses the reproducible modifier; or
27 • The dist_schedule clause is specified with static as the kind parameter.
28 Programs can only depend on which team executes a particular iteration if the schedule is
29 reproducible. Schedule reproducibility is also used for determining its consistency with other
30 schedules (see Section 2.11.2).

32 The distribute-begin event occurs after an implicit task encounters a distribute construct but
33 before the task starts to execute the structured block of the distribute region.
34 The distribute-end event occurs after an implicit task finishes execution of a distribute region
35 but before it resumes execution of the enclosing context.

1 Tool Callbacks
3 as its endpoint argument and ompt_work_distribute as its wstype argument for each
4 occurrence of a distribute-begin event in that thread. Similarly, a thread dispatches a registered
6 ompt_work_distribute as its wstype argument for each occurrence of a distribute-end event
7 in that thread. The callbacks occur in the context of the implicit task. The callbacks have type
9 Restrictions
10 Restrictions to the distribute construct are as follows:
11 • The distribute construct inherits the restrictions of the worksharing-loop construct.
12 • Each distribute region must be encountered by the initial threads of all initial teams in a
13 league or by none at all.
14 • The sequence of the distribute regions encountered must be the same for every initial thread
15 of every initial team in a league.
16 • The region that corresponds to the distribute construct must be strictly nested inside a
17 teams region.
18 • A list item may appear in a firstprivate or lastprivate clause, but not in both.
19 • At most one dist_schedule clause can appear on the directive.
20 • If the dist_schedule is present then none of the associated loops may be non-rectangular
21 loops.
22 Cross References
23 • teams construct, see Section 2.7
28 • ompt_work_distribute, see Section 4.4.4.15.

1 2.11.6.2 distribute simd Construct
2 Summary
3 The distribute simd construct specifies a loop that will be distributed across the primary
4 threads of the teams region and executed concurrently using SIMD instructions. The
5 distribute simd construct is a composite construct.
6 Syntax
C / C++
7 The syntax of the distribute simd construct is as follows:
8 #pragma omp distribute simd [clause[ [,] clause] ... ] new-line
9 loop-nest
10 where loop-nest is a canonical loop nest and clause can be any of the clauses accepted by the
11 distribute or simd directives with identical meanings and restrictions.
C / C++
Fortran
12 The syntax of the distribute simd construct is as follows:
13 !$omp distribute simd [clause[ [,] clause] ... ]
14 loop-nest
15 [!$omp end distribute simd]
17 distribute or simd directives with identical meanings and restrictions.
18 If an end distribute simd directive is not specified, an end distribute simd directive is
19 assumed at the end of the do-loops.
Fortran
20 Description
21 The distribute simd construct will first distribute the logical iterations of the associated loops
22 across the initial tasks of the teams region in a manner consistent with any clauses that apply to
23 the distribute construct. Each resulting chunk of iterations will then be converted to a SIMD
24 loop in a manner consistent with any clauses that apply to the simd construct.

26 This composite construct generates the same events as the distribute construct.
27 Tool Callbacks
28 This composite construct dispatches the same callbacks as the distribute construct.

1 Restrictions
2 All restrictions to the distribute and simd constructs apply to the distribute simd
3 construct. In addition, the following restrictions apply:
4 • A list item may not appear in a linear clause unless it is the loop iteration variable of a loop
5 that is associated with the construct.
6 • The conditional modifier may not appear in a lastprivate clause.
7 Cross References
12 2.11.6.3 Distribute Parallel Worksharing-Loop Construct

13 Summary
14 The distribute parallel worksharing-loop construct specifies a loop that can be executed in parallel
15 by multiple threads that are members of multiple teams. The distribute parallel worksharing-loop
16 construct is a composite construct.
17 Syntax
C / C++
18 The syntax of the distribute parallel worksharing-loop construct is as follows:
19 #pragma omp distribute parallel for [clause[ [,] clause] ... ] new-line
20 loop-nest
22 distribute or parallel worksharing-loop directives with identical meanings and restrictions.
C / C++
Fortran
23 The syntax of the distribute parallel worksharing-loop construct is as follows:
24 !$omp distribute parallel do [clause[ [,] clause] ... ]
25 loop-nest
26 [!$omp end distribute parallel do]
28 distribute or parallel worksharing-loop directives with identical meanings and restrictions.
29 If an end distribute parallel do directive is not specified, an end distribute
30 parallel do directive is assumed at the end of the do-loops.
Fortran

1 Description
2 The distribute parallel worksharing-loop construct will first distribute the logical iterations of the
3 associated loops across the initial tasks of the teams region in a manner consistent with any
4 clauses that apply to the distribute construct. Each resulting chunk of iterations will then
5 execute as if part of a parallel worksharing-loop region in a manner consistent with any clauses that
6 apply to the parallel worksharing-loop construct.

8 This composite construct generates the same events as the distribute and parallel
9 worksharing-loop constructs.
10 Tool Callbacks
11 This composite construct dispatches the same callbacks as the distribute and parallel
12 worksharing-loop constructs.
13 Restrictions
14 All restrictions to the distribute and parallel worksharing-loop constructs apply to the
15 distribute parallel worksharing-loop construct. In addition, the following restrictions apply:
16 • No ordered clause can be specified.
17 • No linear clause can be specified.
18 • The conditional modifier must not appear in a lastprivate clause.
19 Cross References
22 • Parallel worksharing-loop construct, see Section 2.16.1.
24 2.11.6.4 Distribute Parallel Worksharing-Loop SIMD Construct

25 Summary
26 The distribute parallel worksharing-loop SIMD construct specifies a loop that can be executed
27 concurrently using SIMD instructions in parallel by multiple threads that are members of multiple
28 teams. The distribute parallel worksharing-loop SIMD construct is a composite construct.

1 Syntax
C / C++
2 The syntax of the distribute parallel worksharing-loop SIMD construct is as follows:
3 #pragma omp distribute parallel for simd \
4 [clause[ [,] clause] ... ] new-line
5 loop-nest
7 distribute or parallel worksharing-loop SIMD directives with identical meanings and
8 restrictions.
C / C++
Fortran
9 The syntax of the distribute parallel worksharing-loop SIMD construct is as follows:
10 !$omp distribute parallel do simd [clause[ [,] clause] ... ]
11 loop-nest
12 [!$omp end distribute parallel do simd]
14 distribute or parallel worksharing-loop SIMD directives with identical meanings and
15 restrictions.
16 If an end distribute parallel do simd directive is not specified, an end distribute
17 parallel do simd directive is assumed at the end of the do-loops.
Fortran
18 Description
19 The distribute parallel worksharing-loop SIMD construct will first distribute the logical iterations
20 of the associated loops across the initial tasks of the teams region in a manner consistent with any
21 clauses that apply to the distribute construct. Each resulting chunk of iterations will then
22 execute as if part of a parallel worksharing-loop SIMD region in a manner consistent with any
23 clauses that apply to the parallel worksharing-loop SIMD construct.

25 This composite construct generates the same events as the distribute and parallel
26 worksharing-loop SIMD constructs.
27 Tool Callbacks
28 This composite construct dispatches the same callbacks as the distribute and parallel
29 worksharing-loop SIMD constructs.

1 Restrictions
2 All restrictions to the distribute and parallel worksharing-loop SIMD constructs apply to the
3 distribute parallel worksharing-loop SIMD construct. In addition, the following restrictions apply:
4 • No ordered clause can be specified.
5 • A list item may not appear in a linear clause unless it is the loop iteration variable of a loop
6 that is associated with the construct.
8 • If any if clause on the directive includes a directive-name-modifier then all if clauses on the
9 directive must include a directive-name-modifier.
10 • At most one if clause without a directive-name-modifier can appear on the directive.
11 • At most one if clause with the parallel directive-name-modifier can appear on the directive.
12 • At most one if clause with the simd directive-name-modifier can appear on the directive.
13 Cross References
16 • Parallel worksharing-loop SIMD construct, see Section 2.16.5.
18 2.11.7 loop Construct

19 Summary
20 A loop construct specifies that the logical iterations of the associated loops may execute
21 concurrently and permits the encountering threads to execute the loop accordingly.
22 Syntax
C / C++
23 The syntax of the loop construct is as follows:
24 #pragma omp loop [clause[ [,] clause] ... ] new-line
25 loop-nest
27 bind(binding)
28 collapse(n)
30 private(list)

1 lastprivate(list)
2 reduction([default ,]reduction-identifier : list)
3 where binding is one of the following:

4 teams
5 parallel
6 thread
C / C++
Fortran
7 The syntax of the loop construct is as follows:
8 !$omp loop [clause[ [,] clause] ... ]
9 loop-nest
10 [!$omp end loop]
12 bind(binding)
13 collapse(n)
15 private(list)
18 where binding is one of the following:

19 teams
20 parallel
21 thread
22 If an end loop directive is not specified, an end loop directive is assumed at the end of the
23 do-loops.
Fortran

1 Binding
2 If the bind clause is present on the construct, the binding region is determined by binding.
3 Specifically, if binding is teams and an innermost enclosing teams region exists then the binding
4 region is that teams region; if binding is parallel then the binding region is the innermost
5 enclosing parallel region, which may be an implicit parallel region; and if binding is thread then
6 the binding region is not defined. If the bind clause is not present on the construct and the loop
7 construct is closely nested inside a teams or parallel construct, the binding region is the
8 corresponding teams or parallel region. If none of those conditions hold, the binding region
9 is not defined.
10 If the binding region is a teams region, then the binding thread set is the set of initial threads that
11 are executing that region. If the binding region is a parallel region, then the binding thread set is the
12 team of threads that are executing that region. If the binding region is not defined, then the binding
13 thread set is the encountering thread.
14 Description
15 The loop construct is associated with a loop nest that consists of one or more loops that follow the
16 directive. The directive asserts that the iterations may execute in any order, including concurrently.
17 The collapse clause may be used to specify how many loops are associated with the loop
18 construct. The parameter of the collapse clause must be a constant positive integer expression.
19 If the collapse clause is omitted, the behavior is as if a collapse clause with a parameter
20 value of one was specified. The collapse clause specifies the number of loops that are collapsed
21 into a logical iteration space.
25 Each logical iteration is executed once per instance of the loop region that is encountered by the
26 binding thread set.
27 If an order clause is present then the semantics are as described in Section 2.11.3. If the order
28 clause is not present, the behavior is as if an order clause that specifies concurrent appeared
29 on the construct.
30 The set of threads that may execute the iterations of the loop region is the binding thread set. Each
31 iteration is executed by one thread from this set.
32 If the loop region binds to a teams region, the threads in the binding thread set may continue
33 execution after the loop region without waiting for all logical iterations of the associated loops to
34 complete. The iterations are guaranteed to complete before the end of the teams region.
35 If the loop region does not bind to a teams region, all logical iterations of the associated loops
36 must complete before the encountering threads continue execution after the loop region.
37 For the purpose of determining its consistency with other schedules (see Section 2.11.2), the
38 schedule is defined by the implicit order clause.

1 The schedule is reproducible if the schedule specified through the implicit order clause is
2 reproducible.
3 Restrictions
4 Restrictions to the loop construct are as follows:
5 • At most one collapse clause can appear on a loop directive.
6 • A list item may not appear in a lastprivate clause unless it is the loop iteration variable of a
7 loop that is associated with the construct.
8 • If a loop construct is not nested inside another OpenMP construct and it appears in a procedure,
9 the bind clause must be present.
10 • If a loop region binds to a teams or parallel region, it must be encountered by all threads in
11 the binding thread set or by none of them.
12 • At most one bind clause can appear on a loop directive.
13 • If the bind clause is present on the loop construct and binding is teams then the
14 corresponding loop region must be strictly nested inside a teams region.
15 • If the bind clause, with teams specified as binding, is present on the loop construct and the
16 corresponding loop region executes on a non-host device then the behavior of a reduction
17 clause that appears on the construct is unspecified if the construct is not nested inside a teams
18 construct.
19 • If the bind clause is present on the loop construct and binding is parallel then the
20 behavior is unspecified if the corresponding loop region is closely nested inside a simd region.
21 Cross References
22 • The single construct, see Section 2.10.2.
25 • The Worksharing-Loop construct, see Section 2.11.4.
26 • SIMD directives, see Section 2.11.5.
28 2.11.8 scan Directive

29 Summary
30 The scan directive specifies that scan computations update the list items on each iteration of an
31 enclosing loop nest that is associated with a worksharing-loop, worksharing-loop SIMD, or simd
32 directive.

1 Syntax
C / C++
2 The syntax of the scan directive and the loop body that contains it is as follows:
3 {
5 #pragma omp scan clause new-line
7 }

9 inclusive(list)
10 exclusive(list)
11 and where the containing loop body belongs to the innermost loop that is associated with the
12 directive of an enclosing for, for simd, or simd construct.
C / C++
Fortran
13 The syntax of the scan directive and the loop body that contains it is as follows:
15 !$omp scan clause

18 inclusive(list)
19 exclusive(list)
20 and where the containing loop body belongs to the innermost loop that is associated with the
21 directive of an enclosing do, do simd, or simd construct.
Fortran

1 Description
2 A scan directive is associated with the same worksharing-loop, worksharing-loop SIMD, or simd
3 directive as the associated loop to which its containing loop body belongs. The directive specifies
4 that a scan computation updates each list item on each logical iteration of the associated loops
5 controlled by its associated directive. The directive specifies that either an inclusive scan
6 computation is to be performed for each list item that appears in an inclusive clause on the
7 directive, or an exclusive scan computation is to be performed for each list item that appears in an
8 exclusive clause on the directive. For each list item for which a scan computation is specified,
9 statements that lexically precede or follow the directive constitute one of two phases for a given
10 logical iteration of the loop — an input phase or a scan phase.
11 If the list item appears in an inclusive clause, all statements in the structured block sequence
12 that lexically precede the directive constitute the input phase and all statements in the structured
13 block sequence that lexically follow the directive constitute the scan phase. If the list item appears
14 in an exclusive clause, all statements in the structured block sequence that lexically precede the
15 directive constitute the scan phase and all statements in the structured block sequence that lexically
16 follow the directive constitute the input phase. The input phase contains all computations that
17 update the list item in the iteration, and the scan phase ensures that any statement that reads the list
18 item uses the result of the scan computation for that iteration.
19 The list items that appear in an inclusive or exclusive clause may include array sections.
20 The result of a scan computation for a given iteration is calculated according to the last generalized
21 prefix sum (PRESUMlast ) applied over the sequence of values given by the original value of the list
22 item prior to the loop and all preceding updates to the list item in the logical iteration space of the
23 loop. The operation PRESUMlast ( op, a1 , . . . , aN ) is defined for a given binary operator op and a
24 sequence of N values a1 , . . . , aN as follows:
25 • if N = 1, a1
26 • if N > 1, op( PRESUMlast (op, a1 , . . . , aK ), PRESUMlast (op, aL , . . . , aN ) ), where
27 1 ≤ K + 1 = L ≤ N.
28 At the beginning of the input phase of each iteration, the list item is initialized with the initializer
29 value of the reduction-identifier specified by the reduction clause on the innermost enclosing
30 construct. The update value of a list item is, for a given iteration, the value of the list item on
31 completion of its input phase.
32 Let orig-val be the value of the original list item on entry to the enclosing worksharing-loop,
33 worksharing-loop SIMD, or simd construct. Let combiner be the combiner for the
34 reduction-identifier specified by the reduction clause on the construct. And let uI be the update
35 value of a list item for iteration I. For list items that appear in an inclusive clause on the scan
36 directive, at the beginning of the scan phase for iteration I the list item is assigned the result of the
37 operation PRESUMlast ( combiner, orig-val, u0 , . . . , uI ). For list items that appear in an
38 exclusive clause on the scan directive, at the beginning of the scan phase for iteration I = 0
39 the list item is assigned the value orig-val, and at the beginning of the scan phase for iteration I > 0
40 the list item is assigned the result of the operation PRESUMlast ( combiner, orig-val, u0 , . . . , uI-1 ).

1 For list items that appear in an inclusive clause, at the end of the enclosing worksharing-loop,
2 worksharing-loop SIMD, or simd construct, the original list item is assigned the private copy from
3 the last logical iteration of the loops associated with the enclosing construct. For list items that
4 appear in an exclusive clause, let L be the last logical iteration of the loops associated with the
5 enclosing construct. At the end of the enclosing construct, the original list item is assigned the
6 result of the operation PRESUMlast ( combiner, orig-val, u0 , . . . , uL ).
7 Restrictions
8 Restrictions to the scan directive are as follows:
9 • Exactly one scan directive must be associated with a given worksharing-loop, worksharing-loop
10 SIMD, or simd directive on which a reduction clause with the inscan modifier is present.
11 • The loops that are associated with the directive to which the scan directive is associated must
12 all be perfectly nested.
13 • A list item that appears in the inclusive or exclusive clause must appear in a
14 reduction clause with the inscan modifier on the associated worksharing-loop,
15 worksharing-loop SIMD, or simd construct.
16 • Cross-iteration dependences across different logical iterations must not exist, except for
17 dependences for the list items specified in an inclusive or exclusive clause.
18 • Intra-iteration dependences from a statement in the structured block sequence that precede a
19 scan directive to a statement in the structured block sequence that follows a scan directive
20 must not exist, except for dependences for the list items specified in an inclusive or
21 exclusive clause.
22 • The private copy of list items that appear in the inclusive or exclusive clause may not be
23 modified in the scan phase.
24 Cross References
27 • Worksharing-loop SIMD construct, see Section 2.11.5.2.
29 2.11.9 Loop Transformation Constructs

30 A loop transformation construct replaces itself, including its associated loop nest, with a structured
31 block that may be another loop nest. If the loop transformation construct is nested inside another
32 loop nest, its replacement becomes part of that loop nest and therefore its generated loops may
33 become associated with another loop-associated directive that forms an enclosing construct. A loop

1 transformation construct that is closely nested within another loop transformation construct applies
2 before the enclosing loop transformation construct.
3 The associated loop nest of a loop transformation construct must have canonical loop nest form (see
4 Section 2.11.1). All generated loops have canonical loop nest form, unless otherwise specified.
5 Loop iteration variables of generated loops are always private in the enclosing teams,
6 parallel, simd, or task generating construct.
7 Cross References
9 2.11.9.1 tile Construct

10 Summary
11 The tile construct tiles one or more loops.
12 Syntax
C / C++
13 The syntax of the tile construct is as follows:
14 #pragma omp tile sizes(size-list) new-line
15 loop-nest
16 where loop-nest is a canonical loop nest and size-list is a list s1 , . . . , sn of positive integer
17 expressions.
C / C++
Fortran
18 The syntax of the tile construct is as follows:
19 !$omp tile sizes(size-list)
20 loop-nest
21 [!$omp end tile]
22 where loop-nest is a canonical loop nest and size-list is a list s1 , . . . , sn of positive integer
23 expressions.
24 If an end tile directive is not specified, an end tile directive is assumed at the end of the
25 do-loops.
Fortran

1 Description
2 The tile construct controls the outer n loops of the associated loop nest, where n is the number
3 of items in size-list. Let `1 , . . . `n be the associated loops, from outermost to innermost, which the
4 construct replaces with a loop nest that consists of 2n perfectly nested loops. Let
5 f1 , . . . , fn , t1 , . . . , tn be the generated loops, from outermost to innermost. The loops f1 , . . . , fn
6 are the floor loops and the loops t1 , . . . , tn are the tile loops. The tile loops do not have canonical
7 loop nest form.
8 Let Ω be the logical iteration vector space of the associated loops. For any (α1 , . . . , αn ) ∈ Nn ,
9 define a tile Tα1 ,...,αn as the set of iterations
10 {(i1 , . . . , in ) ∈ Ω | ∀k ∈ {1, . . . , n} : sk αk ≤ ik < sk αk + sk } and
11 Qn= {Tα1 ,...,αn | Tα1 ,...,αn 6= ∅} as the set of tiles with at least one iteration. Tiles that contain
F
12 k=1 sk iterations are complete tiles. Otherwise, they are partial tiles.
13 The floor loops iterate over all tiles {Tα1 ,...,αn ∈ F } in lexicographic order with respect to their
14 indices (α1 , . . . , αn ) and the tile loops iterate over the iterations in Tα1 ,...,αn in the lexicographic
15 order of the corresponding iteration vectors. An implementation may reorder the sequential
16 execution of two iterations if at least one is from a partial tile and if their respective logical iteration
17 vectors in loop-nest do not have a product order relation.
18 Restrictions
19 Restrictions to the tile construct are as follows:
20 • The depth of the associated loop nest must be greater than or equal to n.
21 • All loops that are associated with the construct must be perfectly nested.
22 • No loop that is associated with the construct may be a non-rectangular loop.
23 Cross References
27 • taskloop construct, see Section 2.12.2.

1 2.11.9.2 unroll Construct
2 Summary
3 The unroll construct fully or partially unrolls a loop.
4 Syntax
C / C++
5 The syntax of the unroll construct is as follows:
6 #pragma omp unroll [clause] new-line
7 loop-nest
9 full
10 partial[(unroll-factor)]
11 where unroll-factor is a positive integer expression that is a compile-time constant.

C / C++
Fortran
12 The syntax of the unroll construct is as follows:
13 !$omp unroll [clause]
14 loop-nest
15 [!$omp end unroll]
17 full
18 partial[(unroll-factor)]
19 where unroll-factor is a positive integer expression that is a compile-time constant.

20 If an end unroll directive is not specified, an end unroll directive is assumed at the end of
21 the do-loop.
Fortran
22 Description
23 The unroll construct controls the outermost loop of the loop nest.
24 When the full clause is specified, the associated loop is fully unrolled – it is replaced with n
25 instances of its loop body, one for each logical iteration of the associated loop and in the order of its
26 logical iterations. The construct is replaced by a structured block that only contains the n loop body
27 instances.

1 When the partial clause is specified, the associated loop is first tiled with a tile size of
2 unroll-factor. Then, the generated tile loop is fully unrolled. If the partial clause is used without
3 an unroll-factor argument then the unroll factor is a positive integer that is implementation defined.
4 When neither the full nor the partial clauses are specified, if and how the loop is unrolled is
6 The unroll construct results in a generated loop that has canonical loop nest form if and only if
7 the partial clause is specified.
8 Restrictions
9 Restrictions to the unroll construct are as follows:
10 • If the full clause is specified, the iteration count of the loop must be a compile-time constant.
11 Cross References
14 2.12 Tasking Constructs

15 2.12.1 task Construct
16 Summary
17 The task construct defines an explicit task.
18 Syntax
C / C++
19 The syntax of the task construct is as follows:
20 #pragma omp task [clause[ [,] clause] ... ] new-line
21 structured-block

23 if([ task :] scalar-expression)
24 final(scalar-expression)
25 untied
27 mergeable
28 private(list)

1 shared(list)
2 in_reduction(reduction-identifier : list)
4 priority(priority-value)
6 affinity([aff-modifier :] locator-list)
7 detach(event-handle)
8 where event-handle is a variable of omp_event_handle_t type and aff-modifier is one of the

9 following:
C / C++
Fortran
11 The syntax of the task construct is as follows:
12 !$omp task [clause[ [,] clause] ... ]
14 !$omp end task
15 or
16 !$omp task [clause[ [,] clause] ... ]
18 [!$omp end task]

20 if([ task :] scalar-logical-expression)
21 final(scalar-logical-expression)
22 untied
24 mergeable
25 private(list)
27 shared(list)

2 affinity([aff-modifier :] locator-list)
3 detach(event-handle)
4 where event-handle is an integer variable of omp_event_handle_kind kind and aff-modifier

5 is one of the following:
Fortran
7 Binding
8 The binding thread set of the task region is the current team. A task region binds to the
10 Description
11 The task construct is a task generating construct. When a thread encounters a task construct, an
12 explicit task is generated from the code for the associated structured block. The data environment
13 of the task is created according to the data-sharing attribute clauses on the task construct, per-data
14 environment ICVs, and any defaults that apply. The data environment of the task is destroyed when
15 the execution code of the associated structured block is completed.
16 The encountering thread may immediately execute the task, or defer its execution. In the latter case,
17 any thread in the team may be assigned the task. Completion of the task can be guaranteed using
18 task synchronization constructs and clauses. If a task construct is encountered during execution
19 of an outer task, the generated task region that corresponds to this construct is not a part of the
20 outer task region unless the generated task is an included task.
21 If a detach clause is present on a task construct a new allow-completion event is created and
22 connected to the completion of the associated task region. The original event-handle is updated
23 to represent that allow-completion event before the task data environment is created. The
24 event-handle is considered as if it was specified on a firstprivate clause. The use of a
25 variable in a detach clause expression of a task construct causes an implicit reference to the
27 If no detach clause is present on a task construct the generated task is completed when the
28 execution of its associated structured block is completed. If a detach clause is present on a task
29 construct, the task is completed when the execution of its associated structured block is completed
30 and the allow-completion event is fulfilled.
31 When an if clause is present on a task construct and the if clause expression evaluates to false,
32 an undeferred task is generated, and the encountering thread must suspend the current task region,
33 for which execution cannot be resumed until execution of the structured block that is associated
34 with the generated task is completed. The use of a variable in an if clause expression of a task
35 construct causes an implicit reference to the variable in all enclosing constructs.

1 When a final clause is present on a task construct and the final clause expression evaluates
2 to true, the generated task is a final task. All task constructs that are encountered during
3 execution of a final task generate final and included tasks. The use of a variable in a final clause
4 expression of a task construct causes an implicit reference to the variable in all enclosing
5 constructs. Encountering a task construct with the detach clause during the execution of a final
6 task results in unspecified behavior.
7 The if clause expression and the final clause expression are evaluated in the context outside of
8 the task construct, and no ordering of those evaluations is specified.
9 A thread that encounters a task scheduling point within the task region may temporarily suspend
10 the task region. By default, a task is tied and its suspended task region can only be resumed by
11 the thread that started its execution. If the untied clause is present on a task construct, any
12 thread in the team can resume the task region after a suspension. The untied clause is ignored
13 if the task is a final or an included task.
14 The task construct includes a task scheduling point in the task region of its generating task,
15 immediately following the generation of the explicit task. Each explicit task region includes a
16 task scheduling point at the end of its associated structured block.
17 When the mergeable clause is present on a task construct, the generated task is a mergeable
18 task.
19 The priority clause is a hint for the priority of the generated task. The priority-value is a
20 non-negative integer expression that provides a hint for task execution order. Among all tasks ready
21 to be executed, higher priority tasks (those with a higher numerical value in the priority clause
22 expression) are recommended to execute before lower priority ones. The default priority-value
23 when no priority clause is specified is zero (the lowest priority). If a value is specified in the
24 priority clause that is higher than the max-task-priority-var ICV then the implementation will
25 use the value of that ICV. A program that relies on the task execution order being determined by the
26 priority-value may have unspecified behavior.
27 The affinity clause is a hint to indicate data affinity of the generated task. The task is
28 recommended to execute close to the location of the list items. A program that relies on the task
29 execution location being determined by this list may have unspecified behavior.
30 The list items that appear in the affinity clause may reference iterators defined by an
31 iterators-definition that appears in the same clause. The list items that appear in the affinity
32 clause may include array sections.
C / C++
33 The list items that appear in the affinity clause may use shape-operators.
C / C++
34 If a list item appears in an affinity clause then data affinity refers to the original list item.

1
2 Note – When storage is shared by an explicit task region, the programmer must ensure, by
3 adding proper synchronization, that the storage does not reach the end of its lifetime before the
4 explicit task region completes its execution.
5

7 The task-create event occurs when a thread encounters a construct that causes a new task to be
8 created. The event occurs after the task is initialized but before it begins execution or is deferred.
9 Tool Callbacks
10 A thread dispatches a registered ompt_callback_task_create callback for each occurrence
11 of a task-create event in the context of the encountering task. This callback has the type signature
12 ompt_callback_task_create_t and the flags argument indicates the task types shown in
13 Table 2.7.
TABLE 2.7: ompt_callback_task_create Callback Flags Evaluation
Operation Evaluates to true
(flags & ompt_task_explicit) Always in the dispatched callback

(flags & ompt_task_undeferred) If the task is an undeferred task
(flags & ompt_task_final) If the task is a final task
(flags & ompt_task_untied) If the task is an untied task
(flags & ompt_task_mergeable) If the task is a mergeable task
(flags & ompt_task_merged) If the task is a merged task
14 Restrictions
15 Restrictions to the task construct are as follows:
16 • A program must not depend on any ordering of the evaluations of the clauses of the task
17 directive, or on any side effects of the evaluations of the clauses.
19 • At most one final clause can appear on the directive.
20 • At most one priority clause can appear on the directive.
21 • At most one detach clause can appear on the directive.
22 • If a detach clause appears on the directive, then a mergeable clause cannot appear on the
23 same directive.

C / C++
1 • A throw executed inside a task region must cause execution to resume within the same task
2 region, and the same thread that threw the exception must catch it.
C / C++
3 Cross References
4 • Task scheduling constraints, see Section 2.12.6.
8 • Data-sharing attribute clauses, Section 2.21.4.
9 • in_reduction clause, see Section 2.21.5.6.
10 • omp_fulfill_event, see Section 3.11.1.
11 • ompt_callback_task_create_t, see Section 4.5.2.7.
12 2.12.2 taskloop Construct

13 Summary
14 The taskloop construct specifies that the iterations of one or more associated loops will be
15 executed in parallel using explicit tasks. The iterations are distributed across tasks generated by the
16 construct and scheduled to be executed.
17 Syntax
C / C++
18 The syntax of the taskloop construct is as follows:
19 #pragma omp taskloop [clause[[,] clause] ...] new-line
20 loop-nest
22 if([ taskloop :] scalar-expression)
23 shared(list)
24 private(list)

2 grainsize([strict:]grain-size)
3 num_tasks([strict:]num-tasks)
4 collapse(n)
5 final(scalar-expr)
7 untied
8 mergeable
9 nogroup
C / C++
Fortran
11 The syntax of the taskloop construct is as follows:
12 !$omp taskloop [clause[[,] clause] ...]
13 loop-nest
14 [!$omp end taskloop]
16 if([ taskloop :] scalar-logical-expression)
17 shared(list)
18 private(list)
24 grainsize([strict:]grain-size)
25 num_tasks([strict:]num-tasks)
26 collapse(n)
27 final(scalar-logical-expr)
29 untied
30 mergeable

1 nogroup
3 If an end taskloop directive is not specified, an end taskloop directive is assumed at the end
4 of the do-loops.
Fortran
5 Binding
6 The binding thread set of the taskloop region is the current team. A taskloop region binds to
7 the innermost enclosing parallel region.
8 Description
9 The taskloop construct is a task generating construct. When a thread encounters a taskloop
10 construct, the construct partitions the iterations of the associated loops into explicit tasks for
11 parallel execution. The data environment of each generated task is created according to the
12 data-sharing attribute clauses on the taskloop construct, per-data environment ICVs, and any
13 defaults that apply. The order of the creation of the loop tasks is unspecified. Programs that rely on
14 any execution order of the logical iterations are non-conforming.
15 By default, the taskloop construct executes as if it was enclosed in a taskgroup construct
16 with no statements or directives outside of the taskloop construct. Thus, the taskloop
17 construct creates an implicit taskgroup region. If the nogroup clause is present, no implicit
18 taskgroup region is created.
19 If a reduction clause is present, the behavior is as if a task_reduction clause with the
20 same reduction operator and list items was applied to the implicit taskgroup construct that
21 encloses the taskloop construct. The taskloop construct executes as if each generated task
22 was defined by a task construct on which an in_reduction clause with the same reduction
23 operator and list items is present. Thus, the generated tasks are participants of the reduction defined
24 by the task_reduction clause that was applied to the implicit taskgroup construct.
25 If an in_reduction clause is present, the behavior is as if each generated task was defined by a
26 task construct on which an in_reduction clause with the same reduction operator and list
27 items is present. Thus, the generated tasks are participants of a reduction previously defined by a
28 reduction scoping clause.
29 If a grainsize clause is present, the number of logical iterations assigned to each generated task
30 is greater than or equal to the minimum of the value of the grain-size expression and the number of
31 logical iterations, but less than two times the value of the grain-size expression. If the grainsize
32 clause has the strict modifier, the number of logical iterations assigned to each generated task is
33 equal to the value of the grain-size expression, except for the generated task that contains the
34 sequentially last iteration, which may have fewer iterations. The parameter of the grainsize
35 clause must be a positive integer expression.
36 If num_tasks is specified, the taskloop construct creates as many tasks as the minimum of the
37 num-tasks expression and the number of logical iterations. Each task must have at least one logical

1 iteration. The parameter of the num_tasks clause must be a positive integer expression. If the
2 num_tasks clause has the strict modifier for a task loop with N logical iterations, the logical
3 iterations are partitioned in a balanced manner and each partition is assigned, in order, to a
4 generated task. The partition size is dN/num-tasksee until the number of remaining iterations
5 divides the number of remaining tasks evenly, at which point the partition size becomes
6 bN/num-tasksc c.
7 If neither a grainsize nor num_tasks clause is present, the number of loop tasks generated
8 and the number of logical iterations assigned to these tasks is implementation defined.
9 The collapse clause may be used to specify how many loops are associated with the taskloop
10 construct. The parameter of the collapse clause must be a constant positive integer expression.
11 If the collapse clause is omitted, the behavior is as if a collapse clause with a parameter
12 value of one was specified. The collapse clause specifies the number of loops that are collapsed
13 into a logical iteration space that is then divided according to the grainsize and num_tasks
14 clauses.
18 The iteration count for each associated loop is computed before entry to the outermost loop. If
19 execution of any associated loop changes any of the values used to compute any of the iteration
20 counts, then the behavior is unspecified.
21 When an if clause is present and the if clause expression evaluates to false, undeferred tasks are
22 generated. The use of a variable in an if clause expression causes an implicit reference to the
24 When a final clause is present and the final clause expression evaluates to true, the generated
25 tasks are final tasks. The use of a variable in a final clause expression of a taskloop construct
26 causes an implicit reference to the variable in all enclosing constructs.
27 When a priority clause is present, the generated tasks use the priority-value as if it was
28 specified for each individual task. If the priority clause is not specified, tasks generated by the
29 taskloop construct have the default task priority (zero).
30 When the untied clause is present, each generated task is an untied task.
31 When the mergeable clause is present, each generated task is a mergeable task.
C++
32 For firstprivate variables of class type, the number of invocations of copy constructors that
33 perform the initialization is implementation defined.
C++

1
2 Note – When storage is shared by a taskloop region, the programmer must ensure, by adding
3 proper synchronization, that the storage does not reach the end of its lifetime before the taskloop
4 region and its descendant tasks complete their execution.
5

7 The taskloop-begin event occurs after a task encounters a taskloop construct but before any
8 other events that may trigger as a consequence of executing the taskloop region. Specifically, a
9 taskloop-begin event for a taskloop region will precede the taskgroup-begin that occurs unless a
10 nogroup clause is present. Regardless of whether an implicit taskgroup is present, a
11 taskloop-begin will always precede any task-create events for generated tasks.
12 The taskloop-end event occurs after a taskloop region finishes execution but before resuming
13 execution of the encountering task.
14 The taskloop-iteration-begin event occurs before an explicit task executes each iteration of a
15 taskloop region.
16 Tool Callbacks
17 A thread dispatches a registered ompt_callback_work callback for each occurrence of a
18 taskloop-begin and taskloop-end event in that thread. The callback occurs in the context of the
19 encountering task. The callback has type signature ompt_callback_work_t. The callback
20 receives ompt_scope_begin or ompt_scope_end as its endpoint argument, as appropriate,
21 and ompt_work_taskloop as its wstype argument.
23 taskloop-iteration-begin event in that thread. The callback occurs in the context of the encountering
24 task. The callback has type signature ompt_callback_dispatch_t.
25 Restrictions
26 Restrictions to the taskloop construct are as follows:
27 • If a reduction clause is present, the nogroup clause must not be specified.
28 • The same list item cannot appear in both a reduction and an in_reduction clause.
29 • At most one grainsize clause can appear on the directive.
30 • At most one num_tasks clause can appear on the directive.
31 • Neither the grainsize clause nor the num_tasks clause may appear on the directive if any
32 of the associated loops is a non-rectangular loop.
33 • The grainsize clause and num_tasks clause are mutually exclusive and may not appear on
34 the same taskloop directive.
35 • At most one collapse clause can appear on the directive.

2 • At most one final clause can appear on the directive.
3 • At most one priority clause can appear on the directive.
4 Cross References
7 • task construct, Section 2.12.1.
9 • taskgroup construct, Section 2.19.6.
10 • Data-sharing attribute clauses, Section 2.21.4.
12 • ompt_work_taskloop, see Section 4.4.4.15.
14 • ompt_callback_dispatch_t, see Section 4.5.2.6.
15 2.12.3 taskloop simd Construct

16 Summary
17 The taskloop simd construct specifies a loop that can be executed concurrently using SIMD
18 instructions and that those iterations will also be executed in parallel using explicit tasks. The
19 taskloop simd construct is a composite construct.
20 Syntax
C / C++
21 The syntax of the taskloop simd construct is as follows:
22 #pragma omp taskloop simd [clause[[,] clause] ...] new-line
23 loop-nest
25 taskloop or simd directives with identical meanings and restrictions.
C / C++

Fortran
1 The syntax of the taskloop simd construct is as follows:
2 !$omp taskloop simd [clause[[,] clause] ...]
3 loop-nest
4 [!$omp end taskloop simd]
6 taskloop or simd directives with identical meanings and restrictions.
7 If an end taskloop simd directive is not specified, an end taskloop simd directive is
8 assumed at the end of the do-loops.
Fortran
9 Binding
10 The binding thread set of the taskloop simd region is the current team. A taskloop simd
11 region binds to the innermost enclosing parallel region.
12 Description
13 The taskloop simd construct first distributes the iterations of the associated loops across tasks
14 in a manner consistent with any clauses that apply to the taskloop construct. The resulting tasks
15 are then converted to a SIMD loop in a manner consistent with any clauses that apply to the simd
16 construct, except for the collapse clause. For the purposes of each task’s conversion to a SIMD
17 loop, the collapse clause is ignored and the effect of any in_reduction clause is as if a
18 reduction clause with the same reduction operator and list items is present on the simd
19 construct.

21 This composite construct generates the same events as the taskloop construct.
22 Tool Callbacks
23 This composite construct dispatches the same callbacks as the taskloop construct.
24 Restrictions
25 Restrictions to the taskloop simd construct are as follows:
26 • The restrictions for the taskloop and simd constructs apply.
31 • At most one if clause with the taskloop directive-name-modifier can appear on the directive.

1 Cross References
6 2.12.4 taskyield Construct

7 Summary
8 The taskyield construct specifies that the current task can be suspended in favor of execution of
9 a different task. The taskyield construct is a stand-alone directive.
10 Syntax
C / C++
11 The syntax of the taskyield construct is as follows:
12 #pragma omp taskyield new-line
C / C++
Fortran
13 The syntax of the taskyield construct is as follows:
14 !$omp taskyield
Fortran
15 Binding
16 A taskyield region binds to the current task region. The binding thread set of the taskyield
17 region is the current team.
18 Description
19 The taskyield region includes an explicit task scheduling point in the current task region.
20 Cross References
21 • Task scheduling, see Section 2.12.6.

1 2.12.5 Initial Task
3 No events are associated with the implicit parallel region in each initial thread.
4 The initial-thread-begin event occurs in an initial thread after the OpenMP runtime invokes the tool
5 initializer but before the initial thread begins to execute the first OpenMP region in the initial task.
6 The initial-task-begin event occurs after an initial-thread-begin event but before the first OpenMP
7 region in the initial task begins to execute.
8 The initial-task-end event occurs before an initial-thread-end event but after the last OpenMP
9 region in the initial task finishes execution.
10 The initial-thread-end event occurs as the final event in an initial thread at the end of an initial task
11 immediately prior to invocation of the tool finalizer.
12 Tool Callbacks
14 initial-thread-begin event in an initial thread. The callback occurs in the context of the initial
15 thread. The callback has type signature ompt_callback_thread_begin_t. The callback
16 receives ompt_thread_initial as its thread_type argument.
18 ompt_scope_begin as its endpoint argument for each occurrence of an initial-task-begin event
19 in that thread. Similarly, a thread dispatches a registered ompt_callback_implicit_task
20 callback with ompt_scope_end as its endpoint argument for each occurrence of an
21 initial-task-end event in that thread. The callbacks occur in the context of the initial task and have
22 type signature ompt_callback_implicit_task_t. In the dispatched callback,
23 (flag & ompt_task_initial) always evaluates to true.
25 initial-thread-end event in that thread. The callback occurs in the context of the thread. The
26 callback has type signature ompt_callback_thread_end_t. The implicit parallel region
27 does not dispatch a ompt_callback_parallel_end callback; however, the implicit parallel
28 region can be finalized within this ompt_callback_thread_end callback.
29 Cross References
30 • ompt_thread_initial, see Section 4.4.4.10.
31 • ompt_task_initial, see Section 4.4.4.18.

1 2.12.6 Task Scheduling
2 Whenever a thread reaches a task scheduling point, the implementation may cause it to perform a
3 task switch, beginning or resuming execution of a different task bound to the current team. Task
4 scheduling points are implied at the following locations:
5 • during the generation of an explicit task;
6 • the point immediately following the generation of an explicit task;
7 • after the point of completion of the structured block associated with a task;
8 • in a taskyield region;
9 • in a taskwait region;
10 • at the end of a taskgroup region;
11 • in an implicit barrier region;
12 • in an explicit barrier region;
13 • during the generation of a target region;
14 • the point immediately following the generation of a target region;
15 • at the beginning and end of a target data region;
16 • in a target update region;
17 • in a target enter data region;
18 • in a target exit data region;
19 • in the omp_target_memcpy routine;
20 • in the omp_target_memcpy_async routine;
21 • in the omp_target_memcpy_rect routine; and
22 • in the omp_target_memcpy_rect_async routine.
23 When a thread encounters a task scheduling point it may do one of the following, subject to the
24 Task Scheduling Constraints (below):
25 • begin execution of a tied task bound to the current team;
26 • resume any suspended task region, bound to the current team, to which it is tied;
27 • begin execution of an untied task bound to the current team; or
28 • resume any suspended untied task region bound to the current team.
29 If more than one of the above choices is available, which one is chosen is unspecified.

1 Task Scheduling Constraints are as follows:
2 1. Scheduling of new tied tasks is constrained by the set of task regions that are currently tied to the
3 thread and that are not suspended in a barrier region. If this set is empty, any new tied task may
4 be scheduled. Otherwise, a new tied task may be scheduled only if it is a descendant task of
5 every task in the set.
6 2. A dependent task shall not start its execution until its task dependences are fulfilled.
7 3. A task shall not be scheduled while any task with which it is mutually exclusive has been
8 scheduled but has not yet completed.
9 4. When an explicit task is generated by a construct that contains an if clause for which the
10 expression evaluated to false, and the previous constraints are already met, the task is executed
11 immediately after generation of the task.
12 A program that relies on any other assumption about task scheduling is non-conforming.
13
14 Note – Task scheduling points dynamically divide task regions into parts. Each part is executed
15 uninterrupted from start to end. Different parts of the same task region are executed in the order in
16 which they are encountered. In the absence of task synchronization constructs, the order in which a
17 thread executes parts of different schedulable tasks is unspecified.
18 A program must behave correctly and consistently with all conceivable scheduling sequences that
19 are compatible with the rules above.
20 For example, if threadprivate storage is accessed (explicitly in the source code or implicitly
21 in calls to library routines) in one part of a task region, its value cannot be assumed to be preserved
22 into the next part of the same task region if another schedulable task exists that modifies it.
23 As another example, if a lock acquire and release happen in different parts of a task region, no
24 attempt should be made to acquire the same lock in any part of another task that the executing
25 thread may schedule. Otherwise, a deadlock is possible. A similar situation can occur when a
26 critical region spans multiple parts of a task and another schedulable task contains a
27 critical region with the same name.
28 The use of threadprivate variables and the use of locks or critical sections in an explicit task with an
29 if clause must take into account that when the if clause evaluates to false, the task is executed
30 immediately, without regard to Task Scheduling Constraint 2.
31

33 The task-schedule event occurs in a thread when the thread switches tasks at a task scheduling
34 point; no event occurs when switching to or from a merged task.

1 Tool Callbacks
2 A thread dispatches a registered ompt_callback_task_schedule callback for each
3 occurrence of a task-schedule event in the context of the task that begins or resumes. This callback
4 has the type signature ompt_callback_task_schedule_t. The argument prior_task_status
5 is used to indicate the cause for suspending the prior task. This cause may be the completion of the
6 prior task region, the encountering of a taskyield construct, or the encountering of an active
7 cancellation point.
8 Cross References
9 • ompt_callback_task_schedule_t, see Section 4.5.2.10.
10 2.13 Memory Management Directives

11 2.13.1 Memory Spaces
12 OpenMP memory spaces represent storage resources where variables can be stored and retrieved.
13 Table 2.8 shows the list of predefined memory spaces. The selection of a given memory space
14 expresses an intent to use storage with certain traits for the allocations. The actual storage resources
15 that each memory space represents are implementation defined.
TABLE 2.8: Predefined Memory Spaces
Memory space name Storage selection intent
omp_default_mem_space Represents the system default storage

omp_large_cap_mem_space Represents storage with large capacity
omp_const_mem_space Represents storage optimized for variables with
constant values
omp_high_bw_mem_space Represents storage with high bandwidth
omp_low_lat_mem_space Represents storage with low latency
16 Variables allocated in the omp_const_mem_space memory space may be initialized through
17 the firstprivate clause or with compile time constants for static and constant variables.
18 Implementation-defined mechanisms to provide the constant value of these variables may also be
19 supported.
20 Restrictions
21 Restrictions to OpenMP memory spaces are as follows:
22 • Variables in the omp_const_mem_space memory space may not be written.

1 Cross References
2 • omp_init_allocator routine, see Section 3.13.2.
3 2.13.2 Memory Allocators

4 OpenMP memory allocators can be used by a program to make allocation requests. When a
5 memory allocator receives a request to allocate storage of a certain size, an allocation of logically
6 consecutive memory in the resources of its associated memory space of at least the size that was
7 requested will be returned if possible. This allocation will not overlap with any other existing
8 allocation from an OpenMP memory allocator.
9 The behavior of the allocation process can be affected by the allocator traits that the user specifies.
10 Table 2.9 shows the allowed allocator traits, their possible values and the default value of each trait.
TABLE 2.9: Allocator Traits
Allocator trait Allowed values Default value
sync_hint contended, uncontended, contended

serialized, private
alignment A positive integer value that is a power of 1 byte
2
access all, cgroup, pteam, thread all
pool_size Positive integer value Implementation
defined
fallback default_mem_fb, null_fb, default_mem_fb
abort_fb, allocator_fb
fb_data an allocator handle (none)
pinned true, false false
partition environment, nearest, blocked, environment
interleaved
11 The sync_hint trait describes the expected manner in which multiple threads may use the
12 allocator. The values and their descriptions are:
13 • contended: high contention is expected on the allocator; that is, many threads are expected to
14 request allocations simultaneously.
15 • uncontended: low contention is expected on the allocator; that is, few threads are expected to
16 request allocations simultaneously.

1 • serialized: only one thread at a time will request allocations with the allocator. Requesting
2 two allocations simultaneously when specifying serialized results in unspecified behavior.
3 • private: the same thread will request allocations with the allocator every time. Requesting an
4 allocation from different threads, simultaneously or not, when specifying private results in
5 unspecified behavior.
6 Allocated memory will be byte aligned to at least the value specified for the alignment trait of
7 the allocator. Some directives and API routines can specify additional requirements on alignment
8 beyond those described in this section.
9 Memory allocated by allocators with the access trait defined to be all must be accessible by all
10 threads in the device where the allocation was requested. Memory allocated by allocators with the
11 access trait defined to be cgroup will be memory accessible by all threads in the same
12 contention group as the thread that requested the allocation. Attempts to access the memory
13 returned by an allocator with the access trait defined to be cgroup from a thread that is not part
14 of the same contention group as the thread that allocated the memory result in unspecified behavior.
15 Memory allocated by allocators with the access trait defined to be pteam will be memory
16 accessible by all threads that bind to the same parallel region of the thread that requested the
17 allocation. Attempts to access the memory returned by an allocator with the access trait defined
18 to be pteam from a thread that does not bind to the same parallel region as the thread that
19 allocated the memory result in unspecified behavior. Memory allocated by allocators with the
20 access trait defined to be thread will be memory accessible by the thread that requested the
21 allocation. Attempts to access the memory returned by an allocator with the access trait defined
22 to be thread from a thread other than the one that allocated the memory result in unspecified
23 behavior.
24 The total amount of storage in bytes that an allocator can use is limited by the pool_size trait.
25 For allocators with the access trait defined to be all, this limit refers to allocations from all
26 threads that access the allocator. For allocators with the access trait defined to be cgroup, this
27 limit refers to allocations from threads that access the allocator from the same contention group. For
28 allocators with the access trait defined to be pteam, this limit refers to allocations from threads
29 that access the allocator from the same parallel team. For allocators with the access trait defined
30 to be thread, this limit refers to allocations from each thread that accesses the allocator. Requests
31 that would result in using more storage than pool_size will not be fulfilled by the allocator.
32 The fallback trait specifies how the allocator behaves when it cannot fulfill an allocation
33 request. If the fallback trait is set to null_fb, the allocator returns the value zero if it fails to
34 allocate the memory. If the fallback trait is set to abort_fb, program execution will be
35 terminated if the allocation fails. If the fallback trait is set to allocator_fb then when an
36 allocation fails the request will be delegated to the allocator specified in the fb_data trait. If the
37 fallback trait is set to default_mem_fb then when an allocation fails another allocation will
38 be tried in omp_default_mem_space, which assumes all allocator traits to be set to their
39 default values except for fallback trait, which will be set to null_fb.

1 Allocators with the pinned trait defined to be true ensure that their allocations remain in the
2 same storage resource at the same location for their entire lifetime.
3 The partition trait describes the partitioning of allocated memory over the storage resources
4 represented by the memory space associated with the allocator. The partitioning will be done in
5 parts with a minimum size that is implementation defined. The values are:
6 • environment: the placement of allocated memory is determined by the execution
7 environment;
8 • nearest: allocated memory is placed in the storage resource that is nearest to the thread that
9 requests the allocation;
10 • blocked: allocated memory is partitioned into parts of approximately the same size with at
11 most one part per storage resource; and
12 • interleaved: allocated memory parts are distributed in a round-robin fashion across the
13 storage resources.
14 Table 2.10 shows the list of predefined memory allocators and their associated memory spaces. The
15 predefined memory allocators have default values for their allocator traits unless otherwise
16 specified.
TABLE 2.10: Predefined Allocators
Allocator name Associated memory space Non-default trait

values
omp_default_mem_alloc omp_default_mem_space fallback:null_fb

omp_large_cap_mem_alloc omp_large_cap_mem_space (none)
omp_const_mem_alloc omp_const_mem_space (none)
omp_high_bw_mem_alloc omp_high_bw_mem_space (none)
omp_low_lat_mem_alloc omp_low_lat_mem_space (none)
omp_cgroup_mem_alloc Implementation defined access:cgroup
omp_pteam_mem_alloc Implementation defined access:pteam
omp_thread_mem_alloc Implementation defined access:thread
Fortran
17 If any operation of the base language causes a reallocation of a variable that is allocated with a
18 memory allocator then that memory allocator will be used to deallocate the current memory and to
19 allocate the new memory. For allocated allocatable components of such variables, the allocator that
20 will be used for the deallocation and allocation is unspecified.
Fortran

1 Cross References
2 • omp_init_allocator routine, see Section 3.13.2.
3 • omp_destroy_allocator routine, see Section 3.13.3.
6 • OMP_ALLOCATOR environment variable, see Section 6.22.
7 2.13.3 allocate Directive

8 Summary
9 The allocate directive specifies how to allocate the specified variables. The allocate
10 directive is a declarative directive if it is not associated with an allocation statement.
11 Syntax
C / C++
12 The syntax of the allocate directive is as follows:
13 #pragma omp allocate(list) [clause[ [,] clause] ... ] new-line

15 allocator(allocator)
16 align(alignment)
17 where allocator is an expression of omp_allocator_handle_t type and alignment is a

18 constant positive integer expression with a value that is a power of two.
C / C++
Fortran
19 The syntax of the allocate directive is as follows:
20 !$omp allocate(list) [clause[ [,] clause] ... ]
21 or
22 !$omp allocate[(list)] [clause[ [,] clause] ... ]
23 [!$omp allocate[(list)] [clause[ [,] clause] ... ]
24 [...]]
25 allocate-stmt
26 where allocate-stmt is a Fortran ALLOCATE statement and clause is one of the following:
28 align(alignment)

1 where allocator is an integer expression of omp_allocator_handle_kind kind and
2 alignment is a constant scalar positive integer expression with a value that is a power of two.
Fortran
3 Description
4 The storage for each list item that appears in the allocate directive is provided by an allocation
5 through a memory allocator. If no allocator clause is specified then the memory allocator
6 specified by the def-allocator-var ICV is used. If the allocator clause is specified, the memory
7 allocator specified in the clause is used. If the align clause is specified then the allocation of each
8 list item is byte aligned to at least the maximum of the alignment required by the base language for
9 the type of that list item, the alignment trait of the allocator and the alignment value of the
10 align clause. If the align clause is not specified then the allocation of each list item is byte
11 aligned to at least the maximum of the alignment required by the base language for the type of that
12 list item and the alignment trait of the allocator.
13 The scope of this allocation is that of the list item in the base language. At the end of the scope for a
14 given list item the memory allocator used to allocate that list item deallocates the storage.
Fortran
15 If the directive is associated with an allocate-stmt, the allocate-stmt allocates all list items that
16 appear in the directive list using the specified memory allocator. If no list items are specified then
17 all variables that are listed by the allocate-stmt and are not listed in an allocate directive
18 associated with the statement are allocated with the specified memory allocator.
Fortran
19 For allocations that arise from this directive the null_fb value of the fallback allocator trait
20 behaves as if the abort_fb had been specified.
21 Restrictions
22 Restrictions to the allocate directive are as follows:
23 • At most one allocator clause may appear on the directive.
24 • At most one align clause may appear on the directive.
25 • A variable that is part of another variable (as an array or structure element) cannot appear in a
26 declarative allocate directive.
27 • A declarative allocate directive must appear in the same scope as the declarations of each of
28 its list items and must follow all such declarations.
29 • A declared variable may appear as a list item in at most one declarative allocate directive in a
30 given compilation unit.
31 • At most one allocator clause can appear on the allocate directive.

1 • allocate directives that appear in a target region must specify an allocator clause
2 unless a requires directive with the dynamic_allocators clause is present in the same
3 compilation unit.
C / C++
4 • If a list item has static storage duration, the allocator clause must be specified and the
5 allocator expression in the clause must be a constant expression that evaluates to one of the
6 predefined memory allocator values.
7 • A variable that is declared in a namespace or global scope may only appear as a list item in an
8 allocate directive if an allocate directive that lists the variable follows a declaration that
9 defines the variable and if all allocate directives that list the variable specify the same
10 allocator.
C / C++
C
11 • After a list item has been allocated, the scope that contains the allocate directive must not
12 end abnormally, such as through a call to the longjmp function.
C
C++
13 • After a list item has been allocated, the scope that contains the allocate directive must not end
14 abnormally, such as through a call to the longjmp function, other than through C++ exceptions.
15 • A variable that has a reference type may not appear as a list item in an allocate directive.
C++
Fortran
16 • An allocate directive that is associated with an allocate-stmt and specifies a list must be
17 preceded by an executable statement or OpenMP construct.
18 • A list item that is specified in a declarative allocate directive must not have the
19 ALLOCATABLE or POINTER attribute.
20 • If a list item is specified in an allocate directive that is associated with an allocate-stmt, it
21 must appear as one of the data objects in the allocation list of that statement.
22 • A list item may not be specified more than once in an allocate directive that is associated
23 with an allocate-stmt.
24 • If multiple directives are associated with an allocate-stmt then at most one directive may specify
25 no list items.
26 • If a list item has the SAVE attribute, either explicitly or implicitly, or is a common block name
27 then the allocator clause must be specified and only predefined memory allocator
28 parameters can be used in the clause.
29 • A variable that is part of a common block may not be specified as a list item in an allocate
30 directive, except implicitly via the named common block.

1 • A named common block may appear as a list item in at most one allocate directive in a given
2 compilation unit.
3 • If a named common block appears as a list item in an allocate directive, it must appear as a
4 list item in an allocate directive that specifies the same allocator in every compilation unit in
5 which the common block is used.
6 • An associate name may not appear as a list item in an allocate directive.
7 • A type parameter inquiry cannot appear in an allocate directive.
Fortran
8 Cross References
9 • def-allocator-var ICV, see Section 2.4.1.
10 • Memory allocators, see Section 2.13.2.
11 • omp_allocator_handle_t and omp_allocator_handle_kind, see Section 3.13.1.
12 2.13.4 allocate Clause

13 Summary
14 The allocate clause specifies the memory allocator to be used to obtain storage for private
15 variables of a directive.
16 Syntax
17 The syntax of the allocate clause is one of the following:
18 allocate([allocator:] list)
19 allocate(allocate-modifier [, allocate-modifier]: list)
20 where allocate-modifier is one of the following:

22 align(alignment)
23 where alignment is a constant positive integer expression with a value that is a power of two; and
C / C++
24 where allocator is an expression of the omp_allocator_handle_t type.
C / C++
Fortran
25 where allocator is an integer expression of the omp_allocator_handle_kind kind.
Fortran

1 Description
2 The storage for new list items that arise from list items that appear in the directive is provided
3 through a memory allocator. If an allocator is specified in the clause, that allocator is used for
4 allocations. If no allocator is specified in the clause and the directive is not a target directive
5 then the memory allocator that is specified by the def-allocator-var ICV is used for the list items
6 that are specified in the allocate clause. If no allocator is specified in the clause and the
7 directive is a target directive the behavior is unspecified. If the align allocate-modifier is
8 specified then the allocation of each list item is byte aligned to at least the maximum of the
9 alignment required by the base language for the type of that list item, the alignment trait of the
10 allocator and the alignment value of the align allocate-modifier.If the align allocate-modifier
11 is not specified then the allocation of each list item is byte aligned to at least the maximum of the
12 alignment required by the base language for the type of that list item and the alignment trait of
13 the allocator.
14 For allocations that arise from this clause the null_fb value of the fallback allocator trait behaves
15 as if the abort_fb had been specified.
16 Restrictions
17 Restrictions to the allocate clause are as follows:
18 • At most one allocator allocate-modifier may be specified on the clause.
19 • At most one align allocate-modifier may be specified on the clause.
20 • For any list item that is specified in the allocate clause on a directive, a data-sharing attribute
21 clause that may create a private copy of that list item must be specified on the same directive.
22 • For task, taskloop or target directives, allocation requests to memory allocators with the
23 trait access set to thread result in unspecified behavior.
24 • allocate clauses that appear on a target construct or on constructs in a target region
25 must specify an allocator expression unless a requires directive with the
26 dynamic_allocators clause is present in the same compilation unit.
27 Cross References
28 • def-allocator-var ICV, see Section 2.4.1.
30 • List Item Privatization, see Section 2.21.3.
31 • omp_allocator_handle_t and omp_allocator_handle_kind, see Section 3.13.1.

1 2.14 Device Directives
2 2.14.1 Device Initialization
4 The device-initialize event occurs in a thread that encounters the first target, target data, or
5 target enter data construct or a device memory routine that is associated with a particular
6 target device after the thread initiates initialization of OpenMP on the device and the device’s
7 OpenMP initialization, which may include device-side tool initialization, completes.
8 The device-load event for a code block for a target device occurs in some thread before any thread
9 executes code from that code block on that target device.
10 The device-unload event for a target device occurs in some thread whenever a code block is
11 unloaded from the device.
12 The device-finalize event for a target device that has been initialized occurs in some thread before
13 an OpenMP implementation shuts down.
14 Tool Callbacks
15 A thread dispatches a registered ompt_callback_device_initialize callback for each
16 occurrence of a device-initialize event in that thread. This callback has type signature
17 ompt_callback_device_initialize_t.
18 A thread dispatches a registered ompt_callback_device_load callback for each occurrence
19 of a device-load event in that thread. This callback has type signature
20 ompt_callback_device_load_t.
21 A thread dispatches a registered ompt_callback_device_unload callback for each
22 occurrence of a device-unload event in that thread. This callback has type signature
23 ompt_callback_device_unload_t.
24 A thread dispatches a registered ompt_callback_device_finalize callback for each
25 occurrence of a device-finalize event in that thread. This callback has type signature
26 ompt_callback_device_finalize_t.
27 Restrictions
28 Restrictions to OpenMP device initialization are as follows:
29 • No thread may offload execution of an OpenMP construct to a device until a dispatched
30 ompt_callback_device_initialize callback completes.
31 • No thread may offload execution of an OpenMP construct to a device after a dispatched
32 ompt_callback_device_finalize callback occurs.

1 Cross References
2 • ompt_callback_device_initialize_t, see Section 4.5.2.19.
3 • ompt_callback_device_finalize_t, see Section 4.5.2.20.
4 • ompt_callback_device_load_t, see Section 4.5.2.21.
5 • ompt_callback_device_unload_t, see Section 4.5.2.22.
6 2.14.2 target data Construct

7 Summary
8 The target data construct maps variables to a device data environment for the extent of the
9 region.
10 Syntax
C / C++
11 The syntax of the target data construct is as follows:
12 #pragma omp target data clause[ [ [,] clause] ... ] new-line
13 structured-block

15 if([ target data :] scalar-expression)
17 map([[map-type-modifier[,] [map-type-modifier[,] ...]] map-type: ] locator-list)
18 use_device_ptr(list)
19 use_device_addr(list)
C / C++
Fortran
20 The syntax of the target data construct is as follows:
21 !$omp target data clause[ [ [,] clause] ... ]
23 !$omp end target data
24 or
25 !$omp target data clause[ [ [,] clause] ... ]
27 [!$omp end target data]

2 if([ target data :] scalar-logical-expression)
5 use_device_ptr(list)
6 use_device_addr(list)
Fortran
7 Binding
8 The binding task set for a target data region is the generating task. The target data region
9 binds to the region of the generating task.
10 Description
11 When a target data construct is encountered, the encountering task executes the region. If no
12 device clause is present, the behavior is as if the device clause appeared with an expression
13 equal to the value of the default-device-var ICV. When an if clause is present and the if clause
14 expression evaluates to false, the target device is the host. Variables are mapped for the extent of the
15 region, according to any data-mapping attribute clauses, from the data environment of the
16 encountering task to the device data environment.
17 If a list item that appears in a use_device_addr clause has corresponding storage in the device
18 data environment, references to the list item in the associated structured block are converted into
19 references to the corresponding list item. If the list item is not a mapped list item, it is assumed to
20 be accessible on the target device. Inside the structured block, the list item has a device address and
21 its storage may not be accessible from the host device. The list items that appear in a
22 use_device_addr clause may include array sections.
C / C++
23 If a list item in a use_device_addr clause is an array section that has a base pointer, the effect
24 of the clause is to convert the base pointer to a pointer that is local to the structured block and that
25 contains the device address. This conversion may be elided if the list item was not already mapped.
26 If a list item that appears in a use_device_ptr clause is a pointer to an object that is mapped to
27 the device data environment, references to the list item in the associated structured block are
28 converted into references to a device pointer that is local to the structured block and that refers to
29 the device address of the corresponding object. If the list item does not point to a mapped object, it
30 must contain a valid device address for the target device, and the list item references are instead
31 converted to references to a local device pointer that refers to this device address.
C / C++

Fortran
1 If a list item that appears in a use_device_ptr clause is of type C_PTR and points to a data
2 entity that is mapped to the device data environment, references to the list item in the associated
3 structured block are converted into references to a device pointer that is local to the structured block
4 and that refers to the device address of the corresponding entity. If a list item of type C_PTR does
5 not point to a mapped object, it must contain a valid device address for the target device, and the list
6 item references are instead converted to references to a local device pointer that refers to this device
7 address.
8 If a list item in a use_device_ptr clause is not of type C_PTR, the behavior is as if the list item
9 appeared in a use_device_addr clause. Support for such list items in a use_device_ptr
10 clause is deprecated.
Fortran
11 If one or more map clauses are present, the list item conversions that are performed for any
12 use_device_ptr or use_device_addr clause occur after all variables are mapped on entry
13 to the region according to those map clauses.

15 The events associated with entering a target data region are the same events as associated with
16 a target enter data construct, as described in Section 2.14.3.
17 The events associated with exiting a target data region are the same events as associated with a
18 target exit data construct, as described in Section 2.14.4.
19 Tool Callbacks
20 The tool callbacks dispatched when entering a target data region are the same as the tool
21 callbacks dispatched when encountering a target enter data construct, as described in
22 Section 2.14.3.
23 The tool callbacks dispatched when exiting a target data region are the same as the tool
24 callbacks dispatched when encountering a target exit data construct, as described in
25 Section 2.14.4.
26 Restrictions
27 Restrictions to the target data construct are as follows:
28 • A program must not depend on any ordering of the evaluations of the clauses of the
29 target data directive, except as explicitly stated for map clauses and for map clauses relative
30 to use_device_ptr and use_device_addr clauses, or on any side effects of the
31 evaluations of the clauses.
32 • At most one device clause can appear on the directive. The device clause expression must
33 evaluate to a non-negative integer value that is less than or equal to the value of
34 omp_get_num_devices().

2 • A map-type in a map clause must be to, from, tofrom or alloc.
3 • At least one map, use_device_addr or use_device_ptr clause must appear on the
4 directive.
5 • A list item may not be specified more than once in use_device_ptr clauses that appear on
6 the directive.
7 • A list item may not be specified more than once in use_device_addr clauses that appear on
8 the directive.
9 • A list item may not be specified in both a use_device_addr clause and a
10 use_device_ptr clause on the directive.
11 • A list item in a use_device_addr clause must have a corresponding list item in the device
12 data environment or be accessible on the target device.
13 • A list item that appears in a use_device_ptr or use_device_addr clause must not be a
14 structure element.
C / C++
15 • A list item in a use_device_ptr clause must be a pointer for which the value is the address
16 of an object that has corresponding storage in the device data environment or is accessible on the
17 target device.
18 • If a list item in a use_device_addr clause is an array section, the base expression must be a
19 base language identifier.
C / C++
Fortran
20 • The value of a list item in a use_device_ptr clause that is of type C_PTR must be the
21 address of a data entity that has corresponding storage in the device data environment or is
22 accessible on the target device.
23 • If a list item in a use_device_addr clause is an array section, the designator of the base
24 expression must be a name without any selectors.
Fortran
25 Cross References
26 • default-device-var, see Section 2.4.
28 • map clause, see Section 2.21.7.1.
29 • omp_get_num_devices routine, see Section 3.7.4.

1 2.14.3 target enter data Construct
2 Summary
3 The target enter data directive specifies that variables are mapped to a device data
4 environment. The target enter data directive is a stand-alone directive.
5 Syntax
C / C++
6 The syntax of the target enter data construct is as follows:
7 #pragma omp target enter data [clause[ [,] clause] ... ] new-line

9 if([ target enter data :] scalar-expression)
11 map([map-type-modifier[,] [map-type-modifier[,] ...]] map-type: locator-list)
13 nowait
C / C++
Fortran
14 The syntax of the target enter data is as follows:
15 !$omp target enter data [clause[ [,] clause] ... ]

17 if([ target enter data :] scalar-logical-expression)
21 nowait
Fortran
22 Binding
23 The binding task set for a target enter data region is the generating task, which is the target
24 task generated by the target enter data construct. The target enter data region binds
25 to the corresponding target task region.

1 Description
2 When a target enter data construct is encountered, the list items are mapped to the device
3 data environment according to the map clause semantics.
4 The target enter data construct is a task generating construct. The generated task is a target
5 task. The generated task region encloses the target enter data region.
6 All clauses are evaluated when the target enter data construct is encountered. The data
7 environment of the target task is created according to the data-mapping attribute clauses on the
8 target enter data construct, per-data environment ICVs, and any default data-sharing
9 attribute rules that apply to the target enter data construct. If a variable or part of a variable
10 is mapped by the target enter data construct, the variable has a default data-sharing attribute
11 of shared in the data environment of the target task.
12 Assignment operations associated with mapping a variable (see Section 2.21.7.1) occur when the
13 target task executes.
14 If the nowait clause is present, execution of the target task may be deferred. If the nowait
15 clause is not present, the target task is an included task.
16 If a depend clause is present, it is associated with the target task.
17 If no device clause is present, the behavior is as if the device clause appears with an expression
18 equal to the value of the default-device-var ICV.
19 When an if clause is present and the if clause expression evaluates to false, the target device is
20 the host.

22 Events associated with a target task are the same as for the task construct defined in
23 Section 2.12.1.
24 The target-enter-data-begin event occurs when a thread enters a target enter data region.
25 The target-enter-data-end event occurs when a thread exits a target enter data region.
26 Tool Callbacks
27 Callbacks associated with events for target tasks are the same as for the task construct defined in
28 Section 2.12.1; (flags & ompt_task_target) always evaluates to true in the dispatched
29 callback.
30 A thread dispatches a registered ompt_callback_target or
31 ompt_callback_target_emi callback with ompt_scope_begin as its endpoint
32 argument and ompt_target_enter_data or ompt_target_enter_data_nowait if
33 the nowait clause is present as its kind argument for each occurrence of a target-enter-data-begin
34 event in that thread in the context of the target task on the host. Similarly, a thread dispatches a
35 registered ompt_callback_target or ompt_callback_target_emi callback with
36 ompt_scope_end as its endpoint argument and ompt_target_enter_data or

1 ompt_target_enter_data_nowait if the nowait clause is present as its kind argument
2 for each occurrence of a target-enter-data-end event in that thread in the context of the target task
3 on the host. These callbacks have type signature ompt_callback_target_t or
4 ompt_callback_target_emi_t, respectively.
5 Restrictions
6 Restrictions to the target enter data construct are as follows:
8 target enter data directive, or on any side effects of the evaluations of the clauses.
9 • At least one map clause must appear on the directive.
14 • A map-type must be specified in all map clauses and must be either to or alloc.
15 • At most one nowait clause can appear on the directive.
16 Cross References
17 • default-device-var, see Section 2.4.1.
18 • task, see Section 2.12.1.
19 • task scheduling constraints, see Section 2.12.6.
20 • target data, see Section 2.14.2.
21 • target exit data, see Section 2.14.4.
25 • ompt_callback_target_t and ompt_callback_target_emi_t callback type, see
26 Section 4.5.2.26.
27 2.14.4 target exit data Construct

28 Summary
29 The target exit data directive specifies that list items are unmapped from a device data
30 environment. The target exit data directive is a stand-alone directive.

1 Syntax
C / C++
2 The syntax of the target exit data construct is as follows:
3 #pragma omp target exit data [clause[ [,] clause] ... ] new-line

5 if([ target exit data :] scalar-expression)
9 nowait
C / C++
Fortran
10 The syntax of the target exit data is as follows:
11 !$omp target exit data [clause[ [,] clause] ... ]

13 if([ target exit data :] scalar-logical-expression)
17 nowait
Fortran
18 Binding
19 The binding task set for a target exit data region is the generating task, which is the target
20 task generated by the target exit data construct. The target exit data region binds to
21 the corresponding target task region.
22 Description
23 When a target exit data construct is encountered, the list items in the map clauses are
24 unmapped from the device data environment according to the map clause semantics.
25 The target exit data construct is a task generating construct. The generated task is a target
26 task. The generated task region encloses the target exit data region.

1 All clauses are evaluated when the target exit data construct is encountered. The data
2 environment of the target task is created according to the data-mapping attribute clauses on the
3 target exit data construct, per-data environment ICVs, and any default data-sharing attribute
4 rules that apply to the target exit data construct. If a variable or part of a variable is mapped
5 by the target exit data construct, the variable has a default data-sharing attribute of shared in
6 the data environment of the target task.
12 If no device clause is present, the behavior is as if the device clause appears with an expression
14 When an if clause is present and the if clause expression evaluates to false, the target device is
15 the host.

18 Section 2.12.1.
19 The target-exit-data-begin event occurs when a thread enters a target exit data region.
20 The target-exit-data-end event occurs when a thread exits a target exit data region.
21 Tool Callbacks
24 callback.
27 argument and ompt_target_exit_data or ompt_target_exit_data_nowait if the
28 nowait clause is present as its kind argument for each occurrence of a target-exit-data-begin
29 event in that thread in the context of the target task on the host. Similarly, a thread dispatches a
30 registered ompt_callback_target or ompt_callback_target_emi callback with
31 ompt_scope_end as its endpoint argument and ompt_target_exit_data or
32 ompt_target_exit_data_nowait if the nowait clause is present as its kind argument for
33 each occurrence of a target-exit-data-end event in that thread in the context of the target task on the
34 host. These callbacks have type signature ompt_callback_target_t or

1 Restrictions
2 Restrictions to the target exit data construct are as follows:
4 target exit data directive, or on any side effects of the evaluations of the clauses.
5 • At least one map clause must appear on the directive.
10 • A map-type must be specified in all map clauses and must be either from, release, or
11 delete.
13 Cross References
14 • default-device-var, see Section 2.4.1.
15 • task, see Section 2.12.1.
17 • target data, see Section 2.14.2.
18 • target enter data, see Section 2.14.3.
22 • ompt_callback_target_t and ompt_callback_target_emi_t callback type, see
23 Section 4.5.2.26.

1 2.14.5 target Construct
2 Summary
3 The target construct maps variables to a device data environment and executes the construct on
4 that device.
5 Syntax
C / C++
6 The syntax of the target construct is as follows:
7 #pragma omp target [clause[ [,] clause] ... ] new-line
8 structured-block

10 if([ target :] scalar-expression)
11 device([ device-modifier :] integer-expression)
12 thread_limit(integer-expression)
13 private(list)
18 has_device_addr(list)
19 defaultmap(implicit-behavior[:variable-category])
20 nowait
23 uses_allocators(allocator[(allocator-traits-array)]
24 [,allocator[(allocator-traits-array)] ...])
25 and where device-modifier is one of the following:

26 ancestor
27 device_num
28 and where allocator is an identifier of omp_allocator_handle_t type and

29 allocator-traits-array is an identifier of const omp_alloctrait_t * type.
C / C++

Fortran
1 The syntax of the target construct is as follows:
2 !$omp target [clause[ [,] clause] ... ]
4 !$omp end target
5 or
6 !$omp target [clause[ [,] clause] ... ]
8 [!$omp end target]

10 if([ target :] scalar-logical-expression)
11 device([ device-modifier :] scalar-integer-expression)
12 thread_limit(scalar-integer-expression)
13 private(list)
18 has_device_addr(list)
20 nowait
22 allocate([allocator:] list)
23 uses_allocators(allocator[(allocator-traits-array)]
24 [,allocator[(allocator-traits-array)] ...])
25 and where device-modifier is one of the following:

26 ancestor
27 device_num
28 and where allocator is an integer expression of omp_allocator_handle_kind kind and

29 allocator-traits-array is an array of type(omp_alloctrait) type.
Fortran

1 Binding
2 The binding task set for a target region is the generating task, which is the target task generated
3 by the target construct. The target region binds to the corresponding target task region.
4 Description
5 The target construct provides a superset of the functionality provided by the target data
6 directive, except for the use_device_ptr and use_device_addr clauses.
7 The functionality added to the target directive is the inclusion of an executable region to be
8 executed on a device. That is, the target directive is an executable directive.
9 The target construct is a task generating construct. The generated task is a target task. The
10 generated task region encloses the target region. The device clause determines the device on
11 which the target region executes.
12 All clauses are evaluated when the target construct is encountered. The data environment of the
13 target task is created according to the data-sharing and data-mapping attribute clauses on the
14 target construct, per-data environment ICVs, and any default data-sharing attribute rules that
15 apply to the target construct. If a variable or part of a variable is mapped by the target
16 construct and does not appear as a list item in an in_reduction clause on the construct, the
17 variable has a default data-sharing attribute of shared in the data environment of the target task.
20 As described in Section 2.4.4.1, the target construct limits the number of threads that may
21 participate in a contention group initiated by the initial thread by setting the value of the
22 thread-limit-var ICV for the initial task to an implementation defined value greater than zero. If the
23 thread_limit clause is specified, the number of threads will be less than or equal to the value
24 specified in the clause.
25 If a device clause in which the device_num device-modifier appears is present on the
26 construct, the device clause expression specifies the device number of the target device. If
27 device-modifier does not appear in the clause, the behavior of the clause is as if device-modifier is
28 device_num.
29 If a device clause in which the ancestor device-modifier appears is present on the target
30 construct and the device clause expression evaluates to 1, execution of the target region occurs
31 on the parent device of the enclosing target region. If the target construct is not encountered
32 in a target region, the current device is treated as the parent device. The encountering thread
33 waits for completion of the target region on the parent device before resuming. For any list item
34 that appears in a map clause on the same construct, if the corresponding list item exists in the device
35 data environment of the parent device, it is treated as if it has a reference count of positive infinity.
36 If no device clause is present, the behavior is as if the device clause appears without a
37 device-modifier and with an expression equal to the value of the default-device-var ICV.

4 When an if clause is present and the if clause expression evaluates to false, the target region
5 is executed by the host device.
6 The has_device_addr clause indicates that its list items already have device addresses and
7 therefore they may be directly accessed from a target device. If the device address of a list item is
8 not for the device on which the target region executes, accessing the list item inside the region
9 results in unspecified behavior. The list items may include array sections.
C / C++
10 The is_device_ptr clause indicates that its list items are device pointers. Inside the target
11 construct, each list item is privatized and the new list item is initialized to the device address to
12 which the original list item refers. Support for device pointers created outside of OpenMP,
13 specifically outside of any OpenMP mechanism that returns a device pointer, is implementation
14 defined.
C / C++
Fortran
15 The is_device_ptr clause indicates that its list items are device pointers if they are of type
16 C_PTR. Inside the target construct, each list item of type C_PTR is privatized and the new list
17 item is initialized to the device address to which the original list item refers. Support for device
18 pointers created outside of OpenMP, specifically outside of any OpenMP mechanism that returns a
19 device pointer, is implementation defined. For any list item in an is_device_ptr clause that is
20 not of type C_PTR, the behavior is as if the list item appeared in a has_device_addr clause.
21 Support for such list items in an is_device_ptr clause is deprecated.
Fortran
22 If a function (C, C++, Fortran) or subroutine (Fortran) is referenced in a target construct that
23 does not specify a device clause in which the ancestor device-modifier appears then that
24 function or subroutine is treated as if its name had appeared in a to clause on a declare target
25 directive.
26 If a variable with static storage duration is declared in a target construct that does not specify a
27 device clause in which the ancestor device-modifier appears then the named variable is
28 treated as if it had appeared in a to clause on a declare target directive.
29 Each memory allocator specified in the uses_allocators clause will be made available in the
30 target region. For each non-predefined allocator that is specified, a new allocator handle will be
31 associated with an allocator that is created with the specified traits as if by a call to
32 omp_init_allocator at the beginning of the target region. Each non-predefined allocator
33 will be destroyed as if by a call to omp_destroy_allocator at the end of the target region.

C / C++
1 If a list item in a map clause has a base pointer and it is a scalar variable with a predetermined
2 data-sharing attribute of firstprivate (see Section 2.21.1.1), then on entry to the target region:
3 • If the list item is not a zero-length array section, the corresponding private variable is initialized
4 such that the corresponding list item in the device data environment can be accessed through the
5 pointer in the target region.
6 • If the list item is a zero-length array section , the corresponding private variable is initialized
7 according to Section 2.21.7.2.
C / C++
Fortran
8 When an internal procedure is called in a target region, any references to variables that are host
9 associated in the procedure have unspecified behavior.
Fortran

12 Section 2.12.1.
13 Events associated with the initial task that executes the target region are defined in
14 Section 2.12.5.
15 The target-begin event occurs when a thread enters a target region.
16 The target-end event occurs when a thread exits a target region.
17 The target-submit-begin event occurs prior to initiating creation of an initial task on a target device
18 for a target region.
19 The target-submit-end event occurs after initiating creation of an initial task on a target device for a
20 target region.
21 Tool Callbacks
24 callback.
27 argument and ompt_target or ompt_target_nowait if the nowait clause is present as its
28 kind argument for each occurrence of a target-begin event in that thread in the context of the target
29 task on the host. Similarly, a thread dispatches a registered ompt_callback_target or
30 ompt_callback_target_emi callback with ompt_scope_end as its endpoint argument
31 and ompt_target or ompt_target_nowait if the nowait clause is present as its kind

1 argument for each occurrence of a target-end event in that thread in the context of the target task on
2 the host. These callbacks have type signature ompt_callback_target_t or
4 A thread dispatches a registered ompt_callback_target_submit_emi callback with
5 ompt_scope_begin as its endpoint argument for each occurrence of a target-submit-begin
7 ompt_callback_target_submit_emi callback with ompt_scope_end as its endpoint
8 argument for each occurrence of a target-submit-end event in that thread. These callbacks have type
9 signature ompt_callback_target_submit_emi_t.
10 A thread dispatches a registered ompt_callback_target_submit callback for each
11 occurrence of a target-submit-begin event in that thread. The callback occurs in the context of the
12 target task and has type signature ompt_callback_target_submit_t.
13 Restrictions
14 Restrictions to the target construct are as follows:
15 • If a target update, target data, target enter data, or target exit data
16 construct is encountered during execution of a target region, the behavior is unspecified.
17 • The result of an omp_set_default_device, omp_get_default_device, or
18 omp_get_num_devices routine called within a target region is unspecified.
19 • The effect of an access to a threadprivate variable in a target region is unspecified.
20 • If a list item in a map clause is a structure element, any other element of that structure that is
21 referenced in the target construct must also appear as a list item in a map clause.
22 • A list item cannot appear in both a map clause and a data-sharing attribute clause on the same
23 target construct.
24 • A variable referenced in a target region but not the target construct that is not declared in
25 the target region must appear in a declare target directive.
26 • At most one defaultmap clause for each category can appear on the directive.
29 • A map-type in a map clause must be to, from, tofrom or alloc.
30 • A list item that appears in an is_device_ptr clause must be a valid device pointer for the
31 device data environment.
32 • A list item that appears in a has_device_addr clause must have a valid device address for
33 the device data environment.
34 • A list item may not be specified in both an is_device_ptr clause and a
35 has_device_addr clause on the directive.

1 • A list item that appears in an is_device_ptr or a has_device_addr clause must not be
2 specified in any data-sharing attribute clause on the same target construct.
6 • If a device clause in which the ancestor device-modifier appears is present on the
7 construct, then the following restrictions apply:
8 – A requires directive with the reverse_offload clause must be specified;
9 – The device clause expression must evaluate to 1;
10 – Only the device, firstprivate, private, defaultmap, and map clauses may
11 appear on the construct;
12 – No OpenMP constructs or calls to OpenMP API runtime routines are allowed inside the
13 corresponding target region.
14 • Memory allocators that do not appear in a uses_allocators clause cannot appear as an
15 allocator in an allocate clause or be used in the target region unless a requires
16 directive with the dynamic_allocators clause is present in the same compilation unit.
17 • Memory allocators that appear in a uses_allocators clause cannot appear in other
18 data-sharing attribute clauses or data-mapping attribute clauses in the same construct.
19 • Predefined allocators appearing in a uses_allocators clause cannot have traits specified.
20 • Non-predefined allocators appearing in a uses_allocators clause must have traits specified.
21 • Arrays that contain allocator traits that appear in a uses_allocators clause must be
22 constant arrays, have constant values and be defined in the same scope as the construct in which
23 the clause appears.
24 • Any IEEE floating-point exception status flag, halting mode, or rounding mode set prior to a
25 target region is unspecified in the region.
26 • Any IEEE floating-point exception status flag, halting mode, or rounding mode set in a target
27 region is unspecified upon exiting the region.
C / C++
28 • An attached pointer must not be modified in a target region.
C / C++
C
29 • A list item that appears in an is_device_ptr clause must have a type of pointer or array.
C

C++
1 • A list item that appears in an is_device_ptr clause must have a type of pointer, array,
2 reference to pointer or reference to array.
3 • A throw executed inside a target region must cause execution to resume within the same
4 target region, and the same thread that threw the exception must catch it.
5 • The run-time type information (RTTI) of an object can only be accessed from the device on
6 which it was constructed.
C++
Fortran
7 • An attached pointer that is associated with a given pointer target must not become associated
8 with a different pointer target in a target region.
9 • If a list item in a map clause is an array section, and the array section is derived from a variable
10 with a POINTER or ALLOCATABLE attribute then the behavior is unspecified if the
11 corresponding list item’s variable is modified in the region.
12 • A reference to a coarray that is encountered on a non-host device must not be coindexed or appear
13 as an actual argument to a procedure where the corresponding dummy argument is a coarray.
14 • If the allocation status of a mapped variable that has the ALLOCATABLE attribute is unallocated
15 on entry to a target region, the allocation status of the corresponding variable in the device
16 data environment must be unallocated upon exiting the region.
17 • If the allocation status of a mapped variable that has the ALLOCATABLE attribute is allocated on
18 entry to a target region, the allocation status and shape of the corresponding variable in the
19 device data environment may not be changed, either explicitly or implicitly, in the region after
20 entry to it.
21 • If the association status of a list item with the POINTER attribute that appears in a map clause
22 on the construct is associated upon entry to the target region, the list item must be associated
23 with the same pointer target upon exit from the region.
25 on the construct is disassociated upon entry to the target region, the list item must be
26 disassociated upon exit from the region.
28 on the construct is disassociated or undefined on entry to the target region and if the list item
29 is associated with a pointer target inside the target region, the pointer association status must
30 become disassociated before the end the region.
Fortran

1 Cross References
3 • task construct, see Section 2.12.1.
4 • task scheduling constraints, see Section 2.12.6
6 • target data construct, see Section 2.14.2.
8 • private and firstprivate clauses, see Section 2.21.4.
9 • Data-Mapping Attribute Rules and Clauses, see Section 2.21.7.
11 • omp_alloctrait_t and omp_alloctrait types, see Section 3.13.1.
14 • ompt_callback_target_t or ompt_callback_target_emi_t callback type, see
15 Section 4.5.2.26.
16 • ompt_callback_target_submit_t or ompt_callback_target_submit_emi_t
17 callback type, Section 4.5.2.28.
18 2.14.6 target update Construct

19 Summary
20 The target update directive makes the corresponding list items in the device data environment
21 consistent with their original list items, according to the specified motion clauses. The
22 target update construct is a stand-alone directive.
23 Syntax
C / C++
24 The syntax of the target update construct is as follows:
25 #pragma omp target update clause[ [ [,] clause] ... ] new-line
26 where clause is either motion-clause or one of the following:

27 if([ target update :] scalar-expression)
29 nowait

1 and motion-clause is one of the following:
2 to([motion-modifier[,] [motion-modifier[,] ...]: ] locator-list)
3 from([motion-modifier[,] [motion-modifier[,] ...]: ] locator-list)
4 where motion-modifier is one of the following:

5 present
6 mapper(mapper-identifier)
C / C++
Fortran
8 The syntax of the target update construct is as follows:
9 !$omp target update clause[ [ [,] clause] ... ]
10 where clause is either motion-clause or one of the following:

11 if([ target update :] scalar-logical-expression)
13 nowait
15 and motion-clause is one of the following:

16 to([motion-modifier[,] [motion-modifier[,] ...]: ] locator-list)
17 from([motion-modifier[,] [motion-modifier[,] ...]: ] locator-list)
18 where motion-modifier is one of the following:

19 present
Fortran
22 Binding
23 The binding task set for a target update region is the generating task, which is the target task
24 generated by the target update construct. The target update region binds to the
25 corresponding target task region.

1 Description
2 A corresponding list item and an original list item exist for each list item in a to or from clause. If
3 the corresponding list item is not present in the device data environment and the present
4 modifier is not specified in the clause then no assignment occurs to or from the original list item.
5 Otherwise, each corresponding list item in the device data environment has an original list item in
6 the current task’s data environment.
7 If the mapper motion-modifier is not present, the behavior is as if the mapper(default)
8 modifier was specified. The effect of a motion clause on a list item is modified by a visible
9 user-defined mapper (see Section 2.21.7.4) if the mapper has the same mapper-identifier as the
10 mapper motion-modifier and is specified for a type that matches the type of the list item. For a to
11 clause, each list item is replaced with the list items that the given mapper specifies are to be mapped
12 with a to or tofrom map type. For a from clause, each list item is replaced with the list items
13 that the given mapper specifies are to be mapped with a from or tofrom map type.
14 If a list item is an array or array section of a type for which a user-defined mapper exists, each array
15 element is updated according to the mapper as if it appeared as a list item in the clause.
16 If a present modifier appears in the clause and the corresponding list item is not present in the
17 device data environment then an error occurs and the program terminates. For a list item that is
18 replaced with a set of list items as a result of a user-defined mapper, the present modifier only
19 applies to those mapper list items that share storage with the original list item.
20 The list items that appear in a to or from may reference iterators defined by an iterators-definition
21 appearing on an iterator modifier.
Fortran
22 If a list item or a subobject of a list item in a motion clause has the ALLOCATABLE attribute, its
23 update is performed only if its allocation status is allocated and only with respect to the allocated
24 storage.
25 If a list item in a motion clause has the POINTER attribute and its association status is associated,
26 the effect is as if the update is performed with respect to the pointer target.
Fortran
27 For each list item in a from or a to clause:
28 • For each part of the list item that is an attached pointer:
C / C++
29 – On exit from the region that part of the original list item will have the value it had on entry to
30 the region;
31 – On exit from the region that part of the corresponding list item will have the value it had on
32 entry to the region;
C / C++

Fortran
1 – On exit from the region that part of the original list item, if associated, will be associated with
2 the same pointer target with which it was associated on entry to the region;
3 – On exit from the region that part of the corresponding list item, if associated, will be
4 associated with the same pointer target with which it was associated on entry to the region.
Fortran
5 • For each part of the list item that is not an attached pointer:
6 – If the clause is from, the value of that part of the corresponding list item is assigned to that
7 part of the original list item;
8 – If the clause is to, the value of that part of the original list item is assigned to that part of the
9 corresponding list item.
10 • To avoid data races:
11 – Concurrent reads or updates of any part of the original list item must be synchronized with the
12 update of the original list item that occurs as a result of the from clause;
13 – Concurrent reads or updates of any part of the corresponding list item must be synchronized
14 with the update of the corresponding list item that occurs as a result of the to clause.
C / C++
15 The list items that appear in the to or from clauses may use shape-operators.
C / C++
16 The list items that appear in the to or from clauses may include array sections with stride
17 expressions.
18 The target update construct is a task generating construct. The generated task is a target task.
19 The generated task region encloses the target update region.
20 All clauses are evaluated when the target update construct is encountered. The data
21 environment of the target task is created according to the motion clauses on the target update
22 construct, per-data environment ICVs, and any default data-sharing attribute rules that apply to the
23 target update construct. If a variable or part of a variable is a list item in a motion clause on
24 the target update construct, the variable has a default data-sharing attribute of shared in the
25 data environment of the target task.

1 The device is specified in the device clause. If no device clause is present, the device is
2 determined by the default-device-var ICV. When an if clause is present and the if clause
3 expression evaluates to false, no assignments occur.

6 Section 2.12.1.
7 The target-update-begin event occurs when a thread enters a target update region.
8 The target-update-end event occurs when a thread exits a target update region.
9 Tool Callbacks
12 callback.
15 argument and ompt_target_update or ompt_target_update_nowait if the nowait
16 clause is present as its kind argument for each occurrence of a target-update-begin event in that
17 thread in the context of the target task on the host. Similarly, a thread dispatches a registered
18 ompt_callback_target or ompt_callback_target_emi callback with
19 ompt_scope_end as its endpoint argument and ompt_target_update or
20 ompt_target_update_nowait if the nowait clause is present as its kind argument for each
21 occurrence of a target-update-end event in that thread in the context of the target task on the host.
22 These callbacks have type signature ompt_callback_target_t or
24 Restrictions
25 Restrictions to the target update construct are as follows:
27 target update directive, or on any side effects of the evaluations of the clauses.
28 • Each of the motion-modifier modifiers can appear at most once on a motion clause.
29 • At least one motion-clause must be specified.
30 • A list item can only appear in a to or from clause, but not in both.
31 • A list item in a to or from clause must have a mappable type.

1 Cross References
2 • Array shaping, see Section 2.1.4.
3 • Array sections, see Section 2.1.5.
4 • Iterators, see Section 2.1.6.
10 • declare mapper directive, see Section 2.21.7.4.
12 • ompt_callback_task_create_t, see Section 4.5.2.7.
13 • ompt_callback_target_t or ompt_callback_target_emi_t callback type, see
14 Section 4.5.2.26.
15 2.14.7 Declare Target Directive

16 Summary
17 The declare target directive specifies that variables, functions (C, C++ and Fortran), and
18 subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive.
19 Syntax
C / C++
20 The syntax of the declare target directive is as follows:
21 #pragma omp declare target new-line
23 #pragma omp end declare target new-line
24 or
25 #pragma omp declare target (extended-list) new-line
26 or
27 #pragma omp declare target clause[ [ [,] clause] ... ] new-line

1 or
2 #pragma omp begin declare target [clause[ [,] clause] ... ] new-line
4 #pragma omp end declare target new-line

6 to(extended-list)
7 link(list)
8 device_type(host | nohost | any)
9 indirect[(invoked-by-fptr)]
10 where invoked-by-fptr is a constant boolean expression that evaluates to true or false at compile
11 time.
C / C++
Fortran
12 The syntax of the declare target directive is as follows:
13 !$omp declare target (extended-list)
14 or
15 !$omp declare target [clause[ [,] clause] ... ]

17 to(extended-list)
18 link(list)
19 device_type(host | nohost | any)
20 indirect[(invoked-by-fptr)]
21 where invoked-by-fptr is a constant logical expression that is evaluated at compile time.

Fortran

1 Description
2 The declare target directive ensures that procedures and global variables can be executed or
3 accessed on a device. Variables are mapped for all device executions, or for specific device
4 executions through a link clause.
5 If an extended-list is present with no clause then the to clause is assumed.
6 The device_type clause specifies if a version of the procedure or variable should be made
7 available on the host, device or both. If host is specified only a host version of the procedure or
8 variable is made available. If any is specified then both device and host versions of the procedure
9 or variable are made available. If nohost is specified for a procedure then only a device version of
10 the procedure is made available. If nohost is specified for a variable then that variable is not
11 available on the host. If no device_type clause is present then the behavior is as if the
12 device_type clause appears with any specified.
13 If a variable with static storage duration is declared in a device routine then the named variable is
14 treated as if it had appeared in a to clause on a declare target directive.
C / C++
15 If a function appears in a to clause in the same compilation unit in which the definition of the
16 function occurs then a device-specific version of the function is created.
17 If a variable appears in a to clause in the same compilation unit in which the definition of the
18 variable occurs then the original list item is allocated a corresponding list item in the device data
19 environment of all devices.
C / C++
Fortran
20 If a procedure appears in a to clause in the same compilation unit in which the definition of the
21 procedure occurs then a device-specific version of the procedure is created.
22 If a variable that is host associated appears in a to clause then the original list item is allocated a
23 corresponding list item in the device data environment of all devices.
Fortran
24 If a variable appears in a to clause then the corresponding list item in the device data environment
25 of each device is initialized once, in the manner specified by the program, but at an unspecified
26 point in the program prior to the first reference to that list item. The list item is never removed from
27 those device data environments as if its reference count was initialized to positive infinity.
28 Including list items in a link clause supports compilation of functions called in a target region
29 that refer to the list items. The list items are not mapped by the declare target directive. Instead,
30 they are mapped according to the data mapping rules described in Section 2.21.7.

C / C++
1 If a function is referenced in a function that appears as a list item in a to clause on a declare target
2 directive that does not specify a device_type clause with host and the function reference is
3 not enclosed in a target construct that specifies a device clause in which the ancestor
4 device-modifier appears then the name of the referenced function is treated as if it had appeared in a
5 to clause on a declare target directive.
6 If a variable with static storage duration or a function (except lambda for C++) is referenced in the
7 initializer expression list of a variable with static storage duration that appears as a list item in a to
8 clause on a declare target directive then the name of the referenced variable or function is treated as
9 if it had appeared in a to clause on a declare target directive.
10 The form, preceded by either the declare target directive that has no clauses and no
11 extended-list or the begin declare target directive and followed by a matching
12 end declare target directive, defines an implicit extended-list. The implicit extended-list
13 consists of the variable names of any variable declarations at file or namespace scope that appear
14 between the two directives and of the function names of any function declarations at file,
15 namespace or class scope that appear between the two directives. The implicit extended-list is
16 converted to an implicit to clause.
17 The declaration-definition-seq preceded by either begin declare target directive or a
18 declare target directive without any clauses or an extended-list and followed by an
19 end declare target directive may contain declare target directives. If a device_type
20 clause is present on the contained declare target directive, then its argument determines which
21 versions are made available. If a list item appears both in an implicit and explicit list, the explicit
22 list determines which versions are made available.
C / C++
Fortran
23 If a procedure is referenced in a procedure that appears as a list item in a to clause on a
24 declare target directive that does not specify a device_type clause with host and the
25 procedure reference is not enclosed in a target construct that specifies a device clause in
26 which the ancestor device-modifier appears then the name of the referenced procedure is treated
27 as if it had appeared in a to clause on a declare target directive.
28 If a declare target does not have any clauses and does not have an extended-list then an
29 implicit to clause with one item is formed from the name of the enclosing subroutine subprogram,
30 function subprogram or interface body to which it applies.
31 If a declare target directive has a device_type clause then any enclosed internal
32 procedures cannot contain any declare target directives. The enclosing device_type
33 clause implicitly applies to internal procedures.
Fortran

1 If the indirect clause is present and invoked-by-fptr is not specified, the effect of the clause is as
2 if invoked-by-fptr evaluates to true.
3 If the indirect clause is present and invoked-by-fptr evaluates to true, any procedures that appear
4 in a to clause on the directive may be called with an indirect device invocation. If the indirect
5 clause is present and invoked-by-fptr does not evaluate to true, any procedures that appear in a to
6 clause on the directive may not be called with an indirect device invocation. Unless otherwise
7 specified by an indirect clause, procedures may not be called with an indirect device invocation.
C / C++
8 If a function appears in the to clause of a begin declare target directive and in the to
9 clause of a declare target directive that is contained in the declaration-definition-seq associated with
10 the begin declare target directive, and if an indirect clause appears on both directives,
11 then the indirect clause on the begin declare target directive has no effect for that
12 function.
C / C++
14 The target-global-data-op event occurs when an original variable is associated with a
15 corresponding variable on a device as a result of a declare target directive; the event occurs before
16 the first access to the corresponding variable.
17 Tool Callbacks
18 A thread dispatches a registered ompt_callback_target_data_op callback, or a registered
19 ompt_callback_target_data_op_emi callback with ompt_scope_beginend as its
20 endpoint argument for each occurrence of a target-global-data-op event in that thread. These
21 callbacks have type signature ompt_callback_target_data_op_t or
22 ompt_callback_target_data_op_emi_t, respectively.
23 Restrictions
24 Restrictions to the declare target directive are as follows:
25 • A threadprivate variable cannot appear in the directive.
26 • A variable declared in the directive must have a mappable type.
27 • The same list item must not appear multiple times in clauses on the same directive.
28 • The same list item must not explicitly appear in both a to clause on one declare target directive
29 and a link clause on another declare target directive.
30 • If the directive has a clause, it must contain at least one to clause or at least one link clause.
31 • A variable for which nohost is specified may not appear in a link clause.
32 • At most one indirect clause can be specified on the directive.
33 • At most one device_type clause can be specified on the directive.

1 • If an indirect clause is present and invoked-by-fptr evaluates to true then the only permitted
2 device_type clause is device_type(any).
C++
3 • A to clause or a link clause cannot appear in a begin declare target directive.
4 • The function names of overloaded functions or template functions may only be specified within
5 an implicit extended-list.
6 • If a lambda declaration and definition appears between a declare target directive and the paired
7 end declare target directive, all variables that are captured by the lambda expression must
8 also appear in a to clause.
9 • A module export or import statement cannot appear between a declare target directive and the
10 paired end declare target directive.
C++
Fortran
11 • If a list item is a procedure name, it must not be a generic name, procedure pointer, entry name,
12 or statement function name.
13 • If the directive does not have any clause or has a device_type clause it must appear in a
14 specification part of a subroutine subprogram, function subprogram or interface body.
15 • If a list item is a procedure name, the directive must be in the specification part of that subroutine
16 or function subprogram or in the specification part of that subroutine or function in an interface
17 body.
18 • If the directive has a variable name in extended-list, it must appear in the specification part of a
19 subroutine subprogram, function subprogram, program or module.
20 • If the directive is specified in an interface block for a procedure, it must match a
21 declare target directive in the definition of the procedure, including the device_type
22 clause if present.
23 • If an external procedure is a type-bound procedure of a derived type and the directive is specified
24 in the definition of the external procedure, it must appear in the interface block that is accessible
25 to the derived-type definition.
26 • If any procedure is declared via a procedure declaration statement that is not in the type-bound
27 procedure part of a derived-type definition, any declare target with the procedure name
28 must appear in the same specification part.
29 • A variable that is part of another variable (as an array, structure element or type parameter
30 inquiry) cannot appear in the directive.
31 • The directive must appear in the declaration section of a scoping unit in which the common block
32 or variable is declared.

1 • If a declare target directive that specifies a common block name appears in one program
2 unit, then such a directive must also appear in every other program unit that contains a COMMON
3 statement that specifies the same name, after the last such COMMON statement in the program unit.
4 • If a list item is declared with the BIND attribute, the corresponding C entities must also be
5 specified in a declare target directive in the C program.
6 • A variable can only appear in a declare target directive in the scope in which it is declared.
7 It must not be an element of a common block or appear in an EQUIVALENCE statement.
8 • A variable that appears in a declare target directive must be declared in the Fortran scope
9 of a module or have the SAVE attribute, either explicitly or implicitly.
Fortran
10 Cross References
13 • ompt_callback_target_data_op_t or
14 ompt_callback_target_data_op_emi_t callback type, see Section 4.5.2.25.
15 2.15 Interoperability
16 An OpenMP implementation may interoperate with one or more foreign runtime environments
17 through the use of the interop construct that is described in this section, the interop operation
18 for a declared variant function and the interoperability routines that are available through the
19 OpenMP Runtime API.
C / C++
20 The implementation must provide foreign-runtime-id values that are enumerators of type
21 omp_interop_fr_t and that correspond to the supported foreign runtime environments.
C / C++
Fortran
22 The implementation must provide foreign-runtime-id values that are named integer constants with
23 kind omp_interop_fr_kind and that correspond to the supported foreign runtime
24 environments.
Fortran
25 Each foreign-runtime-id value provided by an implementation will be available as
26 omp_ifr_name, where name is the name of the foreign runtime environment. Available names
27 include those that are listed in the OpenMP Additional Definitions document;
28 implementation-defined names may also be supported. The value of omp_ifr_last is defined as
29 one greater than the value of the highest supported foreign-runtime-id value that is listed in the
30 aforementioned document.

1 Cross References
3 • Interoperability routines, see Section 3.12.
4 2.15.1 interop Construct

5 Summary
6 The interop construct retrieves interoperability properties from the OpenMP implementation to
7 enable interoperability with foreign execution contexts. The interop construct is a stand-alone
8 directive.
9 Syntax
10 In the following syntax, interop-type is the type of interoperability information being requested or
11 used by the interop construct, and action-clause is a clause that indicates the action to take with
12 respect to that interop object.
C / C++
13 The syntax of the interop construct is as follows:
14 #pragma omp interop clause[ [ [,] clause] ... ] new-line
15 where clause is action-clause or one of the following:

18 where action-clause is one of the following:

19 init([interop-modifier, ]interop-type[[, interop-type] ... ]:interop-var)
20 destroy(interop-var)
21 use(interop-var)
22 nowait
23 where interop-var is a variable of type omp_interop_t, and interop-type is one of the following:
24 target
25 targetsync
26 and interop-modifier is one of the following:

27 prefer_type(preference-list)

1 where preference-list is a comma separated list for which each item is a foreign-runtime-id, which
2 is a base language string literal or a compile-time constant integral expression. Allowed values for
3 foreign-runtime-id include the names (as string literals) and integer values specified in the OpenMP
4 Additional Definitions document and the corresponding omp_ifr_name constants of
5 omp_interop_fr_t type; implementation-defined values may also be supported.
C / C++
Fortran
6 The syntax of the interop construct is as follows:
7 !$omp interop clause[ [ [,] clause] ... ]
8 where clause is action-clause or one of the following:

11 where action-clause is one of the following:

12 init([interop-modifier, ]interop-type[[, interop-type] ... ]:interop-var)
13 destroy(interop-var)
14 use(interop-var)
15 nowait
16 where interop-var is a scalar integer variable of kind omp_interop_kind, and interop-type is

17 one of the following:
18 target
19 targetsync
20 and interop-modifier is one of the following:

21 prefer_type(preference-list)
22 where preference-list is a comma separated list for which each item is a foreign-runtime-id, which
23 is a base language string literal or a compile-time constant integral expression. Allowed values for
24 foreign-runtime-id include the names (as string literals) and integer values specified in the OpenMP
25 Additional Definitions document and the corresponding omp_ifr_name integer constants of kind
26 omp_interop_fr_kind; implementation-defined values may also be supported.
Fortran
27 Binding
28 The binding task set for an interop region is the generating task. The interop region binds to
29 the region of the generating task.

1 Description
2 When an interop construct is encountered, the encountering task executes the region. If no
3 device clause is present, the behavior is as if the device clause appears with an expression
5 If the init action-clause is specified, the interop-var is initialized to refer to the list of properties
6 associated with the given interop-type. For any interop-type, the properties type, type_name,
7 vendor, vendor_name and device_num will be available. If the implementation is unable to
8 initialize the interop-var, it will be initialized to the value of omp_interop_none, which is
9 defined to be zero.
10 The targetsync interop-type will additionally provide the targetsync property, which is the
11 handle to a foreign synchronization object for enabling synchronization between OpenMP tasks and
12 foreign tasks that execute in the foreign execution context.
13 The target interop-type will additionally provide the following properties:
14 • device, which will be a foreign device handle;
15 • device_context, which will be a foreign device context handle; and
16 • platform, which will be a handle to a foreign platform of the device.
17 If the destroy action-clause is specified, the interop-var is set to the value of
18 omp_interop_none after resources associated with interop-var are released. The object
19 referred to by the interop-var will be unusable after destruction and the effect of using values
20 associated with it is unspecified until interop-var is initialized again by another interop
21 construct.
22 If the use action-clause is specified, the interop-var is used for other effects of this directive but is
23 not initialized, destroyed or otherwise modified.
24 For the destroy or use action-clause, the interop-type is inferred based on the interop-type used
25 to initialize the interop-var.
26 If the interop-type specified is targetsync, or the interop-var was initialized with
27 targetsync, an empty mergeable task is generated. If the nowait clause is not present on the
28 construct then the task is also an included task. Any depend clauses that are present on the
29 construct apply to the generated task. The interop construct ensures an ordered execution of the
30 generated task relative to foreign tasks executed in the foreign execution context through the foreign
31 synchronization object accessible through the targetsync property of interop-var. When the
32 creation of the foreign task precedes the encountering of an interop construct in happens before
33 order (see Section 1.4.5), the foreign task must complete execution before the generated task begins
34 execution. Similarly, when the creation of a foreign task follows the encountering of an interop
35 construct in happens before order, the foreign task must not begin execution until the generated task
36 completes execution. No ordering is imposed between the encountering thread and either foreign
37 tasks or OpenMP tasks by the interop construct.

1 If the prefer_type interop-modifier clause is specified, the first supported foreign-runtime-id in
2 preference-list in left-to-right order is used. The foreign-runtime-id that is used if the
3 implementation does not support any of the items in preference-list is implementation defined.
4 Restrictions
5 Restrictions to the interop construct are as follows:
6 • At least one action-clause must appear on the directive.
7 • Each interop-type may be specified on an action-clause at most once.
8 • The interop-var passed to init or destroy must be non-const.
9 • A depend clause can only appear on the directive if a targetsync interop-type is present or
10 the interop-var was initialized with the targetsync interop-type.
11 • Each interop-var may be specified for at most one action-clause of each interop construct.
13 evaluate to a non-negative integer value less than or equal to the value returned by
16 Cross References
18 • Interoperability routines, see Section 3.12.
19 2.15.2 Interoperability Requirement Set

20 The interoperability requirement set of each task is a logical set of properties that can be added or
21 removed by different directives. These properties can be queried by other constructs that have
22 interoperability semantics.
23 A construct can add the following properties to the set:
24 • depend, which specifies that the construct requires enforcement of the synchronization
25 relationship expressed by the depend clause;
26 • nowait, which specifies that the construct is asynchronous; and
27 • is_device_ptr(list-item), which specifies that the list-item is a device pointer in the construct.
28 The following directives may add properties to the set:
29 • dispatch.
30 The following directives may remove properties from the set:
31 • declare variant.

1 Cross References
3 • dispatch construct, see Section 2.3.6.
4 2.16 Combined Constructs

5 Combined constructs are shortcuts for specifying one construct immediately nested inside another
6 construct. The semantics of the combined constructs are identical to that of explicitly specifying
7 the first construct containing one instance of the second construct and no other statements.
8 For combined constructs, tool callbacks are invoked as if the constructs were explicitly nested.
9 2.16.1 Parallel Worksharing-Loop Construct

10 Summary
11 The parallel worksharing-loop construct is a shortcut for specifying a parallel construct
12 containing a worksharing-loop construct with a canonical loop nest and no other statements.
13 Syntax
C / C++
14 The syntax of the parallel worksharing-loop construct is as follows:
15 #pragma omp parallel for [clause[ [,] clause] ... ] new-line
16 loop-nest
18 parallel or for directives, except the nowait clause, with identical meanings and restrictions.
19
C / C++
Fortran
20 The syntax of the parallel worksharing-loop construct is as follows:
21 !$omp parallel do [clause[ [,] clause] ... ]
22 loop-nest
23 [!$omp end parallel do]
25 parallel or do directives, with identical meanings and restrictions.
26 If an end parallel do directive is not specified, an end parallel do directive is assumed at
27 the end of the loop-nest.
Fortran

1 Description
2 The semantics are identical to explicitly specifying a parallel directive immediately followed
3 by a worksharing-loop directive.
4 Restrictions
5 The restrictions for the parallel construct and the worksharing-loop construct apply.
6 Cross References
10 • Data attribute clauses, see Section 2.21.4.
11 2.16.2 parallel loop Construct

12 Summary
13 The parallel loop construct is a shortcut for specifying a parallel construct containing a
14 loop construct with a canonical loop nest and no other statements.
15 Syntax
C / C++
16 The syntax of the parallel loop construct is as follows:
17 #pragma omp parallel loop [clause[ [,] clause] ... ] new-line
18 loop-nest
20 parallel or loop directives, with identical meanings and restrictions.
C / C++
Fortran
21 The syntax of the parallel loop construct is as follows:
22 !$omp parallel loop [clause[ [,] clause] ... ]
23 loop-nest
24 [!$omp end parallel loop]
26 parallel or loop directives, with identical meanings and restrictions.
27 If an end parallel loop directive is not specified, an end parallel loop directive is
28 assumed at the end of the loop-nest.
Fortran

1 Description
3 by a loop directive.
4 Restrictions
5 The restrictions for the parallel construct and the loop construct apply.
6 Cross References
9 • loop construct, see Section 2.11.7.
11 2.16.3 parallel sections Construct

12 Summary
13 The parallel sections construct is a shortcut for specifying a parallel construct
14 containing a sections construct and no other statements.
15 Syntax
C / C++
16 The syntax of the parallel sections construct is as follows:
17 #pragma omp parallel sections [clause[ [,] clause] ... ] new-line
18 {
19 [#pragma omp section new-line]
21 [#pragma omp section new-line
23 ...
24 }
25 where clause can be any of the clauses accepted by the parallel or sections directives,
26 except the nowait clause, with identical meanings and restrictions.
C / C++

Fortran
1 The syntax of the parallel sections construct is as follows:
2 !$omp parallel sections [clause[ [,] clause] ... ]
3 [!$omp section]
5 [!$omp section
7 ...
8 !$omp end parallel sections
9 where clause can be any of the clauses accepted by the parallel or sections directives, with
10 identical meanings and restrictions.
Fortran
11 Description
C / C++
13 by a sections directive.
C / C++
Fortran
15 by a sections directive, and an end sections directive immediately followed by an
16 end parallel directive.
Fortran
17 Restrictions
18 The restrictions for the parallel construct and the sections construct apply.
19 Cross References
21 • sections construct, see Section 2.10.1.
Fortran
23 2.16.4 parallel workshare Construct

24 Summary
25 The parallel workshare construct is a shortcut for specifying a parallel construct
26 containing a workshare construct and no other statements.

1 Syntax
2 The syntax of the parallel workshare construct is as follows:
3 !$omp parallel workshare [clause[ [,] clause] ... ]
5 !$omp end parallel workshare
6 or
7 !$omp parallel workshare [clause[ [,] clause] ... ]
9 [!$omp end parallel workshare]
10 where clause can be any of the clauses accepted by the parallel directive, with identical
11 meanings and restrictions.
12 Description
14 by a workshare directive, and an end workshare directive immediately followed by an
15 end parallel directive.
16 Restrictions
17 The restrictions for the parallel construct and the workshare construct apply.
18 Cross References
20 • workshare construct, see Section 2.10.3.
Fortran
22 2.16.5 Parallel Worksharing-Loop SIMD Construct

23 Summary
24 The parallel worksharing-loop SIMD construct is a shortcut for specifying a parallel construct
25 containing a worksharing-loop SIMD construct and no other statements.
26 Syntax
C / C++
27 The syntax of the parallel worksharing-loop SIMD construct is as follows:
28 #pragma omp parallel for simd [clause[ [,] clause] ... ] new-line
29 loop-nest
31 parallel or for simd directives, except the nowait clause, with identical meanings and
32 restrictions.
C / C++

Fortran
1 The syntax of the parallel worksharing-loop SIMD construct is as follows:
2 !$omp parallel do simd [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end parallel do simd]
6 parallel or do simd directives, with identical meanings and restrictions.
7 If an end parallel do simd directive is not specified, an end parallel do simd directive
8 is assumed at the end of the loop-nest.
Fortran
9 Description
10 The semantics of the parallel worksharing-loop SIMD construct are identical to explicitly
11 specifying a parallel directive immediately followed by a worksharing-loop SIMD directive.
12 Restrictions
13 The restrictions for the parallel construct and the worksharing-loop SIMD construct apply
14 except for the following explicit modifications:
20 Cross References
23 • Worksharing-loop SIMD construct, see Section 2.11.5.2.
26 2.16.6 parallel masked Construct

27 Summary
28 The parallel masked construct is a shortcut for specifying a parallel construct containing
29 a masked construct, and no other statements.

1 Syntax
C / C++
2 The syntax of the parallel masked construct is as follows:
3 #pragma omp parallel masked [clause[ [,] clause] ... ] new-line
4 structured-block
5 where clause can be any of the clauses accepted by the parallel or masked directives, with
C / C++
Fortran
7 The syntax of the parallel masked construct is as follows:
8 !$omp parallel masked [clause[ [,] clause] ... ]
10 !$omp end parallel masked
11 or
12 !$omp parallel masked [clause[ [,] clause] ... ]
14 [!$omp end parallel masked]
15 where clause can be any of the clauses accepted by the parallel or masked directives, with
Fortran
17 The parallel master construct, which has been deprecated, has identical syntax to the
18 parallel masked construct other than the use of parallel master as the directive name.
19 Description
21 by a masked directive.
22 Restrictions
23 The restrictions for the parallel construct and the masked construct apply.
24 Cross References
26 • masked construct, see Section 2.8.

1 2.16.7 masked taskloop Construct
2 Summary
3 The masked taskloop construct is a shortcut for specifying a masked construct containing a
4 taskloop construct and no other statements.
5 Syntax
C / C++
6 The syntax of the masked taskloop construct is as follows:
7 #pragma omp masked taskloop [clause[ [,] clause] ... ] new-line
8 loop-nest
10 masked or taskloop directives with identical meanings and restrictions.
C / C++
Fortran
11 The syntax of the masked taskloop construct is as follows:
12 !$omp masked taskloop [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end masked taskloop]
16 masked or taskloop directives with identical meanings and restrictions.
17 If an end masked taskloop directive is not specified, an end masked taskloop directive is
18 assumed at the end of the loop-nest.
Fortran
19 The master taskloop construct, which has been deprecated, has identical syntax to the
20 masked taskloop construct other than the use of master taskloop as the directive name.
21 Description
22 The semantics are identical to explicitly specifying a masked directive immediately followed by a
23 taskloop directive.
24 Restrictions
25 The restrictions for the masked and taskloop constructs apply.
26 Cross References

1 2.16.8 masked taskloop simd Construct
2 Summary
3 The masked taskloop simd construct is a shortcut for specifying a masked construct
4 containing a taskloop simd construct and no other statements.
5 Syntax
C / C++
6 The syntax of the masked taskloop simd construct is as follows:
7 #pragma omp masked taskloop simd [clause[ [,] clause] ... ] new-line
8 loop-nest
10 masked or taskloop simd directives with identical meanings and restrictions.
C / C++
Fortran
11 The syntax of the masked taskloop simd construct is as follows:
12 !$omp masked taskloop simd [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end masked taskloop simd]
16 masked or taskloop simd directives with identical meanings and restrictions.
17 If an end masked taskloop simd directive is not specified, an end masked
18 taskloop simd directive is assumed at the end of the loop-nest.
Fortran
19 The master taskloop simd construct, which has been deprecated, has identical syntax to the
20 masked taskloop simd construct other than the use of master taskloop simd as the
21 directive name.
22 Description
23 The semantics are identical to explicitly specifying a masked directive immediately followed by a
24 taskloop simd directive.
25 Restrictions
26 The restrictions for the masked and taskloop simd constructs apply.
27 Cross References
30 • taskloop simd construct, see Section 2.12.3.

1 2.16.9 parallel masked taskloop Construct
2 Summary
3 The parallel masked taskloop construct is a shortcut for specifying a parallel
4 construct containing a masked taskloop construct and no other statements.
C / C++
5 The syntax of the parallel masked taskloop construct is as follows:
6 #pragma omp parallel masked taskloop [clause[ [,] clause] ... ] new-line
7 loop-nest
9 parallel or masked taskloop directives, except the in_reduction clause, with identical
C / C++
Fortran
11 The syntax of the parallel masked taskloop construct is as follows:
12 !$omp parallel masked taskloop [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end parallel masked taskloop]
16 parallel or masked taskloop directives, except the in_reduction clause, with identical
18 If an end parallel masked taskloop directive is not specified, an
19 end parallel masked taskloop directive is assumed at the end of the loop-nest.
Fortran
20 The parallel master taskloop construct, which has been deprecated, has identical syntax
21 to the parallel masked taskloop construct other than the use of
22 parallel master taskloop as the directive name.
23 Description
25 by a masked taskloop directive.

1 Restrictions
2 The restrictions for the parallel construct and the masked taskloop construct apply except
3 for the following explicit modifications:
9 Cross References
12 • masked taskloop construct, see Section 2.16.7.
16 2.16.10 parallel masked taskloop simd Construct

17 Summary
18 The parallel masked taskloop simd construct is a shortcut for specifying a parallel
19 construct containing a masked taskloop simd construct and no other statements.
20 Syntax
C / C++
21 The syntax of the parallel masked taskloop simd construct is as follows:
22 #pragma omp parallel masked taskloop simd [clause[ [,] clause] ... ] new-line
23 loop-nest
25 parallel or masked taskloop simd directives, except the in_reduction clause, with
C / C++

Fortran
1 The syntax of the parallel masked taskloop simd construct is as follows:
2 !$omp parallel masked taskloop simd [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end parallel masked taskloop simd]
6 parallel or masked taskloop simd directives, except the in_reduction clause, with
8 If an end parallel masked taskloop simd directive is not specified, an end parallel
9 masked taskloop simd directive is assumed at the end of the loop-nest.
Fortran
10 The parallel master taskloop simd construct, which has been deprecated, has identical
11 syntax to the parallel masked taskloop simd construct other than the use of
12 parallel master taskloop simd as the directive name.
13 Description
15 by a masked taskloop simd directive.
16 Restrictions
17 The restrictions for the parallel construct and the masked taskloop simd construct apply
25 Cross References
28 • masked taskloop simd construct, see Section 2.16.8.

1 2.16.11 teams distribute Construct
2 Summary
3 The teams distribute construct is a shortcut for specifying a teams construct containing a
4 distribute construct and no other statements.
5 Syntax
C / C++
6 The syntax of the teams distribute construct is as follows:
7 #pragma omp teams distribute [clause[ [,] clause] ... ] new-line
8 loop-nest
10 teams or distribute directives with identical meanings and restrictions.
C / C++
Fortran
11 The syntax of the teams distribute construct is as follows:
12 !$omp teams distribute [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end teams distribute]
16 teams or distribute directives with identical meanings and restrictions.
17 If an end teams distribute directive is not specified, an end teams distribute
18 directive is assumed at the end of the loop-nest.
Fortran
19 Description
20 The semantics are identical to explicitly specifying a teams directive immediately followed by a
21 distribute directive.
22 Restrictions
23 The restrictions for the teams and distribute constructs apply.
24 Cross References
25 • teams construct, see Section 2.7.

1 2.16.12 teams distribute simd Construct
2 Summary
3 The teams distribute simd construct is a shortcut for specifying a teams construct
4 containing a distribute simd construct and no other statements.
5 Syntax
C / C++
6 The syntax of the teams distribute simd construct is as follows:
7 #pragma omp teams distribute simd [clause[ [,] clause] ... ] new-line
8 loop-nest
10 teams or distribute simd directives with identical meanings and restrictions.
C / C++
Fortran
11 The syntax of the teams distribute simd construct is as follows:
12 !$omp teams distribute simd [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end teams distribute simd]
16 teams or distribute simd directives with identical meanings and restrictions.
17 If an end teams distribute simd directive is not specified, an end teams
18 distribute simd directive is assumed at the end of the loop-nest.
Fortran
19 Description
21 distribute simd directive.
22 Restrictions
23 The restrictions for the teams and distribute simd constructs apply.
24 Cross References
27 • distribute simd construct, see Section 2.11.6.2.

1 2.16.13 Teams Distribute Parallel Worksharing-Loop
2 Construct
3 Summary
4 The teams distribute parallel worksharing-loop construct is a shortcut for specifying a teams
5 construct containing a distribute parallel worksharing-loop construct and no other statements.
6 Syntax
C / C++
7 The syntax of the teams distribute parallel worksharing-loop construct is as follows:
8 #pragma omp teams distribute parallel for \
10 loop-nest
12 teams or distribute parallel for directives with identical meanings and restrictions.
C / C++
Fortran
13 The syntax of the teams distribute parallel worksharing-loop construct is as follows:
14 !$omp teams distribute parallel do [clause[ [,] clause] ... ]
15 loop-nest
16 [!$omp end teams distribute parallel do]
18 teams or distribute parallel do directives with identical meanings and restrictions.
19 If an end teams distribute parallel do directive is not specified, an end teams
20 distribute parallel do directive is assumed at the end of the loop-nest.
Fortran
21 Description
23 distribute parallel worksharing-loop directive.
24 Restrictions
25 The restrictions for the teams and distribute parallel worksharing-loop constructs apply.
26 Cross References
29 • Distribute parallel worksharing-loop construct, see Section 2.11.6.3.

1 2.16.14 Teams Distribute Parallel Worksharing-Loop SIMD
2 Construct
3 Summary
4 The teams distribute parallel worksharing-loop SIMD construct is a shortcut for specifying a
5 teams construct containing a distribute parallel worksharing-loop SIMD construct and no other
6 statements.
7 Syntax
C / C++
8 The syntax of the teams distribute parallel worksharing-loop SIMD construct is as follows:
9 #pragma omp teams distribute parallel for simd \
11 loop-nest
13 teams or distribute parallel for simd directives with identical meanings and
14 restrictions.
C / C++
Fortran
15 The syntax of the teams distribute parallel worksharing-loop SIMD construct is as follows:
16 !$omp teams distribute parallel do simd [clause[ [,] clause] ... ]
17 loop-nest
18 [!$omp end teams distribute parallel do simd]
20 teams or distribute parallel do simd directives with identical meanings and restrictions.
21 If an end teams distribute parallel do simd directive is not specified, an end teams
22 distribute parallel do simd directive is assumed at the end of the loop-nest.
Fortran
23 Description
25 distribute parallel worksharing-loop SIMD directive.
26 Restrictions
27 The restrictions for the teams and distribute parallel worksharing-loop SIMD constructs apply.

1 Cross References
4 • Distribute parallel worksharing-loop SIMD construct, see Section 2.11.6.4.
6 2.16.15 teams loop Construct

7 Summary
8 The teams loop construct is a shortcut for specifying a teams construct containing a loop
9 construct and no other statements.
10 Syntax
C / C++
11 The syntax of the teams loop construct is as follows:
12 #pragma omp teams loop [clause[ [,] clause] ... ] new-line
13 loop-nest
15 teams or loop directives with identical meanings and restrictions.
C / C++
Fortran
16 The syntax of the teams loop construct is as follows:
17 !$omp teams loop [clause[ [,] clause] ... ]
18 loop-nest
19 [!$omp end teams loop]
21 teams or loop directives with identical meanings and restrictions.
22 If an end teams loop directive is not specified, an end teams loop directive is assumed at the
23 end of the loop-nest.
Fortran
24 Description
26 loop directive.
27 Restrictions
28 The restrictions for the teams and loop constructs apply.

1 Cross References
4 • loop construct, see Section 2.11.7.
6 2.16.16 target parallel Construct

7 Summary
8 The target parallel construct is a shortcut for specifying a target construct containing a
9 parallel construct and no other statements.
10 Syntax
C / C++
11 The syntax of the target parallel construct is as follows:
12 #pragma omp target parallel [clause[ [,] clause] ... ] new-line
13 structured-block
14 where clause can be any of the clauses accepted by the target or parallel directives, except
15 for copyin, with identical meanings and restrictions.
C / C++
Fortran
16 The syntax of the target parallel construct is as follows:
17 !$omp target parallel [clause[ [,] clause] ... ]
19 !$omp end target parallel
20 or
21 !$omp target parallel [clause[ [,] clause] ... ]
23 [!$omp end target parallel]
24 where clause can be any of the clauses accepted by the target or parallel directives, except
25 for copyin, with identical meanings and restrictions.
Fortran
26 Description
27 The semantics are identical to explicitly specifying a target directive immediately followed by a
28 parallel directive.

1 Restrictions
2 The restrictions for the target and parallel constructs apply except for the following explicit
3 modifications:
8 • At most one if clause with the target directive-name-modifier can appear on the directive.
9 Cross References
14 • copyin clause, see Section 2.21.6.1.
15 2.16.17 Target Parallel Worksharing-Loop Construct

16 Summary
17 The target parallel worksharing-loop construct is a shortcut for specifying a target construct
18 containing a parallel worksharing-loop construct and no other statements.
19 Syntax
C / C++
20 The syntax of the target parallel worksharing-loop construct is as follows:
21 #pragma omp target parallel for [clause[ [,] clause] ... ] new-line
22 loop-nest
24 target or parallel for directives, except for copyin, with identical meanings and
25 restrictions.
C / C++

Fortran
1 The syntax of the target parallel worksharing-loop construct is as follows:
2 !$omp target parallel do [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end target parallel do]
6 target or parallel do directives, except for copyin, with identical meanings and
7 restrictions.
8 If an end target parallel do directive is not specified, an end target parallel do
Fortran
10 Description
12 parallel worksharing-loop directive.
13 Restrictions
14 The restrictions for the target and parallel worksharing-loop constructs apply except for the
15 following explicit modifications:
21 Cross References
24 • Parallel Worksharing-Loop construct, see Section 2.16.1.

1 2.16.18 Target Parallel Worksharing-Loop SIMD Construct
2 Summary
3 The target parallel worksharing-loop SIMD construct is a shortcut for specifying a target
4 construct containing a parallel worksharing-loop SIMD construct and no other statements.
5 Syntax
C / C++
6 The syntax of the target parallel worksharing-loop SIMD construct is as follows:
7 #pragma omp target parallel for simd \
8 [clause[[,] clause] ... ] new-line
9 loop-nest
11 target or parallel for simd directives, except for copyin, with identical meanings and
12 restrictions.
C / C++
Fortran
13 The syntax of the target parallel worksharing-loop SIMD construct is as follows:
14 !$omp target parallel do simd [clause[ [,] clause] ... ]
15 loop-nest
16 [!$omp end target parallel do simd]
18 target or parallel do simd directives, except for copyin, with identical meanings and
19 restrictions.
20 If an end target parallel do simd directive is not specified, an end target parallel
21 do simd directive is assumed at the end of the loop-nest.
Fortran
22 Description
24 parallel worksharing-loop SIMD directive.

1 Restrictions
2 The restrictions for the target and parallel worksharing-loop SIMD constructs apply except for
3 the following explicit modifications:
10 Cross References
13 • Parallel worksharing-loop SIMD construct, see Section 2.16.5.
17 2.16.19 target parallel loop Construct

18 Summary
19 The target parallel loop construct is a shortcut for specifying a target construct
20 containing a parallel loop construct and no other statements.
21 Syntax
C / C++
22 The syntax of the target parallel loop construct is as follows:
23 #pragma omp target parallel loop [clause[ [,] clause] ... ] new-line
24 loop-nest
26 target or parallel loop directives, except for copyin, with identical meanings and
27 restrictions.
C / C++

Fortran
1 The syntax of the target parallel loop construct is as follows:
2 !$omp target parallel loop [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end target parallel loop]
6 target or parallel loop directives, except for copyin, with identical meanings and
7 restrictions.
8 If an end target parallel loop directive is not specified, an end target parallel
9 loop directive is assumed at the end of the loop-nest. nowait may not be specified on an
10 end target parallel loop directive.
Fortran
11 Description
13 parallel loop directive.
14 Restrictions
15 The restrictions for the target and parallel loop constructs apply except for the following
16 explicit modifications:
22 Cross References
25 • parallel loop construct, see Section 2.16.2.

1 2.16.20 target simd Construct
2 Summary
3 The target simd construct is a shortcut for specifying a target construct containing a simd
4 construct and no other statements.
5 Syntax
C / C++
6 The syntax of the target simd construct is as follows:
7 #pragma omp target simd [clause[ [,] clause] ... ] new-line
8 loop-nest
10 target or simd directives with identical meanings and restrictions.
C / C++
Fortran
11 The syntax of the target simd construct is as follows:
12 !$omp target simd [clause[ [,] clause] ... ]
13 loop-nest
14 [!$omp end target simd]
16 target or simd directives with identical meanings and restrictions.
17 If an end target simd directive is not specified, an end target simd directive is assumed at
18 the end of the loop-nest.
Fortran
19 Description
21 simd directive.
22 Restrictions
23 The restrictions for the target and simd constructs apply except for the following explicit
24 modifications:

1 Cross References
7 2.16.21 target teams Construct

8 Summary
9 The target teams construct is a shortcut for specifying a target construct containing a
10 teams construct and no other statements.
11 Syntax
C / C++
12 The syntax of the target teams construct is as follows:
13 #pragma omp target teams [clause[ [,] clause] ... ] new-line
14 structured-block
15 where clause can be any of the clauses accepted by the target or teams directives with identical
C / C++
Fortran
17 The syntax of the target teams construct is as follows:
18 !$omp target teams [clause[ [,] clause] ... ]
20 !$omp end target teams
21 or
22 !$omp target teams [clause[ [,] clause] ... ]
24 [!$omp end target teams]
25 where clause can be any of the clauses accepted by the target or teams directives with identical
Fortran
27 Description
29 teams directive.

1 Restrictions
2 The restrictions for the target and teams constructs apply.
3 Cross References
7 2.16.22 target teams distribute Construct

8 Summary
9 The target teams distribute construct is a shortcut for specifying a target construct
10 containing a teams distribute construct and no other statements.
11 Syntax
C / C++
12 The syntax of the target teams distribute construct is as follows:
13 #pragma omp target teams distribute [clause[ [,] clause] ... ] new-line
14 loop-nest
16 target or teams distribute directives with identical meanings and restrictions.
C / C++
Fortran
17 The syntax of the target teams distribute construct is as follows:
18 !$omp target teams distribute [clause[ [,] clause] ... ]
19 loop-nest
20 [!$omp end target teams distribute]
22 target or teams distribute directives with identical meanings and restrictions.
23 If an end target teams distribute directive is not specified, an end target teams
24 distribute directive is assumed at the end of the loop-nest.
Fortran
25 Description
27 teams distribute directive.
28 Restrictions
29 The restrictions for the target and teams distribute constructs apply.

1 Cross References
4 • teams distribute construct, see Section 2.16.11.
6 2.16.23 target teams distribute simd Construct

7 Summary
8 The target teams distribute simd construct is a shortcut for specifying a target
9 construct containing a teams distribute simd construct and no other statements.
10 Syntax
C / C++
11 The syntax of the target teams distribute simd construct is as follows:
12 #pragma omp target teams distribute simd \
14 loop-nest
16 target or teams distribute simd directives with identical meanings and restrictions.
C / C++
Fortran
17 The syntax of the target teams distribute simd construct is as follows:
18 !$omp target teams distribute simd [clause[ [,] clause] ... ]
19 loop-nest
20 [!$omp end target teams distribute simd]
22 target or teams distribute simd directives with identical meanings and restrictions.
23 If an end target teams distribute simd directive is not specified, an end target
24 teams distribute simd directive is assumed at the end of the loop-nest.
Fortran
25 Description
27 teams distribute simd directive.

1 Restrictions
2 The restrictions for the target and teams distribute simd constructs apply except for the
3 following explicit modifications:
9 Cross References
12 • teams distribute simd construct, see Section 2.16.12.
15 2.16.24 target teams loop Construct

16 Summary
17 The target teams loop construct is a shortcut for specifying a target construct containing a
18 teams loop construct and no other statements.
19 Syntax
C / C++
20 The syntax of the target teams loop construct is as follows:
21 #pragma omp target teams loop [clause[ [,] clause] ... ] new-line
22 loop-nest
24 target or teams loop directives with identical meanings and restrictions.
C / C++

Fortran
1 The syntax of the target teams loop construct is as follows:
2 !$omp target teams loop [clause[ [,] clause] ... ]
3 loop-nest
4 [!$omp end target teams loop]
6 target or teams loop directives with identical meanings and restrictions.
7 If an end target teams loop directive is not specified, an end target teams loop
Fortran
9 Description
11 teams loop directive.
12 Restrictions
13 The restrictions for the target and teams loop constructs apply.
14 Cross References
17 • Teams loop construct, see Section 2.16.15.
19 2.16.25 Target Teams Distribute Parallel Worksharing-Loop

20 Construct
21 Summary
22 The target teams distribute parallel worksharing-loop construct is a shortcut for specifying a
23 target construct containing a teams distribute parallel worksharing-loop construct and no other
24 statements.

1 Syntax
C / C++
2 The syntax of the target teams distribute parallel worksharing-loop construct is as follows:
3 #pragma omp target teams distribute parallel for \
5 loop-nest
7 target or teams distribute parallel for directives with identical meanings and
8 restrictions.
C / C++
Fortran
9 The syntax of the target teams distribute parallel worksharing-loop construct is as follows:
10 !$omp target teams distribute parallel do [clause[ [,] clause] ... ]
11 loop-nest
12 [!$omp end target teams distribute parallel do]
14 target or teams distribute parallel do directives with identical meanings and
15 restrictions.
16 If an end target teams distribute parallel do directive is not specified, an
17 end target teams distribute parallel do directive is assumed at the end of the
18 loop-nest.
Fortran
19 Description
21 teams distribute parallel worksharing-loop directive.
22 Restrictions
23 The restrictions for the target and teams distribute parallel worksharing-loop constructs apply

1 Cross References
4 • Teams distribute parallel worksharing-loop construct, see Section 2.16.13.
7 2.16.26 Target Teams Distribute Parallel Worksharing-Loop

8 SIMD Construct
9 Summary
10 The target teams distribute parallel worksharing-loop SIMD construct is a shortcut for specifying a
11 target construct containing a teams distribute parallel worksharing-loop SIMD construct and no
12 other statements.
13 Syntax
C / C++
14 The syntax of the target teams distribute parallel worksharing-loop SIMD construct is as follows:
15 #pragma omp target teams distribute parallel for simd \
17 loop-nest
19 target or teams distribute parallel for simd directives with identical meanings and
20 restrictions.
C / C++
Fortran
21 The syntax of the target teams distribute parallel worksharing-loop SIMD construct is as follows:
22 !$omp target teams distribute parallel do simd [clause[ [,] clause] ... ]
23 loop-nest
24 [!$omp end target teams distribute parallel do simd]
26 target or teams distribute parallel do simd directives with identical meanings and
27 restrictions.
28 If an end target teams distribute parallel do simd directive is not specified, an
29 end target teams distribute parallel do simd directive is assumed at the end of the
30 loop-nest.
Fortran

1 Description
3 teams distribute parallel worksharing-loop SIMD directive.
4 Restrictions
5 The restrictions for the target and teams distribute parallel worksharing-loop SIMD constructs
6 apply except for the following explicit modifications:
13 Cross References
16 • Teams distribute parallel worksharing-loop SIMD construct, see Section 2.16.14.
19 2.17 Clauses on Combined and Composite

20 Constructs
21 This section specifies the handling of clauses on combined or composite constructs and the
22 handling of implicit clauses from variables with predetermined data sharing if they are not
23 predetermined only on a particular construct. Some clauses are permitted only on a single leaf
24 construct of the combined or composite construct, in which case the effect is as if the clause is
25 applied to that specific construct. As detailed in this section, other clauses have the effect as if they
26 are applied to one or more leaf constructs.
27 The collapse clause is applied once to the combined or composite construct.
28 The effect of the private clause is as if it is applied only to the innermost leaf construct that
29 permits it.

1 The effect of the firstprivate clause is as if it is applied to one or more leaf constructs as
2 follows:
3 • To the distribute construct if it is among the constituent constructs;
4 • To the teams construct if it is among the constituent constructs and the distribute
5 construct is not;
6 • To the worksharing-loop construct if it is among the constituent constructs;
7 • To the taskloop construct if it is among the constituent constructs;
8 • To the parallel construct if it is among the constituent constructs and the worksharing-loop
9 construct or the taskloop construct is not;
10 • To the target construct if it is among the constituent constructs and the same list item does not
11 appear in a lastprivate or map clause.
12 If the parallel construct is among the constituent constructs and the effect is not as if the
13 firstprivate clause is applied to it by the above rules, then the effect is as if the shared
14 clause with the same list item is applied to the parallel construct. If the teams construct is
15 among the constituent constructs and the effect is not as if the firstprivate clause is applied to
16 it by the above rules, then the effect is as if the shared clause with the same list item is applied to
17 the teams construct.
18 The effect of the lastprivate clause is as if it is applied to all leaf constructs that permit the
19 clause. If the parallel construct is among the constituent constructs and the list item is not also
20 specified in the firstprivate clause, then the effect of the lastprivate clause is as if the
21 shared clause with the same list item is applied to the parallel construct. If the teams
22 construct is among the constituent constructs and the list item is not also specified in the
23 firstprivate clause, then the effect of the lastprivate clause is as if the shared clause
24 with the same list item is applied to the teams construct. If the target construct is among the
25 constituent constructs and the list item is not specified in a map clause, the effect of the
26 lastprivate clause is as if the same list item appears in a map clause with a map-type of
27 tofrom.
28 The effect of the shared, default, order, or allocate clause is as if it is applied to all leaf
29 constructs that permit the clause.
30 The effect of the reduction clause is as if it is applied to all leaf constructs that permit the
31 clause, except for the following constructs:
32 • The parallel construct, when combined with the sections, worksharing-loop, loop, or
33 taskloop construct; and
34 • The teams construct, when combined with the loop construct.
35 For the parallel and teams constructs above, the effect of the reduction clause instead is as
36 if each list item or, for any list item that is an array item, its corresponding base array or base
37 pointer appears in a shared clause for the construct. If the task reduction-modifier is specified,

1 the effect is as if it only modifies the behavior of the reduction clause on the innermost leaf
2 construct that accepts the modifier (see Section 2.21.5.4). If the inscan reduction-modifier is
3 specified, the effect is as if it modifies the behavior of the reduction clause on all constructs of
4 the combined construct to which the clause is applied and that accept the modifier. If the target
5 construct is among the constituent constructs and the list item is not specified in a map clause, the
6 effect of the reduction clause is as if the same list item appears in a map clause with a map-type
7 of tofrom.
8 The in_reduction clause applies to the single leaf construct on which it is permitted. If that
9 construct is a target construct, the effect is as if the same list item also appears in a map clause
10 with a map-type of tofrom and a map-type-modifier of always.
11 The effect of the if clause is described in Section 2.18.
12 The effect of the linear clause is as if it is applied to the innermost leaf construct. Additionally,
13 if the list item is not the iteration variable of a simd or worksharing-loop SIMD construct, the
14 effect on the outer leaf constructs is as if the list item was specified in firstprivate and
15 lastprivate clauses on the combined or composite construct, with the rules specified above
16 applied. If a list item of the linear clause is the iteration variable of a simd or worksharing-loop
17 SIMD construct and it is not declared in the construct, the effect on the outer leaf constructs is as if
18 the list item was specified in a lastprivate clause on the combined or composite construct with
19 the rules specified above applied.
20 The effect of the nowait clause is as if it is applied to the outermost leaf construct that permits it.
21 If the clauses have expressions on them, such as for various clauses where the argument of the
22 clause is an expression, or lower-bound, length, or stride expressions inside array sections (or
23 subscript and stride expressions in subscript-triplet for Fortran), or linear-step or alignment
24 expressions, the expressions are evaluated immediately before the construct to which the clause has
25 been split or duplicated per the above rules (therefore inside of the outer leaf constructs). However,
26 the expressions inside the num_teams and thread_limit clauses are always evaluated before
27 the outermost leaf construct.
28 The restriction that a list item may not appear in more than one data sharing clause with the
29 exception of specifying a variable in both firstprivate and lastprivate clauses applies
30 after the clauses are split or duplicated per the above rules.
31 2.18 if Clause
32 Summary
33 The semantics of an if clause are described in the section on the construct to which it applies. The
34 if clause directive-name-modifier names the associated construct to which an expression applies,
35 and is particularly useful for composite and combined constructs.

1 Syntax
C / C++
2 The syntax of the if clause is as follows:
3 if([ directive-name-modifier :] scalar-expression)
C / C++
Fortran
4 The syntax of the if clause is as follows:
5 if([ directive-name-modifier :] scalar-logical-expression)
Fortran
6 Description
7 The effect of the if clause depends on the construct to which it is applied. For combined or
8 composite constructs, the if clause only applies to the semantics of the construct named in the
9 directive-name-modifier if one is specified. If no directive-name-modifier is specified for a
10 combined or composite construct then the if clause applies to all constructs to which an if clause
11 can apply.
12 2.19 Synchronization Constructs and Clauses

13 A synchronization construct orders the completion of code executed by different threads. This
14 ordering is imposed by synchronizing flush operations that are executed as part of the region that
15 corresponds to the construct.
16 Synchronization through the use of synchronizing flush operations and atomic operations is
17 described in Section 1.4.4 and Section 1.4.6. Section 2.19.8.1 defines the behavior of synchronizing
18 flush operations that are implied at various other locations in an OpenMP program.
19 2.19.1 critical Construct

20 Summary
21 The critical construct restricts execution of the associated structured block to a single thread at
22 a time.
23 Syntax
C / C++
24 The syntax of the critical construct is as follows:
25 #pragma omp critical [(name) [[,] hint(hint-expression)] ] new-line
26 structured-block
27 where hint-expression is an integer constant expression that evaluates to a valid synchronization

28 hint (as described in Section 2.19.12).
C / C++

Fortran
1 The syntax of the critical construct is as follows:
2 !$omp critical [(name) [[,] hint(hint-expression)] ]
4 !$omp end critical [(name)]
5 or
6 !$omp critical [(name) [[,] hint(hint-expression)] ]
8 [!$omp end critical [(name)]]
9 where hint-expression is a constant expression that evaluates to a scalar value with kind
10 omp_sync_hint_kind and a value that is a valid synchronization hint (as described
11 in Section 2.19.12).
Fortran
12 Binding
13 The binding thread set for a critical region is all threads in the contention group.
14 Description
15 The region that corresponds to a critical construct is executed as if only a single thread at a
16 time among all threads in the contention group enters the region for execution, without regard to the
17 teams to which the threads belong. An optional name may be used to identify the critical
18 construct. All critical constructs without a name are considered to have the same unspecified
19 name.
C / C++
20 Identifiers used to identify a critical construct have external linkage and are in a name space
21 that is separate from the name spaces used by labels, tags, members, and ordinary identifiers.
C / C++
Fortran
22 The names of critical constructs are global entities of the program. If a name conflicts with
23 any other entity, the behavior of the program is unspecified.
Fortran
24 The threads of a contention group execute the critical region as if only one thread of the
25 contention group executes the critical region at a time. The critical construct enforces
26 these execution semantics with respect to all critical constructs with the same name in all
27 threads in the contention group.
28 If present, the hint clause gives the implementation additional information about the expected
29 runtime properties of the critical region that can optionally be used to optimize the
30 implementation. The presence of a hint clause does not affect the isolation guarantees provided
31 by the critical construct. If no hint clause is specified, the effect is as if
32 hint(omp_sync_hint_none) had been specified.

2 The critical-acquiring event occurs in a thread that encounters the critical construct on entry
3 to the critical region before initiating synchronization for the region.
4 The critical-acquired event occurs in a thread that encounters the critical construct after it
5 enters the region, but before it executes the structured block of the critical region.
6 The critical-released event occurs in a thread that encounters the critical construct after it
7 completes any synchronization on exit from the critical region.
8 Tool Callbacks
9 A thread dispatches a registered ompt_callback_mutex_acquire callback for each
10 occurrence of a critical-acquiring event in that thread. This callback has the type signature
11 ompt_callback_mutex_acquire_t.
12 A thread dispatches a registered ompt_callback_mutex_acquired callback for each
13 occurrence of a critical-acquired event in that thread. This callback has the type signature
14 ompt_callback_mutex_t.
15 A thread dispatches a registered ompt_callback_mutex_released callback for each
16 occurrence of a critical-released event in that thread. This callback has the type signature
18 The callbacks occur in the task that encounters the critical construct. The callbacks should receive
19 ompt_mutex_critical as their kind argument if practical, but a less specific kind is
20 acceptable.
21 Restrictions
22 Restrictions to the critical construct are as follows:
23 • Unless the effect is as if hint(omp_sync_hint_none) was specified, the critical
24 construct must specify a name.
25 • If the hint clause is specified, each of the critical constructs with the same name must
26 have a hint clause for which the hint-expression evaluates to the same value.
C++
27 • A throw executed inside a critical region must cause execution to resume within the same
28 critical region, and the same thread that threw the exception must catch it.
C++
Fortran
29 • If a name is specified on a critical directive, the same name must also be specified on the
30 end critical directive.
31 • If no name appears on the critical directive, no name can appear on the end critical
32 directive.
Fortran

1 Cross References
2 • Synchronization Hints, see Section 2.19.12.
3 • ompt_mutex_critical, see Section 4.4.4.16.
4 • ompt_callback_mutex_acquire_t, see Section 4.5.2.14.
5 • ompt_callback_mutex_t, see Section 4.5.2.15.
6 2.19.2 barrier Construct

7 Summary
8 The barrier construct specifies an explicit barrier at the point at which the construct appears.
9 The barrier construct is a stand-alone directive.
10 Syntax
C / C++
11 The syntax of the barrier construct is as follows:
12 #pragma omp barrier new-line
C / C++
Fortran
13 The syntax of the barrier construct is as follows:
14 !$omp barrier
Fortran
15 Binding
16 The binding thread set for a barrier region is the current team. A barrier region binds to the
18 Description
19 All threads of the team that is executing the binding parallel region must execute the barrier
20 region and complete execution of all explicit tasks bound to this parallel region before any are
21 allowed to continue execution beyond the barrier.
22 The barrier region includes an implicit task scheduling point in the current task region.

24 The explicit-barrier-begin event occurs in each thread that encounters the barrier construct on
25 entry to the barrier region.
26 The explicit-barrier-wait-begin event occurs when a task begins an interval of active or passive
27 waiting in a barrier region.

1 The explicit-barrier-wait-end event occurs when a task ends an interval of active or passive waiting
2 and resumes execution in a barrier region.
3 The explicit-barrier-end event occurs in each thread that encounters the barrier construct after
4 the barrier synchronization on exit from the barrier region.
5 A cancellation event occurs if cancellation is activated at an implicit cancellation point in a
6 barrier region.
7 Tool Callbacks
8 A thread dispatches a registered ompt_callback_sync_region callback with
9 ompt_sync_region_barrier_explicit as its kind argument and ompt_scope_begin
10 as its endpoint argument for each occurrence of an explicit-barrier-begin event. Similarly, a thread
11 dispatches a registered ompt_callback_sync_region callback with
12 ompt_sync_region_barrier_explicit as its kind argument and ompt_scope_end as
13 its endpoint argument for each occurrence of an explicit-barrier-end event. These callbacks occur
14 in the context of the task that encountered the barrier construct and have type signature
15 ompt_callback_sync_region_t.
16 A thread dispatches a registered ompt_callback_sync_region_wait callback with
17 ompt_sync_region_barrier_explicit as its kind argument and ompt_scope_begin
18 as its endpoint argument for each occurrence of an explicit-barrier-wait-begin event. Similarly, a
19 thread dispatches a registered ompt_callback_sync_region_wait callback with
20 ompt_sync_region_barrier_explicit as its kind argument and ompt_scope_end as
21 its endpoint argument for each occurrence of an explicit-barrier-wait-end event. These callbacks
22 occur in the context of the task that encountered the barrier construct and have type signature
24 A thread dispatches a registered ompt_callback_cancel callback with
25 ompt_cancel_detected as its flags argument for each occurrence of a cancellation event in
26 that thread. The callback occurs in the context of the encountering task. The callback has type
27 signature ompt_callback_cancel_t.
28 Restrictions
29 Restrictions to the barrier construct are as follows:
30 • Each barrier region must be encountered by all threads in a team or by none at all, unless
32 • The sequence of worksharing regions and barrier regions encountered must be the same for
33 every thread in a team.

1 Cross References
3 • ompt_sync_region_barrier, see Section 4.4.4.13.
4 • ompt_callback_sync_region_t, see Section 4.5.2.13.
5 • ompt_callback_cancel_t, see Section 4.5.2.18.
6 2.19.3 Implicit Barriers

7 This section describes the OMPT events and tool callbacks associated with implicit barriers, which
8 occur at the end of various regions as defined in the description of the constructs to which they
9 correspond. Implicit barriers are task scheduling points. For a description of task scheduling
10 points, associated events, and tool callbacks, see Section 2.12.6.

12 The implicit-barrier-begin event occurs in each implicit task at the beginning of an implicit barrier
13 region.
14 The implicit-barrier-wait-begin event occurs when a task begins an interval of active or passive
15 waiting in an implicit barrier region.
16 The implicit-barrier-wait-end event occurs when a task ends an interval of active or waiting and
17 resumes execution of an implicit barrier region.
18 The implicit-barrier-end event occurs in each implicit task after the barrier synchronization on exit
19 from an implicit barrier region.
20 A cancellation event occurs if cancellation is activated at an implicit cancellation point in an
21 implicit barrier region.
22 Tool Callbacks
23 A thread dispatches a registered ompt_callback_sync_region callback for each implicit
24 barrier begin and end event. Similarly, a thread dispatches a registered
25 ompt_callback_sync_region_wait callback for each implicit barrier wait-begin and
26 wait-end event. All callbacks for implicit barrier events execute in the context of the encountering
27 task and have type signature ompt_callback_sync_region_t.
28 For the implicit barrier at the end of a worksharing construct, the kind argument is
29 ompt_sync_region_barrier_implicit_workshare. For the implicit barrier at the end
30 of a parallel region, the kind argument is
31 ompt_sync_region_barrier_implicit_parallel. For an extra barrier added by an
32 OpenMP implementation, the kind argument is
33 ompt_sync_region_barrier_implementation. For a barrier at the end of a teams
34 region, the kind argument is ompt_sync_region_barrier_teams.

1 A thread dispatches a registered ompt_callback_cancel callback with
2 ompt_cancel_detected as its flags argument for each occurrence of a cancellation event in
3 that thread. The callback occurs in the context of the encountering task. The callback has type
4 signature ompt_callback_cancel_t.
5 Restrictions
6 Restrictions to implicit barriers are as follows:
7 • If a thread is in the state ompt_state_wait_barrier_implicit_parallel, a call to
8 ompt_get_parallel_info may return a pointer to a copy of the data object associated
9 with the parallel region rather than a pointer to the associated data object itself. Writing to the
10 data object returned by omp_get_parallel_info when a thread is in the
11 ompt_state_wait_barrier_implicit_parallel results in unspecified behavior.
12 Cross References
14 • ompt_sync_region_barrier_implementation,
15 ompt_sync_region_barrier_implicit_parallel
16 ompt_sync_region_barrier_teams, and
17 ompt_sync_region_barrier_implicit_workshare, see Section 4.4.4.13.
18 • ompt_cancel_detected, see Section 4.4.4.25.
21 2.19.4 Implementation-Specific Barriers

22 An OpenMP implementation can execute implementation-specific barriers that are not implied by
23 the OpenMP specification; therefore, no execution model events are bound to these barriers. The
24 implementation can handle these barriers like implicit barriers and dispatch all events as for
25 implicit barriers. These callbacks are dispatched with
26 ompt_sync_region_barrier_implementation — or
27 ompt_sync_region_barrier, if the implementation cannot make a distinction — as the kind
28 argument.
29 2.19.5 taskwait Construct

30 Summary
31 The taskwait construct specifies a wait on the completion of child tasks of the current task. The
32 taskwait construct is a stand-alone directive.

1 Syntax
C / C++
2 The syntax of the taskwait construct is as follows:
3 #pragma omp taskwait [clause[ [,] clause] ... ] new-line

5 depend([depend-modifier,]dependence-type : locator-list)
6 nowait
C / C++
Fortran
7 The syntax of the taskwait construct is as follows:
8 !$omp taskwait [clause[ [,] clause] ... ]

11 nowait
Fortran
12 Binding
13 The taskwait region binds to the current task region. The binding thread set of the taskwait
14 region is the current team.
15 Description
16 If no depend clause is present on the taskwait construct, the current task region is suspended
17 at an implicit task scheduling point associated with the construct. The current task region remains
18 suspended until all child tasks that it generated before the taskwait region complete execution.
19 If one or more depend clauses are present on the taskwait construct and the nowait clause is
20 not also present, the behavior is as if these clauses were applied to a task construct with an empty
21 associated structured block that generates a mergeable and included task. Thus, the current task
22 region is suspended until the predecessor tasks of this task complete execution.
23 If one or more depend clauses are present on the taskwait construct and the nowait clause is
24 also present, the behavior is as if these clauses were applied to a task construct with an empty
25 associated structured block that generates a task for which execution may be deferred. Thus, all
26 predecessor tasks of this task must complete execution before any subsequently generated task that
27 depends on this task starts its execution.

2 The taskwait-begin event occurs in a thread when it encounters a taskwait construct with no
3 depend clause on entry to the taskwait region.
4 The taskwait-wait-begin event occurs when a task begins an interval of active or passive waiting in
5 a region corresponding to a taskwait construct with no depend clause.
6 The taskwait-wait-end event occurs when a task ends an interval of active or passive waiting and
7 resumes execution from a region corresponding to a taskwait construct with no depend clause.
8 The taskwait-end event occurs in a thread when it encounters a taskwait construct with no
9 depend clause after the taskwait synchronization on exit from the taskwait region.
10 The taskwait-init event occurs in a thread when it encounters a taskwait construct with one or
11 more depend clauses on entry to the taskwait region.
12 The taskwait-complete event occurs on completion of the dependent task that results from a
13 taskwait construct with one or more depend clauses, in the context of the thread that executes
14 the dependent task and before any subsequently generated task that depends on the dependent task
15 starts its execution.
16 Tool Callbacks
18 ompt_sync_region_taskwait as its kind argument and ompt_scope_begin as its
19 endpoint argument for each occurrence of a taskwait-begin event in the task that encounters the
20 taskwait construct. Similarly, a thread dispatches a registered
21 ompt_callback_sync_region callback with ompt_sync_region_taskwait as its
22 kind argument and ompt_scope_end as its endpoint argument for each occurrence of a
23 taskwait-end event in the task that encounters the taskwait construct. These callbacks occur in
24 the task that encounters the taskwait construct and have the type signature
27 ompt_sync_region_taskwait as its kind argument and ompt_scope_begin as its
28 endpoint argument for each occurrence of a taskwait-wait-begin event. Similarly, a thread
29 dispatches a registered ompt_callback_sync_region_wait callback with
30 ompt_sync_region_taskwait as its kind argument and ompt_scope_end as its endpoint
31 argument for each occurrence of a taskwait-wait-end event. These callbacks occur in the context of
32 the task that encounters the taskwait construct and have type signature
34 A thread dispatches a registered ompt_callback_task_create callback for each occurrence
35 of a taskwait-init event in the context of the encountering task. This callback has the type signature
36 ompt_callback_task_create_t. In the dispatched callback, (flags &
37 ompt_task_taskwait) always evaluates to true. If the nowait clause is not present,
38 (flags & ompt_task_undeferred) also evaluates to true.

1 A thread dispatches a registered ompt_callback_task_schedule callback for each
2 occurrence of a taskwait-complete event. This callback has the type signature
3 ompt_callback_task_schedule_t with ompt_taskwait_complete as its
4 prior_task_status argument.
5 Restrictions
6 Restrictions to the taskwait construct are as follows:
7 • The mutexinoutset dependence-type may not appear in a depend clause on a taskwait
8 construct.
9 • If the dependence-type of a depend clause is depobj then the dependence objects cannot
10 represent dependences of the mutexinoutset dependence type.
11 • The nowait clause may only appear on a taskwait directive if the depend clause is present.
12 • At most one nowait clause can appear on a taskwait directive.
13 Cross References
18 • ompt_sync_region_taskwait, see Section 4.4.4.13.
20 2.19.6 taskgroup Construct

21 Summary
22 The taskgroup construct specifies a wait on completion of child tasks of the current task and
23 their descendent tasks.
24 Syntax
C / C++
25 The syntax of the taskgroup construct is as follows:
26 #pragma omp taskgroup [clause[[,] clause] ...] new-line
27 structured-block

29 task_reduction(reduction-identifier : list)
30 allocate([allocator: ]list)
C / C++

Fortran
1 The syntax of the taskgroup construct is as follows:
2 !$omp taskgroup [clause [ [,] clause] ...]
4 !$omp end taskgroup
5 or
6 !$omp taskgroup [clause [ [,] clause] ...]
8 [!$omp end taskgroup]

11 allocate([allocator: ]list)
Fortran
12 Binding
13 The binding task set of a taskgroup region is all tasks of the current team that are generated in
14 the region. A taskgroup region binds to the innermost enclosing parallel region.
15 Description
16 When a thread encounters a taskgroup construct, it starts executing the region. All child tasks
17 generated in the taskgroup region and all of their descendants that bind to the same parallel
18 region as the taskgroup region are part of the taskgroup set associated with the taskgroup
19 region.
20 An implicit task scheduling point occurs at the end of the taskgroup region. The current task is
21 suspended at the task scheduling point until all tasks in the taskgroup set complete execution.

23 The taskgroup-begin event occurs in each thread that encounters the taskgroup construct on
24 entry to the taskgroup region.
25 The taskgroup-wait-begin event occurs when a task begins an interval of active or passive waiting
26 in a taskgroup region.
27 The taskgroup-wait-end event occurs when a task ends an interval of active or passive waiting and
28 resumes execution in a taskgroup region.
29 The taskgroup-end event occurs in each thread that encounters the taskgroup construct after the
30 taskgroup synchronization on exit from the taskgroup region.

1 Tool Callbacks
3 ompt_sync_region_taskgroup as its kind argument and ompt_scope_begin as its
4 endpoint argument for each occurrence of a taskgroup-begin event in the task that encounters the
5 taskgroup construct. Similarly, a thread dispatches a registered
6 ompt_callback_sync_region callback with ompt_sync_region_taskgroup as its
7 kind argument and ompt_scope_end as its endpoint argument for each occurrence of a
8 taskgroup-end event in the task that encounters the taskgroup construct. These callbacks occur
9 in the task that encounters the taskgroup construct and have the type signature
12 ompt_sync_region_taskgroup as its kind argument and ompt_scope_begin as its
13 endpoint argument for each occurrence of a taskgroup-wait-begin event. Similarly, a thread
14 dispatches a registered ompt_callback_sync_region_wait callback with
15 ompt_sync_region_taskgroup as its kind argument and ompt_scope_end as its
16 endpoint argument for each occurrence of a taskgroup-wait-end event. These callbacks occur in the
17 context of the task that encounters the taskgroup construct and have type signature
19 Cross References
21 • task_reduction clause, see Section 2.21.5.5.
23 • ompt_sync_region_taskgroup, see Section 4.4.4.13.
25 2.19.7 atomic Construct

26 Summary
27 The atomic construct ensures that a specific storage location is accessed atomically, rather than
28 exposing it to the possibility of multiple, simultaneous reading and writing threads that may result
29 in indeterminate values.
30 Syntax
31 In the following syntax, atomic-clause is a clause that indicates the semantics for which atomicity is
32 enforced, and memory-order-clause is a clause that indicates the memory ordering behavior of the
33 construct. Specifically, atomic-clause is one of the following:
34 read
35 write
36 update

1 memory-order-clause is one of the following:
2 seq_cst
3 acq_rel
4 release
5 acquire
6 relaxed
7 and clause is either atomic-clause, memory-order-clause or one of the following:

8 capture
9 compare
10 hint(hint-expression)
11 fail(seq_cst | acquire | relaxed)
12 weak
C / C++
13 The syntax of the atomic construct is:
14 #pragma omp atomic [clause[[,] clause] ... ] new-line
15 statement
16 where statement is a statement with one of the following forms:

17 • If atomic-clause is read then statement is read-expr-stmt, a read expression statement that has
18 the following form:
19 v = x;
20 • If atomic-clause is write then statement is write-expr-stmt, a write expression statement that

21 has the following form:
22 x = expr;
23 • If atomic-clause is update then statement can be update-expr-stmt, an update expression

24 statement that has one of the following forms:
25 x++;
26 x--;
27 ++x;
28 --x;
29 x binop= expr;
30 x = x binop expr;
31 x = expr binop x;

C/C++ (cont.)
1 • If the compare clause is present then either statement is:

2 – cond-expr-stmt, a conditional expression statement that has one of the following forms:
3 x = expr ordop x ? expr : x;
4 x = x ordop expr ? expr : x;
5 x = x == e ? d : x;
6 – or cond-update-stmt, a conditional update statement that has one of the following forms:
7 if(expr ordop x) { x = expr; }
8 if(x ordop expr) { x = expr; }
9 if(x == e) { x = d; }
10 • If the capture clause is present, statement can have one of the following forms:
11 v = expr-stmt
12 { v = x; expr-stmt }
13 { expr-stmt v = x; }
14 where expr-stmt is either write-expr-stmt, update-expr-stmt or cond-expr-stmt.

15 • If both the compare and capture clauses are present then the following forms are also valid:
16 { v = x; cond-update-stmt }
17 { cond-update-stmt v = x; }
18 if(x == e) { x = d; } else { v = x; }
19 { r = x == e; if(r) { x = d; } }
20 { r = x == e; if(r) { x = d; } else { v = x; } }
21 In the preceding expressions:

22 • x, r (result), and v (as applicable) are lvalue expressions with scalar type.
23 • e (expected) is an expression with scalar type, in forms where e is assigned it must be an lvalue.
24 • d (desired) is an expression with scalar type.
25 • r must be of integral type.
26 • During the execution of an atomic region, multiple syntactic occurrences of x must designate
27 the same storage location.
28 • None of v, x, r, d and expr (as applicable) may access the storage location designated by any
29 other in the list.
30 • e and v may refer to, or access, the same storage location.
31 • expr is an expression with scalar type.
32 • The order operation, ordop, is one of <, or >.
33 • binop is one of +, *, -, /, &, ^, |, <<, or >>.

1 • binop, binop=, ordop, ==, ++, and -- are not overloaded operators.
2 • The expression x binop expr must be numerically equivalent to x binop (expr). This requirement
3 is satisfied if the operators in expr have precedence greater than binop, or by using parentheses
4 around expr or subexpressions of expr.
5 • The expression expr binop x must be numerically equivalent to (expr) binop x. This requirement
6 is satisfied if the operators in expr have precedence equal to or greater than binop, or by using
7 parentheses around expr or subexpressions of expr.
8 • == comparisons are performed by comparing the bits that comprise each object as with memcmp.
9 • For forms that allow multiple occurrences of x, the number of times that x is evaluated is
10 unspecified.
11 • hint-expression is a constant integer expression that evaluates to a valid synchronization hint.
C / C++
Fortran
12 The syntax of the atomic construct takes any of the following forms:
13 !$omp atomic [clause[[[,] clause] ... ] [,]]
14 statement
15 [!$omp end atomic]
16 or
17 !$omp atomic [clause[[[,] clause] ... ] [,]] capture [[,] clause [[[,] clause] ... ]]
18 statement
19 capture-statement
21 or
22 !$omp atomic [clause[[[,] clause] ... ] [,]] capture [[,] clause [[[,] clause] ... ]]
23 capture-statement
24 statement
26 where capture-statement has the following form:

27 v = x
28 and statement is a statement with one of the following forms:

29 • If atomic-clause is read then statement is:
30 v = x;
31 • If atomic-clause is write then statement is:

32 x = expr

Fortran (cont.)
1 • If atomic-clause is update then:

2 – statement can have one of the following forms:
3 x = x operator expr
4 x = expr operator x
5 x = intrinsic-procedure-name (x, expr-list)
6 x = intrinsic-procedure-name (expr-list, x)
7 – or, if the capture clause is present and statement is preceded or followed by

8 capture-statement, statement can also have this form:
9 x = expr
10 • If the compare clause is present then:

11 – statement has one of these forms:
12 if (x == e) then
13 x = d
14 end if
15 if (x == e) x = d
16 – or, if the capture clause is also present and statement is not preceded or followed by
17 capture-statement, statement has this form:
18 if (x == e) then
19 x = d
20 else
21 v = x
22 end if
23 In the preceding statements:

24 • x, v, d and e (as applicable) are scalar variables of intrinsic type.
25 • x must not have the ALLOCATABLE attribute.
26 • During the execution of an atomic region, multiple syntactic occurrences of x must designate the
27 same storage location.
28 • None of v, expr, and expr-list (as applicable) may access the same storage location as x.
29 • None of x, expr, and expr-list (as applicable) may access the same storage location as v.
30 • expr is a scalar expression.
31 • expr-list is a comma-separated, non-empty list of scalar expressions. If intrinsic-procedure-name
32 refers to IAND, IOR, or IEOR, exactly one expression must appear in expr-list.
33 • intrinsic-procedure-name is one of MAX, MIN, IAND, IOR, or IEOR.
34 • operator is one of +, *, -, /, .AND., .OR., .EQV., or .NEQV..

1 • The expression x operator expr must be numerically equivalent to x operator (expr). This
2 requirement is satisfied if the operators in expr have precedence greater than operator, or by
3 using parentheses around expr or subexpressions of expr.
4 • The expression expr operator x must be numerically equivalent to (expr) operator x. This
5 requirement is satisfied if the operators in expr have precedence equal to or greater than
6 operator, or by using parentheses around expr or subexpressions of expr.
7 • intrinsic-procedure-name must refer to the intrinsic procedure name and not to other program
8 entities.
9 • operator must refer to the intrinsic operator and not to a user-defined operator.
10 • All assignments must be intrinsic assignments.
11 • For forms that allow multiple occurrences of x, the number of times that x is evaluated is
12 unspecified.
13 • hint-expression is a constant expression that evaluates to a scalar value with kind
14 omp_sync_hint_kind and a value that is a valid synchronization hint.
Fortran
15 Binding
16 If the size of x is 8, 16, 32, or 64 bits and x is aligned to a multiple of its size, the binding thread set
17 for the atomic region is all threads on the device. Otherwise, the binding thread set for the
18 atomic region is all threads in the contention group. atomic regions enforce exclusive access
19 with respect to other atomic regions that access the same storage location x among all threads in
20 the binding thread set without regard to the teams to which the threads belong.
21 Description
22 If atomic-clause is not present on the construct, the behavior is as if the update clause is specified.
23 The atomic construct with the read clause results in an atomic read of the location designated
24 by x.
25 The atomic construct with the write clause results in an atomic write of the location designated
26 by x.
27 The atomic construct with the update clause results in an atomic update of the location
28 designated by x using the designated operator or intrinsic. Only the read and write of the location
29 designated by x are performed mutually atomically. The evaluation of expr or expr-list need not be
30 atomic with respect to the read or write of the location designated by x. No task scheduling points
31 are allowed between the read and the write of the location designated by x.
32 If the capture clause is present, the atomic update is an atomic captured update — an atomic
33 update to the location designated by x using the designated operator or intrinsic while also
34 capturing the original or final value of the location designated by x with respect to the atomic
35 update. The original or final value of the location designated by x is written in the location

1 designated by v based on the base language semantics of structured block or statements of the
2 atomic construct. Only the read and write of the location designated by x are performed mutually
3 atomically. Neither the evaluation of expr or expr-list, nor the write to the location designated by v,
4 need be atomic with respect to the read or write of the location designated by x.
5 If the compare clause is present, the atomic update is an atomic conditional update. For forms
6 that use an equality comparison, the operation is an atomic compare-and-swap — it atomically
7 compares the value of x to e and if they are equal writes the value of d into the location designated
8 by x. Based on the base language semantics of the associated structured block of the atomic
9 construct, the original or final value of the location designated by x is written to the location
10 designated by v, which is allowed to be the same location as designated by e, or the result of the
11 comparison is written to the location designated by r. Only the read and write of the location
12 designated by x are performed mutually atomically. Neither the evaluation of either e or d nor
13 writes to the locations designated by v and r need be atomic with respect to the read or write of the
14 location designated by x.
C / C++
15 If the compare clause is present, forms that use ordop are logically an atomic maximum or
16 minimum, but they may be implemented with a compare-and-swap loop with short-circuiting. For
17 forms where statement is cond-expr-stmt, if the result of the condition implies that the value of x
18 does not change then the update may not occur.
C / C++
19 If the weak clause is present, the comparison performed by an atomic compare-and-swap operation
20 may spuriously fail, evaluating to not equal even when the values are equal.
21
22 Note – Allowing for spurious failure by specifying a weak clause can result in performance gains
23 on some systems when using compare-and-swap in a loop. For cases where a single
24 compare-and-swap would otherwise be sufficient, using a loop over a weak compare-and-swap is
25 unlikely to improve performance.
26
27 If memory-order-clause is present, or implicitly provided by a requires directive, it specifies the
28 effective memory ordering and otherwise the effective memory ordering is relaxed. If the fail
29 clause is present, its parameter overrides the effective memory ordering used if the comparison for
30 an atomic conditional update fails.
31 The atomic construct may be used to enforce memory consistency between threads, based on the
32 guarantees provided by Section 1.4.6. A strong flush on the location designated by x is performed
33 on entry to and exit from the atomic operation, ensuring that the set of all atomic operations applied
34 to the same location in a race-free program has a total completion order. If the write or update
35 clause is specified, the atomic operation is not an atomic conditional update for which the
36 comparison fails, and the effective memory ordering is release, acq_rel, or seq_cst, the
37 strong flush on entry to the atomic operation is also a release flush. If the read or update clause
38 is specified and the effective memory ordering is acquire, acq_rel, or seq_cst then the

1 strong flush on exit from the atomic operation is also an acquire flush. Therefore, if the effective
2 memory ordering is not relaxed, release and/or acquire flush operations are implied and permit
3 synchronization between the threads without the use of explicit flush directives.
4 For all forms of the atomic construct, any combination of two or more of these atomic
5 constructs enforces mutually exclusive access to the locations designated by x among threads in the
6 binding thread set. To avoid data races, all accesses of the locations designated by x that could
7 potentially occur in parallel must be protected with an atomic construct.
8 atomic regions do not guarantee exclusive access with respect to any accesses outside of
9 atomic regions to the same storage location x even if those accesses occur during a critical
10 or ordered region, while an OpenMP lock is owned by the executing task, or during the
11 execution of a reduction clause.
12 However, other OpenMP synchronization can ensure the desired exclusive access. For example, a
13 barrier that follows a series of atomic updates to x guarantees that subsequent accesses do not form
14 a race with the atomic accesses.
15 A compliant implementation may enforce exclusive access between atomic regions that update
16 different storage locations. The circumstances under which this occurs are implementation defined.
17 If the storage location designated by x is not size-aligned (that is, if the byte alignment of x is not a
18 multiple of the size of x), then the behavior of the atomic region is implementation defined.
19 If present, the hint clause gives the implementation additional information about the expected
20 properties of the atomic operation that can optionally be used to optimize the implementation. The
21 presence of a hint clause does not affect the semantics of the atomic construct, and all hints
22 may be ignored. If no hint clause is specified, the effect is as if
23 hint(omp_sync_hint_none) had been specified.

25 The atomic-acquiring event occurs in the thread that encounters the atomic construct on entry to
26 the atomic region before initiating synchronization for the region.
27 The atomic-acquired event occurs in the thread that encounters the atomic construct after it
28 enters the region, but before it executes the structured block of the atomic region.
29 The atomic-released event occurs in the thread that encounters the atomic construct after it
30 completes any synchronization on exit from the atomic region.
31 Tool Callbacks
33 occurrence of an atomic-acquiring event in that thread. This callback has the type signature
36 occurrence of an atomic-acquired event in that thread. This callback has the type signature

1 A thread dispatches a registered ompt_callback_mutex_released callback with
2 ompt_mutex_atomic as the kind argument if practical, although a less specific kind may be
3 used, for each occurrence of an atomic-released event in that thread. This callback has the type
4 signature ompt_callback_mutex_t and occurs in the task that encounters the atomic
5 construct.
6 Restrictions
7 Restrictions to the atomic construct are as follows:
8 • OpenMP constructs may not be encountered during execution of an atomic region.
9 • At most one atomic-clause may appear on the construct.
10 • At most one memory-order-clause may appear on the construct.
11 • At most one hint clause may appear on the construct.
12 • At most one capture clause may appear on the construct.
13 • At most one compare clause may appear on the construct.
14 • If a capture or compare clause appears on the construct then atomic-clause must be
15 update.
16 • At most one fail clause may appear on the construct.
17 • At most one weak clause may appear on the construct.
18 • If atomic-clause is read then memory-order-clause must not be release.
19 • If atomic-clause is write then memory-order-clause must not be acquire.
20 • The weak clause may only appear if the resulting atomic operation is an atomic conditional
21 update for which the comparison tests for equality.
C / C++
22 • All atomic accesses to the storage locations designated by x throughout the program are required
23 to have a compatible type.
24 • The fail clause may only appear if the resulting atomic operation is an atomic conditional
25 update.
C / C++
Fortran
26 • All atomic accesses to the storage locations designated by x throughout the program are required
27 to have the same type and type parameters.
28 • The fail clause may only appear if the resulting atomic operation is an atomic conditional
29 update or an atomic update where intrinsic-procedure-name is either MAX or MIN.
Fortran

1 Cross References
2 • requires directive, see Section 2.5.1.
4 • barrier construct, see Section 2.19.2.
5 • flush construct, see Section 2.19.8.
7 • Synchronization hints, see Section 2.19.12.
9 • lock routines, see Section 3.9.
10 • ompt_mutex_atomic, see Section 4.4.4.16.
13 2.19.8 flush Construct

14 Summary
15 The flush construct executes the OpenMP flush operation. This operation makes a thread’s
16 temporary view of memory consistent with memory and enforces an order on the memory
17 operations of the variables explicitly specified or implied. See the memory model description in
18 Section 1.4 for more details. The flush construct is a stand-alone directive.
19 Syntax
C / C++
20 The syntax of the flush construct is as follows:
21 #pragma omp flush [memory-order-clause] [(list)] new-line
22 where memory-order-clause is one of the following:

23 seq_cst
24 acq_rel
25 release
26 acquire
C / C++

Fortran
1 The syntax of the flush construct is as follows:
2 !$omp flush [memory-order-clause] [(list)]
3 where memory-order-clause is one of the following:

4 seq_cst
5 acq_rel
6 release
7 acquire
Fortran
8 Binding
9 The binding thread set for a flush region is all threads in the device-set of its flush operation.
10 Execution of a flush region affects the memory and it affects the temporary view of memory of
11 the encountering thread. It does not affect the temporary view of other threads. Other threads on
12 devices in the device-set must themselves execute a flush operation in order to be guaranteed to
13 observe the effects of the flush operation of the encountering thread.
14 Description
15 If neither memory-order-clause nor a list appears on the flush construct then the behavior is as if
16 memory-order-clause is seq_cst.
17 A flush construct with the seq_cst clause, executed on a given thread, operates as if all data
18 storage blocks that are accessible to the thread are flushed by a strong flush operation. A flush
19 construct with a list applies a strong flush operation to the items in the list, and the flush operation
20 does not complete until the operation is complete for all specified list items. An implementation
21 may implement a flush construct with a list by ignoring the list and treating it the same as a
22 flush construct with the seq_cst clause.
23 If no list items are specified, the flush operation has the release and/or acquire flush properties:
24 • If memory-order-clause is seq_cst or acq_rel, the flush operation is both a release flush
25 and an acquire flush.
26 • If memory-order-clause is release, the flush operation is a release flush.
27 • If memory-order-clause is acquire, the flush operation is an acquire flush.

C / C++
1 If a pointer is present in the list, the pointer itself is flushed, not the memory block to which the
2 pointer refers.
3 A flush construct without a list corresponds to a call to atomic_thread_fence, where the
4 argument is given by the identifier that results from prefixing memory_order_ to
5 memory-order-clause.
6 For a flush construct without a list, the generated flush region implicitly performs the
7 corresponding call to atomic_thread_fence. The behavior of an explicit call to
8 atomic_thread_fence that occurs in the program and does not have the argument
9 memory_order_consume is as if the call is replaced by its corresponding flush construct.
C / C++
Fortran
10 If the list item or a subobject of the list item has the POINTER attribute, the allocation or
11 association status of the POINTER item is flushed, but the pointer target is not. If the list item is a
12 Cray pointer, the pointer is flushed, but the object to which it points is not. Cray pointer support has
13 been deprecated. If the list item is of type C_PTR, the variable is flushed, but the storage that
14 corresponds to that address is not flushed. If the list item or the subobject of the list item has the
15 ALLOCATABLE attribute and has an allocation status of allocated, the allocated variable is flushed;
16 otherwise the allocation status is flushed.
Fortran
17
18 Note – Use of a flush construct with a list is extremely error prone and users are strongly
19 discouraged from attempting it. The following examples illustrate the ordering properties of the
20 flush operation. In the following incorrect pseudocode example, the programmer intends to prevent
21 simultaneous execution of the protected section by the two threads, but the program does not work
22 properly because it does not enforce the proper ordering of the operations on variables a and b.
23 Any shared data accessed in the protected section is not guaranteed to be current or consistent
24 during or after the protected section. The atomic notation in the pseudocode in the following two
25 examples indicates that the accesses to a and b are atomic write and atomic read operations.
26 Otherwise both examples would contain data races and automatically result in unspecified behavior.
27 The flush operations are strong flushes that are applied to the specified flush lists

Incorrect example:
a = b = 0
thread 1 thread 2
atomic(b = 1) atomic(a = 1)
1 flush(b) flush(a)
flush(a) flush(b)
atomic(tmp = a) atomic(tmp = b)
if (tmp == 0) then if (tmp == 0) then
protected section protected section
end if end if
2 The problem with this example is that operations on variables a and b are not ordered with respect
3 to each other. For instance, nothing prevents the compiler from moving the flush of b on thread 1 or
4 the flush of a on thread 2 to a position completely after the protected section (assuming that the
5 protected section on thread 1 does not reference b and the protected section on thread 2 does not
6 reference a). If either re-ordering happens, both threads can simultaneously execute the protected
7 section.
8 The following pseudocode example correctly ensures that the protected section is executed by only
9 one thread at a time. Execution of the protected section by neither thread is considered correct in
10 this example. This occurs if both flushes complete prior to either thread executing its if statement.
Correct example:
a = b = 0
thread 1 thread 2
atomic(b = 1) atomic(a = 1)
11
flush(a,b) flush(a,b)
atomic(tmp = a) atomic(tmp = b)
if (tmp == 0) then if (tmp == 0) then
protected section protected section
end if end if
12 The compiler is prohibited from moving the flush at all for either thread, ensuring that the
13 respective assignment is complete and the data is flushed before the if statement is executed.
14

2 The flush event occurs in a thread that encounters the flush construct.
3 Tool Callbacks
4 A thread dispatches a registered ompt_callback_flush callback for each occurrence of a
5 flush event in that thread. This callback has the type signature ompt_callback_flush_t.
6 Restrictions
7 Restrictions to the flush construct are as follows:
8 • If a memory-order-clause is specified, list items must not be specified on the flush directive.
9 Cross References
10 • ompt_callback_flush_t, see Section 4.5.2.17.
11 2.19.8.1 Implicit Flushes

12 Flush operations implied when executing an atomic region are described in Section 2.19.7.
13 A flush region that corresponds to a flush directive with the release clause present is
14 implied at the following locations:
15 • During a barrier region;
16 • At entry to a parallel region;
17 • At entry to a teams region;
18 • At exit from a critical region;
19 • During an omp_unset_lock region;
20 • During an omp_unset_nest_lock region;
21 • Immediately before every task scheduling point;
22 • At exit from the task region of each implicit task;
23 • At exit from an ordered region, if a threads clause or a depend clause with a source
24 dependence type is present, or if no clauses are present; and
25 • During a cancel region, if the cancel-var ICV is true.
26 For a target construct, the device-set of an implicit release flush that is performed in a target task
27 during the generation of the target region and that is performed on exit from the initial task
28 region that implicitly encloses the target region consists of the devices that execute the target
29 task and the target region.
30 A flush region that corresponds to a flush directive with the acquire clause present is
31 implied at the following locations:

1 • During a barrier region;
2 • At exit from a teams region;
3 • At entry to a critical region;
4 • If the region causes the lock to be set, during:
5 – an omp_set_lock region;
6 – an omp_test_lock region;
7 – an omp_set_nest_lock region; and
8 – an omp_test_nest_lock region;
9 • Immediately after every task scheduling point;
10 • At entry to the task region of each implicit task;
11 • At entry to an ordered region, if a threads clause or a depend clause with a sink
12 dependence type is present, or if no clauses are present; and
13 • Immediately before a cancellation point, if the cancel-var ICV is true and cancellation has been
14 activated.
15 For a target construct, the device-set of an implicit acquire flush that is performed in a target
16 task following the generation of the target region or that is performed on entry to the initial task
17 region that implicitly encloses the target region consists of the devices that execute the target
18 task and the target region.
19
20 Note – A flush region is not implied at the following locations:

21 • At entry to worksharing regions; and
22 • At entry to or exit from masked regions.
23
24 The synchronization behavior of implicit flushes is as follows:

25 • When a thread executes an atomic region for which the corresponding construct has the
26 release, acq_rel, or seq_cst clause and specifies an atomic operation that starts a given
27 release sequence, the release flush that is performed on entry to the atomic operation
28 synchronizes with an acquire flush that is performed by a different thread and has an associated
29 atomic operation that reads a value written by a modification in the release sequence.
30 • When a thread executes an atomic region for which the corresponding construct has the
31 acquire, acq_rel, or seq_cst clause and specifies an atomic operation that reads a value
32 written by a given modification, a release flush that is performed by a different thread and has an

1 associated release sequence that contains that modification synchronizes with the acquire flush
2 that is performed on exit from the atomic operation.
3 • When a thread executes a critical region that has a given name, the behavior is as if the
4 release flush performed on exit from the region synchronizes with the acquire flush performed on
5 entry to the next critical region with the same name that is performed by a different thread,
6 if it exists.
7 • When a thread team executes a barrier region, the behavior is as if the release flush
8 performed by each thread within the region synchronizes with the acquire flush performed by all
9 other threads within the region.
10 • When a thread executes a taskwait region that does not result in the creation of a dependent
11 task and the task that encounters the corresponding taskwait construct has at least one child
12 task, the behavior is as if each thread that executes a child task that is generated before the
13 taskwait region performs a release flush upon completion of the child task that synchronizes
14 with an acquire flush performed in the taskwait region.
15 • When a thread executes a taskgroup region, the behavior is as if each thread that executes a
16 remaining descendant task performs a release flush upon completion of the descendant task that
17 synchronizes with an acquire flush performed on exit from the taskgroup region.
18 • When a thread executes an ordered region that does not arise from a stand-alone ordered
19 directive, the behavior is as if the release flush performed on exit from the region synchronizes
20 with the acquire flush performed on entry to an ordered region encountered in the next logical
21 iteration to be executed by a different thread, if it exists.
22 • When a thread executes an ordered region that arises from a stand-alone ordered directive,
23 the behavior is as if the release flush performed in the ordered region from a given source
24 iteration synchronizes with the acquire flush performed in all ordered regions executed by a
25 different thread that are waiting for dependences on that iteration to be satisfied.
26 • When a thread team begins execution of a parallel region, the behavior is as if the release
27 flush performed by the primary thread on entry to the parallel region synchronizes with the
28 acquire flush performed on entry to each implicit task that is assigned to a different thread.
29 • When an initial thread begins execution of a target region that is generated by a different
30 thread from a target task, the behavior is as if the release flush performed by the generating
31 thread in the target task synchronizes with the acquire flush performed by the initial thread on
32 entry to its initial task region.
33 • When an initial thread completes execution of a target region that is generated by a different
34 thread from a target task, the behavior is as if the release flush performed by the initial thread on
35 exit from its initial task region synchronizes with the acquire flush performed by the generating
36 thread in the target task.
37 • When a thread encounters a teams construct, the behavior is as if the release flush performed by
38 the thread on entry to the teams region synchronizes with the acquire flush performed on entry

1 to each initial task that is executed by a different initial thread that participates in the execution of
2 the teams region.
3 • When a thread that encounters a teams construct reaches the end of the teams region, the
4 behavior is as if the release flush performed by each different participating initial thread at exit
5 from its initial task synchronizes with the acquire flush performed by the thread at exit from the
6 teams region.
7 • When a task generates an explicit task that begins execution on a different thread, the behavior is
8 as if the thread that is executing the generating task performs a release flush that synchronizes
9 with the acquire flush performed by the thread that begins to execute the explicit task.
10 • When an undeferred task completes execution on a given thread that is different from the thread
11 on which its generating task is suspended, the behavior is as if a release flush performed by the
12 thread that completes execution of the undeferred task synchronizes with an acquire flush
13 performed by the thread that resumes execution of the generating task.
14 • When a dependent task with one or more predecessor tasks begins execution on a given thread,
15 the behavior is as if each release flush performed by a different thread on completion of a
16 predecessor task synchronizes with the acquire flush performed by the thread that begins to
17 execute the dependent task.
18 • When a task begins execution on a given thread and it is mutually exclusive with respect to
19 another sibling task that is executed by a different thread, the behavior is as if each release flush
20 performed on completion of the sibling task synchronizes with the acquire flush performed by
21 the thread that begins to execute the task.
22 • When a thread executes a cancel region, the cancel-var ICV is true, and cancellation is not
23 already activated for the specified region, the behavior is as if the release flush performed during
24 the cancel region synchronizes with the acquire flush performed by a different thread
25 immediately before a cancellation point in which that thread observes cancellation was activated
26 for the region.
27 • When a thread executes an omp_unset_lock region that causes the specified lock to be unset,
28 the behavior is as if a release flush is performed during the omp_unset_lock region that
29 synchronizes with an acquire flush that is performed during the next omp_set_lock or
30 omp_test_lock region to be executed by a different thread that causes the specified lock to be
31 set.
32 • When a thread executes an omp_unset_nest_lock region that causes the specified nested
33 lock to be unset, the behavior is as if a release flush is performed during the
34 omp_unset_nest_lock region that synchronizes with an acquire flush that is performed
35 during the next omp_set_nest_lock or omp_test_nest_lock region to be executed by
36 a different thread that causes the specified nested lock to be set.

1 2.19.9 ordered Construct
2 Summary
3 The ordered construct either specifies a structured block in a worksharing-loop, simd, or
4 worksharing-loop SIMD region that will be executed in the order of the loop iterations, or it is a
5 stand-alone directive that specifies cross-iteration dependences in a doacross loop nest. The
6 ordered construct sequentializes and orders the execution of ordered regions while allowing
7 code outside the region to run in parallel.
8 Syntax
C / C++
9 The syntax of the ordered construct is as follows:
10 #pragma omp ordered [clause[ [,] clause] ] new-line
11 structured-block

13 threads
14 simd
15 or
16 #pragma omp ordered clause [[[,] clause] ... ] new-line

18 depend(source)
19 depend(sink : vec)
C / C++
Fortran
20 The syntax of the ordered construct is as follows:
21 !$omp ordered [clause[ [,] clause] ]
23 !$omp end ordered
24 or
25 !$omp ordered [clause[ [,] clause] ]
27 [!$omp end ordered]

29 threads
30 simd

1 or
2 !$omp ordered clause [[[,] clause] ... ]

4 depend(source)
5 depend(sink : vec)
Fortran
6 If the depend clause is specified, the ordered construct is a stand-alone directive.
7 Binding
8 The binding thread set for an ordered region is the current team. An ordered region binds to
9 the innermost enclosing simd or worksharing-loop SIMD region if the simd clause is present, and
10 otherwise it binds to the innermost enclosing worksharing-loop region. ordered regions that bind
11 to different regions execute independently of each other.
12 Description
13 If no clause is specified, the ordered construct behaves as if the threads clause had been
14 specified. If the threads clause is specified, the threads in the team that is executing the
15 worksharing-loop region execute ordered regions sequentially in the order of the loop iterations.
16 If any depend clauses are specified then those clauses specify the order in which the threads in the
17 team execute ordered regions. If the simd clause is specified, the ordered regions
18 encountered by any thread will execute one at a time in the order of the loop iterations.
19 When the thread that is executing the first iteration of the loop encounters an ordered construct,
20 it can enter the ordered region without waiting. When a thread that is executing any subsequent
21 iteration encounters an ordered construct without a depend clause, it waits at the beginning of
22 the ordered region until execution of all ordered regions that belong to all previous iterations
23 has completed. When a thread that is executing any subsequent iteration encounters an ordered
24 construct with one or more depend(sink:vec) clauses, it waits until its dependences on all
25 valid iterations specified by the depend clauses are satisfied before it completes execution of the
26 ordered region. A specific dependence is satisfied when a thread that is executing the
27 corresponding iteration encounters an ordered construct with a depend(source) clause.

29 The ordered-acquiring event occurs in the task that encounters the ordered construct on entry to
30 the ordered region before it initiates synchronization for the region.
31 The ordered-acquired event occurs in the task that encounters the ordered construct after it
32 enters the region, but before it executes the structured block of the ordered region.
33 The ordered-released event occurs in the task that encounters the ordered construct after it
34 completes any synchronization on exit from the ordered region.

1 The doacross-sink event occurs in the task that encounters an ordered construct for each
2 depend(sink:vec) clause after the dependence is fulfilled.
3 The doacross-source event occurs in the task that encounters an ordered construct with a
4 depend(source:vec) clause before signaling the dependence to be fulfilled.
5 Tool Callbacks
7 occurrence of an ordered-acquiring event in that thread. This callback has the type signature
10 occurrence of an ordered-acquired event in that thread. This callback has the type signature
13 ompt_mutex_ordered as the kind argument if practical, although a less specific kind may be
14 used, for each occurrence of an ordered-released event in that thread. This callback has the type
15 signature ompt_callback_mutex_t and occurs in the task that encounters the atomic
16 construct.
17 A thread dispatches a registered ompt_callback_dependences callback with all vector
18 entries listed as ompt_dependence_type_sink in the deps argument for each occurrence of a
19 doacross-sink event in that thread. A thread dispatches a registered
20 ompt_callback_dependences callback with all vector entries listed as
21 ompt_dependence_type_source in the deps argument for each occurrence of a
22 doacross-source event in that thread. These callbacks have the type signature
23 ompt_callback_dependences_t.
24 Restrictions
25 Restrictions to the ordered construct are as follows:
26 • At most one threads clause can appear on an ordered construct.
27 • At most one simd clause can appear on an ordered construct.
28 • At most one depend(source) clause can appear on an ordered construct.
29 • The construct that corresponds to the binding region of an ordered region must not specify a
30 reduction clause with the inscan modifier.
31 • Either depend(sink:vec) clauses or depend(source) clauses may appear on an
32 ordered construct, but not both.
33 • The worksharing-loop or worksharing-loop SIMD region to which an ordered region
34 corresponding to an ordered construct without a depend clause binds must have an
35 ordered clause without the parameter specified on the corresponding worksharing-loop or
36 worksharing-loop SIMD directive.

1 • The worksharing-loop region to which an ordered region that corresponds to an ordered
2 construct with any depend clauses binds must have an ordered clause with the parameter
3 specified on the corresponding worksharing-loop directive.
4 • An ordered construct with the depend clause specified must be closely nested inside a
5 worksharing-loop (or parallel worksharing-loop) construct.
6 • An ordered region that corresponds to an ordered construct without the simd clause
7 specified must be closely nested inside a worksharing-loop region.
8 • An ordered region that corresponds to an ordered construct with the simd clause specified
9 must be closely nested inside a simd or worksharing-loop SIMD region.
10 • An ordered region that corresponds to an ordered construct with both the simd and
11 threads clauses must be closely nested inside a worksharing-loop SIMD region or must be
12 closely nested inside a worksharing-loop and simd region.
13 • During execution of an iteration of a worksharing-loop or a loop nest within a worksharing-loop,
14 simd, or worksharing-loop SIMD region, a thread must not execute more than one ordered
15 region that corresponds to an ordered construct without a depend clause.
C++
16 • A throw executed inside a ordered region must cause execution to resume within the same
17 ordered region, and the same thread that threw the exception must catch it.
C++
18 Cross References
19 • worksharing-loop construct, see Section 2.11.4.
21 • parallel Worksharing-loop construct, see Section 2.16.1.
22 • depend Clause, see Section 2.19.11
23 • ompt_mutex_ordered, see Section 4.4.4.16.
26 2.19.10 Depend Objects

27 This section describes constructs that support OpenMP depend objects that can be used to supply
28 user-computed dependences to depend clauses. OpenMP depend objects must be accessed only
29 through the depobj construct or through the depend clause; programs that otherwise access
30 OpenMP depend objects are non-conforming.
31 An OpenMP depend object can be in one of the following states: uninitialized or initialized.
32 Initially OpenMP depend objects are in the uninitialized state.

1 2.19.10.1 depobj Construct
2 Summary
3 The depobj construct initializes, updates or destroys an OpenMP depend object. The depobj
4 construct is a stand-alone directive.
5 Syntax
C / C++
6 The syntax of the depobj construct is as follows:
7 #pragma omp depobj(depobj) clause new-line
8 where depobj is an lvalue expression of type omp_depend_t.

10 depend(dependence-type : locator)
11 destroy
12 update(dependence-type)
C / C++
Fortran
13 The syntax of the depobj construct is as follows:
14 !$omp depobj(depobj) clause
15 where depobj is a scalar integer variable of the omp_depend_kind kind.

17 depend(dependence-type : locator)
18 destroy
19 update(dependence-type)
Fortran
20 Binding
21 The binding thread set for a depobj region is the encountering thread.
22 Description
23 A depobj construct with a depend clause present sets the state of depobj to initialized. The
24 depobj is initialized to represent the dependence that the depend clause specifies.
25 A depobj construct with a destroy clause present changes the state of the depobj to
26 uninitialized.
27 A depobj construct with an update clause present changes the dependence type of the
28 dependence represented by depobj to the one specified by the update clause.

1 Restrictions
2 Restrictions to the depobj construct are as follows:
3 • A depend clause on a depobj construct must not have source or sink as dependence-type.
4 • An update clause on a depobj construct must not have source, sink or depobj as
5 dependence-type.
6 • A depend clause on a depobj construct can only specify one locator.
7 • The depobj of a depobj construct with the depend clause present must be in the uninitialized
8 state.
9 • The depobj of a depobj construct with the destroy clause present must be in the initialized
10 state.
11 • The depobj of a depobj construct with the update clause present must be in the initialized
12 state.
13 Cross References
15 2.19.11 depend Clause

16 Summary
17 The depend clause enforces additional constraints on the scheduling of tasks or loop iterations.
18 These constraints establish dependences only between sibling tasks or between loop iterations.
19 Syntax
20 The syntax of the depend clause is as follows:
22 where dependence-type is one of the following:

23 in
24 out
25 inout
26 mutexinoutset
27 inoutset
28 depobj
29 where depend-modifier is one of the following:


1 or
2 depend(dependence-type)
3 where dependence-type is:

4 source
5 or
6 depend(dependence-type : vec)
7 where dependence-type is:

8 sink
9 and where vec is the iteration vector, which has the form:
10 x1 [± d1 ], x2 [± d2 ], . . . , xn [± dn ]
11 where n is the value specified by the ordered clause in the worksharing-loop directive, xi denotes
12 the loop iteration variable of the i-th nested loop associated with the worksharing-loop directive,
13 and di is a constant non-negative integer.
14 Description
15 Task dependences are derived from the dependence-type of a depend clause and its list items
16 when dependence-type is in, out, inout, mutexinoutset or inoutset. When the
17 dependence-type is depobj, the task dependences are derived from the dependences represented
18 by the depend objects specified in the depend clause as if the depend clauses of the depobj
19 constructs were specified in the current construct.
20 The storage location of a list item matches the storage location of another list item if they have the
21 same storage location, or if any of the list items is omp_all_memory.
22 For the in dependence-type, if the storage location of at least one of the list items matches the
23 storage location of a list item appearing in a depend clause with an out, inout,
24 mutexinoutset, or inoutset dependence-type on a construct from which a sibling task was
25 previously generated, then the generated task will be a dependent task of that sibling task.
26 For the out and inout dependence-types, if the storage location of at least one of the list items
27 matches the storage location of a list item appearing in a depend clause with an in, out, inout,
28 mutexinoutset, or inoutset dependence-type on a construct from which a sibling task was
29 previously generated, then the generated task will be a dependent task of that sibling task.
30 For the mutexinoutset dependence-type, if the storage location of at least one of the list items
31 matches the storage location of a list item appearing in a depend clause with an in, out, inout,
32 or inoutset dependence-type on a construct from which a sibling task was previously generated,
33 then the generated task will be a dependent task of that sibling task.
34 If a list item appearing in a depend clause with a mutexinoutset dependence-type on a task
35 generating construct matches a list item appearing in a depend clause with a mutexinoutset

1 dependence-type on a different task generating construct, and both constructs generate sibling tasks,
2 the sibling tasks will be mutually exclusive tasks.
3 For the inoutset dependence-type, if the storage location of at least one of the list items matches
4 the storage location of a list item appearing in a depend clause with an in, out, inout, or
5 mutexinoutset dependence-type on a construct from which a sibling task was previously
6 generated, then the generated task will be a dependent task of that sibling task.
7 The list items that appear in the depend clause may reference iterators defined by an
8 iterators-definition appearing on an iterator modifier.
9 The list items that appear in the depend clause may include array sections or the
10 omp_all_memory reserved locator.
Fortran
11 If a list item has the ALLOCATABLE attribute and its allocation status is unallocated, the behavior
12 is unspecified. If a list item has the POINTER attribute and its association status is disassociated or
13 undefined, the behavior is unspecified.
Fortran
C / C++
14 The list items that appear in a depend clause may use shape-operators.
C / C++
15
16 Note – The enforced task dependence establishes a synchronization of memory accesses

17 performed by a dependent task with respect to accesses performed by the predecessor tasks.
18 However, it is the responsibility of the programmer to synchronize properly with respect to other
19 concurrent accesses that occur outside of those tasks.
20
21 The source dependence-type specifies the satisfaction of cross-iteration dependences that arise
22 from the current iteration.
23 The sink dependence-type specifies a cross-iteration dependence, where the iteration vector vec
24 indicates the iteration that satisfies the dependence.
25 If the iteration vector vec does not occur in the iteration space, the depend clause is ignored. If all
26 depend clauses on an ordered construct are ignored then the construct is ignored.
27
28 Note – An iteration vector vec that does not indicate a lexicographically earlier iteration may cause
29 a deadlock.
30

2 The task-dependences event occurs in a thread that encounters a task generating construct or a
3 taskwait construct with a depend clause immediately after the task-create event for the new
4 task or the taskwait-init event.
5 The task-dependence event indicates an unfulfilled dependence for the generated task. This event
6 occurs in a thread that observes the unfulfilled dependence before it is satisfied.
7 Tool Callbacks
8 A thread dispatches the ompt_callback_dependences callback for each occurrence of the
9 task-dependences event to announce its dependences with respect to the list items in the depend
10 clause. This callback has type signature ompt_callback_dependences_t.
11 A thread dispatches the ompt_callback_task_dependence callback for a task-dependence
12 event to report a dependence between a predecessor task (src_task_data) and a dependent task
13 (sink_task_data). This callback has type signature ompt_callback_task_dependence_t.
14 Restrictions
15 Restrictions to the depend clause are as follows:
16 • List items, other than reserved locators, used in depend clauses of the same task or sibling tasks
17 must indicate identical storage locations or disjoint storage locations.
18 • List items used in depend clauses cannot be zero-length array sections.
19 • The omp_all_memory reserved locator can only be used in a depend clause with an out or
20 inout dependence-type.
21 • Array sections cannot be specified in depend clauses with the depobj dependence type.
22 • List items used in depend clauses with the depobj dependence type must be depend objects
23 in the initialized state.
C / C++
24 • List items used in depend clauses with the depobj dependence type must be expressions of
25 the omp_depend_t type.
26 • List items that are expressions of the omp_depend_t type can only be used in depend
27 clauses with the depobj dependence type.
C / C++
Fortran
28 • A common block name cannot appear in a depend clause.
29 • List items used in depend clauses with the depobj dependence type must be integer
30 expressions of the omp_depend_kind kind.
Fortran

1 • For a vec element of sink dependence-type of the form xi + di or xi − di if the loop iteration
2 variable xi has an integral or pointer type, the expression xi + di or xi − di for any value of the
3 loop iteration variable xi that can encounter the ordered construct must be computable without
4 overflow in the type of the loop iteration variable.
C++
5 • For a vec element of sink dependence-type of the form xi + di or xi − di if the loop iteration
6 variable xi is of a random access iterator type other than pointer type, the expression
7 ( xi − lbi ) + di or ( xi − lbi ) − di for any value of the loop iteration variable xi that can
8 encounter the ordered construct must be computable without overflow in the type that would
9 be used by std::distance applied to variables of the type of xi .
C++
C / C++
10 • A bit-field cannot appear in a depend clause.
C / C++
11 Cross References
12 • Array shaping, see Section 2.1.4.
16 • Task scheduling constraints, see Section 2.12.6.
17 • target enter data construct, see Section 2.14.3.
18 • target exit data construct, see Section 2.14.4.
20 • target update construct, see Section 2.14.6.
22 • depobj construct, see Section 2.19.10.1.
23 • ompt_callback_dependences_t, see Section 4.5.2.8.
24 • ompt_callback_task_dependence_t, see Section 4.5.2.9.

1 2.19.12 Synchronization Hints
2 Hints about the expected dynamic behavior or suggested implementation can be provided by the
3 programmer to locks (by using the omp_init_lock_with_hint or
4 omp_init_nest_lock_with_hint functions to initialize the lock), and to atomic and
5 critical directives by using the hint clause. The effect of a hint does not change the semantics
6 of the associated construct; if ignoring the hint changes the program semantics, the result is
7 unspecified.
8 The C/C++ header file (omp.h) and the Fortran include file (omp_lib.h) and/or Fortran module
9 file (omp_lib) define the valid hint constants. The valid constants must include the following,
10 which can be extended with implementation-defined values:
C / C++
11 typedef enum omp_sync_hint_t {
12 omp_sync_hint_none = 0x0,
13 omp_lock_hint_none = omp_sync_hint_none,
14 omp_sync_hint_uncontended = 0x1,
15 omp_lock_hint_uncontended = omp_sync_hint_uncontended,
16 omp_sync_hint_contended = 0x2,
17 omp_lock_hint_contended = omp_sync_hint_contended,
18 omp_sync_hint_nonspeculative = 0x4,
19 omp_lock_hint_nonspeculative = omp_sync_hint_nonspeculative,
20 omp_sync_hint_speculative = 0x8,
21 omp_lock_hint_speculative = omp_sync_hint_speculative
22 } omp_sync_hint_t;
23
24 typedef omp_sync_hint_t omp_lock_hint_t;
C / C++
Fortran
25 integer, parameter :: omp_lock_hint_kind = omp_sync_hint_kind
26
27 integer (kind=omp_sync_hint_kind), &
28 parameter :: omp_sync_hint_none = &
29 int(Z’0’, kind=omp_sync_hint_kind)
30 integer (kind=omp_lock_hint_kind), &
31 parameter :: omp_lock_hint_none = omp_sync_hint_none
33 parameter :: omp_sync_hint_uncontended = &
36 parameter :: omp_lock_hint_uncontended = &
37 omp_sync_hint_uncontended

1 parameter :: omp_sync_hint_contended = &
4 parameter :: omp_lock_hint_contended = &
5 omp_sync_hint_contended
7 parameter :: omp_sync_hint_nonspeculative = &
10 parameter :: omp_lock_hint_nonspeculative = &
11 omp_sync_hint_nonspeculative
13 parameter :: omp_sync_hint_speculative = &
16 parameter :: omp_lock_hint_speculative = &
17 omp_sync_hint_speculative
Fortran
18 The hints can be combined by using the + or | operators in C/C++ or the + operator in Fortran.
19 Combining omp_sync_hint_none with any other hint is equivalent to specifying the other hint.
20 The intended meaning of each hint is:
21 • omp_sync_hint_uncontended: low contention is expected in this operation, that is, few
22 threads are expected to perform the operation simultaneously in a manner that requires
23 synchronization;
24 • omp_sync_hint_contended: high contention is expected in this operation, that is, many
25 threads are expected to perform the operation simultaneously in a manner that requires
26 synchronization;
27 • omp_sync_hint_speculative: the programmer suggests that the operation should be
28 implemented using speculative techniques such as transactional memory; and
29 • omp_sync_hint_nonspeculative: the programmer suggests that the operation should
30 not be implemented using speculative techniques such as transactional memory.
31
32 Note – Future OpenMP specifications may add additional hints to the omp_sync_hint_t type
33 and the omp_sync_hint_kind kind. Implementers are advised to add implementation-defined
34 hints starting from the most significant bit of the omp_sync_hint_t type and
35 omp_sync_hint_kind kind and to include the name of the implementation in the name of the
36 added hint to avoid name conflicts with other OpenMP implementations.
37

1 The omp_sync_hint_t and omp_lock_hint_t enumeration types and the equivalent types
2 in Fortran are synonyms for each other. The type omp_lock_hint_t has been deprecated.
3 Restrictions
4 Restrictions to the synchronization hints are as follows:
5 • The hints omp_sync_hint_uncontended and omp_sync_hint_contended cannot
6 be combined.
7 • The hints omp_sync_hint_nonspeculative and omp_sync_hint_speculative
8 cannot be combined.
9 The restrictions for combining multiple values of omp_sync_hint apply equally to the
10 corresponding values of omp_lock_hint, and expressions that mix the two types.
11 Cross References
13 • atomic construct, see Section 2.19.7
14 • omp_init_lock_with_hint and omp_init_nest_lock_with_hint, see
15 Section 3.9.2.
16 2.20 Cancellation Constructs

17 2.20.1 cancel Construct
18 Summary
19 The cancel construct activates cancellation of the innermost enclosing region of the type
20 specified. The cancel construct is a stand-alone directive.
21 Syntax
C / C++
22 The syntax of the cancel construct is as follows:
23 #pragma omp cancel construct-type-clause [ [,] if-clause] new-line
24 where construct-type-clause is one of the following:

25 parallel
26 sections
27 for
28 taskgroup

1 and if-clause is
2 if([ cancel :] scalar-expression)
C / C++
Fortran
3 The syntax of the cancel construct is as follows:
4 !$omp cancel construct-type-clause [ [,] if-clause]

6 parallel
7 sections
8 do
9 taskgroup
10 and if-clause is
11 if([ cancel :] scalar-logical-expression)
Fortran
12 Binding
13 The binding thread set of the cancel region is the current team. The binding region of the
14 cancel region is the innermost enclosing region of the type corresponding to the
15 construct-type-clause specified in the directive (that is, the innermost parallel, sections,
16 worksharing-loop, or taskgroup region).
17 Description
18 The cancel construct activates cancellation of the binding region only if the cancel-var ICV is
19 true, in which case the cancel construct causes the encountering task to continue execution at the
20 end of the binding region if construct-type-clause is parallel, for, do, or sections. If the
21 cancel-var ICV is true and construct-type-clause is taskgroup, the encountering task continues
22 execution at the end of the current task region. If the cancel-var ICV is false, the cancel
23 construct is ignored.
24 Threads check for active cancellation only at cancellation points that are implied at the following
25 locations:
26 • cancel regions;
27 • cancellation point regions;
28 • barrier regions;
29 • at the end of a worksharing-loop construct with a nowait clause and for which the same list
30 item appears in both firstprivate and lastprivate clauses; and
31 • implicit barrier regions.

1 When a thread reaches one of the above cancellation points and if the cancel-var ICV is true, then:
2 • If the thread is at a cancel or cancellation point region and construct-type-clause is
3 parallel, for, do, or sections, the thread continues execution at the end of the canceled
4 region if cancellation has been activated for the innermost enclosing region of the type specified.
5 • If the thread is at a cancel or cancellation point region and construct-type-clause is
6 taskgroup, the encountering task checks for active cancellation of all of the taskgroup sets to
7 which the encountering task belongs, and continues execution at the end of the current task
8 region if cancellation has been activated for any of the taskgroup sets.
9 • If the encountering task is at a barrier region or at the end of a worksharing-loop construct with a
10 nowait clause and for which the same list item appears in both firstprivate and
11 lastprivate clauses, the encountering task checks for active cancellation of the innermost
12 enclosing parallel region. If cancellation has been activated, then the encountering task
13 continues execution at the end of the canceled region.
14
15 Note – If one thread activates cancellation and another thread encounters a cancellation point, the
16 order of execution between the two threads is non-deterministic. Whether the thread that
17 encounters a cancellation point detects the activated cancellation depends on the underlying
18 hardware and operating system.
19
20 When cancellation of tasks is activated through a cancel construct with the taskgroup
21 construct-type-clause, the tasks that belong to the taskgroup set of the innermost enclosing
22 taskgroup region will be canceled. The task that encountered that construct continues execution
23 at the end of its task region, which implies completion of that task. Any task that belongs to the
24 innermost enclosing taskgroup and has already begun execution must run to completion or until
25 a cancellation point is reached. Upon reaching a cancellation point and if cancellation is active, the
26 task continues execution at the end of its task region, which implies the task’s completion. Any task
27 that belongs to the innermost enclosing taskgroup and that has not begun execution may be
28 discarded, which implies its completion.
29 When cancellation is active for a parallel, sections, or worksharing-loop region, each
30 thread of the binding thread set resumes execution at the end of the canceled region if a cancellation
31 point is encountered. If the canceled region is a parallel region, any tasks that have been
32 created by a task or a taskloop construct and their descendant tasks are canceled according to
33 the above taskgroup cancellation semantics. If the canceled region is a sections, or
34 worksharing-loop region, no task cancellation occurs.
C++
35 The usual C++ rules for object destruction are followed when cancellation is performed.
C++

Fortran
1 All private objects or subobjects with ALLOCATABLE attribute that are allocated inside the
2 canceled construct are deallocated.
Fortran
3 If the canceled construct contains a reduction, task_reduction or lastprivate clause,
4 the final values of the list items that appeared in those clauses are undefined.
5 When an if clause is present on a cancel construct and the if expression evaluates to false, the
6 cancel construct does not activate cancellation. The cancellation point associated with the
7 cancel construct is always encountered regardless of the value of the if expression.
8
9 Note – The programmer is responsible for releasing locks and other synchronization data
10 structures that might cause a deadlock when a cancel construct is encountered and blocked
11 threads cannot be canceled. The programmer is also responsible for ensuring proper
12 synchronizations to avoid deadlocks that might arise from cancellation of OpenMP regions that
13 contain OpenMP synchronization constructs.
14

16 If a task encounters a cancel construct that will activate cancellation then a cancel event occurs.
17 A discarded-task event occurs for any discarded tasks.
18 Tool Callbacks
19 A thread dispatches a registered ompt_callback_cancel callback for each occurrence of a
20 cancel event in the context of the encountering task. This callback has type signature
21 ompt_callback_cancel_t; (flags & ompt_cancel_activated) always evaluates to
22 true in the dispatched callback; (flags & ompt_cancel_parallel) evaluates to true in the
23 dispatched callback if construct-type-clause is parallel;
24 (flags & ompt_cancel_sections) evaluates to true in the dispatched callback if
25 construct-type-clause is sections; (flags & ompt_cancel_loop) evaluates to true in the
26 dispatched callback if construct-type-clause is for or do; and
27 (flags & ompt_cancel_taskgroup) evaluates to true in the dispatched callback if
28 construct-type-clause is taskgroup.
29 A thread dispatches a registered ompt_callback_cancel callback with the ompt_data_t
30 associated with the discarded task as its task_data argument and
31 ompt_cancel_discarded_task as its flags argument for each occurrence of a
32 discarded-task event. The callback occurs in the context of the task that discards the task and has
33 type signature ompt_callback_cancel_t.

1 Restrictions
2 Restrictions to the cancel construct are as follows:
3 • The behavior for concurrent cancellation of a region and a region nested within it is unspecified.
4 • If construct-type-clause is taskgroup, the cancel construct must be closely nested inside a
5 task or a taskloop construct and the cancel region must be closely nested inside a
6 taskgroup region.
7 • If construct-type-clause is sections, the cancel construct must be closely nested inside a
8 sections or section construct.
9 • If construct-type-clause is neither sections nor taskgroup, the cancel construct must be
10 closely nested inside an OpenMP construct that matches the type specified in
11 construct-type-clause of the cancel construct.
12 • A worksharing construct that is canceled must not have a nowait clause or a reduction
13 clause with a user-defined reduction that uses omp_orig in the initializer-expr of the
14 corresponding declare reduction directive.
15 • A worksharing-loop construct that is canceled must not have an ordered clause or a
16 reduction clause with the inscan modifier.
17 • When cancellation is active for a parallel region, a thread in the team that binds to that
18 region may not be executing or encounter a worksharing construct with an ordered clause, a
19 reduction clause with the inscan modifier or a reduction clause with a user-defined
20 reduction that uses omp_orig in the initializer-expr of the corresponding
21 declare reduction directive.
22 • When cancellation is active for a parallel region, a thread in the team that binds to that
23 region may not be executing or encounter a scope construct with a reduction clause with a
24 user-defined reduction that uses omp_orig in the initializer-expr of the corresponding
26 • During execution of a construct that may be subject to cancellation, a thread must not encounter
27 an orphaned cancellation point. That is, a cancellation point must only be encountered within
28 that construct and must not be encountered elsewhere in its region.
29 Cross References
30 • cancel-var ICV, see Section 2.4.1.
32 • cancellation point construct, see Section 2.20.2.
34 • omp_cancel_flag_t enumeration type, see Section 4.4.4.25.

1 2.20.2 cancellation point Construct
2 Summary
3 The cancellation point construct introduces a user-defined cancellation point at which
4 implicit or explicit tasks check if cancellation of the innermost enclosing region of the type
5 specified has been activated. The cancellation point construct is a stand-alone directive.
6 Syntax
C / C++
7 The syntax of the cancellation point construct is as follows:
8 #pragma omp cancellation point construct-type-clause new-line

10 parallel
11 sections
12 for
13 taskgroup
C / C++
Fortran
14 The syntax of the cancellation point construct is as follows:
15 !$omp cancellation point construct-type-clause

17 parallel
18 sections
19 do
20 taskgroup
Fortran
21 Binding
22 The binding thread set of the cancellation point construct is the current team. The binding
23 region of the cancellation point region is the innermost enclosing region of the type
24 corresponding to the construct-type-clause specified in the directive (that is, the innermost
25 parallel, sections, worksharing-loop, or taskgroup region).

1 Description
2 This directive introduces a user-defined cancellation point at which an implicit or explicit task must
3 check if cancellation of the innermost enclosing region of the type specified in the clause has been
4 requested. This construct does not implement any synchronization between threads or tasks.
5 When an implicit or explicit task reaches a user-defined cancellation point and if the cancel-var
6 ICV is true, then:
7 • If the construct-type-clause of the encountered cancellation point construct is
8 parallel, for, do, or sections, the thread continues execution at the end of the canceled
9 region if cancellation has been activated for the innermost enclosing region of the type specified.
10 • If the construct-type-clause of the encountered cancellation point construct is
11 taskgroup, the encountering task checks for active cancellation of all taskgroup sets to which
12 the encountering task belongs and continues execution at the end of the current task region if
13 cancellation has been activated for any of them.

15 The cancellation event occurs if a task encounters a cancellation point and detected the activation
16 of cancellation.
17 Tool Callbacks
18 A thread dispatches a registered ompt_callback_cancel callback for each occurrence of a
19 cancel event in the context of the encountering task. This callback has type signature
20 ompt_callback_cancel_t; (flags & ompt_cancel_detected) always evaluates to true
21 in the dispatched callback; (flags & ompt_cancel_parallel) evaluates to true in the
22 dispatched callback if construct-type-clause of the encountered cancellation point
23 construct is parallel; (flags & ompt_cancel_sections) evaluates to true in the
24 dispatched callback if construct-type-clause of the encountered cancellation point
25 construct is sections; (flags & ompt_cancel_loop) evaluates to true in the dispatched
26 callback if construct-type-clause of the encountered cancellation point construct is for or
27 do; and (flags & ompt_cancel_taskgroup) evaluates to true in the dispatched callback if
28 construct-type-clause of the encountered cancellation point construct is taskgroup.
29 Restrictions
30 Restrictions to the cancellation point construct are as follows:
31 • A cancellation point construct for which construct-type-clause is taskgroup must be
32 closely nested inside a task or taskloop construct, and the cancellation point region
33 must be closely nested inside a taskgroup region.
34 • A cancellation point construct for which construct-type-clause is sections must be
35 closely nested inside a sections or section construct.
36 • A cancellation point construct for which construct-type-clause is neither sections nor
37 taskgroup must be closely nested inside an OpenMP construct that matches the type specified
38 in construct-type-clause.

1 Cross References
3 • cancel construct, see Section 2.20.1.
6 2.21 Data Environment

7 This section presents directives and clauses for controlling data environments.
8 2.21.1 Data-Sharing Attribute Rules

9 This section describes how the data-sharing attributes of variables referenced in data environments
10 are determined. The following two cases are described separately:
11 • Section 2.21.1.1 describes the data-sharing attribute rules for variables referenced in a construct.
12 • Section 2.21.1.2 describes the data-sharing attribute rules for variables referenced in a region,
13 but outside any construct.
14 2.21.1.1 Variables Referenced in a Construct

15 The data-sharing attributes of variables that are referenced in a construct can be predetermined,
16 explicitly determined, or implicitly determined, according to the rules outlined in this section.
17 Specifying a variable in a data-sharing attribute clause, except for the private clause, or
18 copyprivate clause of an enclosed construct, causes an implicit reference to the variable in the
19 enclosing construct. Specifying a variable in a map clause of an enclosed construct may cause an
20 implicit reference to the variable in the enclosing construct. Such implicit references are also
21 subject to the data-sharing attribute rules outlined in this section.
22 Certain variables and objects have predetermined data-sharing attributes with respect to the
23 construct in which they are referenced. The first matching rule from the following list of
24 predetermined data-sharing attribute rules applies for variables and objects that are referenced in a
25 construct.
C / C++
26 • Variables that appear in threadprivate directives or variables with the _Thread_local
27 (in C) or thread_local (in C++) storage-class specifier are threadprivate.

C
1 • Variables with automatic storage duration that are declared in a scope inside the construct are
2 private.
C
C++
3 • Variables of non-reference type with automatic storage duration that are declared in a scope
4 inside the construct are private.
C++
5 • Objects with dynamic storage duration are shared.
6 • The loop iteration variable in any associated loop of a for, parallel for, taskloop, or
7 distribute construct is private.
8 • The loop iteration variable in the associated loop of a simd construct with just one associated
9 loop is linear with a linear-step that is the increment of the associated loop.
10 • The loop iteration variables in the associated loops of a simd construct with multiple associated
11 loops are lastprivate.
12 • The loop iteration variable in any associated loop of a loop construct is lastprivate.
13 • The implicitly declared variables of a range-based for loop are private.
14 • Variables with static storage duration that are declared in a scope inside the construct are shared.
15 • If a list item in a map clause on the target construct has a base pointer, and the base pointer is
16 a scalar variable that does not appear in a map clause on the construct, the base pointer is
17 firstprivate.
18 • If a list item in a reduction or in_reduction clause on a construct has a base pointer then
19 the base pointer is private.
20 • Static data members are shared.
21 • The __func__ variable and similar function-local predefined variables are shared.
C / C++
Fortran
22 • Variables declared within a BLOCK construct inside a construct that do not have the SAVE
23 attribute are private.
24 • Variables and common blocks that appear in threadprivate directives are threadprivate.
25 • The loop iteration variable in any associated do-loop of a do, parallel do, taskloop, or
26 distribute construct is private.
27 • The loop iteration variable in the associated do-loop of a simd construct with just one
28 associated do-loop is linear with a linear-step that is the increment of the associated do-loop.

1 • The loop iteration variables in the associated do-loops of a simd construct with multiple
2 associated do-loops are lastprivate.
3 • The loop iteration variable in any associated do-loop of a loop construct is lastprivate.
4 • Loop iteration variables inside parallel or task generating constructs are private in the
5 innermost such construct that encloses the loop.
6 • Implied-do, FORALL and DO CONCURRENT indices are private.
7 • Cray pointees have the same data-sharing attribute as the storage with which their Cray pointers
8 are associated. Cray pointer support has been deprecated.
9 • Assumed-size arrays are shared.
10 • Named constants are shared.
11 • An associate name that may appear in a variable definition context is shared if its association
12 occurs outside of the construct and otherwise it has the same data-sharing attribute as the
13 selector with which it is associated.
Fortran
14 Variables with predetermined data-sharing attributes may not be listed in data-sharing attribute
15 clauses, except for the cases listed below. For these exceptions only, listing a predetermined
16 variable in a data-sharing attribute clause is allowed and overrides the variable’s predetermined
17 data-sharing attributes.
C / C++
18 • The loop iteration variable in any associated loop of a for, taskloop, distribute, or
19 loop construct may be listed in a private or lastprivate clause.
20 • If a simd construct has just one associated loop then its loop iteration variable may be listed in a
21 private, lastprivate, or linear clause with a linear-step that is the increment of the
22 associated loop.
23 • If a simd construct has more than one associated loop then their loop iteration variables may be
24 listed in a private or lastprivate clause.
25 • Variables with const-qualified type with no mutable members may be listed in a
26 firstprivate clause, even if they are static data members.
27 • The __func__ variable and similar function-local predefined variables may be listed in a
28 shared or firstprivate clause.
C / C++

Fortran
1 • The loop iteration variable in any associated do-loop of a do, taskloop, distribute, or
2 loop construct may be listed in a private or lastprivate clause.
3 • The loop iteration variable in the associated do-loop of a simd construct with just one
4 associated do-loop may be listed in a private, lastprivate, or linear clause with a
5 linear-step that is the increment of the associated loop.
6 • The loop iteration variables in the associated do-loops of a simd construct with multiple
7 associated do-loops may be listed in a private or lastprivate clause.
8 • Loop iteration variables of loops that are not associated with any OpenMP directive may be
9 listed in data-sharing attribute clauses on the surrounding teams, parallel or task generating
10 construct, and on enclosed constructs, subject to other restrictions.
11 • Assumed-size arrays may be listed in a shared clause.
12 • Named constants may be listed in a firstprivate clause.
Fortran
13 Additional restrictions on the variables that may appear in individual clauses are described with
14 each clause in Section 2.21.4.
15 Variables with explicitly determined data-sharing attributes are those that are referenced in a given
16 construct and are listed in a data-sharing attribute clause on the construct.
17 Variables with implicitly determined data-sharing attributes are those that are referenced in a given
18 construct, do not have predetermined data-sharing attributes, and are not listed in a data-sharing
19 attribute clause on the construct.
20 Rules for variables with implicitly determined data-sharing attributes are as follows:
21 • In a parallel, teams, or task generating construct, the data-sharing attributes of these
22 variables are determined by the default clause, if present (see Section 2.21.4.1).
23 • In a parallel construct, if no default clause is present, these variables are shared.
24 • For constructs other than task generating constructs, if no default clause is present, these
25 variables reference the variables with the same names that exist in the enclosing context.
26 • In a target construct, variables that are not mapped after applying data-mapping attribute
27 rules (see Section 2.21.7) are firstprivate.
C++
28 • In an orphaned task generating construct, if no default clause is present, formal arguments
29 passed by reference are firstprivate.
C++

Fortran
1 • In an orphaned task generating construct, if no default clause is present, dummy arguments
2 are firstprivate.
Fortran
3 • In a task generating construct, if no default clause is present, a variable for which the
4 data-sharing attribute is not determined by the rules above and that in the enclosing context is
5 determined to be shared by all implicit tasks bound to the current team is shared.
6 • In a task generating construct, if no default clause is present, a variable for which the
7 data-sharing attribute is not determined by the rules above is firstprivate.
8 Additional restrictions on the variables for which data-sharing attributes cannot be implicitly
9 determined in a task generating construct are described in Section 2.21.4.4.
10 2.21.1.2 Variables Referenced in a Region but not in a Construct

11 The data-sharing attributes of variables that are referenced in a region, but not in a construct, are
12 determined as follows:
C / C++
13 • Variables with static storage duration that are declared in called routines in the region are shared.
14 • File-scope or namespace-scope variables referenced in called routines in the region are shared
15 unless they appear in a threadprivate directive.
16 • Objects with dynamic storage duration are shared.
17 • Static data members are shared unless they appear in a threadprivate directive.
18 • In C++, formal arguments of called routines in the region that are passed by reference have the
19 same data-sharing attributes as the associated actual arguments.
20 • Other variables declared in called routines in the region are private.
C / C++
Fortran
21 • Local variables declared in called routines in the region and that have the save attribute, or that
22 are data initialized, are shared unless they appear in a threadprivate directive.
23 • Variables belonging to common blocks, or accessed by host or use association, and referenced in
24 called routines in the region are shared unless they appear in a threadprivate directive.
25 • Dummy arguments of called routines in the region that have the VALUE attribute are private.
26 • Dummy arguments of called routines in the region that do not have the VALUE attribute are
27 private if the associated actual argument is not shared.

1 • Dummy arguments of called routines in the region that do not have the VALUE attribute are
2 shared if the actual argument is shared and it is a scalar variable, structure, an array that is not a
3 pointer or assumed-shape array, or a simply contiguous array section. Otherwise, the
4 data-sharing attribute of the dummy argument is implementation-defined if the associated actual
5 argument is shared.
6 • Cray pointees have the same data-sharing attribute as the storage with which their Cray pointers
7 are associated. Cray pointer support has been deprecated.
8 • Implied-do indices, DO CONCURRENT indices, FORALL indices, and other local variables
9 declared in called routines in the region are private.
Fortran
10 2.21.2 threadprivate Directive

11 Summary
12 The threadprivate directive specifies that variables are replicated, with each thread having its
13 own copy. The threadprivate directive is a declarative directive.
14 Syntax
C / C++
15 The syntax of the threadprivate directive is as follows:
16 #pragma omp threadprivate(list) new-line
17 where list is a comma-separated list of file-scope, namespace-scope, or static block-scope variables

18 that do not have incomplete types.
C / C++
Fortran
19 The syntax of the threadprivate directive is as follows:
20 !$omp threadprivate(list)
21 where list is a comma-separated list of named variables and named common blocks. Common
22 block names must appear between slashes.
Fortran
23 Description
24 Unless otherwise specified, each copy of a threadprivate variable is initialized once, in the manner
25 specified by the program, but at an unspecified point in the program prior to the first reference to
26 that copy. The storage of all copies of a threadprivate variable is freed according to how static
27 variables are handled in the base language, but at an unspecified point in the program.

C++
1 Each copy of a block-scope threadprivate variable that has a dynamic initializer is initialized the
2 first time its thread encounters its definition; if its thread does not encounter its definition, its
3 initialization is unspecified.
C++
4 The content of a threadprivate variable can change across a task scheduling point if the executing
5 thread switches to another task that modifies the variable. For more details on task scheduling, see
6 Section 1.3 and Section 2.12.
7 In parallel regions, references by the primary thread will be to the copy of the variable in the
8 thread that encountered the parallel region.
9 During a sequential part references will be to the initial thread’s copy of the variable. The values of
10 data in the initial thread’s copy of a threadprivate variable are guaranteed to persist between any
11 two consecutive references to the variable in the program provided that no teams construct that is
12 not nested inside of a target construct is encountered between the references and that the initial
13 thread is not nested inside of a teams region. For initial threads nested inside of a teams region,
14 the values of data in the copies of a threadprivate variable of those initial threads are guaranteed to
15 persist between any two consecutive references to the variable inside of that teams region.
16 The values of data in the threadprivate variables of threads that are not initial threads are
17 guaranteed to persist between two consecutive active parallel regions only if all of the
18 following conditions hold:
19 • Neither parallel region is nested inside another explicit parallel region;
20 • The number of threads used to execute both parallel regions is the same;
21 • The thread affinity policies used to execute both parallel regions are the same;
22 • The value of the dyn-var internal control variable in the enclosing task region is false at entry to
23 both parallel regions;
24 • No teams construct that is not nested inside of a target construct is encountered between the
25 parallel regions;
26 • No construct with an order clause that specifies concurrent is encountered between the
27 parallel regions; and
28 • Neither the omp_pause_resource nor omp_pause_resource_all routine is called.
29 If these conditions all hold, and if a threadprivate variable is referenced in both regions, then
30 threads with the same thread number in their respective regions will reference the same copy of that
31 variable.

C / C++
1 If the above conditions hold, the storage duration, lifetime, and value of a thread’s copy of a
2 threadprivate variable that does not appear in any copyin clause on the second region will span
3 the two consecutive active parallel regions. Otherwise, the storage duration, lifetime, and value
4 of a thread’s copy of the variable in the second region is unspecified.
C / C++
Fortran
5 If the above conditions hold, the definition, association, or allocation status of a thread’s copy of a
6 threadprivate variable or a variable in a threadprivate common block that is not affected by any
7 copyin clause that appears on the second region (a variable is affected by a copyin clause if the
8 variable appears in the copyin clause or it is in a common block that appears in the copyin
9 clause) will span the two consecutive active parallel regions. Otherwise, the definition and
10 association status of a thread’s copy of the variable in the second region are undefined, and the
11 allocation status of an allocatable variable will be implementation defined.
12 If a threadprivate variable or a variable in a threadprivate common block is not affected by any
13 copyin clause that appears on the first parallel region in which it is referenced, the thread’s
14 copy of the variable inherits the declared type parameter and the default parameter values from the
15 original variable. The variable or any subobject of the variable is initially defined or undefined
16 according to the following rules:
17 • If it has the ALLOCATABLE attribute, each copy created will have an initial allocation status of
18 unallocated;
19 • If it has the POINTER attribute, each copy will have the same association status as the initial
20 association status.
21 • If it does not have either the POINTER or the ALLOCATABLE attribute:
22 – If it is initially defined, either through explicit initialization or default initialization, each copy
23 created is so defined;
24 – Otherwise, each copy created is undefined.
Fortran
C / C++
25 The address of a threadprivate variable may not be an address constant.
C / C++
C++
26 The order in which any constructors for different threadprivate variables of class type are called is
27 unspecified. The order in which any destructors for different threadprivate variables of class type
28 are called is unspecified.
C++

1 Restrictions
2 Restrictions to the threadprivate directive are as follows:
3 • A thread must not reference another thread’s copy of a threadprivate variable.
4 • A threadprivate variable must not appear in any clause except the copyin, copyprivate,
5 schedule, num_threads, thread_limit, and if clauses.
6 • A program in which an untied task accesses threadprivate storage is non-conforming.
C / C++
7 • If the value of a variable referenced in an explicit initializer of a threadprivate variable is
8 modified prior to the first reference to any instance of the threadprivate variable, then the
9 behavior is unspecified.
11 threadprivate directive unless it is a static data member of a C++ class.
12 • A threadprivate directive for file-scope variables must appear outside any definition or
13 declaration, and must lexically precede all references to any of the variables in its list.
14 • A threadprivate directive for namespace-scope variables must appear outside any
15 definition or declaration other than the namespace definition itself, and must lexically precede all
16 references to any of the variables in its list.
17 • Each variable in the list of a threadprivate directive at file, namespace, or class scope must
18 refer to a variable declaration at file, namespace, or class scope that lexically precedes the
19 directive.
20 • A threadprivate directive for static block-scope variables must appear in the scope of the
21 variable and not in a nested scope. The directive must lexically precede all references to any of
22 the variables in its list.
23 • Each variable in the list of a threadprivate directive in block scope must refer to a variable
24 declaration in the same scope that lexically precedes the directive. The variable must have static
25 storage duration.
26 • If a variable is specified in a threadprivate directive in one translation unit, it must be
27 specified in a threadprivate directive in every translation unit in which it is declared.
C / C++
C++
28 • A threadprivate directive for static class member variables must appear in the class
29 definition, in the same scope in which the member variables are declared, and must lexically
30 precede all references to any of the variables in its list.
31 • A threadprivate variable must not have an incomplete type or a reference type.
32 • A threadprivate variable with class type must have:

1 – An accessible, unambiguous default constructor in the case of default initialization without a
2 given initializer;
3 – An accessible, unambiguous constructor that accepts the given argument in the case of direct
4 initialization; and
5 – An accessible, unambiguous copy constructor in the case of copy initialization with an explicit
6 initializer.
C++
Fortran
8 inquiry) cannot appear in a threadprivate directive.
9 • A coarray cannot appear in a threadprivate directive.
10 • An associate name cannot appear in a threadprivate directive.
11 • The threadprivate directive must appear in the declaration section of a scoping unit in
12 which the common block or variable is declared.
13 • If a threadprivate directive that specifies a common block name appears in one program
14 unit, then such a directive must also appear in every other program unit that contains a COMMON
15 statement that specifies the same name. It must appear after the last such COMMON statement in
16 the program unit.
17 • If a threadprivate variable or a threadprivate common block is declared with the BIND attribute,
18 the corresponding C entities must also be specified in a threadprivate directive in the C
19 program.
20 • A variable can only appear in a threadprivate directive in the scope in which it is declared.
21 It must not be an element of a common block or appear in an EQUIVALENCE statement.
22 • A variable that appears in a threadprivate directive must be declared in the scope of a
23 module or have the SAVE attribute, either explicitly or implicitly.
24 • The effect of an access to a threadprivate variable in a DO CONCURRENT construct is unspecified.
Fortran
25 Cross References
26 • dyn-var ICV, see Section 2.4.
27 • Number of threads used to execute a parallel region, see Section 2.6.1.

1 2.21.3 List Item Privatization
2 For any construct, a list item that appears in a data-sharing attribute clause, including a reduction
3 clause, may be privatized. Each task that references a privatized list item in any statement in the
4 construct receives at least one new list item if the construct has one or more associated loops, and
5 otherwise each such task receives one new list item. Each SIMD lane used in a simd construct that
6 references a privatized list item in any statement in the construct receives at least one new list item.
7 Language-specific attributes for new list items are derived from the corresponding original list item.
8 Inside the construct, all references to the original list item are replaced by references to a new list
9 item received by the task or SIMD lane.
10 If the construct has one or more associated loops, within the same logical iteration of the loops,
11 then the same new list item replaces all references to the original list item. For any two logical
12 iterations, if the references to the original list item are replaced by the same list item then the logical
13 iterations must execute in some sequential order.
14 In the rest of the region, whether references are to a new list item or the original list item is
15 unspecified. Therefore, if an attempt is made to reference the original item, its value after the
16 region is also unspecified. If a task or a SIMD lane does not reference a privatized list item,
17 whether the task or SIMD lane receives a new list item is unspecified.
18 The value and/or allocation status of the original list item will change only:
19 • If accessed and modified via pointer;
20 • If possibly accessed in the region but outside of the construct;
21 • As a side effect of directives or clauses; or
Fortran
22 • If accessed and modified via construct association.
Fortran
C++
23 If the construct is contained in a member function, whether accesses anywhere in the region
24 through the implicit this pointer refer to the new list item or the original list item is unspecified.
C++
C / C++
25 A new list item of the same type, with automatic storage duration, is allocated for the construct.
26 The storage and thus lifetime of these list items last until the block in which they are created exits.
27 The size and alignment of the new list item are determined by the type of the variable. This
28 allocation occurs once for each task generated by the construct and once for each SIMD lane used
29 by the construct.
30 The new list item is initialized, or has an undefined initial value, as if it had been locally declared
31 without an initializer.
C / C++

C++
1 If the type of a list item is a reference to a type T then the type will be considered to be T for all
2 purposes of this clause.
3 The order in which any default constructors for different private variables of class type are called is
4 unspecified. The order in which any destructors for different private variables of class type are
5 called is unspecified.
C++
Fortran
6 If any statement of the construct references a list item, a new list item of the same type and type
7 parameters is allocated. This allocation occurs once for each task generated by the construct and
8 once for each SIMD lane used by the construct. If the type of the list item has default initialization,
9 the new list item has default initialization. Otherwise, the initial value of the new list item is
10 undefined. The initial status of a private pointer is undefined.
11 For a list item or the subobject of a list item with the ALLOCATABLE attribute:
12 • If the allocation status is unallocated, the new list item or the subobject of the new list item will
13 have an initial allocation status of unallocated;
14 • If the allocation status is allocated, the new list item or the subobject of the new list item will
15 have an initial allocation status of allocated; and
16 • If the new list item or the subobject of the new list item is an array, its bounds will be the same as
17 those of the original list item or the subobject of the original list item.
18 A privatized list item may be storage-associated with other variables when the data-sharing
19 attribute clause is encountered. Storage association may exist because of constructs such as
20 EQUIVALENCE or COMMON. If A is a variable that is privatized by a construct and B is a variable
21 that is storage-associated with A, then:
22 • The contents, allocation, and association status of B are undefined on entry to the region;
23 • Any definition of A, or of its allocation or association status, causes the contents, allocation, and
24 association status of B to become undefined; and
25 • Any definition of B, or of its allocation or association status, causes the contents, allocation, and
26 association status of A to become undefined.
27 A privatized list item may be a selector of an ASSOCIATE or SELECT TYPE construct. If the
28 construct association is established prior to a parallel region, the association between the
29 associate name and the original list item will be retained in the region.
30 Finalization of a list item of a finalizable type or subobjects of a list item of a finalizable type
31 occurs at the end of the region. The order in which any final subroutines for different variables of a
32 finalizable type are called is unspecified.
Fortran

1 If a list item appears in both firstprivate and lastprivate clauses, the update required
2 for the lastprivate clause occurs after all initializations for the firstprivate clause.
3 Restrictions
4 The following restrictions apply to any list item that is privatized unless otherwise stated for a given
5 data-sharing attribute clause:
C
6 • A variable that is part of another variable (as an array or structure element) cannot be privatized.
C
C++
7 • A variable that is part of another variable (as an array or structure element) cannot be privatized
8 except if the data-sharing attribute clause is associated with a construct within a class non-static
9 member function and the variable is an accessible data member of the object for which the
10 non-static member function is invoked.
11 • A variable of class type (or array thereof) that is privatized requires an accessible, unambiguous
12 default constructor for the class type.
C++
C / C++
13 • A variable that is privatized must not have a const-qualified type unless it is of class type with
14 a mutable member. This restriction does not apply to the firstprivate clause.
15 • A variable that is privatized must not have an incomplete type or be a reference to an incomplete
16 type.
C / C++
Fortran
17 • A variable that is part of another variable (as an array or structure element) cannot be privatized.
18 • Variables that appear in namelist statements, in variable format expressions, and in expressions
19 for statement function definitions, may not be privatized.
20 • Pointers with the INTENT(IN) attribute may not be privatized. This restriction does not apply
21 to the firstprivate clause.
22 • A private variable must not be coindexed or appear as an actual argument to a procedure where
23 the corresponding dummy argument is a coarray.
24 • Assumed-size arrays may not be privatized in a target, teams, or distribute construct.
Fortran

1 2.21.4 Data-Sharing Attribute Clauses
2 Several constructs accept clauses that allow a user to control the data-sharing attributes of variables
3 referenced in the construct. Not all of the clauses listed in this section are valid on all directives.
4 The set of clauses that is valid on a particular directive is described with the directive.
5 Most of the clauses accept a comma-separated list of list items (see Section 2.1). All list items that
6 appear in a clause must be visible, according to the scoping rules of the base language. With the
7 exception of the default clause, clauses may be repeated as needed. A list item may not appear
8 in more than one clause on the same directive, except that it may be specified in both
9 firstprivate and lastprivate clauses.
10 The reduction data-sharing attribute clauses are explained in Section 2.21.5.
C++
11 If a variable referenced in a data-sharing attribute clause has a type derived from a template, and
12 the program does not otherwise reference that variable then any behavior related to that variable is
13 unspecified.
C++
Fortran
14 If individual members of a common block appear in a data-sharing attribute clause other than the
15 shared clause, the variables no longer have a Fortran storage association with the common block.
Fortran
16 2.21.4.1 default Clause

17 Summary
18 The default clause explicitly determines the data-sharing attributes of variables that are
19 referenced in a parallel, teams, or task generating construct and would otherwise be implicitly
20 determined (see Section 2.21.1.1).
21 Syntax
22 The syntax of the default clause is as follows:
24 where data-sharing-attribute is one of the following:

25 shared
26 firstprivate
27 private
28 none

1 Description
2 If data-sharing-attribute is shared or, for Fortran, firstprivate or private, the
3 data-sharing attribute of all variables referenced in the construct that have implicitly determined
4 data-sharing attributes will be data-sharing-attribute.
C / C++
5 If data-sharing-attribute is firstprivate or private, each variable with static storage
6 duration that is declared in a namespace or global scope and referenced in the construct, and that
7 does not have a predetermined data-sharing attribute, must have its data-sharing attribute explicitly
8 determined by being listed in a data-sharing attribute clause. The data-sharing attribute of all other
9 variables that are referenced in the construct and that have implicitly determined data-sharing
10 attributes will be data-sharing-attribute.
C / C++
11 The default(none) clause requires that each variable that is referenced in the construct, and
12 that does not have a predetermined data-sharing attribute, must have its data-sharing attribute
13 explicitly determined by being listed in a data-sharing attribute clause.
14 Restrictions
15 Restrictions to the default clause are as follows:
16 • Only a single default clause may be specified on a parallel, task, taskloop or
17 teams directive.
18 2.21.4.2 shared Clause

19 Summary
20 The shared clause declares one or more list items to be shared by tasks generated by a
21 parallel, teams, or task generating construct.
22 Syntax
23 The syntax of the shared clause is as follows:
24 shared(list)
25 Description
26 All references to a list item within a task refer to the storage area of the original variable at the point
27 the directive was encountered.
28 The programmer must ensure, by adding proper synchronization, that storage shared by an explicit
29 task region does not reach the end of its lifetime before the explicit task region completes its
30 execution.

Fortran
1 The association status of a shared pointer becomes undefined upon entry to and exit from a
2 parallel, teams, or task generating construct if it is associated with a target or a subobject of a
3 target that appears as a privatized list item in a data-sharing attribute clause on the construct.
4
5 Note – Passing a shared variable to a procedure may result in the use of temporary storage in place
6 of the actual argument when the corresponding dummy argument does not have the VALUE or
7 CONTIGUOUS attribute and its data-sharing attribute is implementation-defined as per the rules in
8 Section 2.21.1.2. These conditions effectively result in references to, and definitions of, the
9 temporary storage during the procedure reference. Furthermore, the value of the shared variable is
10 copied into the intervening temporary storage before the procedure reference when the dummy
11 argument does not have the INTENT(OUT) attribute, and is copied out of the temporary storage
12 into the shared variable when the dummy argument does not have the INTENT(IN) attribute. Any
13 references to (or definitions of) the shared storage that is associated with the dummy argument by
14 any other task must be synchronized with the procedure reference to avoid possible data races.
15
16
Fortran
17 Restrictions
18 Restrictions to the shared clause are as follows:
C
20 shared clause.
C
C++
22 shared clause except if the shared clause is associated with a construct within a class
23 non-static member function and the variable is an accessible data member of the object for which
24 the non-static member function is invoked.
C++
Fortran
26 inquiry) cannot appear in a shared clause.
Fortran

1 2.21.4.3 private Clause
2 Summary
3 The private clause declares one or more list items to be private to a task or to a SIMD lane.
4 Syntax
5 The syntax of the private clause is as follows:
6 private(list)
7 Description
8 The private clause specifies that its list items are to be privatized according to Section 2.21.3.
9 Each task or SIMD lane that references a list item in the construct receives only one new list item,
10 unless the construct has one or more associated loops and an order clause that specifies
11 concurrent is also present.
12 Restrictions
13 Restrictions to the private clause are as specified in Section 2.21.3.
14 Cross References
16 2.21.4.4 firstprivate Clause

17 Summary
18 The firstprivate clause declares one or more list items to be private to a task, and initializes
19 each of them with the value that the corresponding original item has when the construct is
20 encountered.
21 Syntax
22 The syntax of the firstprivate clause is as follows:
24 Description
25 The firstprivate clause provides a superset of the functionality provided by the private
26 clause.
Fortran
27 The list items that appear in a firstprivate clause may include named constants.
Fortran

1 A list item that appears in a firstprivate clause is subject to the private clause semantics
2 described in Section 2.21.4.3, except as noted. In addition, the new list item is initialized from the
3 original list item that exists before the construct. The initialization of the new list item is done once
4 for each task that references the list item in any statement in the construct. The initialization is done
5 prior to the execution of the construct.
6 For a firstprivate clause on a parallel, task, taskloop, target, or teams
7 construct, the initial value of the new list item is the value of the original list item that exists
8 immediately prior to the construct in the task region where the construct is encountered unless
9 otherwise specified. For a firstprivate clause on a worksharing construct, the initial value of
10 the new list item for each implicit task of the threads that execute the worksharing construct is the
11 value of the original list item that exists in the implicit task immediately prior to the point in time
12 that the worksharing construct is encountered unless otherwise specified.
13 To avoid data races, concurrent updates of the original list item must be synchronized with the read
14 of the original list item that occurs as a result of the firstprivate clause.
C / C++
15 For variables of non-array type, the initialization occurs by copy assignment. For an array of
16 elements of non-array type, each element is initialized as if by assignment from an element of the
17 original array to the corresponding element of the new array.
C / C++
C++
18 For each variable of class type:
19 • If the firstprivate clause is not on a target construct then a copy constructor is invoked
20 to perform the initialization; and
21 • If the firstprivate clause is on a target construct then how many copy constructors, if
22 any, are invoked is unspecified.
23 If copy constructors are called, the order in which copy constructors for different variables of class
24 type are called is unspecified.
C++
Fortran
25 If the original list item does not have the POINTER attribute, initialization of the new list items
26 occurs as if by intrinsic assignment unless the original list item has a compatible type-bound
27 defined assignment, in which case initialization of the new list items occurs as if by the defined
28 assignment. If the original list item that does not have the POINTER attribute has the allocation
29 status of unallocated, the new list items will have the same status.
30 If the original list item has the POINTER attribute, the new list items receive the same association
31 status of the original list item as if by pointer assignment.
Fortran

1 Restrictions
2 Restrictions to the firstprivate clause are as follows:
3 • A list item that is private within a parallel region must not appear in a firstprivate
4 clause on a worksharing construct if any of the worksharing regions that arise from the
5 worksharing construct ever bind to any of the parallel regions that arise from the
7 • A list item that is private within a teams region must not appear in a firstprivate clause
8 on a distribute construct if any of the distribute regions that arise from the
9 distribute construct ever bind to any of the teams regions that arise from the teams
10 construct.
11 • A list item that appears in a reduction clause of a parallel construct must not appear in a
12 firstprivate clause on a worksharing, task, or taskloop construct if any of the
13 worksharing or task regions that arise from the worksharing, task, or taskloop construct
14 ever bind to any of the parallel regions that arise from the parallel construct.
15 • A list item that appears in a reduction clause of a teams construct must not appear in a
16 firstprivate clause on a distribute construct if any of the distribute regions that
17 arise from the distribute construct ever bind to any of the teams regions that arise from the
18 teams construct.
19 • A list item that appears in a reduction clause of a worksharing construct must not appear in a
20 firstprivate clause in a task construct encountered during execution of any of the
21 worksharing regions that arise from the worksharing construct.
C++
22 • A variable of class type (or array thereof) that appears in a firstprivate clause requires an
23 accessible, unambiguous copy constructor for the class type.
C++
C / C++
24 • If a list item in a firstprivate clause on a worksharing construct has a reference type then it
25 must bind to the same object for all threads of the team.
C / C++
Fortran
26 • If the list item is a polymorphic variable with the ALLOCATABLE attribute, the behavior is
27 unspecified.
Fortran

1 2.21.4.5 lastprivate Clause
2 Summary
3 The lastprivate clause declares one or more list items to be private to an implicit task or to a
4 SIMD lane, and causes the corresponding original list item to be updated after the end of the region.
5 Syntax
6 The syntax of the lastprivate clause is as follows:
8 where lastprivate-modifier is:

9 conditional
10 Description
11 The lastprivate clause provides a superset of the functionality provided by the private
12 clause.
13 A list item that appears in a lastprivate clause is subject to the private clause semantics
14 described in Section 2.21.4.3. In addition, when a lastprivate clause without the
15 conditional modifier appears on a directive and the list item is not an iteration variable of one
16 of the associated loops, the value of each new list item from the sequentially last iteration of the
17 associated loops, or the lexically last section construct, is assigned to the original list item.
18 When the conditional modifier appears on the clause or the list item is an iteration variable of
19 one of the associated loops, if sequential execution of the loop nest would assign a value to the list
20 item then the original list item is assigned the value that the list item would have after sequential
21 execution of the loop nest.
C / C++
22 For an array of elements of non-array type, each element is assigned to the corresponding element
23 of the original array.
C / C++
Fortran
24 If the original list item does not have the POINTER attribute, its update occurs as if by intrinsic
25 assignment unless it has a type bound procedure as a defined assignment.
26 If the original list item has the POINTER attribute, its update occurs as if by pointer assignment.
Fortran
27 When the conditional modifier does not appear on the lastprivate clause, any list item
28 that is not an iteration variable of the associated loops and that is not assigned a value by the
29 sequentially last iteration of the loops, or by the lexically last section construct, has an
30 unspecified value after the construct. When the conditional modifier does not appear on the
31 lastprivate clause, a list item that is the iteration variable of an associated loop and that would
32 not be assigned a value during sequential execution of the loop nest has an unspecified value after
33 the construct. Unassigned subcomponents also have unspecified values after the construct.

1 If the lastprivate clause is used on a construct to which neither the nowait nor the
2 nogroup clauses are applied, the original list item becomes defined at the end of the construct. To
3 avoid data races, concurrent reads or updates of the original list item must be synchronized with the
4 update of the original list item that occurs as a result of the lastprivate clause.
5 Otherwise, If the lastprivate clause is used on a construct to which the nowait or the
6 nogroup clauses are applied, accesses to the original list item may create a data race. To avoid
7 this data race, if an assignment to the original list item occurs then synchronization must be inserted
8 to ensure that the assignment completes and the original list item is flushed to memory.
9 If a list item that appears in a lastprivate clause with the conditional modifier is
10 modified in the region by an assignment outside the construct or not to the list item then the value
11 assigned to the original list item is unspecified.
12 Restrictions
13 Restrictions to the lastprivate clause are as follows:
14 • A list item that is private within a parallel region, or that appears in the reduction clause
15 of a parallel construct, must not appear in a lastprivate clause on a worksharing
16 construct if any of the corresponding worksharing regions ever binds to any of the corresponding
17 parallel regions.
18 • A list item that appears in a lastprivate clause with the conditional modifier must be a
19 scalar variable.
C++
20 • A variable of class type (or array thereof) that appears in a lastprivate clause requires an
21 accessible, unambiguous default constructor for the class type, unless the list item is also
22 specified in a firstprivate clause.
23 • A variable of class type (or array thereof) that appears in a lastprivate clause requires an
24 accessible, unambiguous copy assignment operator for the class type. The order in which copy
25 assignment operators for different variables of class type are called is unspecified.
C++
C / C++
26 • If a list item in a lastprivate clause on a worksharing construct has a reference type then it
27 must bind to the same object for all threads of the team.
C / C++
Fortran
28 • A variable that appears in a lastprivate clause must be definable.
29 • If the original list item has the ALLOCATABLE attribute, the corresponding list item of which the
30 value is assigned to the original item must have an allocation status of allocated upon exit from
31 the sequentially last iteration or lexically last section construct.
33 unspecified.
Fortran

1 2.21.4.6 linear Clause
2 Summary
3 The linear clause declares one or more list items to be private and to have a linear relationship
4 with respect to the iteration space of a loop associated with the construct on which the clause
5 appears.
6 Syntax
C
7 The syntax of the linear clause is as follows:
9 where linear-list is one of the following

10 list
11 modifier(list)
12 where modifier is one of the following:

13 val
C
C++

17 list
18 modifier(list)

20 ref
21 val
22 uval
C++

Fortran

4 list
5 modifier(list)

7 ref
8 val
9 uval
Fortran
10 Description
11 The linear clause provides a superset of the functionality provided by the private clause. A
12 list item that appears in a linear clause is subject to the private clause semantics described in
13 Section 2.21.4.3 except as noted. If linear-step is not specified, it is assumed to be 1.
14 When a linear clause is specified on a construct, the value of the new list item on each logical
15 iteration of the associated loops corresponds to the value of the original list item before entering the
16 construct plus the logical number of the iteration times linear-step. The value corresponding to the
17 sequentially last logical iteration of the associated loops is assigned to the original list item.
18 When a linear clause is specified on a declarative directive, all list items must be formal
19 parameters (or, in Fortran, dummy arguments) of a function that will be invoked concurrently on
20 each SIMD lane. If no modifier is specified or the val or uval modifier is specified, the value of
21 each list item on each lane corresponds to the value of the list item upon entry to the function plus
22 the logical number of the lane times linear-step. If the uval modifier is specified, each invocation
23 uses the same storage location for each SIMD lane; this storage location is updated with the final
24 value of the logically last lane. If the ref modifier is specified, the storage location of each list
25 item on each lane corresponds to an array at the storage location upon entry to the function indexed
26 by the logical number of the lane times linear-step.
27 Restrictions
28 Restrictions to the linear clause are as follows:
29 • The linear-step expression must be invariant during the execution of the region that corresponds
30 to the construct.
31 • Only a loop iteration variable of a loop that is associated with the construct may appear as a
32 list-item in a linear clause if a reduction clause with the inscan modifier also appears
33 on the construct.

C
1 • A list-item that appears in a linear clause must be of integral or pointer type.
C
C++
2 • A list-item that appears in a linear clause without the ref modifier must be of integral or
3 pointer type, or must be a reference to an integral or pointer type.
4 • The ref or uval modifier can only be used if the list-item is of a reference type.
5 • If a list item in a linear clause on a worksharing construct has a reference type then it must
6 bind to the same object for all threads of the team.
7 • If the list item is of a reference type and the ref modifier is not specified and if any write to the
8 list item occurs before any read of the list item then the result is unspecified.
C++
Fortran
9 • A list-item that appears in a linear clause without the ref modifier must be of type
10 integer.
11 • The ref or uval modifier can only be used if the list-item is a dummy argument without the
12 VALUE attribute.
13 • Variables that have the POINTER attribute and Cray pointers may not appear in a linear
14 clause. Cray pointer support has been deprecated.
15 • If the list item has the ALLOCATABLE attribute and the ref modifier is not specified, the
16 allocation status of the list item in the sequentially last iteration must be allocated upon exit from
17 that iteration.
18 • If the ref modifier is specified, variables with the ALLOCATABLE attribute, assumed-shape
19 arrays and polymorphic variables may not appear in the linear clause.
20 • If the list item is a dummy argument without the VALUE attribute and the ref modifier is not
21 specified, any read of the list item must occur before any write to the list item.
22 • A common block name cannot appear in a linear clause.
Fortran
23 2.21.5 Reduction Clauses and Directives

24 The reduction clauses are data-sharing attribute clauses that can be used to perform some forms of
25 recurrence calculations in parallel. Reduction clauses include reduction scoping clauses and
26 reduction participating clauses. Reduction scoping clauses define the region in which a reduction is
27 computed. Reduction participating clauses define the participants in the reduction.

1 2.21.5.1 Properties Common to All Reduction Clauses
2 Syntax
3 The syntax of a reduction-identifier is defined as follows:
C
4 A reduction-identifier is either an identifier or one of the following operators: +, -, *, &, |, ^, &&
5 and ||.
C
C++
6 A reduction-identifier is either an id-expression or one of the following operators: +, -, *, &, |, ^,
7 && and ||.
C++
Fortran
8 A reduction-identifier is either a base language identifier, or a user-defined operator, or one of the
9 following operators: +, -, *, .and., .or., .eqv., .neqv., or one of the following intrinsic
10 procedure names: max, min, iand, ior, ieor.
Fortran
C / C++
11 Table 2.11 lists each reduction-identifier that is implicitly declared at every scope for arithmetic
12 types and its semantic initializer value. The actual initializer value is that value as expressed in the
13 data type of the reduction list item.
TABLE 2.11: Implicitly Declared C/C++ reduction-identifiers
Identifier Initializer Combiner
+ omp_priv = 0 omp_out += omp_in

- omp_priv = 0 omp_out += omp_in
* omp_priv = 1 omp_out *= omp_in
& omp_priv = ~ 0 omp_out &= omp_in
| omp_priv = 0 omp_out |= omp_in
^ omp_priv = 0 omp_out ^= omp_in
&& omp_priv = 1 omp_out = omp_in && omp_out
|| omp_priv = 0 omp_out = omp_in || omp_out

max omp_priv = Minimal omp_out = omp_in > omp_out ?

representable number in the omp_in : omp_out
reduction list item type
min omp_priv = Maximal omp_out = omp_in < omp_out ?
representable number in the omp_in : omp_out
C / C++
Fortran
1 Table 2.12 lists each reduction-identifier that is implicitly declared for numeric and logical types
2 and its semantic initializer value. The actual initializer value is that value as expressed in the data
3 type of the reduction list item.
TABLE 2.12: Implicitly Declared Fortran reduction-identifiers
+ omp_priv = 0 omp_out = omp_in + omp_out

- omp_priv = 0 omp_out = omp_in + omp_out
* omp_priv = 1 omp_out = omp_in * omp_out
.and. omp_priv = .true. omp_out = omp_in .and. omp_out
.or. omp_priv = .false. omp_out = omp_in .or. omp_out
.eqv. omp_priv = .true. omp_out = omp_in .eqv. omp_out
.neqv. omp_priv = .false. omp_out = omp_in .neqv. omp_out
max omp_priv = Minimal omp_out = max(omp_in, omp_out)
representable number in the
min omp_priv = Maximal omp_out = min(omp_in, omp_out)
representable number in the

iand omp_priv = All bits on omp_out = iand(omp_in, omp_out)

ior omp_priv = 0 omp_out = ior(omp_in, omp_out)
ieor omp_priv = 0 omp_out = ieor(omp_in, omp_out)
Fortran
1 In the above tables, omp_in and omp_out correspond to two identifiers that refer to storage of the
2 type of the list item. If the list item is an array or array section, the identifiers to which omp_in
3 and omp_out correspond each refer to an array element. omp_out holds the final value of the
4 combiner operation.
5 Any reduction-identifier that is defined with the declare reduction directive is also valid. In
6 that case, the initializer and combiner of the reduction-identifier are specified by the
7 initializer-clause and the combiner in the declare reduction directive.
8 Description
9 A reduction clause specifies a reduction-identifier and one or more list items.
10 The reduction-identifier specified in a reduction clause must match a previously declared
11 reduction-identifier of the same name and type for each of the list items. This match is done by
12 means of a name lookup in the base language.
13 The list items that appear in a reduction clause may include array sections.
C++
14 If the type is a derived class, then any reduction-identifier that matches its base classes is also a
15 match, if no specific match for the type has been specified.
16 If the reduction-identifier is not an id-expression, then it is implicitly converted to one by
17 prepending the keyword operator (for example, + becomes operator+).
18 If the reduction-identifier is qualified then a qualified name lookup is used to find the declaration.
19 If the reduction-identifier is unqualified then an argument-dependent name lookup must be
20 performed using the type of each list item.
C++
21 If a list item is an array or array section, it will be treated as if a reduction clause would be applied
22 to each separate element of the array section.
23 If a list item is an array section, the elements of any copy of the array section will be stored
24 contiguously.

Fortran
1 If the original list item has the POINTER attribute, any copies of the list item are associated with
2 private targets.
Fortran
3 Any copies of a list item associated with the reduction are initialized with the initializer value of the
4 reduction-identifier.
5 Any copies are combined using the combiner associated with the reduction-identifier.

7 The reduction-begin event occurs before a task begins to perform loads and stores that belong to the
8 implementation of a reduction and the reduction-end event occurs after the task has completed
9 loads and stores associated with the reduction. If a task participates in multiple reductions, each
10 reduction may be bracketed by its own pair of reduction-begin/reduction-end events or multiple
11 reductions may be bracketed by a single pair of events. The interval defined by a pair of
12 reduction-begin/reduction-end events may not contain a task scheduling point.
13 Tool Callbacks
14 A thread dispatches a registered ompt_callback_reduction with
15 ompt_sync_region_reduction in its kind argument and ompt_scope_begin as its
16 endpoint argument for each occurrence of a reduction-begin event in that thread. Similarly, a thread
17 dispatches a registered ompt_callback_reduction with
18 ompt_sync_region_reduction in its kind argument and ompt_scope_end as its
19 endpoint argument for each occurrence of a reduction-end event in that thread. These callbacks
20 occur in the context of the task that performs the reduction and has the type signature
22 Restrictions
23 Restrictions common to reduction clauses are as follows:
24 • Any number of reduction clauses can be specified on the directive, but a list item (or any array
25 element in an array section) can appear only once in reduction clauses for that directive.
26 • For a reduction-identifier declared in a declare reduction directive, the directive must
27 appear before its use in a reduction clause.
28 • If a list item is an array section or an array element, its base expression must be a base language
29 identifier.
30 • If a list item is an array section, it must specify contiguous storage and it cannot be a zero-length
31 array section.
32 • If a list item is an array section or an array element, accesses to the elements of the array outside
33 the specified array section or array element result in unspecified behavior.

C
1 • A variable that is part of another variable, with the exception of array elements, cannot appear in
2 a reduction clause.
C
C++
4 a reduction clause except if the reduction clause is associated with a construct within a class
5 non-static member function and the variable is an accessible data member of the object for which
6 the non-static member function is invoked.
C++
C / C++
7 • The type of a list item that appears in a reduction clause must be valid for the
8 reduction-identifier. For a max or min reduction in C, the type of the list item must be an
9 allowed arithmetic data type: char, int, float, double, or _Bool, possibly modified with
10 long, short, signed, or unsigned. For a max or min reduction in C++, the type of the
11 list item must be an allowed arithmetic data type: char, wchar_t, int, float, double, or
12 bool, possibly modified with long, short, signed, or unsigned.
13 • A list item that appears in a reduction clause must not be const-qualified.
14 • The reduction-identifier for any list item must be unambiguous and accessible.
C / C++
Fortran
16 a reduction clause.
17 • A type parameter inquiry cannot appear in a reduction clause.
18 • The type, type parameters and rank of a list item that appears in a reduction clause must be valid
19 for the combiner and initializer.
20 • A list item that appears in a reduction clause must be definable.
21 • A procedure pointer may not appear in a reduction clause.
22 • A pointer with the INTENT(IN) attribute may not appear in the reduction clause.
23 • An original list item with the POINTER attribute or any pointer component of an original list
24 item that is referenced in the combiner must be associated at entry to the construct that contains
25 the reduction clause. Additionally, the list item or the pointer component of the list item must not
26 be deallocated, allocated, or pointer assigned within the region.

1 • An original list item with the ALLOCATABLE attribute or any allocatable component of an
2 original list item that corresponds to a special variable identifier in the combiner or the initializer
3 must be in the allocated state at entry to the construct that contains the reduction clause.
4 Additionally, the list item or the allocatable component of the list item must be neither
5 deallocated nor allocated, explicitly or implicitly, within the region.
6 • If the reduction-identifier is defined in a declare reduction directive, the
7 declare reduction directive must be in the same subprogram, or accessible by host or use
8 association.
9 • If the reduction-identifier is a user-defined operator, the same explicit interface for that operator
10 must be accessible at the location of the declare reduction directive that defines the
12 • If the reduction-identifier is defined in a declare reduction directive, any procedure
13 referenced in the initializer clause or combiner expression must be an intrinsic function,
14 or must have an explicit interface where the same explicit interface is accessible as at the
Fortran
16 Cross References
18 • ompt_sync_region_reduction, see Section 4.4.4.13.
20 2.21.5.2 Reduction Scoping Clauses

21 Reduction scoping clauses define the region in which a reduction is computed by tasks or SIMD
22 lanes. All properties common to all reduction clauses, which are defined in Section 2.21.5.1, apply
23 to reduction scoping clauses.
24 The number of copies created for each list item and the time at which those copies are initialized
25 are determined by the particular reduction scoping clause that appears on the construct.
26 The time at which the original list item contains the result of the reduction is determined by the
27 particular reduction scoping clause.
28 The location in the OpenMP program at which values are combined and the order in which values
29 are combined are unspecified. Therefore, when comparing sequential and parallel executions, or
30 when comparing one parallel execution to another (even if the number of threads used is the same),
31 bitwise-identical results are not guaranteed to be obtained. Similarly, side effects (such as
32 floating-point exceptions) may not be identical and may not take place at the same location in the
33 OpenMP program.
34 To avoid data races, concurrent reads or updates of the original list item must be synchronized with
35 the update of the original list item that occurs as a result of the reduction computation.

1 2.21.5.3 Reduction Participating Clauses
2 A reduction participating clause specifies a task or a SIMD lane as a participant in a reduction
3 defined by a reduction scoping clause. All properties common to all reduction clauses, which are
4 defined in Section 2.21.5.1, apply to reduction participating clauses.
5 Accesses to the original list item may be replaced by accesses to copies of the original list item
6 created by a region that corresponds to a construct with a reduction scoping clause.
7 In any case, the final value of the reduction must be determined as if all tasks or SIMD lanes that
8 participate in the reduction are executed sequentially in some arbitrary order.
9 2.21.5.4 reduction Clause

10 Summary
11 The reduction clause specifies a reduction-identifier and one or more list items. For each list
12 item, a private copy is created for each implicit task or SIMD lane and is initialized with the
13 initializer value of the reduction-identifier. After the end of the region, the original list item is
14 updated with the values of the private copies using the combiner associated with the
16 Syntax
17 The syntax of the reduction clause is as follows:
19 Where reduction-identifier is defined in Section 2.21.5.1, and reduction-modifier is one of the

20 following:
21 inscan
22 task
23 default
24 Description
25 The reduction clause is a reduction scoping clause and a reduction participating clause, as
26 described in Section 2.21.5.2 and Section 2.21.5.3.
27 If reduction-modifier is not present or the default reduction-modifier is present, the behavior is
28 as follows. For parallel, scope and worksharing constructs, one or more private copies of
29 each list item are created for each implicit task, as if the private clause had been used. For the
30 simd construct, one or more private copies of each list item are created for each SIMD lane, as if
31 the private clause had been used. For the taskloop construct, private copies are created
32 according to the rules of the reduction scoping clauses. For the teams construct, one or more
33 private copies of each list item are created for the initial task of each team in the league, as if the
34 private clause had been used. For the loop construct, private copies are created and used in the

1 construct according to the description and restrictions in Section 2.21.3. At the end of a region that
2 corresponds to a construct for which the reduction clause was specified, the original list item is
3 updated by combining its original value with the final value of each of the private copies, using the
4 combiner of the specified reduction-identifier.
5 If the inscan reduction-modifier is present, a scan computation is performed over updates to the
6 list item performed in each logical iteration of the loop associated with the worksharing-loop,
7 worksharing-loop SIMD, or simd construct (see Section 2.11.8). The list items are privatized in
8 the construct according to the description and restrictions in Section 2.21.3. At the end of the
9 region, each original list item is assigned the value described in Section 2.11.8.
10 If the task reduction-modifier is present for a parallel, scope, or worksharing construct,
11 then each list item is privatized according to the description and restrictions in Section 2.21.3, and
12 an unspecified number of additional private copies may be created to support task reductions. Any
13 copies associated with the reduction are initialized before they are accessed by the tasks that
14 participate in the reduction, which include all implicit tasks in the corresponding region and all
15 participating explicit tasks that specify an in_reduction clause (see Section 2.21.5.6). After
16 the end of the region, the original list item contains the result of the reduction.
17 If nowait is not specified for the construct, the reduction computation will be complete at the end
18 of the region that corresponds to the construct; however, if the reduction clause is used on a
19 construct to which nowait is also applied, accesses to the original list item will create a race and,
20 thus, have unspecified effect unless synchronization ensures that they occur after all threads have
21 executed all of their iterations or section constructs, and the reduction computation has
22 completed and stored the computed value of that list item. This can be ensured simply through a
23 barrier synchronization in most cases.
24 Restrictions
25 Restrictions to the reduction clause are as follows:
26 • All restrictions common to all reduction clauses, which are listed in Section 2.21.5.1, apply to
27 this clause.
28 • A list item that appears in a reduction clause of a worksharing construct must be shared in
29 the parallel region to which a corresponding worksharing region binds.
30 • A list item that appears in a reduction clause of a scope construct must be shared in the
31 parallel region to which a corresponding scope region binds.
32 • If an array section or an array element appears as a list item in a reduction clause of a
33 worksharing construct, scope construct or loop construct for which the corresponding region
34 binds to a parallel region, all threads that participate in the reduction must specify the same
35 storage location.
36 • A list item that appears in a reduction clause with the inscan reduction-modifier must
37 appear as a list item in an inclusive or exclusive clause on a scan directive enclosed by
38 the construct.

1 • A reduction clause without the inscan reduction-modifier may not appear on a construct
2 on which a reduction clause with the inscan reduction-modifier appears.
3 • A reduction clause with the task reduction-modifier may only appear on a parallel
4 construct, a scope construct, a worksharing construct or a combined or composite construct for
5 which any of the aforementioned constructs is a constituent construct and simd or loop are not
6 constituent constructs.
7 • A reduction clause with the inscan reduction-modifier may only appear on a
8 worksharing-loop construct, a simd construct or a combined or composite construct for which
9 any of the aforementioned constructs is a constituent construct and distribute is not a
10 constituent construct.
11 • A list item that appears in a reduction clause of the innermost enclosing worksharing,
12 parallel or scope construct may not be accessed in an explicit task generated by a construct
13 for which an in_reduction clause over the same list item does not appear.
14 • The task reduction-modifier may not appear in a reduction clause if the nowait clause is
15 specified on the same construct.
C / C++
16 • If a list item in a reduction clause on a worksharing construct, scope construct or loop
17 construct for which the corresponding region binds to a parallel region has a reference type then
18 it must bind to the same object for all threads of the team.
19 • If a list item in a reduction clause on a worksharing construct, scope or loop construct for
20 which the corresponding region binds to a parallel region is an array section or an array element
21 then the base pointer must point to the same variable for all threads of the team.
22 • A variable of class type (or array thereof) that appears in a reduction clause with the
23 inscan reduction-modifier requires an accessible, unambiguous default constructor for the
24 class type. The number of calls to the default constructor while performing the scan computation
25 is unspecified.
26 • A variable of class type (or array thereof) that appears in a reduction clause with the
27 inscan reduction-modifier requires an accessible, unambiguous copy assignment operator for
28 the class type. The number of calls to the copy assignment operator while performing the scan
29 computation is unspecified.
C / C++
30 Cross References
31 • scan directive, see Section 2.11.8.
33 • private clause, see Section 2.21.4.3.

1 2.21.5.5 task_reduction Clause
2 Summary
3 The task_reduction clause specifies a reduction among tasks.
4 Syntax
5 The syntax of the task_reduction clause is as follows:
7 where reduction-identifier is defined in Section 2.21.5.1.
8 Description
9 The task_reduction clause is a reduction scoping clause, as described in 2.21.5.2.
10 For each list item, the number of copies is unspecified. Any copies associated with the reduction
11 are initialized before they are accessed by the tasks that participate in the reduction. After the end
12 of the region, the original list item contains the result of the reduction.
13 Restrictions
14 Restrictions to the task_reduction clause are as follows:
16 this clause.
17 2.21.5.6 in_reduction Clause

18 Summary
19 The in_reduction clause specifies that a task participates in a reduction.
20 Syntax
21 The syntax of the in_reduction clause is as follows:
23 where reduction-identifier is defined in Section 2.21.5.1.
24 Description
25 The in_reduction clause is a reduction participating clause, as described in Section 2.21.5.3.
26 For a given list item, the in_reduction clause defines a task to be a participant in a task
27 reduction that is defined by an enclosing region for a matching list item that appears in a
28 task_reduction clause or a reduction clause with task as the reduction-modifier, where
29 either:
30 1. The matching list item has the same storage location as the list item in the in_reduction
31 clause; or
32 2. A private copy, derived from the matching list item, that is used to perform the task reduction
33 has the same storage location as the list item in the in_reduction clause.

1 For the task construct, the generated task becomes the participating task. For each list item, a
2 private copy may be created as if the private clause had been used.
3 For the target construct, the target task becomes the participating task. For each list item, a
4 private copy may be created in the data environment of the target task as if the private clause
5 had been used. This private copy will be implicitly mapped into the device data environment of the
6 target device, if the target device is not the parent device.
7 At the end of the task region, if a private copy was created its value is combined with a copy created
8 by a reduction scoping clause or with the original list item.
9 Restrictions
10 Restrictions to the in_reduction clause are as follows:
12 this clause.
13 • A list item that appears in a task_reduction clause or a reduction clause with task as
14 the reduction-modifier that is specified on a construct that corresponds to a region in which the
15 region of the participating task is closely nested must match each list item. The construct that
16 corresponds to the innermost enclosing region that meets this condition must specify the same
17 reduction-identifier for the matching list item as the in_reduction clause.
18 2.21.5.7 declare reduction Directive

19 Summary
20 The following section describes the directive for declaring user-defined reductions. The
21 declare reduction directive declares a reduction-identifier that can be used in a reduction
22 clause. The declare reduction directive is a declarative directive.
23 Syntax
C
24 The syntax of the declare reduction directive is as follows:
25 #pragma omp declare reduction(reduction-identifier : typename-list :
26 combiner )[initializer-clause] new-line
27 where:
28 • reduction-identifier is either a base language identifier or one of the following operators: +, -, *,
29 &, |, ^, && or ||
30 • typename-list is a list of type names
31 • combiner is an expression
32 • initializer-clause is initializer(initializer-expr) where initializer-expr is
33 omp_priv = initializer or function-name(argument-list)
C

C++
2 #pragma omp declare reduction(reduction-identifier : typename-list :
3 combiner) [initializer-clause] new-line
4 where:
5 • reduction-identifier is either an id-expression or one of the following operators: +, -, *, &, |, ^,
6 && or ||
7 • typename-list is a list of type names
8 • combiner is an expression
9 • initializer-clause is initializer(initializer-expr) where initializer-expr is
10 omp_priv initializer or function-name(argument-list)
C++
Fortran
12 !$omp declare reduction(reduction-identifier : type-list : combiner)
13 [initializer-clause]
14 where:
15 • reduction-identifier is either a base language identifier, or a user-defined operator, or one of the
16 following operators: +, -, *, .and., .or., .eqv., .neqv., or one of the following intrinsic
17 procedure names: max, min, iand, ior, ieor.
18 • type-list is a list of type specifiers that must not be CLASS(*) or an abstract type
19 • combiner is either an assignment statement or a subroutine name followed by an argument list
20 • initializer-clause is initializer(initializer-expr), where initializer-expr is
21 omp_priv = expression or subroutine-name(argument-list)
Fortran
22 Description
23 User-defined reductions can be defined using the declare reduction directive. The
24 reduction-identifier and the type identify the declare reduction directive. The
25 reduction-identifier can later be used in a reduction clause that uses variables of the type or
26 types specified in the declare reduction directive. If the directive specifies several types then
27 the behavior is as if a declare reduction directive was specified for each type.

Fortran
1 If a type with deferred or assumed length type parameter is specified in a declare reduction
2 directive, the reduction-identifier of that directive can be used in a reduction clause with any
3 variable of the same type and the same kind parameter, regardless of the length type Fortran
4 parameters with which the variable is declared.
Fortran
5 The visibility and accessibility of a user-defined reduction are the same as those of a variable
6 declared at the same location in the program. The enclosing context of the combiner and of the
7 initializer-expr is that of the declare reduction directive. The combiner and the
8 initializer-expr must be correct in the base language as if they were the body of a function defined
9 at the same location in the program.
Fortran
10 If the reduction-identifier is the same as the name of a user-defined operator or an extended
11 operator, or the same as a generic name that is one of the allowed intrinsic procedures, and if the
12 operator or procedure name appears in an accessibility statement in the same module, the
13 accessibility of the corresponding declare reduction directive is determined by the
14 accessibility attribute of the statement.
15 If the reduction-identifier is the same as a generic name that is one of the allowed intrinsic
16 procedures and is accessible, and if it has the same name as a derived type in the same module, the
17 accessibility of the corresponding declare reduction directive is determined by the
18 accessibility of the generic name according to the base language.
Fortran
C++
19 The declare reduction directive can also appear at the locations in a program where a static
20 data member could be declared. In this case, the visibility and accessibility of the declaration are
21 the same as those of a static data member declared at the same location in the program.
C++
22 The combiner specifies how partial results are combined into a single value. The combiner can use
23 the special variable identifiers omp_in and omp_out that are of the type of the variables that this
24 reduction-identifier reduces. Each of the two special variable identifiers denotes one of the values
25 to be combined before executing the combiner. The special omp_out identifier refers to the
26 storage that holds the resulting combined value after executing the combiner.
27 The number of times that the combiner is executed and the order of these executions for any
28 reduction clause are unspecified.
Fortran
29 If the combiner is a subroutine name with an argument list, the combiner is evaluated by calling the
30 subroutine with the specified argument list.
31 If the combiner is an assignment statement, the combiner is evaluated by executing the assignment
32 statement.

1 If a generic name is used in the combiner expression and the list item in the corresponding
2 reduction clause is an array or array section, it is resolved to the specific procedure that is
3 elemental or only has scalar dummy arguments.
Fortran
4 If the initializer-expr value of a user-defined reduction is not known a priori, the initializer-clause
5 can be used to specify one. The content of the initializer-clause will be used as the initializer for the
6 private copies of reduction list items where the omp_priv identifier will refer to the storage to be
7 initialized. The special identifier omp_orig can also appear in the initializer-clause and it will
8 refer to the storage of the original variable to be reduced.
9 The number of times that the initializer-expr is evaluated and the order of these evaluations are
10 unspecified.
C / C++
11 If the initializer-expr is a function name with an argument list, the initializer-expr is evaluated by
12 calling the function with the specified argument list. Otherwise, the initializer-expr specifies how
13 omp_priv is declared and initialized.
C / C++
C
14 If no initializer-clause is specified, the private variables will be initialized following the rules for
15 initialization of objects with static storage duration.
C
C++
16 If no initializer-expr is specified, the private variables will be initialized following the rules for
17 default-initialization.
C++
Fortran
18 If the initializer-expr is a subroutine name with an argument list, the initializer-expr is evaluated by
19 calling the subroutine with the specified argument list.
20 If the initializer-expr is an assignment statement, the initializer-expr is evaluated by executing the
21 assignment statement.
22 If no initializer-clause is specified, the private variables will be initialized as follows:
23 • For complex, real, or integer types, the value 0 will be used.
24 • For logical types, the value .false. will be used.
25 • For derived types for which default initialization is specified, default initialization will be used.
26 • Otherwise, not specifying an initializer-clause results in unspecified behavior.
Fortran

C / C++
1 If reduction-identifier is used in a target region then a declare target directive must be specified
2 for any function that can be accessed through the combiner and initializer-expr.
C / C++
Fortran
3 If reduction-identifier is used in a target region then a declare target directive must be
4 specified for any function or subroutine that can be accessed through the combiner and
5 initializer-expr.
Fortran
6 Restrictions
7 Restrictions to the declare reduction directive are as follows:
8 • The only variables allowed in the combiner are omp_in and omp_out.
9 • The only variables allowed in the initializer-clause are omp_priv and omp_orig.
10 • If the variable omp_orig is modified in the initializer-clause, the behavior is unspecified.
11 • If execution of the combiner or the initializer-expr results in the execution of an OpenMP
12 construct or an OpenMP API call, then the behavior is unspecified.
13 • A reduction-identifier may not be re-declared in the current scope for the same type or for a type
14 that is compatible according to the base language rules.
15 • At most one initializer-clause can be specified.
16 • The typename-list must not declare new types.
C / C++
17 • A type name in a declare reduction directive cannot be a function type, an array type, a
18 reference type, or a type qualified with const, volatile or restrict.
C / C++
C
19 • If the initializer-expr is a function name with an argument list, then one of the arguments must be
20 the address of omp_priv.
C
C++
21 • If the initializer-expr is a function name with an argument list, then one of the arguments must be
22 omp_priv or the address of omp_priv.
C++

Fortran
1 • Any selectors in the designator of omp_in and omp_out can only be component selectors.
2 • If the initializer-expr is a subroutine name with an argument list, then one of the arguments must
3 be omp_priv.
4 • Any subroutine or function used in the initializer clause or combiner expression must be
5 an intrinsic function, or must have an accessible interface.
6 • Any user-defined operator, defined assignment or extended operator used in the initializer
7 clause or combiner expression must have an accessible interface.
8 • If any subroutine, function, user-defined operator, defined assignment or extended operator is
9 used in the initializer clause or combiner expression, it must be accessible to the
10 subprogram in which the corresponding reduction clause is specified.
11 • If the length type parameter is specified for a type, it must be a constant, a colon or an *.
12 • If a type with deferred or assumed length parameter is specified in a declare reduction
13 directive, no other declare reduction directive with the same type, the same kind
14 parameters and the same reduction-identifier is allowed in the same scope.
15 • Any subroutine used in the initializer clause or combiner expression must not have any
16 alternate returns appear in the argument list.
17 • If the list item in the corresponding reduction clause is an array or array section, then any
18 procedure used in the initializer clause or combiner expression must either be elemental
19 or have dummy arguments that are scalar.
20 • Any procedure called in the region of initializer-expr or combiner must be pure and may not
21 reference any host-associated variables.
Fortran
22 Cross References
23 • Properties Common to All Reduction Clauses, see Section 2.21.5.1.
24 2.21.6 Data Copying Clauses

25 This section describes the copyin clause (allowed on the parallel construct and combined
26 parallel worksharing constructs) and the copyprivate clause (allowed on the single
27 construct).
28 These two clauses support copying data values from private or threadprivate variables of an
29 implicit task or thread to the corresponding variables of other implicit tasks or threads in the team.
30 The clauses accept a comma-separated list of list items (see Section 2.1). All list items appearing in
31 a clause must be visible, according to the scoping rules of the base language. Clauses may be
32 repeated as needed, but a list item that specifies a given variable may not appear in more than one
33 clause on the same directive.

1 2.21.6.1 copyin Clause
2 Summary
3 The copyin clause provides a mechanism to copy the value of a threadprivate variable of the
4 primary thread to the threadprivate variable of each other member of the team that is executing the
5 parallel region.
6 Syntax
7 The syntax of the copyin clause is as follows:
8 copyin(list)
9 Description
C / C++
10 The copy is performed after the team is formed and prior to the execution of the associated
11 structured block. For variables of non-array type, the copy is by copy assignment. For an array of
12 elements of non-array type, each element is copied as if by assignment from an element of the array
13 of the primary thread to the corresponding element of the array of all other threads.
C / C++
C++
14 For class types, the copy assignment operator is invoked. The order in which copy assignment
15 operators for different variables of the same class type are invoked is unspecified.
C++
Fortran
16 The copy is performed, as if by assignment, after the team is formed and prior to the execution of
17 the associated structured block.
18 On entry to any parallel region, each thread’s copy of a variable that is affected by a copyin
19 clause for the parallel region will acquire the type parameters, allocation, association, and
20 definition status of the copy of the primary thread, according to the following rules:
21 • If the original list item has the POINTER attribute, each copy receives the same association
22 status as that of the copy of the primary thread as if by pointer assignment.
23 • If the original list item does not have the POINTER attribute, each copy becomes defined with
24 the value of the copy of the primary thread as if by intrinsic assignment unless the list item has a
25 type bound procedure as a defined assignment. If the original list item that does not have the
26 POINTER attribute has the allocation status of unallocated, each copy will have the same status.
27 • If the original list item is unallocated or unassociated, each copy inherits the declared type
28 parameters and the default type parameter values from the original list item.
Fortran

1 Restrictions
2 Restrictions to the copyin clause are as follows:
C / C++
3 • A list item that appears in a copyin clause must be threadprivate.
4 • A variable of class type (or array thereof) that appears in a copyin clause requires an
5 accessible, unambiguous copy assignment operator for the class type.
C / C++
Fortran
6 • A list item that appears in a copyin clause must be threadprivate. Named variables that appear
7 in a threadprivate common block may be specified: the whole common block does not need to be
8 specified.
9 • A common block name that appears in a copyin clause must be declared to be a common block
10 in the same scoping unit in which the copyin clause appears.
12 unspecified.
Fortran
13 Cross References
16 2.21.6.2 copyprivate Clause

17 Summary
18 The copyprivate clause provides a mechanism to use a private variable to broadcast a value
19 from the data environment of one implicit task to the data environments of the other implicit tasks
20 that belong to the parallel region.
21 To avoid data races, concurrent reads or updates of the list item must be synchronized with the
22 update of the list item that occurs as a result of the copyprivate clause.
23 Syntax
24 The syntax of the copyprivate clause is as follows:
25 copyprivate(list)

1 Description
2 The effect of the copyprivate clause on the specified list items occurs after the execution of the
3 structured block associated with the single construct (see Section 2.10.2), and before any of the
4 threads in the team have left the barrier at the end of the construct.
C / C++
5 In all other implicit tasks that belong to the parallel region, each specified list item becomes
6 defined with the value of the corresponding list item in the implicit task associated with the thread
7 that executed the structured block. For variables of non-array type, the definition occurs by copy
8 assignment. For an array of elements of non-array type, each element is copied by copy assignment
9 from an element of the array in the data environment of the implicit task that is associated with the
10 thread that executed the structured block to the corresponding element of the array in the data
11 environment of the other implicit tasks.
C / C++
C++
12 For class types, a copy assignment operator is invoked. The order in which copy assignment
13 operators for different variables of class type are called is unspecified.
C++
Fortran
14 If a list item does not have the POINTER attribute, then in all other implicit tasks that belong to the
15 parallel region, the list item becomes defined as if by intrinsic assignment with the value of the
16 corresponding list item in the implicit task that is associated with the thread that executed the
17 structured block. If the list item has a type bound procedure as a defined assignment, the
18 assignment is performed by the defined assignment.
19 If the list item has the POINTER attribute, then, in all other implicit tasks that belong to the
20 parallel region, the list item receives, as if by pointer assignment, the same association status of
21 the corresponding list item in the implicit task that is associated with the thread that executed the
22 structured block.
23 The order in which any final subroutines for different variables of a finalizable type are called is
24 unspecified.
Fortran
25
26 Note – The copyprivate clause is an alternative to using a shared variable for the value when
27 providing such a shared variable would be difficult (for example, in a recursion requiring a different
28 variable at each level).
29

1 Restrictions
2 Restrictions to the copyprivate clause are as follows:
3 • All list items that appear in the copyprivate clause must be either threadprivate or private in
4 the enclosing context.
5 • A list item that appears in a copyprivate clause may not appear in a private or
6 firstprivate clause on the single construct.
C++
7 • A variable of class type (or array thereof) that appears in a copyprivate clause requires an
8 accessible unambiguous copy assignment operator for the class type.
C++
Fortran
9 • A common block that appears in a copyprivate clause must be threadprivate.
10 • Pointers with the INTENT(IN) attribute may not appear in the copyprivate clause.
11 • Any list item with the ALLOCATABLE attribute must have the allocation status of allocated when
12 the intrinsic assignment is performed.
13 • If a list item is a polymorphic variable with the ALLOCATABLE attribute, the behavior is
14 unspecified.
Fortran
15 Cross References
18 • private clause, see Section 2.21.4.3.
19 2.21.7 Data-Mapping Attribute Rules, Clauses, and

20 Directives
21 This section describes how the data-mapping and data-sharing attributes of any variable referenced
22 in a target region are determined. When specified, explicit data-sharing attribute, map,
23 is_device_ptr or has_device_addr clauses on target directives determine these
24 attributes. Otherwise, the first matching rule from the following implicit data-mapping rules applies
25 for variables referenced in a target construct that are not declared in the construct and do not
26 appear in one of the data-sharing attribute, map, is_device_ptr or has_device_addr
27 clauses.
28 • If a variable appears in a to or link clause on a declare target directive that does not have a
29 device_type(nohost) clause then it is treated as if it had appeared in a map clause with a
30 map-type of tofrom.

1 • If a list item appears in a reduction, lastprivate or linear clause on a combined target
2 construct then it is treated as if it also appears in a map clause with a map-type of tofrom.
3 • If a list item appears in an in_reduction clause on a target construct then it is treated as if
4 it also appears in a map clause with a map-type of tofrom and a map-type-modifier of
5 always.
6 • If a defaultmap clause is present for the category of the variable and specifies an implicit
7 behavior other than default, the data-mapping attribute is determined by that clause.
C++
8 • If the target construct is within a class non-static member function, and a variable is an
9 accessible data member of the object for which the non-static data member function is invoked,
10 the variable is treated as if the this[:1] expression had appeared in a map clause with a
11 map-type of tofrom. Additionally, if the variable is of type pointer or reference to pointer, it is
12 also treated as if it had appeared in a map clause as a zero-length array section.
13 • If the this keyword is referenced inside a target construct within a class non-static member
14 function, it is treated as if the this[:1] expression had appeared in a map clause with a
15 map-type of tofrom.
C++
C / C++
16 • A variable that is of type pointer, but not a function pointer or (for C++) a pointer to a member
17 function, is treated as if it is the base pointer of a zero-length array section that had appeared as a
18 list item in a map clause.
C / C++
C++
19 • A variable that is of type reference to pointer, but not a function pointer or a reference to a
20 pointer to a member function is treated as if it had appeared in a map clause as a zero-length
21 array section.
C++
22 • If a variable is not a scalar then it is treated as if it had appeared in a map clause with a map-type
23 of tofrom.
Fortran
24 • If a scalar variable has the TARGET, ALLOCATABLE or POINTER attribute then it is treated as
25 if it had appeared in a map clause with a map-type of tofrom.
Fortran
26 • If none of the above rules applies then a scalar variable is not mapped, but instead has an implicit
27 data-sharing attribute of firstprivate (see Section 2.21.1.1).

1 2.21.7.1 map Clause
2 Summary
3 The map clause specifies how an original list item is mapped from the current task’s data
4 environment to a corresponding list item in the device data environment of the device identified by
5 the construct.
6 Syntax
7 The syntax of the map clause is as follows:
9 where map-type is one of the following:

10 to
11 from
12 tofrom
13 alloc
14 release
15 delete
16 and map-type-modifier is one of the following:

17 always
18 close
20 present
22 Description
23 The list items that appear in a map clause may include array sections and structure elements.
24 The map-type and map-type-modifier specify the effect of the map clause, as described below.
25 For a given construct, the effect of a map clause with the to, from, or tofrom map-type is
26 ordered before the effect of a map clause with the alloc, release, or delete map-type. If a
27 map clause with a present map-type-modifier appears in a map clause, then the effect of the
28 clause is ordered before all other map clauses that do not have the present modifier.
29 If the mapper map-type-modifier is not present, the behavior is as if the mapper(default)
30 modifier was specified. The map behavior of a list item in a map clause is modified by a visible
31 user-defined mapper (see Section 2.21.7.4) if the mapper has the same mapper-identifier as the
32 mapper-identifier in the mapper map-type-modifier and is specified for a type that matches the
33 type of the list item. The effect of the mapper is to remove the list item from the map clause, if the

1 present modifier does not also appear, and to apply the clauses specified in the declared mapper
2 to the construct on which the map clause appears. In the clauses applied by the mapper, references
3 to var are replaced with references to the list item and the map-type is replaced with a final map
4 type that is determined according to the rules of map-type decay (see Section 2.21.7.4).
5 A list item that is an array or array section of a type for which a user-defined mapper exists is
6 mapped as if the map type decays to alloc, release, or delete, and then each array element
7 is mapped with the original map type, as if by a separate construct, according to the mapper.
8 A list item in a map clause may reference iterators defined by an iterators-definition of an
9 iterator modifier.
10 If a list item in a map clause is a variable of structure type then it is treated as if each structure
11 element contained in the variable is a list item in the clause.
12 If a list item in a map clause is a structure element then all other structure elements of the
13 containing structure variable form a structure sibling list. The map clause and the structure sibling
14 list are associated with the same construct. If a corresponding list item of the structure sibling list
15 item is present in the device data environment when the construct is encountered then:
16 • If the structure sibling list item does not appear in a map clause on the construct then:
17 – If the construct is a target, target data, or target enter data construct then the
18 structure sibling list item is treated as if it is a list item in a map clause on the construct with a
19 map-type of alloc.
20 – If the construct is target exit data construct, then the structure sibling list item is treated
21 as if it is a list item in a map clause on the construct with a map-type of release.
22 • If the map clause in which the structure element appears as a list item has a map-type of
23 delete and the structure sibling list item does not appear as a list item in a map clause on the
24 construct with a map-type of delete then the structure sibling list item is treated as if it is a list
25 item in a map clause on the construct with a map-type of delete.
Fortran
26 If a component of a derived type variable is a list item that results from the above rules for mapped
27 structures and mapped structure elements, and it does not explicitly appear as another list item or as
28 the base expression of another list item in a map clause on the construct, then:
29 • If it has the POINTER attribute, the map clause treats its association status as if it is undefined;
30 and
31 • If it has the ALLOCATABLE attribute and an allocated allocation status, and it is present in the
32 device data environment when the construct is encountered, the map clause may treat its
33 allocation status as if it is unallocated if the corresponding component does not have allocated
34 storage.
Fortran

1 Given item1 is a list item in a map clause, and item2 is another list item in a map clause on the same
2 construct, if item2 has a base pointer that is, or is part of, item1 , then:
3 • If the construct is a target, target data, or target enter data construct, then, on
4 entry to the corresponding region, the effect of the map clause on item1 is ordered to occur
5 before the effect of the map clause on item2 .
6 • If the construct is a target, target data, or target exit data construct, then, on exit
7 from the corresponding region, the effect of the map clause on item2 is ordered to occur before
8 the effect of the map clause on item1 .
Fortran
9 If a list item in a map clause is an associated pointer and the pointer is not the base pointer of
10 another list item in a map clause on the same construct, then it is treated as if its pointer target is
11 implicitly mapped in the same clause. For the purposes of the map clause, the mapped pointer
12 target is treated as if its base pointer is the associated pointer.
Fortran
13 If a list item in a map clause has a base pointer, a pointer variable is present in the device data
14 environment that corresponds to the base pointer when the effect of the map clause occurs, and the
15 corresponding pointer or the corresponding list item is created in the device data environment on
16 entry to the construct, then:
C / C++
17 1. The corresponding pointer variable is assigned an address such that the corresponding list item
18 can be accessed through the pointer in a target region.
C / C++
Fortran
19 1. The corresponding pointer variable is associated with a pointer target that has the same rank and
20 bounds as the pointer target of the original pointer, such that the corresponding list item can be
21 accessed through the pointer in a target region.
Fortran
22 2. The corresponding pointer variable becomes an attached pointer for the corresponding list item.
23 3. If the original base pointer and the corresponding attached pointer share storage, then the
24 original list item and the corresponding list item must share storage.
C++
25 If a lambda is mapped explicitly or implicitly, variables that are captured by the lambda behave as
26 follows:
27 • The variables that are of pointer type are treated as if they had appeared in a map clause as
28 zero-length array sections; and
29 • The variables that are of reference type are treated as if they had appeared in a map clause.

1 If a member variable is captured by a lambda in class scope, and the lambda is later mapped
2 explicitly or implicitly with its full static type, the this pointer is treated as if it had appeared on a
3 map clause.
C++
4 The original and corresponding list items may share storage such that writes to either item by one
5 task followed by a read or write of the other item by another task without intervening
6 synchronization can result in data races. They are guaranteed to share storage if the map clause
7 appears on a target construct that corresponds to an inactive target region, or if it appears on
8 a target data, target enter data, or target exit data construct that applies to the
9 device data environment of the host device.
10 If a map clause appears on a target, target data, target enter data or
11 target exit data construct with a present map-type-modifier then on entry to the region if
12 the corresponding list item does not appear in the device data environment then an error occurs and
13 the program terminates.
14 If a map clause appears on a target, target data, or target enter data construct then
15 on entry to the region the following sequence of steps occurs as if they are performed as a single
16 atomic operation:
17 1. If a corresponding list item of the original list item is not present in the device data environment,
18 then:
19 a) A new list item with language-specific attributes is derived from the original list item and
20 created in the device data environment;
21 b) The new list item becomes the corresponding list item of the original list item in the device
22 data environment;
23 c) The corresponding list item has a reference count that is initialized to zero; and
24 d) The value of the corresponding list item is undefined;
25 2. If the reference count of the corresponding list item was not already incremented because of the
26 effect of a map clause on the construct then:
27 a) The reference count is incremented by one;
28 3. If the reference count of the corresponding list item is one or the always map-type-modifier is
29 present, and if the map-type is to or tofrom, then:
C / C++
30 a) For each part of the list item that is an attached pointer, that part of the corresponding list
31 item will have the value that it had at the point immediately prior to the effect of the map
32 clause; and
C / C++

Fortran
1 a) For each part of the list item that is an attached pointer, that part of the corresponding list
2 item, if associated, will be associated with the same pointer target that it was associated with
3 at the point immediately prior to the effect of the map clause.
Fortran
4 b) For each part of the list item that is not an attached pointer, the value of that part of the
5 original list item is assigned to that part of the corresponding list item.
6
7 Note – If the effect of the map clauses on a construct would assign the value of an original list
8 item to a corresponding list item more than once, then an implementation is allowed to ignore
9 additional assignments of the same value to the corresponding list item.
10
11 In all cases on entry to the region, concurrent reads or updates of any part of the corresponding list
12 item must be synchronized with any update of the corresponding list item that occurs as a result of
13 the map clause to avoid data races.
14 If the map clause appears on a target, target data, or target exit data construct and a
15 corresponding list item of the original list item is not present in the device data environment on exit
16 from the region then the list item is ignored. Alternatively, if the map clause appears on a target,
17 target data, or target exit data construct and a corresponding list item of the original list
18 item is present in the device data environment on exit from the region, then the following sequence
19 of steps occurs as if performed as a single atomic operation:
20 1. If the map-type is not delete and the reference count of the corresponding list item is finite
21 and was not already decremented because of the effect of a map clause on the construct then:
22 a) The reference count of the corresponding list item is decremented by one;
23 2. If the map-type is delete and the reference count of the corresponding list item is finite then:
24 a) The reference count of the corresponding list item is set to zero;
25 3. If the map-type is from or tofrom and if the reference count of the corresponding list item is
26 zero or the always map-type-modifier is present then:
C / C++
27 a) For each part of the list item that is an attached pointer, that part of the original list item will
28 have the value that it had at the point immediately prior to the effect of the map clause; and
C / C++
Fortran
29 a) For each part of the list item that is an attached pointer, that part of the original list item, if
30 associated, will be associated with the same pointer target with which it was associated at
31 the point immediately prior to the effect of the map clause; and
Fortran

1 b) For each part of the list item that is not an attached pointer, the value of that part of the
2 corresponding list item is assigned to that part of the original list item; and
3 4. If the reference count of the corresponding list item is zero then the corresponding list item is
4 removed from the device data environment.
5
6 Note – If the effect of the map clauses on a construct would assign the value of a corresponding
7 list item to an original list item more than once, then an implementation is allowed to ignore
8 additional assignments of the same value to the original list item.
9
10 In all cases on exit from the region, concurrent reads or updates of any part of the original list item
11 must be synchronized with any update of the original list item that occurs as a result of the map
12 clause to avoid data races.
13 If a single contiguous part of the original storage of a list item with an implicit data-mapping
14 attribute has corresponding storage in the device data environment prior to a task encountering the
15 construct that is associated with the map clause, only that part of the original storage will have
16 corresponding storage in the device data environment as a result of the map clause.
17 If a list item with an implicit data-mapping attribute does not have any corresponding storage in the
18 device data environment prior to a task encountering the construct associated with the map clause,
19 and one or more contiguous parts of the original storage are either list items or base pointers to list
20 items that are explicitly mapped on the construct, only those parts of the original storage will have
21 corresponding storage in the device data environment as a result of the map clauses on the
22 construct.
C / C++
23 If a new list item is created then a new list item of the same type, with automatic storage duration, is
24 allocated for the construct. The size and alignment of the new list item are determined by the static
25 type of the variable. This allocation occurs if the region references the list item in any statement.
26 Initialization and assignment of the new list item are through bitwise copy.
C / C++
Fortran
27 If a new list item is created then a new list item of the same type, type parameter, and rank is
28 allocated. The new list item inherits all default values for the type parameters from the original list
29 item. The value of the new list item becomes that of the original list item in the map initialization
30 and assignment.
31 If the allocation status of an original list item that has the ALLOCATABLE attribute is changed
32 while a corresponding list item is present in the device data environment, the allocation status of the
33 corresponding list item is unspecified until the list item is again mapped with an always modifier
34 on entry to a target, target data or target enter data region.
Fortran

1 The map-type determines how the new list item is initialized.
2 If a map-type is not specified, the map-type defaults to tofrom.
3 The close map-type-modifier is a hint to the runtime to allocate memory close to the target device.

5 The target-map event occurs when a thread maps data to or from a target device.
6 The target-data-op-begin event occurs before a thread initiates a data operation on a target device.
7 The target-data-op-end event occurs after a thread initiates a data operation on a target device.
8 Tool Callbacks
9 A thread dispatches a registered ompt_callback_target_map or
10 ompt_callback_target_map_emi callback for each occurrence of a target-map event in
11 that thread. The callback occurs in the context of the target task and has type signature
12 ompt_callback_target_map_t or ompt_callback_target_map_emi_t,
13 respectively.
14 A thread dispatches a registered ompt_callback_target_data_op_emi callback with
15 ompt_scope_begin as its endpoint argument for each occurrence of a target-data-op-begin
17 ompt_callback_target_data_op_emi callback with ompt_scope_end as its endpoint
18 argument for each occurrence of a target-data-op-end event in that thread. These callbacks have
19 type signature ompt_callback_target_data_op_emi_t.
20 A thread dispatches a registered ompt_callback_target_data_op callback for each
21 occurrence of a target-data-op-end event in that thread. The callback occurs in the context of the
22 target task and has type signature ompt_callback_target_data_op_t.
23 Restrictions
24 Restrictions to the map clause are as follows:
25 • Each of the map-type-modifier modifiers can appear at most once in the map clause.
C / C++
26 • List items of the map clauses on the same construct must not share original storage unless they
27 are the same lvalue expression or array section.
C / C++
28 • If a list item is an array section, it must specify contiguous storage.
29 • If an expression that is used to form a list item in a map clause contains an iterator identifier, the
30 list item instances that would result from different values of the iterator must not have the same
31 containing array and must not have base pointers that share original storage.

1 • If multiple list items are explicitly mapped on the same construct and have the same containing
2 array or have base pointers that share original storage, and if any of the list items do not have
3 corresponding list items that are present in the device data environment prior to a task
4 encountering the construct, then the list items must refer to the same array elements of either the
5 containing array or the implicit array of the base pointers.
6 • If any part of the original storage of a list item with an explicit data-mapping attribute has
7 corresponding storage in the device data environment prior to a task encountering the construct
8 associated with the map clause, all of the original storage must have corresponding storage in the
9 device data environment prior to the task encountering the construct.
10 • If an array appears as a list item in a map clause, multiple parts of the array have corresponding
11 storage in the device data environment prior to a task encountering the construct associated with
12 the map clause, and the corresponding storage for those parts was created by maps from more
13 than one earlier construct, the behavior is unspecified.
14 • If a list item is an element of a structure, and a different element of the structure has a
15 corresponding list item in the device data environment prior to a task encountering the construct
16 associated with the map clause, then the list item must also have a corresponding list item in the
17 device data environment prior to the task encountering the construct.
18 • A list item must have a mappable type.
19 • Threadprivate variables cannot appear in a map clause.
20 • If a mapper map-type-modifier appears in a map clause, the type on which the specified mapper
21 operates must match the type of the list items in the clause.
22 • Memory spaces and memory allocators cannot appear as a list item in a map clause.
C++
23 • If the type of a list item is a reference to a type T then the reference in the device data
24 environment is initialized to refer to the object in the device data environment that corresponds to
25 the object referenced by the list item. If mapping occurs, it occurs as though the object were
26 mapped through a pointer with an array section of type T and length one.
27 • No type mapped through a reference can contain a reference to its own type, or any references to
28 types that could produce a cycle of references.
29 • If a list item is a lambda, any pointers and references captured by the lambda must have the
30 corresponding list item in the device data environment prior to the task encountering the
31 construct.
C++

C / C++
1 • A list item cannot be a variable that is a member of a structure of a union type.
2 • A bit-field cannot appear in a map clause.
3 • A pointer that has a corresponding attached pointer must not be modified for the duration of the
4 lifetime of the list item to which the corresponding pointer is attached in the device data
5 environment.
C / C++
Fortran
6 • List items of the map clauses on the same construct must not share original storage unless they
7 are the same variable or array section.
8 • If a list item of a map clause is an allocatable variable or is the subobject of an allocatable
9 variable, the original allocatable variable may not be allocated, deallocated or reshaped while the
10 corresponding allocatable variable has allocated storage.
11 • A pointer that has a corresponding attached pointer and is associated with a given pointer target
12 must not become associated with a different pointer target for the duration of the lifetime of the
13 list item to which the corresponding pointer is attached in the device data environment.
14 • If an array section is mapped and the size of the section is smaller than that of the whole array,
15 the behavior of referencing the whole array in the target region is unspecified.
16 • A list item must not be a whole array of an assumed-size array.
Fortran
17 Cross References
20 • declare mapper directive, see Section 2.21.7.4.
23 • ompt_callback_target_map_t or ompt_callback_target_map_emi_t callback
24 type, see Section 4.5.2.27.

C / C++
1 2.21.7.2 Pointer Initialization for Device Data Environments

2 This section describes how a pointer that is predetermined firstprivate for a target construct may
3 be assigned an initial value that is the address of an object that exists in a device data environment
4 and corresponds to a matching mapped list item.
5 All previously mapped list items that have corresponding storage in a given device data
6 environment constitute the set of currently mapped list items. If a currently mapped list item has a
7 base pointer, the base address of the currently mapped list item is the value of its base pointer.
8 Otherwise, the base address is determined by the following steps:
9 1. Let X refer to the currently mapped list item.
10 2. If X refers to an array section or array element, let X refer to its base array.
11 3. If X refers to a structure element, let X refer to its containing structure and return to step 2.
12 4. The base address for the currently mapped list item is the address of X.
13 Additionally, each currently mapped list item has a starting address and an ending address. The
14 starting address is the address of the first storage location associated with the list item, and the
15 ending address is the address of the storage location that immediately follows the last storage
16 location associated with the list item.
17 The mapped address range of the currently mapped list item is the range of addresses that starts
18 from the starting address and ends with the ending address. The extended address range of the
19 currently mapped list item is the range of addresses that starts from the minimum of the starting
20 address and the base address and that ends with the maximum of the ending address and the base
21 address.
22 If the value of a given pointer is in the mapped address range of a currently mapped list item then
23 that currently mapped list item is a matching mapped list item. Otherwise, if the value of the
24 pointer is in the extended address range of a currently mapped list item then that currently mapped
25 list item is a matching mapped list item.
26 If multiple matching mapped list items are found and they all appear as part of the same containing
27 structure, the one that has the lowest starting address is treated as the sole matching mapped list
28 item. Otherwise, if multiple matching mapped list items are found then the behavior is unspecified.
29 If a matching mapped list item is found, the initial value that is assigned to the pointer is a device
30 address such that the corresponding list item in the device data environment can be accessed
31 through the pointer in a target region.
32 If a matching mapped list item is not found, the assigned initial value of the pointer is NULL unless
33 otherwise specified (see Section 2.5.1).

1 Cross References
2 • requires directive, see Section 2.5.1.
C / C++
5 2.21.7.3 defaultmap Clause

6 Summary
7 The defaultmap clause explicitly determines the data-mapping attributes of variables that are
8 referenced in a target construct for which the data-mapping attributes would otherwise be
9 implicitly determined (see Section 2.21.7).
10 Syntax
11 The syntax of the defaultmap clause is as follows:
13 Where implicit-behavior is one of:

14 alloc
15 to
16 from
17 tofrom
18 firstprivate
19 none
20 default
21 present
C / C++
22 and variable-category is one of:
23 scalar
24 aggregate
25 pointer
C / C++

Fortran
1 and variable-category is one of:
2 scalar
3 aggregate
4 allocatable
5 pointer
Fortran
6 Description
7 The defaultmap clause sets the implicit data-mapping attribute for all variables referenced in the
8 construct. If variable-category is specified, the effect of the defaultmap clause is as follows:
9 • If variable-category is scalar, all scalar variables of non-pointer type or all non-pointer
10 non-allocatable scalar variables that have an implicitly determined data-mapping or data-sharing
11 attribute will have a data-mapping or data-sharing attribute specified by implicit-behavior.
12 • If variable-category is aggregate or allocatable, all aggregate or allocatable variables
13 that have an implicitly determined data-mapping or data-sharing attribute will have a
14 data-mapping or data-sharing attribute specified by implicit-behavior.
15 • If variable-category is pointer, all variables of pointer type or with the POINTER attribute
16 that have implicitly determined data-mapping or data-sharing attributes will have a data-mapping
17 or data-sharing attribute specified by implicit-behavior.
18 If no variable-category is specified in the clause then implicit-behavior specifies the implicitly
19 determined data-mapping or data-sharing attribute for all variables referenced in the construct. If
20 implicit-behavior is none, each variable referenced in the construct that does not have a
21 predetermined data-sharing attribute and does not appear in a to or link clause on a declare
22 target directive must be listed in a data-mapping attribute clause, a data-sharing attribute clause
23 (including a data-sharing attribute clause on a combined construct where target is one of the
24 constituent constructs), an is_device_ptr clause or a has_device_addr clause. If
25 implicit-behavior is default, then the clause has no effect for the variables in the category
26 specified by variable-category. If implicit-behavior is present, each variable referenced in the
27 construct in the category specified by variable-category is treated as if it had been listed in a map
28 clause with the map-type of alloc and map-type-modifier of present.
29 2.21.7.4 declare mapper Directive

30 Summary
31 The declare mapper directive declares a user-defined mapper for a given type, and may define a
32 mapper-identifier that can be used in a map clause. The declare mapper directive is a
33 declarative directive.

1 Syntax
C / C++
2 The syntax of the declare mapper directive is as follows:
3 #pragma omp declare mapper([mapper-identifier:]type var) \
C / C++
Fortran
5 The syntax of the declare mapper directive is as follows:
6 !$omp declare mapper([mapper-identifier:] type :: var) &
7 [clause[ [,] clause] ... ]
Fortran
8 where:
9 • mapper-identifier is a base language identifier or default
10 • type is a valid type in scope
11 • var is a valid base language identifier
12 • clause is map([[map-type-modifier[,] [map-type-modifier[,] ...]] map-type: ] list), where
13 map-type is one of the following:
14 – alloc
15 – to
16 – from
17 – tofrom
18 and where map-type-modifier is one of the following:
19 – always
20 – close
21 Description
22 User-defined mappers can be defined using the declare mapper directive. The type and an
23 optional mapper-identifier uniquely identify the mapper for use in a map clause or motion clause
24 later in the program. The visibility and accessibility of this declaration are the same as those of a
25 variable declared at the same location in the program.
26 If mapper-identifier is not specified, the behavior is as if mapper-identifier is default.
27 The variable declared by var is available for use in all map clauses on the directive, and no part of
28 the variable to be mapped is mapped by default.

1 The default mapper for all types T, designated by the predefined mapper-identifier default, is
2 defined as if by the following directive, unless a user-defined mapper is specified for that type.
C / C++
3 #pragma omp declare mapper(T v) map(tofrom: v)
C / C++
Fortran
4 !$omp declare mapper(T :: v) map(tofrom: v)
Fortran
5 A declare mapper directive that uses the default mapper-identifier overrides the predefined
6 default mapper for the given type, making it the default mapper for variables of that type.
7 The effect that a user-defined mapper has on either a map clause that maps a list item of the given
8 type or a motion clause that invokes the mapper and updates a list item of the given type is to
9 replace the map or update with a set of map clauses or updates derived from the map clauses
10 specified by the mapper, as described in Section 2.21.7.1 and Section 2.14.6.
11 The final map types that a mapper applies for a map clause that maps a list item of the given type
12 are determined according to the rules of map-type decay, defined according to Table 2.13.
13 Table 2.13 shows the final map type that is determined by the combination of two map types, where
14 the rows represent the map type specified by the mapper and the columns represent the map type
15 specified by a map clause that invokes the mapper. For a target exit data construct that
16 invokes a mapper with a map clause that has the from map type, if a map clause in the mapper
17 specifies an alloc or to map type then the result is a release map type.
18 A list item in a map clause that appears on a declare mapper directive may include array
19 sections.
20 All map clauses that are introduced by a mapper are further subject to mappers that are in scope,
21 except a map clause with list item var maps var without invoking a mapper.
TABLE 2.13: Map-Type Decay of Map Type Combinations
alloc to from tofrom release delete

alloc alloc alloc alloc (release) alloc release delete
to alloc to alloc (release) to release delete
from alloc alloc from from release delete
tofrom alloc to from tofrom release delete

C++
1 The declare mapper directive can also appear at locations in the program at which a static data
2 member could be declared. In this case, the visibility and accessibility of the declaration are the
3 same as those of a static data member declared at the same location in the program.
C++
4 Restrictions
5 Restrictions to the declare mapper directive are as follows:
6 • No instance of type can be mapped as part of the mapper, either directly or indirectly through
7 another type, except the instance var that is passed as the list item. If a set of
8 declare mapper directives results in a cyclic definition then the behavior is unspecified.
9 • The type must not declare a new type.
10 • At least one map clause that maps var or at least one element of var is required.
11 • List items in map clauses on the declare mapper directive may only refer to the declared
12 variable var and entities that could be referenced by a procedure defined at the same location.
13 • Each map-type-modifier can appear at most once on the map clause.
14 • Multiple declare mapper directives that specify the same mapper-identifier for the same type
15 or for compatible types, according to the base language rules, may not appear in the same scope.
C
16 • type must be a struct or union type.
C
C++
17 • type must be a struct, union, or class type.
C++
Fortran
18 • type must not be an intrinsic type or an abstract type.
Fortran
19 Cross References

1 2.22 Nesting of Regions
2 This section describes a set of restrictions on the nesting of regions. The restrictions on nesting are
3 as follows:
4 • A loop region that binds to a parallel region or a worksharing region may not be closely
5 nested inside a worksharing, loop, task, taskloop, critical, ordered, atomic, or
6 masked region.
7 • A barrier region may not be closely nested inside a worksharing, loop, task, taskloop,
8 critical, ordered, atomic, or masked region.
9 • A masked region may not be closely nested inside a worksharing, loop, atomic, task, or
10 taskloop region.
11 • An ordered region that corresponds to an ordered construct without any clause or with the
12 threads or depend clause may not be closely nested inside a critical, ordered, loop,
13 atomic, task, or taskloop region.
14 • An ordered region that corresponds to an ordered construct without the simd clause
15 specified must be closely nested inside a worksharing-loop region.
16 • An ordered region that corresponds to an ordered construct with the simd clause specified
17 must be closely nested inside a simd or worksharing-loop SIMD region.
18 • An ordered region that corresponds to an ordered construct with both the simd and
19 threads clauses must be closely nested inside a worksharing-loop SIMD region or closely
20 nested inside a worksharing-loop and simd region.
21 • A critical region may not be nested (closely or otherwise) inside a critical region with
22 the same name. This restriction is not sufficient to prevent deadlock.
23 • OpenMP constructs may not be encountered during execution of an atomic region.
24 • The only OpenMP constructs that can be encountered during execution of a simd (or
25 worksharing-loop SIMD) region are the atomic construct, the loop construct without a
26 defined binding region, the simd construct and the ordered construct with the simd clause.
27 • If a target update, target data, target enter data, or target exit data
28 construct is encountered during execution of a target region, the behavior is unspecified.
29 • If a target construct is encountered during execution of a target region and a device
30 clause in which the ancestor device-modifier appears is not present on the construct, the
31 behavior is unspecified.
32 • A teams region must be strictly nested either within the implicit parallel region that surrounds
33 the whole OpenMP program or within a target region. If a teams construct is nested within
34 a target construct, that target construct must contain no statements, declarations or
35 directives outside of the teams construct.

1 • distribute, distribute simd, distribute parallel worksharing-loop, distribute parallel
2 worksharing-loop SIMD, loop, parallel regions, including any parallel regions arising
3 from combined constructs, omp_get_num_teams() regions, and omp_get_team_num()
4 regions are the only OpenMP regions that may be strictly nested inside the teams region.
5 • A loop region that binds to a teams region must be strictly nested inside a teams region.
6 • A distribute region must be strictly nested inside a teams region.
7 • If construct-type-clause is taskgroup, the cancel construct must be closely nested inside a
8 task construct and the cancel region must be closely nested inside a taskgroup region. If
9 construct-type-clause is sections, the cancel construct must be closely nested inside a
10 sections or section construct. Otherwise, the cancel construct must be closely nested
11 inside an OpenMP construct that matches the type specified in construct-type-clause of the
12 cancel construct.
13 • A cancellation point construct for which construct-type-clause is taskgroup must be
14 closely nested inside a task construct, and the cancellation point region must be closely
15 nested inside a taskgroup region. A cancellation point construct for which
16 construct-type-clause is sections must be closely nested inside a sections or section
17 construct. Otherwise, a cancellation point construct must be closely nested inside an
18 OpenMP construct that matches the type specified in construct-type-clause.
19 • The only constructs that may be encountered inside a region that corresponds to a construct with
20 an order clause that specifies concurrent are the loop construct, the parallel
21 construct, the simd construct, and combined constructs for which the first construct is a
24 not contain calls to procedures that contain OpenMP directives or calls to the OpenMP Runtime
25 API.
26 • A scope region may not be closely nested inside a worksharing, loop, task, taskloop,
27 critical, ordered, atomic, or masked region.

1 3 Runtime Library Routines
2 This chapter describes the OpenMP API runtime library routines and queryable runtime states. In
3 this chapter, true and false are used as generic terms to simplify the description of the routines.
C / C++
4 true means a non-zero integer value and false means an integer value of zero.
C / C++
Fortran
5 true means a logical value of .TRUE. and false means a logical value of .FALSE..
Fortran
Fortran
6 Restrictions
7 The following restrictions apply to all OpenMP runtime library routines:
8 • OpenMP runtime library routines may not be called from PURE or ELEMENTAL procedures.
9 • OpenMP runtime library routines may not be called in DO CONCURRENT constructs.
Fortran
10 3.1 Runtime Library Definitions

11 For each base language, a compliant implementation must supply a set of definitions for the
12 OpenMP API runtime library routines and the special data types of their parameters. The set of
13 definitions must contain a declaration for each OpenMP API runtime library routine and variable
14 and a definition of each required data type listed below. In addition, each set of definitions may
15 specify other implementation specific values.
C / C++
16 The library routines are external functions with “C” linkage.
17 Prototypes for the C/C++ runtime library routines described in this chapter shall be provided in a
18 header file named omp.h. This file also defines the following:
CHAPTER 3. RUNTIME LIBRARY ROUTINES 365

1 • The type omp_allocator_handle_t, which must be an implementation-defined (for C++
2 possibly scoped) enum type with at least the omp_null_allocator enumerator with the
3 value zero and an enumerator for each predefined memory allocator in Table 2.10;
4 • omp_atv_default, which is an instance of a type compatible with omp_uintptr_t with
5 the value -1;
6 • The type omp_control_tool_result_t;
7 • The type omp_control_tool_t;
8 • The type omp_depend_t;
9 • The type omp_event_handle_t, which must be an implementation-defined (for C++
10 possibly scoped) enum type;
11 • The type omp_intptr_t, which is a signed integer type that is at least the size of a pointer on
12 any device;
13 • The type omp_interop_t, which must be an implementation-defined integral or pointer type;
14 • The type omp_interop_fr_t, which must be an implementation-defined enum type with
15 enumerators named omp_ifr_name where name is a foreign runtime name that is defined in
16 the OpenMP Additional Definitions document;
17 • The type omp_lock_hint_t (deprecated);
18 • The type omp_lock_t;
19 • The type omp_memspace_handle_t, which must be an implementation-defined (for C++
20 possibly scoped) enum type with an enumerator for at least each predefined memory space in
21 Table 2.8;
22 • The type omp_nest_lock_t;
23 • The type omp_pause_resource_t;
24 • The type omp_proc_bind_t;
25 • The type omp_sched_t;
26 • The type omp_sync_hint_t; and
27 • The type omp_uintptr_t, which is an unsigned integer type capable of holding a pointer on
28 any device.
C / C++

C++
1 The OpenMP enumeration types provided in the omp.h header file shall not be scoped
2 enumeration types unless explicitly allowed.
3 The omp.h header file also defines a class template that models the Allocator concept in the
4 omp::allocator namespace for each predefined memory allocator in Table 2.10 for which the
5 name includes neither the omp_ prefix nor the _alloc suffix.
C++
Fortran
6 The OpenMP Fortran API runtime library routines are external procedures. The return values of
7 these routines are of default kind, unless otherwise specified.
8 Interface declarations for the OpenMP Fortran runtime library routines described in this chapter
9 shall be provided in the form of a Fortran module named omp_lib or a Fortran include file
10 named omp_lib.h. Whether the omp_lib.h file provides derived-type definitions or those
11 routines that require an explicit interface is implementation defined. Whether the include file or
12 the module file (or both) is provided is also implementation defined.
13 These files also define the following:
14 • The default integer named constant omp_allocator_handle_kind;
15 • An integer named constant of kind omp_allocator_handle_kind for each predefined
16 memory allocator in Table 2.10;
17 • The default integer named constant omp_alloctrait_key_kind;
18 • The default integer named constant omp_alloctrait_val_kind;
19 • The default integer named constant omp_control_tool_kind;
20 • The default integer named constant omp_control_tool_result_kind;
21 • The default integer named constant omp_depend_kind;
22 • The default integer named constant omp_event_handle_kind;
23 • The default integer named constant omp_interop_kind;
24 • The default integer named constant omp_interop_fr_kind;
25 • An integer named constant omp_ifr_name of kind omp_interop_fr_kind for each name
26 that is a foreign runtime name that is defined in the OpenMP Additional Definitions document;
27 • The default integer named constant omp_lock_hint_kind (deprecated);
28 • The default integer named constant omp_lock_kind;
29 • The default integer named constant omp_memspace_handle_kind;

1 • An integer named constant of kind omp_memspace_handle_kind for each predefined
2 memory space in Table 2.8;
3 • The default integer named constant omp_nest_lock_kind;
4 • The default integer named constant omp_pause_resource_kind;
5 • The default integer named constant omp_proc_bind_kind;
6 • The default integer named constant omp_sched_kind;
7 • The default integer named constant omp_sync_hint_kind; and
8 • The default integer named constant openmp_version with a value yyyymm where yyyy and
9 mm are the year and month designations of the version of the OpenMP Fortran API that the
10 implementation supports; this value matches that of the C preprocessor macro _OPENMP, when
11 a macro preprocessor is supported (see Section 2.2).
12 Whether any of the OpenMP runtime library routines that take an argument are extended with a
13 generic interface so arguments of different KIND type can be accommodated is implementation
14 defined.
Fortran
15 3.2 Thread Team Routines

16 This section describes routines that affect and monitor thread teams in the current contention group.
17 3.2.1 omp_set_num_threads
18 Summary
19 The omp_set_num_threads routine affects the number of threads to be used for subsequent
20 parallel regions that do not specify a num_threads clause, by setting the value of the first
21 element of the nthreads-var ICV of the current task.
22 Format
C / C++
23 void omp_set_num_threads(int num_threads);
C / C++
Fortran
24 subroutine omp_set_num_threads(num_threads)
25 integer num_threads
Fortran

1 Constraints on Arguments
2 The value of the argument passed to this routine must evaluate to a positive integer, or else the
3 behavior of this routine is implementation defined.
4 Binding
5 The binding task set for an omp_set_num_threads region is the generating task.
6 Effect
7 The effect of this routine is to set the value of the first element of the nthreads-var ICV of the
8 current task to the value specified in the argument.
9 Cross References
10 • nthreads-var ICV, see Section 2.4.
11 • parallel construct and num_threads clause, see Section 2.6.
12 • Determining the number of threads for a parallel region, see Section 2.6.1.
16 3.2.2 omp_get_num_threads
17 Summary
18 The omp_get_num_threads routine returns the number of threads in the current team.
19 Format
C / C++
20 int omp_get_num_threads(void);
C / C++
Fortran
21 integer function omp_get_num_threads()
Fortran
22 Binding
23 The binding region for an omp_get_num_threads region is the innermost enclosing
24 parallel region.
25 Effect
26 The omp_get_num_threads routine returns the number of threads in the team that is executing
27 the parallel region to which the routine region binds. If called from the sequential part of a
28 program, this routine returns 1.

1 Cross References
7 3.2.3 omp_get_max_threads
8 Summary
9 The omp_get_max_threads routine returns an upper bound on the number of threads that
10 could be used to form a new team if a parallel construct without a num_threads clause were
11 encountered after execution returns from this routine.
12 Format
C / C++
13 int omp_get_max_threads(void);
C / C++
Fortran
14 integer function omp_get_max_threads()
Fortran
15 Binding
16 The binding task set for an omp_get_max_threads region is the generating task.
17 Effect
18 The value returned by omp_get_max_threads is the value of the first element of the
19 nthreads-var ICV of the current task. This value is also an upper bound on the number of threads
20 that could be used to form a new team if a parallel region without a num_threads clause were
21 encountered after execution returns from this routine.
22
23 Note – The return value of the omp_get_max_threads routine can be used to allocate
24 sufficient storage dynamically for all threads in the team formed at the subsequent active
25 parallel region.
26

1 Cross References
9 3.2.4 omp_get_thread_num
10 Summary
11 The omp_get_thread_num routine returns the thread number, within the current team, of the
12 calling thread.
13 Format
C / C++
14 int omp_get_thread_num(void);
C / C++
Fortran
15 integer function omp_get_thread_num()
Fortran
16 Binding
17 The binding thread set for an omp_get_thread_num region is the current team. The binding
18 region for an omp_get_thread_num region is the innermost enclosing parallel region.
19 Effect
20 The omp_get_thread_num routine returns the thread number of the calling thread, within the
21 team that is executing the parallel region to which the routine region binds. The thread number
22 is an integer between 0 and one less than the value returned by omp_get_num_threads,
23 inclusive. The thread number of the primary thread of the team is 0. The routine returns 0 if it is
24 called from the sequential part of a program.
25
26 Note – The thread number may change during the execution of an untied task. The value returned
27 by omp_get_thread_num is not generally useful during the execution of such a task region.
28

1 Cross References
8 3.2.5 omp_in_parallel
9 Summary
10 The omp_in_parallel routine returns true if the active-levels-var ICV is greater than zero;
11 otherwise, it returns false.
12 Format
C / C++
13 int omp_in_parallel(void);
C / C++
Fortran
14 logical function omp_in_parallel()
Fortran
15 Binding
16 The binding task set for an omp_in_parallel region is the generating task.
17 Effect
18 The effect of the omp_in_parallel routine is to return true if the current task is enclosed by an
19 active parallel region, and the parallel region is enclosed by the outermost initial task
20 region on the device; otherwise it returns false.
21 Cross References
22 • active-levels-var, see Section 2.4.

1 3.2.6 omp_set_dynamic
2 Summary
3 The omp_set_dynamic routine enables or disables dynamic adjustment of the number of
4 threads available for the execution of subsequent parallel regions by setting the value of the
5 dyn-var ICV.
6 Format
C / C++
7 void omp_set_dynamic(int dynamic_threads);
C / C++
Fortran
8 subroutine omp_set_dynamic(dynamic_threads)
9 logical dynamic_threads
Fortran
10 Binding
11 The binding task set for an omp_set_dynamic region is the generating task.
12 Effect
13 For implementations that support dynamic adjustment of the number of threads, if the argument to
14 omp_set_dynamic evaluates to true, dynamic adjustment is enabled for the current task;
15 otherwise, dynamic adjustment is disabled for the current task. For implementations that do not
16 support dynamic adjustment of the number of threads, this routine has no effect: the value of
17 dyn-var remains false.
18 Cross References
24 3.2.7 omp_get_dynamic
25 Summary
26 The omp_get_dynamic routine returns the value of the dyn-var ICV, which determines whether
27 dynamic adjustment of the number of threads is enabled or disabled.

1 Format
C / C++
2 int omp_get_dynamic(void);
C / C++
Fortran
3 logical function omp_get_dynamic()
Fortran
4 Binding
5 The binding task set for an omp_get_dynamic region is the generating task.
6 Effect
7 This routine returns true if dynamic adjustment of the number of threads is enabled for the current
8 task; it returns false, otherwise. If an implementation does not support dynamic adjustment of the
9 number of threads, then this routine always returns false.
10 Cross References
15 3.2.8 omp_get_cancellation
16 Summary
17 The omp_get_cancellation routine returns the value of the cancel-var ICV, which
18 determines if cancellation is enabled or disabled.
19 Format
C / C++
20 int omp_get_cancellation(void);
C / C++
Fortran
21 logical function omp_get_cancellation()
Fortran
22 Binding
23 The binding task set for an omp_get_cancellation region is the whole program.

1 Effect
2 This routine returns true if cancellation is enabled. It returns false otherwise.
3 Cross References
6 • OMP_CANCELLATION environment variable, see Section 6.11.
7 3.2.9 omp_set_nested (Deprecated)

8 Summary
9 The deprecated omp_set_nested routine enables or disables nested parallelism by setting the
10 max-active-levels-var ICV.
11 Format
C / C++
12 void omp_set_nested(int nested);
C / C++
Fortran
13 subroutine omp_set_nested(nested)
14 logical nested
Fortran
15 Binding
16 The binding task set for an omp_set_nested region is the generating task.
17 Effect
18 If the argument to omp_set_nested evaluates to true, the value of the max-active-levels-var
19 ICV is set to the number of active levels of parallelism that the implementation supports; otherwise,
20 if the value of max-active-levels-var is greater than 1 then it is set to 1. This routine has been
21 deprecated.
22 Cross References
23 • max-active-levels-var ICV, see Section 2.4.
25 • omp_get_nested routine, see Section 3.2.10.

1 3.2.10 omp_get_nested (Deprecated)
2 Summary
3 The deprecated omp_get_nested routine returns whether nested parallelism is enabled or
4 disabled, according to the value of the max-active-levels-var ICV.
5 Format
C / C++
6 int omp_get_nested(void);
C / C++
Fortran
7 logical function omp_get_nested()
Fortran
8 Binding
9 The binding task set for an omp_get_nested region is the generating task.
10 Effect
11 This routine returns true if max-active-levels-var is greater than 1 and greater than active-levels-var
12 for the current task; it returns false, otherwise. If an implementation does not support nested
13 parallelism, this routine always returns false. This routine has been deprecated.
14 Cross References
21 3.2.11 omp_set_schedule
22 Summary
23 The omp_set_schedule routine affects the schedule that is applied when runtime is used as
24 schedule kind, by setting the value of the run-sched-var ICV.

1 Format
C / C++
2 void omp_set_schedule(omp_sched_t kind, int chunk_size);
C / C++
Fortran
3 subroutine omp_set_schedule(kind, chunk_size)
4 integer (kind=omp_sched_kind) kind
5 integer chunk_size
Fortran
7 The first argument passed to this routine can be one of the valid OpenMP schedule kinds (except for
8 runtime) or any implementation-specific schedule. The C/C++ header file (omp.h) and the
9 Fortran include file (omp_lib.h) and/or Fortran module file (omp_lib) define the valid
10 constants. The valid constants must include the following, which can be extended with
11 implementation-specific values:
C / C++
12 typedef enum omp_sched_t {
13 // schedule kinds
14 omp_sched_static = 0x1,
15 omp_sched_dynamic = 0x2,
16 omp_sched_guided = 0x3,
17 omp_sched_auto = 0x4,
18
19 // schedule modifier
20 omp_sched_monotonic = 0x80000000u
21 } omp_sched_t;
C / C++

Fortran
1 ! schedule kinds
2 integer(kind=omp_sched_kind), &
3 parameter :: omp_sched_static = &
4 int(Z’1’, kind=omp_sched_kind)
6 parameter :: omp_sched_dynamic = &
9 parameter :: omp_sched_guided = &
12 parameter :: omp_sched__auto = &
14
15 ! schedule modifier
17 parameter :: omp_sched_monotonic = &
Fortran
19 Binding
20 The binding task set for an omp_set_schedule region is the generating task.
21 Effect
22 The effect of this routine is to set the value of the run-sched-var ICV of the current task to the
23 values specified in the two arguments. The schedule is set to the schedule kind that is specified by
24 the first argument kind. It can be any of the standard schedule kinds or any other
25 implementation-specific one. For the schedule kinds static, dynamic, and guided the
26 chunk_size is set to the value of the second argument, or to the default chunk_size if the value of the
27 second argument is less than 1; for the schedule kind auto the second argument has no meaning;
28 for implementation-specific schedule kinds, the values and associated meanings of the second
29 argument are implementation defined.
30 Each of the schedule kinds can be combined with the omp_sched_monotonic modifier by
31 using the + or | operators in C/C++ or the + operator in Fortran. If the schedule kind is combined
32 with the omp_sched_monotonic modifier, the schedule is modified as if the monotonic
33 schedule modifier was specified. Otherwise, the schedule modifier is nonmonotonic.

1 Cross References
2 • run-sched-var ICV, see Section 2.4.
3 • Determining the schedule of a worksharing-loop, see Section 2.11.4.1.
6 3.2.12 omp_get_schedule
7 Summary
8 The omp_get_schedule routine returns the schedule that is applied when the runtime schedule
9 is used.
10 Format
C / C++
11 void omp_get_schedule(omp_sched_t *kind, int *chunk_size);
C / C++
Fortran
12 subroutine omp_get_schedule(kind, chunk_size)
13 integer (kind=omp_sched_kind) kind
14 integer chunk_size
Fortran
15 Binding
16 The binding task set for an omp_get_schedule region is the generating task.
17 Effect
18 This routine returns the run-sched-var ICV in the task to which the routine binds. The first
19 argument kind returns the schedule to be used. It can be any of the standard schedule kinds as
20 defined in Section 3.2.11, or any implementation-specific schedule kind. The second argument
21 chunk_size returns the chunk size to be used, or a value less than 1 if the default chunk size is to be
22 used, if the returned schedule kind is static, dynamic, or guided. The value returned by the
23 second argument is implementation defined for any other schedule kinds.
24 Cross References
26 • Determining the schedule of a worksharing-loop, see Section 2.11.4.1.

1 3.2.13 omp_get_thread_limit
2 Summary
3 The omp_get_thread_limit routine returns the maximum number of OpenMP threads
4 available to participate in the current contention group.
5 Format
C / C++
6 int omp_get_thread_limit(void);
C / C++
Fortran
7 integer function omp_get_thread_limit()
Fortran
8 Binding
9 The binding task set for an omp_get_thread_limit region is the generating task.
10 Effect
11 The omp_get_thread_limit routine returns the value of the thread-limit-var ICV.
12 Cross References
13 • thread-limit-var ICV, see Section 2.4.
16 • OMP_THREAD_LIMIT environment variable, see Section 6.10.
17 3.2.14 omp_get_supported_active_levels
18 Summary
19 The omp_get_supported_active_levels routine returns the number of active levels of
20 parallelism supported by the implementation.
21 Format
C / C++
22 int omp_get_supported_active_levels(void);
C / C++
Fortran
23 integer function omp_get_supported_active_levels()
Fortran

1 Binding
2 The binding task set for an omp_get_supported_active_levels region is the generating
3 task.
4 Effect
5 The omp_get_supported_active_levels routine returns the number of active levels of
6 parallelism supported by the implementation. The max-active-levels-var ICV may not have a value
7 that is greater than this number. The value returned by the
8 omp_get_supported_active_levels routine is implementation defined, but it must be
9 greater than 0.
10 Cross References
14 3.2.15 omp_set_max_active_levels
15 Summary
16 The omp_set_max_active_levels routine limits the number of nested active parallel
17 regions when a new nested parallel region is generated by the current task by setting the
18 max-active-levels-var ICV.
19 Format
C / C++
20 void omp_set_max_active_levels(int max_levels);
C / C++
Fortran
21 subroutine omp_set_max_active_levels(max_levels)
22 integer max_levels
Fortran
24 The value of the argument passed to this routine must evaluate to a non-negative integer, otherwise
25 the behavior of this routine is implementation defined.
26 Binding
27 The binding task set for an omp_set_max_active_levels region is the generating task.

1 Effect
2 The effect of this routine is to set the value of the max-active-levels-var ICV to the value specified
3 in the argument.
4 If the number of active levels requested exceeds the number of active levels of parallelism
5 supported by the implementation, the value of the max-active-levels-var ICV will be set to the
6 number of active levels supported by the implementation.
7 Cross References
10 • omp_get_supported_active_levels routine, see Section 3.2.14.
13 3.2.16 omp_get_max_active_levels
14 Summary
15 The omp_get_max_active_levels routine returns the value of the max-active-levels-var
16 ICV, which determines the maximum number of nested active parallel regions when the innermost
17 parallel region is generated by the current task.
18 Format
C / C++
19 int omp_get_max_active_levels(void);
C / C++
Fortran
20 integer function omp_get_max_active_levels()
Fortran
21 Binding
22 The binding task set for an omp_get_max_active_levels region is the generating task.
23 Effect
24 The omp_get_max_active_levels routine returns the value of the max-active-levels-var
25 ICV. The current task may only generate an active parallel region if the returned value is greater
26 than the value of the active-levels-var ICV.

1 Cross References
4 • omp_get_supported_active_levels routine, see Section 3.2.14.
7 3.2.17 omp_get_level
8 Summary
9 The omp_get_level routine returns the value of the levels-var ICV.
10 Format
C / C++
11 int omp_get_level(void);
C / C++
Fortran
12 integer function omp_get_level()
Fortran
13 Binding
14 The binding task set for an omp_get_level region is the generating task.
15 Effect
16 The effect of the omp_get_level routine is to return the number of nested parallel regions
17 (whether active or inactive) that enclose the current task such that all of the parallel regions are
18 enclosed by the outermost initial task region on the current device.
19 Cross References
20 • levels-var ICV, see Section 2.4.

1 3.2.18 omp_get_ancestor_thread_num
2 Summary
3 The omp_get_ancestor_thread_num routine returns, for a given nested level of the current
4 thread, the thread number of the ancestor of the current thread.
5 Format
C / C++
6 int omp_get_ancestor_thread_num(int level);
C / C++
Fortran
7 integer function omp_get_ancestor_thread_num(level)
8 integer level
Fortran
9 Binding
10 The binding thread set for an omp_get_ancestor_thread_num region is the encountering
11 thread. The binding region for an omp_get_ancestor_thread_num region is the innermost
12 enclosing parallel region.
13 Effect
14 The omp_get_ancestor_thread_num routine returns the thread number of the ancestor at a
15 given nest level of the current thread or the thread number of the current thread. If the requested
16 nest level is outside the range of 0 and the nest level of the current thread, as returned by the
17 omp_get_level routine, the routine returns -1.
18
19 Note – When the omp_get_ancestor_thread_num routine is called with a value of

20 level=0, the routine always returns 0. If level=omp_get_level(), the routine has the
21 same effect as the omp_get_thread_num routine.
22
23 Cross References
28 • omp_get_team_size routine, see Section 3.2.19.

1 3.2.19 omp_get_team_size
2 Summary
3 The omp_get_team_size routine returns, for a given nested level of the current thread, the size
4 of the thread team to which the ancestor or the current thread belongs.
5 Format
C / C++
6 int omp_get_team_size(int level);
C / C++
Fortran
7 integer function omp_get_team_size(level)
8 integer level
Fortran
9 Binding
10 The binding thread set for an omp_get_team_size region is the encountering thread. The
11 binding region for an omp_get_team_size region is the innermost enclosing parallel
12 region.
13 Effect
14 The omp_get_team_size routine returns the size of the thread team to which the ancestor or
15 the current thread belongs. If the requested nested level is outside the range of 0 and the nested
16 level of the current thread, as returned by the omp_get_level routine, the routine returns -1.
17 Inactive parallel regions are regarded like active parallel regions executed with one thread.
18
19 Note – When the omp_get_team_size routine is called with a value of level=0, the routine
20 always returns 1. If level=omp_get_level(), the routine has the same effect as the
21 omp_get_num_threads routine.
22
23 Cross References
26 • omp_get_ancestor_thread_num routine, see Section 3.2.18.
27 3.2.20 omp_get_active_level
28 Summary
29 The omp_get_active_level routine returns the value of the active-level-var ICV.

1 Format
C / C++
2 int omp_get_active_level(void);
C / C++
Fortran
3 integer function omp_get_active_level()
Fortran
4 Binding
5 The binding task set for the an omp_get_active_level region is the generating task.
6 Effect
7 The effect of the omp_get_active_level routine is to return the number of nested active
8 parallel regions enclosing the current task such that all of the parallel regions are enclosed
9 by the outermost initial task region on the current device.
10 Cross References
11 • active-levels-var ICV, see Section 2.4.
16 3.3 Thread Affinity Routines

17 This section describes routines that affect and access thread affinity policies that are in effect.
18 3.3.1 omp_get_proc_bind
19 Summary
20 The omp_get_proc_bind routine returns the thread affinity policy to be used for the
21 subsequent nested parallel regions that do not specify a proc_bind clause.
22 Format
C / C++
23 omp_proc_bind_t omp_get_proc_bind(void);
C / C++

Fortran
1 integer (kind=omp_proc_bind_kind) function omp_get_proc_bind()
Fortran
3 The value returned by this routine must be one of the valid affinity policy kinds. The C/C++ header
4 file (omp.h) and the Fortran include file (omp_lib.h) and/or Fortran module file (omp_lib)
5 define the valid constants. The valid constants must include the following:
C / C++
6 typedef enum omp_proc_bind_t {
7 omp_proc_bind_false = 0,
8 omp_proc_bind_true = 1,
9 omp_proc_bind_primary = 2,
10 omp_proc_bind_master = omp_proc_bind_primary, // (deprecated)
11 omp_proc_bind_close = 3,
12 omp_proc_bind_spread = 4
13 } omp_proc_bind_t;
C / C++
Fortran
14 integer (kind=omp_proc_bind_kind), &
15 parameter :: omp_proc_bind_false = 0
17 parameter :: omp_proc_bind_true = 1
19 parameter :: omp_proc_bind_primary = 2
21 parameter :: omp_proc_bind_master = &
22 omp_proc_bind_primary ! (deprecated)
24 parameter :: omp_proc_bind_close = 3
26 parameter :: omp_proc_bind_spread = 4
Fortran
27 Binding
28 The binding task set for an omp_get_proc_bind region is the generating task.
29 Effect
30 The effect of this routine is to return the value of the first element of the bind-var ICV of the current
31 task. See Section 2.6.2 for the rules that govern the thread affinity policy.

1 Cross References
2 • bind-var ICV, see Section 2.4.
3 • Controlling OpenMP thread affinity, see Section 2.6.2.
4 • omp_get_num_places routine, see Section 3.3.2.
5 • OMP_PROC_BIND environment variable, see Section 6.4.
7 3.3.2 omp_get_num_places
8 Summary
9 The omp_get_num_places routine returns the number of places available to the execution
10 environment in the place list.
11 Format
C / C++
12 int omp_get_num_places(void);
C / C++
Fortran
13 integer function omp_get_num_places()
Fortran
14 Binding
15 The binding thread set for an omp_get_num_places region is all threads on a device. The
16 effect of executing this routine is not related to any specific region corresponding to any construct
17 or API routine.
18 Effect
19 The omp_get_num_places routine returns the number of places in the place list. This value is
20 equivalent to the number of places in the place-partition-var ICV in the execution environment of
21 the initial task.
22 Cross References
23 • place-partition-var ICV, see Section 2.4.
25 • omp_get_place_num routine, see Section 3.3.5.

1 3.3.3 omp_get_place_num_procs
2 Summary
3 The omp_get_place_num_procs routine returns the number of processors available to the
4 execution environment in the specified place.
5 Format
C / C++
6 int omp_get_place_num_procs(int place_num);
C / C++
Fortran
7 integer function omp_get_place_num_procs(place_num)
8 integer place_num
Fortran
9 Binding
10 The binding thread set for an omp_get_place_num_procs region is all threads on a device.
11 The effect of executing this routine is not related to any specific region corresponding to any
12 construct or API routine.
13 Effect
14 The omp_get_place_num_procs routine returns the number of processors associated with
15 the place numbered place_num. The routine returns zero when place_num is negative, or is greater
16 than or equal to the value returned by omp_get_num_places().
17 Cross References
23 3.3.4 omp_get_place_proc_ids
24 Summary
25 The omp_get_place_proc_ids routine returns the numerical identifiers of the processors
26 available to the execution environment in the specified place.
27 Format
C / C++
28 void omp_get_place_proc_ids(int place_num, int *ids);
C / C++

Fortran
1 subroutine omp_get_place_proc_ids(place_num, ids)
2 integer place_num
3 integer ids(*)
Fortran
4 Binding
5 The binding thread set for an omp_get_place_proc_ids region is all threads on a device.
6 The effect of executing this routine is not related to any specific region corresponding to any
8 Effect
9 The omp_get_place_proc_ids routine returns the numerical identifiers of each processor
10 associated with the place numbered place_num. The numerical identifiers are non-negative and
11 their meaning is implementation defined. The numerical identifiers are returned in the array ids and
12 their order in the array is implementation defined. The array must be sufficiently large to contain
13 omp_get_place_num_procs(place_num) integers; otherwise, the behavior is unspecified.
14 The routine has no effect when place_num has a negative value or a value greater than or equal to
15 omp_get_num_places().
16 Cross References
22 3.3.5 omp_get_place_num
23 Summary
24 The omp_get_place_num routine returns the place number of the place to which the
25 encountering thread is bound.
26 Format
C / C++
27 int omp_get_place_num(void);
C / C++
Fortran
28 integer function omp_get_place_num()
Fortran

1 Binding
2 The binding thread set for an omp_get_place_num region is the encountering thread.
3 Effect
4 When the encountering thread is bound to a place, the omp_get_place_num routine returns the
5 place number associated with the thread. The returned value is between 0 and one less than the
6 value returned by omp_get_num_places(), inclusive. When the encountering thread is not
7 bound to a place, the routine returns -1.
8 Cross References
13 3.3.6 omp_get_partition_num_places
14 Summary
15 The omp_get_partition_num_places routine returns the number of places in the place
16 partition of the innermost implicit task.
17 Format
C / C++
18 int omp_get_partition_num_places(void);
C / C++
Fortran
19 integer function omp_get_partition_num_places()
Fortran
20 Binding
21 The binding task set for an omp_get_partition_num_places region is the encountering
22 implicit task.
23 Effect
24 The omp_get_partition_num_places routine returns the number of places in the
25 place-partition-var ICV.

1 Cross References
6 3.3.7 omp_get_partition_place_nums
7 Summary
8 The omp_get_partition_place_nums routine returns the list of place numbers
9 corresponding to the places in the place-partition-var ICV of the innermost implicit task.
10 Format
C / C++
11 void omp_get_partition_place_nums(int *place_nums);
C / C++
Fortran
12 subroutine omp_get_partition_place_nums(place_nums)
13 integer place_nums(*)
Fortran
14 Binding
15 The binding task set for an omp_get_partition_place_nums region is the encountering
16 implicit task.
17 Effect
18 The omp_get_partition_place_nums routine returns the list of place numbers that
19 correspond to the places in the place-partition-var ICV of the innermost implicit task. The array
20 must be sufficiently large to contain omp_get_partition_num_places() integers;
21 otherwise, the behavior is unspecified.
22 Cross References

1 3.3.8 omp_set_affinity_format
2 Summary
3 The omp_set_affinity_format routine sets the affinity format to be used on the device by
4 setting the value of the affinity-format-var ICV.
5 Format
C / C++
6 void omp_set_affinity_format(const char *format);
C / C++
Fortran
7 subroutine omp_set_affinity_format(format)
8 character(len=*),intent(in) :: format
Fortran
9 Binding
10 When called from a sequential part of the program, the binding thread set for an
11 omp_set_affinity_format region is the encountering thread. When called from within any
12 parallel or teams region, the binding thread set (and binding region, if required) for the
13 omp_set_affinity_format region is implementation defined.
14 Effect
15 The effect of omp_set_affinity_format routine is to copy the character string specified by
16 the format argument into the affinity-format-var ICV on the current device.
17 This routine has the described effect only when called from a sequential part of the program. When
18 called from within a parallel or teams region, the effect of this routine is implementation
19 defined.
20 Cross References
23 • omp_display_affinity routine, see Section 3.3.10.
24 • omp_capture_affinity routine, see Section 3.3.11.

1 3.3.9 omp_get_affinity_format
2 Summary
3 The omp_get_affinity_format routine returns the value of the affinity-format-var ICV on
4 the device.
5 Format
C / C++
6 size_t omp_get_affinity_format(char *buffer, size_t size);
C / C++
Fortran
7 integer function omp_get_affinity_format(buffer)
8 character(len=*),intent(out) :: buffer
Fortran
9 Binding
10 When called from a sequential part of the program, the binding thread set for an
11 omp_get_affinity_format region is the encountering thread. When called from within any
12 parallel or teams region, the binding thread set (and binding region, if required) for the
13 omp_get_affinity_format region is implementation defined.
14 Effect
C / C++
15 The omp_get_affinity_format routine returns the number of characters in the
16 affinity-format-var ICV on the current device, excluding the terminating null byte (’\0’) and if
17 size is non-zero, writes the value of the affinity-format-var ICV on the current device to buffer
18 followed by a null byte. If the return value is larger or equal to size, the affinity format specification
19 is truncated, with the terminating null byte stored to buffer[size-1]. If size is zero, nothing is
20 stored and buffer may be NULL.
C / C++
Fortran
21 The omp_get_affinity_format routine returns the number of characters that are required to
22 hold the affinity-format-var ICV on the current device and writes the value of the
23 affinity-format-var ICV on the current device to buffer. If the return value is larger than
24 len(buffer), the affinity format specification is truncated.
Fortran
25 If the buffer argument does not conform to the specified format then the result is implementation
26 defined.

1 Cross References
8 3.3.10 omp_display_affinity
9 Summary
10 The omp_display_affinity routine prints the OpenMP thread affinity information using the
11 format specification provided.
12 Format
C / C++
13 void omp_display_affinity(const char *format);
C / C++
Fortran
14 subroutine omp_display_affinity(format)
Fortran
16 Binding
17 The binding thread set for an omp_display_affinity region is the encountering thread.
18 Effect
19 The omp_display_affinity routine prints the thread affinity information of the current
20 thread in the format specified by the format argument, followed by a new-line. If the format is
21 NULL (for C/C++) or a zero-length string (for Fortran and C/C++), the value of the
22 affinity-format-var ICV is used. If the format argument does not conform to the specified format
23 then the result is implementation defined.

1 Cross References
8 3.3.11 omp_capture_affinity
9 Summary
10 The omp_capture_affinity routine prints the OpenMP thread affinity information into a
11 buffer using the format specification provided.
12 Format
C / C++
13 size_t omp_capture_affinity(
14 char *buffer,
15 size_t size,
16 const char *format
17 );
C / C++
Fortran
18 integer function omp_capture_affinity(buffer,format)
19 character(len=*),intent(out) :: buffer
Fortran
21 Binding
22 The binding thread set for an omp_capture_affinity region is the encountering thread.
23 Effect
C / C++
24 The omp_capture_affinity routine returns the number of characters in the entire thread
25 affinity information string excluding the terminating null byte (’\0’) and if size is non-zero, writes
26 the thread affinity information of the current thread in the format specified by the format argument
27 into the character string buffer followed by a null byte. If the return value is larger or equal to
28 size, the thread affinity information string is truncated, with the terminating null byte stored to
29 buffer[size-1]. If size is zero, nothing is stored and buffer may be NULL. If the format is NULL or
30 a zero-length string, the value of the affinity-format-var ICV is used.
C / C++

Fortran
1 The omp_capture_affinity routine returns the number of characters required to hold the
2 entire thread affinity information string and prints the thread affinity information of the current
3 thread into the character string buffer with the size of len(buffer) in the format specified by
4 the format argument. If the format is a zero-length string, the value of the affinity-format-var ICV
5 is used. If the return value is larger than len(buffer), the thread affinity information string is
6 truncated. If the format is a zero-length string, the value of the affinity-format-var ICV is used.
Fortran
7 If the format argument does not conform to the specified format then the result is implementation
8 defined.
9 Cross References
16 3.4 Teams Region Routines

17 This section describes routines that affect and monitor the league of teams that may execute a
18 teams region.
19 3.4.1 omp_get_num_teams
20 Summary
21 The omp_get_num_teams routine returns the number of initial teams in the current teams
22 region.
23 Format
C / C++
24 int omp_get_num_teams(void);
C / C++
Fortran
25 integer function omp_get_num_teams()
Fortran

1 Binding
2 The binding task set for an omp_get_num_teams region is the generating task
3 Effect
4 The effect of this routine is to return the number of initial teams in the current teams region. The
5 routine returns 1 if it is called from outside of a teams region.
6 Cross References
8 • omp_get_team_num routine, see Section 3.4.2.
9 3.4.2 omp_get_team_num
10 Summary
11 The omp_get_team_num routine returns the initial team number of the calling thread.
12 Format
C / C++
13 int omp_get_team_num(void);
C / C++
Fortran
14 integer function omp_get_team_num()
Fortran
15 Binding
16 The binding task set for an omp_get_team_num region is the generating task.
17 Effect
18 The omp_get_team_num routine returns the initial team number of the calling thread. The
19 initial team number is an integer between 0 and one less than the value returned by
20 omp_get_num_teams(), inclusive. The routine returns 0 if it is called outside of a teams
21 region.
22 Cross References

1 3.4.3 omp_set_num_teams
2 Summary
3 The omp_set_num_teams routine affects the number of threads to be used for subsequent
4 teams regions that do not specify a num_teams clause, by setting the value of the nteams-var
5 ICV of the current task.
6 Format
C / C++
7 void omp_set_num_teams(int num_teams);
C / C++
Fortran
8 subroutine omp_set_num_teams(num_teams)
9 integer num_teams
Fortran
13 Binding
14 The binding task set for an omp_set_num_teams region is the generating task.
15 Effect
16 The effect of this routine is to set the value of the nteams-var ICV of the current task to the value
17 specified in the argument.
18 Restrictions
19 Restrictions to the omp_set_num_teams routine are as follows:
20 • The routine may not be called from within a parallel region that is not the implicit parallel region
21 that surrounds the whole OpenMP program.
22 Cross References
23 • nteams-var ICV, see Section 2.4.
24 • teams construct and num_teams clause, see Section 2.7.
27 • OMP_NUM_TEAMS environment variable, see Section 6.23.

1 3.4.4 omp_get_max_teams
2 Summary
3 The omp_get_max_teams routine returns an upper bound on the number of teams that could be
4 created by a teams construct without a num_teams clause that is encountered after execution
5 returns from this routine.
6 Format
C / C++
7 int omp_get_max_teams(void);
C / C++
Fortran
8 integer function omp_get_max_teams()
Fortran
9 Binding
10 The binding task set for an omp_get_max_teams region is the generating task.
11 Effect
12 The value returned by omp_get_max_teams is the value of the nteams-var ICV of the current
13 task. This value is also an upper bound on the number of teams that can be created by a teams
14 construct without a num_teams clause that is encountered after execution returns from this
15 routine.
16 Cross References
18 • teams construct and num_teams clause, see Section 2.7.
20 • omp_set_num_teams routine, see Section 3.4.3.
21 3.4.5 omp_set_teams_thread_limit
22 Summary
23 The omp_set_teams_thread_limit routine defines the maximum number of OpenMP
24 threads that can participate in each contention group created by a teams construct.
25 Format
C / C++
26 void omp_set_teams_thread_limit(int thread_limit);
C / C++

Fortran
1 subroutine omp_set_teams_thread_limit(thread_limit)
2 integer thread_limit
Fortran
6 Binding
7 The binding task set for an omp_set_teams_thread_limit region is the generating task.
8 Effect
9 The omp_set_teams_thread_limit routine sets the value of the teams-thread-limit-var
10 ICV to the value of the thread_limit argument.
11 If the value of thread_limit exceeds the number of OpenMP threads that an implementation
12 supports for each contention group created by a teams construct, the value of the
13 teams-thread-limit-var ICV will be set to the number that is supported by the implementation.
14 Restrictions
15 Restrictions to the omp_set_teams_thread_limit routine are as follows:
16 • The routine may not be called from within a parallel region other than the implicit parallel region
17 that surrounds the whole OpenMP program.
18 Cross References
19 • teams_thread-limit-var ICV, see Section 2.4.
20 • teams construct and thread_limit clause, see Section 2.7.
23 3.4.6 omp_get_teams_thread_limit
24 Summary
25 The omp_get_teams_thread_limit routine returns the maximum number of OpenMP
26 threads available to participate in each contention group created by a teams construct.
27 Format
C / C++
28 int omp_get_teams_thread_limit(void);
C / C++

Fortran
1 integer function omp_get_teams_thread_limit()
Fortran
2 Binding
3 The binding task set for an omp_get_teams_thread_limit region is the generating task.
4 Effect
5 The omp_get_teams_thread_limit routine returns the value of the teams-thread-limit-var
6 ICV.
7 Cross References
8 • teams_thread-limit-var ICV, see Section 2.4.
9 • teams construct and thread_limit clause, see Section 2.7.
10 • omp_set_teams_thread_limit routine, see Section 3.4.5.
12 3.5 Tasking Routines

13 This section describes routines that pertain to OpenMP explicit tasks.
14 3.5.1 omp_get_max_task_priority
15 Summary
16 The omp_get_max_task_priority routine returns the maximum value that can be specified
17 in the priority clause.
18 Format
C / C++
19 int omp_get_max_task_priority(void);
C / C++
Fortran
20 integer function omp_get_max_task_priority()
Fortran
21 Binding
22 The binding thread set for an omp_get_max_task_priority region is all threads on the
23 device. The effect of executing this routine is not related to any specific region that corresponds to
24 any construct or API routine.

1 Effect
2 The omp_get_max_task_priority routine returns the value of the max-task-priority-var
3 ICV, which determines the maximum value that can be specified in the priority clause.
4 Cross References
5 • max-task-priority-var, see Section 2.4.
7 3.5.2 omp_in_final
8 Summary
9 The omp_in_final routine returns true if the routine is executed in a final task region;
11 Format
C / C++
12 int omp_in_final(void);
C / C++
Fortran
13 logical function omp_in_final()
Fortran
14 Binding
15 The binding task set for an omp_in_final region is the generating task.
16 Effect
17 omp_in_final returns true if the enclosing task region is final. Otherwise, it returns false.
18 Cross References

1 3.6 Resource Relinquishing Routines
2 This section describes routines that relinquish resources used by the OpenMP runtime.
3 3.6.1 omp_pause_resource
4 Summary
5 The omp_pause_resource routine allows the runtime to relinquish resources used by OpenMP
6 on the specified device.
7 Format
C / C++
8 int omp_pause_resource(
9 omp_pause_resource_t kind,
10 int device_num
11 );
C / C++
Fortran
12 integer function omp_pause_resource(kind, device_num)
13 integer (kind=omp_pause_resource_kind) kind
14 integer device_num
Fortran
16 The first argument passed to this routine can be one of the valid OpenMP pause kind, or any
17 implementation specific pause kind. The C/C++ header file (omp.h) and the Fortran include file
18 (omp_lib.h) and/or Fortran module file (omp_lib) define the valid constants. The valid
19 constants must include the following, which can be extended with implementation-specific values:
20 Format
C / C++
21 typedef enum omp_pause_resource_t {
22 omp_pause_soft = 1,
23 omp_pause_hard = 2
24 } omp_pause_resource_t;
C / C++
Fortran
25 integer (kind=omp_pause_resource_kind), parameter :: &
26 omp_pause_soft = 1
27 integer (kind=omp_pause_resource_kind), parameter :: &
28 omp_pause_hard = 2
Fortran

1 The second argument passed to this routine indicates the device that will be paused. The
2 device_num parameter must be greater than or equal to zero and less than or equal to the result
3 of omp_get_num_devices().
4 Binding
5 The binding task set for an omp_pause_resource region is the whole program.
6 Effect
7 The omp_pause_resource routine allows the runtime to relinquish resources used by OpenMP
8 on the specified device.
9 If successful, the omp_pause_hard value results in a hard pause for which the OpenMP state is
10 not guaranteed to persist across the omp_pause_resource call. A hard pause may relinquish
11 any data allocated by OpenMP on a given device, including data allocated by memory routines for
12 that device as well as data present on the device as a result of a declare target directive or
13 target data construct. A hard pause may also relinquish any data associated with a
14 threadprivate directive. When relinquished and when applicable, base language appropriate
15 deallocation/finalization is performed. When relinquished and when applicable, mapped data on a
16 device will not be copied back from the device to the host.
17 If successful, the omp_pause_soft value results in a soft pause for which the OpenMP state is
18 guaranteed to persist across the call, with the exception of any data associated with a
19 threadprivate directive, which may be relinquished across the call. When relinquished and
20 when applicable, base language appropriate deallocation/finalization is performed.
21
22 Note – A hard pause may relinquish more resources, but may resume processing OpenMP regions
23 more slowly. A soft pause allows OpenMP regions to restart more quickly, but may relinquish fewer
24 resources. An OpenMP implementation will reclaim resources as needed for OpenMP regions
25 encountered after the omp_pause_resource region. Since a hard pause may unmap data on the
26 specified device, appropriate data mapping is required before using data on the specified device
27 after the omp_pause_region region.
28
29 The routine returns zero in case of success, and non-zero otherwise.
30 Tool Callbacks
31 If the tool is not allowed to interact with the specified device after encountering this call, then the
32 runtime must call the tool finalizer for that device.
33 Restrictions
34 Restrictions to the omp_pause_resource routine are as follows:
35 • The omp_pause_resource region may not be nested in any explicit OpenMP region.
36 • The routine may only be called when all explicit tasks have finalized execution.

1 Cross References
3 • Declare target directive, see Section 2.14.7.
4 • threadprivate directives, see Section 2.21.2.
5 • To pause resources on all devices at once, see Section 3.6.2.
6 • omp_get_num_devices, see Section 3.7.4.
7 3.6.2 omp_pause_resource_all
8 Summary
9 The omp_pause_resource_all routine allows the runtime to relinquish resources used by
10 OpenMP on all devices.
11 Format
C / C++
12 int omp_pause_resource_all(omp_pause_resource_t kind);
C / C++
Fortran
13 integer function omp_pause_resource_all(kind)
14 integer (kind=omp_pause_resource_kind) kind
Fortran
15 Binding
16 The binding task set for an omp_pause_resource_all region is the whole program.
17 Effect
18 The omp_pause_resource_all routine allows the runtime to relinquish resources used by
19 OpenMP on all devices. It is equivalent to calling the omp_pause_resource routine once for
20 each available device, including the host device.
21 The argument kind passed to this routine can be one of the valid OpenMP pause kind as defined in
22 Section 3.6.1, or any implementation-specific pause kind.
23 Tool Callbacks
24 If the tool is not allowed to interact with a given device after encountering this call, then the
25 runtime must call the tool finalizer for that device.

1 Restrictions
2 Restrictions to the omp_pause_resource_all routine are as follows:
3 • The omp_pause_resource_all region may not be nested in any explicit OpenMP region.
4 • The routine may only be called when all explicit tasks have finalized execution.
5 Cross References
7 • Declare target directive, see Section 2.14.7.
8 • To pause resources on a specific device only, see Section 3.6.1.
9 3.7 Device Information Routines

10 This section describes routines that pertain to the set of devices that are accessible to an OpenMP
11 program.
12 3.7.1 omp_get_num_procs
13 Summary
14 The omp_get_num_procs routine returns the number of processors available to the device.
15 Format
C / C++
16 int omp_get_num_procs(void);
C / C++
Fortran
17 integer function omp_get_num_procs()
Fortran
18 Binding
19 The binding thread set for an omp_get_num_procs region is all threads on a device. The effect
20 of executing this routine is not related to any specific region corresponding to any construct or API
21 routine.
22 Effect
23 The omp_get_num_procs routine returns the number of processors that are available to the
24 device at the time the routine is called. This value may change between the time that it is
25 determined by the omp_get_num_procs routine and the time that it is read in the calling
26 context due to system actions outside the control of the OpenMP implementation.

1 Cross References
6 3.7.2 omp_set_default_device
7 Summary
8 The omp_set_default_device routine controls the default target device by assigning the
9 value of the default-device-var ICV.
10 Format
C / C++
11 void omp_set_default_device(int device_num);
C / C++
Fortran
12 subroutine omp_set_default_device(device_num)
13 integer device_num
Fortran
14 Binding
15 The binding task set for an omp_set_default_device region is the generating task.
16 Effect
17 The effect of this routine is to set the value of the default-device-var ICV of the current task to the
18 value specified in the argument. When called from within a target region the effect of this
19 routine is unspecified.
20 Cross References
23 • omp_get_default_device, see Section 3.7.3.
25 3.7.3 omp_get_default_device
26 Summary
27 The omp_get_default_device routine returns the default target device.

1 Format
C / C++
2 int omp_get_default_device(void);
C / C++
Fortran
3 integer function omp_get_default_device()
Fortran
4 Binding
5 The binding task set for an omp_get_default_device region is the generating task.
6 Effect
7 The omp_get_default_device routine returns the value of the default-device-var ICV of the
8 current task. When called from within a target region the effect of this routine is unspecified.
9 Cross References
12 • omp_set_default_device, see Section 3.7.2.
14 3.7.4 omp_get_num_devices
15 Summary
16 The omp_get_num_devices routine returns the number of non-host devices available for
17 offloading code or data.
18 Format
C / C++
19 int omp_get_num_devices(void);
C / C++
Fortran
20 integer function omp_get_num_devices()
Fortran
21 Binding
22 The binding task set for an omp_get_num_devices region is the generating task.

1 Effect
2 The omp_get_num_devices routine returns the number of available non-host devices onto
3 which code or data may be offloaded. When called from within a target region the effect of this
4 routine is unspecified.
5 Cross References
8 • omp_get_device_num, see Section 3.7.5.
9 3.7.5 omp_get_device_num
10 Summary
11 The omp_get_device_num routine returns the device number of the device on which the
12 calling thread is executing.
13 Format
C / C++
14 int omp_get_device_num(void);
C / C++
Fortran
15 integer function omp_get_device_num()
Fortran
16 Binding
17 The binding task set for an omp_get_device_num region is the generating task.
18 Effect
19 The omp_get_device_num routine returns the device number of the device on which the
20 calling thread is executing. When called on the host device, it will return the same value as the
21 omp_get_initial_device routine.
22 Cross References
25 • omp_get_num_devices, see Section 3.7.4.
26 • omp_get_initial_device routine, see Section 3.7.7.

1 3.7.6 omp_is_initial_device
2 Summary
3 The omp_is_initial_device routine returns true if the current task is executing on the host
4 device; otherwise, it returns false.
5 Format
C / C++
6 int omp_is_initial_device(void);
C / C++
Fortran
7 logical function omp_is_initial_device()
Fortran
8 Binding
9 The binding task set for an omp_is_initial_device region is the generating task.
10 Effect
11 The effect of this routine is to return true if the current task is executing on the host device;
13 Cross References
15 • Device memory routines, see Section 3.8.
16 3.7.7 omp_get_initial_device
17 Summary
18 The omp_get_initial_device routine returns a device number that represents the host
19 device.
20 Format
C / C++
21 int omp_get_initial_device(void);
C / C++
Fortran
22 integer function omp_get_initial_device()
Fortran
23 Binding
24 The binding task set for an omp_get_initial_device region is the generating task.

1 Effect
2 The effect of this routine is to return the device number of the host device. The value of the device
3 number is the value returned by the omp_get_num_devices routine. When called from within
4 a target region the effect of this routine is unspecified.
5 Cross References
7 • omp_is_initial_device routine, see Section 3.7.6.
8 • Device memory routines, see Section 3.8.
9 3.8 Device Memory Routines

10 This section describes routines that support allocation of memory and management of pointers in
11 the data environments of target devices.
12 3.8.1 omp_target_alloc
13 Summary
14 The omp_target_alloc routine allocates memory in a device data environment and returns a
15 device pointer to that memory.
16 Format
C / C++
17 void* omp_target_alloc(size_t size, int device_num);
C / C++
Fortran
18 type(c_ptr) function omp_target_alloc(size, device_num) bind(c)
19 use, intrinsic :: iso_c_binding, only : c_ptr, c_size_t, c_int
20 integer(c_size_t), value :: size
21 integer(c_int), value :: device_num
Fortran
23 The device_num argument must be greater than or equal to zero and less than or equal to the result
25 Binding
26 The binding task set for an omp_target_alloc region is the generating task, which is the target
27 task generated by the call to the omp_target_alloc routine.

1 Effect
2 The omp_target_alloc routine returns a device pointer that references the device address of a
3 storage location of size bytes. The storage location is dynamically allocated in the device data
4 environment of the device specified by device_num.
5 The omp_target_alloc routine executes as if part of a target task that is generated by the call
6 to the routine and that is an included task.
7 The omp_target_alloc routine returns NULL (or, C_NULL_PTR, for Fortran) if it cannot
8 dynamically allocate the memory in the device data environment.
9 The device pointer returned by omp_target_alloc can be used in an is_device_ptr
10 clause, Section 2.14.5.
Fortran
11 The omp_target_alloc routine requires an explicit interface and so might not be provided in
12 omp_lib.h.
Fortran

14 The target-data-allocation-begin event occurs before a thread initiates a data allocation on a target
15 device.
16 The target-data-allocation-end event occurs after a thread initiates a data allocation on a target
17 device.
18 Tool Callbacks
20 ompt_scope_begin as its endpoint argument for each occurrence of a
21 target-data-allocation-begin event in that thread. Similarly, a thread dispatches a registered
23 argument for each occurrence of a target-data-allocation-end event in that thread. These callbacks
24 have type signature ompt_callback_target_data_op_emi_t.
26 occurrence of a target-data-allocation-begin event in that thread. The callback occurs in the context
27 of the target task and has type signature ompt_callback_target_data_op_t.
28 Restrictions
29 Restrictions to the omp_target_alloc routine are as follows.
30 • Freeing the storage returned by omp_target_alloc with any routine other than
31 omp_target_free results in unspecified behavior.
32 • When called from within a target region the effect is unspecified.

C / C++
1 • Unless the unified_address clause appears on a requires directive in the compilation
2 unit, pointer arithmetic is not supported on the device pointer returned by
3 omp_target_alloc.
C / C++
4 Cross References
7 • omp_target_free routine, see Section 3.8.2.
10 3.8.2 omp_target_free
11 Summary
12 The omp_target_free routine frees the device memory allocated by the
13 omp_target_alloc routine.
14 Format
C / C++
15 void omp_target_free(void *device_ptr, int device_num);
C / C++
Fortran
16 subroutine omp_target_free(device_ptr, device_num) bind(c)
17 use, intrinsic :: iso_c_binding, only : c_ptr, c_int
18 type(c_ptr), value :: device_ptr
Fortran
21 A program that calls omp_target_free with a non-null pointer that does not have a value
22 returned from omp_target_alloc is non-conforming. The device_num argument must be
23 greater than or equal to zero and less than or equal to the result of omp_get_num_devices().
24 Binding
25 The binding task set for an omp_target_free region is the generating task, which is the target
26 task generated by the call to the omp_target_free routine.

1 Effect
2 The omp_target_free routine frees the memory in the device data environment associated
3 with device_ptr. If device_ptr is NULL (or C_NULL_PTR, for Fortran), the operation is ignored.
4 The omp_target_free routine executes as if part of a target task that is generated by the call to
5 the routine and that is an included task.
6 Synchronization must be inserted to ensure that all accesses to device_ptr are completed before the
7 call to omp_target_free.
Fortran
8 The omp_target_free routine requires an explicit interface and so might not be provided in
9 omp_lib.h.
Fortran

11 The target-data-free-begin event occurs before a thread initiates a data free on a target device.
12 The target-data-free-end event occurs after a thread initiates a data free on a target device.
13 Tool Callbacks
15 ompt_scope_begin as its endpoint argument for each occurrence of a target-data-free-begin
18 argument for each occurrence of a target-data-free-end event in that thread. These callbacks have
21 occurrence of a target-data-free-begin event in that thread. The callback occurs in the context of the
23 Restrictions
24 Restrictions to the omp_target_free routine are as follows.
26 Cross References
29 • omp_target_alloc routine, see Section 3.8.1.

1 3.8.3 omp_target_is_present
2 Summary
3 The omp_target_is_present routine tests whether a host pointer refers to storage that is
4 mapped to a given device.
5 Format
C / C++
6 int omp_target_is_present(const void *ptr, int device_num);
C / C++
Fortran
7 integer(c_int) function omp_target_is_present(ptr, device_num) &
8 bind(c)
10 type(c_ptr), value :: ptr
Fortran
13 The value of ptr must be a valid host pointer or NULL (or C_NULL_PTR, for Fortran). The
14 device_num argument must be greater than or equal to zero and less than or equal to the result of
16 Binding
17 The binding task set for an omp_target_is_present region is the encountering task.
18 Effect
19 The omp_target_is_present routine returns true if device_num refers to the host device or
20 if ptr refers to storage that has corresponding storage in the device data environment of device
21 device_num. Otherwise, the routine returns false.
22 Restrictions
23 Restrictions to the omp_target_is_present routine are as follows.
25 Cross References

1 3.8.4 omp_target_is_accessible
2 Summary
3 The omp_target_is_accessible routine tests whether host memory is accessible from a
4 given device.
5 Format
C / C++
6 int omp_target_is_accessible( const void *ptr, size_t size,
7 int device_num);
C / C++
Fortran
8 integer(c_int) function omp_target_is_accessible( &
9 ptr, size, device_num) bind(c)
Fortran
15 The value of ptr must be a valid host pointer or NULL (or C_NULL_PTR, for Fortran). The
16 device_num argument must be greater than or equal to zero and less than or equal to the result of
18 Binding
19 The binding task set for an omp_target_is_accessible region is the encountering task.
20 Effect
21 This routine returns true if the storage of size bytes starting at the address given by ptr is accessible
22 from device device_num. Otherwise, it returns false.
23 Restrictions
24 Restrictions to the omp_target_is_accessible routine are as follows.
26 Cross References

1 3.8.5 omp_target_memcpy
2 Summary
3 The omp_target_memcpy routine copies memory between any combination of host and device
4 pointers.
5 Format
C / C++
6 int omp_target_memcpy(
7 void *dst,
8 const void *src,
9 size_t length,
10 size_t dst_offset,
11 size_t src_offset,
12 int dst_device_num,
13 int src_device_num
14 );
C / C++
Fortran
15 integer(c_int) function omp_target_memcpy(dst, src, length, &
16 dst_offset, src_offset, dst_device_num, src_device_num) bind(c)
17 use, intrinsic :: iso_c_binding, only : c_ptr, c_int, c_size_t
18 type(c_ptr), value :: dst, src
19 integer(c_size_t), value :: length, dst_offset, src_offset
20 integer(c_int), value :: dst_device_num, src_device_num
Fortran
22 Each device pointer specified must be valid for the device on the same side of the copy. The
23 dst_device_num and src_device_num arguments must be greater than or equal to zero and less than
24 or equal to the result of omp_get_num_devices().
25 Binding
26 The binding task set for an omp_target_memcpy region is the generating task, which is the
27 target task generated by the call to the omp_target_memcpy routine.
28 Effect
29 This routine copies length bytes of memory at offset src_offset from src in the device data
30 environment of device src_device_num to dst starting at offset dst_offset in the device data
31 environment of device dst_device_num.
32 The omp_target_memcpy routine executes as if part of a target task that is generated by the call
33 to the routine and that is an included task.
34 The return value is zero on success and non-zero on failure. This routine contains a task scheduling
35 point.

Fortran
1 The omp_target_memcpy routine requires an explicit interface and so might not be provided in
2 omp_lib.h.
Fortran

4 The target-data-op-begin event occurs before a thread initiates a data transfer.
5 The target-data-op-end event occurs after a thread initiated a data transfer.
6 Tool Callbacks
16 Restrictions
17 Restrictions to the omp_target_memcpy routine are as follows.
19 Cross References
24 3.8.6 omp_target_memcpy_rect
25 Summary
26 The omp_target_memcpy_rect routine copies a rectangular subvolume from a
27 multi-dimensional array to another multi-dimensional array. The omp_target_memcpy_rect
28 routine performs a copy between any combination of host and device pointers.

1 Format
C / C++
2 int omp_target_memcpy_rect(
3 void *dst,
4 const void *src,
5 size_t element_size,
6 int num_dims,
7 const size_t *volume,
8 const size_t *dst_offsets,
9 const size_t *src_offsets,
10 const size_t *dst_dimensions,
11 const size_t *src_dimensions,
13 int src_device_num
14 );
C / C++
Fortran
15 integer(c_int) function omp_target_memcpy_rect(dst,src,element_size, &
16 num_dims, volume, dst_offsets, src_offsets, dst_dimensions, src_dimensions, &
17 dst_device_num, src_device_num) bind(c)
20 integer(c_size_t), value :: element_size
21 integer(c_int), value :: num_dims, dst_device_num, src_device_num
22 integer(c_size_t), intent(in) :: volume(*), dst_offsets(*), &
23 src_offsets(*), dst_dimensions(*), src_dimensions(*)
Fortran
28 The length of the offset and dimension arrays must be at least the value of num_dims. The value of
29 num_dims must be between 1 and the implementation-defined limit, which must be at least three.
Fortran
30 Because the interface binds directly to a C language function the function assumes C memory
31 ordering.
Fortran
32 Binding
33 The binding task set for an omp_target_memcpy_rect region is the generating task, which is
34 the target task generated by the call to the omp_target_memcpy_rect routine.

1 Effect
2 This routine copies a rectangular subvolume of src, in the device data environment of device
3 src_device_num, to dst, in the device data environment of device dst_device_num. The volume is
4 specified in terms of the size of an element, number of dimensions, and constant arrays of length
5 num_dims. The maximum number of dimensions supported is at least three; support for higher
6 dimensionality is implementation defined. The volume array specifies the length, in number of
7 elements, to copy in each dimension from src to dst. The dst_offsets (src_offsets) parameter
8 specifies the number of elements from the origin of dst (src) in elements. The dst_dimensions
9 (src_dimensions) parameter specifies the length of each dimension of dst (src).
10 The omp_target_memcpy_rect routine executes as if part of a target task that is generated by
11 the call to the routine and that is an included task.
12 The routine returns zero if successful. Otherwise, it returns a non-zero value. The routine contains
13 a task scheduling point.
14 An application can determine the inclusive number of dimensions supported by an implementation
15 by passing NULL pointers for both dst and src. The routine returns the number of dimensions
16 supported by the implementation for the specified device numbers. No copy operation is performed.
Fortran
17 The omp_target_memcpy_rect routine requires an explicit interface and so might not be
18 provided in omp_lib.h.
Fortran

22 Tool Callbacks
32 Restrictions
33 Restrictions to the omp_target_memcpy_rect routine are as follows.

1 Cross References
6 3.8.7 omp_target_memcpy_async
7 Summary
8 The omp_target_memcpy_async routine asynchronously performs a copy between any
9 combination of host and device pointers.
10 Format
C / C++
11 int omp_target_memcpy_async(
12 void *dst,
13 const void *src,
14 size_t length,
15 size_t dst_offset,
16 size_t src_offset,
18 int src_device_num,
19 int depobj_count,
20 omp_depend_t *depobj_list
21 );
C / C++
Fortran
22 integer(c_int) function omp_target_memcpy_async(dst, src, length, &
23 dst_offset, src_offset, dst_device_num, src_device_num, &
24 depobj_count, depobj_list) bind(c)
27 integer(c_size_t), value :: length, dst_offset, src_offset
28 integer(c_int), value :: dst_device_num, src_device_num, depobj_count
29 integer(omp_depend_kind), optional :: depobj_list(*)
Fortran

1 Binding
2 The binding task set for an omp_target_memcpy_async region is the generating task, which
3 is the target task generated by the call to the omp_target_memcpy_async routine.
4 Effect
5 This routine performs an asynchronous memory copy where length bytes of memory at offset
6 src_offset from src in the device data environment of device src_device_num are copied to dst
7 starting at offset dst_offset in the device data environment of device dst_device_num.
8 The omp_target_memcpy_async routine executes as if part of a target task that is generated
9 by the call to the routine and for which execution may be deferred.
10 Task dependences are expressed with zero or more omp_depend_t objects. The dependences are
11 specified by passing the number of omp_depend_t objects followed by an array of
12 omp_depend_t objects. The generated target task is not a dependent task if the program passes
13 in a count of zero for depobj_count. depojb_list is ignored if the value of depobj_count is zero.
Fortran
16 The omp_target_memcpy_async routine requires an explicit interface and so might not be
Fortran

21 Tool Callbacks
31 Restrictions
32 Restrictions to the omp_target_memcpy_async routine are as follows.

1 Cross References
3 • Depend objects, see Section 2.19.10.
7 3.8.8 omp_target_memcpy_rect_async
8 Summary
9 The omp_target_memcpy_rect_async routine asynchronously performs a copy between
10 any combination of host and device pointers.
11 Format
C / C++
12 int omp_target_memcpy_rect_async(
13 void *dst,
14 const void *src,
15 size_t element_size,
16 int num_dims,
17 const size_t *volume,
18 const size_t *dst_offsets,
19 const size_t *src_offsets,
20 const size_t *dst_dimensions,
21 const size_t *src_dimensions,
24 int depobj_count,
25 omp_depend_t *depobj_list
26 );
C / C++
Fortran
27 integer(c_int) function omp_target_memcpy_rect_async(dst, src, &
28 element_size, num_dims, volume, dst_offsets, src_offsets, &
29 dst_dimensions, src_dimensions, dst_device_num, src_device_num, &
30 depobj_count, depobj_list) bind(c)
33 integer(c_size_t), value :: element_size
34 integer(c_int), value :: num_dims, dst_device_num, src_device_num, &
35 depobj_count

1 integer(c_size_t), intent(in) :: volume(*), dst_offsets(*), &
2 src_offsets(*), dst_dimensions(*), src_dimensions(*)
3 integer(omp_depobj_kind), optional :: depobj_list(*)
Fortran
8 The length of the offset and dimension arrays must be at least the value of num_dims. The value of
9 num_dims must be between 1 and the implementation-defined limit, which must be at least three.
Fortran
10 Because the interface binds directly to a C language function the function assumes C memory
11 ordering.
Fortran
12 Binding
13 The binding task set for an omp_target_memcpy_rect_async region is the generating task,
14 which is the target task generated by the call to the omp_target_memcpy_rect_async
15 routine.
16 Effect
17 This routine copies a rectangular subvolume of src, in the device data environment of device
18 src_device_num, to dst, in the device data environment of device dst_device_num. The volume is
19 specified in terms of the size of an element, number of dimensions, and constant arrays of length
20 num_dims. The maximum number of dimensions supported is at least three; support for higher
21 dimensionality is implementation defined. The volume array specifies the length, in number of
22 elements, to copy in each dimension from src to dst. The dst_offsets (src_offsets) parameter
23 specifies the number of elements from the origin of dst (src) in elements. The dst_dimensions
24 (src_dimensions) parameter specifies the length of each dimension of dst (src).
25 The omp_target_memcpy_rect_async routine executes as if part of a target task that is
26 generated by the call to the routine and for which execution may be deferred.
27 Task dependences are expressed with zero or more omp_depend_t objects. The dependences are
28 specified by passing the number of omp_depend_t objects followed by an array of
29 omp_depend_t objects. The generated target task is not a dependent task if the program passes
30 in a count of zero for depobj_count. depobj_list is ignored if the value of depobj_count is zero.
33 An application can determine the number of inclusive dimensions supported by an implementation
34 by passing NULL pointers (or C_NULL_PTR, for Fortran) for both dst and src. The routine returns

1 the number of dimensions supported by the implementation for the specified device numbers. No
2 copy operation is performed.
Fortran
3 The omp_target_memcpy_rect_async routine requires an explicit interface and so might
4 not be provided in omp_lib.h.
Fortran

8 Tool Callbacks
18 Restrictions
19 Restrictions to the omp_target_memcpy_rect_async routine are as follows.
21 Cross References
23 • Depend objects, see Section 2.19.10.
27 3.8.9 omp_target_associate_ptr
28 Summary
29 The omp_target_associate_ptr routine maps a device pointer, which may be returned
30 from omp_target_alloc or implementation-defined runtime routines, to a host pointer.

1 Format
C / C++
2 int omp_target_associate_ptr(
3 const void *host_ptr,
4 const void *device_ptr,
5 size_t size,
6 size_t device_offset,
7 int device_num
8 );
C / C++
Fortran
9 integer(c_int) function omp_target_associate_ptr(host_ptr, &
10 device_ptr, size, device_offset, device_num) bind(c)
12 type(c_ptr), value :: host_ptr, device_ptr
13 integer(c_size_t), value :: size, device_offset
Fortran
16 The value of device_ptr value must be a valid pointer to device memory for the device denoted by
17 the value of device_num. The device_num argument must be greater than or equal to zero and less
18 than or equal to the result of omp_get_num_devices().
19 Binding
20 The binding task set for an omp_target_associate_ptr region is the generating task, which
21 is the target task generated by the call to the omp_target_associate_ptr routine.
22 Effect
23 The omp_target_associate_ptr routine associates a device pointer in the device data
24 environment of device device_num with a host pointer such that when the host pointer appears in a
25 subsequent map clause, the associated device pointer is used as the target for data motion
26 associated with that host pointer. The device_offset parameter specifies the offset into device_ptr
27 that is used as the base address for the device side of the mapping. The reference count of the
28 resulting mapping will be infinite. After being successfully associated, the buffer to which the
29 device pointer points is invalidated and accessing data directly through the device pointer results in
30 unspecified behavior. The pointer can be retrieved for other uses by using the
31 omp_target_disassociate_ptr routine to disassociate it .
32 The omp_target_associate_ptr routine executes as if part of a target task that is generated
33 by the call to the routine and that is an included task.
34 The routine returns zero if successful. Otherwise it returns a non-zero value.

1 Only one device buffer can be associated with a given host pointer value and device number pair.
2 Attempting to associate a second buffer will return non-zero. Associating the same pair of pointers
3 on the same device with the same offset has no effect and returns zero. Associating pointers that
4 share underlying storage will result in unspecified behavior. The omp_target_is_present
5 function can be used to test whether a given host pointer has a corresponding variable in the device
6 data environment.
Fortran
7 The omp_target_associate_ptr routine requires an explicit interface and so might not be
Fortran

10 The target-data-associate event occurs before a thread initiates a device pointer association on a
11 target device.
12 Tool Callbacks
15 endpoint argument for each occurrence of a target-data-associate event in that thread. These
18 Restrictions
19 Restrictions to the omp_target_associate_ptr routine are as follows.
21 Cross References
25 • omp_target_alloc routine, see Section 3.8.1.
26 • omp_target_is_present routine, see Section 3.8.3.
27 • omp_target_disassociate_ptr routine, see Section 3.8.10.
28 • omp_get_mapped_ptr routine, see Section 3.8.11.

1 3.8.10 omp_target_disassociate_ptr
2 Summary
3 The omp_target_disassociate_ptr removes the associated pointer for a given device
4 from a host pointer.
5 Format
C / C++
6 int omp_target_disassociate_ptr(const void *ptr, int device_num);
C / C++
Fortran
7 integer(c_int) function omp_target_disassociate_ptr(ptr, &
8 device_num) bind(c)
Fortran
15 Binding
16 The binding task set for an omp_target_disassociate_ptr region is the generating task,
17 which is the target task generated by the call to the omp_target_disassociate_ptr routine.
18 Effect
19 The omp_target_disassociate_ptr removes the associated device data on device
20 device_num from the presence table for host pointer ptr. A call to this routine on a pointer that is
21 not NULL (or C_NULL_PTR, for Fortran) and does not have associated data on the given device
22 results in unspecified behavior. The reference count of the mapping is reduced to zero, regardless of
23 its current value.
24 The omp_target_disassociate_ptr routine executes as if part of a target task that is
25 generated by the call to the routine and that is an included task.
26 The routine returns zero if successful. Otherwise it returns a non-zero value.
27 After a call to omp_target_disassociate_ptr, the contents of the device buffer are
28 invalidated.
Fortran
29 The omp_target_disassociate_ptr routine requires an explicit interface and so might not
30 be provided in omp_lib.h.
Fortran

2 The target-data-disassociate event occurs before a thread initiates a device pointer disassociation
3 on a target device.
4 Tool Callbacks
7 endpoint argument for each occurrence of a target-data-disassociate event in that thread. These
10 Restrictions
11 Restrictions to the omp_target_disassociate_ptr routine are as follows.
13 Cross References
16 • omp_target_associate_ptr routine, see Section 3.8.9.
19 3.8.11 omp_get_mapped_ptr
20 Summary
21 The omp_get_mapped_ptr routine returns the device pointer that is associated with a host
22 pointer for a given device.
23 Format
C / C++
24 void * omp_get_mapped_ptr(const void *ptr, int device_num);
C / C++
Fortran
25 type(c_ptr) function omp_get_mapped_ptr(ptr, &
26 device_num) bind(c)
Fortran

4 Binding
5 The binding task set for an omp_get_mapped_ptr region is the encountering task.
6 Effect
7 The omp_get_mapped_ptr routine returns the associated device pointer on device device_num.
8 A call to this routine for a pointer that is not NULL (or C_NULL_PTR, for Fortran) and does not
9 have an associated pointer on the given device results in a NULL pointer.
10 The routine returns NULL (or C_NULL_PTR, for Fortran) if unsuccessful. Otherwise it returns the
11 device pointer, which is ptr if device_num is the value returned by
12 omp_get_initial_device().
Fortran
13 The omp_get_mapped_ptr routine requires an explicit interface and so might not be provided
14 in omp_lib.h.
Fortran

16 No events are associated with this routine.
17 Restrictions
18 Restrictions to the omp_get_mapped_ptr routine are as follows.
20 Cross References

1 3.9 Lock Routines
2 The OpenMP runtime library includes a set of general-purpose lock routines that can be used for
3 synchronization. These general-purpose lock routines operate on OpenMP locks that are
4 represented by OpenMP lock variables. OpenMP lock variables must be accessed only through the
5 routines described in this section; programs that otherwise access OpenMP lock variables are
6 non-conforming.
7 An OpenMP lock can be in one of the following states: uninitialized; unlocked; or locked. If a lock
8 is in the unlocked state, a task can set the lock, which changes its state to locked. The task that sets
9 the lock is then said to own the lock. A task that owns a lock can unset that lock, returning it to the
10 unlocked state. A program in which a task unsets a lock that is owned by another task is
11 non-conforming.
12 Two types of locks are supported: simple locks and nestable locks. A nestable lock can be set
13 multiple times by the same task before being unset; a simple lock cannot be set if it is already
14 owned by the task trying to set it. Simple lock variables are associated with simple locks and can
15 only be passed to simple lock routines. Nestable lock variables are associated with nestable locks
16 and can only be passed to nestable lock routines.
17 Each type of lock can also have a synchronization hint that contains information about the intended
18 usage of the lock by the application code. The effect of the hint is implementation defined. An
19 OpenMP implementation can use this hint to select a usage-specific lock, but hints do not change
20 the mutual exclusion semantics of locks. A conforming implementation can safely ignore the hint.
21 Constraints on the state and ownership of the lock accessed by each of the lock routines are
22 described with the routine. If these constraints are not met, the behavior of the routine is
23 unspecified.
24 The OpenMP lock routines access a lock variable such that they always read and update the most
25 current value of the lock variable. An OpenMP program does not need to include explicit flush
26 directives to ensure that the lock variable’s value is consistent among different tasks.
27 Binding
28 The binding thread set for all lock routine regions is all threads in the contention group. As a
29 consequence, for each OpenMP lock, the lock routine effects relate to all tasks that call the routines,
30 without regard to which teams in the contention group the threads that are executing the tasks
31 belong.
32 Simple Lock Routines

C / C++
33 The type omp_lock_t represents a simple lock. For the following routines, a simple lock variable
34 must be of omp_lock_t type. All simple lock routines require an argument that is a pointer to a
35 variable of type omp_lock_t.
C / C++

Fortran
1 For the following routines, a simple lock variable must be an integer variable of
2 kind=omp_lock_kind.
Fortran
3 The simple lock routines are as follows:
4 • The omp_init_lock routine initializes a simple lock;
5 • The omp_init_lock_with_hint routine initializes a simple lock and attaches a hint to it;
6 • The omp_destroy_lock routine uninitializes a simple lock;
7 • The omp_set_lock routine waits until a simple lock is available and then sets it;
8 • The omp_unset_lock routine unsets a simple lock; and
9 • The omp_test_lock routine tests a simple lock and sets it if it is available.
10 Nestable Lock Routines

C / C++
11 The type omp_nest_lock_t represents a nestable lock. For the following routines, a nestable
12 lock variable must be of omp_nest_lock_t type. All nestable lock routines require an
13 argument that is a pointer to a variable of type omp_nest_lock_t.
C / C++
Fortran
14 For the following routines, a nestable lock variable must be an integer variable of
15 kind=omp_nest_lock_kind.
Fortran
16 The nestable lock routines are as follows:
17 • The omp_init_nest_lock routine initializes a nestable lock;
18 • The omp_init_nest_lock_with_hint routine initializes a nestable lock and attaches a
19 hint to it;
20 • The omp_destroy_nest_lock routine uninitializes a nestable lock;
21 • The omp_set_nest_lock routine waits until a nestable lock is available and then sets it;
22 • The omp_unset_nest_lock routine unsets a nestable lock; and
23 • The omp_test_nest_lock routine tests a nestable lock and sets it if it is available.
24 Restrictions
25 Restrictions to OpenMP lock routines are as follows:
26 • The use of the same OpenMP lock in different contention groups results in unspecified behavior.

1 3.9.1 omp_init_lock and omp_init_nest_lock
2 Summary
3 These routines initialize an OpenMP lock without a hint.
4 Format
C / C++
5 void omp_init_lock(omp_lock_t *lock);
6 void omp_init_nest_lock(omp_nest_lock_t *lock);
C / C++
Fortran
7 subroutine omp_init_lock(svar)
8 integer (kind=omp_lock_kind) svar
9
10 subroutine omp_init_nest_lock(nvar)
11 integer (kind=omp_nest_lock_kind) nvar
Fortran
13 A program that accesses a lock that is not in the uninitialized state through either routine is
14 non-conforming.
15 Effect
16 The effect of these routines is to initialize the lock to the unlocked state; that is, no task owns the
17 lock. In addition, the nesting count for a nestable lock is set to zero.

19 The lock-init event occurs in a thread that executes an omp_init_lock region after initialization
20 of the lock, but before it finishes the region. The nest-lock-init event occurs in a thread that executes
21 an omp_init_nest_lock region after initialization of the lock, but before it finishes the region.
22 Tool Callbacks
23 A thread dispatches a registered ompt_callback_lock_init callback with
24 omp_sync_hint_none as the hint argument and ompt_mutex_lock as the kind argument
25 for each occurrence of a lock-init event in that thread. Similarly, a thread dispatches a registered
26 ompt_callback_lock_init callback with omp_sync_hint_none as the hint argument
27 and ompt_mutex_nest_lock as the kind argument for each occurrence of a nest-lock-init
28 event in that thread. These callbacks have the type signature
29 ompt_callback_mutex_acquire_t and occur in the task that encounters the routine.
30 Cross References

1 3.9.2 omp_init_lock_with_hint and
2 omp_init_nest_lock_with_hint
3 Summary
4 These routines initialize an OpenMP lock with a hint. The effect of the hint is
5 implementation-defined. The OpenMP implementation can ignore the hint without changing
6 program semantics.
7 Format
C / C++
8 void omp_init_lock_with_hint(
9 omp_lock_t *lock,
10 omp_sync_hint_t hint
11 );
12 void omp_init_nest_lock_with_hint(
13 omp_nest_lock_t *lock,
14 omp_sync_hint_t hint
15 );
C / C++
Fortran
16 subroutine omp_init_lock_with_hint(svar, hint)
18 integer (kind=omp_sync_hint_kind) hint
19
20 subroutine omp_init_nest_lock_with_hint(nvar, hint)
22 integer (kind=omp_sync_hint_kind) hint
Fortran
24 A program that accesses a lock that is not in the uninitialized state through either routine is
25 non-conforming.
26 The second argument passed to these routines (hint) is a hint as described in Section 2.19.12.
27 Effect
28 The effect of these routines is to initialize the lock to the unlocked state and, optionally, to choose a
29 specific lock implementation based on the hint. After initialization no task owns the lock. In
30 addition, the nesting count for a nestable lock is set to zero.

2 The lock-init-with-hint event occurs in a thread that executes an omp_init_lock_with_hint
3 region after initialization of the lock, but before it finishes the region. The nest-lock-init-with-hint
4 event occurs in a thread that executes an omp_init_nest_lock region after initialization of the
5 lock, but before it finishes the region.
6 Tool Callbacks
7 A thread dispatches a registered ompt_callback_lock_init callback with the same value
8 for its hint argument as the hint argument of the call to omp_init_lock_with_hint and
9 ompt_mutex_lock as the kind argument for each occurrence of a lock-init-with-hint event in
10 that thread. Similarly, a thread dispatches a registered ompt_callback_lock_init callback
11 with the same value for its hint argument as the hint argument of the call to
12 omp_init_nest_lock_with_hint and ompt_mutex_nest_lock as the kind argument
13 for each occurrence of a nest-lock-init-with-hint event in that thread. These callbacks have the type
14 signature ompt_callback_mutex_acquire_t and occur in the task that encounters the
15 routine.
16 Cross References
17 • Synchronization Hints, see Section 2.19.12.
19 3.9.3 omp_destroy_lock and

20 omp_destroy_nest_lock
21 Summary
22 These routines ensure that the OpenMP lock is uninitialized.
23 Format
C / C++
24 void omp_destroy_lock(omp_lock_t *lock);
25 void omp_destroy_nest_lock(omp_nest_lock_t *lock);
C / C++
Fortran
26 subroutine omp_destroy_lock(svar)
28
29 subroutine omp_destroy_nest_lock(nvar)
Fortran

2 A program that accesses a lock that is not in the unlocked state through either routine is
3 non-conforming.
4 Effect
5 The effect of these routines is to change the state of the lock to uninitialized.

7 The lock-destroy event occurs in a thread that executes an omp_destroy_lock region before it
8 finishes the region. The nest-lock-destroy event occurs in a thread that executes an
9 omp_destroy_nest_lock region before it finishes the region.
10 Tool Callbacks
11 A thread dispatches a registered ompt_callback_lock_destroy callback with
12 ompt_mutex_lock as the kind argument for each occurrence of a lock-destroy event in that
13 thread. Similarly, a thread dispatches a registered ompt_callback_lock_destroy callback
14 with ompt_mutex_nest_lock as the kind argument for each occurrence of a nest-lock-destroy
15 event in that thread. These callbacks have the type signature ompt_callback_mutex_t and
16 occur in the task that encounters the routine.
17 Cross References
19 3.9.4 omp_set_lock and omp_set_nest_lock

20 Summary
21 These routines provide a means of setting an OpenMP lock. The calling task region behaves as if it
22 was suspended until the lock can be set by this task.
23 Format
C / C++
24 void omp_set_lock(omp_lock_t *lock);
25 void omp_set_nest_lock(omp_nest_lock_t *lock);
C / C++
Fortran
26 subroutine omp_set_lock(svar)
28
29 subroutine omp_set_nest_lock(nvar)
Fortran

2 A program that accesses a lock that is in the uninitialized state through either routine is
3 non-conforming. A simple lock accessed by omp_set_lock that is in the locked state must not
4 be owned by the task that contains the call or deadlock will result.
5 Effect
6 Each of these routines has an effect equivalent to suspension of the task that is executing the routine
7 until the specified lock is available.
8
9 Note – The semantics of these routines is specified as if they serialize execution of the region
10 guarded by the lock. However, implementations may implement them in other ways provided that
11 the isolation properties are respected so that the actual execution delivers a result that could arise
12 from some serialization.
13
14 A simple lock is available if it is unlocked. Ownership of the lock is granted to the task that
15 executes the routine.
16 A nestable lock is available if it is unlocked or if it is already owned by the task that executes the
17 routine. The task that executes the routine is granted, or retains, ownership of the lock, and the
18 nesting count for the lock is incremented.

20 The lock-acquire event occurs in a thread that executes an omp_set_lock region before the
21 associated lock is requested. The nest-lock-acquire event occurs in a thread that executes an
22 omp_set_nest_lock region before the associated lock is requested.
23 The lock-acquired event occurs in a thread that executes an omp_set_lock region after it
24 acquires the associated lock but before it finishes the region. The nest-lock-acquired event occurs in
25 a thread that executes an omp_set_nest_lock region if the thread did not already own the
26 lock, after it acquires the associated lock but before it finishes the region.
27 The nest-lock-owned event occurs in a thread when it already owns the lock and executes an
28 omp_set_nest_lock region. The event occurs after the nesting count is incremented but
29 before the thread finishes the region.
30 Tool Callbacks
32 occurrence of a lock-acquire or nest-lock-acquire event in that thread. This callback has the type
33 signature ompt_callback_mutex_acquire_t.
35 occurrence of a lock-acquired or nest-lock-acquired event in that thread. This callback has the type
36 signature ompt_callback_mutex_t.

1 A thread dispatches a registered ompt_callback_nest_lock callback with
2 ompt_scope_begin as its endpoint argument for each occurrence of a nest-lock-owned event in
3 that thread. This callback has the type signature ompt_callback_nest_lock_t.
4 The above callbacks occur in the task that encounters the lock function. The kind argument of these
5 callbacks is ompt_mutex_lock when the events arise from an omp_set_lock region while it
6 is ompt_mutex_nest_lock when the events arise from an omp_set_nest_lock region.
7 Cross References
10 • ompt_callback_nest_lock_t, see Section 4.5.2.16.
11 3.9.5 omp_unset_lock and omp_unset_nest_lock

12 Summary
13 These routines provide the means of unsetting an OpenMP lock.
14 Format
C / C++
15 void omp_unset_lock(omp_lock_t *lock);
16 void omp_unset_nest_lock(omp_nest_lock_t *lock);
C / C++
Fortran
17 subroutine omp_unset_lock(svar)
19
20 subroutine omp_unset_nest_lock(nvar)
Fortran
23 A program that accesses a lock that is not in the locked state or that is not owned by the task that
24 contains the call through either routine is non-conforming.
25 Effect
26 For a simple lock, the omp_unset_lock routine causes the lock to become unlocked.
27 For a nestable lock, the omp_unset_nest_lock routine decrements the nesting count, and
28 causes the lock to become unlocked if the resulting nesting count is zero.
29 For either routine, if the lock becomes unlocked, and if one or more task regions were effectively
30 suspended because the lock was unavailable, the effect is that one task is chosen and given
31 ownership of the lock.

2 The lock-release event occurs in a thread that executes an omp_unset_lock region after it
3 releases the associated lock but before it finishes the region. The nest-lock-release event occurs in a
4 thread that executes an omp_unset_nest_lock region after it releases the associated lock but
5 before it finishes the region.
6 The nest-lock-held event occurs in a thread that executes an omp_unset_nest_lock region
7 before it finishes the region when the thread still owns the lock after the nesting count is
8 decremented.
9 Tool Callbacks
11 ompt_mutex_lock as the kind argument for each occurrence of a lock-release event in that
12 thread. Similarly, a thread dispatches a registered ompt_callback_mutex_released
13 callback with ompt_mutex_nest_lock as the kind argument for each occurrence of a
14 nest-lock-release event in that thread. These callbacks have the type signature
15 ompt_callback_mutex_t and occur in the task that encounters the routine.
17 ompt_scope_end as its endpoint argument for each occurrence of a nest-lock-held event in that
18 thread. This callback has the type signature ompt_callback_nest_lock_t.
19 Cross References
22 3.9.6 omp_test_lock and omp_test_nest_lock

23 Summary
24 These routines attempt to set an OpenMP lock but do not suspend execution of the task that
25 executes the routine.
26 Format
C / C++
27 int omp_test_lock(omp_lock_t *lock);
28 int omp_test_nest_lock(omp_nest_lock_t *lock);
C / C++
Fortran
29 logical function omp_test_lock(svar)
31
32 integer function omp_test_nest_lock(nvar)
Fortran

2 A program that accesses a lock that is in the uninitialized state through either routine is
3 non-conforming. The behavior is unspecified if a simple lock accessed by omp_test_lock is in
4 the locked state and is owned by the task that contains the call.
5 Effect
6 These routines attempt to set a lock in the same manner as omp_set_lock and
7 omp_set_nest_lock, except that they do not suspend execution of the task that executes the
8 routine.
9 For a simple lock, the omp_test_lock routine returns true if the lock is successfully set;
11 For a nestable lock, the omp_test_nest_lock routine returns the new nesting count if the lock
12 is successfully set; otherwise, it returns zero.

14 The lock-test event occurs in a thread that executes an omp_test_lock region before the
15 associated lock is tested. The nest-lock-test event occurs in a thread that executes an
16 omp_test_nest_lock region before the associated lock is tested.
17 The lock-test-acquired event occurs in a thread that executes an omp_test_lock region before it
18 finishes the region if the associated lock was acquired. The nest-lock-test-acquired event occurs in a
19 thread that executes an omp_test_nest_lock region before it finishes the region if the
20 associated lock was acquired and the thread did not already own the lock.
21 The nest-lock-owned event occurs in a thread that executes an omp_test_nest_lock region
22 before it finishes the region after the nesting count is incremented if the thread already owned the
23 lock.
24 Tool Callbacks
26 occurrence of a lock-test or nest-lock-test event in that thread. This callback has the type signature
29 occurrence of a lock-test-acquired or nest-lock-test-acquired event in that thread. This callback has
30 the type signature ompt_callback_mutex_t.
32 ompt_scope_begin as its endpoint argument for each occurrence of a nest-lock-owned event in
33 that thread. This callback has the type signature ompt_callback_nest_lock_t.
34 The above callbacks occur in the task that encounters the lock function. The kind argument of these
35 callbacks is ompt_mutex_test_lock when the events arise from an omp_test_lock
36 region while it is ompt_mutex_test_nest_lock when the events arise from an
37 omp_test_nest_lock region.

1 Cross References
5 3.10 Timing Routines

6 This section describes routines that support a portable wall clock timer.
7 3.10.1 omp_get_wtime
8 Summary
9 The omp_get_wtime routine returns elapsed wall clock time in seconds.
10 Format
C / C++
11 double omp_get_wtime(void);
C / C++
Fortran
12 double precision function omp_get_wtime()
Fortran
13 Binding
14 The binding thread set for an omp_get_wtime region is the encountering thread. The routine’s
15 return value is not guaranteed to be consistent across any set of threads.
16 Effect
17 The omp_get_wtime routine returns a value equal to the elapsed wall clock time in seconds
18 since some time-in-the-past. The actual time-in-the-past is arbitrary, but it is guaranteed not to
19 change during the execution of the application program. The time returned is a per-thread time, so
20 it is not required to be globally consistent across all threads that participate in an application.
21 3.10.2 omp_get_wtick
22 Summary
23 The omp_get_wtick routine returns the precision of the timer used by omp_get_wtime.
24 Format
C / C++
25 double omp_get_wtick(void);
C / C++

Fortran
1 double precision function omp_get_wtick()
Fortran
2 Binding
3 The binding thread set for an omp_get_wtick region is the encountering thread. The routine’s
4 return value is not guaranteed to be consistent across any set of threads.
5 Effect
6 The omp_get_wtick routine returns a value equal to the number of seconds between successive
7 clock ticks of the timer used by omp_get_wtime.
8 3.11 Event Routine

9 This section describes a routine that supports OpenMP event objects.
10 Binding
11 The binding thread set for all event routine regions is the encountering thread.
12 3.11.1 omp_fulfill_event
13 Summary
14 This routine fulfills and destroys an OpenMP event.
15 Format
C / C++
16 void omp_fulfill_event(omp_event_handle_t event);
C / C++
Fortran
17 subroutine omp_fulfill_event(event)
18 integer (kind=omp_event_handle_kind) event
Fortran
20 A program that calls this routine on an event that was already fulfilled is non-conforming. A
21 program that calls this routine with an event handle that was not created by the detach clause is
22 non-conforming.
23 Effect
24 The effect of this routine is to fulfill the event associated with the event handle argument. The effect
25 of fulfilling the event will depend on how the event was created. The event is destroyed and cannot
26 be accessed after calling this routine, and the event handle becomes unassociated with any event.

2 The task-fulfill event occurs in a thread that executes an omp_fulfill_event region before the
3 event is fulfilled if the OpenMP event object was created by a detach clause on a task.
4 Tool Callbacks
5 A thread dispatches a registered ompt_callback_task_schedule callback with NULL as its
6 next_task_data argument while the argument prior_task_data binds to the detached task for each
7 occurrence of a task-fulfill event. If the task-fulfill event occurs before the detached task finished the
8 execution of the associated structured-block, the callback has ompt_task_early_fulfill as
9 its prior_task_status argument; otherwise the callback has ompt_task_late_fulfill as its
10 prior_task_status argument. This callback has type signature
11 ompt_callback_task_schedule_t.
12 Cross References
13 • detach clause, see Section 2.12.1.
14 • ompt_callback_task_schedule_t, see Section 4.5.2.10.
C / C++
15 3.12 Interoperability Routines

16 The interoperability routines provide mechanisms to inspect the properties associated with an
17 omp_interop_t object. Such objects may be initialized, destroyed or otherwise used by an
18 interop construct. Additionally, an omp_interop_t object can be initialized to
19 omp_interop_none, which is defined to be zero. An omp_interop_t object may only be
20 accessed or modified through OpenMP directives and API routines.
21 An omp_interop_t object can be copied without affecting, or copying, the underlying state.
22 Destruction of an omp_interop_t object destroys the state to which all copies of the object refer.
23 OpenMP reserves all negative values for properties, as listed in Table 3.1; implementation-defined
24 properties may use zero and positive values. The special property, omp_ipr_first, will always
25 have the lowest property value which may change in future versions of this specification. Valid
26 values and types for the properties that Table 3.1 lists are specified in the OpenMP Additional
27 Definitions document or are implementation defined unless otherwise specified.
28 Table 3.2 lists the return codes used by routines that take an int* ret_code argument.
29 Binding
30 The binding task set for all interoperability routine regions is the generating task.

C/C++ (cont.)
TABLE 3.1: Required Values of the omp_interop_property_t enum Type
enum name contexts name property

An intptr_t value that
omp_ipr_fr_id = -1 all fr_id represents the foreign runtime
id of context
C string value that represents the
omp_ipr_fr_name = -2 all fr_name
foreign runtime name of context
An intptr_t that represents
omp_ipr_vendor = -3 all vendor
the vendor of context
omp_ipr_vendor_name = C string value that represents the
all vendor_name
-4 vendor of context
The OpenMP device ID for
the device in the range 0 to
omp_ipr_device_num = -5 all device_num
omp_get_num_devices()
inclusive
A foreign platform handle
omp_ipr_platform = -6 target platform usually spanning multiple
devices
omp_ipr_device = -7 target device A foreign device handle
omp_ipr_device_context A handle to an instance of a
target device_context
= -8 foreign device context
A handle to a synchronization
omp_ipr_targetsync = -9 targetsync targetsync object of a foreign execution
context
omp_ipr_first = -9

C/C++ (cont.)
TABLE 3.2: Required Values for the omp_interop_rc_t enum Type
enum name description

omp_irc_no_value = 1 Parameters valid, no meaningful value available
omp_irc_success = 0 Successful, value is usable
omp_irc_empty = -1 The object provided is equal to omp_interop_none
omp_irc_out_of_range = -2 Property ID is out of range, see Table 3.1
omp_irc_type_int = -3 Property type is int; use omp_get_interop_int
omp_irc_type_ptr = -4 Property type is pointer; use omp_get_interop_ptr
omp_irc_type_str = -5 Property type is string; use omp_get_interop_str
omp_irc_other = -6 Other error; use omp_get_interop_rc_desc
1 3.12.1 omp_get_num_interop_properties
2 Summary
3 The omp_get_num_interop_properties routine retrieves the number of
4 implementation-defined properties available for an omp_interop_t object.
5 Format
6 int omp_get_num_interop_properties(const omp_interop_t interop);
7 Effect
8 The omp_get_num_interop_properties routine returns the number of
9 implementation-defined properties available for interop. The total number of properties available
10 for interop is the returned value minus omp_ipr_first.
11 Cross References
12 • interop construct, see Section 2.15.1.
13 3.12.2 omp_get_interop_int
14 Summary
15 The omp_get_interop_int routine retrieves an integer property from an omp_interop_t
16 object.
17 Format
18 omp_intptr_t omp_get_interop_int(const omp_interop_t interop,
19 omp_interop_property_t property_id,
20 int *ret_code);

C/C++ (cont.)
1 Effect
2 The omp_get_interop_int routine returns the requested integer property, if available, and
3 zero if an error occurs or no value is available.
4 If the interop is omp_interop_none, an empty error occurs.
5 If the property_id is smaller than omp_ipr_first or not smaller than
6 omp_get_num_interop_properties(interop), an out of range error occurs.
7 If the requested property value is not convertible into an integer value, a type error occurs.
8 If a non-null pointer is passed to ret_code, an omp_interop_rc_t value that indicates the
9 return code is stored in the object to which ret_code points. If an error occurred, the stored value
10 will be negative and it will match the error as defined in Table 3.2. On success, zero will be stored.
11 If no error occurred but no meaningful value can be returned, omp_irc_no_value, which is
12 one, will be stored.
13 Restrictions
14 Restrictions to the omp_get_interop_int routine are as follows:
15 • The behavior of the routine is unspecified if an invalid omp_interop_t object is provided.
16 Cross References
18 • omp_get_num_interop_properties routine, see Section 3.12.1.
19 3.12.3 omp_get_interop_ptr
20 Summary
21 The omp_get_interop_ptr routine retrieves a pointer property from an omp_interop_t
22 object.
23 Format
24 void* omp_get_interop_ptr(const omp_interop_t interop,
26 int *ret_code);
27 Effect
28 The omp_get_interop_ptr routine returns the requested pointer property, if available, and
29 NULL if an error occurs or no value is available.
33 If the requested property value is not convertible into a pointer value, a type error occurs.

C/C++ (cont.)

2 return code is stored in the object to which the ret_code points. If an error occurred, the stored
3 value will be negative and it will match the error as defined in Table 3.2. On success, zero will be
4 stored. If no error occurred but no meaningful value can be returned, omp_irc_no_value,
5 which is one, will be stored.
6 Restrictions
7 Restrictions to the omp_get_interop_ptr routine are as follows:
9 • Memory referenced by the pointer returned by the omp_get_interop_ptr routine is
10 managed by the OpenMP implementation and should not be freed or modified.
11 Cross References
14 3.12.4 omp_get_interop_str
15 Summary
16 The omp_get_interop_str routine retrieves a string property from an omp_interop_t
17 object.
18 Format
19 const char* omp_get_interop_str(const omp_interop_t interop,
21 int *ret_code);
22 Effect
23 The omp_get_interop_str routine returns the requested string property as a C string, if
24 available, and NULL if an error occurs or no value is available.
28 If the requested property value is not convertible into a string value, a type error occurs.
30 return code is stored in the object to which the ret_code points. If an error occurred, the stored
31 value will be negative and it will match the error as defined in Table 3.2. On success, zero will be
32 stored. If no error occurred but no meaningful value can be returned, omp_irc_no_value,
33 which is one, will be stored.

C/C++ (cont.)
1 Restrictions
2 Restrictions to the omp_get_interop_str routine are as follows:
4 • Memory referenced by the pointer returned by the omp_get_interop_str routine is
6 Cross References
9 3.12.5 omp_get_interop_name
10 Summary
11 The omp_get_interop_name routine retrieves a property name from an omp_interop_t
12 object.
13 Format
14 const char* omp_get_interop_name(const omp_interop_t interop,
15 omp_interop_property_t property_id)
16 ;
17 Effect
18 The omp_get_interop_name routine returns the name of the property identified by
19 property_id as a C string.
20 Property names for non-implementation defined properties are listed in Table 3.1.
22 omp_get_num_interop_properties(interop), NULL is returned.
23 Restrictions
24 Restrictions to the omp_get_interop_name routine are as follows:
25 • The behavior of the routine is unspecified if an invalid object is provided.
26 • Memory referenced by the pointer returned by the omp_get_interop_name routine is
28 Cross References

C/C++ (cont.)
1 3.12.6 omp_get_interop_type_desc
2 Summary
3 The omp_get_interop_type_desc routine retrieves a description of the type of a property
4 associated with an omp_interop_t object.
5 Format
6 const char* omp_get_interop_type_desc(const omp_interop_t interop,
7 omp_interop_property_t
8 property_id);
9 Effect
10 The omp_get_interop_type_desc routine returns a C string that describes the type of the
11 property identified by property_id in human-readable form. That may contain a valid C type
12 declaration possibly followed by a description or name of the type.
13 If interop has the value omp_interop_none, NULL is returned.
15 omp_get_num_interop_properties(interop), NULL is returned.
16 Restrictions
17 Restrictions to the omp_get_interop_type_desc routine are as follows:
18 • The behavior of the routine is unspecified if an invalid object is provided.
19 • Memory referenced by the pointer returned from the omp_get_interop_type_desc
20 routine is managed by the OpenMP implementation and should not be freed or modified.
21 Cross References
24 3.12.7 omp_get_interop_rc_desc
25 Summary
26 The omp_get_interop_rc_desc routine retrieves a description of the return code associated
27 with an omp_interop_t object.
28 Format
29 const char* omp_get_interop_rc_desc(const omp_interop_t interop,
30 omp_interop_rc_t ret_code);
31 Effect
32 The omp_get_interop_rc_desc routine returns a C string that describes the return code
33 ret_code in human-readable form.

1 Restrictions
2 Restrictions to the omp_get_interop_rc_desc routine are as follows:
3 • The behavior of the routine is unspecified if an invalid object is provided or if ret_code was not
4 last written by an interoperability routine invoked with the omp_interop_t object interop.
5 • Memory referenced by the pointer returned by the omp_get_interop_rc_desc routine is
7 Cross References
C / C++
10 3.13 Memory Management Routines

11 This section describes routines that support memory management on the current device.
12 Instances of memory management types must be accessed only through the routines described in
13 this section; programs that otherwise access instances of these types are non-conforming.
14 3.13.1 Memory Management Types

15 The following type definitions are used by the memory management routines:
C / C++
16 typedef enum omp_alloctrait_key_t {
17 omp_atk_sync_hint = 1,
18 omp_atk_alignment = 2,
19 omp_atk_access = 3,
20 omp_atk_pool_size = 4,
21 omp_atk_fallback = 5,
22 omp_atk_fb_data = 6,
23 omp_atk_pinned = 7,
24 omp_atk_partition = 8
25 } omp_alloctrait_key_t;
26
27 typedef enum omp_alloctrait_value_t {
28 omp_atv_false = 0,
29 omp_atv_true = 1,
30 omp_atv_contended = 3,
31 omp_atv_uncontended = 4,
32 omp_atv_serialized = 5,

1 omp_atv_sequential = omp_atv_serialized, // (deprecated)
2 omp_atv_private = 6,
3 omp_atv_all = 7,
4 omp_atv_thread = 8,
5 omp_atv_pteam = 9,
6 omp_atv_cgroup = 10,
7 omp_atv_default_mem_fb = 11,
8 omp_atv_null_fb = 12,
9 omp_atv_abort_fb = 13,
10 omp_atv_allocator_fb = 14,
11 omp_atv_environment = 15,
12 omp_atv_nearest = 16,
13 omp_atv_blocked = 17,
14 omp_atv_interleaved = 18
15 } omp_alloctrait_value_t;
16
17 typedef struct omp_alloctrait_t {
18 omp_alloctrait_key_t key;
19 omp_uintptr_t value;
20 } omp_alloctrait_t;
C / C++
Fortran
21
22 integer(kind=omp_alloctrait_key_kind), &
23 parameter :: omp_atk_sync_hint = 1
25 parameter :: omp_atk_alignment = 2
27 parameter :: omp_atk_access = 3
29 parameter :: omp_atk_pool_size = 4
31 parameter :: omp_atk_fallback = 5
33 parameter :: omp_atk_fb_data = 6
35 parameter :: omp_atk_pinned = 7
37 parameter :: omp_atk_partition = 8
38
39 integer(kind=omp_alloctrait_val_kind), &
40 parameter :: omp_atv_default = -1

Fortran (cont.)
1 parameter :: omp_atv_false = 0
3 parameter :: omp_atv_true = 1
5 parameter :: omp_atv_contended = 3
7 parameter :: omp_atv_uncontended = 4
9 parameter :: omp_atv_serialized = 5
11 parameter :: omp_atv_sequential = &
12 omp_atv_serialized ! (deprecated)
14 parameter :: omp_atv_private = 6
16 parameter :: omp_atv_all = 7
18 parameter :: omp_atv_thread = 8
20 parameter :: omp_atv_pteam = 9
22 parameter :: omp_atv_cgroup = 10
24 parameter :: omp_atv_default_mem_fb = 11
26 parameter :: omp_atv_null_fb = 12
28 parameter :: omp_atv_abort_fb = 13
30 parameter :: omp_atv_allocator_fb = 14
32 parameter :: omp_atv_environment = 15
34 parameter :: omp_atv_nearest = 16
36 parameter :: omp_atv_blocked = 17
38 parameter :: omp_atv_interleaved = 18
39
40 ! omp_alloctrait might not be provided in omp_lib.h.
41 type omp_alloctrait
42 integer(kind=omp_alloctrait_key_kind) key
43 integer(kind=omp_alloctrait_val_kind) value

1 end type omp_alloctrait
2
3 integer(kind=omp_allocator_handle_kind), &
4 parameter :: omp_null_allocator = 0
Fortran
5 3.13.2 omp_init_allocator
6 Summary
7 The omp_init_allocator routine initializes an allocator and associates it with a memory
8 space.
9 Format
C / C++
10 omp_allocator_handle_t omp_init_allocator (
11 omp_memspace_handle_t memspace,
12 int ntraits,
13 const omp_alloctrait_t traits[]
14 );
C / C++
Fortran
15 integer(kind=omp_allocator_handle_kind) &
16 function omp_init_allocator ( memspace, ntraits, traits )
17 integer(kind=omp_memspace_handle_kind),intent(in) :: memspace
18 integer,intent(in) :: ntraits
19 type(omp_alloctrait),intent(in) :: traits(*)
Fortran
21 The memspace argument must be one of the predefined memory spaces defined in Table 2.8.
22 If the ntraits argument is greater than zero then the traits argument must specify at least that many
23 traits. If it specifies fewer than ntraits traits the behavior is unspecified.
24 Binding
25 The binding thread set for an omp_init_allocator region is all threads on a device. The
26 effect of executing this routine is not related to any specific region that corresponds to any construct
27 or API routine.

1 Effect
2 The omp_init_allocator routine creates a new allocator that is associated with the
3 memspace memory space and returns a handle to it. All allocations through the created allocator
4 will behave according to the allocator traits specified in the traits argument. The number of traits in
5 the traits argument is specified by the ntraits argument. Specifying the same allocator trait more
6 than once results in unspecified behavior. The routine returns a handle for the created allocator. If
7 the special omp_atv_default value is used for a given trait, then its value will be the default
8 value specified in Table 2.9 for that given trait.
9 If memspace is omp_default_mem_space and the traits argument is an empty set this
10 routine will always return a handle to an allocator. Otherwise if an allocator based on the
11 requirements cannot be created then the special omp_null_allocator handle is returned.
12 Restrictions
13 The restrictions to the omp_init_allocator routine are as follows:
14 • The use of an allocator returned by this routine on a device other than the one on which it was
15 created results in unspecified behavior.
16 • Unless a requires directive with the dynamic_allocators clause is present in the same
17 compilation unit, using this routine in a target region results in unspecified behavior.
18 Cross References
19 • Memory Spaces, see Section 2.13.1.
20 • Memory Allocators, see Section 2.13.2.
21 3.13.3 omp_destroy_allocator
22 Summary
23 The omp_destroy_allocator routine releases all resources used by the allocator handle.
24 Format
C / C++
25 void omp_destroy_allocator (omp_allocator_handle_t allocator);
C / C++
Fortran
26 subroutine omp_destroy_allocator ( allocator )
27 integer(kind=omp_allocator_handle_kind),intent(in) :: allocator
Fortran
29 The allocator argument must not represent a predefined memory allocator.

1 Binding
2 The binding thread set for an omp_destroy_allocator region is all threads on a device. The
3 effect of executing this routine is not related to any specific region that corresponds to any construct
4 or API routine.
5 Effect
6 The omp_destroy_allocator routine releases all resources used to implement the allocator
7 handle.
8 If allocator is omp_null_allocator then this routine will have no effect.
9 Restrictions
10 The restrictions to the omp_destroy_allocator routine are as follows:
11 • Accessing any memory allocated by the allocator after this call results in unspecified behavior.
12 • Unless a requires directive with the dynamic_allocators clause is present in the same
13 compilation unit, using this routine in a target region results in unspecified behavior.
14 Cross References
16 3.13.4 omp_set_default_allocator
17 Summary
18 The omp_set_default_allocator routine sets the default memory allocator to be used by
19 allocation calls, allocate directives and allocate clauses that do not specify an allocator.
20 Format
C / C++
21 void omp_set_default_allocator (omp_allocator_handle_t allocator);
C / C++
Fortran
22 subroutine omp_set_default_allocator ( allocator )
23 integer(kind=omp_allocator_handle_kind),intent(in) :: allocator
Fortran
25 The allocator argument must be a valid memory allocator handle.
26 Binding
27 The binding task set for an omp_set_default_allocator region is the binding implicit task.

1 Effect
2 The effect of this routine is to set the value of the def-allocator-var ICV of the binding implicit task
3 to the value specified in the allocator argument.
4 Cross References
5 • def-allocator-var ICV, see Section 2.4.
7 • omp_alloc routine, see Section 3.13.6.
8 3.13.5 omp_get_default_allocator
9 Summary
10 The omp_get_default_allocator routine returns a handle to the memory allocator to be
11 used by allocation calls, allocate directives and allocate clauses that do not specify an
12 allocator.
13 Format
C / C++
14 omp_allocator_handle_t omp_get_default_allocator (void);
C / C++
Fortran
15 integer(kind=omp_allocator_handle_kind)&
16 function omp_get_default_allocator ()
Fortran
17 Binding
18 The binding task set for an omp_get_default_allocator region is the binding implicit task.
19 Effect
20 The effect of this routine is to return the value of the def-allocator-var ICV of the binding implicit
21 task.
22 Cross References
25 • omp_alloc routine, see Section 3.13.6.

1 3.13.6 omp_alloc and omp_aligned_alloc
2 Summary
3 The omp_alloc and omp_aligned_alloc routines request a memory allocation from a
4 memory allocator.
5 Format
C
6 void *omp_alloc(size_t size, omp_allocator_handle_t allocator);
7 void *omp_aligned_alloc(
8 size_t alignment,
9 size_t size,
10 omp_allocator_handle_t allocator);
C
C++
11 void *omp_alloc(
12 size_t size,
13 omp_allocator_handle_t allocator=omp_null_allocator
14 );
15 void *omp_aligned_alloc(
16 size_t alignment,
17 size_t size,
19 );
C++
Fortran
20 type(c_ptr) function omp_alloc(size, allocator) bind(c)
21 use, intrinsic :: iso_c_binding, only : c_ptr, c_size_t
23 integer(omp_allocator_handle_kind), value :: allocator
24
25 type(c_ptr) function omp_aligned_alloc(alignment, &
26 size, allocator) bind(c)
28 integer(c_size_t), value :: alignment, size
Fortran

2 Unless dynamic_allocators appears on a requires directive in the same compilation unit,
3 omp_alloc and omp_aligned_alloc invocations that appear in target regions must not
4 pass omp_null_allocator as the allocator argument, which must be a constant expression
5 that evaluates to one of the predefined memory allocator values.
6 The alignment argument to omp_aligned_alloc must be a power of two and the size argument
7 must be a multiple of alignment.
8 Binding
9 The binding task set for an omp_alloc or omp_aligned_alloc region is the generating task.
10 Effect
11 The omp_alloc and omp_aligned_alloc routines request a memory allocation of size bytes
12 from the specified memory allocator. If the allocator argument is omp_null_allocator the
13 memory allocator used by the routines will be the one specified by the def-allocator-var ICV of the
14 binding implicit task. Upon success they return a pointer to the allocated memory. Otherwise, the
15 behavior that the fallback trait of the allocator specifies will be followed.
16 If size is 0, omp_alloc and omp_aligned_alloc will return NULL (or, C_NULL_PTR, for
17 Fortran).
18 Memory allocated by omp_alloc will be byte-aligned to at least the maximum of the alignment
19 required by malloc and the alignment trait of the allocator.
20 Memory allocated by omp_aligned_alloc will be byte-aligned to at least the maximum of the
21 alignment required by malloc, the alignment trait of the allocator and the alignment argument
22 value.
Fortran
23 The omp_alloc and omp_aligned_alloc routines require an explicit interface and so might
24 not be provided in omp_lib.h.
Fortran
25 Cross References
27 3.13.7 omp_free
28 Summary
29 The omp_free routine deallocates previously allocated memory.
30 Format
C
31 void omp_free (void *ptr, omp_allocator_handle_t allocator);
C

C++
1 void omp_free(
2 void *ptr,
4 );
C++
Fortran
5 subroutine omp_free(ptr, allocator) bind(c)
6 use, intrinsic :: iso_c_binding, only : c_ptr
Fortran
9 Binding
10 The binding task set for an omp_free region is the generating task.
11 Effect
12 The omp_free routine deallocates the memory to which ptr points. The ptr argument must have
13 been returned by an OpenMP allocation routine. If the allocator argument is specified it must be
14 the memory allocator to which the allocation request was made. If the allocator argument is
15 omp_null_allocator the implementation will determine that value automatically.
16 If ptr is NULL (or, C_NULL_PTR, for Fortran), no operation is performed.
Fortran
17 The omp_free routine requires an explicit interface and so might not be provided in
18 omp_lib.h.
Fortran
19 Restrictions
20 The restrictions to the omp_free routine are as follows:
21 • Using omp_free on memory that was already deallocated or that was allocated by an allocator
22 that has already been destroyed with omp_destroy_allocator results in unspecified
23 behavior.
24 Cross References

1 3.13.8 omp_calloc and omp_aligned_calloc
2 Summary
3 The omp_calloc and omp_aligned_calloc routines request a zero initialized memory
4 allocation from a memory allocator.
5 Format
C
6 void *omp_calloc(
7 size_t nmemb,
8 size_t size,
9 omp_allocator_handle_t allocator
10 );
11 void *omp_aligned_calloc(
13 size_t nmemb,
14 size_t size,
15 omp_allocator_handle_t allocator
16 );
C
C++
17 void *omp_calloc(
18 size_t nmemb,
19 size_t size,
21 );
22 void *omp_aligned_calloc(
24 size_t nmemb,
25 size_t size,
27 );
C++

Fortran
1 type(c_ptr) function omp_calloc(nmemb, size, allocator) bind(c)
3 integer(c_size_t), value :: nmemb, size
5
6 type(c_ptr) function omp_aligned_calloc(alignment, nmemb, size, &
7 allocator) bind(c)
9 integer(c_size_t), value :: alignment, nmemb, size
Fortran
12 Unless dynamic_allocators appears on a requires directive in the same compilation unit,
13 omp_calloc and omp_aligned_calloc invocations that appear in target regions must
14 not pass omp_null_allocator as the allocator argument, which must be a constant expression
15 that evaluates to one of the predefined memory allocator values.
16 The alignment argument to omp_aligned_calloc must be a power of two and the size
17 argument must be a multiple of alignment.
18 Binding
19 The binding task set for an omp_calloc or omp_aligned_calloc region is the generating
20 task.
21 Effect
22 The omp_calloc and omp_aligned_calloc routines request a memory allocation from the
23 specified memory allocator for an array of nmemb elements each of which has a size of size bytes.
24 If the allocator argument is omp_null_allocator the memory allocator used by the routines
25 will be the one specified by the def-allocator-var ICV of the binding implicit task. Upon success
26 they return a pointer to the allocated memory. Otherwise, the behavior that the fallback trait of
27 the allocator specifies will be followed. Any memory allocated by these routines will be set to zero
28 before returning.
29 If either nmemb or size is 0, omp_calloc will return NULL (or, C_NULL_PTR, for Fortran).
30 Memory allocated by omp_calloc will be byte-aligned to at least the maximum of the alignment
31 required by malloc and the alignment trait of the allocator.
32 Memory allocated by omp_aligned_calloc will be byte-aligned to at least the maximum of
33 the alignment required by malloc, the alignment trait of the allocator and the alignment
34 argument value.

Fortran
1 The omp_calloc and omp_aligned_calloc routines require an explicit interface and so
2 might not be provided in omp_lib.h.
Fortran
3 Cross References
5 3.13.9 omp_realloc
6 Summary
7 The omp_realloc routine deallocates previously allocated memory and requests a memory
8 allocation from a memory allocator.
9 Format
C
10 void *omp_realloc(
11 void *ptr,
12 size_t size,
13 omp_allocator_handle_t allocator,
14 omp_allocator_handle_t free_allocator
15 );
C
C++
16 void *omp_realloc(
17 void *ptr,
18 size_t size,
19 omp_allocator_handle_t allocator=omp_null_allocator,
20 omp_allocator_handle_t free_allocator=omp_null_allocator
21 );
C++
Fortran
22 type(c_ptr) &
23 function omp_realloc(ptr, size, allocator, free_allocator) bind(c)
27 integer(omp_allocator_handle_kind), value :: allocator, free_allocator
Fortran

2 Unless a dynamic_allocators clause appears on a requires directive in the same
3 compilation unit, omp_realloc invocations that appear in target regions must not pass
4 omp_null_allocator as the allocator or free_allocator argument, which must be constant
5 expressions that evaluate to one of the predefined memory allocator values.
6 Binding
7 The binding task set for an omp_realloc region is the generating task.
8 Effect
9 The omp_realloc routine deallocates the memory to which ptr points and requests a new
10 memory allocation of size bytes from the specified memory allocator. If the free_allocator
11 argument is specified, it must be the memory allocator to which the previous allocation request was
12 made. If the free_allocator argument is omp_null_allocator the implementation will
13 determine that value automatically. If the allocator argument is omp_null_allocator the
14 behavior is as if the memory allocator that allocated the memory to which ptr argument points is
15 passed to the allocator argument. Upon success it returns a (possibly moved) pointer to the
16 allocated memory and the contents of the new object shall be the same as that of the old object
17 prior to deallocation, up to the minimum size of old allocated size and size. Any bytes in the new
18 object beyond the old allocated size will have unspecified values. If the allocation failed, the
19 behavior that the fallback trait of the allocator specifies will be followed.
20 If ptr is NULL (or, C_NULL_PTR, for Fortran), omp_realloc will behave the same as
21 omp_alloc with the same size and allocator arguments.
22 If size is 0, omp_realloc will return NULL (or, C_NULL_PTR, for Fortran) and the old
23 allocation will be deallocated.
24 If size is not 0, the old allocation will be deallocated if and only if the function returns a non-NULL
25 value (or, a non-C_NULL_PTR value, for Fortran).
26 Memory allocated by omp_realloc will be byte-aligned to at least the maximum of the
27 alignment required by malloc and the alignment trait of the allocator.
Fortran
28 The omp_realloc routine requires an explicit interface and so might not be provided in
29 omp_lib.h.
Fortran
30 Restrictions
31 The restrictions to the omp_realloc routine are as follows:
32 • The ptr argument must have been returned by an OpenMP allocation routine.
33 • Using omp_realloc on memory that was already deallocated or that was allocated by an
34 allocator that has already been destroyed with omp_destroy_allocator results in
35 unspecified behavior.

1 Cross References
3 3.14 Tool Control Routine

4 Summary
5 The omp_control_tool routine enables a program to pass commands to an active tool.
6 Format
C / C++
7 int omp_control_tool(int command, int modifier, void *arg);
C / C++
Fortran
8 integer function omp_control_tool(command, modifier)
9 integer (kind=omp_control_tool_kind) command
10 integer modifier
Fortran
12 The following enumeration type defines four standard commands. Table 3.3 describes the actions
13 that these commands request from a tool.
C / C++
14 typedef enum omp_control_tool_t {
15 omp_control_tool_start = 1,
16 omp_control_tool_pause = 2,
17 omp_control_tool_flush = 3,
18 omp_control_tool_end = 4
19 } omp_control_tool_t;
C / C++
Fortran
20 integer (kind=omp_control_tool_kind), &
21 parameter :: omp_control_tool_start = 1
23 parameter :: omp_control_tool_pause = 2
25 parameter :: omp_control_tool_flush = 3
27 parameter :: omp_control_tool_end = 4
Fortran

1 Tool-specific values for command must be greater or equal to 64. Tools must ignore command
2 values that they are not explicitly designed to handle. Other values accepted by a tool for command,
3 and any values for modifier and arg are tool-defined.
TABLE 3.3: Standard Tool Control Commands
Command Action
omp_control_tool_start Start or restart monitoring if it is off. If monitoring

is already on, this command is idempotent. If
monitoring has already been turned off permanently,
this command will have no effect.
omp_control_tool_pause Temporarily turn monitoring off. If monitoring is
already off, it is idempotent.
omp_control_tool_flush Flush any data buffered by a tool. This command may
be applied whether monitoring is on or off.
omp_control_tool_end Turn monitoring off permanently; the tool finalizes
itself and flushes all output.
4 Binding
5 The binding task set for an omp_control_tool region is the generating task.
6 Effect
7 An OpenMP program may use omp_control_tool to pass commands to a tool. An application
8 can use omp_control_tool to request that a tool starts or restarts data collection when a code
9 region of interest is encountered, that a tool pauses data collection when leaving the region of
10 interest, that a tool flushes any data that it has collected so far, or that a tool ends data collection.
11 Additionally, omp_control_tool can be used to pass tool-specific commands to a particular
12 tool.
13 The following types correspond to return values from omp_control_tool:
C / C++
14 typedef enum omp_control_tool_result_t {
15 omp_control_tool_notool = -2,
16 omp_control_tool_nocallback = -1,
17 omp_control_tool_success = 0,
18 omp_control_tool_ignored = 1
19 } omp_control_tool_result_t;
C / C++

Fortran
1 integer (kind=omp_control_tool_result_kind), &
2 parameter :: omp_control_tool_notool = -2
4 parameter :: omp_control_tool_nocallback = -1
6 parameter :: omp_control_tool_success = 0
8 parameter :: omp_control_tool_ignored = 1
Fortran
9 If the OMPT interface state is inactive, the OpenMP implementation returns
10 omp_control_tool_notool. If the OMPT interface state is active, but no callback is
11 registered for the tool-control event, the OpenMP implementation returns
12 omp_control_tool_nocallback. An OpenMP implementation may return other
13 implementation-defined negative values strictly smaller than -64; an application may assume that
14 any negative return value indicates that a tool has not received the command. A return value of
15 omp_control_tool_success indicates that the tool has performed the specified command. A
16 return value of omp_control_tool_ignored indicates that the tool has ignored the specified
17 command. A tool may return other positive values strictly greater than 64 that are tool-defined.

19 The tool-control event occurs in the thread that encounters a call to omp_control_tool at a
20 point inside its corresponding OpenMP region.
21 Tool Callbacks
22 A thread dispatches a registered ompt_callback_control_tool callback for each
23 occurrence of a tool-control event. The callback executes in the context of the call that occurs in the
24 user program and has type signature ompt_callback_control_tool_t. The callback may
25 return any non-negative value, which will be returned to the application by the OpenMP
26 implementation as the return value of the omp_control_tool call that triggered the callback.
27 Arguments passed to the callback are those passed by the user to omp_control_tool. If the
28 call is made in Fortran, the tool will be passed NULL as the third argument to the callback. If any of
29 the four standard commands is presented to a tool, the tool will ignore the modifier and arg
30 argument values.
31 Restrictions
32 Restrictions on access to the state of an OpenMP first-party tool are as follows:
33 • An application may access the tool state modified by an OMPT callback only by using
34 omp_control_tool.

1 Cross References
2 • OMPT Interface, see Chapter 4
3 • ompt_callback_control_tool_t, see Section 4.5.2.29.
4 3.15 Environment Display Routine

5 Summary
6 The omp_display_env routine displays the OpenMP version number and the initial values of
7 ICVs associated with the environment variables described in Chapter 6.
8 Format
C / C++
9 void omp_display_env(int verbose);
C / C++
Fortran
10 subroutine omp_display_env(verbose)
11 logical,intent(in) :: verbose
Fortran
12 Binding
13 The binding thread set for an omp_display_env region is the encountering thread.
14 Effect
15 Each time the omp_display_env routine is invoked, the runtime system prints the OpenMP
16 version number and the initial values of the ICVs associated with the environment variables
17 described in Chapter 6. The displayed values are the values of the ICVs after they have been
18 modified according to the environment variable settings and before the execution of any OpenMP
20 The display begins with "OPENMP DISPLAY ENVIRONMENT BEGIN", followed by the
21 _OPENMP version macro (or the openmp_version named constant for Fortran) and ICV values,
22 in the format NAME ’=’ VALUE. NAME corresponds to the macro or environment variable name,
23 optionally prepended with a bracketed DEVICE. VALUE corresponds to the value of the macro or
24 ICV associated with this environment variable. Values are enclosed in single quotes. DEVICE
25 corresponds to the device on which the value of the ICV is applied. The display is terminated with
26 "OPENMP DISPLAY ENVIRONMENT END".
27 For the OMP_NESTED environment variable, the printed value is true if the max-active-levels-var
28 ICV is initialized to a value greater than 1; otherwise the printed value is false. The OMP_NESTED
29 environment variable has been deprecated.

1 If the verbose argument is set to 0 (or false in Fortran), the runtime displays the OpenMP version
2 number defined by the _OPENMP version macro (or the openmp_version named constant for
3 Fortran) value and the initial ICV values for the environment variables listed in Chapter 6. If the
4 verbose argument is set to 1 (or true for Fortran), the runtime may also display the values of
5 vendor-specific ICVs that may be modified by vendor-specific environment variables.
6 Example output:
7 OPENMP DISPLAY ENVIRONMENT BEGIN
8 _OPENMP=’202011’
9 [host] OMP_SCHEDULE=’GUIDED,4’
10 [host] OMP_NUM_THREADS=’4,3,2’
11 [device] OMP_NUM_THREADS=’2’
12 [host,device] OMP_DYNAMIC=’TRUE’
13 [host] OMP_PLACES=’{0:4},{4:4},{8:4},{12:4}’
14 ...
15 OPENMP DISPLAY ENVIRONMENT END
16 Cross References
17 • OMP_DISPLAY_ENV environment variable, see Section 6.12.

1 4 OMPT Interface
2 This chapter describes OMPT, which is an interface for first-party tools. First-party tools are linked
3 or loaded directly into the OpenMP program. OMPT defines mechanisms to initialize a tool, to
4 examine OpenMP state associated with an OpenMP thread, to interpret the call stack of an OpenMP
5 thread, to receive notification about OpenMP events, to trace activity on OpenMP target devices, to
6 assess implementation-dependent details of an OpenMP implementation (such as supported states
7 and mutual exclusion implementations), and to control a tool from an OpenMP application.
8 4.1 OMPT Interfaces Definitions

C / C++
9 A compliant implementation must supply a set of definitions for the OMPT runtime entry points,
10 OMPT callback signatures, and the special data types of their parameters and return values. These
11 definitions, which are listed throughout this chapter, and their associated declarations shall be
12 provided in a header file named omp-tools.h. In addition, the set of definitions may specify
13 other implementation-specific values.
14 The ompt_start_tool function is an external function with C linkage.
C / C++
15 4.2 Activating a First-Party Tool

16 To activate a tool, an OpenMP implementation first determines whether the tool should be
17 initialized. If so, the OpenMP implementation invokes the initializer of the tool, which enables the
18 tool to prepare to monitor execution on the host. The tool may then also arrange to monitor
19 computation that executes on target devices. This section explains how the tool and an OpenMP
20 implementation interact to accomplish these tasks.
21 4.2.1 ompt_start_tool
22 Summary
23 In order to use the OMPT interface provided by an OpenMP implementation, a tool must implement
24 the ompt_start_tool function, through which the OpenMP implementation initializes the tool.
CHAPTER 4. OMPT INTERFACE 471

1 Format
C
2 ompt_start_tool_result_t *ompt_start_tool(
3 unsigned int omp_version,
4 const char *runtime_version
5 );
C
6 Description
7 For a tool to use the OMPT interface that an OpenMP implementation provides, the tool must define
8 a globally-visible implementation of the function ompt_start_tool. The tool indicates that it
9 will use the OMPT interface that an OpenMP implementation provides by returning a non-null
10 pointer to an ompt_start_tool_result_t structure from the ompt_start_tool
11 implementation that it provides. The ompt_start_tool_result_t structure contains
12 pointers to tool initialization and finalization callbacks as well as a tool data word that an OpenMP
13 implementation must pass by reference to these callbacks. A tool may return NULL from
14 ompt_start_tool to indicate that it will not use the OMPT interface in a particular execution.
15 A tool may use the omp_version argument to determine if it is compatible with the OMPT interface
16 that the OpenMP implementation provides.
17 Description of Arguments
18 The argument omp_version is the value of the _OPENMP version macro associated with the
19 OpenMP API implementation. This value identifies the OpenMP API version that an OpenMP
20 implementation supports, which specifies the version of the OMPT interface that it supports.
21 The argument runtime_version is a version string that unambiguously identifies the OpenMP
22 implementation.
24 The argument runtime_version must be an immutable string that is defined for the lifetime of a
25 program execution.
26 Effect
27 If a tool returns a non-null pointer to an ompt_start_tool_result_t structure, an OpenMP
28 implementation will call the tool initializer specified by the initialize field in this structure before
29 beginning execution of any OpenMP construct or completing execution of any environment routine
30 invocation; the OpenMP implementation will call the tool finalizer specified by the finalize field in
31 this structure when the OpenMP implementation shuts down.
32 Cross References
33 • ompt_start_tool_result_t, see Section 4.4.1.

Runtime enabled
Inactive tool-var Pending
(re)start
disabled
Runtime shutdown no
or pause Inactive Found? Find next tool
yes r=NULL
Call Return
ompt_start_tool value r
0
r=non-null
1 Return Call
Active
value r->initialize
F IGURE 4.1: First-Party Tool Activation Flow Chart
1 4.2.2 Determining Whether a First-Party Tool Should be

2 Initialized
3 An OpenMP implementation examines the tool-var ICV as one of its first initialization steps. If the
4 value of tool-var is disabled, the initialization continues without a check for the presence of a tool
5 and the functionality of the OMPT interface will be unavailable as the program executes. In this
6 case, the OMPT interface state remains inactive.
7 Otherwise, the OMPT interface state changes to pending and the OpenMP implementation activates
8 any first-party tool that it finds. A tool can provide a definition of ompt_start_tool to an
9 OpenMP implementation in three ways:
10 • By statically-linking its definition of ompt_start_tool into an OpenMP application;
11 • By introducing a dynamically-linked library that includes its definition of ompt_start_tool
12 into the application’s address space; or
13 • By providing, in the tool-libraries-var ICV, the name of a dynamically-linked library that is
14 appropriate for the architecture and operating system used by the application and that includes a
15 definition of ompt_start_tool.

1 If the value of tool-var is enabled, the OpenMP implementation must check if a tool has provided
2 an implementation of ompt_start_tool. The OpenMP implementation first checks if a
3 tool-provided implementation of ompt_start_tool is available in the address space, either
4 statically-linked into the application or in a dynamically-linked library loaded in the address space.
5 If multiple implementations of ompt_start_tool are available, the OpenMP implementation
6 will use the first tool-provided implementation of ompt_start_tool that it finds.
7 If the implementation does not find a tool-provided implementation of ompt_start_tool in the
8 address space, it consults the tool-libraries-var ICV, which contains a (possibly empty) list of
9 dynamically-linked libraries. As described in detail in Section 6.19, the libraries in
10 tool-libraries-var are then searched for the first usable implementation of ompt_start_tool
11 that one of the libraries in the list provides.
12 If the implementation finds a tool-provided definition of ompt_start_tool, it invokes that
13 method; if a NULL pointer is returned, the OMPT interface state remains pending and the
14 implementation continues to look for implementations of ompt_start_tool; otherwise a
15 non-null pointer to an ompt_start_tool_result_t structure is returned, the OMPT
16 interface state changes to active and the OpenMP implementation makes the OMPT interface
17 available as the program executes. In this case, as the OpenMP implementation completes its
18 initialization, it initializes the OMPT interface.
19 If no tool can be found, the OMPT interface state changes to inactive.
20 Cross References
21 • tool-libraries-var ICV, see Section 2.4.
22 • tool-var ICV, see Section 2.4.
23 • ompt_start_tool function, see Section 4.2.1.
24 • ompt_start_tool_result_t type, see Section 4.4.1.
25 4.2.3 Initializing a First-Party Tool

26 To initialize the OMPT interface, the OpenMP implementation invokes the tool initializer that is
27 specified in the ompt_start_tool_result_t structure that is indicated by the non-null
28 pointer that ompt_start_tool returns. The initializer is invoked prior to the occurrence of any
29 OpenMP event.
30 A tool initializer, described in Section 4.5.1.1, uses the function specified in its lookup argument to
31 look up pointers to OMPT interface runtime entry points that the OpenMP implementation
32 provides; this process is described in Section 4.2.3.1. Typically, a tool initializer obtains a pointer to
33 the ompt_set_callback runtime entry point with type signature ompt_set_callback_t
34 and then uses this runtime entry point to register tool callbacks for OpenMP events, as described in
35 Section 4.2.4.

1 A tool initializer may use the ompt_enumerate_states runtime entry point, which has type
2 signature ompt_enumerate_states_t, to determine the thread states that an OpenMP
3 implementation employs. Similarly, it may use the ompt_enumerate_mutex_impls runtime
4 entry point, which has type signature ompt_enumerate_mutex_impls_t, to determine the
5 mutual exclusion implementations that the OpenMP implementation employs.
6 If a tool initializer returns a non-zero value, the OMPT interface state remains active for the
7 execution; otherwise, the OMPT interface state changes to inactive.
8 Cross References
11 • ompt_initialize_t type, see Section 4.5.1.1.
12 • ompt_callback_thread_begin_t type, see Section 4.5.2.1.
13 • ompt_enumerate_states_t type, see Section 4.6.1.1.
14 • ompt_enumerate_mutex_impls_t type, see Section 4.6.1.2.
15 • ompt_set_callback_t type, see Section 4.6.1.3.
16 • ompt_function_lookup_t type, see Section 4.6.3.
17 4.2.3.1 Binding Entry Points in the OMPT Callback Interface

18 Functions that an OpenMP implementation provides to support the OMPT interface are not defined
19 as global function symbols. Instead, they are defined as runtime entry points that a tool can only
20 identify through the lookup function that is provided as an argument with type signature
21 ompt_function_lookup_t to the tool initializer. A tool can use this function to obtain a
22 pointer to each of the runtime entry points that an OpenMP implementation provides to support the
23 OMPT interface. Once a tool has obtained a lookup function, it may employ it at any point in the
24 future.
25 For each runtime entry point in the OMPT interface for the host device, Table 4.1 provides the
26 string name by which it is known and its associated type signature. Implementations can provide
27 additional implementation-specific names and corresponding entry points. Any names that begin
28 with ompt_ are reserved names.
29 During initialization, a tool should look up each runtime entry point in the OMPT interface by
30 name and bind a pointer maintained by the tool that can later be used to invoke the entry point. The
31 entry points described in Table 4.1 enable a tool to assess the thread states and mutual exclusion
32 implementations that an OpenMP implementation supports to register tool callbacks, to inspect
33 registered callbacks, to introspect OpenMP state associated with threads, and to use tracing to
34 monitor computations that execute on target devices.

1 Detailed information about each runtime entry point listed in Table 4.1 is included as part of the
2 description of its type signature.
3 Cross References
5 • ompt_enumerate_mutex_impls_t type, see Section 4.6.1.2.
7 • ompt_get_callback_t type, see Section 4.6.1.4.
8 • ompt_get_thread_data_t type, see Section 4.6.1.5.
9 • ompt_get_num_procs_t type, see Section 4.6.1.6.
10 • ompt_get_num_places_t type, see Section 4.6.1.7.
11 • ompt_get_place_proc_ids_t type, see Section 4.6.1.8.
12 • ompt_get_place_num_t type, see Section 4.6.1.9.
13 • ompt_get_partition_place_nums_t type, see Section 4.6.1.10.
14 • ompt_get_proc_id_t type, see Section 4.6.1.11.
15 • ompt_get_state_t type, see Section 4.6.1.12.
16 • ompt_get_parallel_info_t type, see Section 4.6.1.13.
17 • ompt_get_task_info_t type, see Section 4.6.1.14.
18 • ompt_get_task_memory_t type, see Section 4.6.1.15.
19 • ompt_get_target_info_t type, see Section 4.6.1.16.
20 • ompt_get_num_devices_t type, see Section 4.6.1.17.
21 • ompt_get_unique_id_t type, see Section 4.6.1.18.
22 • ompt_finalize_tool_t type, see Section 4.6.1.19.
24 4.2.4 Monitoring Activity on the Host with OMPT

25 To monitor the execution of an OpenMP program on the host device, a tool initializer must register
26 to receive notification of events that occur as an OpenMP program executes. A tool can use the
27 ompt_set_callback runtime entry point to register callbacks for OpenMP events. The return
28 codes for ompt_set_callback use the ompt_set_result_t enumeration type. If the
29 ompt_set_callback runtime entry point is called outside a tool initializer, registration of
30 supported callbacks may fail with a return value of ompt_set_error.

TABLE 4.1: OMPT Callback Interface Runtime Entry Point Names and Their Type Signatures
Entry Point String Name Type signature
“ompt_enumerate_states” ompt_enumerate_states_t
“ompt_enumerate_mutex_impls” ompt_enumerate_mutex_impls_t
“ompt_set_callback” ompt_set_callback_t
“ompt_get_callback” ompt_get_callback_t
“ompt_get_thread_data” ompt_get_thread_data_t
“ompt_get_num_places” ompt_get_num_places_t
“ompt_get_place_proc_ids” ompt_get_place_proc_ids_t
“ompt_get_place_num” ompt_get_place_num_t
“ompt_get_partition_place_nums” ompt_get_partition_place_nums_t
“ompt_get_proc_id” ompt_get_proc_id_t
“ompt_get_state” ompt_get_state_t
“ompt_get_parallel_info” ompt_get_parallel_info_t
“ompt_get_task_info” ompt_get_task_info_t
“ompt_get_task_memory” ompt_get_task_memory_t
“ompt_get_num_devices” ompt_get_num_devices_t
“ompt_get_num_procs” ompt_get_num_procs_t
“ompt_get_target_info” ompt_get_target_info_t
“ompt_get_unique_id” ompt_get_unique_id_t
“ompt_finalize_tool” ompt_finalize_tool_t

1 All callbacks registered with ompt_set_callback or returned by ompt_get_callback use
2 the dummy type signature ompt_callback_t.
3 For callbacks listed in Table 4.2, ompt_set_always is the only registration return code that is
4 allowed. An OpenMP implementation must guarantee that the callback will be invoked every time
5 that a runtime event that is associated with it occurs. Support for such callbacks is required in a
6 minimal implementation of the OMPT interface.
7 For callbacks listed in Table 4.3, the ompt_set_callback runtime entry may return any
8 non-error code. Whether an OpenMP implementation invokes a registered callback never,
9 sometimes, or always is implementation defined. If registration for a callback allows a return code
10 of omp_set_never, support for invoking such a callback may not be present in a minimal
11 implementation of the OMPT interface. The return code from registering a callback indicates the
12 implementation-defined level of support for the callback.
13 Two techniques reduce the size of the OMPT interface. First, in cases where events are naturally
14 paired, for example, the beginning and end of a region, and the arguments needed by the callback at
15 each endpoint are identical, a tool registers a single callback for the pair of events, with
16 ompt_scope_begin or ompt_scope_end provided as an argument to identify for which
17 endpoint the callback is invoked. Second, when a class of events is amenable to uniform treatment,
18 OMPT provides a single callback for that class of events, for example, an
19 ompt_callback_sync_region_wait callback is used for multiple kinds of synchronization
20 regions, such as barrier, taskwait, and taskgroup regions. Some events, for example,
21 ompt_callback_sync_region_wait, use both techniques.
22 Cross References
23 • ompt_set_result_t type, see Section 4.4.4.2.
25 • ompt_get_callback_t type, see Section 4.6.1.4.
26 4.2.5 Tracing Activity on Target Devices with OMPT

27 A target device may or may not initialize a full OpenMP runtime system. Unless it does,
28 monitoring activity on a device using a tool interface based on callbacks may not be possible. To
29 accommodate such cases, the OMPT interface defines a monitoring interface for tracing activity on
30 target devices. Tracing activity on a target device involves the following steps:
31 • To prepare to trace activity on a target device, a tool must register for an
32 ompt_callback_device_initialize callback. A tool may also register for an
33 ompt_callback_device_load callback to be notified when code is loaded onto a target
34 device or an ompt_callback_device_unload callback to be notified when code is
35 unloaded from a target device. A tool may also optionally register an
36 ompt_callback_device_finalize callback.

TABLE 4.2: Callbacks for which ompt_set_callback Must Return ompt_set_always
Callback name
ompt_callback_thread_begin
ompt_callback_thread_end
ompt_callback_parallel_begin
ompt_callback_parallel_end
ompt_callback_task_create
ompt_callback_task_schedule
ompt_callback_implicit_task
ompt_callback_target
ompt_callback_target_emi
ompt_callback_target_data_op
ompt_callback_target_data_op_emi
ompt_callback_target_submit
ompt_callback_target_submit_emi
ompt_callback_control_tool
ompt_callback_device_initialize
ompt_callback_device_finalize
ompt_callback_device_load
ompt_callback_device_unload

TABLE 4.3: Callbacks for which ompt_set_callback May Return Any Non-Error Code
Callback name
ompt_callback_sync_region_wait
ompt_callback_mutex_released
ompt_callback_dependences
ompt_callback_task_dependence
ompt_callback_work
ompt_callback_master // (deprecated)
ompt_callback_masked
ompt_callback_target_map
ompt_callback_target_map_emi
ompt_callback_sync_region
ompt_callback_reduction
ompt_callback_lock_init
ompt_callback_lock_destroy
ompt_callback_mutex_acquire
ompt_callback_mutex_acquired
ompt_callback_nest_lock
ompt_callback_flush
ompt_callback_cancel
ompt_callback_dispatch

1 • When an OpenMP implementation initializes a target device, the OpenMP implementation
2 dispatches the device initialization callback of the tool on the host device. If the OpenMP
3 implementation or target device does not support tracing, the OpenMP implementation passes
4 NULL to the device initializer of the tool for its lookup argument; otherwise, the OpenMP
5 implementation passes a pointer to a device-specific runtime entry point with type signature
6 ompt_function_lookup_t to the device initializer of the tool.
7 • If a non-null lookup pointer is provided to the device initializer of the tool, the tool may use it to
8 determine the runtime entry points in the tracing interface that are available for the device and
9 may bind the returned function pointers to tool variables. Table 4.4 indicates the names of
10 runtime entry points that may be available for a device; an implementations may provide
11 additional implementation-defined names and corresponding entry points. The driver for the
12 device provides the runtime entry points that enable a tool to control the trace collection interface
13 of the device. The native trace format that the interface uses may be device specific and the
14 available kinds of trace records are implementation defined. Some devices may allow a tool to
15 collect traces of records in a standard format known as OMPT trace records. Each OMPT trace
16 record serves as a substitute for an OMPT callback that cannot be made on the device. The fields
17 in each trace record type are defined in the description of the callback that the record represents.
18 If this type of record is provided then the lookup function returns values for the runtime entry
19 points ompt_set_trace_ompt and ompt_get_record_ompt, which support collecting
20 and decoding OMPT traces. If the native tracing format for a device is the OMPT format then
21 tracing can be controlled using the runtime entry points for native or OMPT tracing.
22 • The tool uses the ompt_set_trace_native and/or the ompt_set_trace_ompt
23 runtime entry point to specify what types of events or activities to monitor on the device. The
24 return codes for ompt_set_trace_ompt and ompt_set_trace_native use the
25 ompt_set_result_t enumeration type. If the ompt_set_trace_native or the
26 ompt_set_trace_ompt runtime entry point is called outside a device initializer, registration
27 of supported callbacks may fail with a return code of ompt_set_error.
28 • The tool initiates tracing on the device by invoking ompt_start_trace. Arguments to
29 ompt_start_trace include two tool callbacks through which the OpenMP implementation
30 can manage traces associated with the device. One callback allocates a buffer in which the device
31 can deposit trace events. The second callback processes a buffer of trace events from the device.
32 • If the device requires a trace buffer, the OpenMP implementation invokes the tool-supplied
33 callback function on the host device to request a new buffer.
34 • The OpenMP implementation monitors the execution of OpenMP constructs on the device and
35 records a trace of events or activities into a trace buffer. If possible, device trace records are
36 marked with a host_op_id—an identifier that associates device activities with the target
37 operation that the host initiated to cause these activities. To correlate activities on the host with
38 activities on a device, a tool can register a ompt_callback_target_submit_emi
39 callback. Before and after the host initiates creation of an initial task on a device associated with
40 a structured block for a target construct, the OpenMP implementation dispatches the
41 ompt_callback_target_submit_emi callback on the host in the thread that is executing

TABLE 4.4: OMPT Tracing Interface Runtime Entry Point Names and Their Type Signatures
Entry Point String Name Type Signature

“ompt_get_device_num_procs” ompt_get_device_num_procs_t
“ompt_get_device_time” ompt_get_device_time_t
“ompt_translate_time” ompt_translate_time_t
“ompt_set_trace_ompt” ompt_set_trace_ompt_t
“ompt_set_trace_native” ompt_set_trace_native_t
“ompt_start_trace” ompt_start_trace_t
“ompt_pause_trace” ompt_pause_trace_t
“ompt_flush_trace” ompt_flush_trace_t
“ompt_stop_trace” ompt_stop_trace_t
“ompt_advance_buffer_cursor” ompt_advance_buffer_cursor_t
“ompt_get_record_type” ompt_get_record_type_t
“ompt_get_record_ompt” ompt_get_record_ompt_t
“ompt_get_record_native” ompt_get_record_native_t
“ompt_get_record_abstract” ompt_get_record_abstract_t

1 the task that encounters the target construct. This callback provides the tool with a pair of
2 identifiers: one that identifies the target region and a second that uniquely identifies the initial
3 task associated with that region. These identifiers help the tool correlate activities on the target
4 device with their target region.
5 • When appropriate, for example, when a trace buffer fills or needs to be flushed, the OpenMP
6 implementation invokes the tool-supplied buffer completion callback to process a non-empty
7 sequence of records in a trace buffer that is associated with the device.
8 • The tool-supplied buffer completion callback may return immediately, ignoring records in the
9 trace buffer, or it may iterate through them using the ompt_advance_buffer_cursor
10 entry point to inspect each record. A tool may use the ompt_get_record_type runtime
11 entry point to inspect the type of the record at the current cursor position. Three runtime entry
12 points (ompt_get_record_ompt, ompt_get_record_native, and
13 ompt_get_record_abstract) allow tools to inspect the contents of some or all records in
14 a trace buffer. The ompt_get_record_native runtime entry point uses the native trace
15 format of the device. The ompt_get_record_abstract runtime entry point decodes the
16 contents of a native trace record and summarizes them as an ompt_record_abstract_t
17 record. The ompt_get_record_ompt runtime entry point can only be used to retrieve
18 records in OMPT format.
19 • Once tracing has been started on a device, a tool may pause or resume tracing on the device at
20 any time by invoking ompt_pause_trace with an appropriate flag value as an argument.
21 • A tool may invoke the ompt_flush_trace runtime entry point for a device at any time
22 between device initialization and finalization to cause the device to flush pending trace records.
23 • At any time, a tool may use the ompt_start_trace runtime entry point to start tracing or the
24 ompt_stop_trace runtime entry point to stop tracing on a device. When tracing is stopped
25 on a device, the OpenMP implementation eventually gathers all trace records already collected
26 on the device and presents them to the tool using the buffer completion callback.
27 • An OpenMP implementation can be shut down while device tracing is in progress.
28 • When an OpenMP implementation is shut down, it finalizes each device. Device finalization
29 occurs in three steps. First, the OpenMP implementation halts any tracing in progress for the
30 device. Second, the OpenMP implementation flushes all trace records collected for the device
31 and uses the buffer completion callback associated with that device to present them to the tool.
32 Finally, the OpenMP implementation dispatches any ompt_callback_device_finalize
33 callback registered for the device.
34 Restrictions
35 Restrictions on tracing activity on devices are as follows:
36 • Implementation-defined names must not start with the prefix ompt_, which is reserved for the
37 OpenMP specification.

1 Cross References
2 • ompt_callback_device_initialize_t callback type, see Section 4.5.2.19.
3 • ompt_callback_device_finalize_t callback type, see Section 4.5.2.20.
4 • ompt_get_device_num_procs runtime entry point, see Section 4.6.2.1.
5 • ompt_get_device_time runtime entry point, see Section 4.6.2.2.
6 • ompt_translate_time runtime entry point, see Section 4.6.2.3.
7 • ompt_set_trace_ompt runtime entry point, see Section 4.6.2.4.
8 • ompt_set_trace_native runtime entry point, see Section 4.6.2.5.
9 • ompt_start_trace runtime entry point, see Section 4.6.2.6.
10 • ompt_pause_trace runtime entry point, see Section 4.6.2.7.
11 • ompt_flush_trace runtime entry point, see Section 4.6.2.8.
12 • ompt_stop_trace runtime entry point, see Section 4.6.2.9.
13 • ompt_advance_buffer_cursor runtime entry point, see Section 4.6.2.10.
14 • ompt_get_record_type runtime entry point, see Section 4.6.2.11.
15 • ompt_get_record_ompt runtime entry point, see Section 4.6.2.12.
16 • ompt_get_record_native runtime entry point, see Section 4.6.2.13.
17 • ompt_get_record_abstract runtime entry point, see Section 4.6.2.14.
18 4.3 Finalizing a First-Party Tool

19 If the OMPT interface state is active, the tool finalizer, which has type signature
20 ompt_finalize_t and is specified by the finalize field in the
21 ompt_start_tool_result_t structure returned from the ompt_start_tool function, is
22 called when the OpenMP implementation shuts down.
23 Cross References
24 • ompt_finalize_t callback type, see Section 4.5.1.2

1 4.4 OMPT Data Types
2 The C/C++ header file (omp-tools.h) provides the definitions of the types that are specified
3 throughout this subsection.
4 4.4.1 Tool Initialization and Finalization

5 Summary
6 A tool’s implementation of ompt_start_tool returns a pointer to an
7 ompt_start_tool_result_t structure, which contains pointers to the tool’s initialization
8 and finalization callbacks as well as an ompt_data_t object for use by the tool.
9 Format
C / C++
10 typedef struct ompt_start_tool_result_t {
11 ompt_initialize_t initialize;
12 ompt_finalize_t finalize;
13 ompt_data_t tool_data;
14 } ompt_start_tool_result_t;
C / C++
15 Restrictions
16 Restrictions to the ompt_start_tool_result_t type are as follows:
17 • The initialize and finalize callback pointer values in an ompt_start_tool_result_t
18 structure that ompt_start_tool returns must be non-null.
19 Cross References
21 • ompt_data_t type, see Section 4.4.4.4.
22 • ompt_initialize_t callback type, see Section 4.5.1.1.
23 • ompt_finalize_t callback type, see Section 4.5.1.2.
24 4.4.2 Callbacks
25 Summary
26 The ompt_callbacks_t enumeration type indicates the integer codes used to identify OpenMP
27 callbacks when registering or querying them.

1 Format
C / C++
2 typedef enum ompt_callbacks_t {
3 ompt_callback_thread_begin = 1,
4 ompt_callback_thread_end = 2,
5 ompt_callback_parallel_begin = 3,
6 ompt_callback_parallel_end = 4,
7 ompt_callback_task_create = 5,
8 ompt_callback_task_schedule = 6,
9 ompt_callback_implicit_task = 7,
10 ompt_callback_target = 8,
11 ompt_callback_target_data_op = 9,
12 ompt_callback_target_submit = 10,
13 ompt_callback_control_tool = 11,
14 ompt_callback_device_initialize = 12,
15 ompt_callback_device_finalize = 13,
16 ompt_callback_device_load = 14,
17 ompt_callback_device_unload = 15,
18 ompt_callback_sync_region_wait = 16,
19 ompt_callback_mutex_released = 17,
20 ompt_callback_dependences = 18,
21 ompt_callback_task_dependence = 19,
22 ompt_callback_work = 20,
23 ompt_callback_masked = 21,
24 ompt_callback_master /*(deprecated)*/ = ompt_callback_masked,
25 ompt_callback_target_map = 22,
26 ompt_callback_sync_region = 23,
27 ompt_callback_lock_init = 24,
28 ompt_callback_lock_destroy = 25,
29 ompt_callback_mutex_acquire = 26,
30 ompt_callback_mutex_acquired = 27,
31 ompt_callback_nest_lock = 28,
32 ompt_callback_flush = 29,
33 ompt_callback_cancel = 30,
34 ompt_callback_reduction = 31,
35 ompt_callback_dispatch = 32,
36 ompt_callback_target_emi = 33,
37 ompt_callback_target_data_op_emi = 34,
38 ompt_callback_target_submit_emi = 35,
39 ompt_callback_target_map_emi = 36,
40 ompt_callback_error = 37
41 } ompt_callbacks_t;
C / C++

1 4.4.3 Tracing
2 OpenMP provides type definitions that support tracing with OMPT.
3 4.4.3.1 Record Type

4 Summary
5 The ompt_record_t enumeration type indicates the integer codes used to identify OpenMP
6 trace record formats.
7 Format
C / C++
8 typedef enum ompt_record_t {
9 ompt_record_ompt = 1,
10 ompt_record_native = 2,
11 ompt_record_invalid = 3
12 } ompt_record_t;
C / C++
13 4.4.3.2 Native Record Kind

14 Summary
15 The ompt_record_native_t enumeration type indicates the integer codes used to identify
16 OpenMP native trace record contents.
17 Format
C / C++
18 typedef enum ompt_record_native_t {
19 ompt_record_native_info = 1,
20 ompt_record_native_event = 2
21 } ompt_record_native_t;
C / C++
22 4.4.3.3 Native Record Abstract Type

23 Summary
24 The ompt_record_abstract_t type provides an abstract trace record format that is used to
25 summarize native device trace records.

1 Format
C / C++
2 typedef struct ompt_record_abstract_t {
3 ompt_record_native_t rclass;
4 const char *type;
5 ompt_device_time_t start_time;
6 ompt_device_time_t end_time;
7 ompt_hwid_t hwid;
8 } ompt_record_abstract_t;
C / C++
9 Description
10 An ompt_record_abstract_t record contains information that a tool can use to process a
11 native record that it may not fully understand. The rclass field indicates that the record is
12 informational or that it represents an event; this information can help a tool determine how to
13 present the record. The record type field points to a statically-allocated, immutable character string
14 that provides a meaningful name that a tool can use to describe the event to a user. The start_time
15 and end_time fields are used to place an event in time. The times are relative to the device clock. If
16 an event does not have an associated start_time (end_time), the value of the start_time (end_time)
17 field is ompt_time_none. The hardware identifier field, hwid, indicates the location on the
18 device where the event occurred. A hwid may represent a hardware abstraction such as a core or a
19 hardware thread identifier. The meaning of a hwid value for a device is implementation defined. If
20 no hardware abstraction is associated with the record then the value of hwid is ompt_hwid_none.
21 4.4.3.4 Record Type

22 Summary
23 The ompt_record_ompt_t type provides a standard complete trace record format.
24 Format
C / C++
25 typedef struct ompt_record_ompt_t {
26 ompt_callbacks_t type;
27 ompt_device_time_t time;
28 ompt_id_t thread_id;
29 ompt_id_t target_id;
30 union {
31 ompt_record_thread_begin_t thread_begin;
32 ompt_record_parallel_begin_t parallel_begin;
33 ompt_record_parallel_end_t parallel_end;
34 ompt_record_work_t work;
35 ompt_record_dispatch_t dispatch;
36 ompt_record_task_create_t task_create;

1 ompt_record_dependences_t dependences;
2 ompt_record_task_dependence_t task_dependence;
3 ompt_record_task_schedule_t task_schedule;
4 ompt_record_implicit_task_t implicit_task;
5 ompt_record_masked_t masked;
6 ompt_record_sync_region_t sync_region;
7 ompt_record_mutex_acquire_t mutex_acquire;
8 ompt_record_mutex_t mutex;
9 ompt_record_nest_lock_t nest_lock;
10 ompt_record_flush_t flush;
11 ompt_record_cancel_t cancel;
12 ompt_record_target_t target;
13 ompt_record_target_data_op_t target_data_op;
14 ompt_record_target_map_t target_map;
15 ompt_record_target_kernel_t target_kernel;
16 ompt_record_control_tool_t control_tool;
17 ompt_record_error_t error;
18 } record;
19 } ompt_record_ompt_t;
C / C++
20 Description
21 The field type specifies the type of record provided by this structure. According to the type, event
22 specific information is stored in the matching record entry.
23 Restrictions
24 Restrictions to the ompt_record_ompt_t type are as follows:
25 • If type is set to ompt_callback_thread_end_t then the value of record is undefined.
26 4.4.4 Miscellaneous Type Definitions

27 This section describes miscellaneous types and enumerations used by the tool interface.
28 4.4.4.1 ompt_callback_t
29 Summary
30 Pointers to tool callback functions with different type signatures are passed to the
31 ompt_set_callback runtime entry point and returned by the ompt_get_callback
32 runtime entry point. For convenience, these runtime entry points expect all type signatures to be
33 cast to a dummy type ompt_callback_t.

1 Format
C / C++
2 typedef void (*ompt_callback_t) (void);
C / C++
3 4.4.4.2 ompt_set_result_t
4 Summary
5 The ompt_set_result_t enumeration type corresponds to values that the
6 ompt_set_callback, ompt_set_trace_ompt and ompt_set_trace_native
7 runtime entry points return.
8 Format
C / C++
9 typedef enum ompt_set_result_t {
10 ompt_set_error = 0,
11 ompt_set_never = 1,
12 ompt_set_impossible = 2,
13 ompt_set_sometimes = 3,
14 ompt_set_sometimes_paired = 4,
15 ompt_set_always = 5
16 } ompt_set_result_t;
C / C++
17 Description
18 Values of ompt_set_result_t, may indicate several possible outcomes. The
19 omp_set_error value indicates that the associated call failed. Otherwise, the value indicates
20 when an event may occur and, when appropriate, dispatching a callback event leads to the
21 invocation of the callback. The ompt_set_never value indicates that the event will never occur
22 or that the callback will never be invoked at runtime. The ompt_set_impossible value
23 indicates that the event may occur but that tracing of it is not possible. The
24 ompt_set_sometimes value indicates that the event may occur and, for an
25 implementation-defined subset of associated event occurrences, will be traced or the callback will
26 be invoked at runtime. The ompt_set_sometimes_paired value indicates the same result as
27 ompt_set_sometimes and, in addition, that a callback with an endpoint value of
28 ompt_scope_begin will be invoked if and only if the same callback with an endpoint value of
29 ompt_scope_end will also be invoked sometime in the future. The ompt_set_always value
30 indicates that, whenever an associated event occurs, it will be traced or the callback will be invoked.

1 Cross References
2 • Monitoring activity on the host with OMPT, see Section 4.2.4.
3 • Tracing activity on target devices with OMPT, see Section 4.2.5.
4 • ompt_set_callback runtime entry point, see Section 4.6.1.3.
5 • ompt_set_trace_ompt runtime entry point, see Section 4.6.2.4.
6 • ompt_set_trace_native runtime entry point, see Section 4.6.2.5.
7 4.4.4.3 ompt_id_t
8 Summary
9 The ompt_id_t type is used to provide various identifiers to tools.
10 Format
C / C++
11 typedef uint64_t ompt_id_t;
C / C++
12 Description
13 When tracing asynchronous activity on devices, identifiers enable tools to correlate target regions
14 and operations that the host initiates with associated activities on a target device. In addition,
15 OMPT provides identifiers to refer to parallel regions and tasks that execute on a device. These
16 various identifiers are of type ompt_id_t.
17 ompt_id_none is defined as an instance of type ompt_id_t with the value 0.
18 Restrictions
19 Restrictions to the ompt_id_t type are as follows:
20 • Identifiers created on each device must be unique from the time an OpenMP implementation is
21 initialized until it is shut down. Identifiers for each target region and target data operation
22 instance that the host device initiates must be unique over time on the host. Identifiers for parallel
23 and task region instances that execute on a device must be unique over time within that device.

1 4.4.4.4 ompt_data_t
2 Summary
3 The ompt_data_t type represents data associated with threads and with parallel and task regions.
4 Format
C / C++
5 typedef union ompt_data_t {
6 uint64_t value;
7 void *ptr;
8 } ompt_data_t;
C / C++
9 Description
10 The ompt_data_t type represents data that is reserved for tool use and that is related to a thread
11 or to a parallel or task region. When an OpenMP implementation creates a thread or an instance of
12 a parallel, teams, task, or target region, it initializes the associated ompt_data_t object with
13 the value ompt_data_none, which is an instance of the type with the data and pointer fields
14 equal to 0.
15 4.4.4.5 ompt_device_t
16 Summary
17 The ompt_device_t opaque object type represents a device.
18 Format
C / C++
19 typedef void ompt_device_t;
C / C++
20 4.4.4.6 ompt_device_time_t
21 Summary
22 The ompt_device_time_t type represents raw device time values.
23 Format
C / C++
24 typedef uint64_t ompt_device_time_t;
C / C++

1 Description
2 The ompt_device_time_t opaque object type represents raw device time values.
3 ompt_time_none refers to an unknown or unspecified time and is defined as an instance of type
4 ompt_device_time_t with the value 0.
5 4.4.4.7 ompt_buffer_t
6 Summary
7 The ompt_buffer_t opaque object type is a handle for a target buffer.
8 Format
C / C++
9 typedef void ompt_buffer_t;
C / C++
10 4.4.4.8 ompt_buffer_cursor_t
11 Summary
12 The ompt_buffer_cursor_t opaque type is a handle for a position in a target buffer.
13 Format
C / C++
14 typedef uint64_t ompt_buffer_cursor_t;
C / C++
15 4.4.4.9 ompt_dependence_t
16 Summary
17 The ompt_dependence_t type represents a task dependence.
18 Format
C / C++
19 typedef struct ompt_dependence_t {
20 ompt_data_t variable;
21 ompt_dependence_type_t dependence_type;
22 } ompt_dependence_t;
C / C++

1 Description
2 The ompt_dependence_t type is a structure that holds information about a depend clause. For
3 task dependences, the variable field points to the storage location of the dependence. For doacross
4 dependences, the variable field contains the value of a vector element that describes the
5 dependence. The dependence_type field indicates the type of the dependence.
6 Cross References
7 • ompt_dependence_type_t type, see Section 4.4.4.23.
8 4.4.4.10 ompt_thread_t
9 Summary
10 The ompt_thread_t enumeration type defines the valid thread type values.
11 Format
C / C++
12 typedef enum ompt_thread_t {
13 ompt_thread_initial = 1,
14 ompt_thread_worker = 2,
15 ompt_thread_other = 3,
16 ompt_thread_unknown = 4
17 } ompt_thread_t;
C / C++
18 Description
19 Any initial thread has thread type ompt_thread_initial. All OpenMP threads that are not
20 initial threads have thread type ompt_thread_worker. A thread that an OpenMP
21 implementation uses but that does not execute user code has thread type ompt_thread_other.
22 Any thread that is created outside an OpenMP implementation and that is not an initial thread has
23 thread type ompt_thread_unknown.
24 4.4.4.11 ompt_scope_endpoint_t
25 Summary
26 The ompt_scope_endpoint_t enumeration type defines valid scope endpoint values.
27 Format
C / C++
28 typedef enum ompt_scope_endpoint_t {
29 ompt_scope_begin = 1,
30 ompt_scope_end = 2,
31 ompt_scope_beginend = 3
32 } ompt_scope_endpoint_t;
C / C++

1 4.4.4.12 ompt_dispatch_t
2 Summary
3 The ompt_dispatch_t enumeration type defines the valid dispatch kind values.
4 Format
C / C++
5 typedef enum ompt_dispatch_t {
6 ompt_dispatch_iteration = 1,
7 ompt_dispatch_section = 2
8 } ompt_dispatch_t;
C / C++
9 4.4.4.13 ompt_sync_region_t
10 Summary
11 The ompt_sync_region_t enumeration type defines the valid synchronization region kind
12 values.
13 Format
C / C++
14 typedef enum ompt_sync_region_t {
15 ompt_sync_region_barrier = 1, // deprecated
16 ompt_sync_region_barrier_implicit = 2, // deprecated
17 ompt_sync_region_barrier_explicit = 3,
18 ompt_sync_region_barrier_implementation = 4,
19 ompt_sync_region_taskwait = 5,
20 ompt_sync_region_taskgroup = 6,
21 ompt_sync_region_reduction = 7,
22 ompt_sync_region_barrier_implicit_workshare = 8,
23 ompt_sync_region_barrier_implicit_parallel = 9,
24 ompt_sync_region_barrier_teams = 10
25 } ompt_sync_region_t;
C / C++

1 4.4.4.14 ompt_target_data_op_t
2 Summary
3 The ompt_target_data_op_t enumeration type defines the valid target data operation values.
4 Format
C / C++
5 typedef enum ompt_target_data_op_t {
6 ompt_target_data_alloc = 1,
7 ompt_target_data_transfer_to_device = 2,
8 ompt_target_data_transfer_from_device = 3,
9 ompt_target_data_delete = 4,
10 ompt_target_data_associate = 5,
11 ompt_target_data_disassociate = 6,
12 ompt_target_data_alloc_async = 17,
13 ompt_target_data_transfer_to_device_async = 18,
14 ompt_target_data_transfer_from_device_async = 19,
15 ompt_target_data_delete_async = 20
16 } ompt_target_data_op_t;
C / C++
17 4.4.4.15 ompt_work_t
18 Summary
19 The ompt_work_t enumeration type defines the valid work type values.
20 Format
C / C++
21 typedef enum ompt_work_t {
22 ompt_work_loop = 1,
23 ompt_work_sections = 2,
24 ompt_work_single_executor = 3,
25 ompt_work_single_other = 4,
26 ompt_work_workshare = 5,
27 ompt_work_distribute = 6,
28 ompt_work_taskloop = 7,
29 ompt_work_scope = 8
30 } ompt_work_t;
C / C++

1 4.4.4.16 ompt_mutex_t
2 Summary
3 The ompt_mutex_t enumeration type defines the valid mutex kind values.
4 Format
C / C++
5 typedef enum ompt_mutex_t {
6 ompt_mutex_lock = 1,
7 ompt_mutex_test_lock = 2,
8 ompt_mutex_nest_lock = 3,
9 ompt_mutex_test_nest_lock = 4,
10 ompt_mutex_critical = 5,
11 ompt_mutex_atomic = 6,
12 ompt_mutex_ordered = 7
13 } ompt_mutex_t;
C / C++
14 4.4.4.17 ompt_native_mon_flag_t
15 Summary
16 The ompt_native_mon_flag_t enumeration type defines the valid native monitoring flag
17 values.
18 Format
C / C++
19 typedef enum ompt_native_mon_flag_t {
20 ompt_native_data_motion_explicit = 0x01,
21 ompt_native_data_motion_implicit = 0x02,
22 ompt_native_kernel_invocation = 0x04,
23 ompt_native_kernel_execution = 0x08,
24 ompt_native_driver = 0x10,
25 ompt_native_runtime = 0x20,
26 ompt_native_overhead = 0x40,
27 ompt_native_idleness = 0x80
28 } ompt_native_mon_flag_t;
C / C++

1 4.4.4.18 ompt_task_flag_t
2 Summary
3 The ompt_task_flag_t enumeration type defines valid task types.
4 Format
C / C++
5 typedef enum ompt_task_flag_t {
6 ompt_task_initial = 0x00000001,
7 ompt_task_implicit = 0x00000002,
8 ompt_task_explicit = 0x00000004,
9 ompt_task_target = 0x00000008,
10 ompt_task_taskwait = 0x00000010,
11 ompt_task_undeferred = 0x08000000,
12 ompt_task_untied = 0x10000000,
13 ompt_task_final = 0x20000000,
14 ompt_task_mergeable = 0x40000000,
15 ompt_task_merged = 0x80000000
16 } ompt_task_flag_t;
C / C++
17 Description
18 The ompt_task_flag_t enumeration type defines valid task type values. The least significant
19 byte provides information about the general classification of the task. The other bits represent
20 properties of the task.
21 4.4.4.19 ompt_task_status_t
22 Summary
23 The ompt_task_status_t enumeration type indicates the reason that a task was switched
24 when it reached a task scheduling point.
25 Format
C / C++
26 typedef enum ompt_task_status_t {
27 ompt_task_complete = 1,
28 ompt_task_yield = 2,
29 ompt_task_cancel = 3,
30 ompt_task_detach = 4,
31 ompt_task_early_fulfill = 5,
32 ompt_task_late_fulfill = 6,
33 ompt_task_switch = 7,
34 ompt_taskwait_complete = 8
35 } ompt_task_status_t;
C / C++

1 Description
2 The value ompt_task_complete of the ompt_task_status_t type indicates that the task
3 that encountered the task scheduling point completed execution of the associated structured block
4 and an associated allow-completion event was fulfilled. The value ompt_task_yield indicates
5 that the task encountered a taskyield construct. The value ompt_task_cancel indicates
6 that the task was canceled when it encountered an active cancellation point. The value
7 ompt_task_detach indicates that a task for which the detach clause was specified completed
8 execution of the associated structured block and is waiting for an allow-completion event to be
9 fulfilled. The value ompt_task_early_fulfill indicates that the allow-completion event of
10 the task was fulfilled before the task completed execution of the associated structured block. The
11 value ompt_task_late_fulfill indicates that the allow-completion event of the task was
12 fulfilled after the task completed execution of the associated structured block. The value
13 ompt_taskwait_complete indicates completion of the dependent task that results from a
14 taskwait construct with one or more depend clauses. The value ompt_task_switch is
15 used for all other cases that a task was switched.
16 4.4.4.20 ompt_target_t
17 Summary
18 The ompt_target_t enumeration type defines the valid target type values.
19 Format
C / C++
20 typedef enum ompt_target_t {
21 ompt_target = 1,
22 ompt_target_enter_data = 2,
23 ompt_target_exit_data = 3,
24 ompt_target_update = 4,
25
26 ompt_target_nowait = 9,
27 ompt_target_enter_data_nowait = 10,
28 ompt_target_exit_data_nowait = 11,
29 ompt_target_update_nowait = 12
30 } ompt_target_t;
C / C++

1 4.4.4.21 ompt_parallel_flag_t
2 Summary
3 The ompt_parallel_flag_t enumeration type defines valid invoker values.
4 Format
C / C++
5 typedef enum ompt_parallel_flag_t {
6 ompt_parallel_invoker_program = 0x00000001,
7 ompt_parallel_invoker_runtime = 0x00000002,
8 ompt_parallel_league = 0x40000000,
9 ompt_parallel_team = 0x80000000
10 } ompt_parallel_flag_t;
C / C++
11 Description
12 The ompt_parallel_flag_t enumeration type defines valid invoker values, which indicate
13 how an outlined function is invoked.
14 The value ompt_parallel_invoker_program indicates that the outlined function
15 associated with implicit tasks for the region is invoked directly by the application on the primary
16 thread for a parallel region.
17 The value ompt_parallel_invoker_runtime indicates that the outlined function
18 associated with implicit tasks for the region is invoked by the runtime on the primary thread for a
19 parallel region.
20 The value ompt_parallel_league indicates that the callback is invoked due to the creation of
21 a league of teams by a teams construct.
22 The value ompt_parallel_team indicates that the callback is invoked due to the creation of a
23 team of threads by a parallel construct.

1 4.4.4.22 ompt_target_map_flag_t
2 Summary
3 The ompt_target_map_flag_t enumeration type defines the valid target map flag values.
4 Format
C / C++
5 typedef enum ompt_target_map_flag_t {
6 ompt_target_map_flag_to = 0x01,
7 ompt_target_map_flag_from = 0x02,
8 ompt_target_map_flag_alloc = 0x04,
9 ompt_target_map_flag_release = 0x08,
10 ompt_target_map_flag_delete = 0x10,
11 ompt_target_map_flag_implicit = 0x20
12 } ompt_target_map_flag_t;
C / C++
13 4.4.4.23 ompt_dependence_type_t
14 Summary
15 The ompt_dependence_type_t enumeration type defines the valid task dependence type
16 values.
17 Format
C / C++
18 typedef enum ompt_dependence_type_t {
19 ompt_dependence_type_in = 1,
20 ompt_dependence_type_out = 2,
21 ompt_dependence_type_inout = 3,
22 ompt_dependence_type_mutexinoutset = 4,
23 ompt_dependence_type_source = 5,
24 ompt_dependence_type_sink = 6,
25 ompt_dependence_type_inoutset = 7
26 } ompt_dependence_type_t;
C / C++

1 4.4.4.24 ompt_severity_t
2 Summary
3 The ompt_severity_t enumeration type defines the valid severity values.
4 Format
C / C++
5 typedef enum ompt_severity_t {
6 ompt_warning = 1,
7 ompt_fatal = 2
8 } ompt_severity_t;
C / C++
9 4.4.4.25 ompt_cancel_flag_t
10 Summary
11 The ompt_cancel_flag_t enumeration type defines the valid cancel flag values.
12 Format
C / C++
13 typedef enum ompt_cancel_flag_t {
14 ompt_cancel_parallel = 0x01,
15 ompt_cancel_sections = 0x02,
16 ompt_cancel_loop = 0x04,
17 ompt_cancel_taskgroup = 0x08,
18 ompt_cancel_activated = 0x10,
19 ompt_cancel_detected = 0x20,
20 ompt_cancel_discarded_task = 0x40
21 } ompt_cancel_flag_t;
C / C++
22 4.4.4.26 ompt_hwid_t
23 Summary
24 The ompt_hwid_t opaque type is a handle for a hardware identifier for a target device.
25 Format
C / C++
26 typedef uint64_t ompt_hwid_t;
C / C++

1 Description
2 The ompt_hwid_t opaque type is a handle for a hardware identifier for a target device.
3 ompt_hwid_none is an instance of the type that refers to an unknown or unspecified hardware
4 identifier and that has the value 0. If no hwid is associated with an
5 ompt_record_abstract_t then the value of hwid is ompt_hwid_none.
6 Cross References
7 • ompt_record_abstract_t type, see Section 4.4.3.3.
8 4.4.4.27 ompt_state_t
9 Summary
10 If the OMPT interface is in the active state then an OpenMP implementation must maintain thread
11 state information for each thread. The thread state maintained is an approximation of the
12 instantaneous state of a thread.
13 Format
C / C++
14 A thread state must be one of the values of the enumeration type ompt_state_t or an
15 implementation-defined state value of 512 or higher.
16 typedef enum ompt_state_t {
17 ompt_state_work_serial = 0x000,
18 ompt_state_work_parallel = 0x001,
19 ompt_state_work_reduction = 0x002,
20
21 ompt_state_wait_barrier = 0x010, //
22 deprecated
23 ompt_state_wait_barrier_implicit_parallel = 0x011,
24 ompt_state_wait_barrier_implicit_workshare = 0x012,
25 ompt_state_wait_barrier_implicit = 0x013, //
26 deprecated
27 ompt_state_wait_barrier_explicit = 0x014,
28 ompt_state_wait_barrier_implementation = 0x015,
29 ompt_state_wait_barrier_teams = 0x016,
30
31 ompt_state_wait_taskwait = 0x020,
32 ompt_state_wait_taskgroup = 0x021,
33
34 ompt_state_wait_mutex = 0x040,
35 ompt_state_wait_lock = 0x041,
36 ompt_state_wait_critical = 0x042,
37 ompt_state_wait_atomic = 0x043,
38 ompt_state_wait_ordered = 0x044,

1
2 ompt_state_wait_target = 0x080,
3 ompt_state_wait_target_map = 0x081,
4 ompt_state_wait_target_update = 0x082,
5
6 ompt_state_idle = 0x100,
7 ompt_state_overhead = 0x101,
8 ompt_state_undefined = 0x102
9 } ompt_state_t;
C / C++
10 Description
11 A tool can query the OpenMP state of a thread at any time. If a tool queries the state of a thread that
12 is not associated with OpenMP then the implementation reports the state as
13 ompt_state_undefined.
14 The value ompt_state_work_serial indicates that the thread is executing code outside all
15 parallel regions.
16 The value ompt_state_work_parallel indicates that the thread is executing code within the
17 scope of a parallel region.
18 The value ompt_state_work_reduction indicates that the thread is combining partial
19 reduction results from threads in its team. An OpenMP implementation may never report a thread
20 in this state; a thread that is combining partial reduction results may have its state reported as
21 ompt_state_work_parallel or ompt_state_overhead.
22 The value ompt_state_wait_barrier_implicit_parallel indicates that the thread is
23 waiting at the implicit barrier at the end of a parallel region.
24 The value ompt_state_wait_barrier_implicit_workshare indicates that the thread
25 is waiting at an implicit barrier at the end of a worksharing construct.
26 The value ompt_state_wait_barrier_explicit indicates that the thread is waiting in an
27 explicit barrier region.
28 The value ompt_state_wait_barrier_implementation indicates that the thread is
29 waiting in a barrier not required by the OpenMP standard but introduced by an OpenMP
30 implementation.
31 The value ompt_state_wait_barrier_teams indicates that the thread is waiting at a
32 barrier at the end of a teams region.
33 The value ompt_state_wait_taskwait indicates that the thread is waiting at a taskwait
34 construct.
35 The value ompt_state_wait_taskgroup indicates that the thread is waiting at the end of a
36 taskgroup construct.

1 The value ompt_state_wait_mutex indicates that the thread is waiting for a mutex of an
2 unspecified type.
3 The value ompt_state_wait_lock indicates that the thread is waiting for a lock or nestable
4 lock.
5 The value ompt_state_wait_critical indicates that the thread is waiting to enter a
6 critical region.
7 The value ompt_state_wait_atomic indicates that the thread is waiting to enter an atomic
8 region.
9 The value ompt_state_wait_ordered indicates that the thread is waiting to enter an
10 ordered region.
11 The value ompt_state_wait_target indicates that the thread is waiting for a target
12 region to complete.
13 The value ompt_state_wait_target_map indicates that the thread is waiting for a target
14 data mapping operation to complete. An implementation may report
15 ompt_state_wait_target for target data constructs.
16 The value ompt_state_wait_target_update indicates that the thread is waiting for a
17 target update operation to complete. An implementation may report
18 ompt_state_wait_target for target update constructs.
19 The value ompt_state_idle indicates that the thread is idle, that is, it is not part of an
20 OpenMP team.
21 The value ompt_state_overhead indicates that the thread is in the overhead state at any point
22 while executing within the OpenMP runtime, except while waiting at a synchronization point.
23 The value ompt_state_undefined indicates that the native thread is not created by the
25 4.4.4.28 ompt_frame_t
26 Summary
27 The ompt_frame_t type describes procedure frame information for an OpenMP task.
28 Format
C / C++
29 typedef struct ompt_frame_t {
30 ompt_data_t exit_frame;
31 ompt_data_t enter_frame;
32 int exit_frame_flags;
33 int enter_frame_flags;
34 } ompt_frame_t;
C / C++

1 Description
2 Each ompt_frame_t object is associated with the task to which the procedure frames belong.
3 Each non-merged initial, implicit, explicit, or target task with one or more frames on the stack of a
4 native thread has an associated ompt_frame_t object.
5 The exit_frame field of an ompt_frame_t object contains information to identify the first
6 procedure frame executing the task region. The exit_frame for the ompt_frame_t object
7 associated with the initial task that is not nested inside any OpenMP construct is NULL.
8 The enter_frame field of an ompt_frame_t object contains information to identify the latest still
9 active procedure frame executing the task region before entering the OpenMP runtime
10 implementation or before executing a different task. If a task with frames on the stack has not been
11 suspended, the value of enter_frame for the ompt_frame_t object associated with the task may
12 contain NULL.
13 For exit_frame, the exit_frame_flags and, for enter_frame, the enter_frame_flags field indicates that
14 the provided frame information points to a runtime or an application frame address. The same
15 fields also specify the kind of information that is provided to identify the frame, These fields are a
16 disjunction of values in the ompt_frame_flag_t enumeration type.
17 The lifetime of an ompt_frame_t object begins when a task is created and ends when the task is
18 destroyed. Tools should not assume that a frame structure remains at a constant location in memory
19 throughout the lifetime of the task. A pointer to an ompt_frame_t object is passed to some
20 callbacks; a pointer to the ompt_frame_t object of a task can also be retrieved by a tool at any
21 time, including in a signal handler, by invoking the ompt_get_task_info runtime entry point
22 (described in Section 4.6.1.14). A pointer to an ompt_frame_t object that a tool retrieved is
23 valid as long as the tool does not pass back control to the OpenMP implementation.
24
25 Note – A monitoring tool that uses asynchronous sampling can observe values of exit_frame and
26 enter_frame at inconvenient times. Tools must be prepared to handle ompt_frame_t objects
27 observed just prior to when their field values will be set or cleared.
28
29 4.4.4.29 ompt_frame_flag_t
30 Summary
31 The ompt_frame_flag_t enumeration type defines valid frame information flags.

1 Format
C / C++
2 typedef enum ompt_frame_flag_t {
3 ompt_frame_runtime = 0x00,
4 ompt_frame_application = 0x01,
5 ompt_frame_cfa = 0x10,
6 ompt_frame_framepointer = 0x20,
7 ompt_frame_stackaddress = 0x30
8 } ompt_frame_flag_t;
C / C++
9 Description
10 The value ompt_frame_runtime of the ompt_frame_flag_t type indicates that a frame
11 address is a procedure frame in the OpenMP runtime implementation. The value
12 ompt_frame_application of the ompt_frame_flag_t type indicates that a frame
13 address is a procedure frame in the OpenMP application.
14 Higher order bits indicate the kind of provided information that is unique for the particular frame
15 pointer. The value ompt_frame_cfa indicates that a frame address specifies a canonical frame
16 address. The value ompt_frame_framepointer indicates that a frame address provides the
17 value of the frame pointer register. The value ompt_frame_stackaddress indicates that a
18 frame address specifies a pointer address that is contained in the current stack frame.
19 4.4.4.30 ompt_wait_id_t
20 Summary
21 The ompt_wait_id_t type describes wait identifiers for an OpenMP thread.
22 Format
C / C++
23 typedef uint64_t ompt_wait_id_t;
C / C++
24 Description
25 Each thread maintains a wait identifier of type ompt_wait_id_t. When a task that a thread
26 executes is waiting for mutual exclusion, the wait identifier of the thread indicates the reason that
27 the thread is waiting. A wait identifier may represent a critical section name, a lock, a program
28 variable accessed in an atomic region, or a synchronization object that is internal to an OpenMP
29 implementation. When a thread is not in a wait state then the value of the wait identifier of the
30 thread is undefined.
31 ompt_wait_id_none is defined as an instance of type ompt_wait_id_t with the value 0.

1 4.5 OMPT Tool Callback Signatures and Trace
2 Records
3 The C/C++ header file (omp-tools.h) provides the definitions of the types that are specified
4 throughout this subsection. Restrictions to the OpenMP tool callbacks are as follows:
5 Restrictions
6 • Tool callbacks may not use OpenMP directives or call any runtime library routines described in
7 Section 3.
8 • Tool callbacks must exit by either returning to the caller or aborting.
9 4.5.1 Initialization and Finalization Callback Signature

10 4.5.1.1 ompt_initialize_t
11 Summary
12 A callback with type signature ompt_initialize_t initializes use of the OMPT interface.
13 Format
C / C++
14 typedef int (*ompt_initialize_t) (
15 ompt_function_lookup_t lookup,
16 int initial_device_num,
17 ompt_data_t *tool_data
18 );
C / C++
19 Description
20 To use the OMPT interface, an implementation of ompt_start_tool must return a non-null
21 pointer to an ompt_start_tool_result_t structure that contains a pointer to a tool
22 initializer function with type signature ompt_initialize_t. An OpenMP implementation will
23 call the initializer after fully initializing itself but before beginning execution of any OpenMP
24 construct or runtime library routine.
25 The initializer returns a non-zero value if it succeeds; otherwise the OMPT interface state changes
26 to inactive as described in Section 4.2.3.
28 The lookup argument is a callback to an OpenMP runtime routine that must be used to obtain a
29 pointer to each runtime entry point in the OMPT interface. The initial_device_num argument
30 provides the value of omp_get_initial_device(). The tool_data argument is a pointer to
31 the tool_data field in the ompt_start_tool_result_t structure that ompt_start_tool
32 returned.

1 Cross References
7 4.5.1.2 ompt_finalize_t
8 Summary
9 A tool implements a finalizer with the type signature ompt_finalize_t to finalize its use of the
10 OMPT interface.
11 Format
C / C++
12 typedef void (*ompt_finalize_t) (
13 ompt_data_t *tool_data
14 );
C / C++
15 Description
16 To use the OMPT interface, an implementation of ompt_start_tool must return a non-null
17 pointer to an ompt_start_tool_result_t structure that contains a non-null pointer to a tool
18 finalizer with type signature ompt_finalize_t. An OpenMP implementation must call the tool
19 finalizer after the last OMPT event as the OpenMP implementation shuts down.
21 The tool_data argument is a pointer to the tool_data field in the
22 ompt_start_tool_result_t structure returned by ompt_start_tool.
23 Cross References

1 4.5.2 Event Callback Signatures and Trace Records
2 This section describes the signatures of tool callback functions that an OMPT tool may register and
3 that are called during runtime of an OpenMP program. An implementation may also provide a trace
4 of events per device. Along with the callbacks, the following defines standard trace records. For the
5 trace records, tool data arguments are replaced by an ID, which must be initialized by the OpenMP
6 implementation. Each of parallel_id, task_id, and thread_id must be unique per target region. Tool
7 implementations of callbacks are not required to be async signal safe.
8 Cross References
9 • ompt_id_t type, see Section 4.4.4.3.
11 4.5.2.1 ompt_callback_thread_begin_t
12 Summary
13 The ompt_callback_thread_begin_t type is used for callbacks that are dispatched when
14 native threads are created.
15 Format
C / C++
16 typedef void (*ompt_callback_thread_begin_t) (
17 ompt_thread_t thread_type,
18 ompt_data_t *thread_data
19 );
C / C++
20 Trace Record
C / C++
21 typedef struct ompt_record_thread_begin_t {
22 ompt_thread_t thread_type;
23 } ompt_record_thread_begin_t;
C / C++
25 The thread_type argument indicates the type of the new thread: initial, worker, or other. The
26 binding of the thread_data argument is the new thread.

1 Cross References
4 • Initial task, see Section 2.12.5.
6 • ompt_thread_t type, see Section 4.4.4.10.
7 4.5.2.2 ompt_callback_thread_end_t
8 Summary
9 The ompt_callback_thread_end_t type is used for callbacks that are dispatched when
10 native threads are destroyed.
11 Format
C / C++
12 typedef void (*ompt_callback_thread_end_t) (
13 ompt_data_t *thread_data
14 );
C / C++
16 The binding of the thread_data argument is the thread that will be destroyed.
17 Cross References
21 • ompt_record_ompt_t type, see Section 4.4.3.4.
23 4.5.2.3 ompt_callback_parallel_begin_t
24 Summary
25 The ompt_callback_parallel_begin_t type is used for callbacks that are dispatched
26 when a parallel or teams region starts.

1 Format
C / C++
2 typedef void (*ompt_callback_parallel_begin_t) (
3 ompt_data_t *encountering_task_data,
4 const ompt_frame_t *encountering_task_frame,
5 ompt_data_t *parallel_data,
6 unsigned int requested_parallelism,
7 int flags,
8 const void *codeptr_ra
9 );
C / C++
10 Trace Record
C / C++
11 typedef struct ompt_record_parallel_begin_t {
12 ompt_id_t encountering_task_id;
13 ompt_id_t parallel_id;
14 unsigned int requested_parallelism;
15 int flags;
16 const void *codeptr_ra;
17 } ompt_record_parallel_begin_t;
C / C++
19 The binding of the encountering_task_data argument is the encountering task.
20 The encountering_task_frame argument points to the frame object that is associated with the
21 encountering task. Accessing the frame object after the callback returned can cause a data race.
22 The binding of the parallel_data argument is the parallel or teams region that is beginning.
23 The requested_parallelism argument indicates the number of threads or teams that the user
24 requested.
25 The flags argument indicates whether the code for the region is inlined into the application or
26 invoked by the runtime and also whether the region is a parallel or teams region. Valid values
27 for flags are a disjunction of elements in the enum ompt_parallel_flag_t.
28 The codeptr_ra argument relates the implementation of an OpenMP region to its source code. If a
29 runtime routine implements the region associated with a callback that has type signature
30 ompt_callback_parallel_begin_t then codeptr_ra contains the return address of the call
31 to that runtime routine. If the implementation of the region is inlined then codeptr_ra contains the
32 return address of the invocation of the callback. If attribution to source code is impossible or
33 inappropriate, codeptr_ra may be NULL.

1 Cross References
5 • ompt_parallel_flag_t type, see Section 4.4.4.21.
6 • ompt_frame_t type, see Section 4.4.4.28.
7 4.5.2.4 ompt_callback_parallel_end_t
8 Summary
9 The ompt_callback_parallel_end_t type is used for callbacks that are dispatched when a
10 parallel or teams region ends.
11 Format
C / C++
12 typedef void (*ompt_callback_parallel_end_t) (
15 int flags,
17 );
C / C++
18 Trace Record
C / C++
19 typedef struct ompt_record_parallel_end_t {
22 int flags;
24 } ompt_record_parallel_end_t;
C / C++
26 The binding of the parallel_data argument is the parallel or teams region that is ending.
28 The flags argument indicates whether the execution of the region is inlined into the application or
29 invoked by the runtime and also whether it is a parallel or teams region. Values for flags are a
30 disjunction of elements in the enum ompt_parallel_flag_t.

3 ompt_callback_parallel_end_t then codeptr_ra contains the return address of the call to
4 that runtime routine. If the implementation of the region is inlined then codeptr_ra contains the
7 Cross References
11 • ompt_parallel_flag_t type, see Section 4.4.4.21.
12 4.5.2.5 ompt_callback_work_t
13 Summary
14 The ompt_callback_work_t type is used for callbacks that are dispatched when worksharing
15 regions, loop-related regions, taskloop regions and scope regions begin and end.
16 Format
C / C++
17 typedef void (*ompt_callback_work_t) (
18 ompt_work_t wstype,
19 ompt_scope_endpoint_t endpoint,
21 ompt_data_t *task_data,
22 uint64_t count,
24 );
C / C++
25 Trace Record
C / C++
26 typedef struct ompt_record_work_t {
27 ompt_work_t wstype;
28 ompt_scope_endpoint_t endpoint;
30 ompt_id_t task_id;
31 uint64_t count;
33 } ompt_record_work_t;
C / C++

2 The wstype argument indicates the kind of region.
3 The endpoint argument indicates that the callback signals the beginning of a scope or the end of a
4 scope.
5 The binding of the parallel_data argument is the current parallel region.
6 The binding of the task_data argument is the current task.
7 The count argument is a measure of the quantity of work involved in the construct. For a
8 worksharing-loop or taskloop construct, count represents the number of iterations in the
9 iteration space, which may be the result of collapsing several associated loops. For a sections
10 construct, count represents the number of sections. For a workshare construct, count represents
11 the units of work, as defined by the workshare construct. For a single or scope construct,
12 count is always 1. When the endpoint argument signals the end of a scope, a count value of 0
13 indicates that the actual count value is not available.
16 ompt_callback_work_t then codeptr_ra contains the return address of the call to that
17 runtime routine. If the implementation of the region is inlined then codeptr_ra contains the return
18 address of the invocation of the callback. If attribution to source code is impossible or
20 Cross References
21 • Worksharing constructs, see Section 2.10.
22 • Loop-related directives, see Section 2.11.
23 • Worksharing-Loop construct, see Section 2.11.4.
26 • ompt_scope_endpoint_t type, see Section 4.4.4.11.
27 • ompt_work_t type, see Section 4.4.4.15.
28 4.5.2.6 ompt_callback_dispatch_t
29 Summary
30 The ompt_callback_dispatch_t type is used for callbacks that are dispatched when a
31 thread begins to execute a section or loop iteration.

1 Format
C / C++
2 typedef void (*ompt_callback_dispatch_t) (
5 ompt_dispatch_t kind,
6 ompt_data_t instance
7 );
C / C++
8 Trace Record
C / C++
9 typedef struct ompt_record_dispatch_t {
12 ompt_dispatch_t kind;
13 ompt_data_t instance;
14 } ompt_record_dispatch_t;
C / C++
17 The binding of the task_data argument is the implicit task that executes the structured block of the
18 parallel region.
19 The kind argument indicates whether a loop iteration or a section is being dispatched.
20 For a loop iteration, the instance.value argument contains the logical iteration number. For a
21 structured block in the sections construct, instance.ptr contains a code address that identifies
22 the structured block. In cases where a runtime routine implements the structured block associated
23 with this callback, instance.ptr contains the return address of the call to the runtime routine. In
24 cases where the implementation of the structured block is inlined, instance.ptr contains the return
25 address of the invocation of this callback.
26 Cross References
27 • sections and section constructs, see Section 2.10.1.
31 • ompt_dispatch_t type, see Section 4.4.4.12.

1 4.5.2.7 ompt_callback_task_create_t
2 Summary
3 The ompt_callback_task_create_t type is used for callbacks that are dispatched when
4 task regions are generated.
5 Format
C / C++
6 typedef void (*ompt_callback_task_create_t) (
8 const ompt_frame_t *encountering_task_frame,
9 ompt_data_t *new_task_data,
10 int flags,
11 int has_dependences,
13 );
C / C++
14 Trace Record
C / C++
15 typedef struct ompt_record_task_create_t {
17 ompt_id_t new_task_id;
18 int flags;
19 int has_dependences;
21 } ompt_record_task_create_t;
C / C++
24 The encountering_task_frame argument points to the frame object associated with the encountering
25 task. Accessing the frame object after the callback returned can cause a data race.
26 The binding of the new_task_data argument is the generated task.
27 The flags argument indicates the kind of task (explicit or target) that is generated. Values for flags
28 are a disjunction of elements in the ompt_task_flag_t enumeration type.
29 The has_dependences argument is true if the generated task has dependences and false otherwise.
32 ompt_callback_task_create_t then codeptr_ra contains the return address of the call to

3 Cross References
7 • ompt_task_flag_t type, see Section 4.4.4.18.
9 4.5.2.8 ompt_callback_dependences_t
10 Summary
11 The ompt_callback_dependences_t type is used for callbacks that are related to
12 dependences and that are dispatched when new tasks are generated and when ordered constructs
13 are encountered.
14 Format
C / C++
15 typedef void (*ompt_callback_dependences_t) (
17 const ompt_dependence_t *deps,
18 int ndeps
19 );
C / C++
20 Trace Record
C / C++
21 typedef struct ompt_record_dependences_t {
23 ompt_dependence_t dep;
24 int ndeps;
25 } ompt_record_dependences_t;
C / C++
27 The binding of the task_data argument is the generated task for a depend clause on a task construct,
28 the target task for a depend clause on a target construct respectively depend object in an
29 asynchronous runtime routine, or the encountering implicit task for a depend clause of the ordered
30 construct.

1 The deps argument lists dependences of the new task or the dependence vector of the ordered
2 construct. Dependences denoted with dependency objects are described in terms of their
3 dependency semantics.
4 The ndeps argument specifies the length of the list passed by the deps argument. The memory for
5 deps is owned by the caller; the tool cannot rely on the data after the callback returns.
6 The performance monitor interface for tracing activity on target devices provides one record per
7 dependence.
8 Cross References
12 • ompt_dependence_t type, see Section 4.4.4.9.
13 4.5.2.9 ompt_callback_task_dependence_t
14 Summary
15 The ompt_callback_task_dependence_t type is used for callbacks that are dispatched
16 when unfulfilled task dependences are encountered.
17 Format
C / C++
18 typedef void (*ompt_callback_task_dependence_t) (
19 ompt_data_t *src_task_data,
20 ompt_data_t *sink_task_data
21 );
C / C++
22 Trace Record
C / C++
23 typedef struct ompt_record_task_dependence_t {
24 ompt_id_t src_task_id;
25 ompt_id_t sink_task_id;
26 } ompt_record_task_dependence_t;
C / C++
28 The binding of the src_task_data argument is a running task with an outgoing dependence.
29 The binding of the sink_task_data argument is a task with an unsatisfied incoming dependence.

1 Cross References
4 4.5.2.10 ompt_callback_task_schedule_t
5 Summary
6 The ompt_callback_task_schedule_t type is used for callbacks that are dispatched when
7 task scheduling decisions are made.
8 Format
C / C++
9 typedef void (*ompt_callback_task_schedule_t) (
10 ompt_data_t *prior_task_data,
11 ompt_task_status_t prior_task_status,
12 ompt_data_t *next_task_data
13 );
C / C++
14 Trace Record
C / C++
15 typedef struct ompt_record_task_schedule_t {
16 ompt_id_t prior_task_id;
17 ompt_task_status_t prior_task_status;
18 ompt_id_t next_task_id;
19 } ompt_record_task_schedule_t;
C / C++
21 The prior_task_status argument indicates the status of the task that arrived at a task scheduling
22 point.
23 The binding of the prior_task_data argument is the task that arrived at the scheduling point.
24 The binding of the next_task_data argument is the task that is resumed at the scheduling point.
25 This argument is NULL if the callback is dispatched for a task-fulfill event or if the callback signals
26 completion of a taskwait construct.
27 Cross References
30 • ompt_task_status_t type, see Section 4.4.4.19.

1 4.5.2.11 ompt_callback_implicit_task_t
2 Summary
3 The ompt_callback_implicit_task_t type is used for callbacks that are dispatched when
4 initial tasks and implicit tasks are generated and completed.
5 Format
C / C++
6 typedef void (*ompt_callback_implicit_task_t) (
10 unsigned int actual_parallelism,
11 unsigned int index,
12 int flags
13 );
C / C++
14 Trace Record
C / C++
15 typedef struct ompt_record_implicit_task_t {
19 unsigned int actual_parallelism;
20 unsigned int index;
21 int flags;
22 } ompt_record_implicit_task_t;
C / C++
25 scope.
26 The binding of the parallel_data argument is the current parallel or teams region. For the
27 implicit-task-end and the initial-task-end events, this argument is NULL.
28 The binding of the task_data argument is the implicit task that executes the structured block of the
29 parallel or teams region.
30 The actual_parallelism argument indicates the number of threads in the parallel region or the
31 number of teams in the teams region. For initial tasks, that are not closely nested in a teams
32 construct, this argument is 1. For the implicit-task-end and the initial-task-end events, this
33 argument is 0.

1 The index argument indicates the thread number or team number of the calling thread, within the
2 team or league that is executing the parallel or teams region to which the implicit task region
3 binds. For initial tasks, that are not created by a teams construct, this argument is 1.
4 The flags argument indicates the kind of task (initial or implicit).
5 Cross References
9 • ompt_scope_endpoint_t enumeration type, see Section 4.4.4.11.
10 4.5.2.12 ompt_callback_masked_t
11 Summary
12 The ompt_callback_masked_t type is used for callbacks that are dispatched when masked
13 regions start and end.
14 Format
C / C++
15 typedef void (*ompt_callback_masked_t) (
20 );
C / C++
21 Trace Record
C / C++
22 typedef struct ompt_record_masked_t {
27 } ompt_record_masked_t;
C / C++

3 scope.
5 The binding of the task_data argument is the encountering task.
8 ompt_callback_masked_t then codeptr_ra contains the return address of the call to that
12 Cross References
16 4.5.2.13 ompt_callback_sync_region_t
17 Summary
18 The ompt_callback_sync_region_t type is used for callbacks that are dispatched when
19 barrier regions, taskwait regions, and taskgroup regions begin and end and when waiting
20 begins and ends for them as well as for when reductions are performed.
21 Format
C / C++
22 typedef void (*ompt_callback_sync_region_t) (
23 ompt_sync_region_t kind,
28 );
C / C++

1 Trace Record
C / C++
2 typedef struct ompt_record_sync_region_t {
3 ompt_sync_region_t kind;
8 } ompt_record_sync_region_t;
C / C++
10 The kind argument indicates the kind of synchronization.
12 scope.
13 The binding of the parallel_data argument is the current parallel region. For the barrier-end event
14 at the end of a parallel region this argument is NULL.
15 The binding of the task_data argument is the current task.
18 ompt_callback_sync_region_t then codeptr_ra contains the return address of the call to
22 Cross References
23 • barrier construct, see Section 2.19.2.
24 • Implicit barriers, see Section 2.19.3.
25 • taskwait construct, see Section 2.19.5.
26 • taskgroup construct, see Section 2.19.6.
27 • Properties common to all reduction clauses, see Section 2.21.5.1.
30 • ompt_sync_region_t type, see Section 4.4.4.13.

1 4.5.2.14 ompt_callback_mutex_acquire_t
2 Summary
3 The ompt_callback_mutex_acquire_t type is used for callbacks that are dispatched when
4 locks are initialized, acquired and tested and when critical regions, atomic regions, and
5 ordered regions are begun.
6 Format
C / C++
7 typedef void (*ompt_callback_mutex_acquire_t) (
8 ompt_mutex_t kind,
9 unsigned int hint,
10 unsigned int impl,
11 ompt_wait_id_t wait_id,
13 );
C / C++
14 Trace Record
C / C++
15 typedef struct ompt_record_mutex_acquire_t {
16 ompt_mutex_t kind;
17 unsigned int hint;
18 unsigned int impl;
19 ompt_wait_id_t wait_id;
21 } ompt_record_mutex_acquire_t;
C / C++
23 The kind argument indicates the kind of mutual exclusion event.
24 The hint argument indicates the hint that was provided when initializing an implementation of
25 mutual exclusion. If no hint is available when a thread initiates acquisition of mutual exclusion, the
26 runtime may supply omp_sync_hint_none as the value for hint.
27 The impl argument indicates the mechanism chosen by the runtime to implement the mutual
28 exclusion.
29 The wait_id argument indicates the object being awaited.
32 ompt_callback_mutex_acquire_t then codeptr_ra contains the return address of the call
33 to that runtime routine. If the implementation of the region is inlined then codeptr_ra contains the

1 Cross References
5 • omp_init_lock and omp_init_nest_lock routines, see Section 3.9.1.
6 • ompt_mutex_t type, see Section 4.4.4.16.
7 • ompt_wait_id_t type, see Section 4.4.4.30.
8 4.5.2.15 ompt_callback_mutex_t
9 Summary
10 The ompt_callback_mutex_t type is used for callbacks that indicate important
11 synchronization events.
12 Format
C / C++
13 typedef void (*ompt_callback_mutex_t) (
14 ompt_mutex_t kind,
17 );
C / C++
18 Trace Record
C / C++
19 typedef struct ompt_record_mutex_t {
20 ompt_mutex_t kind;
23 } ompt_record_mutex_t;
C / C++
25 The kind argument indicates the kind of mutual exclusion event.
29 ompt_callback_mutex_t then codeptr_ra contains the return address of the call to that

1 Cross References
5 • omp_destroy_lock and omp_destroy_nest_lock routines, see Section 3.9.3.
6 • omp_set_lock and omp_set_nest_lock routines, see Section 3.9.4.
7 • omp_unset_lock and omp_unset_nest_lock routines, see Section 3.9.5.
8 • omp_test_lock and omp_test_nest_lock routines, see Section 3.9.6.
11 4.5.2.16 ompt_callback_nest_lock_t
12 Summary
13 The ompt_callback_nest_lock_t type is used for callbacks that indicate that a thread that
14 owns a nested lock has performed an action related to the lock but has not relinquished ownership
15 of it.
16 Format
C / C++
17 typedef void (*ompt_callback_nest_lock_t) (
21 );
C / C++
22 Trace Record
C / C++
23 typedef struct ompt_record_nest_lock_t {
27 } ompt_record_nest_lock_t;
C / C++
30 scope.

3 ompt_callback_nest_lock_t then codeptr_ra contains the return address of the call to that
7 Cross References
8 • omp_set_nest_lock routine, see Section 3.9.4.
9 • omp_unset_nest_lock routine, see Section 3.9.5.
10 • omp_test_nest_lock routine, see Section 3.9.6.
13 4.5.2.17 ompt_callback_flush_t
14 Summary
15 The ompt_callback_flush_t type is used for callbacks that are dispatched when flush
16 constructs are encountered.
17 Format
C / C++
18 typedef void (*ompt_callback_flush_t) (
19 ompt_data_t *thread_data,
21 );
C / C++
22 Trace Record
C / C++
23 typedef struct ompt_record_flush_t {
25 } ompt_record_flush_t;
C / C++
27 The binding of the thread_data argument is the executing thread.
30 ompt_callback_flush_t then codeptr_ra contains the return address of the call to that

1 Cross References
2 • flush construct, see Section 2.19.8.
4 4.5.2.18 ompt_callback_cancel_t
5 Summary
6 The ompt_callback_cancel_t type is used for callbacks that are dispatched for cancellation,
7 cancel and discarded-task events.
8 Format
C / C++
9 typedef void (*ompt_callback_cancel_t) (
11 int flags,
13 );
C / C++
14 Trace Record
C / C++
15 typedef struct ompt_record_cancel_t {
17 int flags;
19 } ompt_record_cancel_t;
C / C++
21 The binding of the task_data argument is the task that encounters a cancel construct, a
22 cancellation point construct, or a construct defined as having an implicit cancellation
23 point.
24 The flags argument, defined by the ompt_cancel_flag_t enumeration type, indicates whether
25 cancellation is activated by the current task, or detected as being activated by another task. The
26 construct that is being canceled is also described in the flags argument. When several constructs are
27 detected as being concurrently canceled, each corresponding bit in the argument will be set.
30 ompt_callback_cancel_t then codeptr_ra contains the return address of the call to that

1 Cross References
2 • omp_cancel_flag_t enumeration type, see Section 4.4.4.25.
3 4.5.2.19 ompt_callback_device_initialize_t
4 Summary
5 The ompt_callback_device_initialize_t type is used for callbacks that initialize
6 device tracing interfaces.
7 Format
C / C++
8 typedef void (*ompt_callback_device_initialize_t) (
9 int device_num,
10 const char *type,
11 ompt_device_t *device,
12 ompt_function_lookup_t lookup,
13 const char *documentation
14 );
C / C++
15 Description
16 Registration of a callback with type signature ompt_callback_device_initialize_t for
17 the ompt_callback_device_initialize event enables asynchronous collection of a trace
18 for a device. The OpenMP implementation invokes this callback after OpenMP is initialized for the
19 device but before execution of any OpenMP construct is started on the device.
21 The device_num argument identifies the logical device that is being initialized.
22 The type argument is a character string that indicates the type of the device. A device type string is
23 a semicolon-separated character string that includes at a minimum the vendor and model name of
24 the device. These names may be followed by a semicolon-separated sequence of properties that
25 describe the hardware or software of the device.
26 The device argument is a pointer to an opaque object that represents the target device instance.
27 Functions in the device tracing interface use this pointer to identify the device that is being
28 addressed.
29 The lookup argument points to a runtime callback that a tool must use to obtain pointers to runtime
30 entry points in the device’s OMPT tracing interface. If a device does not support tracing then
31 lookup is NULL.
32 The documentation argument is a string that describes how to use any device-specific runtime entry
33 points that can be obtained through the lookup argument. This documentation string may be a
34 pointer to external documentation, or it may be inline descriptions that include names and type

1 signatures for any device-specific interfaces that are available through the lookup argument along
2 with descriptions of how to use these interface functions to control monitoring and analysis of
3 device traces.
5 The type and documentation arguments must be immutable strings that are defined for the lifetime
6 of program execution.
7 Effect
8 A device initializer must fulfill several duties. First, the type argument should be used to determine
9 if any special knowledge about the hardware and/or software of a device is employed. Second, the
10 lookup argument should be used to look up pointers to runtime entry points in the OMPT tracing
11 interface for the device. Finally, these runtime entry points should be used to set up tracing for the
12 device.
13 Initialization of tracing for a target device is described in Section 4.2.5.
14 Cross References
16 4.5.2.20 ompt_callback_device_finalize_t
17 Summary
18 The ompt_callback_device_initialize_t type is used for callbacks that finalize device
19 tracing interfaces.
20 Format
C / C++
21 typedef void (*ompt_callback_device_finalize_t) (
22 int device_num
23 );
C / C++
25 The device_num argument identifies the logical device that is being finalized.
26 Description
27 A registered callback with type signature ompt_callback_device_finalize_t is
28 dispatched for a device immediately prior to finalizing the device. Prior to dispatching a finalization
29 callback for a device on which tracing is active, the OpenMP implementation stops tracing on the
30 device and synchronously flushes all trace records for the device that have not yet been reported.
31 These trace records are flushed through one or more buffer completion callbacks with type
32 signature ompt_callback_buffer_complete_t as needed prior to the dispatch of the
33 callback with type signature ompt_callback_device_finalize_t.

1 Cross References
2 • ompt_callback_buffer_complete_t callback type, see Section 4.5.2.24.
3 4.5.2.21 ompt_callback_device_load_t
4 Summary
5 The ompt_callback_device_load_t type is used for callbacks that the OpenMP runtime
6 invokes to indicate that it has just loaded code onto the specified device.
7 Format
C / C++
8 typedef void (*ompt_callback_device_load_t) (
9 int device_num,
10 const char *filename,
11 int64_t offset_in_file,
12 void *vma_in_file,
13 size_t bytes,
14 void *host_addr,
15 void *device_addr,
16 uint64_t module_id
17 );
C / C++
19 The device_num argument specifies the device.
20 The filename argument indicates the name of a file in which the device code can be found. A NULL
21 filename indicates that the code is not available in a file in the file system.
22 The offset_in_file argument indicates an offset into filename at which the code can be found. A
23 value of -1 indicates that no offset is provided.
24 ompt_addr_none is defined as a pointer with the value ~0.
25 The vma_in_file argument indicates a virtual address in filename at which the code can be found. A
26 value of ompt_addr_none indicates that a virtual address in the file is not available.
27 The bytes argument indicates the size of the device code object in bytes.
28 The host_addr argument indicates the address at which a copy of the device code is available in
29 host memory. A value of ompt_addr_none indicates that a host code address is not available.
30 The device_addr argument indicates the address at which the device code has been loaded in device
31 memory. A value of ompt_addr_none indicates that a device code address is not available.
32 The module_id argument is an identifier that is associated with the device code object.

1 Cross References
2 • Device directives, see Section 2.14.
3 4.5.2.22 ompt_callback_device_unload_t
4 Summary
5 The ompt_callback_device_unload_t type is used for callbacks that the OpenMP
6 runtime invokes to indicate that it is about to unload code from the specified device.
7 Format
C / C++
8 typedef void (*ompt_callback_device_unload_t) (
9 int device_num,
10 uint64_t module_id
11 );
C / C++
14 The module_id argument is an identifier that is associated with the device code object.
15 Cross References
16 • Device directives, see Section 2.14.
17 4.5.2.23 ompt_callback_buffer_request_t
18 Summary
19 The ompt_callback_buffer_request_t type is used for callbacks that are dispatched
20 when a buffer to store event records for a device is requested.
21 Format
C / C++
22 typedef void (*ompt_callback_buffer_request_t) (
23 int device_num,
24 ompt_buffer_t **buffer,
25 size_t *bytes
26 );
C / C++
27 Description
28 A callback with type signature ompt_callback_buffer_request_t requests a buffer to
29 store trace records for the specified device. A buffer request callback may set *bytes to 0 if it does
30 not provide a buffer. If a callback sets *bytes to 0, further recording of events for the device is
31 disabled until the next invocation of ompt_start_trace. This action causes the device to drop
32 future trace records until recording is restarted.

3 The *buffer argument points to a buffer where device events may be recorded. The *bytes argument
4 indicates the length of that buffer.
5 Cross References
6 • ompt_buffer_t type, see Section 4.4.4.7.
7 4.5.2.24 ompt_callback_buffer_complete_t
8 Summary
9 The ompt_callback_buffer_complete_t type is used for callbacks that are dispatched
10 when devices will not record any more trace records in an event buffer and all records written to the
11 buffer are valid.
12 Format
C / C++
13 typedef void (*ompt_callback_buffer_complete_t) (
14 int device_num,
15 ompt_buffer_t *buffer,
16 size_t bytes,
17 ompt_buffer_cursor_t begin,
18 int buffer_owned
19 );
C / C++
20 Description
21 A callback with type signature ompt_callback_buffer_complete_t provides a buffer that
22 contains trace records for the specified device. Typically, a tool will iterate through the records in
23 the buffer and process them.
24 The OpenMP implementation makes these callbacks on a thread that is not an OpenMP primary or
25 worker thread.
26 The callee may not delete the buffer if the buffer_owned argument is 0.
27 The buffer completion callback is not required to be async signal safe.
29 The device_num argument indicates the device for which the buffer contains events.
30 The buffer argument is the address of a buffer that was previously allocated by a buffer request
31 callback.
32 The bytes argument indicates the full size of the buffer.

1 The begin argument is an opaque cursor that indicates the position of the beginning of the first
2 record in the buffer.
3 The buffer_owned argument is 1 if the data to which the buffer points can be deleted by the callback
4 and 0 otherwise. If multiple devices accumulate trace events into a single buffer, this callback may
5 be invoked with a pointer to one or more trace records in a shared buffer with buffer_owned = 0. In
6 this case, the callback may not delete the buffer.
7 Cross References
9 • ompt_buffer_cursor_t type, see Section 4.4.4.8.
10 4.5.2.25 ompt_callback_target_data_op_emi_t and

11 ompt_callback_target_data_op_t
12 Summary
13 Theompt_callback_target_data_op_emi_t and
14 ompt_callback_target_data_op_t types are used for callbacks that are dispatched when
15 a thread maps data to a device.
16 Format
C / C++
17 typedef void (*ompt_callback_target_data_op_emi_t) (
19 ompt_data_t *target_task_data,
20 ompt_data_t *target_data,
21 ompt_id_t *host_op_id,
22 ompt_target_data_op_t optype,
23 void *src_addr,
25 void *dest_addr,
26 int dest_device_num,
27 size_t bytes,
29 );

1 typedef void (*ompt_callback_target_data_op_t) (
2 ompt_id_t target_id,
3 ompt_id_t host_op_id,
4 ompt_target_data_op_t optype,
5 void *src_addr,
7 void *dest_addr,
8 int dest_device_num,
9 size_t bytes,
11 );
C / C++
12 Trace Record
C / C++
13 typedef struct ompt_record_target_data_op_t {
14 ompt_id_t host_op_id;
15 ompt_target_data_op_t optype;
16 void *src_addr;
17 int src_device_num;
18 void *dest_addr;
19 int dest_device_num;
20 size_t bytes;
23 } ompt_record_target_data_op_t;
C / C++
24 Description
25 A thread dispatches a registered ompt_callback_target_data_op_emi or
26 ompt_callback_target_data_op callback when device memory is allocated or freed, as
27 well as when data is copied to or from a device.
28
29 Note – An OpenMP implementation may aggregate program variables and data operations upon
30 them. For instance, an OpenMP implementation may synthesize a composite to represent multiple
31 scalars and then allocate, free, or copy this composite as a whole rather than performing data
32 operations on each scalar individually. Thus, callbacks may not be dispatched as separate data
33 operations on each variable.
34

2 The endpoint argument indicates that the callback signals the beginning or end of a scope.
3 The binding of the target_task_data argument is the target task region.
4 The binding of the target_data argument is the target region.
5 The host_op_id argument points to a tool controlled integer value, which identifies a data operation
7 The optype argument indicates the kind of data operation.
8 The src_addr argument indicates the data address before the operation, where applicable.
9 The src_device_num argument indicates the source device number for the data operation, where
10 applicable.
11 The dest_addr argument indicates the data address after the operation.
12 The dest_device_num argument indicates the destination device number for the data operation.
13 Whether in some operations src_addr or dest_addr may point to an intermediate buffer is
15 The bytes argument indicates the size of data.
18 ompt_callback_target_data_op_emi_t or ompt_callback_target_data_op_t
19 then codeptr_ra contains the return address of the call to that runtime routine. If the implementation
20 of the region is inlined then codeptr_ra contains the return address of the invocation of the callback.
21 If attribution to source code is impossible or inappropriate, codeptr_ra may be NULL.
22 Restrictions
23 Restrictions to the ompt_callback_target_data_op_emi and
24 ompt_callback_target_data_op callbacks are as follows:
25 • These callbacks must not be registered at the same time.
26 Cross References
31 • ompt_target_data_op_t type, see Section 4.4.4.14.

1 4.5.2.26 ompt_callback_target_emi_t and
2 ompt_callback_target_t
3 Summary
4 The ompt_callback_target_emi_t and ompt_callback_target_t types are used
5 for callbacks that are dispatched when a thread begins to execute a device construct.
6 Format
C / C++
7 typedef void (*ompt_callback_target_emi_t) (
8 ompt_target_t kind,
10 int device_num,
12 ompt_data_t *target_task_data,
15 );
16 typedef void (*ompt_callback_target_t) (
17 ompt_target_t kind,
19 int device_num,
23 );
C / C++
24 Trace Record
C / C++
25 typedef struct ompt_record_target_t {
26 ompt_target_t kind;
28 int device_num;
32 } ompt_record_target_t;
C / C++

2 The kind argument indicates the kind of target region.
4 scope.
5 The device_num argument indicates the device number of the device that will execute the target
6 region.
7 The binding of the task_data argument is the generating task.
8 The binding of the target_task_data argument is the target region.
12 ompt_callback_target_emi_t or ompt_callback_target_t then codeptr_ra
13 contains the return address of the call to that runtime routine. If the implementation of the region is
14 inlined then codeptr_ra contains the return address of the invocation of the callback. If attribution
15 to source code is impossible or inappropriate, codeptr_ra may be NULL.
16 Restrictions
17 Restrictions to the ompt_callback_target_emi and ompt_callback_target callbacks
18 are as follows:
20 Cross References
29 • ompt_target_t type, see Section 4.4.4.20.

1 4.5.2.27 ompt_callback_target_map_emi_t and
2 ompt_callback_target_map_t
3 Summary
4 The ompt_callback_target_map_emi_t and ompt_callback_target_map_t types
5 are used for callbacks that are dispatched to indicate data mapping relationships.
6 Format
C / C++
7 typedef void (*ompt_callback_target_map_emi_t) (
9 unsigned int nitems,
10 void **host_addr,
11 void **device_addr,
12 size_t *bytes,
13 unsigned int *mapping_flags,
15 );
16 typedef void (*ompt_callback_target_map_t) (
18 unsigned int nitems,
19 void **host_addr,
20 void **device_addr,
21 size_t *bytes,
22 unsigned int *mapping_flags,
24 );
C / C++
25 Trace Record
C / C++
26 typedef struct ompt_record_target_map_t {
28 unsigned int nitems;
29 void **host_addr;
30 void **device_addr;
31 size_t *bytes;
32 unsigned int *mapping_flags;
34 } ompt_record_target_map_t;
C / C++

1 Description
2 An instance of a target, target data, target enter data, or target exit data
3 construct may contain one or more map clauses. An OpenMP implementation may report the set of
4 mappings associated with map clauses for a construct with a single
5 ompt_callback_target_map_emi or ompt_callback_target_map callback to report
6 the effect of all mappings or multiple ompt_callback_target_map_emi or
7 ompt_callback_target_map callbacks with each reporting a subset of the mappings.
8 Furthermore, an OpenMP implementation may omit mappings that it determines are unnecessary.
9 If an OpenMP implementation issues multiple ompt_callback_target_map_emi or
10 ompt_callback_target_map callbacks, these callbacks may be interleaved with
11 ompt_callback_target_data_op_emi or ompt_callback_target_data_op
12 callbacks used to report data operations associated with the mappings.
15 The nitems argument indicates the number of data mappings that this callback reports.
16 The host_addr argument indicates an array of host data addresses.
17 The device_addr argument indicates an array of device data addresses.
18 The bytes argument indicates an array of sizes of data.
19 The mapping_flags argument indicates the kind of data mapping. Flags for a mapping include one
20 or more values specified by the ompt_target_map_flag_t type.
23 ompt_callback_target_map_t or ompt_callback_target_map_emi_t then
24 codeptr_ra contains the return address of the call to that runtime routine. If the implementation of
25 the region is inlined then codeptr_ra contains the return address of the invocation of the callback. If
26 attribution to source code is impossible or inappropriate, codeptr_ra may be NULL.
27 Restrictions
28 Restrictions to the ompt_callback_target_data_map_emi and
29 ompt_callback_target_data_map callbacks are as follows:
31 Cross References

3 • ompt_target_map_flag_t type, see Section 4.4.4.22.
4 • ompt_callback_target_data_op_emi_t or
5 ompt_callback_target_data_op_t callback type, see Section 4.5.2.25.
6 4.5.2.28 ompt_callback_target_submit_emi_t and

7 ompt_callback_target_submit_t
8 Summary
9 The ompt_callback_target_submit_emi_t and
10 ompt_callback_target_submit_t types are used for callbacks that are dispatched before
11 and after the host initiates creation of an initial task on a device.
12 Format
C / C++
13 typedef void (*ompt_callback_target_submit_emi_t) (
16 ompt_id_t *host_op_id,
17 unsigned int requested_num_teams
18 );
19 typedef void (*ompt_callback_target_submit_t) (
21 ompt_id_t host_op_id,
22 unsigned int requested_num_teams
23 );
C / C++
24 Trace Record
C / C++
25 typedef struct ompt_record_target_kernel_t {
26 ompt_id_t host_op_id;
27 unsigned int requested_num_teams;
28 unsigned int granted_num_teams;
30 } ompt_record_target_kernel_t;
C / C++

1 Description
2 A thread dispatches a registered ompt_callback_target_submit_emi or
3 ompt_callback_target_submit callback on the host before and after a target task initiates
4 creation of an initial task on a device.
6 The endpoint argument indicates that the callback signals the beginning or end of a scope.
8 The host_op_id argument points to a tool controlled integer value, which identifies an initial task
10 The requested_num_teams argument is the number of teams that the host requested to execute the
11 kernel. The actual number of teams that execute the kernel may be smaller and generally will not be
12 known until the kernel begins to execute on the device.
13 If ompt_set_trace_ompt has configured the device to trace kernel execution then the device
14 will log a ompt_record_target_kernel_t record in a trace. The fields in the record are as
15 follows:
16 • The host_op_id field contains a tool-controlled identifier that can be used to correlate a
17 ompt_record_target_kernel_t record with its associated
18 ompt_callback_target_submit_emi or ompt_callback_target_submit
19 callback on the host;
20 • The requested_num_teams field contains the number of teams that the host requested to execute
21 the kernel;
22 • The granted_num_teams field contains the number of teams that the device actually used to
23 execute the kernel;
24 • The time when the initial task began execution on the device is recorded in the time field of an
25 enclosing ompt_record_t structure; and
26 • The time when the initial task completed execution on the device is recorded in the end_time
27 field.
28 Restrictions
29 Restrictions to the ompt_callback_target_submit_emi and
30 ompt_callback_target_submit callbacks are as follows:

1 Cross References
6 4.5.2.29 ompt_callback_control_tool_t
7 Summary
8 The ompt_callback_control_tool_t type is used for callbacks that dispatch tool-control
9 events.
10 Format
C / C++
11 typedef int (*ompt_callback_control_tool_t) (
12 uint64_t command,
13 uint64_t modifier,
14 void *arg,
16 );
C / C++
17 Trace Record
C / C++
18 typedef struct ompt_record_control_tool_t {
19 uint64_t command;
20 uint64_t modifier;
22 } ompt_record_control_tool_t;
C / C++
23 Description
24 Callbacks with type signature ompt_callback_control_tool_t may return any
25 non-negative value, which will be returned to the application as the return value of the
26 omp_control_tool call that triggered the callback.
28 The command argument passes a command from an application to a tool. Standard values for
29 command are defined by omp_control_tool_t in Section 3.14.
30 The modifier argument passes a command modifier from an application to a tool.
31 The command and modifier arguments may have tool-specific values. Tools must ignore command
32 values that they are not designed to handle.

1 The arg argument is a void pointer that enables a tool and an application to exchange arbitrary state.
2 The arg argument may be NULL.
5 ompt_callback_control_tool_t then codeptr_ra contains the return address of the call to
10 Tool-specific values for command must be ≥ 64.
11 Cross References
12 • Tool control routine and types, see Section 3.14.
13 4.5.2.30 ompt_callback_error_t
14 Summary
15 The ompt_callback_error_t type is used for callbacks that dispatch runtime-error events.
16 Format
C / C++
17 typedef void (*ompt_callback_error_t) (
18 ompt_severity_t severity,
19 const char *message,
20 size_t length,
22 );
C / C++
23 Trace Record
C / C++
24 typedef struct ompt_record_error_t {
25 ompt_severity_t severity;
26 const char *message;
27 size_t length;
29 } ompt_record_error_t;
C / C++
30 Description
31 A thread dispatches a registered ompt_callback_error_t callback when an error directive
32 is encountered for which the at(execution) clause is specified.

2 The severity argument passes the specified severity level.
3 The message argument passes the string from the message clause.
4 The length argument provides the length of the string.
7 ompt_callback_error_t then codeptr_ra contains the return address of the call to that
11 Cross References
12 • error directive, see Section 2.5.4.
13 • ompt_severity_t enumeration type, see Section 4.4.4.24.
14 4.6 OMPT Runtime Entry Points for Tools

15 OMPT supports two principal sets of runtime entry points for tools. One set of runtime entry points
16 enables a tool to register callbacks for OpenMP events and to inspect the state of an OpenMP thread
17 while executing in a tool callback or a signal handler. The second set of runtime entry points
18 enables a tool to trace activities on a device. When directed by the tracing interface, an OpenMP
19 implementation will trace activities on a device, collect buffers of trace records, and invoke
20 callbacks on the host to process these records. OMPT runtime entry points should not be global
21 symbols since tools cannot rely on the visibility of such symbols.
22 OMPT also supports runtime entry points for two classes of lookup routines. The first class of
23 lookup routines contains a single member: a routine that returns runtime entry points in the OMPT
24 callback interface. The second class of lookup routines includes a unique lookup routine for each
25 kind of device that can return runtime entry points in a device’s OMPT tracing interface.
26 The omp-tools.h C/C++ header file provides the definitions of the types that are specified
27 throughout this subsection.
28 Binding
29 The binding thread set for each of the entry points in this section is the encountering thread unless
30 otherwise specified. The binding task set is the task executing on the encountering thread.
31 Restrictions
32 Restrictions on OMPT runtime entry points are as follows:
33 • OMPT runtime entry points must not be called from a signal handler on a native thread before a
34 native-thread-begin or after a native-thread-end event.
35 • OMPT device runtime entry points must not be called after a device-finalize event for that device.

1 4.6.1 Entry Points in the OMPT Callback Interface
2 Entry points in the OMPT callback interface enable a tool to register callbacks for OpenMP events
3 and to inspect the state of an OpenMP thread while executing in a tool callback or a signal handler.
4 Pointers to these runtime entry points are obtained through the lookup function that is provided
5 through the OMPT initializer.
6 4.6.1.1 ompt_enumerate_states_t
7 Summary
8 The ompt_enumerate_states_t type is the type signature of the
9 ompt_enumerate_states runtime entry point, which enumerates the thread states that an
10 OpenMP implementation supports.
11 Format
C / C++
12 typedef int (*ompt_enumerate_states_t) (
13 int current_state,
14 int *next_state,
15 const char **next_state_name
16 );
C / C++
17 Description
18 An OpenMP implementation may support only a subset of the states defined by the
19 ompt_state_t enumeration type. An OpenMP implementation may also support
20 implementation-specific states. The ompt_enumerate_states runtime entry point, which has
21 type signature ompt_enumerate_states_t, enables a tool to enumerate the supported thread
22 states.
23 When a supported thread state is passed as current_state, the runtime entry point assigns the next
24 thread state in the enumeration to the variable passed by reference in next_state and assigns the
25 name associated with that state to the character pointer passed by reference in next_state_name.
26 Whenever one or more states are left in the enumeration, the ompt_enumerate_states
27 runtime entry point returns 1. When the last state in the enumeration is passed as current_state,
28 ompt_enumerate_states returns 0, which indicates that the enumeration is complete.
30 The current_state argument must be a thread state that the OpenMP implementation supports. To
31 begin enumerating the supported states, a tool should pass ompt_state_undefined as
32 current_state. Subsequent invocations of ompt_enumerate_states should pass the value
33 assigned to the variable that was passed by reference in next_state to the previous call.

1 The value ompt_state_undefined is reserved to indicate an invalid thread state.
2 ompt_state_undefined is defined as an integer with the value 0.
3 The next_state argument is a pointer to an integer in which ompt_enumerate_states returns
4 the value of the next state in the enumeration.
5 The next_state_name argument is a pointer to a character string pointer through which
6 ompt_enumerate_states returns a string that describes the next state.
8 Any string returned through the next_state_name argument must be immutable and defined for the
9 lifetime of program execution.
10 Cross References
11 • ompt_state_t type, see Section 4.4.4.27.
12 4.6.1.2 ompt_enumerate_mutex_impls_t
13 Summary
14 The ompt_enumerate_mutex_impls_t type is the type signature of the
15 ompt_enumerate_mutex_impls runtime entry point, which enumerates the kinds of mutual
16 exclusion implementations that an OpenMP implementation employs.
17 Format
C / C++
18 typedef int (*ompt_enumerate_mutex_impls_t) (
19 int current_impl,
20 int *next_impl,
21 const char **next_impl_name
22 );
C / C++
23 Description
24 Mutual exclusion for locks, critical sections, and atomic regions may be implemented in
25 several ways. The ompt_enumerate_mutex_impls runtime entry point, which has type
26 signature ompt_enumerate_mutex_impls_t, enables a tool to enumerate the supported
27 mutual exclusion implementations.
28 When a supported mutex implementation is passed as current_impl, the runtime entry point assigns
29 the next mutex implementation in the enumeration to the variable passed by reference in next_impl
30 and assigns the name associated with that mutex implementation to the character pointer passed by
31 reference in next_impl_name.
32 Whenever one or more mutex implementations are left in the enumeration, the
33 ompt_enumerate_mutex_impls runtime entry point returns 1. When the last mutex

1 implementation in the enumeration is passed as current_impl, the runtime entry point returns 0,
2 which indicates that the enumeration is complete.
4 The current_impl argument must be a mutex implementation that an OpenMP implementation
5 supports. To begin enumerating the supported mutex implementations, a tool should pass
6 ompt_mutex_impl_none as current_impl. Subsequent invocations of
7 ompt_enumerate_mutex_impls should pass the value assigned to the variable that was
8 passed in next_impl to the previous call.
9 The value ompt_mutex_impl_none is reserved to indicate an invalid mutex implementation.
10 ompt_mutex_impl_none is defined as an integer with the value 0.
11 The next_impl argument is a pointer to an integer in which ompt_enumerate_mutex_impls
12 returns the value of the next mutex implementation in the enumeration.
13 The next_impl_name argument is a pointer to a character string pointer in which
14 ompt_enumerate_mutex_impls returns a string that describes the next mutex
15 implementation.
17 Any string returned through the next_impl_name argument must be immutable and defined for the
18 lifetime of a program execution.
19 Cross References
21 4.6.1.3 ompt_set_callback_t
22 Summary
23 The ompt_set_callback_t type is the type signature of the ompt_set_callback runtime
24 entry point, which registers a pointer to a tool callback that an OpenMP implementation invokes
25 when a host OpenMP event occurs.
26 Format
C / C++
27 typedef ompt_set_result_t (*ompt_set_callback_t) (
28 ompt_callbacks_t event,
29 ompt_callback_t callback
30 );
C / C++

1 Description
2 OpenMP implementations can use callbacks to indicate the occurrence of events during the
3 execution of an OpenMP program. The ompt_set_callback runtime entry point, which has
4 type signature ompt_set_callback_t, registers a callback for an OpenMP event on the
5 current device, The return value of ompt_set_callback indicates the outcome of registering
6 the callback.
8 The event argument indicates the event for which the callback is being registered.
9 The callback argument is a tool callback function. If callback is NULL then callbacks associated
10 with event are disabled. If callbacks are successfully disabled then ompt_set_always is
11 returned.
13 When a tool registers a callback for an event, the type signature for the callback must match the
14 type signature appropriate for the event.
15 Restrictions
16 Restrictions on the ompt_set_callback runtime entry point are as follows:
17 • The entry point must not return ompt_set_impossible.
18 Cross References
19 • Monitoring activity on the host with OMPT, see Section 4.2.4.
20 • ompt_callbacks_t enumeration type, see Section 4.4.2.
21 • ompt_callback_t type, see Section 4.4.4.1.
23 • ompt_get_callback_t host callback type signature, see Section 4.6.1.4.
24 4.6.1.4 ompt_get_callback_t
25 Summary
26 The ompt_get_callback_t type is the type signature of the ompt_get_callback runtime
27 entry point, which retrieves a pointer to a registered tool callback routine (if any) that an OpenMP
28 implementation invokes when a host OpenMP event occurs.
29 Format
C / C++
30 typedef int (*ompt_get_callback_t) (
31 ompt_callbacks_t event,
32 ompt_callback_t *callback
33 );
C / C++

1 Description
2 The ompt_get_callback runtime entry point, which has type signature
3 ompt_get_callback_t, retrieves a pointer to the tool callback that an OpenMP
4 implementation may invoke when a host OpenMP event occurs. If a non-null tool callback is
5 registered for the specified event, the pointer to the tool callback is assigned to the variable passed
6 by reference in callback and ompt_get_callback returns 1; otherwise, it returns 0. If
7 ompt_get_callback returns 0, the value of the variable passed by reference as callback is
8 undefined.
10 The event argument indicates the event for which the callback would be invoked.
11 The callback argument returns a pointer to the callback associated with event.
13 The callback argument cannot be NULL and must point to valid storage.
14 Cross References
15 • ompt_callbacks_t enumeration type, see Section 4.4.2.
16 • ompt_callback_t type, see Section 4.4.4.1.
17 • ompt_set_callback_t type signature, see Section 4.6.1.3.
18 4.6.1.5 ompt_get_thread_data_t
19 Summary
20 The ompt_get_thread_data_t type is the type signature of the
21 ompt_get_thread_data runtime entry point, which returns the address of the thread data
22 object for the current thread.
23 Format
C / C++
24 typedef ompt_data_t *(*ompt_get_thread_data_t) (void);
C / C++
25 Description
26 Each OpenMP thread can have an associated thread data object of type ompt_data_t. The
27 ompt_get_thread_data runtime entry point, which has type signature
28 ompt_get_thread_data_t, retrieves a pointer to the thread data object, if any, that is
29 associated with the current thread. A tool may use a pointer to an OpenMP thread’s data object that
30 ompt_get_thread_data retrieves to inspect or to modify the value of the data object. When
31 an OpenMP thread is created, its data object is initialized with value ompt_data_none.
32 This runtime entry point is async signal safe.
33 Cross References

1 4.6.1.6 ompt_get_num_procs_t
2 Summary
3 The ompt_get_num_procs_t type is the type signature of the ompt_get_num_procs
4 runtime entry point, which returns the number of processors currently available to the execution
5 environment on the host device.
6 Format
C / C++
7 typedef int (*ompt_get_num_procs_t) (void);
C / C++
8 Binding
9 The binding thread set is all threads on the host device.
10 Description
11 The ompt_get_num_procs runtime entry point, which has type signature
12 ompt_get_num_procs_t, returns the number of processors that are available on the host
14 determined and the time that it is read in the calling context due to system actions outside the
15 control of the OpenMP implementation.
17 4.6.1.7 ompt_get_num_places_t
18 Summary
19 The ompt_get_num_places_t type is the type signature of the ompt_get_num_places
20 runtime entry point, which returns the number of places currently available to the execution
21 environment in the place list.
22 Format
C / C++
23 typedef int (*ompt_get_num_places_t) (void);
C / C++
24 Binding
25 The binding thread set is all threads on a device.
26 Description
27 The ompt_get_num_places runtime entry point, which has type signature
28 ompt_get_num_places_t, returns the number of places in the place list. This value is
29 equivalent to the number of places in the place-partition-var ICV in the execution environment of
30 the initial task.

1 Cross References
4 4.6.1.8 ompt_get_place_proc_ids_t
5 Summary
6 The ompt_get_place_procs_ids_t type is the type signature of the
7 ompt_get_num_place_procs_ids runtime entry point, which returns the numerical
8 identifiers of the processors that are available to the execution environment in the specified place.
9 Format
C / C++
10 typedef int (*ompt_get_place_proc_ids_t) (
11 int place_num,
12 int ids_size,
13 int *ids
14 );
C / C++
15 Binding
16 The binding thread set is all threads on a device.
17 Description
18 The ompt_get_place_proc_ids runtime entry point, which has type signature
19 ompt_get_place_proc_ids_t, returns the numerical identifiers of each processor that is
20 associated with the specified place. These numerical identifiers are non-negative, and their meaning
21 is implementation defined.
23 The place_num argument specifies the place that is being queried.
24 The ids argument is an array in which the routine can return a vector of processor identifiers in the
25 specified place.
26 The ids_size argument indicates the size of the result array that is specified by ids.
27 Effect
28 If the ids array of size ids_size is large enough to contain all identifiers then they are returned in ids
29 and their order in the array is implementation defined. Otherwise, if the ids array is too small, the
30 values in ids when the function returns are unspecified. The routine always returns the number of
31 numerical identifiers of the processors that are available to the execution environment in the
32 specified place.

1 4.6.1.9 ompt_get_place_num_t
2 Summary
3 The ompt_get_place_num_t type is the type signature of the ompt_get_place_num
4 runtime entry point, which returns the place number of the place to which the current thread is
5 bound.
6 Format
C / C++
7 typedef int (*ompt_get_place_num_t) (void);
C / C++
8 Description
9 When the current thread is bound to a place, ompt_get_place_num returns the place number
10 associated with the thread. The returned value is between 0 and one less than the value returned by
11 ompt_get_num_places, inclusive. When the current thread is not bound to a place, the routine
12 returns -1.
14 4.6.1.10 ompt_get_partition_place_nums_t
15 Summary
16 The ompt_get_partition_place_nums_t type is the type signature of the
17 ompt_get_partition_place_nums runtime entry point, which returns a list of place
18 numbers that correspond to the places in the place-partition-var ICV of the innermost implicit task.
19 Format
C / C++
20 typedef int (*ompt_get_partition_place_nums_t) (
21 int place_nums_size,
22 int *place_nums
23 );
C / C++
24 Description
25 The ompt_get_partition_place_nums runtime entry point, which has type signature
26 ompt_get_partition_place_nums_t, returns a list of place numbers that correspond to
27 the places in the place-partition-var ICV of the innermost implicit task.

2 The place_nums argument is an array in which the routine can return a vector of place identifiers.
3 The place_nums_size argument indicates the size of the result array that the place_nums argument
4 specifies.
5 Effect
6 If the place_nums array of size place_nums_size is large enough to contain all identifiers then they
7 are returned in place_nums and their order in the array is implementation defined. Otherwise, if the
8 place_nums array is too small, the values in place_nums when the function returns are unspecified.
9 The routine always returns the number of places in the place-partition-var ICV of the innermost
10 implicit task.
11 Cross References
14 4.6.1.11 ompt_get_proc_id_t
15 Summary
16 The ompt_get_proc_id_t type is the type signature of the ompt_get_proc_id runtime
17 entry point, which returns the numerical identifier of the processor of the current thread.
18 Format
C / C++
19 typedef int (*ompt_get_proc_id_t) (void);
C / C++
20 Description
21 The ompt_get_proc_id runtime entry point, which has type signature
22 ompt_get_proc_id_t, returns the numerical identifier of the processor of the current thread.
23 A defined numerical identifier is non-negative, and its meaning is implementation defined. A
24 negative number indicates a failure to retrieve the numerical identifier.
26 4.6.1.12 ompt_get_state_t
27 Summary
28 The ompt_get_state_t type is the type signature of the ompt_get_state runtime entry
29 point, which returns the state and the wait identifier of the current thread.

1 Format
C / C++
2 typedef int (*ompt_get_state_t) (
3 ompt_wait_id_t *wait_id
4 );
C / C++
5 Description
6 Each OpenMP thread has an associated state and a wait identifier. If a thread’s state indicates that
7 the thread is waiting for mutual exclusion then its wait identifier contains an opaque handle that
8 indicates the data object upon which the thread is waiting. The ompt_get_state runtime entry
9 point, which has type signature ompt_get_state_t, retrieves the state and wait identifier of the
10 current thread. The returned value may be any one of the states predefined by ompt_state_t or
11 a value that represents an implementation-specific state. The tool may obtain a string representation
12 for each state with the ompt_enumerate_states function.
13 If the returned state indicates that the thread is waiting for a lock, nest lock, critical region,
14 atomic region, or ordered region then the value of the thread’s wait identifier is assigned to a
15 non-null wait identifier passed as the wait_id argument.
18 The wait_id argument is a pointer to an opaque handle that is available to receive the value of the
19 wait identifier of the thread. If wait_id is not NULL then the entry point assigns the value of the
20 wait identifier of the thread to the object to which wait_id points. If the returned state is not one of
21 the specified wait states then the value of opaque object to which wait_id points is undefined after
22 the call.
24 The argument passed to the entry point must be a reference to a variable of the specified type or
25 NULL.
26 Cross References
30 4.6.1.13 ompt_get_parallel_info_t
31 Summary
32 The ompt_get_parallel_info_t type is the type signature of the
33 ompt_get_parallel_info runtime entry point, which returns information about the parallel
34 region, if any, at the specified ancestor level for the current execution context.

1 Format
C / C++
2 typedef int (*ompt_get_parallel_info_t) (
3 int ancestor_level,
4 ompt_data_t **parallel_data,
5 int *team_size
6 );
C / C++
7 Description
8 During execution, an OpenMP program may employ nested parallel regions. The
9 ompt_get_parallel_info runtime entry point, which has type signature
10 ompt_get_parallel_info_t, retrieves information, about the current parallel region and any
11 enclosing parallel regions for the current execution context. The entry point returns 2 if a parallel
12 region exists at the specified ancestor level and the information is available, 1 if a parallel region
13 exists at the specified ancestor level but the information is currently unavailable, and 0 otherwise.
14 A tool may use the pointer to the data object of a parallel region that it obtains from this runtime
15 entry point to inspect or to modify the value of the data object. When a parallel region is created, its
16 data object will be initialized with the value ompt_data_none.
18 Between a parallel-begin event and an implicit-task-begin event, a call to
19 ompt_get_parallel_info(0,...) may return information about the outer parallel team,
20 the new parallel team or an inconsistent state.
21 If a thread is in the state ompt_state_wait_barrier_implicit_parallel then a call to
22 ompt_get_parallel_info may return a pointer to a copy of the specified parallel region’s
23 parallel_data rather than a pointer to the data word for the region itself. This convention enables
24 the primary thread for a parallel region to free storage for the region immediately after the region
25 ends, yet avoid having some other thread in the team that is executing the region potentially
26 reference the parallel_data object for the region after it has been freed.
28 The ancestor_level argument specifies the parallel region of interest by its ancestor level. Ancestor
29 level 0 refers to the innermost parallel region; information about enclosing parallel regions may be
30 obtained using larger values for ancestor_level.
31 The parallel_data argument returns the parallel data if the argument is not NULL.
32 The team_size argument returns the team size if the argument is not NULL.

1 Effect
2 If the runtime entry point returns 0 or 1, no argument is modified. Otherwise,
3 ompt_get_parallel_info has the following effects:
4 • If a non-null value was passed for parallel_data, the value returned in parallel_data is a pointer
5 to a data word that is associated with the parallel region at the specified level; and
6 • If a non-null value was passed for team_size, the value returned in the integer to which team_size
7 point is the number of threads in the team that is associated with the parallel region.
9 While argument ancestor_level is passed by value, all other arguments to the entry point must be
10 pointers to variables of the specified types or NULL.
11 Cross References
13 4.6.1.14 ompt_get_task_info_t
14 Summary
15 The ompt_get_task_info_t type is the type signature of the ompt_get_task_info
16 runtime entry point, which returns information about the task, if any, at the specified ancestor level
17 in the current execution context.
18 Format
C / C++
19 typedef int (*ompt_get_task_info_t) (
20 int ancestor_level,
21 int *flags,
22 ompt_data_t **task_data,
23 ompt_frame_t **task_frame,
24 ompt_data_t **parallel_data,
25 int *thread_num
26 );
C / C++
27 Description
28 During execution, an OpenMP thread may be executing an OpenMP task. Additionally, the stack of
29 the thread may contain procedure frames that are associated with suspended OpenMP tasks or
30 OpenMP runtime system routines. To obtain information about any task on the stack of the current
31 thread, a tool uses the ompt_get_task_info runtime entry point, which has type signature
32 ompt_get_task_info_t.
33 Ancestor level 0 refers to the active task; information about other tasks with associated frames
34 present on the stack in the current execution context may be queried at higher ancestor levels.

1 The ompt_get_task_info runtime entry point returns 2 if a task region exists at the specified
2 ancestor level and the information is available, 1 if a task region exists at the specified ancestor level
3 but the information is currently unavailable, and 0 otherwise.
4 If a task exists at the specified ancestor level and the information is available then information is
5 returned in the variables passed by reference to the entry point. If no task region exists at the
6 specified ancestor level or the information is unavailable then the values of variables passed by
7 reference to the entry point are undefined when ompt_get_task_info returns.
8 A tool may use a pointer to a data object for a task or parallel region that it obtains from
9 ompt_get_task_info to inspect or to modify the value of the data object. When either a
10 parallel region or a task region is created, its data object will be initialized with the value
11 ompt_data_none.
14 The ancestor_level argument specifies the task region of interest by its ancestor level. Ancestor
15 level 0 refers to the active task; information about ancestor tasks found in the current execution
16 context may be queried at higher ancestor levels.
17 The flags argument returns the task type if the argument is not NULL.
18 The task_data argument returns the task data if the argument is not NULL.
19 The task_frame argument returns the task frame pointer if the argument is not NULL.
20 The parallel_data argument returns the parallel data if the argument is not NULL.
21 The thread_num argument returns the thread number if the argument is not NULL.
22 Effect
23 If the runtime entry point returns 0 or 1, no argument is modified. Otherwise,
24 ompt_get_task_info has the following effects:
25 • If a non-null value was passed for flags then the value returned in the integer to which flags
26 points represents the type of the task at the specified level; possible task types include initial,
27 implicit, explicit, and target tasks;
28 • If a non-null value was passed for task_data then the value that is returned in the object to which
29 it points is a pointer to a data word that is associated with the task at the specified level;
30 • If a non-null value was passed for task_frame then the value that is returned in the object to
31 which task_frame points is a pointer to the ompt_frame_t structure that is associated with the
32 task at the specified level;
33 • If a non-null value was passed for parallel_data then the value that is returned in the object to
34 which parallel_data points is a pointer to a data word that is associated with the parallel region
35 that contains the task at the specified level or, if the task at the specified level is an initial task,
36 NULL; and

1 • If a non-null value was passed for thread_num, then the value that is returned in the object to
2 which thread_num points indicates the number of the thread in the parallel region that is
3 executing the task at the specified level.
5 While argument ancestor_level is passed by value, all other arguments to
6 ompt_get_task_info must be pointers to variables of the specified types or NULL.
7 Cross References
9 • ompt_task_flag_t type, see Section 4.4.4.18.
11 4.6.1.15 ompt_get_task_memory_t
12 Summary
13 The ompt_get_task_memory_t type is the type signature of the
14 ompt_get_task_memory runtime entry point, which returns information about memory ranges
15 that are associated with the task.
16 Format
C / C++
17 typedef int (*ompt_get_task_memory_t)(
18 void **addr,
19 size_t *size,
20 int block
21 );
C / C++
22 Description
23 During execution, an OpenMP thread may be executing an OpenMP task. The OpenMP
24 implementation must preserve the data environment from the creation of the task for the execution
25 of the task. The ompt_get_task_memory runtime entry point, which has type signature
26 ompt_get_task_memory_t, provides information about the memory ranges used to store the
27 data environment for the current task.
28 Multiple memory ranges may be used to store these data. The block argument supports iteration
29 over these memory ranges.
30 The ompt_get_task_memory runtime entry point returns 1 if more memory ranges are
31 available, and 0 otherwise. If no memory is used for a task, size is set to 0. In this case, addr is
32 unspecified.

2 The addr argument is a pointer to a void pointer return value to provide the start address of a
3 memory block.
4 The size argument is a pointer to a size type return value to provide the size of the memory block.
5 The block argument is an integer value to specify the memory block of interest.
6 4.6.1.16 ompt_get_target_info_t
7 Summary
8 The ompt_get_target_info_t type is the type signature of the
9 ompt_get_target_info runtime entry point, which returns identifiers that specify a thread’s
10 current target region and target operation ID, if any.
11 Format
C / C++
12 typedef int (*ompt_get_target_info_t) (
13 uint64_t *device_num,
14 ompt_id_t *target_id,
15 ompt_id_t *host_op_id
16 );
C / C++
17 Description
18 The ompt_get_target_info entry point, which has type signature
19 ompt_get_target_info_t, returns 1 if the current thread is in a target region and 0
20 otherwise. If the entry point returns 0 then the values of the variables passed by reference as its
21 arguments are undefined.
22 If the current thread is in a target region then ompt_get_target_info returns information
23 about the current device, active target region, and active host operation, if any.
26 The device_num argument returns the device number if the current thread is in a target region.
27 The target_id argument returns the target region identifier if the current thread is in a target
28 region.
29 If the current thread is in the process of initiating an operation on a target device (for example,
30 copying data to or from an accelerator or launching a kernel), then host_op_id returns the identifier
31 for the operation; otherwise, host_op_id returns ompt_id_none.

2 Arguments passed to the entry point must be valid references to variables of the specified types.
3 Cross References
5 4.6.1.17 ompt_get_num_devices_t
6 Summary
7 The ompt_get_num_devices_t type is the type signature of the
8 ompt_get_num_devices runtime entry point, which returns the number of available devices.
9 Format
C / C++
10 typedef int (*ompt_get_num_devices_t) (void);
C / C++
11 Description
12 The ompt_get_num_devices runtime entry point, which has type signature
13 ompt_get_num_devices_t, returns the number of devices available to an OpenMP program.
15 4.6.1.18 ompt_get_unique_id_t
16 Summary
17 The ompt_get_unique_id_t type is the type signature of the ompt_get_unique_id
18 runtime entry point, which returns a unique number.
19 Format
C / C++
20 typedef uint64_t (*ompt_get_unique_id_t) (void);
C / C++
21 Description
22 The ompt_get_unique_id runtime entry point, which has type signature
23 ompt_get_unique_id_t, returns a number that is unique for the duration of an OpenMP
24 program. Successive invocations may not result in consecutive or even increasing numbers.

1 4.6.1.19 ompt_finalize_tool_t
2 Summary
3 The ompt_finalize_tool_t type is the type signature of the ompt_finalize_tool
4 runtime entry point, which enables a tool to finalize itself.
5 Format
C / C++
6 typedef void (*ompt_finalize_tool_t) (void);
C / C++
7 Description
8 A tool may detect that the execution of an OpenMP program is ending before the OpenMP
9 implementation does. To facilitate clean termination of the tool, the tool may invoke the
10 ompt_finalize_tool runtime entry point, which has type signature
11 ompt_finalize_tool_t. Upon completion of ompt_finalize_tool, no OMPT
12 callbacks are dispatched.
13 Effect
14 The ompt_finalize_tool routine detaches the tool from the runtime, unregisters all callbacks
15 and invalidates all OMPT entry points passed to the tool in the lookup-function. Upon completion
16 of ompt_finalize_tool, no further callbacks will be issued on any thread.
17 Before the callbacks are unregistered, the OpenMP runtime should attempt to dispatch all
18 outstanding registered callbacks as well as the callbacks that would be encountered during
19 shutdown of the runtime, if possible in the current execution context.
20 4.6.2 Entry Points in the OMPT Device Tracing Interface

21 The runtime entry points with type signatures of the types that are specified in this section enable a
22 tool to trace activities on a device.
23 4.6.2.1 ompt_get_device_num_procs_t
24 Summary
25 The ompt_get_device_num_procs_t type is the type signature of the
26 ompt_get_device_num_procs runtime entry point, which returns the number of processors
27 currently available to the execution environment on the specified device.
28 Format
C / C++
29 typedef int (*ompt_get_device_num_procs_t) (
30 ompt_device_t *device
31 );
C / C++

1 Description
2 The ompt_get_device_num_procs runtime entry point, which has type signature
3 ompt_get_device_num_procs_t, returns the number of processors that are available on the
5 determined and the time that it is read in the calling context due to system actions outside the
6 control of the OpenMP implementation.
8 The device argument is a pointer to an opaque object that represents the target device instance. The
9 pointer to the device instance object is used by functions in the device tracing interface to identify
10 the device being addressed.
11 Cross References
12 • ompt_device_t type, see Section 4.4.4.5.
13 4.6.2.2 ompt_get_device_time_t
14 Summary
15 The ompt_get_device_time_t type is the type signature of the
16 ompt_get_device_time runtime entry point, which returns the current time on the specified
17 device.
18 Format
C / C++
19 typedef ompt_device_time_t (*ompt_get_device_time_t) (
21 );
C / C++
22 Description
23 Host and target devices are typically distinct and run independently. If host and target devices are
24 different hardware components, they may use different clock generators. For this reason, a common
25 time base for ordering host-side and device-side events may not be available.
26 The ompt_get_device_time runtime entry point, which has type signature
27 ompt_get_device_time_t, returns the current time on the specified device. A tool can use
28 this information to align time stamps from different devices.

1 Cross References
3 • ompt_device_time_t type, see Section 4.4.4.6.
4 4.6.2.3 ompt_translate_time_t
5 Summary
6 The ompt_translate_time_t type is the type signature of the ompt_translate_time
7 runtime entry point, which translates a time value that is obtained from the specified device to a
8 corresponding time value on the host device.
9 Format
C / C++
10 typedef double (*ompt_translate_time_t) (
12 ompt_device_time_t time
13 );
C / C++
14 Description
15 The ompt_translate_time runtime entry point, which has type signature
16 ompt_translate_time_t, translates a time value obtained from the specified device to a
17 corresponding time value on the host device. The returned value for the host time has the same
18 meaning as the value returned from omp_get_wtime.
19
20 Note – The accuracy of time translations may degrade, if they are not performed promptly after a
21 device time value is received and if either the host or device vary their clock speeds. Prompt
22 translation of device times to host times is recommended.
23
28 The time argument is a time from the specified device.
29 Cross References
30 • omp_get_wtime routine, see Section 3.10.1.
32 • ompt_device_time_t type, see Section 4.4.4.6.

1 4.6.2.4 ompt_set_trace_ompt_t
2 Summary
3 The ompt_set_trace_ompt_t type is the type signature of the ompt_set_trace_ompt
4 runtime entry point, which enables or disables the recording of trace records for one or more types
5 of OMPT events.
6 Format
C / C++
7 typedef ompt_set_result_t (*ompt_set_trace_ompt_t) (
9 unsigned int enable,
10 unsigned int etype
11 );
C / C++
13 The device argument points to an opaque object that represents the target device instance. Functions
14 in the device tracing interface use this pointer to identify the device that is being addressed.
15 The etype argument indicates the events to which the invocation of ompt_set_trace_ompt
16 applies. If the value of etype is 0 then the invocation applies to all events. If etype is positive then it
17 applies to the event in ompt_callbacks_t that matches that value.
18 The enable argument indicates whether tracing should be enabled or disabled for the event or events
19 that the etype argument specifies. A positive value for enable indicates that recording should be
20 enabled; a value of 0 for enable indicates that recording should be disabled.
21 Restrictions
22 Restrictions on the ompt_set_trace_ompt runtime entry point are as follows:
23 • The entry point must not return ompt_set_sometimes_paired.
24 Cross References
26 • ompt_callbacks_t type, see Section 4.4.2.

1 4.6.2.5 ompt_set_trace_native_t
2 Summary
3 The ompt_set_trace_native_t type is the type signature of the
4 ompt_set_trace_native runtime entry point, which enables or disables the recording of
5 native trace records for a device.
6 Format
C / C++
7 typedef ompt_set_result_t (*ompt_set_trace_native_t) (
9 int enable,
10 int flags
11 );
C / C++
12 Description
13 This interface is designed for use by a tool that cannot directly use native control functions for the
14 device. If a tool can directly use the native control functions then it can invoke native control
15 functions directly using pointers that the lookup function associated with the device provides and
16 that are described in the documentation string that is provided to the device initializer callback.
20 The enable argument indicates whether this invocation should enable or disable recording of events.
21 The flags argument specifies the kinds of native device monitoring to enable or to disable. Each
22 kind of monitoring is specified by a flag bit. Flags can be composed by using logical or to combine
23 enumeration values from type ompt_native_mon_flag_t.
24 To start, to pause, to flush, or to stop tracing for a specific target device associated with device, a
25 tool invokes the ompt_start_trace, ompt_pause_trace, ompt_flush_trace, or
26 ompt_stop_trace runtime entry point for the device.
27 Restrictions
28 Restrictions on the ompt_set_trace_native runtime entry point are as follows:
29 • The entry point must not return ompt_set_sometimes_paired.
30 Cross References

1 4.6.2.6 ompt_start_trace_t
2 Summary
3 The ompt_start_trace_t type is the type signature of the ompt_start_trace runtime
4 entry point, which starts tracing of activity on a specific device.
5 Format
C / C++
6 typedef int (*ompt_start_trace_t) (
8 ompt_callback_buffer_request_t request,
9 ompt_callback_buffer_complete_t complete
10 );
C / C++
11 Description
12 A device’s ompt_start_trace runtime entry point, which has type signature
13 ompt_start_trace_t, initiates tracing on the device. Under normal operating conditions,
14 every event buffer provided to a device by a tool callback is returned to the tool before the OpenMP
15 runtime shuts down. If an exceptional condition terminates execution of an OpenMP program, the
16 OpenMP runtime may not return buffers provided to the device.
17 An invocation of ompt_start_trace returns 1 if the command succeeds and 0 otherwise.
21 The request argument specifies a tool callback that supplies a buffer in which a device can deposit
22 events.
23 The complete argument specifies a tool callback that is invoked by the OpenMP implementation to
24 empty a buffer that contains event records.
25 Cross References
27 • ompt_callback_buffer_request_t callback type, see Section 4.5.2.23.
28 • ompt_callback_buffer_complete_t callback type, see Section 4.5.2.24.
29 4.6.2.7 ompt_pause_trace_t
30 Summary
31 The ompt_pause_trace_t type is the type signature of the ompt_pause_trace runtime
32 entry point, which pauses or restarts activity tracing on a specific device.

1 Format
C / C++
2 typedef int (*ompt_pause_trace_t) (
4 int begin_pause
5 );
C / C++
6 Description
7 A device’s ompt_pause_trace runtime entry point, which has type signature
8 ompt_pause_trace_t, pauses or resumes tracing on a device. An invocation of
9 ompt_pause_trace returns 1 if the command succeeds and 0 otherwise. Redundant pause or
10 resume commands are idempotent and will return the same value as the prior command.
14 The begin_pause argument indicates whether to pause or to resume tracing. To resume tracing,
15 zero should be supplied for begin_pause; To pause tracing, any other value should be supplied.
16 Cross References
18 4.6.2.8 ompt_flush_trace_t
19 Summary
20 The ompt_flush_trace_t type is the type signature of the ompt_flush_trace runtime
21 entry point, which causes all pending trace records for the specified device to be delivered.
22 Format
C / C++
23 typedef int (*ompt_flush_trace_t) (
25 );
C / C++
26 Description
27 A device’s ompt_flush_trace runtime entry point, which has type signature
28 ompt_flush_trace_t, causes the OpenMP implementation to issue a sequence of zero or more
29 buffer completion callbacks to deliver all trace records that have been collected prior to the flush.
30 An invocation of ompt_flush_trace returns 1 if the command succeeds and 0 otherwise.

4 Cross References
6 4.6.2.9 ompt_stop_trace_t
7 Summary
8 The ompt_stop_trace_t type is the type signature of the ompt_stop_trace runtime entry
9 point, which stops tracing for a device.
10 Format
C / C++
11 typedef int (*ompt_stop_trace_t) (
13 );
C / C++
14 Description
15 A device’s ompt_stop_trace runtime entry point, which has type signature
16 ompt_stop_trace_t, halts tracing on the device and requests that any pending trace records
17 are flushed. An invocation of ompt_stop_trace returns 1 if the command succeeds and 0
18 otherwise.
22 Cross References
24 4.6.2.10 ompt_advance_buffer_cursor_t
25 Summary
26 The ompt_advance_buffer_cursor_t type is the type signature of the
27 ompt_advance_buffer_cursor runtime entry point, which advances a trace buffer cursor to
28 the next record.

1 Format
C / C++
2 typedef int (*ompt_advance_buffer_cursor_t) (
5 size_t size,
6 ompt_buffer_cursor_t current,
7 ompt_buffer_cursor_t *next
8 );
C / C++
9 Description
10 A device’s ompt_advance_buffer_cursor runtime entry point, which has type signature
11 ompt_advance_buffer_cursor_t, advances a trace buffer pointer to the next trace record.
12 An invocation of ompt_advance_buffer_cursor returns true if the advance is successful
13 and the next position in the buffer is valid.
17 The buffer argument indicates a trace buffer that is associated with the cursors.
18 The argument size indicates the size of buffer in bytes.
19 The current argument is an opaque buffer cursor.
20 The next argument returns the next value of an opaque buffer cursor.
21 Cross References
24 4.6.2.11 ompt_get_record_type_t
25 Summary
26 The ompt_get_record_type_t type is the type signature of the
27 ompt_get_record_type runtime entry point, which inspects the type of a trace record.
28 Format
C / C++
29 typedef ompt_record_t (*ompt_get_record_type_t) (
31 ompt_buffer_cursor_t current
32 );
C / C++

1 Description
2 Trace records for a device may be in one of two forms: native record format, which may be
3 device-specific, or OMPT record format, in which each trace record corresponds to an OpenMP
4 event and most fields in the record structure are the arguments that would be passed to the OMPT
5 callback for the event.
6 A device’s ompt_get_record_type runtime entry point, which has type signature
7 ompt_get_record_type_t, inspects the type of a trace record and indicates whether the
8 record at the current position in the trace buffer is an OMPT record, a native record, or an invalid
9 record. An invalid record type is returned if the cursor is out of bounds.
11 The buffer argument indicates a trace buffer.
13 Cross References
14 • ompt_record_t type, see Section 4.4.3.1.
17 4.6.2.12 ompt_get_record_ompt_t
18 Summary
19 The ompt_get_record_ompt_t type is the type signature of the
20 ompt_get_record_ompt runtime entry point, which obtains a pointer to an OMPT trace
21 record from a trace buffer associated with a device.
22 Format
C / C++
23 typedef ompt_record_ompt_t *(*ompt_get_record_ompt_t) (
25 ompt_buffer_cursor_t current
26 );
C / C++
27 Description
28 A device’s ompt_get_record_ompt runtime entry point, which has type signature
29 ompt_get_record_ompt_t, returns a pointer that may point to a record in the trace buffer, or
30 it may point to a record in thread local storage in which the information extracted from a record was
31 assembled. The information available for an event depends upon its type.
32 The return value of the ompt_record_ompt_t type includes a field of a union type that can
33 represent information for any OMPT event record type. Another call to the runtime entry point may
34 overwrite the contents of the fields in a record returned by a prior invocation.

4 Cross References
5 • ompt_record_ompt_t type, see Section 4.4.3.4.
8 4.6.2.13 ompt_get_record_native_t
9 Summary
10 The ompt_get_record_native_t type is the type signature of the
11 ompt_get_record_native runtime entry point, which obtains a pointer to a native trace
12 record from a trace buffer associated with a device.
13 Format
C / C++
14 typedef void *(*ompt_get_record_native_t) (
16 ompt_buffer_cursor_t current,
17 ompt_id_t *host_op_id
18 );
C / C++
19 Description
20 A device’s ompt_get_record_native runtime entry point, which has type signature
21 ompt_get_record_native_t, returns a pointer that may point may point into the specified
22 trace buffer, or into thread local storage in which the information extracted from a trace record was
23 assembled. The information available for a native event depends upon its type. If the function
24 returns a non-null result, it will also set the object to which host_op_id points to a host-side
25 identifier for the operation that is associated with the record. A subsequent call to
26 ompt_get_record_native may overwrite the contents of the fields in a record returned by a
27 prior invocation.
31 The host_op_id argument is a pointer to an identifier that is returned by the function. The entry
32 point sets the identifier to which host_op_id points to the value of a host-side identifier for an
33 operation on a target device that was created when the operation was initiated by the host.

1 Cross References
5 4.6.2.14 ompt_get_record_abstract_t
6 Summary
7 The ompt_get_record_abstract_t type is the type signature of the
8 ompt_get_record_abstract runtime entry point, which summarizes the context of a native
9 (device-specific) trace record.
10 Format
C / C++
11 typedef ompt_record_abstract_t *(*ompt_get_record_abstract_t) (
12 void *native_record
13 );
C / C++
14 Description
15 An OpenMP implementation may execute on a device that logs trace records in a native
16 (device-specific) format that a tool cannot interpret directly. The
17 ompt_get_record_abstract runtime entry point of a device, which has type signature
18 ompt_get_record_abstract_t, translates a native trace record into a standard form.
20 The native_record argument is a pointer to a native trace record.
21 Cross References
22 • ompt_record_abstract_t type, see Section 4.4.3.3.
23 4.6.3 Lookup Entry Points: ompt_function_lookup_t

24 Summary
25 The ompt_function_lookup_t type is the type signature of the lookup runtime entry points
26 that provide pointers to runtime entry points that are part of the OMPT interface.
27 Format
C / C++
28 typedef void (*ompt_interface_fn_t) (void);
29
30 typedef ompt_interface_fn_t (*ompt_function_lookup_t) (
31 const char *interface_function_name
32 );
C / C++

1 Description
2 An OpenMP implementation provides a pointer to a lookup routine that provides pointers to OMPT
3 runtime entry points. When the implementation invokes a tool initializer to configure the OMPT
4 callback interface, it provides a lookup function that provides pointers to runtime entry points that
5 implement routines that are part of the OMPT callback interface. Alternatively, when it invokes a
6 tool initializer to configure the OMPT tracing interface for a device, it provides a lookup function
7 that provides pointers to runtime entry points that implement tracing control routines appropriate
8 for that device.
9 If the provided function name is unknown to the OpenMP implementation, the function returns
10 NULL. In a compliant implementation, the lookup function provided by the tool initializer for the
11 OMPT callback interface returns a valid function pointer for any OMPT runtime entry point name
12 listed in Table 4.1.
13 A compliant implementation of a lookup function passed to a tool’s
14 ompt_device_initialize callback must provide non-NULL function pointers for all strings
15 in Table 4.4, except for ompt_set_trace_ompt and ompt_get_record_ompt, as
16 described in Section 4.2.5.
18 The interface_function_name argument is a C string that represents the name of a runtime entry
19 point.
20 Cross References
21 • Tool initializer for a device’s OMPT tracing interface, see Section 4.2.5.
22 • Tool initializer for the OMPT callback interface, see Section 4.5.1.1.
23 • Entry points in the OMPT callback interface, see Table 4.1 for a list and Section 4.6.1 for
24 detailed definitions.
25 • Entry points in the OMPT tracing interface, see Table 4.4 for a list and Section 4.6.2 for detailed
26 definitions.

1 5 OMPD Interface
2 This chapter describes OMPD, which is an interface for third-party tools. Third-party tools exist in
3 separate processes from the OpenMP program. To provide OMPD support, an OpenMP
4 implementation must provide an OMPD library that the third-party tool can load. An OpenMP
5 implementation does not need to maintain any extra information to support OMPD inquiries from
6 third-party tools unless it is explicitly instructed to do so.
7 OMPD allows third-party tools such as debuggers to inspect the OpenMP state of a live program or
8 core file in an implementation-agnostic manner. That is, a third-party tool that uses OMPD should
9 work with any conforming OpenMP implementation. An OpenMP implementer provides a library
10 for OMPD that a third-party tool can dynamically load. The third-party tool can use the interface
11 exported by the OMPD library to inspect the OpenMP state of a program. In order to satisfy
12 requests from the third-party tool, the OMPD library may need to read data from the OpenMP
13 program, or to find the addresses of symbols in it. The OMPD library provides this functionality
14 through a callback interface that the third-party tool must instantiate for the OMPD library.
15 To use OMPD, the third-party tool loads the OMPD library. The OMPD library exports the API
16 that is defined throughout this section, and the third-party tool uses the API to determine OpenMP
17 information about the OpenMP program. The OMPD library must look up the symbols and read
18 data out of the program. It does not perform these operations directly but instead directs the third-
19 party tool to perform them by using the callback interface that the third-party tool exports.
20 The OMPD design insulates third-party tools from the internal structure of the OpenMP runtime,
21 while the OMPD library is insulated from the details of how to access the OpenMP program. This
22 decoupled design allows for flexibility in how the OpenMP program and third-party tool are
23 deployed, so that, for example, the third-party tool and the OpenMP program are not required to
24 execute on the same machine.
25 Generally, the third-party tool does not interact directly with the OpenMP runtime but instead
26 interacts with the runtime through the OMPD library. However, a few cases require the third-party
27 tool to access the OpenMP runtime directly. These cases fall into two broad categories. The first is
28 during initialization where the third-party tool must look up symbols and read variables in the
29 OpenMP runtime in order to identify the OMPD library that it should use, which is discussed in
30 Section 5.2.2 and Section 5.2.3. The second category relates to arranging for the third-party tool to
31 be notified when certain events occur during the execution of the OpenMP program. For this
32 purpose, the OpenMP implementation must define certain symbols in the runtime code, as is
33 discussed in Section 5.6. Each of these symbols corresponds to an event type. The OpenMP
34 runtime must ensure that control passes through the appropriate named location when events occur.
35 If the third-party tool requires notification of an event, it can plant a breakpoint at the matching
577
1 location. The location can, but may not, be a function. It can, for example, simply be a label.
2 However, the names of the locations must have external C linkage.
3 5.1 OMPD Interfaces Definitions

C / C++
4 A compliant implementation must supply a set of definitions for the OMPD runtime entry points,
5 OMPD third-party tool callback signatures, third-party tool interface functions and the special data
6 types of their parameters and return values. These definitions, which are listed throughout this
7 chapter, and their associated declarations shall be provided in a header file named omp-tools.h.
8 In addition, the set of definitions may specify other implementation-specific values.
9 The ompd_dll_locations variable, all OMPD third-party tool interface functions, and all
10 OMPD runtime entry points are external symbols with C linkage.
C / C++
11 5.2 Activating a Third-Party Tool

12 The third-party tool and the OpenMP program exist as separate processes. Thus, coordination is
13 required between the OpenMP runtime and the third-party tool for OMPD.
14 5.2.1 Enabling Runtime Support for OMPD

15 In order to support third-party tools, the OpenMP runtime may need to collect and to store
16 information that it may not otherwise maintain. The OpenMP runtime collects whatever
17 information is necessary to support OMPD if the environment variable OMP_DEBUG is set to
18 enabled.
19 Cross References
20 • Activating a first-party tool, see Section 4.2.
21 • OMP_DEBUG environment variable, see Section 6.21.
22 5.2.2 ompd_dll_locations
23 Summary
24 The ompd_dll_locations global variable points to the locations of OMPD libraries that are
25 compatible with the OpenMP implementation.
26 Format
C
27 extern const char **ompd_dll_locations;
C

1 Description
2 An OpenMP runtime may have more than one OMPD library. The third-party tool must be able to
3 locate the right library to use for the OpenMP program that it is examining. The OpenMP runtime
4 system must provide a public variable ompd_dll_locations, which is an argv-style vector of
5 filename string pointers that provides the names of any compatible OMPD libraries. This variable
6 must have C linkage. The third-party tool uses the name of the variable verbatim and, in particular,
7 does not apply any name mangling before performing the look up.
8 The architecture on which the third-party tool and, thus, the OMPD library execute does not have to
9 match the architecture on which the OpenMP program that is being examined executes. The
10 third-party tool must interpret the contents of ompd_dll_locations to find a suitable OMPD
11 library that matches its own architectural characteristics. On platforms that support different
12 architectures (for example, 32-bit vs 64-bit), OpenMP implementations are encouraged to provide
13 an OMPD library for each supported architecture that can handle OpenMP programs that run on
14 any supported architecture. Thus, for example, a 32-bit debugger that uses OMPD should be able to
15 debug a 64-bit OpenMP program by loading a 32-bit OMPD implementation that can manage a
16 64-bit OpenMP runtime.
17 The ompd_dll_locations variable points to a NULL-terminated vector of zero or more
18 NULL-terminated pathname strings that do not have any filename conventions. This vector must be
19 fully initialized before ompd_dll_locations is set to a non-null value. Thus, if a third-party
20 tool, such as a debugger, stops execution of the OpenMP program at any point at which
21 ompd_dll_locations is non-null, the vector of strings to which it points shall be valid and
22 complete.
23 Cross References
24 • ompd_dll_locations_valid global variable, see Section 5.2.3.
25 5.2.3 ompd_dll_locations_valid
26 Summary
27 The OpenMP runtime notifies third-party tools that ompd_dll_locations is valid by allowing
28 execution to pass through a location that the symbol ompd_dll_locations_valid identifies.
29 Format
C
30 void ompd_dll_locations_valid(void);
C
CHAPTER 5. OMPD INTERFACE 579

1 Description
2 Since ompd_dll_locations may not be a static variable, it may require runtime initialization.
3 The OpenMP runtime notifies third-party tools that ompd_dll_locations is valid by having
4 execution pass through a location that the symbol ompd_dll_locations_valid identifies. If
5 ompd_dll_locations is NULL, a third-party tool can place a breakpoint at
6 ompd_dll_locations_valid to be notified that ompd_dll_locations is initialized. In
7 practice, the symbol ompd_dll_locations_valid may not be a function; instead, it may be a
8 labeled machine instruction through which execution passes once the vector is valid.
9 5.3 OMPD Data Types

10 This section defines OMPD data types.
11 5.3.1 Size Type

12 Summary
13 The ompd_size_t type specifies the number of bytes in opaque data objects that are passed
14 across the OMPD API.
15 Format
C / C++
16 typedef uint64_t ompd_size_t;
C / C++
17 5.3.2 Wait ID Type

18 Summary
19 A variable of ompd_wait_id_t type identifies the object on which a thread waits.
20 Format
C / C++
21 typedef uint64_t ompd_wait_id_t;
C / C++
22 Description
23 The values and meaning of ompd_wait_id_t is the same as defined for the
24 ompt_wait_id_t type.
25 Cross References

1 5.3.3 Basic Value Types
2 Summary
3 These definitions represent word, address, and segment value types.
4 Format
C / C++
5 typedef uint64_t ompd_addr_t;
6 typedef int64_t ompd_word_t;
7 typedef uint64_t ompd_seg_t;
C / C++
8 Description
9 The ompd_addr_t type represents an address in an OpenMP process with an unsigned integer type.
10 The ompd_word_t type represents a data word from the OpenMP runtime with a signed integer
11 type. The ompd_seg_t type represents a segment value with an unsigned integer type.
12 5.3.4 Address Type

13 Summary
14 The ompd_address_t type is used to specify device addresses.
15 Format
C / C++
16 typedef struct ompd_address_t {
17 ompd_seg_t segment;
18 ompd_addr_t address;
19 } ompd_address_t;
C / C++
20 Description
21 The ompd_address_t type is a structure that OMPD uses to specify device addresses, which
22 may or may not be segmented. For non-segmented architectures, ompd_segment_none is used
23 in the segment field of ompd_address_t; it is an instance of the ompd_seg_t type that has the
24 value 0.

1 5.3.5 Frame Information Type
2 Summary
3 The ompd_frame_info_t type is used to specify frame information.
4 Format
C / C++
5 typedef struct ompd_frame_info_t {
6 ompd_address_t frame_address;
7 ompd_word_t frame_flag;
8 } ompd_frame_info_t;
C / C++
9 Description
10 The ompd_frame_info_t type is a structure that OMPD uses to specify frame information.
11 The frame_address field of ompd_frame_info_t identifies a frame. The frame_flag field of
12 ompd_frame_info_t indicates what type of information is provided in frame_address. The
13 values and meaning is the same as defined for the ompt_frame_flag_t enumeration type.
14 Cross References
16 5.3.6 System Device Identifiers

17 Summary
18 The ompd_device_t type provides information about OpenMP devices.
19 Format
C / C++
20 typedef uint64_t ompd_device_t;
C / C++
21 Description
22 OpenMP runtimes may utilize different underlying devices, each represented by a device identifier.
23 The device identifiers can vary in size and format and, thus, are not explicitly represented in the
24 OMPD interface. Instead, a device identifier is passed across the interface via its
25 ompd_device_t kind, its size in bytes and a pointer to where it is stored. The OMPD library and
26 the third-party tool use the ompd_device_t kind to interpret the format of the device identifier
27 that is referenced by the pointer argument. Each different device identifier kind is represented by a
28 unique unsigned 64-bit integer value.
29 Recommended values of ompd_device_t kinds are defined in the ompd-types.h header file,
30 which is available on http://www.openmp.org/.

1 5.3.7 Native Thread Identifiers
2 Summary
3 The ompd_thread_id_t type provides information about native threads.
4 Format
C / C++
5 typedef uint64_t ompd_thread_id_t;
C / C++
6 Description
7 OpenMP runtimes may use different native thread implementations. Native thread identifiers for
8 these implementations can vary in size and format and, thus, are not explicitly represented in the
9 OMPD interface. Instead, a native thread identifier is passed across the interface via its
10 ompd_thread_id_t kind, its size in bytes and a pointer to where it is stored. The OMPD
11 library and the third-party tool use the ompd_thread_id_t kind to interpret the format of the
12 native thread identifier that is referenced by the pointer argument. Each different native thread
13 identifier kind is represented by a unique unsigned 64-bit integer value.
14 Recommended values of ompd_thread_id_t kinds, and formats for some corresponding native
15 thread identifiers, are defined in the ompd-types.h header file, which is available on
16 http://www.openmp.org/.
17 5.3.8 OMPD Handle Types

18 Summary
19 The OMPD library defines handles for referring to address spaces, threads, parallel regions and
20 tasks. The internal structure of the handles are opaque to the third-party tool.
21 Format
C / C++
22 typedef struct _ompd_aspace_handle ompd_address_space_handle_t;
23 typedef struct _ompd_thread_handle ompd_thread_handle_t;
24 typedef struct _ompd_parallel_handle ompd_parallel_handle_t;
25 typedef struct _ompd_task_handle ompd_task_handle_t;
C / C++
26 Description
27 OMPD uses handles for address spaces (ompd_address_space_handle_t), threads
28 (ompd_thread_handle_t), parallel regions (ompd_parallel_handle_t), and tasks
29 (ompd_task_handle_t). Each operation of the OMPD interface that applies to a particular
30 address space, thread, parallel region or task must explicitly specify a corresponding handle. A
31 handle for an entity is constant while the entity itself is alive. Handles are defined by the OMPD
32 library and are opaque to the third-party tool.

1 Defining externally visible type names in this way introduces type safety to the interface, and helps
2 to catch instances where incorrect handles are passed by the third-party tool to the OMPD library.
3 The structures do not need to be defined; instead, the OMPD library must cast incoming (pointers
4 to) handles to the appropriate internal, private types.
5 5.3.9 OMPD Scope Types

6 Summary
7 The ompd_scope_t type identifies OMPD scopes.
8 Format
C / C++
9 typedef enum ompd_scope_t {
10 ompd_scope_global = 1,
11 ompd_scope_address_space = 2,
12 ompd_scope_thread = 3,
13 ompd_scope_parallel = 4,
14 ompd_scope_implicit_task = 5,
15 ompd_scope_task = 6
16 } ompd_scope_t;
C / C++
17 Description
18 The ompd_scope_t type identifies OpenMP scopes, including those related to parallel regions
19 and tasks. When used in an OMPD interface function call, the scope type and the OMPD handle
20 must match according to Table 5.1.
TABLE 5.1: Mapping of Scope Type and OMPD Handles
Scope types Handles

ompd_scope_global Address space handle for the host device
ompd_scope_address_space Any address space handle
ompd_scope_thread Any thread handle
ompd_scope_parallel Any parallel region handle
ompd_scope_implicit_task Task handle for an implicit task
ompd_scope_task Any task handle

1 5.3.10 ICV ID Type
2 Summary
3 The ompd_icv_id_t type identifies an OpenMP implementation ICV.
4 Format
C / C++
5 typedef uint64_t ompd_icv_id_t;
C / C++
6 The ompd_icv_id_t type identifies OpenMP implementation ICVs. ompd_icv_undefined
7 is an instance of this type with the value 0.
8 5.3.11 Tool Context Types

9 Summary
10 A third-party tool defines contexts to identify abstractions uniquely. The internal structure of these
11 contexts are opaque to the OMPD library.
12 Format
C / C++
13 typedef struct _ompd_aspace_cont ompd_address_space_context_t;
14 typedef struct _ompd_thread_cont ompd_thread_context_t;
C / C++
15 Description
16 A third-party tool uniquely defines an address space context to identify the address space for the
17 process that it is monitoring. Similarly, it uniquely defines a thread context to identify a native
18 thread of the process that it is monitoring. These contexts are opaque to the OMPD library.
19 5.3.12 Return Code Types

20 Summary
21 The ompd_rc_t type is the return code type of an OMPD operation.
22 Format
C / C++
23 typedef enum ompd_rc_t {
24 ompd_rc_ok = 0,
25 ompd_rc_unavailable = 1,
26 ompd_rc_stale_handle = 2,
27 ompd_rc_bad_input = 3,
28 ompd_rc_error = 4,
29 ompd_rc_unsupported = 5,
30 ompd_rc_needs_state_tracking = 6,

1 ompd_rc_incompatible = 7,
2 ompd_rc_device_read_error = 8,
3 ompd_rc_device_write_error = 9,
4 ompd_rc_nomem = 10,
5 ompd_rc_incomplete = 11,
6 ompd_rc_callback_error = 12
7 } ompd_rc_t;
C / C++
8 Description
9 The ompd_rc_t type is used for the return codes of OMPD operations. The return code types and
10 their semantics are defined as follows:
11 • ompd_rc_ok is returned when the operation is successful;
12 • ompd_rc_unavailable is returned when information is not available for the specified
13 context;
14 • ompd_rc_stale_handle is returned when the specified handle is no longer valid;
15 • ompd_rc_bad_input is returned when the input parameters (other than handle) are invalid;
16 • ompd_rc_error is returned when a fatal error occurred;
17 • ompd_rc_unsupported is returned when the requested operation is not supported;
18 • ompd_rc_needs_state_tracking is returned when the state tracking operation failed
19 because state tracking is not currently enabled;
20 • ompd_rc_device_read_error is returned when a read operation failed on the device;
21 • ompd_rc_device_write_error is returned when a write operation failed on the device;
22 • ompd_rc_incompatible is returned when this OMPD library is incompatible with the
23 OpenMP program or is not capable of handling it;
24 • ompd_rc_nomem is returned when a memory allocation fails;
25 • ompd_rc_incomplete is returned when the information provided on return is incomplete,
26 while the arguments are still set to valid values; and
27 • ompd_rc_callback_error is returned when the callback interface or any one of the
28 required callback routines provided by the third-party tool is invalid.
29 5.3.13 Primitive Type Sizes

30 Summary
31 The ompd_device_type_sizes_t type provides the size of primitive types in the OpenMP
32 architecture address space.

1 Format
C / C++
2 typedef struct ompd_device_type_sizes_t {
3 uint8_t sizeof_char;
4 uint8_t sizeof_short;
5 uint8_t sizeof_int;
6 uint8_t sizeof_long;
7 uint8_t sizeof_long_long;
8 uint8_t sizeof_pointer;
9 } ompd_device_type_sizes_t;
C / C++
10 Description
11 The ompd_device_type_sizes_t type is used in operations through which the OMPD
12 library can interrogate the third-party tool about the size of primitive types for the target
13 architecture of the OpenMP runtime, as returned by the sizeof operator. The fields of
14 ompd_device_type_sizes_t give the sizes of the eponymous basic types used by the
15 OpenMP runtime. As the third-party tool and the OMPD library, by definition, execute on the same
16 architecture, the size of the fields can be given as uint8_t.
17 Cross References
18 • ompd_callback_sizeof_fn_t type, see Section 5.4.2.2.
19 5.4 OMPD Third-Party Tool Callback Interface

20 For the OMPD library to provide information about the internal state of the OpenMP runtime
21 system in an OpenMP process or core file, it must have a means to extract information from the
22 OpenMP process that the third-party tool is examining. The OpenMP process on which the
23 third-party tool is operating may be either a “live” process or a core file, and a thread may be either
24 a “live” thread in an OpenMP process or a thread in a core file. To enable the OMPD library to
25 extract state information from an OpenMP process or core file, the third-party tool must supply the
26 OMPD library with callback functions to inquire about the size of primitive types in the device of
27 the OpenMP process, to look up the addresses of symbols, and to read and to write memory in the
28 device. The OMPD library uses these callbacks to implement its interface operations. The OMPD
29 library only invokes the callback functions in direct response to calls made by the third-party tool to
30 the OMPD library.
31 Description of Return Codes

32 All of the OMPD callback functions must return the following return codes or function-specific
33 return codes:
34 • ompd_rc_ok on success; or
35 • ompd_rc_stale_handle if an invalid context argument is provided.

1 5.4.1 Memory Management of OMPD Library
2 The OMPD library must not access the heap manager directly. Instead, if it needs heap memory it
3 must use the memory allocation and deallocation callback functions that are described in this
4 section, ompd_callback_memory_alloc_fn_t (see Section 5.4.1.1) and
5 ompd_callback_memory_free_fn_t (see Section 5.4.1.2), which are provided by the
6 third-party tool to obtain and to release heap memory. This mechanism ensures that the library does
7 not interfere with any custom memory management scheme that the third-party tool may use.
8 If the OMPD library is implemented in C++ then memory management operators, like new and
9 delete and their variants, must all be overloaded and implemented in terms of the callbacks that
10 the third-party tool provides. The OMPD library must be implemented in a manner such that any of
11 its definitions of new or delete do not interfere with any that the third-party tool defines.
12 In some cases, the OMPD library must allocate memory to return results to the third-party tool.
13 The third-party tool then owns this memory and has the responsibility to release it. Thus, the
14 OMPD library and the third-party tool must use the same memory manager.
15 The OMPD library creates OMPD handles, which are opaque to the third-party tool and may have a
16 complex internal structure. The third-party tool cannot determine if the handle pointers that the
17 API returns correspond to discrete heap allocations. Thus, the third-party tool must not simply
18 deallocate a handle by passing an address that it receives from the OMPD library to its own
19 memory manager. Instead, the OMPD API includes functions that the third-party tool must use
20 when it no longer needs a handle.
21 A third-party tool creates contexts and passes them to the OMPD library. The OMPD library does
22 not release contexts; instead the third-party tool releases them after it releases any handles that may
23 reference the contexts.
24 5.4.1.1 ompd_callback_memory_alloc_fn_t
25 Summary
26 The ompd_callback_memory_alloc_fn_t type is the type signature of the callback routine
27 that the third-party tool provides to the OMPD library to allocate memory.
28 Format
C
29 typedef ompd_rc_t (*ompd_callback_memory_alloc_fn_t) (
30 ompd_size_t nbytes,
31 void **ptr
32 );
C
33 Description
34 The ompd_callback_memory_alloc_fn_t type is the type signature of the memory
35 allocation callback routine that the third-party tool provides. The OMPD library may call the
36 ompd_callback_memory_alloc_fn_t callback function to allocate memory.

2 The nbytes argument is the size in bytes of the block of memory to allocate.
3 The address of the newly allocated block of memory is returned in the location to which the ptr
4 argument points. The newly allocated block is suitably aligned for any type of variable and is not
5 guaranteed to be set to zero.

7 Routines that use the ompd_callback_memory_alloc_fn_t type may return the general
8 return codes listed at the beginning of Section 5.4.
9 Cross References
10 • ompd_size_t type, see Section 5.3.1.
11 • ompd_rc_t type, see Section 5.3.12.
12 5.4.1.2 ompd_callback_memory_free_fn_t
13 Summary
14 The ompd_callback_memory_free_fn_t type is the type signature of the callback routine
15 that the third-party tool provides to the OMPD library to deallocate memory.
16 Format
C
17 typedef ompd_rc_t (*ompd_callback_memory_free_fn_t) (
18 void *ptr
19 );
C
20 Description
21 The ompd_callback_memory_free_fn_t type is the type signature of the memory
22 deallocation callback routine that the third-party tool provides. The OMPD library may call the
23 ompd_callback_memory_free_fn_t callback function to deallocate memory that was
24 obtained from a prior call to the ompd_callback_memory_alloc_fn_t callback function.
26 The ptr argument is the address of the block to be deallocated.

28 Routines that use the ompd_callback_memory_free_fn_t type may return the general

1 Cross References
3 • ompd_callback_memory_alloc_fn_t type, see Section 5.4.1.1.
4 • ompd_callbacks_t type, see Section 5.4.6.
5 5.4.2 Context Management and Navigation

6 Summary
7 The third-party tool provides the OMPD library with callbacks to manage and to navigate context
8 relationships.
9 5.4.2.1 ompd_callback_get_thread_context_for_thread_id
10 _fn_t
11 Summary
12 The ompd_callback_get_thread_context_for_thread_id_fn_t is the type
13 signature of the callback routine that the third-party tool provides to the OMPD library to map a
14 native thread identifier to a third-party tool thread context.
15 Format
C
16 typedef ompd_rc_t
17 (*ompd_callback_get_thread_context_for_thread_id_fn_t) (
18 ompd_address_space_context_t *address_space_context,
19 ompd_thread_id_t kind,
20 ompd_size_t sizeof_thread_id,
21 const void *thread_id,
22 ompd_thread_context_t **thread_context
23 );
C
24 Description
25 The ompd_callback_get_thread_context_for_thread_id_fn_t is the type
26 signature of the context mapping callback routine that the third-party tool provides. This callback
27 maps a native thread identifier to a third-party tool thread context. The native thread identifier is
28 within the address space that address_space_context identifies. The OMPD library can use the
29 thread context, for example, to access thread local storage.
31 The address_space_context argument is an opaque handle that the third-party tool provides to
32 reference an address space. The kind, sizeof_thread_id, and thread_id arguments represent a native
33 thread identifier. On return, the thread_context argument provides an opaque handle that maps a
34 native thread identifier to a third-party tool thread context.

2 In addition to the general return codes listed at the beginning of Section 5.4, routines that use the
3 ompd_callback_get_thread_context_for_thread_id_fn_t type may also return
4 the following return codes:
5 • ompd_rc_bad_input if a different value in sizeof_thread_id is expected for the native thread
6 identifier kind given by kind; or
7 • ompd_rc_unsupported if the native thread identifier kind is not supported.
8 Restrictions
9 Restrictions on routines that use
10 ompd_callback_get_thread_context_for_thread_id_fn_t are as follows:
11 • The provided thread_context must be valid until the OMPD library returns from the OMPD
12 third-party tool interface routine.
13 Cross References
15 • ompd_thread_id_t type, see Section 5.3.7.
16 • ompd_address_space_context_t type, see Section 5.3.11.
17 • ompd_thread_context_t type, see Section 5.3.11.
19 5.4.2.2 ompd_callback_sizeof_fn_t
20 Summary
21 The ompd_callback_sizeof_fn_t type is the type signature of the callback routine that the
22 third-party tool provides to the OMPD library to determine the sizes of the primitive types in an
23 address space.
24 Format
C
25 typedef ompd_rc_t (*ompd_callback_sizeof_fn_t) (
27 ompd_device_type_sizes_t *sizes
28 );
C
29 Description
30 The ompd_callback_sizeof_fn_t is the type signature of the type-size query callback
31 routine that the third-party tool provides. This callback provides the sizes of the basic primitive
32 types for a given address space.

2 The callback returns the sizes of the basic primitive types used by the address space context that the
3 address_space_context argument specifies in the location to which the sizes argument points.

5 Routines that use the ompd_callback_sizeof_fn_t type may return the general return
6 codes listed at the beginning of Section 5.4.
7 Cross References
10 • ompd_device_type_sizes_t type, see Section 5.3.13.
12 5.4.3 Accessing Memory in the OpenMP Program or

13 Runtime
14 The OMPD library cannot directly read from or write to memory of the OpenMP program. Instead
15 the OMPD library must use callbacks that the third-party tool provides so that the third-party tool
16 performs the operation.
17 5.4.3.1 ompd_callback_symbol_addr_fn_t
18 Summary
19 The ompd_callback_symbol_addr_fn_t type is the type signature of the callback that the
20 third-party tool provides to look up the addresses of symbols in an OpenMP program.
21 Format
C
22 typedef ompd_rc_t (*ompd_callback_symbol_addr_fn_t) (
24 ompd_thread_context_t *thread_context,
25 const char *symbol_name,
26 ompd_address_t *symbol_addr,
27 const char *file_name
28 );
C
29 Description
30 The ompd_callback_symbol_addr_fn_t is the type signature of the symbol-address query
31 callback routine that the third-party tool provides. This callback looks up addresses of symbols
32 within a specified address space.

2 This callback looks up the symbol provided in the symbol_name argument.
3 The address_space_context argument is the third-party tool’s representation of the address space of
4 the process, core file, or device.
5 The thread_context argument is NULL for global memory accesses. If thread_context is not
6 NULL, thread_context gives the thread-specific context for the symbol lookup for the purpose of
7 calculating thread local storage addresses. In this case, the thread to which thread_context refers
8 must be associated with either the process or the device that corresponds to the
9 address_space_context argument.
10 The third-party tool uses the symbol_name argument that the OMPD library supplies verbatim. In
11 particular, no name mangling, demangling or other transformations are performed prior to the
12 lookup. The symbol_name parameter must correspond to a statically allocated symbol within the
13 specified address space. The symbol can correspond to any type of object, such as a variable,
14 thread local storage variable, function, or untyped label. The symbol can have a local, global, or
15 weak binding.
16 The file_name argument is an optional input parameter that indicates the name of the shared library
17 in which the symbol is defined, and it is intended to help the third-party tool disambiguate symbols
18 that are defined multiple times across the executable or shared library files. The shared library name
19 may not be an exact match for the name seen by the third-party tool. If file_name is NULL then the
20 third-party tool first tries to find the symbol in the executable file, and, if the symbol is not found,
21 the third-party tool tries to find the symbol in the shared libraries in the order in which the shared
22 libraries are loaded into the address space. If file_name is non-null then the third-party tool first
23 tries to find the symbol in the libraries that match the name in the file_name argument, and, if the
24 symbol is not found, the third-party tool then uses the same procedure as when file_name is NULL.
25 The callback does not support finding either symbols that are dynamically allocated on the call
26 stack or statically allocated symbols that are defined within the scope of a function or subroutine.
27 The callback returns the address of the symbol in the location to which symbol_addr points.

30 ompd_callback_symbol_addr_fn_t type may also return the following return codes:
31 • ompd_rc_error if the requested symbol is not found; or
32 • ompd_rc_bad_input if no symbol name is provided.
33 Restrictions
34 Restrictions on routines that use the ompd_callback_symbol_addr_fn_t type are as
35 follows:
36 • The address_space_context argument must be non-null.
37 • The symbol that the symbol_name argument specifies must be defined.

1 Cross References
2 • ompd_address_t type, see Section 5.3.4.
7 5.4.3.2 ompd_callback_memory_read_fn_t
8 Summary
9 The ompd_callback_memory_read_fn_t type is the type signature of the callback that the
10 third-party tool provides to read data (read_memory) or a string (read_string) from an OpenMP
11 program.
12 Format
C
13 typedef ompd_rc_t (*ompd_callback_memory_read_fn_t) (
16 const ompd_address_t *addr,
18 void *buffer
19 );
C
20 Description
21 The ompd_callback_memory_read_fn_t is the type signature of the read callback routines
22 that the third-party tool provides.
23 The read_memory callback copies a block of data from addr within the address space given by
24 address_space_context to the third-party tool buffer.
25 The read_string callback copies a string to which addr points, including the terminating null byte
26 (’\0’), to the third-party tool buffer. At most nbytes bytes are copied. If a null byte is not among
27 the first nbytes bytes, the string placed in buffer is not null-terminated.
29 The address from which the data are to be read in the OpenMP program that
30 address_space_context specifies is given by addr. The nbytes argument is the number of bytes to
31 be transferred. The thread_context argument is optional for global memory access, and in that case
32 should be NULL. If it is non-null, thread_context identifies the thread-specific context for the
33 memory access for the purpose of accessing thread local storage.

1 The data are returned through buffer, which is allocated and owned by the OMPD library. The
2 contents of the buffer are unstructured, raw bytes. The OMPD library must arrange for any
3 transformations such as byte-swapping that may be necessary (see Section 5.4.4) to interpret the
4 data.

7 ompd_callback_memory_read_fn_t type may also return the following return codes:
8 • ompd_rc_incomplete if no terminating null byte is found while reading nbytes using the
9 read_string callback; or
10 • ompd_rc_error if unallocated memory is reached while reading nbytes using either the
11 read_memory or read_string callback.
12 Cross References
18 • ompd_callback_device_host_fn_t type, see Section 5.4.4.
20 5.4.3.3 ompd_callback_memory_write_fn_t
21 Summary
22 The ompd_callback_memory_write_fn_t type is the type signature of the callback that
23 the third-party tool provides to write data to an OpenMP program.
24 Format
C
25 typedef ompd_rc_t (*ompd_callback_memory_write_fn_t) (
28 const ompd_address_t *addr,
30 const void *buffer
31 );
C

1 Description
2 The ompd_callback_memory_write_fn_t is the type signature of the write callback
3 routine that the third-party tool provides. The OMPD library may call this callback to have the
4 third-party tool write a block of data to a location within an address space from a provided buffer.
6 The address to which the data are to be written in the OpenMP program that address_space_context
7 specifies is given by addr. The nbytes argument is the number of bytes to be transferred. The
8 thread_context argument is optional for global memory access, and in that case should be NULL. If
9 it is non-null then thread_context identifies the thread-specific context for the memory access for
10 the purpose of accessing thread local storage.
11 The data to be written are passed through buffer, which is allocated and owned by the OMPD
12 library. The contents of the buffer are unstructured, raw bytes. The OMPD library must arrange for
13 any transformations such as byte-swapping that may be necessary (see Section 5.4.4) to render the
14 data into a form that is compatible with the OpenMP runtime.

16 Routines that use the ompd_callback_memory_write_fn_t type may return the general
18 Cross References
26 5.4.4 Data Format Conversion:

27 ompd_callback_device_host_fn_t
28 Summary
29 The ompd_callback_device_host_fn_t type is the type signature of the callback that the
30 third-party tool provides to convert data between the formats that the third-party tool and the
31 OMPD library use and that the OpenMP program uses.

1 Format
C
2 typedef ompd_rc_t (*ompd_callback_device_host_fn_t) (
4 const void *input,
5 ompd_size_t unit_size,
6 ompd_size_t count,
7 void *output
8 );
C
9 Description
10 The architecture on which the third-party tool and the OMPD library execute may be different from
11 the architecture on which the OpenMP program that is being examined executes. Thus, the
12 conventions for representing data may differ. The callback interface includes operations to convert
13 between the conventions, such as the byte order (endianness), that the third-party tool and OMPD
14 library use and the ones that the OpenMP program use. The callback with the
15 ompd_callback_device_host_fn_t type signature converts data between the formats.
17 The address_space_context argument specifies the OpenMP address space that is associated with
18 the data. The input argument is the source buffer and the output argument is the destination buffer.
19 The unit_size argument is the size of each of the elements to be converted. The count argument is
20 the number of elements to be transformed.
21 The OMPD library allocates and owns the input and output buffers. It must ensure that the buffers
22 have the correct size and are eventually deallocated when they are no longer needed.

24 Routines that use the ompd_callback_device_host_fn_t type may return the general
26 Cross References

1 5.4.5 ompd_callback_print_string_fn_t
2 Summary
3 The ompd_callback_print_string_fn_t type is the type signature of the callback that
4 the third-party tool provides so that the OMPD library can emit output.
5 Format
C
6 typedef ompd_rc_t (*ompd_callback_print_string_fn_t) (
7 const char *string,
8 int category
9 );
C
10 Description
11 The OMPD library may call the ompd_callback_print_string_fn_t callback function to
12 emit output, such as logging or debug information. The third-party tool may set the
13 ompd_callback_print_string_fn_t callback function to NULL to prevent the OMPD
14 library from emitting output. The OMPD library may not write to file descriptors that it did not
15 open.
17 The string argument is the null-terminated string to be printed. No conversion or formatting is
18 performed on the string.
19 The category argument is the implementation-defined category of the string to be printed.

21 Routines that use the ompd_callback_print_string_fn_t type may return the general
23 Cross References
26 5.4.6 The Callback Interface

27 Summary
28 All OMPD library interactions with the OpenMP program must be through a set of callbacks that
29 the third-party tool provides. These callbacks must also be used for allocating or releasing
30 resources, such as memory, that the OMPD library needs.

1 Format
C
2 typedef struct ompd_callbacks_t {
3 ompd_callback_memory_alloc_fn_t alloc_memory;
4 ompd_callback_memory_free_fn_t free_memory;
5 ompd_callback_print_string_fn_t print_string;
6 ompd_callback_sizeof_fn_t sizeof_type;
7 ompd_callback_symbol_addr_fn_t symbol_addr_lookup;
8 ompd_callback_memory_read_fn_t read_memory;
9 ompd_callback_memory_write_fn_t write_memory;
10 ompd_callback_memory_read_fn_t read_string;
11 ompd_callback_device_host_fn_t device_to_host;
12 ompd_callback_device_host_fn_t host_to_device;
13 ompd_callback_get_thread_context_for_thread_id_fn_t
14 get_thread_context_for_thread_id;
15 } ompd_callbacks_t;
C
16 Description
17 The set of callbacks that the OMPD library must use is collected in the ompd_callbacks_t
18 structure. An instance of this type is passed to the OMPD library as a parameter to
19 ompd_initialize (see Section 5.5.1.1). Each field points to a function that the OMPD library
20 must use either to interact with the OpenMP program or for memory operations.
21 The alloc_memory and free_memory fields are pointers to functions the OMPD library uses to
22 allocate and to release dynamic memory.
23 The print_string field points to a function that prints a string.
24 The architecture on which the OMPD library and third-party tool execute may be different from the
25 architecture on which the OpenMP program that is being examined executes. The sizeof_type field
26 points to a function that allows the OMPD library to determine the sizes of the basic integer and
27 pointer types that the OpenMP program uses. Because of the potential differences in the targeted
28 architectures, the conventions for representing data in the OMPD library and the OpenMP program
29 may be different. The device_to_host field points to a function that translates data from the
30 conventions that the OpenMP program uses to those that the third-party tool and OMPD library
31 use. The reverse operation is performed by the function to which the host_to_device field points.
32 The symbol_addr_lookup field points to a callback that the OMPD library can use to find the
33 address of a global or thread local storage symbol. The read_memory, read_string and
34 write_memory fields are pointers to functions for reading from and writing to global memory or
35 thread local storage in the OpenMP program.
36 The get_thread_context_for_thread_id field is a pointer to a function that the OMPD library can
37 use to obtain a thread context that corresponds to a native thread identifier.

1 Cross References
2 • ompd_callback_memory_alloc_fn_t type, see Section 5.4.1.1.
3 • ompd_callback_memory_free_fn_t type, see Section 5.4.1.2.
4 • ompd_callback_get_thread_context_for_thread_id_fn_t type, see
5 Section 5.4.2.1.
6 • ompd_callback_sizeof_fn_t type, see Section 5.4.2.2.
7 • ompd_callback_symbol_addr_fn_t type, see Section 5.4.3.1.
8 • ompd_callback_memory_read_fn_t type, see Section 5.4.3.2.
9 • ompd_callback_memory_write_fn_t type, see Section 5.4.3.3.
11 • ompd_callback_print_string_fn_t type, see Section 5.4.5
12 5.5 OMPD Tool Interface Routines

13 This section defines the interface provided by the OMPD library to be used by the third-party tool.

15 All of the OMPD Tool Interface Routines must return function specific return codes or any of the
16 following return codes:
17 • ompd_rc_stale_handle if a provided handle is stale;
18 • ompd_rc_bad_input if NULL is provided for any input argument unless otherwise specified;
19 • ompd_rc_callback if a callback returned an unexpected error, which leads to a failure of the
20 query;
21 • ompd_rc_needs_state_tracking if the information cannot be provided while the
22 debug-var is disabled;
23 • ompd_rc_ok on success; or
24 • ompd_rc_error for any other error.
25 5.5.1 Per OMPD Library Initialization and Finalization

26 The OMPD library must be initialized exactly once after it is loaded, and finalized exactly once
27 before it is unloaded. Per OpenMP process or core file initialization and finalization are also
28 required.

1 Once loaded, the tool can determine the version of the OMPD API that the library supports by
2 calling ompd_get_api_version (see Section 5.5.1.2). If the tool supports the version that
3 ompd_get_api_version returns, the tool starts the initialization by calling
4 ompd_initialize (see Section 5.5.1.1) using the version of the OMPD API that the library
5 supports. If the tool does not support the version that ompd_get_api_version returns, it may
6 attempt to call ompd_initialize with a different version.
7 5.5.1.1 ompd_initialize
8 Summary
9 The ompd_initialize function initializes the OMPD library.
10 Format
C
11 ompd_rc_t ompd_initialize(
12 ompd_word_t api_version,
13 const ompd_callbacks_t *callbacks
14 );
C
15 Description
16 A tool that uses OMPD calls ompd_initialize to initialize each OMPD library that it loads.
17 More than one library may be present in a third-party tool, such as a debugger, because the tool
18 may control multiple devices, which may use different runtime systems that require different
19 OMPD libraries. This initialization must be performed exactly once before the tool can begin to
20 operate on an OpenMP process or core file.
22 The api_version argument is the OMPD API version that the tool requests to use. The tool may call
23 ompd_get_api_version to obtain the latest OMPD API version that the OMPD library
24 supports.
25 The tool provides the OMPD library with a set of callback functions in the callbacks input
26 argument which enables the OMPD library to allocate and to deallocate memory in the tool’s
27 address space, to lookup the sizes of basic primitive types in the device, to lookup symbols in the
28 device, and to read and to write memory in the device.

30 This routine must return any of the general return codes listed at the beginning of Section 5.5 or any
31 of the following return codes:
32 • ompd_rc_bad_input if invalid callbacks are provided; or
33 • ompd_rc_unsupported if the requested API version cannot be provided.

1 Cross References
4 • ompd_get_api_version routine, see Section 5.5.1.2.
5 5.5.1.2 ompd_get_api_version
6 Summary
7 The ompd_get_api_version function returns the OMPD API version.
8 Format
C
9 ompd_rc_t ompd_get_api_version(ompd_word_t *version);
C
10 Description
11 The tool may call the ompd_get_api_version function to obtain the latest OMPD API
12 version number of the OMPD library. The OMPD API version number is equal to the value of the
13 _OPENMP macro defined in the associated OpenMP implementation, if the C preprocessor is
14 supported. If the associated OpenMP implementation compiles Fortran codes without the use of a
15 C preprocessor, the OMPD API version number is equal to the value of the Fortran integer
16 parameter openmp_version.
18 The latest version number is returned into the location to which the version argument points.

20 This routine must return any of the general return codes listed at the beginning of Section 5.5.
21 Cross References
23 5.5.1.3 ompd_get_version_string
24 Summary
25 The ompd_get_version_string function returns a descriptive string for the OMPD library
26 version.
27 Format
C
28 ompd_rc_t ompd_get_version_string(const char **string);
C

1 Description
2 The tool may call this function to obtain a pointer to a descriptive version string of the OMPD
3 library vendor, implementation, internal version, date, or any other information that may be useful
4 to a tool user or vendor. An implementation should provide a different string for every change to its
5 source code or build that could be visible to the interface user.
7 A pointer to a descriptive version string is placed into the location to which the string output
8 argument points. The OMPD library owns the string that the OMPD library returns; the tool must
9 not modify or release this string. The string remains valid for as long as the library is loaded. The
10 ompd_get_version_string function may be called before ompd_initialize (see
11 Section 5.5.1.1). Accordingly, the OMPD library must not use heap or stack memory for the string.
12 The signatures of ompd_get_api_version (see Section 5.5.1.2) and
13 ompd_get_version_string are guaranteed not to change in future versions of the API. In
14 contrast, the type definitions and prototypes in the rest of the API do not carry the same guarantee.
15 Therefore a tool that uses OMPD should check the version of the API of the loaded OMPD library
16 before it calls any other function of the API.

19 Cross References
21 5.5.1.4 ompd_finalize
22 Summary
23 When the tool is finished with the OMPD library it should call ompd_finalize before it
24 unloads the library.
25 Format
C
26 ompd_rc_t ompd_finalize(void);
C
27 Description
28 The call to ompd_finalize must be the last OMPD call that the tool makes before it unloads the
29 library. This call allows the OMPD library to free any resources that it may be holding.
30 The OMPD library may implement a finalizer section, which executes as the library is unloaded
31 and therefore after the call to ompd_finalize. During finalization, the OMPD library may use
32 the callbacks that the tool provided earlier during the call to ompd_initialize.

2 This routine must return any of the general return codes listed at the beginning of Section 5.5 or the
3 following return code:
4 • ompd_rc_unsupported if the OMPD library is not initialized.
5 Cross References
7 5.5.2 Per OpenMP Process Initialization and Finalization

8 5.5.2.1 ompd_process_initialize
9 Summary
10 A tool calls ompd_process_initialize to obtain an address space handle when it initializes
11 a session on a live process or core file.
12 Format
C
13 ompd_rc_t ompd_process_initialize(
14 ompd_address_space_context_t *context,
15 ompd_address_space_handle_t **handle
16 );
C
17 Description
18 A tool calls ompd_process_initialize to obtain an address space handle when it initializes
19 a session on a live process or core file. On return from ompd_process_initialize, the tool
20 owns the address space handle, which it must release with
21 ompd_rel_address_space_handle. The initialization function must be called before any
22 OMPD operations are performed on the OpenMP process or core file. This call allows the OMPD
23 library to confirm that it can handle the OpenMP process or core file that context identifies.
25 The context argument is an opaque handle that the tool provides to address an address space. On
26 return, the handle argument provides an opaque handle to the tool for this address space, which the
27 tool must release when it is no longer needed.

31 • ompd_rc_incompatible if the OMPD library is incompatible with the runtime library
32 loaded in the process.

1 Cross References
2 • ompd_address_space_handle_t type, see Section 5.3.8.
5 • ompd_rel_address_space_handle routine, see Section 5.5.2.3.
6 5.5.2.2 ompd_device_initialize
7 Summary
8 A tool calls ompd_device_initialize to obtain an address space handle for a device that has
9 at least one active target region.
10 Format
C
11 ompd_rc_t ompd_device_initialize(
12 ompd_address_space_handle_t *process_handle,
13 ompd_address_space_context_t *device_context,
14 ompd_device_t kind,
15 ompd_size_t sizeof_id,
16 void *id,
17 ompd_address_space_handle_t **device_handle
18 );
C
19 Description
20 A tool calls ompd_device_initialize to obtain an address space handle for a device that has
21 at least one active target region. On return from ompd_device_initialize, the tool owns the
22 address space handle.
24 The process_handle argument is an opaque handle that the tool provides to reference the address
25 space of the OpenMP process or core file. The device_context argument is an opaque handle that
26 the tool provides to reference a device address space. The kind, sizeof_id, and id arguments
27 represent a device identifier. On return the device_handle argument provides an opaque handle to
28 the tool for this address space.

32 • ompd_rc_unsupported if the OMPD library has no support for the specific device.

1 Cross References
3 • ompd_device_t type, see Section 5.3.6.
7 5.5.2.3 ompd_rel_address_space_handle
8 Summary
9 A tool calls ompd_rel_address_space_handle to release an address space handle.
10 Format
C
11 ompd_rc_t ompd_rel_address_space_handle(
12 ompd_address_space_handle_t *handle
13 );
C
14 Description
15 When the tool is finished with the OpenMP process address space handle it should call
16 ompd_rel_address_space_handle to release the handle, which allows the OMPD library
17 to release any resources that it has related to the address space.
19 The handle argument is an opaque handle for the address space to be released.
20 Restrictions
21 Restrictions to the ompd_rel_address_space_handle routine are as follows:
22 • An address space context must not be used after the corresponding address space handle is
23 released.

26 Cross References

1 5.5.3 Thread and Signal Safety
2 The OMPD library does not need to be reentrant. The tool must ensure that only one thread enters
3 the OMPD library at a time. The OMPD library must not install signal handlers or otherwise
4 interfere with the tool’s signal configuration.
5 5.5.4 Address Space Information

6 5.5.4.1 ompd_get_omp_version
7 Summary
8 The tool may call the ompd_get_omp_version function to obtain the version of the OpenMP
9 API that is associated with an address space.
10 Format
C
11 ompd_rc_t ompd_get_omp_version(
12 ompd_address_space_handle_t *address_space,
13 ompd_word_t *omp_version
14 );
C
15 Description
16 The tool may call the ompd_get_omp_version function to obtain the version of the OpenMP
17 API that is associated with the address space.
19 The address_space argument is an opaque handle that the tool provides to reference the address
20 space of the OpenMP process or device.
21 Upon return, the omp_version argument contains the version of the OpenMP runtime in the
22 _OPENMP version macro format.

25 Cross References

1 5.5.4.2 ompd_get_omp_version_string
2 Summary
3 The ompd_get_omp_version_string function returns a descriptive string for the OpenMP
4 API version that is associated with an address space.
5 Format
C
6 ompd_rc_t ompd_get_omp_version_string(
7 ompd_address_space_handle_t *address_space,
8 const char **string
9 );
C
10 Description
11 After initialization, the tool may call the ompd_get_omp_version_string function to obtain
12 the version of the OpenMP API that is associated with an address space.
14 The address_space argument is an opaque handle that the tool provides to reference the address
15 space of the OpenMP process or device. A pointer to a descriptive version string is placed into the
16 location to which the string output argument points. After returning from the call, the tool owns the
17 string. The OMPD library must use the memory allocation callback that the tool provides to
18 allocate the string storage. The tool is responsible for releasing the memory.

21 Cross References

1 5.5.5 Thread Handles
2 5.5.5.1 ompd_get_thread_in_parallel
3 Summary
4 The ompd_get_thread_in_parallel function enables a tool to obtain handles for OpenMP
5 threads that are associated with a parallel region.
6 Format
C
7 ompd_rc_t ompd_get_thread_in_parallel(
8 ompd_parallel_handle_t *parallel_handle,
9 int thread_num,
10 ompd_thread_handle_t **thread_handle
11 );
C
12 Description
13 A successful invocation of ompd_get_thread_in_parallel returns a pointer to a thread
14 handle in the location to which thread_handle points. This call yields meaningful results only
15 if all OpenMP threads in the parallel region are stopped.
17 The parallel_handle argument is an opaque handle for a parallel region and selects the parallel
18 region on which to operate. The thread_num argument selects the thread, the handle of which is to
19 be returned. On return, the thread_handle argument is an opaque handle for the selected thread.

23 • ompd_rc_bad_input if the thread_num argument is greater than or equal to the
24 team-size-var ICV or negative.
25 Restrictions
26 Restrictions on the ompd_get_thread_in_parallel function are as follows:
27 • The value of thread_num must be a non-negative integer smaller than the team size that was
28 provided as the team-size-var ICV from ompd_get_icv_from_scope.
29 Cross References
30 • ompd_parallel_handle_t type, see Section 5.3.8.
31 • ompd_thread_handle_t type, see Section 5.3.8.
33 • ompd_get_icv_from_scope routine, see Section 5.5.9.2.

1 5.5.5.2 ompd_get_thread_handle
2 Summary
3 The ompd_get_thread_handle function maps a native thread to an OMPD thread handle.
4 Format
C
5 ompd_rc_t ompd_get_thread_handle(
6 ompd_address_space_handle_t *handle,
9 const void *thread_id,
10 ompd_thread_handle_t **thread_handle
11 );
C
12 Description
13 The ompd_get_thread_handle function determines if the native thread identifier to which
14 thread_id points represents an OpenMP thread. If so, the function returns ompd_rc_ok and the
15 location to which thread_handle points is set to the thread handle for the OpenMP thread.
17 The handle argument is an opaque handle that the tool provides to reference an address space. The
18 kind, sizeof_thread_id, and thread_id arguments represent a native thread identifier. On return, the
19 thread_handle argument provides an opaque handle to the thread within the provided address space.
20 The native thread identifier to which thread_id points is guaranteed to be valid for the duration of
21 the call. If the OMPD library must retain the native thread identifier, it must copy it.
25 • ompd_rc_bad_input if a different value in sizeof_thread_id is expected for a thread kind of
26 kind.
27 • ompd_rc_unsupported if the kind of thread is not supported.
28 • ompd_rc_unavailable if the thread is not an OpenMP thread.
29 Cross References

1 5.5.5.3 ompd_rel_thread_handle
2 Summary
3 The ompd_rel_thread_handle function releases a thread handle.
4 Format
C
5 ompd_rc_t ompd_rel_thread_handle(
6 ompd_thread_handle_t *thread_handle
7 );
C
8 Description
9 Thread handles are opaque to tools, which therefore cannot release them directly. Instead, when the
10 tool is finished with a thread handle it must pass it to ompd_rel_thread_handle for disposal.
12 The thread_handle argument is an opaque handle for a thread to be released.

15 Cross References
18 5.5.5.4 ompd_thread_handle_compare
19 Summary
20 The ompd_thread_handle_compare function allows tools to compare two thread handles.
21 Format
C
22 ompd_rc_t ompd_thread_handle_compare(
23 ompd_thread_handle_t *thread_handle_1,
24 ompd_thread_handle_t *thread_handle_2,
25 int *cmp_value
26 );
C
27 Description
28 The internal structure of thread handles is opaque to a tool. While the tool can easily compare
29 pointers to thread handles, it cannot determine whether handles of two different addresses refer to
30 the same underlying thread. The ompd_thread_handle_compare function compares thread
31 handles.

1 On success, ompd_thread_handle_compare returns in the location to which cmp_value
2 points a signed integer value that indicates how the underlying threads compare: a value less than,
3 equal to, or greater than 0 indicates that the thread corresponding to thread_handle_1 is,
4 respectively, less than, equal to, or greater than that corresponding to thread_handle_2.
6 The thread_handle_1 and thread_handle_2 arguments are opaque handles for threads. On return
7 the cmp_value argument is set to a signed integer value.

10 Cross References
13 5.5.5.5 ompd_get_thread_id
14 Summary
15 The ompd_get_thread_id maps an OMPD thread handle to a native thread.
16 Format
C
17 ompd_rc_t ompd_get_thread_id(
18 ompd_thread_handle_t *thread_handle,
21 void *thread_id
22 );
C
23 Description
24 The ompd_get_thread_id function maps an OMPD thread handle to a native thread identifier.
26 The thread_handle argument is an opaque thread handle. The kind argument represents the native
27 thread identifier. The sizeof_thread_id argument represents the size of the native thread identifier.
28 On return, the thread_id argument is a buffer that represents a native thread identifier.

4 • ompd_rc_bad_input if a different value in sizeof_thread_id is expected for a thread kind of
5 kind; or
6 • ompd_rc_unsupported if the kind of thread is not supported.
7 Cross References
12 5.5.6 Parallel Region Handles

13 5.5.6.1 ompd_get_curr_parallel_handle
14 Summary
15 The ompd_get_curr_parallel_handle function obtains a pointer to the parallel handle for
16 an OpenMP thread’s current parallel region.
17 Format
C
18 ompd_rc_t ompd_get_curr_parallel_handle(
20 ompd_parallel_handle_t **parallel_handle
21 );
C
22 Description
23 The ompd_get_curr_parallel_handle function enables the tool to obtain a pointer to the
24 parallel handle for the current parallel region that is associated with an OpenMP thread. This call is
25 meaningful only if the associated thread is stopped. The parallel handle is owned by the tool and it
26 must be released by calling ompd_rel_parallel_handle.
28 The thread_handle argument is an opaque handle for a thread and selects the thread on which to
29 operate. On return, the parallel_handle argument is set to a handle for the parallel region that the
30 associated thread is currently executing, if any.

4 • ompd_rc_unavailable if the thread is not currently part of a team.
5 Cross References
9 • ompd_rel_parallel_handle routine, see Section 5.5.6.4.
10 5.5.6.2 ompd_get_enclosing_parallel_handle
11 Summary
12 The ompd_get_enclosing_parallel_handle function obtains a pointer to the parallel
13 handle for an enclosing parallel region.
14 Format
C
15 ompd_rc_t ompd_get_enclosing_parallel_handle(
17 ompd_parallel_handle_t **enclosing_parallel_handle
18 );
C
19 Description
20 The ompd_get_enclosing_parallel_handle function enables a tool to obtain a pointer
21 to the parallel handle for the parallel region that encloses the parallel region that
22 parallel_handle specifies. This call is meaningful only if at least one thread in the parallel
23 region is stopped. A pointer to the parallel handle for the enclosing region is returned in the
24 location to which enclosing_parallel_handle points. After the call, the tool owns the handle; the
25 tool must release the handle with ompd_rel_parallel_handle when it is no longer required.
27 The parallel_handle argument is an opaque handle for a parallel region that selects the parallel
28 region on which to operate. On return, the enclosing_parallel_handle argument is set to a handle
29 for the parallel region that encloses the selected parallel region.

4 • ompd_rc_unavailable if no enclosing parallel region exists.
5 Cross References
9 5.5.6.3 ompd_get_task_parallel_handle
10 Summary
11 The ompd_get_task_parallel_handle function obtains a pointer to the parallel handle for
12 the parallel region that encloses a task region.
13 Format
C
14 ompd_rc_t ompd_get_task_parallel_handle(
15 ompd_task_handle_t *task_handle,
16 ompd_parallel_handle_t **task_parallel_handle
17 );
C
18 Description
19 The ompd_get_task_parallel_handle function enables a tool to obtain a pointer to the
20 parallel handle for the parallel region that encloses the task region that task_handle specifies. This
21 call is meaningful only if at least one thread in the parallel region is stopped. A pointer to the
22 parallel regions handle is returned in the location to which task_parallel_handle points. The tool
23 owns that parallel handle, which it must release with ompd_rel_parallel_handle.
25 The task_handle argument is an opaque handle that selects the task on which to operate. On return,
26 the parallel_handle argument is set to a handle for the parallel region that encloses the selected task.
29 Cross References
30 • ompd_task_handle_t type, see Section 5.3.8.

1 5.5.6.4 ompd_rel_parallel_handle
2 Summary
3 The ompd_rel_parallel_handle function releases a parallel region handle.
4 Format
C
5 ompd_rc_t ompd_rel_parallel_handle(
6 ompd_parallel_handle_t *parallel_handle
7 );
C
8 Description
9 Parallel region handles are opaque so tools cannot release them directly. Instead, a tool must pass a
10 parallel region handle to the ompd_rel_parallel_handle function for disposal when
11 finished with it.
13 The parallel_handle argument is an opaque handle to be released.

16 Cross References
19 5.5.6.5 ompd_parallel_handle_compare
20 Summary
21 The ompd_parallel_handle_compare function compares two parallel region handles.
22 Format
C
23 ompd_rc_t ompd_parallel_handle_compare(
24 ompd_parallel_handle_t *parallel_handle_1,
25 ompd_parallel_handle_t *parallel_handle_2,
26 int *cmp_value
27 );
C

1 Description
2 The internal structure of parallel region handles is opaque to tools. While tools can easily compare
3 pointers to parallel region handles, they cannot determine whether handles at two different
4 addresses refer to the same underlying parallel region and, instead must use the
5 ompd_parallel_handle_compare function.
6 On success, ompd_parallel_handle_compare returns a signed integer value in the location
7 to which cmp_value points that indicates how the underlying parallel regions compare. A value less
8 than, equal to, or greater than 0 indicates that the region corresponding to parallel_handle_1 is,
9 respectively, less than, equal to, or greater than that corresponding to parallel_handle_2. This
10 function is provided since the means by which parallel region handles are ordered is
13 The parallel_handle_1 and parallel_handle_2 arguments are opaque handles that correspond to
14 parallel regions. On return the cmp_value argument points to a signed integer value that indicates
15 how the underlying parallel regions compare.

18 Cross References
21 5.5.7 Task Handles

22 5.5.7.1 ompd_get_curr_task_handle
23 Summary
24 The ompd_get_curr_task_handle function obtains a pointer to the task handle for the
25 current task region that is associated with an OpenMP thread.
26 Format
C
27 ompd_rc_t ompd_get_curr_task_handle(
29 ompd_task_handle_t **task_handle
30 );
C

1 Description
2 The ompd_get_curr_task_handle function obtains a pointer to the task handle for the
3 current task region that is associated with an OpenMP thread. This call is meaningful only if the
4 thread for which the handle is provided is stopped. The task handle must be released with
5 ompd_rel_task_handle.
7 The thread_handle argument is an opaque handle that selects the thread on which to operate. On
8 return, the task_handle argument points to a location that points to a handle for the task that the
9 thread is currently executing.

13 • ompd_rc_unavailable if the thread is currently not executing a task.
14 Cross References
18 • ompd_rel_task_handle routine, see Section 5.5.7.5.
19 5.5.7.2 ompd_get_generating_task_handle
20 Summary
21 The ompd_get_generating_task_handle function obtains a pointer to the task handle of
22 the generating task region.
23 Format
C
24 ompd_rc_t ompd_get_generating_task_handle(
26 ompd_task_handle_t **generating_task_handle
27 );
C
28 Description
29 The ompd_get_generating_task_handle function obtains a pointer to the task handle for
30 the task that encountered the OpenMP task construct that generated the task represented by
31 task_handle. The generating task is the OpenMP task that was active when the task specified by
32 task_handle was created. This call is meaningful only if the thread that is executing the task that
33 task_handle specifies is stopped. The generating task handle must be released with
34 ompd_rel_task_handle.

3 the generating_task_handle argument points to a location that points to a handle for the generating
4 task.

8 • ompd_rc_unavailable if no generating task region exists.
9 Cross References
13 5.5.7.3 ompd_get_scheduling_task_handle
14 Summary
15 The ompd_get_scheduling_task_handle function obtains a task handle for the task that
16 was active at a task scheduling point.
17 Format
C
18 ompd_rc_t ompd_get_scheduling_task_handle(
20 ompd_task_handle_t **scheduling_task_handle
21 );
C
22 Description
23 The ompd_get_scheduling_task_handle function obtains a task handle for the task that
24 was active when the task that task_handle represents was scheduled. This call is meaningful only if
25 the thread that is executing the task that task_handle specifies is stopped. The scheduling task
26 handle must be released with ompd_rel_task_handle.
28 The task_handle argument is an opaque handle for a task and selects the task on which to operate.
29 On return, the scheduling_task_handle argument points to a location that points to a handle for the
30 task that is still on the stack of execution on the same thread and was deferred in favor of executing
31 the selected task.

4 • ompd_rc_unavailable if no scheduling task region exists.
5 Cross References
9 5.5.7.4 ompd_get_task_in_parallel
10 Summary
11 The ompd_get_task_in_parallel function obtains handles for the implicit tasks that are
12 associated with a parallel region.
13 Format
C
14 ompd_rc_t ompd_get_task_in_parallel(
16 int thread_num,
17 ompd_task_handle_t **task_handle
18 );
C
19 Description
20 The ompd_get_task_in_parallel function obtains handles for the implicit tasks that are
21 associated with a parallel region. A successful invocation of ompd_get_task_in_parallel
22 returns a pointer to a task handle in the location to which task_handle points. This call yields
23 meaningful results only if all OpenMP threads in the parallel region are stopped.
25 The parallel_handle argument is an opaque handle that selects the parallel region on which to
26 operate. The thread_num argument selects the implicit task of the team to be returned. The
27 thread_num argument is equal to the thread-num-var ICV value of the selected implicit task. On
28 return, the task_handle argument points to a location that points to an opaque handle for the
29 selected implicit task.

4 • ompd_rc_bad_input if the thread_num argument is greater than or equal to the
5 team-size-var ICV or negative.
6 Restrictions
7 Restrictions on the ompd_get_task_in_parallel function are as follows:
8 • The value of thread_num must be a non-negative integer that is smaller than the size of the team
9 size that is the value of the team-size-var ICV that ompd_get_icv_from_scope returns.
10 Cross References
14 • ompd_get_icv_from_scope routine, see Section 5.5.9.2.
15 5.5.7.5 ompd_rel_task_handle
16 Summary
17 This ompd_rel_task_handle function releases a task handle.
18 Format
C
19 ompd_rc_t ompd_rel_task_handle(
20 ompd_task_handle_t *task_handle
21 );
C
22 Description
23 Task handles are opaque to tools; thus tools cannot release them directly. Instead, when a tool is
24 finished with a task handle it must use the ompd_rel_task_handle function to release it.
26 The task_handle argument is an opaque task handle to be released.

29 Cross References

1 5.5.7.6 ompd_task_handle_compare
2 Summary
3 The ompd_task_handle_compare function compares task handles.
4 Format
C
5 ompd_rc_t ompd_task_handle_compare(
6 ompd_task_handle_t *task_handle_1,
7 ompd_task_handle_t *task_handle_2,
8 int *cmp_value
9 );
C
10 Description
11 The internal structure of task handles is opaque; so tools cannot directly determine if handles at two
12 different addresses refer to the same underlying task. The ompd_task_handle_compare
13 function compares task handles. After a successful call to ompd_task_handle_compare, the
14 value of the location to which cmp_value points is a signed integer that indicates how the underlying
15 tasks compare: a value less than, equal to, or greater than 0 indicates that the task that corresponds
16 to task_handle_1 is, respectively, less than, equal to, or greater than the task that corresponds to
17 task_handle_2. The means by which task handles are ordered is implementation defined.
19 The task_handle_1 and task_handle_2 arguments are opaque handles that correspond to tasks. On
20 return, the cmp_value argument points to a location in which a signed integer value indicates how
21 the underlying tasks compare.
24 Cross References
27 5.5.7.7 ompd_get_task_function
28 Summary
29 This ompd_get_task_function function returns the entry point of the code that corresponds
30 to the body of a task.
31 Format
C
32 ompd_rc_t ompd_get_task_function (
34 ompd_address_t *entry_point
35 );
C

1 Description
2 The ompd_get_task_function function returns the entry point of the code that corresponds
3 to the body of code that the task executes.
6 the entry_point argument is set to an address that describes the beginning of application code that
7 executes the task region.

10 Cross References
14 5.5.7.8 ompd_get_task_frame
15 Summary
16 The ompd_get_task_frame function extracts the frame pointers of a task.
17 Format
C
18 ompd_rc_t ompd_get_task_frame (
20 ompd_frame_info_t *exit_frame,
21 ompd_frame_info_t *enter_frame
22 );
C
23 Description
24 An OpenMP implementation maintains an ompt_frame_t object for every implicit or explicit
25 task. The ompd_get_task_frame function extracts the enter_frame and exit_frame fields of
26 the ompt_frame_t object of the task that task_handle identifies.
28 The task_handle argument specifies an OpenMP task. On return, the exit_frame argument points to
29 an ompd_frame_info_t object that has the frame information with the same semantics as the
30 exit_frame field in the ompt_frame_t object that is associated with the specified task. On return,
31 the enter_frame argument points to an ompd_frame_info_t object that has the frame
32 information with the same semantics as the enter_frame field in the ompt_frame_t object that is
33 associated with the specified task.

3 Cross References
6 • ompd_frame_info_t type, see Section 5.3.5.
9 5.5.7.9 ompd_enumerate_states
10 Summary
11 The ompd_enumerate_states function enumerates thread states that an OpenMP
12 implementation supports.
13 Format
C
14 ompd_rc_t ompd_enumerate_states (
15 ompd_address_space_handle_t *address_space_handle,
16 ompd_word_t current_state,
17 ompd_word_t *next_state,
18 const char **next_state_name,
19 ompd_word_t *more_enums
20 );
C
21 Description
22 An OpenMP implementation may support only a subset of the states that the ompt_state_t
23 enumeration type defines. In addition, an OpenMP implementation may support
24 implementation-specific states. The ompd_enumerate_states call enables a tool to
25 enumerate the thread states that an OpenMP implementation supports.
26 When the current_state argument is a thread state that an OpenMP implementation supports, the
27 call assigns the value and string name of the next thread state in the enumeration to the locations to
28 which the next_state and next_state_name arguments point.
29 On return, the third-party tool owns the next_state_name string. The OMPD library allocates
30 storage for the string with the memory allocation callback that the tool provides. The tool is
31 responsible for releasing the memory.
32 On return, the location to which the more_enums argument points has the value 1 whenever one or
33 more states are left in the enumeration. On return, the location to which the more_enums argument
34 points has the value 0 when current_state is the last state in the enumeration.

2 The address_space_handle argument identifies the address space. The current_state argument must
3 be a thread state that the OpenMP implementation supports. To begin enumerating the supported
4 states, a tool should pass ompt_state_undefined as the value of current_state. Subsequent
5 calls to ompd_enumerate_states by the tool should pass the value that the call returned in
6 the next_state argument. On return, the next_state argument points to an integer with the value of
7 the next state in the enumeration. On return, the next_state_name argument points to a character
8 string that describes the next state. On return, the more_enums argument points to an integer with a
9 value of 1 when more states are left to enumerate and a value of 0 when no more states are left.

13 • ompd_rc_bad_input if an unknown value is provided in current_state.
14 Cross References
18 5.5.7.10 ompd_get_state
19 Summary
20 The ompd_get_state function obtains the state of a thread.
21 Format
C
22 ompd_rc_t ompd_get_state (
24 ompd_word_t *state,
25 ompd_wait_id_t *wait_id
26 );
C
27 Description
28 The ompd_get_state function returns the state of an OpenMP thread.
30 The thread_handle argument identifies the thread. The state argument represents the state of that
31 thread as represented by a value that ompd_enumerate_states returns. On return, if the
32 wait_id argument is non-null then it points to a handle that corresponds to the wait_id wait
33 identifier of the thread. If the thread state is not one of the specified wait states, the value to which
34 wait_id points is undefined.

3 Cross References
4 • ompd_wait_id_t type, see Section 5.3.2.
7 • ompd_enumerate_states routine, see Section 5.5.7.9.
8 5.5.8 Display Control Variables

9 5.5.8.1 ompd_get_display_control_vars
10 Summary
11 The ompd_get_display_control_vars function returns a list of name/value pairs for
12 OpenMP control variables.
13 Format
C
14 ompd_rc_t ompd_get_display_control_vars (
15 ompd_address_space_handle_t *address_space_handle,
16 const char * const **control_vars
17 );
C
18 Description
19 The ompd_get_display_control_vars function returns a NULL-terminated vector of
20 NULL-terminated strings of name/value pairs of control variables that have user controllable
21 settings and are important to the operation or performance of an OpenMP runtime system. The
22 control variables that this interface exposes include all OpenMP environment variables, settings
23 that may come from vendor or platform-specific environment variables, and other settings that
24 affect the operation or functioning of an OpenMP runtime.
25 The format of the strings is "icv-name=icv-value".
26 On return, the third-party tool owns the vector and the strings. The OMPD library must satisfy the
27 termination constraints; it may use static or dynamic memory for the vector and/or the strings and is
28 unconstrained in how it arranges them in memory. If it uses dynamic memory then the OMPD
29 library must use the allocate callback that the tool provides to ompd_initialize. The tool must
30 use the ompd_rel_display_control_vars function to release the vector and the strings.
32 The address_space_handle argument identifies the address space. On return, the control_vars
33 argument points to the vector of display control variables.

3 Cross References
6 • ompd_initialize routine, see Section 5.5.1.1.
7 • ompd_rel_display_control_vars routine, see Section 5.5.8.2.
8 5.5.8.2 ompd_rel_display_control_vars
9 Summary
10 The ompd_rel_display_control_vars releases a list of name/value pairs of OpenMP
11 control variables previously acquired with ompd_get_display_control_vars.
12 Format
C
13 ompd_rc_t ompd_rel_display_control_vars (
14 const char * const **control_vars
15 );
C
16 Description
17 The third-party tool owns the vector and strings that ompd_get_display_control_vars
18 returns. The tool must call ompd_rel_display_control_vars to release the vector and the
19 strings.
21 The control_vars argument is the vector of display control variables to be released.

24 Cross References
26 • ompd_get_display_control_vars routine, see Section 5.5.8.1.

1 5.5.9 Accessing Scope-Specific Information
2 5.5.9.1 ompd_enumerate_icvs
3 Summary
4 The ompd_enumerate_icvs function enumerates ICVs.
5 Format
C
6 ompd_rc_t ompd_enumerate_icvs (
7 ompd_address_space_handle_t *handle,
8 ompd_icv_id_t current,
9 ompd_icv_id_t *next_id,
10 const char **next_icv_name,
11 ompd_scope_t *next_scope,
12 int *more
13 );
C
14 Description
15 An OpenMP implementation must support all ICVs listed in Section 2.4.1. An OpenMP
16 implementation may support additional implementation-specific variables. An implementation may
17 store ICVs in a different scope than Table 2.3 indicates. The ompd_enumerate_icvs function
18 enables a tool to enumerate the ICVs that an OpenMP implementation supports and their related
19 scopes. The ICVs num-procs-var, thread-num-var, final-task-var, implicit-task-var and
20 team-size-var must also be available with an ompd- prefix.
21 When the current argument is set to the identifier of a supported ICV, ompd_enumerate_icvs
22 assigns the value, string name, and scope of the next ICV in the enumeration to the locations to
23 which the next_id, next_icv_name, and next_scope arguments point. On return, the third-party tool
24 owns the next_icv_name string. The OMPD library uses the memory allocation callback that the
25 tool provides to allocate the string storage; the tool is responsible for releasing the memory.
26 On return, the location to which the more argument points has the value of 1 whenever one or more
27 ICV are left in the enumeration. On return, that location has the value 0 when current is the last
28 ICV in the enumeration.
30 The address_space_handle argument identifies the address space. The current argument must be
31 an ICV that the OpenMP implementation supports. To begin enumerating the ICVs, a tool should
32 pass ompd_icv_undefined as the value of current. Subsequent calls to
33 ompd_enumerate_icvs should pass the value returned by the call in the next_id output
34 argument. On return, the next_id argument points to an integer with the value of the ID of the next
35 ICV in the enumeration. On return, the next_icv_name argument points to a character string with
36 the name of the next ICV. On return, the next_scope argument points to the scope enum value of the
37 scope of the next ICV. On return, the more_enums argument points to an integer with the value of 1
38 when more ICVs are left to enumerate and the value of 0 when no more ICVs are left.

4 • ompd_rc_bad_input if an unknown value is provided in current.
5 Cross References
7 • ompd_scope_t type, see Section 5.3.9.
8 • ompd_icv_id_t type, see Section 5.3.10.
10 5.5.9.2 ompd_get_icv_from_scope
11 Summary
12 The ompd_get_icv_from_scope function returns the value of an ICV.
13 Format
C
14 ompd_rc_t ompd_get_icv_from_scope (
15 void *handle,
16 ompd_scope_t scope,
17 ompd_icv_id_t icv_id,
18 ompd_word_t *icv_value
19 );
C
20 Description
21 The ompd_get_icv_from_scope function provides access to the ICVs that
22 ompd_enumerate_icvs identifies.
24 The handle argument provides an OpenMP scope handle. The scope argument specifies the kind of
25 scope provided in handle. The icv_id argument specifies the ID of the requested ICV. On return,
26 the icv_value argument points to a location with the value of the requested ICV.
28 The provided handle must match the scope as defined in Section 5.3.10.
29 The provided scope must match the scope for icv_id as requested by ompd_enumerate_icvs.

4 • ompd_rc_incompatible if the ICV cannot be represented as an integer;
5 • ompd_rc_incomplete if only the first item of the ICV is returned in the integer (e.g., if
6 nthreads-var is a list); or
7 • ompd_rc_bad_input if an unknown value is provided in icv_id.
8 Cross References
16 • ompd_enumerate_icvs routine, see Section 5.5.9.1.
17 5.5.9.3 ompd_get_icv_string_from_scope
18 Summary
19 The ompd_get_icv_string_from_scope function returns the value of an ICV.
20 Format
C
21 ompd_rc_t ompd_get_icv_string_from_scope (
22 void *handle,
24 ompd_icv_id_t icv_id,
25 const char **icv_string
26 );
C
27 Description
28 The ompd_get_icv_string_from_scope function provides access to the ICVs that
29 ompd_enumerate_icvs identifies.

3 scope provided in handle. The icv_id argument specifies the ID of the requested ICV. On return,
4 the icv_string argument points to a string representation of the requested ICV.
5 On return, the third-party tool owns the icv_string string. The OMPD library allocates the string
6 storage with the memory allocation callback that the tool provides. The tool is responsible for
7 releasing the memory.
9 The provided handle must match the scope as defined in Section 5.3.10.
10 The provided scope must match the scope for icv_id as requested by ompd_enumerate_icvs.
14 • ompd_rc_bad_input if an unknown value is provided in icv_id.
15 Cross References
23 • ompd_enumerate_icvs routine, see Section 5.5.9.1.
24 5.5.9.4 ompd_get_tool_data
25 Summary
26 The ompd_get_tool_data function provides access to the OMPT data variable stored for each
27 OpenMP scope.
28 Format
C
29 ompd_rc_t ompd_get_tool_data(
30 void* handle,
32 ompd_word_t *value,
33 ompd_address_t *ptr
34 );
C

1 Description
2 The ompd_get_tool_data function provides access to the OMPT tool data stored for each
3 scope. If the runtime library does not support OMPT then the function returns
4 ompd_rc_unsupported.
7 scope provided in handle. On return, the value argument points to the value field of the
8 ompt_data_t union stored for the selected scope. On return, the ptr argument points to the ptr
9 field of the ompt_data_t union stored for the selected scope.

13 • ompd_rc_unsupported if the runtime library does not support OMPT.
14 Cross References
22 5.6 Runtime Entry Points for OMPD

23 The OpenMP implementation must define several entry point symbols through which execution
24 must pass when particular events occur and data collection for OMPD is enabled. A tool can enable
25 notification of an event by setting a breakpoint at the address of the entry point symbol.
26 Entry point symbols have external C linkage and do not require demangling or other
27 transformations to look up their names to obtain the address in the OpenMP program. While each
28 entry point symbol conceptually has a function type signature, it may not be a function. It may be a
29 labeled location

1 5.6.1 Beginning Parallel Regions
2 Summary
3 Before starting the execution of an OpenMP parallel region, the implementation executes
4 ompd_bp_parallel_begin.
5 Format
C
6 void ompd_bp_parallel_begin(void);
C
7 Description
8 The OpenMP implementation must execute ompd_bp_parallel_begin at every
9 parallel-begin event. At the point that the implementation reaches
10 ompd_bp_parallel_begin, the binding for ompd_get_curr_parallel_handle is the
11 parallel region that is beginning and the binding for ompd_get_curr_task_handle is the
12 task that encountered the parallel construct.
13 Cross References
15 • ompd_get_curr_parallel_handle routine, see Section 5.5.6.1.
16 • ompd_get_curr_task_handle routine, see Section 5.5.7.1.
17 5.6.2 Ending Parallel Regions

18 Summary
19 After finishing the execution of an OpenMP parallel region, the implementation executes
20 ompd_bp_parallel_end.
21 Format
C
22 void ompd_bp_parallel_end(void);
C
23 Description
24 The OpenMP implementation must execute ompd_bp_parallel_end at every parallel-end
25 event. At the point that the implementation reaches ompd_bp_parallel_end, the binding for
26 ompd_get_curr_parallel_handle is the parallel region that is ending and the binding
27 for ompd_get_curr_task_handle is the task that encountered the parallel construct.
28 After execution of ompd_bp_parallel_end, any parallel_handle that was acquired for the
29 parallel region is invalid and should be released.

1 Cross References
3 • ompd_get_curr_parallel_handle routine, see Section 5.5.6.1.
6 5.6.3 Beginning Task Regions

7 Summary
8 Before starting the execution of an OpenMP task region, the implementation executes
9 ompd_bp_task_begin.
10 Format
C
11 void ompd_bp_task_begin(void);
C
12 Description
13 The OpenMP implementation must execute ompd_bp_task_begin immediately before starting
14 execution of a structured-block that is associated with a non-merged task. At the point that the
15 implementation reaches ompd_bp_task_begin, the binding for
16 ompd_get_curr_task_handle is the task that is scheduled to execute.
17 Cross References
19 5.6.4 Ending Task Regions

20 Summary
21 After finishing the execution of an OpenMP task region, the implementation executes
22 ompd_bp_task_end.
23 Format
C
24 void ompd_bp_task_end(void);
C

1 Description
2 The OpenMP implementation must execute ompd_bp_task_end immediately after completion
3 of a structured-block that is associated with a non-merged task. At the point that the implementation
4 reaches ompd_bp_task_end, the binding for ompd_get_curr_task_handle is the task
5 that finished execution. After execution of ompd_bp_task_end, any task_handle that was
6 acquired for the task region is invalid and should be released.
7 Cross References
10 5.6.5 Beginning OpenMP Threads

11 Summary
12 When starting an OpenMP thread, the implementation executes ompd_bp_thread_begin.
13 Format
C
14 void ompd_bp_thread_begin(void);
C
15 Description
16 The OpenMP implementation must execute ompd_bp_thread_begin at every
17 native-thread-begin and initial-thread-begin event. This execution occurs before the thread starts
18 the execution of any OpenMP region.
19 Cross References
22 5.6.6 Ending OpenMP Threads

23 Summary
24 When terminating an OpenMP thread, the implementation executes ompd_bp_thread_end.
25 Format
C
26 void ompd_bp_thread_end(void);
C

1 Description
2 The OpenMP implementation must execute ompd_bp_thread_end at every native-thread-end
3 and initial-thread-end event. This execution occurs after the thread completes the execution of all
4 OpenMP regions. After executing ompd_bp_thread_end, any thread_handle that was acquired
5 for this thread is invalid and should be released.
6 Cross References
9 • ompd_rel_thread_handle routine, see Section 5.5.5.3.
10 5.6.7 Initializing OpenMP Devices

11 Summary
12 The OpenMP implementation must execute ompd_bp_device_begin at every device-initialize
13 event.
14 Format
C
15 void ompd_bp_device_begin(void);
C
16 Description
17 When initializing a device for execution of a target region, the implementation must execute
18 ompd_bp_device_begin. This execution occurs before the work associated with any OpenMP
19 region executes on the device.
20 Cross References
21 • Device Initialization, see Section 2.14.1.
22 5.6.8 Finalizing OpenMP Devices

23 Summary
24 When terminating an OpenMP thread, the implementation executes ompd_bp_device_end.
25 Format
C
26 void ompd_bp_device_end(void);
C

1 Description
2 The OpenMP implementation must execute ompd_bp_device_end at every device-finalize
3 event. This execution occurs after the thread executes all OpenMP regions. After execution of
4 ompd_bp_device_end, any address_space_handle that was acquired for this device is invalid
5 and should be released.
6 Cross References
7 • Device Initialization, see Section 2.14.1.
8 • ompd_rel_address_space_handle routine, see Section 5.5.2.3.

1 6 Environment Variables
2 This chapter describes the OpenMP environment variables that specify the settings of the ICVs that
3 affect the execution of OpenMP programs (see Section 2.4). The names of the environment
4 variables must be upper case. Unless otherwise specified, the values assigned to the environment
5 variables are case insensitive and may have leading and trailing white space. Modifications to the
6 environment variables after the program has started, even if modified by the program itself, are
7 ignored by the OpenMP implementation. However, the settings of some of the ICVs can be
8 modified during the execution of the OpenMP program by the use of the appropriate directive
9 clauses or OpenMP API routines.
10 The following examples demonstrate how the OpenMP environment variables can be set in
11 different environments:
12 • csh-like shells:
13 setenv OMP_SCHEDULE "dynamic"
14 • bash-like shells:
15 export OMP_SCHEDULE="dynamic"
16 • Windows Command Line:

17 set OMP_SCHEDULE=dynamic
18 As defined following Table 2.1 in Section 2.4.2, device-specific environment variables extend many
19 of the environment variables defined in this chapter. If the corresponding environment variable for
20 a specific device number, including the host device, is set, then the setting for that environment
21 variable is used to set the value of the associated ICV of the device with the corresponding device
22 number. If the corresponding environment variable that includes the _DEV suffix but no device
23 number is set, then the setting of that environment variable is used to set the value of the associated
24 ICV of any non-host device for which the device-number-specific corresponding environment
25 variable is not set. In all cases the setting of an environment variable for which a device number is
26 specified takes precedence.
27 Restrictions
28 Restrictions to device-specific environment variables are as follows:
29 • Device-specific environment variables must not correspond to environment variables that
30 initialize ICVs with global scope.
639
1 6.1 OMP_SCHEDULE
2 The OMP_SCHEDULE environment variable controls the schedule kind and chunk size of all loop
3 directives that have the schedule kind runtime, by setting the value of the run-sched-var ICV.
4 The value of this environment variable takes the form:
5 [modifier:]kind[, chunk]
6 where
7 • modifier is one of monotonic or nonmonotonic;
8 • kind is one of static, dynamic, guided, or auto;
9 • chunk is an optional positive integer that specifies the chunk size.
10 If the modifier is not present, the modifier is set to monotonic if kind is static; for any other
11 kind it is set to nonmonotonic.
12 If chunk is present, white space may be on either side of the “,”. See Section 2.11.4 for a detailed
13 description of the schedule kinds.
14 The behavior of the program is implementation defined if the value of OMP_SCHEDULE does not
15 conform to the above format.
16 Examples:
17 setenv OMP_SCHEDULE "guided,4"
18 setenv OMP_SCHEDULE "dynamic"
19 setenv OMP_SCHEDULE "nonmonotonic:dynamic,4"
20 Cross References
22 • Worksharing-Loop construct, see Section 2.11.4.
23 • Parallel worksharing-loop construct, see Section 2.16.1.
26 6.2 OMP_NUM_THREADS
27 The OMP_NUM_THREADS environment variable sets the number of threads to use for parallel
28 regions by setting the initial value of the nthreads-var ICV. See Section 2.4 for a comprehensive set
29 of rules about the interaction between the OMP_NUM_THREADS environment variable, the
30 num_threads clause, the omp_set_num_threads library routine and dynamic adjustment of

1 threads, and Section 2.6.1 for a complete algorithm that describes how the number of threads for a
2 parallel region is determined.
3 The value of this environment variable must be a list of positive integer values. The values of the
4 list set the number of threads to use for parallel regions at the corresponding nested levels.
5 The behavior of the program is implementation defined if any value of the list specified in the
6 OMP_NUM_THREADS environment variable leads to a number of threads that is greater than an
7 implementation can support, or if any value is not a positive integer.
8 The OMP_NUM_THREADS environment variable sets the max-active-levels-var ICV to the number
9 of active levels of parallelism that the implementation supports if the OMP_NUM_THREADS
10 environment variable is set to a comma-separated list of more than one value. The value of the
11 max-active-level-var ICV may be overridden by setting OMP_MAX_ACTIVE_LEVELS or
12 OMP_NESTED. See Section 6.8 and Section 6.9 for details.
13 Example:
14 setenv OMP_NUM_THREADS 4,3,2
15 Cross References
22 6.3 OMP_DYNAMIC
23 The OMP_DYNAMIC environment variable controls dynamic adjustment of the number of threads
24 to use for executing parallel regions by setting the initial value of the dyn-var ICV.
25 The value of this environment variable must be one of the following:
26 true | false
27 If the environment variable is set to true, the OpenMP implementation may adjust the number of
28 threads to use for executing parallel regions in order to optimize the use of system resources. If
29 the environment variable is set to false, the dynamic adjustment of the number of threads is
30 disabled. The behavior of the program is implementation defined if the value of OMP_DYNAMIC is
31 neither true nor false.
CHAPTER 6. ENVIRONMENT VARIABLES 641

1 Example:
2 setenv OMP_DYNAMIC true
3 Cross References
7 6.4 OMP_PROC_BIND
8 The OMP_PROC_BIND environment variable sets the initial value of the bind-var ICV. The value
9 of this environment variable is either true, false, or a comma separated list of primary,
10 master (master has been deprecated), close, or spread. The values of the list set the thread
11 affinity policy to be used for parallel regions at the corresponding nested level.
12 If the environment variable is set to false, the execution environment may move OpenMP threads
13 between OpenMP places, thread affinity is disabled, and proc_bind clauses on parallel
14 constructs are ignored.
15 Otherwise, the execution environment should not move OpenMP threads between OpenMP places,
16 thread affinity is enabled, and the initial thread is bound to the first place in the place-partition-var
17 ICV prior to the first active parallel region. An initial thread that is created by a teams construct is
18 bound to the first place in its place-partition-var ICV before it begins execution of the associated
19 structured block.
20 If the environment variable is set to true, the thread affinity policy is implementation defined but
21 must conform to the previous paragraph. The behavior of the program is implementation defined if
22 the value in the OMP_PROC_BIND environment variable is not true, false, or a comma
23 separated list of primary, master (master has been deprecated), close, or spread. The
24 behavior is also implementation defined if an initial thread cannot be bound to the first place in the
25 place-partition-var ICV.
26 The OMP_PROC_BIND environment variable sets the max-active-levels-var ICV to the number of
27 active levels of parallelism that the implementation supports if the OMP_PROC_BIND environment
28 variable is set to a comma-separated list of more than one element. The value of the
29 max-active-level-var ICV may be overridden by setting OMP_MAX_ACTIVE_LEVELS or
30 OMP_NESTED. See Section 6.8 and Section 6.9 for details.
31 Examples:
32 setenv OMP_PROC_BIND false
33 setenv OMP_PROC_BIND "spread, spread, close"

1 Cross References
2 • bind-var ICV, see Section 2.4.
3 • proc_bind clause, see Section 2.6.2.
4 • omp_get_proc_bind routine, see Section 3.3.1.
5 6.5 OMP_PLACES
6 The OMP_PLACES environment variable sets the initial value of the place-partition-var ICV. A list
7 of places can be specified in the OMP_PLACES environment variable. The value of OMP_PLACES
8 can be one of two types of values: either an abstract name that describes a set of places or an
9 explicit list of places described by non-negative numbers.
10 The OMP_PLACES environment variable can be defined using an explicit ordered list of
11 comma-separated places. A place is defined by an unordered set of comma-separated non-negative
12 numbers enclosed by braces, or a non-negative number. The meaning of the numbers and how the
13 numbering is done are implementation defined. Generally, the numbers represent the smallest unit
14 of execution exposed by the execution environment, typically a hardware thread.
15 Intervals may also be used to define places. Intervals can be specified using the <lower-bound> :
16 <length> : <stride> notation to represent the following list of numbers: “<lower-bound>,
17 <lower-bound> + <stride>, ..., <lower-bound> + (<length> - 1)*<stride>.” When <stride> is
18 omitted, a unit stride is assumed. Intervals can specify numbers within a place as well as sequences
19 of places.
20 An exclusion operator “!” can also be used to exclude the number or place immediately following
21 the operator.
22 Alternatively, the abstract names listed in Table 6.1 should be understood by the execution and
23 runtime environment. The precise definitions of the abstract names are implementation defined. An
24 implementation may also add abstract names as appropriate for the target platform.
25 The abstract name may be appended by a positive number in parentheses to denote the length of the
26 place list to be created, that is abstract_name(num-places). When requesting fewer places than
27 available on the system, the determination of which resources of type abstract_name are to be
28 included in the place list is implementation defined. When requesting more resources than
29 available, the length of the place list is implementation defined.

TABLE 6.1: Predefined Abstract Names for OMP_PLACES
Abstract Name Meaning

threads Each place corresponds to a single hardware thread on the
device.
cores Each place corresponds to a single core (having one or more
hardware threads) on the device.
ll_caches Each place corresponds to a set of cores that share the last
level cache on the device.
numa_domains Each place corresponds to a set of cores for which their closest
memory on the device is:
• the same memory; and
• at a similar distance from the cores.
sockets Each place corresponds to a single socket (consisting of one or
more cores) on the device.
1 The behavior of the program is implementation defined when the execution environment cannot
2 map a numerical value (either explicitly defined or implicitly derived from an interval) within the
3 OMP_PLACES list to a processor on the target platform, or if it maps to an unavailable processor.
4 The behavior is also implementation defined when the OMP_PLACES environment variable is
5 defined using an abstract name.
6 The following grammar describes the values accepted for the OMP_PLACES environment variable.
hlisti |= hp-listi | hanamei

hp-listi |= hp-intervali | hp-listi,hp-intervali
hp-intervali |= hplacei:hleni:hstridei | hplacei:hleni | hplacei | !hplacei
hplacei |= {hres-listi} | hresi
hres-listi |= hres-intervali | hres-listi,hres-intervali
hres-intervali |= hresi:hnum-placesi:hstridei | hresi:hnum-placesi | hresi | !hresi
hanamei |= hwordi(hnum-placesi) | hwordi
hwordi |= sockets | cores | ll_caches | numa_domains | threads
| <implementation-defined abstract name>
hresi |= non-negative integer
hnum-placesi |= positive integer
hstridei |= integer
hleni |= positive integer

1 Examples:
2 setenv OMP_PLACES threads
3 setenv OMP_PLACES "threads(4)"
4 setenv OMP_PLACES
5 "{0,1,2,3},{4,5,6,7},{8,9,10,11},{12,13,14,15}"
6 setenv OMP_PLACES "{0:4},{4:4},{8:4},{12:4}"
7 setenv OMP_PLACES "{0:4}:4:4"
8 where each of the last three definitions corresponds to the same 4 places including the smallest
9 units of execution exposed by the execution environment numbered, in turn, 0 to 3, 4 to 7, 8 to 11,
10 and 12 to 15.
11 Cross References
12 • place-partition-var, see Section 2.4.
19 • omp_get_partition_place_nums routine, see Section 3.3.7.
20 6.6 OMP_STACKSIZE
21 The OMP_STACKSIZE environment variable controls the size of the stack for threads created by
22 the OpenMP implementation, by setting the value of the stacksize-var ICV. The environment
23 variable does not control the size of the stack for an initial thread.
24 The value of this environment variable takes the form:
25 size | sizeB | sizeK | sizeM | sizeG
26 where:
27 • size is a positive integer that specifies the size of the stack for threads that are created by the
29 • B, K, M, and G are letters that specify whether the given size is in Bytes, Kilobytes (1024 Bytes),
30 Megabytes (1024 Kilobytes), or Gigabytes (1024 Megabytes), respectively. If one of these letters
31 is present, white space may occur between size and the letter.

1 If only size is specified and none of B, K, M, or G is specified, then size is assumed to be in Kilobytes.
2 The behavior of the program is implementation defined if OMP_STACKSIZE does not conform to
3 the above format, or if the implementation cannot provide a stack with the requested size.
4 Examples:
5 setenv OMP_STACKSIZE 2000500B
6 setenv OMP_STACKSIZE "3000 k "
7 setenv OMP_STACKSIZE 10M
8 setenv OMP_STACKSIZE " 10 M "
9 setenv OMP_STACKSIZE "20 m "
10 setenv OMP_STACKSIZE " 1G"
11 setenv OMP_STACKSIZE 20000
12 Cross References
13 • stacksize-var ICV, see Section 2.4.
14 6.7 OMP_WAIT_POLICY
15 The OMP_WAIT_POLICY environment variable provides a hint to an OpenMP implementation
16 about the desired behavior of waiting threads by setting the wait-policy-var ICV. A compliant
17 OpenMP implementation may or may not abide by the setting of the environment variable.
19 active | passive
20 The active value specifies that waiting threads should mostly be active, consuming processor
21 cycles, while waiting. An OpenMP implementation may, for example, make waiting threads spin.
22 The passive value specifies that waiting threads should mostly be passive, not consuming
23 processor cycles, while waiting. For example, an OpenMP implementation may make waiting
24 threads yield the processor to other threads or go to sleep.
25 The details of the active and passive behaviors are implementation defined.
26 The behavior of the program is implementation defined if the value of OMP_WAIT_POLICY is
27 neither active nor passive.
28 Examples:
29 setenv OMP_WAIT_POLICY ACTIVE
30 setenv OMP_WAIT_POLICY active
31 setenv OMP_WAIT_POLICY PASSIVE
32 setenv OMP_WAIT_POLICY passive
33 Cross References
34 • wait-policy-var ICV, see Section 2.4.

1 6.8 OMP_MAX_ACTIVE_LEVELS
2 The OMP_MAX_ACTIVE_LEVELS environment variable controls the maximum number of nested
3 active parallel regions by setting the initial value of the max-active-levels-var ICV.
4 The value of this environment variable must be a non-negative integer. The behavior of the
5 program is implementation defined if the requested value of OMP_MAX_ACTIVE_LEVELS is
6 greater than the maximum number of nested active parallel levels an implementation can support,
7 or if the value is not a non-negative integer.
8 Cross References
12 6.9 OMP_NESTED (Deprecated)

13 The OMP_NESTED environment variable controls nested parallelism by setting the initial value of
14 the max-active-levels-var ICV. If the environment variable is set to true, the initial value of
15 max-active-levels-var is set to the number of active levels of parallelism supported by the
16 implementation. If the environment variable is set to false, the initial value of
17 max-active-levels-var is set to 1. The behavior of the program is implementation defined if the
18 value of OMP_NESTED is neither true nor false.
19 If both the OMP_NESTED and OMP_MAX_ACTIVE_LEVELS environment variables are set, the
20 value of OMP_NESTED is false, and the value of OMP_MAX_ACTIVE_LEVELS is greater than
21 1, then the behavior is implementation defined. Otherwise, if both environment variables are set
22 then the OMP_NESTED environment variable has no effect.
23 The OMP_NESTED environment variable has been deprecated.
24 Example:
25 setenv OMP_NESTED false
26 Cross References

1 6.10 OMP_THREAD_LIMIT
2 The OMP_THREAD_LIMIT environment variable sets the maximum number of OpenMP threads
3 to use in a contention group by setting the thread-limit-var ICV.
4 The value of this environment variable must be a positive integer. The behavior of the program is
5 implementation defined if the requested value of OMP_THREAD_LIMIT is greater than the
6 number of threads an implementation can support, or if the value is not a positive integer.
7 Cross References
8 • thread-limit-var ICV, see Section 2.4.
9 • omp_get_thread_limit routine, see Section 3.2.13.
10 6.11 OMP_CANCELLATION
11 The OMP_CANCELLATION environment variable sets the initial value of the cancel-var ICV.
13 true|false
14 If the environment variable is set to true, the effects of the cancel construct and of cancellation
15 points are enabled and cancellation is activated. If the environment variable is set to false,
16 cancellation is disabled and the cancel construct and cancellation points are effectively ignored.
17 The behavior of the program is implementation defined if OMP_CANCELLATION is set to neither
18 true nor false.
19 Cross References
20 • cancel-var, see Section 2.4.1.
22 • cancellation point construct, see Section 2.20.2.
24 6.12 OMP_DISPLAY_ENV
25 The OMP_DISPLAY_ENV environment variable instructs the runtime to display the information as
26 described in the omp_display_env routine section (Section 3.15).
27 The value of the OMP_DISPLAY_ENV environment variable may be set to one of these values:
28 true | false | verbose

1 If the environment variable is set to true, the effect is as if the omp_display_env routine is
2 called with the verbose argument set to false at the beginning of the program. If the environment
3 variable is set to verbose, the effect is as if the omp_display_env routine is called with the
4 verbose argument set to true at the beginning of the program. If the environment variable is
5 undefined or set to false, the runtime does not display any information. For all values of the
6 environment variable other than true, false, and verbose, the displayed information is
7 unspecified.
8 Example:
9 % setenv OMP_DISPLAY_ENV true
10 For the output of the above example, see Section 3.15.
11 Cross References
12 • omp_display_env routine, see Section 3.15.
13 6.13 OMP_DISPLAY_AFFINITY
14 The OMP_DISPLAY_AFFINITY environment variable instructs the runtime to display formatted
15 affinity information for all OpenMP threads in the parallel region upon entering the first parallel
16 region and when any change occurs in the information accessible by the format specifiers listed in
17 Table 6.2. If affinity of any thread in a parallel region changes then thread affinity information for
18 all threads in that region is displayed. If the thread affinity for each respective parallel region at
19 each nesting level has already been displayed and the thread affinity has not changed, then the
20 information is not displayed again. Thread affinity information for threads in the same parallel
21 region may be displayed in any order.
22 The value of the OMP_DISPLAY_AFFINITY environment variable may be set to one of these
23 values:
24 true | false
25 The true value instructs the runtime to display the OpenMP thread affinity information, and uses
26 the format setting defined in the affinity-format-var ICV.
27 The runtime does not display the OpenMP thread affinity information when the value of the
28 OMP_DISPLAY_AFFINITY environment variable is false or undefined. For all values of the
29 environment variable other than true or false, the display action is implementation defined.
30 Example:
31 setenv OMP_DISPLAY_AFFINITY TRUE
32 The above example causes an OpenMP implementation to display OpenMP thread affinity
33 information during execution of the program, in a format given by the affinity-format-var ICV. The
34 following is a sample output:

1 nesting_level= 1, thread_num= 0, thread_affinity= 0,1
2 nesting_level= 1, thread_num= 1, thread_affinity= 2,3
3 Cross References
10 6.14 OMP_AFFINITY_FORMAT
11 The OMP_AFFINITY_FORMAT environment variable sets the initial value of the
12 affinity-format-var ICV which defines the format when displaying OpenMP thread affinity
13 information.
14 The value of this environment variable is case sensitive and leading and trailing whitespace is
15 significant.
16 The value of this environment variable is a character string that may contain as substrings one or
17 more field specifiers, in addition to other characters. The format of each field specifier is
18 %[[[0].] size ] type
19 where an individual field specifier must contain the percent symbol (%) and a type. The type can be
20 a single character short name or its corresponding long name delimited with curly braces, such as
21 %n or %{thread_num}. A literal percent is specified as %%. Field specifiers can be provided in
22 any order.
23 The 0 modifier indicates whether or not to add leading zeros to the output, following any indication
24 of sign or base. The . modifier indicates the output should be right justified when size is specified.
25 By default, output is left justified. The minimum field length is size, which is a decimal digit string
26 with a non-zero first digit. If no size is specified, the actual length needed to print the field will be
27 used. If the 0 modifier is used with type of A, {thread_affinity}, H, {host}, or a type that
28 is not printed as a number, the result is unspecified. Any other characters in the format string that
29 are not part of a field specifier will be included literally in the output.

TABLE 6.2: Available Field Types for Formatting OpenMP Thread Affinity Information
Short Long Name Meaning

Name
t team_num The value returned by omp_get_team_num().

T num_teams The value returned by omp_get_num_teams().
L nesting_level The value returned by omp_get_level().
n thread_num The value returned by omp_get_thread_num().
N num_threads The value returned by omp_get_num_threads().
a ancestor_tnum The value returned by
omp_get_ancestor_thread_num(level),
where level is omp_get_level() minus 1.
H host The name for the host device on which the OpenMP
program is running.
P process_id The process identifier used by the implementation.
i native_thread_id The native thread identifier used by the implementation.
A thread_affinity The list of numerical identifiers, in the format of a comma-
separated list of integers or integer ranges, that represent
processors on which a thread may execute, subject to
OpenMP thread affinity control and/or other external
affinity mechanisms.
1 Implementations may define additional field types. If an implementation does not have information
2 for a field type, "undefined" is printed for this field when displaying the OpenMP thread affinity
3 information.
4 Example:
5 setenv OMP_AFFINITY_FORMAT
6 "Thread Affinity: %0.3L %.8n %.15{thread_affinity} %.12H"
7 The above example causes an OpenMP implementation to display OpenMP thread affinity
8 information in the following form:
9 Thread Affinity: 001 0 0-1,16-17 nid003
10 Thread Affinity: 001 1 2-3,18-19 nid003
11 Cross References

5 6.15 OMP_DEFAULT_DEVICE
6 The OMP_DEFAULT_DEVICE environment variable sets the device number to use in device
7 constructs by setting the initial value of the default-device-var ICV.
8 The value of this environment variable must be a non-negative integer value.
9 Cross References
10 • default-device-var ICV, see Section 2.4.
11 • device directives, Section 2.14.
12 6.16 OMP_MAX_TASK_PRIORITY
13 The OMP_MAX_TASK_PRIORITY environment variable controls the use of task priorities by
14 setting the initial value of the max-task-priority-var ICV. The value of this environment variable
15 must be a non-negative integer.
16 Example:
17 % setenv OMP_MAX_TASK_PRIORITY 20
18 Cross References
19 • max-task-priority-var ICV, see Section 2.4.
20 • Tasking Constructs, see Section 2.12.
21 • omp_get_max_task_priority routine, see Section 3.5.1.
22 6.17 OMP_TARGET_OFFLOAD
23 The OMP_TARGET_OFFLOAD environment variable sets the initial value of the target-offload-var
24 ICV. The value of the OMP_TARGET_OFFLOAD environment variable must be one of the
25 following:
26 mandatory | disabled | default

1 The mandatory value specifies that program execution is terminated if a device construct or
2 device memory routine is encountered and the device is not available or is not supported by the
3 implementation. Support for the disabled value is implementation defined. If an
4 implementation supports it, the behavior is as if the only device is the host device.
5 The default value specifies the default behavior as described in Section 1.3.
6 Example:
7 % setenv OMP_TARGET_OFFLOAD mandatory
8 Cross References
9 • target-offload-var ICV, see Section 2.4.
10 • Device Directives, see Section 2.14.
11 • Device Memory Routines, see Section 3.8.
12 6.18 OMP_TOOL
13 The OMP_TOOL environment variable sets the tool-var ICV, which controls whether an OpenMP
14 runtime will try to register a first party tool.
16 enabled | disabled
17 If OMP_TOOL is set to any value other than enabled or disabled, the behavior is unspecified.
18 If OMP_TOOL is not defined, the default value for tool-var is enabled.
19 Example:
20 % setenv OMP_TOOL enabled
21 Cross References
22 • tool-var ICV, see Section 2.4.
23 • OMPT Interface, see Chapter 4.
24 6.19 OMP_TOOL_LIBRARIES
25 The OMP_TOOL_LIBRARIES environment variable sets the tool-libraries-var ICV to a list of tool
26 libraries that are considered for use on a device on which an OpenMP implementation is being
27 initialized. The value of this environment variable must be a list of names of dynamically-loadable
28 libraries, separated by an implementation specific, platform typical separator. Whether the value of
29 this environment variable is case sensitive is implementation defined.

1 If the tool-var ICV is not enabled, the value of tool-libraries-var is ignored. Otherwise, if
2 ompt_start_tool is not visible in the address space on a device where OpenMP is being
3 initialized or if ompt_start_tool returns NULL, an OpenMP implementation will consider
4 libraries in the tool-libraries-var list in a left to right order. The OpenMP implementation will
5 search the list for a library that meets two criteria: it can be dynamically loaded on the current
6 device and it defines the symbol ompt_start_tool. If an OpenMP implementation finds a
7 suitable library, no further libraries in the list will be considered.
8 Example:
9 % setenv OMP_TOOL_LIBRARIES libtoolXY64.so:/usr/local/lib/
10 libtoolXY32.so
11 Cross References
12 • tool-libraries-var ICV, see Section 2.4.
14 • ompt_start_tool routine, see Section 4.2.1.
15 6.20 OMP_TOOL_VERBOSE_INIT
16 The OMP_TOOL_VERBOSE_INIT environment variable sets the tool-verbose-init-var ICV, which
17 controls whether an OpenMP implementation will verbosely log the registration of a tool.
19 disabled | stdout | stderr | <filename>
20 If OMP_TOOL_VERBOSE_INIT is set to any value other than case insensitive disabled,
21 stdout or stderr, the value is interpreted as a filename and the OpenMP runtime will try to log
22 to a file with prefix filename. If the value is interpreted as a filename, whether it is case sensitive is
23 implementation defined. If opening the logfile fails, the output will be redirected to stderr. If
24 OMP_TOOL_VERBOSE_INIT is not defined, the default value for tool-verbose-init-var is
25 disabled. Support for logging to stdout or stderr is implementation defined. Unless
26 tool-verbose-init-var is disabled, the OpenMP runtime will log the steps of the tool activation
27 process defined in Section 4.2.2 to a file with a name that is constructed using the provided
28 filename prefix. The format and detail of the log is implementation defined. At a minimum, the log
29 will contain the following:
30 • either that tool-var is disabled, or
31 • an indication that a tool was available in the address space at program launch, or
32 • the path name of each tool in OMP_TOOL_LIBRARIES that is considered for dynamic loading,
33 whether dynamic loading was successful, and whether the ompt_start_tool function is
34 found in the loaded library.

1 In addition, if an ompt_start_tool function is called the log will indicate whether or not the
2 tool will use the OMPT interface.
3 Example:
4 % setenv OMP_TOOL_VERBOSE_INIT disabled
5 % setenv OMP_TOOL_VERBOSE_INIT STDERR
6 % setenv OMP_TOOL_VERBOSE_INIT ompt_load.log
7 Cross References
8 • tool-verbose-init-var ICV, see Section 2.4.
10 6.21 OMP_DEBUG
11 The OMP_DEBUG environment variable sets the debug-var ICV, which controls whether an
12 OpenMP runtime collects information that an OMPD library may need to support a tool.
14 enabled | disabled
15 If OMP_DEBUG is set to any value other than enabled or disabled then the behavior is
17 Example:
18 % setenv OMP_DEBUG enabled
19 Cross References
20 • debug-var ICV, see Section 2.4.
21 • OMPD Interface, see Chapter 5.
22 • Enabling the Runtime for OMPD, see Section 5.2.1.
23 6.22 OMP_ALLOCATOR
24 The OMP_ALLOCATOR environment variable sets the initial value of the def-allocator-var ICV
25 that specifies the default allocator for allocation calls, directives and clauses that do not specify an
26 allocator.
27 The following grammar describes the values accepted for the OMP_ALLOCATOR environment
28 variable.

hallocatori |= hpredef-allocatori | hpredef-mem-spacei |
hpredef-mem-spacei:htraitsi
htraitsi |= htraiti=hvaluei | htraiti=hvaluei,htraitsi
hpredef-allocatori |= one of the predefined allocators from Table 2.10
hpredef-mem-spacei |= one of the predefined memory spaces from Table 2.8
htraiti |= one of the allocator trait names from Table 2.9
hvaluei |= one of the allowed values from Table 2.9 | non-negative integer |
hpredef-allocatori
1 value can be an integer only if the trait accepts a numerical value, for the fb_data trait the value
2 can only be predef-allocator. If the value of this environment variable is not a predefined allocator,
3 then a new allocator with the given predefined memory space and optional traits is created and set
4 as the def-allocator-var ICV. If the new allocator cannot be created, the def-allocator-var ICV will
5 be set to omp_default_mem_alloc.
6 Example:
7 setenv OMP_ALLOCATOR omp_high_bw_mem_alloc
8 setenv OMP_ALLOCATOR omp_large_cap_mem_space:alignment=16,\
9 pinned=true
10 setenv OMP_ALLOCATOR omp_high_bw_mem_space:pool_size=1048576,\
11 fallback=allocator_fb,fb_data=omp_low_lat_mem_alloc
12 Cross References
17 • omp_alloc and omp_aligned_alloc routines, see Section 3.13.6
18 • omp_calloc and omp_aligned_calloc routines, see Section 3.13.8
19 6.23 OMP_NUM_TEAMS
20 The OMP_NUM_TEAMS environment variable sets the maximum number of teams created by a
21 teams construct by setting the nteams-var ICV.

2 implementation defined if the requested value of OMP_NUM_TEAMS is greater than the number of
3 teams that an implementation can support, or if the value is not a positive integer.
4 Cross References
7 6.24 OMP_TEAMS_THREAD_LIMIT
8 The OMP_TEAMS_THREAD_LIMIT environment variable sets the maximum number of OpenMP
9 threads to use in each contention group created by a teams construct by setting the
10 teams-thread-limit-var ICV.
12 implementation defined if the requested value of OMP_TEAMS_THREAD_LIMIT is greater than
13 the number of threads that an implementation can support, or if the value is not a positive integer.
14 Cross References
15 • teams-thread-limit-var ICV, see Section 2.4.

1 A OpenMP Implementation-Defined
2 Behaviors
3 This appendix summarizes the behaviors that are described as implementation defined in this API.
4 Each behavior is cross-referenced back to its description in the main specification. An
5 implementation is required to define and to document its behavior in these cases.
6 Chapter 1:
7 • Processor: A hardware unit that is implementation defined (see Section 1.2.1).
8 • Device: An implementation defined logical execution engine (see Section 1.2.1).
9 • Device pointer: an implementation defined handle that refers to a device address (see
10 Section 1.2.6).
11 • Supported active levels of parallelism: The maximum number of active parallel regions that
12 may enclose any region of code in the program is implementation defined (see Section 1.2.7).
13 • Memory model: The minimum size at which a memory update may also read and write back
14 adjacent variables that are part of another variable (as array or structure elements) is
15 implementation defined but is no larger than required by the base language. The manner in which
16 a program can obtain the referenced device address from a device pointer, outside the
17 mechanisms specified by OpenMP, is implementation defined (see Section 1.4.1).
18 Chapter 2:
19 • OpenMP context: Whether the dispatch construct is added to the construct set, the accepted
20 isa-name values for the isa trait, the accepted arch-name values for the arch trait, and the
21 accepted extension-name values for the extension trait are implementation defined (see
22 Section 2.3.1).
23 • Metadirectives: The number of times that each expression of the context selector of a when
24 clause is evaluated is implementation defined (see Section 2.3.4).
25 • Declare variant directive: If two replacement candidates have the same score, their order is
26 implementation defined. The number of times each expression of the context selector of a match
27 clause is evaluated is implementation defined. For calls to constexpr base functions that are
28 evaluated in constant expressions, whether any variant replacement occurs is implementation
29 defined. Any differences that the specific OpenMP context requires in the prototype of the
30 variant from the base function prototype are implementation defined (see Section 2.3.5).
659
1 • Internal control variables: The initial values of dyn-var, nthreads-var, run-sched-var,
2 def-sched-var, bind-var, stacksize-var, wait-policy-var, thread-limit-var, max-active-levels-var,
3 place-partition-var, affinity-format-var, default-device-var, num-procs-var and def-allocator-var
4 are implementation defined (see Section 2.4.2).
5 • requires directive: Support for any feature specified by a requirement clause on a
6 requires directive is implementation defined (see Section 2.5.1).
7 • Dynamic adjustment of threads: Providing the ability to adjust the number of threads
8 dynamically is implementation defined (see Section 2.6.1).
9 • Thread affinity: For the close thread affinity policy, if T > P and P does not divide T evenly,
10 the exact number of threads in a particular place is implementation defined. For the spread
11 thread affinity, if T > P and P does not divide T evenly, the exact number of threads in a
12 particular subpartition is implementation defined. The determination of whether the affinity
13 request can be fulfilled is implementation defined. If not, the mapping of threads in the team to
14 places is implementation defined (see Section 2.6.2).
15 • teams construct: The number of teams that are created is implementation defined, it is greater
16 than or equal to the lower bound and less than or equal to the upper bound values of the
17 num_teams clause if specified or it is less than or equal to the value of the nteams-var ICV if
18 its value is greater than zero. Otherwise it is greater than or equal to 1. The maximum number of
19 threads that participate in the contention group that each team initiates is implementation defined
20 if no thread_limit clause is specified on the construct. The assignment of the initial threads
21 to places and the values of the place-partition-var and default-device-var ICVs for each initial
22 thread are implementation defined (see Section 2.7).
23 • sections construct: The method of scheduling the structured blocks among threads in the
24 team is implementation defined (see Section 2.10.1).
25 • single construct: The method of choosing a thread to execute the structured block each time
26 the team encounters the construct is implementation defined (see Section 2.10.2).
27 • Canonical loop nest form: The particular integer type used to compute the iteration count for
28 the collapsed loop is implementation defined (see Section 2.11.1).
29 • Worksharing-loop directive: The effect of the schedule(runtime) clause when the
30 run-sched-var ICV is set to auto is implementation defined. The value of simd_width for the
31 simd schedule modifier is implementation defined (see Section 2.11.4).
32 • simd construct: The number of iterations that are executed concurrently at any given time is
33 implementation defined. If the alignment parameter is not specified in the aligned clause, the
34 default alignments for the SIMD instructions are implementation defined (see Section 2.11.5.1).
35 • declare simd directive: If the parameter of the simdlen clause is not a constant positive
36 integer expression, the number of concurrent arguments for the function is implementation
37 defined. If the alignment parameter of the aligned clause is not specified, the default
38 alignments for SIMD instructions are implementation defined (see Section 2.11.5.3).

1 • distribute construct: If no dist_schedule clause is specified then the schedule for the
2 distribute construct is implementation defined (see Section 2.11.6.1).
3 • unroll construct: If the partial clause is specified without an argument, the unroll factor is
4 a positive integer that is implementation defined. If neither the partial nor the full clause is
5 specified, if and how the loop is unrolled is implementation defined (see Section 2.11.9.2).
6 • taskloop construct: The number of loop iterations assigned to a task created from a
7 taskloop construct is implementation defined, unless the grainsize or num_tasks
8 clause is specified (see Section 2.12.2).
C++
9 • taskloop construct: For firstprivate variables of class type, the number of invocations
10 of copy constructors to perform the initialization is implementation defined (see Section 2.12.2).
C++
11 • Memory spaces: The actual storage resources that each memory space defined in Table 2.8
12 represents are implementation defined (see Section 2.13.1).
13 • Memory allocators: The minimum partitioning size for partitioning of allocated memory over
14 the storage resources is implementation defined. The default value for the pool_size allocator
15 trait (see Table 2.9) is implementation defined. The associated memory space for each of the
16 predefined omp_cgroup_mem_alloc, omp_pteam_mem_alloc and
17 omp_thread_mem_alloc allocators (see Table 2.10) is implementation defined (see
18 Section 2.13.2).
19 • target construct: The maximum number of threads that participate in the contention group
20 that each team initiates is implementation defined if no thread_limit clause is specified on
21 the construct (see Section 2.14.5).
22 • is_device_ptr clause: Support for pointers created outside of the OpenMP device data
23 management routines is implementation defined (see Section 2.14.5).
24 • interop directive: The foreign-runtime-id that is used if the implementation does not support
25 any of the items in preference-list is implementation defined (see Section 2.15.1).
26 • interop Construct: The foreign-runtime-id values for the prefer_type clause that the
27 implementation supports, including non-standard names compatible with this clause, and the
28 default choice when the implementation supports multiple values are implementation defined
29 (see Section 2.15.1).
30 • The concrete types of the values of interop properties for implementation defined
31 foreign-runtime-ids are implementation defined (see Section 2.15.1).
32 • atomic construct: A compliant implementation may enforce exclusive access between
33 atomic regions that update different storage locations. The circumstances under which this
34 occurs are implementation defined. If the storage location designated by x is not size-aligned
35 (that is, if the byte alignment of x is not a multiple of the size of x), then the behavior of the
36 atomic region is implementation defined (see Section 2.19.7).
APPENDIX A. OPENMP IMPLEMENTATION-DEFINED BEHAVIORS 661

Fortran
1 • Data-sharing attributes: The data-sharing attributes of dummy arguments without the VALUE
2 attribute are implementation defined if the associated actual argument is shared, except for the
3 conditions specified (see Section 2.21.1.2).
4 • threadprivate directive: If the conditions for values of data in the threadprivate objects of
5 threads (other than an initial thread) to persist between two consecutive active parallel regions do
6 not all hold, the allocation status of an allocatable variable in the second region is
7 implementation defined (see Section 2.21.2).
Fortran
8 Chapter 3:
C / C++
9 • Runtime library definitions: The enum types for omp_allocator_handle_t,
10 omp_event_handle_t, omp_interop_type_t and omp_memspace_handle_t are
11 implementation defined. The integral or pointer type for omp_interop_t is implementation
12 defined (see Section 3.1).
C / C++
Fortran
13 • Runtime library definitions: Whether the include file omp_lib.h or the module omp_lib
14 (or both) is provided is implementation defined. Whether the omp_lib.h file provides
15 derived-type definitions or those routines that require an explicit interface is implementation
16 defined. Whether any of the OpenMP runtime library routines that take an argument are
17 extended with a generic interface so arguments of different KIND type can be accommodated is
18 implementation defined (see Section 3.1).
Fortran
19 • omp_set_num_threads routine: If the argument is not a positive integer the behavior is
21 • omp_set_schedule routine: For implementation-specific schedule kinds, the values and
22 associated meanings of the second argument are implementation defined (see Section 3.2.11).
23 • omp_get_schedule routine: The value returned by the second argument is implementation
24 defined for any schedule kinds other than static, dynamic and guided (see Section 3.2.12).
25 • omp_get_supported_active_levels routine: The number of active levels of
26 parallelism supported by the implementation is implementation defined, but must be greater than
27 0 (see Section 3.2.14).
28 • omp_set_max_active_levels routine: If the argument is not a non-negative integer then
29 the behavior is implementation defined (see Section 3.2.15).

1 • omp_get_place_proc_ids routine: The meaning of the non-negative numerical identifiers
2 returned by the omp_get_place_proc_ids routine is implementation defined. The order of
3 the numerical identifiers returned in the array ids is implementation defined (see Section 3.3.4).
4 • omp_set_affinity_format routine: When called from within any parallel or
5 teams region, the binding thread set (and binding region, if required) for the
6 omp_set_affinity_format region and the effect of this routine are implementation
7 defined (see Section 3.3.8).
8 • omp_get_affinity_format routine: When called from within any parallel or
9 teams region, the binding thread set (and binding region, if required) for the
10 omp_get_affinity_format region is implementation defined (see Section 3.3.9).
11 • omp_display_affinity routine: If the format argument does not conform to the specified
12 format then the result is implementation defined (see Section 3.3.10).
13 • omp_capture_affinity routine: If the format argument does not conform to the specified
14 format then the result is implementation defined (see Section 3.3.11).
15 • omp_set_num_teams routine: If the argument is not evaluated to a positive integer the
16 behavior of this routine is implementation defined (see Section 3.4.3).
17 • omp_set_teams_thread_limit routine: If the argument is not a positive integer the
18 behavior is implementation defined (see Section 3.4.5).
19 • omp_target_memcpy_rect routine: The maximum number of dimensions supported is
20 implementation defined, but must be at least three (see Section 3.8.6).
21 • Lock routines: If a lock contains a synchronization hint, the effect of the hint is implementation
22 defined (see Section 3.9 and Section 3.9.2).
23 Chapter 4:
24 • ompt_callback_sync_region_wait, ompt_callback_mutex_released,
25 ompt_callback_dependences, ompt_callback_task_dependence,
26 ompt_callback_work, ompt_callback_master (deprecated),
27 ompt_callback_masked, ompt_callback_target_map,
28 ompt_callback_target_map_emi, ompt_callback_sync_region,
29 ompt_callback_reduction, ompt_callback_lock_init,
30 ompt_callback_lock_destroy, ompt_callback_mutex_acquire,
31 ompt_callback_mutex_acquired, ompt_callback_nest_lock,
32 ompt_callback_flush, ompt_callback_cancel and
33 ompt_callback_dispatch tool callbacks: If a tool attempts to register a callback with the
34 string name using the runtime entry point ompt_set_callback (see Table 4.3), whether the
35 registered callback may never, sometimes or always invoke this callback for the associated events
36 is implementation defined (see Section 4.2.4).

1 • Device tracing: Whether a target device supports tracing or not is implementation defined; if a
2 target device does not support tracing, a NULL may be supplied for the lookup function to the
3 device initializer of a tool (see Section 4.2.5).
4 • ompt_set_trace_ompt and ompt_buffer_get_record_ompt runtime entry
5 points: Whether a device-specific tracing interface will define this runtime entry point,
6 indicating that it can collect traces in OMPT format is implementation defined. The kinds of
7 trace records available for a device is implementation defined (see Section 4.2.5).
8 • Native record abstract type: The meaning of a hwid value for a device is implementation
9 defined (see Section 4.4.3.3).
10 • ompt_record_abstract_t type: The set of OMPT thread states supported is
11 implementation defined (see Section 4.4.4.27).
12 • ompt_callback_target_data_op_t callback type: Whether in some operations
13 src_addr or dest_addr might point to an intermediate buffer is implementation defined (see
14 Section 4.5.2.25).
15 • ompt_set_callback_t entry point type: The subset of the associated event in which the
16 callback is invoked is implementation defined (see Section 4.6.1.3).
17 • ompt_get_place_proc_ids_t entry point type: The meaning of the numerical
18 identifiers returned is implementation defined. The order of ids returned in the array is
20 • ompt_get_partition_place_nums_t entry point type: The order of the identifiers
21 returned in the array place_nums is implementation defined (see Section 4.6.1.10).
22 • ompt_get_proc_id_t entry point type: The meaning of the numerical identifier returned
23 is implementation defined (see Section 4.6.1.11).
24 Chapter 5:
25 • ompd_callback_print_string_fn_t callback function: The value of category is
27 • ompd_parallel_handle_compare operation: The means by which parallel region
28 handles are ordered is implementation defined (see Section 5.5.6.5).
29 • ompd_task_handle_compare operation: The means by which task handles are ordered is
31 Chapter 6:
32 • OMP_SCHEDULE environment variable: If the value does not conform to the specified format
33 then the behavior of the program is implementation defined (see Section 6.1).
34 • OMP_NUM_THREADS environment variable: If any value of the list specified leads to a number
35 of threads that is greater than the implementation can support, or if any value is not a positive
36 integer, then the behavior of the program is implementation defined (see Section 6.2).

1 • OMP_DYNAMIC environment variable: If the value is neither true nor false the behavior of
2 the program is implementation defined (see Section 6.3).
3 • OMP_PROC_BIND environment variable: If the value is not true, false, or a comma
4 separated list of primary (master has been deprecated), close, or spread, the behavior is
5 implementation defined. The behavior is also implementation defined if an initial thread cannot
6 be bound to the first place in the OpenMP place list. The thread affinity policy is implementation
7 defined if the value is true (see Section 6.4).
8 • OMP_PLACES environment variable: The meaning of the numbers specified in the
9 environment variable and how the numbering is done are implementation defined. The precise
10 definitions of the abstract names are implementation defined. An implementation may add
11 implementation-defined abstract names as appropriate for the target platform. When creating a
12 place list of n elements by appending the number n to an abstract name, the determination of
13 which resources to include in the place list is implementation defined. When requesting more
14 resources than available, the length of the place list is also implementation defined. The behavior
15 of the program is implementation defined when the execution environment cannot map a
16 numerical value (either explicitly defined or implicitly derived from an interval) within the
17 OMP_PLACES list to a processor on the target platform, or if it maps to an unavailable processor.
18 The behavior is also implementation defined when the OMP_PLACES environment variable is
19 defined using an abstract name (see Section 6.5).
20 • OMP_STACKSIZE environment variable: If the value does not conform to the specified format
21 or the implementation cannot provide a stack of the specified size then the behavior is
23 • OMP_WAIT_POLICY environment variable: The details of the active and passive
24 behaviors are implementation defined (see Section 6.7).
25 • OMP_MAX_ACTIVE_LEVELS environment variable: If the value is not a non-negative integer
26 or is greater than the maximum number of nested active parallel levels that an implementation
27 can support then the behavior of the program is implementation defined (see Section 6.8).
28 • OMP_NESTED environment variable (deprecated): If the value is neither true nor false
29 the behavior of the program is implementation defined (see Section 6.9).
30 • Conflicting OMP_NESTED (deprecated) and OMP_MAX_ACTIVE_LEVELS environment
31 variables: If both environment variables are set, the value of OMP_NESTED is false, and the
32 value of OMP_MAX_ACTIVE_LEVELS is greater than 1, the behavior is implementation
33 defined (see Section 6.9).
34 • OMP_THREAD_LIMIT environment variable: If the requested value is greater than the number
35 of threads an implementation can support, or if the value is not a positive integer, the behavior of
36 the program is implementation defined (see Section 6.10).
37 • OMP_DISPLAY_AFFINITY environment variable: For all values of the environment
38 variables other than true or false, the display action is implementation defined (see
39 Section 6.13).

1 • OMP_AFFINITY_FORMAT environment variable: If the value does not conform to the
2 specified format then the result is implementation defined (see Section 6.14).
3 • OMP_TARGET_OFFLOAD environment variable: The support of disabled is
5 • OMP_TOOL_LIBRARIES environment variable: Whether the value of the environment
6 variable is case sensitive or insensitive is implementation defined (see Section 6.19).
7 • OMP_TOOL_VERBOSE_INIT environment variable: Support for logging to stdout or
8 stderr is implementation defined. Whether the value of the environment variable is case
9 sensitive when it is treated as a filename is implementation defined. The format and detail of the
10 log is implementation defined (see Section 6.20).
11 • OMP_DEBUG environment variable: If the value is neither disabled nor enabled the
12 behavior is implementation defined (see Section 6.21).
13 • OMP_NUM_TEAMS environment variable: If the value is not a positive integer or is greater than
14 the number of teams that an implementation can support, the behavior of the program is
16 • OMP_TEAMS_THREAD_LIMIT environment variable: If the value is not a positive integer or
17 is greater than the number of threads that an implementation can support, the behavior of the
18 program is implementation defined (see Section 6.24).

1 B Features History
2 This appendix summarizes the major changes between OpenMP API versions since version 2.5.
3 B.1 Deprecated Features

4 The following features have been deprecated in Version 5.1.
5 • Cray pointer support was deprecated.
6 • The use of clauses supplied to the requires directive as context traits was deprecated.
7 • The master affinity policy was deprecated.
8 • The master construct and all combined and composite constructs of which it is a constituent
9 construct were deprecated.
10 • The constant omp_atv_sequential was deprecated.
11 • In Fortran, specifying list items that are not of type C_PTR in a use_device_ptr or
12 is_device_ptr clause was deprecated.
13 • The ompt_sync_region_barrier and ompt_sync_region_barrier_implicit
14 values of the ompt_sync_region_t enum were deprecated.
15 • The ompt_state_wait_barrier and ompt_state_wait_barrier_implicit
16 values of the ompt_state_t enum were deprecated.
17 The following features have been deprecated in Version 5.0.
18 • The nest-var ICV, the OMP_NESTED environment variable, and the omp_set_nested and
19 omp_get_nested routines were deprecated.
20 • Lock hints were renamed to synchronization hints. The following lock hint type and constants
21 were deprecated:
22 – the C/C++ type omp_lock_hint_t and the Fortran kind omp_lock_hint_kind;
23 – the constants omp_lock_hint_none, omp_lock_hint_uncontended,
24 omp_lock_hint_contended, omp_lock_hint_nonspeculative, and
25 omp_lock_hint_speculative.
667
1 B.2 Version 5.0 to 5.1 Differences
2 • Full support of C11, C++11, C++14, C++17, C++20 and Fortran 2008 was completed (see
3 Section 1.7).
4 • Various changes throughout the specification were made to provide initial support of Fortran
5 2018 (see Section 1.7).
6 • The OpenMP directive syntax was extended to include C++ attribute specifiers (see Section 2.1).
7 • The omp_all_memory reserved locator was added (see Section 2.1), and the depend clause
8 was extended to allow its use (see Section 2.19.11).
9 • The target_device trait set was added to the OpenMP Context (see Section 2.3.1), and the
10 target_device selector set was added to context selectors (see Section 2.3.2).
11 • For C/C++, the declare variant directive was extended to support elision of preprocessed code
12 and to allow enclosed function definitions to be interpreted as variant functions (see
13 Section 2.3.5).
14 • The declare variant directive was extended with new clauses (adjust_args and
15 append_args) that support adjustment of the interface between the original function and its
16 variants (see Section 2.3.5).
17 • The dispatch construct was added to allow users to control when variant substitution happens
18 and to define additional information that can be passed as arguments to the function variants (see
19 Section 2.3.6).
20 • To support device-specific ICV settings the environment variable syntax was extended to support
21 device-specific variables (see Section 2.4.2 and Section 6).
22 • The assume directive was added to allow users to specify invariants (see Section 2.5.2).
23 • To support clarity in metadirectives, the nothing directive was added (see Section 2.5.3).
24 • To allow users to control the compilation process and runtime error actions, the error directive
25 was added (see Section 2.5.4).
26 • The masked construct was added to support restricting execution to a specific thread (see
27 Section 2.8).
28 • The scope directive was added to support reductions without requiring a parallel or
29 worksharing region (see Section 2.9).
30 • Loop transformation constructs were added (see Section 2.11.9).
31 • The grainsize and num_tasks clauses for the taskloop construct were extended with a
32 strict modifier to ensure a deterministic distribution of logical iterations to tasks (see
33 Section 2.12.2).

1 • Support for the align clause on the allocate directive and allocator and align
2 modifiers on the allocate clause was added (see Section 2.13).
3 • The thread_limit clause was added to the target construct to control the upper bound on
4 the number of threads in the created contention group (see Section 2.14.5).
5 • The has_device_addr clause was added to the target construct to allow access to
6 variables or array sections that already have a device address (see Section 2.14.5).
7 • Support was added so that iterators may be defined and used in a motion clause on a
8 target update directive (see Section 2.14.6) or in a map clause (see Section 2.21.7.1).
9 • Support was added for indirect calls to the device version of a procedure or function in target
10 regions. (see Section 2.14.7).
11 • The interop directive was added to enable portable interoperability with foreign execution
12 contexts used to implement OpenMP (see Section 2.15.1). Runtime routines that facilitate use of
13 omp_interop_t objects were also added (see Section 3.12).
14 • The nowait clause was added to the taskwait directive to support insertion of non-blocking
15 join operations in a task dependence graph (see Section 2.19.5).
16 • Support was added for compare-and-swap and (for C and C++) minimum and maximum atomic
17 operations through the compare clause. Support was also added for the specification of the
18 memory order to apply to a failed comparing atomic operation with the fail clause (see
19 Section 2.19.7).
20 • Specification of the seq_cst clause on a flush construct was allowed, with the same
21 meaning as a flush construct without a list and without a clause (see Section 2.19.8).
22 • To support inout sets, the inoutset argument was added to the depend clause (see
23 Section 2.19.11).
24 • Support for private and firstprivate as an argument to the default clause in C and
25 C++ was added (see Section 2.21.4.1).
26 • The present argument was added to the defaultmap clause (see Section 2.21.7.3).
27 • The omp_set_num_teams and omp_set_teams_thread_limit runtime routines were
28 added to control the number of teams and the size of those teams on the teams construct (see
29 Section 3.4.3 and Section 3.4.5). Additionally, the omp_get_max_teams and
30 omp_get_teams_thread_limit runtime routines were added to retrieve the values that
31 will be used in the next teams construct (see Section 3.4.4 and Section 3.4.6).
32 • The omp_target_is_accessible runtime routine was added to test whether host memory
33 is accessible from a given device (see Section 3.8.4).
34 • To support asynchronous device memory management, omp_target_memcpy_async and
35 omp_target_memcpy_rect_async runtime routines were added (see Section 3.8.7 and
36 Section 3.8.8).
APPENDIX B. FEATURES HISTORY 669

1 • The omp_get_mapped_ptr runtime routine was added to support obtaining the device
2 pointer that is associated with a host pointer for a given device (see Section 3.8.11).
3 • The omp_calloc, omp_realloc, omp_aligned_alloc and omp_aligned_calloc
4 API routines were added (see Section 3.13).
5 • For the omp_alloctrait_key_t enum, the omp_atv_serialized value was added and
6 the omp_atv_default value was changed (see Section 3.13.1).
7 • The omp_display_env runtime routine was added to provide information about ICVs and
8 settings of environment variables (see Section 3.15).
9 • The ompt_scope_beginend value was added to the ompt_scope_endpoint_t enum
10 to indicate the coincident beginning and end of a scope (see Section 4.4.4.11).
11 • The ompt_sync_region_barrier_implicit_workshare,
12 ompt_sync_region_barrier_implicit_parallel and
13 ompt_sync_region_barrier_teams values were added to the
14 ompt_sync_region_t enum (see Section 4.4.4.13).
15 • Values for asynchronous data transfers were added to the ompt_target_data_op_t enum
16 (see Section 4.4.4.14).
17 • The ompt_state_wait_barrier_implementation and
18 ompt_state_wait_barrier_teams values were added to the ompt_state_t enum
19 (see Section 4.4.4.27).
20 • The ompt_callback_target_data_op_emi_t, ompt_callback_target_emi_t,
21 ompt_callback_target_map_emi_t and
22 ompt_callback_target_submit_emi_t callbacks were added to support external
23 monitoring interfaces (see Section 4.5.2.25, Section 4.5.2.26, Section 4.5.2.27 and
24 Section 4.5.2.28).
25 • The ompt_callback_error_t type was added (see Section 4.5.2.30).
26 • The OMP_PLACES syntax was extended (see Section 6.5).
27 • The OMP_NUM_TEAMS and OMP_TEAMS_THREAD_LIMIT environment variables were added
28 to control the number and size of teams on the teams construct (see Section 6.23 and
29 Section 6.24).

31 • The memory model was extended to distinguish different types of flush operations according to
32 specified flush properties (see Section 1.4.4) and to define a happens before order based on
33 synchronizing flush operations (see Section 1.4.5).

1 • Various changes throughout the specification were made to provide initial support of C11,
2 C++11, C++14, C++17 and Fortran 2008 (see Section 1.7).
3 • Full support of Fortran 2003 was completed (see Section 1.7).
4 • Support for array shaping (see Section 2.1.4) and for array sections with non-unit strides in C and
5 C++ (see Section 2.1.5) was added to facilitate specification of discontiguous storage and the
6 target update construct (see Section 2.14.6) and the depend clause (see Section 2.19.11)
7 were extended to allow the use of shape-operators (see Section 2.1.4).
8 • Iterators (see Section 2.1.6) were added to support expressions in a list that expand to multiple
9 expressions.
10 • The metadirective directive (see Section 2.3.4) and declare variant directive (see
11 Section 2.3.5) were added to support selection of directive variants and declared function
12 variants at a call site, respectively, based on compile-time traits of the enclosing context.
13 • The target-offload-var internal control variable (see Section 2.4) and the
14 OMP_TARGET_OFFLOAD environment variable (see Section 6.17) were added to support
15 runtime control of the execution of device constructs.
16 • Control over whether nested parallelism is enabled or disabled was integrated into the
17 max-active-levels-var internal control variable (see Section 2.4.2), the default value of which is
18 now implementation defined, unless determined according to the values of the
19 OMP_NUM_THREADS (see Section 6.2) or OMP_PROC_BIND (see Section 6.4) environment
20 variables.
21 • The requires directive (see Section 2.5.1) was added to support applications that require
22 implementation-specific features.
23 • The teams construct (see Section 2.7) was extended to support execution on the host device
24 without an enclosing target construct (see Section 2.14.5).
25 • The canonical loop form was defined for Fortran and, for all base languages, extended to permit
26 non-rectangular loop nests (see Section 2.11.1).
27 • The relational-op in the canonical loop form for C/C++ was extended to include != (see
28 Section 2.11.1).
29 • The default loop schedule modifier for worksharing-loop constructs without the static
30 schedule and the ordered clause was changed to nonmonotonic (see Section 2.11.4).
31 • The collapse of associated loops that are imperfectly nested loops was defined for the
32 worksharing-loop (see Section 2.11.4), simd (see Section 2.11.5.1), taskloop (see
33 Section 2.12.2) and distribute (see Section 2.11.6.2) constructs.
34 • The simd construct (see Section 2.11.5.1) was extended to accept the if, nontemporal and
35 order(concurrent) clauses and to allow the use of atomic constructs within it.

1 • The loop construct and the order(concurrent) clause were added to support compiler
2 optimization and parallelization of loops for which iterations may execute in any order, including
3 concurrently (see Section 2.11.7).
4 • The scan directive (see Section 2.11.8) and the inscan modifier for the reduction clause
5 (see Section 2.21.5.4) were added to support inclusive and exclusive scan computations.
6 • To support task reductions, the task (see Section 2.12.1) and target (see Section 2.14.5)
7 constructs were extended to accept the in_reduction clause (see Section 2.21.5.6), the
8 taskgroup construct (see Section 2.19.6) was extended to accept the task_reduction
9 clause Section 2.21.5.5), and the task modifier was added to the reduction clause (see
10 Section 2.21.5.4).
11 • The affinity clause was added to the task construct (see Section 2.12.1) to support hints
12 that indicate data affinity of explicit tasks.
13 • The detach clause for the task construct (see Section 2.12.1) and the
14 omp_fulfill_event runtime routine (see Section 3.11.1) were added to support execution
15 of detachable tasks.
16 • To support taskloop reductions, the taskloop (see Section 2.12.2) and taskloop simd
17 (see Section 2.12.3) constructs were extended to accept the reduction (see Section 2.21.5.4)
18 and in_reduction (see Section 2.21.5.6) clauses.
19 • The taskloop construct (see Section 2.12.2) was added to the list of constructs that can be
20 canceled by the cancel construct (see Section 2.20.1)).
21 • To support mutually exclusive inout sets, a mutexinoutset dependence-type was added to
22 the depend clause (see Section 2.12.6 and Section 2.19.11).
23 • Predefined memory spaces (see Section 2.13.1), predefined memory allocators and allocator
24 traits (see Section 2.13.2) and directives, clauses (see Section 2.13 and API routines (see
25 Section 3.13) to use them were added to support different kinds of memories.
26 • The semantics of the use_device_ptr clause for pointer variables was clarified and the
27 use_device_addr clause for using the device address of non-pointer variables inside the
28 target data construct was added (see Section 2.14.2).
29 • To support reverse offload, the ancestor modifier was added to the device clause for
30 target constructs (see Section 2.14.5).
31 • To reduce programmer effort implicit declare target directives for some functions (C, C++,
32 Fortran) and subroutines (Fortran) were added (see Section 2.14.5 and Section 2.14.7).
33 • The target update construct (see Section 2.14.6) was modified to allow array sections that
34 specify discontiguous storage.
35 • The to and from clauses on the target update construct (see Section 2.14.6), the depend
36 clause on task generating constructs (see Section 2.19.11), and the map clause (see
37 Section 2.21.7.1) were extended to allow any lvalue expression as a list item for C/C++.

1 • Support for nested declare target directives was added (see Section 2.14.7).
2 • New combined constructs master taskloop (see Section 2.16.7), parallel master (see
3 Section 2.16.6), parallel master taskloop (see Section 2.16.9),
4 master taskloop simd (see Section 2.16.8), parallel master taskloop simd (see
5 Section 2.16.10) were added.
6 • The depend clause was added to the taskwait construct (see Section 2.19.5).
7 • To support acquire and release semantics with weak memory ordering, the acq_rel,
8 acquire, and release clauses were added to the atomic construct (see Section 2.19.7) and
9 flush construct (see Section 2.19.8), and the memory ordering semantics of implicit flushes on
10 various constructs and runtime routines were clarified (see Section 2.19.8.1).
11 • The atomic construct was extended with the hint clause (see Section 2.19.7).
12 • The depend clause (see Section 2.19.11) was extended to support iterators and to support
13 depend objects that can be created with the new depobj construct.
14 • Lock hints were renamed to synchronization hints, and the old names were deprecated (see
15 Section 2.19.12).
16 • To support conditional assignment to lastprivate variables, the conditional modifier was
17 added to the lastprivate clause (see Section 2.21.4.5).
18 • The description of the map clause was modified to clarify the mapping order when multiple
19 map-types are specified for a variable or structure members of a variable on the same construct.
20 The close map-type-modifier was added as a hint for the runtime to allocate memory close to
21 the target device (see Section 2.21.7.1).
22 • The capability to map C/C++ pointer variables and to assign the address of device memory that
23 is mapped by an array section to them was added. Support for mapping of Fortran pointer and
24 allocatable variables, including pointer and allocatable components of variables, was added (see
25 Section 2.21.7.1).
26 • The defaultmap clause (see Section 2.21.7.3) was extended to allow selecting the
27 data-mapping or data-sharing attributes for any of the scalar, aggregate, pointer or allocatable
28 classes on a per-region basis. Additionally it accepts the none parameter to support the
29 requirement that all variables referenced in the construct must be explicitly mapped or privatized.
30 • The declare mapper directive was added to support mapping of data types with direct and
31 indirect members (see Section 2.21.7.4).
32 • The omp_set_nested (see Section 3.2.9) and omp_get_nested (see Section 3.2.10)
33 routines and the OMP_NESTED environment variable (see Section 6.9) were deprecated.
34 • The omp_get_supported_active_levels routine was added to query the number of
35 active levels of parallelism supported by the implementation (see Section 3.2.14).

1 • Runtime routines omp_set_affinity_format (see Section 3.3.8),
2 omp_get_affinity_format (see Section 3.3.9), omp_set_affinity (see
3 Section 3.3.10), and omp_capture_affinity (see Section 3.3.11) and environment
4 variables OMP_DISPLAY_AFFINITY (see Section 6.13) and OMP_AFFINITY_FORMAT (see
5 Section 6.14) were added to provide OpenMP runtime thread affinity information.
6 • The omp_pause_resource and omp_pause_resource_all runtime routines were
7 added to allow the runtime to relinquish resources used by OpenMP (see Section 3.6.1 and
8 Section 3.6.2).
9 • The omp_get_device_num runtime routine (see Section 3.7.5) was added to support
10 determination of the device on which a thread is executing.
11 • Support for a first-party tool interface (see Section 4) was added.
12 • Support for a third-party tool interface (see Section 5) was added.
13 • Support for controlling offloading behavior with the OMP_TARGET_OFFLOAD environment
14 variable was added (see Section 6.17).
15 • Stubs for Runtime Library Routines (previously Appendix A) were moved to a separate
16 document.
17 • Interface Declarations (previously Appendix B) were moved to a separate document.

19 • Support for several features of Fortran 2003 was added (see Section 1.7).
20 • A parameter was added to the ordered clause of the worksharing-loop construct (see
21 Section 2.11.4) and clauses were added to the ordered construct (see Section 2.19.9) to
22 support doacross loop nests and use of the simd construct on loops with loop-carried backward
23 dependences.
24 • The linear clause was added to the worksharing-loop construct (see Section 2.11.4).
25 • The simdlen clause was added to the simd construct (see Section 2.11.5.1) to support
26 specification of the exact number of iterations desired per SIMD chunk.
27 • The priority clause was added to the task construct (see Section 2.12.1) to support hints
28 that specify the relative execution priority of explicit tasks. The
29 omp_get_max_task_priority routine was added to return the maximum supported
30 priority value (see Section 3.5.1) and the OMP_MAX_TASK_PRIORITY environment variable
31 was added to control the maximum priority value allowed (see Section 6.16).
32 • Taskloop constructs (see Section 2.12.2 and Section 2.12.3) were added to support nestable
33 parallel loops that create OpenMP tasks.

1 • To support interaction with native device implementations, the use_device_ptr clause was
2 added to the target data construct (see Section 2.14.2) and the is_device_ptr clause
3 was added to the target construct (see Section 2.14.5).
4 • To support unstructured data mapping for devices, the target enter data (see
5 Section 2.14.3) and target exit data (see Section 2.14.4) constructs were added and the
6 map clause (see Section 2.21.7.1) was updated.
7 • The nowait and depend clauses were added to the target construct (see Section 2.14.5) to
8 improve support for asynchronous execution of target regions.
9 • The private, firstprivate and defaultmap clauses were added to the target
10 construct (see Section 2.14.5).
11 • The declare target directive was extended to allow mapping of global variables to be
12 deferred to specific device executions and to allow an extended-list to be specified in C/C++ (see
13 Section 2.14.7).
14 • To support a more complete set of device construct shortcuts, the target parallel (see
15 Section 2.16.16), target parallel worksharing-loop (see Section 2.16.17), target parallel
16 worksharing-loop SIMD (see Section 2.16.18), and target simd (see Section 2.16.20),
17 combined constructs were added.
18 • The if clause was extended to take a directive-name-modifier that allows it to apply to combined
19 constructs (see Section 2.18).
20 • The hint clause was added to the critical construct (see Section 2.19.1).
21 • The source and sink dependence types were added to the depend clause (see
22 Section 2.19.11) to support doacross loop nests.
23 • The implicit data-sharing attribute for scalar variables in target regions was changed to
24 firstprivate (see Section 2.21.1.1).
25 • Use of some C++ reference types was allowed in some data sharing attribute clauses (see
26 Section 2.21.4).
27 • The ref, val, and uval modifiers were added to the linear clause (see Section 2.21.4.6).
28 • Semantics for reductions on C/C++ array sections were added and restrictions on the use of
29 arrays and pointers in reductions were removed (see Section 2.21.5.4).
30 • Support was added to the map clauses to handle structure elements (see Section 2.21.7.1).
31 • Query functions for OpenMP thread affinity were added (see Section 3.3.2 to Section 3.3.7).
32 • Device memory routines were added to allow explicit allocation, deallocation, memory transfers
33 and memory associations (see Section 3.8).
34 • The lock API was extended with lock routines that support storing a hint with a lock to select a
35 desired lock implementation for a lock’s intended usage by the application code (see

1 Section 3.9.2).
2 • C/C++ Grammar (previously Appendix B) was moved to a separate document.

4 • Various changes throughout the specification were made to provide initial support of Fortran
5 2003 (see Section 1.7).
6 • C/C++ array syntax was extended to support array sections (see Section 2.1.5).
7 • The proc_bind clause (see Section 2.6.2), the OMP_PLACES environment variable (see
8 Section 6.5), and the omp_get_proc_bind runtime routine (see Section 3.3.1) were added to
9 support thread affinity policies.
10 • SIMD directives were added to support SIMD parallelism (see Section 2.11.5).
11 • Implementation defined task scheduling points for untied tasks were removed (see
12 Section 2.12.6).
13 • Device directives (see Section 2.14), the OMP_DEFAULT_DEVICE environment variable (see
14 Section 6.15), and the omp_set_default_device, omp_get_default_device,
15 omp_get_num_devices, omp_get_num_teams, omp_get_team_num, and
16 omp_is_initial_device routines were added to support execution on devices.
17 • The taskgroup construct (see Section 2.19.6) was added to support more flexible deep task
18 synchronization.
19 • The atomic construct (see Section 2.19.7) was extended to support atomic swap with the
20 capture clause, to allow new atomic update and capture forms, and to support sequentially
21 consistent atomic operations with a new seq_cst clause.
22 • The depend clause (see Section 2.19.11) was added to support task dependences.
23 • The cancel construct (see Section 2.20.1), the cancellation point construct (see
24 Section 2.20.2), the omp_get_cancellation runtime routine (see Section 3.2.8) and the
25 OMP_CANCELLATION environment variable (see Section 6.11) were added to support the
26 concept of cancellation.
27 • The reduction clause (see Section 2.21.5.4) was extended and the declare reduction
28 construct (see Section 2.21.5.7) was added to support user defined reductions.
29 • The OMP_DISPLAY_ENV environment variable (see Section 6.12) was added to display the
30 value of ICVs associated with the OpenMP environment variables.
31 • Examples (previously Appendix A) were moved to a separate document.

2 • The bind-var ICV (see Section 2.4.1) and the OMP_PROC_BIND environment variable (see
3 Section 6.4) were added to support control of whether threads are bound to processors.
4 • The nthreads-var ICV was modified to be a list of the number of threads to use at each nested
5 parallel region level and the algorithm for determining the number of threads used in a parallel
6 region was modified to handle a list (see Section 2.6.1).
7 • The final and mergeable clauses (see Section 2.12.1) were added to the task construct to
8 support optimization of task data environments.
9 • The taskyield construct (see Section 2.12.4) was added to allow user-defined task scheduling
10 points.
11 • The atomic construct (see Section 2.19.7) was extended to include read, write, and
12 capture forms, and an update clause was added to apply the already existing form of the
13 atomic construct.
14 • Data environment restrictions were changed to allow intent(in) and const-qualified types
15 for the firstprivate clause (see Section 2.21.4.4).
16 • Data environment restrictions were changed to allow Fortran pointers in firstprivate (see
17 Section 2.21.4.4) and lastprivate (see Section 2.21.4.5).
18 • New reduction operators min and max were added for C and C++ (see Section 2.21.5).
19 • The nesting restrictions in Section 2.22 were clarified to disallow closely-nested OpenMP
20 regions within an atomic region so that an atomic region can be consistently defined with
21 other OpenMP regions to include all code in the atomic construct.
22 • The omp_in_final runtime library routine (see Section 3.5.2) was added to support
23 specialization of final task regions.
24 • Descriptions of examples (previously Appendix A) were expanded and clarified.
25 • Incorrect use of omp_integer_kind in Fortran interfaces was replaced with
26 selected_int_kind(8).

28 • The definition of active parallel region was changed so that a parallel region is active if
29 it is executed by a team that consists of more than one thread (see Section 1.2.2).
30 • The concept of tasks was added to the OpenMP execution model (see Section 1.2.5 and
31 Section 1.3).
32 • The OpenMP memory model was extended to cover atomicity of memory accesses (see
33 Section 1.4.1). The description of the behavior of volatile in terms of flush was removed.

1 • The definition of the nest-var, dyn-var, nthreads-var and run-sched-var internal control variables
2 (ICVs) were modified to provide one copy of these ICVs per task instead of one copy for the
3 whole program (see Section 2.4). The omp_set_num_threads, omp_set_nested and
4 omp_set_dynamic runtime library routines were specified to support their use from inside a
5 parallel region (see Section 3.2.1, Section 3.2.6 and Section 3.2.9).
6 • The thread-limit-var ICV, the omp_get_thread_limit runtime library routine and the
7 OMP_THREAD_LIMIT environment variable were added to support control of the maximum
8 number of threads that participate in the OpenMP program (see Section 2.4.1, Section 3.2.13 and
9 Section 6.10).
10 • The max-active-levels-var ICV, the omp_set_max_active_levels and
11 omp_get_max_active_levels runtime library routine and the
12 OMP_MAX_ACTIVE_LEVELS environment variable and were added to support control of the
13 number of nested active parallel regions (see Section 2.4.1, Section 3.2.15, Section 3.2.16
14 and Section 6.8).
15 • The stacksize-var ICV and the OMP_STACKSIZE environment variable were added to support
16 control of the stack size for threads that the OpenMP implementation creates (see Section 2.4.1
17 and Section 6.6).
18 • The wait-policy-var ICV and the OMP_WAIT_POLICY environment variable were added to
19 control the desired behavior of waiting threads (see Section 2.4.1 and Section 6.7).
20 • The rules for determining the number of threads used in a parallel region were modified (see
21 Section 2.6.1).
22 • The assignment of iterations to threads in a loop construct with a static schedule kind was
23 made deterministic (see Section 2.11.4).
24 • The worksharing-loop construct was extended to support association with more than one
25 perfectly nested loop through the collapse clause (see Section 2.11.4).
26 • Iteration variables for worksharing-loops were allowed to be random access iterators or of
27 unsigned integer type (see Section 2.11.4).
28 • The schedule kind auto was added to allow the implementation to choose any possible mapping
29 of iterations in a loop construct to threads in the team (see Section 2.11.4).
30 • The task construct (see Section 2.12) was added to support explicit tasks.
31 • The taskwait construct (see Section 2.19.5) was added to support task synchronization.
32 • Predetermined data-sharing attributes were defined for Fortran assumed-size arrays (see
33 Section 2.21.1.1).
34 • Static class members variables were allowed to appear in a threadprivate directive (see
35 Section 2.21.2).

1 • Invocations of constructors and destructors for private and threadprivate class type variables was
2 clarified (see Section 2.21.2, Section 2.21.4.3, Section 2.21.4.4, Section 2.21.6.1 and
3 Section 2.21.6.2).
4 • The use of Fortran allocatable arrays was allowed in private, firstprivate,
5 lastprivate, reduction, copyin and copyprivate clauses (see Section 2.21.2,
6 Section 2.21.4.3, Section 2.21.4.4, Section 2.21.4.5, Section 2.21.5.4, Section 2.21.6.1 and
7 Section 2.21.6.2).
8 • The firstprivate argument was added for the default clause in Fortran (see
9 Section 2.21.4.1).
10 • Implementations were precluded from using the storage of the original list item to hold the new
11 list item on the primary thread for list items in the private clause and the value was made well
12 defined on exit from the parallel region if no attempt is made to reference the original list
13 item inside the parallel region (see Section 2.21.4.3).
14 • The runtime library routines omp_set_schedule and omp_get_schedule were added to
15 set and to retrieve the value of the run-sched-var ICV (see Section 3.2.11 and Section 3.2.12).
16 • The omp_get_level runtime library routine was added to return the number of nested
17 parallel regions that enclose the task that contains the call (see Section 3.2.17).
18 • The omp_get_ancestor_thread_num runtime library routine was added to return the
19 thread number of the ancestor for a given nested level of the current thread, (see Section 3.2.18).
20 • The omp_get_team_size runtime library routine was added to return the size of the thread
21 team to which the ancestor belongs for a given nested level of the current thread, (see
22 Section 3.2.19).
23 • The omp_get_active_level runtime library routine was added to return the number of
24 nested active parallel regions that enclose the task that contains the call (see Section 3.2.20).
25 • Lock ownership was defined in terms of tasks instead of threads (see Section 3.9).

Index
Symbols data copying, 341

_OPENMP macro, 52, 648–650 data-sharing, 315
default, 315
A defaultmap, 357
acquire flush, 29 depend, 288
affinity, 98 firstprivate, 318
allocate, 181, 184 hint, 293
array sections, 46 if Clause, 254
array shaping, 45 in_reduction, 335
assume, 86 lastprivate, 321
atomic, 266 linear, 323
atomic construct, 661 map, 347
attribute clauses, 315 private, 318
attributes, data-mapping, 345 reduction, 332
attributes, data-sharing, 302 schedule, 128
auto, 130 shared, 316
task_reduction, 335
B combined constructs, 221
barrier, 258 masked taskloop, 228
barrier, implicit, 260 masked taskloop simd, 229
parallel loop, 222
C
parallel masked, 226
cancel, 295
parallel masked taskloop, 230
cancellation constructs, 295
parallel masked taskloop simd,
cancel, 295
231
cancellation point, 300
parallel sections, 223
cancellation point, 300
parallel workshare, 224
canonical loop nest form, 117
parallel worksharing-loop construct,
capture, atomic, 266
221
clauses
parallel worksharing-loop SIMD
allocate, 184
construct, 225
attribute data-sharing, 315
target parallel, 238
collapse, 128
target parallel loop, 242
copyin, 342
target parallel worksharing-loop
copyprivate, 343
construct, 239
681
target parallel worksharing-loop SIMD distribute parallel for simd,
construct, 241 149
target simd, 244 distribute parallel worksharing-loop
target teams, 245 construct, 148
target teams distribute, 246 distribute parallel worksharing-loop
target teams distribute parallel SIMD construct, 149
worksharing-loop construct, 249 distribute simd, 147
target teams distribute parallel do Fortran, 126
worksharing-loop SIMD construct, flush, 275
251 for, C/C++, 126
target teams distribute simd, interop, 217
247 loop, 151
target teams loop construct, 248 masked, 104
teams distribute, 233 masked taskloop, 228
teams distribute parallel masked taskloop simd, 229
worksharing-loop construct, 235 ordered, 283
teams distribute parallel parallel, 92
worksharing-loop SIMD construct, parallel do Fortran, 221
236 parallel for C/C++, 221
teams distribute simd, 234 parallel loop, 222
teams loop, 237 parallel masked, 226
compare, atomic, 266 parallel masked taskloop, 230
compilation sentinels, 52, 53 parallel masked taskloop simd,
compliance, 33 231
conditional compilation, 52 parallel sections, 223
consistent loop schedules, 125 parallel workshare, 224
constructs parallel worksharing-loop construct,
atomic, 266 221
barrier, 258 parallel worksharing-loop SIMD
cancel, 295 construct, 225
cancellation constructs, 295 scope, 106
cancellation point, 300 sections, 109
combined constructs, 221 simd, 134
critical, 255 single, 112
declare mapper, 358 target, 197
depobj, 287 target data, 187
device constructs, 186 target enter data, 191
dispatch, 69 target exit data, 193
distribute, 143 target parallel, 238
distribute parallel do, 148 target parallel do, 239
distribute parallel do simd, target parallel do simd, 241
149 target parallel for, 239
distribute parallel for, 148 target parallel for simd, 241

target parallel loop, 242 D
target parallel worksharing-loop data copying clauses, 341
construct, 239 data environment, 302
target parallel worksharing-loop SIMD data terminology, 14
construct, 241 data-mapping rules and clauses, 345
target simd, 244 data-sharing attribute clauses, 315
target teams, 245 data-sharing attribute rules, 302
target teams distribute, 246 declare mapper, 358
target teams distribute parallel declare reduction, 336
worksharing-loop construct, 249 declare simd, 140
target teams distribute parallel Declare Target, 210
worksharing-loop SIMD construct, declare variant, 63
251 default, 315
target teams distribute simd, defaultmap, 357
247 depend, 288
target teams loop, 248 depend object, 286
target update, 205 depobj, 287
task, 161 deprecated features, 667
taskgroup, 264 device constructs
tasking constructs, 161 declare mapper, 358
taskloop, 166 device constructs, 186
taskloop simd, 171 distribute, 143
taskwait, 261 distribute parallel worksharing-loop
taskyield, 173 construct, 148
teams, 100 distribute parallel worksharing-loop
teams distribute, 233 SIMD construct, 149
teams distribute parallel distribute simd, 147
worksharing-loop construct, 235 target, 197
teams distribute parallel target update, 205
worksharing-loop SIMD construct, teams, 100
236 device data environments, 26, 191, 193
teams distribute simd, 234 device directives, 186
teams loop, 237 device information routines, 407
tile, 158 device memory routines, 412
unroll, 160 directive format, 38
workshare, 114 directives, 37
worksharing, 108 allocate, 181
worksharing-loop construct, 126 assume, 86
worksharing-loop SIMD construct, 138 declare mapper, 358
controlling OpenMP thread affinity, 98 declare reduction, 336
copyin, 342 declare simd, 140
copyprivate, 343 Declare Target, 210
critical, 255 declare variant, 63
Index 683
error, 90 OMP_TOOL_LIBRARIES, 653
memory management directives, 177 OMP_TOOL_VERBOSE_INIT, 654
metadirective, 60 OMP_WAIT_POLICY, 646
nothing, 89 event, 443
requires, 83 event callback registration, 476
scan Directive, 154 event callback signatures, 510
threadprivate, 307 event routines, 443
variant directives, 53 execution model, 22
dispatch, 69
distribute, 143 F
distribute parallel worksharing-loop features history, 667
construct, 148 firstprivate, 318
distribute parallel worksharing-loop SIMD fixed source form conditional compilation
construct, 149 sentinels, 52
distribute simd, 147 fixed source form directives, 43
do, Fortran, 126 flush, 275
do simd, 138 flush operation, 27
dynamic, 129 flush synchronization, 29
dynamic thread adjustment, 660 flush-set, 27
for, C/C++, 126
E for simd, 138
environment display routine, 468 frames, 505
environment variables, 639 free source form conditional compilation
OMP_AFFINITY_FORMAT, 650 sentinel, 53
OMP_ALLOCATOR, 655 free source form directives, 44
OMP_CANCELLATION, 648
OMP_DEBUG, 655 G
OMP_DEFAULT_DEVICE, 652 glossary, 2
OMP_DISPLAY_AFFINITY, 649 guided, 129
OMP_DISPLAY_ENV, 648
OMP_DYNAMIC, 641 H
OMP_MAX_ACTIVE_LEVELS, 647 happens before, 29
OMP_MAX_TASK_PRIORITY, 652 header files, 365
OMP_NESTED, 647 history of features, 667
OMP_NUM_TEAMS, 656
I
OMP_NUM_THREADS, 640
ICVs (internal control variables), 71
OMP_PLACES, 643
if Clause, 254
OMP_PROC_BIND, 642
implementation, 659
OMP_SCHEDULE, 640
implementation terminology, 18
OMP_STACKSIZE, 645
implicit barrier, 260
OMP_TARGET_OFFLOAD, 652
implicit flushes, 279
OMP_TEAMS_THREAD_LIMIT, 657
in_reduction, 335
OMP_THREAD_LIMIT, 648
include files, 365
OMP_TOOL, 653

informational and utility directives, 83 omp_calloc, 461
internal control variables, 659 OMP_CANCELLATION, 648
internal control variables (ICVs), 71 omp_capture_affinity, 396
interoperability, 216 OMP_DEBUG, 655
Interoperability routines, 444 OMP_DEFAULT_DEVICE, 652
introduction, 1 omp_destroy_allocator, 455
iterators, 49 omp_destroy_lock, 436
omp_destroy_nest_lock, 436
L OMP_DISPLAY_AFFINITY, 649
lastprivate, 321 omp_display_affinity, 395
linear, 323 OMP_DISPLAY_ENV, 648
list item privatization, 312 omp_display_env, 468
lock routines, 432 OMP_DYNAMIC, 641
loop, 151 omp_free, 459
loop terminology, 9 omp_fulfill_event, 443
loop transformation constructs, 157 omp_get_active_level, 385
omp_get_affinity_format, 394
M omp_get_ancestor_thread_num, 384
map, 347 omp_get_cancellation, 374
masked, 104 omp_get_default_allocator, 457
masked taskloop, 228 omp_get_default_device, 408
masked taskloop simd, 229 omp_get_device_num, 410
memory allocators, 178 omp_get_dynamic, 373
memory management, 177 omp_get_initial_device, 411
memory management directives omp_get_interop_int, 446
memory management directives, 177 omp_get_interop_name, 449
memory management routines, 451 omp_get_interop_ptr, 447
memory model, 25 omp_get_interop_rc_desc, 450
memory spaces, 177 omp_get_interop_str, 448
metadirective, 60 omp_get_interop_type_desc, 450
modifying and retrieving ICV values, 77 omp_get_level, 383
modifying ICVs, 74 omp_get_mapped_ptr, 430
omp_get_max_active_levels, 382
N
omp_get_max_task_priority, 402
nesting of regions, 362
omp_get_max_teams, 400
normative references, 33
omp_get_max_threads, 370
nothing, 89
omp_get_nested, 376
O omp_get_num_devices, 409
OMP_AFFINITY_FORMAT, 650 omp_get_num_interop_properties,
omp_aligned_alloc, 458 446
omp_aligned_calloc, 461 omp_get_num_places, 388
omp_alloc, 458 omp_get_num_procs, 407
OMP_ALLOCATOR, 655 omp_get_num_teams, 397
Index 685
omp_get_num_threads, 369 omp_set_nested, 375
omp_get_partition_num_places, omp_set_num_teams, 399
391 omp_set_num_threads, 368
omp_get_partition_place_nums, omp_set_schedule, 376
392 omp_set_teams_thread_limit, 400
omp_get_place_num, 390 OMP_STACKSIZE, 645
omp_get_place_num_procs, 389 omp_target_alloc, 412
omp_get_place_proc_ids, 389 omp_target_associate_ptr, 426
omp_get_proc_bind, 386 omp_target_disassociate_ptr, 429
omp_get_schedule, 379 omp_target_free, 414
omp_get_supported_active omp_target_is_accessible, 417
_levels, 380 omp_target_is_present, 416
omp_get_team_num, 398 omp_target_memcpy, 418
omp_get_team_size, 385 omp_target_memcpy_async, 422
omp_get_teams_thread_limit, 401 omp_target_memcpy_rect, 419
omp_get_thread_limit, 380 omp_target_memcpy_rect_async,
omp_get_thread_num, 371 424
omp_get_wtick, 442 OMP_TARGET_OFFLOAD, 652
omp_get_wtime, 442 OMP_TEAMS_THREAD_LIMIT, 657
omp_in_final, 403 omp_test_lock, 440
omp_in_parallel, 372 omp_test_nest_lock, 440
omp_init_allocator, 454 OMP_THREAD_LIMIT, 648
omp_init_lock, 434, 435 OMP_TOOL, 653
omp_init_nest_lock, 434, 435 OMP_TOOL_LIBRARIES, 653
omp_is_initial_device, 411 OMP_TOOL_VERBOSE_INIT, 654
OMP_MAX_ACTIVE_LEVELS, 647 omp_unset_lock, 439
OMP_MAX_TASK_PRIORITY, 652 omp_unset_nest_lock, 439
OMP_NESTED, 647 OMP_WAIT_POLICY, 646
OMP_NUM_TEAMS, 656 ompd_bp_device_begin, 636
OMP_NUM_THREADS, 640 ompd_bp_device_end, 636
omp_pause_resource, 404 ompd_bp_parallel_begin, 633
omp_pause_resource_all, 406 ompd_bp_parallel_end, 633
OMP_PLACES, 643 ompd_bp_task_begin, 634
OMP_PROC_BIND, 642 ompd_bp_task_end, 634
omp_realloc, 463 ompd_bp_thread_begin, 635
OMP_SCHEDULE, 640 ompd_bp_thread_end, 635
omp_set_affinity_format, 393 ompd_callback_device_host
omp_set_default_allocator, 456 _fn_t, 596
omp_set_default_device, 408 ompd_callback_get_thread
omp_set_dynamic, 373 _context_for_thread_id
omp_set_lock, 437 _fn_t, 590
omp_set_max_active_levels, 381 ompd_callback_memory_alloc
omp_set_nest_lock, 437 _fn_t, 588

ompd_callback_memory_free _unload_t, 533
_fn_t, 589 ompt_callback_target_data
ompd_callback_memory_read _emi_op_t, 535
_fn_t, 594 ompt_callback_target_data
ompd_callback_memory_write _op_t, 535
_fn_t, 595 ompt_callback_target_emi_t, 538
ompd_callback_print_string ompt_callback_target
_fn_t, 598 _map_emi_t, 540
ompd_callback_sizeof_fn_t, 591 ompt_callback_target_map_t, 540
ompd_callback_symbol_addr ompt_callback_target
_fn_t, 592 _submit_emi_t, 542
ompd_callbacks_t, 598 ompt_callback_target
ompd_dll_locations_valid, 579 _submit_t, 542
ompd_dll_locations, 578 ompt_callback_target_t, 538
ompt_callback_buffer ompt_callback_task_create_t, 517
_complete_t, 534 ompt_callback_task
ompt_callback_buffer _dependence_t, 519
_request_t, 533 ompt_callback_task
ompt_callback_cancel_t, 529 _schedule_t, 520
ompt_callback_control ompt_callback_thread
_tool_t, 544 _begin_t, 510
ompt_callback_dependences_t, 518 ompt_callback_thread_end_t, 511
ompt_callback_dispatch_t, 515 ompt_callback_work_t, 514
ompt_callback_error_t, 545 OpenMP compliance, 33
ompt_callback_device order clause, 125
_finalize_t, 531 ordered, 283
ompt_callback_device
_initialize_t, 530 P
ompt_callback_flush_t, 528 parallel, 92
ompt_callback_implicit parallel loop, 222
_task_t, 521 parallel masked construct, 226
ompt_callback_masked_t, 522 parallel masked taskloop, 230
ompt_callback_mutex parallel masked taskloop simd, 231
_acquire_t, 525 parallel sections, 223
ompt_callback_mutex_t, 526 parallel workshare, 224
ompt_callback_nest_lock_t, 527 parallel worksharing-loop construct, 221
ompt_callback_parallel parallel worksharing-loop SIMD
_begin_t, 511 construct, 225
ompt_callback_parallel private, 318
_end_t, 513
ompt_callback_sync_region_t, 523 R
ompt_callback_device_load_t, 532 read, atomic, 266
ompt_callback_device reduction, 332
reduction clauses, 325
Index 687
release flush, 29 target teams loop, 248
requires, 83 target update, 205
resource relinquishing routines, 404 task, 161
runtime, 130 task scheduling, 175
runtime library definitions, 365 task_reduction, 335
runtime library routines, 365 taskgroup, 264
tasking constructs, 161
S tasking routines, 402
scan Directive, 154 tasking terminology, 12
scheduling, 175 taskloop, 166
scope, 106 taskloop simd, 171
sections, 109 taskwait, 261
shared, 316 taskyield, 173
simd, 134 teams, 100
SIMD Directives, 134 teams distribute, 233
Simple Lock Routines, 432 teams distribute parallel worksharing-loop
single, 112 construct, 235
stand-alone directives, 45 teams distribute parallel worksharing-loop
static, 129 SIMD construct, 236
strong flush, 27 teams distribute simd, 234
synchronization constructs, 255 teams loop, 237
synchronization constructs and clauses, 255 teams region routines, 397
synchronization hints, 293 thread affinity, 98
synchronization terminology, 10 thread affinity routines, 386
thread team routines, 368
T threadprivate, 307
target, 197 tile, 158
target data, 187 timer, 442
target memory routines, 412 timing routines, 442
target parallel, 238 tool control, 465
target parallel loop, 242 tool initialization, 474
target parallel worksharing-loop tool interfaces definitions, 471, 578
construct, 239 tools header files, 471, 578
target parallel worksharing-loop SIMD tracing device activity, 478
construct, 241
target simd, 244 U
target teams, 245 unroll, 160
target teams distribute, 246 update, atomic, 266
target teams distribute parallel
V
worksharing-loop construct, 249
variables, environment, 639
target teams distribute parallel
variant directives, 53
worksharing-loop SIMD
construct, 251 W
target teams distribute simd, 247 wait identifier, 507

wall clock timer, 442
error, 90
workshare, 114
worksharing
constructs, 108
parallel, 221
scheduling, 133
worksharing constructs, 108
worksharing-loop construct, 126
worksharing-loop SIMD construct, 138
write, atomic, 266
Index 689

OpenMP API Specification 5 1

Uploaded by

Copyright:

Available Formats

OpenMP API Specification 5 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OpenMP API Specification 5 1

Uploaded by

Copyright:

Available Formats

OpenMP

Version 5.1 November 2020

1 Overview of the OpenMP API 1

ii OpenMP API – Version 5.1 November 2020

iv OpenMP API – Version 5.1 November 2020

3 Runtime Library Routines 365

vi OpenMP API – Version 5.1 November 2020

viii OpenMP API – Version 5.1 November 2020

x OpenMP API – Version 5.1 November 2020

xii OpenMP API – Version 5.1 November 2020

5 OMPD Interface 577

xiv OpenMP API – Version 5.1 November 2020

6 Environment Variables 639

xvi OpenMP API – Version 5.1 November 2020

A OpenMP Implementation-Defined Behaviors 659

B Features History 667

4.1 First-Party Tool Activation Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . 473

3.1 Required Values of the omp_interop_property_t enum Type . . . . . . . . 445

5.1 Mapping of Scope Type and OMPD Handles . . . . . . . . . . . . . . . . . . . . 584

6.1 Predefined Abstract Names for OMP_PLACES . . . . . . . . . . . . . . . . . . . . 644

3 thread An execution entity with a stack and associated threadprivate memory.

20 1.2.2 OpenMP Language Terminology

2 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 3

4 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 5

6 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 7

8 OpenMP API – Version 5.1 November 2020

9 1.2.3 Loop Terminology

CHAPTER 1. OVERVIEW OF THE OPENMP API 9

17 1.2.4 Synchronization Terminology

18 barrier A point in the execution of a program encountered by a team of threads, beyond

10 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 11

12 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 13

14 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 15

15 structure A structure is a variable that contains one or more variables.

16 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 17

18 1.2.7 Implementation Terminology

22 nested parallelism Support of more than one active level of parallelism.

18 OpenMP API – Version 5.1 November 2020

18 1.2.8 Tool Terminology

CHAPTER 1. OVERVIEW OF THE OPENMP API 19

20 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 21

6 1.3 Execution Model

22 OpenMP API – Version 5.1 November 2020

CHAPTER 1. OVERVIEW OF THE OPENMP API 23

24 OpenMP API – Version 5.1 November 2020

8 1.4 Memory Model

CHAPTER 1. OVERVIEW OF THE OPENMP API 25

22 1.4.2 Device Data Environments

26 OpenMP API – Version 5.1 November 2020

11 1.4.3 Memory Management

24 1.4.4 The Flush Operation