similar to: [LLVMdev] LLVM can now bootstrap itself!

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.

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 :)

On Fri, 23 Apr 2004, Patrick Flanagan wrote: > I'm interested in getting LLVM running on OS X so I can play around > with it and check it out. I downloaded the LLVM 1.2 package and > compiled and installed with no errors (used config options > --with-llvmgccidr and --enable-spec2000 pointing to the relevant > directories). I want to look at performance of SPEC CPU2000 with LLVM

Adam, I recant my previous message. I built FreeType with GCC not LLVMGCC by accident (I shoulda checked!). The thing is, FreeType's makefiles don't respect environment variables. So, I did this: CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure make and was able to reproduce the problem. Not sure what's up with that but as Misha pointed out, llvmgcc isn't any

Hi, I'm able to build the llvm tools on the MinGW platform: burg, fpcmp, tblgen, llvm-as, llvm-dis, opt, gccas, llc, llvm-link, lli, gccld, llvm-stub, analyze and extract. I wonder if these tools are sufficient to start build the cfrontend? Henrik. _________________________________________________________________ Undg� pop-ups med MSN Toolbar - http://toolbar.msn.dk hent den gratis!

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. The real problem is that the bootstrapped frontend binaries built using gcc may not properly link with LLVM binaries built

Dear yueqiang, I tracked this down this morning, and it is a bug with our Python code that runs the tests. Essentially what is happening is that the code is finding the temporary directory it created the first time it ran the tests and believes that there are tests inside of it which it needs to run. It then gets confused and quits. This bug only shows up when the source tree and the

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}", []>,

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with

On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: > Thanks Aaron. > > I don't have a Windows system, and haven't seen any buildbot failures, so I > it's difficult to come up with a patch for something I can't reproduce > locally or see any actual failures. Could you send me the commands you used > that uncovered the failure? This

yue wrote: > hi, > about [LLVMdev] another question > > thanks > > yueqiang One other thing you might want to try is to put your object tree in a directory that is *not* inside of your source tree. Currently, we don't support using separate object trees that are subdirectories of the source tree. In other words: Will work: ========== SRC_ROOT=/home/yue/llvm

I just had a chance to read some of follow-up comments on Reid's initial document. I agree with Chris's discussion below of what is needed for users to get IPO/lifelong opt'n via LLVM without extensive changes to Makefiles, and about what .o files should contain. This is in perfect agreement with what I just said about how users should view LLVM. --Vikram

On Sun, Oct 15, 2017 at 11:19 AM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:06 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: >> > Thanks Aaron. >> > >> > I don't have a Windows system, and haven't seen any

On Wed, 2004-07-28 at 11:26, Chris Lattner wrote: > On Wed, 28 Jul 2004, Reid Spencer wrote: > > 2. MODE OF OPERATION > > ==================== > > The driver will simply read its command line arguments, read its > > configuration data, and invoke the compilation, linking, and > > optimization tools necessary to complete the user's request. Its basic > >

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Hello; I am still having problems making the llvm-test suite and running command like "make TEST=libcalls report" is giving me unexpected output. So first I tried the following - 1. I built and installed llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would

On Wed, 28 Jul 2004, Reid Spencer wrote: > 2. MODE OF OPERATION > ==================== > The driver will simply read its command line arguments, read its > configuration data, and invoke the compilation, linking, and > optimization tools necessary to complete the user's request. Its basic I'm not sure that I agree with this. Compilers need to be extremely predictable and

Hi Reid Spencer, > CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure > make > > and was able to reproduce the problem. Not sure what's up with that but > as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its > just 3.4ish. I also concur with him that you should file a bug and > attach the pre-processed source to it. You can get that with