[llvm-bugs] [Bug 42925] New: Assertion Failure ScalarEvolutionExpander.cpp:80: `SE.DT.dominates(Ret, &*BIP)' failed

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42925

            Bug ID: 42925
           Summary: Assertion Failure ScalarEvolutionExpander.cpp:80:
                    `SE.DT.dominates(Ret, &*BIP)' failed
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: warren_ristow at playstation.sony.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 22355
  --> https://bugs.llvm.org/attachment.cgi?id=22355&action=edit
reduced test-case

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:
  0. Program arguments: opt -O1 test.ll -S -o -
  1. Running pass 'CallGraph Pass Manager' on module 'test.ll'.
  2. Running pass 'Loop Pass Manager' on function '@foo'
  3. 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190807/34922a01/attachment-0001.html>