search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.87k stars 11.92k forks source link

Assertion Failure ScalarEvolutionExpander.cpp:80: `SE.DT.dominates(Ret, &*BIP)' failed #42270

Open wjristow opened 5 years ago

wjristow commented 5 years ago
Bugzilla Link 42925
Version trunk
OS All
Blocks llvm/llvm-project#44654
Attachments reduced test-case
CC @berolinux,@fhahn,@zmodem,@tstellar,@yuanfang-chen

Extended Description

The attached test-case hits an assertion failure in Induction Variable Simplification, when optimized at -O1:

$ opt -O1 test.ll -S -o - opt: ..../llvm/lib/Analysis/ScalarEvolutionExpander.cpp:80: llvm::Value llvm::SCEVExpander::ReuseOrCreateCast( llvm::Value, llvm::Type, llvm::Instruction::CastOps, llvm::BasicBlock::iterator): Assertion `SE.DT.dominates(Ret, &BIP)' failed. Stack dump:

  1. Program arguments: opt -O1 test.ll -S -o -
  2. Running pass 'CallGraph Pass Manager' on module 'test.ll'.
  3. Running pass 'Loop Pass Manager' on function '@foo'
  4. Running pass 'Induction Variable Simplification' on basic block '%do.body' ... $

Bisecting shows that this problem first appeared with r320700, although that's a valid commit, and it's clear that it just exposed a bug that was latent. It still happens with ToT (tested with r368100).

FTR, the IR of the test-case contains code that clearly would deref a nullptr at run-time if it were to be executed. Specifically, it contains:

define void @​foo(i8* %arg) { entry: %stack_var = alloca i32, align 4 br label %do.body

do.body: ; preds = %do.body, %entry %tmp3.0 = phi i32 [ 0, %entry ], [ %tmp2, %do.body ] %tmp4.0 = phi i8 [ null, %entry ], [ %add.ptr, %do.body ] %tmp1 = load i8, i8 %tmp4.0, align 1 ... }

I haven't been able to come up with a crashing test-case that's "clean" (in the sense it does not have this nullptr deref problem). So maybe it's rooted in that. For reference, the original test-case prior to reducing, had a formal argument feeding into that PHI node in the definition of the full function, rather than an explicit null. The problem as reported by the customer only happened when LTO was on, and cross-module inlining exposed it. I tried analyzing the callers in the original bitcode, to see whether I could determine if a nullptr could be deduced to reach a call-site (and so there would be Undefined Behavior at run-time), but I wasn't able to figure that out. My guess is that that's what's happening. Regardless, of course a compile-time crash isn't how we want to handle Undefined Behavior.

tstellar commented 2 years ago

mentioned in issue llvm/llvm-project#44654

wjristow commented 4 years ago

Has this been fixed?

Unfortunately no.

I just tested it with ToT (llvmorg-11-init-18307-g1fed131660b), and it still crashes in Induction Variable Simplification.

tstellar commented 4 years ago

Has this been fixed?

tstellar commented 4 years ago

Rui, is this OK to merge?

https://github.com/tstellar/llvm-project/pull/114/files

Sorry, posted this on the wrong bug.

tstellar commented 4 years ago

Rui, is this OK to merge?

https://github.com/tstellar/llvm-project/pull/114/files

berolinux commented 4 years ago

Also reproducible on current 10.0 branch in Linux with this C snippet:

a[]; b() { int c; void *d = c = 0; for (;; c++) { e(a[c]); f(d++); } }