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

[Chandler Carruth]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130411/c42c8a56/attachment.html>