<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 11:51 AM, Sanjay Patel <span dir="ltr"><<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hi Language Lawyers!<br><br>In PR23827 ( <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23827&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=17BngoQArftkINet3NRNu9WVFtBzGDM6quiH-_vyFTU&s=TVzKPGZzSHkGDgQLIbe15YwNCTM_cJ9c_5Zhevtot2Q&e=" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=23827</a> ), a bitwise op on booleans is considered equivalent to a logical op:<br> <br>  if ((x < 3) & (y > 10))<br><br>effectively becomes:<br> <br>  if ((x < 3) && (y > 10))<br><br>where x and y are of type 'int'. The second statement (&&) requires short-circuit evaluation to bypass the y comparison when the x comparison is false (creates an extra branch vs. the original code).<br><br>From N4296 -<span style="font-size:12pt;font-family:LMRoman12"> </span><br>4.5 Integral Promotions:<br>"A prvalue of type bool can be converted to a prvalue of type int, with false becoming zero and true becoming one."<br><br>5.11 Bitwise AND operator:<br>"The usual arithmetic conversions are performed; the result is the bitwise AND function of the operands."<br> <br>Is the type promotion optional ("can be")? Under what conditions would the promotion be performed?<br></div></div></blockquote><div><br></div><div>"can be" here just means "this is one of the available conversions".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br>Assuming the transform is correct, what is the recommended way to write this in C/C++ to achieve the desired effect: we want both comparisons to be evaluated (do *not* want short-circuiting)?<br></div></div></blockquote><div><br></div><div>This all falls under the as-if rule; there is nothing the user can do that will *require* the compiler to do either thing.<div><br></div><div>-- Sean Silva</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div>FWIW, the IR coming out of clang looks like what I expect: the i1 types are zexted and fed into an 'and i32'. It's the IR and backend optimizations that are surprising me.<br><div><div><br></div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>