x86-64 assembler silently truncates 64-bit address

[MauriceKayser]

When using a 64-bit address with the mov instruction on x86-64, the assembler truncates the 64-bit address to 32-bit without notifying the user. It seems to expect an abs suffix on the mov instruction (movabs) to correctly use the 64-bit address, which I could not find in the Intel specification. See godbolt snippet:

asm!(
    "mov    [0x1234567890], al",
    "movabs [0x1234567890], al"
);

becomes:

mov BYTE PTR ds:0x34567890,   al ; 88 04 25 90 78 56 34
movabs       ds:0x1234567890, al ; a2       90 78 56 34 12 00 00 00

I would expect some form of feedback from the compiler, preferably a compilation failure, instead of the silent truncation.

Meta

rustc --version --verbose:

Stable:

rustc 1.74.0 (79e9716c9 2023-11-13)
binary: rustc
commit-hash: 79e9716c980570bfd1f666e3b16ac583f0168962
commit-date: 2023-11-13
host: x86_64-unknown-linux-gnu
release: 1.74.0
LLVM version: 17.0.4

Nightly:

rustc 1.76.0-nightly (2f8d81f9d 2023-11-21)
binary: rustc
commit-hash: 2f8d81f9dbac6b8df982199f69da04a4c8357227
commit-date: 2023-11-21
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.5

[apiraino]

this looks like a miscompilation so let's try to investigate this. WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[workingjubilee]

Hm, movabs is an AT&T syntax instruction. I believe this is incorrect assembly by LLVM's inline assembler, and thus the usual caveat about correctness and validity of assembly does not apply.

[workingjubilee]

I have opened llvm/llvm-project#73481