melver wrote:
Cleaned it up some more.
https://github.com/llvm/llvm-project/pull/142955
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver ready_for_review
https://github.com/llvm/llvm-project/pull/142955
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/142955
>From 608c4f657e2bcc0591e2fc32606a6738445cade6 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 21 May 2025 23:49:48 +0200
Subject: [PATCH] Thread Safety Analysis: Very basic capability alias-analysis
Add a
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/142955
>From c2dcde6db1d853bc4b30e8c5daf6165f7b45c6c6 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 21 May 2025 23:49:48 +0200
Subject: [PATCH] Thread Safety Analysis: Very basic capability alias-analysis
Add a
melver wrote:
> Thanks for the new diagnostic! I think you should also add a release note to
> `clang/docs/ReleaseNotes.rst` so users know about the new diagnostic group.
Added and updated the ThreadSafetyAnalysis.rst document as well.
PTAL.
https://github.com/llvm/llvm-project/pull/141599
__
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/141599
>From 83695bf73a66fb0024393466578a61feb2f2cd1d Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Tue, 27 May 2025 15:12:11 +0200
Subject: [PATCH] Thread Safety Analysis: Warn when using negative reentrant
capabil
@@ -4222,6 +4222,11 @@ def warn_fun_requires_lock_precise :
InGroup, DefaultIgnore;
def note_found_mutex_near_match : Note<"found near match '%0'">;
+// Pedantic thread safety warnings enabled by default
+def warn_thread_reentrant_with_negative_capability : Warning<
+ "%0 i
melver wrote:
> On a related note, do we emit `-Wthread-safety-negative` for reentrant locks?
> I don't remember that we carved out an exception for that, and we probably
> should.
We do - and it's deliberate on my part as I've been trying to indicate that
there might be valid use cases for t
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/141500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/142955
Add a simple form of alias analysis for capabilities by substituting local
pointer variables with their initializers if they are `const` or never
reassigned.
For example, the analysis will no longer generate fa
melver wrote:
@aaronpuchert - RFC regarding basic capability alias analysis.
For the bare minimum this would work, and likely covers 90% of the cases I
worry about. I believe later enhancements could be built on top.
There might be something I'm missing though. Kindly take a look.
Many thanks!
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/141599
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/141599
The purpose of negative capabilities is documented as helping to prevent double
locking, which is not an issue for most reentrant capabilities (such as
mutexes).
Introduce a pedantic warning group, which is ena
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/141500
In ScopedLockableFactEntry::unlock(), we can avoid a second search, pop_back(),
and push_back() if we use the already obtained iterator into the FactSet to
replace the old FactEntry and take its position in the
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From b8754a894e8822c43dfce62b7d13d5169ea4a215 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Thu, 24 Apr 2025 09:02:08 +0200
Subject: [PATCH] Thread Safety Analysis: Support reentrant capabilities
Introduce t
Author: Marco Elver
Date: 2025-05-26T16:59:51+02:00
New Revision: 365dcf48b8aa726fb6a9ace4b37eb1f1cf121941
URL:
https://github.com/llvm/llvm-project/commit/365dcf48b8aa726fb6a9ace4b37eb1f1cf121941
DIFF:
https://github.com/llvm/llvm-project/commit/365dcf48b8aa726fb6a9ace4b37eb1f1cf121941.diff
L
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From bce9df281e5ea7c2efd9c880f791f6572732c31d Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
> @melver, this request came from @AaronBallman. But since you're also working
> on Thread Safety Analysis in C, you might have some thoughts of your own
> about this.
>
> I haven't checked any real-world code yet. (Specifically, how many functions
> would be affected by this ex
melver wrote:
As additional motivation - quote from a kernel maintainer:
> But I think we should get the infrastructure in once your reentrancy
> support has landed in a release, because with that we can start
> annotation some code and show uses, while also helping to driver more
> requirements
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From b264872c3f28f6cf172b0123087adda9d53dc1b9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
Gentle ping - PTAL.
Many thanks!
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
Thanks for the feedback. Addressed comments as best as I could.
Most notable changes:
- Also warns properly for loops with mismatching reentrancy depth.
- Devirtualized new helpers.
- Require ordering `reentrant_capability` after `capability`.
- Stylistic improvements.
PTAL.
http
@@ -235,6 +266,20 @@ class FactSet {
return false;
}
+ std::optional replaceLock(FactManager &FM, iterator It,
+std::unique_ptr Entry) {
+if (It == end())
+ return std::nullopt;
+FactID F = FM.newFact(std::move(Entry));
+
Author: Marco Elver
Date: 2025-05-09T20:14:30+02:00
New Revision: 49c22e3ee147326668aa0b2097f857d0b0c2a81e
URL:
https://github.com/llvm/llvm-project/commit/49c22e3ee147326668aa0b2097f857d0b0c2a81e
DIFF:
https://github.com/llvm/llvm-project/commit/49c22e3ee147326668aa0b2097f857d0b0c2a81e.diff
L
@@ -271,26 +272,34 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ static constexpr unsigned FlagNegative = 1u << 0;
@@ -1011,6 +979,30 @@ void SExprBuilder::exitCFG(const CFGBlock *Last) {
IncompleteArgs.clear();
}
+static CapabilityExpr makeCapabilityExpr(const til::SExpr *E, QualType VDT,
+ bool Neg) {
+ // We need to look at the declaration of t
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
@@ -4048,6 +4048,9 @@ def warn_thread_attribute_not_on_scoped_lockable_param :
Warning<
"%0 attribute applies to function parameters only if their type is a "
"reference to a 'scoped_lockable'-annotated type">,
InGroup, DefaultIgnore;
+def warn_reentrant_capability_witho
@@ -1078,22 +1091,65 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
@@ -1078,22 +1091,65 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
https://github.com/melver commented:
Generally LGTM - but let's also wait for others to comment.
Documentation of this feature is lacking (and afaik also wasn't added in
https://reviews.llvm.org/D36839). Given this will be used in the kernel, some
kind of official documentation might be good t
https://github.com/melver approved this pull request.
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1078,22 +1092,44 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
https://github.com/melver requested changes to this pull request.
This is also missing flag and IR tests.
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -34,6 +34,7 @@ class SanitizerArgs {
std::vector CoverageIgnorelistFiles;
std::vector BinaryMetadataIgnorelistFiles;
int CoverageFeatures = 0;
+ int StackDepthCallbackMin = 0;
melver wrote:
`CoverageStackDepthCallbackMin`
https://github.com/llvm/llv
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From a8319028f08192ca6140beed7f27a83a829c6d84 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
Author: Marco Elver
Date: 2025-04-30T08:49:15+02:00
New Revision: 4bf93c098c8b04a06f228b05732d691d0ce2babc
URL:
https://github.com/llvm/llvm-project/commit/4bf93c098c8b04a06f228b05732d691d0ce2babc
DIFF:
https://github.com/llvm/llvm-project/commit/4bf93c098c8b04a06f228b05732d691d0ce2babc.diff
L
@@ -388,7 +395,7 @@ class SExprBuilder {
til::LiteralPtr *createVariable(const VarDecl *VD);
// Create placeholder for this: we don't know the VarDecl on construction
yet.
- std::pair
+ std::pair
melver wrote:
I think this code is just more complex tha
@@ -81,26 +81,25 @@ static bool isCalleeArrow(const Expr *E) {
return ME ? ME->isArrow() : false;
}
-static StringRef ClassifyDiagnostic(const CapabilityAttr *A) {
- return A->getName();
-}
-
-static StringRef ClassifyDiagnostic(QualType VDT) {
+static CapabilityExpr makeCa
@@ -235,6 +266,20 @@ class FactSet {
return false;
}
+ std::optional replaceLock(FactManager &FM, iterator It,
+std::unique_ptr Entry) {
+if (It == end())
+ return std::nullopt;
+FactID F = FM.newFact(std::move(Entry));
+
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
> I think the biggest issue is that removing `const` from `FactEntry` does not
> work. You'll have to undo all those changes and instead create a new
> `FactEntry` for every lock/unlock.
Good catch, reworked this.
PTAL.
https://github.com/llvm/llvm-project/pull/137133
__
@@ -434,6 +434,16 @@ class can be used as a capability. The string argument
specifies the kind of
capability in error messages, e.g. ``"mutex"``. See the ``Container`` example
given above, or the ``Mutex`` class in :ref:`mutexheader`.
+REENTRANT
+-
+
+``REENTRANT``
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
@@ -3990,6 +3990,13 @@ def LocksExcluded : InheritableAttr {
let Documentation = [Undocumented];
}
+def ReentrantCapability : InheritableAttr {
+ let Spellings = [Clang<"reentrant_capability">];
+ let Subjects = SubjectList<[Record, TypedefName]>;
+ let Documentation = [U
@@ -1831,15 +1852,15 @@ void BuildLockset::handleCall(const Expr *Exp, const
NamedDecl *D,
assert(!Self);
const auto *TagT = Exp->getType()->getAs();
if (D->hasAttrs() && TagT && Exp->isPRValue()) {
- std::pair Placeholder =
- Analyzer->SxBuilder.crea
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
@@ -163,15 +184,15 @@ using FactID = unsigned short;
/// the analysis of a single routine.
class FactManager {
private:
- std::vector> Facts;
+ std::vector> Facts;
melver wrote:
Fixed.
I guess we have to do clone-mutate-replace of the FactEntries - a little
Author: Marco Elver
Date: 2025-04-25T09:56:54+02:00
New Revision: a9788e3a86cab64ae92dd7d041718b0722f43c3a
URL:
https://github.com/llvm/llvm-project/commit/a9788e3a86cab64ae92dd7d041718b0722f43c3a
DIFF:
https://github.com/llvm/llvm-project/commit/a9788e3a86cab64ae92dd7d041718b0722f43c3a.diff
L
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From c60ccbc31de8e81e6a4af915a83b8271f58f8e7e Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From c60ccbc31de8e81e6a4af915a83b8271f58f8e7e Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
In
https://lore.kernel.org/all/CANpmjNPquO=W1JAh1FNQb8pMQjgeZAKCPQUAd7qUg=5pjJ6x=q...@mail.gmail.com/
I wrote:
> 1. Re-entrant acquires: rcu_read_lock(), preempt_disable(), etc. are
> all re-entrant locks. My proposal is to introduce an attribute that
> can be added to "ACQUIRE(.
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/137133
Introduce the `reentrant_capability` attribute, which may be specified
alongside the `capability(..)` attribute to denote that the defined
capability type is reentrant. Marking a capability as reentrant means
that
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
Committed!
> Looks good to me, and thanks for the contribution!
Thanks for your review!
Fingers crossed the Linux kernel changes will also land soon.
> > Note, I think for now it might be safer to not enable by default yet, but
> > I've made a note (and hinted at in changelog)
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Marco Elver
Date: 2025-02-26T16:34:33+01:00
New Revision: 3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6
URL:
https://github.com/llvm/llvm-project/commit/3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6
DIFF:
https://github.com/llvm/llvm-project/commit/3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6.diff
L
Author: Marco Elver
Date: 2025-02-26T16:34:33+01:00
New Revision: de10e44b6fe7f3d3cfde3afd8e1222d251172ade
URL:
https://github.com/llvm/llvm-project/commit/de10e44b6fe7f3d3cfde3afd8e1222d251172ade
DIFF:
https://github.com/llvm/llvm-project/commit/de10e44b6fe7f3d3cfde3afd8e1222d251172ade.diff
L
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From f9fec4c8415b2b9c802b1d7ecdcc9f5cb038f7be Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
melver wrote:
> I think this looks very good! I just have some minor remarks.
>
> Thanks to @aoates for trying this out, this is always appreciated!
>
> And sorry for the delay.
Thanks for the review! I addressed the comments, PTAL.
Note, I think for now it might be safer to not enable by def
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From f9fec4c8415b2b9c802b1d7ecdcc9f5cb038f7be Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4955,13 +4968,18 @@ class Foo {
//showDataCell(*datap2_); // xpected-warning {{reading the value pointed
to by 'datap2_' requires holding mutex 'mu_'}}
int a = data_[0]; // expected-warning {{reading variable 'data_'
requires holding mutex 'mu_'}}
+
+(v
@@ -528,6 +529,9 @@ for a period of time, after which they are migrated into
the standard analysis.
* ``-Wthread-safety-beta``: New features. Off by default.
+ + ``-Wthread-safety-pointer``: Checks when passing or returning pointers to
+guarded variables, or pointers
@@ -528,6 +529,9 @@ for a period of time, after which they are migrated into
the standard analysis.
* ``-Wthread-safety-beta``: New features. Off by default.
+ + ``-Wthread-safety-pointer``: Checks when passing or returning pointers to
+guarded variables, or pointers
@@ -6087,9 +6215,37 @@ class Return {
const Foo &returns_constref_shared_locks_required()
SHARED_LOCKS_REQUIRED(mu) {
return foo;
}
+
+ Foo *returns_ptr_exclusive_locks_required() EXCLUSIVE_LOCKS_REQUIRED(mu) {
+return &foo;
+ }
+
+ Foo *returns_pt_ptr_exclusive
melver wrote:
> I only have a few comments about documenting the caveats (no alias analysis).
>
> The actual code changes look very simple and this looks like a clear
> improvement that would catch many useful cases.
>
> I don't have much experience with this code and would still advise to wai
@@ -143,6 +143,11 @@ Improvements to Clang's diagnostics
- A statement attribute applied to a ``case`` label no longer suppresses
'bypassing variable initialization' diagnostics (#84072).
+- The :doc:`ThreadSafetyAnalysis` now supports ``-Wthread-safety-pointer``
---
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From a70f021becb2888d6c2a63b2d1e619393a996058 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
melver wrote:
> > I need to commit this by end of day Wednesday - if I should wait a little
> > longer, let me know so I can plan around it. Thanks.
>
> Sorry, but I'm at C standards meetings this week, so I don't think I'll be
> able to review it by then. CC @aaronpuchert who maybe can help?
melver wrote:
Gentle ping.
Thanks!
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
> I'm very excited about this, as I have wanted it for many years for my C
> codebase, and TSA is not super useful in C without this!
This PR is being superseded by https://github.com/llvm/llvm-project/pull/127396
(implementation changed completely) - we agreed to go with the mor
melver wrote:
FWIW, I'm ready for sending a v2 series to the Linux kernel mailing list:
https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/log/?h=cap-analysis/dev
But I'd like to sort out this PR first before sending the v2 series.
https://github.com/llvm/llvm-project/pull/127396
melver wrote:
(Side-note: I cannot figure out what the canonical way to do "stacked commits"
is for LLVM these days, so I'm just doing this the "old" way i.e. plain and
simple normal git commits which I will commit separately after PR review.)
https://github.com/llvm/llvm-project/pull/127396
_
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver converted_to_draft
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
[...]
> Then we only need to make sure that `checkPtAccess` can look through `&`, as
> mentioned above. (Casts should already be unwrapped.) This might not even
> need a new flag, it's just closing a gap in the existing analysis.
Thanks for the suggestions!
I implemented both -
melver wrote:
Superseded by https://github.com/llvm/llvm-project/pull/127396
https://github.com/llvm/llvm-project/pull/127397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/127397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From a70f021becb2888d6c2a63b2d1e619393a996058 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
1 - 100 of 157 matches
Mail list logo
