<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 9, 2015, at 12:20 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 9, 2015 at 11:52 AM, Adrian Prantl <span dir="ltr" class=""><<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">FYI: I’m hitting this assertion on today’s ToT with the following program:<div class=""><br class=""></div><div class=""><div class="">@protocol NSObject</div><div class="">@end</div><div class="">@interface NSObject <NSObject></div><div class="">@end</div><div class="">int printf(const char * __restrict, ...);</div><div class="">struct Foo</div><div class="">{</div><div class=""> int mId;</div><div class=""><span style="white-space:pre-wrap" class=""> </span>~Foo(){ </div><div class=""> printf("~Foo(%d)\n", mId);</div><div class=""> };</div><div class="">};</div><div class="">@interface TNSObject : NSObject</div><div class="">{</div><div class=""><span style="white-space:pre-wrap" class=""> </span>Foo _cppObjectNonAtomic;</div><div class="">}</div><div class="">@property (assign, readwrite, nonatomic) const Foo& cppObjectNonAtomic;</div><div class="">@end</div><div class="">@implementation TNSObject</div><div class="">- (id)init</div><div class="">{</div><div class=""><span style="white-space:pre-wrap" class=""> </span>Foo cppObject;</div><div class=""> self.cppObjectNonAtomic = cppObject;</div><div class="">}</div><div class="">@end</div><div class=""><br class=""></div><div class="">$ clang "-cc1" "-triple" "x86_64-apple-macosx10.10.0" "-emit-obj" "-gdwarf-2" "-stdlib=libc++" "-Os" "-fexceptions" "-x" "objective-c++" <a href="http://test1.mm/" target="_blank" class="">test1.mm</a></div><div class=""><br class=""></div><div class="">Looks like ~Foo() is getting inlined into [TNSObject init] without the scope being updated with an InlinedAt location. I’ll keep digging.</div></div></div></blockquote></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">I'll be reverting this shortly - there's a bunch of regressions of a similar flavor recorded on the relevant bug, but any reduced test cases will be handy when trying to ensure everything's covered before I recommit.<br class=""><br class="">The 'root cause' in (almost?) all of these should be something like this:<br class=""><br class="">1) a function with debug info (a function appearing in the CU's subprogram list) calls<br class="">2) another function with debug info through<br class="">3) a call instruction with no debugloc<br class=""></div></div></div></div></div></blockquote><div><br class=""></div>In the particular case I posted above, the problem appears to be with the call to ~Foo from within the landingpad:</div><div><br class=""></div><div><div>lpad: ; preds = %entry</div><div> %4 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)</div><div> cleanup</div><div> %5 = extractvalue { i8*, i32 } %4, 0</div><div> store i8* %5, i8** %exn.slot</div><div> %6 = extractvalue { i8*, i32 } %4, 1</div><div> store i32 %6, i32* %ehselector.slot</div><div> invoke void @_ZN3FooD1Ev(%struct.Foo* %cppObject)</div><div> to label %invoke.cont1 unwind label %terminate.lpad ; Note that none of the insns in the landingpad have a DebugLoc</div><div><br class=""></div><div>which after inlining turns into </div><div><br class=""></div><div><div>lpad: ; preds = %entry</div><div> %3 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)</div><div> cleanup</div><div> call void @llvm.dbg.value(metadata %struct.Foo* %cppObject, i64 0, metadata !64, metadata !76), !dbg !93</div><div> call void @llvm.dbg.value(metadata %struct.Foo* %cppObject, i64 0, metadata !94, metadata !76), !dbg !96</div><div> %mId.i.i3 = getelementptr inbounds %struct.Foo* %cppObject, i64 0, i32 0, !dbg !97</div><div> %4 = load i32* %mId.i.i3, align 4, !dbg !97, !tbaa !88</div><div> %call.i.i45 = invoke i32 (i8*, ...)* @_Z6printfPKcz(i8* getelementptr inbounds ([10 x i8]* @.str, i64 0, i64 0), i32 %4) #6</div><div> to label %eh.resume unwind label %terminate.lpad, !dbg !97</div><div><br class=""></div><div>!97 = !{i32 10, i32 0, !87, !95}</div><div>!95 = !{i32 9, i32 0, !62, null} <-- wrong. Should be _ZN3FooD2Ev inlined into _ZN3FooD1Ev</div><div class=""><br class=""></div><div class="">One one hand this is a bug in InlineFunction.cpp:fixupLineNumbers(), but we could also attach DebugLocs to those instructions in CFE in the first place.</div><div class=""><br class=""></div><div class="">-- adrian</div></div><div><br class=""></div><div></div></div></body></html>