search for: 1111101

...n. setInt only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. David

...only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) > > That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. > Yep, I meant it looks...

...gn. setInt only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. Yep, I meant it looks like...

...gn. setInt only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. Yep, I meant it looks like...

...u to set integer values > that fit into the available bits. It won't move the sign bit, so negative > values won't fit, unless you have a 3 bit signed type ;) > > That doesn’t sound right (for any computer made in the last few decades), > the representation of -3 will be 1111…1111101. Storing the low bits will > yield 101, which is a 3-bit negative three. When you then sign extend this > to any other signed type, you will get -3 in that representation. It > sounds as if the signed specialisation of PointerIntPair is simply not > doing the sign extension. > &gt...

...u to set integer values > that fit into the available bits. It won't move the sign bit, so negative > values won't fit, unless you have a 3 bit signed type ;) > > That doesn’t sound right (for any computer made in the last few decades), > the representation of -3 will be 1111…1111101. Storing the low bits will > yield 101, which is a 3-bit negative three. When you then sign extend this > to any other signed type, you will get -3 in that representation. It > sounds as if the signed specialisation of PointerIntPair is simply not > doing the sign extension. > &gt...

...ues >> that fit into the available bits. It won't move the sign bit, so negative >> values won't fit, unless you have a 3 bit signed type ;) >> >> That doesn’t sound right (for any computer made in the last few decades), >> the representation of -3 will be 1111…1111101. Storing the low bits will >> yield 101, which is a 3-bit negative three. When you then sign extend this >> to any other signed type, you will get -3 in that representation. It >> sounds as if the signed specialisation of PointerIntPair is simply not >> doing the sign ext...

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

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

...only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) > > That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. > > > Yep, I mean...

...gn. setInt only allows you to set integer values that fit into the available bits. It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) That doesn’t sound right (for any computer made in the last few decades), the representation of -3 will be 1111…1111101. Storing the low bits will yield 101, which is a 3-bit negative three. When you then sign extend this to any other signed type, you will get -3 in that representation. It sounds as if the signed specialisation of PointerIntPair is simply not doing the sign extension. Yep, I meant it looks like...

Hello all, We're having the following issue: when in UEFI mode, any output/errors from a lua script is invisible! This occurs even just running 'lua -v'. It runs and returns to a (visible) 'boot:' prompt, but there is simply no output visible from lua! (It does do a linefeed, but no visible text appears.) Has anyone encountered this? And/or know of a solution? For