[llvm] r214761 - Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

[David Blaikie]

Awesome - was able to reduce this to a debug info quality (in cases where
we don't tickle UB enough to crash) more consistently fixed it in r219210.
Thanks again for your patience/help.

The assertion now fires on a few test cases that it didn't before - but I
suspect that might just be some wrinkles from Adrian or Duncan's recent
schema changes, so I'll try bisecting to see when they regressed (since the
test cases are old and passed when I last tried to apply the assertions).

Thanks again,

- David

On Mon, Oct 6, 2014 at 2:16 PM, Reid Kleckner <rnk at google.com> wrote:

> Aha, this asserts on both Windows and Linux.
>
> On Mon, Oct 6, 2014 at 11:50 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Mon, Oct 6, 2014 at 11:39 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> That would be mighty unfortunate... :/ Perhaps we can find some
>>> assertions to put in to stabilize the failure, though I haven't a clue what
>>> they'd be just yet.
>>>
>>
>> I'm staring at the .ll file diff, trying to figure out what went wrong.
>> There are several small differences, and I wonder if they are for things
>> like order of evaluation, where the only difference is a use-list order
>> change.
>>
>> Yep, that test case doesn't produce an assertion for me. Crud. What's a
>>> useful way for me to debug this on a Windows machine? Am I just going to
>>> have to sit with you/someone - or can I get remote access somehow (from
>>> Linux, ideally?)?
>>>
>>
>> Most Windows remote access solutions tend to take over the primary
>> screen, unless you have some server OS variant, so if you want to debug it
>> directly you'd want to rig up a local VM. This is doable, there are
>> gwindows images you can fetch, but I'll let you know why I give up over
>> here. :)
>>
>> Here's the function we assert on:
>>
>> ; Function Attrs: noreturn nounwind
>> define internal void @"\01??$assert_cast at PAVRedeclarableTemplateDecl@clang@@@@YAPAVRedeclarableTemplateDecl at clang@@ZZ"() #4 {
>> entry:
>>   tail call void @"\01?llvm_unreachable_internal at llvm@@YAXPBD0I at Z"(i8* getelementptr inbounds ([16 x i8]* @"\01??_C at _0BA@OELEAIJA at bad?5assert_cast?$AA@", i32 0, i32 0), i8* getelementptr inbounds ([51 x i8]* @"\01??_C at _0DD@BABLEMGH@?4?4?2tools?2clang?2lib?2Serialization@", i32 0, i32 0), i32 2108) #12, !dbg !34160
>>   unreachable, !dbg !34160
>> }
>>
>> There are no diffs in the code, but here's some related debug info that
>> is suspiciously different:
>>
>> -!1590 = metadata !{metadata !"0x2e\00assert_cast<clang::NamespaceDecl *>\00assert_cast<clang::NamespaceDecl *>\00\002107\001\001\000\000\00256\001\002107", metadata !13, metadata !14, metadata !7, null, void ()* @"\01??$assert_cast at PAVRedeclarableTemplateDecl@clang@@@@YAPAVRedeclarableTemplateDecl at clang@@ZZ", null, null, metadata !2}
>> +!1590 = metadata !{metadata !"0x2e\00assert_cast<clang::NamespaceDecl *>\00assert_cast<clang::NamespaceDecl *>\00\002107\001\001\000\000\00256\001\002107", metadata !13, metadata !14, metadata !7, null, null, null, null, metadata !2} ; [ DW_TAG_subprogram ] [line 2107] [local] [def] [assert_cast<clang::NamespaceDecl *>]
>>
>> Thoughts?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141007/9f01af14/attachment.html>