Repository navigation
global_asm! macro causes non-fatal errors to be printed during compilation for some RISC-V extension instructions when targeting the GC extensions #80608
Description
Activity
I can't seem to reproduce this: https://rust.godbolt.org/z/5hW8jn
Ah, finally was able to reproduce it, looks like its not
asm!butglobal_asm!(I never made the connection between the output andglobal_asm!, I assumed it affected both since I don't use those instructions in non-global_asm!code), so I'll correct the title. It also requires the--emit=dep-info,linkargument to be passed torustc, at which point you can see all of the errors, here's a godbolt link: https://rust.godbolt.org/z/KreW3M- changed the title
[-]`asm!` macro causes non-fatal errors to be printed during compilation for some RISC-V extension instructions when targeting the GC extensions[/-][+]`global_asm!` macro causes non-fatal errors to be printed during compilation for some RISC-V extension instructions when targeting the GC extensions[/+]on Jan 2, 2021 I saw
error: instruction requires the following: 'D' (Double-Precision Floating-Point)in myglobal_asmon theriscv64gc-unknown-none-elftarget, too, but only in release mode.Reacted by Deepak SironeI still don't know what the cause of this problem is (it seems to be in LLVM?). However I have found a workaround: you need to add
.attribute arch, "rv64gc"to the assembly code to enable thefanddfeatures in the assembler.Reacted by usamoi, Gary Guo, Théo Rozier, Deepak Sirone, sslime336, Js2xxx, silvanshade and SaZiKKI see the following in a release build with
global_asm!:error: instruction requires the following: 'A' (Atomic Instructions) amoswap.d.aq t0, t0, (t1) ^ error: instruction requires the following: 'M' (Integer Multiplication and Division) or 'Zmmul' (Integer Multiplication) mul t1, a3, t2Upstream bug: llvm/llvm-project#61991
35 remaining items
LLVM now supports setting target features on asm blocks (llvm/llvm-project#204548 was merged today).
I'm not sure whether Rust would fill that in for you, or if we require users to do it (in which case it doesn't seem a lot better than just manually specifying
.arch v8mor something in the assembly text itself).If I read it right, a backend can now override functions to enter and exit a context with particular target features (
emitTargetFeaturePushandemitTargetFeaturePop). So, the relevant backends would need to add support (currently only the riscv backend overrides this, so a follow-up is needed still). Then, from what I can tell the functionality is also not yet exposed via the C api.Anyhow, this is all in LLVM, so for rust it's just a matter of forwarding the correct target features. We'd at least forward the target features that are statically enabled. We'll need to figure something out if we want something more custom than that.
The target feature push/pop is only relevant when round-tripping through assembly. When going directly to machine code, just specifying the target features on the global asm would be sufficient. That's either the global features, or the target features on a naked function (if that's something we support).
Reacted by Folkert de Vriesor the target features on a naked function (if that's something we support).
It's something we'd like to support
It sounds like we'd already get the push/pop behavior of features that we want then? (i.e. features enabled in an module-level assembly block do not "leak" into other code). I tried to implement that manually at some point but got kind of stuck, see #137720.
- added 3 commits that reference this issue
on Aug 28, 2026 - added a commit that references this issue
on Aug 29, 2026
I'm currently using the
asm!macro on theriscv64gc-unknown-none-elftarget, and have been getting some "errors" for a while about instructions requiring extensions -- except that GC includes the extensions of the instructions I'm using (IMAFDC). So far I've seen errors for F, D, and A instructions, everything else seems to be fine that I've used so far. Despite them being reported as errors, the build still succeeds however. @nbdd0121 suggested this may be an LLVM bug.Example: