similar to: [LLVMdev] Clang build problem

On Sep 24, 2013, at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: >> Hi LLD developers, >>

On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> > wrote: > > On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: > >> Hi LLD developers, >> >> I'm about to make a change to invert the return value of Driver::parse()

On Tue, Sep 24, 2013 at 4:44 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Sep 24, 2013, at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > > On Tue, Sep 24, 2013 at 4:17 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> >> On Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> >> wrote: >> >>

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 Sep 24, 2013, at 12:40 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Tue, Sep 24, 2013 at 12:33 PM, Rui Ueyama <ruiu at google.com> wrote: > Hi LLD developers, > > I'm about to make a change to invert the return value of Driver::parse() to return true on success. Currently it returns false on success. > > In many other functions, we return true

On OpenBSD we still use the "classic" SunOS 4 shared library versioning scheme where the major and minor number are part of the library name (and recorded in DT_NEEDED entries). For example the shared libc on the OpenBSD-current is named libc.so.89.2. With this scheme, linker has to pick the pick the library with the highest major and minor (within the highest major version); the

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

Hi, I'd like to make code emitted by LLVM that includes floating point operations which raise FP exceptions behave closer to what is defined by IEEE754 standard. I'm not going to "fix everything", just incorrect behaviour I faced so far. Most of troubles regarding FP exceptions are caused by optimizations, so there should be a flag to disable/block them if one wants to get

Hi Mark, If we have to do this, or LLD doesn't work on OpenBSD, I think we need to do this. But can I ask one question? I wonder why OpenBSD systems don't have symbolic links unlike the other Unix-like systems in the first place. On Mon, Dec 19, 2016 at 2:27 PM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On OpenBSD we still use the "classic"

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

You are right. Regarding lanes i can comment only when the other things run fine. Here I am stuck with unsigned vs uint64_t. it looks as if i need to replace each occurrence of unsigned with uint64_t. Should i do it for complete llvm folder or codegen only?? i am continuously getting such errors which require changing unsigned with uint64_t. What to do now??? On Thu, Jul 20, 2017 at 1:03 AM,

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"*) > };

As you mentioned i changed 32 to 64 but now some new errors come which require to change unsigned to uint64_t in mentioned files. i have changed in mentioned files but still errors come to change in other files.. What to do? On Thu, Jul 20, 2017 at 12:08 AM, Craig Topper <craig.topper at gmail.com> wrote: > Did you change the hardcoded 32 right before the line that prints that >

Hi LLVM developers, I am implementing Loong Language[1] using Clang FrontEnd and LLVM MiddleEnd. I add `wire`[2] Builtin Type, and clang is able to parse very small testcase fulladder[3] but failed to work for 10+K loc RISCV E203 project[4]: Loongson clang version 7.0.0 (git at github.com:Loong-Language/loong-clang.git 8f7e826f27abbe12ea08d9563490298c38d3adc1) (git at

Thank You. I have replaced all the occurrences of unsigned with uint64_t in Lanemask.h and in all other related files like codegenregisters.cpp, codegenregisters.h, MIParser.cpp etc... Also i changed Log2_32 to Log2_64 and replaced 4 with 8 in codegenregisters.cpp, but still getting the same error: error:Ran out of lanemask bits to represent subregister

hi, I compile a case (test.c) to get IR file (test.ll) using clang as follows: "clang -emit-llvm -S -O2 test.c -o test.ll" My clang source code version is release 3.3 and debugging build. //test.c int foo(int j) { return ++j > 0; } int main() { if (foo(((~0U)>>1))) abort(); exit(0) } //end test.c Here are the generated IR file: //test.ll ;

Hi, I think this more of a front-end issue than a compile-rt issue, but I’m also copying the llvm-dev list In compiler-rt the file lib/builtins/atomic.c seems to rely on determining at compile time if an atomic operation of size 1, 2, 4, or 8 is always lock free. For example, in the implementation of __atomic_load_8() we have something like this after macro expansion: void __atomic_load_8(…) {

Hello everyone, I have an integer and I want to convert it to StringRef in order to set metadata. setMetadata->(StringRef, MDNode*); It is there a native LLVM way to do it? 1. In the llvm::APSInt Class is toString() method, which seems it is not for this purpose 2. itoa and string are not part of LLVM 3. stringstream is not part of LLVM 4. to_string is not part of LLVM 5. any casting method?

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

With the TableGen problem circumvented the build proceeds quite well up until: llvm[2]: Linking Debug executable llc /home/neale/LLVM/llvm/tools/llc/Debug/llc.o: In function `ForceCodegenLinking': /home/neale/LLVM/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:45: undefined reference to `llvm::createBURRListDAGScheduler(llvm::SelectionDAGISel*, bool)'