Skip to content
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

Explain the discrepancy in the mask type for _mm_shuffle_ps #879

Merged
merged 2 commits into from
Aug 1, 2020

Conversation

georgio
Copy link
Contributor

@georgio georgio commented Jul 31, 2020

Hello everyone,
This pull request attempts to solve rust-lang/rust#62490.
I have based my notes on the discussion from #522

Hope this is helpful :-)

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @gnzlbg (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@georgio georgio changed the title Explain the discrepancy of the mask type in _mm_shuffle_ps Explain the discrepancy in the mask type for _mm_shuffle_ps Jul 31, 2020
/// `_mm_shuffle_ps` is supposed to take an `i32` instead of an `u32`
/// as is the case for [other shuffle intrinsics](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_shuffle_).
/// Performing an implicit type conversion between an unsigned integer and a signed integer
/// does not cause a problem in C, however Rust's commitment to safety does not allow this.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion:

however Rust's commitment to strong typing does not allow this.

u32/i32 flipping isn't a safety related issue, at least not in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct, it's more an issue of Rust's strong typing vs C's weak typing which allows much more implicit conversions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your suggestion! It has been added.

@Amanieu Amanieu merged commit 78891cd into rust-lang:master Aug 1, 2020
@Amanieu
Copy link
Member

Amanieu commented Aug 1, 2020

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants