Endian-dependent type-punning from vectors to tuples and arrays #400
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.
Using type punning via an union from a vector type to a tuple or array in general currently results in unspecified (and platform-dependent) behavior.
If the array or tuple have the same element type as the vector, this operation just happen to work (e.g. see some of the previous tests). But when the array or tuple types differ, we get unspecified platform-specific behavior (see the new tests). These cases are basically the same as bit-casting between vectors of different number of lanes.
Also I had to use
repr(C)
to force the tuple layout because otherwise I was getting complete garbage. Possibly because the compiler might reorder the tuple fields to reduce padding. In any case, the layout of tuple elements is completely unspecified, and rustc does use this fact to optimize things already, so...