similar to: [LLVMdev] dejagnu test failures on x86-32 linux

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:

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:

Since it came up, what is blocking us from putting these tests in the llvm-gcc test suite instead of in the LLVM test suite? - Daniel On Tue, Jul 14, 2009 at 4:01 AM, Jakob Stoklund Olesen<stoklund at 2pi.dk> wrote: > > On 14/07/2009, at 12.35, Harel Cain wrote: >> When using "make check" with the DejaGNU test collection, I encounter >> two unexpected failures

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

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 everyone, I'm wrestling with the LLVM unit and regression tests now and would like to discuss some changes to make. I will be preparing patches, but any input/ideas are welcome. I leave "where the tests should run" question out for the scope yet. Let's review what kind of tests we have and how to handle them correctly. We have 3 types of unit and regression tests: 1.)

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

Hi Daniel, > Since it came up, what is blocking us from putting these tests in the > llvm-gcc test suite instead of in the LLVM test suite? they are useful for testing the llvm gcc plugin. This is llvm-gcc implemented as a gcc plugin. As such, it is not possible to make modifications to the underlying gcc tree, such as adding testcases, except by pushing changes upstream to mainline gcc.

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 Tue, Jul 14, 2009 at 8:49 AM, Daniel Dunbar<daniel at zuster.org> wrote: > Since it came up, what is blocking us from putting these tests in the > llvm-gcc test suite instead of in the LLVM test suite? Usually we want to check these tests regularly against llvm backend changes. The nightly tester does not svn update and rebuild llvm-gcc hence these tests are in LLVM Test Suite.

I built my package under the R version 2.14.1 on windows without any problems by first checking for issues using R CMD check (no warnings) and then R CMD build to build the tar.gz. I can install this on version 2.14.1 using install.packages(...). I next tested to see if I could also install on version 2.15.0 (also on my computer) using install.packages() with the version 2.14.1 tar.gz this

On Tue, Jul 14, 2009 at 11:08 AM, Tanya Lattner<lattner at apple.com> wrote: > > On Jul 14, 2009, at 10:03 AM, Devang Patel wrote: > > On Tue, Jul 14, 2009 at 8:49 AM, Daniel Dunbar<daniel at zuster.org> wrote: > > Since it came up, what is blocking us from putting these tests in the > > llvm-gcc test suite instead of in the LLVM test suite? > > Usually we

Hello: Under my Windows 7 system, "R CMD check DiercxkSpline_1.1-5.tar.gz" fails because: f951.exe: sorry, unimplemented: 64-bit mode not compiled in make: *** [bispev.o] Error 1 gfortran -m64 -O2 -mtune=core2 -c bispev.f -o bispev.o f951.exe: sorry, unimplemented: 64-bit mode not compiled in make: *** [bispev.o] Error 1 ERROR: compilation failed for package

All passes: # of expected passes 1415 # of expected failures 31 Evan

I should mention a couple of useful self-explanatory LLVM flags for triage: -enable-misched=false -verify-misched -Andy On Oct 15, 2013, at 4:43 PM, Eric Christopher <echristo at gmail.com> wrote: > Grats on the work, a long time coming! > > Beware the incoming register allocation bugs ;) > > -eric > > On Tue, Oct 15, 2013 at 4:33 PM, Andrew Trick <atrick at

On Jul 14, 2009, at 10:03 AM, Devang Patel wrote: > On Tue, Jul 14, 2009 at 8:49 AM, Daniel Dunbar<daniel at zuster.org> > wrote: >> Since it came up, what is blocking us from putting these tests in the >> llvm-gcc test suite instead of in the LLVM test suite? > > Usually we want to check these tests regularly against llvm backend > changes. The nightly tester

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

Using the command: llvm-gcc -m64 hello.c resulted in the following error: sorry, unimplemented: 64-bit mode not compiled in Bill Wendling wrote: > > Did you compile it with -m64? > > -bw > > On Jul 24, 2009, at 11:00 PM, funceval wrote: > >> >> Hi, >> >> I just installed llvm on a 64 bit system and tried running it on a >> hello >>

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