similar to: [LLVMdev] [PATCH] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?

Hi Patrik, On 12/06/13 09:48, Patrik Hägglund H wrote: > Thanks, now it links. > > If nobody objects, I will commit the following patch: > > diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp > index 44d8cce..8acc220 100644 > --- a/lib/Target/X86/X86JITInfo.cpp > +++ b/lib/Target/X86/X86JITInfo.cpp > @@ -339,6 +339,8 @@ extern "C" {

I tried to compile LLVM with gcc-4.8.1 -flto. I got the following error, when linking lli, llc, opt, or libLTO.so: `LLVMX86CompilationCallback2' referenced in section `.text' of /tmp/cclv7BYB.ltrans0.ltrans.o: defined in discarded section `.text' of X86JITInfo.o (symbol from plugin) collect2: error: ld returned 1 exit status Removing the LLVM_LIBRARY_VISIBILITY attribute for

Hi Morten, If you can make the VS2005 project files availiable on the net then I can test them as I have VS2005 now, so then with Chris'es okay then they could be distributed with LLVM. Thanks, Aaron ----- Original Message ----- From: "Morten Ofstad" <morten at hue.no> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, January 26,

I first sent this to the Clang dev list, but they told me to come here: ---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: >>> I'm trying to build svn LLVM with Visual Studio 2010: >>> >>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error

I don't normally build using nmake.. but I just tried and it worked 100% here. Are you sure you are using the trunk? On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com>wrote: > I first sent this to the Clang dev list, but they told me to come here: > > > ---------- Forwarded message ---------- > From: Ruben Van Boxem <vanboxem.ruben at

Hello, Following some recent messages about building with Visual Studio 2010, I have gotten most things to compile in release mode on 64b windows 7. (Mainly the few errors with 0 -> nullptr in the second argument of the pair constructor, and making an ECValue constructor public). I'm falling at the last hurdle though when it comes to the final link: 1>------ Build started: Project:

On 02/03/2010 01:08 PM, Kristaps Straupe wrote: > Hello again. > > I still think that you are wrong. Realignement with and esp,-16 not > always changes stack poiner. If esp is already aligned to 16 byte > boundary, it will not change! Take a look at following example. > Assume esp has value 0x000001000 at start of X86CompilationCallback > function. Then execution of it will

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov

Hi, > I'm parallelizing loops to be called by pthread. The thread body that I pass > to pthread_create looks like > > define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) > parent_frame is pointer to shared variables in original function > > 0x00007f0de11c41f0: mov (%r10),%rax > 0x00007f0de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6:

Hello, Everyone. Now I have some spare time and I've decided to build LLVM on Mingw. I've grab the latest 1.7 release (not CVS snapshot). Here are some issues fixed during the build. Now I'm preparing gcc build. So, I think, there will some other "parts" 1. Prerequisites 1.1 GCC 3.4.5 from mingw.org site. $ gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C)

If you look in X86JITInfo.cpp, you'll find CompilationCallback. I'm not sure about CompilationCallback2. In any event, the code is conditionally compiled and that might be tripping things up on Cygwin. Reid. On Mon, 2005-05-30 at 17:17 +0100, Aaron Gray wrote: > Consistant error building LLVM on Cygwin from CVS :- > > make[2]: Entering directory

Hello, I am trying to use LLVM JIT to emit the following codes and execute both functions in my program, but I get segmentation fault, the problem seems to originate from "thread_local" global variable. my LLVM library is 3.1 and platform is x86 32bit , OS : Ubuntu 10.04 @0 = internal thread_local global i32 522, align 4 define void @setValue(i32 %v) { %1 = alloca i32,

On Monday 09 June 2008, Albert Graef wrote: > Unfortunately, that approach doesn't work on x86-64 with LLVM 2.2, > since some parts of the LLVM JIT apparently contain non-relocatable > code; I hope that this will be fixed in the forthcoming LLVM 2.3. Unfortunately it's not fixed in 2.3 :( I made a patch ([1]) for 2.2 and gave it to one of the developer, I guess he forgot about

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

Hi! We are running llvm jit x86 on MS Visual Studio 2005. It seems there is a bug in asm code in function X86CompilationCallback in file X86JITInfo.cpp. Current code sets stack pointer to invalid value in instruction "and esp, 16". Depending on current stack pointer value it sometimes overwrites ecx and edx registers with next three lines. We have fixed this problem by changing this

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

The patch I recently attached to bug 2606, reproduced here, is my first attempt to solve this issue as represented by the attached test cases. To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found "external" GlobalVariable. To solve the foreign Module Function problem, I modified both JIT.{h,cpp} and

'collect2.exe' is an internal version of 'ld' called by GCC The GCC command line is :- g++ -I/usr/build/llvm-2/tools/llc -I/usr/src/llvm/tools/llc -I/usr/build/llvm-2/ include -I/usr/src/llvm/include -I/usr/build/llvm-2/include -I/usr/src/llvm/incl ude -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused -g -D_DEBUG -v -o /usr/build/llvm-2/Debug/bin/llc.exe