<div dir="ltr">Yes, 

 you are right, I just double checked, it's not allowed to pick any other choice.

<div><br></div><div>The issue is that we are maintaining an arbitrary precision library. We provide a method that returns a range of bits, and a method that returns a single bit. The method that returns a range of bits, when used to pick a single bit, was behaving much better than the method that returns a single bit. The reason is the method that returns a single bit uses bool, while the other one stay in the realm of the library (aka. returns an arbitrary precision integer range).</div><div><br></div><div>It's not the first time we see poor behavior from C++ native types, we should have expected it... (in general, we should move away from integral types smaller than int to avoid those pesky integer conversion/promotion)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 1:54 PM Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>But: you can use ! Instead of ~ to avoid this issue.</div><div><br></div><div>– Steve</div><div><br><blockquote type="cite"><div>On Sep 13, 2019, at 4:52 PM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:</div><br class="gmail-m_-4924184801541164849gmail-m_-6890220969321865375Apple-interchange-newline"><div><div>The C and C++ language standards fully specify this behavior. There’s no flexibility here to change it.<div><br></div><div>– Steve<br><div><br><blockquote type="cite"><div>On Sep 13, 2019, at 4:49 PM, Alexandre Isoard via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-4924184801541164849gmail-m_-6890220969321865375Apple-interchange-newline"><div><div dir="ltr">Sorry for the typo:<div><br></div><div><div>false → 0b0000 → <font color="#cc0000">0b1111 </font>→ true</div><div>true → 0b0001 → 0b1110 → true</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 1:38 PM Alexandre Isoard <<a href="mailto:alexandre.isoard@gmail.com" target="_blank">alexandre.isoard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="background-color:rgb(255,255,254)">Hello,</div><div style="background-color:rgb(255,255,254)"><br></div><div style="background-color:rgb(255,255,254)">I encountered a really annoying issue, I am not sure it is Clang or C++ language issue.</div><div style="background-color:rgb(255,255,254)"><br></div><div style="background-color:rgb(255,255,254)">But basically, the following code:</div><div style="background-color:rgb(255,255,254)"><div><div><br><div><span style="color:rgb(0,0,255)">bool</span> foo(<span style="color:rgb(0,0,255)">bool</span> a) {</div><div>    <span style="color:rgb(0,0,255)">return</span> ~a;</div><div>}</div></div></div></div><div><br></div><div>Collapse into:</div><div><br></div><div><div style="background-color:rgb(255,255,254)"><div><span style="color:rgb(0,0,255)">bool</span> foo(<span style="color:rgb(0,0,255)">bool</span> a) {</div><div>    <span style="color:rgb(0,0,255)">return</span> true;</div><div>}</div></div></div><div><br></div><div>The explanation is simple:</div><div>- a is implicitly converted to int using zext</div><div>- int operator~(int) has the unexpected behavior described below</div><div>- then icmp ne 0 is used to convert to bool and is always true</div><div><br></div><div>Here is the truth table of bool-to-int + operator~(int) + int-to-bool:</div><div>false → 0b0000 → 0b0000 → true</div><div>true → 0b0001 → 0b1110 → true</div><div><br></div><div>Note that we can solve the issue by using sext for bool-to-int conversions.</div><div>Should we? Is this a known problem?</div><div><br></div>-- <br><div dir="ltr" class="gmail-m_-4924184801541164849gmail-m_-6890220969321865375gmail-m_-557060104621179273gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-4924184801541164849gmail-m_-6890220969321865375gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-4924184801541164849gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>