
<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=""><div><blockquote type="cite" class=""><div class="">On 20 Oct 2014, at 14:06, 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="">I've checked this out on the GDB test suite & it seems fine.<br class=""></div></div></blockquote><div><br class=""></div><div>Thanks a lot!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Looking at the code itself, I think it could be made a bit more obvious/uniform to have VariableDIE always refer to the definition and have just a single conditional to decide whether to attach the DW_AT_specification or not.<br class=""></div></div></blockquote><div><br class=""></div><div>I suppose that’s the diff you attached? I’ll review it tomorrow</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Actually this works pretty well & even adds another source fidelity benefit, allowing the definition, while out-of-line of the class, to be attributed to the scope in which the definition occurs (eg: namespace x { struct foo { static int i; }; int foo::i; } - putting the definition in namespace 'x' instead of just forcing it out to the global namespace) and exposes a bug in Clang where the definition is scoped to the decl context instead of the lexical context. (patch attached to show a slightly short-sighted fix there)<br class=""></div></div></blockquote><div><br class=""></div><div>I had seen that and I think I even know where the code is wrong. But the patch you attached for it isn’t the right one.</div><div><br class=""></div><div>Fred</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">If we did a few more smart things in the frontend, we could get better fidelity for declarations/definitions of namespace/global variables - removing the weird special case introduced with my patch. Probably the right thing here is to optimize in the frontend, if the definition appears in the decl context (eg: if the global variable's decl context is the same as the lexical context) then just produce the definition. If the decl and lexical context differ, produce both a declaration (in the decl context) and a definition (in the lexical context) - this would be the best source fidelity, but probably isn't too worthwhile.<br class=""><br class="">Oh, and if we wanted to be really good here, we could make sure we emit any attributes onto the definition that differ from the declaration - note GCC does the right thing here, putting DW_AT_decl_line/file on the definitions if the line/file happens to be different from the declaration's line/file. We don't do that - we just put nothing on the definition (& I don't think we do this for function declarations/definitions either (again, here, GCC gets this right)... could, but probably not important)<br class=""><br class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 16, 2014 at 8:46 AM, Frederic Riss <span dir="ltr" class=""><<a href="mailto:friss@apple.com" target="_blank" class="">friss@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">ping<br class="">

<br class="">

<a href="http://reviews.llvm.org/D5457" target="_blank" class="">http://reviews.llvm.org/D5457</a><br class="">

<br class="">

<br class="">

<br class="">

_______________________________________________<br class="">

llvm-commits mailing list<br class="">

<a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">

</blockquote></div><br class=""></div>

<span id="cid:F0900B11-B453-45F6-9356-4FE2A606C3B4@attlocal.net"><static_var_def.diff></span><span id="cid:30C37173-E967-483D-984C-4C7B18958E2D@attlocal.net"><global_var.diff></span></div></blockquote></div><br class=""></body></html>