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

Displaying 20 results from an estimated 900 matches similar to: "[LLVMdev] [PATCH] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?"

2013 Jun 12
0
[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" {
2013 Jun 10
1
[LLVMdev] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?
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
2006 Jan 26
0
[LLVMdev] VS2005 patch
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,
2010 Dec 31
2
[LLVMdev] LLVM on Windows MSVC 10
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 Dec 31
2
[LLVMdev] LLVM on Windows MSVC 10
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:
2010 Dec 31
0
[LLVMdev] LLVM on Windows MSVC 10
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
2010 Dec 31
0
[LLVMdev] LLVM on Windows MSVC 10
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
2010 May 12
2
[LLVMdev] Linking problems with llvm-2.7, release 64b build with vs2010
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:
2010 Feb 03
0
[LLVMdev] jit X86 target compilation callback bug
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
2010 Feb 03
2
[LLVMdev] jit X86 target compilation callback bug
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
2008 Nov 01
0
[LLVMdev] nested function's static link gets clobbered
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:
2006 Apr 29
3
[LLVMdev] Building LLVM under Mingw. Part I: tools-only
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)
2005 May 30
0
[LLVMdev] [Cygwin] onsistant error building LLVM
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
2012 Sep 24
2
[LLVMdev] JIT problem with thread local global variable
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,
2008 Jun 11
0
[LLVMdev] Shared libs?
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
2009 Feb 28
2
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
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
2010 Feb 02
3
[LLVMdev] jit X86 target compilation callback bug
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
2009 Mar 02
0
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
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 :- > >
2010 Feb 16
2
[LLVMdev] Work in progress patch to bug 2606
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
2005 Jun 01
0
[LLVMdev] [Cygwin] 'make tools-only' configuration error
'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