Repository navigation
Closed
Labels
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.A-inline-assemblyArea: Inline assembly (`asm!(…)`)Area: Inline assembly (`asm!(…)`)A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.Area: Enabling/disabling target features like AVX, Neon, etc.C-bugCategory: This is a bug.Category: This is a bug.C-external-bugCategory: issue that is caused by bugs in software beyond our controlCategory: issue that is caused by bugs in software beyond our controlO-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateS-waiting-on-LLVMStatus: the compiler-dragon is eepy, can someone get it some tea?Status: the compiler-dragon is eepy, can someone get it some tea?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.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Description
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/armv7r-unknown-none-eabihf.20weirdness/near/448803070 for discussion and https://github.com/ferrous-systems/armv7r-issues for a reproducer.
I tried this code:
core::arch::global_asm!(
r#"
.section .text.startup
.global _start
.code 32
.align 0
_start:
// Set stack pointer
ldr r3, =stack_top
mov sp, r3
// Allow VFP coprocessor access
mrc p15, 0, r0, c1, c0, 2
orr r0, r0, #0xF00000
mcr p15, 0, r0, c1, c0, 2
// Enable VFP
mov r0, #0x40000000
vmsr fpexc, r0
// Jump to application
bl kmain
// In case the application returns, loop forever
b .
"#
);In debug profile, this compiles OK. If you use release profile and force codegen-units=1, it compiles. On armv8r-unknown-none-eabihf, it compiles.
But, if the target is armv7r-unknown-none-eabihf and codegen-units != 1, you get this error:
error: <inline asm>:18:5: instruction requires: VFP2
vmsr fpexc, r0
^
Meta
rustc --version --verbose:
rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: aarch64-apple-darwin
release: 1.78.0
LLVM version: 18.1.2
or
rustc 1.81.0-nightly (6b0f4b5ec 2024-06-24)
binary: rustc
commit-hash: 6b0f4b5ec3aa707ecaa78230722117324a4ce23c
commit-date: 2024-06-24
host: aarch64-apple-darwin
release: 1.81.0-nightly
LLVM version: 18.1.7
Both have the same issue.
Metadata
Metadata
Assignees
Labels
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.A-inline-assemblyArea: Inline assembly (`asm!(…)`)Area: Inline assembly (`asm!(…)`)A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.Area: Enabling/disabling target features like AVX, Neon, etc.C-bugCategory: This is a bug.Category: This is a bug.C-external-bugCategory: issue that is caused by bugs in software beyond our controlCategory: issue that is caused by bugs in software beyond our controlO-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateS-waiting-on-LLVMStatus: the compiler-dragon is eepy, can someone get it some tea?Status: the compiler-dragon is eepy, can someone get it some tea?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.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Type
Projects
- StatusShow more project fieldsDone
Activity
chrisnc commentedon Jul 3, 2024
The same issue happens with
riscv32imac-unknown-none-elf, when trying to use the "A" extension inglobal_asm!, so this does not seem to be an issue with a specific target, but rather howrustchandles target features forglobal_asm!. Adding.option arch, rv32imacmakes the error go away.Dirbaio commentedon Jul 3, 2024
minimized:
works: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=0 -C embed-bitcode=no'
fails: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=0'
fails: 'rustc --edition=2021 --crate-type lib --target armv7r-none-eabihf repro.rs -C opt-level=s -C embed-bitcode=no'
so both
opt-levelandembed-bitcode=noaffect it. huhjamesmunns commentedon Jul 3, 2024
I have a half-baked (read: totally uninformed goose chase) that LLVM might not be properly copying the target features when creating the TargetMachine codegen.
Following this down:
The last one says:
But:
rust/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
Lines 405 to 530 in c872a14
doesn't do the copying. I'm trying to hunt down where in LLVM this copy would actually take place, in the createTargetMachine code.
jamesmunns commentedon Jul 3, 2024
@Dirbaio tried leaking the feature flags, so it's probably not the "llvm doesn't copy the data right" thing I was guessing. Leaving the breadcrumbs in case it's useful for anyone following the codegen process down.
thejpster commentedon Jul 3, 2024
This is possibly a dupe of #80608
Dirbaio commentedon Jul 3, 2024
i've narrowed it to this line. If that runs, compilation fails.
rust/compiler/rustc_codegen_llvm/src/back/write.rs
Line 720 in 7ba82d6
so it's LTO-related, yep. Seems similar to #80608 though the compilation does abort here. Probably root cause is llvm/llvm-project#61991 too.
Dirbaio commentedon Jul 3, 2024
narrowed it down to https://github.com/rust-lang/llvm-project/blob/96aca7c51701f9b3c5dd8567fcddf29492008e6d/llvm/lib/Object/ModuleSymbolTable.cpp#L96
the target features string there is empty. If I hardcode it to "+vfp3d16" the error goes away, that confirms the issue is there.
chrisnc commentedon Jul 6, 2024
As in #80608 (comment), the workaround is to add assembly directives in the
global_asm!block to enable target features. In this case it would be.fpu vfpv3-d16, whicharmv7r-none-eabihfenables by default.11 remaining items
jonathanpallant commentedon Feb 26, 2026
This issue kicked my ass again today, when I switched some stuff to use naked functions and in doing so dropped the magic .fpu directive that makes my code build.
chrisnc commentedon Feb 28, 2026
I've updated llvm/llvm-project#97685 (comment). Hopefully this can be addressed soon and there's nothing else blocking it besides the intended refactor of target feature tracking which appears to have stalled.
thejpster commentedon Jul 4, 2026
llvm/llvm-project#204548 was merged upstream
chrisnc commentedon Jul 4, 2026
It was reverted due to build breakages unfortunately: llvm/llvm-project#207399.
chrisnc commentedon Jul 28, 2026
And fixed again llvm/llvm-project#207677
Rollup merge of rust-lang#160594 - folkertdev:asm-forward-target-feat…
Rollup merge of rust-lang#160594 - folkertdev:asm-forward-target-feat…
Rollup merge of rust-lang#160594 - folkertdev:asm-forward-target-feat…
Rollup merge of rust-lang#160594 - folkertdev:asm-forward-target-feat…
Rollup merge of rust-lang#160594 - folkertdev:asm-forward-target-feat…
Unrolled build for #160594 in rollup 161959