Rust: LLVM error: "Instruction does not dominate all uses!" on Windows

Created on 22 May 2020  ·  31Comments  ·  Source: rust-lang/rust

Code

Project is here: https://github.com/kryptan/llvm-error

Compile with cargo test --release on Windows-MSVC (compilation on Linux works fine).

src/lib.rs:

use std::future::Future;
use std::sync::Arc;

pub async fn run() {
    foo(|| async { create() }).await;
    foo(|| async { create() }).await;
}

async fn foo<F>(create: impl Fn() -> F)
where
    F: Future<Output = Struct>,
{
    call_empty::<()>(create().await, "").await;
}

struct Struct {
    _vec: Vec<u8>,
    _arc: Arc<()>,
}

fn create() -> Struct {
    Struct {
        _vec: Vec::new(),
        _arc: Arc::new(()),
    }
}

async fn call_empty<R>(_: Struct, _: &str) {
    empty()
}

fn empty() {}

tests/test.rs:

use std::future::Future;

#[test]
fn test() {
    let _: Box<dyn Future<Output = ()>> = Box::new(llvm_eror::run());
}

Meta

I tried two versions of the compiler (LLVM 9 & LLVM 10):

rustc --version --verbose:

rustc 1.45.0-nightly (9310e3bd4 2020-05-21)
binary: rustc
commit-hash: 9310e3bd4f425f84fc27878ebf2bda1f30935a63
commit-date: 2020-05-21
host: x86_64-pc-windows-msvc
release: 1.45.0-nightly
LLVM version: 10.0

rustc --version --verbose:

rustc 1.45.0-nightly (a74d1862d 2020-05-14)
binary: rustc
commit-hash: a74d1862d4d87a56244958416fd05976c58ca1a8
commit-date: 2020-05-14
host: x86_64-pc-windows-msvc
release: 1.45.0-nightly
LLVM version: 9.0

Error output

Instruction does not dominate all uses!
  %117 = phi i8* [ %117, %111 ], [ %117, %105 ], [ %43, %60 ], [ %43, %58 ], [ %51, %56 ]
  %117 = phi i8* [ %117, %111 ], [ %117, %105 ], [ %43, %60 ], [ %43, %58 ], [ %51, %56 ]
Instruction does not dominate all uses!
  %117 = phi i8* [ %117, %111 ], [ %117, %105 ], [ %43, %60 ], [ %43, %58 ], [ %51, %56 ]
  %117 = phi i8* [ %117, %111 ], [ %117, %105 ], [ %43, %60 ], [ %43, %58 ], [ %51, %56 ]
Instruction does not dominate all uses!
  %228 = phi i8* [ %228, %222 ], [ %228, %216 ], [ %155, %171 ], [ %155, %169 ], [ %162, %167 ]
  %228 = phi i8* [ %228, %222 ], [ %228, %216 ], [ %155, %171 ], [ %155, %169 ], [ %162, %167 ]
Instruction does not dominate all uses!
  %228 = phi i8* [ %228, %222 ], [ %228, %216 ], [ %155, %171 ], [ %155, %169 ], [ %162, %167 ]
  %228 = phi i8* [ %228, %222 ], [ %228, %216 ], [ %155, %171 ], [ %155, %169 ], [ %162, %167 ]
in function _ZN97_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$4poll17hf4840ccb0415d3e1E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `llvm_eror`.
A-LLVM A-async-await A-codegen AsyncAwait-Triaged C-bug E-needs-mcve I-ICE ICEBreaker-Cleanup-Crew ICEBreaker-LLVM O-windows-msvc P-high T-compiler regression-from-stable-to-nightly
Source
picture kryptan

Most helpful comment

I have now pushed a 2-file repro. I'll leave the rest to our LLVM experts.

picture jonas-schievink on 1 Aug 2020
🎉2

All 31 comments

Regression from rustc 1.45.0-nightly (bad3bf622 2020-05-09) to rustc 1.45.0-nightly (9912925c2 2020-05-10)

bad3bf622...9912925c2

Further bisection might be needed

jonas-schievink picture jonas-schievink on 22 May 2020

A smaller reproduction would be useful (if that's possible), marking needs-mcve

jonas-schievink picture jonas-schievink on 22 May 2020

@rustbot ping cleanup

jonas-schievink picture jonas-schievink on 24 May 2020

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
[instructions] for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

rustbot picture rustbot on 24 May 2020

With some bisection, I think this caused by #71840, cc @matthewjasper

JohnTitor picture JohnTitor on 25 May 2020

Assigning P-critical, and pinging the LLVM ICE-breaker group as discussed as part of the Prioritization WG process.

@rustbot ping llvm

LeSeulArtichaut picture LeSeulArtichaut on 26 May 2020

Hey LLVM ICE-breakers! This bug has been identified as a good
"LLVM ICE-breaking candidate". In case it's useful, here are some
[instructions] for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @comex @CrazyDebugger @cuviper @DutchGhost @hanna-kruppe @hdhoang @heyrutvik @JOE1994 @jryans @mmilenko @nagisa @nikic @Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique

rustbot picture rustbot on 26 May 2020

self-assigning, with plan to revert injecting PR before it hits beta.

pnkfelix picture pnkfelix on 28 May 2020

So, investigating this bug some more:

  • Merging everything into 1 crate doesn't give a broken IR error
  • -C codegen-units=1 doesn't give a broken IR error
  • --emit llvm-ir -C no-prepopulate-passes causes an assertion in llvm (if enabled), but works on nightly. llc then happily compiles to asm.

So reverting is the only thing that I can think of to fix this.

matthewjasper picture matthewjasper on 28 May 2020

So reverting is the only thing that I can think of to fix this.

Is the only quick fix, I guess.

Ultimately this extremely likely to be an issue in LLVM itself – you cannot really construct a IR malformed in a way that would raise this error in lowering to LLVM-IR (I believe almost by construction of the LLVM API), especially because we do not generate phis.

I think the PR in question is worthwhile enough to warrant spending time looking into it, so I would love to see an issue filled with links to all the information we currently have so that it does not get lost as this one is closed by the PR above.

nagisa picture nagisa on 6 Jun 2020
  • --emit llvm-ir -C no-prepopulate-passes causes an assertion in llvm (if enabled), but works on nightly. llc then happily compiles to asm.

What was the assertion failure?

nikic picture nikic on 7 Jun 2020

This is the failing assertion
https://github.com/rust-lang/llvm-project/blob/02e0d7fa5547f2b270b8b57cf4f4f8e177153c8d/llvm/lib/Analysis/LazyValueInfo.cpp#L727

matthewjasper picture matthewjasper on 8 Jun 2020

More notes from investigating this:

  • There's no error with -Clto=no, -Clto=thin and Clto=fat (somewhat surprisingly, none of these is the default).
  • There's no error with -Znew-llvm-pass-manager
  • The following patch avoids the error:
index 461b13c4f63..d49014dc7cd 100644
--- a/src/librustc_mir/transform/generator.rs
+++ b/src/librustc_mir/transform/generator.rs
@@ -301,10 +301,13 @@ impl MutVisitor<'tcx> for TransformVisitor<'tcx> {
     }

     fn visit_basic_block_data(&mut self, block: BasicBlock, data: &mut BasicBlockData<'tcx>) {
-        // Remove StorageLive and StorageDead statements for remapped locals      
+        // Remove StorageLive and StorageDead statements for remapped locals.     
+        // Also remove storage dead from unwind paths where it's no longer        
+        // needed.
+        let is_cleanup = data.is_cleanup;
         data.retain_statements(|s| match s.kind {
             StatementKind::StorageLive(l) | StatementKind::StorageDead(l) => {    
-                !self.remap.contains_key(&l)
+                !is_cleanup && !self.remap.contains_key(&l)
             }
             _ => true,
         });

Output with -Cllvm-args=--print-before-all: log.zip (23 MB unzipped)

Dubious llvm transform?

LLVM appears to have created a phi-node that references it

Before (line 311985 of the output):

115:                                              ; preds = %61, %59, %57
  %116 = phi i8* [ %44, %61 ], [ %44, %59 ], [ %53, %57 ]
  %117 = phi %"core::future::from_generator::GenFuture<llvm_ice::foo::{{closure}}<core::future::from_generator::GenFuture<llvm_ice::run::{{closure}}::{{closure}}::{{closure}}>, llvm_ice::run::{{closure}}::{{closure}}>>.0"* [ %24, %61 ], [ %24, %59 ], [ %55, %57 ]
  %118 = phi i8* [ %21, %61 ], [ %21, %59 ], [ %54, %57 ]
  %119 = cleanuppad within none []
  call void @llvm.lifetime.end.p0i8(i64 24, i8* nonnull %116)
  cleanupret from %119 unwind label %120

120:                                              ; preds = %115, %112, %106
  %121 = phi %"core::future::from_generator::GenFuture<llvm_ice::foo::{{closure}}<core::future::from_generator::GenFuture<llvm_ice::run::{{closure}}::{{closure}}::{{closure}}>, llvm_ice::run::{{closure}}::{{closure}}>>.0"* [ %117, %115 ], [ %84, %112 ], [ %84, %106 ]
  %122 = phi i8* [ %118, %115 ], [ %85, %112 ], [ %85, %106 ]
  %123 = cleanuppad within none []
  %124 = getelementptr inbounds [24 x i8], [24 x i8]* %9, i64 0, i64 0
  call void @llvm.lifetime.end.p0i8(i64 24, i8* nonnull %124)
  %125 = getelementptr inbounds [7 x i8], [7 x i8]* %10, i64 0, i64 0
  call void @llvm.lifetime.end.p0i8(i64 7, i8* nonnull %125)
  store i8 2, i8* %122, align 8
  cleanupret from %123 unwind label %254

After (line 312511 of the output):

115:                                              ; preds = %57, %59, %61, %112, %106
  %116 = phi %"core::future::from_generator::GenFuture<llvm_ice::foo::{{closure}}<core::future::from_generator::GenFuture<llvm_ice::run::{{closure}}::{{closure}}::{{closure}}>, llvm_ice::run::{{closure}}::{{closure}}>>.0"* [ %84, %112 ], [ %84, %106 ], [ %24, %61 ], [ %24, %59 ], [ %55, %57 ]
  %117 = phi i8* [ %85, %112 ], [ %85, %106 ], [ %21, %61 ], [ %21, %59 ], [ %54, %57 ]
# %118 being referenced in its own definition?
  %118 = phi i8* [ %44, %61 ], [ %44, %59 ], [ %53, %57 ], [ %118, %112 ], [ %118, %106 ]
  %119 = cleanuppad within none []
  %120 = getelementptr inbounds [24 x i8], [24 x i8]* %9, i64 0, i64 0
  call void @llvm.lifetime.end.p0i8(i64 24, i8* nonnull %120)
  %121 = getelementptr inbounds [7 x i8], [7 x i8]* %10, i64 0, i64 0
  call void @llvm.lifetime.end.p0i8(i64 7, i8* nonnull %121)
  store i8 2, i8* %117, align 8
  cleanupret from %119 unwind label %246

matthewjasper picture matthewjasper on 8 Jun 2020
👍2

@pnkfelix given that this has been already reverted, I guess we may want to remove P-critical, right? and leave the issue open, probably with a different priority to find a better proper fix.

spastorino picture spastorino on 10 Jun 2020

The revert has been applied to both master and beta. Downgrading priority to P-high.

spastorino picture spastorino on 17 Jun 2020

Same Error.
this problem is not solved yet?

@spastorino @pnkfelix 

⨯ ⚡ Administrator@x  G:\work   master ≣ +1 ~0 -0 !                                                                                                                                                 [16:28]
❯ rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\Administrator\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)

installed targets for active toolchain
--------------------------------------

x86_64-pc-windows-gnu
x86_64-pc-windows-msvc

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.44.1 (c7087fe00 2020-06-17)


⚡ Administrator@x  G:\work   master ≣ +1 ~0 -0 !                                                                                                                                                   [16:28]
❯ cargo build --release
   Compiling xxxxx v0.1.0 (G:\work)
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
Instruction does not dominate all uses!
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
  %917 = phi i8* [ %122, %121 ], [ %134, %842 ], [ %134, %965 ], [ %134, %846 ], [ %134, %964 ], [ %134, %849 ], [ %917, %772 ], [ %917, %762 ], [ %917, %953 ], [ %917, %922 ], [ %917, %808 ], [ %917, %804 ], [ %917, %788 ], [ %917, %786 ]
in function _ZN97_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$4poll17hdcdcba61c9bee376E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `rust-template`.
xtutu picture xtutu on 19 Jun 2020

(checking if I can replicate @xtutu 's observations locally now)

pnkfelix picture pnkfelix on 1 Jul 2020

oddly enough, I have having trouble creating the original bug atop the listed versions of rustc. (So weird!)

  • Oh, of course: I was trying to do cargo build --release instead of cargo test --release, but the latter is what is required. (Which makes sense, given @matthewjasper 's observations about needing multiple crates and LTO etc.)

In the meantime, while I resolve that oddity: @xtutu , can you post a link to the source for the crate where you are observing this occurrence of the LLVM error here?

pnkfelix picture pnkfelix on 1 Jul 2020

Hi, @pnkfelix You can check the difference between the two commits.

https://github.com/xtutu/temp-rust-debug

image

xtutu picture xtutu on 14 Jul 2020

@xtutu I tried to reproduce the problem in a Windows VM with your temp-rust-debug repository, but I was not able to do so at the commits you highlighted.

There's one more factor I haven't accounted for: Changes to crate dependencies. Can you check-in a Cargo.lock file into temp-rust-debug, one that shows the problem atop 3e9935f4d1b361ac557?

pnkfelix picture pnkfelix on 24 Jul 2020

Hi @pnkfelix ， I add Cargo.lock now.

xtutu picture xtutu on 27 Jul 2020

Thanks @xtutu ! I was able to replicate the LLVM assertion now with that Cargo.lock in place! (And of course, I had to remember to do cargo build --release instead of a debug build. 😉 )

pnkfelix picture pnkfelix on 27 Jul 2020

I've narrowed the rust-template crate itself down to this pair of files: a main.rs and a Cargo.toml that specifies the precise version of tokio one needs to use to replicate the problem:

// src/main.rs
use tokio;
use std::error::Error;
use std::sync::Mutex;

#[allow(dead_code)]
enum Msg {
    A(Vec<()>),
    B,
}

#[allow(unused_must_use)]
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let (_, mut rx) = tokio::sync::mpsc::unbounded_channel::<Msg>();
    let entity = Box::new(Mutex::new(()));

    tokio::spawn(async move {
        tokio::select! {
            Some(msg) = rx.recv() => {
                entity.lock();
                drop(msg);
            }
        }
        entity.lock();
    });

    return Ok(());
}

# Cargo.toml
[package]
name = "rust-template"
version = "0.1.0"
authors = ["linyongxing <[email protected]>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

default-run = "rust-template"

[dependencies]
tokio = { version = "=0.2.21", features = ["rt-core", "macros", "sync"] }

With these two files in a fresh crate, I get this from a release build (still on Windows, keep in mind, with stable rustc 1.44.1 c7087fe00):

> cargo build --release
    Updating crates.io index
   Compiling proc-macro2 v1.0.19
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.36
   Compiling bytes v0.5.6
   Compiling fnv v1.0.7
   Compiling pin-project-lite v0.1.7
   Compiling quote v1.0.7
   Compiling tokio-macros v0.2.5
   Compiling tokio v0.2.21
   Compiling rust-template v0.1.0 (C:\Users\pfxbo\temp-rust-debug\rust-template)
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
Instruction does not dominate all uses!
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
  %182 = phi i8* [ %92, %91 ], [ %55, %190 ], [ %182, %89 ], [ %182, %85 ], [ %182, %187 ], [ %182, %112 ], [ %182, %108 ], [ %182, %105 ], [ %182, %101 ]
in function _ZN97_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h257417a290b49d85E
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `rust-template`.

To learn more, run the command again with --verbose.
pnkfelix picture pnkfelix on 28 Jul 2020
👍1

We've been running into this error using Windows MSVC on our work codebase. I've been able to pin down the regression to the Rust 1.44.0 which was part of https://github.com/rust-lang/rust/pull/69033. We've not observed this error occurring on Linux, MacOS, FreeBSD, or Windows-GNU.

cc/ @jonas-schievink

Error

Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %132197 ], [ %13219, %12944 ]
Instruction does not dominate all uses!
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
  %13219 = phi i8* [ %13219, %13235 ], [ %13219, %13233 ], [ %13219, %13230 ], [ %13219, %13227 ], [ %13219, %13224 ], [ %13219, %13221 ], [ %13219, %12592 ], [ %13219, %12707 ], [ %12837, %12834 ], [ %12831, %12827 ], [ %13219, %12944 ]
in function _ZN8tiberius3tds6stream5token20TokenStream$LT$S$GT$10try_unfold28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17hbf00841fdd51402aE.llvm.12308354007712700541
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `quaint`.

After this error the usual error of Instruction does not dominate all uses! in GenFuture follows. Instruction does not dominate all uses! is printed multiple times in our codebase.

Tested versions

I've tested a range of versions on several Windows machines. I reliably got the following results:

| version | result |
|---|---|
| 1.42.0 MSVC| Ok|
| 1.43.0 MSVC| Ok|
| 1.44.0 MSVC| Error |
| 1.44.1 MSVC| Error |
| 1.45.0 MSVC| Error |
| 1.45.1 MSVC| Error |

Repro

The main codebase at work is a rather large one and takes a while to compile. I haven't been able to pin this down to a specific dependency or file that triggers this error yet. Luckily our codebase is open source, which allows people to clone and build it. To do so do:

$ git clone [email protected]:prisma/prisma-engines.git
$ cd prisma-engines
$ cargo build --release

I don't believe we have any peer dependencies aside from a Rust MSVC toolchain to compile on Windows.

yoshuawuyts picture yoshuawuyts on 31 Jul 2020

prisma-engines has multiple C dependencies (libsqlite, zlib, libgit2), which means that cross-compiling it rather painful (from Linux to Windows, that is). I did further reduce the code posted by @pnkfelix above though, removing tokio's proc. macros in the process: https://github.com/jonas-schievink/llvm-error

I'll try to reduce that down further.

jonas-schievink picture jonas-schievink on 31 Jul 2020
❤1

I have now pushed a 2-file repro. I'll leave the rest to our LLVM experts.

jonas-schievink picture jonas-schievink on 1 Aug 2020
🎉2

I've filed two test cases on the repro:

It seems that switching the channel impl makes the error disappear. Whereas switching the block_on impl keeps it. According to @jonas-schievink in https://github.com/jonas-schievink/llvm-error/pull/1#issuecomment-668535630 the channel code is quite fragile, and changing any part of it makes the error disappear.

yoshuawuyts picture yoshuawuyts on 4 Aug 2020

Does this still reproduce with the latest nightly (LLVM 11)?

Aaron1011 picture Aaron1011 on 25 Sep 2020

On rustc 1.48.0-nightly (8b4085359 2020-09-23) I can't reproduce this

jonas-schievink picture jonas-schievink on 25 Sep 2020

A bisect shows that this was fixed by the upgrade to LLVM 11 in https://github.com/rust-lang/rust/pull/73526. I'm going to try-relanding the original PR.

Aaron1011 picture Aaron1011 on 2 Oct 2020

Fixed by #77466.

tmandry picture tmandry on 6 Oct 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

behnam picture behnam  ·  3Comments
lambda-fairy picture lambda-fairy  ·  3Comments
eddyb picture eddyb  ·  3Comments
tikue picture tikue  ·  3Comments
dwrensha picture dwrensha  ·  3Comments