This is an archive of the discontinued LLVM Phabricator instance.

OpenMP version 5.0 added
ClosedPublic

Authored by omalyshe on Feb 28 2017, 2:06 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

omalyshe created this revision.Feb 28 2017, 2:06 AM

Do we really need this? In other words: Is there a use case for not building the OpenMP runtime for the latest standard?

Do we really need this? In other words: Is there a use case for not building the OpenMP runtime for the latest standard?

For example, if it is supposed to use the runtime library with the compiler which does not support the latest standard.

Do we really need this? In other words: Is there a use case for not building the OpenMP runtime for the latest standard?

For example, if it is supposed to use the runtime library with the compiler which does not support the latest standard.

The code for the older standards seems to always be backwards compatible and compiling for newer versions only add additional entry points or features, no?

Do we really need this? In other words: Is there a use case for not building the OpenMP runtime for the latest standard?

For example, if it is supposed to use the runtime library with the compiler which does not support the latest standard.

The code for the older standards seems to always be backwards compatible and compiling for newer versions only add additional entry points or features, no?

(1) We had examples of changed semantics of omp_in_parallel() API from OpenMP 2.0 --> 2.5. Recent incompatibility of OpenMP 4.0 and 4.5 is probably pure compiler related, but anyway, codes written for OpenMP 4.0 don't work for OpenMP 4.5 (because of changed implicit data sharing attribute of scalars in the target construct).
(2) It can be worthwhile to be able to build library for various OpenMP versions support, e.g. for matching the version supported by compiler the library is built for. It looks inelegant and confusing for customers when compiler and library declare different supported versions.

Just my 2 cents.

(1) We had examples of changed semantics of omp_in_parallel() API from OpenMP 2.0 --> 2.5. Recent incompatibility of OpenMP 4.0 and 4.5 is probably pure compiler related, but anyway, codes written for OpenMP 4.0 don't work for OpenMP 4.5 (because of changed implicit data sharing attribute of scalars in the target construct).
(2) It can be worthwhile to be able to build library for various OpenMP versions support, e.g. for matching the version supported by compiler the library is built for. It looks inelegant and confusing for customers when compiler and library declare different supported versions.

Just my 2 cents.

I have to partly agree on that points. For the second point we have the VCS with release branches though...

tlwilmar accepted this revision.Mar 3 2017, 2:01 PM

LGTM

This revision is now accepted and ready to land.Mar 3 2017, 2:01 PM
This revision was automatically updated to reflect the committed changes.