<div dir="ltr">I'd still wonder if this meets the bar for false positives (generally we try to only add warnings that would be enabled by default, even in new codebases - where most of what they find in a newcodebase are latent bugs, not noise (so the cleanup is at least fairly justified as being beneficial in itself rather than only as a means to enable the warning to catch some bugs in the future))<br><br>But I know we made some exception for the &&/|| version of -Wparentheses, so maybe this variation meets that same bar. (if Richard Trieu doesn't have enough context to make that call, I'd probably rope in Richard Smith (& possibly Chandler Carruth - I recall him commenting on the &&/|| -Wparentheses form on more than one occasion))</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 27, 2016 at 10:01 AM Bruno Cardoso Lopes <<a href="mailto:bruno.cardoso@gmail.com">bruno.cardoso@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">bruno added a subscriber: bruno.<br class="gmail_msg">
bruno added a comment.<br class="gmail_msg">
<br class="gmail_msg">
Hi Daniel,<br class="gmail_msg">
<br class="gmail_msg">
This is very nice.<br class="gmail_msg">
<br class="gmail_msg">
In <a href="https://reviews.llvm.org/D24861#553606" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D24861#553606</a>, @danielmarjamaki wrote:<br class="gmail_msg">
<br class="gmail_msg">
> Compiling 2064 projects resulted in 904 warnings<br class="gmail_msg">
><br class="gmail_msg">
> Here are the results:<br class="gmail_msg">
>  <a href="https://drive.google.com/file/d/0BykPmWrCOxt2N04tYl8zVHA3MXc/view?usp=sharing" rel="noreferrer" class="gmail_msg" target="_blank">https://drive.google.com/file/d/0BykPmWrCOxt2N04tYl8zVHA3MXc/view?usp=sharing</a><br class="gmail_msg">
><br class="gmail_msg">
> The results looks acceptable imho. The code looks intentional in many cases so I believe there are users that will disable this warning. Probably there are true positives where the evaluation order is not really known. There were many warnings about macro arguments where the macro bitshifts the argument - these macros look very shaky to me.<br class="gmail_msg">
><br class="gmail_msg">
> I saw some warnings about such code:<br class="gmail_msg">
><br class="gmail_msg">
>   a * b << c<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Maybe we should not warn about this. As far as I see, the result will be the same if (a*b) or (b<<c) is evaluated first - unless there is some overflow or signedness issues. What do you think? I'll keep these warnings for now.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Any idea on how expensive would be to reason about these false positives and avoid them?<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Repository:<br class="gmail_msg">
  rL LLVM<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D24861" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D24861</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>