r286898 - [sanitizer] Passthrough CMAKE_OSX_DEPLOYMENT_TARGET when building compiler-rt from clang/runtime/CMakeLists.txt

Author: kuba.brecka Date: Mon Nov 14 16:38:57 2016 New Revision: 286898 URL: http://llvm.org/viewvc/llvm-project?rev=286898&view=rev Log: [sanitizer] Passthrough CMAKE_OSX_DEPLOYMENT_TARGET when building compiler-rt from clang/runtime/CMakeLists.txt This breaks some Swift builds, because Swift's

[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

kubabrecka added a comment. This passes TSan tests on Darwin. LGTM. https://reviews.llvm.org/D24991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

kubabrecka added a comment. In https://reviews.llvm.org/D24991#586219, @sebpop wrote: > I just ran ninja check-all with and without this patch and there are no > regressions in compiler-rt on an x86_64-linux machine. The TSan interceptors (and testcases) are Darwin-only at this point. I'll ru

[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

kubabrecka added a comment. Just a question: TSan intercepts on the dylib functions, namely `__release_shared`, to track the atomic accesses. Can you make sure this doesn't break? There's a few testcases for this in compiler-rt. https://reviews.llvm.org/D24991 ___

[PATCH] D25857: [tsan][clang] Introduce a function attribute to disable TSan checking at run time

kubabrecka added a comment. Does this also disable checking for the compiler generated `.cxx_destruct` Obj-C methods? Can we add a testcase both here and into compiler-rt? https://reviews.llvm.org/D25857 ___ cfe-commits mailing list cfe-commits@li

[libcxx] r281603 - [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneously

Author: kuba.brecka Date: Thu Sep 15 06:04:53 2016 New Revision: 281603 URL: http://llvm.org/viewvc/llvm-project?rev=281603&view=rev Log: [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneously Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”). Differe

[libcxx] r281477 - [libcxx] Add a TSan regression test for a data race in call_once

Author: kuba.brecka Date: Wed Sep 14 09:15:42 2016 New Revision: 281477 URL: http://llvm.org/viewvc/llvm-project?rev=281477&view=rev Log: [libcxx] Add a TSan regression test for a data race in call_once Differential Revision: https://reviews.llvm.org/D24297 Added: libcxx/trunk/test/std/thr

[libcxx] r281476 - [libcxx] Fix a typo in test/libcxx/test/target_info.py that prevents running tests on Darwin with sanitizers

Author: kuba.brecka Date: Wed Sep 14 09:13:50 2016 New Revision: 281476 URL: http://llvm.org/viewvc/llvm-project?rev=281476&view=rev Log: [libcxx] Fix a typo in test/libcxx/test/target_info.py that prevents running tests on Darwin with sanitizers Differential Revision: https://reviews.llvm.org/D

[libcxx] r281475 - [libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS X

Author: kuba.brecka Date: Wed Sep 14 09:12:50 2016 New Revision: 281475 URL: http://llvm.org/viewvc/llvm-project?rev=281475&view=rev Log: [libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS X This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMak

Re: [PATCH] D24048: [Driver] [Darwin] Add sanitizer libraries even if -nodefaultlibs is passed

kubabrecka added a comment. Anyone who uses `-nostdlib` or `-nodefaultlibs` has to be aware that his program will be linked with less stuff than usual and has to expect linker error. If such a user doesn’t know that ASan and TSan require a dylib on macOS, he should be able to figure this out f

[libcxx] r280621 - [libcxx] Fix a data race in call_once

Author: kuba.brecka Date: Sun Sep 4 04:55:12 2016 New Revision: 280621 URL: http://llvm.org/viewvc/llvm-project?rev=280621&view=rev Log: [libcxx] Fix a data race in call_once call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load

Re: [PATCH] D21082: Do not assume that -fsanitize=address is valid option in clang tests

kubabrecka added a subscriber: kubabrecka. kubabrecka added a comment. This doesn’t make sense to me, Clang is able to produce ASanified code even when the compiler itself isn’t ASanified (that’s what LLVM_USE_SANITIZER does). Where exactly is this test failing? Repository: rL LLVM http://

Re: [PATCH] D18280: [tsan] Allow -fsanitize=thread for iOS-style simulator targets

kubabrecka added a comment. LGTM after adding a check for a simulator. http://reviews.llvm.org/D18280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

kubabrecka added inline comments. Comment at: test/Driver/fsanitize.c:221 @@ +220,3 @@ +// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DA

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

kubabrecka added inline comments. Comment at: test/Driver/fsanitize.c:221 @@ +220,3 @@ +// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DA

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

kubabrecka added a comment. > The one thing I'm not sure about on this is, do we really want this to be > darwin-only? I kinda think it might be nice if we unified this behavior > across all platforms. > ... I wonder if this can't be better abstracted. > I'd really like to see all operating

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

kubabrecka updated this revision to Diff 42041. kubabrecka added a comment. Applying clang-format. http://reviews.llvm.org/D15225 Files: include/clang/Basic/DiagnosticDriverKinds.td include/clang/Driver/ToolChain.h lib/Driver/SanitizerArgs.cpp lib/Driver/ToolChain.cpp lib/Driver/ToolC

r252311 - Followup test failure fix for r252310 ("[tsan] Add Clang frontend support for TSan on OS X").

Author: kuba.brecka Date: Fri Nov 6 09:20:30 2015 New Revision: 252311 URL: http://llvm.org/viewvc/llvm-project?rev=252311&view=rev Log: Followup test failure fix for r252310 ("[tsan] Add Clang frontend support for TSan on OS X"). Modified: cfe/trunk/test/Driver/fsanitize.c Modified: cfe/

r252310 - [tsan] Add Clang frontend support for TSan on OS X

Author: kuba.brecka Date: Fri Nov 6 09:09:20 2015 New Revision: 252310 URL: http://llvm.org/viewvc/llvm-project?rev=252310&view=rev Log: [tsan] Add Clang frontend support for TSan on OS X We're currently in process of porting TSan to OS X, and quite a few of the initial support in the runtime l

[PATCH] D14440: [tsan] Add Clang frontend support for TSan on OS X

kubabrecka created this revision. kubabrecka added reviewers: dvyukov, samsonov, kcc, glider. kubabrecka added subscribers: cfe-commits, zaks.anna, ismailp, jasonk, jevinskie. We're currently in process of porting TSan to OS X, and quite a few of the initial support in the runtime library has al

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

kubabrecka added a comment. > > I first noticed it when I tried to run the version of clang-tidy I'd just > > built and found I had to pass the path for it to find iostream. > > > I think it works if you a) check out libcxx into llvm/projects/libcxx b) run > `make install` and c) run the bi

Re: [PATCH] D12646: Add libc++ header path for DarwinClang builds

kubabrecka added a comment. In what scenario exactly are you seeing an issue? If it's a just-built clang that can't find C++ headers, then you should just build the libcxx project alongside. Comment at: lib/Driver/ToolChains.cpp:290-295 @@ +289,8 @@ + + // FIXME: We shou

Re: [PATCH][www] Mention that libcxx is necessary on OS X

> On 07 Sep 2015, at 17:21, Nico Weber wrote: > > libcxx is needed to run compiler-rt tests, but it shouldn't be needed to run > clang's tests. And to _use_ your self-built compiler, you need to add > `-isysroot $(xcrun -show-sdk-path)` to the compile flags to let the compiler > find C header

Re: [PATCH][www] Mention that libcxx is necessary on OS X

I’m also curious what exact test failed for you with the "can't find iostream” error. AFAIK, you should currently receive the explaining message instead. But anyway, I’d also like to see libcxx[abi] mentioned in the Getting started page. Kuba > On 04 Sep 2015, at 23:07, Yuri Gribov