On Apr 11, 2013, at 6:34 PM, Chandler Carruth <[email protected]> wrote:
> On Thu, Apr 11, 2013 at 10:52 AM, John McCall <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to