A OpenMP Implementation-Deﬁned Behaviors

| OPENMP API Specification: "Version 5.2 -- GIT rev 95b2e3a44"

A. OpenMP Implementation-Deﬁned Behaviors

This appendix summarizes the behaviors that are described as implementation deﬁned in the OpenMP API. Each behavior is cross-referenced back to its description in the main speciﬁcation. An implementation is required to deﬁne and to document its behavior in these cases.

Chapter 1:

Processor: A hardware unit that is implementation deﬁned (see Section 1.2.1).
Device: An implementation-deﬁned logical execution engine (see Section 1.2.1).
Device pointer: An implementation-deﬁned handle that refers to a device address (see Section 1.2.6).
Supported active levels of parallelism: The maximum number of active parallel regions that may enclose any region of code in the program is implementation deﬁned (see Section 1.2.7).
Deprecated features: For any deprecated feature, whether any modiﬁcations provided by its replacement feature (if any) apply to the deprecated feature is implementation deﬁned (see Section 1.2.7).
Memory model: The minimum size at which a memory update may also read and write back adjacent variables that are part of another variable (as array elements or structure elements) is implementation deﬁned but is no larger than the base language requires. The manner in which a program can obtain the referenced device address from a device pointer, outside the mechanisms speciﬁed by OpenMP, is implementation deﬁned (see Section 1.4.1).

Chapter 2:

Internal control variables: The initial values of dyn-var, nthreads-var, run-sched-var, bind-var, stacksize-var, wait-policy-var, thread-limit-var, max-active-levels-var, place-partition-var, aﬃnity-format-var, default-device-var, num-procs-var and def-allocator-var are implementation deﬁned (see Section 2.2).

Chapter 3:

A pragma directive that uses ompx as the ﬁrst processing token is implementation deﬁned (see Section 3.1).

The attribute namespace of an attribute speciﬁer or the optional namespace qualiﬁer within a sequence attribute that uses ompx is implementation deﬁned (see Section 3.1). Whether a throw executed inside a region that arises from an exception-aborting directive results in runtime error termination is implementation deﬁned (see Section 3.1).

Any directive that uses omx or ompx in the sentinel is implementation deﬁned (see Section 3.1).

Chapter 4:

Loop-iteration spaces and vectors: The particular integer type used to compute the iteration count for the collapsed loop is implementation deﬁned (see Section 4.4.2).

Chapter 5:

Data-sharing attributes: The data-sharing attributes of dummy arguments that do not have the VALUE attribute are implementation deﬁned if the associated actual argument is shared unless the actual argument is a scalar variable, structure, an array that is not a pointer or assumed-shape array, or a simply contiguous array section (see Section 5.1.2). threadprivate directive: If the conditions for values of data in the threadprivate objects of threads (other than an initial thread) to persist between two consecutive active parallel regions do not all hold, the allocation status of an allocatable variable in the second region is implementation deﬁned (see Section 5.2).

is_device_ptr clause: Support for pointers created outside of the OpenMP device data management routines is implementation deﬁned (see Section 5.4.7).

Chapter 6:

Memory spaces: The actual storage resources that each memory space deﬁned in 6.1 represents are implementation deﬁned. The mechanism that provides the constant value of the variables allocated in the omp_const_mem_space memory space is implementation deﬁned (see Section 6.1).
Memory allocators: The minimum size for partitioning allocated memory over storage resources is implementation deﬁned. The default value for the pool_size allocator trait (see 6.2) is implementation deﬁned. The memory spaces associated with the predeﬁned omp_cgroup_mem_alloc, omp_pteam_mem_alloc and omp_thread_mem_alloc allocators (see 6.3) are implementation deﬁned (see Section 6.2).
aligned clause: If the alignment modiﬁer is not speciﬁed, the default alignments for SIMD instructions on the target platforms are implementation deﬁned (see Section 5.11).

Chapter 7:

OpenMP context: The accepted isa-name values for the isa trait, the accepted arch-name values for the arch trait, the accepted extension-name values for the extension trait and whether the dispatch construct is added to the construct set are implementation deﬁned (see Section 7.1).
Metadirectives: The number of times that each expression of the context selector of a when clause is evaluated is implementation deﬁned (see Section 7.4.1).
Declare variant directives: If two replacement candidates have the same score then their order is implementation deﬁned. The number of times each expression of the context selector of a match clause is evaluated is implementation deﬁned. For calls to constexpr base functions that are evaluated in constant expressions, whether any variant replacement occurs is implementation deﬁned. Any diﬀerences that the speciﬁc OpenMP context requires in the prototype of the variant from the base function prototype are implementation deﬁned (see Section 7.5).
declare simd directive: If a SIMD version is created and the simdlen clause is not speciﬁed, the number of concurrent arguments for the function is implementation deﬁned (see Section 7.7).
Declare target directives: Whether the same version is generated for diﬀerent devices, or whether a version that is called in a target region diﬀers from the version that is called outside a target region, is implementation deﬁned (see Section 7.8).

Chapter 8:

requires directive: Support for any feature speciﬁed by a requirement clause on a requires directive is implementation deﬁned (see Section 8.2).

Chapter 9:

unroll construct: If no clauses are speciﬁed, if and how the loop is unrolled is implementation deﬁned. If the partial clause is speciﬁed without an unroll-factor argument then the unroll factor is a positive integer that is implementation deﬁned (see Section 9.2).

Chapter 10:

Dynamic adjustment of threads: Providing the ability to adjust the number of threads dynamically is implementation deﬁned (see Section 10.1.1).
Thread aﬃnity: For the close thread aﬃnity policy, if T > P and P does not divide T evenly, the exact number of threads in a particular place is implementation deﬁned. For the spread thread aﬃnity, if T > P and P does not divide T evenly, the exact number of threads in a particular subpartition is implementation deﬁned. The determination of whether the aﬃnity request can be fulﬁlled is implementation deﬁned. If the aﬃnity request cannot be fulﬁlled, then the aﬃnity of threads in the team is implementation deﬁned (see Section 10.1.3).
teams construct: The number of teams that are created is implementation deﬁned, but it is greater than or equal to the lower bound and less than or equal to the upper bound values of the num_teams clause if speciﬁed. If the num_teams clause is not speciﬁed,r the number of teams is less than or equal to the value of the nteams-var ICV if its value is greater than zero. Otherwise it is an implementation deﬁned value greater than or equal to 1 (see Section 10.2).
simd construct: The number of iterations that are executed concurrently at any given time is implementation deﬁned (see Section 10.4).

Chapter 11:

single construct: The method of choosing a thread to execute the structured block each time the team encounters the construct is implementation deﬁned (see Section 11.1).
sections construct: The method of scheduling the structured block sequences among threads in the team is implementation deﬁned (see Section 11.3).
Worksharing-loop directive: The schedule that is used is implementation deﬁned if the schedule clause is not speciﬁed or if the speciﬁed schedule has the kind auto. The value of simd_width for the simd schedule modiﬁer is implementation deﬁned (see Section 11.5).
distribute construct: If no dist_schedule clause is speciﬁed then the schedule for the distribute construct is implementation deﬁned (see Section 11.6).

Chapter 12:

taskloop construct: The number of loop iterations assigned to a task created from a taskloop construct is implementation deﬁned, unless the grainsize or num_tasks clause is speciﬁed (see Section 12.6).

taskloop construct: For firstprivate variables of class type, the number of invocations of copy constructors to perform the initialization is implementation deﬁned (see Section 12.6).

Chapter 13:

thread_limit clause: The maximum number of threads that participate in the contention group that each team initiates is implementation deﬁned if no thread_limit clause is speciﬁed on the construct. Otherwise, it has the implementation deﬁned upper bound of the teams-thread-limit-var ICV, if the value of this ICV is greater than zero (see Section 13.3).

Chapter 14:

interop Construct: The foreign-runtime-id values for the prefer_type clause that the implementation supports, including non-standard names compatible with this clause, and the default choice when the implementation supports multiple values are implementation deﬁned (see Section 14.1).

Chapter 15:

atomic construct: A compliant implementation may enforce exclusive access between atomic regions that update diﬀerent storage locations. The circumstances under which this occurs are implementation deﬁned. If the storage location designated by x is not size-aligned (that is, if the byte alignment of x is not a multiple of the size of x), then the behavior of the atomic region is implementation deﬁned (see Section 15.8.4).

Chapter 16:

None.

Chapter 17:

None.

Chapter 18:

Runtime Routine names that begin with the ompx_ preﬁx are implementation-deﬁned extensions to the OpenMP Runtime API (see Chapter 18).

Runtime library deﬁnitions: The enum types for omp_allocator_handle_t, omp_event_handle_t, omp_interop_fr_t and omp_memspace_handle_t are implementation deﬁned. The integral or pointer type for omp_interop_t is implementation deﬁned. The value of the omp_invalid_device enumerator is implementation deﬁned (see Section 18.1).

Runtime library deﬁnitions: Whether the include ﬁle omp_lib.h or the module omp_lib (or both) is provided is implementation deﬁned. Whether the omp_lib.h ﬁle provides derived-type deﬁnitions or those routines that require an explicit interface is implementation deﬁned. Whether any of the OpenMP runtime library routines that take an argument are extended with a generic interface so arguments of diﬀerent KIND type can be accommodated is implementation deﬁned. The value of the omp_invalid_device named constant is implementation deﬁned (see Section 18.1).

omp_set_num_threads routine: If the argument is not a positive integer, the behavior is implementation deﬁned (see Section 18.2.1).
omp_set_schedule routine: For implementation-speciﬁc schedule kinds, the values and associated meanings of the second argument are implementation deﬁned (see Section 18.2.11).
omp_get_schedule routine: The value returned by the second argument is implementation deﬁned for any schedule kinds other than static, dynamic and guided (see Section 18.2.12).
omp_get_supported_active_levels routine: The number of active levels of parallelism supported by the implementation is implementation deﬁned, but must be positive (see Section 18.2.14).
omp_set_max_active_levels routine: If the argument is a negative integer then the behavior is implementation deﬁned. If the argument is less than the active-levels-var ICV, the max-active-levels-var ICV is set to an implementation-deﬁned value between the value of the argument and the value of active-levels-var, inclusive (see Section 18.2.15).
omp_get_place_proc_ids routine: The meaning of the non-negative numerical identiﬁers returned by the omp_get_place_proc_ids routine is implementation deﬁned. The order of the numerical identiﬁers returned in the array ids is implementation deﬁned (see Section 18.3.4).
omp_set_affinity_format routine: When called from within any parallel or teams region, the binding thread set (and binding region, if required) for the omp_set_affinity_format region and the eﬀect of this routine are implementation deﬁned (see Section 18.3.8).
omp_get_affinity_format routine: When called from within any parallel or teams region, the binding thread set (and binding region, if required) for the omp_get_affinity_format region is implementation deﬁned (see Section 18.3.9).
omp_display_affinity routine: If the format argument does not conform to the speciﬁed format then the result is implementation deﬁned (see Section 18.3.10).
omp_capture_affinity routine: If the format argument does not conform to the speciﬁed format then the result is implementation deﬁned (see Section 18.3.11).
omp_set_num_teams routine: If the argument does not evaluate to a positive integer, the behavior of this routine is implementation deﬁned (see Section 18.4.3).
omp_set_teams_thread_limit routine: If the argument is not a positive integer, the behavior is implementation deﬁned (see Section 18.4.5).
omp_pause_resource_all routine: The behavior of this routine is implementation deﬁned if the argument kind is not listed in Section 18.6.1 (see Section 18.6.2).
omp_target_memcpy_rect and omp_target_memcpy_rect_async routines: The maximum number of dimensions supported is implementation deﬁned, but must be at least three (see Section 18.8.6 and Section 18.8.8).
Lock routines: If a lock contains a synchronization hint, the eﬀect of the hint is implementation deﬁned (see Section 18.9).
Interoperability routines: Implementation-deﬁned properties may use zero and positive values for properties associated with an omp_interop_t object (see Section 18.12).

Chapter 19:

Tool callbacks: If a tool attempts to register a callback listed in Table 19.3), whether the registered callback may never, sometimes or always invoke this callback for the associated events is implementation deﬁned (see Section 19.2.4).
Device tracing: Whether a target device supports tracing or not is implementation deﬁned; if a target device does not support tracing, a NULL may be supplied for the lookup function to the device initializer of a tool (see Section 19.2.5).
ompt_set_trace_ompt and ompt_get_record_ompt runtime entry points: Whether a device-speciﬁc tracing interface deﬁnes this runtime entry point, indicating that it can collect traces in OMPT format, is implementation deﬁned. The kinds of trace records available for a device is implementation deﬁned (see Section 19.2.5).
Native record abstract type: The meaning of a hwid value for a device is implementation deﬁned (see Section 19.4.3.3).
ompt_dispatch_chunk_t type: Whether the chunk of a taskloop is contiguous is implementation deﬁned (see Section 19.4.4.13).
ompt_record_abstract_t type: The set of OMPT thread states supported is implementation deﬁned (see Section 19.4.4.28).
ompt_callback_sync_region_t callback type: For the implicit-barrier-wait-begin and implicit-barrier-wait-end events at the end of a parallel region, whether the parallel_data argument is NULL or points to the parallel data of the current parallel region is implementation deﬁned (see Section 19.5.2.13).
ompt_callback_target_data_op_emi_t and ompt_callback_target_data_op_t callback types: Whether in some operations src_addr or dest_addr might point to an intermediate buﬀer is implementation deﬁned (see Section 19.5.2.25).
ompt_get_place_proc_ids_t entry point type: The meaning of the numerical identiﬁers returned is implementation deﬁned. The order of ids returned in the array is implementation deﬁned (see Section 19.6.1.8).
ompt_get_partition_place_nums_t entry point type: The order of the identiﬁers returned in the array place_nums is implementation deﬁned (see Section 19.6.1.10).
ompt_get_proc_id_t entry point type: The meaning of the numerical identiﬁer returned is implementation deﬁned (see Section 19.6.1.11).

Chapter 20:

ompd_callback_print_string_fn_t callback type: The value of category is implementation deﬁned (see Section 20.4.5).
ompd_parallel_handle_compare operation: The means by which parallel region handles are ordered is implementation deﬁned (see Section 20.5.6.5).
ompd_task_handle_compare operation: The means by which task handles are ordered is implementation deﬁned (see Section 20.5.7.6).

Chapter 21:

OMP_DYNAMIC environment variable: If the value is neither true nor false, the behavior of the program is implementation deﬁned (see Section 21.1.1).
OMP_NUM_THREADS environment variable: If any value of the list speciﬁed leads to a number of threads that is greater than the implementation can support, or if any value is not a positive integer, then the behavior of the program is implementation deﬁned (see Section 21.1.2).
OMP_THREAD_LIMIT environment variable: If the requested value is greater than the number of threads an implementation can support, or if the value is not a positive integer, the behavior of the program is implementation deﬁned (see Section 21.1.3).
OMP_MAX_ACTIVE_LEVELS environment variable: If the value is a negative integer or is greater than the maximum number of nested active parallel levels that an implementation can support then the behavior of the program is implementation deﬁned (see Section 21.1.4).
OMP_NESTED environment variable (deprecated): If the value is neither true nor false, the behavior of the program is implementation deﬁned (see Section 21.1.5).
Conﬂicting OMP_NESTED (deprecated) and OMP_MAX_ACTIVE_LEVELS environment variables: If both environment variables are set, the value of OMP_NESTED is false, and the value of OMP_MAX_ACTIVE_LEVELS is greater than 1, then the behavior is implementation deﬁned (see Section 21.1.5).
OMP_PLACES environment variable: The meaning of the numbers speciﬁed in the environment variable and how the numbering is done are implementation deﬁned. The precise deﬁnitions of the abstract names are implementation deﬁned. An implementation may add implementation-deﬁned abstract names as appropriate for the target platform. When creating a place list of n elements by appending the number n to an abstract name, the determination of which resources to include in the place list is implementation deﬁned. When requesting more resources than available, the length of the place list is also implementation deﬁned. The behavior of the program is implementation deﬁned when the execution environment cannot map a numerical value (either explicitly deﬁned or implicitly derived from an interval) within the OMP_PLACES list to a processor on the target platform, or if it maps to an unavailable processor. The behavior is also implementation deﬁned when the OMP_PLACES environment variable is deﬁned using an abstract name (see Section 21.1.6).
OMP_PROC_BIND environment variable: If the value is not true, false, or a comma separated list of primary (master has been deprecated), close, or spread, the behavior is implementation deﬁned. The behavior is also implementation deﬁned if an initial thread cannot be bound to the ﬁrst place in the OpenMP place list. The thread aﬃnity policy is implementation deﬁned if the value is true (see Section 21.1.7).
OMP_SCHEDULE environment variable: If the value does not conform to the speciﬁed format then the behavior of the program is implementation deﬁned (see Section 21.2.1).
OMP_STACKSIZE environment variable: If the value does not conform to the speciﬁed format or the implementation cannot provide a stack of the speciﬁed size then the behavior is implementation deﬁned (see Section 21.2.2).
OMP_WAIT_POLICY environment variable: The details of the active and passive behaviors are implementation deﬁned (see Section 21.2.3).
OMP_DISPLAY_AFFINITY environment variable: For all values of the environment variables other than true or false, the display action is implementation deﬁned (see Section 21.2.4).
OMP_AFFINITY_FORMAT environment variable: Additional implementation-deﬁned ﬁeld types can be added (see Section 21.2.5).
OMP_CANCELLATION environment variable: If the value is set to neither true nor false, the behavior of the program is implementation deﬁned (see Section 21.2.6).
OMP_TARGET_OFFLOAD environment variable: The support of disabled is implementation deﬁned (see Section 21.2.8).
OMP_TOOL_LIBRARIES environment variable: Whether the value of the environment variable is case sensitive is implementation deﬁned (see Section 21.3.2).
OMP_TOOL_VERBOSE_INIT environment variable: Support for logging to stdout or stderr is implementation deﬁned. Whether the value of the environment variable is case sensitive when it is treated as a ﬁlename is implementation deﬁned. The format and detail of the log is implementation deﬁned (see Section 21.3.3).
OMP_DEBUG environment variable: If the value is neither disabled nor enabled, the behavior is implementation deﬁned (see Section 21.4.1).
OMP_NUM_TEAMS environment variable: If the value is not a positive integer or is greater than the number of teams that an implementation can support, the behavior of the program is implementation deﬁned (see Section 21.6.1).
OMP_TEAMS_THREAD_LIMIT environment variable: If the value is not a positive integer or is greater than the number of threads that an implementation can support, the behavior of the program is implementation deﬁned (see Section 21.6.2).

[next] [prev] [prev-tail] [front] [up]