A OpenMP Implementation-Defined Behaviors

| OPENMP API Specification: Version 5.1 November 2020

A. OpenMP Implementation-Defined Behaviors

This appendix summarizes the behaviors that are described as implementation defined in this API. Each behavior is cross-referenced back to its description in the main specification. An implementation is required to define and to document its behavior in these cases.

Chapter 1:

Processor: A hardware unit that is implementation defined (see Section 1.2.1).
Device: An implementation defined logical execution engine (see Section 1.2.1).
Device pointer: an implementation defined 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 defined (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 or structure elements) is implementation defined but is no larger than required by the base language. The manner in which a program can obtain the referenced device address from a device pointer, outside the mechanisms specified by OpenMP, is implementation defined (see Section 1.4.1).

Chapter 2:

OpenMP context: Whether the dispatch construct is added to the construct set, the accepted isa-name values for the isa trait, the accepted arch-name values for the arch trait, and the accepted extension-name values for the extension trait are implementation defined (see Section 2.3.1).
Metadirectives: The number of times that each expression of the context selector of a when clause is evaluated is implementation defined (see Section 2.3.4).
Declare variant directive: If two replacement candidates have the same score, their order is implementation defined. The number of times each expression of the context selector of a match clause is evaluated is implementation defined. For calls to constexpr base functions that are evaluated in constant expressions, whether any variant replacement occurs is implementation defined. Any differences that the specific OpenMP context requires in the prototype of the variant from the base function prototype are implementation defined (see Section 2.3.5).
Internal control variables: The initial values of dyn-var, nthreads-var, run-sched-var, def-sched-var, bind-var, stacksize-var, wait-policy-var, thread-limit-var, max-active-levels-var, place-partition-var, affinity-format-var, default-device-var, num-procs-var and def-allocator-var are implementation defined (see Section 2.4.2).
requires directive: Support for any feature specified by a requirement clause on a requires directive is implementation defined (see Section 2.5.1).
Dynamic adjustment of threads: Providing the ability to adjust the number of threads dynamically is implementation defined (see Section 2.6.1).
Thread affinity: For the close thread affinity policy, if T > P and P does not divide T evenly, the exact number of threads in a particular place is implementation defined. For the spread thread affinity, if T > P and P does not divide T evenly, the exact number of threads in a particular subpartition is implementation defined. The determination of whether the affinity request can be fulfilled is implementation defined. If not, the mapping of threads in the team to places is implementation defined (see Section 2.6.2).
teams construct: The number of teams that are created is implementation defined, 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 specified or it is less than or equal to the value of the nteams-var ICV if its value is greater than zero. Otherwise it is greater than or equal to 1. The maximum number of threads that participate in the contention group that each team initiates is implementation defined if no thread_limit clause is specified on the construct. The assignment of the initial threads to places and the values of the place-partition-var and default-device-var ICVs for each initial thread are implementation defined (see Section 2.7).
sections construct: The method of scheduling the structured blocks among threads in the team is implementation defined (see Section 2.10.1).
single construct: The method of choosing a thread to execute the structured block each time the team encounters the construct is implementation defined (see Section 2.10.2).
Canonical loop nest form: The particular integer type used to compute the iteration count for the collapsed loop is implementation defined (see Section 2.11.1).
Worksharing-loop directive: The effect of the schedule(runtime) clause when the run-sched-var ICV is set to auto is implementation defined. The value of simd_width for the simd schedule modifier is implementation defined (see Section 2.11.4).
simd construct: The number of iterations that are executed concurrently at any given time is implementation defined. If the alignment parameter is not specified in the aligned clause, the default alignments for the SIMD instructions are implementation defined (see Section 2.11.5.1).
declare simd directive: If the parameter of the simdlen clause is not a constant positive integer expression, the number of concurrent arguments for the function is implementation defined. If the alignment parameter of the aligned clause is not specified, the default alignments for SIMD instructions are implementation defined (see Section 2.11.5.3).
distribute construct: If no dist_schedule clause is specified then the schedule for the distribute construct is implementation defined (see Section 2.11.6.1).
unroll construct: If the partial clause is specified without an argument, the unroll factor is a positive integer that is implementation defined. If neither the partial nor the full clause is specified, if and how the loop is unrolled is implementation defined (see Section 2.11.9.2).
taskloop construct: The number of loop iterations assigned to a task created from a taskloop construct is implementation defined, unless the grainsize or num_tasks clause is specified (see Section 2.12.2).

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

Memory spaces: The actual storage resources that each memory space defined in Table 2.8 represents are implementation defined (see Section 2.13.1).
Memory allocators: The minimum partitioning size for partitioning of allocated memory over the storage resources is implementation defined. The default value for the pool_size allocator trait (see Table 2.9) is implementation defined. The associated memory space for each of the predefined omp_cgroup_mem_alloc, omp_pteam_mem_alloc and omp_thread_mem_alloc allocators (see Table 2.10) is implementation defined (see Section 2.13.2).
target construct: The maximum number of threads that participate in the contention group that each team initiates is implementation defined if no thread_limit clause is specified on the construct (see Section 2.14.5).
is_device_ptr clause: Support for pointers created outside of the OpenMP device data management routines is implementation defined (see Section 2.14.5).
interop directive: The foreign-runtime-id that is used if the implementation does not support any of the items in preference-list is implementation defined (see Section 2.15.1).
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 defined (see Section 2.15.1).
The concrete types of the values of interop properties for implementation defined foreign-runtime-ids are implementation defined (see Section 2.15.1).
atomic construct: A compliant implementation may enforce exclusive access between atomic regions that update different storage locations. The circumstances under which this occurs are implementation defined. 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 defined (see Section 2.19.7).

Data-sharing attributes: The data-sharing attributes of dummy arguments without the VALUE attribute are implementation defined if the associated actual argument is shared, except for the conditions specified (see Section 2.21.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 defined (see Section 2.21.2).

Chapter 3:

Runtime library definitions: The enum types for omp_allocator_handle_t, omp_event_handle_t, omp_interop_type_t and omp_memspace_handle_t are implementation defined. The integral or pointer type for omp_interop_t is implementation defined (see Section 3.1).

Runtime library definitions: Whether the include file omp_lib.h or the module omp_lib (or both) is provided is implementation defined. Whether the omp_lib.h file provides derived-type definitions or those routines that require an explicit interface is implementation defined. Whether any of the OpenMP runtime library routines that take an argument are extended with a generic interface so arguments of different KIND type can be accommodated is implementation defined (see Section 3.1).

Chapter 4:

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 and ompt_callback_dispatch tool callbacks: If a tool attempts to register a callback with the string name using the runtime entry point ompt_set_callback (see Table 4.3), whether the registered callback may never, sometimes or always invoke this callback for the associated events is implementation defined (see Section 4.2.4).
Device tracing: Whether a target device supports tracing or not is implementation defined; 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 4.2.5).
ompt_set_trace_ompt and ompt_buffer_get_record_ompt runtime entry points: Whether a device-specific tracing interface will define this runtime entry point, indicating that it can collect traces in OMPT format is implementation defined. The kinds of trace records available for a device is implementation defined (see Section 4.2.5).
Native record abstract type: The meaning of a hwid value for a device is implementation defined (see Section 4.4.3.3).
ompt_record_abstract_t type: The set of OMPT thread states supported is implementation defined (see Section 4.4.4.27).
ompt_callback_target_data_op_t callback type: Whether in some operations src_addr or dest_addr might point to an intermediate buffer is implementation defined (see Section 4.5.2.25).
ompt_set_callback_t entry point type: The subset of the associated event in which the callback is invoked is implementation defined (see Section 4.6.1.3).
ompt_get_place_proc_ids_t entry point type: The meaning of the numerical identifiers returned is implementation defined. The order of ids returned in the array is implementation defined (see Section 4.6.1.8).
ompt_get_partition_place_nums_t entry point type: The order of the identifiers returned in the array place_nums is implementation defined (see Section 4.6.1.10).
ompt_get_proc_id_t entry point type: The meaning of the numerical identifier returned is implementation defined (see Section 4.6.1.11).

Chapter 5:

ompd_callback_print_string_fn_t callback function: The value of category is implementation defined (see Section 5.4.5).
ompd_parallel_handle_compare operation: The means by which parallel region handles are ordered is implementation defined (see Section 5.5.6.5).
ompd_task_handle_compare operation: The means by which task handles are ordered is implementation defined (see Section 5.5.7.6).

Chapter 6:

OMP_SCHEDULE environment variable: If the value does not conform to the specified format then the behavior of the program is implementation defined (see Section 6.1).
OMP_NUM_THREADS environment variable: If any value of the list specified 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 defined (see Section 6.2).
OMP_DYNAMIC environment variable: If the value is neither true nor false the behavior of the program is implementation defined (see Section 6.3).
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 defined. The behavior is also implementation defined if an initial thread cannot be bound to the first place in the OpenMP place list. The thread affinity policy is implementation defined if the value is true (see Section 6.4).
OMP_PLACES environment variable: The meaning of the numbers specified in the environment variable and how the numbering is done are implementation defined. The precise definitions of the abstract names are implementation defined. An implementation may add implementation-defined 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 defined. When requesting more resources than available, the length of the place list is also implementation defined. The behavior of the program is implementation defined when the execution environment cannot map a numerical value (either explicitly defined 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 defined when the OMP_PLACES environment variable is defined using an abstract name (see Section 6.5).
OMP_STACKSIZE environment variable: If the value does not conform to the specified format or the implementation cannot provide a stack of the specified size then the behavior is implementation defined (see Section 6.6).
OMP_WAIT_POLICY environment variable: The details of the active and passive behaviors are implementation defined (see Section 6.7).
OMP_MAX_ACTIVE_LEVELS environment variable: If the value is not a non-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 defined (see Section 6.8).
OMP_NESTED environment variable (deprecated): If the value is neither true nor false the behavior of the program is implementation defined (see Section 6.9).
Conflicting 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, the behavior is implementation defined (see Section 6.9).
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 defined (see Section 6.10).
OMP_DISPLAY_AFFINITY environment variable: For all values of the environment variables other than true or false, the display action is implementation defined (see Section 6.13).
OMP_AFFINITY_FORMAT environment variable: If the value does not conform to the specified format then the result is implementation defined (see Section 6.14).
OMP_TARGET_OFFLOAD environment variable: The support of disabled is implementation defined (see Section 6.17).
OMP_TOOL_LIBRARIES environment variable: Whether the value of the environment variable is case sensitive or insensitive is implementation defined (see Section 6.19).
OMP_TOOL_VERBOSE_INIT environment variable: Support for logging to stdout or stderr is implementation defined. Whether the value of the environment variable is case sensitive when it is treated as a filename is implementation defined. The format and detail of the log is implementation defined (see Section 6.20).
OMP_DEBUG environment variable: If the value is neither disabled nor enabled the behavior is implementation defined (see Section 6.21).
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 defined (see Section 6.23).
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 defined (see Section 6.24).

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