[llvm-bugs] [Bug 42773] New: [DebugInfo] ICE from inconsistent LiveDebugValues state

[via llvm-bugs]

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

            Bug ID: 42773
           Summary: [DebugInfo] ICE from inconsistent LiveDebugValues
                    state
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: aprantl at apple.com, chackz0x12 at gmail.com,
                    llvm-bugs at lists.llvm.org, orlando.hyams at sony.com,
                    paul.robinson at am.sony.com, stephen.tozer at sony.com,
                    vsk at apple.com, Wolfgang_Pieb at playstation.sony.com

Created attachment 22293
  --> https://bugs.llvm.org/attachment.cgi?id=22293&action=edit
Crash reproducer

While building clang-3.4 with asan (for various reasons) I ran into an
assertion failure when building llvm-3.4's SparcISelLower.cpp. I'm using
clang/llvm trunk @ r366789, building the old copy of clang in RelWithDebInfo
mode and -fsanitize=address added to CXXFLAGS, and using a pre-built version of
tblgen because old-tblgen doesn't work under asan. I'm attaching a modified
version of live-debug-values-restore.mir that reproduces the crash

In r363256 [0] I added fragment-tracking to LiveDebugValues, so that
independent variable fragments would be tracked independently. This builds a
map of which-fragments-overlap-others at the start. However, it seems I missed
the fact that the spill-restorer [1] creates an empty expression when restoring
from a stack slot. This introduces DBG_VALUEs with no fragment to the mix,
_after_ the overlap map has been built.

In the attached reproducer (the "g" function, see the MIR) I spill-and-restore
a fragment in block %bb.1, which erronously becomes a DBG_VALUE with no
fragment. In %bb.2 another spill and restore happens in a slightly different
location; what happens then is:
 * ProcessVarLoc [2] closes the open range of the {32,32} fragment
 * A new location is inserted into the open ranges [3], however, it doesn't 
   "take" because the new DBG_VALUE with no fragment is already open.
 * We now have two open machine locations, but only one open variable;
   assertions galore fire.

Part of the problem is ProcessVarLoc using two DBG_VALUEs as sources of the
fragment, but a mix of no-fragment/fragmented DBG_VALUEs is going to fire
assertions later in compilation anyway.

It's awkward / difficult to recover the correct expression for [1], see bug
42772. IMO the best fix for now is to give [1] the correct fragment, even if
some of the overall expression is lost. A bad location is strictly better than
the compiler crashing.

This is also in the 9.0 release, so I'll submit a pull-up at some point.

[0] https://reviews.llvm.org/rL363256
[1]
https://github.com/llvm/llvm-project/blob/12aca5de026bd15663596c392ac828f8078bca6b/llvm/lib/CodeGen/LiveDebugValues.cpp#L696
[2]
https://github.com/llvm/llvm-project/blob/12aca5de026bd15663596c392ac828f8078bca6b/llvm/lib/CodeGen/LiveDebugValues.cpp#L638
[3]
https://github.com/llvm/llvm-project/blob/12aca5de026bd15663596c392ac828f8078bca6b/llvm/lib/CodeGen/LiveDebugValues.cpp#L641

-- 
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/20190726/e7fc2d88/attachment-0001.html>