[PATCH] [ms-cxxabi] Implement codegen for dereferencing member pointers

[John McCall]

On Apr 11, 2013, at 6:34 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Apr 11, 2013 at 10:52 AM, John McCall <rjmccall at apple.com> wrote:
> >> +  llvm::BasicBlock *OriginalBB;
> >> +  llvm::BasicBlock *SkipAdjustBB;
> >>
> >> You'll need to zero-initialize these in order to pacify compiler warnings.
> >
> > OK.  There's been some debate on the list, and I wasn't sure which way to go.
> 
> It's pretty straightforward.  You need to zero-initialize things that are only
> conditionally initialized and used because you can't rely on warnings to be
> clever enough to detect correlated branches.
> 
> Er, no, I specifically have been arguing against this. My rule is much simpler: initialize it before each use.
> 
> Old versions of GCC had a -Wunitialized variant that always warned when there was both conditional initialization and conditional use and it couldn't prove that the predicates were correlated (often). Both Clang and modern GCC now only warn with -Wuninitialized when there is a statically demonstrable path through the function which causes an uninitialized use. The old behavior is sunk behind off-by-default flags in both compilers, and they should stay off because of how problematic the behavior is. I think we even have logic in the build systems for both LLVM and Clang to disable -Wuninitialized on sufficiently old versions of GCC.
> 
> If we were to just add dead stores to silence the warnings, we would also lose the ability to detect actual bugs when they arise with tools like Valgrind. While with a null pointer this might still be easy to debug, in many cases it makes things much harder than necessary to debug.

Okay;  I'm willing to accept that my knowledge of GCC is outdated.  If you're certain
that all the tools we care about hosting on have conservative enough -Wuninitialized
diagnostics that the correlated-branches problem is no longer a problem, then
I agree that we should do what we can to enable better dynamic checking.

I don't know how old "sufficiently old" is relative to the LLVM/clang stated baseline.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130411/07f43782/attachment.html>