Repository navigation
The extern "C" ABI of SIMD vector types depends on target features (tracking issue for abi_unsupported_vector_types future-incompatibility lint) #116558
Description
Activity
For a hard error, I think it probably should go through RFC. I can start drafting that now. As for what it would check, I'd expect a hard error on any time a simd type is passed by value and the appropriate feature is unavailable, even if the specific ABI wouldn't necessarily pass it in registers, including inside a structure, and the lint should probably check the same thing.
That can have potentially surprising effects, e.g. when a closure captures something of type
__m256and the closure gets passed by-value to a generic function.It also means adding adding a private field that contains by-val
repr(simd)data can be a semver-breaking change. Cc @ehussIt also means adding adding a private field that contains by-val repr(simd) data can be a semver-breaking change
This would already be the case with replacing several fields with a SIMD type. For example, changing
struct Foo(u64,u64,u64,u64);tostruct Foo(__m256i);Although thinking about it, because features can be per-crate, this might be a problem on crates that specialize based on target features.
Perhaps
#[repr(Rust)]types should be exempted and always passed indirectly when they contain SIMD types (but not#[repr(C)]types).With RISC-V, you have
ZfinxandZdinxwhich have hard-floats but have moved the floats to the normal general purpose registers. In this case, forbidding the passing of floats by-value, if thef(RISC-V's version of single-precision float) target is not present, is very restrictive and probably not what you would want. Otherwise, allowing the passing-by-value of floats betweenfandZfinxis also UB.But the ABI only changes when
fis present or not present, I assume? Whenfis present,Zfinxjust means more instructions can be used but the ABI still saysf32is passed on float registers? And whenfis not present, softfloat andZfinxuse the same ABI?So that sounds like whether or not
fis present should be a different target triple. Code with vs withoutfsimply cannot be linked together. But having or not havingZfinxdoesn't make an ABI difference. Or am I misunderstanding?No, that is exactly it. Do I understand correctly that you essentially want to do something similar to
thumbwith theeabiandeabihf?I'm not an expert on target details. 🙈 Usually my purview ends when I have given precise abstract semantics to nasty pieces of unsafe Rust and MIR.^^ But every now and then terrible low-level CPU nightmares creep onto my territory and then I have to learn how to deal with them...
So, I don't know what ARM does with eabi vs eabihf. But it sounds like they are considering "hard float" and "soft float" two different ABIs that presumably use different registers for argument passing (so they are indeed different ABIs), and then have corresponding target triples to tell apart the ABIs. So yeah that sounds like what I am suggesting we should do for other targets as well. (We could also consider different ABI strings, like "C" vs "C-softfloat" or so. No idea if that makes any sense.)
Obviously we don't actually care whether the functions behind those ABIs use x87/d/f hardware instructions or do some softfloat stuff, we just care how arguments are passed. But sadly it seems that in LLVM, there's no way to say "you have the
d,ftarget features available but please use the softfloat ABI anyway"? If that is something people need (enabled,forx87,sse,sse2on softfloat targets without affecting ABI) we should start talking with LLVM people about whether and how that could be achieved.This may all be completely naive since I'm just coming at this with my principled approach of making everything safe or at least sound and giving it semantics at a high level; I rely on people like @chorman0773 to tell me when my ideas make no sense "in the field". ;)
Reacted by Connor Horman and Gijs BurghoornIf
with_target_featurecallingno_target_featureis UB due do different target features, shouldn'tmaincallingwith_target_featurehave the same problem? just the other way around?
Or is this specific to "C" being a non Rust-ABI?Yeah for the Rust ABI we do apply a work-around (it always passes such types in memory), so that call is fine. But the combination of
extern fnandtarget_featureis a big minefield currently.(I updated the example to actually use the Rust ABI for
with_target_feature.)Would adding a
inline(never)Rust ABI intermediate function be a valid workaround to prevent UB here?
Unconditional code generation #[target_feature]: Note 1 making#[inline(never)]required as otherwise the compiler may inline the function and then we would be back to the incorrect feature set.EDIT: The referenced Note
Note 1: a function has the features of the crate where the function is defined +/- #[target_feature] annotations. Iff the function is inlined into a context that extends its feature set, then the compiler is allowed to generate code for the function using this extended feature set (sub-note: inlining is forbidden in the opposite case).
Inlining should be aware of target features, so
inline(never)should not be needed. If it is needed that's a critical bug in the inliner that we should track and fix.Yes such an intermediate Rust ABI function works around the problem successfully. But the fundamental problem remains with function pointers: we have to decide whether an
extern "C" fn(__m256)has the AVX ABI or some fallback ABI, without having any clue where and how the function it points to was declared. We probably want it to have the AVX ABI since people that use AVX and interface between Rust and C code likely will have their C code built in a way that it uses the AVX ABI. This means allextern "C" fndeclared in Rust that take__m256as arguments should do this the AVX style, no matter the set of enabled target features -- or they should fail to build.The compiler does report
improper_ctypes_definitionswarnings for the given code so I guess it isn't unexpected? It would e better to have an example that doesn't triggerimproper_ctypes_definitions.128 remaining items
- added a commit that references this issue
on Apr 24, 2025 - added a commit that references this issue
on Apr 24, 2025 - added a commit that references this issue
on Apr 28, 2025 @RalfJung I've noticed new warnings as a result of this change. Here's a CI run: https://github.com/BLAKE3-team/BLAKE3/actions/runs/15326026728/job/43120654065. Reproducing that locally:
$ git clone https://github.com/BLAKE3-team/BLAKE3 ... $ cd BLAKE3 $ cross rustc --release --target i686-unknown-linux-musl -- -C target-cpu=i386 ... warning: this function definition uses SIMD vector type `std::arch::x86::__m128i` which (with the chosen ABI) requires the `sse` target feature, wh ich is not enabled --> src/rust_sse2.rs:75:1 | 75 | / unsafe fn g1( 76 | | row0: &mut __m128i, 77 | | row1: &mut __m128i, 78 | | row2: &mut __m128i, 79 | | row3: &mut __m128i, 80 | | m: __m128i, 81 | | ) { | |_^ function defined here | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558> = help: consider enabling it globally (`-C target-feature=+sse`) or locally (`#[target_feature(enable="sse")]`) ...The code in that file is divided into two types of functions, public ones annotated with
#[target_feature(enable = "sse2")], and private ones annotated with#[inline(always)]. I had thought (or read somewhere) thatinline(always)functions assumed the CPU features of their caller and didn't need to be annotated. Either way it seems to be incompatible withtarget_feature. What's should this code be doing differently?@oconnor663 please file a new issue.
I'm surprised this only came up now, this was an FCW for 4 releases...
Weird, I'm pretty sure this test target has been running regularly for years. Thanks for getting back to me so quickly. Opened: #141848
- Well, FCW are warnings, so if nobody looks a the CI output and CI does not set "-D warnings" and people ignore the warnings in local builds they can get missed.
Ah this is with 1.87, not with nightly, I see -- so it is still a warning. It'll be a hard error with 1.88.
But it has been a warning for local crates since 1.84, and for all dependencies since 1.85.
- added 6 commits that reference this issue
on Jan 27, 2026 - added a commit that references this issue
on Feb 3, 2026
The following program has UB, for very surprising reasons:
The reason is that the ABI of the
__m256type depends on the set of target features, so the caller (with_target_feature) and callee (no_target_feature) do not agree on how the argument should be passed. The result is a vector half-filled with junk. (The same issue also arises in the other direction, where the caller has fewer features than the callee: example here.)Currently, we have no good way to do correct code generation here. See #132865 for a discussion of how we could support such code in the future; it will require some non-trivial work. So instead, the current plan is to reject such code entirely.
This is the tracking issue for the lint that moves us in that direction. The hope is that passing SIMD vectors across a C ABI is sufficiently rare, and most of the cases being rejected have anyway already been broken, that we can reject this without much of an ecosystem impact. Crater showed no regressions.
This is linted against since Rust 1.84, and shown in future breakage reports starting with Rust 1.85. The plan is to move to a hard error with Rust 1.87.
When this becomes a hard error:
Original issue text:
I'm not sure if this is currently even properly documented? We are mentioning it in #115476 but the program above doesn't involve any function pointers so we really cannot expect people to be aware of that part of the docs. We show a general warning about the type not being FFI-compatible, but that warning shows up a lot and anyway in this case both caller and callee are Rust functions!
I think we need to do better here, but backwards compatibility might make that hard. @chorman0773 suggested we should just reject functions like
no_target_featurethat take an AVX type by-val without having declared the AVX feature. That seems reasonable; a crater run would be needed to assess whether it breaks too much code. An alternative might be to have a deny-by-default lint that very clearly explains what is happening.There are also details to work out wrt what exactly the lint should check. Newtypes around
__m256will have the same problem. What about other larger types that contain__m256? Behind a ptr indirection it's obviously fine, but what about(__m256, __m256)? If we apply theScalarPairoptimization this will be passed in registers even on x86.A possible place to put the check could be somewhere around here.
In terms of process, I am not sure if an RFC is required; a t-compiler MCP might be sufficient. Currently we accept code that clearly doesn't do what it looks like it should do.
And finally -- are there any other targets (besides x86 and x86-64) that have target-features that affect the ABI? They should get the same treatment.
Note that this is different from #116344 in two ways:
__m256by-pointer exactly to work-around this issue.)#[target_feature]), the other issue comes about when the user disables features (which is only possible on a per-crate level via-C, and if you're mixing crates with different-Cflags then you're already already on very shaky grounds -- we do that with std but nobody else really gets to do that, I think).Cc @workingjubilee more ABI fun ;)