similar to: [LLVMdev] Build Failure

I am still seeing build errors with -Werror: [off-dbg] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Support/APInt.cpp: In function 'unsigned int getDigit(char, uint8_t)': [off-dbg] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Support/APInt.cpp:57: error: comparison between signed and unsigned integer expressions [off-dbg] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Support/APInt.cpp:61:

I'm breaking this out from LLVM asserts thread. Here are all the assertions in APInt I consider should be recoverable: APInt::APInt: bitwidth too small Null pointer detected! APInt::getBitsNeeded: Invalid string length string is only a minus! Invalid radix APInt::fromString: Radix should be 2, 8, 10, or 16! Invalid string length string is only a minus Insufficient bit width Invalid digit in

On Aug 19, 2009, at 9:36 PM, Erick Tryzelaar wrote: > I'm breaking this out from LLVM asserts thread. Here are all the > assertions in APInt I consider should be recoverable: > > APInt::APInt: > bitwidth too small > Null pointer detected! Hi Eric, As we discussed on IRC, I don't think there is any reason for the implementation of these methods to check these

I'm getting this build error with -Werror: [off-opt] : [llvm] cc1plus: warnings being treated as errors [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp: In member function 'llvm::MachineBasicBlock* llvm::ARMTargetLowering::EmitAtomicBinary64(llvm::MachineInstr*, llvm::MachineBasicBlock*, unsigned int, unsigned int, bool, bool) const': [off-opt]

Hi, I think you may try to use llvm::Twine(int). For example, to convert 30 to string, you can use: Twine(30).str() To convert the string back to integer, you can try the StringRef::getAsInteger(unsigned, APInt &). For example: APInt i; str.getAsInteger(/*radix=*/ 10, /*output=*/ i); Sincerely, Logan On Thu, May 2, 2013 at 9:53 PM, Alexandru Ionut Diaconescu <

On Thu, Sep 1, 2011 at 3:17 PM, David Greene <dag at cray.com> wrote: > I'm getting this build error with -Werror: > > [off-opt]    : [llvm] cc1plus: warnings being treated as errors > [off-opt]    : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp: In member function 'llvm::MachineBasicBlock*

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

The problem is that I want to pass only srsr which is an int. "marked" was just an example :) Thanks you! On Thu, May 2, 2013 at 5:06 PM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > I'm not familiar with this, but maybe you can try: > > StringRef tst = ("marked" + Twine(srsr)).str(); > > It seems that you can't use integer as meta data

Yes, it sounds good. I can try tomorrow. Thank you for your advice ! On Thu, May 2, 2013 at 5:43 PM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > I think the better solution should be: > > > LLVMContext& C = is->getContext(); > Value *values[] = { > ConstantInt::getSigned(Type::getInt64Ty(C), *scsr*), > MDString::get(C, *"path"*) > };

I think the better solution should be: LLVMContext& C = is->getContext(); Value *values[] = { ConstantInt::getSigned(Type::getInt64Ty(C), *scsr*), MDString::get(C, *"path"*) }; lnstr.setMetadata(*"your_analysis_name"*, MDNode::get(C, values)); So that you can take advantage of the type system of LLVM bitcode, and don't have to cast the integers from/to strings

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. Program received signal SIGABRT, Aborted. 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

I made my first attempt to build on an x86_64-unknown-linux-gnu system. Is this supposed to work? I get libtools errors (below). The problem seems to be that it finds a 32-bit libltdl rather than the 64-bit libltdl. /home/dag> ls /usr/lib/libltdl.so.3.1.0 /usr/lib/libltdl.so.3.1.0 /home/dag> ls /usr/lib64/libltdl.so.3.1.0 /usr/lib64/libltdl.so.3.1.0 Is this a known problem?

connecting legacy PBX to Asterisk (for the very same reason, those PBX use TE-PTMP). If others could join this thread and say if they agree or not with NT-PTMP being the 2nd most needed mode, would be great. Please, do not hesitate to comment. > > > Right now, I would not preclude the possibility that NT-PTMP support > might be added, but I could not give you a concrete time at which

Török Edwin <edwintorok at gmail.com> writes: >> > Which regression tests are failing with LLVM 2.8 and GCC 4.4.x? >> >> Too many to list. > > Can you give me 2 or 3 examples (that fail with LLVM 2.8 and GCC 4.4 > but work with LLVM 2.8 and GCC 4.3), also I'd like to know how they > fail. > If I have some time I'll check with my 4.4 to see if

I'm getting the following when building llvm-gcc with an optimized set of LLVM libraries: /ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/xgcc -B/ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/ -B/cray/iss/compiler/cost/tools/llvm-tools/llvm/install.trunk.official.opt/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/

David Greene wrote: > I'm getting the following when building llvm-gcc with an optimized set of > LLVM libraries: > > /ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/xgcc > -B/ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/ >

... Thanks, anyway for telling as at least, it reflects your needs. > > > You want NT PtMP and i second that, > not being limited on the asterisk > side is a must in the > telephony ecosystem, since the legacy PABX aren't alwsys easy to > reconfigure. > > _______________________________________________ > -- Bandwidth and Colocation Provided by

Hi ! I have a patch for print_svid.c, that enhances the usage of the "printcap=lpstat" option under System V. It not only gets the names of the printers via lpstat, but also the comments from the unix printing system. It works under Solaris, and should also work with SCO. I haven't access to other System V based systems. I don't know if this list is the appropriate place to