<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 7, 2014, at 11:32, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, Mar 7, 2014 at 11:19 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><blockquote type="cite">Author: jrose<br>Date: Fri Mar 7 13:19:56 2014<br>New Revision: 203273<br><br>URL: <a href="http://llvm.org/viewvc/llvm-project?rev=203273&view=rev">http://llvm.org/viewvc/llvm-project?rev=203273&view=rev</a><br>Log:<br>[ADT] Update PointerIntPair to handle pointer types with more than 31 bits free.<br><br>Previously, the assertions in PointerIntPair would try to calculate the value<br>(1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were<br>more than 31 bits available we'd get a shift overflow.<br></blockquote><br>I'm guessing this was found by the static analyzer? (how/why? the<br>"bits free" would be an template parameter, not a runtime value - and<br>I assume we never even approach 32 bits free... seems sort of like a<br>false positive?)<br><br>Or do we really have such a pointer somewhere that's aligned to 4 GB?<br></blockquote></div><br><div>I bet the analyzer <i>could</i> find it if such a path occurred, but the real answer is much more mundane: I've been working on an internal tool that actually has a Fixnum class like the one in the test case, which was originally just being used in a PointerUnion (alongside a real pointer). I tried using the same Fixnum<31> with a PointerIntPair, and Clang gave me a warning (-Wshift-op-overflow, I think).</div><div><br></div><div>(Why 31? Because it represents a field in a serialized file that I wanted to keep under 32 bits, and because I didn't want the size of this particular type to change between 32-bit and 64-bit builds. The latter is probably just me being pedantic, though...I don't think anyone's going to build this particular tool for 32-bit.)</div><div><br></div><div>So, not a terribly common use case (unless Fixnum gets pushed into llvm/ADT), but it didn't hurt to support it. Or rather, it won't hurt once everyone has rebuilt everything once...sorry about that.</div><div><br></div><div>Jordan</div></body></html>