similar to: [LLVMdev] Very Experimental LLVM Debian packages for i386

I'm not a Debian user, so I can't help by testing, but I do have some comments... On Tue, Jan 18, 2005 at 03:59:07PM -0700, Al Stone wrote: [snip] > If you want to install the packages one at a time, do the > following, in this order: > > apt-get install llvm-libs > apt-get install llvm-cfe > apt-get install llvm > apt-get install llvm-doc [snip I

On Wed, 2005-06-01 at 10:04 -0500, Misha Brukman wrote: > On Wed, Jun 01, 2005 at 10:50:35AM -0400, Bill Wendling wrote: > > It didn't look like there was a cftonend binary for the IA-64 > > platform. Are we supposed to use the x86 binaries instead? > > The answer to that is that we don't have IA-64 in-house, so we don't > provide an IA-64 C/C++ front-end, but

Hi Misha, On 6/1/05, Misha Brukman <brukman at uiuc.edu> wrote: > On Wed, Jun 01, 2005 at 10:33:39AM -0400, Bill Wendling wrote: > > What's the plan for support on Linux 64-bit machines? Is that actively > > being worked on right now or is there a roadmap for doing this? > > Do you mean compiling on 64-bit Linux or generating code for 64-bits? > I meant

On Wed, Jun 01, 2005 at 10:50:35AM -0400, Bill Wendling wrote: > It didn't look like there was a cftonend binary for the IA-64 > platform. Are we supposed to use the x86 binaries instead? The answer to that is that we don't have IA-64 in-house, so we don't provide an IA-64 C/C++ front-end, but if someone were to contribute it to us, we would gratefully host it. Note that if you

Hello, I'm considering a possibility of writing an llvm backend for my research uses. Unfortunately, I can't find much information on how do to it. I more or less understood now the C backend is implemented, but for real backend I'd need at least register allocation. I beleive there's already register allocator in LLVM and I would like to reuse it if possible. The question is

So, I'm trying to build everything from source for the Debian package for LLVM, including the C/C++ front end. I'm running this build on LLVM 1.4 source (the released tarball), using Debian unstable (gcc 3.3.5, on a 2.6.8 kernel, on an x86_64 box, dual CPU). Before I get _too_ deep into it, I thought I would ask if the following compilation failure on the CFE looks the least bit familiar

On Thu, 10 Mar 2005, Andrew Lenharth wrote: > yes, so this happens on anything that uses a struct for va_list (like > alpha). I am currently working on fixing this. if you look at the last > patch to the alpha portion of llvm-gcc, you can see a quick hack to work > around that (aka, get it to compile), but the resultant compiler will > have issues with varargs. While Andrew is

So. I _finally_ got the building and packaging of LLVM and the GCC FE into a state I'm more or less happy with. As a result, I uploaded x86 packages into the NEW queue just a little while ago. Whew. What this means is that in a few weeks (hard to say how long, really) the package will be reviewed by the Debian FTP masters. If they like/approve of what they see, they'll let the package

On Sun, 2006-10-29 at 19:39 -0500, Adam Goode wrote: > Hi, > > I'm still working on the Fedora Extras package for LLVM. > > Because of the Fedora requirement that all packages in Extras be built > from source, I must build the dreaded C Front End. :) > > I think I've mostly got things set up correctly, but I've found what I > suspect is a tricky problem:

yes, so this happens on anything that uses a struct for va_list (like alpha). I am currently working on fixing this. if you look at the last patch to the alpha portion of llvm-gcc, you can see a quick hack to work around that (aka, get it to compile), but the resultant compiler will have issues with varargs. Alternately, build ia-32 binaries on x86_64, llvm-gcc is happy with the the abi there.

On Sun, Apr 24, 2005 at 07:15:03PM +0800, Tzu-Chien Chiu wrote: > i'd like to know if there is any plan or existing work to add a Aho's > trig language like code generator generator? I'm not aware of either the trig language code generator nor any work to implement it in LLVM. > "...If you are starting a new port, we recommend that you write the > instruction

i'd like to know if there is any plan or existing work to add a Aho's trig language like code generator generator? "...If you are starting a new port, we recommend that you write the instruction selector using the SelectionDAG infrastructure." any other things i should know before i write one? thank you.

Would anyone mind terribly if I tried to get LLVM packaged and added to the Debian distribution? -- Ciao, al ---------------------------- Al Stone Linux & Open Source Lab Hewlett-Packard Company E-mail: ahs3 at fc.hp.com ----------------------------

In trying to package up LLVM for Debian, it appears that x86_64 is no longer a supported architecture -- so, my first question is, is that correct? Best I can tell, the only thing that's supposed to work for x86_64 is the C backend. For Debian, I need to build everything from scratch. When trying to build llvm-gcc4 from source, though, I get part way through the build and am told that

On Thu, 2005-04-21 at 23:58 -0700, Reid Spencer wrote: > On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > > On Thu, 21 Apr 2005, Reid Spencer wrote: > > > With Misha's changes requiring a total rebuild, I've been reminded how > > > long the targets take to build. Now that there are more of them and in > > > most cases I really don't care

On Fri, 11 Mar 2005, Al Stone wrote: > So. I _finally_ got the building and packaging of LLVM and the > GCC FE into a state I'm more or less happy with. As a result, I > uploaded x86 packages into the NEW queue just a little while ago. > Whew. Nice! Thanks a lot Al! -Chris > What this means is that in a few weeks (hard to say how long, > really) the package will be

On Fri, 2005-04-22 at 08:15 -0500, Andrew Lenharth wrote: > -enable-targets=x86,alpha,sparcv9 > -link-targets=alpha,host > > Valid options for both are: > the names of the targets > host > all As others have agreed, this is a much better approach than the one I was thinking of. Its harder to parse in the configure script, but I can probably find a way to do it. >

Hi, I'm still working on the Fedora Extras package for LLVM. Because of the Fedora requirement that all packages in Extras be built from source, I must build the dreaded C Front End. :) I think I've mostly got things set up correctly, but I've found what I suspect is a tricky problem: make[1]: Leaving directory `/home/adam/rpmbuild/BUILD/llvm-1.8/llvm-gcc4-obj/gcc' Checking

On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > On Thu, 21 Apr 2005, Reid Spencer wrote: > > With Misha's changes requiring a total rebuild, I've been reminded how > > long the targets take to build. Now that there are more of them and in > > most cases I really don't care about n-1 of them, I'm wondering if its > > time to have configure allow

On Fri, 22 Apr 2005, Al Stone wrote: >> Actually, the options have to be expressed as "enable-something" so >> I've opted for "--enable-target-this" to enable just the $host target. >> if you specify --disable-target-this (the default) then you get >> whatever platforms you specify with --enable-target-{targetname} >> >> Does that make