<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 1, 2009, at 6:09 AM, Stefanus Du Toit wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Nicolas,<div><br></div><div><div><div><div><div>On 1-May-09, at 6:32 AM, Nicolas Capens wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">I’ve located a regression that causes my project to crash. It’s in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows.</div></div></div></span></blockquote><div><br></div>We're looking into a similar bug right now. We see the problem elsewhere (early on in optimization, during the first instcombine pass) but it sounds like the same issue. We'll let you know when we know more.<div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn’t seem very safe to me to store other data into a pointer to begin with, but surely the lower bits must be a safer location than the upper bits?</div></div></div></span></blockquote><div><br></div><div>Just to be clear, PointerIntPair doesn't (AFAIK) store the integer in the "high bits" of the pointer. It just uses the "higher parts" of the "low available bits" of the pointer. So, if a pointer is always aligned such that it always has 4 bits clear on the low side, and you only need to store one bit, it'll be stored in bit 3 (counting from the LSB towards the MSB).</div></div></div></div></div></div></blockquote><div><br></div></div>FWIW, the reason it does this is to allow composable pointerintpairs, for example, PointerIntPair< PointerIntPair<foo*, 1>, 2> can use the low 3 bits as two different bitfields.<div><br></div><div>-Chris</div></body></html>