You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently users can check which SYCL library version they use with __SYCL_COMPILER_VERSION macro. This macro is set in CL/sycl/version.hpp file to a date when the library is built.
However, there are some disadvantages of this approach.
At first, the name of this variable is not accurate. It isn't compiler version, but library version.
At second, building time may not correlate with the last changes in the library. The same source code may be built on the 1st January of 2020 and on the 31st December of 2030.
It would be nice to have a versioning mechanism so that the version of the library is unambiguously correlated with the changes it contains.
The text was updated successfully, but these errors were encountered:
We have a macro `__SYCL_COMPILER_VERSION` which only corresponds to a
date when build was performed - it does not give any indication of the
actual compiler version, nor does it give any indication of the actual
library build.
This patch attempts to deprecate that old macro and replaces it with
`__LIBSYCL_TIMESTAMP` which contains a date of the latest commit
included into the SYCL library (and therefore SYCL headers) build. Using
commit date is more relibable than build date and its naming speicifally
refers to library instead of the compiler.
"Attempts" above is because it is a bit tricky to deprecate a macro and
heavily depends on the compiler which is being used. Not every 3rd-party
host compiler is covered, i.e. deprecation message may only be emitted
from device compilation pass in certain cases.
Resolvesintel#2250
Currently users can check which SYCL library version they use with __SYCL_COMPILER_VERSION macro. This macro is set in CL/sycl/version.hpp file to a date when the library is built.
However, there are some disadvantages of this approach.
At first, the name of this variable is not accurate. It isn't compiler version, but library version.
At second, building time may not correlate with the last changes in the library. The same source code may be built on the 1st January of 2020 and on the 31st December of 2030.
It would be nice to have a versioning mechanism so that the version of the library is unambiguously correlated with the changes it contains.
The text was updated successfully, but these errors were encountered: