similar to: [LLVMdev] Building LLVM under Mingw. Part I: tools-only

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

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)

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

1. I got the tools to build. Yay! 2. I got past all the annoying trouble with not finding header files. Yay! Now I'm having problems with this: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid I'm investigating this with the debugger and so far I've learned that

Fixing one bug uncovers the next one... To reproduce: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> The result: C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move './libgcc.a-000003' to './libgcc.a-000002': Cannot create a file when that file already exists. So apparently, we're trying to move one file on top of another. The

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 Sat, 6 May 2006, Greg Pettyjohn wrote: > Now I'm having problems with this: > > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid > I've tracked this down in the debugger. It is indeed a bug. The problem is that Path::isValid() will reject a string

Yep, you found another bug. Unlike Unix, Windows does not allow a file to be implicitly replaced via renaming. I'll fix it. Greg Pettyjohn wrote: > Fixing one bug uncovers the next one... > > To reproduce: > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > > The result: > C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: Can't move

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT

Greg, Looks like Jeff Cohen already fixed this in CVS. Please update and give it another shot. Thanks, Reid. On Sat, 2006-05-06 at 16:43 -0400, Greg Pettyjohn wrote: > > On Sat, 6 May 2006, Greg Pettyjohn wrote: > > > Now I'm having problems with this: > > > > llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> > >

Chris Lattner wrote: > On Sat, 6 May 2006, Reid Spencer wrote: >> Looks like Jeff Cohen already fixed this in CVS. Please update and give >> it another shot. > > Is this fixing the issue, or just papering over it? Why are we trying > to load an archive member without a path set? We're not. It's just a sentry value. > > -Chris > >> On Sat,

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

OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>

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" { /// must locate the start of the stub or call site and pass it into the JIT /// compiler function.

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:

2008/12/28 Elvis Dowson <elvis.dowson at mac.com> > Where can I get gccas ? I am running Mac OS X 10.5.6 and I get the > following error: > gccas is one of the LLVM tools; you have to build them before building llvm-gcc and you should configure llvm-gcc with the --enable-llvm=[...] flag unless the LLVM tools are in your PATH. See

On Sat, 6 May 2006, Reid Spencer wrote: > Looks like Jeff Cohen already fixed this in CVS. Please update and give > it another shot. Is this fixing the issue, or just papering over it? Why are we trying to load an archive member without a path set? -Chris > On Sat, 2006-05-06 at 16:43 -0400, Greg Pettyjohn wrote: >> >> On Sat, 6 May 2006, Greg Pettyjohn wrote: >>

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" {