similar to: [LLVMdev] Release Branch for llvm-gcc

> I would like to create the release branch for the llvm-gcc source code > tomorrow morning. I imagine this will be okay as llvm-gcc seems pretty > healthy and no one is currently doing any development on it. > > If there's something that needs to be fixed, or you're working on > llvm-gcc, please email the list so that I can delay creating the branch as >

On Fri, Oct 21, 2005 at 12:10:12AM +0100, Aaron Gray wrote: > I thought I should warn you the Cygwin Release (ENABLE_OPTIMIZED=1) build > fails due to 'ld/collect2' assertion failure. > > This is really a Cygwin problem that I thought would be fixed with time by > now but is still present with GCC 3.4.4 and binutils 2.16.91. Is there a version of Cygwin that _does_ build

On Thu, 2005-05-19 at 22:34 +0100, Aaron Gray wrote: > I do not really feel upto looking into makefiles yet as I don't really know > automake, configure scripts, etc, etc > Aaron, its trivial. Open up tools/llvm-ar/Makefile in an editor. Go to the TOOLNAME line, delete the space at the end of the line, save the file, rebuild. > >I'll patch the makefiles when UIUC's

Hello, I have observed that the LLVM build takes pretty long time to link executables (i.e. tools). Is that a normal behavior? Thanks, Rahul

Hi, I am wondering whether the bytecode generated by my llvm-gcc is correct? When I run $ llvm-gcc hello.c -o hello What I get is hello.exe.bc, and hello.exe (I can actually llvm-dis the bytecode file which is hello.exe.bc). However, I do not get a shell script(named hello) as stated in the documentation... Best Regards, Kiat On 5/25/05, Aaron Gray <angray at beeb.net> wrote: >

Hi, This is a simple question about building ARM cross-compiler. What is the building procedure using LLVM 2.4 and GCC front-end 4.2? I used these commands for LLVM, and it is okay. $ ../configure --prefix=/usr/local -target=arm $ make ENABLE_OPTIMIZED=0 $ make ENABLE_OPTIMIZED=0 install Then these commands were used for GCC front-end but this got couple of errors. $ ../configure

On Wed, Dec 29, 2004 at 08:37:46AM +0200, Alex Vinokur wrote: > But it seems that there are no asterisks at > * http://llvm.cs.uiuc.edu/testresults/ > * http://llvm.x10sys.com/testresults/Cygwin/ That's because there was a build error (see the big red notice). Check out http://llvm.x10sys.com/testresults/Cygwin/2004-12-27.html > By the way, is it possible to send a relevant

I have recently completed a build on Cygwin and am now hosting the Cygwin nightly tester. Here's some things you should know: 1. LLVM 1.4 release won't build on Cygwin so you'll have to use the latest CVS sources. 2. Even if you build it on Cygwin, it probably won't work unless you use the C Backend. See the test results here: http://llvm.x10sys.com/testresults/Cygwin

On Wed, Dec 29, 2004 at 08:13:21AM +0200, Alex Vinokur wrote: > Thank you for that information. I will wait until you get Cygwin > issues figured out. How can I know of that? Check out the link to the Cygwin nightly tester results here: http://llvm.cs.uiuc.edu/testresults/ Wait until most of the asterisks in the test results go away. :) The tester runs nightly, so checking every few

Misha Brukman wrote: > On Wed, Aug 18, 2004 at 12:16:04AM +0400, Valery A.Khamenya wrote: > >>Building PowerPC.td register information header with tblgen >>Included from PowerPC.td:22: >>Parsing PowerPCInstrInfo.td:53: Variable not defined: 'GPRC'! >>make[3]: *** [PowerPCGenRegisterInfo.h.inc] Error 1 >>make[3]: Leaving directory

On Thu, May 19, 2005 at 02:50:54PM -0700, Reid Spencer wrote: > Yeah, cygwin's a bit of a pig. To do a release build, just do: > make ENABLE_RELEASE=1 Actually, it's "make ENABLE_OPTIMIZED=1". Perhaps it should also allow ENABLE_RELEASE=1 as a synonym. Note that if you run ./configure the usual way, you *always* have to run "make ENABLE_OPTIMIZED=1" to build,

Alexander Friedman wrote: > On May 17, John Criswell wrote: > >>Dear All, >> >>I've finished building binaries for the GCC frontends and am now testing >> the 1.5 release branch on i386/Linux, Sparc/Solaris, and PowerPC/MacOS X. >> >>I'm looking for volunteers to test LLVM 1.5 on platforms that we don't >>have in house. I'm

Dear All, First, we're pushing back the creation of the release branch until tonight. This means two things: 1. If you want something to go into LLVM 1.5, you have until I create the release branch to get it in. I am tentatively scheduling this for 5:00 pm today (CST). 2. If you don't want something to go into LLVM 1.5, please refrain from adding it until I create the release

On Tue, 2004-12-28 at 22:42, Misha Brukman wrote: > This would be the right one, so maybe if we ask Reid nicely, he'll do it > (as he maintains the Cygwin nightly tester). I haven't used Net News since its signal-to-noise ratio dropped below my tolerance level (circa 1995). However, if you'd like to tell me how to make the post, I'd be happy to. -------------- next part

Reid Spencer wrote: > > I have recently completed a build on Cygwin and am now hosting the > Cygwin nightly tester. Here's some things you should know: > > 1. LLVM 1.4 release won't build on Cygwin so you'll have to use the > latest CVS sources. > 2. Even if you build it on Cygwin, it probably won't work unless you > use the C Backend. See the test

Misha Brukman wrote: > > On Wed, Dec 29, 2004 at 08:13:21AM +0200, Alex Vinokur wrote: > > Thank you for that information. I will wait until you get Cygwin > > issues figured out. How can I know of that? > > Check out the link to the Cygwin nightly tester results here: > > http://llvm.cs.uiuc.edu/testresults/ > > Wait until most of the asterisks in the

Attached is the patch I've been building arm-eabi with, which might help with linux-gnueabi. I disable multilib to get around several bugs with thumb. I build cross binutils first, then llvm, then llvm-gcc with newlib merged in. The following bugs need to be addressed for these non-Darwin ARM targets: 1388 2313 2545 2985 deep On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at

Looks much better. The stdc library things are caused by Cygwin's inability to recognize symbols linked into the main program with dlsym. For example, if lli (the interpreter) has "printf" already linked in, then the JIT compiler will not be able to find "printf" if it is used in the program it is compiling. There's currently no workaround for this other than to fix

ymxia at nudt.edu.cn wrote: > When I compiled a linux kernel, gccas was used to compile assembly code. > > But gccas cannot recognize the line comment character "#" of gnu assembler, > > and abort the compile with reporting a error "syntax error, unexpected $undefined". > > I watch llvm/tools/gccas, but donot known how to add this function in it. >

Henrik Bach wrote: > Hi > > I noticed that these defines (line 35 to 37) are hardcoded in the > DataTypes.h include file: > ---------------- > #define HAVE_SYS_TYPES_H 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_STDINT_H 1 > ---------------- > > Shouldn't they have be defined by the configure script into > llvm/Config/config.h? These lines are set by