similar to: [LLVMdev] `make check' failures in r102924

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 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 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, I started playing with llvm on Darwin. When I do a "make check" from the llvm root, I am getting these failed tests: Failing Tests (13):     LLVM :: FrontendC++/2010-04-30-OptimizedMethod-Dbg.cpp     LLVM :: FrontendC++/2010-05-12-PtrToMember-Dbg.cpp     LLVM :: FrontendC/2007-05-16-EmptyStruct.c     LLVM :: FrontendC/2007-10-01-BuildArrayRef.c     LLVM ::

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

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

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

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 some basic tests, analyzed dumps of both the objects files and the final

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

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 some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks

Hi David, On Fri, Jul 9, 2010 at 3:25 PM, David Greene <dag at cray.com> wrote: > Now that Bruno is putting in some AVX stuff, it's a good motivator to > move my x86 SIMD reorg work into trunk (and got management to agree to > prioritize it - Thanks Bruno! :) ). > > Attached is the first patch of many to accomplish this.  The overall > goal is to have all x86 SIMD

Hello, I just built a virgin ToT (r98634) for release on vanilla Snow Leopard. It seems that the Hello pass doesn't want to load because of undefined symbols: builddir% ../llvm/configure --prefix=$(PWD)/../installdir --enable-optimized builddir% make builddir% make install && cd ../installdir installdir% bin/opt -load lib/libLLVMHello.dylib Error opening

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:

Now that Bruno is putting in some AVX stuff, it's a good motivator to move my x86 SIMD reorg work into trunk (and got management to agree to prioritize it - Thanks Bruno! :) ). Attached is the first patch of many to accomplish this. The overall goal is to have all x86 SIMD instructions share a set of common patterns so that we can have a more maintainable machine description (e.g. SS, SD,

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: