Array as asm output ICEs LLVM

[kmcallister]

#![feature(asm)]

fn main() {
    let arr: [u8; 16];
    unsafe { asm!("" : "=m"(arr)); }
    println!("{:?}", arr);
}

$ rustc --version
rustc 1.0.0-dev (896cb36ec 2015-01-14 12:19:58 +0000)

$ rustc foo.rs
Unknown type!
UNREACHABLE executed at /home/keegan/rust-master/src/llvm/lib/IR/ValueTypes.cpp:251!
Aborted

[erickt]

visiting for triage. Still reproducible.

[steveklabnik]

Triage: still reproduces

[kmcallister]

Updated the code.

[tamird]

Triage: this is worse now - no longer an ICE, this now causes all kinds of failures:

$ rustc --version
rustc 1.0.0-dev (f46c4e158 2015-04-20) (built 2015-04-20)
$ rustc src/bin/main.rs
Segmentation fault: 11
$ rustc src/bin/main.rs
Segmentation fault: 11
$ rustc src/bin/main.rs
Segmentation fault: 11
$ RUST_BACKTRACE=1 rustc src/bin/main.rs
Illegal instruction: 4
$ RUST_BACKTRACE=1 rustc src/bin/main.rs
Segmentation fault: 11
$ RUST_BACKTRACE=1 rustc src/bin/main.rs
Segmentation fault: 11
$ RUST_BACKTRACE=1 rustc src/bin/main.rs
Illegal instruction: 4

[kmcallister]

I don't remember whether we now disable LLVM assertions by default, but that might explain the change.

[dotdash]

LLVM assertions are off by default now, only with --enable-llvm-assertions or --enable-debug and the nightly channel have them enabled. @tamird could you please check whether LLVM assertions are enabled in your rustc, and if not, re-check this and any other issues that you triaged that were about LLVM assertions? Thanks!

[jooert]

With LLVM assertions enabled, this still fails with the original error.

[jethrogb]

Possibly related to #15402

[chordowl]

Triage: still reproduces:

Unknown type!
UNREACHABLE executed at /checkout/src/llvm/lib/IR/ValueTypes.cpp:285!
error: Could not compile `playground`.

[cuviper]

With llvm-assertions, the error is still in the same place:

Unknown type!
UNREACHABLE executed at [...]/rust/src/llvm/lib/CodeGen/ValueTypes.cpp:285!
Aborted (core dumped)

The code in question doesn't look able to support direct arrays:
https://github.com/rust-lang/llvm/blob/5a081f0363340dd895d0958955d0c84661f60f05/lib/CodeGen/ValueTypes.cpp#L285

Backtrace from GDB:

#0  0x00007ffff72f4eab in raise () from /lib64/libc.so.6
#1  0x00007ffff72df5b9 in abort () from /lib64/libc.so.6
#2  0x00007fffede0bbba in llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) ()
#3  0x00007fffed381cb1 in llvm::MVT::getVT(llvm::Type*, bool) [clone .localalias.44] ()
#4  0x00007fffed381ce4 in llvm::EVT::getEVT(llvm::Type*, bool) ()
#5  0x00007fffecfa75bb in llvm::TargetLowering::ParseConstraints(llvm::DataLayout const&, llvm::TargetRegisterInfo const*, llvm::ImmutableCallSite) const ()
#6  0x00007fffece2eb6e in llvm::FunctionLoweringInfo::set(llvm::Function const&, llvm::MachineFunction&, llvm::SelectionDAG*) ()
#7  0x00007fffecf83b96 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .part.971] ()
#8  0x00007fffebfeb874 in (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#9  0x00007fffed1972a4 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#10 0x00007fffedba2658 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#11 0x00007fffedba26d9 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#12 0x00007fffedba1cb8 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#13 0x00007fffebf0fdd2 in LLVMRustWriteOutputFile ()
[...]

The LLVM-IR for the call looks like:

  %arr = alloca [16 x i8], align 1
  %0 = call [16 x i8] asm "", "=m,~{dirflag},~{fpsr},~{flags}"(), !srcloc !6
  store [16 x i8] %0, [16 x i8]* %arr, align 1

I tried to create a similar input for clang:

#include <stdint.h>
#include <stdio.h>
int main() {
    uint8_t arr[16];
    asm("" : "=m" (arr));
    printf("[%i, ..]\n", arr[0]);
    return 0;
}

The IR here instead gives the array as an indirect parameter for the call, through a pointer, and just returns void.

  %2 = alloca [16 x i8], align 16
  call void asm "", "=*m,~{dirflag},~{fpsr},~{flags}"([16 x i8]* %2) #2, !srcloc !2

[pnkfelix]

ICE is dependent on feature(asm) (cc #29722), which is not on the 2019 roadmap. Marking as P-medium until we get an overall plan for asm in Rust.

[pnkfelix]

(Although the fact that this can cause rustc itself to segfault, presumably via a problem internal to LLVM, does lead me to wonder if I should up the priority to P-high anyway.)

[Amanieu]

This issue does not apply to the new asm! (RFC 2850) which has stricter checks on the types that can be used as asm operands.

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