similar to: [LLVMdev] BURG now included in LLVM cvs tree

Burg now uses the same build system as the rest of the llvm system. It sends it's files into the correct BUILD_ROOT, and can build seperate debug, release, and profile versions as well. The only user of burg (lib/Target/Sparc) will automatically use the correct binary from your BUILD_ROOT. This is implemented with the following change sets:

I commented this line and it is compiling now: extern void *malloc ARGS((unsigned)); I hope that will not cause a different kind of problem. What it is zalloc used for? Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > It seems that this happened before but I do not know the details: > >

Yes, sorry for not mentioning it. I added that header also Although I suppose that if I am not using Sparc there will be no problem (it's an Itanium 2 machine) Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > I commented this line and it is compiling now: > > > > extern void *malloc ARGS((unsigned)); > >

It seems that this happened before but I do not know the details: http://llvm.cs.uiuc.edu/testresults/SparcV9/2004-12-07.html Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > llvm[2]: Compiling zalloc.c for Release build > > /homes/myuser/LLVM/llvmobj/../llvmsrc/utils/Burg/zalloc.c:9: error: conflictin > > g types for

Hi These are: ======================== llvm[2]: Linking Release Object Library LLVMbzip2.o gmake[2]: Leaving directory `/homes/myuser/LLVM/llvmobj/lib/Support/bzip2' gmake[1]: Leaving directory `/homes/myuser/LLVM/llvmobj/lib/Support' gmake[1]: Entering directory `/homes/myuser/LLVM/llvmobj/utils' gmake[2]: Entering directory `/homes/myuser/LLVM/llvmobj/utils/Burg' llvm[2]:

Chris, Thanks for your answer Here is the verbose output: =========================== gmake tools-only VERBOSE=1 TOOL_VERBOSE=1 for dir in lib/System lib/Support utils lib tools ; do \ if [ ! -f $dir/Makefile ]; then \ /home/myuser/LLVM/objdir/../srcdir/autoconf/mkinstalldirs $dir; \ cp /home/myuser/LLVM/objdir/../srcdir//$dir/Makefile $dir/Makefile; \ fi; \ (gmake -C $dir all )

LLVM can now be considered a real compiler: it can compile and run itself. This is a pretty big accomplishment, because LLVM makes "nontrivial" use of lots of C++ features. :) If you'd like to play around with this, grab the 1.1 release (due out soon), build a set of native tools, and put the native tool directory into your path. Then checkout another copy of the LLVM source tree,

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>,

On Tue, 2 Nov 2004, Jeff Cohen wrote: > The problem with building the frontend on Windows is that gcc cannot be > bootstrapped using Window's native compiler -- i.e. VC++ -- unlike every > other platform. It can be built on Windows using gcc, of course, but > even then only if the entire GNU environment is present. Yeah, annoying. Unfortunately we're not up to fixing GCC :)

i want to extend a burg-style code generator generator to write a retargetable compiler, implementing the algorithm: Rainer Leupers: Code Selection for Media Processors with SIMD Instructions. DATE 2000: 4-8 what i have now is only iburg, though robust but with very limited functionality. i have consider using "nova" - http://cocom.sourceforge.net/nona.html but it seems not be

On Fri, 4 Apr 2008, heisenbug wrote: >> point taken. thanks! > > > Whatever I try I get something like this: > > ggreif$ cd MultiSource/ > ggreif$ make > make[2]: *** No rule to make target `Output/be.bc', needed by `Output/ > burg.linked.rbc'. Stop. > make[1]: *** [Burg/.makeall] Error 2 > make: *** [Applications/.makeall] Error 2 This is the

On Wed, 15 Sep 2004, Jeff Cohen wrote: > Anyway, I avoided bleeding edge stuff like WOW64 for now. Still, > Signals.cpp is going to require some esoteric Structured Exception > Handling stuff and debug symbol table support. Nothing that hasn't been > around for a while, but rarely used by the typical Windows programmer. Note that you don't HAVE to implement the stack trace

I guess Bill Wendling cleared it up a little more for me. Neither llvm nor gcc ignore const. The type checking in each of their frontends makes sure that const is not violated. The reason I was asking about const is as follows. I was under the impression that const was part of c to aid the compiler with optimization and not just for type checking purposes. As you previously pointed out,

On Mon, 27 Jun 2005, Alexander Friedman wrote: > Hi all, > have flex/bison. Most (but not all) unix boxes have them, but almost > no windows boxes have them. This requires either > > 1) Forcing the user to dowload flex/bison (bad) > 2) Distributing flex/bison with the front-end (not as bad, but a pain) > > 3) or, and this seems like a simple fix, just distribute the output

On Thu, 16 Dec 2004, Markus F.X.J. Oberhumer wrote: > Hello Chris, > > many thanks for your quick fix. No problem. > I'm currently trying to compile llvm under AMD64 - after applying the trivial > fix for Burg/zalloc.c attached below I do get pretty far - compilation stops > somewhere in gcc when compiling libgcc, probably related to a varargs problem. > I still have to

Hey all, In case anyone is interested in using the X86 JIT for stuff, here's a rundown on where it stands. The X86 JIT can currently be used like this: lli -force-interpreter=false foo.bc <args> Until the remaining issues, described below, are fixed, the -force-interpreter switch will default to true. Once things are finished, it will default to false, so lli will automatically

On 6/29/05, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 27 Jun 2005, Alexander Friedman wrote: > > Hi all, > > have flex/bison. Most (but not all) unix boxes have them, but almost > > no windows boxes have them. This requires either > > > > 1) Forcing the user to dowload flex/bison (bad) > > 2) Distributing flex/bison with the front-end (not as

On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: > I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This > is on persephone. > > Are you not getting this error? Perhaps I should check out a fresh tree and > try to compile it? Nope, I don't think anyone else is getting this error. If you could try a fresh build that would be great, I'll fire

Hello hackers, I seem to be having some trouble compiling the top of the llvm CVS tree... Is someone working on something involving IPModRef.cpp and the data structure graph? I have attached a make -k log. -Brian -- gaeke at uiuc.edu -------------- next part -------------- gmake[1]: Entering directory `/scratch/scratch0/gaeke/llvm-497cz/utils/Burg' gmake[1]: Nothing to be done for

Does LLVM called the pthread directly? and what time do you plan to release Java front end? I'll try this. ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "yue" <qiangyue at ict.ac.cn> Cc: <llvmdev at cs.uiuc.edu> Sent: Wednesday, December 24, 2003 12:47 PM Subject: Re: [LLVMdev] GCC3.5 tree-ssa > On Wed, 24 Dec 2003,