On Thu, May 3, 2012 at 11:39 AM, Chandler Carruth <[email protected]>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 <[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
