$1 in asm with only one operand silently chooses some arbitrary register

[kmcallister]

asm!("movups $1, %xmm0" : : "r"(0) : "xmm0");

produces

  406519:       0f 10 c0                movups %xmm0,%xmm0

And

asm!("xor $1, %rax" :: "r"(0));

gives

<inline asm>:1:2: error: unknown use of instruction mnemonic without a size suffix
        xor %flags, %rax
        ^
LLVM ERROR: Error parsing inline asm

Possibly it indexes into the clobbers list. If I add a "rax" clobber to the latter example, I get xor %rax, %rax.

rustc 0.10-pre (68a4f7d 2014-02-24 12:42:02 -0800)
host: x86_64-unknown-linux-gnu

[emberian]

This is very unfortunate. cc @Aatch @luqmana

[steveklabnik]

Triage: appears to be the same today.

[steveklabnik]

Triage: https://is.gd/aLBo9e reproduces.

[AstralSorceress]

It seems that LLVM does in fact index into the clobber list. If a clobber is specified, the errant operand will change to whatever was specified first in the clobber list. For example:

#![feature(asm)]

fn main() {
    unsafe {
        asm!("xor $1, %rax" :: "r"(0) : "xmm0");
    }
}

will change the error to

error: <inline asm>:1:2: error: unknown use of instruction mnemonic without a size suffix
        xor %xmm0, %rax
        ^

and if the clobber list is changed to "rbx", the program compiles without issue.

Also of note is that an out-of-bounds index will cause a compiler crash:
asm!("xor $2, %rax" :: "r"(0)); will result in

   Compiling playground v0.0.1 (/playground)
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:355:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:480
   6: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   9: core::panicking::panic
             at libcore/panicking.rs:52
  10: rustc_codegen_llvm::llvm::diagnostic::Diagnostic::unpack
  11: rustc_codegen_llvm::back::write::diagnostic_handler
  12: _ZN4llvm17DiagnosticHandler17handleDiagnosticsERKNS_14DiagnosticInfoE
  13: _ZN4llvm11LLVMContext8diagnoseERKNS_14DiagnosticInfoE
  14: _ZNK4llvm10AsmPrinter13EmitInlineAsmEPKNS_12MachineInstrE
  15: _ZN4llvm10AsmPrinter16EmitFunctionBodyEv
  16: _ZN4llvm13X86AsmPrinter20runOnMachineFunctionERNS_15MachineFunctionE
  17: _ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE
  18: _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE
  19: _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE
  20: _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE
  21: LLVMRustWriteOutputFile
  22: rustc_codegen_llvm::back::write::write_output_file
  23: rustc_codegen_llvm::back::write::codegen::{{closure}}
  24: rustc::util::common::time_ext
  25: rustc_codegen_llvm::back::write::codegen
  26: rustc_codegen_llvm::back::write::execute_work_item
query stack during panic:
end of query stack
error: aborting due to worker thread failure

error: aborting due to previous error

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

I'm thinking about writing a patch to just check that all indices are in bounds before giving the asm template string to LLVM.

[Amanieu]

This issue does not apply to the new asm! (RFC 2850) which validates the asm template string.

The legacy llvm_asm! is deprecated and is no longer maintained.