similar to: [LLVMdev] test suite and int main

On Wed, 2011-11-02 at 11:07 -0700, Eli Friedman wrote: > On Wed, Nov 2, 2011 at 10:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > I'm just setting up the test suite, and I'm seeing a lot of failures > > from main() not returning int, etc. in some of the tests. Is this > > normal? > > > > For example: > >

On Wed, Nov 2, 2011 at 10:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I'm just setting up the test suite, and I'm seeing a lot of failures > from main() not returning int, etc. in some of the tests. Is this > normal? > > For example: > Output/2003-07-09-LoadShorts.cbe.c:117:1: error: 'main' must return > 'int' > unsigned int main(unsigned

On Nov 2, 2011, at 11:18 AM, Hal Finkel wrote: > On Wed, 2011-11-02 at 11:07 -0700, Eli Friedman wrote: >> On Wed, Nov 2, 2011 at 10:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: >>> I'm just setting up the test suite, and I'm seeing a lot of failures >>> from main() not returning int, etc. in some of the tests. Is this >>> normal? >>>

Hi all, llvm-test fails on me in the first test (and many subsequent tests, but I hope that fixing the first test will allow me to continue). I see syntax errors from the C compiler and core dumps from llc. Is any of this supposed to happen? This is still on my amd64 machine. However, the build process is using the right incantation to compile (gcc-4.2 -m32 -Wl,-melf_i386). The llvm-gcc

Hi Devang, I've tried the OPTBETA approach, and it now runs with and without my patch succesfully. I've found two problems, however: 1. The output of the nightly report does not include the figures from opt-beta by default. I've modified the TEST.nightly.report script to add two columns (OPT-BETA and LLC/OPT-BETA), but committing this change would mean that most users will be

Hello, Some problems were solved, new ones arised... Getting closer though... The fixes for the previous problems are at the bottom of this email, bug reports will be submitted when all problems are solved. +++ New/remaining problems +++ Currently, 9/26 benchmarks compile and run succesfully. One (fma3d) still has a f95 related problem (see below). The other 16 are divided into two groups:

Hi, SQLite3 has a very simple build system, and it comes with an extensive testsuite (over 40000 tests). It hasn't shown any bugs in LLVM, but it is fairly simple to build [even turn off features via -D], and can be CPU intensive. I have integrated SQLite3 into llvm-test's build system, it is too large to send as attachment (784K), you can get it from here:

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

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

Hello, I'm trying to add some tests from PARSEC to MultiSource, and I can't figure out how to disable the lli and cbe backends. Because the code uses inline assembly, only the llc backend works. Does anyone know how to do this? Thanks, --Patrick -- If I'm not here, I've gone out to find myself. If I get back before I return, please keep me here.

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

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

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

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

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

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

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>

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

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

Everything builds fine on sparc. The configure script needs to be fixed though (see previous email). Sparc testing results: make check: # of expected passes 1189 # of expected failures 34 Regressions Single Source: None New Failures Single Source (new tests): 2005-05-12-Int64ToFP: llc,jit Regressions MultiSource: Applications/d/make_dparser: llc, cbe, jit