[cfe-commits] [PATCH] Fix random crasher

[Robinson, Paul]

Thanks!



I am not familiar with valgrind, but I suppose I could learn, if

there is still interest in a test case that triggers it.

--paulr



________________________________
From: metafoo at gmail.com [metafoo at gmail.com] on behalf of Richard Smith [richard at metafoo.co.uk]
Sent: Wednesday, July 18, 2012 4:54 PM
To: Robinson, Paul
Cc: cfe-commits at cs.uiuc.edu
Subject: Re: [cfe-commits] [PATCH] Fix random crasher

On Wed, Jul 18, 2012 at 4:51 PM, Richard Smith <richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>> wrote:
On Wed, Jul 18, 2012 at 3:55 PM, Robinson, Paul <Paul.Robinson at am.sony.com<mailto:Paul.Robinson at am.sony.com>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120719/60be308d/attachment.html>