-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Apologies if this code was always broken and I just don't know it yet :) Here's a CI run that recently started failing, due to new warnings plus our usual RUSTFLAGS: "-D warnings"
: 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) that inline(always)
functions assumed the CPU features of their caller and didn't need to be annotated. Either way it seems to be incompatible with target_feature
. What's should this code be doing differently?
Metadata
Metadata
Assignees
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
extern "C"
ABI of SIMD vector types depends on target features (tracking issue forabi_unsupported_vector_types
future-incompatibility lint) #116558RalfJung commentedon Jun 1, 2025
RalfJung commentedon Jun 1, 2025
Uh, wait, something is very strange here. You are not using the "C" ABI it seems? It shouldn't be possible to hit this warning with the "Rust" ABI...
Oh. You are using
-C target-cpu=i386
. That should lead to warnings by itself. You can't disable the SSE/SSE2 target features on i686 targets.RalfJung commentedon Jun 1, 2025
So the actual problem is this:
This warning is emitted so early it's not affected by
-D warnings
.That also explains why you only started seeing this recently.
The "good" news is that #141309 will make the errors go away.
But the warning I just quoted will stay, and we do plan to make it a hard error eventually. Building code without SSE2 should use an i586 target, which are generally lower-tier reflecting the fact that our support for such CPUs is not great (not least because LLVM has a long-standing soundness issue for such targets caused by use of the x87 FPU -- there's apparently not enough people interested in such retro chips to keep them well-supported).
16 remaining items