similar to: [LLVMdev] 1.9 Next Steps

Hi Tanya, I've been checking the state of the various llvm-test failures on X86/Linux with GCC 3.4.6 and llvm-gcc4. I haven't finished this, but I thought the following might be useful for other people that are testing the release on Linux. Each group of failing tests below is followed by a comment about why its failing. llc /MultiSource/Applications/oggenc/oggenc jit

Hi Tanya, Here's my second attempt on Fedora Core 5. The changes this time are: 1. Using GCC 4.0.3 as the compiler 2. Building everything from source (no pre-built binaries used) BUILD LLVM WITH GCC 4.0.3 * No issues, just the usual warnings. BUILD LLVM-GCC WITH GCC 4.0.3 * No issues RUN LLVM-TEST WITH GCC 4.0.3 * The following failures were encountered. Some of them are

LLVMers, The LLVM 1.9 Prerelease is available for testing: http://llvm.org/prereleases/1.9/ If anyone can spare some time, please download the appropriate tarballs for your platform and test the release (at least with make check). I'd also appreciate any documentation reviews. Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You should see one XPASS for

Tanya, Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) HIGH LEVEL COMMENTS * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't that be llvm-1.9? * LLVM was built in Release mode in all cases * I don't think this is ready for release. In particular the llvm-gcc4 binary seg faults on FC 5 for most of llvm-test programs. *

Hello; I was able to build and install 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 like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

LLVMers, The 2.2 prerelease is now available for testing: http://llvm.org/prereleases/2.2/ If anyone can help test this release, I ask that you do the following: 1) Build llvm and llvm-gcc (or use a binary). You may build release (default) or debug. You may pick llvm-gcc-4.0, llvm-gcc-4.2, or both. 2) Run 'make check'. 3) In llvm-test, run 'make TEST=nightly report'. 4) When

Hi Tanya, > 1) Compile llvm from source and untar the llvm-test in the projects > directory (name it llvm-test or test-suite). Choose to use a > pre-compiled llvm-gcc or re-compile it yourself. I compiled llvm and llvm-gcc with separate objects directories. Platform is x86_64-linux-gnu. > 2) Run make check, report any failures (FAIL or unexpected pass). Note > that you need to

LLVMers, The 2.1 pre-release (version 1) is available for testing: http://llvm.org/prereleases/2.1/version1/ I'm looking for members of the LLVM community to test the 2.1 release. There are 2 ways you can help: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download

On Tue, Nov 07, 2006 at 10:39:46PM -0800, Tanya M. Lattner wrote: > cvs -d <CVS Repository> co -r release_19 llvm I'm getting a build error: llvm[2]: Compiling llvmAsmParser.cpp for Release build /rest/llvm/llvm/lib/AsmParser/llvmAsmParser.y: In function `int llvmAsmparse()': /rest/llvm/llvm/lib/AsmParser/llvmAsmParser.y:2105: error: expected `;' before '}' token

At the LLVM Developers' Meeting in November, I promised to work on isolating a subset of the current test suite that is useful for benchmarking. Having looked at this in more detail, most of the applications and benchmarks in the test suite are useful for benchmarking, and so I think that a better way of phrasing it is that we should construct a list of programs in the test suite that are not

LLVMers, 2.6 pre-release2 is ready to be tested by the community. http://llvm.org/prereleases/2.6/ If you have time, I'd appreciate anyone who can help test the release. To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it llvm-test or test-suite). Choose to use a pre- compiled llvm-gcc or re-compile it yourself. 2) Run make check,

G'Day Tanya, Is it too late to bring in the following patches to fix some major brokenness in the AuroraUX tool chain for 2.6? http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make

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 Apr 4, 8:06 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 4, 7:51 pm, Török Edwin <edwinto... at gmail.com> wrote: > > > > > heisenbug wrote: > > > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > > > ... > > > >>> 3) Make sure that make check and some reasonable subset of llvm-test > > >>>

On Thu, 9 Sep 2004 20:16:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Thu, 9 Sep 2004 08:52:10 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > > I haven't got around to this yet but I will. The odds are good the > > > problem is in a BSD system header file so I need to capture the > > > preprocessed source. > > >

Dale, Thanks for reviewing this. I have some newbie questions regarding the test-suite for you or anyone: I'm trying to run the test-suite as described in the "LLVM Testing Infrastructure Guide" on a Ubuntu x86 64 bit system. Initially I ran into problems with missing tools like yacc, which I fixed as I went along until the make at the test-suite level completed. However, I get

Dale, I took a closer look at the first llc failure, initp1. Looking at the initp1.llc file in gdb, it appears that the statically constructed objects without the init_priority attribute are being constructed before those with it, though the test seems to expect the opposite. The initp1.llc.s file seems to have the .ctors table in the right order, but the _init code is reading the table in

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

CBE is fairly broken everywhere AFAIK, don't worry about it. Most of the JIT failures are in tests that exercise exception handling. Not sure if that is supposed to work in your environment, it works in some JITs and not others. The LLC failures are cause for concern. On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote: > Dale, > > Thanks for reviewing this. > > I have