similar to: [LLVMdev] make check on Darwin - some failed tests.

I successfully built LLVM (r102824) with ./configure --enable-optimized --enable-targets=host --with-built-clang on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built version.) However, running `make check' produced 6 unexpected failures (see below). If there's something you'd like me to do, just holler. --- Vladimir FAIL:

On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: > I successfully built LLVM (r102824) with > > ./configure --enable-optimized --enable-targets=host --with-built-clang > > on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built > version.) and the llvm-gcc appears to be also? > However, running `make check' produced 6 unexpected failures

on 05/03/2010 11:13 AM Dale Johannesen said the following: > On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: > > >> I successfully built LLVM (r102824) with >> >> ./configure --enable-optimized --enable-targets=host --with-built-clang >> >> on Fedora 12 on an Athlon64 processor. (The clang is the 2.7 pre-built >> version.) > > and

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

On Feb 24, 2011, at 11:52 AM, Devang Patel wrote: > > On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > >> >> On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: >> >>> Hello All, >>> >>> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a

On Jul 5, 2009, at 5:09 PM, Bill Wendling wrote: > This should probably have these lines: > > // XFAIL: * > // XTARGET: darwin > > -bw > > On Jul 4, 2009, at 11:03 AM, Nick Lewycky wrote: > >> This doesn't work with my llvm-g++ on Linux:; My apologies. >> $ llvm-g++ test/FrontendC++/2009-06-30-ByrefBlock.cpp >>

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> This patch merely moves some common pattern fragments (memop, >> alignedload, etc.) to a file separate from X86InstrSSE.td so that all >> current x86 SIMD implementations can still use the classes while the >> transition happens. >> >> Ok to commit? > > I'm Ok with this patch. So

on 05/03/2010 12:43 PM Dale Johannesen said the following: > However, running `make check' produced 6 unexpected failures >>>> (see below). If there's something you'd like me to do, just holler. >>> >>> In general, tests added after a branch forked won't pass on that branch. That accounts for these at least: >> I don't understand. These

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the

On May 3, 2010, at 12:09 PMPDT, Vladimir G. Ivanovic wrote: > on 05/03/2010 11:13 AM Dale Johannesen said the following: >> On May 3, 2010, at 10:43 AMPDT, Vladimir G. Ivanovic wrote: >> >> >>> I successfully built LLVM (r102824) with >>> >>> ./configure --enable-optimized --enable-targets=host --with-built-clang >>> >>> on

On Dec 2, 2010, at 2:37 PM, Scott Ricketts wrote: > My install went fine except for some failures during make check > (Unexpected Failures: 92). All failures were in one of the following: > > LLVM::FrontendC++ > LLVM::FrontendC > LLVM::FrontendObjC++ > LLVM::FrontendObjC These are actually testing llvm-gcc, not llvm. If you build and install llvm-gcc, and tell llvm where

The only Transforms check that fails is LLVM :: Transforms/GVN/null-aliases-nothing.ll Could that be related? On Thu, Dec 2, 2010 at 2:50 PM, dalej <dalej at apple.com> wrote: > > On Dec 2, 2010, at 2:37 PM, Scott Ricketts wrote: > >> My install went fine except for some failures during make check >> (Unexpected Failures: 92). All failures were in one of the following:

Hi all, I recently experienced the same issue as below with LLVM 2.8 on Mac OS 10.5.8. I can load the pass with the debug version of opt, but not the optimized version. Does anyone know what the problem is or have any suggestions for debugging this? My install went fine except for some failures during make check (Unexpected Failures: 92). All failures were in one of the following:

On Dec 2, 2010, at 3:13 PM, Scott Ricketts wrote: > The only Transforms check that fails is LLVM :: > Transforms/GVN/null-aliases-nothing.ll > > Could that be related? running "opt -basicaa -gvn -S null-aliases-nothing.ll" should produce this output, what are you seeing? ; ModuleID = 'null-aliases-nothing.ll' %t = type { i32 } declare void @test1f(i8*) define

Hi all, When using "make check" with the DejaGNU test collection, I encounter two unexpected failures (they seem to be closely related). My question: are they well known, and if so what's the problem and how can I fix it? This is the error text I get: FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c Failed with exit(1) at line 1 while running:

Two failing tests on x86-32 linux: FAIL: test/FrontendC/2008-08-07-AlignPadding1.c Failed with exit(1) at line 1 while running: /usr/local/bin/llvm-gcc -emit-llvm -w test/FrontendC/2008-08-07-AlignPadding1.c -m64 -S -o - -emit-llvm -O0 | grep

Hi, I think I have discovered a bug in FreeBSD 4.8-STABLE's system C++ compiler: % gcc -v % Using builtin specs. % gcc version 2.95.4 20020320 [FreeBSD] Here is a stripped down example that can be used to reproduce the bug: // ----------- begin bug.cpp ----------- #include <iostream> class Class { public: void M1 (void) { cout << "M1" << endl; }; void M2

On 14/07/2009, at 12.35, Harel Cain wrote: > When using "make check" with the DejaGNU test collection, I encounter > two unexpected failures (they seem to be closely related). > My question: are they well known, and if so what's the problem and how > can I fix it? > FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19- > AlwaysInline.c > FAIL:

Building r80796 of the "release_26" branch on Ubuntu 9.04, I'm getting an XPASS on: ssen at ssen:~/llvm/build$ make TESTONE=FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c check-one make[1]: Entering directory `/home/ssen/llvm/build/test' Making a new site.exp file... XPASS: /home/ssen/llvm/test/FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c make[1]: Leaving directory

I experienced FAIL: /localtmp/astifter/llvm/llvm-svn/test/FrontendC/2007-03-27-VarLengthArray.c Failed with exit(1) at line 1 while running: /nfs/a5/astifter/astifter/llvm/llvm-svn-obj/../llvm-svn-install/bin/llvm-gcc -emit-llvm -w -S /localtmp/astifter/llvm/l lvm-svn/test/FrontendC/2007-03-27-VarLengthArray.c -o - | /bin/grep {getelementptr inbounds \[0 x i32\]} child process exited abnormally