similar to: [LLVMdev] Current state of tests in llvm/test?

On Mar 16, 2005, at 22:13, Chris Lattner wrote: > Which 15 failures are those? Are they dated tests for the C/C++ > front-end whose date is later than the CFE build you are using? Ah ha! Of course. That makes perfect sense. 12 of the failures are in "CFrontend" and are dated 2005-01-02 through 2005-03-11. The remaining three are: FAIL:

On Wed, 16 Mar 2005, Evan Jones wrote: > Maybe I'm screwing something up, but with the current CVS build on x86 Linux, > I get the following output when I execute "make" in the test directory: > > === Summary === > > # of expected passes 978 > # of unexpected failures 15 > # of expected failures 32 > > >

I am currently trying to build the CVS version of LLVM, and no matter what I do, ./configure always reports that llvm-gcc cannot be found or is not working. I currently have the LLVM 1.4 llvm-gcc binaries. My path is set correctly: rn-spra1c07:~/llvm/llvm ejones$ which llvm-gcc /Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin/llvm-gcc rn-spra1c07:~/llvm/llvm ejones$ which llvm-g++

Evan, You need to tell configure where the install directory for all of llvm-gcc is located. When you configured llvm-gcc you provided a --prefix option to the configure script. The value of that option (location of where to install llvm-gcc) is what you need to provide to --with-llvmgccdir= when configuring LLVM. You should follow the instructions in the CFEBuildInstrs.html document:

On Feb 19, 2005, at 20:26, Reid Spencer wrote: > You need to tell configure where the install directory for all of > llvm-gcc is located. Ah ha. That was my problem. I forgot that I ran into this with LLVM 1.4 as well. Basically, I specified: --with-llvmgccdir=/Users/ejones/llvm/cfrontend/ppc/llvm-gcc/bin instead of: --with-llvmgccdir=/Users/ejones/llvm/cfrontend/ppc/llvm-gcc Which

The current LLVM CVS HEAD does not build for me (RedHat 9). The issue is a one line fix. The file "include/llvm/ADT/EquivalenceClasses.h" needs to include <stdint.h> in order to get the typedef for "intptr_t." If anyone wants me to make a patch for this, let me know. The build error that this solves is: llvm[3]: Compiling DataStructure.cpp for Debug build In file

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/

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

On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > At this point I cannot know the type of 'i' at compile time. At > runtime 'i' is a structure that contains a type and a function > pointer. What I can't figure out is how to cast my llvm function > pointer to an appropriate function type. I cannot know until runtime > what the type will be.

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

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, 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

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

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

> 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

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

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a

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.

> > There are two problems with this: 1) there is no JIT for PPC yet, so > LLVM will use the interpreter (which is intolerably slow and has other > issues). 2) Spec compiles the executables in one place and them moves > them to another, but it only copies the shell script and not the > bytecode file, so you get that error message. > > The normal solution to this problem

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