similar to: [LLVMdev] PowerPC Regressions for LLVM 1.6

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

Dear All, I've created the LLVM release branch (CVS tag release_16). Those developers wanting to commit changes to LLVM without having your changes go into LLVM 1.6 can now commit to CVS mainline to your heart's content. :) TESTING: -------- 1. I'm still looking for volunteers to test MacOS X and Solaris. If you'd like to volunteer, please email the list to let us know.

>> Everything builds fine on sparc. The configure script needs to be fixed >> though (see previous email). > > I'm not getting the error with the configure script (on Kain, anyway). I've > tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my > $PATH. I get the error with and without the --with-f2c option. I never used the NAG Fotran

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

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

On Aug 30, 2010, at 3:11 PMPDT, John Thompson wrote: > 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

Tanya Lattner wrote: > > Everything builds fine on sparc. The configure script needs to be fixed > though (see previous email). I'm not getting the error with the configure script (on Kain, anyway). I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in and out of my $PATH. Can you verify that the configure script works for you without the --with-f2c option?

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

On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote: > 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? In principle, yes, I'd like to rereview if it's changed. > My

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

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests 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

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>

Dear All, I have found the following regressions on Linux/i386: 176.gcc (cbe, llc, jit) 252.eon (cbe, llc, jit) 126.gcc (cbe, llc, jit) Named (llc, jit) I ran a quick test on 176.gcc, and it doesn't seem to be an optimization problem. -- John T. -- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite

Tanya Lattner wrote: > >>> Everything builds fine on sparc. The configure script needs to be >>> fixed though (see previous email). >> >> >> I'm not getting the error with the configure script (on Kain, anyway). >> I've tried it with --with-f2c and with f96 (NAG Fortran compiler) in >> and out of my $PATH. > > > I get the

Chris Lattner wrote: > On Thu, 12 May 2005, John Criswell wrote: > >> Here is a more complete list of regressions for the platforms listed >> below. Some of the regressions from the previous list I emailed a few >> days ago have been fixed or were false positives. Thanks to all >> who've helped fix things. >> >> We would like to try to get as many

For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It didn't make a difference. So here are the failures for llvm-test. All diffs are against the "native" output. ===================== MultiSource/Applications/sgefa cbe failed differently from jit/llc. First cbe: 84c84 < One-Norm(A) ---------- 8.879153e+02. --- > One-Norm(A) ---------- 8.879156e+02.

Valery A.Khamenya wrote: >>For example: >>$ llvmgcc ackerman.c -o ackerman -Wl,-native-cbe > > > BTW, Chris, what should be then an analogy > of "gcc -O3 -S foo.c" in LLVM framework? > > The invocation of > > $ llvmgcc -S ackerman.c -o ackerman -Wl,-native-cbe > > does not produce native assebler output as one might expect.

On Jan 30, 2008, at 9:12 PM, Apache wrote: > http://llvm.org/nightlytest/test.php?machine=231&night=4754 > Name: il0102a-dhcp80.apple.com > Nickname: OldGrawp-O0-PIC > Buildstatus: OK > > New Test Passes: > test/CFrontend/2008-01-28-PragmaMark.c [DEJAGNU] > > > New Test Failures: > Benchmarks/Shootout-C++/except [LLC compile, ] >

It's me. Our ISD::LABEL implementation has issues... Evan On Jan 30, 2008, at 9:34 PM, Dale Johannesen wrote: > > On Jan 30, 2008, at 9:12 PM, Apache wrote: > >> http://llvm.org/nightlytest/test.php?machine=231&night=4754 >> Name: il0102a-dhcp80.apple.com >> Nickname: OldGrawp-O0-PIC >> Buildstatus: OK >> >> New Test Passes: >>