similar to: [LLVMdev] Assert with getZExtValue()?

On Fri, Nov 16, 2012 at 3:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Was hoping it might get some help or a better explanation of this: > > /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion > `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. The error message is exactly what it says: you're trying to call

Eli, Thanks for responding. Yes, I read the error message but it seems odd that it would be trying to use more than 64 bits. It compiles and executes in gcc on 32 bit arch just fine. I'll probably take your suggestion and file a bug with a reduced testcase. Thanks again, Ryan On Fri, Nov 16, 2012 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Nov 16, 2012

So is there a way to return the value as a string instead? On Fri, Nov 16, 2012 at 3:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Was hoping it might get some help or a better explanation of this: > > /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion > `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. >

So the problem here was trying to return MIN_VALUE zero extended, if I return sign extended than this issue is resolved; however, I still get an error with getSExtValue when trying to get the value of the const from Instruction: %mask166 = and i128 %lvar_ins176, -18446462598732840961 On Fri, Nov 16, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > > Thanks

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u,

Neil Booth wrote: > Talin wrote:- > >> Well, I may be using it wrong. But looking at APFloat.h, I see four >> functions that purport to convert to integer: >> >> opStatus convertToInteger(integerPart *, unsigned int, bool, >> roundingMode) const; >> opStatus convertFromSignExtendedInteger(const integerPart *, >>

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

Talin wrote:- > Well, I may be using it wrong. But looking at APFloat.h, I see four > functions that purport to convert to integer: > > opStatus convertToInteger(integerPart *, unsigned int, bool, > roundingMode) const; > opStatus convertFromSignExtendedInteger(const integerPart *, > unsigned int, >

Neil Booth wrote: > Talin wrote:- > >> On the other hand, writing an interpreter means duplicating a lot of >> the functionality that's already in LLVM. For example, consider just >> the problem of float to int conversions: >> >> char B[ (int)3.0 ]; >> >> Generating code for this is relatively simple; Converting >> arbitrary-sized

gmake[1]: Entering directory `/home/ryan/llvm/llvm_core/trunk/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc 0 llvm-tblgen 0x000000000058525f 1 llvm-tblgen 0x0000000000585719 2 libpthread.so.0 0x00002b05a7801c60 3 libc.so.6 0x00002b05a83ead05 gsignal + 53 4

I am getting a build error after doing a "make update" and then running "make clean all": gmake[4]: *** No rule to make target `/home/ryan/llvm/llvm_core/trunk/Release+Asserts/lib/ocaml/llvm.cmi', needed by `/home/ryan/llvm/llvm_core/trunk/bindings/ocaml/transforms/ipo/Release+Asserts/llvm_ipo.cmi'. Stop. gmake[4]: Leaving directory

On 9/11/12 4:53 PM, Ryan Taylor wrote: > Tried a fresh checkout with the same issue. I'm assuming this issue > must be on my end. Dumb question: do you have a restrictive ulimit setting that might cause the tblgen program to run out of memory? I tend to doubt that this is the case, but it'd be good to double check. -- John T. > > ---------- Forwarded message ----------

ulimit -s = 8192 set "ulimit -c unlimited" On Tue, Sep 11, 2012 at 3:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > John, > > Thanks for responding. No, I don't see a limit from ulimit. It's > definitely with the tblgen though, I have the same errors trying to compile > clang. > > > On Tue, Sep 11, 2012 at 2:57 PM, John Criswell

Tried a fresh checkout with the same issue. I'm assuming this issue must be on my end. ---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Tue, Sep 11, 2012 at 1:28 PM Subject: Build Error from Intrinsics.td To: llvmdev at cs.uiuc.edu gmake[1]: Entering directory `/home/ryan/llvm/llvm_core/trunk/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp

John, Thanks for responding. No, I don't see a limit from ulimit. It's definitely with the tblgen though, I have the same errors trying to compile clang. On Tue, Sep 11, 2012 at 2:57 PM, John Criswell <criswell at illinois.edu>wrote: > On 9/11/12 4:53 PM, Ryan Taylor wrote: > > Tried a fresh checkout with the same issue. I'm assuming this issue must > be on my

Usually it is the ones that end in ".inc". From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ryan Taylor Sent: Tuesday, September 11, 2012 3:12 PM To: John Criswell Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Fwd: Build Error from Intrinsics.td What files are created by the TableGen so that I can clean them out and start fresh? On Tue, Sep

Hi Ryan, Sometimes the configure machinery can get confused. I haven't seen this particular error, so I don't know for sure if that's happening here, though. Try running "./config.status" from the build directory. Perhaps unrelated, but it looks like you're building inside the source tree. I'd recommend not doing that, as it's not too uncommon for that to run

llvm[1]: Compiling APFloat.cpp for Release+Asserts build clang: TargetInfo.cpp:1778: llvm::Type *GetX86_64ByValArgumentPair(llvm::Type *, llvm::Type *, const llvm::TargetData &): Assertion `Lo->isIntegerTy() && "Invalid/unknown lo type"' failed. 0 clang 0x0000000001c132ef 1 clang 0x0000000001c13804 2 libpthread.so.0 0x00002ba7d7eaec60 3

Here's another question. It's failing on a clean checkout, so what does llvm use from a previous install that I would need to clean when installing a new clean checkout? On Tue, Sep 11, 2012 at 3:27 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > Usually it is the ones that end in ".inc".**** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu

What files are created by the TableGen so that I can clean them out and start fresh? On Tue, Sep 11, 2012 at 3:11 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > ulimit -s = 8192 > set "ulimit -c unlimited" > > > > On Tue, Sep 11, 2012 at 3:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> John, >> >> Thanks for responding. No,