On Wed, Jul 18, 2012 at 4:51 PM, Richard Smith <[email protected]>wrote:
> On Wed, Jul 18, 2012 at 3:55 PM, Robinson, Paul <[email protected] > > wrote: > >> Guard use of a possibly uninitialized field. >> >> This was causing very unpredictable compiler crashes. I have not >> provided a test because even our most reliable reproducer still failed >> less than 10% of the time. >> >> I really really really don't like sometimes-uninitialized fields >> guarded by flags. It is not a robust practice and took us a couple of >> weeks of poking at it to find the root cause. But it is how the rest >> of SemaOverload handles this field, so we fixed it using the >> prevailing practice in the module. >> > > Do you know where the uninitialized OverloadCandidate is coming from? The > only place I can see one being created is in > OverloadCandidateSet::addCandidate, which says: > > Candidates.push_back(OverloadCandidate()); > > This zero-initializes the OverloadCandidate object. > I've checked in a variant on your change in r160470: it seems correct and appropriate even if FailureKind is always initialized, since we were previously implicitly and accidentally relying on ovl_fail_bad_deduction being nonzero.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
