search for: dllvm_lit_args

...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 Lot's of different errors, but this one stands out (from 'check-tsan'): cannot find "bin/../lib/clang/3.4/lib/linux/libclang_rt.tsan-arm.a" No surprise that library is missing - the ARM Linux runtime doesn't have enough information to build. We...

...pecific: it only happens during optimized compile using Clang-3.9. This is all I did: 1. checkout LLVM/clang trunk 2. make sure clang in path is clang-3.9 3. cmake .. -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_ENABLE_ASSERTIONS=On -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DLLVM_LIT_ARGS="-v --vg" 4. ninja check John

...gt; -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 > > > Lot's of different errors, but this one stands out (from 'check-tsan'): > > cannot find "bin/../lib/clang/3.4/lib/linux/libclang_rt.tsan-arm.a" > > No surprise that library is missing - the ARM Linux runtime doesn'...

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

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

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

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 cpus. paul

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

...cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/w/c/org -DLLVM_TARGETS_TO_BUILD:STRING=all -DLLVM_BUILD_RUNTIME:BOOL=ON -DLIBCLANG_BUILD_STATIC=ON -DLLVM_ENABLE_PIC:BOOL=ON -DLLVM_ENABLE_ASSERTIONS:BOOL=ON -DLLVM_INCLUDE_TOOLS:BOOL=ON -DLLVM_LIT_ARGS:STRING="-s -v" -DWITH_POLLY:BOOL=ON -DLINK_POLLY_INTO_TOOLS:BOOL=ON -DCMAKE_C_COMPILER=/w/c/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang -DCMAKE_CXX_COMPILER=/w/c/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/bin/clang++ -DCMAKE_CXX_FLAGS='-stdlib=libc++'...

...-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 >> >> >> Lot's of different errors, but this one stands out (from 'check-tsan'): >> >> cannot find "bin/../lib/clang/3.4/lib/linux/libclang_rt.tsan-arm.a" >> >> No surprise that library is missin...

Just to follow-up, I'm now encountering this as well. I'm doing this on Linux. It seems that when linking with the most-recently built clang, the unit tests are taking a while to complete. It's notably not using more than 1 thread, and if using `lld` I would have expected the linker to still be running in parallel. I'm doing this on a debug build, so that might help narrow it

...OOL=OFF include/llvm/Config/llvm-config.h:/* Defined in debug builds and release builds if LLVM_FORCE_ENABLE_DUMP is what I see from a cmake options of... -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DCOMPILER_RT_ENABLE_IOS:BOOL=OFF -DLLVM_ENABLE_FFI=ON -DFFI_INCLUDE_DIR=/sw/include -DFFI_LIBRARY_DIR=/sw/lib -DLLVM_LIT_ARGS:STRING=-v -DPYTHON_EXECUTABLE:FILEPATH=/sw/bin/python2.7 -DLIBOMP_OSX_ARCHITECTURES=x86_64;i386 -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF -DCMAKE_OSX_SYSROOT:STRING=/ -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING= -DLLVM_TARGETS_TO_BUILD=X86;PowerPC;ARM -DCMAKE_INSTALL_PREFIX:PATH=/sw/opt/llvm-6.0 -DCMAKE_BUILD_TYP...

...builds and release >> builds if LLVM_FORCE_ENABLE_DUMP >> >> is what I see from a cmake options of... >> >> -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DCOMPILER_RT_ENABLE_IOS:BOOL=OFF >> -DLLVM_ENABLE_FFI=ON -DFFI_INCLUDE_DIR=/sw/include >> -DFFI_LIBRARY_DIR=/sw/lib -DLLVM_LIT_ARGS:STRING=-v >> -DPYTHON_EXECUTABLE:FILEPATH=/sw/bin/python2.7 >> -DLIBOMP_OSX_ARCHITECTURES=x86_64;i386 -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF >> -DCMAKE_OSX_SYSROOT:STRING=/ -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING= >> -DLLVM_TARGETS_TO_BUILD=X86;PowerPC;ARM -DCMAKE_INSTALL_PREFIX:PAT...

After re-cmaking and rebuilding everything from scratch, I'm seeing failures in MCJIT. It this something known or expected? I build LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". Example failure: /w/bld/org/./bin/lli -remote-mcjit -mcjit-remote-process=/w/bld/org/./bin/lli-child-target /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll -- Exit Code:

Well, it looks like almost all of the problems go away when I build using trunk instead of 3.9. So, that was scary but I'm going to forget it ever happened. >8000 test cases failed under Valgrind!! John On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote: > Hi John, > > This is probably somewhat of a stretch, but since the problem does not > happen with a Debug build,

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for