<div class="gmail_quote">On Thu, May 3, 2012 at 11:39 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm adding Doug as this is changing the AST in a non-trivial way, and his review is probably best there.<div><br></div><div>Also, Bill, I'm CC-ing you because I'm worried this might be a release blocker... The bug has been here for a long time, I'm not even sure if its a regression, but we noticed this in the wild (not with contrived code), and non-deterministic output seems really really bad.<br>
</div></blockquote><div><br></div><div>FYI, after chatting on IRC, Doug OK-ed this patch.</div><div><br></div><div>He also didn't think it was likely a release blocker. If anyone disagrees or cares greatly about the deterministic output of debug info in 3.1, give a shout.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br><div class="gmail_quote"><div><div class="h5">On Wed, May 2, 2012 at 9:44 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hello folks,<div><br></div><div>We found a pretty gross bug. Turns out debug information for template methods of template classes can, in some specific circumstances, end up with non-deterministic output. The cause is the fact that the specializations for a function template are stored in a FoldingSet which has non-deterministic iteration order. At one point, the debug info generation needs to emit information for all function template specializations, and walks this to do so.</div>


<div><br></div><div>There are a few possible solutions to this:</div><div><br></div><div>1) Sort the specializations by their mangled name. This is really only a partial solution as it doesn't fix cases where there *is* no accurate family name: consider if the class template is function local, etc. Also, it leaves a land-mine waiting for the next person to iterate over this particular interface in the AST.</div>


<div><br></div><div>2) We could add a sequence number to each specialization and then copy all of them to a vector, sorting before we walk the list of them. This is somewhat tempting, and appears to be used in at least one other place, but it makes iteration extremely expensive, and again, penalizes every future user of the AST's API.</div>


<div><br></div><div>3) The solution I settled on was to build a data structure that better suits this use case. The desired iteration order is the insertion order, which SetVector models cleanly, but we don't have a FoldingSetVector. That said, it is very easy to add. =] I've done so, and used it to fix the issue. See the two attached patches, one which introduces this ADT, and the other uses it in Clang.</div>


<div><br></div><div><br></div><div>I've included a contrived test case that exercise the non-determinism. It also appears to be a fantastic test case at exercising other parts of LLVM/Clang, as plugging in large numbers and running the optimizer is... very very slow. =]</div>


<br></div></div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br>