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