OpenMP 4.0 Release Candidate 2 Available

[rchrd]

The OpenMP 4.0 Release Candidate 2 is now available for public discussion on this forum.

http://openmp.org/wp/openmp-specifications/

In addition to a number of corrections and clarifications to the specifications, Release Candidate 2 includes the following major enhancements:

* cancel and cancellation point constructs to request cancellation of a parallel region and to declare a user-defined cancellation point to check for cancellation requests. (Section 2.13, p116: Cancellation Constructs)
* Support for Array Sections in C and C++ as well as adding sectioning support for Fortran. (Section 2.4, p36: Array Sections)
* Support for offloaded code regions to attached heterogeneous devices: Device Data Environments (p16), target constructs (p68: target, target data, target update, declare target, teams, distribute; p151: map clause, and associated runtime routines (p191).)
* Extends declare simd to allow multiple declarations. (p64)
* New environment variable OMP_DISPLAY_ENV instructs the runtime to display the OpenMP version number and initial values during initialization. (p219)
* New depend clause enforces additional constraints on the scheduling of tasks. (p91)

This is in addition to enhancements introduced in RC1: thread affinity, initial support for Fortran 2003, SIMD constructs to vectorize both serial and parallelized loops, TASKGROUP, user-defined reductions, and sequentially consistent atomics.

[jakub]

Appendix F.1 hasn't been updated, it seems to only list (some of the) rc1 changes.
Thanks for posting a short list of rc2 changes here.

[tob]

A very minor issue: On page 32: "OMP_DEFAULT-DEVICE" should be "OMP_DEFAULT_DEVICE"

[tob]

OMP_DISPLAY_ENV: Unfortunately, there is no way defined how to handle unset values. For instance, OMP_WAIT_POLICY can be PASSIVE or ACTIVE. However, an implementation might choose to use by default something between ACTIVE and PASSIVE if no environment variable is set. Thus, printing PASSIVE or ACTIVE doesn't really reflect the actual state.

One possibility would be to explicitly permit: OMP_WAIT_POLICY='', implying a default setting which is neither. (It shouldn't be used as environment variable directly as export OMP_WAIT_POLICY='' will be invalid as an empty is not permitted.)

The same might apply to other environment variables.

[rchrd]

A very minor issue: On page 32: "OMP_DEFAULT-DEVICE" should be "OMP_DEFAULT_DEVICE"

Noted. Thanks!

[AlexEichenberger]

Regarding the OMP_DISPLAY_ENV

The intent of this command is not to state what is in the environment of the program (a simple "printenv | grep OMP" would do that. It is also expected that the env var that were set by the user explicitly will be directly reflected (as is) in the display output (more on this in the verbose paragraph below).

What is probably of greater interest is precisely the values of the env var not set by the user, namely the default values of the ICVs. As it currently, some have defaults that defined by the standard, others by the vendor, possibly machine dependent. This make figuring out their value difficult. So the OMP_DISPLAY_ENV is a concise summary of the default values for the given runtime targeting the given machine of the given vendor. This will let in turn the user tweak the default values by changing their values. This is why we print only the "actionable" data, i.e. the data that can be changed by environment variables.

Now another important use is with the "verbose mode." This also print the vendor specific environment variables. Now some of these may have a complex interplay with default OMP env var. Brian Bliss was telling me that, in some cases, Intel's env. var take precedence over the OMP env vars. So this will also let the user understand (by example) what happen when OMP and vendor specific env variables are both set.

For the stated reasons, I believe it is especially important to list all values, including the one not set by the user.

[tob]

Regarding the OMP_DISPLAY_ENV

The intent of this command is not to state what is in the environment of the program (a simple "printenv | grep OMP" would do that. It is also expected that the env var that were set by the user explicitly will be directly reflected (as is) in the display output (more on this in the verbose paragraph below). What is probably of greater interest is precisely the values of the env var not set by the user, namely the default values of the ICVs. As it currently, some have defaults that defined by the standard, others by the vendor, possibly machine dependent.

Still, the default value for OMP_ might not match the default. As written, "OMP_WAIT_POLICY='' is such a case - at least with one compiler. There OMP_WAIT_POLICY=PASSIVE immediately does passive waits, ACTIVE implies 30 billion spins in the spin/busy-wait lock - before waiting passively. And if unset, does 300,000 spins. (If there are more threads than available CPUs, the number reduce to 0, 100 and 1000, respectively.)

Thus, what should the compiler print now with OMP_DISPLAY_ENV for OMP_WAIT_POLICY, if OMP_WAIT_POLICY is unset? ACTIVE, PASSIVE or something else? In the OpenMP 4 development branch it currently prints PASSIVE but as written above it does 300,000 spins - that's more than 0 with PASSIVE but less than 30 billion with ACTIVE. (With OMP_DISPLAY_ENV=verbose, it shows the vendor-specific environment variable which can be used to set the spin count - which shows the real default value.)