search for: pointerintpairs

llvm::PointerIntPair<double*, 3, signed> P; P.setInt(-4); Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving the same as an 3-bit unsigned field which has the legal value range of [0,7]. Is this by design? Are negative values not allowed in PointerIntPair? /Riyaz

On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >> llvm::PointerIntPair<double*, 3, signed> P; >> P.setInt(-4); >> Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the

I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion: llvm::PointerIntPair<SomeType*, 3, int> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The above

Hi Nicolas, On 1-May-09, at 6:32 AM, Nicolas Capens wrote: > 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. We're looking into a similar bug right now. We see the problem

Rather than “fixing” it, it might be better to support a separate method for signed extension. My reasoning is as follows: int x = 7; llvm::PointerIntPair<double*, 3, int> pip; pip.setInt(x); There could be code out there that expects pip.getInt() to return 7 and not -1. So if you really want to set a negative and return a negative value, a separate method setSignedInt and getSignedInt

It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) Note that if you assign negative values to and then read from a signed bit-field, you would do sign extension. So 3-bit signed types do exist in C++. It begs the question why PointerIntPair supports signed int types if it always loses the sign. Is it just to avoid signed/unsigned comparison

On 04/04/2018 11:15, David Chisnall wrote: > On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >>> llvm::PointerIntPair<double*, 3, signed> P; >>> P.setInt(-4); >>> Ideally, the value range for a 3-bit signed integer

Hi, On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: > llvm::PointerIntPair<double*, 3, signed> P; > > P.setInt(-4); > > Ideally, the value range for a 3-bit signed integer should be [-4,3]. > But the above call to setInt will fail. Essentially, the signed int > field in PointerIntPair is behaving the same as an 3-bit unsigned field > which has the

I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and less error prone for the user to write the sign extension if they want it. By extension, it seems good that PointerIntPair doesn't do sign extension when the type happens to be signed. On Wed, Apr 4, 2018 at 9:47 AM David Blaikie via llvm-dev < llvm-dev at

I'd suggest someone try fixing this & see if it breaks anything that can't reasonably be fixed (before we go assuming this is by design/shouldn't be fixed just because it's the way it is today). On Wed, Apr 4, 2018 at 7:16 AM Riyaz Puthiyapurayil via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It won't move the sign bit, so negative values won't fit,

I think it'd be reasonable to model this on the same behavior as int to short to int round-tripping & not to speculate that there might be code relying on the existing behavior until there's evidence of it. I'd suggest changing the behavior & testing to see if anything breaks - and if nothing does, moving to the behavior rather than supporting both. On Wed, Apr 4, 2018 at

The sign extension is correct. Otherwise setInt(-1) won’t work. If you don’t want sign extension, then use ‘unsigned’ and not ‘int’ in the template arguments. > On Apr 4, 2018, at 14:34, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and

Hi all, 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. 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

Hi Nicolas, Looks like Preston and I have found the cause of the problem. The issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This is set to 3, which basically assumes that unless the traits are specialized for a particular pointer type, objects of that type are allocated with malloc() and aligned to 8 bytes. While PointerLikeTypeTraits is overloaded for Use*, it is

On 2009-05-01, at 18:40, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with malloc()

Hi Gabor, On 3-May-09, at 4:57 PM, Gabor Greif wrote: > Your analysis is perfectly correct. I Was AFK for the last two days, > so I couldn't > tell you this same story. Thanks, glad I was on the right track :). > The algorithm relies on the fact that the LSBit of the first "pointer" > in User > is zero. This is normally the case with VPtrs, which are

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object

Hmm. What about the errors I quoted from using clang-7 (starting about a third of the way down my email, sorry if they got kinda lost in all the noise)? Thanks, Jay. On Tue, 3 Sep 2019 at 20:00, David Blaikie <dblaikie at gmail.com> wrote: > > Looks to me like a bug in GCC's constexpr+_GLIBCXX_CONCEPT_CHECKS support. Small test case: > > $ g++-8 test.cpp -std=c++2a

On 3 Mai, 18:56, Stefanus Du Toit <stefanus.dut... at rapidmind.com> wrote: > On 1-May-09, at 8:35 PM, Chris Lattner wrote: > > > I still don't understand why this is a problem, but I decreased the > > default to 2 bits.  Please verify that this helps, > > I think I've figured out what's going on, and why no assertions are   > caused by this. It

I just ran into this today. Do we need to update our requirements on libstdc++ version? Jay, did you figure out a way around this? On Wed, Sep 4, 2019 at 5:29 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's a bug in libstdc++ - so if you have clang using libstdc++ (which it will by default, I think) then it's the same thing. You could try with