Repository: rust
Issue: LLVM has rare assert failure (3% of time?) during async trans
Labels: A-LLVM,T-compiler,C-bug

I recently tried turning on LLVM assertions (and built it in Debug mode, etc; part of debugging something else) via the following in my `config.toml`:
```
[llvm]

# Indicates whether rustc will support compilation with LLVM
# note: rustc does not compile without LLVM at the moment
#enabled = true

# Indicates whether the LLVM build is a Release or Debug build
# optimize = true
optimize = false

# Indicates whether an LLVM Release build should include debug info
#release-debuginfo = false
release-debuginfo = true

# Indicates whether the LLVM assertions are enabled or not
assertions = true

# Indicates whether ccache is used when building LLVM
ccache = true
```

and then discovered that sometimes we get LLVM assertion faillures when running the *compile-fail* test suite.

This is of course surprising since one does not expect trans to run if the input has some problem with its static semantics.

Here is an example of such output.

```
failures:

---- [compile-fail] compile-fail/simd-type-generic-monomorphisation.rs stdout ----

error: Error: expected failure status (Some(101)) but received status None.
status: signal: 6
command: "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/pnkfelix/Dev/Mozilla/rust.git/src/test/compile-fail/simd-type-generic-monomorphisation.rs" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-unknown-linux-gnu/test/compile-fail" "--target=x86_64-unknown-linux-gnu" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-unknown-linux-gnu/test/compile-fail/simd-type-generic-monomorphisation.stage1-x86_64-unknown-linux-gnu" "-Crpath" "-Zmiri" "-Zunstable-options" "-Lnative=/home/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/build/x86_64-unknown-linux-gnu/test/compile-fail/simd-type-generic-monomorphisation.stage1-x86_64-unknown-linux-gnu.aux" "-A" "unused"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
error: monomorphising SIMD type `Simd2<X>` with a non-machine element type `X`

error: aborting due to previous error

rustc: /home/pnkfelix/Dev/Mozilla/rust.git/src/llvm/lib/CodeGen/TargetPassConfig.cpp:805: virtual void llvm::TargetPassConfig::addMachinePasses(): Assertion `TPI && IPI && "Pass ID not registered!"' failed.

------------------------------------------

thread '[compile-fail] compile-fail/simd-type-generic-monomorphisation.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:2919:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    [compile-fail] compile-fail/simd-type-generic-monomorphisation.rs

test result: FAILED. 233 passed; 1 failed; 1 ignored; 0 measured; 2087 filtered out
```

Iteratively running that `rustc` command 1000 times yielded that LLVM assert 31 times (that's the basis of my 3% above).

I looked at a generated core file and got a backtrace from it, here: https://gist.github.com/7cb39f28bd7f4960130a4ef555589e98

The current hypothesis in `#rustc` about this is that it is caused from setting up async trans, and then something during a subsequent error from the compiler (in this case the error is signaled during trans, since its a SIMD issue) is tearing down LLVM state that the async trans needs to remain in place.