<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 February 2015 at 12:48,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been debugging some strange happenings over here and I put an<br>
assert in APInt to catch what I think is the source of the problem:<br>
<br>
  int64_t getSExtValue() const {<br>
    // An i1 -1 is unrepresentable.<br>
    assert(BitWidth != 1 && "Signed i1 value is not representable!");<br></blockquote><div><br></div><div>Please don't do this. Asking for an i1 APInt to be sign-extended does not mean that we have encountered a bug. How would you write a parser for the constant expression "i32 sext(i1 true)"? It grabs the i1 and sign extends it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To me an i1 -1 makes no sense whatsoever.  It is not representable in<br>
twos-complement form.  It cannot be distinguished from unsigned i1 1.<br>
<br>
It turns out this assert triggers all over the place.  Before I dive<br>
into this rat hole I'd like to confirm with others my sense that we<br>
shouldn't be creating i1 -1 values.  Is there some legitimate reason to<br>
do so?<br></blockquote><div><br></div><div>We don't create i1 -1 values, nor do we create i1 1 values. APInt is neither signed nor unsigned, it is signless. The interpretation of the bits (or in this case, the bit) is a matter for the caller to decide.</div><div><br></div><div>Nick</div></div><br></div></div>