<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">According to the documentation, the starting position of the field has to be encoded too:</div><div class=""><br class=""></div><a href="https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html" class="">https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html</a><div class=""><br class=""></div><div class="">I’m not sure whether we need the same information for bitfield ivars though.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2017, at 12:03 PM, Joerg Sonnenberger <<a href="mailto:joerg@bec.de" class="">joerg@bec.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, Jun 22, 2017 at 11:09:48AM -0700, Akira Hatanaka wrote:<br class=""><blockquote type="cite" class="">Do you want the same encoding for the bitfield “int : 1” you saw before r297792, which is just “i"?<br class=""><br class="">The encoding for bitfield is normally bN where N is the number of bits,<br class="">but the comment in function EncodeBitField says GNU runtime encodes it differently.<br class=""></blockquote><br class="">Sorry, can't answer that. I primarily care about a new clang crash that<br class="">didn't exist before, cut I can't answer what the correct behavior should<br class="">be.<br class=""><br class="">Joerg<br class=""></div></div></blockquote></div><br class=""></div></body></html>