<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Mar 7, 2017, at 11:19 AM, 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=""><div dir="ltr" class="gmail_msg">Ah, I see - might be worth a comment in the test case to describe a bit more about what it's aiming for?<br class=""><br class="">& would this suffice?<br class=""><br class=""><div dir="ltr" class="gmail_msg">void sink();</div><div dir="ltr" class="gmail_msg">inline __attribute__((always_inline)) void f1(int) {</div><div dir="ltr" class="gmail_msg"> sink();</div><div dir="ltr" class="gmail_msg">}</div><div dir="ltr" class="gmail_msg">void f2() {</div><div dir="ltr" class="gmail_msg"> f1(0);</div><div dir="ltr" class="gmail_msg"> f1(0);</div><div class="gmail_msg">}<br class=""><br class="">(if that's not sufficient, then perhaps the verifier needs to be made stronger to catch this case where they're actually different variables even though they're represented by the same DILocalVariable? (two different inlinings) - or I guess this case it got correct for free/accidentally because it was the same variable object)<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>The verifier is not smart enough to catch this, no. It also can't catch conflicts for inlined variables. It's a trade-off for speed. Currently it uses constant time lookups, if we support looking into inlined functions we'd have to use DenseMap lookups instead, and I was afraid this might blow up on, e.g., boost code.</div><div><br class=""></div>-- adrian</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="">Anyway, all good (:</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017 at 11:00 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="gmail_msg" target="_blank">aprantl@apple.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 7, 2017, at 10:58 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="gmail_msg m_8292515682058266832m_-6364127514350684656Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Ah, it might be more obvious if one of 'f' or 'g' was left standalone/non-inline, then? Or perhaps I'm not fully understanding the conflict being tested for? Two args with the same name but different arg objects in the same function?<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">The name is not relevant. The condition is two args with different variables that both claim to be argNo: 1 and are not inlined.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- adrian</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><br class="gmail_msg">OK, so I can see why that would require two inlinings, if that's the case. Thanks for explaining!</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017 at 10:49 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="gmail_msg" target="_blank">aprantl@apple.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">Because the outermost function is nodebug and we need at least two function args to create a conflict.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">-- adrian</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 7, 2017, at 10:47 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="gmail_msg m_8292515682058266832m_-6364127514350684656m_4785047271789843433Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg">Thanks! Any idea why it requires both 'f' and 'g' to reproduce this?<br class="gmail_msg"><br class="gmail_msg">(& I imagine the return values probably aren't needed?)</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Mar 7, 2017 at 10:39 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="gmail_msg" target="_blank">aprantl@apple.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I replaced it with a smaller, hand-crafted testcase in r297176.<br class="gmail_msg">
<br class="gmail_msg">
-- adrian<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>
</div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div>
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></body></html>