<div dir="rtl"><div dir="ltr">It's fairly quick to workaround a warning compared with much more time identifying and debugging a real bug, so in total it is more efficient to keep even high false positive rate warnings enabled.</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-03-27 20:31 GMT+03:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So a while back we took a moderately aggressive stance on disabling GCC warnings with false positives, specifically those related to uninitialized variables. In cases where GCC suggested initializing a variable yet the algorithm was safely initializing the variable, adding the GCC-suggested initialization could thwart tools like MSan/ASan. So it was suggested that we should not abide by GCC's warning and rely on Clang's more carefully limited warning without the problematic false positives.<br><br>Recently Andy Kaylor's been working on getting the MSVC build warning clean by a combination of disabling warnings and fixing a few cases of relatively low frequency.<br><br>I've generally been encouraging people to aggressively disable non-clang warnings whenever there's a false positive (anything other than a bug, or at least anything that doesn't strictly improve readability) and one such instance of this is in the review for r233088 which amounts to something like:<br><br>template<typename T><br>int func(T t) {<br>  return t.func() >> 8;<br>}<br><br>(it's more complicated than that, but this is the crux of it) - for some instantiations of this template, T::func returns an 8-bit type, and MSVC warns that the shift will produce a zero value. The code is correct (the author intended this behavior, because some instantiations produce a wider-than-8-bit- type and the higher bits are desired, if present).<br><br>I suggested disabling this warning, but that would mean we miss out on the true positives as well (Clang doesn't seem to have any warning like this), though we haven't seen these very often.<br><br>How do people feel about working around this warning so we can keep it enabled?<br>How do people feel about disabling this warning?<br>How do people feel about disabling other non-Clang warnings which have false positives?<br><br>(in the case of Clang warnings with false positives we should take the same approach, except we also have the option to improve the quality of the warning by fixing Clang, which is what we generally try to do)<span class="HOEnZb"><font color="#888888"><br><br>- David</font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>