Repository navigation
Inline assembly with tied operands of different sizes #65452
Description
When transpiling (or manually translating) the following C code from /usr/include/bits/select.h:
# define __FD_ZERO(fdsp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
: "=c" (__d0), "=D" (__d1) \
: "a" (0), "0" (sizeof (fd_set) \
/ sizeof (__fd_mask)), \
"1" (&__FDS_BITS (fdsp)[0]) \
: "memory"); \
} while (0)into Rust, we get approximately the following code (manually rewritten to make it cleaner):
let mut x: u32 = 0;
let mut y: u32;
let mut z: u32;
unsafe {
asm!("cld; rep stosb"
: "={di}"(y), "={cx}"(z)
: "{al}"(42), "0"(&mut x), "1"(4)
: "memory"
: "volatile"
);
}the resulting Rust inline assembly works fine in release mode, but crashes in debug mode.
Link to Playground
The issue here is that the "0"(&mut x) input operand is tied to the same register as the "={di}"(y) output operand, but they have different types and sizes (&mut u32 vs u32). LLVM assigns both operands to the edi register in debug mode (which is wrong) but to rdi in release mode (which is the expected assignment).
gcc and clang compile the original C code correctly because they extend both operands to the larger size in the front end (link to clang code). The equivalent correct Rust code would be something like
unsafe {
let y64: u64;
asm!("cld; rep stosb"
: "={di}"(y64), "={cx}"(z)
: "{al}"(42), "0"(&mut x), "1"(4)
: "memory"
: "volatile"
);
y = y64 as u32;
}Should rustc expect to never see this input (I think it's LLVM UB), or replicate clang's behavior? If it's the latter, I could implement that myself and submit a PR, but I'm trying to get some feedback before writing any code.
Activity
nagisa commentedon Oct 16, 2019
The current implementation of Rust’s
asm!is pretty much "pass it through to LLVM" and any larger changes to it, such as replicating some of the clang’s behaviour, are likely going to be a part of the larger inline assembly design work that will be necessary for inline assembly to stabilise.Nevertheless this issue is a good corner case to consider when exploring our options and, eventually, implementing a new inline asm. Thanks for the report!
Amanieu commentedon May 23, 2020
This issue does not apply to the new
asm!(RFC 2850) which properly rejects tied operands of different sizes.The legacy
llvm_asm!is deprecated and is no longer maintained.