similar to: [LLVMdev] Setting number of lit threads with make check

Try: make check-all LIT_ARGS="-s -j10" To limit the threads to 10, for example. On Wed, Jan 16, 2013 at 1:38 PM, Redmond, Paul <paul.redmond at intel.com> wrote: > Hi, > > Does anyone know how I can set the number of threads lit uses when invoked by make check? Lit has the —threads argument but this doesn't get set when run through make so it uses the max number of

Folks, Some of our CMake buildbots are failing to timeout, and I believe it's something to do with how the output comes from the LIT tests, even though we add -v to LIT_ARGS. When the "check-all" stage runs, the output stops at the "Running tests" message and only prints the rest of the output (including all tests that pass, fail, etc) at the end. I believe this has to

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all

Hi. I just want to know does anyone has the same problem or not. After running "make check-lit" tests are stopped at 61th percent (Linker tests). Each time it stops on different tests. Thanks. -- Regards, Stepan

Are there any sanitizer lit tests in non-X86 configurations? For example: $ cmake -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi All ASan tests were removed from the build and all the other sanitizers have tests but they all fail. Should they all be disabled too? Or can we add a REQUIRES tag to get lit to

Yes, I think we should disable sanitizer tests on these platforms. What is the exact line you use to configure build tree, and the output you see? On Fri, Oct 25, 2013 at 2:45 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Are there any sanitizer lit tests in non-X86 configurations? For example: > > $ cmake -DLLVM_TARGETS_TO_BUILD=ARM \ >

On Tue, Oct 29, 2013 at 10:55 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > What is the exact line you use to configure build tree, and the output > you see? > > cmake ../.. \ > -G Ninja \ > -DCMAKE_INSTALL_PREFIX=ship \ > -DCMAKE_BUILD_TYPE=Release \ > -DLLVM_ENABLE_ASSERTIONS=ON \ > -DLLVM_TARGETS_TO_BUILD=ARM \ >

Hm... tests were corrected themselves. No svn updates was made. 0. I turned on my laptop and boot Ubuntu 11.04. 1. I run ../llvm/configure in clean folder. 2. make 3. make check-lit 4. Tests was looped at 61%. Eclipse doesn't want to debug it too. It crashes at the start of debug session. I reboot my computer again, and all work well now. Probably some specific bios + OS + (specific cpu

----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On

Thanks, Anton. I always forget about llvm-admin :). I'd say converting all branches would be best, would help track the MCJIT work for example. Gaël, does that sound good to you? You're the one making all the commits these days :). ~Will On Sun, Jan 5, 2014 at 9:03 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > I can create a mirror, this is not

Hi all, Don't suppose VMKit could be added to the set of subprojects with official git mirrors? Please and thank you! :) ~Will

missing-abstract-variable is a recent one I introduced - looking into it. On Wed, Jun 4, 2014 at 2:39 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi Hal, > > These tests failures go away when I disable static libs aka > -DBUILD_SHARED_LIBS=OFF , with that only 2 regtest failures are left: > > > [ 1314s] FAILED: cd /home/abuild/rpmbuild/BUILD/llvm/stage2/test

Hmm, disregard my previous comment (while you might still have issues with 64bit, that's not what's primarily causing your issue)--your particular error is when you don't point vmkit to the classpath libraries properly. Set it with the configure option --with-gnu-classpath-glibj=/path/to/classpath-0.97.2/lib/glibj.zip Good luck! ~Will On Tue, Aug 23, 2011 at 5:49 PM, Will Dietz

Thanks for the response, Eli. The header suggestion could certainly cause this issue (I panicked for a second), but unfortunately as far as I can tell the headers are in fact from LLVM 2.7. The pass is built as a project configured by llvm, so hopefully that would make things right, but also: --include paths look legit (make VERBOSE=1, etc) --strace on the build process for the project confirms

> Do I understand correctly that you build Clang that targets ARM on an X86 host? Correct. > If yes, then we should modify compiler-rt CMake rules to check if just-built Clang can target the host system and avoid running any sanitizer tests otherwise. Hmm, depends on the tests, I suppose. If the test runs the executable, then yes it should be disabled (or prefixed with an emulator (i.e.

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?

Is there an equivalent "make check-all VERBOSE=1" in the CMake build? I'm looking to see the full list of unit tests and the result of each. Thanks, Greg

Hi all, First time posting to llvmdev, be gentle :). I'm working on an AliasAnalysis implementation and running into an issue on 2.7, that doesn't exist in 2.6 as far as I can tell. Short version: has anyone been able to load an AliasAnalysis module into 2.7's opt? Longer version: Even with a dummy pass implementation (just returns MayAlias for everything), I'm getting very

Hi, I added some tests to test/CodeGen/Generic/intrinsics.ll. I couldn't find a way to run make check for a particular architecture so I ran llc -march= manually for all architectures. I found that intrinsics.ll does not compile for all architectures out of the box. For example with march=sparcv9 it fails when "Running pass 'SPARC DAG->DAG Pattern Instruction Selection' on

Ah yes, thanks, this was one problem, now I hit another: llvm[2]: Building Release+Asserts mmtk-vmkit.jar all Thread 0x110000000 received a SIGSEGV: either the VM code or an external native method is bogus. Aborting... ; 0x5cfeed (0x1100fe410) in _Z14sigsegvHandleriP7siginfoPv ; 0x2b889c232c60 in Unknown method ; 0x561499 (0x1100fe900) in _ZN2j310JavaObject7acquireEPS0_ ; 0x55b464 (0x1100fe920)