[llvm-commits] PATCH: Fix non-deterministic debug info output for C++ inputs

[Chandler Carruth]

I'm adding Doug as this is changing the AST in a non-trivial way, and his
review is probably best there.

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.

On Wed, May 2, 2012 at 9:44 PM, Chandler Carruth <chandlerc at gmail.com>wrote:

> Hello folks,
>
> 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.
>
> There are a few possible solutions to this:
>
> 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.
>
> 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.
>
> 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.
>
>
> 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. =]
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120503/3e200af8/attachment.html>