<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 9:59 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Mar 24, 2015 at 12:51 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> REPOSITORY<br>
>   rL LLVM<br>
><br>
> ================<br>
> Comment at: cmake/modules/HandleLLVMOptions.cmake:286<br>
> @@ +285,3 @@<br>
> +    -wd4706 # Suppress 'assignment within conditional expression'<br>
> +    -wd4310 # Suppress 'cast truncates constant value'<br>
> +    -wd4701 # Suppress 'potentially uninitialized local variable'<br>
> ----------------<br>
> You mentioned this one fired ~200 times - this might actually be worth doing a small sample check to see what it's firing on. Perhaps these are things we should fix - unless they appear in dependent expressions in templates, in which case they're probably false positives.<br>
><br>
> The rest of these disables I'm totally fine with - if you want, please commit them separately/ahead of the rest of the review.<br>
><br>
> ================<br>
> Comment at: lib/Support/APFloat.cpp:1433<br>
> @@ -1432,3 +1432,3 @@<br>
>       an addition or subtraction.  */<br>
> -  subtract ^= sign ^ rhs.sign;<br>
> +  subtract ^= (sign ^ rhs.sign) != 0;<br>
><br>
> ----------------<br>
> andrew.w.kaylor wrote:<br>
>> This addresses warning C4805: unsafe mix of type <X> and type <Y> in operation.<br>
> This one's been fixed (slightly differently) by Aaron Ballman. We had some more discussions about the same issues/principles in that review thread too - I think he's OK with the idea of disabling this warning.<br>
<br>
</span>Yup, I am okay with disabling this one.<br>
<span class=""><br>
><br>
> ================<br>
> Comment at: lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp:641<br>
> @@ -640,3 +640,3 @@<br>
>    unsigned Op = ARM_AM::getAM5Op(MO2.getImm());<br>
> -  if (AlwaysPrintImm0 || ImmOffs || Op == ARM_AM::sub) {<br>
> +  if (ImmOffs || Op == ARM_AM::sub || AlwaysPrintImm0) {<br>
>      O << ", "<br>
> ----------------<br>
> andrew.w.kaylor wrote:<br>
>> This addresses warning C4189: local variable is initialized but not referenced.<br>
>><br>
>> AlwaysPrintImm0 is a template parameter that can short circuit the condition so that ImmOffs and Op are never referenced.<br>
> This seems like a step backwards, actually - we try to deliberately put the cheap tests first (and a compile time constant is the cheapest test). Granted any compiler worth its salt will kill the dead expressions, but there's no need to ask it to do that work.<br>
><br>
> I'm fairly strongly in favor of disabling this warning rather than making this code change.<br>
<br>
</span>Oye, that's a tough one. I agree with your logic, but at the same<br>
time, initialized variables that are unused is a bad code smell. In<br>
this case, the warning found two true positives, for instance.<br></blockquote><div><br>I think it's probably best to catch the two true positives with a different warning (it's not obvious from the code that they're unused - since they're used to call (albeit static) member functions). I think it'd be reasonable to add such a warning to clang, but it doesn't seem like a high priority (given we only had two instances in all of Clang - well, two instances that involved otherwise unused variables - but we could catch the rest too). But it'd probably just be a clang-tidy check, it's not really a bug to use a static function as a member function call - it's just a bit weird.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> ================<br>
> Comment at: lib/Target/NVPTX/NVPTXAsmPrinter.cpp:507<br>
> @@ -506,4 +506,3 @@<br>
>    unsigned RegNo = MI->getOperand(0).getReg();<br>
> -  const TargetRegisterInfo *TRI = nvptxSubtarget->getRegisterInfo();<br>
> -  if (TRI->isVirtualRegister(RegNo)) {<br>
> +  if (TargetRegisterInfo::isVirtualRegister(RegNo)) {<br>
>      OutStreamer.AddComment(Twine("implicit-def: ") +<br>
> ----------------<br>
> andrew.w.kaylor wrote:<br>
>> This addresses warning C4189: local variable is initialized but not referenced.<br>
>><br>
>> Because isVirtualRegister() is a static function, the TRI variable was not actually referenced.<br>
> The code change is good, the motivation is questionable - I'd probably fix the code but still disable the warning. A clang-tidy check for calling static functions from a non-static context might be nice to have, but it doesn't really raise to the level of compiler warning.<br>
<br>
</span>Not everyone runs clang-tidy (unless we have a bot that would catch<br>
these issues). Also, that diagnostic triggers for other true<br>
positives, like:<br>
<br>
void f() {<br>
  int i = 12;<br>
  // Did we forget something here?<br>
<span class="">}<br></span></blockquote><div><br>Clang's -Wunused-variable already catches this, so the codebase isn't going to end up violating this constraint for very long.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
><br>
> ================<br>
> Comment at: tools/llvm-c-test/metadata.c:21<br>
> @@ -21,1 +20,3 @@<br>
> +  LLVMValueRef values[1];<br>
> +  values[0] = LLVMConstInt(LLVMInt32Type(), 0, 0);<br>
><br>
> ----------------<br>
> andrew.w.kaylor wrote:<br>
>> This addresses warning C4204: nonstandard extension used : non-constant aggregate initializer.<br>
> Clang has a warning for this (-Wc99-extensions) but we don't enable it, so I'd say it's reasonable to disable MSVC's equivalent for consistency. Unless someone wants to look at turning Clang's version on & seeing what breaks...<br>
<br>
</span>MSVC's nonstandard extensions tend to be more... interesting... to a<br>
cross-platform code base. I'd be curious to see what Clang's warning<br>
catches on our code base and whether we want to consider turning that<br>
warning on instead of turning MSVC's off. But I don't feel strongly on<br>
this one since bots are good at catching these problems when they<br>
really matter.<br></blockquote><div><br>Yeah, I mean if one of these warnings caught cases that would be errors on another (supported) compiler I'd say we keep it, but otherwise it doesn't seem too important. Maybe other people have other ideas/like the idea of being more stringent here (I know compiler-rt compiles with -pedantic, not sure when/why/how that choice was made).<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> <a href="http://reviews.llvm.org/D8572" target="_blank">http://reviews.llvm.org/D8572</a><br>
><br>
> EMAIL PREFERENCES<br>
>   <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>