[PATCH] D143675: Discussion: Darwin Sanitizers Stable ABI

kubamracek added a comment. @kcc Any takes from you on this? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143675/new/ https://reviews.llvm.org/D143675 ___ cfe-commits mailing list cfe-commits@lists.llvm

[PATCH] D112965: [GlobalDCE][IR] Allow and support multiple !vcall_visibility ranges

kubamracek created this revision. kubamracek added reviewers: pcc, rjmccall, fhahn. kubamracek added a project: LLVM. Herald added subscribers: ormris, dexonsmith, hiraditya. kubamracek requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Reposi

[PATCH] D112929: [Clang] For VFE, emit vtable ranges in !vcall_visibility metadata

kubamracek created this revision. kubamracek added reviewers: rjmccall, pcc, fhahn. kubamracek added a project: clang. kubamracek requested review of this revision. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D112929 Files: clang/lib/CodeGen/CGVTables.cpp clang/test/CodeGe

[PATCH] D98291: [compiler-rt] Fix stale incremental builds when using `LLVM_BUILD_EXTERNAL_COMPILER_RT=ON`.

kubamracek accepted this revision. kubamracek added a comment. Looks good! By the way, Apple Clang releases also build compiler-rt this way, so it would be worth checking with @arphaman that he's okay with the change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://r

[PATCH] D98291: [compiler-rt] Fix stale incremental builds when using `LLVM_BUILD_EXTERNAL_COMPILER_RT=ON`.

kubamracek added a comment. When using Ninja, does this mean running a null build is no longer a null build, but it at least always invokes this sub-build? Not saying that's bad, just want to understand the change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://revi

[PATCH] D84082: [tsan] Allow TSan in the Clang driver for Apple Silicon Macs

This revision was automatically updated to reflect the committed changes. Closed by commit rG33d9c4109ac2: [tsan] Allow TSan in the Clang driver for Apple Silicon Macs (authored by kubamracek). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84082/new/

[PATCH] D84082: [tsan] Allow TSan in the Clang driver for Apple Silicon Macs

kubamracek added a comment. Let's handle simulators separately. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84082/new/ https://reviews.llvm.org/D84082 ___ cfe-commits mailing list cfe-commits@lists.l

[PATCH] D84082: [tsan] Allow TSan in the Clang driver for Apple Silicon Macs

kubamracek created this revision. kubamracek added reviewers: dcoughlin, delcypher, yln, arphaman, steven_wu. kubamracek added a project: Sanitizers. Herald added subscribers: cfe-commits, Charusso, dexonsmith. Herald added a project: clang. Repository: rG LLVM Github Monorepo https://reviews.l

[PATCH] D50724: SafeStack: Disable Darwin support

kubamracek added a comment. Doesn't this need any tests to be updated? Otherwise, LGTM. Repository: rC Clang https://reviews.llvm.org/D50724 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cf

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

kubamracek added a comment. This looks great to me, but someone else should review this as well. https://reviews.llvm.org/D15225 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46363: Follow-up to r331378. Update tests to allow to use C atomics in C++.

kubamracek accepted this revision. kubamracek added a comment. This revision is now accepted and ready to land. https://reviews.llvm.org/D46363 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/c

[PATCH] D43787: Fix which Darwin versions have ObjC runtime with full subscripting support.

kubamracek added a comment. Great! So the versions in `ObjCRuntime.h` didn't really match what the iOS and macOS supported? https://reviews.llvm.org/D43787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailma

[PATCH] D42644: [asan] Intercept std::rethrow_exception indirectly.

kubamracek added a comment. > This is our first patch so we're unfamiliar with the LLVM testing > infrastructure. Could you please tell us what kind of test you'd like? An > example would also be great. Thank you for your first contribution! I'm going to comment on the testing infrastructure o

[PATCH] D42644: [asan] Intercept std::rethrow_exception indirectly.

kubamracek added a comment. Cool. Can we get a lit test as well? Repository: rCRT Compiler Runtime https://reviews.llvm.org/D42644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39114: [XRay][darwin] Initial XRay in Darwin Support

kubamracek added a comment. And we should probably introduce files named `xray_linux.cc` and `xray_mac.cc` to contain platform-specific functions. https://reviews.llvm.org/D39114 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.

[PATCH] D39114: [XRay][darwin] Initial XRay in Darwin Support

kubamracek added a comment. Hi, can you split the patch and send individual changes as separate patches? It's getting hard to follow. And I think we should land the parts that are "safe to land", e.g. the ASM changes or some of the NFC whitespace changes. The Darwin-specific changes in tests ca

[PATCH] D39114: [XRay][darwin] Initial XRay in Darwin Support

kubamracek added a comment. Can we just not use clock_gettime on Darwin and instead use mach_absolute_time? Repository: rL LLVM https://reviews.llvm.org/D39114 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/

[PATCH] D39114: [XRay][darwin] Initial XRay in Darwin Support

kubamracek added inline comments. Comment at: compiler-rt/trunk/lib/xray/xray_trampoline_x86_64.S:75 - .globl __xray_FunctionEntry + .globl ASM_TSAN_SYMBOL(__xray_FunctionEntry) .align 16, 0x90 Since we want to use `ASM_TSAN_SYMBOL` outside

[PATCH] D39114: [XRay] Initial XRay in Darwin Support

kubamracek added a comment. > When linking the final binary, the XRay runtime can't seem to find the > `__{start,stop}_xray_{fn_idx,instr_map}` symbols. I've marked them weak, but > they seem to either not be resolved when statically linking the binary. The > dynamic lib version of the XRay run

[PATCH] D39114: [XRay] Initial XRay in Darwin Support

kubamracek added a comment. Thanks for working on this! Can we split the patch and land parts that are LGTM? It's getting a bit crowded here. I think the ASM changes should be a separate patch, and the test changes as well, probably. https://reviews.llvm.org/D39114 _

[PATCH] D39114: [XRay] Initial XRay in Darwin Support

kubamracek added a comment. Also, please make sure this builds and tests pass before actually landing this patch. FYI, there are bots that run on older macOS versions (10.11 for sure, probably even older). https://reviews.llvm.org/D39114 ___ cfe-c

[PATCH] D39114: [XRay] Initial XRay in Darwin Support

kubamracek accepted this revision. kubamracek added a comment. This revision is now accepted and ready to land. Hi and sorry for replying so late! All of the changes LGTM with a few nits. > Assembly for Darwin x86_64 and how we avoid the ELF'isms (do we need to > implement darwin-specific assemb

[PATCH] D36437: [clang] Get rid of "%T" expansions

kubamracek created this revision. kubamracek added a project: clang. Herald added subscribers: mehdi_amini, klimek. The `%T` lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a sour

[PATCH] D34175: [driver][macOS] Pick the system version for the deployment target if the SDK is newer than the system

kubamracek added a comment. Nice! Repository: rL LLVM https://reviews.llvm.org/D34175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32029: [ObjC] Fix lifetime markers of loop variable in EmitObjCForCollectionStmt

kubamracek updated this revision to Diff 95271. kubamracek added a comment. Trying a different approach: Keeping the loop variable alive for the whole loop by extending ForScope and registering the cleanup function inside EmitAutoVarAlloca. https://reviews.llvm.org/D32029 Files: lib/CodeGe

[PATCH] D32029: [ObjC] Fix lifetime markers of loop variable in EmitObjCForCollectionStmt

kubamracek reopened this revision. kubamracek added a comment. This revision is now accepted and ready to land. Reverted because this fails for-in.m by crashing the compiler when compiling: void t2(NSArray *array) { for (NSArray *array in array) { // expected-warning {{collection expression

[PATCH] D32029: [ObjC] Fix lifetime markers of loop variable in EmitObjCForCollectionStmt

kubamracek added a comment. Note that C++ foreach loops also generate lifetime.start and lifetime.end inside of the loop body. Repository: rL LLVM https://reviews.llvm.org/D32029 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lis

[PATCH] D32029: [ObjC] Fix lifetime markers of loop variable in EmitObjCForCollectionStmt

kubamracek created this revision. kubamracek added a project: Sanitizers. CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: `lifetime.start` is emitted before the loop is entered, but `lifetime.end` is emitted inside the lo

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

kubabrecka added inline comments. Comment at: libcxx/include/memory:3702 +inline T +__libcpp_atomic_increment(T& t) _NOEXCEPT +{ I don't think this should be named `__libcpp_atomic_increment`, because it uses relaxed ordering and thus it's not a generic incremen