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
We'd need to incorporate the documentation of rust-lang/rust#64145 or cross-reference it at some point.
The issue is that #[target_feature]s are part of a function ABI, so two functions with different target-features do not necessarily have the same ABI. For example:
The ABI of foo is #[target_feature(enable = "sse")] extern "Rust while the ABI of bar is #[target_feature(enable = "avx")] extern "Rust", and these two ABIs are incompatible, foo expects its F64x4 argument in two 128-bit wide registers, while bar expects its argument in one 256-bit wide register.
might exhibit undefined behavior of the form "wrong call ABI" (we kind of work around this being UB by passing SIMD vectors behind a pointer all the time).
We should document this. In particular, libstd is compiled with the base features for the target, e.g., on x86_64, that's sse2, etc. but external crates can be compiled with different target features, e.g. using -C target-feature=-sse (removing SSE).
When that happens and a crate calls a libstd function, it does so through an extern "Rust" declaration without the SSE, but the libstd definition has SSE. That is, that's undefined behavior of this particular form, and will break all code using floats on ABIs because when SSE is available floats are passed in SSE registers, but when they are disabled they are passed in x87 FPU registers.
So we should not only document that target features can be used to exhibit this particular form of undefined behavior, but that the -C target-featureCLI option makes it trivial to do so, and that we have no checks nor general workarounds for this.
The text was updated successfully, but these errors were encountered:
We'd need to incorporate the documentation of rust-lang/rust#64145 or cross-reference it at some point.
The issue is that
#[target_feature]
s are part of a function ABI, so two functions with different target-features do not necessarily have the same ABI. For example:The ABI of
foo
is#[target_feature(enable = "sse")] extern "Rust
while the ABI ofbar
is#[target_feature(enable = "avx")] extern "Rust"
, and these two ABIs are incompatible,foo
expects itsF64x4
argument in two 128-bit wide registers, whilebar
expects its argument in one 256-bit wide register.That is, code like this:
might exhibit undefined behavior of the form "wrong call ABI" (we kind of work around this being UB by passing SIMD vectors behind a pointer all the time).
We should document this. In particular,
libstd
is compiled with the base features for the target, e.g., on x86_64, that's sse2, etc. but external crates can be compiled with different target features, e.g. using-C target-feature=-sse
(removing SSE).When that happens and a crate calls a libstd function, it does so through an
extern "Rust"
declaration without the SSE, but the libstd definition has SSE. That is, that's undefined behavior of this particular form, and will break all code using floats on ABIs because when SSE is available floats are passed in SSE registers, but when they are disabled they are passed in x87 FPU registers.So we should not only document that target features can be used to exhibit this particular form of undefined behavior, but that the
-C target-feature
CLI option makes it trivial to do so, and that we have no checks nor general workarounds for this.The text was updated successfully, but these errors were encountered: