similar to: [LLVMdev] verbose check-all with cmake?

> 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

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

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

> it assumes that compiler-rt is checked out to > llvm/projects/compiler-rt. Apparently, this is a problem. I have a patch for this ready. I'll send it to you and llvm-commits. Most of the tests pass with "make check-all" but the recently-added lsan tests are all failing. Do those fail for you as well? If so, can we XFAIL them for now and try to keep the "make

As a temporary fix, you can replace this line in sanitizer_linux_libcdep.c: const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304); with const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); The tests should pass after that. I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. On Fri, May 31, 2013 at 8:48 PM, Greg

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

I blame this line in lsan/lit_tests/lit.cfg: # Setup attributes common for all compiler-rt projects. compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", "compiler-rt", "lib", "lit.common.cfg") On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com>wrote: > > On Fri, May 24,

Those changes shouldn't affect ARM at all, since everything is under #if defined(__i386__) || defined(__x86_64__). What version of glibc are you building with on x86? On Fri, May 31, 2013 at 7:16 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my > example code segfaults, whereas before it worked. I

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

> What version of glibc are you building with on x86? 2.11.1 for 64-bit x86 linux $ ldd --version ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1 On Fri, May 31, 2013 at 8:24 AM, Sergey Matveev <earthdok at google.com> wrote: > Those changes shouldn't affect ARM at all, since everything is under #if > defined(__i386__) || defined(__x86_64__). > > What version of glibc are

I'm hoping to revive the LLD standalone CMake build. I'm new to this build but it looks like it borrowed code from an old version of compiler-rt, which I did some work on last year. Like compiler-rt, I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > it assumes that compiler-rt is checked out to > > llvm/projects/compiler-rt. Apparently, this is a problem. > > I have a patch for this ready. I'll send it to you and llvm-commits. > Most of the tests pass with "make check-all" but the recently-added lsan > tests are

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

> const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); Yes, that change causes all tests to pass. > I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. Okay, no worries, thanks for doing this. I've moved over to release_33 for the short-term. With the one change mentioned earlier (#include <stdint.h>), asan

> Not that I know of, and I always build compiler-rt natively, together with Clang and LLVM. :( Do you mean "natively on ARM" or "natively on X86 with the ARM target enabled"? If the former, do you have a script to merge the target libs into the host's install directory? If the latter, that'll only build the X86 versions of the compiler-rt libraries. > Would

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require

On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <garious at gmail.com> wrote: > For me, UBsan fails with clang 3.2 and passes with clang 3.3. > Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong). I don't really want to mark these tests as "failing