-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redefine SYCL_LANGUAGE_VERSION #634
Open
gmlueck
wants to merge
1
commit into
KhronosGroup:main
Choose a base branch
from
gmlueck:gmlueck/sycl-lang-version
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now that we have a unified specification, we need to decouple the `SYCL_LANGUAGE_VERSION` macro from the document revision. We decided to keep the 6 digit format where the top 4 digits are the year of the SYCL specification. The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro `__cplusplus`. Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now `202012` for SYCL 2020. We also decided to add the `L` literal suffix to make the macro into a long integer literal. This makes sense because an `int` is only guaranteed to be 16 bits, which is not enough to hold these 6-digit values. This is consistent with `__cplusplus`, which is also a long integer literal.
TApplencourt
approved these changes
Sep 30, 2024
tomdeakin
approved these changes
Oct 1, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks Greg!
keryell
approved these changes
Oct 3, 2024
bader
pushed a commit
to llvm/llvm-project
that referenced
this pull request
Dec 5, 2024
Version of SYCL was changed according to the latest agreement: The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro __cplusplus. Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now 202012 for SYCL 2020. see PR for details KhronosGroup/SYCL-Docs#634
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
Version of SYCL was changed according to the latest agreement: The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro __cplusplus. Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now 202012 for SYCL 2020. see PR for details KhronosGroup/SYCL-Docs#634
chrsmcgrr
pushed a commit
to RooflineAI/llvm-project
that referenced
this pull request
Dec 12, 2024
Version of SYCL was changed according to the latest agreement: The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro __cplusplus. Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now 202012 for SYCL 2020. see PR for details KhronosGroup/SYCL-Docs#634
TIFitis
pushed a commit
to TIFitis/llvm-project
that referenced
this pull request
Dec 18, 2024
Version of SYCL was changed according to the latest agreement: The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro __cplusplus. Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now 202012 for SYCL 2020. see PR for details KhronosGroup/SYCL-Docs#634
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that we have a unified specification, we need to decouple the
SYCL_LANGUAGE_VERSION
macro from the document revision. We decided to keep the 6 digit format where the top 4 digits are the year of the SYCL specification. The lower 2 digits are not formally specified, but we plan to use these to identify the month in which we submit the specification for ratification, which is similar to the C++ macro__cplusplus
.Since the SYCL 2020 specification was submitted for ratification in December of 2020, the macro's value is now
202012
for SYCL 2020.We also decided to add the
L
literal suffix to make the macro into a long integer literal. This makes sense because anint
is only guaranteed to be 16 bits, which is not enough to hold these 6-digit values. This is consistent with__cplusplus
, which is also a long integer literal.