[llvm] r297072 - Verifier: Change Assert to AssertDI.

[David Blaikie via llvm-commits]

Fair enough - in LTO I can understand the default being "silently drop" -
and we don't have good argument plumbing such that it's easy for it to have
a different default... :/ which is lame.

On Mon, Mar 6, 2017 at 2:59 PM Adrian Prantl <aprantl at apple.com> wrote:

> On Mar 6, 2017, at 2:45 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Mar 6, 2017 at 2:36 PM Adrian Prantl <aprantl at apple.com> wrote:
>
> On Mar 6, 2017, at 2:21 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Mar 6, 2017 at 1:17 PM Adrian Prantl via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: adrian
> Date: Mon Mar  6 15:05:14 2017
> New Revision: 297072
>
> URL: http://llvm.org/viewvc/llvm-project?rev=297072&view=rev
> Log:
> Verifier: Change Assert to AssertDI.
> This error can be recovered from by stripping debug info.
> This is NFC for +asserts builds.
>
>
> Is there no way in a +Asserts build to get the behavior of "if debug info
> doesn't verify, strip it"? That seems... bad (untestable codepath that
> someone's relying on?).
>
>
> The behavior is still there, but the assertion fires first :-)
>
>
> Schrodinger's behavior - it's untested, it might work, might not - who
> knows?
>
>
> We treat debug info verification errors as recoverable by stripping the
> debug info. But when assertions are enabled, we assert that even the debug
> info is correct. This allows us to find, e.g., bitcode upgrade bugs with
> asserts-enabled compilers during compiler qualification.
>
> It is true that we cannot test the stripping behavior with assertions
> enabled. I had a vague memory that there was a command line option to force
> the noasserts behavior for some tools, but I must have misremembered or
> didn't find it.
>
>
> Ha! I found it:
>
> cl::opt<bool> LTOStripInvalidDebugInfo(
>     "lto-strip-invalid-debug-info",
>     cl::desc("Strip invalid debug info metadata during LTO instead of
> aborting."),
> #ifdef NDEBUG
>     cl::init(true),
> #else
>     cl::init(false),
> #endif
>     cl::Hidden);
>
> with that I should be able to create a testcase for this change, too.
>
>
> Please fix this or remove the fallback behavior. I'd personally prefer
> none of this goes behind an asserts modifier, but have a flag that makes it
> a "hard stop" or "silently drop" (is the hard stop behavior at all? Would a
> warning suffice? (a warning that could be promoted to error or demoted to
> silence would be ideal - but I realize LLVM's tools, etc, don't have that
> level of warning control, so depending on where/how this is all implemented
> that may not be practical))
>
>
> That's pretty much the problem. This typically occurs during LTO where we
> don't have an amazing level of control, because it is in libLTO and driven
> by the linker.
>
> -- adrian
>
>
> - Dave
>
>
>
> -- adrian
>
>
>
>
> Modified:
>     llvm/trunk/lib/IR/Verifier.cpp
>
> Modified: llvm/trunk/lib/IR/Verifier.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=297072&r1=297071&r2=297072&view=diff
>
> ==============================================================================
> --- llvm/trunk/lib/IR/Verifier.cpp (original)
> +++ llvm/trunk/lib/IR/Verifier.cpp Mon Mar  6 15:05:14 2017
> @@ -2734,9 +2734,9 @@ void Verifier::verifyCallSite(CallSite C
>    // do so causes assertion failures when the inliner sets up inline
> scope info.
>    if (I->getFunction()->getSubprogram() && CS.getCalledFunction() &&
>        CS.getCalledFunction()->getSubprogram())
> -    Assert(I->getDebugLoc(), "inlinable function call in a function with
> debug "
> -                             "info must have a !dbg location",
> -           I);
> +    AssertDI(I->getDebugLoc(), "inlinable function call in a function
> with "
> +                               "debug info must have a !dbg location",
> +             I);
>
>    visitInstruction(*I);
>  }
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170306/85afdd36/attachment.html>