https://github.com/melver created https://github.com/llvm/llvm-project/pull/179028
Alias reassignment through pointer-to-pointer (nor ptr-to-ptr-to-ptr...) does not invalidate an alias for now. While this may result in either false positives or negatives, there's rarely a good reason not to just do direct assignment within the same scope. For the time being, we retain this as a deliberate "escape hatch": specifically, this may be used to help the alias analysis to "see through" complex helper macros that e.g. read a value (such as a pointer) via inline assembly or other opaque helpers [1]. Add a test to document the current behaviour. NFC. [1] https://lore.kernel.org/all/[email protected]/ >From 84669ac5fa993c4b1d1835bb1a548ae2643459b9 Mon Sep 17 00:00:00 2001 From: Marco Elver <[email protected]> Date: Sat, 31 Jan 2026 03:37:14 +0100 Subject: [PATCH] Thread Safety Analysis: Add test for alias reassignment through pointer-to-pointer Alias reassignment through pointer-to-pointer (nor ptr-to-ptr-to-ptr...) does not invalidate an alias for now. While this may result in either false positives or negatives, there's rarely a good reason not to just do direct assignment within the same scope. For the time being, we retain this as a deliberate "escape hatch": specifically, this may be used to help the alias analysis to "see through" complex helper macros that e.g. read a value (such as a pointer) via inline assembly or other opaque helpers [1]. Add a test to document the current behaviour. NFC. [1] https://lore.kernel.org/all/[email protected]/ --- .../SemaCXX/warn-thread-safety-analysis.cpp | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/clang/test/SemaCXX/warn-thread-safety-analysis.cpp b/clang/test/SemaCXX/warn-thread-safety-analysis.cpp index d9efa745b7d59..466135a1d9cef 100644 --- a/clang/test/SemaCXX/warn-thread-safety-analysis.cpp +++ b/clang/test/SemaCXX/warn-thread-safety-analysis.cpp @@ -7498,6 +7498,27 @@ void testReassignment() { ptr->mu.Unlock(); } +// Alias reassignment through pointer-to-pointer (nor ptr-to-ptr-to-ptr...) does +// not invalidate aliases for now. +// +// While this may result in either false positives or negatives, there's rarely +// a good reason not to just do direct assignment within the same scope. For the +// time being, we retain this as a deliberate "escape hatch": specifically, this +// may be used to help the alias analysis to "see through" complex helper macros +// that e.g. read a value (such as a pointer) via inline assembly or other +// opaque helpers. +void testReassignmentPointerToAlias(Foo *f) { + Mutex *mu = &f->mu; + // Escape hatch. + Mutex **mu_p = μ + Mutex *actual_mu = [&] { /* ... */ return mu; }(); + *mu_p = actual_mu; + + mu->Lock(); + f->data = 42; + mu->Unlock(); +} + // Nested field access through pointer struct Container { Foo foo; _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
