similar to: [LLVMdev] llvm-config --system-libs has newlines in output

What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/

Yeah, it's not linking the runtime because you're building a shared library. This is totally ok. In this case there are undefined __asan_* symbols that are resolved when an instrumented binary loads your library. What's wrong here is that some flag passed to ld prevents it from creating undefined symbols (--no-undefined?). This flag must be removed when building with ASan. This

Hello everybody, after moving from OS X to Linux build llvm with asan enabled (I also updated to trunk, but not sure if that's related). However, it's totally possible that I missed a step that I took back when I set this up for me, so I might be doing something very stupid. Anyway, I'm configuring LLVM with ../configure --prefix=/home/kfischer/julia/usr --build=x86_64-pc-linux-gnu

Indeed, removing that flag works fine, the only question is why this is added in tools/llvm-shlib/Makefile in the first place then and what to do about it: ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD)) # Don't allow unresolved symbols. LLVMLibsOptions += -Wl,--no-undefined endif On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <glider at

Actually it only link the shlib fine. Linking any executable against it fails: llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols) /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++ -fsanitize=address -O3 -Wl,-R -Wl,'$ORIGIN/../lib' -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib

On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <kfischer at csail.mit.edu> wrote: > Hello everybody, > > after moving from OS X to Linux build llvm with asan enabled Sorry, I failed to parse this. You're compiling Clang on Linux, and OSX is unrelated, right? > (I also updated > to trunk, but not sure if that's related). However, it's totally possible > that I

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

I'm trying to link a program with LLVM on Linux. I've managed to take out the test files from 'llvm-config --libs' but now it's getting errors with missing symbols. The same program successfully links with the same version of LLVM (3.8) on Windows, so it's not a problem with the code per se, it's some kind of configuration issue. Any ideas? g++ -std=c++11

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

Hello all. At XMOS we are working towards updating the upstream XCore backend for newer versions of the chip. XCore is the XMOS processor. The XCore backend was written by Richard Osborne at XMOS. Richard has moved on. The current code owner in CODE_OWNERS.TXT, Robert Lytton, has also moved on. For some years XMOS has developed the compiler in-house, for new versions of the chip, but not

Hi, I'm a compiler engineer at XMOS (http://www.xmos.com) and in the last few months I've been working on porting LLVM to target our XS1-G4 chip. I thought it may be of interest to the list to find out how we are using of LLVM. The XS1-G4 has four processors and 32 hardware threads. It has been designed to be highly responsive to I/O events allowing many tasks normally be done by

If I give instcombine the following IR: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %c = getelementptr [1 x i8]* %a, i32 0, i32 0 %d = getelementptr [1 x i8]* %b, i32 0, i32 0 %cmp = icmp ult i8* %c, %d ret i1 %cmp } It optimizes it into: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %cmp = icmp slt [1 x i8]* %a, %b ret i1 %cmp } Is this a bug, or are there some semantics of icmp

Thanks for reviewing this. Committed in r98255 and r98256. The bug against the ARM backend is 6581: http://llvm.org/bugs/show_bug.cgi?id=6581 On 10/03/10 21:45, Chris Lattner wrote: > Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! > > -Chris > > On Mar

Hi Richard, Thanks for working on this! Your patched solved my initial problem, but introduced another one. Please find attached another BC file that fails on xcore with the linear scan regalloc. This is the error message I get eliminateFrameIndex Frame size too big: -3 0 llc 0x08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

... and so (I infer from that) it should not be patched let alone need any changes. Assuming my inference is correct, any patching should only affect the XCore target and only if there is a good reason why the XCore requires the change. So, is #ifdef around all/most changes the correct way to submit a patch? Robert ________________________________ From: Eric Christopher [echristo at gmail.com]