<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 10:52 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank" class="cremed">rjmccall@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>> +  llvm::BasicBlock *OriginalBB;<br>
>> +  llvm::BasicBlock *SkipAdjustBB;<br>
>><br>
>> You'll need to zero-initialize these in order to pacify compiler warnings.<br>
><br>
> OK.  There's been some debate on the list, and I wasn't sure which way to go.<br>
<br>
</div>It's pretty straightforward.  You need to zero-initialize things that are only<br>
conditionally initialized and used because you can't rely on warnings to be<br>
clever enough to detect correlated branches.</blockquote><div><br></div><div style>Er, no, I specifically have been arguing against this. My rule is much simpler: initialize it before each use.</div><div style><br></div>
<div style>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.</div>
<div style><br></div><div style>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.</div>
</div></div></div>