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

[Chandler Carruth]

On Thu, May 3, 2012 at 11:39 AM, Chandler Carruth <chandlerc at gmail.com>wrote:

> 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.
>

FYI, after chatting on IRC, Doug OK-ed this patch.

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.


>
> 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/cfe-commits/attachments/20120503/7bd64107/attachment.html>