search for: cfrontends

Hi, When compiling the cfrontend for Linux/PPC architecture on a powermac G5, i got the following error : -------------------------------Compilation error listing if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi make GCC_FOR_TARGET="/usr/local/home/cyrille/project/llvm/cfrontend/build/gcc/xgcc -B/usr/local/home/cyrille/project/llvm/cfrontend/build/gcc/

This is a forward of a question from the SourceForge LLVM forum. If anyone has experience with Cygwin and building the C front-end there, please reply and CC Alex. --- Post by Alex Vinokur below --- =============== Windows 2000 GNU gcc 3.3.3 (cygwin special) =============== ./configure ./make I have got compilation error ------------------------------- make[1]: Entering directory

On Sun, 05 Sep 2004 10:49:44 -0700 Reid Spencer <reid at x10sys.com> wrote: > Jeff, > > Actually, that was my fault. I forgot to remove the non-existent > directories from the configure.ac file. That's done and committed > now, so the advice is still the same: update configure script :) > > Reid. OK, no problems building. I got some minor issues with the simple

Cyrille Mescam wrote: > Hi, > > > When compiling the cfrontend for Linux/PPC architecture on a powermac > G5, i got > the following error : I hate to ask a silly question, but are you using "make bootstrap" to build the cfrontend? Your output looks like gccas is being given a native code assembly language file to parse, and I seem to recall that that happens if

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int

Hi Guys I'm trying to port and build the GCC Front End to the Interix environment. I've succeded until the xgcc program executes: /usr/local/src/cfrontend/build/gcc/xgcc -B/usr/local/src/cfrontend/build/gcc/ -B/usr/local/src/cfrontend/install//i586-pc-interix3/bin/ -B/usr/local/src/cfrontend/install//i586-pc-interix3/lib/ -isystem

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 Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

Jeff, Actually, that was my fault. I forgot to remove the non-existent directories from the configure.ac file. That's done and committed now, so the advice is still the same: update configure script :) Reid. On Sun, 2004-09-05 at 09:53, Jeff Cohen wrote: > Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :)

On Sun, 2004-09-05 at 13:48, Jeff Cohen wrote: > On Sun, 05 Sep 2004 10:49:44 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Jeff, > > > > Actually, that was my fault. I forgot to remove the non-existent > > directories from the configure.ac file. That's done and committed > > now, so the advice is still the same: update configure script

> Okay, I took a closer look at your output. > > I was correct in that gccas is attempting to assemble a native PPC > assembly language file. However, this appears to be happening because > the assembly file is generated by the GCC Makefiles for libgcc2 (in > llvm-gcc/gcc/config/rs6000/t-ppccomm, I think). > > The first thing I would try is Marco's suggestion: add

Am Montag, 8. August 2005 18:12 schrieb Reid Spencer: > Stephan, > > I've seen this before. It happens when you do "make bootstrap" in llvm-gcc. > While "make bootstrap" is the correct way to build GCC, its not the correct > way to build llvm-gcc. > > Based on my experience with this, I suggest you completely erase your build > tree and then follow

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.

Answers inline .. Stephan Wienczny wrote: > > Hallo, > > do you know if bootstrap is the default target? No, "all" is the default. > > This is what I'm doing: > <code> > inherit eutils > > DESCRIPTION="C, C++ Frontend for Low Level Virtual _Machine" > HOMEPAGE="http://llvm.org/" >

On Mon, Jun 13, 2005 at 11:02:10AM -0500, John Criswell wrote: > Cyrille Mescam wrote: > >Hi, > > > > > >When compiling the cfrontend for Linux/PPC architecture on a powermac > >G5, i got > >the following error : > > I hate to ask a silly question, but are you using "make bootstrap" to > build the cfrontend? Your output looks like gccas

> >> Just to make sure I understand how LLVM works, got a few >> clarifications: >> >> 1. The ppc code I'm generating with the -native-cbe is static, >> correct? > > Yes, it's purely static with the -native-cbe or -native options. Is there anything special flagwise that I would need to specify to tell it to include symbol and debug information?

Is it safe to use the LLVM cfrontend 1.6 with LLVM 1.7 or the latest LLVM from CVS? I am running OS X 10.3.9, which I believe corresponds to Darwin kernel version 7.9.0. When I tried to use the 1.7 cfrontend, I could not get LLVM 1.7 or the LLVM from CVS to compile. However, when I used the 1.6 cfrontend (which is additionally labeled Darwin 7.9.0), I was able to get them to compile.

LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. There is no reason to use it

On Fri, 30 Apr 2004, Patrick Flanagan wrote: > Thanks! Grabbed the latest from CVS and added that linker option to the > config file. It looks like it compiles and runs the SPEC tests ok now. Great! > Just to make sure I understand how LLVM works, got a few clarifications: > > 1. The ppc code I'm generating with the -native-cbe is static, correct? Yes, it's purely static