-
Notifications
You must be signed in to change notification settings - Fork 69
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
Clarify vec::as
behavior
#724
Open
Pennycook
wants to merge
1
commit into
KhronosGroup:main
Choose a base branch
from
Pennycook:vec-as
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
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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.
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.
Do we need some additional words to say that bit-cast from a 3-element
vec
to a 4-elementvec
produces undefined results? See #447.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.
I think this might be covered by the definition of
bit_cast
, but we could still add some clarification.The C++20 definition says that "Each bit of the value representation of the result is equal to the corresponding bit in the object representation of from". The definition in the latest draft is much more verbose, and includes statements like "A bit in the value representation of the result is indeterminate if it does not correspond to a bit in the value representation of from or corresponds to a bit for which the smallest enclosing object is not within its lifetime or has an indeterminate value."
By either definition, I think the intended behavior is clear for
vec::as
. Since a 3-elementvec
is specified to have the same alignment and size as a 4-elementvec
, the bits in the fourth element of the result must come from padding bits that are not part of the value representation of the 3-elementvec
. By the C++20 definition, the bits in the fourth element of the result will be padding bits of unknown value. By the C++23 definition, the bits in the fourth element of the result are explicitly "indeterminate" because they didn't come from the value representation.Maybe we could just say something like:
...or we could even put the note in Section 4.14.2.6, since it applies to use of
bit_cast
as well.Note that I said can lead to undefined behavior, because for certain operations some of the bits are guaranteed to be well-defined. For example, when going from
vec<T, 3>
tovec<T, 4>
, the first three elements should be guaranteed to have well-defined values (and this is the behavior of DPC++, at least).I realize now that this is actually weaker than the wording that was there before, but I think it's a more accurate reflection of how implementations behave. And it would be odd for
as
to have a restriction that a developer could work around trivially by usingbit_cast
instead.