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 <[email protected]>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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
