Global `-Ctarget-feature` flags not applied to entry function

[heiher]

I encountered an issue where global -Ctarget-feature flags are not consistently applied to the program’s entry function (e.g. main).

When passing -Ctarget-feature=-avx, the compiler does not attach the expected function-level target-features attributes to the entry function. As a result, the AVX feature is not fully disabled in that context. This leads to inconsistencies between global target feature settings and the actual function attributes emitted by rustc.

This discrepancy becomes particularly problematic under LTO. In cases where a feature is explicitly disabled in the Rust frontend but implicitly enabled by the LLVM backend for the target architecture, the entry function ends up with mismatched assumptions, potentially causing miscompilation or unexpected behavior.

I tried this code:

fn main() {}

rustc -O --emit llvm-ir -o - t.rs -C target-feature=-avx

I expected to see this happen:

The global target features should be applied to the entry function.

...

define void @main() unnamed_addr #5 personality ptr @rust_eh_personality {
  ...
}

attributes #5 = { nonlazybind "probe-stack"="inline-asm" "target-cpu"="x86-64" "target-features"="-avx,..." }

...

Instead, this happened:

The global target features were not applied to the entry function.

...

define void @main() unnamed_addr #5 personality ptr @rust_eh_personality {
  ...
}

attributes #5 = { nonlazybind "probe-stack"="inline-asm" "target-cpu"="x86-64" }

...

Meta

rustc --version --verbose:

rustc 1.91.0-nightly (51ff89506 2025-09-02)
binary: rustc
commit-hash: 51ff895062ba60a7cba53f57af928c3fb7b0f2f4
commit-date: 2025-09-02
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0

[bjorn3]

As a result, the AVX feature is not fully disabled in that context.

AVX is not a feature that is enabled by default on x86, so AVX should be disabled even without that attribute unless you use -Ctarget-cpu with a cpu that supports AVX, but in that case enabling AVX here should be harmless. The entry function is only emitted for userspace applications, which can depend on all CPU supported features being allowed to use.

In cases where a feature is explicitly disabled in the Rust frontend but implicitly enabled by the LLVM backend for the target architecture, the entry function ends up with mismatched assumptions, potentially causing miscompilation or unexpected behavior.

Note that enabling/disabling AVX does not change the ABI precisely to allow mixing target features between functions as necessary for runtime feature detection to be useful.

[heiher]

As a result, the AVX feature is not fully disabled in that context.

AVX is not a feature that is enabled by default on x86, so AVX should be disabled even without that attribute unless you use -Ctarget-cpu with a cpu that supports AVX, but in that case enabling AVX here should be harmless. The entry function is only emitted for userspace applications, which can depend on all CPU supported features being allowed to use.

In cases where a feature is explicitly disabled in the Rust frontend but implicitly enabled by the LLVM backend for the target architecture, the entry function ends up with mismatched assumptions, potentially causing miscompilation or unexpected behavior.

Note that enabling/disabling AVX does not change the ABI precisely to allow mixing target features between functions as necessary for runtime feature detection to be useful.

Note that x86 AVX is only used here as an example. More precisely, this refers to a target feature that is implicitly enabled by the backend but explicitly disabled by the user in the frontend, for instance, LSX on LoongArch.