[llvm] r203273 - [ADT] Update PointerIntPair to handle pointer types with more than 31 bits free.

Jordan Rose jordan_rose at apple.com
Fri Mar 7 11:57:37 PST 2014

On Mar 7, 2014, at 11:32, David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Mar 7, 2014 at 11:19 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>> Author: jrose
>> Date: Fri Mar  7 13:19:56 2014
>> New Revision: 203273
>> URL: http://llvm.org/viewvc/llvm-project?rev=203273&view=rev
>> Log:
>> [ADT] Update PointerIntPair to handle pointer types with more than 31 bits free.
>> Previously, the assertions in PointerIntPair would try to calculate the value
>> (1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were
>> more than 31 bits available we'd get a shift overflow.
> I'm guessing this was found by the static analyzer? (how/why? the
> "bits free" would be an template parameter, not a runtime value - and
> I assume we never even approach 32 bits free... seems sort of like a
> false positive?)
> Or do we really have such a pointer somewhere that's aligned to 4 GB?

I bet the analyzer could 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).

(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.)

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140307/9f76db33/attachment.html>

More information about the llvm-commits mailing list